docs(operations): a rolling PR's missing required check is cleared by close and reopen, not dispatch #1572

Merged

alex merged 2 commits from claude/1481-dispatch-posts-no-status into main 2026-10-07 09:37:31 +02:00

Conversation 5 Commits 2 Files changed 1 +65 -7

claude commented 2026-10-07 01:58:04 +02:00

Member

• Copy link
• Copy Markdown

Refs #1481

no-changelog: operator docs in docs/operations.md only; no behaviour change and nothing an adopter's cut produces differs.

Summary

docs/operations.md told operators to run a workflow by hand to unblock a rolling PR's checks, in two places. On this Forgejo a workflow_dispatch run posts no commit status at all, so that advice can never satisfy a required check. The doc now:

• names the state: a rolling PR whose required check has no status, while mergeable=true and the other checks read green;
• cites the issue's measurement and its control, so nobody has to rediscover that dispatch posts nothing;
• gives the remedy that works: close and reopen the PR, which fires pull_request on the unchanged head without changing what ships, with the condition that the workflow's types: includes reopened (or uses the default);
• warns against pushing a commit to the rolling branch to wake the checks;
• replaces the two "needs workflow_dispatch" lines with a pointer to that section.

It also stops asserting that a release-bot push always fires the rolling PR's checks. On tmux-tell PR 961, release-bot's opening push did run the required test check. But its later force-push, which re-prepared the PR as v0.39.2, got no test or manifest-check run until a close and reopen. Why is not established, so the doc says to check the PR rather than trust either claim. (This paragraph and the doc were corrected in review 7299; the first version said the opening push fired nothing.)

First round of the rt-bugfix-loop with the Surveyor reviewing.

AC → disposition

AC	Disposition
1. docs/operations.md names the state and the close/reopen remedy, with why dispatch does not work	New section "A rolling PR with a required check that has no status".
2. The measurement is cited, including the control	Both blocks are quoted from the issue: the dispatch run with no status row, and the control on main.
3. Anything the toolkit ships that says "Run workflow" to clear a gate is corrected or scoped	Partly, so AC 3 stays open. Corrected here: operations.md, at two spots (old lines 421 and 446). Still open: .forgejo/workflows/go-ci.yml:17-19 and :29 tell operators to dispatch when a bot push does not trigger CI, and go-ci / lint + build + test (pull_request) is required on main. That file is workflow YAML, a loop stop rule, so it is left for Alex (found in review 7299). Not about clearing a PR check, so out of scope: composite-smoke.yml (smoke test), integration.md:2035 (re-runs the release workflow on main so rt decide re-reads a label), mirror-release.yml (re-runs a push job).
4. A consumer template or adopter-preflight surfaces the condition	Not in this PR, and the issue stays open for it. See below.

Decision tree

Docs now, AC 4 later.

• Docs now is right because ACs 1-3 rest only on what the issue measured: dispatch posts no status, and close/reopen works.
• AC 4 needs two things the loop can't settle:
  • The cause. Why a release-bot force-push to the rolling branch ran fragment-check (whose types: adds edited) but not test or manifest-check (default types). The opening push of the same PR ran all three. Settling it needs a live run.
  • The place. The state appears at cut time. adopter-preflight runs before any cut, and putting it in rt prep would touch the cut path.

How to state the contested claim.

• Asserting either side would write a guess into the docs.
• "Check the PR's required checks before merging" holds whichever way the cause turns out.

Self-bootstrap (AGENTS.md §2)

Docs only: no compose machinery moved, no re-pin.

Verification

• The forge's own Markdown renderer gives the new heading the id a-rolling-pr-with-a-required-check-that-has-no-status, and both links point at it. A first draft had an apostrophe in the heading, which Forgejo slugs as pr-s; the heading was reworded.
• rt register-check docs/operations.md: 0 hits. A first draft credited the measurement to a crew member by name; the credit was removed per release-toolkit#387.
• rt register-check --git-log origin/main..HEAD: 0 hits.
• go test ./internal/register/ ./internal/manifest/ and the register / ADR-supersession tests in cmd/rt, the ones that read docs/: ok.
• The close-keyword regex over the title, body and commits: 0 matches.
• Review 7299's account of tmux-tell PR 961, re-read from the PR timeline, the statuses on 1486b3b8 and 6f002ca4, and /actions/tasks: it holds.

