git.create_tag false skips the manifest bump, not just the tag #176

New issue

Closed

opened 2026-08-15 19:15:44 +00:00 by john · 1 comment

john commented

2026-08-15 19:15:44 +00:00

Owner

Source: hit live at the v3.4.1 close, 2026-08-15

Claim

git.create_tag is documented as "Tag on milestone", but milestone.md step 2 reads it as the release-mode discriminator for the whole step:

Detect release mode first: read git.create_tag from config and probe for any existing tag (git tag). It is a non-release milestone when git.create_tag is false [...] then skip this step

Skipping that step skips the release-bump.mjs call as well as the tag. So a repo that sets create_tag: false gets no manifest bump and no changelog scaffold, and the close proceeds to prune and evolve with .claude-plugin/plugin.json still carrying the previous version. Step 2's own halt language names that outcome as the failure it exists to prevent: "A close continued past a refused bump ships a manifest still carrying the previous version."

Why the key no longer earns the coupling

Step 2 does not cut a tag at all any more:

No tag is cut here - tag-after-merge. [...] /cad-land cuts the tag in its cleanup step, on the pulled base, after the merge is confirmed - this close's job ends at the bump commit.

So create_tag: false now suppresses only the bump, which is the opposite of what a user setting a key named "tag on milestone" is asking for. This repo sets it precisely to keep /cad-milestone from tagging (tags are cut after merge on base), and the side effect was invisible until the close ran.

Observed

At the v3.4.1 close in this repo (.planning/config.json:5 has "create_tag": false), step 2 classified a tagged, versioned plugin release as a non-release milestone. The bump was run by hand instead: release-bump.mjs bump --dir . --version 3.4.1 returned action:"bumped", 3.4.0 -> 3.4.1, changelog.section_empty: true. Left to the workflow, v3.4.1 would have shipped labeled 3.4.0.

Fix shape

Split the two decisions. create_tag governs the tag only. Release mode is a separate test - the existing "has this project ever tagged, or is the user cutting a named version" probe already in step 2 - so a project that tags at land still bumps at close.

**Source:** hit live at the v3.4.1 close, 2026-08-15 ### Claim `git.create_tag` is documented as "Tag on milestone", but `milestone.md` step 2 reads it as the release-mode discriminator for the whole step: > Detect release mode first: read `git.create_tag` from config and probe for any existing tag (`git tag`). It is a non-release milestone when `git.create_tag` is false [...] then skip this step Skipping that step skips the `release-bump.mjs` call as well as the tag. So a repo that sets `create_tag: false` gets no manifest bump and no changelog scaffold, and the close proceeds to prune and evolve with `.claude-plugin/plugin.json` still carrying the previous version. Step 2's own halt language names that outcome as the failure it exists to prevent: "A close continued past a refused bump ships a manifest still carrying the previous version." ### Why the key no longer earns the coupling Step 2 does not cut a tag at all any more: > **No tag is cut here - tag-after-merge.** [...] `/cad-land` cuts the tag in its cleanup step, on the pulled base, after the merge is confirmed - this close's job ends at the bump commit. So `create_tag: false` now suppresses only the bump, which is the opposite of what a user setting a key named "tag on milestone" is asking for. This repo sets it precisely to keep `/cad-milestone` from tagging (tags are cut after merge on base), and the side effect was invisible until the close ran. ### Observed At the v3.4.1 close in this repo (`.planning/config.json:5` has `"create_tag": false`), step 2 classified a tagged, versioned plugin release as a non-release milestone. The bump was run by hand instead: `release-bump.mjs bump --dir . --version 3.4.1` returned `action:"bumped"`, `3.4.0 -> 3.4.1`, `changelog.section_empty: true`. Left to the workflow, `v3.4.1` would have shipped labeled `3.4.0`. ### Fix shape Split the two decisions. `create_tag` governs the tag only. Release mode is a separate test - the existing "has this project ever tagged, or is the user cutting a named version" probe already in step 2 - so a project that tags at land still bumps at close.