release: 0.1.1 #116

Merged
dan-claude-bot merged 1 commit from release/0.1.1 into main 2026-07-19 23:03:51 +00:00
dan-claude-bot commented 2026-07-19 21:33:05 +00:00 (Migrated from github.com)

The 0.1.1 release ceremony — merging this PR is the release
(CONTRIBUTING; #111, box#96's design).

The diff

  • package.json + package-lock.json: 0.1.1-dev -> 0.1.1. Patch is
    correct — the shipped section carries only a ### Fixed entry.
  • CHANGELOG.md: ## Unreleased stamped as ## 0.1.1 — 2026-07-19,
    and re-armed with a fresh, empty ## Unreleased immediately above
    it. Both halves in this diff, per #113/#114 — stamping without
    re-arming is what heavy-duty/rig#66 caught in the wild.

This is the first cast release to go through the merge door

0.1.0 could not. The interlock refused it (run 29698017907:
version '0.1.0' is bare, unchanged by this PR, and never released)
because cast had said 0.1.0 in package.json since its first commit,
so there was no -dev transition to detect; 0.1.0 shipped by the manual
tag fallback. main now genuinely reads 0.1.1-dev, so release.yml's
decide step lands in the bare, changed state — the ceremony — and
proceeds.

Verification

  • npm run check — clean, 58 files.
  • npm run build — tsc clean.
  • npm test623 passed (35 files), matching main's baseline.
  • test/release.test.ts — 41/41. The version-keyed guard added by #114
    is green on this exact tree: a bare version with an empty re-armed
    ## Unreleased over the stamp is precisely the case it was written to
    permit.
  • bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md — extracts
    non-empty (3017 bytes), stops cleanly above ## 0.1.0.

No change to release.yml was needed. The cast-0.1.1.tgz asset is
built and attached entirely by the workflow.

The 0.1.1 release ceremony — merging this PR **is** the release ([CONTRIBUTING](../blob/main/CONTRIBUTING.md#releasing); #111, box#96's design). ## The diff - `package.json` + `package-lock.json`: `0.1.1-dev` -> `0.1.1`. Patch is correct — the shipped section carries only a `### Fixed` entry. - `CHANGELOG.md`: `## Unreleased` stamped as `## 0.1.1 — 2026-07-19`, **and re-armed** with a fresh, empty `## Unreleased` immediately above it. Both halves in this diff, per #113/#114 — stamping without re-arming is what heavy-duty/rig#66 caught in the wild. ## This is the first cast release to go through the merge door 0.1.0 could not. The interlock refused it (run 29698017907: `version '0.1.0' is bare, unchanged by this PR, and never released`) because cast had said `0.1.0` in `package.json` since its first commit, so there was no `-dev` transition to detect; 0.1.0 shipped by the manual tag fallback. main now genuinely reads `0.1.1-dev`, so release.yml's decide step lands in the **bare, changed** state — the ceremony — and proceeds. ## Verification - `npm run check` — clean, 58 files. - `npm run build` — tsc clean. - `npm test` — **623 passed (35 files)**, matching main's baseline. - `test/release.test.ts` — 41/41. The version-keyed guard added by #114 is green on this exact tree: a bare version with an empty re-armed `## Unreleased` over the stamp is precisely the case it was written to permit. - `bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md` — extracts non-empty (3017 bytes), stops cleanly above `## 0.1.0`. No change to `release.yml` was needed. The `cast-0.1.1.tgz` asset is built and attached entirely by the workflow.
danmt (Migrated from github.com) reviewed 2026-07-19 21:33:05 +00:00
grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 21:44:38 +00:00
grok-bot-andresmgsl (Migrated from github.com) left a comment

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

Ceremony stamp at ee9c832:

  • package.json + package-lock.json: 0.1.1-dev → bare 0.1.1
  • CHANGELOG.md: empty ## Unreleased re-armed above ## 0.1.1 — 2026-07-19 with a populated ### Fixed shipping section (the #113/#114 two-edit shape)

Patch is correct for Fixed-only notes. First cast release that can actually take the merge door (real -dev → bare transition). release label present; checks green (build, install, reconcile, scope). No blockers.

**Verdict: Approve** — I agree with this as-is. Ceremony stamp at `ee9c832`: - `package.json` + `package-lock.json`: `0.1.1-dev` → bare `0.1.1` - `CHANGELOG.md`: empty `## Unreleased` re-armed above `## 0.1.1 — 2026-07-19` with a populated `### Fixed` shipping section (the #113/#114 two-edit shape) Patch is correct for Fixed-only notes. First cast release that can actually take the merge door (real `-dev` → bare transition). `release` label present; checks green (build, install, reconcile, scope). No blockers.
claude-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 21:52:53 +00:00
claude-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve. The 0.1.1 ceremony is complete, correct, and verified end-to-end on the exact head tree (ee9c832). This is the first cast release able to take the merge door, and the decide step's asserts all land green when simulated against this tree.

Ceremony vs CONTRIBUTING.md#releasing (at this head)

  • package.json:4 and package-lock.json:3/package-lock.json:8: 0.1.1-dev -> bare 0.1.1, both lockfile spots in step. Patch bump is right — the shipping section is ### Fixed only.
  • CHANGELOG.md:8 re-armed empty ## Unreleased immediately above CHANGELOG.md:10 ## 0.1.1 — 2026-07-19 (date is correct). Both halves of the #113/#114 two-edit shape are in this one diff, exactly what CONTRIBUTING step 1 mandates.
  • Diff is ceremony-only: 3 files, +5/-3, nothing smuggled.

Full suite on the stamped tree (run locally at ee9c832)

  • npm run build — tsc clean.
  • npm test623 passed, 35 files (matches the PR body's claim and main's baseline).
  • test/release.test.ts in isolation — 41/41, including #114's version-keyed guard: bare version + empty re-armed ## Unreleased over the stamp is precisely the state it permits, and it is green here — this is the state that #108 proved must not be red.
  • npm run check — biome clean, 58 files.
  • bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md — extracts 3017 bytes non-empty, starts at ### Fixed, stops cleanly above ## 0.1.0.

Merge-door simulation (.github/workflows/release.yml)

Walked the decide step's logic against this tree and origin/main:

  • ver=0.1.1 (bare), base=0.1.1-dev (origin/main aa5905d, the merge base) — the bare, changed state: the ceremony branch, proceeds. This is the real -dev transition 0.1.0 never had (run 29698017907 refused it correctly; 0.1.0 shipped via the manual tag fallback).
  • Label assert: release label is present on #116, so commits/<merge_sha>/pulls will find a merged, release-labeled PR behind the push.
  • Assert 4: git ls-remote origin refs/tags/0.1.1 — empty; gh release view 0.1.1 — not found. Nothing exists yet; the tag create and publish will proceed. (The 0.1.0 release exists with bare tag 0.1.0, confirming the no-v scheme the workflow tags with.)
  • The post-release bump step will compute 0.1.2-dev and re-arm main's version; the changelog re-arm is already in this diff, so the two halves meet as test/release.test.ts expects.

CHANGELOG completeness since the 0.1.0 tag (f098a27)

Merged since the tag: #114 (the changelog re-arm fix, #113) and #115 (the 0.1.1-dev bump). #114 is the sole ### Fixed entry in the 0.1.1 section — complete. #115 is version machinery with no user-facing surface, correctly omitted. #112 predates the tag and already lives in the 0.1.0 section. Nothing missing, nothing misplaced.

Version consistency

0.1.1 lives in exactly the three stamped files. The 0.1.0 strings in README.md:30 and install.sh:135/install.sh:147 are pre-existing prose/examples about the first release, not version pins this ceremony owns — no action needed here (a follow-up could refresh the README's transitional note now that releases exist, but that is not this PR's job).

CI on the head is green (build, install, reconcile, scope). No changes requested — merge is the ship decision.

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

**Verdict: Approve.** The 0.1.1 ceremony is complete, correct, and verified end-to-end on the exact head tree (`ee9c832`). This is the first cast release able to take the merge door, and the decide step's asserts all land green when simulated against this tree. ## Ceremony vs CONTRIBUTING.md#releasing (at this head) - `package.json:4` and `package-lock.json:3`/`package-lock.json:8`: `0.1.1-dev` -> bare `0.1.1`, both lockfile spots in step. Patch bump is right — the shipping section is `### Fixed` only. - `CHANGELOG.md:8` re-armed empty `## Unreleased` immediately above `CHANGELOG.md:10` `## 0.1.1 — 2026-07-19` (date is correct). Both halves of the #113/#114 two-edit shape are in this one diff, exactly what CONTRIBUTING step 1 mandates. - Diff is ceremony-only: 3 files, +5/-3, nothing smuggled. ## Full suite on the stamped tree (run locally at ee9c832) - `npm run build` — tsc clean. - `npm test` — **623 passed, 35 files** (matches the PR body's claim and main's baseline). - `test/release.test.ts` in isolation — **41/41**, including #114's version-keyed guard: bare version + empty re-armed `## Unreleased` over the stamp is precisely the state it permits, and it is green here — this is the state that #108 proved must not be red. - `npm run check` — biome clean, 58 files. - `bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md` — extracts **3017 bytes** non-empty, starts at `### Fixed`, stops cleanly above `## 0.1.0`. ## Merge-door simulation (`.github/workflows/release.yml`) Walked the decide step's logic against this tree and origin/main: - `ver=0.1.1` (bare), `base=0.1.1-dev` (origin/main `aa5905d`, the merge base) — the **bare, changed** state: the ceremony branch, proceeds. This is the real `-dev` transition 0.1.0 never had (run 29698017907 refused it correctly; 0.1.0 shipped via the manual tag fallback). - Label assert: `release` label is present on #116, so `commits/<merge_sha>/pulls` will find a merged, release-labeled PR behind the push. - Assert 4: `git ls-remote origin refs/tags/0.1.1` — empty; `gh release view 0.1.1` — not found. Nothing exists yet; the tag create and publish will proceed. (The 0.1.0 release exists with bare tag `0.1.0`, confirming the no-`v` scheme the workflow tags with.) - The post-release bump step will compute `0.1.2-dev` and re-arm main's version; the changelog re-arm is already in this diff, so the two halves meet as `test/release.test.ts` expects. ## CHANGELOG completeness since the `0.1.0` tag (f098a27) Merged since the tag: #114 (the changelog re-arm fix, #113) and #115 (the `0.1.1-dev` bump). #114 is the sole `### Fixed` entry in the 0.1.1 section — complete. #115 is version machinery with no user-facing surface, correctly omitted. #112 predates the tag and already lives in the 0.1.0 section. Nothing missing, nothing misplaced. ## Version consistency `0.1.1` lives in exactly the three stamped files. The `0.1.0` strings in `README.md:30` and `install.sh:135`/`install.sh:147` are pre-existing prose/examples about the first release, not version pins this ceremony owns — no action needed here (a follow-up could refresh the README's transitional note now that releases exist, but that is not this PR's job). CI on the head is green (build, install, reconcile, scope). No changes requested — merge is the ship decision. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_
codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 21:59:52 +00:00
codex-bot-andresmgsl (Migrated from github.com) left a comment

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

The current head correctly performs the complete 0.1.1 release ceremony: both package manifests move from 0.1.1-dev to 0.1.1, and CHANGELOG.md preserves an empty Unreleased section above the populated 0.1.1 stamp. The release label is present, the version transition and changelog structure match the repository release guidance, and all current check runs are successful.

Verdict: I agree with everything and have no additional feedback. The current head correctly performs the complete 0.1.1 release ceremony: both package manifests move from 0.1.1-dev to 0.1.1, and CHANGELOG.md preserves an empty Unreleased section above the populated 0.1.1 stamp. The release label is present, the version transition and changelog structure match the repository release guidance, and all current check runs are successful.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/cast#116
No description provided.