Decide: does mandatory-fable clause ② cover packages/lint authoring rules that newly reject clean metadata? (PR #9890 held)

[claude]

Raised by the domain:devx PM seat off PR #9890 (#9698), which is held out of the merge queue pending this answer. The work is reviewed and accepted; only the tier question blocks it.

The ambiguity

SKILL.md's mandatory-fable clause ② reads:

② 凡改变契约接受/拒绝行为或扩大公开面的卡(domain:spec 语义面;判据即分诊代裁的机械边界测试与 spec 席内分派判据,⛔ 不另抄第二份)一律 claude-fable-5

Two readings, and they disagree on a whole class of card:

• Operative text — "改变契约接受/拒绝行为". A new packages/lint authoring rule that refuses previously-lint-clean metadata plainly does this: metadata that built yesterday fails objectstack build today. ⇒ clause ② applies, fable mandatory.
• Parenthetical scope — "(domain:spec 语义面 …)". lint: a sharing rule declared on an object whose effective sharing model is public is statically detectable and unreported until boot #9698 is domain:devx, lands in packages/lint, and touches no spec schema. ⇒ clause ② does not apply, opus is correct.

scripts/pm/dispatch-gates.mjs --tier returns "no path-derived mandate" on these paths — which is explicitly a FLOOR, never a clearance, so the tool cannot settle it either.

Why the PM seat cannot resolve this itself

The dispatching seat reading the clause narrowly, such that its own dispatch turns out to have been correctly tiered, is self-clearing — forbidden by name. I dispatched #9698 at opus. Any answer I give here is the answer that exonerates me, so the answer has to come from elsewhere.

The dev declared Clause-②: yes on the claim comment against its own interest — the declaration is what is holding up its own finished PR — and asked for the disposition rather than picking one. That is the behaviour the rule is meant to produce, and it worked; what it exposed is that the clause's boundary is undefined for this class.

Why it recurs

This is not one card. packages/lint authoring rules are a standing category in the devx lane, and every one of them has the same shape: make the build reject something it used to accept. The lane will hit this question again within days. Today it is resolved per-card by whoever happens to read the clause, which is the worst of the three possible states.

Note the asymmetry that makes it matter: a lint rule's accept/reject change is authoring-time, caught by the author on their next build, and reversible in one revert. A spec contract change poisons downstream consumers who never see it. That asymmetry is presumably why the parenthetical scopes to domain:spec — but the operative text does not say so.

The question

Does clause ② cover a packages/lint authoring rule that newly rejects previously-clean metadata?

• A — yes, the operative text governs. Any card making the toolchain reject what it used to accept is fable, wherever it lands. Safest; raises the tier on a recurring devx category, and would make PR lint: a sharing rule anchored where sharing has nothing to widen is an authoring-time error #9890 a mis-tiered dispatch needing re-run or explicit clearance.
• B — no, the parenthetical scopes it to domain:spec 语义面. Lint authoring rules stay at the PM's judgement tier (opus default, fable when the rule's semantics are the hard part). Matches the asymmetry above; needs the clause amended so it stops reading like A.
• C — a third tier: lint rules are clause-② only when the rejected shape is one the spec schema still accepts — i.e. when lint and spec would disagree about validity. Narrowest and most principled; costs a judgement call per card, which is what the clause was written to remove.

My read is B, and I am stating it as input, not as a decision — under the self-clearing bar it cannot be mine. If B, the clause should be amended to say so explicitly, because the current text supports A on a plain reading and the next dev will declare Clause-②: yes again.

⚠️ Whatever the answer: amending SKILL.md is itself clause-① (.claude/skills/pm-dispatch/**), so the amendment is fable-mandatory and human-merge-only. Same constraint as #9884.

Disposition of PR #9890 either way

• B or C ⇒ clearance recorded here, needs:contract-review dropped, PR queued as normal.
• A ⇒ needs a contract-review-tier seat other than this one to clear it, or a re-run on fable. ⚠️ The work is measured and complete — three sharing postures exercised against a real SharingService, and an ablation that proved it reached the built artifact before concluding. A re-run should re-verify the tier, not re-derive the result.

Refs: PR #9890 / #9698 (held) · #9884 (the other governed pm-dispatch card) · SKILL.md 模型分级 §.

---

Generated by Claude Code

[claude]

PM: closing this — the SKILL already answers it, and my tentative reading was wrong

I filed this as a maintainer decision. It is not one. Updating this seat's checkout to origin/main (818c27ce42) brought a pm-dispatch/SKILL.md revision that rules the question outright, under 条款②入队闸门 (maintainer approved 2026-08-16; 声明肢 ruled 2026-08-17).

The ruling

双肢命中任一 且派发档位低于契约复审档位 ⇒ ⛔ 禁止入队

• 路径肢 = diff 触及契约面 (packages/spec/src/**, 含 error-code-ledger 与 *.zod.ts 契约 schema)
• 声明肢 = 认领评论声明 Clause-②: yes,与路径无关

⛔ 永不把路径触发读作条款②的完整覆盖 —— 它只盖路径肢;不触契约文件而改变接受/拒绝行为或扩大公开面的内容肢由声明行承载。

That is this card's exact fact pattern, named: a change that alters accept/reject behaviour without touching contract files. The content limb is carried by the declaration line, and the declaration is path-independent.

So option A is correct, and my stated read (B) was wrong

I wrote "My read is B" — that the parenthetical scopes clause ② to the domain:spec semantic surface, so a packages/lint authoring rule falls outside. The SKILL forbids precisely that inference: the parenthetical delegates the path criterion to references/lanes/spec.md; it does not bound the clause. Reading a path trigger as the whole of clause ② is the error the rule names in advance.

PR #9890's hold stands, for the reason the dev gave rather than the one I was unsure of.

What I got right, and what I got wrong

Right: the dispatching seat's duty is "卡上记一行认定、挂 needs:contract-review、停手;⛔ 禁止自查放行" — record, label, stop, never self-clear. That is what I did, and my "I cannot resolve this myself" instinct was correct even though my reasoning about why was not.

Wrong: I escalated to the maintainer a question the SKILL already answers, and I pointed at the wrong resolver.

The correct resolver is NOT the maintainer

复审资格双条件,同时满足 —— ① 跑在契约复审档位;② 非该卡派发席(犯规席在结构上无资格补救自己的犯规)。
归属:常设 = 分诊席 …;过渡期(分诊 Routine 未建成前)由 skills 席代行。

Contract-review tier is CONTRACT_REVIEW_TIER = 'claude-fable-5' (scripts/pm/dispatch-gates.mjs:1629 — the single source; ⛔ the tier is never spelled as a model name in prose or labels).

⇒ PR #9890 needs the 分诊席, or the skills 席 acting for it in the transition — running at claude-fable-5, and not this seat. It reviews only the contract increment, writes a one-line conclusion on the card, and clears the label; only then may it queue.

⚠️ Also noted: 契约复审 ⛔ 不适用额度耗尽豁免降档 — the exemption applies to dispatch, and the review exists precisely to compensate for one below-floor dispatch. So this cannot be cleared on opus for quota reasons.

Closing as answered. The mis-tiered dispatch itself remains mine.

---

Generated by Claude Code