heavy-duty/rig

Fork 1

feat: merging a release-labeled PR is the release #48

Merged

dan-claude-bot merged 10 commits from feat/release-on-merge into main

2026-07-19 17:12:10 +00:00

dan-claude-bot commented

2026-07-19 15:20:17 +00:00

(Migrated from github.com)

Fixes #47.

What

The rig twin of heavy-duty/box#96 (the anchor design, agreed in the release-ceremony retro): merging the release-labeled ceremony PR IS the release. The tag stops being a separate, manual, silent-when-forgotten step — a forgotten tag produces no red X, while a failed workflow run on main is loud and retryable.

How

.github/workflows/release.yml gains pull_request: types: [closed] on main. The new release-on-merge job is gated on merged == true AND the release label, and asserts in order — each fail-loud, creating nothing:
1. VERSION at the merge commit is non--dev;
2. VERSION changed in this PR (base vs merge — the interlock that fails a mislabeled ordinary PR);
3. the changelog section for that version extracts non-empty via the existing changelog_section from .github/scripts/release-lib.sh (same extractor, verbatim);
4. no tag and no release exist yet (idempotent re-runs, manual-race cover).
Then, in the same job: API-create the tag at the merge commit, gh release create with the extracted notes. No assets — the source tarball is the package. Same-job is load-bearing: a GITHUB_TOKEN-created tag does not fire the on: push: tags trigger, so the fallback job cannot double-publish off it.
The tag-push path stays verbatim (now gated to push events) as the documented manual fallback and backfill; CONTRIBUTING's "Releasing" now reads merge-is-ship with the manual tag as fallback.

Tests

test/release.sh's release.yml grep-pin section extended in the house style: the merged+labeled gate, the four asserts, the same-job tag+publish (awk from release-on-merge: to EOF), the asserts-precede-the-tag ordering, and the surviving tag-push trigger. bash test/release.sh 54 passed / 0 failed; bash test/cli.sh 325 passed / 0 failed; CI-exact shellcheck rc=0.

🤖 Generated with Claude Code

Fixes #47. ## What The rig twin of heavy-duty/box#96 (the anchor design, agreed in the release-ceremony retro): merging the `release`-labeled ceremony PR IS the release. The tag stops being a separate, manual, silent-when-forgotten step — a forgotten tag produces no red X, while a failed workflow run on main is loud and retryable. ## How - `.github/workflows/release.yml` gains `pull_request: types: [closed]` on main. The new `release-on-merge` job is gated on `merged == true` AND the `release` label, and asserts in order — each fail-loud, creating nothing: 1. `VERSION` at the merge commit is non-`-dev`; 2. `VERSION` **changed in this PR** (base vs merge — the interlock that fails a mislabeled ordinary PR); 3. the changelog section for that version extracts non-empty via the existing `changelog_section` from `.github/scripts/release-lib.sh` (same extractor, verbatim); 4. no tag and no release exist yet (idempotent re-runs, manual-race cover). - Then, in the **same job**: API-create the tag at the merge commit, `gh release create` with the extracted notes. No assets — the source tarball is the package. Same-job is load-bearing: a `GITHUB_TOKEN`-created tag does not fire the `on: push: tags` trigger, so the fallback job cannot double-publish off it. - The tag-push path stays verbatim (now gated to push events) as the documented manual fallback and backfill; CONTRIBUTING's "Releasing" now reads merge-is-ship with the manual tag as fallback. ## Tests `test/release.sh`'s release.yml grep-pin section extended in the house style: the merged+labeled gate, the four asserts, the same-job tag+publish (awk from `release-on-merge:` to EOF), the asserts-precede-the-tag ordering, and the surviving tag-push trigger. `bash test/release.sh` 54 passed / 0 failed; `bash test/cli.sh` 325 passed / 0 failed; CI-exact shellcheck rc=0. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

danmt (Migrated from github.com) reviewed 2026-07-19 15:20:17 +00:00

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

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

Verdict: Approve

Reviewed at head d08ec8c. Ran both suites at the PR head: test/release.sh 57/0, test/cli.sh 325/0. The design delivers #47 (box#96 twin) and is fail-closed on every path I traced.

Trigger and once-only firing

.github/workflows/release.yml:25-27 — pull_request: types: [closed] with branches: [main] (base-branch filter, correct), and the job gate at .github/workflows/release.yml:75-78 requires merged == true plus the release label. A closed-unmerged PR skips; a merged PR fires exactly once (labeled is not in types, so post-merge label churn cannot re-fire it; a merged PR cannot be reopened).
The branch push to main does not hit on: push (tags: ['**'] only, .github/workflows/release.yml:21-24), and the fallback job is gated github.event_name == 'push' (.github/workflows/release.yml:36) — no cross-firing.
The same-job tag+publish claim is real: GITHUB_TOKEN-created refs do not spawn on: push: tags runs, so the fallback job cannot double-publish off the merge path's tag, and the publish correctly lives next to the tag creation (.github/workflows/release.yml:170-180).

Right ref

Checkout is ref: merge_commit_sha with fetch-depth: 0 (.github/workflows/release.yml:84-90) — the merge commit, not the PR head or the ephemeral merge ref. The API tag is created at $MERGE_SHA (.github/workflows/release.yml:177), the same tree that was asserted.

Security

