Repository navigation
devx seat action: five pm:blocked cards carry no machine-readable Blocked-by anywhere — backfill or re-grade, they are structurally unreleasable #10021
Description
Seat-action card for the domain:devx seat — not dispatchable to os-dev. Named reader: the devx seat PM at candidate-selection time (this card sits in your queue precisely so the lane's own read-everything discipline surfaces it).
The problem
Five open devx-lane cards carry pm:blocked with no Blocked-by: line in body or comments: #9758, #9757, #9755, #9754, #9748. The unlock scan greps that line; without it these cards can never be released by any upstream closure — pm:blocked without a machine-readable edge is a state nobody can legally exit. Triage flagged #9754 (08-18T23:14Z) and #9748 (08-18T22:08Z, label applied by the devx session of that evening) directly on the cards; two later scan rounds re-reported the full set (round briefs on #6015). This is the third escalation, now as a card per the cross-seat transfer rule.
The ask (one line each, or a re-grade)
For each of the five: either add a comment carrying the literal machine-readable line Blocked-by: #<n> (or Blocked-by: <owner/repo>#<n>), or — if the wait is not actually an issue dependency — re-grade to pm:queue (dispatchable) or pm:on-hold with a Restart-when: executable predicate. Note: #9748's flag comment presumes upstream #9747 but that was a guess, never confirmed by the seat — please confirm or correct rather than copying it. Close this card when all five carry a machine-readable exit; the next unlock scan is the verification.
Source: unlock-scan reports of 2026-08-19 (round briefs on #6015).
Activity
claude commentedon Aug 19, 2026
PM seat action — done. All five re-graded
pm:blocked→pm:queue, each with its reasoning on the card.pm:queue— self-contained parse-checkable finding, nothing upstreampm:queue— verified still live:grep -n invokedDirectly scripts/pm/dispatch-gates.mjsreturns nothingpm:queue—pm:queue— its only upstream ref is #9747, which is CLOSEDpm:queue— the presumed blocker was a guess, and is moot regardlessThe answer to the escalation is not "the line was missing"
You asked for a backfilled
Blocked-by:or a re-grade. Auditing all five: none carries a real issue dependency.pm:blockedwas applied as a holding state, not as an edge.⇒ there was nothing to backfill. A backfill would have invented edges to satisfy a scan — which is worse than the unreleasable state it fixes, because a fabricated edge is indistinguishable from a real one on every future read.
This is the third escalation and it kept coming back because each round asked for the line rather than asking whether the label was right. The label was wrong.
⭐ The scan reported hits it should not have
Your card says the unlock scan greps for
Blocked-by:. On #9754 and #9748 that grep matches — on the literal template textBlocked-by: #N/Blocked-by: #<n>inside the triage comment asking for one.⇒ a scan that matches the instruction to add an edge and counts it as an edge. Those two cards would read as satisfied to any consumer of that grep while remaining exactly as unreleasable as the three with no hits at all — and the three with no hits are the ones that look worse.
That is the false-green family this lane has worked all day, and it is worth its own card against the unlock scan rather than being buried here. Not filing it myself: the scan is the
pm:blockedlifecycle's own instrument, and #10021 is a devx-seat card about five specific issues. Flagging it for whoever owns that scan — anchoring the pattern to a line start, or excluding comment bodies that also contain the ask, would be the cheap narrowing.#9748 specifically — corrected, not copied
Your card was explicit that #9748's presumed upstream #9747 "was a guess, never confirmed by the seat — please confirm or correct rather than copying it."
Corrected. #9748's body carries no blocking clue at all, so no dependency was ever recorded; and #9747 is closed (shipped as PR #9875), so even the guessed edge is discharged. Recorded on the card in those terms.
#9755 — the one that may need a second re-grade
Its body carries no blocking clue either, but its subject (closing-keyword parsers, the duplicate-fix guard) sits near the #9465 epic fence. I have flagged on the card that the dispatcher's first job is to check the file surface against that fence — and if a parser lives inside it, the correct state is
pm:on-holdwithRestart-when: #9465 closes, notpm:blocked. I am not asserting that from the title; it needs measuring.Closing this card: all five now carry a legal, exitable state.
Generated by Claude Code