[finding] `Blocked-by:` can only name an issue, but the two conditions cards actually wait on are "a PR merges" and "a release lands and the pin covers it" — measured on both

[os-zhuang]

Finding — recording only, not claimed. Filed under the maintainer direct-dispatch channel, this session, verbatim: 「然后 把 1–4 落成 finding 卡」. PM session session_0124Qg8rLvpXnQDwCmpKUmaJ.

The Blocked-by: #N contract expresses exactly one condition: issue N closes. Two conditions that occur routinely cannot be written in it, so they get written in prose — where no sweep can see them — or written as an issue reference that fires at the wrong moment.

Case A — blocked on a PR merging

objectui#5493. No Blocked-by: in either channel; the block lives only in the prose tail of a triage comment:

Serial note: coordinate with the in-flight #5328 pin-bump branch — this card's gate reading only goes red once the 17.1.0 lockfile lands, so it dispatches after that PR merges.

The card also carries pm:blocked while that same comment's verdict line reads Triage: → pm:queue, Bug — label and comment disagree, which is a second symptom of having nowhere legitimate to put the condition.

There is a near-miss in the protocol already: Unlock-action: re-check PR #M exists, but it is scoped to the other situation — work finished, PR stuck behind a broken external gate. It does not cover "I am waiting on someone else's PR before I start".

Case B — blocked on a release, not on a merge

The sharper one, because here the machine predicate fires and is wrong.

objectui#5601 → Blocked-by: objectstack-ai/objectstack#10054. Measured 2026-08-23:

check	reading
target closed?	yes — 2026-08-21T17:37:56Z, PR #10910 merged
in a released spec?	no — zero hits for #10054 in packages/spec/CHANGELOG.md on origin/main; changeset still pending, unversioned
consumer's pin	objectui pnpm-lock.yaml resolves @objectstack/spec@17.1.0, the newest released version

Any unlock scan reading the declared contract would have returned this card to pm:queue, where a dev would have picked it up and found the retirement absent from the package it consumes. It was held back this round only because the release state was checked by hand.

The same class, satisfied rather than violated, on four sibling cards: objectui#4676/#4664 (blockers released in spec 17.1.0) and #5233/#5210 (same). All four were genuinely unblocked — but "the blocker closed" was not what made them so; "the change shipped in 17.1.0 and the lockfile resolves 17.1.0" was. The predicate and the truth agreed by luck of timing.

And the gap can be long: a merge sits unreleased for as long as no version is cut. #10054 is two days in and counting.

Why this is one finding and not two

Both cases are the same defect — the vocabulary has one noun (an issue) for a relation that has several kinds. Cards do not stop having the condition; they route it into prose, and prose is invisible to the candidate query, the unlock sweep and the ageing alarm alike, which is the failure mode the two-channel Blocked-by: rule was introduced to end.

Shape of the fix — options, not a recommendation

1. Admit a PR form — Blocked-by: <owner/repo>!<n> or similar — resolved the same way, fired on merge. Smallest vocabulary change; the resolver already speaks to the API.
2. Admit a release form for the cross-repo case — e.g. Blocked-until: <pkg>@<range> pinned — and let the sweep read the consumer's lockfile. Strictly more work, and it is the one that would have caught fix(cli): 把本地存储根写成设置服务读的那个 env 名 —— OS_STORAGE_ROOT → OS_STORAGE_LOCAL_ROOT(方案 B) #5601.
3. Neither; make the existing line carry it — require that a card in either situation names an issue that does close at the right moment (a pin-bump chore card for case B, which the protocol already tells seats to file). Zero mechanism change, more discipline, and discipline is what the whole half-state patrol exists because we do not have.

Option 3 has a live precedent from this round: objectui#5601 now carries a second, comment-channel Blocked-by: naming objectui#5716 — the card that actually gates the pin advancing — so both targets resolve and the block correctly holds.

⛔ Which option, and whether case B is worth mechanising at all before the pin-bump flow stabilises, is a design call for the maintainer — not decided here.

[os-zhuang]

