Merge PR #666: fleetd #664 — correct the main-clone build guidance

The old text warned only that a 'mvn clean' deletes the running daemon's jar.
Replacement is enough: the shutdown drain loads its classes lazily, at
shutdown, from the jar file the JVM opened at boot. So any build that writes
fleetd/target/fleetd.jar under a live daemon breaks its drain, nothing warns
at the time, and the damage surfaces at the next restart where it looks like
the restart's fault.

Both files now state the real rule and the positive one: verify a merge by
building in a throwaway git worktree, and let only
scripts/redeploy-fleetd.sh touch the main clone's jar.

The canonical block is untouched (20938 bytes, identical to main) and the
wiki sync check passes against wiki/7-Use-Cases.md.

.claude/skills/redeploy-fleetd/SKILL.md

@@ -26,9 +26,15 @@ scripts/redeploy-fleetd.sh --no-build # restart the jar already on disk
 when you just built and nothing changed since. It gives up the protection in the next paragraph: no
 build runs, so a stale or missing jar is not caught early. The script still checks the file is there
 and dies with `no jar at … — run without --no-build` if it is not, but it cannot tell you the jar is
-old. A `mvn clean` in the tree deletes that jar while the daemon keeps running on it, and nothing
-degrades until the next restart. Run `--check` first: it prints the jar's hash and its modification
-time, so you can see for yourself whether the jar is missing or older than the code you mean to ship.
+old. Any build that writes `fleetd/target/fleetd.jar` while the daemon runs, including `mvn install`
+with or without `clean`, breaks that daemon's shutdown drain. The drain loads its classes lazily at
+shutdown from the jar file the JVM opened at boot. Deleting is not the only hazard; replacing the jar
+is enough. Nothing warns at the time. The damage appears at the next restart, where it looks like the
+restart's fault. Verify a merge by building in a throwaway git worktree. Let only
+`scripts/redeploy-fleetd.sh` touch the main clone's jar. Its stage-then-swap protects its own build,
+but it cannot undo a replacement that already happened. Run `--check` first: it prints the jar's hash
+and its modification time, so you can see for yourself whether the jar is missing or older than the
+code you mean to ship.
 
 It builds before it stops anything, so a failed build never leaves the fleet down; it waits for the
 old process to exit rather than assuming; it polls `/healthz`; and it anchors its log checks to a

CLAUDE.md

@@ -323,6 +323,12 @@ must obey belongs in the charter, not here.
   reference**, with the intent→tool table above as the short form. `McpContractDocTest` fails if
   that page names a `fleet_*` tool the server does not register. The flows are kept out of this
   file because this file loads into every session's context.
+- **Never build into the main clone while `fleetd` runs.** Any build that writes
+  `fleetd/target/fleetd.jar`, with or without `clean`, breaks the shutdown drain because its classes
+  load lazily from the jar file the JVM opened at boot. Nothing warns at the time. The damage appears
+  at the next restart, where it looks like the restart's fault. Verify merges in a throwaway git
+  worktree. Let only `scripts/redeploy-fleetd.sh` touch the main clone's jar. Its stage-then-swap
+  cannot undo a replacement that already happened.
 
 ### Redeploying the daemon — the lead may do this (primary only)