Skip to content

[finding] Two comments still call the launch-window major guard "dormant because we are in pre mode" — the repo left pre mode at the 17.0.0 GA and the guard is armed #9561

Description

@os-project-manager

Found while landing the @changesets/cli v3 migration (#9498 / PR #9560), in the same headers that card rewrites. Deliberately not folded into that PR — it is a different defect class: nothing about v3 causes it, and correcting it reverses a present-tense claim rather than restating a measured one, which is a judgement the migration card was not scoped to make.

The measurement

.changeset/pre.json is absent on main (verified on 955ccf20d and again on 65d4fff7c). The repo is not in pre mode and has not been since the 17.0.0 GA exit. readPre() collapses absent to null, and judge() gives an exemption only on pre?.mode === 'pre' — so the guard is armed, not dormant.

The two stale claims

1. .github/workflows/pr-automation.yml:783

# DORMANT TODAY, and the dormancy is deliberately not load-bearing.
# `check-changeset-no-major.mjs` stands aside for the whole pre-release
# window (its RC EXEMPTION note) and `.changeset/pre.json` currently says
# `"mode": "pre"`, so the guard below cannot fail and the label is never
# needed. It re-arms by itself at `changeset pre exit` -- precisely the day
# whole-stack majors are under discussion and `allow-major` is most likely to
# be applied by hand, seconds after `gh pr create`.

The re-arm the paragraph predicts has already happened. The comment now reads as a live description of a state the repo left.

2. scripts/check-changeset-no-major.mjs:195 (the --self-test coverage note, #6923)

* NOT COVERED — the CI path. `.changeset/pre.json` says `"mode": "pre"`, so
* the real scan below still takes the exemption branch and exits 0 on every
* run; the `enforce` verdict has never been produced by a CI invocation of
* this script and still is not after #7005.

Same false premise, and it matters more here: this note exists to tell a reader how much to trust a green tick from this file. It understates the gate's coverage — today a PR that introduces a major gets the enforce verdict from a real CI invocation, not an exemption. A clean PR gets clean, which is a third case and also not the exemption branch.

Why it is worth a card rather than a drive-by

Both comments are the kind a reader acts on. #1 sits directly above the live allow-major label read and tells whoever maintains it that the step cannot fail; #2 is quoted whenever someone asks whether this gate is really enforcing. This is the same class as the closed #8654 — a pre-mode assumption outliving the window that made it true — reached from the prose side instead of the fixture side.

Shape of a fix

Not a wording pass: whoever takes it should decide what these notes should say in a repo that moves in and out of pre mode, so the claim does not go stale again at the next pre enter. The candidates, roughly:

  • state the phase-dependence rather than the phase ("this guard is exempt for the duration of an RC window; outside one it enforces"), which is true in both phases and needs no edit at the next transition; or
  • keep a dated present-tense reading, and add it to whatever list already gets refreshed at a cut.

The #6923 note in #2 additionally needs its coverage claim re-derived, not just re-worded: "fixtured but never executed on CI" was the whole point of that paragraph, and it is now wrong in the direction that flatters the gate.

Adjacent, already correct: the same file's header measurement at line ~62 (the 1552/171/222/1279 numbers) was dated to @changesets/cli v2 in PR #9560, so it reads as history and is not part of this finding.


Generated by Claude Code

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions