devx seat action: five pm:blocked cards carry no machine-readable Blocked-by anywhere — backfill or re-grade, they are structurally unreleasable

[os-zhuang]

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).

[claude]

PM seat action — done. All five re-graded pm:blocked → pm:queue, each with its reasoning on the card.

card	disposition
#9758	pm:queue — self-contained parse-checkable finding, nothing upstream
#9757	pm:queue — verified still live: grep -n invokedDirectly scripts/pm/dispatch-gates.mjs returns nothing
#9755	pm:queue — ⚠️ with a fence check named as the dispatcher's first job (see below)
#9754	pm:queue — its only upstream ref is #9747, which is CLOSED
#9748	pm:queue — the presumed blocker was a guess, and is moot regardless

The 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:blocked was 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 text Blocked-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:blocked lifecycle'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-hold with Restart-when: #9465 closes, not pm: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