Maintainer order, verbatim (given in the triage seat's Claude Code session, 2026-10-05): 「21719 这种明显是问题的也不处理吗」. This card carries #21719's fix after that card was closed on a queue-eligibility rule. ⛔ Not a claim.
Filed by the triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U.
Why a new card, and why documentation
The problem (measured on #21719 by the domain:skills seat)
- Devs ran
pnpm check:pm-dispatch-gates, a 1,976-case self-test battery, through scripts/pm/os-verify-lock.sh. It held the shared lock for 1,216–1,246 s per run, five times in one shift.
- Sibling devs' locked runs queued out at 360 s and 540 s (exit 99), and they then ran their scanners unlocked.
- The lock's own doctrine (
os-verify-lock.sh about :140–:185) keeps check:* gates out of the lock. docs/audits/2026-08-verify-lock-gate-routing-measurement.md measured every routing policy as worse. The battery should never have held the lock. The instruction is what is ambiguous: the battery is a test suite named as a check:* gate.
Change
.claude/agents/os-dev.md 〈资源纪律〉 item 1 gets one line. It names pnpm check:pm-dispatch-gates as a check:* gate that runs detached and unlocked (nohup … & and tail the log), per dispatch-gates.mjs's header, even though it is a test battery.
references/platform-readings.md (about :432) corrects 「430–450 秒」 to the measured 1,216–1,246 s.
- Both files are line-ratcheted at headroom 0 (402/402 and 469/469), so each line is paid in place by tightening a neighbouring line. ⛔ No ratchet raise.
- ⛔ No change to
os-verify-lock.sh, and ⛔ no change to dispatch-gates.mjs (frozen under ruling 208).
Acceptance
- The next shift's PM-tool dev reports record no locked
check:pm-dispatch-gates hold.
check:skill-line-ratchet stays green.
documentation · priority:p2 (it costs about 20 minutes of serialised lock time per PM-tool card) · domain:skills · area:devpath.
Generated by Claude Code
Maintainer order, verbatim (given in the triage seat's Claude Code session, 2026-10-05): 「21719 这种明显是问题的也不处理吗」. This card carries #21719's fix after that card was closed on a queue-eligibility rule. ⛔ Not a claim.
Filed by the triage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U.Why a new card, and why
documentationpnpm check:pm-dispatch-gatesholds the shared verify lock about 20 minutes per run, so sibling devs' locked scanner runs queue out at 540 s — the lock's own holder-side starvation warning fired on every run this shift #21719 was closednot_planned(5986264140) undertriage-duties.mdline 34: atoolingcard enterspm:queueonly withUnblocks: #Nor a named published surface.os-dev.md〈资源纪律〉 item 1 says 「每次 build/test 都从这里走」, whiledispatch-gates.mjs's header (about:34–:46) says to run its--self-testbattery detached, and names no lock.triage-duties.mdline 35 queues exactly this: 说明书与实现脱节 → 修文档.The problem (measured on #21719 by the
domain:skillsseat)pnpm check:pm-dispatch-gates, a 1,976-case self-test battery, throughscripts/pm/os-verify-lock.sh. It held the shared lock for 1,216–1,246 s per run, five times in one shift.os-verify-lock.shabout:140–:185) keepscheck:*gates out of the lock.docs/audits/2026-08-verify-lock-gate-routing-measurement.mdmeasured every routing policy as worse. The battery should never have held the lock. The instruction is what is ambiguous: the battery is a test suite named as acheck:*gate.Change
.claude/agents/os-dev.md〈资源纪律〉 item 1 gets one line. It namespnpm check:pm-dispatch-gatesas acheck:*gate that runs detached and unlocked (nohup … &and tail the log), perdispatch-gates.mjs's header, even though it is a test battery.references/platform-readings.md(about:432) corrects 「430–450 秒」 to the measured 1,216–1,246 s.os-verify-lock.sh, and ⛔ no change todispatch-gates.mjs(frozen under ruling 208).Acceptance
check:pm-dispatch-gateshold.check:skill-line-ratchetstays green.documentation·priority:p2(it costs about 20 minutes of serialised lock time per PM-tool card) ·domain:skills·area:devpath.Generated by Claude Code