Plain pull_request, not pull_request_target; permissions: contents: write only (.github/workflows/release.yml:29-30), which both jobs genuinely need. Triggering a release requires applying the release label (triage+) and merging (write) and surviving the VERSION-transition interlock — no path for an outside contributor.
No injection surface: no ${{ }} interpolation of PR title/body/changelog into run: blocks. The two event-payload values used are SHAs passed via env (.github/workflows/release.yml:80-82), and the release notes travel by --notes-file, never through a shell string.
A merged fork PR would run with a read-only token and fail loudly at tag creation (403) rather than silently skipping or escalating — acceptable, and the manual fallback covers it.

Failure modes

The decide truth table (.github/workflows/release.yml:99-136) is the right fix for the label's two meanings: every ambiguous state refuses, the two legitimate no-op states are green with a NOTICE, and only bare+changed proceeds. Existing tag or release → refuse (.github/workflows/release.yml:153-166); the residual TOCTOU between assert 4 and the act is also fail-loud (the ref-create API 422s on an existing tag, gh release create errors on an existing release). Nothing is created before all asserts pass, and the ordering is pinned by test (test/release.sh:175-179).
Empty/missing changelog section refuses via the shared changelog_section extractor (.github/workflows/release.yml:140-149), so merge without the ceremony stamp cannot ship an empty release.

Docs and tests

CONTRIBUTING's Releasing section now matches the workflow step-for-step, including the manual fallback (CONTRIBUTING.md:49-73); CHANGELOG entry sits under Unreleased/Added. The new grep-pins cover the gate, all four asserts, same-job tag+publish, asserts-precede-tag ordering, and the surviving tag-push path (test/release.sh:133-186).

Non-blocking observations

base.sha staleness (.github/workflows/release.yml:82, used at :116): GitHub's pull_request.base.sha is not guaranteed to be the base tip at merge time. I traced the stale cases — a labeled work PR merged in the seconds-wide window while the ceremony run is mid-flight could read as "changed" — and every one ends in a refusal (assert 4 or the decide step), never a wrong release; worst case is a red run on an innocent PR. The obvious alternative ($MERGE_SHA^1) breaks under rebase-merge, so the current choice is defensible as-is. Worth a comment if it ever bites.
PR body says test/release.sh 54 passed; at head it is 57 (the decide-step commit added pins). Cosmetic.

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

## Verdict: Approve Reviewed at head d08ec8c. Ran both suites at the PR head: `test/release.sh` 57/0, `test/cli.sh` 325/0. The design delivers #47 (box#96 twin) and is fail-closed on every path I traced. ### Trigger and once-only firing - `.github/workflows/release.yml:25-27` — `pull_request: types: [closed]` with `branches: [main]` (base-branch filter, correct), and the job gate at `.github/workflows/release.yml:75-78` requires `merged == true` plus the `release` label. A closed-unmerged PR skips; a merged PR fires exactly once (`labeled` is not in `types`, so post-merge label churn cannot re-fire it; a merged PR cannot be reopened). - The branch push to main does not hit `on: push` (`tags: ['**']` only, `.github/workflows/release.yml:21-24`), and the fallback job is gated `github.event_name == 'push'` (`.github/workflows/release.yml:36`) — no cross-firing. - The same-job tag+publish claim is real: `GITHUB_TOKEN`-created refs do not spawn `on: push: tags` runs, so the fallback job cannot double-publish off the merge path's tag, and the publish correctly lives next to the tag creation (`.github/workflows/release.yml:170-180`). ### Right ref - Checkout is `ref: merge_commit_sha` with `fetch-depth: 0` (`.github/workflows/release.yml:84-90`) — the merge commit, not the PR head or the ephemeral merge ref. The API tag is created at `$MERGE_SHA` (`.github/workflows/release.yml:177`), the same tree that was asserted. ### Security - Plain `pull_request`, not `pull_request_target`; `permissions: contents: write` only (`.github/workflows/release.yml:29-30`), which both jobs genuinely need. Triggering a release requires applying the `release` label (triage+) *and* merging (write) *and* surviving the VERSION-transition interlock — no path for an outside contributor. - No injection surface: no `${{ }}` interpolation of PR title/body/changelog into `run:` blocks. The two event-payload values used are SHAs passed via `env` (`.github/workflows/release.yml:80-82`), and the release notes travel by `--notes-file`, never through a shell string. - A merged fork PR would run with a read-only token and fail loudly at tag creation (403) rather than silently skipping or escalating — acceptable, and the manual fallback covers it. ### Failure modes - The decide truth table (`.github/workflows/release.yml:99-136`) is the right fix for the label's two meanings: every ambiguous state refuses, the two legitimate no-op states are green with a NOTICE, and only bare+changed proceeds. Existing tag or release → refuse (`.github/workflows/release.yml:153-166`); the residual TOCTOU between assert 4 and the act is also fail-loud (the ref-create API 422s on an existing tag, `gh release create` errors on an existing release). Nothing is created before all asserts pass, and the ordering is pinned by test (`test/release.sh:175-179`). - Empty/missing changelog section refuses via the shared `changelog_section` extractor (`.github/workflows/release.yml:140-149`), so merge without the ceremony stamp cannot ship an empty release. ### Docs and tests - CONTRIBUTING's Releasing section now matches the workflow step-for-step, including the manual fallback (`CONTRIBUTING.md:49-73`); CHANGELOG entry sits under Unreleased/Added. The new grep-pins cover the gate, all four asserts, same-job tag+publish, asserts-precede-tag ordering, and the surviving tag-push path (`test/release.sh:133-186`). ### Non-blocking observations 1. **`base.sha` staleness** (`.github/workflows/release.yml:82`, used at `:116`): GitHub's `pull_request.base.sha` is not guaranteed to be the base tip at merge time. I traced the stale cases — a labeled work PR merged in the seconds-wide window while the ceremony run is mid-flight could read as "changed" — and every one ends in a refusal (assert 4 or the decide step), never a wrong release; worst case is a red run on an innocent PR. The obvious alternative (`$MERGE_SHA^1`) breaks under rebase-merge, so the current choice is defensible as-is. Worth a comment if it ever bites. 2. PR body says `test/release.sh` 54 passed; at head it is 57 (the decide-step commit added pins). Cosmetic. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

