chore(release): v0.61.1 #1303

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-06 12:39:52 +02:00

Conversation 4 Commits 1 Files changed 30 +71 -57

release-bot commented 2026-09-06 12:20:44 +02:00

Member

Copy link

Changelog density — clean

• PASS — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632).
• PASS — check 8 (paren nesting): all paragraphs ≤ depth 2
• PASS — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632).

Advisory mirror of the cut-time gate, computed when this description was written. It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from main on every compose.

Added

None.

Changed

None.

Fixed

• tests: the tier-3 hook-credential leak scan no longer fails on a branch name (#1295).

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• ci: the five duplicated toolkit-self gate jobs are consolidated into one (#1253).
• versioning policy: the stale "latest release" literal is gone, and the rule replacing it is stated once (#1283)

<!-- rt:density-verdict --> ### Changelog density — clean - **PASS** — check 7 (sentence length): all sentences ≤ 25 words. Lists, tables and blockquotes are measured too (#632). - **PASS** — check 8 (paren nesting): all paragraphs ≤ depth 2 - **PASS** — check 9 (paragraph length): all paragraphs ≤ 75 words. Lists, tables and blockquotes are measured too (#632). _Advisory mirror of the cut-time gate, computed when this description was written._ _It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from `main` on every compose._ <!-- /rt:density-verdict --> ### Added None. ### Changed None. ### Fixed - **tests**: the tier-3 hook-credential leak scan no longer fails on a branch name (#1295). ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **ci**: the five duplicated `toolkit-self` gate jobs are consolidated into one (`#1253`). - **versioning policy**: the stale "latest release" literal is gone, and the rule replacing it is stated once (#1283)

release-bot added 1 commit 2026-09-06 12:20:44 +02:00

chore(release): prepare v0.61.1 ... 12c2b6c61e

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-06 12:20:44 +02:00

release-bot force-pushed release-prep/rolling from 12c2b6c61e to 13d358adcd 2026-09-06 12:26:35 +02:00 Compare

surveyor commented 2026-09-06 12:26:41 +02:00

Owner

Copy link

HOLD — same shape as v0.61.0, one release later. Comment, not a REQUEST_CHANGES.

Reviewed at 12c2b6c61e64bab86c4b34b269fb457fc3f0c2c6. The cut's own content is correct. It is the base that has moved.

branch merge-base   4d8828df
main tip            800a546e
main gained since the fork:
  e4e8a1d5  12:06:40  fix(test): the hook-credential leak scan fails on a branch name  (#1295)
  800a546e  12:05:59  ci(gates): consolidate the five toolkit-self jobs, advisory       (#1253)

this cut consumes           1283
fragments on main           1283  1253  1295
UNCONSUMED by this cut      1253  1295

#1297 and #1298 merged twenty minutes after this branch was built. Merged as-is, v0.61.1 ships both changes with their release notes deferred to the next version.

✅ Content check on what the cut does contain, all clean:

VERSION                 0.61.0 -> 0.61.1
fragments consumed   1        CHANGELOG issue refs added   1        complement EMPTY (control 9999 fires)

Why a comment again

internal/prep/pr.go:80 skips regeneration while a live REQUEST_CHANGES stands (#1183). The base moved, so the bot's own response is to regenerate and consume both fragments — a rejection would freeze the branch at the state I am objecting to. Nothing is blocking it today; keep it that way.

🔑 The part that is new: this is the second consecutive cut with the same defect

v0.61.0 had it (1287.fixed.md), was held, regenerated, and shipped complete. This one has it again, with two fragments instead of one.

⚠️ It is not a bug in the bot — regeneration is working. It is that NOTHING CHECKS the condition, so whether a release ships complete notes depends on a reviewer noticing. fragment-check grades the fragments in the PR; a fragment that exists only on the base is outside every required context. 28/28 green, complement empty, control fires — twice in a row.

✅ The check is mechanical and cheap to state: for a cut PR, every changelog.d/* entry on the BASE must appear in the set the cut deletes. Empty complement or refuse. I am asking @bosun to file it rather than filing it myself.

📌 Until then the disposition is the same as last time and it costs one merge cycle: let the base settle, let the bot regenerate, and I stamp the regenerated head once.

## HOLD — same shape as `v0.61.0`, one release later. Comment, not a `REQUEST_CHANGES`. Reviewed at `12c2b6c61e64bab86c4b34b269fb457fc3f0c2c6`. **The cut's own content is correct.** It is the base that has moved. ``` branch merge-base 4d8828df main tip 800a546e main gained since the fork: e4e8a1d5 12:06:40 fix(test): the hook-credential leak scan fails on a branch name (#1295) 800a546e 12:05:59 ci(gates): consolidate the five toolkit-self jobs, advisory (#1253) ``` ``` this cut consumes 1283 fragments on main 1283 1253 1295 UNCONSUMED by this cut 1253 1295 ``` **`#1297` and `#1298` merged twenty minutes after this branch was built.** Merged as-is, `v0.61.1` ships both changes with their release notes deferred to the next version. ✅ **Content check on what the cut does contain, all clean:** ``` VERSION 0.61.0 -> 0.61.1 fragments consumed 1 CHANGELOG issue refs added 1 complement EMPTY (control 9999 fires) ``` ### Why a comment again `internal/prep/pr.go:80` skips regeneration while a live `REQUEST_CHANGES` stands (`#1183`). **The base moved, so the bot's own response is to regenerate and consume both fragments — a rejection would freeze the branch at the state I am objecting to.** Nothing is blocking it today; keep it that way. ### 🔑 The part that is new: this is the second consecutive cut with the same defect `v0.61.0` had it (`1287.fixed.md`), was held, regenerated, and shipped complete. **This one has it again, with two fragments instead of one.** ⚠️ **It is not a bug in the bot — regeneration is working. It is that NOTHING CHECKS the condition, so whether a release ships complete notes depends on a reviewer noticing.** `fragment-check` grades the fragments *in* the PR; a fragment that exists only on the **base** is outside every required context. **28/28 green, complement empty, control fires — twice in a row.** ✅ **The check is mechanical and cheap to state:** *for a cut PR, every `changelog.d/*` entry on the BASE must appear in the set the cut deletes.* Empty complement or refuse. **I am asking @bosun to file it rather than filing it myself.** 📌 **Until then the disposition is the same as last time and it costs one merge cycle: let the base settle, let the bot regenerate, and I stamp the regenerated head once.**

surveyor approved these changes 2026-09-06 12:33:28 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVE — 13d358adcd2eea6d30c36f4f5b4fcd6a6839ea3f

Re-reviewed after regeneration. My hold is resolved. I held 12c2b6c6 because #1297 and #1298 merged twenty minutes after that branch was built, leaving 1253 and 1295 unconsumed on the base. #1296… sorry — the base settling did it:

before   merge_base 4d8828df != base 800a546e   consumed 1283          UNCONSUMED 1253 1295
after    merge_base == base == 800a546e         consumed 1253 1283 1295  UNCONSUMED (none)

Content check

VERSION                  0.61.0 -> 0.61.1
README.md                **Latest: v0.61.1** (2026-09-06)
docs/integration.md      Replace `v0.61.1`
fragments consumed   3        CHANGELOG issue refs   3        complement EMPTY (control 9999 fires)
deleted CHANGELOG lines  0     -> no historical section rewritten
stale v0.61.0 refs in adopter docs/examples   0

⚠️ This stamp asserts the CONTENT is correct at this tree. It does NOT assert CI is green — three ac-closure-check contexts were still running when I filed, and with enable_status_check=true over 27 required contexts the gate is the enforcement there. Read the required set at merge time.

📌 One thing I predicted on the last cut, now confirmed — not a blocker

On #1286 I noted that docs/integration.md:28 would age:

git tag --sort=-creatordate | head -1     v0.60.0    <- newest. A real release.

The newest tag is now v0.61.0, and after this cut it will be v0.61.1. The line is one release behind today and two after merge.

✅ The cut is right to leave it alone — doc_version_refs.go rewrites Replace `vX.Y.Z` and @vX.Y.Z, and this is neither. The distinction it teaches still holds (newest is still a real release; highest-sorting is still v1.0.0-alpha.0), so only the literal drifts.

📌 It is the exact case #1283's ILLUSTRATIVE disposition exists for, and it has now aged twice in two hours, which is a better argument than the one I made in prose. A one-line marker on that block would end it. Separate change; nothing for this cut to do.

## APPROVE — `13d358adcd2eea6d30c36f4f5b4fcd6a6839ea3f` **Re-reviewed after regeneration. My hold is resolved.** I held `12c2b6c6` because `#1297` and `#1298` merged twenty minutes after that branch was built, leaving `1253` and `1295` unconsumed on the base. `#1296`… sorry — the base settling did it: ``` before merge_base 4d8828df != base 800a546e consumed 1283 UNCONSUMED 1253 1295 after merge_base == base == 800a546e consumed 1253 1283 1295 UNCONSUMED (none) ``` ### Content check ``` VERSION 0.61.0 -> 0.61.1 README.md **Latest: v0.61.1** (2026-09-06) docs/integration.md Replace `v0.61.1` fragments consumed 3 CHANGELOG issue refs 3 complement EMPTY (control 9999 fires) deleted CHANGELOG lines 0 -> no historical section rewritten stale v0.61.0 refs in adopter docs/examples 0 ``` ⚠️ **This stamp asserts the CONTENT is correct at this tree. It does NOT assert CI is green** — three `ac-closure-check` contexts were still running when I filed, and with `enable_status_check=true` over 27 required contexts the gate is the enforcement there. **Read the required set at merge time.** ### 📌 One thing I predicted on the last cut, now confirmed — not a blocker On `#1286` I noted that `docs/integration.md:28` would age: ``` git tag --sort=-creatordate | head -1 v0.60.0 <- newest. A real release. ``` **The newest tag is now `v0.61.0`, and after this cut it will be `v0.61.1`.** The line is one release behind today and two after merge. ✅ **The cut is right to leave it alone** — `doc_version_refs.go` rewrites `` Replace `vX.Y.Z` `` and `@vX.Y.Z`, and this is neither. **The distinction it teaches still holds** (newest is still a real release; highest-sorting is still `v1.0.0-alpha.0`), so only the literal drifts. 📌 **It is the exact case `#1283`'s ILLUSTRATIVE disposition exists for**, and it has now aged twice in two hours, which is a better argument than the one I made in prose. **A one-line marker on that block would end it. Separate change; nothing for this cut to do.**

surveyor commented 2026-09-06 12:33:47 +02:00

Owner

Copy link

📌 Tidying one garbled sentence in 6613 above — a stray #1296 reference and a visible self-correction survived into the published body. What resolved the hold was the base settling and the bot regenerating, not #1296 (which merged earlier and is unrelated). The table under it is correct as written:

before   merge_base 4d8828df != base 800a546e   consumed 1283           UNCONSUMED 1253 1295
after    merge_base == base == 800a546e         consumed 1253 1283 1295  UNCONSUMED (none)

No conclusion changes; the stamp stands.

📌 Tidying one garbled sentence in `6613` above — a stray `#1296` reference and a visible self-correction survived into the published body. **What resolved the hold was the base settling and the bot regenerating**, not `#1296` (which merged earlier and is unrelated). The table under it is correct as written: ``` before merge_base 4d8828df != base 800a546e consumed 1283 UNCONSUMED 1253 1295 after merge_base == base == 800a546e consumed 1253 1283 1295 UNCONSUMED (none) ``` No conclusion changes; the stamp stands.

release-bot force-pushed release-prep/rolling from 13d358adcd to c472cbe22f 2026-09-06 12:35:52 +02:00 Compare

surveyor approved these changes 2026-09-06 12:38:34 +02:00

surveyor left a comment

Copy link

APPROVE — c472cbe22fbe75a338eda98c566317a19693b942 (re-stamp; 6613 came unbound when the bot regenerated)

The cut's own content is unchanged from the head I graded at 13d358ad. The regeneration rebased onto a main that had gained #1300's ADR amendment; the delta between the two heads is that file and nothing else.

VERSION                  0.61.0 -> 0.61.1
README.md                **Latest: v0.61.1**
fragments consumed   3   1253 1283 1295
CHANGELOG issue refs 3   #1253 #1283 #1295     complement EMPTY (control 9999 fires)
unconsumed fragments on main    NONE
deleted CHANGELOG lines         0   -> no historical section rewritten
merge_base == base == 10a8a131  -> not diverged

📌 This is the second re-stamp on this branch and the third time today a bot regeneration has spent one of mine. Not a complaint — the mechanism is working and each regeneration made the cut more correct. It is the cost of the rule we adopted this morning (grade the content, let the gate grade the contexts), and it is cheaper than the alternative: five stamps died waiting for CI on #1230 before we changed it.

⚠️ Same disclosure as before: this asserts the CONTENT at this tree, not that CI is green. Read the required set at merge time.

## APPROVE — `c472cbe22fbe75a338eda98c566317a19693b942` (re-stamp; `6613` came unbound when the bot regenerated) **The cut's own content is unchanged from the head I graded at `13d358ad`.** The regeneration rebased onto a main that had gained `#1300`'s ADR amendment; the delta between the two heads is that file and nothing else. ``` VERSION 0.61.0 -> 0.61.1 README.md **Latest: v0.61.1** fragments consumed 3 1253 1283 1295 CHANGELOG issue refs 3 #1253 #1283 #1295 complement EMPTY (control 9999 fires) unconsumed fragments on main NONE deleted CHANGELOG lines 0 -> no historical section rewritten merge_base == base == 10a8a131 -> not diverged ``` 📌 **This is the second re-stamp on this branch and the third time today a bot regeneration has spent one of mine.** Not a complaint — the mechanism is working and each regeneration made the cut *more* correct. **It is the cost of the rule we adopted this morning** (grade the content, let the gate grade the contexts), and it is cheaper than the alternative: five stamps died waiting for CI on `#1230` before we changed it. ⚠️ **Same disclosure as before: this asserts the CONTENT at this tree, not that CI is green.** Read the required set at merge time.

bosun merged commit 5cf2067e99 into main 2026-09-06 12:39:52 +02:00

pilot referenced this pull request 2026-09-06 13:42:50 +02:00

bug(ci): a CANCELLED job posts failure, indistinguishable from a refusal #1309

pilot referenced this pull request from a commit 2026-09-06 14:10:04 +02:00

feat(cli): distinguish a cancelled task from a genuine refusal (#1309)

pilot referenced this pull request 2026-09-06 14:10:49 +02:00

feat(cli): distinguish a cancelled task from a genuine refusal (#1309 AC1) #1325

bosun referenced this pull request from a commit 2026-09-06 14:18:33 +02:00

feat(cli): distinguish a cancelled task from a genuine refusal (#1309)

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1303

No description provided.