From b92ef31897024075b54dd784bd4dbf91b26d4ebf Mon Sep 17 00:00:00 2001 From: JohnnyT Date: Sun, 27 Sep 2026 09:34:59 -0600 Subject: [PATCH] Says the merged release prep's tag is the conductor's release.md and commit.md still described the tag of a release prep as the operator's. CLAUDE.md now carries a separate tag row and a Release preps paragraph: once the version bump is merged to origin/main, the conductor or the session that owns the release bead tags that merged commit with the new version. Both guides now say so in their own words, and both keep the publish (mix hex.publish) as the operator's. release.md also named the 2.4.0 prep as the most recent release prep; it now names the 2.9.0 prep, f2365bb, which is tagged v2.9.0, touched exactly the four files the table lists, moved the README pin from ~> 2.8 to ~> 2.9, and kept the version reasoning in its commit body. Docs only: no path in the gate's build_paths changes, and agent tooling takes no changelog fragment. Refs: st-tnov, st-48z7 --- .claude/wurk/commit.md | 8 +++++--- .claude/wurk/release.md | 34 ++++++++++++++++++++++------------ 2 files changed, 27 insertions(+), 15 deletions(-) diff --git a/.claude/wurk/commit.md b/.claude/wurk/commit.md index ef3db82a..124f6bf1 100644 --- a/.claude/wurk/commit.md +++ b/.claude/wurk/commit.md @@ -43,9 +43,11 @@ the public API tell the difference? If not, no fragment. Releases follow SemVer from 2.0.0 on (ADR-0066) and ship to Hex. The `mix.exs` version field moves only in a release-prep commit - the version bump plus the changelog promotion, landing alone in its own PR, under a -consent that names it - and the tag and publish that follow are always the -user's. Never edit the version field as part of any other commit; a diff -that touches it alongside other work is a bug in the diff. +consent that names it. Once that prep is merged to `origin/main`, the +conductor or the session that owns the release bead tags the merged commit +with the new version; the publish that follows (`mix hex.publish`) is always +the user's. Never edit the version field as part of any other commit; a +diff that touches it alongside other work is a bug in the diff. ## Gate-guard ledger: ADR-0011 diff --git a/.claude/wurk/release.md b/.claude/wurk/release.md index 34866295..7f410270 100644 --- a/.claude/wurk/release.md +++ b/.claude/wurk/release.md @@ -8,7 +8,7 @@ override, and nothing below rewrites a step the skill already performs. Read this together with `.claude/wurk.json`'s `release` block. Between them they name every file a release commit here touches, and no others. -The reference for the shape is `e739263`, the 2.4.0 prep - the most recent +The reference for the shape is `f2365bb`, the 2.9.0 prep - the most recent release prep in this repo, and the commit every step below is modeled on. ## Why the recipe names no changelog @@ -54,7 +54,7 @@ in the table below, in the same change that adds it. ## Step B: promote the changelog fragments Placed where the skill's changelog step would have been, and modeled on the -2.4.0 prep commit `e739263`, which is the reference for the shape. +2.9.0 prep commit `f2365bb`, which is the reference for the shape. 1. Read every `changelog.d/*.md` fragment except `README.md`. Each is a Keep a Changelog section heading followed by its bullets. @@ -71,7 +71,7 @@ Placed where the skill's changelog step would have been, and modeled on the mandatory: `2.2.1` has none, because its two bullets said everything there was to say. Write one when there is something the bullets do not say, and keep the reasoning for the version choice in the commit body, where - `e739263` put it. + `f2365bb` put it. 4. Then the fragments' bullets, grouped by heading and ordered `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`. **Carry every bullet over byte for byte.** The lead paragraph is the only @@ -94,8 +94,8 @@ that judgement, not a rule that computes it. `release.readme_pin` is `true`. `README.md`'s `def deps` snippet carries `{:statifier, "~> X.Y"}` - the major/minor form with the patch component -dropped that the skill's step 2 bumps. `e739263` shows the previous release -moving it that way (`~> 2.3` to `~> 2.4`), and that is the commit the skill's +dropped that the skill's step 2 bumps. `f2365bb` shows the previous release +moving it that way (`~> 2.8` to `~> 2.9`), and that is the commit the skill's "check a previous release commit rather than inventing the format" step should be read against here. @@ -113,17 +113,22 @@ Exactly these, and a release commit that touches anything else is wrong: | `CHANGELOG.md` | step B | | `changelog.d/*.md` (deleted) | step B | -No `lib/` file appears in that table, and step A explains why. `e739263` +No `lib/` file appears in that table, and step A explains why. `f2365bb` touched exactly this set. ## What a release here still is not The skill does not tag, push, open a request or publish, and this extension -does not either. `CLAUDE.md` is explicit on both halves of the boundary: - -- *a release (tag, `mix hex.publish`, GitHub release)* - trigger **never**, - still unauthorized **always**: "publishing is the operator's, in every - campaign". +does not either. The tag comes later, once the prep has merged; the publish +never comes from an agent. `CLAUDE.md` is explicit on each part of the +boundary: + +- *tagging a release prep* - allowed once "the release bead's version bump is + merged to `origin/main`; the tag names that version at the merged commit", + and still unauthorized "before the bump is on `origin/main`; a tag naming + any other version or commit". +- *a release (`mix hex.publish`, GitHub release)* - trigger **never**, still + unauthorized **always**: "publishing is the operator's, in every campaign". - *a version bump on a release bead's branch* - allowed only on "an operator-authorized release bead, inside a campaign carrying the operator's explicit consent", and still unauthorized "on any other bead, on main, or @@ -137,7 +142,12 @@ a named release bead's branch, under a campaign consent that names it - is release *prep*. `CLAUDE.md`'s changelog rule describes the whole arc, of which this recipe is the first two thirds: "a release assembles the fragments, deletes them, and tags." The assembling and the deleting are step B. The -tagging is the operator's, here and in every campaign. +tagging follows the merge, outside this recipe: `CLAUDE.md`'s Release preps +paragraph says that once the prep is merged to `origin/main`, the conductor +or the session that owns the release bead tags that merged commit with the +new version and pushes the tag. The publish (`mix hex.publish`, a docs +republish included) stays the operator's one release step, in every +campaign. `.claude/wurk/commit.md`'s version-bump section records the same boundary from the commit side: the version field moves only through a release bead, never as