[lead-coder] — 本日 1 セッションで 5 件、「既に直っていた issue」に人を投入しました。 5 回同じ形が出たので、注意ではなく仕組みで閉じます。
実例（すべて 2026-08-11、同一セッション）
★#4107 ★5.5 時間前に #4161 が 直していた ── ★投入してから 発覚
★#4081 残件① ── ★#4188/#4189 が 直していた
★#2193 ★#4249 が 3 項目すべて 解決済み
★#3616 ①は pyperclip で解決済み、②は owner 裁定待ち ── ★実作業ゼロ
★#4077 ★textual の版だけの問題で、issue が主張していた「共存の問題」は 存在しなかった
なぜ起きるか — OPEN は「未着手」の witness ではありません
issue の 本文 ★起票時点の 地点 ── ★現在地ではない
issue の list ★題と ラベルしか 運ばない ── ★doneness を 記録する面ではない
closing keyword ★規律ある PR ほど 伏せる（sub-PR は part of #X を使う）
→ ★直っても issue は open のまま 残る ── ★構造的に そうなる
⚠️ 「open だから未着手」は、doneness を記録していない面で doneness を判定している形です。個人が気をつけて直る類ではありません — 本日は「気をつける」と決めた後に 4 回 再発しました。
提案する仕組み
merged PR の側から issue を突き合わせる（issue の側から見ても、そこには何も書かれていないため）。
1. ★直近 N 日の merged PR を 列挙
2. 各 PR 本文から ★#NNNN の 参照を 抽出（closing keyword の 有無を 問わず）
3. ★参照先が まだ OPEN なものを 一覧に する
4. ★その一覧を backlog-watcher が 巡回で 報告する（★自動で 閉じない）
⚠️ 自動で閉じてはいけません — 参照は「関連して触れた」も含み、「完了させた」とは限らないからです。判定は人が行い、機械は候補を出すだけにします（候補が出ること自体が、今は存在しない情報です）。
⚪ gh pr list --search "NNNN in:body" は既にこの逆引きができます — 足りないのは仕組みでなく、それを 投入前に必ず 通す運用のほうかもしれません。その場合は「dispatch 前に 1 コマンド」という形の、より小さい対処になります。 どちらが良いかは実装者の判断で構いません。
Test plan
[lead-coder] — 本日 1 セッションで 5 件、「既に直っていた issue」に人を投入しました。 5 回同じ形が出たので、注意ではなく仕組みで閉じます。
実例（すべて 2026-08-11、同一セッション）
なぜ起きるか — OPEN は「未着手」の witness ではありません
提案する仕組み
merged PR の側から issue を突き合わせる（issue の側から見ても、そこには何も書かれていないため）。
⚪
gh pr list --search "NNNN in:body"は既にこの逆引きができます — 足りないのは仕組みでなく、それを 投入前に必ず 通す運用のほうかもしれません。その場合は「dispatch 前に 1 コマンド」という形の、より小さい対処になります。 どちらが良いかは実装者の判断で構いません。Test plan