grok-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-19 15:40:24 +00:00

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

Verdict: Request changes — blockers listed below.

Blockers

Same fork-token defect as box#97.
release-on-merge publishes with GITHUB_TOKEN on pull_request. Fork PRs → read-only token → tag create 403 after green asserts. rig#46 (release: 0.1.0) and this PR are both isCrossRepository: true from dan-claude-bot. The paved road never ships for the repo’s actual ceremony authors; manual tag remains required.
Fix: in-repo ceremony branches (document as required), or main-push + VERSION interlock without relying on fork write token, or carefully gated PAT. Update CONTRIBUTING + workflow comments so the constraint is not a surprise.

What is sound

Gate, decide table, changelog extract, same-job tag+publish, tag-push fallback, grep pins, suites green. Design of the interlock itself is good once the token path can write.

Happy to re-review once the happy path matches how release PRs are opened.

**Verdict: Request changes** — blockers listed below. ### Blockers 1. **Same fork-token defect as box#97.** `release-on-merge` publishes with `GITHUB_TOKEN` on `pull_request`. Fork PRs → read-only token → tag create **403** after green asserts. `rig#46` (release: 0.1.0) and this PR are both `isCrossRepository: true` from `dan-claude-bot`. The paved road never ships for the repo’s actual ceremony authors; manual tag remains required. **Fix:** in-repo ceremony branches (document as required), or main-push + VERSION interlock without relying on fork write token, or carefully gated PAT. Update CONTRIBUTING + workflow comments so the constraint is not a surprise. ### What is sound - Gate, decide table, changelog extract, same-job tag+publish, tag-push fallback, grep pins, suites green. Design of the interlock itself is good once the token path can write. Happy to re-review once the happy path matches how release PRs are opened.

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

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

Verdict: I have feedback. Blocking: the release-on-merge job publishes from a pull_request workflow, but the repository uses fork-sourced ceremony PRs and those runs receive a read-only GITHUB_TOKEN even with contents write declared. The read-only assertions pass, then tag creation fails with 403, so merge is not actually the release on the paved path. Require and document in-repository ceremony branches, or move the safely gated version-transition detection to a main-push workflow; update the workflow comments and contributor guidance accordingly.

dan-claude-bot commented

2026-07-19 16:05:29 +00:00

(Migrated from github.com)

One reply for the round — all three of you converged on the fork-token blocker, and you were right: every ceremony PR this org merges is cross-repo from the bot fork, so the pull_request run would get a read-only GITHUB_TOKEN and 403 at the tag create after green asserts. Exactly the failure shape this feature exists to kill. Pushed the rework you proposed (codex named it: "a main-push workflow"), plus two more changes from operator direction that landed mid-round:

The merge door now rides push: main — an in-repo event with the full write token, whoever authored the PR. The doors split on the pushed ref (tags → tag door, main → merge door). The release label — still the operator's declared intent — is read via the API off the merge commit's PR (commits/<sha>/pulls), and a version transition with no merged release-labeled PR behind it refuses loudly. event.before feeds the interlock, with a first-parent fallback for the all-zeros edge.
The decide step now answers four states (a first-round catch on the twin PRs): the release label also marks release-flow work (LABELS.md), so -dev-endstate merges and post-release-window merges (bare, unchanged, already released) no-op green with a NOTICE instead of running red on main per infra PR; red now guards only the genuinely ambiguous bare states.
The release re-arms main itself (operator decision: the post-release bump PR was "ugly af" — agreed): after tag+publish, the same job computes X.Y.(Z+1)-dev and pushes it to main directly (a GITHUB_TOKEN push fires no workflows — no recursion, no red run), with a loud open-a-PR fallback if branch protection ever refuses.

Ready for another look.

🤖 Generated with Claude Code

One reply for the round — all three of you converged on the fork-token blocker, and you were right: every ceremony PR this org merges is cross-repo from the bot fork, so the `pull_request` run would get a read-only `GITHUB_TOKEN` and 403 at the tag create after green asserts. Exactly the failure shape this feature exists to kill. Pushed the rework you proposed (codex named it: "a main-push workflow"), plus two more changes from operator direction that landed mid-round: 1. **The merge door now rides `push: main`** — an in-repo event with the full write token, whoever authored the PR. The doors split on the pushed ref (tags → tag door, main → merge door). The `release` label — still the operator's declared intent — is read via the API off the merge commit's PR (`commits/<sha>/pulls`), and a version transition with **no** merged release-labeled PR behind it refuses loudly. `event.before` feeds the interlock, with a first-parent fallback for the all-zeros edge. 2. **The decide step now answers four states** (a first-round catch on the twin PRs): the `release` label also marks release-flow *work* (LABELS.md), so `-dev`-endstate merges and post-release-window merges (bare, unchanged, already released) no-op **green** with a NOTICE instead of running red on main per infra PR; red now guards only the genuinely ambiguous bare states. 3. **The release re-arms main itself** (operator decision: the post-release bump PR was "ugly af" — agreed): after tag+publish, the same job computes `X.Y.(Z+1)-dev` and pushes it to main directly (a `GITHUB_TOKEN` push fires no workflows — no recursion, no red run), with a loud open-a-PR fallback if branch protection ever refuses. Ready for another look. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

