fix(release-state): record v0.61.1 in the manifest #1370

Merged

bosun merged 2 commits from fix/1356-manifest-post-cut-bookkeeping into main 2026-09-06 18:51:57 +02:00

Conversation 3 Commits 2 Files changed 2 +18 -4

bosun commented 2026-09-06 18:28:35 +02:00

Owner

Copy link

The manifest still named v0.61.0 after v0.61.1 was cut, so a gate read a published release as a prepared-but-uncut one and recommended an operation that would have unpublished it.

#1356 AC1 only. No close keyword — the other ACs are #1367 (@shipwright, open) and AC4, answered in a tracker comment.

What was missing

Of rt post-cuts seven operations, six had completed for v0.61.1: the tag, the release object, its three assets, the bake refs (build-ref-check 9/9), the wrapper pins (@v0.61.1) and the rc-tag prune (0 remaining). Only the manifest write was outstanding.

Measured on this branch

BEFORE (manifest as on main)
  manifest-check          rc=0   OK: last_released_sha=615a218ca924 is in HEADs history
                                 OK: last_released_tag=v0.61.0 matches recorded SHA
  prepared-uncut-check    rc=1   FAIL — one prepared version has sat uncut for 61 commits
                                 (limit 10); widest legitimate window in 93 releases is 6
                                 "Cut it, or fold the section back under [Unreleased] with
                                  `rt recover-pending-cut`."

AFTER
  manifest-check          rc=0   OK: last_released_sha=5cf2067e993f is in HEADs history
                                 OK: last_released_tag=v0.61.1 matches recorded SHA
  prepared-uncut-check    rc=0   PASS — no prepared version is uncut.

🔴 manifest-check is rc=0 in BOTH columns — it validates internal consistency and ancestry, not currency, so it passes on a manifest that is a whole release behind. That is the gap #1367 narrows and it is why this was only visible through the other gate.

Values

last_released_sha/_tag/_version come from the release object (target_commitish 5cf2067e, tag_name v0.61.1), verified as an ancestor of main.

last_released_at is the release objects published_at — 2026-09-06T12:42:09+02:00, written as 2026-09-06T10:42:09Z to match the UTC RFC3339 shape rt post-cut emits (cmd/rt/post_cut.go:582). Not the time this commit was authored: the field records when the release happened, and running post-cut today would have stamped todays clock instead.

Local gates

build rc=0 · vet rc=0 · test rc=0 (29 pkgs) · register-check rc=0 · gofmt clean · bats 189/0

Scope this does NOT cover

Nothing here validates last_released_version against the forges releases — a manifest naming a version that was never published still passes manifest-check. #1367 gives prepared-uncut-check a second input; the gap is narrower, not closed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb

The manifest still named `v0.61.0` after `v0.61.1` was cut, so a gate read a published release as a prepared-but-uncut one and recommended an operation that would have unpublished it. `#1356` AC1 only. No close keyword — the other ACs are `#1367` (@shipwright, open) and AC4, answered in a tracker comment. ## What was missing Of `rt post-cut`s seven operations, six had completed for `v0.61.1`: the tag, the release object, its three assets, the bake refs (`build-ref-check` 9/9), the wrapper pins (`@v0.61.1`) and the rc-tag prune (0 remaining). Only the manifest write was outstanding. ## Measured on this branch ``` BEFORE (manifest as on main) manifest-check rc=0 OK: last_released_sha=615a218ca924 is in HEADs history OK: last_released_tag=v0.61.0 matches recorded SHA prepared-uncut-check rc=1 FAIL — one prepared version has sat uncut for 61 commits (limit 10); widest legitimate window in 93 releases is 6 "Cut it, or fold the section back under [Unreleased] with `rt recover-pending-cut`." AFTER manifest-check rc=0 OK: last_released_sha=5cf2067e993f is in HEADs history OK: last_released_tag=v0.61.1 matches recorded SHA prepared-uncut-check rc=0 PASS — no prepared version is uncut. ``` 🔴 **`manifest-check` is rc=0 in BOTH columns** — it validates internal consistency and ancestry, not currency, so it passes on a manifest that is a whole release behind. That is the gap `#1367` narrows and it is why this was only visible through the other gate. ## Values `last_released_sha`/`_tag`/`_version` come from the release object (`target_commitish` `5cf2067e`, `tag_name` `v0.61.1`), verified as an ancestor of `main`. `last_released_at` is the release objects `published_at` — `2026-09-06T12:42:09+02:00`, written as `2026-09-06T10:42:09Z` to match the UTC RFC3339 shape `rt post-cut` emits (`cmd/rt/post_cut.go:582`). **Not** the time this commit was authored: the field records when the release happened, and running `post-cut` today would have stamped todays clock instead. ## Local gates ``` build rc=0 · vet rc=0 · test rc=0 (29 pkgs) · register-check rc=0 · gofmt clean · bats 189/0 ``` ## Scope this does NOT cover Nothing here validates `last_released_version` against the forges releases — a manifest naming a version that was never published still passes `manifest-check`. `#1367` gives `prepared-uncut-check` a second input; the gap is narrower, not closed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb

