fix

不具合調査（Fix）

原則: 原因が特定されるまでコードを修正しない。

推測に基づく修正は禁止。実際の実行フローを追い、事実に基づいて原因を特定する。 調査用の一時デバッグログの追加や検証スクリプトの作成は許可（修正ではなく調査手段）。

ワークフロー

Step 0: コンテキスト判定
Step 1: 症状の整理
Step 2: 実行フローのトレース + 原因特定
Step 3: 修正方針の提示

---

Step 0: コンテキスト判定

• feature モード: docs/plans/{feature-name}/plan.md がある場合。仕様を参照しながら調査する
• standalone モード: plan.md なし。コードベースのみで調査する

$ARGUMENTS に feature-name があればそのディレクトリを使用。なければ Glob docs/plans/**/plan.md で候補を探し、AskUserQuestion で選択させる。候補0件なら standalone で進行。

---

Step 1: 症状の整理

$ARGUMENTS または AskUserQuestion で以下を把握する:

• 何をしたか（操作手順）
• 何が起きるはずだったか
• 実際に何が起きたか
• エラーメッセージ、ログがあれば

---

Step 2: 実行フローのトレース + 原因特定

エントリポイントから症状発生箇所まで、コードを実際に追って原因を特定する。

• Grep/Read でコードパスをトレース
• 分岐条件と実際の値を確認
• 必要に応じてテスト実行・一時デバッグログで実際の値を確認
• ライブラリ起因の可能性がある場合は WebSearch で公式ドキュメント・既知の Issue を確認

原因が特定できない場合は追加調査をユーザーと繰り返す。推測で先に進まない。

---

Step 3: 修正方針の提示

原因・修正案・根拠・影響範囲をユーザーに提示する。