yodogawa 2.1.3 → 2.3.0

package/templates/project/01-requirements/{02-features-implemented.md → 06-features-implemented.md}

@@ -1,73 +1,77 @@
-# 実装済み機能一覧
-
-<!--
-何を書くか: 既に実装・リリース済みの機能を体系的に整理した一覧
-
-目的:
-  - プロダクトの現在の機能範囲を明確にする
-  - 新規メンバーへのオンボーディング資料として活用
-  - 機能追加・変更時の影響範囲把握に役立てる
-  - ドキュメントと実装の同期を保つ
-
-記載粒度: ユーザーが認識できる機能単位（APIエンドポイントレベルではなく、ユーザー機能レベル）
-
-更新頻度: 機能リリース時に必ず更新（living documentとして維持）
--->
-
-<!--
-テーブル構成:
-
-【機能ID】
-  - 形式: FN-XXX（Feature Number）
-  - 採番ルール: 連番、欠番は作らない
-  - 用途: 機能の一意識別、他ドキュメントでの参照、変更履歴の追跡
-
-【Category 1】（大分類）
-  - プロダクトの主要な機能領域で分類
-  - 例: ユーザー管理、コンテンツ、決済、通知、分析
-  - 5-10個程度に収める（多すぎると管理が困難）
-
-【Category 2】（中分類）
-  - Category 1 をさらに細分化
-  - 例: ユーザー管理 → 認証、プロフィール、権限
-  - Category 1 と合わせて機能の所在が即座に分かるように
-
-【機能名】
-  - 簡潔で分かりやすい名称（2-5単語程度）
-  - ユーザー視点の表現を使う（実装用語ではなく）
-  - 例: 「ログイン」「記事作成」「パスワードリセット」
-
-【説明】
-  - 1-2文で機能の内容を記述（50-100文字程度）
-  - 何ができるか（What）を中心に、必要に応じてどう動くか（How）を補足
-  - ユーザーへの価値や利点が分かる表現を心がける
-  - 技術的詳細は避け、ユーザー機能として記述
-
-ベストプラクティス:
-  - カテゴリは一貫性を保つ（表記ゆれを避ける）
-  - 機能の粒度を揃える（ある機能だけ詳細すぎる/粗すぎるを避ける）
-  - 説明は能動態で書く（「〜できる」「〜する」）
-  - 内部実装の変更では更新せず、ユーザー体験が変わった時のみ更新
-  - 削除された機能は一覧から削除（履歴はGitで管理）
--->
-
-| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
-|--------|-----------|-----------|--------|------|
-| <!-- FN-001 --> | <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
-
----
-
-**例:**
-
-| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
-|--------|-----------|-----------|--------|------|
-| FN-001 | ユーザー管理 | 認証 | ログイン | メールアドレスとパスワードでログイン |
-| FN-002 | ユーザー管理 | 認証 | ログアウト | セッション終了 |
-| FN-003 | ユーザー管理 | 認証 | パスワードリセット | メールでリセットリンク送信 |
-| FN-004 | ユーザー管理 | プロフィール | プロフィール編集 | 名前、アバター、自己紹介の編集 |
-| FN-005 | ユーザー管理 | プロフィール | プロフィール閲覧 | 他ユーザーのプロフィール表示 |
-| FN-006 | コンテンツ | 投稿 | 記事作成 | Markdown形式での記事作成 |
-| FN-007 | コンテンツ | 投稿 | 記事編集 | 既存記事の編集 |
-| FN-008 | コンテンツ | 投稿 | 記事削除 | 記事の削除 |
-| FN-009 | コンテンツ | コメント | コメント投稿 | 記事へのコメント |
-| FN-010 | コンテンツ | コメント | コメント削除 | 自分のコメント削除 |
+# 実装済み機能一覧
+
+<!--
+何を書くか: 既に実装・リリース済みの機能を体系的に整理した一覧
+
+モード別の扱い:
+  - existing（既存プロダクト）: 必須。既存コード分析と棚卸しで埋める。
+  - greenfield（新規プロダクト）: 任意。実装済み機能が無いため、空のまま／未生成で構わない。
+
+目的:
+  - プロダクトの現在の機能範囲を明確にする
+  - 新規メンバーへのオンボーディング資料として活用
+  - 機能追加・変更時の影響範囲把握に役立てる
+  - ドキュメントと実装の同期を保つ
+
+記載粒度: ユーザーが認識できる機能単位（APIエンドポイントレベルではなく、ユーザー機能レベル）
+
+更新頻度: 機能リリース時に必ず更新（living documentとして維持）
+-->
+
+<!--
+テーブル構成:
+
+【機能ID】
+  - 形式: FN-XXX（Feature Number）
+  - 採番ルール: 連番、欠番は作らない
+  - 用途: 機能の一意識別、他ドキュメントでの参照、変更履歴の追跡
+
+【Category 1】（大分類）
+  - プロダクトの主要な機能領域で分類
+  - 例: ユーザー管理、コンテンツ、決済、通知、分析
+  - 5-10個程度に収める（多すぎると管理が困難）
+
+【Category 2】（中分類）
+  - Category 1 をさらに細分化
+  - 例: ユーザー管理 → 認証、プロフィール、権限
+  - Category 1 と合わせて機能の所在が即座に分かるように
+
+【機能名】
+  - 簡潔で分かりやすい名称（2-5単語程度）
+  - ユーザー視点の表現を使う（実装用語ではなく）
+  - 例: 「ログイン」「記事作成」「パスワードリセット」
+
+【説明】
+  - 1-2文で機能の内容を記述（50-100文字程度）
+  - 何ができるか（What）を中心に、必要に応じてどう動くか（How）を補足
+  - ユーザーへの価値や利点が分かる表現を心がける
+  - 技術的詳細は避け、ユーザー機能として記述
+
+ベストプラクティス:
+  - カテゴリは一貫性を保つ（表記ゆれを避ける）
+  - 機能の粒度を揃える（ある機能だけ詳細すぎる/粗すぎるを避ける）
+  - 説明は能動態で書く（「〜できる」「〜する」）
+  - 内部実装の変更では更新せず、ユーザー体験が変わった時のみ更新
+  - 削除された機能は一覧から削除（履歴はGitで管理）
+-->
+
+| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
+|--------|-----------|-----------|--------|------|
+| <!-- FN-001 --> | <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
+
+---
+
+**例:**
+
+| 機能ID | Category 1 | Category 2 | 機能名 | 説明 |
+|--------|-----------|-----------|--------|------|
+| FN-001 | ユーザー管理 | 認証 | ログイン | メールアドレスとパスワードでログイン |
+| FN-002 | ユーザー管理 | 認証 | ログアウト | セッション終了 |
+| FN-003 | ユーザー管理 | 認証 | パスワードリセット | メールでリセットリンク送信 |
+| FN-004 | ユーザー管理 | プロフィール | プロフィール編集 | 名前、アバター、自己紹介の編集 |
+| FN-005 | ユーザー管理 | プロフィール | プロフィール閲覧 | 他ユーザーのプロフィール表示 |
+| FN-006 | コンテンツ | 投稿 | 記事作成 | Markdown形式での記事作成 |
+| FN-007 | コンテンツ | 投稿 | 記事編集 | 既存記事の編集 |
+| FN-008 | コンテンツ | 投稿 | 記事削除 | 記事の削除 |
+| FN-009 | コンテンツ | コメント | コメント投稿 | 記事へのコメント |
+| FN-010 | コンテンツ | コメント | コメント削除 | 自分のコメント削除 |

