Filed by the triage seat (claude-opus-5) at the maintainer's request, from 20 cards judged under the new threshold plus 6 cards I damaged applying its retroactive clause. ⛔ Unassigned; grading is the skills seat's (SKILL.md:380 — skills-lane cards are self-triaged there, and the whole-repo round skips them).
All anchors re-read on origin/main f48f3f1b at 2026-09-07T09:0xZ, ⛔ not from a snapshot.
⚠️ This card proposes changes to the rules that govern the seat filing it, from a sample that seat chose. Every item below is anchored to a specific card number so the reader can check the judgement rather than take it. See "Conflict of interest" at the end.
Evidence base
|
count |
| Cards judged under the threshold (two rounds, objectui) |
20 |
| of which filed / closed |
13 / 6 |
Cards damaged by me applying SKILL.md:779 retroactively |
6 |
| Damage caught by a read-before-write guard |
1 (objectui#7734, 4 h after it merged) |
⛔ The 20 are not a random sample — I picked them for shape variety. See "What I have no evidence for".
1 · Read current state before every write — ⭐ highest value, and it is not a criterion
Where: the 发现分诊轮 block, SKILL.md:374-380.
Evidence — 6 cards damaged, one identical cause. Applying :779 ("三类外已立的卡关 not planned") I acted on a 24-hour-old list snapshot. All six had been closed completed by merged PRs in the interim; one carried an assignee:
| card |
already closed by |
damage |
| objectui#7876 |
merged PR objectui#8098 |
completed → not_planned, labels replaced |
| objectui#7778 |
merged PR objectui#8040 |
same |
| objectui#7733 |
merged PR objectui#8224 |
same, os-sam's assignee wiped |
| objectui#7724 |
merged PR objectui#8036 |
same |
| objectui#7721 |
merged PR objectui#8100 |
same |
| objectui#7984 |
merged PR objectui#8134 |
same |
All six restored, each with a retraction comment naming its PR.
⭐ The guard then proved itself: objectui#7734 was on my announced close list; a fresh read showed it had merged 4 hours earlier (PR objectui#8230, same assignee os-sam). Not touched.
A technical fact nobody would guess, and the reason the damage was worse than a wrong state:
issue_write replaces the label set when labels is passed, and clears fields that are not passed — that is how an assignee disappeared.
Proposed text (3 lines):
⛔ 写入前对每张卡现读当前状态;任何列表快照读数一律作废。
⛔ 带 pm:dispatched / assignee / 任何 open 或 merged PR 引用的卡,一律不动。
⛔ issue_write 会替换标签集并清空未传字段:写入时必须回传 assignees。
⚠️ Honest limit: no hook can intercept an MCP call, so this can only be prose. Its reliability equals the reliability of the seat reading it. ⛔ Do not record it as a guarantee.
2 · The acceptance-notes fallback needs a named carrier — measured 6 of 6 empty
Where: SKILL.md:355 ("其余进 PR ## 验收备注,⛔ 不立卡") · :779 · os-dev.md:45.
This is the hardest datum in the card. For every card I closed I looked for the PR that would carry the noted item:
| closed card |
carrier |
| objectui#8208 (test costs +7 s) |
⛔ none — that specifier's sweep is complete; objectui#6892 is pm:blocked on an un-triaged card |
objectui#8190 (authUrl required but dead) |
⛔ none — the burn-down batch may not touch packages/auth/src/** |
objectui#8246 (@default nothing reads) |
⛔ none — same batch, same exclusion |
| objectui#8241 (bundle budget headroom) |
⛔ none fixed |
| objectui#8270 (stale warning text) |
⛔ none — batch may not touch plugin-map/src/** |
| objectui#8162 (stale gate header) |
⛔ none — the card itself ruled out the only candidate (governed, stops in draft) |
⇒ Not "mostly empty" — 6 for 6. The rule's escape hatch did not exist in a single measured case.
⭐ The pattern is structural, not accidental: burn-down batches are scoped to docs and explicitly excluded from src/**, .changeset/*.md is consumed rather than edited, and a completed sweep never revisits its files.
Proposed text (4 lines):
判「进验收备注」前先问:哪一个 PR 会碰到这个文件?
说得出具体 PR 或人 ⇒ 写进去。
⛔ 说不出(.changeset/*、无人在改的文档页、生成物、已扫完的批次)⇒ 兜底不成立。
仍然关,但关闭理由必须写明「承接者:无」。
⭐ Side effect already observed: this clause forces the seat to check the name instead of copying it. On objectui#8208 I first read the card's Refs objectui#6892 as "someone will do this"; checking showed both reasons it is false. ⇒ "the card mentions a follow-up plan" ≠ "a vehicle exists that will execute it".
3 · Write down three criterion boundaries — ⛔ not that they cannot be judged, but that they are not reproducible
I decided all three myself and wrote each into the card it arose on. ⛔ But unwritten, the next seat re-decides and may decide differently.
| gap |
criterion text today |
cards |
what I decided |
| Carrier of the key |
(c) says 「AI 写元数据」 |
objectui#8190 (closed) · objectui#8253 (filed) |
the line is "is this stored and re-authored by someone other than its writer?" — React props are not, a stored view config is |
| A third failure mode |
(c) says 「拒收或静默丢弃」 |
objectui#8270 (closed) |
the warning steers an author to metadata that is honoured and makes things worse. Judged out-of-class as written; ⚠️ recorded, ⛔ not escalated |
| Docs as a carrier |
(a) says 「可复现缺陷」 with no surface restriction |
objectui#8161 · objectui#8160 (filed) vs objectui#7724 · objectui#7984 (closed) |
the line is "incomplete vs wrong", ⛔ not "docs vs code". A doc whose example fails when copied is class (a); a doc that omits members is not |
Proposed text (3 lines, one per boundary) — placed with the three classes in SKILL.md:354-355, os-dev.md:42-43, core-rules.md:89.
4 · One irreversibility gate
Evidence: 1 case in 20+ — objectui#7721, a false sentence in a pending changeset. Consumed verbatim into the published CHANGELOG at release, and CHANGELOG is never rewritten. ⇒ ⛔ no PR will ever open that file, so item 2's fallback is empty and the window closes permanently.
⚠️ On the card I recorded that I closed it "with the least confidence in the batch" and that the fallback had no carrier — and closed it anyway, because no gate existed for that shape. That is the failure this item fixes.
Proposed text (1 line), before SKILL.md:378:
三类外但不可逆或有硬时限的(发版即固化、被消费而非编辑的文件、
窗口关闭后无法补做)⇒ 不关,报维护者。
⇒ Frequency ≈ 5 %. ⛔ This is deliberately narrow: it triggers on the thing's window, ⛔ never on the seat's uncertainty. An earlier draft of mine triggered on uncertainty and would have escalated 57 % of a batch — the maintainer rejected it, correctly.
5 · Replace the acceptance metric with one that can fail
Where: #16351's own Acceptance — 「new finding cards per day at or below half of the 09-05/09-06 rate」.
⚠️ That number cannot fail in an informative way. It falls if (i) devs judge well, or (ii) genuine class-(c) items are recorded as noted and never filed, or (iii) nobody reads the acceptance notes. All three look identical.
⇒ This is the failure class the corpus names repeatedly: a reading that cannot fail is indistinguishable from one that passed.
Proposed acceptance (1 line):
落地一周后随机抽 20 条 `noted, not filed`,由席位逐条重判,量出误记率并记档。
⛔ What should NOT change
- The three-class frame. In 17 of 20 cards it gave a clear answer unaided. ⛔ Three boundary gaps are not a reason to rebuild it.
SKILL.md:378's 「三类外关 not planned(不等批准)」. I proposed replacing it with "escalate when unsure"; the maintainer refused. The refusal was right — my version put 57 % of a batch in their inbox.- 「定级即离标」(
:116, :374), the native type field (:361-363), the English audit line (:368). I missed all three in my first round. The rules already say them ⇒ ⛔ that was a reading failure, not a rule failure.
What I have no evidence for
The admission rate. Round 1 was 5 filed / 4 closed; round 2 was 8 / 2. That reads like the threshold is not reducing inflow — ⛔ but my sample is not random: I picked for shape variety, which biases toward substantive cards.
⇒ A real estimate needs 20 randomly drawn bare findings judged the same way. ⛔ I do not have that number and this card does not claim one.
Conflict of interest, stated
The seat proposing these edits is the seat they constrain, and it chose the sample. Mitigation: every item names the cards it rests on (objectui#7721 · #7724 · #7733 · #7734 · #7778 · #7876 · #7984 · #8160 · #8161 · #8162 · #8190 · #8208 · #8241 · #8246 · #8253 · #8270), and items 1 and 2 are the two whose evidence is counting, ⛔ not judgement — those two stand even if every one of my classifications is wrong.
Serial note
SKILL.md is held by #15379 (pm:dispatched, the provenance-stripping pass) and claimed by #16516 (pm:queue, the queue-entry third case). ⚠️ Items 1-4 fold into the same sections both touch ⇒ sequence behind them, with a merge-tree proof against both heads (the shape #16003 used against PR #15946). #16490 touches dispatch-runbook.md only — no collision.
⚠️ Line budget: #16351 landed line-neutral on all four pinned files (SKILL.md 811 · os-dev.md 403 · core-rules.md 150 · AGENTS.md 1058 — all four re-measured on f48f3f1b and unchanged). Items 1-4 add ≈ 11 lines. ⇒ Offsetting folds are the implementing seat's call, ⛔ not specified here.
Dedup
search_issues over the threshold / acceptance-notes / triage-rule vocabulary returned 228 results — a live instrument, ⛔ not a silent zero. Read: #16351 (the threshold itself, closed — this is its follow-up, ⛔ not a duplicate) · #16490 (runbook wording confusable with the threshold — adjacent, different file) · #16516 (queue-entry rule needs a red-by-design case — ⭐ adjacent to my objectui#8128 reading, but a different rule) · #15379 (holds SKILL.md) · #16003 / #16004 / #15404 / #15412 / #15671 (closed, other topics). ⚠️ Bounded: one semantic query, ⛔ not an exhaustive sweep.
Filed by the triage seat (
claude-opus-5) at the maintainer's request, from 20 cards judged under the new threshold plus 6 cards I damaged applying its retroactive clause. ⛔ Unassigned; grading is the skills seat's (SKILL.md:380— skills-lane cards are self-triaged there, and the whole-repo round skips them).All anchors re-read on
origin/mainf48f3f1bat 2026-09-07T09:0xZ, ⛔ not from a snapshot.Evidence base
SKILL.md:779retroactively⛔ The 20 are not a random sample — I picked them for shape variety. See "What I have no evidence for".
1 · Read current state before every write — ⭐ highest value, and it is not a criterion
Where: the 发现分诊轮 block,
SKILL.md:374-380.Evidence — 6 cards damaged, one identical cause. Applying
:779("三类外已立的卡关 not planned") I acted on a 24-hour-old list snapshot. All six had been closedcompletedby merged PRs in the interim; one carried an assignee:completed→not_planned, labels replacedos-sam's assignee wipedAll six restored, each with a retraction comment naming its PR.
⭐ The guard then proved itself: objectui#7734 was on my announced close list; a fresh read showed it had merged 4 hours earlier (PR objectui#8230, same assignee
os-sam). Not touched.A technical fact nobody would guess, and the reason the damage was worse than a wrong state:
Proposed text (3 lines):
2 · The acceptance-notes fallback needs a named carrier — measured 6 of 6 empty
Where:
SKILL.md:355("其余进 PR## 验收备注,⛔ 不立卡") ·:779·os-dev.md:45.This is the hardest datum in the card. For every card I closed I looked for the PR that would carry the noted item:
pm:blockedon an un-triaged cardauthUrlrequired but dead)packages/auth/src/**@defaultnothing reads)plugin-map/src/**⇒ Not "mostly empty" — 6 for 6. The rule's escape hatch did not exist in a single measured case.
⭐ The pattern is structural, not accidental: burn-down batches are scoped to docs and explicitly excluded from
src/**,.changeset/*.mdis consumed rather than edited, and a completed sweep never revisits its files.Proposed text (4 lines):
⭐ Side effect already observed: this clause forces the seat to check the name instead of copying it. On objectui#8208 I first read the card's
Refs objectui#6892as "someone will do this"; checking showed both reasons it is false. ⇒ "the card mentions a follow-up plan" ≠ "a vehicle exists that will execute it".3 · Write down three criterion boundaries — ⛔ not that they cannot be judged, but that they are not reproducible
I decided all three myself and wrote each into the card it arose on. ⛔ But unwritten, the next seat re-decides and may decide differently.
Proposed text (3 lines, one per boundary) — placed with the three classes in
SKILL.md:354-355,os-dev.md:42-43,core-rules.md:89.4 · One irreversibility gate
Evidence: 1 case in 20+ — objectui#7721, a false sentence in a pending changeset. Consumed verbatim into the published CHANGELOG at release, and CHANGELOG is never rewritten. ⇒ ⛔ no PR will ever open that file, so item 2's fallback is empty and the window closes permanently.
Proposed text (1 line), before
SKILL.md:378:⇒ Frequency ≈ 5 %. ⛔ This is deliberately narrow: it triggers on the thing's window, ⛔ never on the seat's uncertainty. An earlier draft of mine triggered on uncertainty and would have escalated 57 % of a batch — the maintainer rejected it, correctly.
5 · Replace the acceptance metric with one that can fail
Where: #16351's own Acceptance — 「new
findingcards per day at or below half of the 09-05/09-06 rate」.notedand never filed, or (iii) nobody reads the acceptance notes. All three look identical.⇒ This is the failure class the corpus names repeatedly: a reading that cannot fail is indistinguishable from one that passed.
Proposed acceptance (1 line):
⛔ What should NOT change
SKILL.md:378's 「三类外关 not planned(不等批准)」. I proposed replacing it with "escalate when unsure"; the maintainer refused. The refusal was right — my version put 57 % of a batch in their inbox.:116,:374), the nativetypefield (:361-363), the English audit line (:368). I missed all three in my first round. The rules already say them ⇒ ⛔ that was a reading failure, not a rule failure.What I have no evidence for
The admission rate. Round 1 was 5 filed / 4 closed; round 2 was 8 / 2. That reads like the threshold is not reducing inflow — ⛔ but my sample is not random: I picked for shape variety, which biases toward substantive cards.
⇒ A real estimate needs 20 randomly drawn bare findings judged the same way. ⛔ I do not have that number and this card does not claim one.
Conflict of interest, stated
The seat proposing these edits is the seat they constrain, and it chose the sample. Mitigation: every item names the cards it rests on (objectui#7721 · #7724 · #7733 · #7734 · #7778 · #7876 · #7984 · #8160 · #8161 · #8162 · #8190 · #8208 · #8241 · #8246 · #8253 · #8270), and items 1 and 2 are the two whose evidence is counting, ⛔ not judgement — those two stand even if every one of my classifications is wrong.
Serial note
SKILL.mdis held by #15379 (pm:dispatched, the provenance-stripping pass) and claimed by #16516 (pm:queue, the queue-entry third case).dispatch-runbook.mdonly — no collision.SKILL.md811 ·os-dev.md403 ·core-rules.md150 ·AGENTS.md1058 — all four re-measured onf48f3f1band unchanged). Items 1-4 add ≈ 11 lines. ⇒ Offsetting folds are the implementing seat's call, ⛔ not specified here.Dedup
search_issuesover the threshold / acceptance-notes / triage-rule vocabulary returned 228 results — a live instrument, ⛔ not a silent zero. Read: #16351 (the threshold itself, closed — this is its follow-up, ⛔ not a duplicate) · #16490 (runbook wording confusable with the threshold — adjacent, different file) · #16516 (queue-entry rule needs a red-by-design case — ⭐ adjacent to my objectui#8128 reading, but a different rule) · #15379 (holdsSKILL.md) · #16003 / #16004 / #15404 / #15412 / #15671 (closed, other topics).