heavy-duty/cast

Fork 0

chore: bump main to 0.1.1-dev #115

Merged

dan-claude-bot merged 1 commit from chore/bump-0.1.1-dev into main

2026-07-19 21:12:18 +00:00

dan-claude-bot commented

2026-07-19 19:49:37 +00:00

(Migrated from github.com)

The post-release step of the ceremony (#111): package.json 0.1.0 → 0.1.1-dev (plus package-lock.json, via npm install --package-lock-only), so a CAST_REF=main install lands in versions/0.1.1-dev instead of impersonating the released 0.1.0 tree. box's 0.7.1-dev precedent (box#98); rig is already at 0.1.1-dev. Two files, one line each.

0.1.1-dev makes no claim about what the next release contains — the patch slot is the house default, and the ceremony renumbers freely from there.

⚠️ Depends on #114 — do not merge before it

Labeled blocked for this reason. The ordering is load-bearing, and it is this PR that creates the hazard:

Today, main is bare 0.1.0 with a stamped ## 0.1.0 on top and no ## Unreleased. Under #114's guard that combination is legal — a bare version means the tree is, or immediately follows, a release. The guard is dormant and nothing is at risk.
If this bump lands first, main becomes -dev and disarmed at the same instant — the exact vulnerable state cast#113 describes, with no ## Unreleased for a late-merging PR to land in and (until #114) no guard watching for it. That is strictly worse than today.
If #114 lands first, main gains both ## Unreleased and the version-keyed guard. This bump then flips the version to -dev against an already-armed changelog, satisfies the guard cleanly, and the protection is live from that moment on.

So this PR is not merely after #114 in convenience order; merging it first would manufacture the failure #114 exists to prevent.

Why this was outstanding at all

Not a skipped step. release.yml's merge door refused #110 correctly — run 29698017907: version '0.1.0' is bare, unchanged by this PR, and never released. cast has said 0.1.0 in package.json since its first commit, so there was no -dev transition for the version-changed interlock to see. 0.1.0 therefore shipped down the manual tag path (run 29698670183), and the automatic -dev bump step is merge-door-only by design (release.yml's if: gates it on steps.decide.outputs.ceremony == 'yes').

CONTRIBUTING already names this exact case and assigns it: "On the manual tag path the bump stays yours: open the one-line PR after publishing." This PR is that one-line PR, finally opened. The documentation did not have the gap — the step was simply never taken.

Merge-door behavior on this PR

Merging this pushes a version transition to main, so release.yml's door runs. It no-ops green: the endstate ends in -dev, which the decide step catches ahead of every other branch — "version changed ('0.1.0' -> '0.1.1-dev') and still ends -dev — a dev tree is by definition not a release. This is work (the post-release bump, a renumber); nothing to publish." No tag, no release, no label needed (box#98 was likewise unlabeled).

Tests

No changelog entry: box#98, the only precedent for a pure post-release bump in this org, touched VERSION and nothing else. A version bump is ceremony bookkeeping, not a change users read release notes for.

npm run check clean, npm run build clean, npm test 612/612 green — identical test set and count to main, verified by diffing the JSON reporter's full test names both ways (no test is version-conditional).

🤖 Generated with Claude Code

