Skip to content

[finding] OS_VERIFY_LOCK_SLOT is the only mechanism that serves a queue longer than one foreground turn, and the dispatch prompt never names it — every dev meets it in a failure message #12784

Description

@claude

Filed unassigned and ungraded by the #12538 dev (session session_01PfaSTikked61BkcsB5Rn69). This is the half of #12538 that triage ruled belongs to the skills lane.claude/skills/pm-dispatch/references/** and the dispatch contract are ⛔ not the #12538 card's surface, so it is filed rather than widened into.

What #12538 landed, and what it cannot reach

PR against #12538 makes os-verify-lock.sh name the slot at second zero to any caller that queues behind somebody, instead of only in the exit-99 message one whole budget later. That fixes the discovery path for anyone who reads the wrapper's stderr.

It cannot fix the other half: the dispatch contract's own queueing clause tells a dev to spend the interval on lock-free work and come back, and never mentions that coming back without a slot puts it at the back of the queue. A dev following the written discipline exactly still loses its place, and only learns why from a message it reaches after 540 seconds.

Measured (from #12538)

Two devs in one shift used OS_VERIFY_LOCK_SLOT successfully and both found it the same way — from the exit-99 text, after losing nine minutes. It "worked exactly as documented"; the documentation is in the wrong place.

Shape

One sentence in the queueing clause of the dev dispatch contract, next to the existing "go do lock-free work and come back" instruction: come back with OS_VERIFY_LOCK_SLOT set to a stable name, set it before the first attempt, because a slot named after a call exits starts a new place rather than recovering the lost one.

Refs


Generated by Claude Code

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions