yodogawa 1.0.2 → 1.0.4

package/.windsurf/workflows/a-006-ReviewRequirementsDomain.md

@@ -29,9 +29,11 @@ auto_execution_mode: 1
 ### 1. ドキュメント存在確認
 
 - 必要なすべてのドキュメントが存在するか確認する：
+
   ```bash
   ls -l docs/project/requirements/*.md docs/project/behavior/*.md docs/project/domain/*.md
   ```
+
 - 不足しているドキュメントがある場合、対応するワークフロー（a-002, a-003, a-004）の実行を促す。
 
 ### 2. 一貫性チェックの実行
@@ -39,25 +41,31 @@ auto_execution_mode: 1
 以下の項目について、自動検索（grep等）と手動確認を組み合わせて検証する。
 
 #### 2.1 ユーザーストーリー ↔ シナリオ
+
 - **カバレッジ**: すべてのユーザーストーリー（US-XXX）に対応するシナリオ（SC-XXX）が存在するか。
 - **整合性**: ストーリーの「価値」とシナリオの「結果」が一致しているか。
 
 #### 2.2 実装済み機能・予定機能 ↔ シナリオ
+
 - **実装済み機能**: `02-features-implemented.md` に記載の機能に、リグレッションテスト用のシナリオが存在するか。
 - **予定機能**: `03-features-planned.md` の優先度High機能にシナリオが存在するか。
 
 #### 2.3 非機能要件 ↔ ドメインモデル
+
 - **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度など）に対し、Read ModelやCQRSが検討されているか。
 - **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
 
 #### 2.4 シナリオ ↔ ドメインモデル
+
 - **Command**: シナリオのWhen（アクション）がドメインモデルのCommandとして定義されているか。
 - **Event**: シナリオのThen（結果）がドメインモデルのDomain Eventとして定義されているか。
 - **Actor**: シナリオのActorがドメインモデルに存在するか。
 
 #### 2.5 ユビキタス言語の遵守
+
 - **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
 - **禁止用語**: 各ドキュメントに禁止用語（Data, Process等）が使われていないか。
+
   ```bash
   # 禁止用語の簡易検索（例）
   grep -r "Data" docs/project/domain/ || echo "No 'Data' found"
@@ -65,6 +73,7 @@ auto_execution_mode: 1
   ```
 
 #### 2.6 目的との整合性
+
 - システム概要の「目的」と、ドメインモデルの「Core Domain」が一致しているか。
 
 ### 3. レビュー結果レポートの作成
@@ -72,6 +81,7 @@ auto_execution_mode: 1
 - 検出された問題（Error/Warning）をまとめ、`docs/project/REVIEW-REPORT.md` を作成する。
 
 **レポートフォーマット例**:
+
 ```markdown
 # ドキュメント一貫性レビュー結果
 **実施日**: YYYY-MM-DD
@@ -113,6 +123,7 @@ auto_execution_mode: 1
 ### 5. Git への追加（オプション）
 
 - ユーザーが希望する場合、レポートをコミットする。
+
   ```bash
   git add docs/project/REVIEW-REPORT--YYYYMMDDHHMMSS.md
   git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
@@ -129,4 +140,4 @@ auto_execution_mode: 1
 - 多数のエラーが検出された場合：
   - 「不整合が多いため、ドキュメントの信頼性が低くなっています。関係者を集めて大規模なレビュー会議を行うことを推奨します。」
 - 重要機能（Core Domain）で不整合がある場合：
-  - 「Core Domainにおける不整合はリスクが高いです。実装前に必ず解消してください。」
+  - 「Core Domainにおける不整合はリスクが高いです。実装前に必ず解消してください。」

package/.windsurf/workflows/a-007-DefineTechStack.md

@@ -21,9 +21,11 @@ description: 要件を分析して推奨技術スタックを提案し、ユー
 ### 1. ドキュメントと前提条件の確認
 
 - `docs/project/design/` ディレクトリの存在を確認
+
   ```bash
   ls -la docs/project/design/ 2>/dev/null || echo "ディレクトリが存在しません"
   ```
