実装の原則

テストファーストを実践し、 Red-Green-Refactor のフローを遵守する

Definition of Done (DoD)

1. 変更は課題解決に必要な範囲へ限定する。
2. 実装後は RUNBOOK.md の手順に従って必要コマンドを実行する。
3. ユーザーがすぐ検証できる状態を作る（起動、疎通、確認コマンド提示まで含む）。
4. 実行不能なチェックは黙って省略せず、未実施理由と影響を明記する。

実装後チェック手順（順序固定）

1. 品質ゲートを実行する。

• golang バックエンドの場合
  • make ci-check
• frontend の場合
  • bun run build
  • bun run lint
  • bun run test

2. DB 変更がある場合はマイグレーションを適用する。

3. 初期データ更新が必要な場合は seed を実行する。

4. コンテナを再ビルドする。

• docker compose up -d --build
• docker compose ps
• curl http://localhost:8080/api/health

5. e2e テストを行う

6. 主要フローを最低 1 回確認し、検証手順をユーザーへ提示する。

7. codex にレビューを依頼する

• codex review --uncommitted

記録と報告ルール

1. 実行したコマンドと結果（成功/失敗）を簡潔に報告する。
2. 変更した依存関係を ascii アートで示す（例: A -> B で A が B に依存していることを表す）。
3. 実装したテスト項目を必ずリストで記載する。

• 例: 追加したユニットテスト, 修正した既存テスト, 実行した統合テスト, 手動確認シナリオ

3. 未実施項目がある場合は以下を必ず記載する。

• 未実施項目
• 未実施理由（環境制約・権限・依存不足など）
• 影響範囲
• ユーザーが代替実行するためのコマンド

4. 変更終了時はプロジェクトメモリを同期する。

• 最低でも STATUS.md の「最終更新日」「変更点」「次アクション」を更新する。
• 仕様/設計/運用手順に変更があれば SPEC.md / ARCHITECTURE.md / RUNBOOK.md も更新する。