fleetd #612 A-gaps: coordinator path + reportRoleFallbackGaps inside the assembly boundary #624

2026-09-22T06:38:47+02:00

agent commented

2026-09-22 06:38:47 +02:00

Closes the two A-gaps an architect found in PR #620 (fleetd #612), per the lead's ticket comment "Lead decision on the re-sequencing":

Gap 1 — coordinator path never exercised. FleetdAssemblyLifecycleTest left coordinator: unset, so leadMailbox/leadCoordLoop stayed null. Generalised Fleetd.LeadMailboxOpener (and FleetdRuntime's field) from the concrete LeadMailbox to a new LeadChannelHandle (LeadChannel + AutoCloseable) — FleetMcp/LeadCoordLoop already consumed the narrower LeadChannel, so this only widens the owner's seam. FleetdAssemblyCoordinatorLifecycleTest drives FleetdAssembly.assembleAndStart with a real coordinator: block and a fake closeable channel, and proves the assembly builds it and shutdown closes it.

Gap 2 — a call outside the assembly boundary. Fleetd.java:185 called reportRoleFallbackGaps(cfg) (and assertChartersNameOnlyRegisteredTools(cfg)) between cfg.validateAll() and the FleetdAssembly.assembleAndStart(...) call — outside the boundary FleetdAssemblyLifecycleTest drives, so deleting either call compiled clean and left the suite green. Moved both into FleetdAssembly.assembleAndStart, immediately after cfg.validateAll(), in the same relative order, before any I/O. FleetdAssemblyRoleFallbackBoundaryTest pins the moved call behaviourally (captured log output), not source text.

Both new tests were verified red under a targeted mutation and restored (see the hand-off for the pasted output):

Gap 1: (a) commented out leadMailbox.close() in FleetdRuntime.close(), and (b) forced leadMailbox = null in the assembly — each turned the new test red on its own assertion.
Gap 2: deleted Fleetd.reportRoleFallbackGaps(cfg); from FleetdAssembly.assembleAndStart — turned the new test red.

Expected non-green build (per the lead's brief — do not fix): mvn clean install from fleetd/ reports Tests run: 1880, Failures: 9, Errors: 0, Skipped: 0, BUILD FAILURE. All 9 are the known source-text tests that read Fleetd.java and assert on text Unit A (PR #620) moved into FleetdAssembly.java: FleetdCompletionResolverWiringTest (4), FleetdBackendQuarantineWiringTest (1), FleetdLeadRolloverWiringTest (1), FleetdLeadSeatWiringTest (1), FleetdConnectionIdentityConstructionTest (1), FleetdFleetAppConstructionTest (1) — same 9 as the lead's own measurement, no new failures. Not touched, per the brief.

Out of scope, reported not fixed: the five report calls in Fleetd.main before cfg.validateAll() (reportRequiredSecrets, reportGitHostShape, reportMemberTrustModel, reportMemberCredentialsGap, reportExhaustedPatternGap) are already pinned end-to-end by FleetdStartupReportTest (drives Fleetd.main itself). guard.assertPrimaryClean(System.getenv()) in Fleetd.main, however, has the same shape gap 2 did: nothing drives Fleetd.main with a tainted environment to prove this call site itself still runs (only SubscriptionGuardTest tests the method directly). Flagging for the lead to scope — not moved or fixed here.

Base branch is worker/fleetd-612-unita-87807e-1 (PR #620), not main, per the brief.

Closes the two A-gaps an architect found in PR #620 (fleetd #612), per the lead's ticket comment "Lead decision on the re-sequencing": **Gap 1 — coordinator path never exercised.** `FleetdAssemblyLifecycleTest` left `coordinator:` unset, so `leadMailbox`/`leadCoordLoop` stayed null. Generalised `Fleetd.LeadMailboxOpener` (and `FleetdRuntime`'s field) from the concrete `LeadMailbox` to a new `LeadChannelHandle` (`LeadChannel` + `AutoCloseable`) — `FleetMcp`/`LeadCoordLoop` already consumed the narrower `LeadChannel`, so this only widens the owner's seam. `FleetdAssemblyCoordinatorLifecycleTest` drives `FleetdAssembly.assembleAndStart` with a real `coordinator:` block and a fake closeable channel, and proves the assembly builds it and shutdown closes it. **Gap 2 — a call outside the assembly boundary.** `Fleetd.java:185` called `reportRoleFallbackGaps(cfg)` (and `assertChartersNameOnlyRegisteredTools(cfg)`) between `cfg.validateAll()` and the `FleetdAssembly.assembleAndStart(...)` call — outside the boundary `FleetdAssemblyLifecycleTest` drives, so deleting either call compiled clean and left the suite green. Moved both into `FleetdAssembly.assembleAndStart`, immediately after `cfg.validateAll()`, in the same relative order, before any I/O. `FleetdAssemblyRoleFallbackBoundaryTest` pins the moved call behaviourally (captured log output), not source text. Both new tests were verified red under a targeted mutation and restored (see the hand-off for the pasted output): - Gap 1: (a) commented out `leadMailbox.close()` in `FleetdRuntime.close()`, and (b) forced `leadMailbox = null` in the assembly — each turned the new test red on its own assertion. - Gap 2: deleted `Fleetd.reportRoleFallbackGaps(cfg);` from `FleetdAssembly.assembleAndStart` — turned the new test red. **Expected non-green build (per the lead's brief — do not fix):** `mvn clean install` from `fleetd/` reports `Tests run: 1880, Failures: 9, Errors: 0, Skipped: 0`, BUILD FAILURE. All 9 are the known source-text tests that read `Fleetd.java` and assert on text Unit A (PR #620) moved into `FleetdAssembly.java`: `FleetdCompletionResolverWiringTest` (4), `FleetdBackendQuarantineWiringTest` (1), `FleetdLeadRolloverWiringTest` (1), `FleetdLeadSeatWiringTest` (1), `FleetdConnectionIdentityConstructionTest` (1), `FleetdFleetAppConstructionTest` (1) — same 9 as the lead's own measurement, no new failures. Not touched, per the brief. **Out of scope, reported not fixed:** the five report calls in `Fleetd.main` before `cfg.validateAll()` (`reportRequiredSecrets`, `reportGitHostShape`, `reportMemberTrustModel`, `reportMemberCredentialsGap`, `reportExhaustedPatternGap`) are already pinned end-to-end by `FleetdStartupReportTest` (drives `Fleetd.main` itself). `guard.assertPrimaryClean(System.getenv())` in `Fleetd.main`, however, has the same shape gap 2 did: nothing drives `Fleetd.main` with a tainted environment to prove this call site itself still runs (only `SubscriptionGuardTest` tests the method directly). Flagging for the lead to scope — not moved or fixed here. Base branch is `worker/fleetd-612-unita-87807e-1` (PR #620), not `main`, per the brief.

agent added 1 commit 2026-09-22 06:38:47 +02:00

fleetd #612 A-gaps: exercise the coordinator path and pull reportRoleFallbackGaps inside the assembly boundary 526e3b7459

Gap 1: generalise Fleetd.LeadMailboxOpener (and FleetdRuntime's field) from the concrete
LeadMailbox to a new closeable LeadChannelHandle (LeadChannel + AutoCloseable), so a test can
fake the configured-coordinator path without a real broker. FleetdAssemblyCoordinatorLifecycleTest
drives FleetdAssembly.assembleAndStart with a coordinator: block and a fake channel, proving the
assembly builds it and shutdown closes it.

Gap 2: move reportRoleFallbackGaps(cfg) and assertChartersNameOnlyRegisteredTools(cfg) out of
Fleetd.main and into FleetdAssembly.assembleAndStart, immediately after cfg.validateAll(), so
both run inside the tested assembly boundary before any I/O. FleetdAssemblyRoleFallbackBoundaryTest
pins the moved call site behaviourally (captured log output), not by reading source text.

Both new tests were verified red under a targeted mutation (a non-closing/null coordinator for
gap 1; deleting the moved call for gap 2) and restored.

ltms merged commit 608e4496be into worker/fleetd-612-unita-87807e-1

2026-09-22 06:41:42 +02:00

ltms referenced this pull request

2026-09-22 06:44:11 +02:00

Fleetd.main's injected wirings are unpinned: 16 call sites go inert with a fully green suite #612

ltms referenced this pull request

2026-09-22 06:50:12 +02:00

Fleetd.main's injected wirings are unpinned: 16 call sites go inert with a fully green suite #612

ltms referenced this pull request

2026-09-22 07:48:28 +02:00

Fleetd.main's injected wirings are unpinned: 16 call sites go inert with a fully green suite #612

Sign in to join this conversation.