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.
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.
Dai Ha