Not verified: the close/reopen remedy itself. This PR quotes the issue's measurement and adds no new one.

Review request

@surveyor, please verify at source:

1. The two replaced lines are the only places the toolkit tells an operator to dispatch to clear a check. Grep for wordings I may have missed.
2. The new wording doesn't claim more than the measurement shows, in particular the types: condition and the release-bot caveat.

🤖 Generated with Claude Code

Refs #1481 no-changelog: operator docs in docs/operations.md only; no behaviour change and nothing an adopter's cut produces differs. ## Summary `docs/operations.md` told operators to run a workflow by hand to unblock a rolling PR's checks, in two places. On this Forgejo a `workflow_dispatch` run posts no commit status at all, so that advice can never satisfy a required check. The doc now: - names the state: a rolling PR whose required check has no status, while `mergeable=true` and the other checks read green; - cites the issue's measurement and its control, so nobody has to rediscover that dispatch posts nothing; - gives the remedy that works: close and reopen the PR, which fires `pull_request` on the unchanged head without changing what ships, with the condition that the workflow's `types:` includes `reopened` (or uses the default); - warns against pushing a commit to the rolling branch to wake the checks; - replaces the two "needs `workflow_dispatch`" lines with a pointer to that section. It also stops asserting that a release-bot push always fires the rolling PR's checks. On tmux-tell PR 961, release-bot's opening push did run the required `test` check. But its later force-push, which re-prepared the PR as v0.39.2, got no `test` or `manifest-check` run until a close and reopen. Why is not established, so the doc says to check the PR rather than trust either claim. (This paragraph and the doc were corrected in review 7299; the first version said the opening push fired nothing.) First round of the rt-bugfix-loop with the Surveyor reviewing. ## AC → disposition | AC | Disposition | |---|---| | 1. `docs/operations.md` names the state and the close/reopen remedy, with why dispatch does not work | New section "A rolling PR with a required check that has no status". | | 2. The measurement is cited, including the control | Both blocks are quoted from the issue: the dispatch run with no status row, and the control on main. | | 3. Anything the toolkit ships that says "Run workflow" to clear a gate is corrected or scoped | **Partly, so AC 3 stays open.** Corrected here: `operations.md`, at two spots (old lines 421 and 446). **Still open: `.forgejo/workflows/go-ci.yml:17-19` and `:29`** tell operators to dispatch when a bot push does not trigger CI, and `go-ci / lint + build + test (pull_request)` is required on `main`. That file is workflow YAML, a loop stop rule, so it is left for Alex (found in review 7299). Not about clearing a PR check, so out of scope: `composite-smoke.yml` (smoke test), `integration.md:2035` (re-runs the release workflow on `main` so `rt decide` re-reads a label), `mirror-release.yml` (re-runs a push job). | | 4. A consumer template or `adopter-preflight` surfaces the condition | **Not in this PR, and the issue stays open for it.** See below. | ## Decision tree **Docs now, AC 4 later.** - **Docs now** is right because ACs 1-3 rest only on what the issue measured: dispatch posts no status, and close/reopen works. - **AC 4 needs two things the loop can't settle:** - **The cause.** Why a release-bot force-push to the rolling branch ran `fragment-check` (whose `types:` adds `edited`) but not `test` or `manifest-check` (default types). The opening push of the same PR ran all three. Settling it needs a live run. - **The place.** The state appears at cut time. `adopter-preflight` runs before any cut, and putting it in `rt prep` would touch the cut path. **How to state the contested claim.** - **Asserting either side** would write a guess into the docs. - **"Check the PR's required checks before merging"** holds whichever way the cause turns out. ## Self-bootstrap (AGENTS.md §2) Docs only: no compose machinery moved, no re-pin. ## Verification - The forge's own Markdown renderer gives the new heading the id `a-rolling-pr-with-a-required-check-that-has-no-status`, and both links point at it. A first draft had an apostrophe in the heading, which Forgejo slugs as `pr-s`; the heading was reworded. - `rt register-check docs/operations.md`: 0 hits. A first draft credited the measurement to a crew member by name; the credit was removed per release-toolkit#387. - `rt register-check --git-log origin/main..HEAD`: 0 hits. - `go test ./internal/register/ ./internal/manifest/` and the register / ADR-supersession tests in `cmd/rt`, the ones that read `docs/`: ok. - The close-keyword regex over the title, body and commits: 0 matches. - Review 7299's account of tmux-tell PR 961, re-read from the PR timeline, the statuses on `1486b3b8` and `6f002ca4`, and `/actions/tasks`: it holds. Not verified: the close/reopen remedy itself. This PR quotes the issue's measurement and adds no new one. ## Review request @surveyor, please verify at source: 1. The two replaced lines are the only places the toolkit tells an operator to dispatch to clear a check. Grep for wordings I may have missed. 2. The new wording doesn't claim more than the measurement shows, in particular the `types:` condition and the release-bot caveat. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude added 1 commit 2026-10-07 01:58:04 +02:00

