chore(release): v0.53.0 #982

Merged

bosun merged 1 commit from release-prep/rolling into main 2026-08-27 09:12:42 +02:00

Conversation 3 Commits 1 Files changed 26 +65 -73

release-bot commented 2026-08-26 23:15:45 +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

• workflows: shared Forgejo parse guard records complete workflow coverage (#841)
• release: rebuilding an old tag now uses current pipeline logic (#980)

Changed

• contributor CI: fork pull requests now receive an explicit workflow-approval notice (#645)
• ac-closure-check: the undeclared-target refusal now names the negation case explicitly (#989)

Fixed

• manifest PR auto-merge: explicitly requests deletion of the generated branch (#633)
• release: the pipeline checkout no longer dirties the tree being built (#980)
• workflow-parse-check: toolkit-self cuts resolve the toolkit from main before the new tag exists (#995)

Removed

None.

Deprecated

None.

Upgrade

None.

Internal

• release: document refactor-of-an-already-documented-change guidance and the non-automated Refactors: trailer convention (#492)
• fetch-rt.sh: comment why a surviving checksums.txt is safe on both early-exit paths (#643)
• internal: keep hidden workflow verbs in the complete CLI registration census (#787)
• release-assets: pin that an unreadable release body cannot skip DELETE authorization (#967)

<!-- 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 - **workflows**: shared Forgejo parse guard records complete workflow coverage (#841) - **release**: rebuilding an old tag now uses current pipeline logic (#980) ### Changed - **contributor CI**: fork pull requests now receive an explicit workflow-approval notice (#645) - **ac-closure-check**: the undeclared-target refusal now names the negation case explicitly (#989) ### Fixed - **manifest PR auto-merge**: explicitly requests deletion of the generated branch (#633) - **release**: the pipeline checkout no longer dirties the tree being built (#980) - **workflow-parse-check**: toolkit-self cuts resolve the toolkit from `main` before the new tag exists (#995) ### Removed None. ### Deprecated None. ### Upgrade None. ### Internal - **release**: document refactor-of-an-already-documented-change guidance and the non-automated `Refactors:` trailer convention (#492) - **fetch-rt.sh**: comment why a surviving `checksums.txt` is safe on both early-exit paths (#643) - **internal**: keep hidden workflow verbs in the complete CLI registration census (#787) - **release-assets**: pin that an unreadable release body cannot skip DELETE authorization (#967)

release-bot added 1 commit 2026-08-26 23:15:45 +02:00

chore(release): prepare v0.53.0 ... aeee8b7b21

Generated by release-toolkit rt prep.

Tracker: frankenbit/release-toolkit#1

release-bot force-pushed release-prep/rolling from aeee8b7b21 to 6cd5c44ab4 2026-08-26 23:25:57 +02:00 Compare

release-bot force-pushed release-prep/rolling from 6cd5c44ab4 to c1b2733d95 2026-08-27 00:07:59 +02:00 Compare

release-bot force-pushed release-prep/rolling from c1b2733d95 to ade826bf2e 2026-08-27 00:35:00 +02:00 Compare

release-bot force-pushed release-prep/rolling from ade826bf2e to b416daf1a4 2026-08-27 00:42:36 +02:00 Compare

release-bot force-pushed release-prep/rolling from b416daf1a4 to ba3a2a0ba7 2026-08-27 00:49:45 +02:00 Compare

release-bot force-pushed release-prep/rolling from ba3a2a0ba7 to f0bc87a751 2026-08-27 01:08:24 +02:00 Compare

release-bot force-pushed release-prep/rolling from f0bc87a751 to a1c383ea6f 2026-08-27 01:14:39 +02:00 Compare

surveyor requested changes 2026-08-27 01:15:54 +02:00

Dismissed

surveyor left a comment

Copy link

REQUEST CHANGES @ f0bc87a751459d37d1fc5bb54b1ce217fb3294cb — workflow-parse-check cannot pass on this PR, and it is not a flake, a stale base, or the cut's content. It is circular by construction, and this is the first cut to meet the new gate.

🔴 The gate resolves to a tag that this PR creates

reusable-workflow-parse-check.yml
  BUILD_BAKED_TOOLKIT_REF: 'v0.53.0'     ← rebaked by `rt prep`, IN THIS DIFF
  checkout release-toolkit @ that ref

server:  GET /tags/v0.53.0  →  404       ← the tag this cut creates
log:     Fetching the repository … git failed exit 1 (×2, then fail)

rt prep rebakes the ref to the version being cut; the tag for that version does not exist until the cut merges. So the gate checks out a ref that cannot exist yet, on every cut PR, forever.

The diff shows the rebake explicitly:

-  BUILD_BAKED_TOOLKIT_REF: 'main'      # release-toolkit-build-ref
+  BUILD_BAKED_TOOLKIT_REF: 'v0.53.0'   # release-toolkit-build-ref

🔴 And the #456 override exists for exactly this and does not fire here

The resolver has a floating-pin escape hatch, commented "keeps toolkit-self floating pins from resolving a transient pre-cut tag (#456)" — the precise failure above. I replayed its logic against this branch:

WRAPPER_REF = ''            ← the wrapper uses `uses: ./.forgejo/workflows/…`
                              a LOCAL PATH, so there is no `@ref` to read
override condition          WRAPPER_REF == "main"   → FALSE
resolved ref                v0.53.0   (source=baked)

🔑 The override was written for the CONSUMER shape (frankenbit/release-toolkit/….yml@main) and this repo invokes its own reusable workflow by local path. An empty WRAPPER_REF is the self-hosted case and it falls through to the baked value — which on a cut PR is always the unpublished tag.

✅ Why the other five baked gates pass and this one does not

Six workflows carry v0.53.0 after the rebake. reusable-ac-closure-check.yml is the exception — it is still 'main'. So there is already precedent for a gate that is not rebaked, and whatever excludes that one is the natural place to exclude this one.

📌 Three candidate fixes, and I would not choose for you:

• Treat an empty WRAPPER_REF as main — extends #456's override to the self-hosted invocation. Smallest change; fixes every future cut.
• Exclude the parse workflow from rt prep's rebake, as reusable-ac-closure-check.yml already is.
• Resolve to the PR's own tree for the self-check case, the way the toolkit-self gate jobs already do — they build rt from the PR and are the only reason the other gates are green here.

📌 This is the gate's first encounter with a cut

workflow-parse-check landed at 48d87084 (00:48); #982 was created 23:15 and is the first release cut since. There is no prior green to contradict this — the gate has simply never met a cut PR before, so the interaction was unobservable until now.

⚠️ And it is not #982's defect. The cut is doing exactly what rt prep is supposed to do. The fix belongs in the gate or in the rebake exclusion, not in this branch — though this branch is where it surfaces and will keep surfacing.

---

Everything else on the cut, checked while I was here: ac-closure-check has since gone green on its own; manifest-check was still pending at my read. I will re-read the artifact — VERSION, fragment consumption, bullet fidelity, stale-version sweep — once the parse question is resolved, since a rebase or a gate change may move the head and I would rather grade the tree that is going to merge.

**REQUEST CHANGES @ `f0bc87a751459d37d1fc5bb54b1ce217fb3294cb`** — `workflow-parse-check` cannot pass on this PR, and **it is not a flake, a stale base, or the cut's content.** It is circular by construction, and this is the first cut to meet the new gate. ## 🔴 The gate resolves to a tag that this PR creates ``` reusable-workflow-parse-check.yml BUILD_BAKED_TOOLKIT_REF: 'v0.53.0' ← rebaked by `rt prep`, IN THIS DIFF checkout release-toolkit @ that ref server: GET /tags/v0.53.0 → 404 ← the tag this cut creates log: Fetching the repository … git failed exit 1 (×2, then fail) ``` **`rt prep` rebakes the ref to the version being cut; the tag for that version does not exist until the cut merges.** So the gate checks out a ref that cannot exist yet, on every cut PR, forever. **The diff shows the rebake explicitly:** ``` - BUILD_BAKED_TOOLKIT_REF: 'main' # release-toolkit-build-ref + BUILD_BAKED_TOOLKIT_REF: 'v0.53.0' # release-toolkit-build-ref ``` ## 🔴 And the `#456` override exists for exactly this and does not fire here The resolver has a floating-pin escape hatch, commented *"keeps toolkit-self floating pins from resolving a transient pre-cut tag (#456)"* — **the precise failure above.** I replayed its logic against this branch: ``` WRAPPER_REF = '' ← the wrapper uses `uses: ./.forgejo/workflows/…` a LOCAL PATH, so there is no `@ref` to read override condition WRAPPER_REF == "main" → FALSE resolved ref v0.53.0 (source=baked) ``` 🔑 **The override was written for the CONSUMER shape (`frankenbit/release-toolkit/….yml@main`) and this repo invokes its own reusable workflow by local path.** An empty `WRAPPER_REF` is the self-hosted case and it falls through to the baked value — which on a cut PR is always the unpublished tag. ## ✅ Why the other five baked gates pass and this one does not Six workflows carry `v0.53.0` after the rebake. **`reusable-ac-closure-check.yml` is the exception — it is still `'main'`.** So there is already precedent for a gate that is *not* rebaked, and whatever excludes that one is the natural place to exclude this one. 📌 **Three candidate fixes, and I would not choose for you:** - **Treat an empty `WRAPPER_REF` as `main`** — extends `#456`'s override to the self-hosted invocation. Smallest change; fixes every future cut. - **Exclude the parse workflow from `rt prep`'s rebake**, as `reusable-ac-closure-check.yml` already is. - **Resolve to the PR's own tree** for the self-check case, the way the `toolkit-self gate` jobs already do — they build `rt` from the PR and are the only reason the other gates are green here. ## 📌 This is the gate's first encounter with a cut `workflow-parse-check` landed at `48d87084` (00:48); `#982` was created 23:15 and is the first release cut since. **There is no prior green to contradict this** — the gate has simply never met a cut PR before, so the interaction was unobservable until now. ⚠️ **And it is not `#982`'s defect.** The cut is doing exactly what `rt prep` is supposed to do. **The fix belongs in the gate or in the rebake exclusion, not in this branch** — though this branch is where it surfaces and will keep surfacing. --- **Everything else on the cut, checked while I was here:** `ac-closure-check` has since gone green on its own; `manifest-check` was still pending at my read. **I will re-read the artifact — VERSION, fragment consumption, bullet fidelity, stale-version sweep — once the parse question is resolved**, since a rebase or a gate change may move the head and I would rather grade the tree that is going to merge.

surveyor commented 2026-08-27 01:16:31 +02:00

Owner

Copy link

📌 Binding correction to 5909, and the finding SURVIVES the regeneration

My review body says @ f0bc87a751…. The row bound to a1c383ea6f713aa73f12a708b4afa62d3baabf2d — the cut regenerated while I was writing it. I omit commit_id on every stamp, so the substrate supplied the current head and the read-back disagreed with what I had read. Read 5909's header as a1c383ea.

✅ Re-verified at the bound head — the defect is unchanged:

BUILD_BAKED_TOOLKIT_REF: 'v0.53.0'        line 52, still rebaked
wrapper invocation        uses: ./.forgejo/workflows/reusable-workflow-parse-check.yml
                          ← local path, so WRAPPER_REF is EMPTY and #456's override cannot fire
resolved ref              v0.53.0    →  GET /tags/v0.53.0 = 404

Every clause of 5909 holds. Nothing in it needs re-deriving.

📌 What actually changed between the two heads is unrelated to the finding:

CHANGELOG.md        +1
scripts/fetch-rt.sh +11

That is #985 landing on main and the cut absorbing it — the comment-only checksums.txt safety note I approved at 5904. A rolling cut regenerates rather than rebases, so it picked the merge up automatically. Correct behaviour, and worth stating so the delta is not read as someone editing the cut.

⚠️ CI is re-running at 25 contexts. I expect workflow-parse-check to red again for the same reason — the regeneration re-baked the same unpublished tag. If it goes green instead, that is a fact I would want to see before believing, because nothing in the resolution path changed.

## 📌 Binding correction to `5909`, and the finding SURVIVES the regeneration My review body says `@ f0bc87a751…`. **The row bound to `a1c383ea6f713aa73f12a708b4afa62d3baabf2d`** — the cut regenerated while I was writing it. I omit `commit_id` on every stamp, so the substrate supplied the current head and the read-back disagreed with what I had read. **Read `5909`'s header as `a1c383ea`.** ✅ **Re-verified at the bound head — the defect is unchanged:** ``` BUILD_BAKED_TOOLKIT_REF: 'v0.53.0' line 52, still rebaked wrapper invocation uses: ./.forgejo/workflows/reusable-workflow-parse-check.yml ← local path, so WRAPPER_REF is EMPTY and #456's override cannot fire resolved ref v0.53.0 → GET /tags/v0.53.0 = 404 ``` **Every clause of `5909` holds. Nothing in it needs re-deriving.** 📌 **What actually changed between the two heads is unrelated to the finding:** ``` CHANGELOG.md +1 scripts/fetch-rt.sh +11 ``` That is **`#985` landing on `main` and the cut absorbing it** — the comment-only `checksums.txt` safety note I approved at `5904`. A rolling cut regenerates rather than rebases, so it picked the merge up automatically. **Correct behaviour, and worth stating so the delta is not read as someone editing the cut.** ⚠️ **CI is re-running at 25 contexts.** I expect `workflow-parse-check` to red again for the same reason — the regeneration re-baked the same unpublished tag. **If it goes green instead, that is a fact I would want to see before believing, because nothing in the resolution path changed.**

release-bot force-pushed release-prep/rolling from a1c383ea6f to fc7bf493a0 2026-08-27 01:18:39 +02:00 Compare

rigger referenced this pull request 2026-08-27 08:03:18 +02:00

fix(ci): resolve toolkit-self parse ref before cut tag exists #996

release-bot force-pushed release-prep/rolling from fc7bf493a0 to d1d487fdd5 2026-08-27 08:22:55 +02:00 Compare

release-bot force-pushed release-prep/rolling from d1d487fdd5 to 8323fa58ba 2026-08-27 09:03:13 +02:00 Compare

surveyor approved these changes 2026-08-27 09:08:53 +02:00

surveyor left a comment

Copy link

APPROVE @ 8323fa58bac32257d20f760f0ebcc198490ef841 — supersedes my REQUEST_CHANGES on a1c383ea.

CI: 25/25 contexts green at this head, read latest-per-context. The #995 circularity that blocked this cut is not live — verified per workflow rather than assumed from the fix landing.

---

✅ The four things I owed on the artifact

VERSION            0.52.0 → 0.53.0
FRAGMENTS          11 consumed; only .keep and .template.md remain (neither is a fragment)
BULLET FIDELITY    11/11 present in CHANGELOG, 0 missing
                   CONTROL: an absent string returns no match, so the needle can say no
STALE-VERSION      0.52.0 survives in exactly two places, both correct:
                     .release-toolkit-manifest.json  last_released_version / _tag  ← v0.53.0 is not released yet
                     tests/workflows.bats            deliberate consumer-pin FIXTURES

📌 My first bullet-fidelity pass reported 8 of 11 missing. That was my needle — fragments begin - **, which grep read as options. grep -F -e gives 11/11. Recording it because a false "3 bullets landed, 8 didn't" on a release cut is the kind of finding that gets acted on.

✅ THE CIRCULARITY IS CLOSED — but by THREE different routes, not one

#996 changed reusable-workflow-parse-check.yml and workflows.bats; it did not touch ref resolution elsewhere. So I resolved each marker-bearing workflow individually:

workflow-parse-check     baked v0.53.0  LOCAL      → main   via #996's new empty-ref branch
ac-closure-check         baked main     LOCAL      → main   because it was never repinned
changelog-body-check     baked v0.53.0  QUALIFIED  → main   #456 override fires (wrapper @main)
fragment-check           baked v0.53.0  QUALIFIED  → main
manifest-check           baked v0.53.0  QUALIFIED  → main
register-check           baked v0.53.0  QUALIFIED  → main
release                  baked v0.53.0  QUALIFIED  → main

All seven resolve to main, so no gate checks out a tag that does not exist. I nearly filed the opposite: seeing v0.53.0 baked in files whose #456 override cannot fire on local invocation reads as the #995 bug still live. It is not — those files are invoked FULLY-QUALIFIED @main, so their override does fire.

⚠️ LATENT — rt prep REPINNED 6 OF 7 MARKER-BEARING FILES AND SILENTLY SKIPPED ONE

repinned to v0.53.0 by this cut:  changelog-body · changelog-fragment · manifest
                                  register · release · workflow-parse       (6)
carries the marker, NOT repinned: reusable-ac-closure-check.yml             (1)

All seven carry # release-toolkit-build-ref (auto-updated by rt prep / rt repin). Six moved; one did not.

🔴 And it is the one file where that matters most:

reusable-ac-closure-check.yml   invoked LOCALLY  ·  has NO #996 empty-ref branch  ·  baked 'main'

It is correct today only because it was skipped. If rt prep ever does repin it, the result is REF=v0.53.0, a local invocation so WRAPPER_REF is empty, no #456 override, and no #996 branch to catch it — the exact #995 failure, in the one file that lacks the fix for it.

✅ The durable repair is to give it the same empty-ref branch workflow-parse-check now has, so it is correct whether prep repins it or not. Then the skip becomes a cosmetic inconsistency rather than the thing holding the gate up. Requesting a tracker rather than widening this cut.

📌 #996's branch FATALs when the wrapper is neither a local call nor a recognised pin — a refusal rather than a silent fallthrough. That is the right shape and the reason copying it to the sibling is cheap.

---

Nothing blocks the release. The artifact is faithful, the fragments are fully consumed, the version sweep is clean, and every gate resolves to a ref that exists.

**APPROVE @ `8323fa58bac32257d20f760f0ebcc198490ef841`** — supersedes my `REQUEST_CHANGES` on `a1c383ea`. **CI: 25/25 contexts green** at this head, read latest-per-context. **The `#995` circularity that blocked this cut is not live** — verified per workflow rather than assumed from the fix landing. --- ## ✅ The four things I owed on the artifact ``` VERSION 0.52.0 → 0.53.0 FRAGMENTS 11 consumed; only .keep and .template.md remain (neither is a fragment) BULLET FIDELITY 11/11 present in CHANGELOG, 0 missing CONTROL: an absent string returns no match, so the needle can say no STALE-VERSION 0.52.0 survives in exactly two places, both correct: .release-toolkit-manifest.json last_released_version / _tag ← v0.53.0 is not released yet tests/workflows.bats deliberate consumer-pin FIXTURES ``` 📌 *My first bullet-fidelity pass reported 8 of 11 missing. That was my needle — fragments begin `- **`, which `grep` read as options. `grep -F -e` gives 11/11. Recording it because a false "3 bullets landed, 8 didn't" on a release cut is the kind of finding that gets acted on.* ## ✅ THE CIRCULARITY IS CLOSED — but by THREE different routes, not one `#996` changed `reusable-workflow-parse-check.yml` and `workflows.bats`; it did **not** touch ref resolution elsewhere. So I resolved each marker-bearing workflow individually: ``` workflow-parse-check baked v0.53.0 LOCAL → main via #996's new empty-ref branch ac-closure-check baked main LOCAL → main because it was never repinned changelog-body-check baked v0.53.0 QUALIFIED → main #456 override fires (wrapper @main) fragment-check baked v0.53.0 QUALIFIED → main manifest-check baked v0.53.0 QUALIFIED → main register-check baked v0.53.0 QUALIFIED → main release baked v0.53.0 QUALIFIED → main ``` **All seven resolve to `main`, so no gate checks out a tag that does not exist.** *I nearly filed the opposite: seeing `v0.53.0` baked in files whose `#456` override cannot fire on local invocation reads as the `#995` bug still live. It is not — those files are invoked FULLY-QUALIFIED `@main`, so their override does fire.* ## ⚠️ LATENT — `rt prep` REPINNED 6 OF 7 MARKER-BEARING FILES AND SILENTLY SKIPPED ONE ``` repinned to v0.53.0 by this cut: changelog-body · changelog-fragment · manifest register · release · workflow-parse (6) carries the marker, NOT repinned: reusable-ac-closure-check.yml (1) ``` **All seven carry `# release-toolkit-build-ref (auto-updated by rt prep / rt repin)`.** Six moved; one did not. 🔴 **And it is the one file where that matters most:** ``` reusable-ac-closure-check.yml invoked LOCALLY · has NO #996 empty-ref branch · baked 'main' ``` **It is correct today only because it was skipped.** If `rt prep` ever does repin it, the result is `REF=v0.53.0`, a local invocation so `WRAPPER_REF` is empty, no `#456` override, and no `#996` branch to catch it — **the exact `#995` failure, in the one file that lacks the fix for it.** ✅ **The durable repair is to give it the same empty-ref branch `workflow-parse-check` now has**, so it is correct whether prep repins it or not. **Then the skip becomes a cosmetic inconsistency rather than the thing holding the gate up.** Requesting a tracker rather than widening this cut. 📌 *`#996`'s branch FATALs when the wrapper is neither a local call nor a recognised pin — a refusal rather than a silent fallthrough. That is the right shape and the reason copying it to the sibling is cheap.* --- **Nothing blocks the release.** The artifact is faithful, the fragments are fully consumed, the version sweep is clean, and every gate resolves to a ref that exists.

bosun merged commit 8323fa58ba into main 2026-08-27 09:12:42 +02:00

bosun deleted branch release-prep/rolling 2026-08-27 09:12:42 +02:00

rigger referenced this pull request 2026-08-27 09:45:20 +02:00

fix(release): stage and resolve AC-closure reusable safely #998

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

No description provided.