+
 - 存在しない場合：ユーザーに通知し、`SetupDocStructure` (a-001) を実行するよう促す。
 
 - 必要な要件ドキュメントを読み込む：
@@ -35,6 +37,7 @@ description: 要件を分析して推奨技術スタックを提案し、ユー
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/01-tech-stack.md" "docs/project/design/01-tech-stack.md"
   ```
@@ -76,6 +79,7 @@ description: 要件を分析して推奨技術スタックを提案し、ユー
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # フロントエンドセクションの確認
      grep "### フロントエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Frontend section"
@@ -94,11 +98,14 @@ description: 要件を分析して推奨技術スタックを提案し、ユー
 
 - ユーザーに確認：「作成した技術スタックドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/01-tech-stack.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: 技術スタック選定ドキュメントの作成
 

package/.windsurf/workflows/a-008-DefineRepositoryStructure.md

@@ -21,14 +21,17 @@ description: 技術スタックに基づいてプロジェクトのディレク
 ### 1. ドキュメントと前提条件の確認
 
 - `docs/project/design/01-tech-stack.md` を読み込み、技術スタックを確認する。
+
   ```bash
   ls -la docs/project/design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
   ```
+
 - 存在しない場合：ユーザーに通知し、`DefineTechStack` (a-007) を実行するよう促す。
 
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/02-repository-structure.md" "docs/project/design/02-repository-structure.md"
   ```
@@ -50,11 +53,13 @@ description: 技術スタックに基づいてプロジェクトのディレク
 ユーザーからのフィードバックを受け、詳細を決定する。
 
 #### 4.1 ディレクトリ構成
+
 - ソースコードのルート（`src/` vs `app/`）
 - テストコードの配置（`tests/` vs コロケーション）
 - 機能モジュールの構成（`features/`, `components/`, `lib/` 等）
 
 #### 4.2 命名規則とルール
+
 - ファイル名（PascalCase, camelCase, kebab-case）
 - 依存関係ルール（上位層から下位層への依存のみ許可など）
 - コロケーション戦略（関連ファイルをまとめるか分離するか）
@@ -73,6 +78,7 @@ description: 技術スタックに基づいてプロジェクトのディレク
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # ディレクトリ構造図の確認
      grep "project-root/" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Directory tree"
@@ -91,11 +97,14 @@ description: 技術スタックに基づいてプロジェクトのディレク
 
 - ユーザーに確認：「作成したリポジトリ構造ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/02-repository-structure.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: リポジトリ構造とアーキテクチャ定義の作成
 

package/.windsurf/workflows/a-009-DefineScreenDesign.md

@@ -31,6 +31,7 @@ description: ユーザーストーリーとシナリオから画面一覧を抽
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/03-screen-design.md" "docs/project/design/03-screen-design.md"
   ```
@@ -48,11 +49,13 @@ description: ユーザーストーリーとシナリオから画面一覧を抽
 ユーザーからのフィードバックを受け、以下を定義する。
 
 #### 4.1 各画面の詳細
+
 - 画面ID、名称、URLパス
 - アクセス権限（誰が見れるか）
 - **重要な状態**: 初回訪問(Empty State)、ロード中、エラー時など
 
 #### 4.2 画面遷移フロー
+
 - 主要なユーザーフロー（認証、メイン機能、エラー）をMermaid図で表現する。
 - デッドエンド（戻れない画面）がないか確認する。
 
@@ -75,6 +78,7 @@ description: ユーザーストーリーとシナリオから画面一覧を抽
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # 画面一覧セクションの確認
      grep "## 画面一覧" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Screen list"
@@ -93,11 +97,14 @@ description: ユーザーストーリーとシナリオから画面一覧を抽
 
 - ユーザーに確認：「作成した画面設計ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/03-screen-design.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: 画面設計ドキュメントの作成
 

package/.windsurf/workflows/a-010-DefineDataModel.md

@@ -32,6 +32,7 @@ description: ドメインモデルと画面設計からデータベース構造
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/04-data-model.md" "docs/project/design/04-data-model.md"
   ```
