yodogawa 2.1.1 → 2.2.0

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

@@ -1,200 +1,200 @@
-# 実装タスクリスト
-
-<!--
-このドキュメントについて:
-  - 格納場所: 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）
--->
+# 実装タスクリスト
+
+<!--
+このドキュメントについて:
+  - 格納場所: docs/tasks/task000001-{スラッグ}/c-implementation.md
+  - 作成方法: /b-004-create-task-implementation スキルで作成
+  - 実行方法: /c-001-implement-task スキルで各ステップを実行
+  - 前提条件: a-definition.md と b-research.md が作成済みであること
+  - 関連ドキュメント:
+    - a-definition.md (タスク定義ドキュメント)
+    - b-research.md (リサーチドキュメント)
+
+このドキュメントの目的:
+  - 実装作業を段階的に分割して管理
+  - 進捗の可視化とチーム共有
+  - 各ステップの成果物を明確化
+  - 実装漏れの防止
+
+更新タイミング:
+  - 実装開始前にフェーズ分割を計画
+  - 各ステップ完了時にチェック（/c-001-implement-task が自動更新）
+  - 新たな作業が発覚した際に追加
+  - レビュー指摘事項を反映
+-->
+
+---
+
+## フェーズ 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/scripts/create-task.sh

@@ -1,77 +0,0 @@
-#!/bin/bash
-
-# create-task.sh
-# docs/tasks/ 配下に連番 ID 付きのタスクディレクトリを作成するスクリプト
-# Usage: bash scripts/create-task.sh <slug>
-# 例:    bash scripts/create-task.sh user-profile-edit
-
-set -e
-
-TASKS_DIR="docs/tasks"
-SLUG="$1"
-
-echo "📂 タスクディレクトリの作成を開始します..."
-
-# 1. 引数チェック
-if [ -z "$SLUG" ]; then
-  echo "❌ スラッグが指定されていません。"
-  echo "   使い方: bash scripts/create-task.sh <slug>"
-  echo "   例:     bash scripts/create-task.sh user-profile-edit"
-  exit 1
-fi
-
-# 2. スラッグの形式チェック（英小文字・数字・ハイフンのみ、連続ハイフン禁止）
-if ! [[ "$SLUG" =~ ^[a-z0-9]+(-[a-z0-9]+)*$ ]]; then
-  echo "❌ スラッグは英小文字・数字・ハイフンのみ使用できます: '$SLUG'"
-  echo "   例: user-profile-edit"
-  exit 1
-fi
-
-# 3. 単語数の警告（3〜5 語を推奨、範囲外は警告のみで続行）
-WORD_COUNT=$(echo "$SLUG" | awk -F'-' '{print NF}')
-if [ "$WORD_COUNT" -lt 3 ] || [ "$WORD_COUNT" -gt 5 ]; then
-  echo "⚠️  スラッグは 3〜5 語を推奨しています（現在: ${WORD_COUNT} 語）。"
-fi
-
-# 4. docs/tasks/ の存在確認
-if [ ! -d "$TASKS_DIR" ]; then
-  echo "❌ '$TASKS_DIR' が存在しません。"
-  echo "   先に /a-001-setup-doc-structure を実行してください。"
-  exit 1
-fi
-
-# 5. 既存タスクから次の ID を採番
-MAX_ID=0
-for dir in "$TASKS_DIR"/task*; do
-  [ -d "$dir" ] || continue
-  BASENAME=$(basename "$dir")
-  # task000123-xxx から 000123 を抜き出す
-  if [[ "$BASENAME" =~ ^task([0-9]{6})- ]]; then
-    NUM=$((10#${BASH_REMATCH[1]}))
-    if [ "$NUM" -gt "$MAX_ID" ]; then
-      MAX_ID=$NUM
-    fi
-  fi
-done
-
-NEXT_ID=$((MAX_ID + 1))
-TASK_ID=$(printf "task%06d" "$NEXT_ID")
-TASK_DIR="$TASKS_DIR/${TASK_ID}-${SLUG}"
-
-# 6. 同名ディレクトリの存在確認（理論上発生しないが保険）
-if [ -d "$TASK_DIR" ]; then
-  echo "❌ '$TASK_DIR' は既に存在します。"
-  exit 1
-fi
-
-# 7. 作成
-echo "🔨 ディレクトリを作成中: $TASK_DIR"
-mkdir -p "$TASK_DIR"
-
-# 8. 完了報告
-echo ""
-echo "✅ タスクディレクトリを作成しました。"
-echo "   パス: $TASK_DIR"
-echo ""
-echo "次のステップ:"
-echo "  - タスク定義書を作成する: /b-002-create-task-definition"

package/scripts/init-project-docs.sh

@@ -1,90 +0,0 @@
-#!/bin/bash
-
-# init-project-docs.sh
-# templates/project/<category>/ 配下のテンプレートを
-# docs/project/<category>/ へ一括コピーするスクリプト
-# Usage: bash scripts/init-project-docs.sh <category>
-#   category: requirements | behavior | domain | design
-# 例:    bash scripts/init-project-docs.sh requirements
-
-set -e
-
-CATEGORY="$1"
-
-# スクリプト自身の位置からテンプレートルートを解決（.claude/scripts -> .claude/templates）
-SCRIPT_SELF_DIR="$(cd "$(dirname "$0")" && pwd)"
-TEMPLATE_ROOT="$SCRIPT_SELF_DIR/../templates/project"
-
-echo "📝 プロジェクトドキュメントの一括初期化を開始します..."
-
-# 1. 引数チェック
-if [ -z "$CATEGORY" ]; then
-  echo "❌ category 引数が指定されていません。"
-  echo "   使い方: bash scripts/init-project-docs.sh <category>"
-  echo "   category: requirements | behavior | domain | design"
-  exit 1
-fi
-
-# 2. category を番号付きディレクトリ名にマッピング
-case "$CATEGORY" in
-  requirements)
-    SUBDIR="01-requirements"
-    ;;
-  behavior)
-    SUBDIR="02-behavior"
-    ;;
-  domain)
-    SUBDIR="03-domain"
-    ;;
-  design)
-    SUBDIR="04-design"
-    ;;
-  *)
-    echo "❌ 不明な category: '$CATEGORY'"
-    echo "   有効な category: requirements | behavior | domain | design"
-    exit 1
-    ;;
-esac
-
-SRC_DIR="$TEMPLATE_ROOT/$SUBDIR"
-DEST_DIR="docs/project/$SUBDIR"
-
-# 3. テンプレートディレクトリの存在確認
-if [ ! -d "$SRC_DIR" ]; then
-  echo "❌ テンプレートディレクトリが見つかりません: $SRC_DIR"
-  echo "   yodogawa CLI での再インストールを検討してください。"
-  exit 1
-fi
-
-# 4. 出力先ディレクトリの存在確認
-if [ ! -d "$DEST_DIR" ]; then
-  echo "❌ 出力先ディレクトリが存在しません: $DEST_DIR"
-  echo "   先に /a-001-setup-doc-structure を実行してください。"
-  exit 1
-fi
-
-# 5. テンプレートファイルを一括コピー（既存はスキップして冪等性を確保）
-COPIED=0
-SKIPPED=0
-
-for SRC_PATH in "$SRC_DIR"/*.md; do
-  [ -f "$SRC_PATH" ] || continue
-  FILENAME=$(basename "$SRC_PATH")
-  DEST_PATH="$DEST_DIR/$FILENAME"
-
-  if [ -f "$DEST_PATH" ]; then
-    echo "ℹ️  既に存在するためスキップ: $DEST_PATH"
-    SKIPPED=$((SKIPPED + 1))
-  else
-    echo "🔨 コピー中: $SRC_PATH → $DEST_PATH"
-    cp "$SRC_PATH" "$DEST_PATH"
-    COPIED=$((COPIED + 1))
-  fi
-done
-
-# 6. 完了報告
-echo ""
-echo "✅ プロジェクトドキュメントを初期化しました。"
-echo "   カテゴリ: $CATEGORY ($SUBDIR)"
-echo "   コピー: ${COPIED} ファイル / スキップ: ${SKIPPED} ファイル"
-echo "   パス: $DEST_DIR"

package/scripts/init-task-doc.sh

@@ -1,77 +0,0 @@
-#!/bin/bash
-
-# init-task-doc.sh
-# タスクディレクトリにテンプレートから指定のドキュメントをコピーするスクリプト
-# Usage: bash scripts/init-task-doc.sh <task-dir> <type>
-#   type: definition | research | implementation
-# 例:    bash scripts/init-task-doc.sh docs/tasks/task000001-user-profile-edit definition
-
-set -e
-
-TASK_DIR="$1"
-DOC_TYPE="$2"
-
-# スクリプト自身の位置からテンプレートルートを解決（.claude/scripts -> .claude/templates）
-SCRIPT_SELF_DIR="$(cd "$(dirname "$0")" && pwd)"
-TEMPLATE_ROOT="$SCRIPT_SELF_DIR/../templates/tasks/task-template"
-
-echo "📝 タスクドキュメントの初期化を開始します..."
-
-# 1. 引数チェック
-if [ -z "$TASK_DIR" ] || [ -z "$DOC_TYPE" ]; then
-  echo "❌ 引数が不足しています。"
-  echo "   使い方: bash scripts/init-task-doc.sh <task-dir> <type>"
-  echo "   type:   definition | research | implementation"
-  echo "   例:     bash scripts/init-task-doc.sh docs/tasks/task000001-login definition"
-  exit 1
-fi
-
-# 2. タスクディレクトリの存在確認
-if [ ! -d "$TASK_DIR" ]; then
-  echo "❌ タスクディレクトリが存在しません: $TASK_DIR"
-  echo "   先に /b-001-create-task-directory を実行してください。"
-  exit 1
-fi
-
-# 3. type をファイル名にマッピング
-case "$DOC_TYPE" in
-  definition)
-    SRC_FILE="a-definition.md"
-    ;;
-  research)
-    SRC_FILE="b-research.md"
-    ;;
-  implementation)
-    SRC_FILE="c-implementation.md"
-    ;;
-  *)
-    echo "❌ 不明な type: '$DOC_TYPE'"
-    echo "   有効な type: definition | research | implementation"
-    exit 1
-    ;;
-esac
-
-SRC_PATH="$TEMPLATE_ROOT/$SRC_FILE"
-DEST_PATH="$TASK_DIR/$SRC_FILE"
-
-# 4. テンプレートの存在確認
-if [ ! -f "$SRC_PATH" ]; then
-  echo "❌ テンプレートが見つかりません: $SRC_PATH"
-  echo "   yodogawa CLI での再インストールを検討してください。"
-  exit 1
-fi
-
-# 5. 既存ファイルはスキップ（冪等性）
-if [ -f "$DEST_PATH" ]; then
-  echo "ℹ️  既に存在するためスキップ: $DEST_PATH"
-  exit 0
-fi
-
-# 6. コピー
-echo "🔨 コピー中: $SRC_PATH → $DEST_PATH"
-cp "$SRC_PATH" "$DEST_PATH"
-
-# 7. 完了報告
-echo ""
-echo "✅ タスクドキュメントを初期化しました。"
-echo "   パス: $DEST_PATH"