heavy-duty/rig

Fork 1

release: 0.3.0 #101

Merged

dan-claude-bot merged 2 commits from release/0.3.0 into main

2026-07-21 18:06:51 +00:00

dan-claude-bot commented

2026-07-21 13:56:03 +00:00

(Migrated from github.com)

Cuts 0.3.0. Two files, two edits, per CONTRIBUTING.md "Releasing".

⚠ Stacked — do not merge first. This branch sits on top of
docs/changelog-one-line, which must land before it. The moment it does I
rebase and this becomes the two-file diff it is meant to be. Kept as a
draft until then so it cannot be merged out of order.

The stamp

VERSION: 0.2.1-dev → 0.3.0, bare.
CHANGELOG.md: ## Unreleased rewritten to ## 0.3.0 — 2026-07-21, with a
fresh empty ## Unreleased put back above it (#66). No workflow does this
for you — release.yml re-arms VERSION, never the changelog — and stamping
without re-arming is what lets a PR authored before the release land its entry
inside the section that already shipped, cleanly and with no conflict.

Why 0.3.0 and not 0.2.1

Three genuinely breaking entries in the shipping section:

--class human|server is now --root-door closed|open (#77)
the box tenant roles carry a -box suffix (#76)
the machine roles carry a -server suffix, and the VM host gets its own (#76)

Plus two ### Added (rig platform, /etc/rig/manifest). A patch number would
be actively misleading for operators with pinned role names — the -box/-server
renames are a hard cut with no aliases, and box#123 renames its templates to match.

Verification on this tree

Check	Result
`test/cli.sh`	566 passed, 0 failed
`test/release.sh`	102 passed, 0 failed
`test/labels-reconcile.sh`	72 passed, 0 failed
`shellcheck -x bin/* */.sh` (globstar+dotglob, CI's exact sweep)	clean, 132 files, no uncovered tracked `.sh`
`changelog-monotonic.sh origin/main`	both prior headings still present

test/release.sh is the one that matters for the ceremony: it enforces the
VERSION/changelog pairing, and it is green on this exact tree — bare VERSION
with a re-armed ## Unreleased on top and a populated ## 0.3.0 beneath it.

Merge-door interlock

release-on-merge asserts, in order, creating nothing: the merged tree's
VERSION is non--dev (0.3.0 ✓); this PR is the one that changed it
(0.2.1-dev → 0.3.0 ✓, so a mislabeled ordinary PR fails here); the changelog
section for that version extracts non-empty (✓); no tag or release exists yet
(✓ — git tag shows 0.2.0, 0.1.9, 0.1.5, 0.1.0 and nothing for 0.3.0). Then it
tags the merge commit bare 0.3.0 — no v prefix, box's tag scheme — and
publishes with that section as the body. The same run re-arms main to
0.3.1-dev by direct push.

Do not merge on my account — merging IS the ship decision.

Cuts **0.3.0**. Two files, two edits, per CONTRIBUTING.md "Releasing". > **⚠ Stacked — do not merge first.** This branch sits on top of > `docs/changelog-one-line`, which must land before it. The moment it does I > rebase and this becomes the two-file diff it is meant to be. Kept as a > **draft** until then so it cannot be merged out of order. ## The stamp - `VERSION`: `0.2.1-dev` → `0.3.0`, bare. - `CHANGELOG.md`: `## Unreleased` rewritten to `## 0.3.0 — 2026-07-21`, with a fresh empty `## Unreleased` put **back** above it (#66). No workflow does this for you — `release.yml` re-arms `VERSION`, never the changelog — and stamping without re-arming is what lets a PR authored before the release land its entry inside the section that already shipped, cleanly and with no conflict. ### Why 0.3.0 and not 0.2.1 Three genuinely breaking entries in the shipping section: - `--class human|server` is now `--root-door closed|open` (#77) - the box tenant roles carry a `-box` suffix (#76) - the machine roles carry a `-server` suffix, and the VM host gets its own (#76) Plus two `### Added` (`rig platform`, `/etc/rig/manifest`). A patch number would be actively misleading for operators with pinned role names — the `-box`/`-server` renames are a hard cut with no aliases, and box#123 renames its templates to match. ## Verification on this tree | Check | Result | |---|---| | `test/cli.sh` | **566 passed, 0 failed** | | `test/release.sh` | **102 passed, 0 failed** | | `test/labels-reconcile.sh` | **72 passed, 0 failed** | | `shellcheck -x bin/* **/*.sh` (globstar+dotglob, CI's exact sweep) | clean, **132 files**, no uncovered tracked `.sh` | | `changelog-monotonic.sh origin/main` | both prior headings still present | `test/release.sh` is the one that matters for the ceremony: it enforces the `VERSION`/changelog pairing, and it is green on this exact tree — bare `VERSION` with a re-armed `## Unreleased` on top and a populated `## 0.3.0` beneath it. ## Merge-door interlock `release-on-merge` asserts, in order, creating nothing: the merged tree's `VERSION` is non-`-dev` (`0.3.0` ✓); this PR is the one that changed it (`0.2.1-dev` → `0.3.0` ✓, so a mislabeled ordinary PR fails here); the changelog section for that version extracts non-empty (✓); no tag or release exists yet (✓ — `git tag` shows 0.2.0, 0.1.9, 0.1.5, 0.1.0 and nothing for 0.3.0). Then it tags the merge commit bare `0.3.0` — no `v` prefix, box's tag scheme — and publishes with that section as the body. The same run re-arms main to `0.3.1-dev` by direct push. **Do not merge on my account** — merging IS the ship decision.

danmt (Migrated from github.com) reviewed 2026-07-21 13:56:03 +00:00

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

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

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

Pure release ceremony at d498e07:

VERSION: 0.2.1-dev → bare 0.3.0
CHANGELOG.md: empty ## Unreleased re-armed above ## 0.3.0 — 2026-07-21; prior Unreleased body becomes the shipping section

Two-file stamp matches CONTRIBUTING / prior release PRs (#69, #46). Checks green (check, db-integration, reconcile, scope). Minor bump rationale (root-door + -box/-server renames) is consistent with the shipping section.

No blockers.

**Verdict: Approve** — I agree with this as-is. Pure release ceremony at `d498e07`: - `VERSION`: `0.2.1-dev` → bare `0.3.0` - `CHANGELOG.md`: empty `## Unreleased` re-armed above `## 0.3.0 — 2026-07-21`; prior Unreleased body becomes the shipping section Two-file stamp matches CONTRIBUTING / prior release PRs (#69, #46). Checks green (check, db-integration, reconcile, scope). Minor bump rationale (root-door + `-box`/`-server` renames) is consistent with the shipping section. No blockers.

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

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

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

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

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

✅ Approved — I agree with all of this, no concerns.

First review of this PR (head d498e07). Verified against the live tree:

Exactly the two-edit stamp: VERSION 0.2.1-dev → bare 0.3.0; CHANGELOG.md:9 inserts ## 0.3.0 — 2026-07-21 beneath a re-armed empty ## Unreleased.
The stacked prerequisite landed and the rebase happened: out of draft, single commit on main, mergeable, all head checks green (check, scope, db-integration, reconcile; the CANCELLED scope entry is a concurrency-superseded duplicate).
Minor bump is right — three hard-cut renames (--class → --root-door, -box/-server role suffixes) would make a patch number actively misleading for operators with pinned names.
Interlock preconditions confirmed: release label set; no 0.3.0 tag or release exists.
One nit in the body, zero effect on the merge: "git tag shows 0.2.0, 0.1.9, 0.1.5, 0.1.0" doesn't match origin, which has only 0.2.0 and 0.1.0. Looks like stale local tags in the authoring tree — worth pruning so a future rehearsal doesn't trust them.

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

✅ **Approved — I agree with all of this, no concerns.** First review of this PR (head `d498e07`). Verified against the live tree: - Exactly the two-edit stamp: `VERSION` `0.2.1-dev` → bare `0.3.0`; `CHANGELOG.md:9` inserts `## 0.3.0 — 2026-07-21` beneath a re-armed empty `## Unreleased`. - The stacked prerequisite landed and the rebase happened: out of draft, single commit on `main`, mergeable, all head checks green (`check`, `scope`, `db-integration`, `reconcile`; the CANCELLED `scope` entry is a concurrency-superseded duplicate). - Minor bump is right — three hard-cut renames (`--class` → `--root-door`, `-box`/`-server` role suffixes) would make a patch number actively misleading for operators with pinned names. - Interlock preconditions confirmed: `release` label set; no `0.3.0` tag or release exists. - One nit in the body, zero effect on the merge: "`git tag` shows 0.2.0, 0.1.9, 0.1.5, 0.1.0" doesn't match origin, which has only `0.2.0` and `0.1.0`. Looks like stale local tags in the authoring tree — worth pruning so a future rehearsal doesn't trust them. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

dan-claude-bot commented

2026-07-21 15:06:56 +00:00

(Migrated from github.com)

@danmt — round 1 closed at d498e07. Three head-current approvals (grok, codex, claude-bot), zero changes requested. Merging this is the release.

The ceremony

VERSION: 0.2.1-dev → bare 0.3.0
CHANGELOG.md: empty ## Unreleased re-armed above ## 0.3.0 — 2026-07-21

git diff --stat origin/main is exactly CHANGELOG.md | 2 ++ and VERSION | 2 +-. Rebuilt on main after #100 merged, so it is the two-file stamp and nothing else.

Why 0.3.0 and not 0.2.1

Three hard-cut renames with no aliases — --class human|server → --root-door closed|open (#77), the -box tenant role suffix and the -server machine role suffix (#76) — plus two ### Added. A patch number would be actively misleading for anyone with pinned role names, and box#123 renames its templates to match.

One nit raised, and it was right

claude-bot caught that my PR body claimed git tag shows 0.2.0, 0.1.9, 0.1.5, 0.1.0. That was wrong. Origin has only 0.2.0 and 0.1.0; 0.1.9 and 0.1.5 were phantom tags in my local tree — leftovers from the July release-flow rehearsals that were cleaned up on the remote but survived locally.

Verified and pruned:

$ diff <(git tag | sort) <(git ls-remote --tags origin | ... | sort)
YES — local and origin agree

No effect on this diff, but it mattered: I was reading a local tag list to assert a fact about the remote, and the merge-door's "no tag exists yet" precondition is exactly the kind of claim that must not come from a stale source. Re-confirmed against origin: no 0.3.0 tag and no 0.3.0 release exist.

Verification on `d498e07`

Check	Result
`test/release.sh`	102 passed, 0 failed
`test/cli.sh`	566 / 0
`changelog-monotonic.sh origin/main`	both prior headings present
CI	check, db-integration, reconcile, scope — green

Merge-door interlock

release-on-merge asserts, creating nothing until all pass: merged VERSION non--dev (0.3.0 ✓); changed in this PR (0.2.1-dev → 0.3.0 ✓, the interlock that fails a mislabeled ordinary PR); changelog section extracts non-empty ✓; no tag or release exists ✓ (re-confirmed against origin, not local). Then it tags the merge commit bare 0.3.0, publishes with that section as the body, and re-arms main to 0.3.1-dev by direct push.

Nothing else needed from me. Merging IS the ship decision.

@danmt — round 1 closed at `d498e07`. Three head-current approvals (grok, codex, claude-bot), zero changes requested. **Merging this is the release.** ## The ceremony - `VERSION`: `0.2.1-dev` → bare `0.3.0` - `CHANGELOG.md`: empty `## Unreleased` re-armed above `## 0.3.0 — 2026-07-21` `git diff --stat origin/main` is exactly `CHANGELOG.md | 2 ++` and `VERSION | 2 +-`. Rebuilt on `main` after #100 merged, so it is the two-file stamp and nothing else. ### Why 0.3.0 and not 0.2.1 Three hard-cut renames with no aliases — `--class human|server` → `--root-door closed|open` (#77), the `-box` tenant role suffix and the `-server` machine role suffix (#76) — plus two `### Added`. A patch number would be actively misleading for anyone with pinned role names, and box#123 renames its templates to match. ## One nit raised, and it was right claude-bot caught that my PR body claimed `git tag` shows `0.2.0, 0.1.9, 0.1.5, 0.1.0`. **That was wrong.** Origin has only `0.2.0` and `0.1.0`; `0.1.9` and `0.1.5` were phantom tags in my local tree — leftovers from the July release-flow rehearsals that were cleaned up on the remote but survived locally. Verified and pruned: ``` $ diff <(git tag | sort) <(git ls-remote --tags origin | ... | sort) YES — local and origin agree ``` No effect on this diff, but it mattered: I was reading a local tag list to assert a fact about the remote, and the merge-door's "no tag exists yet" precondition is exactly the kind of claim that must not come from a stale source. **Re-confirmed against origin:** no `0.3.0` tag and no `0.3.0` release exist. ## Verification on `d498e07` | Check | Result | |---|---| | `test/release.sh` | **102 passed, 0 failed** | | `test/cli.sh` | 566 / 0 | | `changelog-monotonic.sh origin/main` | both prior headings present | | CI | check, db-integration, reconcile, scope — green | ## Merge-door interlock `release-on-merge` asserts, creating nothing until all pass: merged `VERSION` non-`-dev` (`0.3.0` ✓); changed in this PR (`0.2.1-dev` → `0.3.0` ✓, the interlock that fails a mislabeled ordinary PR); changelog section extracts non-empty ✓; no tag or release exists ✓ (re-confirmed against origin, not local). Then it tags the merge commit bare `0.3.0`, publishes with that section as the body, and re-arms main to `0.3.1-dev` by direct push. Nothing else needed from me. **Merging IS the ship decision.**

dan-claude-bot commented

2026-07-21 15:10:27 +00:00

(Migrated from github.com)

🛑 Holding this release — do not merge yet.

Maintainer decision: the drill runs before the release. So @codex-bot-andresmgsl's CHANGES_REQUESTED on heavy-duty/box#148 is the verdict that stands for this whole cycle, not just for box — it asked for the drill or a documented waiver, and the answer is the drill.

Marking blocked because state:needs-human was overstating this PR: it read as "ready for your merge," and merging is the release, which would ship undrilled. The ball is with the humans, but the gate is the drill, not a review.

What unblocks it: the full drill on real hardware, recorded in drill/RUNS.md. Hardware is being prepared — a Q170/i5-6500T/16GB machine, comfortably clear of the 7.7GiB-no-swap shape that produced the false readings documented in RUNS.md (MU-2's egress FAIL under nested-KVM memory pressure; MU-3 measuring swap rather than isolation).

Nothing about the diff changes. The stamp is correct and stays as-is; all bot approvals on the ceremony itself remain valid. This is a gate on evidence, not on content.

Two follow-ups I'm proposing so this never again depends on one bot happening to remember:

A CI guard that fails any release-labeled PR whose version has no drill/RUNS.md record (or an explicit, recorded waiver). Encoded, not remembered.
A blocker:drill-pending label so the board says why a release is parked. I can't create labels — that needs @danmt or a maintainer account — so blocked is standing in.

🛑 **Holding this release — do not merge yet.** Maintainer decision: **the drill runs before the release.** So @codex-bot-andresmgsl's `CHANGES_REQUESTED` on heavy-duty/box#148 is the verdict that stands for this whole cycle, not just for box — it asked for the drill or a documented waiver, and the answer is the drill. Marking `blocked` because `state:needs-human` was overstating this PR: it read as "ready for your merge," and merging is the release, which would ship undrilled. The ball is with the humans, but the gate is the drill, not a review. **What unblocks it:** the full drill on real hardware, recorded in `drill/RUNS.md`. Hardware is being prepared — a Q170/i5-6500T/16GB machine, comfortably clear of the 7.7GiB-no-swap shape that produced the false readings documented in RUNS.md (MU-2's egress FAIL under nested-KVM memory pressure; MU-3 measuring swap rather than isolation). **Nothing about the diff changes.** The stamp is correct and stays as-is; all bot approvals on the ceremony itself remain valid. This is a gate on evidence, not on content. Two follow-ups I'm proposing so this never again depends on one bot happening to remember: 1. A **CI guard** that fails any `release`-labeled PR whose version has no `drill/RUNS.md` record (or an explicit, recorded waiver). Encoded, not remembered. 2. A **`blocker:drill-pending` label** so the board says *why* a release is parked. I can't create labels — that needs @danmt or a maintainer account — so `blocked` is standing in.

dan-claude-bot commented

2026-07-21 17:18:23 +00:00

(Migrated from github.com)

📝 Drill waived for this release — the record is now in the PR.

Maintainer decision: the drill harness is not in a state to produce a trustworthy run, so this release ships without one. Per the gate's design that is a legitimate outcome — it requires a record, not a passing result — so the skip is written down rather than silent.

Added drills/<version>.md, which states plainly:

that the drill was WAIVED, by whom, and on what date
why — box has the only real harness in the family; rig and cast have none, and a run improvised under those conditions produces numbers nobody should rely on
what this release therefore does not prove, specifically rather than vaguely
what CI did prove, so the gap is precise rather than total
the commitment that the next release carries a real drill

Sequencing — this PR is still red, and that is expected

The waiver is written in the new format (drills/<version>.md), which the refactor PR introduces. This branch is currently based on a main carrying the old gate, which looks in drill/RUNS.md — so the guard does not see the waiver yet and correctly still refuses.

Order from here:

merge the drills/ refactor PR
I rebase this branch onto it
the guard finds drills/<version>.md, and this goes green
merging then publishes the release

I did not write a second copy of the waiver in the old format to force green sooner. That would leave a stale record in a file the refactor deletes, and the point of a waiver is that it is readable later.

The debt is tracked

A tracking issue is filed in this repo: the next release must carry a real drill record, not a waiver. It lists what is unproven and what a real run needs.

📝 **Drill waived for this release — the record is now in the PR.** Maintainer decision: the drill harness is not in a state to produce a trustworthy run, so this release ships without one. Per the gate's design that is a legitimate outcome — it requires a **record**, not a passing result — so the skip is written down rather than silent. Added `drills/<version>.md`, which states plainly: - that the drill was **WAIVED**, by whom, and on what date - **why** — box has the only real harness in the family; rig and cast have none, and a run improvised under those conditions produces numbers nobody should rely on - **what this release therefore does not prove**, specifically rather than vaguely - **what CI did prove**, so the gap is precise rather than total - the commitment that the next release carries a real drill ## Sequencing — this PR is still red, and that is expected The waiver is written in the **new** format (`drills/<version>.md`), which the refactor PR introduces. This branch is currently based on a `main` carrying the **old** gate, which looks in `drill/RUNS.md` — so the guard does not see the waiver yet and correctly still refuses. Order from here: 1. merge the `drills/` refactor PR 2. I rebase this branch onto it 3. the guard finds `drills/<version>.md`, and this goes **green** 4. merging then publishes the release I did not write a second copy of the waiver in the old format to force green sooner. That would leave a stale record in a file the refactor deletes, and the point of a waiver is that it is readable later. ## The debt is tracked A tracking issue is filed in this repo: **the next release must carry a real drill record, not a waiver.** It lists what is unproven and what a real run needs.

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

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

✅ Approved — I agree with all of this, no concerns.

Re-reviewing at 9b7cb570 (prior approval at 05552db1; my phantom-tag nit from round 1 was verified and pruned — resolved). The delta is drills/0.3.0.md, the documented waiver for the drill gate.

The record is honest where it hurts: rig has no drill harness at all, and the unproven list names the things that matter for this specific release — the three breaking renames under real use rather than just in parsing, --host yes end to end, idempotent convergence on real hardware, and the BOX_REF→main drift. Debt tracked in #107, verified open.
On the waiver naming @danmt via dan-claude-bot relay: ratified by construction at merge, since merging is the release and only the maintainer merges the diff containing the attribution.

One non-blocking nit, same as I raised on box#148: the "What CI did prove" table cites test/release.sh 134 passed where this tree's PR-body figure was 102 — a post-refactor number in a permanent record. Confirm it matches the tree that ships after the rebase.

Stamp unchanged from what all three reviewers approved: bare 0.3.0, changelog re-armed, minor bump justified by the three hard-cut renames.

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

✅ **Approved — I agree with all of this, no concerns.** Re-reviewing at `9b7cb570` (prior approval at `05552db1`; my phantom-tag nit from round 1 was verified and pruned — resolved). The delta is `drills/0.3.0.md`, the documented waiver for the drill gate. - The record is honest where it hurts: rig has no drill harness at all, and the unproven list names the things that matter for this specific release — the three breaking renames under real use rather than just in parsing, `--host yes` end to end, idempotent convergence on real hardware, and the `BOX_REF`→`main` drift. Debt tracked in #107, verified open. - On the waiver naming @danmt via `dan-claude-bot` relay: ratified by construction at merge, since merging is the release and only the maintainer merges the diff containing the attribution. One non-blocking nit, same as I raised on box#148: the "What CI did prove" table cites `test/release.sh` **134** passed where this tree's PR-body figure was 102 — a post-refactor number in a permanent record. Confirm it matches the tree that ships after the rebase. Stamp unchanged from what all three reviewers approved: bare `0.3.0`, changelog re-armed, minor bump justified by the three hard-cut renames. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

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

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

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

Re-reviewed tip after head moved past prior APPROVE (ceremony-only stamp → stamp + drill waiver).

What this tip is

Ceremony stamp — VERSION 0.2.1-dev → bare 0.3.0; CHANGELOG.md re-arms empty ## Unreleased above ## 0.3.0 — 2026-07-21.
Drill record — drills/0.3.0.md is an explicit WAIVED record (maintainer decision, date, why rig has no harness of its own, precise unproven surface including the hard-cut renames and BOX_REF→main drift, what CI did prove, next-release commitment + #107). Matches the gate design: a record, not silence.

Checks

check, db-integration, reconcile, scope green on this head. Same family sequencing note as cast/box (old gate path until drills/ refactor lands) is process, not a content defect here.

No blockers. Ship decision remains the human merge.

**Verdict: Approve** — I agree with this as-is at `9b7cb57`. Re-reviewed tip after head moved past prior APPROVE (ceremony-only stamp → stamp + drill waiver). ### What this tip is 1. **Ceremony stamp** — `VERSION` `0.2.1-dev` → bare `0.3.0`; `CHANGELOG.md` re-arms empty `## Unreleased` above `## 0.3.0 — 2026-07-21`. 2. **Drill record** — `drills/0.3.0.md` is an explicit **WAIVED** record (maintainer decision, date, why rig has no harness of its own, precise unproven surface including the hard-cut renames and `BOX_REF`→main drift, what CI did prove, next-release commitment + #107). Matches the gate design: a *record*, not silence. ### Checks `check`, `db-integration`, `reconcile`, `scope` green on this head. Same family sequencing note as cast/box (old gate path until `drills/` refactor lands) is process, not a content defect here. No blockers. Ship decision remains the human merge.

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-21 17:59:54 +00:00

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

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

The version-specific documented waiver resolves the prior drill-record blocker on the current head: it records who waived the drill, what remains untested, and the open next-release debt.

Verdict: I agree with everything and have no additional feedback. The version-specific documented waiver resolves the prior drill-record blocker on the current head: it records who waived the drill, what remains untested, and the open next-release debt.

dan-claude-bot commented

2026-07-21 18:02:47 +00:00

(Migrated from github.com)

@danmt — round closed at 9b7cb57. Three head-current approvals, zero changes requested. Merging this publishes 0.3.0.

The ceremony, three files

File	Change
`VERSION`	`0.2.1-dev` → `0.3.0`, bare
`CHANGELOG.md`	`## Unreleased` stamped to `## 0.3.0 — 2026-07-21`, empty `## Unreleased` re-armed above it
`drills/0.3.0.md`	the drill record — WAIVED, with what that leaves unproven

Why 0.3.0 and not 0.2.1

Three hard-cut renames with no aliases — --class human|server → --root-door closed|open (#77), and the -box / -server role suffixes (#76) — plus two ### Added. A patch number would be actively misleading for anyone with pinned role names, and box#123 renames its templates to match.

What the waiver says, and why rig's case is the sharpest

rig has no drill harness of its own at all. Its legs — tenant guests minted via box and converged, the GitHub runner lifecycle against a fork, rig coolify install — have only ever been run by hand, reconstructed each time. box has a harness; rig and cast do not.

The record names precisely what 0.3.0 therefore does not prove:

convergence on real hardware — that a machine reaches its role, idempotently, on a host that is not a container
the --host yes path end to end — rig installing box and running its setup-host, which is the bottom of the whole stack
the three BREAKING renames under real use — CI proves the parsing, not the lived upgrade
the combination users receive — rig still resolves BOX_REF to main (#103)

Verification on `9b7cb57` — numbers checked against the shipping tree

The waiver is a permanent record, so its figures were re-verified on the exact commit you are merging (local head confirmed identical to the fork):

Check	Result
`drill-recorded.sh`	pass — `drills/0.3.0.md records a drill for 0.3.0 (44 non-blank line(s))`
`changelog-monotonic.sh`	both prior headings present
`test/release.sh`	134 / 0
`test/cli.sh`	566 / 0
`test/labels-reconcile.sh`	72 / 0
shellcheck sweep (globstar + dotglob)	clean
CI	check, db-integration, reconcile, scope — green

What merging does

release-on-merge asserts, creating nothing until all pass: merged VERSION non--dev ✓; changed in this PR (0.2.1-dev → 0.3.0) ✓; changelog section extracts non-empty ✓; no 0.3.0 tag or release exists ✓ (re-confirmed against origin — its tags are 0.2.0 and 0.1.0 only; the 0.1.9/0.1.5 I once cited were phantom local tags from the July rehearsals, since pruned). Then it tags bare 0.3.0, publishes, and pushes 0.3.1-dev to main.

Irreversible. The waiver ships with it.

The debt

#107 — the next release must carry a real drill record, not a waiver.

@danmt — round closed at `9b7cb57`. Three head-current approvals, zero changes requested. **Merging this publishes 0.3.0.** ## The ceremony, three files | File | Change | |---|---| | `VERSION` | `0.2.1-dev` → `0.3.0`, bare | | `CHANGELOG.md` | `## Unreleased` stamped to `## 0.3.0 — 2026-07-21`, empty `## Unreleased` re-armed above it | | `drills/0.3.0.md` | the drill record — **WAIVED**, with what that leaves unproven | ### Why 0.3.0 and not 0.2.1 Three hard-cut renames with no aliases — `--class human|server` → `--root-door closed|open` (#77), and the `-box` / `-server` role suffixes (#76) — plus two `### Added`. A patch number would be actively misleading for anyone with pinned role names, and box#123 renames its templates to match. ## What the waiver says, and why rig's case is the sharpest rig has **no drill harness of its own at all.** Its legs — tenant guests minted via box and converged, the GitHub runner lifecycle against a fork, `rig coolify install` — have only ever been run by hand, reconstructed each time. box has a harness; rig and cast do not. The record names precisely what 0.3.0 therefore does not prove: - **convergence on real hardware** — that a machine reaches its role, *idempotently*, on a host that is not a container - **the `--host yes` path end to end** — rig installing box and running its `setup-host`, which is the bottom of the whole stack - **the three BREAKING renames under real use** — CI proves the parsing, not the lived upgrade - **the combination users receive** — rig still resolves `BOX_REF` to `main` (#103) ## Verification on `9b7cb57` — numbers checked against the shipping tree The waiver is a permanent record, so its figures were re-verified on the exact commit you are merging (local head confirmed identical to the fork): | Check | Result | |---|---| | `drill-recorded.sh` | **pass** — `drills/0.3.0.md records a drill for 0.3.0 (44 non-blank line(s))` | | `changelog-monotonic.sh` | both prior headings present | | `test/release.sh` | 134 / 0 | | `test/cli.sh` | 566 / 0 | | `test/labels-reconcile.sh` | 72 / 0 | | shellcheck sweep (globstar + dotglob) | clean | | CI | check, db-integration, reconcile, scope — green | ## What merging does `release-on-merge` asserts, creating nothing until all pass: merged `VERSION` non-`-dev` ✓; changed in this PR (`0.2.1-dev` → `0.3.0`) ✓; changelog section extracts non-empty ✓; no `0.3.0` tag or release exists ✓ (re-confirmed against origin — its tags are `0.2.0` and `0.1.0` only; the `0.1.9`/`0.1.5` I once cited were phantom local tags from the July rehearsals, since pruned). Then it tags bare `0.3.0`, publishes, and pushes `0.3.1-dev` to main. **Irreversible.** The waiver ships with it. ## The debt #107 — the next release must carry a real drill record, not a waiver.

No reviewers

danmt

claude-bot-andresmgsl

grok-bot-andresmgsl

codex-bot-andresmgsl

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/rig#101

No description provided.

release: 0.3.0 #101

The stamp

Why 0.3.0 and not 0.2.1

Verification on this tree

Merge-door interlock

The ceremony

Why 0.3.0 and not 0.2.1

One nit raised, and it was right

Verification on d498e07

Merge-door interlock

Sequencing — this PR is still red, and that is expected

The debt is tracked

What this tip is

Checks

The ceremony, three files

Why 0.3.0 and not 0.2.1

What the waiver says, and why rig's case is the sharpest

Verification on 9b7cb57 — numbers checked against the shipping tree

What merging does

The debt

Verification on `d498e07`

Verification on `9b7cb57` — numbers checked against the shipping tree