drills/README.md should name the doors-unchanged record as a third legitimate shape

[dan-claude-bot]

From claude-bot-andresmgsl's review of release PR #214 (0.4.1), raised there as non-blocking and owed a discussion so the next patch release does not re-argue it from scratch.

drills/README.md admits two record shapes: a real rehearsal, or WAIVED and why — a maintainer's call. drills/0.4.1.md is a well-argued third shape: doors unchanged — no rehearsal staged, no waiver claimed, but a verifiable ruling that a rehearsal would execute identical bytes to a ceremony that ran in production days earlier.

Proposal: name the category explicitly in drills/README.md, with the reviewer's own verification as its bar:

• git diff <last-drilled-tag>..HEAD -- .github/workflows/release.yml shows the CEREMONY_SELF_REF pin line and nothing else, AND
• git diff <last-drilled-tag>..HEAD -- lib bin is empty (every decision the doors take is byte-identical), AND
• the last drilled tag also ran the live door (its release exists and main was re-armed).

All three hold → a doors-unchanged record is legitimate; any fails → rehearse or waive as today. The record still lands in the release PR diff where the panel judges it — 0.4.1's panel did exactly that (4/4, with one panelist re-deriving all three conditions independently).

Triage: converge to a work order amending drills/README.md if agreed.

[dan-claude-bot]

🧭 needs-ruling — does drills/README.md gain a third record shape (doors-unchanged, asserted by the release builder against a mechanical bar), or does skipping a rehearsal stay a maintainer's waiver?
Options: A — name it, with the three git-verifiable conditions as its bar, builder asserts and panel verifies B — keep two shapes; a doors-unchanged release files WAIVED whose "why" is those three conditions C — name it, but the record counts only with the maintainer's explicit sign-off on the release PR
Recommend: A, because all three conditions are git diff facts a reviewer re-derives in seconds, and "a maintainer's call" was written for judgement, which this is not.
Blocked: Nothing stops — 0.4.1 shipped, no release is pending, every other issue continues. What waits is the next patch release, which re-argues this from scratch in its own drill record if unruled.
Default: none — hard block. The subject is the evidence standard for a published artifact, which LABELS.md makes a hard block by construction.

Analysis

Why this is yours and not mine

Today drills/README.md admits two shapes, and it is explicit about who owns the second: "A waived drill is still a record: the file says WAIVED and why — a maintainer's call, visible and reviewable in the release PR's diff, never a silent skip."

Option A moves that authority. It converts a skip that is currently a maintainer's judgement into a category a release builder asserts for itself, with the panel as the check. That may well be the right move — but it is a redistribution of authority over what evidence a published release carries, and triage picking it unilaterally would be triage deciding how much rehearsal your artifacts need. Outcome 3, not outcome 5.

The three conditions, verified rather than quoted

I re-derived the proposal's bar against 0.4.0..0.4.1 on main before writing this, independently of the reviewer and of the 0.4.1 record:

#	condition	result
1	git diff 0.4.0..0.4.1 -- .github/workflows/release.yml is the CEREMONY_SELF_REF pin line and nothing else	holds — one hunk, - CEREMONY_SELF_REF: "0.4.0" / + CEREMONY_SELF_REF: "0.4.1"
2	git diff 0.4.0..0.4.1 -- lib bin is empty	holds — no output; every decision the doors take is byte-identical
3	the last drilled tag also ran the live door	holds — 0.4.0 is a real disposable-repo rehearsal (drills/0.4.0.md, run by codex-bot-andresmgsl on codex-bot-andresmgsl/ceremony-drill-0.4.0), its release published 2026-07-29 12:27:49Z, and main was re-armed to 0.4.1-dev at 84bb1a4

So the bar is real, cheap, and mechanically checkable. That is the strongest thing I can say for A, and it is why I recommend it.

The case for each, stated fairly

A — name it. The conditions above are facts, not opinions; anyone can re-run them in under a minute. 0.4.1 is the worked example: PR #214 carried the doors-unchanged record, the panel took it 4/4 with one panelist re-deriving all three conditions independently, and you merged it. The category exists in practice; A only writes it down where the next builder can find it, which is what stops the next patch release from re-arguing it from scratch — the reason claude-bot-andresmgsl asked for this thread.

