0.3.2

[danmt]

Cut the release of 0.3.2 by minting a release issue for it

[dan-claude-bot]

Minted: #190 — the 0.3.2 cut, blocked on #107 and on nothing else. This window's membership is now closed at five members, and the only thing left in it with your name on it is the drill afternoon.

What #190 says

It is specced against main at cc6af3e, so a builder claims it and starts rather than re-measuring the tree:

• VERSION 0.3.2-dev → bare 0.3.2, the fifteen fragments in changelog.d/ assembled into one stamped ## 0.3.2 section by changelog-assemble at ceremony 0.7.4, and the fragments consumed in the same commit. Nothing else in the diff.
• The assembly is already green. I ran changelog-assemble 0.3.2 --check against cc6af3e before writing the issue: exit 0, all fifteen fragments accepted, grouped ### Added / ### Changed / ### Fixed. No fragment needs repair first, so the work really is stamping.
• It says Refs #190, not Closes. The tag, the published release and the re-arm of main to 0.3.3-dev are only checkable after the merge, so the merge sends it to post-merge and triage closes it on that evidence. Cut the 0.3.1 release (the proof) #144 used Closes last cycle; refs-guard exists now and CONTRIBUTING item 5 says otherwise.
• The drill record is not in this PR. drills/0.3.2.md lands in The next release must carry a real drill record, not a waiver #107's own PR against a -dev tree — drill-recorded passes anything ending in -dev — and Cut the 0.3.2 release — bare VERSION, fifteen fragments assembled, the merge door tags and publishes #190 then stamps a bare version onto a tree that already carries it. No chicken-and-egg, and no reason for one builder to hold both.

Why it is minted blocked rather than ready

Your 11:38Z ruling stands: option A, no third waiver. drills/ still holds 0.3.0.md and 0.3.1.md and both are waivers, so drill-recorded would red this PR the moment VERSION goes bare. When your session happens — pass or fail — #107 closes on its record's PR and the sweep flips #190 to ready on its own.

So the board reads two blocked issues in a line, which is honest rather than tidy: one operator afternoon, then two ordinary builds. What your directive bought is that the second of those builds is now written down and readable at leisure instead of being drafted in the same hour as the tag.

One decision came out of specifying it, and it is yours to overturn

BOX_RELEASE reads 0.9.0; box published 0.9.1 on 2026-08-04. CONTRIBUTING says each release "deliberately bumps and drills the BOX_RELEASE pin", so at the letter this cycle is short. I have decided it rather than asked it, because it is reversible until the tag and because the alternative costs you the afternoon you already have:

• 0.3.2 ships 0.9.0, and the bump is 0.3.3's first issue. rig 0.3.2 — the registry finishes its move, and the drill stops being a waiver #182's third acceptance criterion is that the refs the drill pinned are the refs 0.3.2 ships. A bump landing after your session invalidates its evidence; a bump landing before it puts a build in front of an afternoon that is unblocked today.
• One word overturns it — say so and the bump is minted immediately, lands before the session, and your --box-ref becomes 0.9.1. It is not a decision that can be taken after the run.

And one correction to the runbook I have been giving you

The command in #173 omits --rig-ref and --box-ref. drill.sh requires both and exits 2 in pre-flight without them — deliberately, since #103: an unstated ref means the installers quietly use their defaults and the record looks like evidence. drill/README.md has always carried them; my condensation dropped them. The corrected command is on #173, together with the BOX_RELEASE decision above, since that is what --box-ref has to say.

Closing this thread — the ask is discharged and #190 is the record. #173 stays the door for the session, and it is the one place worth replying if you want the box pin bumped first.