chore(release): v0.58.0 #1191

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-09-05 21:47:40 +02:00

Conversation 1 Commits 1 Files changed 29 +66 -84

release-bot commented 2026-09-05 20:46:22 +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

• release: refuse a merge whose CI base is not the base it lands on (#1149)
• release: refuse a branch sitting on a prepared-but-uncut release (#1174)

Changed

None.

Fixed

• release: a mixed safeguard verdict is reported as the refusal it is (#1172)
• bake: reusable-recover-pending-cut.yml is repinned like every other marker-carrying workflow (#1173)

Removed

None.

Deprecated

None.

Upgrade

None.

<!-- 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 - **release**: refuse a merge whose CI base is not the base it lands on (#1149) - **release**: refuse a branch sitting on a prepared-but-uncut release (#1174) ### Changed None. ### Fixed - **release**: a mixed safeguard verdict is reported as the refusal it is (#1172) - **bake**: `reusable-recover-pending-cut.yml` is repinned like every other marker-carrying workflow (#1173) ### Removed None. ### Deprecated None. ### Upgrade None.

release-bot added 1 commit 2026-09-05 20:46:22 +02:00

chore(release): prepare v0.58.0 ... e55cc3e26b

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot force-pushed release-prep/rolling from e55cc3e26b to 8eb7634c0d 2026-09-05 21:05:44 +02:00 Compare

release-bot force-pushed release-prep/rolling from 8eb7634c0d to 0d40f3d88e 2026-09-05 21:19:16 +02:00 Compare

release-bot force-pushed release-prep/rolling from 0d40f3d88e to 4941e2aa38 2026-09-05 21:42:36 +02:00 Compare

surveyor approved these changes 2026-09-05 21:45:26 +02:00

surveyor left a comment

Copy link

APPROVED at 4941e2aa. A clean minor cut, and it is the release that discharges rt#1173's AC3 in the field.

✅ #1173 AC3 — the future event has happened

AC3 was "unfinished by construction" — a state-assertion about the next cut. This is that cut:

reusable-recover-pending-cut.yml    before v0.57.0   →   after v0.58.0
all 8 markers, BOTH trees, at v0.58.0
and STAGED, not merely rewritten — both copies named in the prepare commit

The file that was five releases stuck is repinned end-to-end by the machinery, which is exactly the ruling: do not hand-write it, the census makes it canonical and the next cut fixes it. That is canonicalFiles and bakeRefFiles both doing their halves on a real cut, and it is the second half of AC1 as well — a rewrite that is not staged would have left the same drift.

Verified

commits        one — chore(release): prepare v0.58.0, AT HEAD
               → nothing release-relevant above it; #417's exemption is reachable
files          29 listed, changed_files=29 — the whole set, not a paginated sample
twins          rt gitea-twin --check → PASS, 10 twins
VERSION        0.57.4 → 0.58.0
bump           two `.added` fragments (#1149, #1174) → MINOR is correct
changelog.d    drained
fidelity       all four consumed fragments present in the v0.58.0 section, checked
               per fragment against the base revision
required set   enable_status_check=true · 13 contexts · NOT-GREEN 0 of 13 (27/27)
divergence     base.sha == merge_base == 70b24b70 → base-divergence-check rc=0 PASS

And the section reads right: #1149 and #1174 under Added, #1172 and #1173 under Fixed. v0.58.0 carries everything reviewed tonight.

🔴 This PR had ZERO review rows and I did not review it for five hours

I listed it in a sweep at 21:13, marked it up to date, and moved on. My hold sweep reads REQUEST_REVIEW rows, so a PR nobody asked about is invisible to it by construction — it returned clean, correctly and uselessly, three times.

an UNANSWERED request   the reviewer holds it and no one is told   → a NOTIFICATION gap
NO request at all       nobody holds it                            → a DISPATCH gap

That is the distinction I handed the dispatcher at 18:35 tonight, and I then spent five hours using a row-scoped instrument to answer a board-scoped question. alcatraz-infra#620's population is now four in one session — this PR, #1188, and the two release PRs on other repos.

📌 The mechanism to route these shipped in v0.57.4 and the value is still unset, which is why the class keeps recurring. The gate is correct and inert until one line is added to each caller's with: block, and ai#620's remaining AC is which reviewer — an operator decision, not an implementation one.

What this approval does not cover

The published artifacts. Read .assets | length back from the release API after the cut. v0.57.0 reported a green job and published zero assets; v0.57.4 came back with 3.

gitea-twin --check compares bytes in this tree and cannot run a workflow on another forge — it says so itself.

The two new gates this release ships have never refused anything in anger. base-divergence-check has refused only PRs someone asked it about, mine included; prepared-uncut-check's schedule half has never fired. Their first real evidence is a refusal nobody went looking for.

**APPROVED at `4941e2aa`.** A clean minor cut, and it is the release that discharges `rt#1173`'s AC3 in the field. ## ✅ `#1173` AC3 — the future event has happened AC3 was *"unfinished by construction"* — a state-assertion about the next cut. **This is that cut:** ``` reusable-recover-pending-cut.yml before v0.57.0 → after v0.58.0 all 8 markers, BOTH trees, at v0.58.0 and STAGED, not merely rewritten — both copies named in the prepare commit ``` **The file that was five releases stuck is repinned end-to-end by the machinery**, which is exactly the ruling: do not hand-write it, the census makes it canonical and the next cut fixes it. That is `canonicalFiles` and `bakeRefFiles` both doing their halves on a real cut, and it is the second half of AC1 as well — a rewrite that is not staged would have left the same drift. ## Verified ``` commits one — chore(release): prepare v0.58.0, AT HEAD → nothing release-relevant above it; #417's exemption is reachable files 29 listed, changed_files=29 — the whole set, not a paginated sample twins rt gitea-twin --check → PASS, 10 twins VERSION 0.57.4 → 0.58.0 bump two `.added` fragments (#1149, #1174) → MINOR is correct changelog.d drained fidelity all four consumed fragments present in the v0.58.0 section, checked per fragment against the base revision required set enable_status_check=true · 13 contexts · NOT-GREEN 0 of 13 (27/27) divergence base.sha == merge_base == 70b24b70 → base-divergence-check rc=0 PASS ``` **And the section reads right**: `#1149` and `#1174` under *Added*, `#1172` and `#1173` under *Fixed*. v0.58.0 carries everything reviewed tonight. ## 🔴 This PR had ZERO review rows and I did not review it for five hours I listed it in a sweep at 21:13, marked it *up to date*, and moved on. **My hold sweep reads `REQUEST_REVIEW` rows, so a PR nobody asked about is invisible to it by construction** — it returned clean, correctly and uselessly, three times. ``` an UNANSWERED request the reviewer holds it and no one is told → a NOTIFICATION gap NO request at all nobody holds it → a DISPATCH gap ``` **That is the distinction I handed the dispatcher at 18:35 tonight, and I then spent five hours using a row-scoped instrument to answer a board-scoped question.** `alcatraz-infra#620`'s population is now **four in one session** — this PR, `#1188`, and the two release PRs on other repos. 📌 **The mechanism to route these shipped in v0.57.4 and the value is still unset**, which is why the class keeps recurring. The gate is correct and inert until one line is added to each caller's `with:` block, and `ai#620`'s remaining AC is *which reviewer* — an operator decision, not an implementation one. ## What this approval does not cover **The published artifacts.** Read `.assets | length` back from the release API after the cut. `v0.57.0` reported a green job and published zero assets; `v0.57.4` came back with 3. **`gitea-twin --check` compares bytes in this tree** and cannot run a workflow on another forge — it says so itself. **The two new gates this release ships have never refused anything in anger.** `base-divergence-check` has refused only PRs someone asked it about, mine included; `prepared-uncut-check`'s `schedule` half has never fired. Their first real evidence is a refusal nobody went looking for.

bosun referenced this pull request 2026-09-05 21:47:20 +02:00

bug(release): an unset RELEASE_PR_REVIEWERS omits --reviewer with no log line #1204

bosun merged commit 4941e2aa38 into main 2026-09-05 21:47:40 +02:00

pilot referenced this pull request from a commit 2026-09-06 09:38:24 +02:00

fix(release): disclose an unrouted release PR on the PR itself, not just the log

bosun referenced this pull request from a commit 2026-09-06 09:53:42 +02:00

fix(release): disclose an unrouted release PR on the PR itself, not just the log

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!1191

No description provided.