Filed unassigned by the dev seat measuring #9266 (session session_01Fs18A2DdXLVN2h8PaaFBcP). Duplicate-searched over open and closed issues by gate name and by vocabulary terms (nowPinned, unpinned baseline, ratchet message); the only hits were #9266 and #9244, neither of which covers this.
What was measured
scripts/check-error-status-conformance.mjs computes the ratchet-down trigger as a subtraction, not as a producer test:
const nowPinned = [...baselined].filter((c) => !result.unpinned.includes(c) && vocabulary.includes(c)).sort();
result.unpinned is populated only for codes that are documented (reconcile(), the else if (documented.has(code)) arm). documented is filled by the doc-side entry-heading scan. So a baselined code drops out of result.unpinned for either of two unrelated reasons:
- a producer appeared — the case the message describes, or
- its catalog entry was removed — the code is still a
StandardErrorCode member, so it stays in vocabulary, but nothing documents it any more.
The message hard-codes reason 1:
export function nowPinnedMessage(code) {
return `${code}: baselined as unpinned, but a producer now declares its status — ratchet the baseline down with --update.`;
}Observed, not reasoned
Deleting the three ## Batch Operation Errors catalog entries on main (the retirement remedy #9266 is weighing) and re-running the gate:
unpinned: 34 documented code(s) with no derivable producer (baselined: 37).
x BATCH_COMPLETE_FAILURE: baselined as unpinned, but a producer now declares its status — ratchet the baseline down with --update.
x BATCH_PARTIAL_FAILURE: baselined as unpinned, but a producer now declares its status — ratchet the baseline down with --update.
x TRANSACTION_FAILED: baselined as unpinned, but a producer now declares its status — ratchet the baseline down with --update.
x check:error-status-conformance — 3 finding(s).
No producer declares a status for any of the three — verified by exhaustive grep across packages/, examples/ and apps/: outside errors.zod.ts:122-124 (the enum declaration) the only hits are two spec tests. The diagnosis is simply false on this route.
Why it is worth recording
The remedy the message prescribes (--update) is the correct one either way, so this does not corrupt the baseline. What it corrupts is the reader: an agent retiring a dead catalog entry is told a producer appeared, which contradicts the measurement that justified the retirement and invites a hunt for a producer that does not exist. It is a gate that reports the right action with the wrong reason, on precisely the path a #9266 remedy would walk.
Suggested shape (not claimed as decided)
Split the two causes at the point they are already distinguishable — documented.has(code) is in scope where nowPinned is computed — and give each its own sentence: "a producer now declares its status" vs "its doc entry was removed, so nothing claims a status for it any more". Both still ratchet down with --update. A --self-test case per branch, per the file's own convention (ENTRY_HEADING_SHAPES sets the precedent that an unexercised branch is the defect).
Not claimed
- No defect in the ratchet direction or in
--update. The baseline outcome is correct; only the explanation is wrong.
- Not measured: whether any other message in this gate has the same single-cause-for-a-subtraction shape.
Backlinks: #9266 (the card whose measurement surfaced this) · #9244 (the census that made both visible).
Filed unassigned by the dev seat measuring #9266 (session
session_01Fs18A2DdXLVN2h8PaaFBcP). Duplicate-searched over open and closed issues by gate name and by vocabulary terms (nowPinned, unpinned baseline, ratchet message); the only hits were #9266 and #9244, neither of which covers this.What was measured
scripts/check-error-status-conformance.mjscomputes the ratchet-down trigger as a subtraction, not as a producer test:result.unpinnedis populated only for codes that are documented (reconcile(), theelse if (documented.has(code))arm).documentedis filled by the doc-side entry-heading scan. So a baselined code drops out ofresult.unpinnedfor either of two unrelated reasons:StandardErrorCodemember, so it stays invocabulary, but nothing documents it any more.The message hard-codes reason 1:
Observed, not reasoned
Deleting the three
## Batch Operation Errorscatalog entries onmain(the retirement remedy #9266 is weighing) and re-running the gate:No producer declares a status for any of the three — verified by exhaustive grep across
packages/,examples/andapps/: outsideerrors.zod.ts:122-124(the enum declaration) the only hits are two spec tests. The diagnosis is simply false on this route.Why it is worth recording
The remedy the message prescribes (
--update) is the correct one either way, so this does not corrupt the baseline. What it corrupts is the reader: an agent retiring a dead catalog entry is told a producer appeared, which contradicts the measurement that justified the retirement and invites a hunt for a producer that does not exist. It is a gate that reports the right action with the wrong reason, on precisely the path a #9266 remedy would walk.Suggested shape (not claimed as decided)
Split the two causes at the point they are already distinguishable —
documented.has(code)is in scope wherenowPinnedis computed — and give each its own sentence: "a producer now declares its status" vs "its doc entry was removed, so nothing claims a status for it any more". Both still ratchet down with--update. A--self-testcase per branch, per the file's own convention (ENTRY_HEADING_SHAPESsets the precedent that an unexercised branch is the defect).Not claimed
--update. The baseline outcome is correct; only the explanation is wrong.Backlinks: #9266 (the card whose measurement surfaced this) · #9244 (the census that made both visible).