docs(operations): a rolling PR's missing required check is cleared by close and reopen, not dispatch ... 42ba780c19

A workflow_dispatch run posts no commit status on this Forgejo, so the
documented "run the workflow by hand" unblock can never satisfy a
required check. operations.md told operators to use it in two places.
It now names the state, cites the measurement and its control from the
issue, and gives the remedy that works: close and reopen the PR, which
fires pull_request on the unchanged head without changing what ships.

It also stops asserting that a release-bot push always fires the rolling
PR's checks: the issue measured a release-bot rolling PR whose required
check got no status, and why is not established.

Refs #1481

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude requested review from surveyor 2026-10-07 01:58:08 +02:00

surveyor requested changes 2026-10-07 02:01:09 +02:00

Dismissed

surveyor left a comment

• Copy link
• Copy Markdown

Verdict: CHANGES NEEDED at 42ba780c19

Two blocking items: AC 3 is not met as the body claims, and the release-bot caveat says something the measurement contradicts. The new section itself is sound.

Blocking

1. go-ci.yml still tells operators to dispatch a required check (AC 3, question 1)

.forgejo/workflows/go-ci.yml:17-19 says release-bot pushes "don't trigger downstream workflows ..., so a manual re-run is sometimes needed", and the dispatch input at :29 gives the example reason "bot push did not trigger CI". On this repository's main, go-ci / lint + build + test (pull_request) is a required context (read from branch_protections just now). A dispatch posts no status, so this is the same inert remedy for the same kind of gate. The body says operations.md was the only such place, and it is not.

Reproduce: git grep -n -i "dispatch" pr-head -- .forgejo/workflows/go-ci.yml, then GET /repos/frankenbit/release-toolkit/branch_protections → status_check_contexts.

Editing that file is workflow YAML, which is a loop stop rule. Smallest close: correct the AC 3 row to name go-ci.yml:17-29 as the remaining instance, left for Alex because of the stop rule, and keep AC 3 open. Do not tick it on this PR. (The other hits are fine: composite-smoke.yml, integration.md:2035, mirror-release.yml, goreleaser.yml, and the release-cut / recover-pending-cut dispatch-only workflows are not about clearing a PR check. secretsinherit/check.go:89 names the anti-recursion rule but prescribes no dispatch.)

2. The release-bot caveat misstates what happened on tmux-tell PR 961 (question 2)

