yodogawa 2.1.3 → 2.2.0

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 対策は仕様どおり固定で実装する。 -->

package/templates/project/03-domain/01-domain-model.md

@@ -1,339 +1,120 @@
-# ドメインモデル (Event Storming)
-
-<!--
-何を書くか: Event Storming形式でドメインモデルを記述したドキュメント
-
-目的:
-  - ビジネスドメインの境界（Bounded Context）を明確化
-  - 各コンテキスト内のEvent Storming要素を体系的に整理
-  - ドメイン間の関係性を可視化
-  - チーム間の共通理解を構築
-
-Event Storming形式とは:
-  - Alberto Brandolini考案のドメインモデリング手法
-  - Actors, Commands, Events, Policies, Aggregatesなどの要素で構成
-  - 時系列に沿った業務フローの表現
-  - 色分けされた要素分類（付箋の色に対応）
-
-ドキュメント構成:
-  1. 各Bounded Contextごとにセクションを分ける
-  2. 各Context内でEvent Storming要素をリスト化
-  3. 最後にContext Map（全体の関係図）を記述
-
-更新頻度:
-  - ドメインモデリング完了後に初版作成
-  - スプリントレビュー時に見直し
-  - 新しいBounded Contextや要素の発見時に追加
--->
-
----
-
-## Bounded Context: [コンテキスト名]
-
-<!--
-各Bounded Context（境界づけられたコンテキスト）を個別に記述
-複数のBounded Contextがある場合は、このセクションを繰り返す
-
-【コンテキスト名】
-  - ビジネス領域を表す名前（ユビキタス言語を使用）
-  - 例: 「ユーザー管理」「注文処理」「在庫管理」「決済」
-
-【戦略的分類】
-  - Core Domain: ビジネスの競争優位性を生む中核領域
-  - Supporting Domain: コアをサポートする重要な領域
-  - Generic Domain: 汎用的な機能（既製品で代替可能）
--->
-
-### 概要
-
-**戦略的分類**: <!-- Core / Supporting / Generic -->
-
-**責務**:
-<!-- このBounded Contextが担当するビジネス機能を1-2文で記述 -->
-
-**主要な責任**:
-
-- <!-- 責任1 -->
-- <!-- 責任2 -->
-- <!-- 責任3 -->
-
----
-
-### Actors（アクター）
-
-<!--
-コマンドを発行する人やシステム
-
-【記載内容】
-  - アクター名: ユーザーの役割やシステム
-  - 説明: アクターの責任や権限
-  - 例: 「管理者」「エンドユーザー」「外部API」
-
-【Event Storming表記】小さな黄色の付箋
-
-記載のポイント:
-  - このBounded Context内で行動するアクターのみ記載
-  - 技術的な役割ではなく、ビジネス上の役割で記述
--->
-
-| アクター | 説明 |
-|---------|------|
-| <!-- 例: 管理者 --> | <!-- 例: システム設定を管理し、ユーザー権限を制御する --> |
-| <!-- 例: エンドユーザー --> | <!-- 例: サービスを利用する一般ユーザー --> |
-
----
-
-### Commands（コマンド）
-
-<!--
-アクターが発行する指示・アクション
-
-【記載内容】
-  - コマンド名: 命令形で記述
-  - 発行者: どのアクターが実行するか
-  - 説明: コマンドの目的と効果
-
-【Event Storming表記】青色の付箋
-
-フォーマット:
-  - 動詞で始める: 「登録する」「更新する」「削除する」「承認する」
-  - ユーザーの意図を表現
-  - 例: 「ユーザーを登録する」「注文を確定する」「在庫を補充する」
-
-記載のポイント:
-  - コマンドは必ずDomain Eventをトリガーする
-  - UIのボタンやAPIエンドポイントに対応することが多い
--->
-
-| コマンド | 発行者 | 説明 |
-|---------|--------|------|
-| <!-- 例: ユーザーを登録する --> | <!-- 例: エンドユーザー --> | <!-- 例: 新しいユーザーアカウントを作成する --> |
-| <!-- 例: プロフィールを更新する --> | <!-- 例: エンドユーザー --> | <!-- 例: 既存ユーザーの情報を変更する --> |
-
----
-
-### Domain Events（ドメインイベント）
-
-<!--
-ビジネスにとって重要な出来事
-
-【記載内容】
-  - イベント名: 過去形で記述
-  - トリガー: どのコマンドから発生するか
-  - 説明: イベントの意味とビジネスへの影響
-
-【Event Storming表記】オレンジ色の付箋
-
-フォーマット:
-  - 過去形で記述: 「〜された」「〜完了」
-  - ビジネスにとって意味のある出来事を表現
-  - 例: 「ユーザー登録完了」「注文確定」「決済成功」
-
-記載のポイント:
-  - 技術的なイベント（「DBに保存」）ではなく、ビジネスイベント
-  - 他のBounded Contextに通知される可能性のあるイベント
-  - 時系列に沿って並べると業務フローが見えやすい
--->
-
-| ドメインイベント | トリガー（コマンド） | 説明 |
-|-----------------|---------------------|------|
-| <!-- 例: ユーザー登録完了 --> | <!-- 例: ユーザーを登録する --> | <!-- 例: 新しいユーザーがシステムに登録された --> |
-| <!-- 例: プロフィール更新完了 --> | <!-- 例: プロフィールを更新する --> | <!-- 例: ユーザー情報が変更された --> |
-
----
-
-### Policies（ポリシー）
-
-<!--
-自動化ルールやビジネスルール
-
-【記載内容】
-  - ポリシー名: ルールの名称
-  - 条件: "Whenever [イベント]"
-  - アクション: "Then [コマンド]"
-  - 説明: ルールの詳細
-
-【Event Storming表記】紫/ライラック色の付箋
-
-フォーマット:
-  - "Whenever [イベント], then [コマンド]"
-  - "If [条件], then [アクション]"
-  - 例: "Whenever ユーザー登録完了, then ウェルカムメールを送信する"
-
-記載のポイント:
-  - イベントからコマンドへの自動的な流れを表現
-  - コードで実装される場合とオペレーターが手動で実行する場合がある
-  - ビジネスロジックの重要な部分
--->
-
-| ポリシー | 条件（Whenever） | アクション（Then） | 説明 |
-|---------|-----------------|-------------------|------|
-| <!-- 例: ウェルカムメール送信 --> | <!-- 例: ユーザー登録完了 --> | <!-- 例: ウェルカムメールを送信する --> | <!-- 例: 新規ユーザーに対して自動的にメールを送信 --> |
-| <!-- 例: 管理者通知 --> | <!-- 例: 不正ログイン検知 --> | <!-- 例: 管理者に通知する --> | <!-- 例: セキュリティイベント発生時に管理者へ警告 --> |
-
----
-
-### Aggregates（集約）
-
-<!--
-一貫性を保つべきエンティティの集まり
-
-【記載内容】
-  - Aggregate名: 集約のルートエンティティ
-  - 責務: この集約が保護するビジネスルール
-  - 含まれるエンティティ: 集約内のオブジェクト
-
-【Event Storming表記】大きな黄色の付箋
-
-DDDの概念:
-  - コマンドを受け取り、ビジネスルールを適用し、イベントを発行する
-  - トランザクション境界を定義
-  - 一貫性の保証範囲
-  - 1つのAggregateは1つのルートエンティティを持つ
-
-記載のポイント:
-  - Aggregateは独立してデプロイ可能な単位
-  - 他のAggregateとは疎結合
-  - イベントを通じて連携
--->
-
-| Aggregate | 責務 | 含まれるエンティティ |
-|-----------|------|---------------------|
-| <!-- 例: User --> | <!-- 例: ユーザーの認証情報とプロフィールの整合性を保つ --> | <!-- 例: User, Profile, Credentials --> |
-| <!-- 例: Order --> | <!-- 例: 注文の状態遷移とビジネスルールを管理 --> | <!-- 例: Order, OrderItem, ShippingAddress --> |
-
----
-
-### Read Models（読み取りモデル）
-
-<!--
-UIに表示する情報
-
-【記載内容】
-  - Read Model名: 画面やビューの名称
-  - 表示データ: 必要な情報の一覧
-  - 利用者: どのアクターが使用するか
-
-【Event Storming表記】緑色の付箋
-
-CQRSの概念:
-  - Command（書き込み）とQuery（読み込み）を分離
-  - Read Modelは最適化された読み取り専用のデータ構造
-  - イベントから非同期に構築されることが多い
-
-記載のポイント:
-  - ドメインモデルとは別の最適化されたモデル
-  - UIのニーズに合わせた構造
-  - 複数のAggregateからデータを集約する場合もある
--->
-
-| Read Model | 表示データ | 利用者 |
-|-----------|----------|--------|
-| <!-- 例: ユーザープロフィール画面 --> | <!-- 例: 名前, メール, アバター, 登録日, 最終ログイン --> | <!-- 例: エンドユーザー --> |
-| <!-- 例: ユーザー一覧画面 --> | <!-- 例: ID, 名前, ステータス, 登録日 --> | <!-- 例: 管理者 --> |
-
----
-
-### External Systems（外部システム）
-
-<!--
-このBounded Contextが連携する外部システム
-
-【記載内容】
-  - システム名: 外部システムの名称
-  - 連携方法: API, メッセージング, バッチなど
-  - 目的: なぜ連携が必要か
-
-【Event Storming表記】ピンク色の大きな付箋
-
-記載のポイント:
-  - 外部システムとの境界を明確にする
-  - Anticorruption Layer（腐敗防止層）の必要性を検討
-  - 外部システムの障害がこのContextに与える影響を考慮
--->
-
-| 外部システム | 連携方法 | 目的 |
-|------------|---------|------|
-| <!-- 例: メール送信サービス --> | <!-- 例: REST API --> | <!-- 例: ウェルカムメールや通知メールの送信 --> |
-| <!-- 例: 認証プロバイダ --> | <!-- 例: OAuth 2.0 --> | <!-- 例: ソーシャルログイン機能の提供 --> |
-
----
-
-## 次のBounded Context
-
-<!--
-上記のセクション構造を繰り返して、他のBounded Contextを記述
-各Contextは独立して理解できるように記述
--->
-
----
-
-## Context Map（コンテキスト間の関係図）
-
-<!--
-すべてのBounded Context間の関係性を可視化
-
-目的:
-  - ドメイン間の依存関係を明確化
-  - チーム間の連携方法を定義
-  - アーキテクチャの全体像を把握
-
-Context Mapping Patterns（関係性のパターン）:
-  - Shared Kernel: 共有カーネル（共通のモデルを共有）
-  - Customer-Supplier: 顧客-供給者関係（下流が上流に依存）
-  - Conformist: 順応者（上流の変更に従う）
-  - Anticorruption Layer: 腐敗防止層（変換層を介して連携）
-  - Open Host Service: 公開ホストサービス（API経由で提供）
-  - Published Language: 公開言語（共通のデータフォーマット）
-  - Partnership: パートナーシップ（相互依存、共同開発）
-  - Separate Ways: 独立した道（連携なし）
-
-エッジラベルの記載:
-  - パターン名: どの関係性パターンか
-  - 通信方法: REST API, イベント, GraphQLなど
-  - データ: やり取りされる主要なデータ
--->
-
-```mermaid
-graph TD
-    A[ユーザー管理<br/>User Management] -->|Domain Events<br/>Customer-Supplier| B[通知<br/>Notification]
-    A -->|REST API<br/>Open Host Service| C[注文処理<br/>Order Processing]
-    C -->|Domain Events<br/>Customer-Supplier| D[在庫管理<br/>Inventory]
-
-    %% スタイル定義
-    classDef core fill:#FFD700,stroke:#333,stroke-width:3px
-    classDef supporting fill:#87CEEB,stroke:#333,stroke-width:2px
-    classDef generic fill:#D3D3D3,stroke:#333,stroke-width:1px
-
-    %% Core Domain
-    class C core
-    %% Supporting Domain
-    class A,D supporting
-    %% Generic Domain
-    class B generic
-```
-
----
-
-## Context間の関係性一覧
-
-<!--
-Context Map図を補足する詳細情報
--->
-
-| 上流Context | 下流Context | 関係パターン | 通信方法 | やり取りされるデータ |
-|------------|------------|-------------|---------|-------------------|
-| <!-- 例: ユーザー管理 --> | <!-- 例: 通知 --> | <!-- 例: Customer-Supplier --> | <!-- 例: Domain Events (Kafka) --> | <!-- 例: ユーザー登録完了イベント --> |
-| <!-- 例: ユーザー管理 --> | <!-- 例: 注文処理 --> | <!-- 例: Open Host Service --> | <!-- 例: REST API --> | <!-- 例: ユーザー情報取得 --> |
-
----
-
-## メモ
-
-<!--
-全体に関する補足情報:
-  - ドメインモデル作成日と関与したメンバー
-  - 次回レビューの予定
-  - アーキテクチャ上の重要な決定事項
-  - 技術的な制約や前提条件
--->
+# ドメインモデル (Event Storming)
+
+<!--
+位置づけ（任意 / advanced テンプレート）:
+  - MVP 標準フローのテンプレートではない。標準は軽量な Domain Sketch（01-domain-sketch.md、/a-004 が生成）。
+  - 完全な Event Storming（Bounded Context / Commands / Events / Policies / Aggregates / Read Models /
+    Context Map）が必要な複雑ドメインで、任意スキル /a-005-create-domain-diagram から使う。図化の自己目的化に注意。
+  - 各要素の意味・付箋の色・CQRS / ACL などの解説は
+    skills/a-004-define-domain-model/reference/event-storming-guide.md を参照。
+-->
+
+---
+
+## Bounded Context: [コンテキスト名]
+
+<!-- Bounded Context ごとにこの節を繰り返す。名前はユビキタス言語を使う（例: 注文処理 / 在庫管理）。 -->
+
+### 概要
+
+**戦略的分類**: <!-- Core（競争優位の中核）/ Supporting / Generic（既製品で代替可能） -->
+
+**責務**: <!-- この Context が担うビジネス機能を 1〜2 文で -->
+
+**主要な責任**:
+
+- <!-- 責任1 -->
+- <!-- 責任2 -->
+
+### Actors（アクター）
+
+<!-- コマンドを発行する人やシステム。この Context 内で行動するビジネス上の役割のみ。 -->
+
+| アクター | 説明 |
+|---------|------|
+| <!-- 例: 管理者 --> | <!-- 例: システム設定を管理し、ユーザー権限を制御する --> |
+
+### Commands（コマンド）
+
+<!-- アクターが発行する指示。動詞・命令形（例: ユーザーを登録する）。必ず Domain Event をトリガーする。 -->
+
+| コマンド | 発行者 | 説明 |
+|---------|--------|------|
+| <!-- 例: ユーザーを登録する --> | <!-- 例: エンドユーザー --> | <!-- 例: 新しいアカウントを作成する --> |
+
+### Domain Events（ドメインイベント）
+
+<!-- ビジネス上重要な出来事。過去形（例: ユーザー登録完了）。技術イベント（DB 保存）ではなくビジネスイベント。 -->
+
+| ドメインイベント | トリガー（コマンド） | 説明 |
+|-----------------|---------------------|------|
+| <!-- 例: ユーザー登録完了 --> | <!-- 例: ユーザーを登録する --> | <!-- 例: 新規ユーザーが登録された --> |
+
+### Policies（ポリシー）
+
+<!-- 自動化ルール。「Whenever [イベント], then [コマンド]」形式。 -->
+
+| ポリシー | 条件（Whenever） | アクション（Then） | 説明 |
+|---------|-----------------|-------------------|------|
+| <!-- 例: ウェルカムメール送信 --> | <!-- 例: ユーザー登録完了 --> | <!-- 例: ウェルカムメールを送信する --> | <!-- 例: 新規ユーザーへ自動送信 --> |
+
+### Aggregates（集約）
+
+<!-- 一貫性を保つエンティティの塊。1 集約 1 ルートエンティティ。トランザクション境界を定義する。 -->
+
+| Aggregate | 責務 | 含まれるエンティティ |
+|-----------|------|---------------------|
+| <!-- 例: User --> | <!-- 例: 認証情報とプロフィールの整合性を保つ --> | <!-- 例: User, Profile, Credentials --> |
+
+### Read Models（読み取りモデル）
+
+<!-- UI 表示用の参照モデル（CQRS）。イベントから構築される最適化済みの読み取り専用構造。 -->
+
+| Read Model | 表示データ | 利用者 |
+|-----------|----------|--------|
+| <!-- 例: ユーザープロフィール画面 --> | <!-- 例: 名前, メール, アバター, 登録日 --> | <!-- 例: エンドユーザー --> |
+
+### External Systems（外部システム）
+
+<!-- 連携する外部システム。連携方法と目的を記す。境界には Anticorruption Layer の要否を検討する。 -->
+
+| 外部システム | 連携方法 | 目的 |
+|------------|---------|------|
+| <!-- 例: メール送信サービス --> | <!-- 例: REST API --> | <!-- 例: 通知メールの送信 --> |
+
+---
+
+## Context Map（コンテキスト間の関係図）
+
+<!--
+すべての Bounded Context 間の関係性を可視化する。
+関係パターン（Customer-Supplier / Shared Kernel / Anticorruption Layer / Open Host Service など）と
+通信方法をエッジラベルに記す。各パターンの意味は event-storming-guide.md を参照。
+-->
+
+```mermaid
+graph TD
+    A[ユーザー管理] -->|Domain Events / Customer-Supplier| B[通知]
+    A -->|REST API / Open Host Service| C[注文処理]
+    C -->|Domain Events / Customer-Supplier| D[在庫管理]
+
+    classDef core fill:#FFD700,stroke:#333,stroke-width:3px
+    classDef supporting fill:#87CEEB,stroke:#333,stroke-width:2px
+    classDef generic fill:#D3D3D3,stroke:#333,stroke-width:1px
+
+    class C core
+    class A,D supporting
+    class B generic
+```
+
+## Context間の関係性一覧
+
+<!-- Context Map 図を補足する詳細。 -->
+
+| 上流Context | 下流Context | 関係パターン | 通信方法 | やり取りされるデータ |
+|------------|------------|-------------|---------|-------------------|
+| <!-- 例: ユーザー管理 --> | <!-- 例: 通知 --> | <!-- 例: Customer-Supplier --> | <!-- 例: Domain Events (Kafka) --> | <!-- 例: ユーザー登録完了イベント --> |
+
+## メモ
+
+<!-- 作成日・関与メンバー・次回レビュー・重要なアーキテクチャ決定・前提条件など。 -->

