review-fix

Instructions

以下の 4 フェーズを順次実行する。

進捗の可視化（必須）

合計 5〜20 分かかる。沈黙せず、各フェーズの開始時に一文出す:

1. 着手前: 「review-fix を開始します（フェーズ0: ベースライン取得 → 1: レビュー8件並列 → 2: 修正 → 3: bun run c + bun run lint + bun test → 4: レポート）」。フェーズ1 の前に bun run lint と bun test を 1 回ずつ流し、warning 件数と pass 件数を控える
2. 各フェーズ開始時: 「フェーズN 開始」
3. フェーズ3 リトライ時: 「検証失敗、リトライN/3」
4. 完了時: 収束判定とサマリ

スコープ引数

/review-all と同じ引数体系（なし=デフォルト比較ブランチ差分 / wt / PR #N / vs:<branch> / <a>..<b> / ファイル列挙）。mode=non-interactive を併せて受け取れる（review-fix-loop から呼ばれる場合）。

フェーズ1: レビュー実行

/review-all と同じ手順（スコープ取得 → 8 レビュー並列 dispatch → 統合レポート → /tmp/arima-review-all-result.md 出力）を実行する。統合レポートのフォーマット・FAIL 帰属規律は /review-all の定義を参照。

フェーズ2: 指摘内容の反映

統合レポートの推奨アクションを HIGH → MEDIUM → LOW の順に全件反映する。

反映ルール

1. OK のチェック項目は何もしない
2. 各修正は Edit で既存ファイルを編集。新規ファイルは必要最小限
3. 過度な抽象化・過剰設計を避ける。指摘に忠実に最小限の変更で対応する
4. 既存のコードスタイル・命名語彙（docs/ARCHITECTURE.md / docs/MODELS.md / docs/DATABASE.md / docs/DEVELOPMENT.md）に合わせる
5. 指摘が曖昧で対応方針が不明確な場合はユーザーに確認する。ただし非対話モードでは確認せず最もシンプルな解釈で対応し、判断内容をフェーズ4 の「スキップした指摘」または「対応サマリ」に記録する
6. スコアの重み・計算式・スコア要素を変える修正は、docs/MODELS.md・docs/ARCHITECTURE.md・README.md・.claude/skills/help・.claude/skills/score-calc の配分記述も同時に更新する（片側だけ直すとドキュメントが嘘になる）
7. 既存債務（本変更非起因）として WARN に下げられた指摘は、修正のついでに直してよいが、スコープを広げすぎない。直した場合はレポートに「既存債務の併せ修正」と明記する

対話 / 非対話モードの判定（優先順）

1. args / prompt に mode=non-interactive / mode=interactive があればそれに従う
2. 呼び出し元が review-fix-loop と確認できれば非対話
3. 判別不能なら非対話と仮定（ユーザーへの妨害を避ける）

指摘 0 件のとき

フェーズ2 は実質スキップ。フェーズ3 も省略してよい（修正がないため再検証は冗長）。フェーズ4 で変更ファイル「（なし）」・CONVERGED のレポートを出力する。

フェーズ3: 自己検証（セルフクリティーク）

修正完了後、以下を自動実行する:

1. 型チェック: bun run c（tsgo --noEmit）。bun c は bun create と解釈されて失敗するので必ず bun run c と書く
2. lint: bun run lint。error は 0 件でなければ FAIL。warning はフェーズ1 の開始時に取ったベースラインと比べ、純増していれば WARN（減っているぶんには問題ない）
3. テスト: bun test。フェーズ1 開始時の pass 件数から減っていれば FAIL。テストが実ネットワークを叩かないことも併せて確認する
4. いずれかが失敗した場合のリトライプロトコル（最大 3 回）:
   • 1 リトライ = bun run c + bun run lint + bun test のサイクル全体 1 回
   • 修正なしの単純再実行はしない。必ず Bash の戻り値から失敗テスト名・エラーを特定し、原因を修正してから再実行する
   • テスト側のバグか実装側のバグかを git diff で切り分ける
   • 同じ修正を繰り返さない。前回の修正が効かなかったアプローチは捨てる
   • テストを skip・削除して通すことは禁止（review-test 5.3 の回帰テスト規律に反する）
5. 3 回リトライしても失敗が続く場合:
   • コードはロールバックしない（部分修正を残した方がトレースしやすい）
   • レポートに FAIL とリトライ回数 3 を記録し、収束判定は必ず NOT_CONVERGED
   • 対話モードのみ「リトライ枯渇。手動修正に切り替えますか?」と確認。非対話モードは確認なしでレポート出力して完了（ループの次反復に委ねる）
6. テスト実行で生成された一時ファイル（test-*.db / test-*.json）が残っていないか確認し、残っていれば削除する
7. 修正によって新たな問題が生じていないか、変更ファイルを読み返して確認する（消し残し・死にコードの観点 — review-code と同じ目線）

フェーズ4: 完了レポート

# レビュー指摘 反映完了レポート

## 対応サマリ

| 優先度 | 指摘数 | 対応済 | スキップ | 理由 |
| ------ | ------ | ------ | -------- | ---- |
| HIGH   | ?      | ?      | ?        | ...  |
| MEDIUM | ?      | ?      | ?        | ...  |
| LOW    | ?      | ?      | ?        | ...  |

## 変更ファイル一覧

| ファイル | 変更内容 |
| -------- | -------- |

## 自己検証結果

- `bun run c`: PASS / FAIL
- `bun run lint`: PASS（errors=0, warnings=<n>／ベースライン <n> からの増減）/ FAIL
- `bun test`: PASS（<n> pass／ベースライン <n>）/ FAIL
- ドキュメント追随: 実施 / N-A（重み・計算式の変更なし）
- 一時ファイルの後片付け: 済 / 不要
- 自己検証リトライ回数: 0〜3

## スキップした指摘（ある場合）

| 指摘内容 | スキップ理由 |
| -------- | ------------ |

## 収束判定

- `CONVERGED`: 指摘が全て 0（HIGH=0, MEDIUM=0, LOW=0）で修正なし、かつ検証失敗なし
- `NOT_CONVERGED`: 指摘が 1 件でもあった（対応済み・スキップ問わず — 修正によるデグレ可能性のため再レビュー必要）、または検証が PASS せず完了した

空欄ハンドリング: 指摘 0 のとき理由=「指摘なし」、変更ファイルなしは「| （なし） | 修正不要 |」、検証省略時のリトライ回数は「skip（指摘 0 件のため）」。

結果ファイル出力

完了レポート全文を /tmp/arima-review-fix-result.md に Write すること（review-fix-loop が収束判定に使う）。