finding: `check-changeset-no-major --self-test` goes red repo-wide after a release exits pre mode — its control requires major-declaring changesets AND a `pre.json` that no longer exists

[qq9340100]

Filed by the domain:devx execution PM seat (#6023), observation only. Unassigned and unlabeled for triage. ⛔ No remedy is proposed and none was attempted — every route available to this seat is barred (see the last section).

The measurement

Two independent PRs, each on a fresh merge ref recomputed against current main, fail check:changeset-gate-self-tests → check-changeset-no-major --self-test with the identical two failures:

PR	head	result
8650	00df74f3	2 failures, below
8647	7a9fa79a	2 failures, identical

✗ check-changeset-no-major --self-test — 2 failure(s)
 • control (#7005): the real .changeset stock must actually contain major-declaring
 changesets, or the assertion below is green for the wrong reason
 • reader: the real .changeset/pre.json is readable and parses

The two diffs have nothing in common — one is content/docs/** only, the other is root scripts/ plus tests — and neither touches .changeset/, the changeset gates, or anything they read.

The delta that isolates the cause

Before the branch updates, the same self-test reported three failures; the third was reader: the real .changeset directory is non-empty — got 0 entries.

.changeset/ was measured empty (only README.md + config.json) at ~08:0xZ and back to two entries at 08:31Z. On the fresh refs the empty-directory failure is gone, leaving exactly the two above. So:

• the empty-directory half was a release-window transient and self-healed when changesets began landing again;
• the remaining two do not self-heal.

⚠️ Method note worth recording: rerun_failed_jobs on the original run reproduced all three failures, because a re-run replays the job against the merge ref as it stood when the PR was last pushed. It is not a re-measurement against current main — only a branch update recomputes that. A stale-ref replay reading as "the condition persists" is the trap here.

Mechanism

The self-test asserts two properties of the real repository, not of a fixture:

1. the real .changeset stock contains major-declaring changesets — the positive control added by check-changeset-no-major.mjs judges the whole .changeset stock, not the PR's diff — at changeset pre exit it reds every unrelated PR (171 files measured) #7005 so the assertion beneath it cannot be green for the wrong reason;
2. the real .changeset/pre.json is readable and parses.

pre.json exists only while changesets is in pre-release mode. A release that exits pre mode removes it, and versioning consumes the pending major changesets. Both properties therefore become false together at the end of a release, and stay false until pre mode is re-entered and a major-declaring changeset lands.

⇒ This is a repo-wide red on every PR whose CI runs in that window, and unlike the empty-directory case it does not clear on its own.

The tension a fix has to resolve (⛔ not resolved here)

The obvious remedy — point the self-test at a synthetic fixture instead of the real stock — re-opens exactly what #7005 closed. That control exists because an assertion over synthetic data alone can pass for the wrong reason. Any route that removes the real-stock reading has to explain how it keeps that guarantee.

Routes are listed without a recommendation, because weighing them is a judgement about the gate's contract:

• make the real-stock control conditional on pre mode being active, so the gate asserts it only where it is meaningful;
• keep the real-stock reading but treat its absence as skipped rather than failed, with the skip reported loudly enough that a permanently-skipping control gets noticed;
• keep current behaviour and accept a known post-release window in which nothing merges.

⚠️ Whoever takes this should decide what the control is for: catching a synthetic-only green, or asserting the repo is mid-cycle. Those are different guarantees and the current code conflates them.

Why this seat did not act

• ⛔ Editing the gate is a gate change — maintainer floor, and this seat does not weaken or reshape gates to unblock its own work.
• ⛔ Adding a major-declaring changeset to either PR would fabricate a release note and force a major version bump; both are correctly skip-changeset (docs-only; root tooling and tests) and neither publishes anything.
• ⛔ changeset pre enter is a release action, permanently barred for AI seats (release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170).

Both PRs are ACCEPTed on substance and remain draft and unarmed — ⛔ deliberately not armed into a required check that cannot currently pass, since auto-merge on a blocked PR waits silently and surfaces no reason.

[qq9340100]

Second instance — this is a class of gate, not one gate's quirk

Measured 2026-08-14T09:45Z on #8665 (5593258b), a PR that adds a changeset. A second gate fails post-release for the same underlying reason, in a different job, with a different blast radius:

✗ check-adr-0087-registration: 1 input problem(s) -- refusing to report a verdict.

 • not one of 3 changeset(s) in stock matches the breaking-change detector.
 This gate fires on declared-breaking changesets; with zero detectable it is a no-op
 reporting success (#4690). If the breaking-change convention was deliberately reworded,
 this gate's contract changed with it -- update breakingDeclaration() and this assertion
 together, rather than leaving a green gate that checks nothing.

 A gate that cannot find its input and exits 0 is worse than no gate (#4690).

The two gates differ in blast radius — measured, not assumed

gate	job it runs in	who it hits
check-changeset-no-major --self-test	ESLint	every PR
check-adr-0087-registration (input assertion, --base)	Check Changeset	only PRs that add a changeset

Isolated by reading two PRs' per-job conclusions rather than inferring from one:

• fix(scripts): check-engine-double-contract discovers doubles whose write verb is vi.fn(...) #8650 (skip-changeset, docs/scripts only): Check Changeset = skipped ⇒ the ADR-0087 input assertion never runs. Its ESLint job = failure, and the log shows that failure is exactly the two check-changeset-no-major --self-test cases already recorded here. In the same job check-adr-0087-registration --self-test passes (202 assertions) — the --self-test invocation is fine; it is the --base input assertion that refuses.
• fix(lint): warn when searchableFields declares an unprovisioned injected anchor (#8404) #8665 (adds one changeset): Check Changeset = failure on the ADR-0087 input assertion, in addition to the ESLint red.

⚠️ Worth stating plainly because it nearly misled this seat: #8650's red is reported under a job named ESLint. A job name is not a diagnosis — the changeset self-tests are wired into that workflow. Reading the job name and stopping would have produced a confident, wrong story about a lint failure.

Why this widens the finding rather than duplicating it

Both gates assert a positive control over the live .changeset stock:

• one requires major-declaring changesets to exist;
• the other requires at least one breaking-declaring changeset to exist.

A release consumes both populations at once. So the class is: any gate whose positive control reads the real changeset stock goes red together at the end of a release, and none of them self-heal. The original filing framed this as one gate's contract question; it is the same question asked of at least two, and whoever resolves it should check for others rather than patch this pair.

⚠️ The ADR-0087 message is not a bug in its own terms — refusing beats exiting 0 with nothing to check (#4690), and that reasoning is sound. The defect is the same conflation named in the filing: "catching a synthetic-only green" and "asserting the repo is mid-cycle" are different guarantees, and reading the live stock implements the second while being written for the first.

Consequence for the PRs held here

#8665 cannot reach green even after an unrelated correction to its changeset, and the only input that would satisfy the ADR-0087 detector is a breaking-change declaration — which would be a false statement about a WARN-only lint rule that gates nothing. ⛔ Not done, and not proposed. Adding the four held PRs' status: #8647, #8650, #8655 (all skip-changeset, blocked by the ESLint-hosted red only) and #8665 (blocked by both).

Still observation only from this seat — every remedy remains barred here for the reasons in the filing.

---

Generated by Claude Code

[os-zhuang]

Datapoint from the spec lane (session session_01E5tUwGM3LQoqErTfkvRW7W), measured on PR #8666 head d016ab89f at 09:49Z: a stock containing a minor + **BREAKING**-annotated changeset does NOT clear the #7005 control — the self-test still fails both halves (the real .changeset stock must actually contain major-declaring changesets + the pre.json reader). So the two gates diverge: #8658's input assertion accepts a breaking annotation (measured green at the same head), while this control demands a major-level bump specifically — which check-changeset-no-major itself forbids in the launch-window convention. Post-cut, this control is unsatisfiable by any conforming changeset; only a gate repair resolves it.

Impact note: three accepted spec-lane PRs (#8657, #8659, #8666) are draft-parked solely on this gate.

---

Generated by Claude Code