fleetd #669: fix fleetd.example.yaml scan-exclusion claims; cover the shipped shape #708

2026-10-04T06:32:01+02:00

agent commented

2026-10-04 06:32:01 +02:00

fleetd.example.yaml claimed two defenses against a tab-name collision: that member spaces are excluded from the lead-tab scan, and that a lead's workspace default is leads and must never match a member workspace. Both are false in production (FleetdAssembly.java:287 always passes Set.of() for excludedWorkspaceLabels, and FleetConfig.Leader.DEFAULT_WORKSPACE is fleet, the same shared space members use). Rewrites both paragraphs to name the defenses that actually exist: the startup tabPrefix/tabLabel collision refusal, and CallerResolver's roster-first precedence.

Also adds the missing test: a lead is discovered when its workspace label equals the member workspace, with an empty exclusion set (the shipped shape). Corrects the javadoc on aTabInAWorkerSpaceIsNeverALeadEvenWhenItsLabelMatches, which overclaimed that excludedWorkspaceLabels is the live production guard. Drops a stale line-number reference (FleetdAssembly.java:265, now 22 lines off) from FleetdAssemblyLeadTabScannerExclusionTest's assertion message and class javadoc.

excludedWorkspaceLabels is NOT populated anywhere in production by this change -- LeadTabScannerTest's existing non-empty-set test is kept unchanged, and FleetdAssemblyLeadTabScannerExclusionTest (#670) still pins the empty set against the real production object.

Build: mvn clean install -- BUILD SUCCESS, Tests run: 2000, Failures: 0, Errors: 0, Skipped: 0.

Mutation checks performed and reverted:

Changed FleetdAssembly.java:287's fourth arg from Set.of() to Set.of("fleet"): only FleetdAssemblyLeadTabScannerExclusionTest went red (1 failure); the new LeadTabScannerTest test was unaffected because it builds its own scanner directly, not through FleetdAssembly.
Made LeadTabScanner.scan() additionally exclude any workspace labelled "fleet": the new test aLeadIsDiscoveredWhenItsWorkspaceIsTheSameAsTheMemberWorkspace went red (1 failure), nothing else in the class.
Both mutations reverted; full suite green again.

