renaming from gitTally to Werkator

docs/adrs/0006-2026-08-10.runtime-bundle-distribution.md

@@ -6,30 +6,30 @@
 - rejected: -
 - superseded: -
 
-**Decision [accepted]:** GitTally is distributed for hosts without a Java runtime as a self-contained runtime bundle — a jlink-trimmed JRE plus `gittally.jar` plus a launcher script in one tarball, built by `./gradlew runtimeBundle`.
-The JAR stays the primary artifact; a GraalVM native image and a containerized GitTally runtime were rejected.
+**Decision [accepted]:** werkator is distributed for hosts without a Java runtime as a self-contained runtime bundle — a jlink-trimmed JRE plus `werkator.jar` plus a launcher script in one tarball, built by `./gradlew runtimeBundle`.
+The JAR stays the primary artifact; a GraalVM native image and a containerized werkator runtime were rejected.
 
 ## Context and Problem Statement
 
-GitTally must run on Hostsharing container servers (the primary target, see ADR 0005).
+werkator must run on Hostsharing container servers (the primary target, see ADR 0005).
 These hosts provide git, Docker, make, and systemd user sessions, but no Java runtime, and nothing may be installed system-wide.
-`docs/bootstrapping.md` sketched a containerized GitTally runtime as the future answer; that sketch was never validated against the operational details.
+`docs/bootstrapping.md` sketched a containerized werkator runtime as the future answer; that sketch was never validated against the operational details.
 
 ## Considered Options
 
 * jlink runtime bundle (trimmed JRE + jar + launcher, one tarball)
 * GraalVM native image (single executable)
-* Containerized GitTally runtime (the original `docs/bootstrapping.md` sketch)
+* Containerized werkator runtime (the original `docs/bootstrapping.md` sketch)
 
 ### jlink Runtime Bundle
 
-A `jlink`-generated JRE with the pinned module list, the boot jar, and a `bin/gittally` launcher script, packed as `gittally-runtime-linux-x64.tar.gz` (~66 MB) and unpacked to `~/opt/gittally/` on the target host.
+A `jlink`-generated JRE with the pinned module list, the boot jar, and a `bin/werkator` launcher script, packed as `werkator-runtime-linux-x64.tar.gz` (~66 MB) and unpacked to `~/opt/werkator/` on the target host.
 
 Good:
 
 - No production-code changes and plain JVM semantics — no new failure modes.
 - git and docker CLIs are used from the host; build worktree paths stay host paths.
-- `init --systemd` works unchanged: `java.home` and the running-jar path resolve into the bundle, so the generated unit points at `<bundle>/jre/bin/java` and `<bundle>/lib/gittally.jar` (verified).
+- `init --systemd` works unchanged: `java.home` and the running-jar path resolve into the bundle, so the generated unit points at `<bundle>/jre/bin/java` and `<bundle>/lib/werkator.jar` (verified).
 - Every JDK 21 ships jlink — no new build-toolchain requirement.
 
 Bad:
@@ -44,12 +44,12 @@ Bad:
 
 ### GraalVM Native Image
 
-Rejected because Spring AOT evaluates bean conditions at build time, and GitTally's dual-mode wiring cannot be represented in a single AOT arrangement:
+Rejected because Spring AOT evaluates bean conditions at build time, and werkator's dual-mode wiring cannot be represented in a single AOT arrangement:
 the CLI context runs without web and with `@Profile("!server")` `CliRunner`, while the `server` subcommand starts a second `SpringApplication` with `WebApplicationType.SERVLET` and the `server` profile gating the watcher/metrics/nginx lifecycles.
 Whichever profile and web type the AOT processing fixes, the other mode's beans are missing from the binary.
 Supporting both would require replacing the profile wiring with runtime guards and collapsing the two context shapes — an invasive rewrite with regression risk for the JVM path, on top of the usual native-image reflection work (Jackson-bound config and persistence classes, picocli).
 
-### Containerized GitTally Runtime
+### Containerized werkator Runtime
 
 Rejected for operational complexity: the image must bundle git and docker CLIs; the container needs a same-path `$HOME` mount plus a docker-socket mount and uid/gid mapping so that `DockerBuildRunner`'s `--volume $workspace:$workspace` sibling mounts keep working; and the systemd unit must be hand-edited to a `docker run` invocation.
 This remains the documented fallback if the runtime bundle ever becomes unworkable.