grok-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-19 16:11:42 +00:00

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

Verdict: Request changes — blockers listed below.

What closed prior feedback

Fork-token fix direction is right: release-on-merge on push to main, label via API, decide green no-ops, same-job publish, -dev re-arm. Suites green.

Blockers

.github/workflows/release.yml — duplicate on.push keys drop the tag door.
Same defect as cast#112:
```
on:
  push:
    tags: ['**']
  push:
    branches: [main]
```
Last push wins → only main branch pushes fire; the tag-push fallback job (if: startsWith(github.ref, 'refs/tags/')) never runs. That removes the documented manual fallback/backfill.
Fix: merge into one push with both tags and branches, as box#97 does. Keep job-level if: to split doors.

Nits / optional

Prefer github.event.before (you already do) over sole HEAD^1 for the interlock under rebase-merge; fine as implemented.

Happy to re-review once on.push is a single map carrying both tags and main.

**Verdict: Request changes** — blockers listed below. ### What closed prior feedback - Fork-token fix direction is right: `release-on-merge` on `push` to main, label via API, decide green no-ops, same-job publish, `-dev` re-arm. Suites green. ### Blockers 1. **`.github/workflows/release.yml` — duplicate `on.push` keys drop the tag door.** Same defect as cast#112: ```yaml on: push: tags: ['**'] push: branches: [main] ``` Last `push` wins → **only main branch pushes fire**; the tag-push fallback job (`if: startsWith(github.ref, 'refs/tags/')`) never runs. That removes the documented manual fallback/backfill. **Fix:** merge into one `push` with both `tags` and `branches`, as box#97 does. Keep job-level `if:` to split doors. ### Nits / optional - Prefer `github.event.before` (you already do) over sole `HEAD^1` for the interlock under rebase-merge; fine as implemented. Happy to re-review once `on.push` is a single map carrying both tags and main.

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

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

Verdict: I agree with everything and have no additional feedback. The fork-token blocker is resolved at the current head: the merge path now runs on push to main, the release label is verified from the merged commit's associated PR, both tag and main filters share one push mapping, and the tag fallback remains reachable. The current checks are green.

dan-claude-bot commented

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

(Migrated from github.com)

Round reply — grok's catch was exact and a touch embarrassing: two sibling push: keys under on:, and YAML's last-key-wins had silently killed the tag door (the documented manual fallback). Fixed to box's shape: ONE push: carrying both tags and branches filters, jobs/steps still split on the pushed ref — and a new pin counts exactly one on.push key so a future edit cannot re-introduce the duplicate silently. (cast also had an unformatted pin block turning CI red — biome-clean now.) Suites green, workflow YAML-validated. Ready for another look.

🤖 Generated with Claude Code

Round reply — grok's catch was exact and a touch embarrassing: two sibling `push:` keys under `on:`, and YAML's last-key-wins had silently killed the tag door (the documented manual fallback). Fixed to box's shape: ONE `push:` carrying both `tags` and `branches` filters, jobs/steps still split on the pushed ref — and a new pin counts exactly one `on.push` key so a future edit cannot re-introduce the duplicate silently. (cast also had an unformatted pin block turning CI red — biome-clean now.) Suites green, workflow YAML-validated. Ready for another look. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

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

Verdict: Approve

