Refactor Advisor：リファクタリング提案

対象の差分を読み、機能要件や受入条件を変えない改善候補を提示します。委任する場合は、親がreferences/refactor-guidance.mdの実体絶対pathを実行者へ渡し、実行者が自身で専門基準をReadします。親が直接確認する場合は、親自身がそのreferenceをReadします。必要なら現在のランタイムの委譲primitiveを使いますが、担当数や起動方式を固定しません。

対象範囲: $ARGUMENTS

提案は任意の補助情報であり、レビューのVERDICT、実装、テストの完了条件に自動で混ぜません。重大度は code-review-guidance/references/result-contract.md の P0–P3 を使い、提案は P2・P3 に限ります。P0/P1 相当を提案へ紛れ込ませず、見つけた場合は担当外の重要事項として親へ重大度を保持して返します。適用する場合は、ユーザーまたは親が候補を選び、対象リスクに応じて別の実装・レビュー・テストを計画します。

---

ステップ 0: 実行コンテキストの確認

対象repoと現在のstatus/diffを確認する。成果物を保存する場合だけ、親またはruntimeが提示した実在のRUN_DIR/REPORT_PATHを使う。特定runtimeのhome、memory配置、パス正規化を推測しない。

---

ステップ 1: 対象範囲の特定

$ARGUMENTS に応じて対象を決定する:

• 指定なし: git status --porcelain からstaged・unstaged・untrackedを含む未コミット変更を取得
• ファイルパス: 指定されたファイルをそのまま対象とする
• ブランチ名: repoとremote/refを確認してから、明示したbase/headの差分を取得
• コミット範囲（例: HEAD~3..HEAD）: git diff --name-only <range> で差分を取得

対象ファイルが 0 件の場合はユーザーに「対象がないため refactor-advisor は起動しません」と報告して終了する（提案ゼロ件の起動は無駄なので）。

---

ステップ 2: 提案の作成

親が対象差分、要件、既存パターンを照合し、必要なら現在のruntimeの委譲primitiveへ、目的、対象、禁止範囲、根拠、返却事項、references/refactor-guidance.mdの実体pathを渡す。委譲できない場合は親が同じ観点で確認する。担当数、model、再実行回数、専用のplan/reportを固定しない。

提案には、対象箇所、改善内容、期待する利点、機能退行・移行リスク、既存実装との根拠を含める。3箇所以上の重複、既存helper・標準library、既存pattern、今回追加された抽象、説明文との整合、構造投資領域の対称性を必要に応じて確認する。存在しない計画、path、判定を補完しない。

---

ステップ 3: 結果の提示

実際に作成した提案と、保存した場合だけ実在する成果物をユーザーに提示する。提案が不要、対象がない、または利用可能な情報が不足する場合は、その事実と理由を示す。

ユーザーへの提示フォーマット

## リファクタリング提案

### PROPOSALS
[N]件（P2: M件 / P3: L件）。ここではVERDICTを返さない。

### 書き出し先
[保存した場合だけ実在するパス]

### 提案一覧（要約）
- [P2|P3] `ファイル:行`：[タイトル]（根拠：既存先例または制約を満たす要点を1行）
...

### 除外した候補
[実際に除外した候補と理由。なければ none]

提案がない場合はPROPOSALS: 0件とし、対象と確認範囲を示す。未生成のレポートや提案数を作らない。

適用はユーザーまたは親が候補を選んで明示した場合だけ行う。適用する場合は、変更された挙動に必要な review/test を別途選び、機能要件を広げない。