# 0.2.0 — drill record

Run 2026-07-24, by `claude-bot-andresmgsl`, against the release candidate
`heavy-duty/ceremony@682b9cb8929aa8c50a3101b64ca57fee7b09fef1` (PR #129's
head at drill time — the ceremony PR adds only `VERSION`, the assembled
section with its fragment deletions, the self-ref stamps, and this record;
no machinery differs between the drilled tree and the released one).

Where: scratch private repo `claude-bot-andresmgsl/ceremony-drill-0.2.0`,
carrying the `docs/CONSUMERS.md` caller stubs (modulo the pin deviation
below) and a fixture consumer tree in the **fragment shape** this release
exists to ship: `VERSION` `0.5.0-dev`, `CHANGELOG.md` preamble plus a
shipped `## 0.4.0` section, `changelog.d/` with its `README.md` marker and
two fragments, `drills/`, and the five guard actions in CI at the drill
ref. Archived after this record was written; deletion needs the
`delete_repo` scope this box's token deliberately lacks, so the operator
owns the final delete — the repo is the evidence's scaffolding, this file
is the evidence. Run ids below are kept for the record's own audit trail.

## The deviation: the self-drill deadlock recurs past the first release

The spec (#118) expected the 0.1.0 record's fork deviation to be moot —
"`0.1.0` exists, so the pinned path runs straight." It does not, for
ceremony's *own* drill: the candidate tree pins
`CEREMONY_SELF_REF: "0.2.0"` — the very stamp this PR makes — and the
consumer path checks out `heavy-duty/ceremony` at exactly that ref, which
cannot exist before the merge. What `0.1.0` existing does make moot is the
*consumer-side* deadlock: a governed repo drilling its own release pins
ceremony at a real tag and runs straight. Raised on #118 before drilling;
proceeded per the deviation triage already ruled for #11, unchanged in
shape: **no `0.2.0`-named ref on the canonical repo**; the scratch callers
pin the fork ref `claude-bot-andresmgsl/ceremony@drill/0.2.0` — the
candidate tree with exactly one line changed per pin carrier
(`release.yml` and `labels.yml`, both — `self-ref-check.sh` requires the
carriers to agree), `CEREMONY_SELF_REF: "0.2.0"` →
`"682b9cb8929aa8c50a3101b64ca57fee7b09fef1"`. Every `.ceremony-src` byte
the doors executed still came from `heavy-duty/ceremony` at the candidate
SHA (reachable there via PR #129's pull ref); the fork supplied
orchestration YAML differing by the one line the ceremony stamps each
release anyway. Drilling against `0.1.0` instead would not have been a
drill of the candidate: `lib/changelog.sh`, which both doors source for
notes extraction, is +214 lines since `0.1.0` (fragment mode; #98).

## The probes

| # | probe | run | result |
|---|---|---|---|
| a | merge-door ceremony, fragment shape | 30089779736 (attempt 1) | ✅ exactly one release |
| b | mislabeled ordinary PR | 30089842547 | ✅ green NOTICE no-op |
| c | bare-version PR, no label | 30089908740 | ✅ refused, red, created nothing |
| d | re-run of the completed ceremony | 30089779736 (attempt 2) | ✅ refused, red, created nothing |
| e | tag door, manual matching tag | 30090053523 | ✅ published, no bump |
| f | tag door, mismatched tag | 30090082676 | ✅ refused, red, created nothing |

**(a) The ceremony, in fragment shape.** PR `release: 0.5.0` — hand-set
`release` label, `VERSION` `0.5.0-dev` → `0.5.0`, and the stamp made by
the candidate's own `bin/changelog-assemble 0.5.0`: two fragments folded
into `## 0.5.0 — 2026-07-24` (newest issue first), deleted in the same
commit, `changelog.d/` left holding only its `README.md` marker — no
re-arm edit, armed by existing. The five guard actions at the drill ref —
`changelog-armed`, `changelog-monotonic`, `changelog-assembled`,
`drill-recorded`, `runner-isolated` — all green on that PR (run
30089703224): the assembled guard replayed the assembly from the merge
base and matched it byte-for-byte, live, on the mechanism this release
ships. Merged. The one run: facts
`ver='0.5.0' base_ver='0.5.0-dev' labeled='yes'` → `ceremony=yes` → tag
`0.5.0` on the merge commit (`9b9e58e`), release `0.5.0` published with
the assembled section — verbatim, both bullets — as its body, and main
re-armed to `0.5.1-dev` by the run itself. The GITHUB_TOKEN tag create
and bump push fired **no** second run (anti-recursion held).

**(b) Mislabeled ordinary PR.** Docs-only PR wearing the `release` label.
Green: `NOTICE: the version '0.5.1-dev' is -dev and unchanged by this PR —
release-flow work under the release label, not a ceremony. Nothing to
publish.` No tag, no release.

**(c) Bare-version PR without the label.** The ceremony's edits —
`0.5.1-dev` → `0.5.1`, a section assembled from a fragment — label
deliberately absent. Red at decide:
`the version transitioned ('0.5.1-dev' -> '0.5.1') but no merged,
release-labeled PR is behind this commit — a release is a labeled ceremony
PR, not a bare push — creating nothing.` No tag, no release; main
reverted to the armed state afterwards, and the revert push itself ran
green as a no-op (run 30090017774), as it should.

**(d) Re-run of the completed ceremony.** Re-ran (a)'s run. Red at the
nothing-may-exist assert:
`tag '0.5.0' already exists — this release already happened, or a manual
tag won the race; refusing to re-release, creating nothing.` Release
count still exactly one.

**(e) Tag door.** Branch with `VERSION` `0.6.0` and its section assembled
from a fragment; manual `0.6.0` tag pushed at its head (never merged to
main). The tag door published release `0.6.0` with that section as its
body; the merge door correctly skipped. Main untouched: `VERSION` stayed
`0.5.1-dev` — the fallback does not rewrite main.

**(f) Mismatched tag.** Tag `9.9.9` pushed at main (tree version
`0.5.1-dev`). Red:
`tag '9.9.9' does not match the tree's version '0.5.1-dev' — creating
nothing.` No release, and the operator-facing remediation text printed as
designed.

## Failures

None among the probes; every refusal path was checked for droppings — the
only releases and workflow-created tags that exist are (a)'s and (e)'s.

One finding outside the probe set, written down plainly: the fixture's
**initial push** — the very first commit of the scratch repo, caller
included — ran the merge door red (run 30089682128): `lib/facts.sh`
resolves the base as `MERGE_SHA^1` when `event.before` is all-zeros, and
a repo's first commit has no parent, so `git rev-parse` fails loudly
(exit 128) before deciding. Nothing was created, and every subsequent
push behaved; but a greenfield consumer bootstrapping caller-first will
meet one red run on its first push, which the doctrine's "every
legitimate non-ceremony is a green NOTICE no-op" does not intend.
`facts.sh` is unchanged since `0.1.0` — not a candidate regression, not a
blocker for this release; escalated as a discussion, not fixed here.