pre-modification-check

Repowise による変更前チェック

Repowise でインデックス化されたコードベースのファイルを変更する前に、影響を評価します。

ファイルを編集する前

get_risk(targets=["path/to/file.py"]) を呼び出します。ファイルごとに hotspot_score、trend、risk_type、impact_surface（上位 3 件）、 dependents_count、co_change_partners、primary_owner、 test_gap、security_signals が返されます。以下を確認します。

• バグ修正の履歴（defect_profile）— 修正件数がカウントされているファイルにのみ表示されます。直近 6 か月の fix_count、last_fix_days_ago、最近も継続して修正されていることを示す bug_magnet フラグ、top_symbols（シンボルごとの件数は概算です。「主にこの箇所」と捉えてください）が含まれます。何度も修正されているファイルは、次の編集で何かを壊す可能性を示す最も強い単独のシグナルです。最初に確認してください。
• ホットスポットの状態（hotspot_score、trend）— 変更頻度が高く、複雑でもありますか？特別な注意が必要です。
• 依存先（dependents_count、impact_surface）— 影響範囲はどれほど広いでしょうか？
• 同時変更されるファイル — インポートの関連がない場合でも、このファイルと一緒に変更されるファイルです。そちらも更新が必要な場合があります。
• 所有者／バス係数 — 誰が担当しているか、単独の作成者が保守しているかを確認します。
• テスト不足とセキュリティシグナル — 手を加える前に、テストされていないファイルやセキュリティ上重要なファイルを把握します。

複数ファイルを変更する場合

対象をまとめて 1 回の呼び出しにします：get_risk(targets=["file1.py", "file2.py", "module/"])。

ユーザーに警告するタイミング

get_risk が以下を示した場合：

• bug_magnet が設定された defect_profile — このファイルは最近も繰り返し修正されていると明確に伝えます
• ホットスポットスコアが 90 パーセンタイルを超える — 変更頻度が高く、リスクの大きいファイルであると伝えます
• 依存先が 10 件を超える — 依存先の上位項目を列挙します。この箇所の API を変更すると、利用側に影響します
• バス係数が 1 — 1 人だけでこのコードを保守していることを伝えます
• リスクタイプが "bug-prone" または "high-coupling" — 変更前に明示して注意を促します

コードをリファクタリングまたは移動する前

まず get_context(targets=["file.py"]) を呼び出し、ファイルを使用している箇所、その構成を決めている判断、その構成になっている理由など、全体の背景を把握します。これにより、アーキテクチャ上の決定に誤って反することを防げます。

大規模なリファクタリングでは、あわせて get_health(targets=["file.py"]) も呼び出します。マーカーによる検出結果（複雑さ、深いネスト、凝集度の低さ、重複）から、その作業で改善すべき点が分かり、変更前後のスコアも確認できます。

エラー処理

get_risk がツールエラーを返した場合、MCP サーバーが起動していない可能性があります。変更を進めますが、リスク評価を利用できなかったことを明記してください。