Clause-② criterion: does removing a FALSE REJECTION count, when no declared surface moves? Three seats read it three ways with every fact measured

[claude]

The question

Does Clause-② apply to a fix that removes a false rejection — a door that wrongly refused a legitimate body now accepts it — when no exported symbol or signature moves?

This is a criterion question, not a question about any particular diff. It came up on #15950 / PR #16223, where three seats read it three ways with every relevant fact already measured and the disagreement resting entirely on how the criterion is worded.

Why it needs naming once rather than per PR

"A fix that removes a false rejection" is a recurring shape, not a one-off: any declared-but-not-enforced repair, any gate whose resolution universe was too small, any validator keyed on a stale source. Each one will re-derive this from scratch, and the two readings lead to different lanes — one takes a contract review at CONTRACT_REVIEW_TIER, the other is an ordinary blocking-defect round.

The two readings, as they were actually argued

A — yes, it is Clause-② (what the implementing seat declared, and it hung needs:contract-review on both carriers):

• The criterion as written is "any card that changes accept-or-reject behaviour, however small" (「不论多小」), phrasing that appears designed to defeat exactly the "it is only a bug fix" reading.
• PUT /api/v1/meta/dashboard flips 422 → 200 on a published contract face, measured against a prod-like deployment.
• The error costs are asymmetric: an over-declaration costs one visible review round; an under-declaration crosses a maintainer guardrail invisibly.

B — no, it is not:

• The rejection being removed is a phantom. packages/lint/src/runtime-gate.ts:165 already declares the field as "The live dataset declarations", so the set of legitimate bodies accepted is unchanged — the implementation is moving into conformance with an already-published contract. That is the declared-not-enforced class, an ordinary blocking-defect lane.
• Measured support: 0 exported symbols or signatures move; the sole declaration delta is private foldStoredCollection;, a private member's bare name.
• The standing precedent that made [finding] ObjectQL.find returns hookContext.result unguarded, so an afterFind hook can make a find() declared to resolve to any[] resolve to an envelope instead — measured #15823 a yes grounds it specifically on the accepted behaviour NARROWING ("a non-array afterFind result is now refused"). Narrowing can break a working consumer; a widening that deletes a false refusal cannot, because nothing could have relied on it except the defect itself.

What a ruling would look like

Whatever the answer, the useful output is one named boundary in the criterion, e.g.:

• "Clause-② covers a narrowing of accepted behaviour and any movement of a declared surface; a widening that removes a refusal the published contract already contradicted is NOT clause-② — it is the declared-not-enforced lane" — or
• "Clause-② covers any change to accept-or-reject at a published door, in either direction", which settles it the other way and makes the declared-not-enforced lane a subset.

⛔ This card does not decide PR #16223. That PR carries needs:contract-review on both carriers and its reviewer decides it on the day; if this criterion later says otherwise, that is a downgrade someone can apply in one line rather than a re-derivation.

Positions on record

• Implementing seat (The dashboard publish gate resolves widget.dataset against the boot-time stack, so a dataset saved through PUT /meta/dataset is a phantom widget-dataset-unknown until the runtime restarts #15950 round): A, recommended with the asymmetry argument, and it recorded B's full argument in its own PR body and claim comment so a reviewer can downgrade in one line rather than re-derive.
• Triage seat: B (read no at triage time).
• PM dispatch seat: read no in the dispatch brief's Zone 2; on the measured facts I now think B is the better reading — and ⛔ I did not act on that: a PM seat never strips a needs:contract-review hung by the implementing seat, and the one reason I must not act on is the one that would benefit me (this seat cannot perform contract reviews at all, so a yes costs me a held PR — throughput is not an argument about a contract criterion).

Refs

#15950 (the card) · PR #16223 (the diff, held on needs:contract-review) · #15823 (the ruled precedent, grounded on narrowing) · the ruling and full record: #15950 (comment)

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option C: removing a false rejection is not a clause-② move on its own, and the no declaration must cite the published contract text that makes the rejection false (director seat, decision batch #55, 2026-09-06 13:51Z)

Maintainer's reply to the batch, verbatim: 「同意」 — recommendation C adopted as ruled.

The criterion, as ruled

1. Clause ② is anchored on two machine-readable facts: (a) an exported symbol or signature moves on a published .d.ts under files[], or a new key lands on a published payload — the mechanical floor; (b) the accept set of a published door narrows, or a declared surface moves.
2. Removing a false rejection — a refusal the already-published contract text contradicts (a .describe(), a documented route contract, a schema the door was supposed to honour) — is the declared-not-enforced lane: it widens the accept set back to what the contract already promised and is graded Clause-②: no.
3. Burden of proof on the no: the claim comment (and the PR body) must quote the published contract text the rejection contradicts. A no without that citation is illegible (pair check treats it as missing). A reviewer, or the seat, downgrades to yes in one line if the citation does not say what is claimed — the false-rejection reading is then not established and the change is reviewed at tier.
4. A rejection that was deliberate (a guard with its own ruling, a security refusal, a fail-closed posture) is never a "false rejection" however wrong its prose; removing it is a narrowing/widening of a ruled surface and is yes.

Execution: this is text in .claude/skills/pm-dispatch/references/contract-review.md (the criterion section and the claim-comment spelling) plus, if the pair checker reads the declaration line, a one-line rule that a Clause-②: no on a rejection-removing diff carries a Contract-text: citation. That is the skills seat's work.

State: needs-user-decision → pm:queue in this stroke; domain:skills added (the card carried no lane).

---

Generated by Claude Code

[claude]

Blocked-by: #16004

Graded priority:p2 documentation by the skills seat (14:2xZ) and placed behind flight A. The ruling (option C, 13:51Z) names references/contract-review.md as the execution surface, but that file's own first line points the clause-② criterion at SKILL.md 〈入队与落地〉, where the criterion sentences live (the 强制条款② line and its negative boundary, three lines apart) — so the named boundary (a narrowing or a declared-surface move is yes; a widening that removes a refusal the published contract already contradicts is no, with the contract text cited; a deliberate refusal is never a false rejection) lands in SKILL.md, with contract-review.md carrying the claim-comment spelling (Contract-text: beside a Clause-②: no on a rejection-removing diff) and check-clause2-carriers.mjs a one-line reading of that spelling if the declaration limb is read there. SKILL.md is held by flight A (#16004 + #16064 + #15897 + #15975 + #14768's hit + #15961) — same file, a flight already running, no fold — so this card is dispatched as its own flight the moment flight A's PR merges.

---

Generated by Claude Code