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

claude commented

2026-10-02 11:27:08 +02:00

Member

The recovery (B) PR that reusable-recover-pending-cut.yml opens still tells its reviewer that release-toolkit#1173 has not landed. It landed on 2026-09-05, and every release since v0.58.0 carries it.

Measured

On live main @ 55a12b9 (2026-10-02), the PR-body builder emits this paragraph from .forgejo/workflows/reusable-recover-pending-cut.yml:427 and its twin .gitea/workflows/reusable-recover-pending-cut.yml:440:

Tagged-adopter dependency: this fix is in the recovery binary selected by the workflow. 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. Toolkit-self uses its local @main override; #1173 remains a separate bake-population fix.

What is true instead:

#1173 is closed (2026-09-05). 1347777 added the file to canonicalFiles, and bd28bdd (#1190) added it to bakeRefFiles.
The file's baked ref, read on 2026-10-02 at the forge's tag SHAs. git ls-remote matched the local tags one-for-one, and the contents API at v0.58.0 returned blob 5cb836d1, the same blob as the local tag:

tag              BUILD_BAKED_TOOLKIT_REF (.forgejo and .gitea)
v0.57.0-v0.57.4  'v0.57.0'
v0.58.0-v0.63.1  each tag's own name (12 tags, all match)

docs/integration.md carried the same sentence, and dc9df38 (#1484) corrected it. Nothing corrected the PR-body copy, and no remote branch changes it (every branch diffed against main, 2026-10-02).

Both copies also carry a smaller inaccuracy. Toolkit-self's wrapper (.forgejo/workflows/recover-pending-cut.yml:33) pins frankenbit/release-toolkit/...@main. The resolve step routes that pin through the release-toolkit#456 floating-pin arm (SOURCE="floating-pin-override (release-toolkit#456)"). It does not use the toolkit-self local invocation arm, which handles a ./.forgejo/... uses line. The PR body says "its local @main override", and docs/integration.md says "Toolkit-self's local @main invocation".

Why it matters

The PR body is what the operator reads before merging the fold. Telling them a fix is still pending sends them looking for a gap that closed a month ago. Because the text is generated, no review ever reads it again.

Remove or rewrite

The paragraph reaches a reader only through the YAML at the ref the adopter runs. Any ref that could render NEW text here also runs a correctly baked rt:

a release tag after the change: the bake (every tag from v0.58.0 names itself);
@main: the #456 floating-pin override;
a commit SHA: bootstrap rt refuses it with a pin-a-release-tag remedy (#1514, composite/bootstrap-rt/action.yml:9-11), so no recovery runs at all.

So:

Remove the paragraph when no run that renders it can act on it. The list above argues that is every run.
Rewrite it only if the PR-body reader needs the v0.58.0 floor for some other adopter. That floor already lives in docs/integration.md, the page that tells adopters what to pin.

Acceptance criteria

The recovery PR body no longer says #1173 is pending, in both the .forgejo and .gitea twins (gitea-twin-check green).
docs/integration.md names toolkit-self's actual path for its @main pin (the #456 floating-pin override), not a "local" invocation.
git grep -n 1173 -- .forgejo .gitea cmd internal returns only historical references; none says #1173 is pending.

Notes for the implementer

reusable-recover-pending-cut.yml is in gates.DefaultComposeScripts, but every toolkit-self wrapper pins @main, so check-self-bootstrap takes the #456 floating-pin early exit and passes. No re-pin follows. (Corrected 2026-10-02: the first version of this note said the check would go red, following AGENTS.md section 2. Measured instead; see the comment below.)
Write no @vX.Y.Z tokens in prose. readme-pin-check scans docs/integration.md and reads @v<semver> as a prescriptive pin.
Workflow YAML stays ASCII-only (AGENTS.md section 11).

The recovery (B) PR that `reusable-recover-pending-cut.yml` opens still tells its reviewer that release-toolkit#1173 has not landed. It landed on 2026-09-05, and every release since v0.58.0 carries it. ## Measured On live `main` @ `55a12b9` (2026-10-02), the PR-body builder emits this paragraph from `.forgejo/workflows/reusable-recover-pending-cut.yml:427` and its twin `.gitea/workflows/reusable-recover-pending-cut.yml:440`: > **Tagged-adopter dependency:** this fix is in the recovery binary selected by the workflow. 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. Toolkit-self uses its local `@main` override; #1173 remains a separate bake-population fix. What is true instead: - #1173 is closed (2026-09-05). `1347777` added the file to `canonicalFiles`, and `bd28bdd` (#1190) added it to `bakeRefFiles`. - The file's baked ref, read on 2026-10-02 at the forge's tag SHAs. `git ls-remote` matched the local tags one-for-one, and the contents API at `v0.58.0` returned blob `5cb836d1`, the same blob as the local tag: ``` tag BUILD_BAKED_TOOLKIT_REF (.forgejo and .gitea) v0.57.0-v0.57.4 'v0.57.0' v0.58.0-v0.63.1 each tag's own name (12 tags, all match) ``` - `docs/integration.md` carried the same sentence, and `dc9df38` (#1484) corrected it. Nothing corrected the PR-body copy, and no remote branch changes it (every branch diffed against `main`, 2026-10-02). Both copies also carry a smaller inaccuracy. Toolkit-self's wrapper (`.forgejo/workflows/recover-pending-cut.yml:33`) pins `frankenbit/release-toolkit/...@main`. The resolve step routes that pin through the release-toolkit#456 floating-pin arm (`SOURCE="floating-pin-override (release-toolkit#456)"`). It does not use the `toolkit-self local invocation` arm, which handles a `./.forgejo/...` uses line. The PR body says "its local `@main` override", and `docs/integration.md` says "Toolkit-self's local `@main` invocation". ## Why it matters The PR body is what the operator reads before merging the fold. Telling them a fix is still pending sends them looking for a gap that closed a month ago. Because the text is generated, no review ever reads it again. ## Remove or rewrite The paragraph reaches a reader only through the YAML at the ref the adopter runs. Any ref that could render NEW text here also runs a correctly baked `rt`: - a release tag after the change: the bake (every tag from v0.58.0 names itself); - `@main`: the #456 floating-pin override; - a commit SHA: `bootstrap rt` refuses it with a pin-a-release-tag remedy (#1514, `composite/bootstrap-rt/action.yml:9-11`), so no recovery runs at all. So: - **Remove the paragraph** when no run that renders it can act on it. The list above argues that is every run. - **Rewrite it** only if the PR-body reader needs the v0.58.0 floor for some other adopter. That floor already lives in `docs/integration.md`, the page that tells adopters what to pin. ## Acceptance criteria - [ ] The recovery PR body no longer says #1173 is pending, in both the `.forgejo` and `.gitea` twins (`gitea-twin-check` green). - [ ] `docs/integration.md` names toolkit-self's actual path for its `@main` pin (the #456 floating-pin override), not a "local" invocation. - [ ] `git grep -n 1173 -- .forgejo .gitea cmd internal` returns only historical references; none says #1173 is pending. ## Notes for the implementer - `reusable-recover-pending-cut.yml` is in `gates.DefaultComposeScripts`, but every toolkit-self wrapper pins `@main`, so `check-self-bootstrap` takes the #456 floating-pin early exit and passes. No re-pin follows. *(Corrected 2026-10-02: the first version of this note said the check would go red, following AGENTS.md section 2. Measured instead; see the comment below.)* - Write no `@vX.Y.Z` tokens in prose. `readme-pin-check` scans `docs/integration.md` and reads `@v<semver>` as a prescriptive pin. - Workflow YAML stays ASCII-only (AGENTS.md section 11).

claude added the

labels

2026-10-02 11:27:08 +02:00

claude commented

2026-10-02 21:17:40 +02:00

Author

Member

Body corrected in two places, both measured rather than inferred:

No re-pin follows. The first version said check-self-bootstrap would go red after merge, following AGENTS.md section 2. Every toolkit-self wrapper pins @main (7 of 7 uses: lines under .forgejo/workflows/), so the check exits early. Run on the change itself (8333455, in a container on an LF clone):
```
[check-self-bootstrap] pinned toolkit ref: main
[check-self-bootstrap] floating-pin (release-toolkit#456): main matches main by construction
rc=0
```
SHA pins. The "remove or rewrite" list cited the #336 SHA-pin arm. Since #1514, bootstrap rt refuses a commit SHA with a pin-a-release-tag remedy (composite/bootstrap-rt/action.yml:9-11), so a SHA-pinned run never reaches the PR body at all. The conclusion (remove) is unchanged.

AGENTS.md section 2 still describes the pre-#456 shape for toolkit-self. That is a separate doc gap, not this issue.

Body corrected in two places, both measured rather than inferred: 1. **No re-pin follows.** The first version said `check-self-bootstrap` would go red after merge, following AGENTS.md section 2. Every toolkit-self wrapper pins `@main` (7 of 7 `uses:` lines under `.forgejo/workflows/`), so the check exits early. Run on the change itself (`8333455`, in a container on an LF clone): ``` [check-self-bootstrap] pinned toolkit ref: main [check-self-bootstrap] floating-pin (release-toolkit#456): main matches main by construction rc=0 ``` 2. **SHA pins.** The "remove or rewrite" list cited the #336 SHA-pin arm. Since #1514, `bootstrap rt` refuses a commit SHA with a pin-a-release-tag remedy (`composite/bootstrap-rt/action.yml:9-11`), so a SHA-pinned run never reaches the PR body at all. The conclusion (remove) is unchanged. AGENTS.md section 2 still describes the pre-#456 shape for toolkit-self. That is a separate doc gap, not this issue.

claude referenced this issue from a commit

2026-10-02 21:18:01 +02:00

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

claude referenced this issue

2026-10-02 21:19:00 +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:53 +02:00

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

claude commented

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

Author

Member

Duplicate of #1500, which a parallel session filed two minutes later with the same measurements. Its PR #1504 carries the change; this issue's PR #1522 is withdrawn.

The second acceptance criterion here (the "local @main" wording in docs/integration.md) has no counterpart in #1500, so it is offered on #1504 as a suggestion. The corrections above (no re-pin needed; the #1514 SHA refusal) agree with #1504's body.

Duplicate of #1500, which a parallel session filed two minutes later with the same measurements. Its PR #1504 carries the change; this issue's PR #1522 is withdrawn. The second acceptance criterion here (the "local `@main`" wording in `docs/integration.md`) has no counterpart in #1500, so it is offered on #1504 as a suggestion. The corrections above (no re-pin needed; the #1514 SHA refusal) agree with #1504's body.

claude closed this issue

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

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)

claude referenced this issue

2026-10-02 21:45:54 +02:00

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

claude commented

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

Author

Member

Follow-up after the duplicate withdrawal: all three of this issue's criteria are now met on main, through PR #1504 (issue #1500). It landed as c231c21f8ebb06d5467c9142f632455e49893352, fast-forward, approved by alex in review 7200.

The recovery PR body no longer says #1173 is pending, in either twin (50d132f), and gitea-twin-check is green.
docs/integration.md recovery (B) now says toolkit-self's @main pin goes through the release-toolkit#456 floating-pin override, not a "local" invocation (c231c21, the #1522 wording). #1500 took this on as its fifth criterion.
git grep -n 1173 -- .forgejo .gitea cmd internal at c231c21 returns:
- the new bash comment in both twins, which says the file is baked from v0.58.0 (#1173), i.e. landed;
- internal/bake/marker.go:151;
- internal/bake/marker_test.go:102,140.
None of them says #1173 is pending.

The branch claude/1499-recover-pr-body-1173 (head 8333455) is still on the remote. Nothing has removed it.

Follow-up after the duplicate withdrawal: all three of this issue's criteria are now met on `main`, through PR #1504 (issue #1500). It landed as `c231c21f8ebb06d5467c9142f632455e49893352`, fast-forward, approved by alex in review 7200. 1. The recovery PR body no longer says #1173 is pending, in either twin (`50d132f`), and `gitea-twin-check` is green. 2. `docs/integration.md` recovery (B) now says toolkit-self's `@main` pin goes through the release-toolkit#456 floating-pin override, not a "local" invocation (`c231c21`, the #1522 wording). #1500 took this on as its fifth criterion. 3. `git grep -n 1173 -- .forgejo .gitea cmd internal` at `c231c21` returns: - the new bash comment in both twins, which says the file is baked from v0.58.0 (#1173), i.e. landed; - `internal/bake/marker.go:151`; - `internal/bake/marker_test.go:102,140`. None of them says #1173 is pending. The branch `claude/1499-recover-pr-body-1173` (head `8333455`) is still on the remote. Nothing has removed it.

Rows
Columns

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

Measured

Why it matters

Remove or rewrite

Acceptance criteria

Notes for the implementer