/da-fix-plan — 直さないものを決め、残りに順番をつける

レビューの所見を計画にする。主な仕事は引き算。

欠落を探せと言われたレビュアーは、作業が健全でも何かしら報告する。全所見を追うと過剰設計（余計な抽象層、防御的なコード、起こりえないケースのテスト）になる。

防ぐのは見落としではなく全部に対応すること。全所見を受け入れた計画は書き写しにすぎない。

計画に合意するまでは読み取り専用。 計画を作って見せ、止まる。修正はその後。

実行条件

ワークフロー上の位置

/receiving-code-review は 1 つの指摘への応じ方を扱う。こちらは報告全体から順序つきの成果物をディスクに作る。

結果をレビュアーに書き返す時（説明が要る Decline、一部誤った所見の訂正）は、profiles/review-voice.md の応答側の口調に従う。同意か訂正から始め、コミットを引き、自分に不利なことも自分から言う。receiving-code-review には教えられないので案内をここに置く。

これがレビューのループの停止条件。 所見を求められたレビュアーは所見を出すので、何も見つからなくなるまでのレビューは終わらない。ループを終わらせるのは回数ではなく Decline のバケット、つまりどの所見をなぜ直さないかを記録に残すこと（gate のチェックも同じ形で、3 回試して諦めたと言う VERDICT を出す）。Decline の無いループには出口が無い。

読むファイル

常に読む

条件つきで読む

差分全体を読み直さない。これは判断のパスであって 2 度目のレビューではない。レビューし始めたら止まる（報告に無かった所見を持ち込むことになる）。

報告はユーザーが書いている言語で書く（不明なら日本語）。パス、識別子、コマンド、コード片、ログ出力は元の形のまま。

Step 1. 変更の目的を言い直す

spec か PR の説明から 1〜2 文。トリアージの前に確認する。

トリアージの半分は、所見を意図した範囲と比べること。 意図が頭の中にしか無いと、その比較は検証できない。

Step 2. すべての所見をちょうど 1 つのバケットに入れる

所見は 5 つのどれかに入る。分類しないまま残さず、黙って落とさない。直さないことは理由つきの見える結果。

バケットに意味を持たせる規則を 3 つ。

• spec の範囲外の所見は Follow-up か Decline に入れ、Fix now には入れない。 範囲に関係なく出荷される欠陥は例外。スコープの膨張はまさにここから入る
• Nit: の所見は既定で Decline。 レビュアーが任意と印をつけたもので、作業として扱うとその意図を覆す
• Decline したい 🔴 は、先にコードで確かめる。 要約だけで重い所見を退けると、本物のバグがノイズとして閉じられる

Step 3. 残りに順番をつけ、その理由を書く

重大度の順ではなく、順番を誤ると何が壊れるかで並べる。

1. 不可逆なものを先に。 データ、マイグレーション、公開された契約。後の修正であるべき形が変わっても、その時には実行済み
2. 次に、共有インターフェースを変える修正。 それに依存する呼び出し元より前
3. 次に、独立したもの。 1 コミットにまとめてよい
4. 最後に、テストだけに触れるもの。

次に、飛ばされがちな相互作用を確かめる。

• ある修正が別の修正を不要にするか。 まとめ、そう書く。根本原因が同じ 2 つの所見は 1 つの修正
• ある修正が別の修正の前提を崩すか。 2 つ目は再検証が要ると印をつけ、1 つ目の後で確かめ直す
• 2 つの修正が同じ行に触れるか。 順番を明示し、衝突として発見させない

Step 4. 計画をファイルに書く

会話にではなくファイルに書く。/clear を越えて残り、/da-verify と次のレビューが測る基準になる。

既定のパスは docs/fix-plans/<date>-<branch>.md。リポジトリに独自の規約があればそれに従う（作り出す前に確かめる）。役に立つ計画の 3 つの性質を守る。関わるファイルとインターフェースを名指しし、範囲外を書き、検証の手順で終える。

# 修正計画 — <ブランチまたは PR>

**変更の目的:** <1〜2 文>
**出どころ:** <どのレビューか、所見は何件か>

## 今すぐ直す（Fix now）
| # | 所見 | 場所 | 最小の修正 | 順番 |
|---|---|---|---|---|

## 今すぐ直す、ただし提案より小さく（Fix now, but smaller than proposed）
| # | 所見 | 提案された修正 | 実際に要るもの | 小さい方で塞がる理由 |

## 後で対応（Follow-up）
| # | 所見 | 待てる理由 | issue に書くべきこと |

## 直さない（Declined）
| # | 所見 | 理由 |
|---|---|---|
| | | spec の範囲外 / 推測 / 好みの問題 / 過剰設計 / レビュアーが意図を読み違えた |

## 判断が要る（Needs a decision）
| # | 問い | 誰が決めるか | 決めるのに要るもの |

## 順番と相互作用
- 不可逆なものを先に: …
- 統合した（根本原因が同じ）: …
- 先の修正の後に再検証が要る: …
- 同じファイルで衝突するので順番を決める: …

## この計画の範囲外
<この計画があえて触らないもの>

## 検証
<採用した修正が終わったことを示すコマンドやチェック。/da-verify が実行するもの>

## 採択率
<accepted N / total M = XX%>。前回の記録があれば併記する。

バケットの見出しは括弧の英語名を残す。scripts/loop.sh とこのファイルの他の箇所がその名前でバケットを参照する。

Step 5. 中身ではなく形を報告する

詳細はファイルにある。会話では次だけを言う。

• バケットごとの件数。Declined は隠さず数で言う
• Needs a decision の項目。人間待ちになっているのはそこだけ
• 順番の先頭 2〜3 件。次の一手が明らかになる

何も Decline しなかったなら、そう言い、警告の兆候として扱う。 レビューが珍しくきれいだったか、このパスが書き写したかのどちらか。

Decline の数が、レビュアーを信頼できるかの唯一の計測

件数だけでなく率で報告する。 受け入れ（Fix now + Fix now smaller + Follow-up）÷ 全所見。1 回分の数字は何も言わないので、レビューをまたいで蓄積するよう計画ファイルに書く。

自動レビュアーの信頼の指標であり、両方向に読む。

記録しない率は誰も使えない。 反証のパスが誤検知を抑えられたかを測るのはこの数字だけ。

完了条件

• すべての所見がちょうど 1 つのバケットにあり、落としたものは無い
• すべての Decline に、「優先度が低い」ではなく一覧の理由がついている
• 🔴 以上の Decline はすべて、要約ではなくコードで確かめた
• 順番の根拠は重大度ではなく不可逆性と依存関係
• 根本原因が同じ修正はまとめ、衝突するものは順番を決めた
• 計画がディスクにあり、ファイルを名指しし、範囲外を書き、検証の手順で終わる
• Decline の件数を率として声に出して報告し、計画ファイルに書いた

ガードレール

• 計画に合意するまでは読み取り専用。 明らかに見える 1 行の修正でも、このスキルではコードを変えない。計画中の修正は誰もレビューしていない修正
• issue の作成、PR へのコメント、push はしない。計画は提案し、決めるのはユーザー
• 所見を足さない。 見落としは別に言う。混ぜるとレビュアーが実際に何を言ったか分からなくなる