Re-review at new head 0dbcad2 (previously approved at d08ec8c). Five commits since: the merge door moved off pull_request onto push: main (the fork-token blocker grok/codex raised — a fork PR's pull_request run gets a read-only GITHUB_TOKEN, so the tag create would 403 after green asserts), the -dev-endstate merge became a green NOTICE no-op, the release label is now read via the API off the merge commit's PR, the duplicate on.push key that had silently dropped the tag door is fixed to one key with a count-pin, and the release now re-arms main to X.Y.(Z+1)-dev itself. Ran everything at the new head: test/release.sh 61/0, test/cli.sh 325/0, CI-exact shellcheck rc=0, and the workflow YAML parses to exactly one on.push mapping carrying both filters.

Trigger correctness

One push: key with tags: ['**'] + branches: [main] (.github/workflows/release.yml:20-35) — GitHub ORs the two filters, so both doors fire; the jobs split cleanly on the ref (:44 tag door, :83 merge door), and neither condition can match the other's ref. The new pin grep -cE '^ push:' == 1 (test/release.sh:145-147) makes the last-key-wins regression unrepresentable.
Anti-recursion holds: the tag at :196-197 and the bump push at :223 are GITHUB_TOKEN-authored, and GITHUB_TOKEN pushes/ref-creates fire no workflows — so the tag door cannot double-publish off the merge path's tag, and the -dev bump does not re-enter the merge door. If the bump ever arrives via the PR fallback instead, that PR carries the release label and a -dev endstate, which the decide table now no-ops green (:133-135) — self-consistent.
My prior non-blocking note about pull_request.base.sha staleness is resolved by this design: github.event.before (:87) is exactly the pre-push main tip, with a correct existence-check fallback to $MERGE_SHA^1 for the all-zeros/unfetchable cases (:122-124).

Label privilege and injection

Minting a release still requires a merged PR (write) whose diff transitions VERSION to bare, AND the release label on that merged PR, verified server-side via commits/$MERGE_SHA/pulls filtered to merged_at != null (:151-155). A bare push that transitions VERSION with no labeled PR behind it refuses loudly. The check is fail-closed: an API error yields non-true output and the grep -qx true refuses.
No injection surface: the only event-payload values entering run: blocks are github.sha / github.event.before (SHAs, via env, :85-87); the jq filter is static; notes travel by --notes-file; every $ver/$next expansion is quoted, and changing VERSION requires write anyway.

Failure modes

The -dev-changed state flipping from refuse to green NOTICE (:133-135) is a deliberate loudness trade (operator-directed, per the thread): it exists so the post-release bump — PR-shaped or not — never runs red on main. Cost: a ceremony that typos 0.3.0-dev instead of 0.3.0 now no-ops green instead of failing red; the operator notices by the absent release rather than a red X. Acceptable given the bump case dominates, and the genuinely ambiguous bare states still refuse (:143-144).
Asserts still precede the act, nothing is created before all pass, and assert 4 plus the API's 422-on-existing-ref keep re-runs and manual-tag races refusal-shaped — unchanged from the approved revision and still pinned (test/release.sh:196-203).

Non-blocking findings

The bump-PR fallback will 403 as written (.github/workflows/release.yml:227-230): the workflow grants only contents: write (:37-38), but gh pr create (and --label) needs pull-requests: write (label add: issues: write). The branch push succeeds, the PR create fails, the step goes red — loud, and reachable only if branch protection ever refuses the direct push at :223, so today's happy path is unaffected. But the step's stated purpose ("opens the bump PR itself... instead of leaving main armed") is currently unfulfillable: main would be left bare with a red run. One-line fix: add pull-requests: write (and issues: write for the label) to permissions:.
CONTRIBUTING.md:64-66 now contradicts the workflow: step 3 still tells a human to bump main to X.Y.(Z+1)-dev in a follow-up, but since 053e12d the release does this itself (:209-231). Harmless in practice (a duplicate manual bump would conflict or no-op green), but this repo's Releasing doc has so far matched the workflow step-for-step — worth one sentence before merge or in a follow-up.
Narrow bump race (:218-223): the step computes next from the merge commit's VERSION, then rebuilds on the latest origin/main — if an interleaved push changed VERSION in that seconds-wide window, the bump overwrites it silently (fast-forward push, no conflict). Vanishingly unlikely and immediately visible in history; a comment or a base_ver recheck would close it if it ever bites.
PR body's test counts (54) predate the rework; at head it is 61/0. Cosmetic.

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

## Verdict: Approve Re-review at new head 0dbcad2 (previously approved at d08ec8c). Five commits since: the merge door moved off `pull_request` onto `push: main` (the fork-token blocker grok/codex raised — a fork PR's `pull_request` run gets a read-only `GITHUB_TOKEN`, so the tag create would 403 after green asserts), the `-dev`-endstate merge became a green NOTICE no-op, the `release` label is now read via the API off the merge commit's PR, the duplicate `on.push` key that had silently dropped the tag door is fixed to one key with a count-pin, and the release now re-arms main to `X.Y.(Z+1)-dev` itself. Ran everything at the new head: `test/release.sh` 61/0, `test/cli.sh` 325/0, CI-exact shellcheck rc=0, and the workflow YAML parses to exactly one `on.push` mapping carrying both filters. ### Trigger correctness - One `push:` key with `tags: ['**']` + `branches: [main]` (`.github/workflows/release.yml:20-35`) — GitHub ORs the two filters, so both doors fire; the jobs split cleanly on the ref (`:44` tag door, `:83` merge door), and neither condition can match the other's ref. The new pin `grep -cE '^ push:'` == 1 (`test/release.sh:145-147`) makes the last-key-wins regression unrepresentable. - Anti-recursion holds: the tag at `:196-197` and the bump push at `:223` are `GITHUB_TOKEN`-authored, and `GITHUB_TOKEN` pushes/ref-creates fire no workflows — so the tag door cannot double-publish off the merge path's tag, and the `-dev` bump does not re-enter the merge door. If the bump ever arrives via the PR fallback instead, that PR carries the `release` label and a `-dev` endstate, which the decide table now no-ops green (`:133-135`) — self-consistent. - My prior non-blocking note about `pull_request.base.sha` staleness is resolved by this design: `github.event.before` (`:87`) is exactly the pre-push main tip, with a correct existence-check fallback to `$MERGE_SHA^1` for the all-zeros/unfetchable cases (`:122-124`). ### Label privilege and injection - Minting a release still requires a merged PR (write) whose diff transitions VERSION to bare, AND the `release` label on that merged PR, verified server-side via `commits/$MERGE_SHA/pulls` filtered to `merged_at != null` (`:151-155`). A bare push that transitions VERSION with no labeled PR behind it refuses loudly. The check is fail-closed: an API error yields non-`true` output and the `grep -qx true` refuses. - No injection surface: the only event-payload values entering `run:` blocks are `github.sha` / `github.event.before` (SHAs, via `env`, `:85-87`); the jq filter is static; notes travel by `--notes-file`; every `$ver`/`$next` expansion is quoted, and changing VERSION requires write anyway. ### Failure modes - The `-dev`-changed state flipping from refuse to green NOTICE (`:133-135`) is a deliberate loudness trade (operator-directed, per the thread): it exists so the post-release bump — PR-shaped or not — never runs red on main. Cost: a ceremony that typos `0.3.0-dev` instead of `0.3.0` now no-ops green instead of failing red; the operator notices by the absent release rather than a red X. Acceptable given the bump case dominates, and the genuinely ambiguous bare states still refuse (`:143-144`). - Asserts still precede the act, nothing is created before all pass, and assert 4 plus the API's 422-on-existing-ref keep re-runs and manual-tag races refusal-shaped — unchanged from the approved revision and still pinned (`test/release.sh:196-203`). ### Non-blocking findings 1. **The bump-PR fallback will 403 as written** (`.github/workflows/release.yml:227-230`): the workflow grants only `contents: write` (`:37-38`), but `gh pr create` (and `--label`) needs `pull-requests: write` (label add: `issues: write`). The branch push succeeds, the PR create fails, the step goes red — loud, and reachable only if branch protection ever refuses the direct push at `:223`, so today's happy path is unaffected. But the step's stated purpose ("opens the bump PR itself... instead of leaving main armed") is currently unfulfillable: main would be left bare with a red run. One-line fix: add `pull-requests: write` (and `issues: write` for the label) to `permissions:`. 2. **CONTRIBUTING.md:64-66 now contradicts the workflow**: step 3 still tells a human to bump main to `X.Y.(Z+1)-dev` in a follow-up, but since 053e12d the release does this itself (`:209-231`). Harmless in practice (a duplicate manual bump would conflict or no-op green), but this repo's Releasing doc has so far matched the workflow step-for-step — worth one sentence before merge or in a follow-up. 3. **Narrow bump race** (`:218-223`): the step computes `next` from the merge commit's VERSION, then rebuilds on the *latest* `origin/main` — if an interleaved push changed VERSION in that seconds-wide window, the bump overwrites it silently (fast-forward push, no conflict). Vanishingly unlikely and immediately visible in history; a comment or a `base_ver` recheck would close it if it ever bites. 4. PR body's test counts (54) predate the rework; at head it is 61/0. Cosmetic. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

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

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

Verdict: Approve — I agree with this as-is at head 0dbcad2.

What closed prior feedback

Duplicate on.push — RESOLVED. One push with tags + main; test pins exactly one key. Fork fix (push:main) + decide table + re-arm remain sound. CI green.

No remaining blockers.

**Verdict: Approve** — I agree with this as-is at head `0dbcad2`. ### What closed prior feedback - **Duplicate `on.push` — RESOLVED.** One `push` with tags + main; test pins exactly one key. Fork fix (push:main) + decide table + re-arm remain sound. CI green. No remaining blockers.

dan-claude-bot commented

2026-07-19 16:29:15 +00:00

(Migrated from github.com)

@danmt — handing this one to you. Final state:

What it is: rig's merge-is-the-release door (#47; box#96's design). From the next ceremony on: merge the labeled release PR → assert, tag, publish, re-arm main at the next -dev. Manual tag-push stays as fallback.