package/templates/project/02-behavior/01-core-scenarios.md

@@ -0,0 +1,80 @@
+# Core Scenarios
+
+<!--
+何のドキュメントか: MVP の「価値提供が成立する最小行動」を定義する軽量資料。
+                    全ケース網羅（ハッピー / エラー / 境界値）の BDD ではない。
+                    Day 1 に必ず通る成功体験と、価値を壊す重大失敗だけを固定する。
+
+使い方:
+  - 対象は MVP Scope の Must 機能のみ（02-mvp-scope.md）。Not Now / Won't は扱わない。
+  - 各シナリオは「ユーザーの意図」で書く。UI 操作（ボタン名・画面遷移）の詳細には踏み込まない。
+  - 網羅したくなったら止める。MVP で対応しない行動・エラーは「Not Covered in MVP」へ逃がす。
+
+SSoT の住み分け:
+  - User Story（05-user-stories.md）= 要約レベルの受け入れ基準（AC）。
+  - Core Scenario（本書）= 実行時の主要行動（誰が・何をして・何が起きれば成功か）。
+  - 詳細な Gherkin / 境界値 / Scenario Outline / タグ戦略が必要になったら、実装直前または
+    テスト設計時に任意で `skills/a-003-create-scenarios/reference/detailed-gherkin-template.md` を使う。
+-->
+
+## 参照: MVP Scope
+
+<!-- 02-mvp-scope.md の Must 機能のうち、本書で主要行動を固定する対象を列挙する。 -->
+
+- 対象 Must 機能: <!-- 例: FN-001 プロフィール作成 / FN-002 コメント投稿 -->
+
+## Core Flow 一覧
+
+<!--
+何を書くか: MVP の中核となるユーザー行動の流れ（1〜3本）。価値が成立する最短経路。
+記法: 表で「フロー / 主アクター / 提供価値（So that）/ 対応 Must」を一覧化する。
+-->
+
+| フロー | 主アクター | 提供価値（So that） | 対応 Must |
+|---|---|---|---|
+| <!-- 例: 自己紹介を作り共通点を見つける --> | <!-- 例: 新入社員 --> | <!-- 例: 早くチームに馴染める --> | <!-- 例: FN-001 --> |
+
+## Day 1 Happy Path（1〜3本）
+
+<!--
+何を書くか: リリース初日に「必ず通る」成功シナリオ。MVP の価値検証の中心。
+記法: Given-When-Then を1〜数文で。ユーザーの意図を書き、UI 詳細は避ける。
+-->
+
+### CS-001: <!-- シナリオ名 -->
+
+- **対応フロー / Must**: <!-- 例: 自己紹介フロー / FN-001 -->
+- **Given**: <!-- 前提（例: 新入社員がログイン済み） -->
+- **When**: <!-- 行動（例: ライフラインチャートを入力して公開する） -->
+- **Then**: <!-- 成功条件（例: プロフィールが一覧に表示され、他者が閲覧できる） -->
+
+## Critical Failure（価値を壊す重大失敗）
+
+<!--
+何を書くか: 起きると MVP の価値そのものが崩れる失敗だけ。網羅ではなく「致命傷」に限定。
+            法務・課金・権限・データ消失など、外すと危険な境界条件を優先する。
+-->
+
+### CF-001: <!-- 失敗名 -->
+
+- **何が起きると価値が壊れるか**: <!-- 例: 公開範囲を誤り社外に個人情報が漏れる -->
+- **MVP での扱い**: <!-- 例: 公開範囲は社内固定（設定不可）にして発生源を断つ -->
+
+## Not Covered in MVP（MVP で対応しない行動・エラー）
+
+<!--
+何を書くか: 「今回は対応しない」行動・エラーを明示する。スコープ膨張の防止弁。
+            02-mvp-scope.md の Not Now / Won't と整合させる。
+-->
+
+- <!-- 例: 退職者プロフィールの自動アーカイブ → Not Now -->
+- <!-- 例: 多言語対応 → Won't -->
+
+## AI 実装時の振る舞い注意点
+
+<!--
+何を書くか: 実装エージェント（Vibe coding / AI）が踏みやすい落とし穴と、固定すべき振る舞い。
+-->
+
+- <!-- 例: エラーケースを勝手に網羅実装しない。Not Covered のものは作らない。 -->
+- <!-- 例: 公開範囲のような Critical Failure 対策は仕様どおり固定で実装する。 -->