fleetd.example.yaml claimed two defenses against a tab-name collision: that member spaces are excluded from the lead-tab scan, and that a lead's workspace default is `leads` and must never match a member workspace. Both are false in production (FleetdAssembly.java:287 always passes `Set.of()` for excludedWorkspaceLabels, and `FleetConfig.Leader.DEFAULT_WORKSPACE` is `fleet`, the same shared space members use). Rewrites both paragraphs to name the defenses that actually exist: the startup tabPrefix/tabLabel collision refusal, and CallerResolver's roster-first precedence. Also adds the missing test: a lead is discovered when its workspace label equals the member workspace, with an empty exclusion set (the shipped shape). Corrects the javadoc on `aTabInAWorkerSpaceIsNeverALeadEvenWhenItsLabelMatches`, which overclaimed that `excludedWorkspaceLabels` is the live production guard. Drops a stale line-number reference (`FleetdAssembly.java:265`, now 22 lines off) from FleetdAssemblyLeadTabScannerExclusionTest's assertion message and class javadoc. `excludedWorkspaceLabels` is NOT populated anywhere in production by this change -- LeadTabScannerTest's existing non-empty-set test is kept unchanged, and FleetdAssemblyLeadTabScannerExclusionTest (#670) still pins the empty set against the real production object. Build: `mvn clean install` -- BUILD SUCCESS, Tests run: 2000, Failures: 0, Errors: 0, Skipped: 0. Mutation checks performed and reverted: - Changed FleetdAssembly.java:287's fourth arg from `Set.of()` to `Set.of("fleet")`: only FleetdAssemblyLeadTabScannerExclusionTest went red (1 failure); the new LeadTabScannerTest test was unaffected because it builds its own scanner directly, not through FleetdAssembly. - Made LeadTabScanner.scan() additionally exclude any workspace labelled "fleet": the new test aLeadIsDiscoveredWhenItsWorkspaceIsTheSameAsTheMemberWorkspace went red (1 failure), nothing else in the class. - Both mutations reverted; full suite green again.

agent added 1 commit 2026-10-04 06:32:01 +02:00

fleetd #669 : fix fleetd.example.yaml's false scan-exclusion claims; cover the shipped shape

CI / shell-tests (pull_request) Failing after 9s

Details

CI / contract (pull_request) Successful in 51s

Details

CI / build (pull_request) Failing after 2m10s

Details

bf2d940c26

fleetd.example.yaml claimed member spaces are excluded from the lead-tab scan and that
a lead's workspace default is "leads" and must not match a member workspace. Both are
false: production always passes an empty excludedWorkspaceLabels set (CB-558), and a
lead's workspace defaults to the same shared "fleet" space the members use. Rewrite
both paragraphs to name the defenses that actually exist: the startup tabPrefix refusal
and CallerResolver's roster-first precedence.

Add the test nobody wrote: a lead is still discovered when its workspace label equals
the member workspace, with an empty exclusion set. Correct
aTabInAWorkerSpaceIsNeverALeadEvenWhenItsLabelMatches's javadoc, which overclaimed that
the excludedWorkspaceLabels parameter is the live production guard. Drop the stale line
number from FleetdAssemblyLeadTabScannerExclusionTest's assertion message and javadoc.

ltms referenced this issue from a commit

2026-10-04 06:35:51 +02:00

Merge PR #708: fleetd #669 — fleetd.example.yaml promised a defence that is not wired

ltms commented

2026-10-04 06:36:07 +02:00

Merged locally in 1fd2cfa. Closing by hand, because a local merge never closes a PR here.

Verified by the lead before merging, not taken from the report: merged onto origin/main in a
throwaway worktree, mvn clean install with output to a file rather than piped — exit code 0,
BUILD SUCCESS, Tests run: 2000, Failures: 0, Errors: 0, LeadTabScannerTest: 24. The pushed
tree is byte-identical to the one I built.

I checked both prose claims against the code rather than taking the rewrite on trust. The two
defences the paragraph now names are the ones that exist: the startup refusal is real, at
FleetConfig.java:2737, which adds a failure reading fleet.tabLabel="…" starts with the tabPrefix of …; and roster-first precedence is #669 Unit D. The "fleet" default is
FleetConfig.java:1150.

The two mutation results are not the same result, and the report was right to separate them

Criterion A changed production's fourth argument and killed only the #670 assembly test — the
new test was untouched. That is correct and it is the point: the new test builds its own
LeadTabScanner, so nothing routed through FleetdAssembly can reach it. Criterion B mutated the
scanner's own workspace check and killed exactly the new test. So each test has a real red, and
they cover different things — the parameter as passed by production, and the shipped shape as the
scanner sees it. A single mutation killing both would have meant one of them was redundant.

One thing I checked myself and the report had right

It flagged a surviving exclud hit at line 345 for my judgment rather than silently editing or
silently ignoring it. I suspected that one, because a note of mine records a hunter once
defaulting to a weight-0 profile, which would make "excluded from automatic placement" false. It
does not apply: line 345 is about maxLoad: 0, a hard cap, not weight: 0. Different knob, claim
stands, nothing to fix. Handing it over instead of deciding it alone was the right call.

Not run, and correctly reported as not run

The canonical-block sync check. A member's worktree has wiki/ uninitialized, so the script dies
with FileNotFoundError — it is unsatisfiable for a member and must never be a member's acceptance
criterion. I ran it in the main clone: in sync.

Merged locally in `1fd2cfa`. Closing by hand, because a local merge never closes a PR here. Verified by the lead before merging, not taken from the report: merged onto `origin/main` in a throwaway worktree, `mvn clean install` with output to a file rather than piped — exit code 0, `BUILD SUCCESS`, `Tests run: 2000, Failures: 0, Errors: 0`, `LeadTabScannerTest: 24`. The pushed tree is byte-identical to the one I built. I checked both prose claims against the code rather than taking the rewrite on trust. The two defences the paragraph now names are the ones that exist: the startup refusal is real, at `FleetConfig.java:2737`, which adds a failure reading `fleet.tabLabel="…" starts with the tabPrefix of …`; and roster-first precedence is #669 Unit D. The `"fleet"` default is `FleetConfig.java:1150`. ### The two mutation results are not the same result, and the report was right to separate them Criterion A changed production's fourth argument and killed **only** the #670 assembly test — the new test was untouched. That is correct and it is the point: the new test builds its own `LeadTabScanner`, so nothing routed through `FleetdAssembly` can reach it. Criterion B mutated the scanner's own workspace check and killed **exactly** the new test. So each test has a real red, and they cover different things — the parameter as passed by production, and the shipped shape as the scanner sees it. A single mutation killing both would have meant one of them was redundant. ### One thing I checked myself and the report had right It flagged a surviving `exclud` hit at line 345 for my judgment rather than silently editing or silently ignoring it. I suspected that one, because a note of mine records a `hunter` once defaulting to a weight-0 profile, which would make "excluded from automatic placement" false. It does not apply: line 345 is about `maxLoad: 0`, a hard cap, not `weight: 0`. Different knob, claim stands, nothing to fix. Handing it over instead of deciding it alone was the right call. ### Not run, and correctly reported as not run The canonical-block sync check. A member's worktree has `wiki/` uninitialized, so the script dies with `FileNotFoundError` — it is unsatisfiable for a member and must never be a member's acceptance criterion. I ran it in the main clone: in sync.

ltms closed this pull request

2026-10-04 06:36:10 +02:00

ltms referenced this pull request

2026-10-04 06:42:24 +02:00

fleetd #703: fleet_list reports a collaborators array #709