The re-arm section corrected last round said the bump runs after publish and
its refusal leaves a release standing; the overview still promised an
unconditional -dev re-arm and zero artifacts on any failed assert. Scope the
guarantee to the asserts before the publish, name the rc exception where the
reader meets it first, and stop calling a malformed version's refusal
unreachable - only the -dev half is.
The rc path is how this refusal is reached, not 'the one door an
operator actually walks through' -- most releases are bare and never
see it. Also rewrap the npm paragraph, left ragged by the previous
commit.
version_is_dev's range started one line in, past the signature comment
that states the -dev-only rule; and the npm range stopped at L112,
before the npm pkg set / npm install --package-lock-only lines it was
cited for. L68-L76 and L114-L115.
The section called version_next_dev's refusal unreachable by reading
decide's sense of 'bare' (not -dev) into version_next_dev's regex
(^X.Y.Z$). An rc lives between the two: row 6 admits a labeled rc
transition as a shippable ceremony, the bump step gates only on
ceremony=yes, and its VER is the tree's version verbatim -- so an rc
release tags, notes, publishes, then refuses here. State that path and
its remedy (version.sh L78-L82: an rc's next version is a human
decision), keep the guard reading for the -dev/garbage half that really
is unreachable, and close the same conflation in row 6.
Also: version_write runs npm pkg set + a lockfile-only install, not
npm version (which would tag); and drop 'unarmed main' so the section
uses release.yml's one sense of armed.
Reported by claude-bot-andresmgsl on #315.
Self-caught while re-reading the section added in 87f300c. It said
version_next_dev's refusal was "the tag door's edge" — wrong twice. The tag
door does not bump at all (release.yml:303-307, cast's precedent: the
fallback does not rewrite main), and the merge door's bump runs only on
ceremony=yes, which decide rows 5-6 reach only on a transition TO bare. The
message is therefore unreachable through either door as they stand, and the
honest description is a guard against a future decide change, not an edge an
operator can hit today.
Writing a troubleshooting entry that sends an operator looking down the tag
door for a message the tag door cannot emit is the same defect this round is
fixing one paragraph up, so it does not get to ship in the fix.
The drill paragraph called incubator's drill "TBD". It has been defined in
heavy-duty/incubator since 2026-07-23 (f7851cb, refined 7c20a4e on 07-24):
the pre-release verify of the canonical candidate deployed to staging, its
smoke probe run inside the container on deployed credentials, the record
pinning commit SHA and image digest. Carried from main unmeasured, which is
the one thing D1 forbids. With incubator named the paragraph enumerates five
meanings, not three, so its own tally closes now too.
The refusal catalog claimed to be generated from the sources, but its
regeneration grep never read lib/version.sh — the four version_read messages
it quotes all live there. Adding version.sh to the documented command turned
up four more refusals the catalog was missing: unknown backend on the read
side, and version_next_dev / version_write's two on the post-release re-arm,
which release.yml:275,283 really can emit. The re-arm ones get their own
section because their remedy is unlike every other entry here — the tag and
the publish already happened, so the fix is a manual bump, not a re-run.
One refusal stays outside the grep by construction: "no version field" is a
console.error inside the node one-liner, with no >&2 and no "refuse ". The
section now says so rather than shipping a command that silently
under-produces the catalog it claims to generate.
Answers codex-bot-andresmgsl and kimi-bot-andresmgsl (blocking, both the
incubator claim) and claude-bot-andresmgsl nit 2, at head 57a7b15.
The changelog-armed 'Red means' list credited armed with catching a
release that publishes fewer entries than its consumed fragments — armed
cannot see consumed fragments; that is changelog-assembled's merge-base
replay. And the assembled narrative still said a fragment dropped from
the deletion leaves armed green; the trio rows record the opposite: a
surviving fragment reds armed too ('not consumed'), and assembled stands
alone only on the consumed-but-omitted and hand-edited shapes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CONTRIBUTING's flow item, BUILDER.md's entry rule, and the PR template
checklist all point at changelog.d/<issue>.md; the insert-above warning
retires with its anchor while the monotonic guard keeps the case (#117).
Stamp 2 is one assembler-produced edit; changelog-armed's rule is stated
mode-first (fragment, then legacy, #112 D7/D8/D9); changelog-assembled
gets its operator section (#116); monotonic records D10; the two rewritten
error strings and the retired re-arm recovery follow (#117).
Round 1 (PR #48): codex-bot flagged the release-only bump described as a
one-line uses change while the same-tag rule two bullets up requires every
reference on one tag — a release-only setup has four (release caller +
three guards), so a one-line bump splits the consumer across versions.
The bump bullet and the pin-bump procedure now both require every ceremony
uses: reference updated together. Also the README called lib/decide.sh a
5-state table; the spec comment and rendered table have six rows.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
What a release is (the three stamps, box#108's two-edit rule), the two
doors, the decide table rendered for operators, the three guards with
their incidents, the drill doctrine, the verbatim refusal catalog with
cause and remedy, and the design lineage. Condensed from the box/rig/cast
CONTRIBUTING essays per #1 D8; every workflow-behavior claim links the
line or the spec issue.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Issue #12 writes the doctrine into README.md; the extensionless
placeholder was the 12-byte stub triage's readiness note called out.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
