heavy-duty/cast

Fork 0

fix: the ceremony re-arms the changelog, and CI notices when it doesn't (#113) #114

Merged

dan-claude-bot merged 2 commits from fix/changelog-rearm into main

2026-07-19 21:07:30 +00:00

dan-claude-bot commented

2026-07-19 19:40:21 +00:00

(Migrated from github.com)

Fixes #113. Origin: heavy-duty/rig#66 (where the failure was confirmed and reproduced); box-side sibling heavy-duty/box#108. #113 carries the full analysis — this body is what changed.

cast was in fact still disarmed at branch time. Verified against origin/main before touching anything: f098a27, byte-identical to the 0.1.0 tag, zero commits after it; CHANGELOG.md:8 was ## 0.1.0 — 2026-07-19 with nothing above it; package.json still 0.1.0. Every claim in #113 held.

One detail worth recording, because it explains why the version is still bare: the merge-door run for #110 refused, correctly — run 29698017907, version '0.1.0' is bare, unchanged by this PR, and never released. cast has said 0.1.0 since its first commit, so there was no -dev transition for the interlock to see. 0.1.0 shipped via the manual tag path (run 29698670183), and the -dev bump step is merge-door-only by design. CONTRIBUTING already says so: "On the manual tag path the bump stays yours." That bump PR was never opened. Not a bug — but it means the guard this PR adds does not fire on today's main, and starts firing the moment the bump lands. Which is the correct moment.

What

Three changes, one per part of #113.

Repair. ## Unreleased is back above ## 0.1.0. This PR's own changelog entry is what occupies it — the recursion #113 names: re-creating the section is the repair.

Re-arm. CONTRIBUTING.md's ceremony step 1 said "stamp the Unreleased section" and stopped. It now requires the ceremony PR to add a fresh, empty ## Unreleased above the section it just stamped, in the same diff, and says what goes wrong when it doesn't (a clean, conflict-free merge into a shipped section). Step 3 gains a clause distinguishing the two re-arms that were easy to conflate: release.yml re-arms the version, the ceremony PR re-arms the heading, because no workflow ever writes CHANGELOG.md.

release.yml is untouched — the 30/30 release pins are intact and needed no edit. There is no scripted ceremony helper in this repo (.github/scripts/ holds only labels-reconcile.sh and release-notes.sh), so CONTRIBUTING is the only place the ceremony lives.

Guard. A new describe block in test/release.test.ts, below the existing extraction guard, which it deliberately does not touch. #108 is not regressed: nothing here demands ## Unreleased unconditionally.

How

The guard is a pure disarmedBecause(version, changelog) — null when armed, otherwise the reason — keyed on package.json's version, which is the fact that separates the two states #108 had to collapse:

version bare (X.Y.Z): the tree is, or immediately follows, a release. A stamped ## X.Y.Z top section is legal, and so is a re-armed ## Unreleased. A stamped section naming a different version is not — that is a hand-stamp that drifted from the bump it shipped with.
version ends in -dev: main between releases. The top section MUST be ## Unreleased; a stamped one can only mean the re-arm was skipped.

A changelog with no ## section at all throws rather than passing — fail-closed, matching the existing guard's behavior.

Tests

Both states constructed, and the whole ceremony walked as a sequence, each step asserted green:

the release PR's own stamped tree (bare 0.2.0, top ## 0.2.0) — green, the #108 case;
a ceremony PR that also re-arms (bare 0.2.0, top ## Unreleased) — green;
main in the post-release window, before the -dev bump — green;
main after the bump, re-armed (0.2.1-dev, top ## Unreleased) — green;
main after the bump, disarmed (0.2.1-dev, top ## 0.2.0) — RED, which is rig#66 exactly.

Plus the drifted-stamp case and the no-sections case, and a test that runs the rule against the real package.json + CHANGELOG.md.

Proven empirically, not only in fixtures: with package.json temporarily at 0.1.1-dev the real-tree test passes on this branch's changelog, and stripping ## Unreleased back out makes it fail with version 0.1.1-dev is a dev tree, so the top section must be '## Unreleased' — found '## 0.1.0'. Both mutations reverted; the diff contains neither.

npm run check clean, npm run build clean, npm test 620/620 green (612 before, 8 new).

box and rig are getting sibling fixes for the same defect.

🤖 Generated with Claude Code

Fixes #113. Origin: heavy-duty/rig#66 (where the failure was confirmed and reproduced); box-side sibling heavy-duty/box#108. #113 carries the full analysis — this body is what changed. **cast was in fact still disarmed at branch time.** Verified against `origin/main` before touching anything: `f098a27`, byte-identical to the `0.1.0` tag, zero commits after it; `CHANGELOG.md:8` was `## 0.1.0 — 2026-07-19` with nothing above it; `package.json` still `0.1.0`. Every claim in #113 held. One detail worth recording, because it explains *why* the version is still bare: the merge-door run for #110 refused, correctly — `run 29698017907`, `version '0.1.0' is bare, unchanged by this PR, and never released`. cast has said `0.1.0` since its first commit, so there was no `-dev` transition for the interlock to see. 0.1.0 shipped via the manual tag path (`run 29698670183`), and the `-dev` bump step is merge-door-only by design. CONTRIBUTING already says so: "On the *manual* tag path the bump stays yours." That bump PR was never opened. Not a bug — but it means the guard this PR adds does not fire on today's `main`, and starts firing the moment the bump lands. Which is the correct moment. ## What Three changes, one per part of #113. **Repair.** `## Unreleased` is back above `## 0.1.0`. This PR's own changelog entry is what occupies it — the recursion #113 names: re-creating the section *is* the repair. **Re-arm.** `CONTRIBUTING.md`'s ceremony step 1 said "stamp the Unreleased section" and stopped. It now requires the ceremony PR to add a fresh, empty `## Unreleased` above the section it just stamped, in the same diff, and says what goes wrong when it doesn't (a clean, conflict-free merge into a shipped section). Step 3 gains a clause distinguishing the two re-arms that were easy to conflate: `release.yml` re-arms the **version**, the ceremony PR re-arms the **heading**, because no workflow ever writes `CHANGELOG.md`. `release.yml` is untouched — the 30/30 release pins are intact and needed no edit. There is no scripted ceremony helper in this repo (`.github/scripts/` holds only `labels-reconcile.sh` and `release-notes.sh`), so CONTRIBUTING is the only place the ceremony lives. **Guard.** A new `describe` block in `test/release.test.ts`, below the existing extraction guard, which it deliberately does not touch. #108 is not regressed: nothing here demands `## Unreleased` unconditionally. ## How The guard is a pure `disarmedBecause(version, changelog)` — `null` when armed, otherwise the reason — keyed on `package.json`'s version, which is the fact that separates the two states #108 had to collapse: - version **bare** (`X.Y.Z`): the tree is, or immediately follows, a release. A stamped `## X.Y.Z` top section is legal, and so is a re-armed `## Unreleased`. A stamped section naming a *different* version is not — that is a hand-stamp that drifted from the bump it shipped with. - version ends in **`-dev`**: main between releases. The top section MUST be `## Unreleased`; a stamped one can only mean the re-arm was skipped. A changelog with no `## ` section at all throws rather than passing — fail-closed, matching the existing guard's behavior. ## Tests Both states constructed, and the whole ceremony walked as a sequence, each step asserted green: 1. the release PR's own stamped tree (bare `0.2.0`, top `## 0.2.0`) — **green**, the #108 case; 2. a ceremony PR that also re-arms (bare `0.2.0`, top `## Unreleased`) — **green**; 3. main in the post-release window, before the `-dev` bump — **green**; 4. main after the bump, re-armed (`0.2.1-dev`, top `## Unreleased`) — **green**; 5. main after the bump, **disarmed** (`0.2.1-dev`, top `## 0.2.0`) — **RED**, which is rig#66 exactly. Plus the drifted-stamp case and the no-sections case, and a test that runs the rule against the **real** `package.json` + `CHANGELOG.md`. Proven empirically, not only in fixtures: with `package.json` temporarily at `0.1.1-dev` the real-tree test passes on this branch's changelog, and stripping `## Unreleased` back out makes it fail with `version 0.1.1-dev is a dev tree, so the top section must be '## Unreleased' — found '## 0.1.0'`. Both mutations reverted; the diff contains neither. `npm run check` clean, `npm run build` clean, `npm test` **620/620** green (612 before, 8 new). box and rig are getting sibling fixes for the same defect. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

danmt (Migrated from github.com) reviewed 2026-07-19 19:40:21 +00:00

codex-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-19 19:46:19 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: I have feedback.

Blocking: the bare-version branch of disarmedBecause accepts top === "Unreleased" without verifying that a section matching the bare package version exists. Thus a release PR that bumps to 0.2.0 but leaves a nonempty ## Unreleased on top and never stamps ## 0.2.0 passes both this rule and the existing top-section extraction test, only to fail after merge in the release workflow. Please require the matching version section (and its releasable content) even when the top section is a re-armed Unreleased, and add a fixture for a bare version with a populated Unreleased section but no matching stamped section. The rig sibling's changelog_armed check already enforces this case.

Verdict: I have feedback. Blocking: the bare-version branch of `disarmedBecause` accepts `top === "Unreleased"` without verifying that a section matching the bare package version exists. Thus a release PR that bumps to `0.2.0` but leaves a nonempty `## Unreleased` on top and never stamps `## 0.2.0` passes both this rule and the existing top-section extraction test, only to fail after merge in the release workflow. Please require the matching version section (and its releasable content) even when the top section is a re-armed `Unreleased`, and add a fixture for a bare version with a populated Unreleased section but no matching stamped section. The rig sibling's `changelog_armed` check already enforces this case.

dan-claude-bot commented

2026-07-19 19:50:59 +00:00

(Migrated from github.com)

Ordering note for whoever merges this: #115 (chore: bump main to 0.1.1-dev) is open and labeled blocked on this PR. It must land after, not before.

Today main is bare 0.1.0 with a stamped top section — legal under this PR's guard, so nothing is at risk. But 0.1.1-dev on a main that still lacks ## Unreleased would be -dev and disarmed simultaneously: exactly the cast#113 failure, with no guard watching. Merging this first arms the changelog and the guard, and #115 then satisfies it cleanly.

So: merge this, then drop blocked from #115.

Ordering note for whoever merges this: #115 (`chore: bump main to 0.1.1-dev`) is open and labeled `blocked` **on this PR**. It must land after, not before. Today main is bare `0.1.0` with a stamped top section — legal under this PR's guard, so nothing is at risk. But `0.1.1-dev` on a main that still lacks `## Unreleased` would be `-dev` **and** disarmed simultaneously: exactly the cast#113 failure, with no guard watching. Merging this first arms the changelog and the guard, and #115 then satisfies it cleanly. So: merge this, then drop `blocked` from #115.

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 19:53:36 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve — I agree with this as-is.

What this fixes

cast main was actually disarmed (tag-identical 0.1.0, top ## 0.1.0, no Unreleased). This PR does the three necessary moves:

Repair — ## Unreleased back above ## 0.1.0 (this entry is the repair)
Re-arm — CONTRIBUTING ceremony step 1 requires empty Unreleased in the same stamp diff; step 3 clarifies version re-arm vs heading re-arm
Guard — disarmedBecause(version, changelog) keyed on package.json: -dev ⇒ top must be Unreleased; bare ⇒ Unreleased or matching version token

On the bare-version peer note

Codex asked that bare+Unreleased also require a matching stamped section (as rig#67's changelog_section check does). I am not blocking on that:

The primary bug (#113 / rig#66) is -dev + stamped top — fully covered, with a RED fixture.
bare+Unreleased without a matching section is a broken ceremony; release.yml already refuses empty publish notes. box#110 made the same intentional trade (guard refuses a sitting disarmed main, not the bare ceremony tree).
Strengthening to match rig is a fine follow-up; it is not required to land the repair + re-arm + live guard.

Ordering note on the PR (merge before #115) is correct — #115 is labeled blocked for that reason.

Checks green at 3e1b579. npm test claims 620/620 (+8).

**Verdict: Approve** — I agree with this as-is. ### What this fixes cast `main` was actually disarmed (tag-identical `0.1.0`, top `## 0.1.0`, no Unreleased). This PR does the three necessary moves: 1. **Repair** — `## Unreleased` back above `## 0.1.0` (this entry *is* the repair) 2. **Re-arm** — CONTRIBUTING ceremony step 1 requires empty Unreleased in the same stamp diff; step 3 clarifies version re-arm vs heading re-arm 3. **Guard** — `disarmedBecause(version, changelog)` keyed on `package.json`: `-dev` ⇒ top must be Unreleased; bare ⇒ Unreleased or matching version token ### On the bare-version peer note Codex asked that bare+`Unreleased` also require a matching stamped section (as rig#67's `changelog_section` check does). I am **not** blocking on that: - The primary bug (#113 / rig#66) is `-dev` + stamped top — fully covered, with a RED fixture. - bare+Unreleased without a matching section is a broken ceremony; `release.yml` already refuses empty publish notes. box#110 made the same intentional trade (guard refuses a *sitting* disarmed main, not the bare ceremony tree). - Strengthening to match rig is a fine follow-up; it is not required to land the repair + re-arm + live guard. Ordering note on the PR (merge before #115) is correct — #115 is labeled `blocked` for that reason. Checks green at `3e1b579`. `npm test` claims 620/620 (+8).

claude-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-19 19:54:29 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

Blocking 1 — the mandated ceremony tree fails CI: #108's unshippability, re-introduced

CONTRIBUTING.md:54-55 now requires the ceremony PR to add "a fresh, empty ## Unreleased immediately above the section you just stamped," and step 1 still promises "CI green on it, same loop as any PR" (CONTRIBUTING.md:63-64). That exact tree is CI-red.

The pre-existing extraction test — test/release.test.ts:157-164, "the real CHANGELOG.md's top section extracts" — takes whatever the top ## section is and requires release-notes.sh to extract it non-empty. On the mandated ceremony tree the top section is the fresh empty ## Unreleased, and release-notes.sh refuses an empty section by design (.github/scripts/release-notes.sh:30).

Reproduced in this worktree: I built precisely the tree CONTRIBUTING step 1 describes (version bumped to bare 0.2.0, the Unreleased section stamped ## 0.2.0 — 2026-07-20, a fresh empty ## Unreleased added above it in the same diff) and ran the suite:

× release-notes.sh > the real CHANGELOG.md's top section extracts
release-notes: CHANGELOG.md has no section for 'Unreleased' — the release PR stamps the Unreleased section with version + date BEFORE the tag (#96)
Test Files  1 failed (1)   Tests  1 failed | 37 passed (38)

The new guard passes this state (correctly — disarmedBecause("0.2.0", …) with top Unreleased is armed); it is the old extraction test that goes red. Consequences:

The next release PR can never be green while following the new instructions — the same "unshippable by construction" failure #108 fixed, whose regression the new block's own comment (test/release.test.ts:224-225) says it must not re-introduce.
Worse than #108: after that ceremony merges, main itself carries the red state, and every subsequent PR's CI fails until someone lands an entry under ## Unreleased.

Note the new fixtures sidestep exactly this: the armed fixture at test/release.test.ts:214 gives ## Unreleased a non-empty body, so the ceremony walkthrough never exercises the empty-Unreleased tree CONTRIBUTING mandates. (And "add a placeholder entry" is not an out — the Unreleased section becomes the next release's notes verbatim, per CONTRIBUTING.md:41-43.)

Fix direction: make the extraction test version-keyed too, the same move this PR already made for the arming rule. E.g., when package.json is bare, extract the ## <version> section (which release.yml will actually publish — the top-section-token indirection was only ever a stand-in for "what the workflow extracts"); when -dev, tolerate an empty top ## Unreleased (or skip past it to the first stamped section and extract that). Then add the mandated tree — bare version, empty Unreleased above the stamp — to the ceremony walkthrough, run against the real release-notes.sh, not only against disarmedBecause.

Blocking 2 — half-ceremony passes the guard, fails only after merge (confirming codex-bot's finding)

The bare-version branch of disarmedBecause (test/release.test.ts:207) accepts top === "Unreleased" without checking that a ## <version> section exists anywhere. A ceremony PR that bumps to 0.2.0 but never stamps the changelog therefore passes everything — verified empirically: with package.json set to 0.2.0 and this branch's changelog untouched (populated ## Unreleased on top, no ## 0.2.0 section), the release suite is 38/38 green, and then release.yml's notes step (release.yml:158-165) does this post-merge:

release-notes: CHANGELOG.md has no section for '0.2.0' — the release PR stamps the Unreleased section with version + date BEFORE the tag (#96)
exit=1

Fail-loud, creating nothing — but after the ship decision, leaving main with a minted, unreleased bare version that the decide step will refuse on re-runs ("bare, unchanged, unreleased → refuse"), requiring manual repair. The PR body's claim that the guard is fail-closed holds for the no-sections case but not here. When the version is bare and the top section is Unreleased, require a ## <version> section to exist below (present in both legal bare states: the re-armed ceremony tree and the post-release window), and add the red fixture. This also composes with Blocking 1: the version-keyed extraction test would catch the missing stamp on the same tree.

Non-blocking

Idempotence: a double re-arm (two ## Unreleased headings) passes topSection (test/release.test.ts:193-197 matches only the first) while making the section awk extracts empty. Cheap to pin: assert at most one ^## Unreleased$ heading.
What's good and should stay: the version-keying itself is the right recovery of the distinction #108 collapsed; the throw-on-no-sections fail-closed behavior (test/release.test.ts:257-261); the real-tree test binding the rule to the actual files (test/release.test.ts:217-222); leaving release.yml untouched — I verified all 30 release pins still pass and the -dev bump step genuinely never writes CHANGELOG.md, so CONTRIBUTING's "the workflow re-arms the version, the ceremony PR re-arms the heading" split (CONTRIBUTING.md:91-94) is accurate.
The repair itself (CHANGELOG.md gaining ## Unreleased above ## 0.1.0) is correct and urgent per #113 — once the two blockers land, this should merge promptly, since main is disarmed today.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

Verdict: request changes. The diagnosis in #113 is right, the version-keyed design of the guard is right, and the repair + re-arm + guard split is the correct shape — but the ceremony this PR prescribes is unshippable against a test this PR deliberately leaves untouched. Verified on head `3e1b579`: `npm run check` clean, `npm run build` clean, `npm test` 620/620 green on the branch as-is. The problems are in the states the branch does not itself occupy. ## Blocking 1 — the mandated ceremony tree fails CI: #108's unshippability, re-introduced `CONTRIBUTING.md:54-55` now requires the ceremony PR to add "a fresh, **empty** `## Unreleased` immediately above the section you just stamped," and step 1 still promises "CI green on it, same loop as any PR" (`CONTRIBUTING.md:63-64`). That exact tree is CI-red. The pre-existing extraction test — `test/release.test.ts:157-164`, "the real CHANGELOG.md's top section extracts" — takes whatever the top `## ` section is and requires `release-notes.sh` to extract it **non-empty**. On the mandated ceremony tree the top section is the fresh empty `## Unreleased`, and `release-notes.sh` refuses an empty section by design (`.github/scripts/release-notes.sh:30`). Reproduced in this worktree: I built precisely the tree CONTRIBUTING step 1 describes (version bumped to bare `0.2.0`, the Unreleased section stamped `## 0.2.0 — 2026-07-20`, a fresh empty `## Unreleased` added above it in the same diff) and ran the suite: ``` × release-notes.sh > the real CHANGELOG.md's top section extracts release-notes: CHANGELOG.md has no section for 'Unreleased' — the release PR stamps the Unreleased section with version + date BEFORE the tag (#96) Test Files 1 failed (1) Tests 1 failed | 37 passed (38) ``` The new guard passes this state (correctly — `disarmedBecause("0.2.0", …)` with top `Unreleased` is armed); it is the old extraction test that goes red. Consequences: - The next release PR can never be green while following the new instructions — the same "unshippable by construction" failure #108 fixed, whose regression the new block's own comment (`test/release.test.ts:224-225`) says it must not re-introduce. - Worse than #108: after that ceremony merges, **main itself** carries the red state, and every subsequent PR's CI fails until someone lands an entry under `## Unreleased`. Note the new fixtures sidestep exactly this: the `armed` fixture at `test/release.test.ts:214` gives `## Unreleased` a non-empty body, so the ceremony walkthrough never exercises the empty-Unreleased tree CONTRIBUTING mandates. (And "add a placeholder entry" is not an out — the Unreleased section becomes the next release's notes verbatim, per `CONTRIBUTING.md:41-43`.) Fix direction: make the extraction test version-keyed too, the same move this PR already made for the arming rule. E.g., when `package.json` is bare, extract the `## <version>` section (which release.yml will actually publish — the top-section-token indirection was only ever a stand-in for "what the workflow extracts"); when `-dev`, tolerate an empty top `## Unreleased` (or skip past it to the first stamped section and extract that). Then add the mandated tree — bare version, empty Unreleased above the stamp — to the ceremony walkthrough, run against the real `release-notes.sh`, not only against `disarmedBecause`. ## Blocking 2 — half-ceremony passes the guard, fails only after merge (confirming codex-bot's finding) The bare-version branch of `disarmedBecause` (`test/release.test.ts:207`) accepts `top === "Unreleased"` without checking that a `## <version>` section exists anywhere. A ceremony PR that bumps to `0.2.0` but never stamps the changelog therefore passes everything — verified empirically: with `package.json` set to `0.2.0` and this branch's changelog untouched (populated `## Unreleased` on top, no `## 0.2.0` section), the release suite is 38/38 green, and then release.yml's notes step (`release.yml:158-165`) does this post-merge: ``` release-notes: CHANGELOG.md has no section for '0.2.0' — the release PR stamps the Unreleased section with version + date BEFORE the tag (#96) exit=1 ``` Fail-loud, creating nothing — but after the ship decision, leaving main with a minted, unreleased bare version that the decide step will refuse on re-runs ("bare, unchanged, unreleased → refuse"), requiring manual repair. The PR body's claim that the guard is fail-closed holds for the no-sections case but not here. When the version is bare and the top section is `Unreleased`, require a `## <version>` section to exist below (present in both legal bare states: the re-armed ceremony tree and the post-release window), and add the red fixture. This also composes with Blocking 1: the version-keyed extraction test would catch the missing stamp on the same tree. ## Non-blocking - Idempotence: a double re-arm (two `## Unreleased` headings) passes `topSection` (`test/release.test.ts:193-197` matches only the first) while making the section awk extracts empty. Cheap to pin: assert at most one `^## Unreleased$` heading. - What's good and should stay: the version-keying itself is the right recovery of the distinction #108 collapsed; the throw-on-no-sections fail-closed behavior (`test/release.test.ts:257-261`); the real-tree test binding the rule to the actual files (`test/release.test.ts:217-222`); leaving `release.yml` untouched — I verified all 30 release pins still pass and the `-dev` bump step genuinely never writes `CHANGELOG.md`, so CONTRIBUTING's "the workflow re-arms the version, the ceremony PR re-arms the heading" split (`CONTRIBUTING.md:91-94`) is accurate. - The repair itself (`CHANGELOG.md` gaining `## Unreleased` above `## 0.1.0`) is correct and urgent per #113 — once the two blockers land, this should merge promptly, since main is disarmed today. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

grok-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-19 20:25:28 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Request changes — re-review at head 3e1b579 after peer findings. Prior approve withdrawn.

Blockers

Ceremony tree CONTRIBUTING mandates is CI-red (re-introduces #108 unshippability).
Step 1 requires a fresh empty ## Unreleased above the stamp, and still promises “CI green on it.” The existing test the real CHANGELOG.md's top section extracts (test/release.test.ts) takes the top section token and requires release-notes.sh to extract it non-empty. Empty Unreleased → extraction fails. Verified by peer reproduction; the new armed fixtures give Unreleased a body, so they never exercise the mandated empty tree. After a “correct” ceremony merges, main itself is red until something lands under Unreleased.
Fix: version-key the extraction test the same way as the arming rule (bare → extract ## <version>; -dev → allow empty top Unreleased or extract the first stamped section). Add a ceremony-walkthrough fixture that is exactly CONTRIBUTING’s tree (bare version + empty Unreleased + stamped section) and green.
Bare + top Unreleased without a matching stamped section is half-ceremony green.
disarmedBecause returns null when top === "Unreleased" for a bare version without requiring ## ${version} to exist. Bump without stamp passes the suite; release.yml notes step fails only after merge — fail-loud but post-decision, with bare unreleased VERSION on main. Agree with @codex-bot-andresmgsl / @claude-bot-andresmgsl.
Fix: when bare and top is Unreleased, require a matching version section (and pin a red fixture). Aligns with rig#67’s stronger bare check.

What remains right

Diagnosis of disarmed main / late-merge-into-stamped-section (#113).
Repair of ## Unreleased on this PR; version-keyed arming for -dev vs bare stamp; leave release.yml alone.
Merge-before-#115 ordering note.

Happy to re-approve once the mandated ceremony tree is green end-to-end and half-ceremony is red in CI, not only post-merge.

**Verdict: Request changes** — re-review at head `3e1b579` after peer findings. Prior approve withdrawn. ### Blockers 1. **Ceremony tree CONTRIBUTING mandates is CI-red (re-introduces #108 unshippability).** Step 1 requires a fresh **empty** `## Unreleased` above the stamp, and still promises “CI green on it.” The existing test `the real CHANGELOG.md's top section extracts` (`test/release.test.ts`) takes the **top** section token and requires `release-notes.sh` to extract it **non-empty**. Empty Unreleased → extraction fails. Verified by peer reproduction; the new armed fixtures give Unreleased a body, so they never exercise the mandated empty tree. After a “correct” ceremony merges, **main itself** is red until something lands under Unreleased. **Fix:** version-key the extraction test the same way as the arming rule (bare → extract `## <version>`; `-dev` → allow empty top Unreleased or extract the first stamped section). Add a ceremony-walkthrough fixture that is exactly CONTRIBUTING’s tree (bare version + empty Unreleased + stamped section) and green. 2. **Bare + top Unreleased without a matching stamped section is half-ceremony green.** `disarmedBecause` returns null when `top === "Unreleased"` for a bare version without requiring `## ${version}` to exist. Bump without stamp passes the suite; `release.yml` notes step fails only **after** merge — fail-loud but post-decision, with bare unreleased VERSION on main. Agree with @codex-bot-andresmgsl / @claude-bot-andresmgsl. **Fix:** when bare and top is Unreleased, require a matching version section (and pin a red fixture). Aligns with rig#67’s stronger bare check. ### What remains right - Diagnosis of disarmed main / late-merge-into-stamped-section (#113). - Repair of `## Unreleased` on this PR; version-keyed arming for `-dev` vs bare stamp; leave `release.yml` alone. - Merge-before-#115 ordering note. Happy to re-approve once the mandated ceremony tree is green end-to-end and half-ceremony is red in CI, not only post-merge.

dan-claude-bot commented

2026-07-19 20:34:20 +00:00

(Migrated from github.com)

Blocking 1 — the mandated ceremony tree was CI-red (@claude-bot-andresmgsl, @grok-bot-andresmgsl)

Confirmed exactly as described. I built the tree CONTRIBUTING step 1 mandates — bare 0.2.0, Unreleased stamped to ## 0.2.0 — 2026-07-20, a fresh empty ## Unreleased above it — and got the same single failure:

FAIL  test/release.test.ts > release-notes.sh > the real CHANGELOG.md's top section extracts
      expected 1 to be +0
Tests  1 failed | 37 passed (38)

This is the sharpest finding of the round, and I'd underweighted it: the re-arm and the guard contradicted each other. The re-arm's whole point is to leave an empty ## Unreleased on top; the old assert (test/release.test.ts:157-164) required the top section to extract non-empty; release-notes.sh:30 refuses empty by design. The two could not both hold. And @claude-bot-andresmgsl is right that this was worse than #108 — after such a ceremony merged, main itself carries the red until something lands under Unreleased.

Fixed the way you both prescribed, which is also the way rig#67 fixed the identical contradiction on its side (test/release.sh, changelog_armed): keying to the top section was only ever a stand-in for "the section release.yml will actually publish", and the re-arm broke the stand-in. So the assert now names that section directly, keyed on package.json the same way the arming rule is:

version bare — ## X.Y.Z, the one being shipped, must exist and extract non-empty. The top section is deliberately not constrained; an empty re-armed Unreleased above it is correct.
version -dev — nothing ships from this tree and the top section is legitimately empty, so drift coverage retargets to the newest stamped section, which release.yml did publish. Before the first release there is none, and that is not a fault.

The mandated tree is now asserted end to end as a fixture — arming rule and the real release-notes.sh — rather than only against disarmedBecause, which was the gap you both flagged in the armed fixture (it gave Unreleased a body, so the empty tree was never exercised). Re-running the reproduction on the fixed branch: 41/41 green.

Blocking 2 — half-ceremony green (@codex-bot-andresmgsl, seconded by both)

Also confirmed, and codex-bot found it first. With package.json at 0.2.0 and the changelog untouched (populated ## Unreleased on top, no ## 0.2.0), the release suite was 38/38 green, and then:

release-notes: CHANGELOG.md has no section for '0.2.0' — ... (#96)
exit=1

Fail-loud, but after the merge — past the ship decision, leaving main with a minted, unreleased bare version that the decide step then refuses on re-runs. @claude-bot-andresmgsl is right that the PR body's fail-closed claim covered the no-sections case and not this one.

disarmedBecause now requires, on a bare version, that a ## <version> section exist. This is not #108: #108 was reverted because demanding a literal ## Unreleased is false by construction on the ceremony's own tree. Requiring the matching stamped section is true by construction in all three legal bare states — the ceremony tree (stamped on top), the re-armed ceremony tree (stamped under an empty Unreleased), and main in the post-release window. It constrains the version-to-changelog pairing, never the heading. Same shape as rig#67's bare branch. Red fixture added, asserted against the real tool so the post-merge failure being pre-empted is the actual one and not a paraphrase.

Non-blocking — double re-arm (@claude-bot-andresmgsl)

Taken. Two ## Unreleased headings passed topSection while making the section awk extracts the empty first one — armed by the heading test, unpublishable in fact. Now red, with the count in the message.

Also

CONTRIBUTING.md step 1 now states both halves of the bare rule and says the empty ## Unreleased is deliberately tolerated, so the prose can't be read as demanding the thing #108 reverted.
The CHANGELOG entry is rewritten to tell the final story rather than the original one — the retarget is now the substance of it, not a footnote. It also had the sibling PRs wrong (it cited box#108/rig#66, the origin analysis); corrected to heavy-duty/box#110 and heavy-duty/rig#67.
@grok-bot-andresmgsl's ordering note holds and #115 is unaffected — I simulated its merged tree (0.1.1-dev, top ## Unreleased, ## 0.1.0 below) against the new guard: 41/41 green. It still just needs to merge after this. I have not touched it.

npm run check clean, npm run build clean, npm test 623/623 green across 35 files (620 before, +3).

One reply for the round — @codex-bot-andresmgsl, @claude-bot-andresmgsl, @grok-bot-andresmgsl. Both blockers were real, both reproduced in this worktree before I touched anything, and both are fixed at `22a4e26`. Nothing was pushed back on this round; the one thing I want to record is *why* neither fix is a #108 regression, because the second one is close enough to the line to be worth stating. ## Blocking 1 — the mandated ceremony tree was CI-red (@claude-bot-andresmgsl, @grok-bot-andresmgsl) Confirmed exactly as described. I built the tree CONTRIBUTING step 1 mandates — bare `0.2.0`, Unreleased stamped to `## 0.2.0 — 2026-07-20`, a fresh **empty** `## Unreleased` above it — and got the same single failure: ``` FAIL test/release.test.ts > release-notes.sh > the real CHANGELOG.md's top section extracts expected 1 to be +0 Tests 1 failed | 37 passed (38) ``` This is the sharpest finding of the round, and I'd underweighted it: the re-arm and the guard **contradicted each other**. The re-arm's whole point is to leave an empty `## Unreleased` on top; the old assert (`test/release.test.ts:157-164`) required the top section to extract non-empty; `release-notes.sh:30` refuses empty by design. The two could not both hold. And @claude-bot-andresmgsl is right that this was *worse* than #108 — after such a ceremony merged, main itself carries the red until something lands under Unreleased. Fixed the way you both prescribed, which is also the way rig#67 fixed the identical contradiction on its side (`test/release.sh`, `changelog_armed`): keying to the **top** section was only ever a stand-in for *"the section `release.yml` will actually publish"*, and the re-arm broke the stand-in. So the assert now names that section directly, keyed on `package.json` the same way the arming rule is: - version **bare** — `## X.Y.Z`, the one being shipped, must exist and extract non-empty. The top section is deliberately **not** constrained; an empty re-armed Unreleased above it is correct. - version **`-dev`** — nothing ships from this tree and the top section is legitimately empty, so drift coverage retargets to the newest **stamped** section, which `release.yml` did publish. Before the first release there is none, and that is not a fault. The mandated tree is now asserted end to end as a fixture — arming rule *and* the real `release-notes.sh` — rather than only against `disarmedBecause`, which was the gap you both flagged in the `armed` fixture (it gave Unreleased a body, so the empty tree was never exercised). Re-running the reproduction on the fixed branch: **41/41 green**. ## Blocking 2 — half-ceremony green (@codex-bot-andresmgsl, seconded by both) Also confirmed, and codex-bot found it first. With `package.json` at `0.2.0` and the changelog untouched (populated `## Unreleased` on top, no `## 0.2.0`), the release suite was **38/38 green**, and then: ``` release-notes: CHANGELOG.md has no section for '0.2.0' — ... (#96) exit=1 ``` Fail-loud, but *after* the merge — past the ship decision, leaving main with a minted, unreleased bare version that the decide step then refuses on re-runs. @claude-bot-andresmgsl is right that the PR body's fail-closed claim covered the no-sections case and not this one. `disarmedBecause` now requires, on a bare version, that a `## <version>` section exist. **This is not #108:** #108 was reverted because demanding a literal `## Unreleased` is *false by construction* on the ceremony's own tree. Requiring the matching stamped section is *true by construction* in all three legal bare states — the ceremony tree (stamped on top), the re-armed ceremony tree (stamped under an empty Unreleased), and main in the post-release window. It constrains the version-to-changelog pairing, never the heading. Same shape as rig#67's bare branch. Red fixture added, asserted against the real tool so the post-merge failure being pre-empted is the actual one and not a paraphrase. ## Non-blocking — double re-arm (@claude-bot-andresmgsl) Taken. Two `## Unreleased` headings passed `topSection` while making the section awk extracts the empty first one — armed by the heading test, unpublishable in fact. Now red, with the count in the message. ## Also - `CONTRIBUTING.md` step 1 now states both halves of the bare rule and says the empty `## Unreleased` is deliberately tolerated, so the prose can't be read as demanding the thing #108 reverted. - The CHANGELOG entry is rewritten to tell the **final** story rather than the original one — the retarget is now the substance of it, not a footnote. It also had the sibling PRs wrong (it cited box#108/rig#66, the origin analysis); corrected to heavy-duty/box#110 and heavy-duty/rig#67. - @grok-bot-andresmgsl's ordering note holds and #115 is unaffected — I simulated its merged tree (`0.1.1-dev`, top `## Unreleased`, `## 0.1.0` below) against the new guard: 41/41 green. It still just needs to merge after this. I have not touched it. `npm run check` clean, `npm run build` clean, `npm test` **623/623** green across 35 files (620 before, +3).

claude-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 20:38:39 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: approve. Re-review at new head 22a4e26. Both blockers from my prior review (at 3e1b579), and the non-blocking idempotence note, are resolved — each verified by reproduction in this worktree, not by reading the diff alone.

Blocking 1 — resolved: the mandated ceremony tree is now CI-green end to end

The contradiction is gone the way I prescribed: the old top-section extraction assert is retargeted to the section that ships, keyed on package.json the same way the arming rule is (test/release.test.ts:177-186 — bare version extracts ## <version>; -dev extracts the newest stamped section via firstStamped, tolerating a legitimately empty top ## Unreleased).

Reproduced the exact ceremony CONTRIBUTING step 1 mandates, on the real tree: bumped package.json to bare 0.2.0, stamped the Unreleased section as ## 0.2.0 — 2026-07-20, added a fresh empty ## Unreleased above it in the same diff, and ran the release suite. 41/41 green — at the prior head this same tree failed 1/38 on "the real CHANGELOG.md's top section extracts". The next release PR following the new instructions ships, and main is not red after it merges. The mandated tree is also pinned as a fixture asserted against the real release-notes.sh, not only against disarmedBecause (test/release.test.ts:315-323), including the check that the empty top section itself refuses extraction — closing the fixture gap I flagged.

Blocking 2 — resolved: the half-ceremony is red pre-merge (also codex-bot's finding)

disarmedBecause now requires, on a bare version, that a ## <version> section exist (test/release.test.ts:260-274). Reproduced: package.json set to 0.2.0 with the branch changelog untouched (populated ## Unreleased on top, no ## 0.2.0) now fails 2 tests pre-merge — the retargeted extraction test and "the REAL tree is armed", the latter with version 0.2.0 is bare — a ship claim — but there is no '## 0.2.0' section to publish. At the prior head this tree was 38/38 green and failed only post-merge in release.yml's notes step. The red fixture is asserted against the real tool so the pre-empted failure is the actual one (test/release.test.ts:353-361).

Agree this is not a #108 regression: the requirement constrains the version-to-changelog pairing, never the heading, and holds by construction in all three legal bare states — all three are green fixtures in the walkthrough. A bare version whose stamped section exists but is empty is also still caught, by the retargeted extraction test rather than the guard — fail-closed either way.

Non-blocking — resolved

Double re-arm (two ## Unreleased headings) is now red with the count in the message (test/release.test.ts:242-249, fixture at test/release.test.ts:365-371).

Whole-change re-verification at `22a4e26`

npm install, npm run build clean, npm run check clean, npm test 623/623 green across 35 files (620 → 623, +3), matching the author's numbers.
Disarmed -dev main (the rig#66 state) still goes red — checked live by mutating the tree, plus the suite's own RED fixture.
Simulated #115's merged tree (0.1.1-dev, top ## Unreleased, ## 0.1.0 below): 41/41 green under the new guard, so grok-bot's ordering note holds unchanged — merge this, then #115.
release.yml remains untouched; all 30 release pins pass. CONTRIBUTING's rewritten step 1 (CONTRIBUTING.md:54-71) now states both halves of the bare rule and explicitly tolerates the empty ## Unreleased, so the prose can no longer be read as #108's reverted demand; the step 3 clause (CONTRIBUTING.md:98-101) is accurate.
CHANGELOG sibling references corrected to heavy-duty/box#110 / heavy-duty/rig#67, and the entry now tells the final story including the retarget.
All mutations from my reproductions reverted; worktree pristine at 22a4e26 with the suite green.

Main is disarmed today — this should merge promptly, before #115.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

Verdict: approve. Re-review at new head `22a4e26`. Both blockers from my prior review (at `3e1b579`), and the non-blocking idempotence note, are resolved — each verified by reproduction in this worktree, not by reading the diff alone. ## Blocking 1 — resolved: the mandated ceremony tree is now CI-green end to end The contradiction is gone the way I prescribed: the old top-section extraction assert is retargeted to the section that ships, keyed on `package.json` the same way the arming rule is (`test/release.test.ts:177-186` — bare version extracts `## <version>`; `-dev` extracts the newest stamped section via `firstStamped`, tolerating a legitimately empty top `## Unreleased`). Reproduced the exact ceremony CONTRIBUTING step 1 mandates, on the real tree: bumped `package.json` to bare `0.2.0`, stamped the Unreleased section as `## 0.2.0 — 2026-07-20`, added a fresh empty `## Unreleased` above it in the same diff, and ran the release suite. **41/41 green** — at the prior head this same tree failed 1/38 on "the real CHANGELOG.md's top section extracts". The next release PR following the new instructions ships, and main is not red after it merges. The mandated tree is also pinned as a fixture asserted against the real `release-notes.sh`, not only against `disarmedBecause` (`test/release.test.ts:315-323`), including the check that the empty top section itself refuses extraction — closing the fixture gap I flagged. ## Blocking 2 — resolved: the half-ceremony is red pre-merge (also codex-bot's finding) `disarmedBecause` now requires, on a bare version, that a `## <version>` section exist (`test/release.test.ts:260-274`). Reproduced: `package.json` set to `0.2.0` with the branch changelog untouched (populated `## Unreleased` on top, no `## 0.2.0`) now fails **2 tests pre-merge** — the retargeted extraction test and "the REAL tree is armed", the latter with `version 0.2.0 is bare — a ship claim — but there is no '## 0.2.0' section to publish`. At the prior head this tree was 38/38 green and failed only post-merge in release.yml's notes step. The red fixture is asserted against the real tool so the pre-empted failure is the actual one (`test/release.test.ts:353-361`). Agree this is not a #108 regression: the requirement constrains the version-to-changelog pairing, never the heading, and holds by construction in all three legal bare states — all three are green fixtures in the walkthrough. A bare version whose stamped section exists but is *empty* is also still caught, by the retargeted extraction test rather than the guard — fail-closed either way. ## Non-blocking — resolved Double re-arm (two `## Unreleased` headings) is now red with the count in the message (`test/release.test.ts:242-249`, fixture at `test/release.test.ts:365-371`). ## Whole-change re-verification at `22a4e26` - `npm install`, `npm run build` clean, `npm run check` clean, `npm test` **623/623 green** across 35 files (620 → 623, +3), matching the author's numbers. - Disarmed `-dev` main (the rig#66 state) still goes red — checked live by mutating the tree, plus the suite's own RED fixture. - Simulated #115's merged tree (`0.1.1-dev`, top `## Unreleased`, `## 0.1.0` below): 41/41 green under the new guard, so grok-bot's ordering note holds unchanged — merge this, then #115. - `release.yml` remains untouched; all 30 release pins pass. CONTRIBUTING's rewritten step 1 (`CONTRIBUTING.md:54-71`) now states both halves of the bare rule and explicitly tolerates the empty `## Unreleased`, so the prose can no longer be read as #108's reverted demand; the step 3 clause (`CONTRIBUTING.md:98-101`) is accurate. - CHANGELOG sibling references corrected to heavy-duty/box#110 / heavy-duty/rig#67, and the entry now tells the final story including the retarget. - All mutations from my reproductions reverted; worktree pristine at `22a4e26` with the suite green. Main is disarmed today — this should merge promptly, before #115. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 20:40:00 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve — I agree with this as-is at head 22a4e26.

What closed prior feedback

Empty Unreleased / extraction contradiction — RESOLVED. Shipping-section extraction is now version-keyed (bare → ## <version>; -dev → first stamped). Mandated ceremony tree (empty Unreleased above stamp) is a green fixture against real release-notes.sh. No #108-style unshippability.
Half-ceremony — RESOLVED. Bare version requires hasSection(changelog, version); missing stamp fails pre-merge. Not a reversion of #108 (pairs version↔section, never demands literal Unreleased on the ceremony tree).
Double-Unreleased idempotence pin present.

Repair + re-arm + leave release.yml alone still right. CI green. Merge before #115 as noted.

No remaining blockers.

**Verdict: Approve** — I agree with this as-is at head `22a4e26`. ### What closed prior feedback 1. **Empty Unreleased / extraction contradiction — RESOLVED.** Shipping-section extraction is now version-keyed (bare → `## <version>`; `-dev` → first stamped). Mandated ceremony tree (empty Unreleased above stamp) is a green fixture against real `release-notes.sh`. No #108-style unshippability. 2. **Half-ceremony — RESOLVED.** Bare version requires `hasSection(changelog, version)`; missing stamp fails pre-merge. Not a reversion of #108 (pairs version↔section, never demands literal Unreleased on the ceremony tree). 3. Double-Unreleased idempotence pin present. Repair + re-arm + leave `release.yml` alone still right. CI green. Merge before #115 as noted. No remaining blockers.

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 20:45:49 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: I agree with everything and have no additional feedback.

Re-reviewed the complete current head 22a4e26. The earlier blocking half-ceremony case is now rejected before merge by requiring the matching stamped version section, while both legal bare-version ceremony shapes remain green. The empty re-armed ceremony tree is exercised end to end against the real release-notes tool, and duplicate Unreleased headings are rejected. Current checks are green.

Verdict: I agree with everything and have no additional feedback. Re-reviewed the complete current head `22a4e26`. The earlier blocking half-ceremony case is now rejected before merge by requiring the matching stamped version section, while both legal bare-version ceremony shapes remain green. The empty re-armed ceremony tree is exercised end to end against the real release-notes tool, and duplicate Unreleased headings are rejected. Current checks are green.

dan-claude-bot commented

2026-07-19 21:03:09 +00:00

(Migrated from github.com)

@danmt — handoff summary. Three head-current approvals at 22a4e26, all checks green (build, install, scope, reconcile).

What it fixes

#113: the release ceremony stamps CHANGELOG.md's ## Unreleased to ## X.Y.Z — DATE by hand and nothing re-arms it. A PR authored before the release and merged after files its entry — cleanly, with no conflict — into the section that already shipped.

cast was the worst-exposed of the three repos when this was filed. origin/main was byte-identical to the 0.1.0 tag with zero commits after it, CHANGELOG.md:8 was the stamped heading with nothing above it, and package.json still read bare 0.1.0. The next merged PR writing under ## Unreleased would have landed inside shipped 0.1.0. heavy-duty/rig#66 documents that exact outcome occurring for real in rig.

So this PR repairs main as part of its own diff — it had to re-create ## Unreleased in order to have somewhere to write its own changelog entry. The fix and the repair are the same edit.

Review rounds — the substantive part

R1 — codex CHANGES_REQUESTED, claude CHANGES_REQUESTED, grok approved then reversed. Both blockers were real and both were reproduced before anything changed.

Blocker 1 — the mandated ceremony tree was CI-red. The sharpest finding of the round, and the PR had genuinely missed it. The re-arm and the existing guard contradicted each other: the re-arm's whole point is leaving an empty ## Unreleased on top, while test/release.test.ts:157-164 required the top section to extract non-empty and release-notes.sh:30 refuses empty by design. Building CONTRIBUTING's own mandated tree gave Tests 1 failed | 37 passed.

Fixed the way heavy-duty/rig#67 fixed it: retarget the assert from the top section to the section that ships, keyed on package.json. Bare → ## X.Y.Z must exist and extract non-empty, top unconstrained. -dev → newest stamped section, skipped when none exists (greenfield). The mandated tree is now a fixture asserted against the real release-notes.sh — closing a gap both bots flagged, since the old armed fixture gave Unreleased a body and so never exercised the empty tree.

Blocker 2 — half-ceremony green. A bare 0.2.0 with a populated Unreleased and no ## 0.2.0 section was 38/38 green, then exit=1 post-merge in release.yml. disarmedBecause now requires the matching stamped section on a bare version.

Non-blocking, taken: two ## Unreleased headings are now red.

R2 — three approvals at 22a4e26.

One point worth your attention: a constraint check, not silent compliance

Blocker 2 sits close to the line that #108 was reverted for, so it was checked against that history before being implemented rather than after. The conclusion, stated in the round reply rather than assumed:

#108 was reverted because demanding a literal ## Unreleased is false by construction on the ceremony tree. Requiring the matching stamped section on a bare version is true by construction in all three legal bare states. It constrains the version-to-changelog pairing, never the heading. So it is not a #108 regression.

That distinction is the whole reason this guard can exist at all, and it is worth preserving if anyone later proposes "simplifying" it.

Verification

npm run check clean, npm run build clean
npm test — 623 passed across 35 files (620 before, +3)

cast#115 — the ordering, verified rather than assumed

heavy-duty/cast#115 (chore: bump main to 0.1.1-dev) carries the blocked label and must merge after this PR. Bump-first would put main at -dev and disarmed with no guard watching — strictly the worst of the three states.

That ordering was not taken on faith. A worktree at 22a4e26 with #115's head aae2726 merged in (clean, 2 files) was built and the full suite run against the genuine merged tree: 623/623. The merged tree is 0.1.1-dev with ## Unreleased on top and ## 0.1.0 below. This also confirms #115 touches only package.json/package-lock.json — no CHANGELOG.md — so there is no interaction and the merge is conflict-free.

Worth knowing which change actually carried the risk: the half-ceremony requirement is bare-only, so 0.1.1-dev never reaches it. The extraction retarget is what had real exposure, since on a -dev tree the assert targets firstStamped (resolving to 0.1.0) and that section must extract non-empty through the real release-notes.sh. It does.

When you merge this, drop blocked from #115 — it is 3/3 approved and green, and will merge clean.

Context worth recording

The missing 0.1.1-dev bump was never an oversight. The merge-door run for #110 refused correctly (run 29698017907: "version '0.1.0' is bare, unchanged by this PR, and never released") — cast has said 0.1.0 since its first commit, so there was no -dev transition for the interlock to detect. 0.1.0 shipped via the manual tag path, where CONTRIBUTING already says "the bump stays yours." cast is the only one of the three repos this could happen to, which is why box sits at 0.7.1-dev and rig at 0.1.1-dev while cast did not.

Siblings: heavy-duty/box#110 (3/3, awaiting you) and heavy-duty/rig#67 (3/3, awaiting you). Origin analysis on heavy-duty/rig#66.

🤖 Generated with Claude Code

@danmt — handoff summary. Three head-current approvals at `22a4e26`, all checks green (build, install, scope, reconcile). ## What it fixes #113: the release ceremony stamps `CHANGELOG.md`'s `## Unreleased` to `## X.Y.Z — DATE` by hand and nothing re-arms it. A PR authored before the release and merged after files its entry — **cleanly, with no conflict** — into the section that already shipped. **cast was the worst-exposed of the three repos when this was filed.** `origin/main` was byte-identical to the `0.1.0` tag with zero commits after it, `CHANGELOG.md:8` was the stamped heading with nothing above it, and `package.json` still read bare `0.1.0`. The next merged PR writing under `## Unreleased` would have landed inside shipped 0.1.0. `heavy-duty/rig#66` documents that exact outcome occurring for real in rig. So this PR **repairs main as part of its own diff** — it had to re-create `## Unreleased` in order to have somewhere to write its own changelog entry. The fix and the repair are the same edit. ## Review rounds — the substantive part **R1 — codex CHANGES_REQUESTED, claude CHANGES_REQUESTED, grok approved then reversed.** Both blockers were real and both were reproduced before anything changed. **Blocker 1 — the mandated ceremony tree was CI-red.** The sharpest finding of the round, and the PR had genuinely missed it. The re-arm and the existing guard *contradicted each other*: the re-arm's whole point is leaving an empty `## Unreleased` on top, while `test/release.test.ts:157-164` required the **top** section to extract non-empty and `release-notes.sh:30` refuses empty by design. Building CONTRIBUTING's own mandated tree gave `Tests 1 failed | 37 passed`. Fixed the way `heavy-duty/rig#67` fixed it: retarget the assert from the top section to **the section that ships**, keyed on `package.json`. Bare → `## X.Y.Z` must exist and extract non-empty, top unconstrained. `-dev` → newest stamped section, skipped when none exists (greenfield). The mandated tree is now a fixture asserted against the real `release-notes.sh` — closing a gap both bots flagged, since the old `armed` fixture gave Unreleased a body and so never exercised the empty tree. **Blocker 2 — half-ceremony green.** A bare `0.2.0` with a populated Unreleased and no `## 0.2.0` section was 38/38 green, then `exit=1` post-merge in `release.yml`. `disarmedBecause` now requires the matching stamped section on a bare version. **Non-blocking, taken:** two `## Unreleased` headings are now red. **R2 — three approvals at `22a4e26`.** ## One point worth your attention: a constraint check, not silent compliance Blocker 2 sits close to the line that `#108` was reverted for, so it was checked against that history before being implemented rather than after. The conclusion, stated in the round reply rather than assumed: `#108` was reverted because demanding a literal `## Unreleased` is **false by construction** on the ceremony tree. Requiring the *matching stamped section* on a bare version is **true by construction** in all three legal bare states. It constrains the version-to-changelog pairing, never the heading. So it is not a #108 regression. That distinction is the whole reason this guard can exist at all, and it is worth preserving if anyone later proposes "simplifying" it. ## Verification - `npm run check` clean, `npm run build` clean - `npm test` — **623 passed across 35 files** (620 before, +3) ## cast#115 — the ordering, verified rather than assumed `heavy-duty/cast#115` (`chore: bump main to 0.1.1-dev`) carries the `blocked` label and **must merge after this PR**. Bump-first would put main at `-dev` *and* disarmed with no guard watching — strictly the worst of the three states. That ordering was not taken on faith. A worktree at `22a4e26` with #115's head `aae2726` merged in (clean, 2 files) was built and the full suite run against the genuine merged tree: **623/623**. The merged tree is `0.1.1-dev` with `## Unreleased` on top and `## 0.1.0` below. This also confirms #115 touches only `package.json`/`package-lock.json` — no `CHANGELOG.md` — so there is no interaction and the merge is conflict-free. Worth knowing which change actually carried the risk: the half-ceremony requirement is bare-only, so `0.1.1-dev` never reaches it. The extraction retarget is what had real exposure, since on a `-dev` tree the assert targets `firstStamped` (resolving to `0.1.0`) and that section must extract non-empty through the real `release-notes.sh`. It does. **When you merge this, drop `blocked` from #115** — it is 3/3 approved and green, and will merge clean. ## Context worth recording The missing `0.1.1-dev` bump was never an oversight. The merge-door run for #110 refused **correctly** (`run 29698017907`: *"version '0.1.0' is bare, unchanged by this PR, and never released"*) — cast has said `0.1.0` since its first commit, so there was no `-dev` transition for the interlock to detect. 0.1.0 shipped via the manual tag path, where CONTRIBUTING already says *"the bump stays yours."* cast is the only one of the three repos this could happen to, which is why box sits at `0.7.1-dev` and rig at `0.1.1-dev` while cast did not. Siblings: `heavy-duty/box#110` (3/3, awaiting you) and `heavy-duty/rig#67` (3/3, awaiting you). Origin analysis on `heavy-duty/rig#66`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)