Skip to content

[finding] a ruling cleared a by-design red by citing 「the protocol's by-design carve-out」 — landing pre-check ③ has no such exception, and check-empty-changeset manufactures that red on purpose #18404

Description

@os-warren

Filed by the domain:spec execution seat (#6017), session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T09:2xZ. ⛔ Not claimed, ⛔ not dispatched. Grading is triage's. ⛔ This seat did not run a dedupe search (per 「立卡者不查重,只附查重词」).

The defect

A maintainer ruling relayed to PR #18198 (comment 5692650519, 2026-09-16T05:46Z) cleared a by-design Check Changeset red with this reason, verbatim:

the gate stays red by design and that red is now admissible under the protocol's by-design carve-out (the PR comment names the gate and the reason, and the maintainer has confirmed)

No such carve-out exists in the protocol.

The controlled zero

  • zero leg: 按设计红 / by-design across .claude/skills/pm-dispatch/0 files.
  • control, same corpus and same path shape: 落地前检4 files ⇒ the probe finds a landing-check concept where the skill has one, so the zero is a real absence rather than a search miss.

What landing pre-check ③ actually says, and why its one exception does not reach this case

references/contract-review.md:45, verbatim:

③ PR 全部 check 全绿,⛔ 非 required 子集;例外:merge-base 上同名同失败签名的红不计。

The only exception is a red already present on the merge base with the same failure signature. It does not cover the #18198 case: the changeset correction exists only on that branch, so the merge base is green on Check Changeset.

Why it landed anyway, and why that is not a substitute for the text

The authority was the maintainer's own 「确认」, which outranks ③ directly under the priority order (维护者裁决 > AGENTS.md > 红线 > 核心条款 > 细则). Mechanically it was also clean — Check Changeset is not a required context, so the queue merges on required status and ③'s 「⛔ 非 required 子集」 is a seat discipline stricter than the queue, not a machine gate. What the maintainer waived was the discipline.

⇒ The landing was sound. What is missing is the written route.

Why this is worth a card rather than a shrug

scripts/check-empty-changeset.mjs deliberately manufactures permanent reds. Its DELIBERATE CORRECTION limb states, in its own words, 「this gate stays red either way, and staying red is what puts the decision in front of a person instead of routing around it」 — so a PR correcting a pending release note is designed to reach the landing check with one red and a human confirmation behind it.

⇒ this is a recurring shape, not a one-off. Today every instance of it needs a maintainer to personally out-rank ③, because ③ has no clause for 「a red the protocol itself designed, with the confirmation the gate asked for already on the PR」.

⚠️ And the immediate harm is already live: the next seat reading ruling 5692650519 will go looking for the carve-out it cites and will not find it — landing either on a false belief that ③ has a general escape hatch, or stalling a correctly-confirmed PR.

What a fix would need to establish, ⛔ not a proposed shape

Whoever takes this has to decide whether ③ gains a second exception at all, and if so what evidence it demands — at minimum the gate is one that declares itself by-design, the PR comment names the gate and the reason, and a maintainer confirmation is on the record. ⛔ That is a decision, not a doc edit, because a wrongly-worded exception turns ③ from a discipline into a formality.

Dedupe words

by-design red · check-empty-changeset DELIBERATE CORRECTION · 落地前检 ③ · 非 required 子集 · carve-out


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions