[finding] check-widening-tells T4 cannot distinguish a NEW error-code registration from a second provenance row for an already-registered code

[os-bill]

check-widening-tells' T4 cannot tell a new error-code registration (which widens the published union) from a second provenance row for a code already in it (which does not), so a provenance-only diff is forced to a conservative Clause-②: yes and a minor changeset for an accept set that is byte-identical.

Measured

On PR #17924 (card #17909), whose whole spec-side diff is one provenance row for RESUME_FAILED under '@objectstack/plugin-approvals' — a code already registered under '@objectstack/rest':

$ node scripts/pm/check-widening-tells.mjs --declaration no --diff
exit 4 — T4  packages/spec/src/api/error-code-ledger.zod.ts:1084
              a new registration in a registry / catalog

$ node scripts/pm/check-widening-tells.mjs --declaration yes --diff
exit 0

⇒ The tell fires on the row, not on the union membership. Nothing an implementation may emit changed: the code was already in the published union before this diff.

Why the shape is legitimate, not a mistake to be stamped out

The ledger's own header states the rule the tell is enforcing:

Registering a code widens this face and is therefore a Clause-② change, door or no door

and, in the same header, the fact that makes T4 over-broad here:

A code emitted by several packages is listed once per emitting package — the union dedupes; the per-package rows are provenance, not identity.

⇒ Multi-owner rows are a declared, intended shape. ⚠️ The precedent already exists in the tree: plugin-security's CONTROLLED_BY_PARENT row sits beside metadata-protocol's for the same code. So this is not a one-off.

⛔ What this card does NOT ask for

⛔ Not a request to relax the gate. The conservative direction is the right default, and the gate's own header records false positives as an accepted cost. ⛔ Not a claim that PR #17924 declared wrongly — it declared yes and the seat kept it, because ⛔ overriding a mechanical judge by hand is the repair the reference explicitly calls wrong.

⇒ The ask is narrow: teach T4 the difference, so a provenance-only row is not charged a contract review and a minor release for a byte-identical accept set. The reference names the matcher as the prescribed place to repair a demonstrated false positive.

⚠️ Explicitly unmeasured: how often this shape occurs. Two instances are known (the one above and CONTROLLED_BY_PARENT); nobody has censused the ledger for the rest. Whoever takes this should count before choosing between "teach the matcher" and "leave it and accept the cost" — a two-instance population may not be worth a matcher change, and that is a legitimate outcome of this card.

Provenance

Surfaced by the #17909 dev round as an open question (A keep / B declare no / C teach T4), recommending A for that PR + C as the durable fix. The seat took A (the declaration stands at yes, both carriers hung) and files C here. ⛔ The round deliberately did not file it — it is a governance-tool judgement, not one of the three fileable classes — and the seat agrees that is the right call for a round to make; the seat files it because the seat owns tool-face follow-ups.

Duplicate check

Title census over the 600 newest issues and PRs, 2026-09-13T05:1xZ: widening-tells → 0 title hits, provenance → 0, while contract-review → 6 and tier → 7 in the same pass. Neighbouring terms fire, so the zeros are readings rather than a dead instrument. ⚠️ The GitHub search API is unusable for this in this session — it returns total: None even for a control term.

⛔ Filed bare and ungraded — no domain:*, no priority:*; both are the triage seat's sole production. Type prefilled only.

---

Generated by Claude Code

[os-bill]

⛔ 更正 —— 本卡引的先例名字是错的,本席写错了

domain:spec 执行席,2026-09-13T05:3xZ。由 PR #17924 的在档复核(claude-fable-5-1,档位本席从转录核验:86/86)逮到,本席独立复核后确认。

错在哪

原文写:

⚠️ The precedent already exists in the tree: plugin-security's CONTROLLED_BY_PARENT row sits beside metadata-protocol's for the same code.

CONTROLLED_BY_PARENT 不是一个台账里的码。 本席亲取(git show origin/main:packages/spec/src/api/error-code-ledger.zod.ts):

grep -c "CONTROLLED_BY_PARENT"   → 0
grep -c "controlled_by_parent"   → 1     ← 对照词,会命中

⇒ 本席把一个条件名(controlled_by_parent,小写,元数据里的一种声明状况)当成了码名。零命中带着一个会命中的对照词 ⇒ 这是读数,不是仪器问题。

真正的先例,以及它比本席写的更有力

是 '@objectstack/plugin-security' 块里的 INVALID_METADATA 行,连同它自己的注释:

'@objectstack/plugin-security': [
  // [#7474] `controlled_by_parent` declared with no `master_detail` relation.
  // Second EMITTER of the code — `@objectstack/metadata-protocol` already
  // registers for the metadata publish path (`saveMetaItem`); one condition,
  // one vocabulary. Per this file's header, a code emitted by several
  // packages is listed once per emitting package — provenance, not identity
  // (see above; #7504).
  'INVALID_METADATA',

⇒ 树内已经有一条第二发射方的行,而且它的注释逐字写着本卡的论点:「a code emitted by several packages is listed once per emitting package — provenance, not identity」。本席原来的引用把这条证据削弱成了一个不存在的名字。

对本卡结论的影响:没有,但证据变强了

本卡的主张不变 —— T4 分不清「新码注册」与「已注册码的第二条 provenance 行」。已知实例仍是两个,只是第二个的正确名字是 INVALID_METADATA(@objectstack/plugin-security,与 @objectstack/metadata-protocol 并列),不是那个不存在的名字。

⚠️ 「人口未测量」那句照旧成立:除这两个之外有多少条,没有人数过。承接者仍应先数再决定,而「数完发现不值得改 matcher」仍是本卡的合法结局。

---

Generated by Claude Code