yodogawa 1.0.0

package/.windsurf/templates/tasks/task-template/c-implementation.md

@@ -0,0 +1,197 @@
+# 実装タスクリスト
+
+<!--
+このドキュメントについて:
+  - 格納場所: docs/tasks/task000001-{スラッグ}/c-implementation.md
+  - 作成方法: /b-003-CreateTaskImplementation ワークフローで作成
+  - 実行方法: /c-001-ImplementTask ワークフローで各ステップを実行
+  - 前提条件: a-definition.md と b-research.md が作成済みであること
+  - 関連ドキュメント:
+    - a-definition.md (タスク定義ドキュメント)
+    - b-research.md (リサーチドキュメント)
+
+このドキュメントの目的:
+  - 実装作業を段階的に分割して管理
+  - 進捗の可視化とチーム共有
+  - 各ステップの成果物を明確化
+  - 実装漏れの防止
+
+更新タイミング:
+  - 実装開始前にフェーズ分割を計画
+  - 各ステップ完了時にチェック（/c-001-ImplementTask が自動更新）
+  - 新たな作業が発覚した際に追加
+  - レビュー指摘事項を反映
+-->
+
+---
+
+## フェーズ 1: [フェーズ名]
+
+<!--
+フェーズの分け方:
+  - 機能単位で分割（例: フロントエンド → バックエンド → 統合）
+  - 依存関係で分割（例: データモデル → API → UI）
+  - リスクで分割（例: 検証 → 本実装 → 最適化）
+
+ベストプラクティス:
+  - 1フェーズは 1-3 日以内で完了できる粒度
+  - フェーズごとに動作確認可能な状態にする
+  - 各フェーズで小さくコミット・PR を作成（レビュー負荷軽減）
+-->
+
+**目的:** <!-- 例: データモデルと API エンドポイントの実装 -->
+
+**完了条件:** <!-- 例: API が期待通りのレスポンスを返し、ユニットテストが全て通る -->
+
+### ステップ
+
+<!--
+ステップの粒度:
+  - 1ステップは 1-3 時間程度で完了できる作業
+  - コミット単位で分割すると管理しやすい
+  - 成果物が明確であること（ファイル、機能、テスト）
+
+記載のポイント:
+  - 具体的なファイル名やコンポーネント名を含める
+  - 実装の詳細にはアルゴリズムや技術的な注意点を記載
+  - 依存関係があるステップは順序を意識
+-->
+
+- [ ] **ステップ 1:** データベーススキーマの定義
+  - **成果物:** `migrations/001_create_users_table.sql`
+  - **詳細:** User テーブルに `email_verified`, `verification_token`, `token_expires_at` を追加。インデックスは `verification_token` に作成
+
+- [ ] **ステップ 2:** TypeScript 型定義の追加
+  - **成果物:** `src/types/User.ts`
+  - **詳細:** `User` インターフェースに新しいフィールドを追加。Zod スキーマも同時に定義
+
+- [ ] **ステップ 3:** メール送信 API エンドポイントの実装
+  - **成果物:** `src/api/auth/send-verification.ts`
+  - **詳細:** トークン生成（UUID v4）、有効期限 24 時間、SendGrid API 呼び出し。エラーハンドリング実装
+
+- [ ] **ステップ 4:** メール認証 API エンドポイントの実装
+  - **成果物:** `src/api/auth/verify-email.ts`
+  - **詳細:** トークン検証、有効期限チェック、ユーザーステータス更新。無効トークンは 400 エラー
+
+---
+
+## フェーズ 2: [フェーズ名]
+
+**目的:** <!-- 例: フロントエンド UI の実装とユーザーフロー統合 -->
+
+**完了条件:** <!-- 例: ユーザー登録から認証完了までの一連の流れが動作し、E2E テストが通る -->
+
+### ステップ
+
+- [ ] **ステップ 1:** メール認証ページの作成
+  - **成果物:** `src/pages/EmailVerificationPage.tsx`
+  - **詳細:** URL パラメータからトークンを取得、API 呼び出し、成功/失敗メッセージ表示
+
+- [ ] **ステップ 2:** ユーザー登録フォームにメール送信処理を追加
+  - **成果物:** `src/features/auth/RegisterForm.tsx` を更新
+  - **詳細:** 登録成功後にメール送信 API を呼び出し、「確認メールを送信しました」メッセージを表示
+
+- [ ] **ステップ 3:** 認証状態のガード実装
+  - **成果物:** `src/middleware/requireEmailVerified.ts`
+  - **詳細:** 未認証ユーザーは特定ページにアクセス不可。リダイレクト処理を実装
+
+---
+
+## フェーズ 3: テスト・ドキュメント
+
+<!--
+テストフェーズの重要性:
+  - 実装と同時にテストを書くことでバグを早期発見
+  - テストコードは仕様書の役割も果たす
+  - リグレッション防止（今後の変更で既存機能が壊れない）
+
+記載すべきテスト:
+  - ユニットテスト（関数、コンポーネント単位）
+  - 統合テスト（API、データベース連携）
+  - E2E テスト（ユーザーフロー全体）
+  - エッジケーステスト（異常系、境界値）
+-->
+
+**目的:** <!-- 例: テストコード作成とドキュメント整備 -->
+
+**完了条件:** <!-- 例: テストカバレッジ 80% 以上、README にセットアップ手順を記載 -->
+
+### ステップ
+
+- [ ] **ステップ 1:** ユニットテストの作成
+  - **成果物:** `src/api/auth/send-verification.test.ts`, `verify-email.test.ts`
+  - **詳細:** トークン生成、有効期限検証、エラーハンドリングのテスト。モックを使用
+
+- [ ] **ステップ 2:** 統合テストの作成
+  - **成果物:** `tests/integration/email-verification.test.ts`
+  - **詳細:** API エンドポイントの実際の動作をテスト。テストデータベース使用
+
+- [ ] **ステップ 3:** E2E テストの作成
+  - **成果物:** `tests/e2e/user-registration.spec.ts`
+  - **詳細:** Playwright でユーザー登録→メール確認→ログインまでの流れをテスト
+
+- [ ] **ステップ 4:** ドキュメント更新
+  - **成果物:** `README.md`, `docs/tasks/task000001-{スラッグ}/a-definition.md`
+  - **詳細:** セットアップ手順、環境変数設定、API 仕様を記載
+
+---
+
+## 受け入れ基準
+
+<!--
+受け入れ基準の記載ポイント:
+  - 機能が正しく動作すること（正常系）
+  - エラーハンドリングが適切に実装されていること（異常系）
+  - エッジケースが処理されること（境界値、特殊な入力）
+  - パフォーマンス要件を満たすこと（必要に応じて）
+  - セキュリティ要件を満たすこと（XSS, CSRF, SQL Injection など）
+  - ブラウザ互換性（必要に応じて）
+  - テストが全て通ること
+  - ドキュメントが更新されていること
+
+各フェーズの完了を判断するための具体的な基準を記載します。
+全ての基準を満たした時点でタスク完了とみなされます。
+-->
+
+### フェーズ 1 の受け入れ基準
+- [ ] データベースマイグレーションが成功する
+- [ ] 型定義が正しく適用される（TypeScript コンパイルエラーなし）
+- [ ] メール送信 API がトークンを生成し、メールを送信する
+- [ ] 無効なトークンでアクセスした場合、エラーが返る
+- [ ] トークンの有効期限切れが正しく検出される
+
+### フェーズ 2 の受け入れ基準
+- [ ] メール認証ページが正しく表示される
+- [ ] 認証成功時に成功メッセージが表示される
+- [ ] 認証失敗時にエラーメッセージが表示される
+- [ ] 未認証ユーザーは保護されたページにアクセスできない
+- [ ] 認証済みユーザーは全ての機能にアクセスできる
+
+### フェーズ 3 の受け入れ基準
+- [ ] 全てのユニットテストが通る
+- [ ] 全ての統合テストが通る
+- [ ] E2E テストが通る（CI 環境でも実行）
+- [ ] テストカバレッジが 80% 以上
+- [ ] ドキュメントに記載された手順で環境構築できる
+
+---
+
+## メモ
+
+<!--
+実装全体に関する補足情報
+
+記載すべき内容:
+  - 実装中に気づいた技術的な課題
+  - リファクタリングが必要な箇所
+  - パフォーマンス最適化の余地
+  - セキュリティ上の注意点
+  - 今後の拡張予定
+  - チームメンバーへの引き継ぎ事項
+
+例:
+- メール送信は現在同期処理だが、将来的にはジョブキューに移行予定
+- トークンの有効期限は現在 24 時間だが、設定ファイルで変更可能にする
+- SendGrid の API キーは環境変数で管理（.env.example に記載）
+- セキュリティレビュー完了（2025-01-15、レビュアー: @john）
+-->