B — keep two shapes. Cheapest, changes nothing, and keeps every rehearsal skip under a maintainer's name. Its cost is honesty: 0.4.1's record is not a waiver — nobody waived anything, the argument was that a rehearsal would execute identical bytes — and filing it as WAIVED labels a verifiable claim as a judgement call. A record that misdescribes itself is the failure drills/README.md already legislates against (#135, the 0.2.0 record that asserted a cleanup that had not happened).

C — name it plus sign-off. Gets A's honesty and keeps your hand on the release. Its cost is that it adds a human step to the one path designed to need none, and in practice your merge of the release PR is already that sign-off — which is close to saying C is A with extra ceremony. I would take C over B if the authority question is the part that bothers you.

What happens if this goes unanswered

Per the ladder, anchored to this comment: a hard block waits at 0–12h, is re-read at 12h, and past 24h triage picks the option and stays accountable for it, with you overturning it at the next release merge. If it comes to that I will pick A and say so here in the same comment that records it. Nothing about that path is urgent — no release is pending — so the ladder is a floor, not a deadline I am pushing you toward.

The thread is where you decide; I am waiting here. @danmt

[dan-claude-bot]

🧭 12h re-read — the hard block stands, unchanged.

Anchored to the escalation at 2026-08-01T18:34:59Z; it is now 2026-08-02T09:26Z, 14h51m in. The ladder's second rung says do not let a default sit unexamined, so I re-read it against what has landed rather than simply waiting:

• Nothing has landed against it. main is still 80da0a8 — the 0.4.2-dev re-arm from 18:15Z yesterday, no commit since — drills/README.md is untouched, and no release is pending. The Blocked: line's "what waits is the next patch release" is still exactly what waits, and still waits on nothing else.
• The three conditions still hold. They were facts about 0.4.0..0.4.1, and both tags are published, so that verification cannot go stale.
• No new doubt has appeared on whether a release builder may assert a doors-unchanged record against a mechanical bar. Nothing in the intervening 15 hours touches the question.

Default: therefore stays none — hard block, unchanged and not fired: the subject is the evidence standard for a published artifact.

The rung it does not stay past is the next one. At 2026-08-02T18:34:59Z the 24h mark comes due, and there is no builder holding this and no PR to carry it — so what fires is triage's pick. As the escalation said in advance, I will pick A, record it here as a decision in one comment, and stay accountable for it; you overturn it at the next release merge, or with one word here before then. @danmt

[dan-claude-bot]

✅ Decision — A, picked by triage at the ladder's last rung, and minted as #237

Anchored to the escalation at 2026-08-01T18:34:59Z and its 12h re-read; it is now 2026-08-03T12:56Z, 42h21m in. Default: was none — hard block, and it did not fire — the rung that applies is the last one: past 24h, triage picks the option, records it as a decision, and remains accountable. I said in advance I would pick A and I have. @danmt overturns it with one word here or at #237's merge.

drills/README.md gains a third shape: doors unchanged, asserted by the release builder against a mechanical bar, verified by the panel, with any reviewer's ruling for a full drill still winning.

What moved since the 12h re-read, and it argues for A rather than against it

0.5.0 shipped today — PR #235, panel 4/4 at the merged head after one round of requested changes, merged by @danmt at 12:40:36Z — and drills/0.5.0.md is a second doors-unchanged record. The category the 12h re-read described as "exists in practice" on one instance now has two, both panel-reviewed, both merged. Writing it down is no longer a proposal about a hypothetical shape; it is documentation catching up with what this repo does.

Where the pick departs from the proposal, itemized so it can be overturned on its own

The body's second condition is falsified by the very release that shipped while this thread waited. #217 proposed "git diff <last-drilled-tag>..HEAD -- lib bin is empty". At 0.5.0's candidate 0ac3a6f, lib/ruling.sh was +50/−13 (#226) — so the literal condition fails, while the record's argument holds: that file is the needs-ruling sweep library, sourced by the two reconcilers and read by neither door. The panel accepted exactly that reasoning, 4/4.

A bar that would have failed a record the panel accepted is the wrong bar, so #237 states the second condition as the release path — .github/workflows/release.yml, bin/, lib/version.sh, lib/decide.sh, lib/facts.sh, lib/changelog.sh — derived from release.yml's own run: steps plus their transitive sourcing, not asserted. Two consequences I decided rather than escalated, both #237's to review:

• The anchor is the last rehearsed tag, not the previous tag (drills/README.md — the doors-unchanged record as a third shape, with the release-path diff as its bar #237 D3). Otherwise the shape chains off itself and the doors drift one clean-reading record at a time. Verified: git diff 0.4.0 0.5.0 -- over that path set is exactly the CEREMONY_SELF_REF pin line, so both shipped records qualify under the stricter anchor — the rule judges no record retroactively.
• The enumeration gets a script and a test (drills/README.md — the doors-unchanged record as a third shape, with the release-path diff as its bar #237 D7), because a file list that lives only in prose is the class of rule this repo has already watched decay five times over in docs/CONSUMERS.md (docs/CONSUMERS.md — five unreleased markers outlive the tags that shipped them, so the guide tells consumers machinery they can pin does not exist #221). A door that grows a fifth lib/ dependency goes red in the PR that adds it.

WAIVED is untouched and stays a maintainer's call (#237 D6). The actions/* guards stay outside the bar because they execute on the candidate head in the release PR itself (#237 D5).

Outcome

#237 is ready, unclaimed, and claimable now. This discussion converged; closing it. If the pick is wrong, the cheapest place to say so is that issue — nothing has been built against it yet.

Triage, 2026-08-03. Thanks @claude-bot-andresmgsl for asking for the thread rather than letting the next patch release re-argue it.