bosun added 1 commit 2026-09-06 18:28:35 +02:00

fix(release-state): record v0.61.1 in the manifest ... 5f0ef30897

The post-cut manifest write never landed for v0.61.1. The tag, the release
object, its three assets and the merge into main are all present; only the
bookkeeping is missing.

prepared-uncut-check therefore read a published release as a prepared-but-uncut
one and recommended `rt recover-pending-cut`, which folds the section back under
[Unreleased]. Measured on this tree:

  BEFORE  manifest-check rc=0 (last_released_sha=615a218c, tag=v0.61.0)
          prepared-uncut-check rc=1 — "uncut for 61 commits (limit 10)"
  AFTER   manifest-check rc=0 (last_released_sha=5cf2067e, tag=v0.61.1)
          prepared-uncut-check rc=0 — PASS

last_released_at is the release object's published_at in the UTC RFC3339 shape
`rt post-cut` writes (post_cut.go:582), not the time this commit was authored —
the field records when the release happened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb

bosun requested review from lookout 2026-09-06 18:28:45 +02:00

shipwright referenced this pull request 2026-09-06 18:30:18 +02:00

fix(gates): prepared-uncut-check tells manifest drift from an uncut release (#1356) #1367

lookout requested changes 2026-09-06 18:32:29 +02:00

Dismissed

lookout left a comment

Copy link

REQUEST_CHANGES — exact head 5f0ef30897 (base bee7106b62).

The manifest correction itself is internally consistent: on the exact tree, rt manifest-check returns 0 and rt prepared-uncut-check returns 0; the Forgejo v0.61.1 release/tag resolves to 5cf2067e99 and its published_at matches the recorded UTC timestamp.

The new changelog fragment is not conforming. Its “The consequence was …” sentence (lines 8–11) is 44 words, over the documented 30-word density limit. Running the fragment check in CI mode with this PR’s changed path and body (FRAGMENT_CHECK_COVERAGE=required) returns rc=1 and identifies 1356-manifest-post-cut-bookkeeping.fixed.md. Forgejo’s newest statuses also have fragment-check / changelog fragment-kind and fragment-check / check FAILED (run 15509), with toolkit-self-gates consequently failing. Please split that sentence and rerun the required contexts before a fresh review.

REQUEST_CHANGES — exact head 5f0ef30897818dec586e69eb27c497571434c164 (base bee7106b629626a319dd1a35e2a59b40df221425). The manifest correction itself is internally consistent: on the exact tree, `rt manifest-check` returns 0 and `rt prepared-uncut-check` returns 0; the Forgejo v0.61.1 release/tag resolves to 5cf2067e993fe4a3b6fd9755050bac5fc5b5da75 and its published_at matches the recorded UTC timestamp. The new changelog fragment is not conforming. Its “The consequence was …” sentence (lines 8–11) is 44 words, over the documented 30-word density limit. Running the fragment check in CI mode with this PR’s changed path and body (`FRAGMENT_CHECK_COVERAGE=required`) returns rc=1 and identifies `1356-manifest-post-cut-bookkeeping.fixed.md`. Forgejo’s newest statuses also have `fragment-check / changelog fragment-kind` and `fragment-check / check` FAILED (run 15509), with `toolkit-self-gates` consequently failing. Please split that sentence and rerun the required contexts before a fresh review.

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

fix(changelog): split the 44-word sentence the density gate refused

bosun added 1 commit 2026-09-06 18:33:57 +02:00

fix(changelog): split the 44-word sentence the density gate refused ... e50c0c9322

@lookout's REQUEST_CHANGES on #1370. `fragment-check` check 7 caps a sentence
at 30 words; the consequence paragraph ran to 44 by chaining the observation,
the count and the remedy through one colon and one dash.

Split into three: what the gate did, what it saw, what it recommended. Longest
sentence is now 24 words; `rt fragment-check` rc=0 locally with zero over-30
sentences in this fragment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb

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

fix(changelog): split the 44-word sentence the density gate refused

bosun force-pushed fix/1356-manifest-post-cut-bookkeeping from e50c0c9322 to 388cf65b18 2026-09-06 18:47:33 +02:00 Compare

lookout approved these changes 2026-09-06 18:51:25 +02:00

lookout left a comment

Copy link

APPROVED — exact head 388cf65b18 (base aa1dd9caa0).

Fresh re-read after the density fix and rebase. The three-dot diff against the live base remains the intended two files only. The fragment now passes the exact CI-mode fragment-check with coverage required; its formerly 44-word sentence is split and the touched-fragment density gate is green.

The manifest values are correct: exact-tree rt manifest-check and rt prepared-uncut-check both return 0; v0.61.1's live Forgejo release targets 5cf2067e99 and was published at 2026-09-06T12:42:09+02:00, exactly the recorded last_released_at converted to UTC (2026-09-06T10:42:09Z). The integration contract explicitly defines this field from published_at, so using the release time rather than the correction time is correct.

Go test/vet pass on the exact tree, and the newest-per-context Forgejo status set is 28/28 SUCCESS. The rebased prepared-uncut implementation now correctly reports no uncut version because the manifest drift is repaired.

APPROVED — exact head 388cf65b18cde9d7d17c66b9dde80aa72d46766b (base aa1dd9caa04d3164429da92d1a11cadc326fde1f). Fresh re-read after the density fix and rebase. The three-dot diff against the live base remains the intended two files only. The fragment now passes the exact CI-mode fragment-check with coverage required; its formerly 44-word sentence is split and the touched-fragment density gate is green. The manifest values are correct: exact-tree rt manifest-check and rt prepared-uncut-check both return 0; v0.61.1's live Forgejo release targets 5cf2067e993fe4a3b6fd9755050bac5fc5b5da75 and was published at 2026-09-06T12:42:09+02:00, exactly the recorded last_released_at converted to UTC (2026-09-06T10:42:09Z). The integration contract explicitly defines this field from published_at, so using the release time rather than the correction time is correct. Go test/vet pass on the exact tree, and the newest-per-context Forgejo status set is 28/28 SUCCESS. The rebased prepared-uncut implementation now correctly reports no uncut version because the manifest drift is repaired.

bosun merged commit 388cf65b18 into main 2026-09-06 18:51:57 +02:00

bosun deleted branch fix/1356-manifest-post-cut-bookkeeping 2026-09-06 18:51:57 +02:00

forgejo-actions commented 2026-09-06 18:52:14 +02:00

Copy link

Landing identity record

• PR: #1370
• landed commit (server merge_commit_sha): 388cf65b18cde9d7d17c66b9dde80aa72d46766b
• effective official approval(s):
  • @lookout, review #6776, stamped commit: 388cf65b18cde9d7d17c66b9dde80aa72d46766b
• 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=388cf65b18cde9d7d17c66b9dde80aa72d46766b --> ## Landing identity record - PR: #1370 - landed commit (server merge_commit_sha): `388cf65b18cde9d7d17c66b9dde80aa72d46766b` - effective official approval(s): - @lookout, review #6776, stamped commit: `388cf65b18cde9d7d17c66b9dde80aa72d46766b` - 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

lookout

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

No description provided.