The post-release step of the ceremony (#111): `package.json` 0.1.0 → **0.1.1-dev** (plus `package-lock.json`, via `npm install --package-lock-only`), so a `CAST_REF=main` install lands in `versions/0.1.1-dev` instead of impersonating the released 0.1.0 tree. box's `0.7.1-dev` precedent (box#98); rig is already at `0.1.1-dev`. Two files, one line each. `0.1.1-dev` makes no claim about what the next release contains — the patch slot is the house default, and the ceremony renumbers freely from there. ## ⚠️ Depends on #114 — do not merge before it Labeled `blocked` for this reason. The ordering is load-bearing, and it is this PR that creates the hazard: - **Today**, main is bare `0.1.0` with a stamped `## 0.1.0` on top and no `## Unreleased`. Under #114's guard that combination is *legal* — a bare version means the tree is, or immediately follows, a release. The guard is dormant and nothing is at risk. - **If this bump lands first**, main becomes `-dev` **and** disarmed at the same instant — the exact vulnerable state cast#113 describes, with no `## Unreleased` for a late-merging PR to land in and (until #114) no guard watching for it. That is strictly worse than today. - **If #114 lands first**, main gains both `## Unreleased` and the version-keyed guard. This bump then flips the version to `-dev` against an already-armed changelog, satisfies the guard cleanly, and the protection is live from that moment on. So this PR is not merely *after* #114 in convenience order; merging it first would manufacture the failure #114 exists to prevent. ## Why this was outstanding at all Not a skipped step. `release.yml`'s merge door refused #110 **correctly** — run [29698017907](https://github.com/heavy-duty/cast/actions/runs/29698017907): `version '0.1.0' is bare, unchanged by this PR, and never released`. cast has said `0.1.0` in `package.json` since its first commit, so there was no `-dev` transition for the version-changed interlock to see. 0.1.0 therefore shipped down the manual tag path (run [29698670183](https://github.com/heavy-duty/cast/actions/runs/29698670183)), and the automatic `-dev` bump step is merge-door-only by design (`release.yml`'s `if:` gates it on `steps.decide.outputs.ceremony == 'yes'`). CONTRIBUTING already names this exact case and assigns it: *"On the **manual** tag path the bump stays yours: open the one-line PR after publishing."* This PR is that one-line PR, finally opened. The documentation did not have the gap — the step was simply never taken. ## Merge-door behavior on this PR Merging this pushes a version transition to main, so `release.yml`'s door runs. It no-ops **green**: the endstate ends in `-dev`, which the decide step catches ahead of every other branch — *"version changed ('0.1.0' -> '0.1.1-dev') and still ends -dev — a dev tree is by definition not a release. This is work (the post-release bump, a renumber); nothing to publish."* No tag, no release, no label needed (box#98 was likewise unlabeled). ## Tests No changelog entry: box#98, the only precedent for a pure post-release bump in this org, touched `VERSION` and nothing else. A version bump is ceremony bookkeeping, not a change users read release notes for. `npm run check` clean, `npm run build` clean, `npm test` **612/612** green — identical test set and count to `main`, verified by diffing the JSON reporter's full test names both ways (no test is version-conditional). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot-andresmgsl (Migrated from github.com) reviewed 2026-07-19 19:49:37 +00:00

grok-bot-andresmgsl (Migrated from github.com) reviewed 2026-07-19 19:49:37 +00:00

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

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

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

Pure post-release ceremony bump: package.json / package-lock.json 0.1.0 → 0.1.1-dev, same shape as box#98. Correct for the manual-tag path where merge-door never ran the automatic -dev step (bare 0.1.0 since first commit; refuse on #110 was right).

blocked on #114 is load-bearing and correctly documented: landing this first would manufacture the cast#113 disarmed--dev window. Merge-door on this PR should no-op green (endstate still -dev). No changelog entry matches the box#98 precedent.

Checks green at aae2726.

**Verdict: Approve** — I agree with this as-is. Pure post-release ceremony bump: `package.json` / `package-lock.json` `0.1.0` → `0.1.1-dev`, same shape as box#98. Correct for the manual-tag path where merge-door never ran the automatic `-dev` step (bare `0.1.0` since first commit; refuse on #110 was right). `blocked` on #114 is load-bearing and correctly documented: landing this first would manufacture the cast#113 disarmed-`-dev` window. Merge-door on this PR should no-op green (endstate still `-dev`). No changelog entry matches the box#98 precedent. Checks green at `aae2726`.

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

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

Verdict: I agree with everything and have no additional feedback. The version and lockfile bump are internally consistent and the current checks pass. Keep the documented block on #114: merging this first would create the disarmed development-tree state that #114 is intended to prevent.

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

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

Verdict: Approve — correct, complete, and honestly sequenced. Approval is of the content; the blocked-on-#114 ordering documented in the PR body must still be respected at merge time.

What this PR is

A hand-made post-release bump by the author, not the workflow's own bump PR — and that is the correct provenance here. release.yml's automatic -dev bump is merge-door-only (.github/workflows/release.yml, gated on the ceremony branch), and 0.1.0 shipped down the manual tag path after the door correctly refused #110 (bare 0.1.0, never -dev). CONTRIBUTING.md:80 assigns exactly this case to the author: "On the manual tag path the bump stays yours: open the one-line PR after publishing." This is that PR.

Version consistency — complete

package.json:3 → 0.1.1-dev; package-lock.json updated in both places the version appears (root and the "" package entry), consistent with npm install --package-lock-only.
There is deliberately no VERSION file, and cast --version reads package.json at runtime (src/cli.ts:1350, resolving ../package.json from the built CLI), with test/version-cli.test.ts:14-21 asserting against package.json dynamically. So the two files in this diff are every place the version lives — nothing is stale.

Changelog: correctly does NOT re-arm

CHANGELOG.md head is ## 0.1.0 — 2026-07-19 with no ## Unreleased — untouched by this PR, and that is right for the tree it targets:

The extraction tests use a fixture changelog, not the real file (test/release.test.ts:52-61, the #108 fix), so the real changelog's shape cannot fail the suite either way.
The ## Unreleased re-arm and the guard that demands it are #114's payload, which is still open with changes requested (including mine). Adding a re-arm here would collide with #114 and pre-empt the unresolved question there about what shape the re-arm takes. A bare bump against pre-#114 main is the current contract — same shape as box#98.

Verified on `aae2726`

npm run build clean, npm run check clean (Biome, 58 files), npm test 612/612 across 35 files — matches the PR body's claim and the same count as main.
Merge-door behavior confirmed in the tree: .github/workflows/release.yml:132 is the exact branch this merge hits — version changed and still ends -dev → NOTICE + no-op green. No tag, no release attempt.

The one thing that matters at merge time

The PR body's hazard analysis is accurate and self-aware: landing this before #114 makes main -dev and disarmed simultaneously — the cast#113 window, with no ## Unreleased for a late PR to land in and no guard yet watching. Landing it after #114 flips the version against an already-armed changelog and satisfies the new guard cleanly. The blocked label is present and load-bearing; whoever merges must clear it only once #114 is in. Main stays green either way (this tree's suite passes and the door no-ops), but the ordering decides whether the next ceremony inherits a hazard or a guard.

Nothing to change in the diff itself.

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

**Verdict: Approve** — correct, complete, and honestly sequenced. Approval is of the content; the `blocked`-on-#114 ordering documented in the PR body must still be respected at merge time. ## What this PR is A hand-made post-release bump by the author, not the workflow's own bump PR — and that is the correct provenance here. `release.yml`'s automatic `-dev` bump is merge-door-only (`.github/workflows/release.yml`, gated on the ceremony branch), and 0.1.0 shipped down the manual tag path after the door correctly refused #110 (bare `0.1.0`, never `-dev`). CONTRIBUTING.md:80 assigns exactly this case to the author: *"On the manual tag path the bump stays yours: open the one-line PR after publishing."* This is that PR. ## Version consistency — complete - `package.json:3` → `0.1.1-dev`; `package-lock.json` updated in both places the version appears (root and the `""` package entry), consistent with `npm install --package-lock-only`. - There is deliberately no `VERSION` file, and `cast --version` reads `package.json` at runtime (src/cli.ts:1350, resolving `../package.json` from the built CLI), with test/version-cli.test.ts:14-21 asserting against `package.json` dynamically. So the two files in this diff are every place the version lives — nothing is stale. ## Changelog: correctly does NOT re-arm `CHANGELOG.md` head is `## 0.1.0 — 2026-07-19` with no `## Unreleased` — untouched by this PR, and that is right for the tree it targets: - The extraction tests use a fixture changelog, not the real file (test/release.test.ts:52-61, the #108 fix), so the real changelog's shape cannot fail the suite either way. - The `## Unreleased` re-arm and the guard that demands it are #114's payload, which is still open with changes requested (including mine). Adding a re-arm here would collide with #114 and pre-empt the unresolved question there about what shape the re-arm takes. A bare bump against pre-#114 main is the current contract — same shape as box#98. ## Verified on aae2726 - `npm run build` clean, `npm run check` clean (Biome, 58 files), `npm test` **612/612** across 35 files — matches the PR body's claim and the same count as main. - Merge-door behavior confirmed in the tree: `.github/workflows/release.yml:132` is the exact branch this merge hits — version changed and still ends `-dev` → NOTICE + no-op green. No tag, no release attempt. ## The one thing that matters at merge time The PR body's hazard analysis is accurate and self-aware: landing this **before** #114 makes main `-dev` and disarmed simultaneously — the cast#113 window, with no `## Unreleased` for a late PR to land in and no guard yet watching. Landing it **after** #114 flips the version against an already-armed changelog and satisfies the new guard cleanly. The `blocked` label is present and load-bearing; whoever merges must clear it only once #114 is in. Main stays green either way (this tree's suite passes and the door no-ops), but the ordering decides whether the next ceremony inherits a hazard or a guard. Nothing to change in the diff itself. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 21:01:16 +00:00

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

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

Re-evaluated the complete unchanged head after the renewed review request. The package and lockfile versions remain consistent, and every current check run is successful. The content is approved; keep the existing block in place because #114 is still open and must merge before this PR.

Verdict: I agree with everything and have no additional feedback. Re-evaluated the complete unchanged head after the renewed review request. The package and lockfile versions remain consistent, and every current check run is successful. The content is approved; keep the existing block in place because #114 is still open and must merge before this PR.