issue-retrolisted

## Purpose issue 対応ループの品質を**次の issue に複利で効かせる**ためのフィードバック工程。Step 4 (敵対的レビュー) / Step 5 (メタレビュー) / Step 7 (E2E) が surfacing した finding を分類し、「事前に見つけられたはずのもの」の検出条件をプロジェクトの Step 0-pre チェックリスト skill (例: artgraph の `artgraph-graph-primitive-impact`) に還元する。 ## 引数 対象 PR (URL or 番号)。loop の各 Step ログ (findings 一覧) があれば併せて渡す。 ## 手順 ### 1. findings の収集 対象 PR のレビューコメント / loop の Step 4・5・7 成果物から finding を列挙する (誤検知と判定されたものは除外)。 ### 2. 事前検出可能性の分類 各 finding を 3 値で分類し、表にする: | 分類 | 基準 | | --- | --- | | **可能** | 現行の Step 0-pre チェックリストのいずれかのチェックを正しく実行していれば検出できた | | **条件付き** | チェックリストに**新しい観点**を足せば検出できた (その観点を明文化する) | | **不可能** | 実装が存在して初めて観測でき��� (実行時挙動・環境依存など)。Step 4/5/7 が正当な検出層 | 分類表の各行: finding 概要 / ランク / 分類 / 根拠 (どのチェックで・なぜ引っかかる or かからないか)。 ### 3. チェックリスト更新提案の判定 「条件付き」の finding について、検出条件をチェックリストへ追加すべきかを判定する: - **追加する**: 同型の欠陥が今後も出うる一般性がある (例: hub-node パターン監査、CLI フラグ parse 意味論監査) - **追加しない**: 一回性が高い / チェックのコストが検出価値を上回る (理由を記録) #### 提案は「可能 : 条件付き」の比を先に見てから出す **チェックリストが長くなること自体が、実行漏れを増やす。** 提案を書く前に、直近 3 ループ分の分類集計を並べて比を出すこと: | ループ | チェックリスト行数 | 可能 (実行漏れ) | 条件付き (新観点) | | --- | ---: | ---: | ---: | - **「条件付き」が横ばい〜減少**なら、カバレッジは足りている。**そこへ新観点を足しても効かない。** - **「可能」が増えている**なら、壊れているのは実行。**必要なのは追加ではなく、トリアージ・再入場トリガー・実行主体の規律**。 - 両方が増えているときだけ、新観点の追加が正当化される。 実測 (2026-08): チェックリストが 370 → 540 行になったループで、「条件付き」12 → 8 に対し「**可能」3 → 9 と 3 倍**になり、うち 6 件が**新設したばかりの 1 チェックの未実行**だった。追加が効かなくなる兆候はこの比に出る。 #### 提案 1 件ごとに予算を書く 各提案に **「何を置き換えるか」または「なぜ純増でなければならないか」** を 1 行で書く。書けない提案は出さない。純増を選ぶ場合は、**その提案がカバー