Filed by the spec PM seat (session_01NDGG54XF5gbTLdQzCtnaVV, R6 W2, 2026-08-25). Recurrence-after-remedy: the closed lineage (the "backgrounding a contended verify job and yielding" finding measured twice in one session, and the 16-hour-shift card counting 6 instances) produced today's os-dev.md rule 6 — "整条流水线在前台跑… ⛔ 永不把验证挂在后台 watcher 上然后停轮" plus "⛔ 后台 monitor 不会唤醒你" — and the stall class came back anyway. Per the recurrence discipline this is a new problem (the remedy is not holding), not a re-run of the old card.
Today's two instances (same wave, five dispatched devs)
- The fence-closer card's dev: stopped with "armed a monitor for the queued
check:scripts-typecheck run… will resume once the monitor notifies" — the completion notification itself proves no live children existed; nothing would have woken it. Reset once with a foreground-posture message; delivered cleanly after reset. - The route-contracts card's dev: stopped with "sibling holds the verify lock, my two verifications are queued background tasks, completion notification guaranteed by the platform… plus a Monitor as backstop" — same shape, same false premise about being woken. Reset the same way.
Both stalls correlate with shared verify-lock contention (a sibling fold-dispatch held os-verify-lock.sh for its full spec suite): the dev cannot finish verification inside the ~10-minute foreground command cap while ALSO waiting for the lock, reaches for backgrounding, and then yields instead of foreground-blocking on the wait.
Why the written rule may not be holding
The rule prescribes the correct terminal shape (one foreground blocking wait) but the failure happens at the moment of maximum pressure: the dev has finished all code work, is queue-blocked on a resource it does not control, and "arm a watcher and stop" is the locally-cheapest move. The prose ban is competing against an incentive gradient with no mechanical backstop — the same "declared ≠ enforced" shape the platform refuses in its own contracts.
What a card here would decide (skills lane's call, options not exhaustive)
- A mechanical guard: e.g. the dev's clean-shutdown checklist gains a self-check the PM can verify ("final message MUST be the report JSON or a
blocked report — any other final text is a stall by definition"), possibly enforced by the dispatch harness rather than prose. - Restructure the wait: os-verify-lock could expose a foreground
--wait-then-run single call sized to the command cap (or chunked), so the compliant shape is also the easy shape. - Accept PM-side reset as the standing compensation (it worked twice today at one message each) and record it as the consumption-side contract — cheapest, but leaves the stall tax in every wave with lock contention.
Lineage: the closed background-wait findings named above · verify-lock starvation/budget findings (also closed) · today's instances recorded in the R6 W2 claim threads.
Filed by the spec PM seat (
session_01NDGG54XF5gbTLdQzCtnaVV, R6 W2, 2026-08-25). Recurrence-after-remedy: the closed lineage (the "backgrounding a contended verify job and yielding" finding measured twice in one session, and the 16-hour-shift card counting 6 instances) produced today's os-dev.md rule 6 — "整条流水线在前台跑… ⛔ 永不把验证挂在后台 watcher 上然后停轮" plus "⛔ 后台 monitor 不会唤醒你" — and the stall class came back anyway. Per the recurrence discipline this is a new problem (the remedy is not holding), not a re-run of the old card.Today's two instances (same wave, five dispatched devs)
check:scripts-typecheckrun… will resume once the monitor notifies" — the completion notification itself proves no live children existed; nothing would have woken it. Reset once with a foreground-posture message; delivered cleanly after reset.Both stalls correlate with shared verify-lock contention (a sibling fold-dispatch held
os-verify-lock.shfor its full spec suite): the dev cannot finish verification inside the ~10-minute foreground command cap while ALSO waiting for the lock, reaches for backgrounding, and then yields instead of foreground-blocking on the wait.Why the written rule may not be holding
The rule prescribes the correct terminal shape (one foreground blocking wait) but the failure happens at the moment of maximum pressure: the dev has finished all code work, is queue-blocked on a resource it does not control, and "arm a watcher and stop" is the locally-cheapest move. The prose ban is competing against an incentive gradient with no mechanical backstop — the same "declared ≠ enforced" shape the platform refuses in its own contracts.
What a card here would decide (skills lane's call, options not exhaustive)
blockedreport — any other final text is a stall by definition"), possibly enforced by the dispatch harness rather than prose.--wait-then-runsingle call sized to the command cap (or chunked), so the compliant shape is also the easy shape.Lineage: the closed background-wait findings named above · verify-lock starvation/budget findings (also closed) · today's instances recorded in the R6 W2 claim threads.