Filed from the 2026-08-07 unlock sweep (maintainer-approved). Unassigned.
The gap, with today's evidence
Batch selection (step 3) orders by priority:p0 → target:<major> board → ordinary queue. Nothing in that order can see that a card is blocking other cards, because the blocking relation lives in the dependents' bodies (Blocked-by: #N), never on the upstream. In the queue view a chain head is indistinguishable from an isolated p3.
Measured today:
#5702 is the proof: dispatchable since 2026-08-06T06:47Z, unswept for ~2 days, with three cards queued behind it. #6428 is the sharper one: it carries no priority signal while blocking #5491 + #5492 — the two halves of the v17 security batch the maintainer ruled today, which must land together.
Proposed clause (step 3, batch selection)
Selection priority: priority:p0 jump-the-queue > upstream cards with unlock fan-out ≥ 2 > target:<major> board items > ordinary queue items.
Fan-out is computed, not declared: build a reverse index of Blocked-by: #N lines across open pm:blocked issues — the same read the unlock sweep already performs, so the cost is zero. Fan-out ordering is ordering only, never an exemption: same-file serialization, the claim protocol and batch independence all still apply.
Why not a new label
A priority:* bump or a new pm:blocking label would need a producer, and every unread label rots (a label exists iff something reads it). Fan-out is derivable from data the protocol already maintains, so deriving it at selection time keeps one source of truth and cannot drift. It also carries the right incentive by construction: work that unblocks other work goes first, and throughput compounds.
Acceptance
Related: today's unlock sweep (8 unblocked, 3 stale ~2 days) recorded on #6015; #6410 is the sibling SKILL card from the same day (compiler-face checklist).
Filed from the 2026-08-07 unlock sweep (maintainer-approved). Unassigned.
The gap, with today's evidence
Batch selection (step 3) orders by
priority:p0→target:<major>board → ordinary queue. Nothing in that order can see that a card is blocking other cards, because the blocking relation lives in the dependents' bodies (Blocked-by: #N), never on the upstream. In the queue view a chain head is indistinguishable from an isolated p3.Measured today:
#5702 is the proof: dispatchable since 2026-08-06T06:47Z, unswept for ~2 days, with three cards queued behind it. #6428 is the sharper one: it carries no priority signal while blocking #5491 + #5492 — the two halves of the v17 security batch the maintainer ruled today, which must land together.
Proposed clause (step 3, batch selection)
Why not a new label
A
priority:*bump or a newpm:blockinglabel would need a producer, and every unread label rots (a label exists iff something reads it). Fan-out is derivable from data the protocol already maintains, so deriving it at selection time keeps one source of truth and cannot drift. It also carries the right incentive by construction: work that unblocks other work goes first, and throughput compounds.Acceptance
$regex响亮拒收 +$icontains各后端实现(#4706 裁决 B 案 · 驱动半边) #5702 / ISharingService 写判定补三态(放行/不表态/拒绝)—— #5492 裁决 B 案的 step1,二态 canEdit 已实测产出 fail-open #6428 above) so the next reader sees the failure mode, not just the rule.Related: today's unlock sweep (8 unblocked, 3 stale ~2 days) recorded on #6015; #6410 is the sibling SKILL card from the same day (compiler-face checklist).