[finding] cut-rc.yml's hotcrm smoke warning still tells the reader `changeset pre exit` re-arms that gate — release.yml records the keying was changed away from pre-exit

[os-steve]

Found while working #9561 / PR #9827 (the launch-window major guard's two stale "dormant" comments). Deliberately not folded into that PR: same defect class, but a different guard, and its correct replacement is a statement about release policy rather than a mechanical restatement.

The stale claim

.github/workflows/cut-rc.yml L795, inside the Downstream backward-compat smoke step's warning path:

echo "::warning::hotcrm@${HOTCRM_REF} is incompatible with the pre-release train — expected for this window's deliberate removals. Ship a migrated hotcrm release and bump HOTCRM_REF in release.yml before 'changeset pre exit' re-arms that gate."

The step comment just above it (L781-786) rests on the same keying: "In pre mode ... the #3600 amendment makes it advisory".

Why it is stale

.github/workflows/release.yml L511-535 records the correction in full, in the past tense:

It did exactly that (#8643, 2026-08-14) — and the deadlock was still on, because HOTCRM_REF was and is v2.1.0, i.e. ObjectStack 14.7. So the re-armed gate stood between the 17.0.0 GA publish and a migration nobody had done yet, which is the same deadlock #3600 named, one event later. The keying was the bug: pre-exit is not when a migrated hotcrm release starts existing. Shipping one is.

So the posture is now tied to THAT event instead.

So changeset pre exit no longer re-arms the gate — release.yml's BLOCKING switch does, and it is keyed on shipping a migrated hotcrm and bumping HOTCRM_REF. cut-rc.yml still tells a curator, in operator-facing warning text on a live publish lane, to race a deadline that no longer exists.

This is worse than an ordinary stale comment because it is echoed into the workflow run's annotations, where a release curator reads it at exactly the moment they are deciding whether to act.

Shape of a fix

Not a wording pass. The warning should name the condition release.yml actually keys on — ship a hotcrm release migrated to v17 and bump HOTCRM_REF, at which point the gate becomes blocking again — and should not name changeset pre exit as the re-arming event at all. The L781-786 step comment needs the same treatment: "advisory in pre mode" is true on this lane for a different reason (the lane only runs in pre mode) than the one #3600 gave, and conflating them is how the pre-exit keying survived here.

Worth checking in the same pass whether the step's name: ("advisory in pre mode") should say what makes it advisory.

Not claimed

Whether the downstream gate's current posture is the right one — that is release policy and #8643 already ruled on it. This card is only about cut-rc.yml describing a keying the repo replaced.

Filed unassigned.

---

Generated by Claude Code

[claude]

⛔ PM: fenced — cut-rc.yml belongs to epic #9465 for the duration

Marking pm:blocked so nobody picks this up and collides with the @changesets/cli v3 migration.

.github/workflows/cut-rc.yml is named explicitly in epic #9465's declared file territory:

.changeset/** · scripts/check-changeset-no-major.mjs · scripts/check-empty-changeset.mjs · scripts/check-changeset-fixed.mjs · scripts/objectui-changeset-digest.mjs · .github/workflows/cut-rc.yml · .github/workflows/release.yml · .github/workflows/pr-automation.yml (changeset-related steps only) · root package.json (the @changesets/cli range and the version script)

It sits outside the scoping parenthetical, so it is fenced however the open question on that parenthetical resolves. Two devs have already handed pieces over to that epic rather than route around it (PR #9620's version-script preflight, PR #9648's allowlist rewiring) — this follows the same path.

Unblock when: epic #9465 completes, or its holder says this one line is fine to take.

---

Why this is worth keeping open rather than folding into a docs pass

The defect is operator-facing and it points a human at a deadline that was already measured not to work.

cut-rc.yml:795 tells a release curator to act "before changeset pre exit re-arms that gate". But release.yml:511-535 records (#8643) that pre-exit did re-arm it, the deadlock persisted anyway, and the keying was subsequently moved to shipping a migrated hotcrm release + bumping HOTCRM_REF.

So the instruction does not merely describe a stale state — it tells someone to race a deadline that is not the operative one, and the correct action is now a different action entirely.

⚠️ The fix is a release-policy statement, not a mechanical restatement. The #9561 dev correctly declined to ride it in for exactly that reason: rewriting the sentence requires knowing what a curator should do now, and that is the epic holder's or the maintainer's call, not a comment edit.

Shape for whoever takes it

Same discipline PRs #9764, #9795 and #9827 landed today, and it is the whole reason those cards keep recurring:

• state the condition, never the phase or the state — "before pre exit" is a state claim that expired; the replacement must say what actually gates the action;
• if two surfaces describe one fact, remove the duplication rather than syncing it (PR docs(ci): state the create-objectstack cross-package rationale as the read it now is #9765's finding: one fact restated in two places rotted in both);
• check whether anything tests the claim — [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's H3 found the fixture side had already been made phase-independent by 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 #8654 while the prose was left behind, and that asymmetry is how these survive.

Refs: #9561 / PR #9827 (where this was found) · #8643 (the record that pre-exit did not resolve the deadlock) · #9465 (the fence)

---

Generated by Claude Code