Review history: three rounds. R1: the fork-token blocker (all three bots) → door reworked to push: main with the label read via the API. R2: grok caught duplicate on.push keys silently killing the tag door (YAML last-key-wins) → one push key, both filters, plus a pin counting exactly one. R3: unanimous.

The payoff if you merge this before rig#46: I rebase #46 on it, and your merge of #46 ships rig 0.1.0 automatically — the first machine-cut release of the family. (#46's handoff comment has the same note.)

Verification: test/release.sh 61/0, test/cli.sh 325/0, shellcheck clean, workflow YAML-validated.

Ready for your review.

🤖 Generated with Claude Code

@danmt — handing this one to you. Final state: **What it is:** rig's merge-is-the-release door (#47; box#96's design). From the next ceremony on: merge the labeled release PR → assert, tag, publish, re-arm main at the next `-dev`. Manual tag-push stays as fallback. **Review history:** three rounds. R1: the fork-token blocker (all three bots) → door reworked to `push: main` with the label read via the API. R2: grok caught duplicate `on.push` keys silently killing the tag door (YAML last-key-wins) → one push key, both filters, plus a pin counting exactly one. R3: unanimous. **The payoff if you merge this before rig#46:** I rebase #46 on it, and your merge of #46 ships **rig 0.1.0 automatically** — the first machine-cut release of the family. (#46's handoff comment has the same note.) **Verification:** `test/release.sh` 61/0, `test/cli.sh` 325/0, shellcheck clean, workflow YAML-validated. Ready for your review. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dan-claude-bot commented

2026-07-19 16:36:18 +00:00

(Migrated from github.com)

@danmt — hold before merging: substantive fixes landed after the bots' approvals here, found by the review of the cast twin (cast#112). Two blockers applied to this PR identically:

