build-loop-codex

Codex Build Loop

品質ゲートを設けた機能開発です。「コンパイルできた」だけではリリースしません。すべての作業単位について、ビルド、レビュー、エンドツーエンドのテストを行い、ユーザーに「完了しました」と伝える前に問題を修正します。

作業の進め方

• 計画ファイルがある場合（ロードマップ、リファクタリング計画、または - [ ] チェックボックス付きのタスクリスト。リポジトリ内を検索してください）：最初の未完了タスクに取り組みます。タスクには意図的に順序が付けられています。先のタスクに飛ばないでください。計画で仕様書が参照されている場合は、現在のタスクに関連するセクションだけを読みます。
• 計画がない場合（または依頼が計画の範囲外の場合）： ユーザーのプロンプトに基づいて進めます。検証可能な目標と2〜4個の成功基準にまとめ、作業を始める前に1回のメッセージでスコープを確認します。

ループ

タスクごと（または依頼された機能ごと）に実行します。すべてのステップに合格するまで先に進みません。

1. ビルドする。 タスクに指定された内容を正確に実装します。要件を満たす最もシンプルな実装を選び、変更は最小限にとどめ、推測でスコープを広げません。既存のプロジェクトの規約に合わせます。

2. レビューする。 /review を実行し、"Review uncommitted changes" を選択します。変更が認証、決済、ユーザー入力、データアクセスに関わる場合は、"Custom review instructions" から2回目のレビューを実行します（例：「セキュリティの脆弱性と未検証の入力に注目してください」）。スコープ内のすべての指摘（バグ、セキュリティ上の問題、エッジケース、パフォーマンス、変更したファイルのスタイル）を修正します。プロジェクトにデザインシステムの仕様（デザイントークンファイル、DESIGN.md、テーマ設定）がある場合は、UI の変更が仕様に準拠しているか確認します。トークンを迂回するハードコードされた色、書体、間隔は使いません。変更していないコードに既存の問題があれば、黙って修正せず、報告に記載します。問題がなくなるまで /review を再実行します。指摘がタスクや仕様と矛盾する場合は、仕様を優先し、その不一致を報告します。

3. エンドツーエンドでテストする。 タスクの検証手順（または成功基準）を実行します。テストスイート全体を実行し、以前に合格していたテストがすべて引き続き合格することを確認します。新しいロジックにはテストを追加します。その後、ユーザーと同じように機能を試します。アプリを起動し、空、読み込み中、エラーの状態を含め、実際のフローを一通り確認します。

4. 修正する。 テストで見つかった問題はすべて、ループに戻して対応します。修正 → /review → 再テストの順に進めます。失敗しているタスクを完了扱いにしないでください。アプリが壊れた状態で次のタスクを始めないでください。

5. 続行する。 タスクを - [x] にし、計画内の進捗／ステータス行を更新してから、依頼されたスコープが完了するまで次のタスクに進みます。

6. 報告する。 完了したら、何を実装したか、計画の進捗、修正したレビュー指摘と保留した指摘、検証方法（テストと確認したフロー）、次にユーザーの対応が必要な事項を伝えます。不安定な箇所や一部しか検証できていない箇所については、正直に報告します。

ルール

• レビューを省略した作業や、テストしていない作業は未完了です。
• 計画上の判断を蒸し返さないでください。タスクに問題があるように思える場合は、推測せず、具体的な質問を1つしてください。
• どのタスクにも含まれない作業が見つかった場合は、明らかにしてタスクとして提案します。黙ってスコープを広げないでください。