fleetd #612 B3: behavioural replacements for lead-seat, quarantine, lead-rollover guards #628
Reference in New Issue
Block a user
Delete Branch "worker/612-b3-mcpwirings-da2b58-3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Scope
fleetd #612 step 2, unit B3 (issue #612 comment 17513) — replaces three
FleetdAssembly.javasource-text guards with tests that drive the real assembled objects throughFleetdAssembly.assembleAndStart(...) -> FleetdRuntime.mcp().Base branch is
worker/fleetd-612-unita-87807e-1, notmain— matches this unit's brief; do not merge this intomain.Disclosure up front: FleetMcp.java accessors are
public, not package-privateThe brief's precedent (
registeredTools()) is package-private, and said to add the new accessors "the same reason" — package-private if possible, and to disclose loudly if not. I could not keep them package-private: my new assembly tests live in packagedev.ltms.fleet(they must, since they build theResourcePortsthatFleetdAssembly.assembleAndStartneeds, andResourcePorts's methods returnFleetd-nested types only visible from that package), whileFleetMcpis indev.ltms.fleet.mcp. A package-private accessor there is invisible fromdev.ltms.fleet. SoquarantineSource(),leadSeatSource()andleadRollover()onFleetMcparepublic. Flagging this for whichever other B-unit (B1/B2) touchesFleetMcp.javaorFleetdRuntime.javanext — no field was added toFleetdRuntimeitself, per the brief's explicit ban.What each deleted guard pinned, and what pins it now
FleetdLeadSeatWiringTest(fleetd #176) — pinned thatFleetMcp'sLeadSeatSourceconstruction still wiresFleetd.leadSeatLookup(...), by scraping the constructor call's source text.Replaced by
FleetdLeadSeatAssemblyTest: seeds oneFakeHerdrtab labelled to match a configuredfleet.leaders.opus.tab(reusing FakeHerdr's own hardcoded default pane/agent —term_a/w2:p7/w2:t7— no FakeHerdr change needed) and asserts the REAL assembledLeadSeatSource(runtime.mcp().leadSeatSource()) reports the live lead's seat against its own subscription profile: 1, not the 0LeadSeatSource.none()(the inert stand-in) could ever report.FleetdBackendQuarantineWiringTest(fleetd #466) — pinned thatBackendQuarantine.withEscalation(...)'s text was present and the flat two-argument constructor's text was absent.Replaced by
FleetdBackendQuarantineAssemblyTest: quarantines the same credential twice through the REAL assembledBackendQuarantine(runtime.mcp().quarantineSource().quarantine()) at controlled fake-clock offsets, and asserts the second cooldown doubles (200s vs 100s) — the one behavioural difference escalation and the flat constructor actually produce.FleetdLeadRolloverWiringTest(fleetd #480), all three methods:unrelatedAnchorStillPresentwas a scaffold anchor with no independent claim — needs no replacement.mainStillCallsTheLeadRolloverFactorypinned theleadRolloverassignment's call-site text.factoryGatesOnConfigPresencepinned that an absentleadRollover:config yields noLeadRollover.Replaced by
FleetdLeadRolloverAssemblyTest's two tests:assembledLeadRolloverRunsTheRealClearAndBootstrapSequencedrives the REAL assembledLeadRollover(runtime.mcp().leadRollover()) throughopen()/confirm()end to end and asserts/clearthenbootstrapTextwere actually sent through the real herdr router, reachingROLLED.absentLeadRolloverConfigMeansNoRolloverIsBuiltcallsFleetd.leadRollover(...)directly with noleadRollover:block and asserts null. This claim was found uncovered anywhere else —LeadRolloverTest's only related assertion is vacuous (assertNull(null)) and never calls the real factory.Mutation proof — all three call sites, RED then GREEN
Each call site in
FleetdAssembly.javawas mutated to its named inert variant, run against ONLY its new test (RED), reverted,touch'd (the Maven mtime trap:git checkout/mvcan restore an mtime older than the compiled.class, so Maven skips recompiling and silently re-runs the mutant's bytecode), and re-run (GREEN).1. Quarantine —
FleetdAssembly.java:179-180BackendQuarantine.withEscalation(ports.nanoClock(), TimeUnit.SECONDS.toNanos(cfg.quarantineCooldownSeconds()))->new BackendQuarantine(ports.nanoClock(), TimeUnit.SECONDS.toNanos(cfg.quarantineCooldownSeconds()))(the flat two-arg constructor)RED:
GREEN (after revert + touch):
2. Lead seats —
FleetdAssembly.java:479new FleetMcp.LeadSeatSource(Fleetd.leadSeatLookup(() -> config.get().profiles(), leaders, leads))->FleetMcp.LeadSeatSource.none()RED:
GREEN (after revert + touch):
3. Lead rollover —
FleetdAssembly.java:408LeadRollover leadRollover = Fleetd.leadRollover(cfg, router.leadAgents(), config, leads);->LeadRollover leadRollover = null;RED:
(the sibling
absentLeadRolloverConfigMeansNoRolloverIsBuiltcorrectly stayed green here — it callsFleetd.leadRolloverdirectly, not through this mutated call site)GREEN (after revert + touch):
After every revert:
git diff -- fleetd/src/main/java/dev/ltms/fleet/FleetdAssembly.javawas empty.Full build
mvn -o testinfleetd/at the tip of this branch:Down from this branch's baseline (1880/9) by exactly the 3 guards this unit deletes. The 6 remaining failures are
FleetdCompletionResolverWiringTest(4),FleetdConnectionIdentityConstructionTest(1) andFleetdFleetAppConstructionTest(1) — all out of this unit's scope (B1/B2, per issue #612 comment 17513's split).BUILD FAILUREis expected and correct until B1/B2 land.Caveats for review
FleetMcp.java's three new accessors arepublic, not package-private — see disclosure above. Likely collides with whatever B1/B2 also touch inFleetMcp.java.FleetdLeadRolloverAssemblyTest's happy-path test takes ~2.6s real wall-clock time: the productionLeadRolloverconstructor always uses a real virtual thread and real 250ms settle-poll sleeps, and FakeHerdr's agent never reportsWORKING, so the post-/clearwait releases via its 8-poll (~2s) pickup-grace path rather than a real completion boundary. This exercises the full real happy path (bothagent.promptsends, ending inROLLED), just not instantaneously.FleetMcpHandoverTest(indev.ltms.fleet.mcp) drivesFleetMcp.handover(...)with a hand-builtLeadRollover/FakeHerdr, not the real assembly — same general concern this ticket exists to address, but out of this unit's scope.