2026-07-18 18:31:53 +00:00
# Contributing
2026-07-23 00:29:20 +00:00
This repo is governed by
[heavy-duty/ceremony ](https://github.com/heavy-duty/ceremony ). **Agents:
read [`.ceremony/AGENTS.md` ](.ceremony/AGENTS.md ) first** — it routes you to
your role file (builder, reviewer, triage), vendored beside it,
byte-identical to ceremony at the pin named in
[`.github/workflows/release.yml` ](.github/workflows/release.yml ) and
guarded by the `docs-sync` step in CI. The review-round doctrine — drafts,
whole-round replies, verdicts, the handoff — lives there and in
[`.ceremony/LABELS.md` ](.ceremony/LABELS.md ); this file keeps only what is
genuinely rig's.
## The PR loop, rig specifics
2026-07-18 18:31:53 +00:00
1. **Fork and branch.** Contributors work from forks; upstream branches are
for maintainers. Title the PR conventionally (`feat:`, `fix:` , `docs:` ).
2026-07-23 00:29:20 +00:00
2. **The review panel** (`.github/labels.conf`'s `panel=` line):
2026-07-30 17:49:39 +00:00
`cluade-reviewer-andresmgsl` , `codex-reviewer-andresmgsl` ,
`grok-reviewer-andresmgsl` , `kimi-reviewer-andresmgsl` —
2026-07-23 00:29:20 +00:00
the required verdicts for a PR are the panel minus its author. The
maintainer (`danmt`) takes the last word and merges.
3. **Checks must be green** : `shellcheck` , `bash test/cli.sh` and
2026-07-18 20:57:13 +00:00
`bash test/release.sh` locally mirror what CI runs; the db dump/restore
round-trip (`test/db-integration.sh`) executes in CI where Docker is
2026-07-23 00:29:20 +00:00
present. The release guards (`changelog-armed`, `changelog-monotonic` ,
2026-07-24 18:37:44 +00:00
`changelog-assembled` , `drill-recorded` , `runner-isolated` , `docs-sync` )
run as ceremony's pinned actions.
2026-07-24 13:55:28 +00:00
4. **Feature PRs land their changelog entry as part of the PR** : write
`changelog.d/<issue>.md` — the release PR assembles those fragments into
the release notes verbatim.
2026-07-18 20:57:13 +00:00
2026-07-21 13:50:43 +00:00
## Changelog entries
2026-07-24 13:55:28 +00:00
Every PR that changes behaviour writes one `changelog.d/<issue>.md` fragment.
The fragment keeps the relevant `### Added` / `### Changed` / `### Fixed`
heading above its entry. One line is the whole rule — if it wraps more than
twice in your editor, cut it down.
2026-07-21 13:50:43 +00:00
- **Say what changed, and stop.** Why it was wrong, how it was found, what it
cost, what it implies — that belongs in the PR body and the commit message,
which is where anyone chasing the reasoning already goes. This file answers
one question: what is different in this version.
- **Any word that can be removed, is removed.**
- **Lead with the surface, not the mechanism.** "`state:needs-human` is set at
handoff" beats "the labels workflow now also wakes on `labeled` ".
- **Cite the issue or PR** — `(#96)` — and let the reader follow it for the
rest.
- **Mark a breaking change** with a leading `BREAKING:` .
- Group under `### Added` / `### Changed` / `### Fixed` / `### Removed` .
- No bold run-in headings, no sub-paragraphs, no code blocks, no prose essays.
Good:
- `state:needs-human` is set at handoff, not by the cron (#96)
- An unreadable check rollup no longer reads as "nothing is failing" (#90)
- BREAKING: `--class human|server` is now `--root-door closed|open` (#77)
Not an entry — that is a PR body:
- **`state:needs-human` no longer waits on the cron to become true** (#96) —
the labels workflow now also wakes on `pull_request_target: labeled` and
`unlabeled` , and the author sets it themselves when handing a PR over. A
review landing was never a trigger. There is no `pull_request_review_target` ,
and on fork PRs — which is all of them here — ...
2026-07-18 20:57:13 +00:00
## Releasing
2026-07-23 00:29:20 +00:00
A release is a PR, and merging it is the release. The ceremony — the two
doors, the decide table, the stamps, the post-release re-arm — is
heavy-duty/ceremony's machinery, consumed by reference:
[its README ](https://github.com/heavy-duty/ceremony/blob/main/README.md )
is the doctrine, `.github/workflows/release.yml` here is the ≤20-line
caller pinning it, and the guards run in `ci.yml` from the same pin.
Bare `X.Y.Z` tags, no `v` ; the tag's source tarball is the package
2026-07-23 23:56:54 +00:00
`install.sh` downloads — rig ships no other artifact. Each release deliberately
bumps and drills the `BOX_RELEASE` pin in `commands/bootstrap.sh` ; it must never
float to a moving ref.
2026-07-23 00:29:20 +00:00
What stays rig's is the **drill** — the real-hardware gate before the
2026-07-24 00:34:30 +00:00
handoff of a release PR, run by `drill/drill.sh` (#105): `rig bootstrap`
converging the machine to its role twice with the second run diffed empty,
2026-07-23 00:29:20 +00:00
`test/db-integration.sh` , the runner lifecycle against a fork, a coolify
install. Rig's drill asserts **convergence** (a machine reaches its role,
idempotently), it runs `--host yes` with `BOX_REF=release/<box-version>` so
it exercises the box that will actually ship, and drills that share a
substrate share **one run ID** so the per-repo records can be joined after
the fact. The full meaning — the fixed candidate-ref pinning that dissolves
the box↔rig recursion, the per-version record files, the waiver rule — is
[`drills/README.md` ](drills/README.md ); the `drill-recorded` guard enforces
the record on every release tree.
feat: merging a release-labeled PR is the release (#47)
The rig twin of heavy-duty/box#96, from the release-ceremony retro: the
tag was a separate, manual, silent-when-forgotten step, and a forgotten
tag produces no red X — the worst failure shape. The ship decision
already lives in the release PR; merging it is "ship". After that,
tagging is transcription, and transcription belongs to machines.
release.yml now also fires on pull_request closed into main, gated on
merged AND the `release` label. The job asserts in order, each fail-loud
and creating nothing: VERSION at the merge commit is non--dev; VERSION
changed in THIS PR (base vs merge — the interlock that fails a
mislabeled ordinary PR); the changelog section for that version extracts
non-empty via the existing changelog_section from release-lib.sh; and no
tag or release exists yet. Then, in the same job, it API-creates the tag
at the merge commit and publishes the release with the extracted notes.
Same-job is load-bearing: a GITHUB_TOKEN-created tag does not fire the
tag-push trigger, so the publish must live next to the tag and the
fallback job cannot double-publish; the nothing-exists assert covers a
manual race. The tag-push path survives verbatim as the documented
manual fallback and backfill, and CONTRIBUTING's Releasing section now
reads merge-is-ship with the manual tag as fallback.
test/release.sh pins the merge path in the house grep-pin 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.
Fixes #47
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-19 15:19:47 +00:00
2026-07-18 18:31:53 +00:00
## Labels — who sets what
2026-07-23 00:29:20 +00:00
The taxonomy and state machine are
[`.ceremony/LABELS.md` ](.ceremony/LABELS.md ); rig's `scope:*` rows live in
`.github/labels.conf` (reconciled by the labels caller) and their path map
in `.github/labeler.yml` . What matters day to day is who sets each kind —
most of it is machinery, and hand-moving a machine-owned label just gets
corrected on the next pass:
2026-07-18 18:31:53 +00:00
| Labels | Set by |
|---|---|
2026-07-23 00:29:20 +00:00
| `state:*` | the labels workflow ([.github/workflows/labels.yml](.github/workflows/labels.yml)) — recomputed from GitHub's own facts on PR events (label changes included) and every 15 minutes. Machine-owned, with one exception: the author sets `state:needs-human` at handoff and the workflow reconciles it. Otherwise never by hand. Exactly one per PR: *whose ball is it.* |
2026-07-20 18:40:12 +00:00
| `blocker:*` | the same workflow, from the same facts — *what is in the way.* Any number per PR, or none. Never by hand: applying one does not stop a merge, and removing one does not unblock anything. Fix the thing and the next sweep drops the label. |
2026-07-18 18:31:53 +00:00
| `stale` | the same workflow — 48h without commits, comments, or reviews. `blocked` PRs are exempt: they are quiet legitimately. |
| `scope:*` on PRs | actions/labeler, from the changed paths ([.github/labeler.yml](.github/labeler.yml)). Additive — you may add more, the machine won't remove them. |
| `scope:*` on issues | you, when opening or triaging — issues have no paths to derive from. |
| `blocked` , `release` | you — automation never guesses intent. |
2026-07-20 18:40:12 +00:00
| `merge-next` | you or the agent owning the queue. Which PR lands first is a judgement about how they conflict, so the workflow never sets it — it only **clears** it, the moment the PR stops being something a human could merge. |
2026-07-18 18:31:53 +00:00
| `bug` / `enhancement` / `documentation` | you, on issues only — a PR's type already lives in its title. |
## Issues
Give issues the same care as PR titles: say the surface in the title, apply a
`scope:` label and a type label (`bug` / `enhancement` / `documentation` ) when
you open one, and `blocked` when it waits on something — that is what keeps
the board navigable as the issue count grows.