@@ -49,15 +50,18 @@ description: ドメインモデルと画面設計からデータベース構造
 ユーザーからのフィードバックを受け、各エンティティの詳細を定義する。
 
 #### 4.1 基本定義
+
 - テーブル名（物理名）、論理名、説明
 - 主キー（ID）の戦略（Auto Increment / UUID / CUID）
 
 #### 4.2 属性（カラム）
+
 - カラム名、データ型（DB製品に合わせて具体的に）
 - 制約（NOT NULL, UNIQUE, DEFAULT）
 - 監査カラム（created_at, updated_at）の有無
 
 #### 4.3 リレーションシップ
+
 - 関連するエンティティ（1:1, 1:N, N:M）
 - 外部キー制約（ON DELETE CASCADE / SET NULL / RESTRICT）
 
@@ -80,6 +84,7 @@ description: ドメインモデルと画面設計からデータベース構造
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # エンティティ一覧の確認
      grep "## エンティティ一覧" docs/project/design/04-data-model.md && echo "OK" || echo "MISSING: Entities"
@@ -98,11 +103,14 @@ description: ドメインモデルと画面設計からデータベース構造
 
 - ユーザーに確認：「作成したデータモデルドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/04-data-model.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: データモデル（ERD）の定義
 

package/.windsurf/workflows/a-011-DefineAPISpec.md

@@ -33,6 +33,7 @@ description: データモデルと画面設計からAPI仕様を定義し、認
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/05-api-spec.md" "docs/project/design/05-api-spec.md"
   ```
@@ -51,15 +52,18 @@ description: データモデルと画面設計からAPI仕様を定義し、認
 ユーザーからのフィードバックを受け、詳細を定義する。
 
 #### 4.1 認証・認可
+
 - 認証方式（JWT, OAuth等）、トークンの扱い（Cookie vs Header）
 - 認可スコープやロールの定義
 
 #### 4.2 エンドポイント詳細
+
 - 各リソースのパス設計（RESTful原則の適用）
 - 認証の要否（Public vs Private）
 - CRUD以外の特殊なアクション（`/cancel`, `/publish` 等）
 
 #### 4.3 共通レスポンス形式
+
 - 成功時のレスポンス構造（`{ data: ... }` ラップの有無）
 - エラー時のレスポンス構造（`{ error: { code, message } }` 等）
 - ページネーションの仕様
@@ -77,6 +81,7 @@ description: データモデルと画面設計からAPI仕様を定義し、認
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # 認証セクションの確認
      grep "## 認証・認可" docs/project/design/05-api-spec.md && echo "OK" || echo "MISSING: Auth section"
@@ -95,11 +100,14 @@ description: データモデルと画面設計からAPI仕様を定義し、認
 
 - ユーザーに確認：「作成したAPI仕様ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/05-api-spec.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: API仕様（基本設計）の作成
 

package/.windsurf/workflows/a-012-DefineArchitecture.md

@@ -34,6 +34,7 @@ description: 技術スタック、リポジトリ構造、データモデル、A
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/06-architecture.md" "docs/project/design/06-architecture.md"
   ```
@@ -51,13 +52,16 @@ description: 技術スタック、リポジトリ構造、データモデル、A
 ユーザーからのフィードバックを受け、詳細を定義する。
 
 #### 4.1 システムアーキテクチャ図
+
 - コンポーネント間の接続、プロトコル（HTTP/gRPC）、データフローをMermaid図で表現する。
 - スケーラビリティや冗長化構成（ロードバランサー、レプリカDB）を反映する。
 
 #### 4.2 アーキテクチャパターン
+
 - 採用したパターン（レイヤード、クリーン、マイクロサービス等）とその選定理由を明確にする。
 
 #### 4.3 ADR (Architecture Decision Records)
+
 - 重要な技術的決定（DB選定、認証方式、フレームワーク選定など）を抽出する。
 - 各決定について、背景・代替案・決定理由・影響を記録する。
 
@@ -74,6 +78,7 @@ description: 技術スタック、リポジトリ構造、データモデル、A
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # アーキテクチャ図の確認
      grep "\`\`\`mermaid" docs/project/design/06-architecture.md && echo "OK" || echo "MISSING: Architecture Diagram"
