[cabcookie]

Stacked on #38 (6j6v.9g8j, fix/9g8j-hand-off-one-step-per-ordered-run). Merge #38 first; this PR's base is that branch.

The bug

Measured in the agents workspace on 2026-10-09/10 (0.206.1). Operation v05a's build step was queued behind th4p's working-copy lease for six hours and never started. At its declared window the tick logged step "build" gave no answer inside its declared window; the flow advanced to step "verify" without it, and a verify slot was opened for a build that never ran.

The rule

A step's answer window starts when its session starts. A step whose trigger still waits in the working-copy queue has not been asked, so it cannot lapse.

• supervised_member_threads (the set the supervisor waits for, read by the tick's tick_move and by the push path) clears stale for any member whose thread has a row in working_tree_queue. That covers both cases from the item:
  • a step queued behind another operation's lease;
  • a later step of an ordered run put back in line at the hand-off (v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's Promotions::deferred), which is a row of the same queue.
• ThreadQuorum::stale is not redefined. M2 §4.3 says its derivation "is unchanged and still the only one", so the quorum SQL is untouched, and nxc threads, nxc status and the opener's wake read it as before. Only the supervisor's reading of its own set changes, the same kind of check as the 10yb liveness gate.
• A started step is not in the queue, so a step that started and then fell silent lapses on its declared timeout: exactly as before.

Same root, fixed here

• Lease bound at hand-off. fire_queued_trigger used to restart the member's clock after trigger_role. The inherit inside trigger_role therefore derived the lease bound (operation_lease_expiry, which takes the latest outstanding window) from the window stamped at queue time. Mutation B below shows the result: the lease expired at 01:01, while the hand-off happened at 07:00:30. The restart now runs before the trigger, so the started member's window is the latest in its area. It stays best-effort and never returns early. If the start fails or is queued again, the restarted clock does no harm: a queued member cannot lapse and is restarted again when it really starts.
• Nothing watched the restarted window. The tick armed at fan-out fires at the old instant, finds the member queued and declines, and a past instant is never re-armed. So a member that starts and then falls silent would only have been noticed by chance. After a Spawned admission, fire_queued_trigger now re-arms the channel thread's tick through rearm_after_the_members_moved. This is best-effort, after the trigger.

Tests

New file crates/chat/tests/a_queued_step_is_not_asked_until_it_starts.rs, at the library seam. It follows the conventions of a_hand_off_starts_one_step_per_ordered_run.rs: a recording worker that answers liveness, and the tick through the compute layer. The hand-off goes through the tick's sweep, as in the field: the holder declares no window, so its lease ran out at the two-hour fallback and only its live builder pinned the copy.

1. a_step_queued_behind_the_working_copy_does_not_lapse_and_its_window_starts_when_it_does
   • The coder is queued for six hours. A tick past its window does not advance the flow, reports no lapse, and opens no verifier.
   • The holder lets go and the coder starts. The hand-off arms a job for the channel at start + 1m.
   • A tick 30 s into that window does not advance.
   • A tick past it advances, with one StepUnanswered.
2. a_started_step_that_falls_silent_still_lapses_on_its_window is the guard for the declared timeout: of a started step. It is green with and without the fix.
3. the_lease_handed_on_after_a_long_wait_is_not_already_expired: the lease row expires after the hand-off instant, and working_tree_holder(now) returns the round.

How they were shown red:

• Without any production change, test 1 failed at its first assertion (reason: "advanced", with the field's exact step "coder" gave no answer… finding).
• With the fix, three mutations were applied, then restored:
  • A: the queue check is disabled (if false && members.iter().any(|m| m.stale)). Test 1 goes red.
  • B: the clock restart is moved back after trigger_role. Test 3 goes red: expires at 2026-10-10T01:01:00Z, handed on at 2026-10-10T07:00:30Z.
  • C: the re-arm after the start is disabled (if false && matches!(admission, …)). Test 1 goes red on the armed-job assertion.

#38's tests were adapted. a_hand_off_starts_one_step_per_ordered_run.rs built its "two steps of one run in line together" premise from the 1wep lapse, which this PR removes. It now builds the premise by posting an answer under the queued coder's session before that session ever starts. This settles the step and opens the verifier behind it. All five tests keep their assertions. The coder's start then carries no reply obligation, so the tests take the coder's slot from the queue entry instead of from reply_thread. The prose in that file and in one_step_per_ordered_run's doc now says the lapse route is closed.

Run locally

• cargo fmt
• cargo test -p nexus-chat --test a_queued_step_is_not_asked_until_it_starts --test a_hand_off_starts_one_step_per_ordered_run
• Gates: --test read_surface --test seam_disposition --test verb_seam. No read_surface row changes, because the set of calls that reach trigger_and_bind is unchanged.
• Neighbouring flow, timeout and lease suites (after cargo build -p nxs):
  • channel_member_timeout, channel_tick, channel_flow, channel_supervisor
  • the_flow_waits_for_a_live_session, a_clock_watches_the_liveness_gate
  • a_start_that_failed_is_not_an_orphan, a_step_ends_when_its_session_ends, a_holder_past_its_bound_is_parked, an_unanswered_escalation_parks_and_comes_back
  • withdraw_a_running_round, a_way_out_of_a_held_lease, orchestration_trigger, working_tree_claim_scope
• cargo test -p nexus-chat --lib -- orchestration::tests working_tree::tests and -- guide
• cargo xtask changelog check origin/main

No clippy and no full suite were run locally; CI is the gate.

Recorded, not changed here

• Second verify slot from a late answer (v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's "superseded slot"). That slot came from the verifier's window lapsing while it was queued. A queued step can no longer lapse, so that route is closed. One way to reach two steps in line is left: an answer posted by hand for a step that is still queued, which is how v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's tests now build the shape. v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's hand-off rule still keeps those two steps from running side by side. Whether a step that was settled while still queued should be withdrawn instead of started is a separate question.
• A started step that lapses while its process still runs opens the next step at once. In a working_tree: exclusive channel, that next step inherits the lease and starts beside the hung session. This is the declared timeout: semantics of 10yb/rs9k ("a lapsed slot is skipped by the liveness gate"), and the item asks to keep them. It is listed because it is the other way two steps of one run can share the copy.

Open decisions

1. A failed start pending retry is not treated as queued. Its trigger is off the queue and in failed_starts, so its window can still lapse. A permanently failed start that could never lapse would stall its flow forever, so I kept to "queued or deferred". The clock restart now runs before the trigger, so a failed start gets a fresh window from the attempt instead of keeping the one from queue time. Should a start with a retry due also hold off the lapse?
2. Replicas. The queue is device-local, so a sync peer still sees the queued member's op-folded deadline and could read it as lapsed. This is the same bound the member_deadline.rs module docs already record for the resettable clock.
3. The tick's reason for a queued member is still not_due. A distinct reason, such as waiting_for_the_working_copy, would tell an operator why. That would add a reason the CLI branches on, so I left it out.

No spec under docs/specs/ is contradicted: §4.3's derivation of stale is untouched, and the change is to what the supervisor counts as settled. The guide's channels page (EN/DE) now says that a window starts when the member's session starts.

🤖 Generated with Claude Code

https://claude.ai/code/session_0184D5PqXGRbwMKDkMkRggdZ

[cabcookie]

Review mitigation and new base (head fa5a8a7)

Base merged: origin/fix/9g8j-hand-off-one-step-per-ordered-run at ee75b7f. Conflicts:

• one_step_per_ordered_run's doc: kept 1wep's wording with v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's new signature.
• v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's test file: kept v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's version. Its premise helper now rebuilds the two-steps-in-line shape the way a build before 1wep left it. The coder's queue row is taken out while its window lapses, then put back in its old place, so the coder still owes its answer.

All 12 tests in #38's file and all 7 in this PR's file pass.

Finding	Outcome	Note
Code #1 / Integrity #2: a failed start with retries left can lapse	Fixed	#38's change did not settle this here. The new test was red on the merged base: reason: "advanced". A failed_starts row with retry_at set now counts as waiting; a row with no retry due lapses as before.
Code #2 / Integrity #5: the re-arm finding is discarded	Fixed	fire_queued_trigger takes a noticed sink, and both callers pass their receipt warnings.
Code #3: the re-arm nest	Fixed	The redundant member_deadline pre-check is gone, and a supervising_parent error is reported.
Code #4: the coder starts for an already-settled step	Fixed	#38's tests no longer answer the coder by hand. Filed nxf 6j6v.fzd5 for the hand-settled-while-queued case, and added a note on 55b1.
Code #5: wedge risk undocumented	Fixed	supervised_member_threads docs and the guide name what ends the wait (copy freed, retry, nxc withdraw).
Test #1: a later step put back in line is untested	Fixed	a_later_step_put_back_in_line_does_not_lapse_while_it_waits. Red without the queue check: the tick went for the consolidation (no_return_address).
Test #2: failed or re-queued start untested	Fixed (failed)	Covered by the two failed-start tests. A re-queued start needs a re-parented thread; see Test #3.
Test #3: Spawned-only re-arm checked one way	Declined (in part)	The failed path returns at trigger_role(..)? before the re-arm, so it cannot reach the gate. A Queued admission from the queue needs a thread re-parented between grant and fire, which has no seam at the library handle. A "failed start arms no window" assertion was added, but it cannot tell the Spawned gate from the ?.
Test #4: lease assertion too loose	Fixed	Now expires >= FRESH_WINDOW_ENDS.
Test #5: guard test green both ways	Declined	It is a guard by design. The queued→started→silent path is test 1's tail.
Test #6: names in #38's tests	Fixed	The premise once again lapses the coder at LAPSED, and the coder answers its own owed slot.
Test #7: stale comment in channel_member_timeout.rs	Fixed
Integrity #1: a queued-forever wait is silent	Fixed	New ConsequenceClass::StepStillWaiting on the declining tick's receipt, plus stderr. Test red without it.
Integrity #3: absolute-instant members	Fixed (docs)	The guide says an absolute instant does not move. Changing that in code would contradict the declared meaning: "this moment, whatever happens".
Integrity #4: cross-process gap between queue delete and clock restart	Declined	The gap lies between the hand-off's commit and fire_queued_trigger's first statement, in one process. Closing it means restarting member clocks inside hand_the_working_tree_on's transaction, in #38's store code. The same window already exists for the lease grant (documented on fire_queued_trigger).

Red without the fix, shown by mutation:

• Queue check removed: 5 tests red.
• Retry-due failed starts not counted as waiting: the retry test goes red.
• Every failed start counted as waiting: the no-retry test goes red.
• Finding not attached: the finding test and the deferred-step test go red.
• Re-arm disabled: test 1 goes red.
• Clock restarted after the trigger: the lease test goes red.

Run locally:

• cargo fmt
• this PR's and v0.207 batch: ordered steps one at a time, queued steps not asked, answered escalations release, store-free lanes, next filters and paging, per-type ranking, self-update restarts the service #38's test files
• the gates read_surface, seam_disposition, verb_seam
• the suites failed_consequences, channel_member_timeout, channel_tick, channel_flow, channel_supervisor, the_flow_waits_for_a_live_session, a_clock_watches_the_liveness_gate, a_start_that_failed_is_not_an_orphan, a_step_ends_when_its_session_ends, a_holder_past_its_bound_is_parked, an_unanswered_escalation_parks_and_comes_back, withdraw_a_running_round, a_way_out_of_a_held_lease, orchestration_trigger, working_tree_claim_scope
• the lib tests orchestration::tests, working_tree::tests and guide
• cargo xtask changelog check origin/main

The fragment is now facade: changed, because of the new enum variant (the enum is #[non_exhaustive]).