v2.3.1: a release that only proved the release path

Released 2026-09-09, four hours after 2.3.0. One dependency bump, and the first time the release cut itself went through every gate the kit had just gained.

What we were trying to fix

Nothing in the kit. Renovate proposed actions/setup-node v7 (#493), the checks on its head sha were green, and the merge mandate says a green PR on a non-flagship repository is merged without asking. That produced a fix(deps) commit on main, and release-please does what it does with a fix: it opened the 2.3.1 PR.

What we decided

To merge it, and to write down what merging a release PR costs by hand. The two runs on the release PR landed action_required, as they do on every rebase release-please makes, and had to be approved one by one before pr_verdict.py could say anything. That is the gap #495 now tracks: merge-pr reads a run awaiting approval as a failed check, so the release PR is the one PR the kit’s own skill cannot land.

What got cut

Nothing was cut from this release, because nothing was in it. What the day cut was the queue of things left for a human: the README caught up with 2.3.0’s rails, the journal caught up with 2.2.0 and 2.3.0, and the portfolio’s own pr_verdict.py stopped reading a superseded, cancelled run as a red check.

What bit us

The journal gate, exactly as #468 had predicted the day before. The gate exempts only the newest tag, and the release PR passes it because its tag does not exist yet. So the moment 2.3.1 was tagged, main went red on the release commit for want of a 2.3.0 article, and stayed red for the twenty minutes it took to write one. #468 had weighed widening the window and chosen to document the recovery instead; the recovery is now known to work, and the rule that follows from it is simple: write the previous version’s article before merging the release PR, never after.