@@ -92,11 +97,14 @@ description: 技術スタック、リポジトリ構造、データモデル、A
 
 - ユーザーに確認：「作成したアーキテクチャ設計ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/06-architecture.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: アーキテクチャ設計の定義
 

package/.windsurf/workflows/a-013-DefineInfrastructure.md

@@ -30,6 +30,7 @@ description: 技術スタックとアーキテクチャ設計を基に、イン
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/04-design/07-infrastructure.md" "docs/project/design/07-infrastructure.md"
   ```
@@ -47,18 +48,22 @@ description: 技術スタックとアーキテクチャ設計を基に、イン
 ユーザーからのフィードバックを受け、詳細を定義する。
 
 #### 4.1 ネットワークとセキュリティ
+
 - VPC構成、サブネット分割（Public/Private/Data）
 - セキュリティグループ方針、WAF、HTTPS化
 
 #### 4.2 コンピューティングとスケーリング
+
 - インスタンスタイプ/サイズ
 - Auto Scalingポリシー（CPU負荷等）
 
 #### 4.3 データベースとストレージ
+
 - Multi-AZ構成、リードレプリカの有無
 - バックアップ方針（頻度、保持期間）
 
 #### 4.4 環境構成
+
 - 開発/ステージング/本番環境の差異（リソースサイズ、冗長化）
 
 ### 5. ドキュメント作成
@@ -74,6 +79,7 @@ description: 技術スタックとアーキテクチャ設計を基に、イン
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # インフラ構成図の確認
      grep "\`\`\`mermaid" docs/project/design/07-infrastructure.md && echo "OK" || echo "MISSING: Infra Diagram"
@@ -92,11 +98,14 @@ description: 技術スタックとアーキテクチャ設計を基に、イン
 
 - ユーザーに確認：「作成したインフラ設計ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/design/07-infrastructure.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: インフラ設計の定義
 

package/.windsurf/workflows/a-014-ReviewDesign.md

@@ -29,9 +29,11 @@ auto_execution_mode: 1
 ### 1. ドキュメント存在確認
 
 - 必要なすべての設計ドキュメントが存在するか確認する：
+
   ```bash
   ls -l docs/project/design/*.md
   ```
+
 - 不足しているドキュメントがある場合、対応するワークフローの実行を促す。
 
 ### 2. 一貫性チェックの実行
@@ -39,22 +41,27 @@ auto_execution_mode: 1
 以下の項目について、自動検索（grep等）と手動確認を組み合わせて検証する。
 
 #### 2.1 テックスタック ↔ アーキテクチャ
+
 - **整合性**: 選定された技術（01-tech-stack.md）がアーキテクチャ図（06-architecture.md）のコンポーネントと一致しているか。
 - **ADR**: 重要な技術選定理由がADRとして記録されているか。
 
 #### 2.2 データモデル ↔ ドメインモデル
+
 - **カバレッジ**: ドメインモデルのAggregate（01-domain-model.md）がデータモデル（04-data-model.md）のエンティティとして定義されているか。
 - **用語統一**: テーブル名やカラム名がユビキタス言語と一致しているか。
 
 #### 2.3 API仕様 ↔ データモデル
+
 - **リソース**: APIリソース（05-api-spec.md）がデータモデルのエンティティに基づいているか。
 - **フィールド**: APIのレスポンスフィールドがデータモデルに存在するか。
 
 #### 2.4 画面設計 ↔ API仕様
+
 - **カバレッジ**: 画面（03-screen-design.md）で必要なデータ取得・操作がAPIエンドポイントとして定義されているか。
 - **状態**: エラー状態やロード状態に対応するレスポンス仕様があるか。
 
 #### 2.5 インフラ ↔ アーキテクチャ
+
 - **構成**: インフラ構成（07-infrastructure.md）がアーキテクチャ図のコンポーネントを網羅しているか。
 - **非機能要件**: 可用性やセキュリティ要件がインフラ設計に反映されているか。
 
@@ -63,6 +70,7 @@ auto_execution_mode: 1
 - 検出された問題（Error/Warning）をまとめ、`docs/project/DESIGN-REVIEW-REPORT.md` を作成する。
 
 **レポートフォーマット例**:
+
 ```markdown
 # 設計ドキュメント一貫性レビュー結果
 **実施日**: YYYY-MM-DD
@@ -103,6 +111,7 @@ auto_execution_mode: 1
 ### 5. Git への追加（オプション）
 
 - ユーザーが希望する場合、レポートをコミットする。
+
   ```bash
   git add docs/project/DESIGN-REVIEW-REPORT.md
   git commit -m "docs: 設計整合性レビューレポートの作成"
@@ -119,4 +128,4 @@ auto_execution_mode: 1
 - 致命的な不整合がある場合：
   - 「データモデルとAPI仕様の間に大きな乖離があります。実装手戻りを防ぐため、設計の見直しを強く推奨します。」
 - ドメインモデルとの乖離がある場合：
-  - 「設計がドメインモデルの意図を反映していません。ビジネスロジックの破綻につながる恐れがあります。」
+  - 「設計がドメインモデルの意図を反映していません。ビジネスロジックの破綻につながる恐れがあります。」

package/.windsurf/workflows/b-001-CreateTaskDirectory.md

@@ -20,9 +20,11 @@ auto_execution_mode: 1
 ### 1. 既存タスクの確認とID採番
 
 - 既存のタスクディレクトリを確認し、次のタスクIDを決定する。
+
   ```bash
   ls -d docs/tasks/task*
   ```
+
 - **採番ルール**:
   - 形式: `task{6桁連番}-{スラッグ}`
   - 例: `task000001-email-auth`
@@ -37,10 +39,13 @@ auto_execution_mode: 1
 ### 3. ディレクトリの作成
 
 - 決定したIDとスラッグを使用してディレクトリを作成する。
+
   ```bash
   mkdir -p docs/tasks/task{ID}-{SLUG}
   ```
+
   例:
+
   ```bash
   mkdir -p docs/tasks/task000001-email-auth
   ```
@@ -48,6 +53,7 @@ auto_execution_mode: 1
 ### 4. 作成確認
 
 - ディレクトリが正しく作成されたか確認する。
+
   ```bash
   ls -ld docs/tasks/task{ID}-{SLUG} && echo "OK" || echo "FAILED"
   ```
@@ -68,4 +74,4 @@ auto_execution_mode: 1
 - `docs/tasks/` が見つからない場合:
   - `mkdir -p docs/tasks` を実行するか、`SetupDocStructure` (a-001) の確認を促す。
 - 命名規則違反:
-  - タスク名にスペースや特殊文字が含まれる場合、修正を求める。
+  - タスク名にスペースや特殊文字が含まれる場合、修正を求める。

package/.windsurf/workflows/b-002-CreateTaskDefinition.md

@@ -21,10 +21,13 @@ description: ユーザーストーリーとインタビューからタスク定
 ### 1. タスクディレクトリとテンプレートの確認
 
 1. タスク候補を一覧し、作業対象を特定する。
+
    ```bash
    ls -d docs/tasks/task*
    ```
+
 2. テンプレートが未配置の場合はコピーする。
+
    ```bash
    cp ".windsurf/templates/tasks/task-template/a-definition.md" \
       "docs/tasks/task{ID}-{SLUG}/a-definition.md"
@@ -85,6 +88,7 @@ grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
 ```
 
 チェックリスト:
+
 - [ ] 目的に数値/Before-Afterが含まれている
 - [ ] すべての重要なユーザーストーリーが列挙されている
 - [ ] 変更箇所がファイル名やエンドポイント単位で特定されている
@@ -96,6 +100,7 @@ grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
 git add docs/tasks/task{ID}-{SLUG}/a-definition.md
 git commit -m "docs(task): タスク定義書の作成 task{ID}"
 ```
+
 - テンプレートに従い、以下を記載：
   - **目的**（解決する問題、提供する価値）
   - **ユーザーストーリー一覧**（ストーリーID、ストーリー）