fix(github-actions): research radar dedupes by paper ID but not by target file

[laurigates]

Problem or motivation

The radar has exactly one memory of what it has already surfaced: paper IDs.

.github/workflows/research-radar.yml, gather job, step Collect already-surfaced paper IDs, greps <!-- research-radar-ids: … --> out of the last 30 radar issue bodies into seen-ids.txt, which is passed to scripts/fetch-research-papers.sh --seen-file so the same paper is never written up twice.

Nothing equivalent exists for the target — the plugin or rule file the suggestion would amend — even though the prompt requires the assessor to group findings by target and to state the exact file and pattern grepped for each one. The target is therefore present in every issue body and discarded.

Observed: .claude/rules/loop-integrity.md drew a candidate in two consecutive weeks:

Week	Issue	Paper	Proposed change
2026-W37	#2631	2609.09153 Procedural Graphs	ordering/precondition field on the Pillar 2 state-packet table
2026-W38	#2673	2609.15364 RSIAgent	curriculum/next-target row on the same table

Both papers are legitimately relevant and both cleared the bar correctly — the defect is that the second run had no way to know the first had happened, so the overlap reached triage unflagged. Landing them as two issues would have meant two passes over one table and a near-certain conflict; they were merged by hand into #2693 only because a human noticed.

Proposed solution

Carry targets forward the way IDs already are, but flag, do not filter — see Alternatives for why the asymmetry matters.

1. Emit. Add a second machine-readable block beside the existing one in the Step 3 issue template:

   <!-- research-radar-ids: <id1> <id2> -->
   <!-- research-radar-targets: <path1> <path2> -->
   

   The assessor already knows these paths — it greps them for the grounding requirement and names them in the body.

2. Collect. In the gather job, parse them out of recent radar issues into recent-targets.txt, mirroring the existing ID collector (--json body | jq, exit-0 on empty per .claude/rules/parallel-safe-queries.md). Bound it by recency, not by the 30-issue window used for IDs — a few weeks, not forever.

3. Surface. Pass the list into the assess prompt as context: when a candidate targets a file amended in the window, the issue body must say so, name the prior issue, and state whether the two should be merged into one change or are genuinely independent.

Acceptance:

• An issue body emits a research-radar-targets block listing every target it names.
• A candidate hitting a recently-amended target is surfaced with the collision noted, not dropped.
• A target outside the recency window produces no note.

Alternatives considered

• Filter candidates by target, as IDs are filtered. Wrong, and the reason this is a flag. A repeated paper is pure noise; a repeated target is not. loop-integrity.md, CLAUDE.md and the .claude/rules/skill-*.md family are central surfaces that will legitimately attract candidates again and again. Suppressing on target would silently discard good findings — a worse failure than the one being fixed, and an invisible one.
• Extend the existing IDs block to carry id:path pairs. Breaks the parser in the collector step against the four existing issue bodies already in the wild. A second block is backward-compatible: absent on old issues, which reads correctly as "no targets recorded".
• Dedupe at triage time by hand. The status quo. It worked once because two issues happened to be read together; it fails whenever they are triaged a week apart, which is the normal case.
• Reuse scripts/check-research-radar-grounding.sh. That guard asserts the workflow prose still carries the grounding requirement. It does not read issue bodies, so it cannot see this. It is, however, the precedent for the semantic guard this change should come with — per .claude/rules/regression-testing.md, and because the fix is again prose inside a YAML block scalar that a later prompt edit could silently drop.

Additional context

Grounding (verified): .github/workflows/research-radar.yml — the ID collector at Collect already-surfaced paper IDs (grep -oE '<!-- research-radar-ids:[^>]*-->'), the grounding requirement under Efficiency rules ("State the exact file(s) and pattern grepped in the issue body"), and the <!-- research-radar-ids: … --> line in the Step 3 gh issue create heredoc.

Related: #2693 (the merged item this collision produced), #2631 and #2673 (the two radar issues, both closed with this finding recorded), scripts/check-research-radar-grounding.sh.

Found during triage of the 2026-W37/W38 radar issues rather than by a guard — which is the point.