Iteration 作成ガイド（テスト実行 -> 分析 -> 自律修正）

目的と位置づけ

• このガイドは、1回のイテレーション、すなわち初回テスト実行 -> 問題分析 -> Codex による自律修正 -> 再テストと収束、を扱います。
• 目的は人手介入を減らし、既存の Draft / Plan / Code 成果物を起点に、受け入れ可能な状態まで素早く閉ループ化することです。

入力

• Plan 文書：技術受け入れチェックリストと実行順序。受け入れ境界の基準になります。
• Code 文書：実装済み内容と未実行テストケースの記録
• Draft 文書：業務セマンティクスの参考。Plan と衝突する場合は Plan を優先します。

フロー

1. 初回テスト実行

• 全テストを実行し、総数 / 成功 / 失敗 / スキップ / 実行時間を収集します。
• 失敗詳細として、テスト識別子、エラー要約、ログ / 画像パスなどの証跡を記録します。

2. 問題分析と分類

• 失敗テストとログから根本原因を特定し、機能 / ロジック / 契約 / 性能 / 環境などの型で分類します。
• 重大度と影響範囲を付け、必要であれば、テスト自体が Plan と不一致な場合にテスト修正提案も行います。

3. 自律修正

• Codex が自律的に修正を行い、可読性と一貫性を維持します。必要に応じて契約 / 型も同期します。
• 修正効果を確認するために必要な関連テストを実行し、不要な波及変更を避けます。

4. 再テストと収束

• 全テストを再実行し、初回結果と比較して失敗が解消されたか、残る阻害要因が明確化されたかを確認します。
• pnpm による typecheck / lint / format:check も実行し、その結果を記録します。

5. 結論出力と保存

• 解決済み / 未解決 / 保留の問題一覧と理由をまとめ、Plan 受け入れチェックリストとの対応結果を出します。
• Review の入力として Iteration 記録文書を作成します。

各ステップの記録要点（テンプレート対応）

• 初回テスト結果：統計、失敗一覧、証跡
• 問題分析と分類：根因、種別、重大度、影響範囲、Plan 受け入れとの関係
• 修正実施：変更要約、対象ファイル、対応テスト識別子、契約 / 型同期の有無
• 再テスト結果：比較統計、残件、理由
• 品質チェック（pnpm）：typecheck / lint / format:check の要約
• 受け入れ結論：Plan 受け入れ項目への対応結果、残件、後続提案

完了定義（DoD）

• 全テストが通る、または理由付きで保留可能な非阻害項目だけが残ること。
• pnpm の型 / スタイル / 形式チェックが通ること。
• 契約 / 型変更が同期され、その影響が記録され、必要な Plan 書き戻しが作られていること。
• Iteration 文書が完成し、そのまま Review に使えること。

出力と保存

• イテレーション終了時には、テンプレートに沿った Iteration 文書と実行結果の要約を出力します。
• まだ阻害要因が残る場合は、最小限の次アクションを示し、次が Iteration 継続か Review 入口条件の整理かを明確にします。