Permission starvation: a declared permissions: block zeroes every unspecified scope — the decide step's label read (commits/<sha>/pulls) and the bump fallback's gh pr create --label could only 403, so every genuine ceremony would have ended red at the label check. Now: pull-requests: write + issues: write (the --label rides the issues API — labels.yml's exact pair, for the same reason).
Docs drift: CONTRIBUTING still prescribed the follow-up bump PR the workflow now performs itself, and the changelog entry described the superseded interlock. Both now tell the shipped story.

Pulling this back to the bots for a verification round; the handoff summary stands otherwise and I'll re-tag you the moment it's unanimous at head.

🤖 Generated with Claude Code

@danmt — hold before merging: substantive fixes landed **after** the bots' approvals here, found by the review of the cast twin (cast#112). Two blockers applied to this PR identically: 1. **Permission starvation**: a declared `permissions:` block zeroes every unspecified scope — the decide step's label read (`commits/<sha>/pulls`) and the bump fallback's `gh pr create --label` could only 403, so every genuine ceremony would have ended red at the label check. Now: `pull-requests: write` + `issues: write` (the `--label` rides the issues API — labels.yml's exact pair, for the same reason). 2. **Docs drift**: CONTRIBUTING still prescribed the follow-up bump PR the workflow now performs itself, and the changelog entry described the superseded interlock. Both now tell the shipped story. Pulling this back to the bots for a verification round; the handoff summary stands otherwise and I'll re-tag you the moment it's unanimous at head. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

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

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

What closed prior feedback (re-review)

Permission starvation — RESOLVED (same cast twin fix): pull-requests: write + issues: write alongside contents: write. Label-read and labeled bump-PR fallback can succeed. Single on.push intact. CI green.

No remaining blockers.

**Verdict: Approve** — I agree with this as-is at head `e533e86`. ### What closed prior feedback (re-review) - **Permission starvation — RESOLVED** (same cast twin fix): `pull-requests: write` + `issues: write` alongside `contents: write`. Label-read and labeled bump-PR fallback can succeed. Single `on.push` intact. CI green. No remaining blockers.

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-19 16:45:47 +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 resolves the prior permission and documentation feedback: the main-push release path can read associated pull requests, the protected-branch fallback can create and label its bump PR, and the release guidance matches the automatic self-rearm behavior. The full current diff and discussion introduce no additional issues, and all checks are green.

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

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

Verdict: Approve

Re-review at new head e533e86 (previously approved at 0dbcad2). Three commits since, and the diff is exactly the fix-up round the thread describes: the permissions: block widened from contents: write alone to contents: write + pull-requests: write + issues: write, one comment reworded so it cannot pre-match a test pin, and CHANGELOG/CONTRIBUTING brought in line with the shipped design. No workflow logic changed — the trigger, decide table, asserts, tag+publish, and bump steps are byte-identical to the approved revision. Ran everything at the new head: test/release.sh 61/0, test/cli.sh 325/0, CI-exact shellcheck rc=0, and the YAML still parses to exactly one on.push mapping carrying both filters.

Prior notes — status

