fix(review-runs,review-reviewers): dedup against merged PRs, and against tend before filing upstream

[tend-agent]

Problem

Two dedup blocks were blind in two different ways, and the cited duplicate needed both fixed.

State filter. review-runs Step 5 and review-reviewers Step 4 both deduped against PRs with gh pr list --state open. A merged PR is never returned by that query, so a finding whose fix already landed reads as undeduped and gets filed again. running-in-ci's PR-creation dedup recheck already gets this right ("with --state all so closed and merged siblings show up"); these two recipes contradicted it.

Repo scope. review-runs is a generated workflow (generator/src/tend/config.py:24 lists it in the enabled set), so it runs in each adopter's checkout and an unqualified gh pr list returns the adopter's PRs. Step 6 routes bundled-skill defects upstream to tend, but neither Step 5 nor any of running-in-ci's dedup recipes — all local-repo — told the agent to dedup in the target repo before filing there. --state all alone does not close this: the adopter's PR list never contained the upstream fix at any state.

review-reviewers is unaffected by the second half. It runs in max-sixty/tend and files onto tend, so its unqualified gh pr list already resolves to the right repo; only the state filter was wrong there.

This bites hardest on tend specifically, because of the pinning model: adopters call max-sixty/tend/<harness>@X.Y.Z, so a merged skill fix stays dormant on their repos until the next release tags. The bug keeps reproducing after the fix merges — which is exactly the window in which the analysis legs are looking at it, and exactly when the dedup queries are blind to the fix.

What happened

max-sixty/cargo-affected's tend-review-runs run 31160677649 (08:11:33Z → 08:21:41Z) hit the | last evidence-log mis-selection: it appended ~12 KB of run evidence into the nightly's unrelated comment on target #73, noticed on its post-verify read, restored comment 5188771252, and re-appended to the real log 5150650688. Good recovery. It then filed #883 upstream, whose "Proposed fix" is a ## Run heading predicate on the comment selector.

#875 merged that exact fix at 07:34:40Z — 46 minutes before the issue was filed — as test("^## Run [0-9]") on the same selector, in the same file. #883 is a duplicate of a merged PR.

The run made three dedup queries before filing (gh issue list --state all --search "tracking issue comment append", a broader gh issue list --state all title regex, and a final gh issue list --state open recheck). All three were gh issue list, which never returns PRs — and all three ran against max-sixty/cargo-affected. Even had it run Step 5's PR line verbatim, it would not have returned #875, for both reasons: the state filter excluded merged PRs, and the query's repo was the adopter's, not tend's.

The fix

• Both skills: gh pr list --state open → --state all, projecting state,mergedAt so a merged hit is legible.
• review-runs only: add the cross-repo pair (gh pr list/gh issue list --repo max-sixty/tend --state all) so a finding heading upstream under Step 6 is deduped against tend first.
• review-runs only: the pinning note is scoped to the upstream repo, since in that skill the reader is the adopter and the local gh pr list above it has nothing to do with pinned refs. review-reviewers keeps the original wording, where tend is the reader and "on adopters" is the correct direction.

Both added commands were run against this repo to confirm they parse and return the expected shape.

Gate assessment

• Evidence level: High. Occurrences: 1 direct, verified end to end (session log, both dedup query sets, fix(review-runs): find the evidence log by its heading, not by recency #875's merge time and diff, review-runs: the evidence-log append target is picked with | last, so any other bot comment on the tracker forks the log #883's body).
• Structural, not stochastic. gh pr list --state open deterministically cannot return a merged PR, and a query scoped to the adopter's repo deterministically cannot return a tend PR; replayed ten times it misses fix(review-runs): find the evidence log by its heading, not by recency #875 ten times. There is no decision point.
• Change type: targeted fix — query lines plus one sentence naming the pinning consequence. It brings both recipes into line with a rule the same plugin already states in running-in-ci, rather than introducing new policy.
• Why act at one occurrence: the six-PR batch merged at 07:34:40Z (#875, #834, #868, #818, #877, #858) is all unreleased, so six distinct bugs remain observable on every adopter until the next release. The first analysis leg after that batch produced the first duplicate. The exposure is six-wide and standing, not one-off.

Not covered by

No open PR touches either dedup block. #845/#850/#838 are the run-window cluster; #849, #856, #857, #864, #869, #876, #809, #837, #821, #836 are elsewhere.

#883 stays open as a maintainer call — it is redundant with #875 but the option-2 half of its body (finish the gist migration for review-runs) is not.

Evidence: https://gist.github.com/dca23a6e6a0d8cae2665944ba31676fb

[tend-agent]

The review-reviewers half is right — that skill runs in max-sixty/tend with tend as gh's default repo, so gh pr list --state all does reach #875.

The review-runs half doesn't fix the case in the PR body. review-runs is a generated workflow (generator/src/tend/config.py lists it in the enabled set), so it runs in each adopter's checkout — a bare gh pr list there returns the adopter's PRs. The cited duplicate was max-sixty/tend#883 filed from a max-sixty/cargo-affected run, duplicating max-sixty/tend#875. Changing --state open to --state all doesn't help: cargo-affected's PR list never contained #875 at any state. So the body's "Even had it run Step 5's PR line verbatim, --state open would not have returned #875" holds for a reason the patch doesn't address — the repo, not the state filter.

Step 6 routes bundled-skill defects upstream (file the fix against tend per **Filing Issues in Other Repos**), but nothing in Step 5 — or in running-in-ci's dedup recipes, which are all local-repo — tells the agent to dedup in the target repo before filing there. That's the actual gap that produced #883.

Second, smaller: the new paragraph is written from tend's vantage point, but in review-runs the reader is the adopter, and the local gh pr list it follows has nothing to do with pinned refs. Suggested reword below scopes it to the upstream repo, which is where the pinning argument actually bites. The review-reviewers copy is fine as-is.