Triage: routed domain:skills — PM-protocol machinery (Blocked-by: vocabulary reach); skills-lane findings are self-triaged by that seat. Sibling cards from the same measurement session: #11219, #11218, #11217.

---

Generated by Claude Code

[os-zhuang]

首触定级(skills 席,session session_01RMTpSRF5CjMmQBFfPtPCwJ,2026-08-23 集中定级轮):转 needs-user-decision —— 卡自陈「⛔ Which option … is a design call for the maintainer」,词表是协议公开面,超出席位裁量。

一句话问题:卡片等的其实是「某个 PR 合了」或「某个版本发了且下游已换上」,但我们的阻塞词表只会写「某张 issue 关了」——于是等待条件被写进散文,机器看不见,该派的不派、不该派的派了。

选项 × 真实代价:

• A. 词表加 PR 形式(Blocked-by: <owner/repo>!<pr>)——做什么:解锁扫描学会认 PR 合并。真实代价:三处读者(解锁扫描/老化告警/巡查)各要多养一个分支,词表每扩一次是永久义务。业务上 = 给调度系统加一种新单据类型。
• B. 再加 release/pin 形式——做什么:扫描读消费仓 lockfile。真实代价:最重,发布节奏不稳时(pin-bump 流程还在演进)这个谓词会反复误判;是 objectui#5601 那类事故的直接解法,但为一类事故养一台机器。业务上 = 给调度系统教会读供应链交货单。
• C. 不扩词表,精确化规则:等 PR/等发版的卡必须指向一张「在正确时刻关闭」的 issue(pin-bump 杂事卡——协议本就要求立);已有活先例(objectui#5601 → objectui#5716 后正确持住)。真实代价:纪律成本,写错的人还会写错;但巡查 H4/H19 已能抓「没有机器行的 blocked 卡」。业务上 = 不加新单据,要求把每笔等待都换开成已有单据。

四棱:

① 项目长远合理性:C 缩特例(一个名词一个谓词),A/B 扩词表——每个新形式是三处读者的永久增生;
② 实际业务拉动:今天真实撞上的是 objectui#5601 一例(B 类)与 5493 一例(A 类),量级 = 每周个位数,C 的活先例已证明够用;
③ 防 AI 犯错:C 下写错 = 巡查响亮点名(无机器行即红);B 下谓词误判 = 静默错派,错得更贵;
④ 创业阶段不扩散:词表是契约,不为个位数场景扩容;C 零机制变更。
推荐:C,回退 A(若 C 落地后同类散文阻塞仍反复出现,加 PR 形式一种、⛔ 不加 release 形式)。
本分析看不见的:pin-bump 杂事卡流程自身的稳定性(若它常缺位,C 的前提弱化)。
裁决格式:回一个字母即可;「C,但 X」= 自动按 A 准备。

裁后执行(你不用管):C ⇒ 协议句精确化一行进 SKILL.md/runbook(治理面 PR),巡查已有谓词不动;A ⇒ 另立实现卡进队列。

---

Generated by Claude Code

[os-zhuang]

<!-- os-decision-facets --> — marker addendum: the raw HTML-comment form was stripped by the body sanitizer from the facets block above (read-back verified); this backtick-quoted line is the surviving machine-greppable spelling. One garbled metavariable in the block, corrected spelling: option A's form is Blocked-by: OWNER/REPO!PR-NUMBER (angle brackets were eaten). The facets block itself is intact.

---

Generated by Claude Code

[claude]

Maintainer ruling recorded (atomic four-part write)

Ruled 2026-08-23, live PM chat, verbatim: 「10950 不考虑存量，其他接受你的建议」 — this card falls under the accepted recommendations. Ruled: C — do not extend the Blocked-by: vocabulary. A card waiting on a PR merge or a release must point at an issue that closes at the right moment (the pin-bump chore card the protocol already requires; live precedent objectui#5601→#5716). Fallback A (PR form only) stays pre-authorized if prose-blocking recurs after C lands — never the release form. needs-user-decision → pm:queue in the same stroke (domain:skills): per the card's own post-ruling step, one protocol-sentence precision edit into SKILL.md/runbook (governed-face PR, draft + human merge).

---

Generated by Claude Code