1044 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
ltms	40c593cd09	Merge #508: a herdr error during the pane scan is refused, not promoted to primary (fleetd #505) ... Closes the worker->primary escalation that fleetd #317 left open on the other side of the same ternary. #317 stopped an UNRESOLVABLE pid being promoted. This stops a RESOLVED pid whose pane scan failed being promoted: the scan now reports completeness, and an incomplete scan resolves to anonymous. Shape chosen: PaneLocator.terminalForPid returns Lookup(terminal, complete); paneOwnsAnyOf returns a private Ownership enum OWNS/DOES_NOT_OWN/UNKNOWN, so a HerdrException is UNKNOWN rather than a clean negative. ConnectionIdentity.Caller gains scanComplete as a third field -- resolved() was NOT widened, correctly: it is documented as testing the lsof sentinel and #505 is a different axis. A definite match still short-circuits, so a genuinely vanished non-owning pane does not become a refusal. Verified by me, not taken from the report. Trial-merged onto main (136312f) and built the merge: mvn clean install -> Tests run: 1694, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS Harness proof, by re-running the worker's own mutation rather than trusting it (UNKNOWN -> DOES_NOT_OWN): Tests run: 63, Failures: 3 -- exactly the three tests meant to pin it, matching their report line for line: CallerResolverTest.aHerdrErrorOnTheOwningPaneDuringTheScanIsRefusedNotPromotedToPrimary ConnectionIdentityTest.scanIsIncompleteWhenHerdrErrorsOnThePaneThatOwnsThePid PaneLocatorTest.anErrorOnThePaneThatOwnsThePidMakesTheScanIncompleteNotAClearNegative So the cells can go red, and their numbers are honest. Restored, shasum 81b797a6... byte-identical, control 63/0. MY OWN MUTATION, on the half they did not touch, FOUND A GAP. I mutated the two-client completeness fold in terminalForPid -- `complete = complete && outcome.complete()` -> `complete = outcome.complete()`, which forgets an earlier client's failure. Two greps proved it applied. Result: Tests run: 63, Failures: 0. NOT pinned. It is not an equivalent mutant: with CB-185's two herdr daemons, a first client that scans incompletely followed by a second that scans cleanly gives `false` originally and `true` mutated, so an incomplete scan would be reported complete and promoted. It is the #393 shape instead -- no test assembles that combination, because the single-daemon tests collapse lead and member to one object. That axis has cost us before: four routing defects passed the suite when one client served both roles with memberHerdrSocket unset. Merging anyway, because the production behaviour is correct and the ticket's defect is pinned three ways -- what is missing is a test for a dimension the PR description claims in prose. Filed as a follow-up with the numbers above. Second item for the follow-up, latent not live: FleetMcp.legacyPrincipal still does `c.terminal() != null ? worker : primary` and drops scanComplete, so it would re-open exactly this hole. Measured unreachable in production -- Fleetd.java:696 always passes a real CallerResolver, and the contextExtractor only calls legacyPrincipal when `callers == null`. A defect on paper is not a reachable defect, so it is not a blocker; it is a trap for whoever next touches that constructor. That second item is also the fleet01 lead's structural point, and it is the sharper framing: #415's antidote (make the decision total) is ORTHOGONAL to this defect. Authz.permits is already a default-less switch over Action and cannot help, because it says nothing about whether the caller was resolved correctly, and Principal carries no record of how it was resolved. #415 guards a decision nobody wrote; this was a decision written correctly and fed a bad input. The durable fix direction is that an unresolved scan should be unrepresentable as a principal rather than checked for at each consumer.	2026-09-12 05:35:41 +02:00
Dai Ha	979adf82eb	fleetd #493: never build into the path a running daemon holds ... redeploy-fleetd.sh's build step wrote straight into fleetd/target/fleetd.jar via `mvn clean install` while the OLD daemon was still running from that exact path. A JVM loads classes lazily, so a class the daemon had not touched yet could be read from a jar already replaced or removed -- the failure landed on the shutdown drain (NoClassDefFoundError, exit 143, looks clean). Stage the freshly built jar at target/fleetd-new.jar (stage_built_jar), confirm the OLD pid has actually exited (wait_for_daemon_exit, extracted from the existing wait loop), and only then swap it into the live path (swap_staged_jar) -- strictly after the wait, strictly before start. A failed swap dies without starting. --no-build and --check keep their existing, truthful behavior (require_no_build_jar; jar_id still reads the live path by default). A leftover staged jar from an interrupted run is wiped before the next build. The build still runs before anything is stopped, so a failed build still never takes the fleet down. Also fixed: the drain-gate abort message ("aborted -- nothing changed") now names the staged jar when one exists, since staging already moves the freshly built jar off the live path before that prompt runs. Adds unit tests for stage_built_jar, swap_staged_jar, require_no_build_jar, wait_for_daemon_exit, and a source-order test proving swap sits after the wait and before start (sourcing stops before the main flow ever runs, so the ordering itself can only be checked by reading the script's own call sites).	2026-09-12 10:35:19 +07:00
Dai Ha	36870836aa	fleetd #505: a herdr error during the pane scan must not read as a clean negative ... A transient herdr error on pane.process_info during PaneLocator's pid→pane scan used to be swallowed into a plain "does not own it", so a real worker whose owning pane errored mid-scan resolved with a null terminal but a resolved (real) pid — exactly what CallerResolver's loopback-trust fallback reads as the primary. That is a worker→primary privilege escalation through the door fleetd #317 did not close: #317 guards a failed lsof lookup (c.resolved()), not a failed herdr pane scan. Fix: add a third state to the scan instead of widening Caller.resolved() (which stays centralised next to the lsof sentinel it tests, per #505's explicit instruction not to reopen that decision). PaneLocator.terminalForPid now returns a Lookup(terminal, complete) record: a HerdrException on one pane marks that pane's ownership UNKNOWN, not DOES_NOT_OWN, and the scan is complete only if every pane was either matched or confirmed not to own the pid. A definite match found elsewhere in the same scan still short-circuits as complete — a pane that genuinely vanished mid-scan without being the caller's own does not turn into a refusal. ConnectionIdentity.Caller carries the new scanComplete flag alongside the unchanged resolved(). CallerResolver's loopback-trust fallback now requires both resolved() and scanComplete() before promoting to Principal.primary(); an incomplete scan resolves anonymous, which fails toward the recoverable error (a refused primary retries loudly; a promoted worker would not). Logs a warning naming the pane and which herdr client (of how many) failed, so the incomplete-scan path is diagnosable rather than silent (fleetd #317's own lesson).	2026-09-12 10:27:42 +07:00
ltms	136312fb11	Merge #503: Injector's readiness-grace warn prints measured elapsed time, never arithmetic on constants (fleetd #501) ... Verified by the lead, not taken from the worker's report. Trial-merged onto main (4f28da6) and built the merge, because a clean auto-merge is not a compiling merge: mvn clean install -> Tests run: 1689, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS InjectorTest -> Tests run: 34, Failures: 0 Gitea CI on ac351ee: success The worker mutated the two log arguments. I mutated the half it did not: the STAMP SITE. Changing the first-sample guard so the clock is re-stamped on every non-ready poll gave 1 failure, InjectorTest.readinessGraceExpiryLogsTheMeasuredElapsedTimeNotArithmeticOnConstants, on a clock-read counter assertion: "the readiness-not-ready branch should read the clock exactly twice — once to stamp the first non-ready sample, once at grace expiry". Two greps proved the mutant applied; restored, shasum byte-identical, control 34/0 green. Behaviour preserved: the restructure from `else if (p != null && ++t.notReadySincePoll >= N)` to a nested `else if (p != null) { ... }` keeps the short-circuit, so the counter still increments only when p != null. All three reset sites now clear notReadySinceMillis alongside notReadySincePoll. Two notes for the record, neither a blocker. The poll-count half is an equivalent mutant and the worker said so instead of reporting a kill it did not get. That is the right call and the code comment states the limit honestly. The clock is injected through a package-private constructor overload while the public constructors default it to System::currentTimeMillis. My brief prescribed that shape. With exactly one production construction site (Fleetd.java:531) a required parameter — fleetd #415's antidote — would have been just as cheap and would match LeadRollover and the new Fleetd.awaitHerdr. The silent-survivor risk #415 names is not present here, because the field is final and both public constructors delegate, so a future constructor cannot compile without supplying it. Recording the choice so the next person does not read it as an oversight.	2026-09-12 05:07:35 +02:00
ltms	4f28da62a3	Merge #499: redeploy-fleetd.sh gains an "unclear" supervisor state that cannot reach kill, and the detail survives the subshell (fleetd #492, #497) ... Two commits, b17f37a and 599419f. Verified by the lead, not taken from the worker's report. b17f37a adds the fifth answer "unclear" for installed-but-not-loaded and for a probe that could not answer at all, and makes require_drivable_supervisor die on it. 599419f fixes a defect I found in b17f37a: SUPERVISOR_UNCLEAR_DETAIL was set inside detect_supervisor, which is called as $(detect_supervisor). A subshell only returns stdout, so the detail never reached the caller, and a ${VAR:-generic} fallback then printed a message naming no supervisor and no reason. Measured before the fix: plain call -> detail length 142; via $( ) -> length 0. Lead verification of the fix, re-running my own original measurement across every branch: launchd installed, not loaded kind=[unclear] detail_len=142 systemd installed, not active kind=[unclear] detail_len=146 launchd loaded (normal) kind=[launchd] detail_len=0 systemd loaded (normal) kind=[systemd] detail_len=0 neither -> none kind=[none] detail_len=0 both loaded -> ambiguous kind=[ambiguous] detail_len=0 The separator is always emitted, so the ${RAW#*SEP} unpack cannot silently fall back to the whole string on the four branches that carry no detail. Harness proof, run by me: making detect_supervisor print the kind alone (two greps proved the mutant applied) turned the suite red, exit 1, "FAIL: detail does not name the systemd unit it found installed-but-not-loaded". Restored, shasum byte-identical, control exit 0, bash -n clean on both files. 23 test functions defined, 23 invoked. The three case "$SUPERVISOR_KIND" switches now have final arms, chosen by what each caller does with the value: the reporting switch warns and continues (a diagnostic that aborts goes silent exactly when the state is novel), while stop and start die. Not fixed here, filed separately: the "was already not running" branches at :603 and :610 swallow a failed launchctl unload / systemctl stop with || true and then print "ok" unconditionally.	2026-09-12 05:04:04 +02:00
ltms	708f1795ad	Merge #502: awaitHerdr reports three outcomes with measured elapsed time, not one boolean (fleetd #498) ... Verified by the lead, not taken from the worker's report. Trial-merged onto main (8f59019) locally and built the merge, because a clean auto-merge is not a compiling merge: mvn clean install -> Tests run: 1687, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS FleetdAwaitHerdrTest -> Tests run: 6, Failures: 0 Gitea CI on 274afaf: success The worker mutated the three return values. I mutated the half it did not: the reap DECISION at the call site. Changing logHerdrWaitOutcomeAndShouldReap to return true for INTERRUPTED gave 1 failure, FleetdAwaitHerdrTest.interruptedLogsItsOwnMessageAndNeverClaimsTheBudgetElapsed:135 ("an interrupted wait must not tell main to reap"). Two greps proved the mutant applied; restored, shasum byte-identical, control 6/0 green. Behaviour preserved: herdrUp is still true only for ANSWERED, and both its readers (the orphan reap at :276 and the lead auto-launch gate at :375) see exactly what they saw before. One correction to the worker's report, which changes nothing in the code. It wrote that a real interrupt-detection regression "would also hang the daemon's startup thread forever". It would not: in production `nanos` is System::nanoTime, so the deadline check still fires. The hang it hit was a test-fixture property — a frozen injected clock with no iteration bound. That is fleetd #486's shape, now seen in a second class, and it is recorded there.	2026-09-12 05:01:02 +02:00
Dai Ha	599419f9e6	fleetd #492 follow-up: carry the unclear detail across detect_supervisor's subshell boundary ... b17f37a set SUPERVISOR_UNCLEAR_DETAIL as a global inside detect_supervisor, but the real call site invokes it as $(detect_supervisor) — a subshell — so that global died with the subshell and the die() message's ${VAR:-fallback} silently masked the loss with generic text. - detect_supervisor now packs kind and detail onto its one stdout line (joined by the ASCII unit separator byte, $SUPERVISOR_DETAIL_SEP), the only channel that survives $( ). The real call site unpacks both with in-shell parameter expansion — no extra subshell. - Dropped the ${SUPERVISOR_UNCLEAR_DETAIL:-...} fallback at the die() message: under set -u, a missing detail now fails loudly instead of silently defaulting (same defect class as #497). - Added a constraints comment block above detect_supervisor for future callers: stdout-only, no ${VAR:-default} papering over a lost value, and every case on the return value needs an explicit *) arm. - Added *) arms to the three `case "$SUPERVISOR_KIND"` switches (report/stop/start): report warns and continues (display-only), stop/start die naming the value (they act on it). - Rewrote the "unclear" test to go through the real call-site shape ($(detect_supervisor) then the same split), not a hand-constructed value, and tightened its final assertion to check for the actual detail text rather than $SYSTEMD_UNIT alone (the die() boilerplate names the unit either way, so that check could pass on a lost value).	2026-09-12 09:58:45 +07:00
Dai Ha	ac351ee1de	fleetd #501: readiness-grace expiry logs measured elapsed time and the loop's own poll counter, never the configured budget ... The line at Injector.java:383-387 printed two numbers that read as measurements but were both compile-time constants: READINESS_GRACE_POLLS for the poll count (the loop's own Target.notReadySincePoll counter was in scope at the same call site), and READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS / 1000 for the elapsed time — arithmetic on two constants, never a measurement, and wrong in the direction that says everything ran on schedule. Fix, copying the LongSupplier-clock shape LeadRollover already uses: - print t.notReadySincePoll instead of the constant for the poll count (the two agree by construction on this branch, so no test can tell them apart — the comment says so honestly). - add Target.notReadySinceMillis, stamped at the first non-ready sample and reset at all three sites notReadySincePoll already resets (:304, :355, :389 pre-fix line numbers), to compute a real elapsed time at expiry. - inject a LongSupplier nowMillis (defaulting to System::currentTimeMillis) through new package-private constructor overloads so a test can supply a clock whose advance does not track POLL_INTERVAL_MILLIS. Tests use a ListAppender to assert on the log message contents, per LeadRolloverTest's pattern. The elapsed-time test drives the loop with a stub clock returning two literal, non-derived values so it can fail if the fix regresses to the constant-arithmetic line — proved by mutation: reverting the elapsed calculation to READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS turns that one test red (1 failure); reverting the poll-count print to the constant is an equivalent mutant (0 failures), because the counter and the constant are identical at that exact call site by construction. fleetd clean install: Tests run: 1683, Failures: 0, Errors: 0, Skipped: 0.	2026-09-12 09:57:57 +07:00
Dai Ha	274afafde6	fleetd #498: awaitHerdr distinguishes deadline-passed from interrupted, with measured elapsed time ... - awaitHerdr now returns a HerdrAwaitOutcome(HerdrWaitResult, elapsedNanos) instead of a bare boolean, so 'the wait budget genuinely ran out' and 'the waiting thread was interrupted' are two distinct, named states instead of the same false (fleetd #497's shape). - awaitHerdr takes the clock (LongSupplier) and the per-poll sleep (Runnable) as required parameters, with no defaulted overload (fleetd #415), so a test can drive it. - The startup call site is extracted into logHerdrWaitOutcomeAndShouldReap, since main() itself cannot be driven from a unit test; it logs a distinct message per outcome, always printing the measured elapsed time next to the configured budget, never the budget alone. - Adds FleetdAwaitHerdrTest covering the seam (all three outcomes, plus the preserved interrupt flag) and the call site (the three distinct log messages), using ListAppender.	2026-09-12 09:54:59 +07:00
ltms	8f59019305	Merge #496: lead-rollover logs measured elapsed time and measured counts, never the configured budget (fleetd #494) ... Three commits. All verified by the lead in a detached worktree, not taken from the worker's report. 3fb3311 — the /clear-settle and success paths return measured elapsed time and a real nudge count c87cc25 — print the measured nudge count; fix the same defect on the sibling turn-settle timeout line e966cba — the poll count on the same line was still a constant; the test could not tell the difference Lead verification at e966cba: mvn clean install -> Tests run: 1681, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS LeadRolloverTest -> Tests run: 33, Failures: 0, Errors: 0, Skipped: 0 Gitea CI on e966cba: success Mutation M2 (PICKUP_GRACE_POLLS 8 -> 5), run by the lead: 2 failures, clearGraceReleaseLogIsWarnWithMeasuredElapsed and successLogPrintsMeasuredElapsedForTheWholeRoll. The emitted line under the mutant read "after 5 consecutive IDLE/DONE polls (4 of those were nudged)", so both numbers now follow the loop. Restored, shasum byte-identical, control 33/0 green. Known and deliberate limit, stated in the code comment: on the grace-release branch both counters equal the constants by construction (one write site each), so no test can prove the difference on that line. The change buys one source of truth, not provable coverage. The place nudges genuinely varies with the run is the /clear-timeout warn, which is covered by a discriminating test.	2026-09-12 04:44:10 +02:00
Dai Ha	e966cbadf9	fleetd #494 follow-up (2nd pass): the grace-release line still had one constant, and its test could not tell the difference ... Two more fixes on the same line, LeadRollover.java:600-624: 1. The poll-count argument (second, was PICKUP_GRACE_POLLS) now prints the loop's own idlePollsAwaitingPickup counter instead of the constant. Same defect shape as the nudges fix from c87cc25, one argument over. 2. LeadRolloverTest's clearGraceReleaseLogIsWarnWithMeasuredElapsed asserted its nudge-count expectation as `LeadRollover.PICKUP_GRACE_POLLS - 1` — the same expression the production code used to build the log line from, so it could not discriminate a reverted fix. Rewritten to plain literals ("after 8 consecutive IDLE/DONE polls (7 of those were nudged)"), proven to trip when PICKUP_GRACE_POLLS's value changes (2 failures under a PICKUP_GRACE_POLLS=5 mutation: this test and successLogPrintsMeasured...). Also corrected the comment above the log line: idlePollsAwaitingPickup and nudges each have exactly one write site on this loop's release branch, so they cannot differ from PICKUP_GRACE_POLLS / PICKUP_GRACE_POLLS - 1 at this call site — confirmed by re-deriving the loop's control flow, and by reverting just the nudges argument (M1) and observing 33/0 stayed green even after the test rewrite. That is an equivalent mutant on this line, not a gap the test rewrite could close; the honest value of printing the counters is one source of truth for the loop, not a provable-by-test difference here. The place nudges truly varies with the run — and is covered by a test that can tell it apart from a constant — is the /clear-timeout warn's clearResult.nudges() in runRollover. mvn -Dtest=LeadRolloverTest test: 33/0. mvn clean install: 1681/0, BUILD SUCCESS. Same-shape sweep (found, not fixed, per instructions): Injector.java:383-387 — the readiness-grace warn prints the constant READINESS_GRACE_POLLS where the measured per-target counter t.notReadySincePoll is in scope (single increment site, just reached the threshold at this call site — same equivalent-mutant situation as this fix).	2026-09-12 09:39:39 +07:00
Dai Ha	b17f37a683	fleetd #492 follow-up: detect_supervisor must never read "could not tell" as "none" ... Two situations were silently landing in the "none" answer, which require_drivable_supervisor accepts and the script then falls back to a raw kill + nohup — exactly the wrong move when a supervisor actually IS present: - installed-but-not-loaded, on either supervisor. `systemctl --user is-active` answers "no" for activating/deactivating/failed and while an auto-restart is pending too, and every one of those is a host that IS under systemd (or launchd) and about to act again. `*_installed` already knew this; it was only ever consulted for a warning line, never by the decision itself. - a systemd probe that could not answer at all (e.g. systemctl cannot reach the user bus over a non-lingering ssh session) looked identical to a clean negative, because both probes redirected stderr straight to /dev/null. detect_supervisor now returns a fifth answer, "unclear", for both cases. systemd_loaded/systemd_installed capture systemctl's exit status and stderr separately and set their own *_ERRORED flag only on a real tool failure (non-zero exit WITH stderr), never on a clean negative. "none" now means only: neither supervisor installed, neither loaded, neither probe errored. require_drivable_supervisor die()s on "unclear" exactly like it already does on "ambiguous", naming the specific supervisor and reason via the new SUPERVISOR_UNCLEAR_DETAIL global. Tests: 4 new cases (systemd/launchd installed-but-not-loaded, a real systemd_loaded run through a systemctl stub that errors on stderr, and the die() refusal for "unclear" naming the unit). All 3 new guards were verified by mutation: each was removed from the real script, the suite caught it (a new FAIL line naming the exact broken assertion), then the file was restored byte-identically and the suite went green again.	2026-09-12 09:23:21 +07:00
Dai Ha	c87cc25aa6	fleetd #494 follow-up: print the measured nudge count, and fix the sibling turn-settle timeout line ... - waitForClearPickupAndSettle's grace-release warn now prints the measured 'nudges' counter instead of the constant PICKUP_GRACE_POLLS - 1. The two happen to agree today, but the constant expression was wrong once before (printed PICKUP_GRACE_POLLS itself, claiming 8 nudges where 7 went out) and a code read did not catch it — only a mutation test did. Printing the counter cannot drift from the loop's real behaviour. - waitUntilAtTurnBoundary (the FIRST wait, ~line 386-391) had the identical 'configured value printed as if measured' defect as the three lines fixed in the original #494 commit, but was out of scope because the brief named specific lines instead of the shape. Fixed the same way: it now returns a TurnSettleResult(settled, elapsedMillis) instead of a bare boolean, and the timeout warn prints 'configured={}s elapsed={}ms' instead of presenting cfg.turnSettleSeconds() as the measured wait. - No behaviour change: same sends, same order, same release/refuse decisions. - Test additions: clearGraceReleaseLogIsWarnWithMeasuredElapsed now also asserts the measured nudge count; successLogPrintsMeasuredElapsedForTheWholeRoll's expected elapsed value is updated (7000ms, not 6500ms) to account for waitUntilAtTurnBoundary's own new clock read; a new turnTimeoutLogPrintsMeasuredElapsedNotJustConfigured test pins the sibling line. - Proved the nudges fix with a temporary mutation: set PICKUP_GRACE_POLLS to 5, confirmed via two greps that the mutant applied and the original constant was gone, ran the grace-release test and read the actual log line — nudge count followed to 4 (= 5 - 1), then restored to 8 and reran the full LeadRolloverTest suite as a control (33/33 green).	2026-09-12 09:22:19 +07:00
Dai Ha	3fb331145a	fleetd #494: log measured elapsed time, never the configured budget, on a lead-rollover failure/success ... - runRollover's /clear-timeout warn now prints configured/elapsed/nudges, each labelled, instead of presenting cfg.clearSettleSeconds() as if it were the measured wait. - waitForClearPickupAndSettle's pickup-grace release is now log.warn (was log.info) and prints the measured elapsed time next to the target pane — this is the exact path that reported a false-success roll in the real incident (438ms of a 20s budget). - The success line ('lead-rollover: rolled') now prints the measured elapsed time for the whole roll. - waitForClearPickupAndSettle now returns a ClearSettleResult(settled, elapsedMillis, nudges) instead of a bare boolean, so callers can log the measured values instead of the config. - No behaviour change: same sends, same order, same release/refuse decisions. - Adds 3 tests to LeadRolloverTest pinning the content of each changed log line, using a self-advancing fake clock so the measured elapsed/nudge values are deterministic and provably distinct from the configured budget.	2026-09-12 09:08:04 +07:00
Dai Ha	dcd505286f	fleetd #492: teach redeploy-fleetd.sh systemd --user as a third supervisor ... launchd, systemd --user, and unsupervised are three different answers, not two. Refuse (die) rather than fall through to kill+nohup when a supervisor is detected that this script cannot drive (e.g. both signals fire at once), and add a post-restart check that fails the run if more than one fleetd process is alive. detect_supervisor()/require_drivable_supervisor()/ count_daemon_pids()/assert_single_daemon() are pure, overridable functions so scripts/test-redeploy-fleetd.sh can exercise them without a real launchd or systemd.	2026-09-12 09:00:59 +07:00
Dai Ha	60fa958da2	docs: a relative handoverPath lands in the LEAD's repo, not fleetd's (#491) ... On this host the lead's cwd IS the fleetd checkout, so fleetd/.gitignore protects the handover file and the distinction is invisible. On fleet01 the lead works in /home/ltms/LTMS/kb while fleetd sits in a different directory, and that repo has no .handover rule — measured 2026-09-12. Tell the lead to check its own workspace's .gitignore before writing, and to report it rather than committing the file or editing someone's .gitignore. Refs fleetd #491, #487, #480.	2026-09-12 08:46:17 +07:00
Dai Ha	9950361bc9	docs: #489 is fixed and deployed, but criterion 6 is still unmet ... The skill said the roll 'does nothing until #489 is merged and redeployed'. Both have happened, so that sentence now reads as a green light. It is not one: no roll has bootstrapped a fresh session end to end yet. Say that plainly, and tell the lead to warn the operator before confirming. Refs fleetd #489, #480.	2026-09-12 07:55:41 +07:00
ltms	9f74b6619a	Merge #490: nudge the /clear submit keystroke before bootstrapText (fleetd #489) ... Fixes the live defect measured on 2026-09-12: the roll joined /clear and bootstrapText into one line and Claude Code refused it as "Unknown command: /clearFresh". Verified by the lead before merge: - mvn clean install: Tests run: 1677, Failures: 0, BUILD SUCCESS - LeadRolloverTest baseline: 29 tests, 0 failures - mutation PICKUP_GRACE_POLLS 8 -> 1: 1 failure (the regression test) - mutation deleting the !clearSettled guard: 3 failures, 2 pre-existing tests - mutation replacing waitForClearPickupAndSettle with "return true": 5 failures, including the strengthened pickup test - positive control after each restore: 29 tests, 0 failures - CI run 1738 on f687046: success A separate mutation of the FIRST gate hung the suite instead of failing it. That is fleetd #486, not a regression here; the reproduction is recorded there.	2026-09-12 02:52:52 +02:00
Dai Ha	f687046450	fleetd #489 follow-up: fix stale class javadoc, off-by-one nudge count, weak test ... Three review corrections on top of the previous commit: 1. The class javadoc's four-step continuation list (lines 47-58) was stale. Step 1 said "report an injectable state", but waitUntilAtTurnBoundary's own javadoc excludes BLOCKED - fixed to say IDLE or DONE. Step 3 still described the old plain re-check ("the original, pre-correction wait... still here") - fixed to describe what waitForClearPickupAndSettle actually does: nudge while unpicked-up, then wait for a real WORKING -> IDLE/DONE boundary, releasing rather than wedging if WORKING never shows. 2. PICKUP_GRACE_POLLS=8 bounds the number of consecutive not-yet-picked-up polls, not the number of nudges - the 8th poll releases instead of nudging again, so 8 polls produce 7 nudges. The log.info in the release branch and two javadoc spots said "8 nudges"; fixed all three to state the poll count and the nudge count separately and correctly. Behavior and the constant are unchanged. 3. pickupSeenStopsNudgingAndBootstrapTextIsSent asserted only promptCallCount and sendKeysCallCount, both of which a return-true stub also satisfies. Added an assertion on the already-tracked postClearGetCalls counter (>= 2), which only a real post-/clear poll loop can produce - this is what makes the test fail against a return-true mutant.	2026-09-12 07:45:36 +07:00
Dai Ha	c6058652be	fleetd #489: nudge the /clear submit keystroke before bootstrapText ... LeadRollover.runRollover's second wait (after /clear) was a no-op: it polled for IDLE/DONE, which /clear itself never leaves since it starts no real turn, so it always returned true on the first poll. Combined with a direct agents.send bypassing Injector (deliberate, to avoid wedging the pane), the submit Enter that accompanies /clear could race the paste and leave it unsubmitted — bootstrapText then landed concatenated onto the same input line, exactly as measured live on 2026-09-12. Replace that second wait with waitForClearPickupAndSettle, which copies the pickup-nudge pattern Injector already ships for its own post-turn /clear housekeeping (fleetd #306): nudge agents.submit while the pane hasn't reported WORKING yet, release after PICKUP_GRACE_POLLS=8 nudges rather than wedge, and require a real WORKING -> IDLE/DONE boundary once a pickup is observed. BLOCKED stays excluded from both the nudge and the boundary check, same as the (unchanged) first wait — a paused live turn is not settled, and nudging Enter into an open prompt could wrongly answer it. Adds four tests to LeadRolloverTest covering the paste-race regression (nudge ordered between /clear and bootstrapText), a confirmed pickup, a deadline expiry with no boundary ever reached, and a throwing submit().	2026-09-12 07:29:26 +07:00
Dai Ha	2a95da2ff4	docs: the handover skill must warn that the automatic roll is broken (#489) ... Section 11 said the bootstrap prompt landing was 'not yet proven end-to-end'. It is now measured failing: the first real roll joined /clear and bootstrapText into one line. Nothing was cleared, so the failure is safe, but a lead that reads the old wording would reach for fleet_handover expecting it to work. Refs fleetd #489, #480.	2026-09-12 07:21:38 +07:00
Dai Ha	7f9137fcb6	fleetd #480: ignore the handover file, and note the absolute-path guarantee in the handover skill ... The lead rollover handover file now lives inside the workspace, at the relative path fleetd.yaml's leadRollover.handoverPath names. It is a snapshot of one moment's live state, so it must never enter git history. The handover skill also now says the handoverPath fleetd hands back is always absolute, even when the configured value is relative — a lead that resolves it itself can pick a different file from the one the daemon checks.	2026-09-12 05:46:34 +07:00
Dai Ha	3bf3968bc7	Merge #487: resolve a relative leadRollover.handoverPath against the calling lead's workspace (fleetd #480 follow-up)	2026-09-12 05:43:12 +07:00
Dai Ha	261aa056f9	fleetd #480 follow-up correction 2: guarantee resolveHandoverPath is always absolute ... LeadRollover.resolveHandoverPath's relative branch resolved the configured handoverPath against leadWorkspace.apply(...) (fleet.leaders.<name>.cwd) but never forced the result absolute. If an operator writes a RELATIVE cwd, the returned path stays relative, silently breaking the "always absolute" contract documented on PendingRollover. Fix: call toAbsolutePath() unconditionally on both branches (the already-absolute input branch, where it is a no-op, and the relative branch), so neither branch trusts isAbsolute() alone to already imply what toAbsolutePath() enforces. Method javadoc now states the absolute result is guaranteed, not merely usual. Added a test: a lead with a RELATIVE cwd and a relative handoverPath still yields an absolute PendingRollover.handoverPath. Asserts both isAbsolute() and the exact resolved value, since isAbsolute() alone would also pass for a path resolved against the wrong base. Proved the test discriminates: reverting the toAbsolutePath() calls (keeping the test) made it fail with an AssertionFailedError ("expected: <true> but was: <false>"); restoring the fix made it pass again. Note: FleetConfig has no validation on fleet.leaders.<name>.cwd at config load (grep across every validate* method: 0 matches for .cwd()) — a relative cwd is silently accepted. Not adding validation here per instruction; that is a separate ticket.	2026-09-12 05:41:40 +07:00
Dai Ha	042b8c99dd	fleetd #480 follow-up correction: cover Fleetd.leadRollover(...)'s own wiring behaviourally ... Add FleetdLeadRolloverWorkspaceLookupTest, calling the package-private Fleetd.leadRollover(...) factory directly (with a real ConfigRef built from a temp fleetd.yaml, never the gitignored live one) to prove the terminal -> lead-name -> Leader.cwd() lookup it builds actually works: a relative handoverPath resolves against the calling lead's configured cwd; a terminal absent from the live lead-terminal map falls back to user.dir; and the lookup is read live, not snapshotted at construction time (a lead discovered by the tab scan after leadRollover(...) was built still resolves correctly). Proved this closes the gap: mutating the factory's lambda body (String leadName = null;, always "no lead found", which forces the daemon-cwd fallback this ticket exists to fix) left the full 1669-test suite green before this commit. With the new test added, the same one-line mutation now fails 2 of its 3 cases; reverting it goes green again (3/3). Mutation applied/reverted only during verification and is not part of this commit (git diff on Fleetd.java is empty). FleetdLeadRolloverWiringTest's class javadoc corrected: it previously claimed no behavioural test could catch this wiring dropping out, which was true only before this commit and only covered the factory's own body, not its call site. Restated what each test class actually covers: the source- text pin covers the call site's argument list; the new behavioural test covers the lambda's body.	2026-09-12 05:32:25 +07:00
Dai Ha	4bfab6b718	fleetd #480 follow-up: resolve a relative leadRollover.handoverPath against the calling lead's workspace ... LeadRollover.open() now resolves handoverPath to an absolute path exactly once, against the calling lead's fleet.leaders.<name>.cwd (falling back to the daemon's own user.dir when that lead has none configured), matching the LeadLauncher#launch precedent. PendingRollover stores only the resolved absolute path, so checkHandover's exists/empty/fresh checks, the path handed back to the lead in the fleet_handover open response, and the default bootstrapText sentence all see the same absolute location instead of a value resolved against whatever directory the daemon process happened to start in. FleetConfig.LeadRollover.bootstrapText is no longer defaulted in the compact constructor (it would otherwise still bake in the raw, possibly-relative handoverPath); a new bootstrapTextFor (resolvedHandoverPath) method builds the default sentence from the resolved path instead. Fleetd.leadRollover(...) gains a required liveLeadTerminals parameter to build the terminal to lead-name to Leader.cwd lookup, read live through the existing `leads` supplier and ConfigRef on every call, never off a startup snapshot.	2026-09-12 05:19:49 +07:00
Dai Ha	008a457557	docs: fleet_handover is shipped — update the charter table and the handover skill ... fleetd #480 merged in #483, #484 and #485, so the instruction surface has to catch up. Per CLAUDE.md's own rule, a code change that silently invalidates the canonical block is an incomplete change. CLAUDE.md + wiki/7-Use-Cases.md: one new intent-to-tool row for fleet_handover. Both copies edited identically; the byte-identical sync check prints True. The row carries the trap rather than just the call: open FIRST, then write the file, then confirm — because confirm refuses the file as stale unless its modified time is later than the open request, so the obvious order fails. .claude/skills/handover/SKILL.md: the skill said "do not call a fleet_handover tool: it does not exist." That was true when it was written this morning and is now false, which is the worst state for an instruction file to be in. Replaced with the two real paths (by hand, or with the tool when leadRollover: is configured), plus a new section 11 giving the three-step order and the five things that surprise a caller — chiefly that `accepted` does not mean the pane has been cleared, and that operatorConfirmed is a report of what a human said, not a confidence level. Section 11 also states plainly that the bootstrap prompt landing in a freshly cleared pane is not yet proven end-to-end, and that the recovery is the manual path — which is why the file is written before confirm, never after.	2026-09-11 07:29:59 +07:00
ltms	9494a6b99a	Merge #485: fleetd #480 Unit C — the fleet_handover MCP tool ... fleet_handover{action: "open"|"confirm"|"cancel"} drives LeadRollover, which #483 and #484 landed with nothing calling it. Primary-only via a new Authz.Action.HANDOVER, on the same case line as SPAWN/STOP/DRAIN. The tool has NO terminal, session or leadTerminal parameter of any kind — the pane is always callerTerminal(exchange), resolved from the connection. A lead can therefore only ever roll itself, never another lead. That is charter invariant 3, and it is the second of the two corrections recorded in LeadRollover's class javadoc. Registered unconditionally, so the tool surface does not vary with config: with leadRollover: absent, every action returns a clean NOT_CONFIGURED refusal instead of failing, and open()'s IllegalStateException (config removed by a hot reload after construction) is caught and turned into the same refusal. A config-dependent tool set would have collided with #474's charter tool-surface gate and McpContractDocTest. Correction round applied before merge, and it is the reason this took two passes. The unit first shipped with a defaulted 15-argument FleetMcp constructor delegating to the new 16-argument one with leadRollover = null. I mutated the wiring rather than reasoning about it: deleting just the leadRollover argument from Fleetd.main's FleetMcp call compiled with 0 errors and passed all 1659 tests, BUILD SUCCESS — while the live daemon would have answered NOT_CONFIGURED to every fleet_handover call for ever. Neither FleetMcpHandoverTest (it builds its own FleetMcp) nor FleetdLeadRolloverWiringTest (it pins that LeadRollover is constructed, not that it is passed on) could see it. The worker then found the defect was wider than I had named: all five shorter constructors (11/12/13/14/15-arg) formed one defaulting chain into the 16-arg one, each silently supplying another feature's "off" value — leadChannel, outage, leadSeats, peers, and finally leadRollover. All five are deleted. FleetMcp now has exactly one public constructor, so every one of those features is compile-enforced at its call site, not just this one. Verified by the lead before merge, on PR head merged with current main (0176378): - CI run 1728 green on eb05576. - The identical mutation re-run by me: control against the original -> 1; mutant present (MUT-DROP-ARG2) -> 1; original gone -> 0; `mvn -o -q compile` now FAILS — "constructor FleetMcp ... cannot be applied to given types; reason: actual and formal argument lists differ in length" at Fleetd.java:[698,24]. The antidote holds: required parameter = compile error, defaulted overload = silent survivor a green suite vouches for. - Restored clean (0 changed files), then mvn clean install on the merged tree: BUILD SUCCESS 1, BUILD FAILURE 0, Tests run: 1662, Failures: 0, Errors: 0, Skipped: 0. - Three call sites of `new FleetMcp(` measured, all accounted for: Fleetd.java, FleetMcpAuthzTest.java, FleetMcpHandoverTest.java.	2026-09-11 02:27:56 +02:00
Dai Ha	eb0557621e	fleetd #480 correction round: collapse FleetMcp to one required constructor ... FleetMcp had a defaulted 15-argument constructor that delegated to the new 16-argument one with an implicit null for leadRollover. Dropping the leadRollover argument from Fleetd.main's FleetMcp(...) call fell back to that shorter overload, compiled fine, and left all 1659 tests green — the live daemon would then answer NOT_CONFIGURED to fleet_handover forever with nothing going red. Delete every overload that could reach the 16-arg constructor with a silently-defaulted leadRollover (11/12/13/14/15-arg forms all chained to it), leaving the 16-arg constructor as FleetMcp's sole public constructor. Update FleetMcpAuthzTest's call site to pass every parameter explicitly (leadChannel null, OutageSource.none(), LeadSeatSource.none(), List.of(), leadRollover null) — Fleetd.java and FleetMcpHandoverTest already called the full form. Proved with mvn -o -q compile: removing the leadRollover argument from Fleetd.main now fails to compile instead of silently defaulting. No behaviour changes — NOT_CONFIGURED refusals are unchanged.	2026-09-11 07:25:08 +07:00
ltms	a0eed6f01b	Merge #484: fleetd #480 Unit E — a BLOCKED pane is not a settled pane ... LeadRollover's two settle waits used AgentStatus#injectable(), which is IDLE || BLOCKED || DONE. That is the right rule for Injector ("may I deliver a message without stepping on a live turn") and the wrong one here ("has the turn actually ended"), because BLOCKED is a live turn that is merely paused — a pane sitting on an approval prompt. Path in: the lead calls confirm(); its turn carries on and hits anything needing approval; herdr reports blocked; within 250ms the deferred continuation reads that as settled; /clear is typed into an open prompt. That destroys the lead's live context mid-turn, which is exactly what the turnSettleSeconds gate added in #483 exists to prevent. The window is turnSettleSeconds, default 20s. Both waits now require a real turn boundary — IDLE or DONE. AgentStatus#injectable() is untouched: it is correct for Injector, LeadHeartbeatLoop, LeadCoordLoop, ReplyPushLoop and HerdrPeerLauncher's two readiness checks, all of which are delivery gates. Verified by the lead before merge: - CI run 1726 green on head e2a91e8. - Mutation on the half the worker did NOT mutate: dropped the DONE arm, leaving `if (status == AgentStatus.IDLE)`. Mutant proven applied with two unrelated proofs using different search strings (MUT-DROP-DONE present -> 1; 'IDLE || status' gone -> 0). Same single test, same 100s cap: unmutated passes in 0.172s; mutated is still running at 100s and does not pass. So doneStatusStillCompletesTheFullRoll really does pin the DONE arm, and the fix did not over-tighten to IDLE-only. Why the earlier #483 battery could not have caught this: it proved the guard FIRES, not that the guard's predicate was tight enough. LeadRolloverTest drove the fake status with only "idle" and "working"; neither value discriminates this defect, only "blocked" does. Correction round applied before merge: both warning lines said "never went idle" and "did not become injectable". Retiring that word is the whole point of the change, so a future reader debugging from those lines would have been handed back the wrong mental model. Both now say "did not reach a turn boundary (IDLE or DONE)". Filed separately as #486, deliberately not fixed here: with the DONE arm removed the test hangs rather than fails, because waitUntilAtTurnBoundary is bounded only by an injected clock that the tests hold fixed. Not a production bug — nowMillis is System::currentTimeMillis there — but it turns a future regression into a CI hang instead of a red test.	2026-09-11 02:21:06 +02:00
Dai Ha	e2a91e883e	fleetd #480 Unit E correction: retire "injectable" wording from the log lines ... Both waitUntilAtTurnBoundary guard messages still said "never went idle" / "did not become injectable" — the old mental model the rename was meant to retire. Made both say what the code now actually waits for: a turn boundary (IDLE or DONE).	2026-09-11 07:18:51 +07:00
Dai Ha	62646957ea	fleetd #480 Unit C: wire fleet_handover MCP tool onto LeadRollover ... Adds the fleet_handover tool (open/confirm/cancel) as a thin adapter over LeadRollover, registered unconditionally so the charter tool-surface gate sees a stable set regardless of whether leadRollover: is configured. With a null LeadRollover every action degrades to a clean NOT_CONFIGURED refusal instead of throwing. Gated on a new Authz.Action.HANDOVER (primary-only, same as SPAWN/STOP/DRAIN). The caller's own connection-resolved terminal is the only lead identity ever used — the tool's input schema carries no terminal/session/leadTerminal parameter, so a lead can only ever roll itself. Fleetd.main now passes its existing leadRollover local into FleetMcp via a new trailing constructor parameter.	2026-09-11 07:07:24 +07:00
Dai Ha	802c0ab701	fleetd #480 Unit E: BLOCKED is not a settled turn boundary ... LeadRollover's waitUntilInjectable used AgentStatus#injectable(), which accepts BLOCKED. A BLOCKED pane is paused mid-turn on a prompt, not settled — reusing injectable() let /clear (or the bootstrap text after it) fire into an open approval prompt within the 20s settle window, destroying the lead's live context. Renamed the helper to waitUntilAtTurnBoundary and restricted both waits to IDLE or DONE only, with a comment explaining why this class does not reuse injectable() (it answers "may I deliver", not "has the turn ended"). Added tests for BLOCKED-forever on both waits (zero sends / exactly one send) and for DONE still completing the full roll.	2026-09-11 07:01:28 +07:00
ltms	4bab23e241	Merge #483: fleetd #480 Unit A — lead rollover core (config + executor) ... Two corrections were applied to the original unit before this merge, and the PR description above still describes the pre-correction shape: 1. confirm() no longer rolls inline. It validates every gate, then hands a one-shot continuation to continuationRunner and returns. confirm() is called BY the lead FROM its own turn, so the pane is WORKING and cannot report injectable until confirm() returns; the old code sent /clear first and then timed out waiting, which destroyed the lead's context and started no fresh session. The continuation waits for the calling turn to settle FIRST (turnSettleSeconds, a new knob), and if that wait times out it sends no /clear at all. 2. The pane to roll comes from the caller's terminal, not PrimaryRegistry. A single-slot lookup let lead X's confirm() clear lead Y's pane. open() records the caller's terminal; confirm() refuses with NOT_YOUR_ROLLOVER on a mismatch. Verified by the lead before merge: - CI run 1722 green on head a942622. - Mutation battery on the two safety-critical branches, in a scratch worktree at a942622. Controls measured against the ORIGINAL first; each mutant proven applied with two unrelated proofs using different search strings. M1 `if (!turnSettled)` -> `if (false)`: turnThatNeverSettlesSendsNoClearAtAll FAILS (LeadRolloverTest:247, expected 0 sends but was 1). M2 ownership check -> `if (false)`: aDifferentLeadTerminalCannotConfirmAnotherLeadsRollover FAILS (LeadRolloverTest:266). Unmutated harness-proof run: exit 0 with both guard WARN lines logged, so the branches really are exercised. Nothing calls LeadRollover yet. The fleet_handover MCP tool is Unit C.	2026-09-11 01:51:20 +02:00
Dai Ha	a94262271b	fleetd #480 correction round: defer the roll, and gate it on caller identity ... Two defects found after the fact, both from the original brief, both fixed here. 1. confirm() is called FROM the calling lead's own turn, so its pane is still WORKING and can never report injectable inside that same call. The old confirm() sent /clear before polling for that — the poll always timed out, but only after /clear had already fired and queued, destroying the lead's context with no fresh session ever started and a refusal return that lied about what had happened. Fix: confirm() now only validates and, if every gate passes, hands a one-shot continuation to a new continuationRunner (a real virtual thread in production, Runnable::run in tests) and returns RollDecision.approved() immediately - "scheduled", not "rolled". The continuation itself does the actual work, once the calling turn has ended: wait for the SAME pane to report injectable again (new turnSettleSeconds config key, default 20) - if this never happens, /clear is NEVER sent, at all - then /clear, then wait again (clearSettleSeconds, as before), then bootstrapText. The "no timer/scheduler, only confirm() can roll" invariant is restated precisely in LeadRollover's class javadoc: it is about initiative, not synchronicity - a single-shot continuation of an already-approved confirm() call still satisfies it; a recurring background loop would not. 2. confirm() resolved the pane to clear via PrimaryRegistry.primaryTerminal(), a single-slot lookup that is correct for a background loop with no caller but wrong here: on a daemon with more than one labelled lead tab, lead X's confirm() could clear lead Y's pane, violating the charter's "identity comes from the connection, never an argument" invariant. Fix: open() and confirm() now take the caller's terminal id as a parameter (resolved by the MCP layer from the connection - the later MCP-tool unit must pass it in, never accept it as a request field). confirm() refuses with a new NOT_YOUR_ROLLOVER reason unless it matches the terminal open() recorded. LeadRollover no longer depends on PrimaryRegistry at all. Also: renamed RollResult to RollDecision (rolled -> accepted) to reflect the new meaning - approved and scheduled, not necessarily cleared yet. Added turnSettleSeconds to the leadRollover: config block (documented in fleetd.example.yaml alongside the existing keys) and updated Fleetd.java's leadRollover(...) factory to drop the primaryRegistry parameter, with FleetdLeadRolloverWiringTest's source-text pin updated to match. New tests: turnThatNeverSettlesSendsNoClearAtAll (the branch that matters most - a turn that never ends means /clear is never sent) and aDifferentLeadTerminalCannotConfirmAnotherLeadsRollover (NOT_YOUR_ROLLOVER), plus a settle-after-clear timeout test and an open() input-validation test. LeadRolloverTest: 11 -> 14 tests.	2026-09-11 06:44:58 +07:00
Dai Ha	5c12865c25	fleetd #480 Unit A: lead rollover core (config block + executor) ... Adds the opt-in leadRollover: config block and LeadRollover, the executor a later unit's MCP tool will call. A lead writes a handover file, then open() records a token and confirm() verifies it (exists, non-empty, fresh) and an operator confirmation before clearing the lead's own pane via /clear (sent directly through AgentControl, bypassing Injector, same as ClaudeCodeLauncher#clearContext) and bootstrapping a fresh session. Nothing but an explicit confirm() call can ever roll a pane - no timer, no heartbeat, no background thread anywhere in this class. Wired into Fleetd.java exactly like LeadHeartbeatLoop: constructed only when leadRollover: is present at startup, and nothing calls it yet - the MCP tool is a separate, later unit. Classified leadRollover: as HOT in ConfigRef (joins placement/ memberCredentials/memberLoginShell/models): the executor holds Supplier<FleetConfig.LeadRollover> and reads every field fresh per call, unlike LeadHeartbeatLoop's frozen final fields. The one caveat: the object's construction is still gated on presence in the startup config snapshot, so a freshly-added block needs a restart before anything exists to call. Tests: LeadRolloverTest (14 cases covering the 6 hard requirements - no object without the config block, only confirm() can roll, missing/empty/ stale handover file each refuse by name, requireOperatorConfirm gating, and the injected wall-clock supplier) and FleetdLeadRolloverWiringTest (source- text pin on Fleetd.main's construction call, mirroring FleetdCompletionResolverWiringTest). Also updated the existing FleetConfigValidateAllTest, FleetConfigWithDefaultsPreservesEveryComponentTest, ConfigRefTopLevelCoverageTest and ConfigRefTopLevelReportingCoverageTest to account for the new record component.	2026-09-11 06:33:01 +07:00
Dai Ha	3f8c956325	docs: the handover skill must not promise a tool that does not exist ... The skill shipped in #481 described fleetd #480's automation in the present tense: "fleetd ticket #480 lets a lead session hand off to a fresh one". The tool is not built. A session loading the skill would look for a fleet_handover tool it cannot call, and this repo already knows what a confidently wrong instruction costs — a wrong comment stops the reader investigating with a false conclusion, which is worse than no comment. Now says plainly: today the handoff is manual, #480 will automate the same cycle, and do not call fleet_handover because it does not exist. The nine procedure rules are unchanged — only who performs the swap changes when #480 ships, not what the file must contain. My wording to fix, not the worker's: the brief handed them the present tense.	2026-09-11 06:17:11 +07:00
ltms	2051ceeb26	Merge #481: the handover skill (fleetd #480 Unit B) ... Adds .claude/skills/handover/SKILL.md — the outgoing lead's procedure for writing the file a fresh lead session inherits. Reviewed by the lead against the eight requirements in the brief: every number carries its command, measured-vs-reported is marked, open decisions name their owner, live hazards, what is not owed, a first section of three re-measurement commands, a time-and-commit stamp, and a plain statement that the file goes stale. All eight are present, plus a leave-out section and a template. Verified by the lead, not taken from the worker's report: - CLAUDE.md diff is the addendum's skill list only, in the primary-side group. - The canonical block is byte-identical with the wiki template (sync check True). - CI run 1718 green on 325d0771, the same commit reviewed. Follow-up owed by the lead: the skill describes #480's automation in the present tense, but the tool does not exist yet. The lead will soften that wording so the skill does not promise a fleet_handover tool a session cannot call.	2026-09-11 01:16:40 +02:00
Dai Ha	325d0771a4	fleetd #480 Unit B: add handover skill for lead session handoff ... Adds .claude/skills/handover/SKILL.md, the procedure an outgoing lead follows to write the handover file a fresh lead session inherits when fleetd clears the pane. Registers the new skill in CLAUDE.md's primary-side skills list; no other change to CLAUDE.md.	2026-09-11 06:13:49 +07:00
Dai Ha	7b97aae85b	docs: move the redeploy procedure out of CLAUDE.md into a skill ... CLAUDE.md loads into every session. The daemon-redeploy procedure is needed only when someone redeploys, so it paid for context it did not use: 58 lines, about 918 est. tokens, every session. The procedure now lives in .claude/skills/redeploy-fleetd/SKILL.md, which loads only when invoked. The moved text is byte-identical to what was removed, plus one new paragraph documenting --no-build (scripts/redeploy-fleetd.sh:34,62,266) — the script and the wiki already had that flag, CLAUDE.md never did. CLAUDE.md keeps an 11-line pointer, because two rules must stay resident: a merge is not a deployment, and workers must never redeploy. A session learns it needs the procedure before it needs the skill, then the next line names the skill. Also updates the addendum's primary-side skill list, as this file's own rule for .claude/skills/** changes requires. CLAUDE.md: 34,442 -> 31,591 chars. Canonical block untouched — the wiki sync check still prints True.	2026-09-11 05:48:06 +07:00
Dai Ha	49a404ddf3	Merge #474 follow-up: pin main's ConfigRef wiring against the surviving mutation ... My battery on the #474 merge found one survivor: reverting Fleetd.java:154 from the three-argument ConfigRef constructor to the plain two-argument one turns the live reload gate off and leaves all 1633 tests green. Both new #474 tests build their own ConfigRef with the method reference, so neither reads what main chose. This adds FleetdConfigRefWiringTest, following the three source-text precedents already in the tree (FleetdBackendQuarantineWiringTest, FleetdLeadSeatWiringTest, FleetdCompletionResolverWiringTest) rather than the weaker sibling pattern that builds the wiring itself. No production change. The worker branched fresh off 4466ee0 rather than continuing its old branch off the stranded 435e022 base. That was its own call and it was the right one: one merge base, a clean 80-line diff, and no cherry-pick needed this time. Its vacuity guard is worth keeping in mind for the next source-text test: it asserts the file it read contains 'public final class Fleetd' before asserting anything about the mutation, with a message saying the assertFalse below would pass vacuously on a broken read. An unrelated anchor is the right choice there, because a guard that shares the mutation's text cannot tell a bad read from a real change.	2026-09-10 20:50:13 +07:00
Dai Ha	72d6a6878b	fleetd #474 follow-up: pin main's config wiring against M2 ... Fleetd.main's own choice of the three-argument ConfigRef constructor (with Fleetd::assertChartersNameOnlyRegisteredTools as extraValidation) was unpinned. Reverting Fleetd.java:154 to the plain two-argument constructor compiled with 0 errors and left the whole suite green, because ConfigRefTest and FleetdConfigRefCharterToolSurfaceWiringTest each build their own ConfigRef directly rather than through main. Adds FleetdConfigRefWiringTest, a source-text check on Fleetd.java following the FleetdBackendQuarantineWiringTest/FleetdLeadSeatWiringTest/ FleetdCompletionResolverWiringTest precedent: asserts the exact three-argument construction is present, asserts the plain two-argument form is absent, and guards against a vacuous pass on a broken/empty source read by first asserting an unrelated anchor is present.	2026-09-10 20:48:05 +07:00
Dai Ha	4466ee0ef2	fleetd #474: ConfigRef.reload() runs the charter tool-surface gate too ... A charter naming an MCP tool the server does not register refused Fleetd.main at startup but slipped through ConfigRef.reload(), because reload() only ran FleetConfig.validateAll(), which never looks at what a charter's text names. CharterToolSurface stays in the mcp package (config must not depend on it), so ConfigRef now accepts the check as a Consumer<FleetConfig> extraValidation, run inside reload()'s same try/catch as validateAll(). Fleetd.main wires a new package-private adapter, Fleetd.assertChartersNameOnlyRegisteredTools, into both the startup call site and ConfigRef's constructor, so the two call sites can never check different things. Tests: ConfigRefTest (reload refuses/accepts, via a locally-built equivalent consumer since Fleetd's method is package-private to dev.ltms.fleet) and the new FleetdConfigRefCharterToolSurfaceWiringTest (same proof through the exact Fleetd::assertChartersNameOnlyRegisteredTools reference production uses). Verified deleting the new extraValidation.accept(fresh) call site fails both new "refuses" tests by name. (cherry picked from commit 97e4c1d658) Lead review. Cherry-picked, not merged: the worker branched from 435e022, which is not an ancestor of main (I had reset and rewritten that commit's message while the worker was already on it). Merging its branch would have added a second merge commit for work already on main. Same content, no duplicated history. Rule learned: once a worker is spawned, its base commit is published. My own mutation battery, five cells, each a full `mvn -B clean test` on this commit's own tree: CONTROL 1, unmutated 1633 tests, 0 failures, BUILD SUCCESS M1 delete accept(fresh) KILLED 2 by name M3 3-arg ctor stores no-op KILLED 2 by name M4 set(fresh) before valid KILLED 6 M5 accept outside try KILLED 2 errors M2 main uses the 2-arg ctor SURVIVED M2 is a real gap and it is a test gap, not a defect: the production code here is correct. Reverting Fleetd.java:154 to `new ConfigRef(configPath, cfg)` turns the live reload gate off and leaves all 1633 tests green, because both new tests build their own ConfigRef with the method reference rather than reading what main wires. That is the fourth Fleetd.main call site to survive a battery (#446 M5 and M7, #466 M1, now this). Extracting a check into a well-tested helper moves the untested surface UP, into the line that chooses to call it. The repo already has the answer in three source-text wiring tests (FleetdBackendQuarantineWiringTest, FleetdLeadSeatWiringTest, FleetdCompletionResolverWiringTest); the worker followed the other sibling pattern, which builds the wiring itself and so cannot pin main. Delegated as a follow-up, with the surviving mutation as its acceptance criterion. Also mine to correct: my M3 cell's annotation said the no-op store "must be 2" and measured 1. The 2-arg constructor delegates rather than assigning, so my pattern only ever matched the mutant. The cell still stands on its other proof (requireNonNull left = 0). Third battery in a row with a wrong CONTROL annotation of my own.	2026-09-10 20:40:49 +07:00
Dai Ha	25ba7f16bb	Merge #473: fleet_profiles and fleet_list report which attempt a quarantine is on (fleetd #466 item 2) ... The escalating cooldown landed in 789b6a8, but the only thing an operator could see was quarantinedForSeconds. A long number does not say whether this is the first exhaustion or the fifth, and after escalation those look the same from outside: 3600 seconds could be a big base cooldown or a credential on its fourth strike. Both reports now carry quarantineAttempt beside quarantinedForSeconds. The part that matters is HOW, not that the field exists. BackendQuarantine#status(credentialId) does ONE quarantines.get() and returns both values from the same QuarantineState. It is not two accessors that a caller pairs up. That is the pattern CompositePeerLauncher.modelGateState() already documents: a report that reads a different source from the behaviour it describes will eventually disagree with it, and the disagreement is invisible because both halves look right on their own. This is reporting only. Escalation, the ceiling and the quiet-gap reset are untouched. The flat two-argument constructor still reports a real growing attempt count even though its cooldown stays flat - which is the honest answer, since the streak is real whether or not the cooldown uses it. The worker's report was lost: its fleet_reply never arrived and its inbox was empty. Nothing was lost with it, because the brief required pushing first and putting the report in the PR body. That is the second time that practice has saved a turn. Numbers and my own mutation battery are on the ticket, measured on this merge commit.	2026-09-10 20:21:14 +07:00
Dai Ha	5ba69c9cf2	fleetd #393: correct a comment that claimed two tests pin a call they cannot ... The comment above the charter writer said flipping that call back to putArray was "proven load-bearing" and pointed at two named tests. I mutated exactly that, on the merge commit, and it SURVIVED at 1618 green - so neither named test covers it, and neither can. The reason is structural, not a missing test: that writer runs first against an empty array, so putArray has nothing to replace and the two idioms are equivalent there. No test can distinguish them. The worker measured the same thing independently and said so in their report; the comment was left over from the pre-fix state, where the mutation being described was a DIFFERENT one (a later writer destroying the charter). A comment that names tests which do not cover the line is worse than no comment. The next person mutates the line, sees green, and concludes the tests are broken. The corrected version states what each cell actually measures: this line is unpinnable and why, the later writers ARE pinned and by which test names, and deleting this line entirely fails the charter-reaches-the-member assertion - the hole that predates #393.	2026-09-10 20:17:21 +07:00
Dai Ha	17052bb515	Merge #471: seeded skills reach an opencode member, and instructions[] stops depending on write order (fleetd #393) ... memberSkills: copied skill folders into every provisioned worktree's .claude/skills/ and stopped there. Claude Code reads that directory natively; opencode never does. So the feature was INERT for opencode members rather than broken: the copy succeeded, the files were correct, and nothing ever read them. No test failed because there was nothing to fail - the feature worked at the only layer it implemented. An opencode member's only channel for static guidance is the instructions[] array in its generated config. OpenCodeLauncher now adds each seeded skill's SKILL.md there. A folder with no SKILL.md is never delivered and the log names it. The second half is an ordering hazard fleet01 found by reading, and that I then measured. Three writers append to instructions[]: the role charter, the seeded skills, and the IDE rules. The charter used putArray (CREATE-OR-REPLACE) while the other two used withArray (get-or-create). That was safe only because the charter ran first against an empty array - an undeclared constraint that nothing tested. Measured on the earlier merge: making the skills writer use putArray left 1603 tests green while silently deleting the charter entry, so an opencode member would launch with no role contract at all. Worse than the bug being fixed, and invisible. All three writers now use withArray, and three tests pin the array's CONTENTS (never its size - a size assertion passes when putArray swaps two entries for two others) across the combinations that matter: charter-only, charter+ide, charter+skills+ide. WHY NOTHING CAUGHT IT, MEASURED RATHER THAN ASSUMED. fleet01 first said the missing axis was the COMBINATION of writers, then revised that to a stronger claim: that nothing asserted the charter reaches an opencode member at all. I checked the second claim on this merge and it is FALSE. Deleting the charter writer outright fails 6 tests, and 3 of those existed before #393: writesRemoteMcpConfigAndCharterInstructionsWhenMcpUrlSet, roleCharterWithoutMcpOrCustomProviderStillWritesAConfig, and aPinnedEndpointAndTheFleetMcpCoexistInOneConfig. The charter reaching a member was already pinned. So their FIRST diagnosis was the right one. The surviving mutation did not delete the charter write; it made a LATER writer replace the whole array. Every pre-existing test had exactly one writer active, and with one writer putArray and withArray are indistinguishable. The gap was never "is the charter delivered" - it was "are two writers ever active at once", which is the combination axis. Recording this because the stronger claim is the more quotable one and it would have sent the next reader looking for a hole that is not there. One honest residue: the charter writer's own idiom cannot be pinned. Flipping it back to putArray leaves the suite green, and always will, because it runs first against an empty array where the two idioms are equivalent. The edit removes an undeclared constraint for the next person to add a writer; it is not a change any test can detect. The comment in the source claimed two named tests cover it - that was wrong, and the commit after this one corrects it rather than leaving a false claim beside the code. What this does NOT do: opencode has no equivalent of Claude Code's Skill tool, so the content is static system-prompt text present from spawn, not something a member can invoke by name. This closes the DELIVERY gap and cannot close the ACTIVATION gap. That residue is opencode's design. Numbers and my own mutation battery are on the ticket, measured on this merge commit.	2026-09-10 20:17:21 +07:00
Dai Ha	e95ed99bf7	fleetd #466 scope item 2: report the quarantine repeat count, not only the seconds ... Add BackendQuarantine#status(credentialId) -> Optional<Status>, a single QuarantineState read that answers both remainingSeconds and repeatCount together -- the same "one accessor" pattern CompositePeerLauncher. modelGateState() already uses, so the two facts can never disagree. fleet_profiles/REST GET /profiles and fleet_list's capacity rows (FleetMcp.profilesView/capacityView) now call status() instead of remainingSeconds() and add a "quarantineAttempt" field beside "quarantinedForSeconds": 1 for a first occurrence, 2 for the second in a row, and so on. No change to the escalation, ceiling, or reset logic itself -- this unit is reporting only.	2026-09-10 20:09:13 +07:00
Dai Ha	1477e4358a	Merge #472: one canonical tool-name set, and charters are checked against it (fleetd #469) ... A role charter is free text in config that tells a member which tools to call, and nothing checked that those tools exist. A charter naming bridge_send - a name CB-634 removed - started the daemon cleanly, and the member found out at run time by calling something that was not there. #464 shipped a test for this, but it wrote its own charter into a @TempDir, so nothing anyone put in the real config could fail it. That was a defect in my acceptance criteria, not in that work. Now: FleetTool is one enum of the 11 registered wire names, and every reader goes through it. - FleetMcp's schema builders pass FleetTool.X.wireName() instead of a literal. - FleetMcp's constructor asserts at startup that what it registers with the SDK equals FleetTool.wireNames() exactly, in both directions. - toolAction(String, Map) resolves arbitrary wire input against FleetTool.byWireName() and keeps its run-time throw, which is necessary - network input has no closed compile-time form. It then hands off to authzAction(FleetTool, Map), a switch over the enum with NO default, so a new tool is a compile error at that layer. - CharterToolSurface lives in mcp, not config, and Fleetd.main calls it right after validateAll(). Config must not depend on the MCP server: config loads before the server exists. My brief undercounted the problem and the worker corrected it. I said there were two tool-name inventories plus a test fixture. There were FIVE: the registrations, the authz switch, and three separate source-text scrapes of FleetMcp.java in CharterToolSurfaceTest, FleetMcpAuthzTest and McpContractDocTest - none of which the ticket mentioned. Fixing those three was required, not scope creep: once the literals moved into FleetTool their regexes matched zero names, so one would have failed on its vacuity guard and the other two would have gone quietly vacuous. Inventories after: one. Verified independently on origin/main before accepting the wider diff: three test files did read FleetMcp.java as source text, with a control file at zero to prove the search discriminated. Build number and my own mutation results are on the ticket and the PR, measured on this merge commit rather than on the branch.	2026-09-10 19:59:03 +07:00
Dai Ha	9e4e423ad6	fleetd #393 follow-up: remove the instructions[] writer-ordering hazard ... OpenCodeLauncher.writeConfig has three writers into the instructions[] array (charter, seeded skills, IDE rules). The charter writer used putArray (create-or-REPLACE) instead of withArray (get-or-create), which "worked" only because it happened to run first against a still-empty array — an undeclared ordering dependency nothing tested. Found by the fleet01 lead and verified on this branch's merge: flipping the skills writer to putArray left the full 1603-test suite green while silently deleting the charter entry, which would launch an opencode member with no role contract at all. Fix: charter's putArray -> withArray (one-word change, behavior-identical today). Add three tests asserting instructions[] CONTENT as an exact ordered list (not size) across writer combinations: charter only, charter + IDE rules, and charter + IDE rules + seeded skills. Mutation testing (see PR body) shows the skills and IDE-rules writers are each independently detectable by name; the charter writer's own mutation is not detectable by any test, because it structurally always runs first against an empty array, so putArray and withArray are equivalent there.	2026-09-10 19:58:25 +07:00
Dai Ha	6c2d6e93cb	fleetd #469: one canonical FleetTool set backs registration, authz and charter checks ... FleetConfig.validateCharters() only checked that a charter key is a role wire name and its text is non-blank; #464's CharterToolSurfaceTest compared charter text against the registered tool surface, but wrote its own charter into a @TempDir fixture, so nothing anyone wrote into the live fleetd.yaml could ever fail it. Add FleetTool, an enum in dev.ltms.fleet.mcp holding the one canonical set of registered tool wire names. FleetMcp's tool schemas now derive their names from it, its constructor asserts at startup that what it actually registers with the SDK equals FleetTool.wireNames() exactly, and its authz dispatch (toolAction/authzAction) resolves the wire string against FleetTool before switching on the enum itself with no default -- adding a tool without pinning its Authz.Action is now a compile error, not just a test gap. Add CharterToolSurface (mcp package, not config -- config loads before the MCP server exists) and call it from Fleetd.main right after cfg.validateAll(), so a charter naming a tool the server does not register refuses the daemon's startup, naming both the charter key and the unknown tool. FleetdStartupValidationTest proves this through Fleetd.main itself against a live-shaped config fixture (bridge_send, CB-634's own removed name). CharterToolSurfaceTest, FleetMcpAuthzTest and McpContractDocTest each kept an independent regex scrape of FleetMcp.java's source for the registered side of their own comparison -- three more copies of the same list nothing tied together. All three now read FleetTool.wireNames() instead. Proved canonical by removal: deleting FleetTool.ACK while ackTool() still referenced it broke mvn compile in two places (FleetMcp.java:940,:1898); registering a schema under a literal not backed by FleetTool ("fleet_ack_v2") failed FleetMcp's new startup assertion in every test that constructs it (12 errors, IllegalStateException at FleetMcp.<init>). Both reverted before this commit.	2026-09-10 19:55:02 +07:00