package/.windsurf/workflows/a-001-SetupDocStructure.md

@@ -0,0 +1,165 @@
+---
+description: プロジェクトのドキュメントディレクトリ構造を作成し、README で構成を説明する軽量セットアップワークフロー
+auto_execution_mode: 1
+---
+
+# SetupDocStructure (a-001)
+
+
+
+## 目的
+
+- プロジェクトルートに標準化されたドキュメントディレクトリ構造を作成する。
+- `docs/README.md` を作成し、ドキュメント構成と更新方針を明文化する。
+
+## 前提
+
+- プロジェクトのルートディレクトリへの書き込み権限があること。
+- `docs/` ディレクトリが存在しない、または既存の構造を拡張したいこと。
+
+## 手順
+
+### 1. 現在の状態確認
+
+- プロジェクトルートで `docs/` ディレクトリの存在を確認する：
+  ```bash
+  ls -la docs/ 2>/dev/null || echo "docs/ ディレクトリは存在しません"
+  ```
+- 既に `docs/` が存在する場合は、ユーザーに確認する：
+  - 「既に `docs/` ディレクトリが存在します。既存の構造を保持したまま、不足しているディレクトリを追加しますか？」
+  - ユーザーが「はい」と回答した場合のみ続行する。
+
+### 2. ディレクトリ構造の作成
+
+- 以下のディレクトリ構造を作成する：
+
+```
+docs/
+├── project/
+│   ├── 01-requirements/    # 要件定義
+│   ├── 02-behavior/         # 振る舞い定義
+│   ├── 03-domain/           # ドメインモデル
+│   └── 04-design/           # 設計
+└── tasks/                   # 個別タスク
+```
+
+- `mkdir -p` コマンドで一括作成：
+  ```bash
+  mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
+  ```
+
+- 作成結果を確認：
+  ```bash
+  find docs/ -type d | sort
+  ```
+
+### 3. docs/README.md の作成
+
+- `docs/README.md` が既に存在する場合は、ユーザーに確認する：
+  - 「`docs/README.md` が既に存在します。上書きしますか、それとも既存のファイルを保持しますか？」
+
+- 以下の内容で `docs/README.md` を作成（または上書き）：
+
+```markdown
+# プロジェクトドキュメント
+
+このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
+
+## 構成
+
+### project/
+プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
+
+- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
+- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
+- **03-domain/**: ドメインモデル（エンティティ、用語集など）
+- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
+
+### tasks/
+個別タスクのドキュメント。Issue やチケット単位で作成します。
+
+## 更新方針
+
+### プロジェクト全体のドキュメント (project/)
+- プロジェクトのスコープ全体に影響する情報を記載
+- チーム全体で共有すべき要件・設計・アーキテクチャを管理
+- 更新時は関係者にレビューを依頼
+
+### 個別タスクのドキュメント (tasks/)
+- 特定の Issue やチケットに紐づく情報を記載
+- タスク単位で作成・完了・アーカイブ
+- 完了後は参照資料として保持、または削除
+
+## ドキュメント作成ガイドライン
+
+- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
+- **測定可能**: 成功基準やパフォーマンス目標を定量化
+- **最新**: 変更があれば速やかに更新し、古い情報を残さない
+- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
+```
+
+### 4. 作成結果の確認
+
+- ディレクトリ構造とREADMEが正しく作成されたか確認：
+  ```bash
+  ls -R docs/
+  ```
+
+- ユーザーに作成結果を報告：
+  ```
+  ✅ ドキュメントディレクトリ構造を作成しました：
+
+  docs/
+  ├── README.md (作成済み - ドキュメント構成の説明)
+  ├── project/
+  │   ├── 01-requirements/
+  │   ├── 02-behavior/
+  │   ├── 03-domain/
+  │   └── 04-design/
+  └── tasks/
+
+  次のステップ:
+  - ドキュメントの作成を開始してください。
+  ```
+
+### 5. Git への追加（オプション）
+
+- ユーザーに確認：「作成したディレクトリ構造を Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/
+  git status
+  ```
+- Git status の結果を表示し、コミットメッセージの提案をする：
+  ```
+  推奨コミットメッセージ:
+  ドキュメント構造の初期化
+
+  - 標準的な構造を持つ docs/ ディレクトリを追加
+  - ドキュメント構成を説明する docs/README.md を追加
+  ```
+
+### 6. 完了条件の確認
+
+- 以下の完了条件を満たしているか、チェックリストで確認してください：
+  - [ ] `docs/` ディレクトリが作成されている
+  - [ ] `docs/project/` 配下に `01-requirements/`, `02-behavior/`, `03-domain/`, `04-design/` ディレクトリが存在する
+  - [ ] `docs/tasks/` ディレクトリが存在する
+  - [ ] `docs/README.md` が作成されている
+
+## 完了条件
+
+- プロジェクトルートに `docs/` ディレクトリが作成されている。
+- `docs/project/` 配下に `01-requirements/`, `02-behavior/`, `03-domain/`, `04-design/` ディレクトリが存在する。
+- `docs/tasks/` ディレクトリが存在する。
+- `docs/README.md` が作成されている。
+- ユーザーに作成結果が報告されている。
+
+## エスカレーション
+
+- 既存の `docs/` ディレクトリが存在し、重要なファイルが含まれている場合：
+  - 「既存のドキュメント構造が検出されました。上書きや削除のリスクがあるため、手動で確認してください。」と警告し、処理を中断する。
+- ファイルシステムの権限エラーが発生した場合：
+  - 「ディレクトリの作成に失敗しました。書き込み権限を確認してください。」とユーザーに通知する。
+- Git リポジトリでない場合に Git 追加を試みた場合：
+  - 「このディレクトリは Git リポジトリではありません。Git の初期化が必要な場合は `git init` を実行してください。」と案内する。

package/.windsurf/workflows/a-002-InitializeProject.md

@@ -0,0 +1,229 @@
+---
+description: プロジェクトのシステム概要・機能要件・非機能要件・ユーザーストーリーを体系的にヒアリングし、詳細なドキュメントを作成するワークフロー
+auto_execution_mode: 1
+---
+
+# InitializeProject (a-002)
+
+## 目的
+
+- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
+- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
+- 抽象的・曖昧な表現を避け、ユーザーとの対話を通じて具体的な数値・期限・制約・優先度を明確化する。
+- 後続の設計・実装フェーズで参照できる、チーム全体が理解できる要件定義書を整備する。
+
+## 前提
+
+- `docs/project/requirements/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) ワークフローを実行）。
+- プロジェクトリポジトリの `docs/` ディレクトリに書き込み権限があること。
+- ユーザーがプロジェクトの概要と主要な機能について基本的な情報を提供できること。
+
+## 手順
+
+### 1. ドキュメントディレクトリの確認
+
+- `docs/project/requirements/` ディレクトリの存在を確認：
+  ```bash
+  ls -la docs/project/requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
+  ```
+
+- ディレクトリが存在しない場合：
+  - ユーザーに通知：「`docs/project/requirements/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してディレクトリ構造を作成してください。」
+
+### 2. システム概要の作成
+
+1. **テンプレートの準備**:
+   ```bash
+   cp ".windsurf/templates/project/01-requirements/01-system-overview.md" "docs/project/requirements/01-system-overview.md"
+   ```
+
+2. **ヒアリングと記入**:
+   以下の質問を行い、その回答で `docs/project/requirements/01-system-overview.md` を更新する。
+
+   #### 背景
+   - 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
+   - 「その問題はなぜ重要ですか？放置した場合のリスクは？」
+   - 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
+   - 「具体的な数値やデータ（例：作業時間、コスト、離脱率など）があれば教えてください。」
+
+   #### 目的
+   - 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
+   - 「期待される成果や変化を、測定可能な形で表現できますか？（例：作業時間50%削減）」
+   - 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
+
+### 3. 実装済み機能一覧の作成
+
+1. **テンプレートの準備**:
+   ```bash
+   cp ".windsurf/templates/project/01-requirements/02-features-implemented.md" "docs/project/requirements/02-features-implemented.md"
+   ```
+
+2. **コードベースの調査と提案**:
+   - プロジェクト内のソースコードを簡易検索し、実装済みの兆候を探す。
+     ```bash
+     # 主要なソースディレクトリの構造を確認（例）
+     find src app lib -maxdepth 2 -type d 2>/dev/null
+     # 特徴的なファイル名を検索
+     find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*" | head -n 20
+     ```
+   - 検出されたディレクトリ名やファイル名から機能を推測し、ユーザーに提案する。
+     - 「`src/auth` ディレクトリが見つかりました。認証機能（ログイン、登録など）は実装済みですか？」
+     - 「`PaymentController` があります。決済機能は稼働していますか？」
+
+3. **ヒアリングと記入**:
+   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/02-features-implemented.md` に記入する（該当なしの場合は「なし」と記載）。
+
+   - 「既に実装済みの機能はありますか？（提案した機能含む）ある場合、以下の情報を教えてください：」
+     - **Category 1**（大分類：ユーザー管理、コンテンツなど）
+     - **Category 2**（中分類：認証、プロフィールなど）
+     - **機能名**（ユーザー視点の名称）
+     - **説明**（何ができるか）
+     - **機能ID**（FN-XXX形式、連番）
+
+### 4. 予定機能一覧の作成
+
+1. **テンプレートの準備**:
+   ```bash
+   cp ".windsurf/templates/project/01-requirements/03-features-planned.md" "docs/project/requirements/03-features-planned.md"
+   ```
+
+2. **要件ギャップ分析と提案**:
+   - 「システム概要」で確認した目的・スコープと、「実装済み機能」の差分を分析する。
+   - 未実装と思われる主要機能をリストアップし、ユーザーに提案する。
+     - 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。これを予定機能に追加しますか？」
+     - 「現在の実装には『××』が含まれていますが、これに関連する『△△機能』は将来的に必要になりますか？」
+
+3. **ヒアリングと記入**:
+   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/03-features-planned.md` に記入する。
+
+   - 「今後実装予定の機能をリストアップしてください（提案した機能含む）。各機能について以下を明確にします：」
+     - **Category 1**（大分類）
+     - **Category 2**（中分類）
+     - **機能名**（アイデア段階でも可）
+     - **説明**（目的や価値を中心に）
+     
+     ※テンプレートの方針に従い、**機能ID**や**優先度**はこの段階では確定させず、柔軟性を重視して記載しない。
+
+### 5. 非機能要件一覧の作成
+
+1. **テンプレートの準備**:
+   ```bash
+   cp ".windsurf/templates/project/01-requirements/04-non-functional-requirements.md" "docs/project/requirements/04-non-functional-requirements.md"
+   ```
+
+2. **必要性の確認と標準提案**:
+   - ユーザーに定義の必要性を確認する：
+     - 「現段階で非機能要件（パフォーマンス、セキュリティなど）を詳細に定義する必要がありますか？『標準的な設定』で仮置きして後で調整することも可能です。」
+   
+   - 必要または仮置きの場合、一般的なベストプラクティスを提案する：
+     - 「Webアプリケーションの標準的な目標値として、以下を提案します。これで問題ないか確認してください：」
+       - **パフォーマンス**: ページ読み込み3秒以内、API応答500ms以内
+       - **セキュリティ**: HTTPS必須、パスワードはハッシュ化、基本認証/OAuth
+       - **可用性**: 日次バックアップ、稼働率99.5%（平日日中）
+
+3. **ヒアリングと記入**:
+   提案内容への合意、または独自の要件がある場合、以下の観点で**定量的な目標**を確認し、回答で `docs/project/requirements/04-non-functional-requirements.md` の各テーブルを更新する。
+
+   #### パフォーマンス
+   - 「ページ読み込み時間の目標は？」
+   - 「APIレスポンス時間の目標は？」
+   - 「想定される同時接続ユーザー数、データ量は？」
+
+   #### セキュリティ
+   - 「認証方式、機密データの扱い、コンプライアンス要件は？」
+
+   #### 可用性・信頼性
+   - 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
+
+   #### スケーラビリティ
+   - 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
+
+   #### ユーザビリティ・保守性
+   - 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
+   - 「ログ・監視要件、デプロイ頻度は？」
+
+### 6. ユーザーストーリーの作成
+
+1. **テンプレートの準備**:
+   ```bash
+   cp ".windsurf/templates/project/01-requirements/05-user-stories.md" "docs/project/requirements/05-user-stories.md"
+   ```
+
+2. **分析と提案**:
+   - ここまで作成した「システム概要」「機能一覧（実装済み/予定）」を分析し、主要なユーザージャーニーを抽出する。
+   - ユーザーに代表的なストーリーを提案する：
+     - 「『〇〇機能』に基づき、以下のストーリーが考えられますが、いかがでしょうか？」
+       - 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+
+3. **ヒアリングと記入**:
+   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/05-user-stories.md` に記入する。
+
+   - 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）。」
+   - 各ストーリーの優先度、受け入れ基準を確認する。
+
+### 7. 全体レビュー
+
+- 作成した全てのドキュメントをユーザーに提示し、内容の正確性を確認する。
+  - 「記載内容に誤りや漏れはありませんか？」
+  - 「抽象的すぎる記述や、後で解釈が分かれそうな表現はありますか？」
+  - 「テンプレートのコメントや不要な例示は適切に処理（残す/削除）されていますか？」
+
+### 8. 完了条件と構造の確認
+
+- 以下の完了条件を満たしていて、且つドキュメントの構造が適切であることを確認します。
+  
+  1. **ファイルの存在と構造確認**:
+     各ファイルが存在し、テンプレートの主要な構造（見出しやテーブル）が維持されているか検証する。
+     ```bash
+     # 01-system-overview.md: 主要セクションの確認
+     grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
+     grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
+     
+     # 02-features-implemented.md: テーブルヘッダーの確認
+     grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md && echo "OK" || echo "MISSING: Table Header"
+     
+     # 03-features-planned.md: テーブルヘッダーの確認
+     grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md && echo "OK" || echo "MISSING: Table Header"
+     
+     # 04-non-functional-requirements.md: テーブルヘッダーの確認
+     grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md && echo "OK" || echo "MISSING: Table Header"
+     
+     # 05-user-stories.md: テーブルヘッダーの確認
+     grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md && echo "OK" || echo "MISSING: Table Header"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] すべてのファイルが存在する
+     - [ ] 各ファイルがテンプレートの基本構造を維持していて、主要なセクションやテーブルが適切に記載されている
+     - [ ] プレースホルダーが適切な内容に置き換わっていいる
+
+### 9. Git への追加（オプション）
+
+- ユーザーに確認：「作成した要件定義ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/requirements/
+  git status
+  ```
+- Git status の結果を表示し、コミットメッセージの提案をする：
+  ```
+  推奨コミットメッセージ:
+  docs: 要件定義ドキュメントの作成
+
+  - システム概要、機能要件、非機能要件、ユーザーストーリーを追加
+  ```
+
+## 完了条件
+
+- `docs/project/requirements/` 配下に一連の要件定義ドキュメントが作成されている。
+- すべてのドキュメントで抽象的な表現が最小化され、具体的な数値・期限・制約が記載されている。
+- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している。
+
+## エスカレーション
+
+- ユーザーが重要な情報を提供できない場合：
+  - 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録する。
+- 競合する要件や矛盾が発見された場合：
+  - 「以下の要件が競合しています：[詳細]。優先順位や調整方針を確認させてください。」と報告する。
+- 想定工数が非現実的に大きい場合：
+  - 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案する。