ci: the review's completion wakes the resolver as the Pipeline's does (ADR-1127) - #958

Claude finished @cdeust's task in 3m 11s —— View job

Review of PR #958 (review 1 of 3)

I found no Blockers, and the verdict is approve. The full review is in this comment.

I couldn't run the tests or the linter in this job because the commands needed approval. The review comes from reading the code.

• Read the diff and the resolver's checks
• Ran the five reviews: code quality, security, performance, test coverage, documentation
• Posted the findings: no Blockers, 3 Notes

Claude review (1 of 3), PR #958

I found no Blockers. I traced the new review wake-up through _pipeline_of_review → _validate_run → the exact job gate → _pr_identity → _review_approves. A run woken by the review still needs three things before it merges:

• a successful same-repo pipeline.yml pull_request run on the exact head, with the full job matrix;
• a claude[bot] verdict that links a review run of that head;
• the head pinned by sha on the merge PUT.

A look-alike PR Review workflow or a fork cannot use the new trigger, because the path, event and head_repository are all checked. A review skipped by its budget still ends success, and _review_approves holds it as before, so ADR decision 4 is right.

I could not run the tests or ruff in this job because the commands needed approval. The verification above comes from reading the code.

Notes, no action before merge

• The two wake-ups can race. The concurrency group (pipeline-post-merge.yml:24) is keyed on workflow_run.id, so the two resolvers are not serialized. If the review wake-up merges first, the Pipeline wake-up sees already_merged, finds no push run (GITHUB_TOKEN merges do not trigger one) and also returns run_tests=true, so the post-merge suite runs twice. Tags are preserved. A fix is a group keyed on workflow_run.head_sha with cancel-in-progress: false.
• The comment at pipeline-post-merge.yml:518 and ADR-1127 decision 3 say the Pipeline completion merged the PR. A hand merge whose push run is not visible yet also takes this branch, so the old "duplicates, never skips" guarantee (:345) is weaker here. The human push Pipeline still covers that commit. The CHANGELOG also says "whichever finishes first", but the merge happens when the last one finishes.
• pipeline-after-merge.yml and pipeline-post-merge.yml are rendered by zetetic-team-subagents render-ci. The same change needs to go into that template, or the next render reverts ADR-1127. The new test checks resolve by splitting its source text; it does not run resolve/_source_run with a fake API.

View job run

Verdict: approve