frankenbit/release-toolkit

Watch

Fork 0

bug(recovery): the recovery PR body still says #1173 has not landed #1500

New issue

Closed

opened 2026-10-02 11:29:26 +02:00 by claude · 1 comment

claude commented

2026-10-02 11:29:26 +02:00

Member

The PR body that reusable-recover-pending-cut.yml writes for a recovery (B) still tells the reviewer that release-toolkit#1173 has not landed, and that a tag-pinned adopter may be running an older recovery binary. #1173 shipped in v0.58.0. Every recovery PR opened since then carries a false caveat.

Measured

The sentence, in the **Tagged-adopter dependency:** printf at .forgejo/workflows/reusable-recover-pending-cut.yml:427 and the .gitea twin at :440, on main @ 55a12b9:

At the current main snapshot, reusable-recover-pending-cut.yml is not yet in the internal/bake/marker.go canonical file set, so a consumer pinned at a release tag can run the older recovery binary until #1173 lands.

#1173 is closed (2026-09-05). 1347777 adds the file to canonicalFiles in internal/bake/marker.go. bd28bdd adds it to bakeRefFiles in cmd/rt/prep.go.
The file's BUILD_BAKED_TOOLKIT_REF, read at each tag. Tag SHAs were checked against git ls-remote on the forge, 2026-10-02.

tag                .forgejo     .gitea
v0.57.0..v0.57.4   'v0.57.0'    'v0.57.0'     <- frozen
v0.58.0            'v0.58.0'    'v0.58.0'     <- first baked tag
v0.59.0..v0.63.1   own name     own name      (all 11 tags in that range)