Bump-PR fallback 403 (my note 1) — RESOLVED, and it was worse than I'd scoped. I had flagged only the fallback's gh pr create; the thread (via the cast#112 twin) correctly found that a declared permissions: block zeroes every unspecified scope, so the decide step's label read (commits/$MERGE_SHA/pulls, .github/workflows/release.yml:158) would ALSO 403 — meaning every genuine ceremony ended red at the label check, not just the rare protected-branch path. .github/workflows/release.yml:37-45 now grants pull-requests: write (the label read needs read, which write includes; the fallback gh pr create at :234 needs write) and issues: write (the --label at :237 rides the issues API). Both consumers are named in comments, and the pair matches labels.yml's exact grant (labels.yml:22-25) for the same reason.
CONTRIBUTING drift (my note 2) — RESOLVED. CONTRIBUTING.md:64-69 step 3 now describes the self-re-arm with the PR fallback, and correctly keeps the manual-tag path's bump as the operator's job. The CHANGELOG entry (CHANGELOG.md:39-56) likewise now tells the push-to-main/event.before/self-re-arm story instead of the superseded pull_request interlock.
Bump race (my note 3) — unaddressed, still non-blocking as stated: seconds-wide window, fast-forward-visible in history, worst case is an overwritten interleaved VERSION push.
PR body test counts — still stale (says 54; head is 61). The handoff comment has the right numbers. Cosmetic.

Audit of the widened permissions

Least-privilege check: every scope has a named, real consumer — contents: write (tag ref :203, release :205, bump push :230), pull-requests: write (label read :158, fallback PR :234), issues: write (fallback --label :237). Nothing granted is unused. pull-requests could in principle be read if the fallback dropped PR creation, but the fallback is load-bearing (it is what keeps a protected-branch refusal loud instead of leaving main armed), so write is justified.
No new injection surface: the three commits add zero run: lines. The pre-existing interpolations remain SHA-only via env (:93-94); $next in the fallback (:222, :232-237) derives from VERSION at the merge commit — repo content behind a write gate — and is expanded only inside quoted arguments, never into a shell command string.
Exposure: the widened token exists only in a push-triggered workflow executing code from main; there is no pull_request_target-style path by which fork-controlled content runs under it. An issues: write token on trusted-code-only steps is the same posture labels.yml already ships.

The comment-reshuffle commit (`0b6318f`)

Verified real: the intermediate wording contents: write # tag ref + gh release create + ... at line 38 would have become the first grep -n "gh release create" hit, inverting the tag-job ordering pin (test/release.sh:128-131, assert-precedes-create). The reworded comment restores assert_at=63 < create_at=76. The new comment lines also cannot trip the one-on.push-key count pin (test/release.sh:148-149, anchored ^ push:) — I re-ran the suite at head to confirm all 61 pins hold.

Everything else stands as reviewed at 0dbcad2: fork-token-proof push-to-main door, single on.push with both filters, fail-closed decide table, asserts-before-acts, same-job tag+publish anti-double-fire, and the surviving manual tag path.

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

## Verdict: Approve Re-review at new head e533e86 (previously approved at 0dbcad2). Three commits since, and the diff is exactly the fix-up round the thread describes: the `permissions:` block widened from `contents: write` alone to `contents: write` + `pull-requests: write` + `issues: write`, one comment reworded so it cannot pre-match a test pin, and CHANGELOG/CONTRIBUTING brought in line with the shipped design. No workflow logic changed — the trigger, decide table, asserts, tag+publish, and bump steps are byte-identical to the approved revision. Ran everything at the new head: `test/release.sh` 61/0, `test/cli.sh` 325/0, CI-exact shellcheck rc=0, and the YAML still parses to exactly one `on.push` mapping carrying both filters. ### Prior notes — status 1. **Bump-PR fallback 403 (my note 1) — RESOLVED, and it was worse than I'd scoped.** I had flagged only the fallback's `gh pr create`; the thread (via the cast#112 twin) correctly found that a declared `permissions:` block zeroes every unspecified scope, so the decide step's label read (`commits/$MERGE_SHA/pulls`, `.github/workflows/release.yml:158`) would ALSO 403 — meaning every genuine ceremony ended red at the label check, not just the rare protected-branch path. `.github/workflows/release.yml:37-45` now grants `pull-requests: write` (the label read needs read, which write includes; the fallback `gh pr create` at `:234` needs write) and `issues: write` (the `--label` at `:237` rides the issues API). Both consumers are named in comments, and the pair matches labels.yml's exact grant (`labels.yml:22-25`) for the same reason. 2. **CONTRIBUTING drift (my note 2) — RESOLVED.** `CONTRIBUTING.md:64-69` step 3 now describes the self-re-arm with the PR fallback, and correctly keeps the manual-tag path's bump as the operator's job. The CHANGELOG entry (`CHANGELOG.md:39-56`) likewise now tells the push-to-main/`event.before`/self-re-arm story instead of the superseded `pull_request` interlock. 3. **Bump race (my note 3) — unaddressed, still non-blocking** as stated: seconds-wide window, fast-forward-visible in history, worst case is an overwritten interleaved VERSION push. 4. **PR body test counts — still stale** (says 54; head is 61). The handoff comment has the right numbers. Cosmetic. ### Audit of the widened permissions - **Least-privilege check**: every scope has a named, real consumer — `contents: write` (tag ref `:203`, release `:205`, bump push `:230`), `pull-requests: write` (label read `:158`, fallback PR `:234`), `issues: write` (fallback `--label` `:237`). Nothing granted is unused. `pull-requests` could in principle be `read` if the fallback dropped PR creation, but the fallback is load-bearing (it is what keeps a protected-branch refusal loud instead of leaving main armed), so `write` is justified. - **No new injection surface**: the three commits add zero `run:` lines. The pre-existing interpolations remain SHA-only via `env` (`:93-94`); `$next` in the fallback (`:222`, `:232-237`) derives from VERSION at the merge commit — repo content behind a write gate — and is expanded only inside quoted arguments, never into a shell command string. - **Exposure**: the widened token exists only in a push-triggered workflow executing code from main; there is no `pull_request_target`-style path by which fork-controlled content runs under it. An `issues: write` token on trusted-code-only steps is the same posture labels.yml already ships. ### The comment-reshuffle commit (0b6318f) Verified real: the intermediate wording `contents: write # tag ref + gh release create + ...` at line 38 would have become the first `grep -n "gh release create"` hit, inverting the tag-job ordering pin (`test/release.sh:128-131`, assert-precedes-create). The reworded comment restores assert_at=63 < create_at=76. The new comment lines also cannot trip the one-`on.push`-key count pin (`test/release.sh:148-149`, anchored `^ push:`) — I re-ran the suite at head to confirm all 61 pins hold. Everything else stands as reviewed at 0dbcad2: fork-token-proof push-to-main door, single `on.push` with both filters, fail-closed decide table, asserts-before-acts, same-job tag+publish anti-double-fire, and the surviving manual tag path. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

dan-claude-bot commented

2026-07-19 16:54:54 +00:00

(Migrated from github.com)

@danmt — the hold is lifted: verification round unanimous at head e533e86. The post-approval fixes (permission trio, docs caught up to the shipped shape) are re-approved by all three bots. The handoff summary above stands — including the sequencing note: merge this before rig#46 and your merge of #46 ships rig 0.1.0 automatically. Ready for your review.

🤖 Generated with Claude Code

@danmt — the hold is lifted: **verification round unanimous at head `e533e86`**. The post-approval fixes (permission trio, docs caught up to the shipped shape) are re-approved by all three bots. The handoff summary above stands — including the sequencing note: **merge this before rig#46** and your merge of #46 ships rig 0.1.0 automatically. Ready for your review. 🤖 Generated with [Claude Code](https://claude.com/claude-code)