fleetd #621: make the context-roll notice obey requireOperatorConfirm #622

2026-09-22T06:27:40+02:00

agent commented

2026-09-22 06:27:40 +02:00

Closes #621.

LeadHeartbeatLoop.contextNotice(...) built its closing sentences unconditionally: "ask the operator" and "Only the operator can approve the roll", with no config reaching it. LeadRollover.confirm(...) already honours leadRollover.requireOperatorConfirm (LeadRollover.java:480), so setting the knob to false stopped the daemon refusing the roll but did nothing about the instruction the lead actually receives — a lead that follows its own text still asks the operator.

This change threads the effective requireOperatorConfirm value through:

contextNotice gains a 4-arg overload (enabled, reading, alreadyNotified, requireOperatorConfirm). The existing 2-arg and 3-arg overloads delegate to it with requireOperatorConfirm=true, so every existing caller (including every pre-#621 test) keeps byte-identical text.
LeadHeartbeatLoop gains a 14-arg constructor carrying the flag; the existing 13-arg constructor delegates with true.
Fleetd.java computes the effective value (cfg.leadRollover() == null || cfg.leadRollover().requireOperatorConfirm()) and passes it at construction.
When false, the notice now tells the lead to confirm on its own judgement and names the actual gate: the handover file must exist, be modified after the open() request, and not be older than maxDocAgeSeconds.

LeadRollover.confirm's own enforcement is untouched — this PR is the message only, per the ticket's stated scope.

Tests

Two new tests in LeadHeartbeatLoopTest: contextNoticeKeepsAskingTheOperatorWhenRequireOperatorConfirmIsTrue and contextNoticeDropsTheOperatorAskWhenRequireOperatorConfirmIsFalse, asserting on the returned string (not source text).
Verified the false-case test is a real instrument: temporarily reverted the branch to hardcode the old text, re-ran only that test, and confirmed it failed red (expected: <false> but was: <true>), then restored the fix.
mvn clean install from fleetd/: Tests run: 1879, Failures: 0, Errors: 0 — BUILD SUCCESS. Baseline on main was 1877; this PR adds 2 tests.

Not in this PR

wiki/11-Features.md — wiki/ is an uninitialized submodule in my worktree. The wiki entry text is in my handoff to the lead, who will paste it in.

Closes #621. `LeadHeartbeatLoop.contextNotice(...)` built its closing sentences unconditionally: "ask the operator" and "Only the operator can approve the roll", with no config reaching it. `LeadRollover.confirm(...)` already honours `leadRollover.requireOperatorConfirm` (LeadRollover.java:480), so setting the knob to `false` stopped the daemon refusing the roll but did nothing about the instruction the lead actually receives — a lead that follows its own text still asks the operator. This change threads the effective `requireOperatorConfirm` value through: - `contextNotice` gains a 4-arg overload `(enabled, reading, alreadyNotified, requireOperatorConfirm)`. The existing 2-arg and 3-arg overloads delegate to it with `requireOperatorConfirm=true`, so every existing caller (including every pre-#621 test) keeps byte-identical text. - `LeadHeartbeatLoop` gains a 14-arg constructor carrying the flag; the existing 13-arg constructor delegates with `true`. - `Fleetd.java` computes the effective value (`cfg.leadRollover() == null || cfg.leadRollover().requireOperatorConfirm()`) and passes it at construction. - When `false`, the notice now tells the lead to confirm on its own judgement and names the actual gate: the handover file must exist, be modified after the `open()` request, and not be older than `maxDocAgeSeconds`. `LeadRollover.confirm`'s own enforcement is untouched — this PR is the message only, per the ticket's stated scope. ## Tests - Two new tests in `LeadHeartbeatLoopTest`: `contextNoticeKeepsAskingTheOperatorWhenRequireOperatorConfirmIsTrue` and `contextNoticeDropsTheOperatorAskWhenRequireOperatorConfirmIsFalse`, asserting on the returned string (not source text). - Verified the false-case test is a real instrument: temporarily reverted the branch to hardcode the old text, re-ran only that test, and confirmed it failed red (`expected: <false> but was: <true>`), then restored the fix. - `mvn clean install` from `fleetd/`: `Tests run: 1879, Failures: 0, Errors: 0` — `BUILD SUCCESS`. Baseline on `main` was 1877; this PR adds 2 tests. ## Not in this PR `wiki/11-Features.md` — `wiki/` is an uninitialized submodule in my worktree. The wiki entry text is in my handoff to the lead, who will paste it in.

agent added 1 commit 2026-09-22 06:27:40 +02:00

fleetd #621 : make the context-roll notice obey requireOperatorConfirm

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

Details

CI / contract (pull_request) Successful in 1m0s

Details

CI / build (pull_request) Failing after 1m53s

Details

cbe872b538

contextNotice hardcoded 'ask the operator' and 'Only the operator can
approve the roll', so setting leadRollover.requireOperatorConfirm to
false stopped the daemon refusing the roll but never stopped the lead
being told to ask. Thread the effective config value into
contextNotice: when true the text stays byte-identical, when false it
tells the lead to confirm on its own judgement against the three
handover-file checks instead.

LeadRollover.confirm's own enforcement is untouched — this is the
message only.

ltms merged commit 63eec8a0da into main

2026-09-22 06:31:02 +02:00

ltms referenced this issue from a commit

2026-09-22 07:43:31 +02:00

fleetd #612: merge main into Unit A, carrying #621's requireOperatorConfirm into the assembly

ltms referenced this pull request

2026-09-22 07:45:26 +02:00

The assembly's requireOperatorConfirm wiring is unpinned: dropping it silently reverts fleetd #621 with a fully green suite #630

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.