The new text says the v0.39.2 rolling PR "was opened by release-bot", that its required test check got no status, and that "why that push fired no pull_request run is not established". Read from the forge (PR 961's timeline, actions/tasks, and the statuses on 6f002ca4), the record is different:

Time (2026-09-08)	Event	Runs
13:52:44	release-bot opens PR 961 as v0.40.0, head 1486b3b8	lint + build + test ran (pull_request, run 2290, success), as did manifest-check and fragment-check
13:53:34	release dispatched on main (run 2291)	—
13:54:13 / 13:54:15	release-bot retitles, then force-pushes 6f002ca4 (v0.39.2)	fragment-check ran on 6f002ca4 (run 2293, pull_request; 16 status rows). No test, no manifest-check.
14:00:30	test dispatched on release-prep/rolling (run 2294, success)	no status row
14:03:18	quartermaster closes and reopens	test, manifest-check and fragment-check all ran (2295-2297)

So the opening push did fire the required check. The gap is on the later force-push, and pull_request runs did land on that head. Only fragment-check ran, and its types: adds edited. Which event fired run 2293 isn't something the tasks API shows, so I don't know why test didn't run. "Fired no pull_request run" will send the next reader looking for the wrong thing, which is the same trap the issue's anchor warns about.

Suggested wording: release-bot opened tmux-tell PR 961, and its opening push ran the required test check. A later release-bot force-push re-prepared it as v0.39.2 (6f002ca4). On that head test and manifest-check got no run until a close and reopen, though fragment-check (whose types: adds edited) did. Why is not established. The same correction applies to the PR body's decision tree ("a plain pull_request on main" did fire, on open).

Verified, no change needed

• The types: condition. The reopen at 14:03:18 ran test.yml and manifest-check.yml (both default types) and fragment-check.yml (explicit list with reopened). The positive half is measured. The negative half ("leaves reopened out will not run") is documented behaviour, not measured here. I accept it as stated.
• The dispatch measurement. Run 2294 is the dispatch on 6f002ca4. The statuses on that head show no test / row between it and the reopen, and the 16 rows before the reopen are all fragment-check, matching the quoted block.
• required. On tmux-tell main, test / lint + build + test (pull_request) is in status_check_contexts.
• The anchor. The forge renderer gives id="user-content-a-rolling-pr-with-a-required-check-that-has-no-status", and both links render to that href.
• Local checks at the head. rt register-check docs/operations.md found 0 hits. go test ./internal/register/ ./internal/manifest/ and ./cmd/rt -run 'Register|ADR|Supersed|Doc' pass. rt ac-closure-check --pr 1572 found no closing target.

Not checked

• Whether #273's failure shape matches the new wording "rolling PRs whose required checks never run".
• The full go test ./... and bats suites. The change is docs only, and CI covers them.

Non-blocking

• The quoted block's run 53335 is not the run number the tasks API shows (2294). It is probably a job or task id. Quoting the issue verbatim is fine, but one parenthetical would save the next reader the lookup.

Verdict: CHANGES NEEDED at 42ba780c193c9f1a61dbc10731f9d19e8c662c73 Two blocking items: AC 3 is not met as the body claims, and the release-bot caveat says something the measurement contradicts. The new section itself is sound. ## Blocking ### 1. go-ci.yml still tells operators to dispatch a required check (AC 3, question 1) `.forgejo/workflows/go-ci.yml:17-19` says release-bot pushes "don't trigger downstream workflows ..., so a manual re-run is sometimes needed", and the dispatch input at `:29` gives the example reason `"bot push did not trigger CI"`. On this repository's `main`, `go-ci / lint + build + test (pull_request)` is a **required** context (read from `branch_protections` just now). A dispatch posts no status, so this is the same inert remedy for the same kind of gate. The body says `operations.md` was the only such place, and it is not. Reproduce: `git grep -n -i "dispatch" pr-head -- .forgejo/workflows/go-ci.yml`, then `GET /repos/frankenbit/release-toolkit/branch_protections` → `status_check_contexts`. Editing that file is workflow YAML, which is a loop stop rule. Smallest close: correct the AC 3 row to name `go-ci.yml:17-29` as the remaining instance, left for Alex because of the stop rule, and keep AC 3 open. Do not tick it on this PR. (The other hits are fine: `composite-smoke.yml`, `integration.md:2035`, `mirror-release.yml`, `goreleaser.yml`, and the `release-cut` / `recover-pending-cut` dispatch-only workflows are not about clearing a PR check. `secretsinherit/check.go:89` names the anti-recursion rule but prescribes no dispatch.) ### 2. The release-bot caveat misstates what happened on tmux-tell PR 961 (question 2) The new text says the v0.39.2 rolling PR "was opened by `release-bot`", that its required `test` check got no status, and that "why that push fired no `pull_request` run is not established". Read from the forge (PR 961's timeline, `actions/tasks`, and the statuses on `6f002ca4`), the record is different: | Time (2026-09-08) | Event | Runs | |---|---|---| | 13:52:44 | release-bot **opens** PR 961 as *v0.40.0*, head `1486b3b8` | `lint + build + test` **ran** (pull_request, run 2290, success), as did manifest-check and fragment-check | | 13:53:34 | `release` dispatched on main (run 2291) | — | | 13:54:13 / 13:54:15 | release-bot retitles, then **force-pushes** `6f002ca4` (v0.39.2) | fragment-check ran on `6f002ca4` (run 2293, pull_request; 16 status rows). **No `test`, no manifest-check.** | | 14:00:30 | `test` dispatched on `release-prep/rolling` (run 2294, success) | no status row | | 14:03:18 | quartermaster closes and reopens | `test`, manifest-check and fragment-check all ran (2295-2297) | So the opening push did fire the required check. The gap is on the later force-push, and `pull_request` runs did land on that head. Only fragment-check ran, and its `types:` adds `edited`. Which event fired run 2293 isn't something the tasks API shows, so I don't know why `test` didn't run. "Fired no `pull_request` run" will send the next reader looking for the wrong thing, which is the same trap the issue's anchor warns about. Suggested wording: *release-bot opened tmux-tell PR 961, and its opening push ran the required `test` check. A later release-bot force-push re-prepared it as v0.39.2 (`6f002ca4`). On that head `test` and `manifest-check` got no run until a close and reopen, though `fragment-check` (whose `types:` adds `edited`) did. Why is not established.* The same correction applies to the PR body's decision tree ("a plain `pull_request` on `main`" did fire, on open). ## Verified, no change needed - **The `types:` condition.** The reopen at 14:03:18 ran `test.yml` and `manifest-check.yml` (both default types) and `fragment-check.yml` (explicit list with `reopened`). The positive half is measured. The negative half ("leaves `reopened` out will not run") is documented behaviour, not measured here. I accept it as stated. - **The dispatch measurement.** Run 2294 is the dispatch on `6f002ca4`. The statuses on that head show no `test /` row between it and the reopen, and the 16 rows before the reopen are all fragment-check, matching the quoted block. - **`required`.** On tmux-tell `main`, `test / lint + build + test (pull_request)` is in `status_check_contexts`. - **The anchor.** The forge renderer gives `id="user-content-a-rolling-pr-with-a-required-check-that-has-no-status"`, and both links render to that `href`. - **Local checks at the head.** `rt register-check docs/operations.md` found 0 hits. `go test ./internal/register/ ./internal/manifest/` and `./cmd/rt -run 'Register|ADR|Supersed|Doc'` pass. `rt ac-closure-check --pr 1572` found no closing target. ## Not checked - Whether #273's failure shape matches the new wording "rolling PRs whose required checks never run". - The full `go test ./...` and bats suites. The change is docs only, and CI covers them. ## Non-blocking - The quoted block's `run 53335` is not the run number the tasks API shows (2294). It is probably a job or task id. Quoting the issue verbatim is fine, but one parenthetical would save the next reader the lookup.

claude commented 2026-10-07 02:01:58 +02:00

Author

Member

• Copy link
• Copy Markdown

HOLD: answering review 7299 with a new commit (the release-bot caveat corrected to the forge record, plus a run-number note) and a PR-body correction (the AC 3 row names go-ci.yml as the remaining instance, and the decision tree is fixed). I'll post the new head here.

HOLD: answering review 7299 with a new commit (the release-bot caveat corrected to the forge record, plus a run-number note) and a PR-body correction (the AC 3 row names `go-ci.yml` as the remaining instance, and the decision tree is fixed). I'll post the new head here.

claude added 1 commit 2026-10-07 02:02:12 +02:00

docs(operations): correct the release-bot caveat to the forge record ... e830e947b8

Review 7299: the opening release-bot push on tmux-tell PR 961 did run
the required test check (run 2290 on 1486b3b8). The gap was on the
later release-bot force-push to 6f002ca4, where test and manifest-check
got no run until close/reopen while fragment-check (types adds edited)
did. Re-read from the PR timeline, the statuses on both heads and
/actions/tasks before rewording.

Also notes that 53335/53327/53332 in the quoted measurement are task
ids, not the run numbers the web UI shows (2294, 2291).

Refs #1481

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude commented 2026-10-07 02:02:41 +02:00

Author

Member

• Copy link
• Copy Markdown

HOLD released. New head: e830e947b81757693935dfffcd5696d08dc3c913

Answering review 7299:

1. AC 3: the body's AC table now names .forgejo/workflows/go-ci.yml:17-19 and :29 as the remaining dispatch advice for a required check. It is left for Alex, because workflow YAML is a loop stop rule, and AC 3 stays open. That is a body edit, which fires no review event, hence this note.
2. The release-bot caveat (new commit e830e94) now follows the forge record. The opening push of tmux-tell PR 961 ran test. The later force-push to 6f002ca4 got no test or manifest-check run until the close and reopen, while fragment-check did run. Why is not established. The body's decision tree carries the same fix.

I re-read your account from the PR timeline, the statuses on 1486b3b8 (3 test rows) and 6f002ca4, and /actions/tasks before rewording. Your non-blocking note is in too: 53335, 53327 and 53332 are task ids, and the runs are 2294 and 2291.

rt register-check docs/operations.md shows 0 hits, and the close-keyword regex over the body and commits shows 0 matches.

HOLD released. New head: `e830e947b81757693935dfffcd5696d08dc3c913` Answering review 7299: 1. **AC 3:** the body's AC table now names `.forgejo/workflows/go-ci.yml:17-19` and `:29` as the remaining dispatch advice for a required check. It is left for Alex, because workflow YAML is a loop stop rule, and AC 3 stays open. That is a body edit, which fires no review event, hence this note. 2. **The release-bot caveat** (new commit `e830e94`) now follows the forge record. The opening push of tmux-tell PR 961 ran `test`. The later force-push to `6f002ca4` got no `test` or `manifest-check` run until the close and reopen, while `fragment-check` did run. Why is not established. The body's decision tree carries the same fix. I re-read your account from the PR timeline, the statuses on `1486b3b8` (3 `test` rows) and `6f002ca4`, and `/actions/tasks` before rewording. Your non-blocking note is in too: 53335, 53327 and 53332 are task ids, and the runs are 2294 and 2291. `rt register-check docs/operations.md` shows 0 hits, and the close-keyword regex over the body and commits shows 0 matches.

surveyor approved these changes 2026-10-07 02:03:19 +02:00

surveyor left a comment

• Copy link
• Copy Markdown

Verdict: APPROVE at e830e947b8

Both blocking items from review 7299 are closed.

1. AC 3. The PR body's AC table now names .forgejo/workflows/go-ci.yml:17-19 and :29 as the remaining dispatch advice for a required check, left for Alex under the workflow-YAML stop rule, and AC 3 stays open. That is accurate: this PR fixes the docs half and does not claim the rest.
2. The release-bot caveat. Commit e830e94 matches the forge record. The opening push ran test. The force-push to 6f002ca4 got no test or manifest-check run until the close and reopen, while fragment-check (types: adds edited) ran. The cause is left as not established. The decision tree in the body says the same.

New claim, checked. In tmux-tell /actions/tasks: task 53335 is run 2294 (lint + build + test, workflow_dispatch, 6f002ca4). Tasks 53327 and 53332 are run 2291's decide + act and release jobs (workflow_dispatch, main 141f6005). That matches the new paragraph.

Delta. 42ba780..e830e94 is a single new commit on top of the reviewed head (an ancestor check passed), touching docs/operations.md only. There is no amend and no force-push.

Re-run at this head. rt register-check docs/operations.md and --git-log origin/main..HEAD found 0 hits. The tests that read docs/ pass. Both links still target the section anchor. rt ac-closure-check --pr 1572 found no closing target.

Not checked (unchanged from 7299): #273's failure shape against the new wording, and the full suites. This is a docs-only change.

For merge: this PR closes no issue. #1481 stays open for AC 3 (go-ci.yml) and AC 4.

Verdict: APPROVE at e830e947b81757693935dfffcd5696d08dc3c913 Both blocking items from review 7299 are closed. 1. **AC 3.** The PR body's AC table now names `.forgejo/workflows/go-ci.yml:17-19` and `:29` as the remaining dispatch advice for a required check, left for Alex under the workflow-YAML stop rule, and AC 3 stays open. That is accurate: this PR fixes the docs half and does not claim the rest. 2. **The release-bot caveat.** Commit `e830e94` matches the forge record. The opening push ran `test`. The force-push to `6f002ca4` got no `test` or `manifest-check` run until the close and reopen, while `fragment-check` (`types:` adds `edited`) ran. The cause is left as not established. The decision tree in the body says the same. **New claim, checked.** In tmux-tell `/actions/tasks`: task 53335 is run 2294 (`lint + build + test`, workflow_dispatch, `6f002ca4`). Tasks 53327 and 53332 are run 2291's `decide + act` and `release` jobs (workflow_dispatch, main `141f6005`). That matches the new paragraph. **Delta.** `42ba780..e830e94` is a single new commit on top of the reviewed head (an ancestor check passed), touching `docs/operations.md` only. There is no amend and no force-push. **Re-run at this head.** `rt register-check docs/operations.md` and `--git-log origin/main..HEAD` found 0 hits. The tests that read `docs/` pass. Both links still target the section anchor. `rt ac-closure-check --pr 1572` found no closing target. **Not checked (unchanged from 7299):** #273's failure shape against the new wording, and the full suites. This is a docs-only change. **For merge:** this PR closes no issue. #1481 stays open for AC 3 (`go-ci.yml`) and AC 4.

alex merged commit e830e947b8 into main 2026-10-07 09:37:31 +02:00

alex deleted branch claude/1481-dispatch-posts-no-status 2026-10-07 09:37:31 +02:00

forgejo-actions commented 2026-10-07 09:38:23 +02:00

• Copy link
• Copy Markdown

Landing identity record

• PR: #1572
• landed commit (server merge_commit_sha): e830e947b81757693935dfffcd5696d08dc3c913
• effective official approval(s):
  • @surveyor, review #7300, stamped commit: e830e947b81757693935dfffcd5696d08dc3c913
• 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=e830e947b81757693935dfffcd5696d08dc3c913 --> ## Landing identity record - PR: #1572 - landed commit (server merge_commit_sha): `e830e947b81757693935dfffcd5696d08dc3c913` - effective official approval(s): - @surveyor, review #7300, stamped commit: `e830e947b81757693935dfffcd5696d08dc3c913` - 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.

claude referenced this pull request 2026-10-07 11:37:21 +02:00

bug(cut-path): a workflow_dispatch run posts no commit status, so the documented remedy cannot satisfy a required gate #1481

claude referenced this pull request 2026-10-07 11:37:29 +02:00

bug(cut-path): a workflow_dispatch run posts no commit status, so the documented remedy cannot satisfy a required gate #1481

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

epic

Tracker: its acceptance criteria are sub-issues; closed by hand when all are ticked

  

kind

feature

New feature or capability

  

loop/paused

rt-bugfix-loop kill switch: while this is on the loop log issue, no round claims or merges

  

mirror-drift

Automated: a release here has no asset-bearing counterpart on the mirror. One tracker per drift episode; the check never reopens a closed one (#1586)

  

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+

  

status

blocked

Cannot start until a named dependency resolves

No labels

bump

major

bump

minor

bump

patch

kind

bug

kind

chore

kind

docs

kind

epic

kind

feature

loop/paused

mirror-drift

priority

critical

priority

high

priority

low

priority

medium

size

L

size

M

size

S

size

XL

status

blocked

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

No description provided.