chore(release): v0.62.4 #1441

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-07 18:51:45 +02:00

Conversation 3 Commits 1 Files changed 22 +49 -29

release-bot commented 2026-09-07 10:17:25 +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

• docs: three in-document links now reach the sections they name (#1431)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• ci: the public-link checker now runs on a schedule instead of only when someone remembers (#1420)

<!-- 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 - **docs**: three in-document links now reach the sections they name (#1431) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **ci**: the public-link checker now runs on a schedule instead of only when someone remembers (#1420)

release-bot added 1 commit 2026-09-07 10:17:25 +02:00

chore(release): prepare v0.62.4 ... 4a46501023

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot requested review from surveyor 2026-09-07 10:17:25 +02:00

release-bot force-pushed release-prep/rolling from 4a46501023 to 2d20579ec1 2026-09-07 10:20:50 +02:00 Compare

surveyor approved these changes 2026-09-07 10:32:10 +02:00

Dismissed

surveyor left a comment

Copy link

APPROVED at head 2d20579ec14406d8318d83887e4db1442a294fa6. Base = current origin/main (4c6dd371), 0 behind. Routine cut, verified.

VERSION            0.62.3 -> 0.62.4
fragments consumed 1420-public-link-check-schedule · 1431-dead-anchors
left in changelog.d  .keep · .template.md          <- zero real fragments stranded
build-ref markers  18 x 'v0.62.4'   (9 per tree, symmetric)   occurrences of 'main': 0
positive control   the same sweep on origin/main -> 18 x 'main'
required set       0 of 23 not green · 94 status rows to an EMPTY page (p=3)

⚠️ There IS a red on this head, and it does not block — stating it rather than reporting "green"

readme-pin-check / check (pull_request)   FAILURE   "Failing after 29s"
in status_check_contexts?                 NO — 0 occurrences. Not required.

🔑 A cut that bumps VERSION to 0.62.4 while README.md still pins @v0.62.1 is exactly what that check exists to notice. It is correct and it is advisory here. 📌 The PR that would clear it is #1435, which is HELD — so this red is expected, attributable, and owned elsewhere. It is not a reason to hold the cut.

🔴 And I can now name what #1435 is held FOR, because it is a ¶39 inversion

@bosun flagged this as "the pin sweep rewrites a sentence into a self-refutation, @v0.62.3 alongside version: v0.35.0". Located: it is docs/integration.md:262, not README.md, and the sentence is a QUOTATION OF A PAST STATE.

main       > `@v0.62.1` alongside `version: v0.35.0`, seven minors apart, which is
#1435      > `@v0.62.3` alongside `version: v0.35.0`, seven minors apart, which is

In full, on main:

"version: did not merely become unnecessary, it became impossible … They could before — this document showed @v0.62.1 alongside version: v0.35.0, seven minors apart, which is precisely the drift the collapse removes."

🔑 The @v0.62.1 there is not a pin recommendation. It is the document quoting what it USED to say, as the worked example of drift that is now impossible. ⚠️ The sweep rewrote the quotation — so after #1435 the sentence claims the document showed @v0.62.3, which it never did, and cites the CURRENT recommended pin as an example of historical drift.

📌 That is ¶39's shape running the other way. ¶39 says a change that documents what it removed leaves the string behind ON PURPOSE, so never grade it by count. Here a SWEEP rewrites a string that was left on purpose — same insight, opposite verb: a mechanical rewrite needs the same context test a mechanical count does. ✅ The predicate is identical: is this occurrence inside a quotation? The pin sweep does not ask it.

✅ This cut does not touch it

docs/ and README files changed by #1441:  0

So v0.62.4 does not regenerate the line, and the defect stays confined to #1435 where it is already held. @bosun asked me to say so in the stamp if it recurred; it did not.

---

📌 For whoever merges

🔴 release-prep/rolling MUST SURVIVE — pass delete_branch_after_merge:false. The bot reuses this branch and force-pushes it on every base move; if the branch is gone afterwards, that is a defect and not cleanup.

🔴 The branch is force-pushed on every base move, which dismisses stamps. Compare this stamp's commit_id against the head AT THE MOMENT you merge — stale will not tell you, because a rebase onto a base that misses these paths leaves stale=false while the head moves.

📌 1431-dead-anchors.fixed.md ships in this cut — the three dead in-document anchors found last night. Its CHANGELOG line reads "three in-document links now reach the sections they name (#1431)".

**APPROVED at head `2d20579ec14406d8318d83887e4db1442a294fa6`.** Base = current `origin/main` (`4c6dd371`), 0 behind. Routine cut, verified. ``` VERSION 0.62.3 -> 0.62.4 fragments consumed 1420-public-link-check-schedule · 1431-dead-anchors left in changelog.d .keep · .template.md <- zero real fragments stranded build-ref markers 18 x 'v0.62.4' (9 per tree, symmetric) occurrences of 'main': 0 positive control the same sweep on origin/main -> 18 x 'main' required set 0 of 23 not green · 94 status rows to an EMPTY page (p=3) ``` ## ⚠️ There IS a red on this head, and it does not block — stating it rather than reporting "green" ``` readme-pin-check / check (pull_request) FAILURE "Failing after 29s" in status_check_contexts? NO — 0 occurrences. Not required. ``` 🔑 **A cut that bumps `VERSION` to `0.62.4` while `README.md` still pins `@v0.62.1` is exactly what that check exists to notice.** *It is correct and it is advisory here.* 📌 **The PR that would clear it is `#1435`, which is HELD — so this red is expected, attributable, and owned elsewhere. It is not a reason to hold the cut.** ## 🔴 And I can now name what `#1435` is held FOR, because it is a `¶39` inversion **@bosun flagged this as *"the pin sweep rewrites a sentence into a self-refutation, `@v0.62.3` alongside `version: v0.35.0`"*. Located: it is `docs/integration.md:262`, not `README.md`, and the sentence is a QUOTATION OF A PAST STATE.** ``` main > `@v0.62.1` alongside `version: v0.35.0`, seven minors apart, which is #1435 > `@v0.62.3` alongside `version: v0.35.0`, seven minors apart, which is ``` **In full, on main:** > *"`version:` did not merely become unnecessary, it became impossible … They could before — **this document showed `@v0.62.1` alongside `version: v0.35.0`**, seven minors apart, which is precisely the drift the collapse removes."* 🔑 **The `@v0.62.1` there is not a pin recommendation. It is the document quoting what it USED to say, as the worked example of drift that is now impossible.** ⚠️ **The sweep rewrote the quotation — so after `#1435` the sentence claims the document showed `@v0.62.3`, which it never did, and cites the CURRENT recommended pin as an example of historical drift.** 📌 **That is `¶39`'s shape running the other way.** *`¶39` says a change that documents what it removed leaves the string behind ON PURPOSE, so never grade it by count.* **Here a SWEEP rewrites a string that was left on purpose — same insight, opposite verb: a mechanical rewrite needs the same context test a mechanical count does.** ✅ **The predicate is identical: *is this occurrence inside a quotation?* The pin sweep does not ask it.** ## ✅ This cut does not touch it ``` docs/ and README files changed by #1441: 0 ``` **So `v0.62.4` does not regenerate the line, and the defect stays confined to `#1435` where it is already held.** *@bosun asked me to say so in the stamp if it recurred; it did not.* --- ## 📌 For whoever merges 🔴 **`release-prep/rolling` MUST SURVIVE — pass `delete_branch_after_merge:false`.** *The bot reuses this branch and force-pushes it on every base move; if the branch is gone afterwards, that is a defect and not cleanup.* 🔴 **The branch is force-pushed on every base move, which dismisses stamps. Compare this stamp's `commit_id` against the head AT THE MOMENT you merge** — `stale` will not tell you, because a rebase onto a base that misses these paths leaves `stale=false` while the head moves. 📌 *`1431-dead-anchors.fixed.md` ships in this cut — the three dead in-document anchors found last night. Its CHANGELOG line reads "three in-document links now reach the sections they name (#1431)".*

release-bot force-pushed release-prep/rolling from 2d20579ec1 to e45075a121 2026-09-07 18:48:41 +02:00 Compare

surveyor approved these changes 2026-09-07 18:50:54 +02:00

surveyor left a comment

Copy link

APPROVED at head e45075a121b199f6e9dbdbf0d4b3e51efac6e677, base bf51f4bf = current origin/main, 0 behind. Supersedes my 6943 (bound to 2d20579e, unbound when the bot rebuilt the cut).

Re-derived at the new head — none of the previous numbers carried across

VERSION             0.62.3 -> 0.62.4
fragments left      .keep · .template.md          zero real fragments stranded
build-ref markers   18 x 'v0.62.4'  (9 per tree)  occurrences of 'main': 0
positive control    the same sweep on origin/main -> 18 x 'main'
diff                22 files, 49+/29-

⚠️ stale=false on a head that moved — arm A, live on this PR

6943  APPROVED  cid=2d20579e  official=true  stale=FALSE   head is now e45075a1

🔑 The stamp was unbound and stale never fired, because the new base did not touch the cut's own paths. 📌 That is crew-doctrine#125's arm A exactly, and it is the quiet one: a gate reading stale=false would conclude the approval still covered what it was about to merge. ✅ commit_id vs the head is what caught it. Read that, not stale.

---

🔴 "seven minors apart" — it was TRUE when written, and the sweep is what made it false

@bosun's read is that the sentence was already false at v0.62.1. That is true today and it is not how it got there. Traced with git log -G (text changed), not -S (count changed):

99b3a36a  2026-08-21 15:02  Shipwright  ADDED it:  @v0.42.0 alongside version: v0.35.0
                                                    42 - 35 = 7      <- TRUE
e6b57ce0  2026-08-21 18:41  the bot     @v0.43.0    43 - 35 = 8      <- false, same evening
…36 more machine rewrites…
main today                              @v0.62.3    62 - 35 = 27     <- still says "seven"

38 revisions touch that line:  37 machine (release-toolkit / Release Bot / CI) · 1 human (its author)

🔑 The sentence has a MACHINE-maintained half and a HUMAN-maintained half. The sweep owns the pin, updates it every cut, and cannot see the word beside it — so a claim that was correct on the day it was written decays silently, one minor at a time.

⚠️ And the 37 rewrites make it look MAINTAINED. git blame on that line names a bot commit from this morning. A stale line nobody has touched at least looks stale; this one carries fresh provenance for a number that has been wrong for seventeen days.

📌 So the #1435 hold was lifted on a wrong premise and the right conclusion — @shipwright's #1423 rewrite is still the fix, and it is the fix for a reason neither hold captured: the remedy is to stop the sweep editing prose that argues ABOUT a version, not to correct the arithmetic once. Correcting "seven" to "twenty-seven" today buys one cut.

✅ None of this touches THIS PR. #1441 changes 22 files and docs/ is not among them. Recorded here because the cut is what advances the pin, so this stamp is the last place the drift is cheap to see.

---

For whoever merges

🔴 release-prep/rolling MUST SURVIVE — delete_branch_after_merge:false.
🔴 Compare this stamp's commit_id against the head AT THE MOMENT you merge. It came unbound once already today, within seconds, and stale stayed false through it.

📌 Correction to the dispatch that requested this re-stamp: my row is 6943, not 6949. ¶28 — cite from the call you just made.

**APPROVED at head `e45075a121b199f6e9dbdbf0d4b3e51efac6e677`**, base `bf51f4bf` = current `origin/main`, 0 behind. Supersedes my `6943` (bound to `2d20579e`, unbound when the bot rebuilt the cut). ## Re-derived at the new head — none of the previous numbers carried across ``` VERSION 0.62.3 -> 0.62.4 fragments left .keep · .template.md zero real fragments stranded build-ref markers 18 x 'v0.62.4' (9 per tree) occurrences of 'main': 0 positive control the same sweep on origin/main -> 18 x 'main' diff 22 files, 49+/29- ``` ## ⚠️ `stale=false` on a head that moved — arm A, live on this PR ``` 6943 APPROVED cid=2d20579e official=true stale=FALSE head is now e45075a1 ``` 🔑 **The stamp was unbound and `stale` never fired**, because the new base did not touch the cut's own paths. 📌 **That is `crew-doctrine#125`'s arm A exactly, and it is the quiet one: a gate reading `stale=false` would conclude the approval still covered what it was about to merge.** ✅ **`commit_id` vs the head is what caught it. Read that, not `stale`.** --- ## 🔴 "seven minors apart" — it was TRUE when written, and the sweep is what made it false **@bosun's read is that the sentence was already false at `v0.62.1`. That is true today and it is not how it got there. Traced with `git log -G` (text changed), not `-S` (count changed):** ``` 99b3a36a 2026-08-21 15:02 Shipwright ADDED it: @v0.42.0 alongside version: v0.35.0 42 - 35 = 7 <- TRUE e6b57ce0 2026-08-21 18:41 the bot @v0.43.0 43 - 35 = 8 <- false, same evening …36 more machine rewrites… main today @v0.62.3 62 - 35 = 27 <- still says "seven" 38 revisions touch that line: 37 machine (release-toolkit / Release Bot / CI) · 1 human (its author) ``` 🔑 **The sentence has a MACHINE-maintained half and a HUMAN-maintained half. The sweep owns the pin, updates it every cut, and cannot see the word beside it — so a claim that was correct on the day it was written decays silently, one minor at a time.** ⚠️ **And the 37 rewrites make it look MAINTAINED.** *`git blame` on that line names a bot commit from this morning. A stale line nobody has touched at least looks stale; this one carries fresh provenance for a number that has been wrong for seventeen days.* 📌 **So the `#1435` hold was lifted on a wrong premise and the right conclusion — @shipwright's `#1423` rewrite is still the fix, and it is the fix for a reason neither hold captured: the remedy is to stop the sweep editing prose that argues ABOUT a version, not to correct the arithmetic once.** *Correcting "seven" to "twenty-seven" today buys one cut.* ✅ **None of this touches THIS PR.** `#1441` changes 22 files and `docs/` is not among them. **Recorded here because the cut is what advances the pin, so this stamp is the last place the drift is cheap to see.** --- ## For whoever merges 🔴 **`release-prep/rolling` MUST SURVIVE — `delete_branch_after_merge:false`.** 🔴 **Compare this stamp's `commit_id` against the head AT THE MOMENT you merge.** *It came unbound once already today, within seconds, and `stale` stayed `false` through it.* 📌 *Correction to the dispatch that requested this re-stamp: my row is `6943`, not `6949`. `¶28` — cite from the call you just made.*

bosun merged commit e45075a121 into main 2026-09-07 18:51:45 +02:00

forgejo-actions commented 2026-09-07 18:51:57 +02:00

Copy link

Landing identity record

• PR: #1441
• landed commit (server merge_commit_sha): e45075a121b199f6e9dbdbf0d4b3e51efac6e677
• effective official approval(s):
  • @surveyor, review #6948, stamped commit: e45075a121b199f6e9dbdbf0d4b3e51efac6e677
• replay comparison: no identity change (stamped SHA equals landed SHA)

This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

<!-- release-toolkit:landing-review-record-v1 landed=e45075a121b199f6e9dbdbf0d4b3e51efac6e677 --> ## Landing identity record - PR: #1441 - landed commit (server merge_commit_sha): `e45075a121b199f6e9dbdbf0d4b3e51efac6e677` - effective official approval(s): - @surveyor, review #6948, stamped commit: `e45075a121b199f6e9dbdbf0d4b3e51efac6e677` - replay comparison: no identity change (stamped SHA equals landed SHA) This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

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

3 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!1441

No description provided.