package/templates/project/03-domain/01-domain-sketch.md

@@ -0,0 +1,90 @@
+# Domain Sketch
+
+<!--
+何のドキュメントか: AI が責務混在を起こさない程度の軽量なドメイン理解を共有する資料。
+                    完全な Event Storming / Bounded Context / Aggregate / Context Map ではない。
+                    主要概念・境界・中核エンティティ・重要ルールだけを素早く固定する。
+
+使い方:
+  - 入力は Core Scenarios（02-behavior/01-core-scenarios.md）と MVP Scope（02-mvp-scope.md）。
+  - 図を作ること自体を目的にしない。1 枚の簡易 Mermaid は任意。
+  - 複雑なドメインで Full DDD（Bounded Context / Aggregate / Context Map）が必要になったら、
+    任意で /a-005-create-domain-diagram（advanced）と 01-domain-model.md を使う。
+-->
+
+## 主要用語（10〜20 個）
+
+<!--
+何を書くか: このドメインで頻出する業務用語。曖昧語（Data / Process / Manager 等）は避ける。
+            使用例・禁止用語まで含む詳細な用語集は 02-ubiquitous-language.md に委ねる。
+-->
+
+| 用語 | 意味（1 行） |
+|---|---|
+| <!-- 例: ライフラインチャート --> | <!-- 例: 入社者が経歴の浮き沈みを時系列で描く自己紹介 --> |
+
+## アクター / 外部システム / システム境界
+
+<!--
+何を書くか: 誰がシステムを使い（アクター）、どの外部システムと連携し、システムの境界はどこか。
+-->
+
+- **アクター**: <!-- 例: 新入社員 / 受け入れチーム -->
+- **外部システム**: <!-- 例: 社内 SSO(SAML) / 通知基盤 -->
+- **システム境界（MVP で作る範囲）**: <!-- 例: プロフィール作成・閲覧・コメントまで -->
+
+## 中核エンティティと責務
+
+<!--
+何を書くか: MVP の中核となるエンティティと、その 1 行責務。属性の網羅は不要。
+-->
+
+| エンティティ | 責務（1 行） |
+|---|---|
+| <!-- 例: Profile --> | <!-- 例: 入社者の自己紹介を保持し公開状態を管理する --> |
+
+## 状態遷移（任意）
+
+<!--
+何を書くか: 重要なエンティティに明確なライフサイクルがある場合のみ記述（例: 下書き→公開→アーカイブ）。
+            不要なら「該当なし」と記す。
+-->
+
+- <!-- 例: Profile: 下書き → 公開 → （退職時）アーカイブ -->
+
+## 重要なビジネスルール
+
+<!--
+何を書くか: 守らないと価値や正しさが崩れるルールだけ。Core Scenarios の Critical Failure と整合させる。
+-->
+
+- <!-- 例: プロフィールの公開範囲は社内に限定される（社外公開不可）。 -->
+
+## MVP では作らないドメイン範囲
+
+<!--
+何を書くか: 今回モデリングしない領域を明示する。02-mvp-scope.md の Not Now / Won't と整合させる。
+-->
+
+- <!-- 例: 人事評価・勤怠は対象外（既存システムが担う）。 -->
+
+## 簡易ドメイン図（任意）
+
+<!--
+何を書くか: アクター・システム境界・外部システムを 1 枚で示す簡易図。任意。
+            複雑な Context Map / Aggregate 図が必要なら /a-005（advanced）で作成する。
+-->
+
+```mermaid
+graph LR
+  Actor[新入社員]
+  subgraph System[本システム MVP 範囲]
+    Profile[Profile]
+    Comment[Comment]
+  end
+  SSO[(社内 SSO)]
+
+  Actor -->|ログイン| SSO
+  Actor -->|自己紹介を作成 / 閲覧| Profile
+  Actor -->|コメント| Comment
+```