The fragment restore (#1166) first ships in v0.57.3 (CHANGELOG.md ## [v0.57.3]). So a tag pin runs the restore only from v0.58.0.
docs/integration.md § Cut-cancellation recovery, recovery (B), was corrected in dc9df38. The workflow text was not.

Why it matters

A reviewer reading a recovery PR is asked to doubt the binary that produced the fold, and is pointed at a fix that shipped on 2026-09-05, in v0.58.0. The caveat also cannot apply to anyone who reads it. The resolve toolkit ref step picks the binary from the same ref as the workflow file: the baked marker (a tag's own name from v0.58.0), main for toolkit-self and @main pins, the consumer's own SHA for a SHA pin, or the wrapper ref as a fallback. A run that prints corrected text is necessarily newer than v0.58.0.

Acceptance criteria

The recovery PR body no longer says #1173 is unlanded, in .forgejo and .gitea alike, and rt gitea-twin --check passes. — DONE @ #1504 (c231c21, reviewed as c231c21; removed in 50d132f, both twins, gitea-twin-check green)
Any replacement text is ASCII-only (AGENTS.md section 11) and makes no claim that a run printing it can contradict. — DONE @ #1504 (c231c21, reviewed as c231c21; the body carries no replacement text, and the new bash comment is ASCII and names only the supported pin shapes)
The tests that cover this workflow pass: the recovery arms in tests/workflows.bats, plus internal/bake, internal/selfboot and cmd/rt. — DONE @ #1504 (c231c21, reviewed as c231c21; required tests / bats and go-ci green on the PR, bats 221/221 and go test ./... ok locally)
A changelog fragment ships the correction. — DONE @ #1504 (c231c21, reviewed as c231c21; changelog.d/1500-recovery-body-1173.fixed.md)
docs/integration.md recovery (B) names toolkit-self's actual path for its @main pin, the release-toolkit#456 floating-pin override, not a "local" invocation. (Added 2026-10-02. It is carried over from #1499's second criterion, after its PR #1522 was withdrawn in favour of #1504.) — DONE @ #1504 (c231c21, reviewed as c231c21; landed in c231c21)

Anchor

Measured 2026-10-02 against forge main @ 55a12b9 and tags v0.57.0 through v0.63.1.

The PR body that `reusable-recover-pending-cut.yml` writes for a recovery (B) still tells the reviewer that release-toolkit#1173 has not landed, and that a tag-pinned adopter may be running an older recovery binary. #1173 shipped in v0.58.0. Every recovery PR opened since then carries a false caveat. ## Measured The sentence, in the `**Tagged-adopter dependency:**` printf at `.forgejo/workflows/reusable-recover-pending-cut.yml:427` and the `.gitea` twin at `:440`, on `main` @ `55a12b9`: > At the current main snapshot, `reusable-recover-pending-cut.yml` is not yet in the `internal/bake/marker.go` canonical file set, so a consumer pinned at a release tag can run the older recovery binary until #1173 lands. - #1173 is closed (2026-09-05). `1347777` adds the file to `canonicalFiles` in `internal/bake/marker.go`. `bd28bdd` adds it to `bakeRefFiles` in `cmd/rt/prep.go`. - The file's `BUILD_BAKED_TOOLKIT_REF`, read at each tag. Tag SHAs were checked against `git ls-remote` on the forge, 2026-10-02. ``` tag .forgejo .gitea v0.57.0..v0.57.4 'v0.57.0' 'v0.57.0' <- frozen v0.58.0 'v0.58.0' 'v0.58.0' <- first baked tag v0.59.0..v0.63.1 own name own name (all 11 tags in that range) ``` - The fragment restore (#1166) first ships in v0.57.3 (`CHANGELOG.md` `## [v0.57.3]`). So a tag pin runs the restore only from v0.58.0. - `docs/integration.md` § Cut-cancellation recovery, recovery (B), was corrected in `dc9df38`. The workflow text was not. ## Why it matters A reviewer reading a recovery PR is asked to doubt the binary that produced the fold, and is pointed at a fix that shipped on 2026-09-05, in v0.58.0. The caveat also cannot apply to anyone who reads it. The `resolve toolkit ref` step picks the binary from the same ref as the workflow file: the baked marker (a tag's own name from v0.58.0), `main` for toolkit-self and `@main` pins, the consumer's own SHA for a SHA pin, or the wrapper ref as a fallback. A run that prints corrected text is necessarily newer than v0.58.0. ## Acceptance criteria - [x] The recovery PR body no longer says #1173 is unlanded, in `.forgejo` and `.gitea` alike, and `rt gitea-twin --check` passes. — DONE @ #1504 (`c231c21`, reviewed as `c231c21`; removed in `50d132f`, both twins, `gitea-twin-check` green) - [x] Any replacement text is ASCII-only (AGENTS.md section 11) and makes no claim that a run printing it can contradict. — DONE @ #1504 (`c231c21`, reviewed as `c231c21`; the body carries no replacement text, and the new bash comment is ASCII and names only the supported pin shapes) - [x] The tests that cover this workflow pass: the recovery arms in `tests/workflows.bats`, plus `internal/bake`, `internal/selfboot` and `cmd/rt`. — DONE @ #1504 (`c231c21`, reviewed as `c231c21`; required `tests / bats` and `go-ci` green on the PR, bats 221/221 and `go test ./...` ok locally) - [x] A changelog fragment ships the correction. — DONE @ #1504 (`c231c21`, reviewed as `c231c21`; `changelog.d/1500-recovery-body-1173.fixed.md`) - [x] `docs/integration.md` recovery (B) names toolkit-self's actual path for its `@main` pin, the release-toolkit#456 floating-pin override, not a "local" invocation. *(Added 2026-10-02. It is carried over from #1499's second criterion, after its PR #1522 was withdrawn in favour of #1504.)* — DONE @ #1504 (`c231c21`, reviewed as `c231c21`; landed in `c231c21`) ## Anchor Measured 2026-10-02 against forge `main` @ `55a12b9` and tags v0.57.0 through v0.63.1.

claude added the

labels

2026-10-02 11:29:26 +02:00

claude referenced this issue from a commit

2026-10-02 11:35:04 +02:00

fix(recovery): drop the stale #1173 caveat from the recovery PR body (#1500)

claude referenced this issue

2026-10-02 11:35:32 +02:00

fix(recovery): drop the stale #1173 caveat from the recovery PR body (#1500) #1504

claude referenced this issue

2026-10-02 21:21:55 +02:00

fix(recover-pending-cut): drop the stale #1173 note from the recovery PR body (#1499) #1522

claude referenced this issue

2026-10-02 21:21:57 +02:00

recover-pending-cut's PR body still says #1173 has not landed; it shipped in v0.58.0 #1499

alex referenced this issue from a commit

2026-10-02 21:22:22 +02:00

fix(recovery): drop the stale #1173 caveat from the recovery PR body (#1500)

claude referenced this issue from a commit

2026-10-02 21:44:28 +02:00

chore(recovery): name each pin shape in the no-caveat comment (#1500)

claude referenced this issue from a commit

2026-10-02 21:44:28 +02:00

docs(recovery): toolkit-self's @main pin takes the #456 override (#1500)

release-bot referenced this issue

2026-10-02 21:55:08 +02:00

chore(release): v0.65.0 #1523

claude commented

2026-10-02 22:36:18 +02:00

Author

Member

This landed through PR #1504 as c231c21f8ebb06d5467c9142f632455e49893352. The merge was fast-forward-only and pinned to the approved head, so what landed is what was reviewed: git range-diff shows all three commits as =.

Commits:
- 50d132f removes the printf from both twins and adds the fragment.
- e5e61ca makes the bash comment name each supported pin shape.
- c231c21 corrects the docs/integration.md recovery (B) wording (the fifth criterion).
Review:
- alex approved at c231c21 (review 7200, official, not stale).
- The verify-at-source review is 7199, made at 50d132f. The two commits after it carry that review's items.
PR checks at c231c21:
- All 25 required contexts passed.
- The one red was readme-pin-check / mirror, which is not required. It flagged pins still at v0.63.0, which #1519 has since bumped.
push:main at c231c21:
- Every job that ran succeeded, including go-ci / record reviewed vs landed commit and tests / bats.
- rt decide printed mode=update, so no cut.
- release / fire-cut and go-ci / page landing-tree failure still show pending status rows. Their job logs say both were skipped because their if conditions were false, so those rows are stale proxies (AGENTS.md section 8, Axis C).

All five acceptance criteria are ticked above. Adopters get the corrected recovery PR body from the next cut tag. I'm shutting this by hand, per AGENTS.md section 15.

This landed through PR #1504 as `c231c21f8ebb06d5467c9142f632455e49893352`. The merge was fast-forward-only and pinned to the approved head, so what landed is what was reviewed: `git range-diff` shows all three commits as `=`. - **Commits:** - `50d132f` removes the printf from both twins and adds the fragment. - `e5e61ca` makes the bash comment name each supported pin shape. - `c231c21` corrects the `docs/integration.md` recovery (B) wording (the fifth criterion). - **Review:** - alex approved at `c231c21` (review 7200, official, not stale). - The verify-at-source review is 7199, made at `50d132f`. The two commits after it carry that review's items. - **PR checks at `c231c21`:** - All 25 required contexts passed. - The one red was `readme-pin-check / mirror`, which is not required. It flagged pins still at v0.63.0, which #1519 has since bumped. - **push:main at `c231c21`:** - Every job that ran succeeded, including `go-ci / record reviewed vs landed commit` and `tests / bats`. - `rt decide` printed `mode=update`, so no cut. - `release / fire-cut` and `go-ci / page landing-tree failure` still show `pending` status rows. Their job logs say both were skipped because their `if` conditions were false, so those rows are stale proxies (AGENTS.md section 8, Axis C). All five acceptance criteria are ticked above. Adopters get the corrected recovery PR body from the next cut tag. I'm shutting this by hand, per AGENTS.md section 15.

claude closed this issue

2026-10-02 22:36:18 +02:00

claude referenced this issue

2026-10-02 22:36:26 +02:00

recover-pending-cut's PR body still says #1173 has not landed; it shipped in v0.58.0 #1499