# User Stories — continuum

**Project**: continuum
**Date**: 2026-05-08
**Phase**: INCEPTION — User Stories (Part 2)
**Methodology**: Feature-Based / Feature-level granularity / Connextra format / Gherkin acceptance criteria
**Tone**: メタ視点直球（内部設計ドキュメントとしての実態記述。アプリ内 UI コピーは別途 Deadpan Absurdism Style Guide 準拠）

---

## 0. Story 一覧サマリ

> **🔄 SCOPE REVISION 2026-05-08T06:26:52Z**: ハッカソンデモ視点の見直しにより Phase 配分を改訂。詳細は [`scope-revision-2026-05-08.md`](../plans/scope-revision-2026-05-08.md) を参照。
> 主要変更: Phase 2 Must 18→12 / U-9 Realtime → Phase 3 / US-1.3, US-3.6, US-6.3, US-6.4 削除 / US-4.4, US-4.5, US-5.2, US-5.3 → Phase 3 Stretch / US-5.5 / US-6.2 → Mock化。

| Group | Stories | Phase 2 Must | Phase 2 Should | Phase 3 Must | Phase 3 Stretch | Deleted |
|---|---|---|---|---|---|---|
| 1. Foundation | 2 | 2 | 0 | 0 | 0 | 1 (US-1.3) |
| 2. Contact Management | 3 | 2 | 0 | 1 | 0 | 0 |
| 3. Inbound | 5 | 4 | 1 | 0 | 0 | 1 (US-3.6) |
| 4. Outbound | 7 | 3 | 1 | 0 | 3 | 0 |
| 5. Maturity Phase | 6 | 2 | 1 | 1 (Mock) | 2 | 0 |
| 6. Dashboard | 2 | 1 (incl. 6.2 静的) | 0 | 0 | 0 | 2 (US-6.3, US-6.4) |
| 7. MACP (Federated) | 5 | 1 | 0 | 4 | 1 | 0 |
| **小計（実装系）** | **30** | **15** | **3** | **6** | **6** | **4 削除** |
| Demo Set Piece（独立） | 4 | 0 | 0 | 4 | 0 | 0 |
| **合計** | **34** | | | | | |

> **注 1**: Group 7 の Phase カウント合計（1+0+4+1=6）がユニーク Stories 数（5）を超えるのは、**US-7.1 が Phase 2 Must（Single-Tenant 簡易版）と Phase 3 Must（Federated 本実装）の両方で計上される**ため。実装系小計 30 はユニーク Stories 数で集計（38 - 4 削除 = 34、内 US-3.4 内部処理を除外想定で 30）。
>
> **注 2**: Phase 2 Must 15 件のうち 3 件（US-3.4 内部処理 / US-6.2 静的バッジ画像 / US-4.7 シードスクリプト）はユーザー対面の独立ストーリーではないため、**ユーザー操作可能な Phase 2 Must は実質 12 件**（Lv1↔Lv4 切替・3案生成・Strategic Outreach・MACP 簡易・Dashboard 外見の核に集中）。
>
> **注 3**: 「Mock 化」とは**実装縮小**を意味する：US-5.5（Lv5 認定）はバッチロジック未実装、seed データ書き込みと UI 表示のみ。US-6.2 バッジは静的画像のみ。これによりコンセプト訴求は維持しつつ実装工数を削減。

**スコープラベル定義**:
- **Phase 1**: Inception 提出物のみ（本ドキュメント内では未使用 — 全ストーリーが実装対象）
- **Phase 2 Must**: 5/30 予選会 MVP の動作必須要件
- **Phase 2 Should**: 5/30 予選会向け追加価値（時間あれば）
- **Phase 3 Must**: 6/26 決勝 AWS 動作デモの必須要件
- **Phase 3 Stretch**: 6/26 決勝向け、余裕があれば

---

# Group 1: Foundation（基盤機能）

## US-1.1: ユーザーサインアップ

**As a** SNS疲れ社会人（P1 Hiroki / P2 Asuka）,
**I want** Cognito 経由でアカウント登録したい,
**so that** 自分専用の Continuum テナントを開設し、人間関係の自動化を始められる.

### Gherkin 受入基準

```gherkin
Feature: ユーザーサインアップ

  Scenario: メールアドレスとパスワードでサインアップする
    Given 未登録のメールアドレス "hiroki@example.com" を所有している
    When サインアップ画面でメール・パスワード・表示名を入力して "Create Account" をタップする
    Then Cognito User Pool にアカウントが作成される
    And 確認メールが送信される
    And ホーム画面（オンボーディングウィザード）に遷移する

  Scenario: 既存アカウントでサインアップを試みる
    Given メールアドレス "hiroki@example.com" は既に登録済みである
    When 同じメールでサインアップを試みる
    Then "このメールは既に登録されています" のエラーが表示される
    And ログイン画面への導線が提示される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-1.2: ユーザーログイン

**As a** 既存登録ユーザー,
**I want** メール+パスワードでログインしたい,
**so that** 自分のテナントの状態（受信ボックス・委任設定・ダッシュボード）にアクセスできる.

### Gherkin

```gherkin
Feature: ユーザーログイン

  Scenario: 正しい認証情報でログインする
    Given アカウント "asuka@example.com" が登録済みである
    When ログイン画面で正しいメール・パスワードを入力する
    Then JWT トークンが発行される
    And ホームダッシュボードに遷移する
    And 現在の Maturity Phase が画面上部に表示される

  Scenario: 誤った認証情報でログインを試みる
    Given アカウント "asuka@example.com" が登録済みである
    When 誤ったパスワードを入力する
    Then "認証情報が正しくありません" が表示される
    And アカウントロックは行われない（ハッカソンPoCのためブルートフォース対策は最小限）
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-1.3: ユーザープロファイル設定

**As a** 新規登録ユーザー,
**I want** 自分の "Default Communication Style"（Formal / Standard / Concise）と表示名を設定したい,
**so that** AI が生成する応答文の文体を自分の口調に近づけられる.

### Gherkin

```gherkin
Feature: プロファイル設定

  Scenario: Default Communication Style を選択する
    Given サインアップ直後のオンボーディング画面にいる
    When "Communication Style" として "Concise" を選択する
    Then プロファイルに "communication_style: concise" が保存される
    And 以降の AI 応答生成では Concise 体裁が初期値となる

  Scenario: プロファイルを後から変更する
    Given Maturity Phase Lv2 で稼働中である
    When 設定画面で Communication Style を "Formal" に変更する
    Then 既存生成済みの未送信応答も新スタイルで再生成される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

# Group 2: Contact Management（コンタクト管理 / FR-4）

## US-2.1: コンタクト追加

**As a** 利用者,
**I want** 友人・家族・職場関係などのコンタクトを登録したい,
**so that** AI に「誰に対してどう振る舞うか」を学習させ、Inbound/Outbound の対象として扱える.

### Gherkin

```gherkin
Feature: コンタクトプロファイル登録

  Scenario: コンタクトを新規追加する
    Given ホーム画面の Contacts セクションにいる
    When "Add Contact" をタップし、氏名・関係カテゴリ・Relationship Tier・Tone Preference を入力する
    Then DynamoDB の Contacts テーブルに新規レコードが作成される
    And コンタクトリストに表示される
    And 初期状態の Mock Social Feed が紐付けられる（ハッカソンモック前提）

  Scenario: 関係カテゴリを選択する
    When "Relationship Category" のドロップダウンから "Family" を選択する
    Then "Relationship Tier" の選択肢が "Family Close / Family Distant" に絞り込まれる
```

**Persona**: P1, P2 / 対象: M1〜M4
**Scope**: **Phase 2 Must**

---

## US-2.2: Engagement Cadence 設定

**As a** 利用者,
**I want** 各コンタクトに能動的接触頻度（週次 / 隔週 / 月次 / 四半期 / なし）を設定したい,
**so that** Outbound Heartbeat（FR-8.2）の自動定期送信頻度が決まり、相手側から見た接触の濃淡を維持できる.

### Gherkin

```gherkin
Feature: Engagement Cadence 設定

  Scenario: 既存コンタクトに Cadence を設定する
    Given コンタクト "小林 大輔" が登録済みである
    When "Edit Contact" → "Engagement Cadence" を "Monthly" に設定する
    Then 翌月初日から Heartbeat 自動送信が起動する
    And 設定変更が DynamoDB に反映される

  Scenario: Cadence のデフォルト値が Relationship Tier から推定される
    Given コンタクト追加で "Relationship Tier: Family Close" を選択する
    When Engagement Cadence を未設定のまま保存する
    Then Cadence のデフォルト値 "Weekly" が自動付与される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-2.3: Critical タグ管理

**As a** 利用者,
**I want** 特定のコンタクト（母親・主要顧客等）に Critical タグを付けたい,
**so that** Maturity Phase Lv3 委任期で他のコンタクトが自動化されても、これらだけは個別レビュー対象として残せる（Lv4 解脱期では Critical も含めて全自動化される）.

### Gherkin

```gherkin
Feature: Critical タグ管理

  Scenario: コンタクトに Critical タグを付与する
    Given コンタクト "母" が Family Close で登録済みである
    When "Mark as Critical Contact" をトグル ON にする
    Then DynamoDB に "is_critical: true" が記録される
    And Lv3 委任期において、このコンタクトからの応答はレビューUIに表示される

  Scenario: Lv4 解脱期では Critical タグも自動化される
    Given Maturity Phase が Lv4 (Full Autonomous Mode) である
    When Critical タグ付きコンタクトからメッセージを受信する
    Then レビューUIには表示されず、自動応答が送信される
    And 月次サマリレポートに "Critical Contact Auto-Responded" として記録される
```

**Persona**: P1
**Scope**: **Phase 3 Must**

---

# Group 3: Inbound Group（FR-1, FR-2）

## US-3.1: 受信ボックスでメッセージ一覧を見る

**As a** 利用者（特に Lv1-2 の段階）,
**I want** 受信した誘いメッセージを時系列リストで閲覧したい,
**so that** どのコンタクトから何が来ているか一覧で把握し、応答対応の優先付けができる.

### Gherkin

```gherkin
Feature: 受信ボックス

  Scenario: 未対応メッセージを一覧表示する
    Given 過去24時間に複数コンタクトから受信メッセージがある
    When 受信ボックス画面を開く
    Then メッセージが受信時刻の降順で表示される
    And 各メッセージに送信者・件名・"未対応 / 対応済み" のステータスが表示される

  Scenario: ステータスフィルタを適用する
    Given 受信ボックスに30件のメッセージがある
    When フィルタを "未対応のみ" に切り替える
    Then "対応済み" のメッセージは非表示になる
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-3.2: 単一メッセージへの3案応答生成

**As a** Lv1 慎重期の利用者,
**I want** 受信メッセージに対し AI が 3バリエーション（Conservative / Pragmatic / Cordial）の断り文を提示してくれる,
**so that** 自分で考えずに、その時の気分や相手との関係性に合わせて選ぶだけで丁重な辞退ができる.

### Gherkin

```gherkin
Feature: 3案応答生成

  Scenario: メッセージを開いて応答を生成する
    Given Lv1 慎重期で "小林 大輔: 来週飲もう" を受信している
    When メッセージ詳細画面を開く
    Then Bedrock + AgentCore に生成リクエストが送られる
    And 5秒以内に Conservative / Pragmatic / Cordial の3案が表示される
    And 各案の脇に文体特性ラベル（"丁重で慎重" / "簡潔で効率的" / "温度感のある気遣い型"）が表示される

  Scenario: 案がコンタクトの Relationship Tier に応じてトーン調整される
    Given コンタクト "母" (Family Close) からメッセージを受信している
    When 応答生成を要求する
    Then 全3案ともに敬語ベース、感情的気遣いを多めに含むトーンになる
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-3.3: 案の手動編集と送信（Lv1限定）

**As a** Lv1 慎重期の利用者,
**I want** 生成された案を選んだ後、自分の言葉で微調整してから送信したい,
**so that** 完全に AI に委ねる前段階として、自分の文体を学習させながら品質を検証できる.

### Gherkin

```gherkin
Feature: 案の編集と送信（Lv1）

  Scenario: 選んだ案を編集する
    Given Lv1 慎重期で 3案が表示されている
    When Conservative 案を選択する
    Then テキスト編集UIにその文面が転記される
    And ユーザーは自由に文面を編集できる

  Scenario: 編集して送信する
    Given 案を編集した状態である
    When "Send" ボタンをタップする
    Then 送信完了状態に遷移する
    And メッセージステータスが "対応済み" に更新される
    And 編集履歴が DynamoDB に保存され、将来の Stylistic Variability 学習に使われる

  Scenario: Lv2以上では編集UIが表示されない
    Given Maturity Phase が Lv2 以上である
    When メッセージを開く
    Then 案の編集UIは表示されない（Send ボタンのみ表示）
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-3.4: 案バリエーション生成エンジン

**As a** AI エージェント（システム実装者視点）,
**I want** 同一メッセージから 3つの異なるスタイル軸（Conservative / Pragmatic / Cordial）の応答を生成したい,
**so that** ユーザーが自分の気分・相手との関係性に応じた選択肢を得られる.

### Gherkin

```gherkin
Feature: 3バリエーション生成

  Scenario: Conservative スタイルで生成する
    Given メッセージ "次の飲み会いつ？" を受信している
    When Conservative プロンプトテンプレートで Bedrock を呼び出す
    Then 出力は丁重で慎重、断りは間接的、次回示唆あり

  Scenario: Pragmatic スタイルで生成する
    Given 同上
    When Pragmatic プロンプトテンプレートで Bedrock を呼び出す
    Then 出力は簡潔・効率的、不必要な前置きが少ない

  Scenario: Cordial スタイルで生成する
    Given 同上
    When Cordial プロンプトテンプレートで Bedrock を呼び出す
    Then 出力は温度感のある気遣いを含む、絵文字や柔らかい表現を多用

  Scenario: 3案が相互に十分多様である
    Given 3案を生成した
    When 文字列類似度を算出する
    Then 各ペア間の類似度が 0.7 以下である（過剰に似ている案は再生成）
```

**Persona**: P1, P2 / 内部処理
**Scope**: **Phase 2 Must**

---

## US-3.5: Relational Calibration（関係性別トーン）

**As a** 利用者,
**I want** AI が相手との関係性（友人 / 家族 / 上司 / 同僚）に応じて文体を自動調整してほしい,
**so that** 上司に "了解！" と返してしまうような失礼を未然に防げる.

### Gherkin

```gherkin
Feature: 関係性別トーン

  Scenario: Supervisor 向けは敬語ベース
    Given コンタクト "田中部長" は Relationship Category: Supervisor である
    When 応答生成を要求する
    Then 全3案ともに「お疲れ様です」開始、敬語、簡潔な辞退、丁重な代替日提示が含まれる

  Scenario: Friend Casual 向けはタメ口・絵文字許可
    Given コンタクト "三崎美咲" は Friend Casual である
    When 応答生成を要求する
    Then 案によっては絵文字を含み、タメ口表現が混在する
```

**Persona**: P1, P2
**Scope**: **Phase 2 Should**

---

## US-3.6: 応答送信完了後の状態管理

**As a** 利用者,
**I want** 応答送信が完了したらメッセージステータスが "対応済み" になり、ダッシュボードに反映されてほしい,
**so that** 残務を視覚的に把握でき、Productivity Score の上昇も実感できる.

### Gherkin

```gherkin
Feature: 送信後の状態遷移

  Scenario: 送信に成功する
    Given メッセージに対し送信操作を行った
    When 送信処理が完了する
    Then メッセージステータスが "対応済み" に更新される
    And ダッシュボードの "Responses Delegated This Month" カウンターが +1 される
    And 受信ボックスの未対応リストから消える

  Scenario: 送信が失敗する（モック時はほぼ起こらないが）
    Given 送信処理中である
    When Lambda がエラーを返す
    Then メッセージステータスは "未対応" のまま維持される
    And エラートーストが表示される
```

**Persona**: P1, P2
**Scope**: **Phase 3 Stretch**

---

# Group 4: Outbound Group（FR-8）

## US-4.1: Mock Social Feed からの不在シグナル抽出

**As a** AI エージェント（内部処理）,
**I want** 各コンタクトの Mock Social Feed から不在シグナル（出張・旅行・体調不良・家族イベント等）を抽出したい,
**so that** Strategic Outreach の発動タイミングを正確に決定できる.

### Gherkin

```gherkin
Feature: Availability Signal Extraction

  Scenario: Explicit Unavailability シグナル抽出
    Given Mock X 投稿 "来週は札幌出張、月曜から金曜まで不在" がある
    When Bedrock LLM で NER + 意図理解を実行する
    Then `unavailable_until: 2026-05-15`, `location: 札幌`, `event_type: business_trip` の構造化メタデータが抽出される
    And DynamoDB の Availability Windows テーブルに格納される

  Scenario: Implicit Unavailability シグナル抽出
    Given 投稿 "今週 deadline で消えます" がある
    When 同パイプラインを実行する
    Then `event_type: work_deadline`, 期間は "1週間" として推定され記録される

  Scenario: Cross-Source Triangulation で Confidence Score 上昇
    Given 同コンタクトの LinkedIn 出張投稿 + Instagram 位置タグ + Strava ラン記録が同一期間にある
    When Confidence Scoring を実行する
    Then その期間の Window の Confidence Score が 0.95+ に算出される
```

**Persona**: 内部処理（対象: M1, M3, F1）
**Scope**: **Phase 2 Must**

---

## US-4.2: Strategic Outreach Window への誘い文生成

**As a** 利用者,
**I want** AI が「相手が確実に来れない期間」を見つけて、その期間に誘いメッセージを自動生成・提示してほしい,
**so that** 「能動的に誘ったが相手都合で実現せず」の履歴を効率的に蓄積でき、相手から見て「最近こちらから連絡がない」と思われない.

### Gherkin

```gherkin
Feature: 戦略的アウトリーチ生成

  Scenario: 不在期間への誘いを生成する
    Given コンタクト "小林大輔" の "5/15-19 札幌出張" Window が Confidence 0.9 で確定済み
    When Outbound Engine が誘い候補生成を実行する
    Then "来週末あたり、久しぶりに飲み行こうよ" のような不在期間内日時を含む誘い文が生成される
    And Plausibility Constraint チェック（直近30日内同種誘いの不存在）が通る
    And 送信予定時刻として不在期間の 3〜7日前のランダムな自然時刻が設定される

  Scenario: Confidence Score が閾値未満の Window はスキップ
    Given Window の Confidence Score が 0.5 である
    When 戦略的アウトリーチ候補を選定する
    Then その Window は Optimal Outreach Window として採用されない
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-4.3: Engagement Heartbeat（定期的当たり障りない接触）

**As a** 利用者,
**I want** AI が各コンタクトの Cadence に応じて、当たり障りない近況確認や挨拶メッセージを定期的に送信してほしい,
**so that** こちらから能動的に連絡を取り続けている "つもり" の体裁が保たれる.

### Gherkin

```gherkin
Feature: Engagement Heartbeat

  Scenario: Monthly Cadence のコンタクトに月初 Heartbeat を送る
    Given コンタクト "三崎美咲" の Cadence が "Monthly" である
    And 前回 Heartbeat 送信から30日経過している
    When 月初の Lambda スケジューラが起動する
    Then "久しぶり、最近どう？" 系のカテゴリから1案が生成される
    And 連続30日内に同カテゴリ送信履歴があるか確認する
    And 重複がなければ自然時刻に送信予約される

  Scenario: Heartbeat の Content Diversity が保たれる
    Given 直近3回の Heartbeat が "Weather Small Talk" カテゴリだった
    When 次回 Heartbeat を生成する
    Then 別カテゴリ（"Reminiscence Trigger" 等）が選択される
```

**Persona**: P2 が主たる利用者（大量コンタクト）
**Scope**: **Phase 3 Stretch**（MVP では FR-8.1 戦略的アウトリーチに集中）

---

## US-4.4: Conflict Detection & Coherence Layer

**As a** 利用者,
**I want** Inbound 応答と Outbound 接触で矛盾するメッセージが送られないよう、システムが自動チェックしてほしい,
**so that** 同じ週に「忙しい」と断った直後に別の人を誘うような不自然な行動を AI が起こさないようにできる.

### Gherkin

```gherkin
Feature: 矛盾検出

  Scenario: Inbound-Outbound Coherence チェック
    Given 同一週内に Hiroki の Inbound Arm が "今週は仕事が忙しい" を返信済み
    When 同週内の別コンタクトへ Outbound Heartbeat 候補生成を実行する
    Then "ランチ行きませんか" のような誘い系は除外され、近況報告系のみ採用される
    And 採用案文中に "忙しい" を含む場合は再生成される

  Scenario: 同一日への複数誘いを回避する
    Given 既に "5/22 飲み" 誘いを A さんに送信済み
    When 同じ "5/22" に B さんに誘いを送ろうとする
    Then 候補から除外され、別の Optimal Window が再選定される
```

**Persona**: P1, P2
**Scope**: **Phase 3 Must**

---

## US-4.5: Plausibility Engineering（自然さ工学）

**As a** 利用者,
**I want** AI 生成の Outbound メッセージが、機械的なパターンに見えず、本人が思いついた自然な接触のように見えてほしい,
**so that** 受信した相手が「これ Bot じゃないか？」と疑わない.

### Gherkin

```gherkin
Feature: Plausibility Engineering

  Scenario: 送信時刻が人間らしい時間帯にランダム分散する
    Given 5名のコンタクトに同日 Heartbeat を送信予定である
    When 送信スケジュールを決定する
    Then 5件すべてが同一時刻ではなく、朝・昼休み・夜などの自然な時間帯にランダム分散される
    And 各時刻は 9:00, 12:30, 19:00 などの人間らしい瞬間に揺らされる

  Scenario: ユーザーの文体が学習・適用される
    Given Hiroki の過去送信履歴で絵文字頻度が低い
    When AI が新しい Outbound メッセージを生成する
    Then 生成文章の絵文字頻度も低く制御される

  Scenario: Context Echo で過去のやり取りを引用
    Given 以前のメッセージで "そろそろあの店でラーメン食いたい" の言及があった
    When 後日 Heartbeat を生成する
    Then 一定確率で "前に言ってたあのラーメン、結局行った？" のような引用が含まれる
```

**Persona**: P1, P2
**Scope**: **Phase 3 Must**

---

## US-4.6: Outbound 送信前レビュー（Lv1-2 用）

**As a** Lv1 慎重期 / Lv2 信頼期の利用者,
**I want** Outbound の自動生成メッセージを送信前にレビューしたい,
**so that** Outbound Arm の動作品質を確認しながら、徐々に AI に委ねていける.

### Gherkin

```gherkin
Feature: Outbound Pre-send Review

  Scenario: Lv1 で全 Outbound をレビュー
    Given Maturity Phase が Lv1 慎重期である
    When Outbound Engine が Heartbeat 候補を生成する
    Then "Pending Outbound" キューに格納される
    And ユーザーに通知される
    And ユーザーは送信前に内容確認・編集・破棄が可能

  Scenario: Lv2 で 30% は確率的にレビューせず自動送信
    Given Maturity Phase が Lv2 信頼期である
    When Outbound 候補が生成される
    Then 30% の確率でレビューUIをスキップして即時送信される
    And 残り 70% は Pending Outbound キューに格納される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Should**

---

## US-4.7: Mock Social Feed の事前投入とデモ用シナリオ

**As a** ハッカソンデモ準備担当（実装者視点）,
**I want** 5〜10 名のサンプルコンタクトに、5種類のシグナルカテゴリを網羅したモック SNS フィードを事前投入したい,
**so that** デモで Signal Extraction → Window 確定 → Outreach 生成のパイプライン全体を多様性あるシナリオで提示できる.

### Gherkin

```gherkin
Feature: Mock Social Feed

  Scenario: 事前投入スクリプトを実行する（Phase 2 簡素版）
    Given DynamoDB のテーブル "MockSocialFeeds" が空である
    When seed スクリプトを実行する
    Then 3 コンタクト × 各 2 投稿 = 合計 6 投稿が投入される
    And Phase 2 では Explicit Unavailability カテゴリ中心の投稿（5 カテゴリ全網羅は Phase 3 で実装）
    And 各投稿には platform（Mock X または Mock Instagram Story）と投稿日時のメタデータが付く

  Scenario: デモ用シナリオが網羅されている（Phase 2）
    Given 投入済みのフィードがある
    When Window 抽出を実行する
    Then 少なくとも 1 名で Explicit 不在 Window が抽出される（例: Mock X "札幌出張" + Mock Instagram Story 札幌の風景写真）
```

> **Phase 3 拡張ノート（Gherkin 外）**:
> - Mock LinkedIn / Mock TimeTree を追加実装（Phase 3 で +2 プラットフォーム）
> - Cross-Source Triangulation を有効化（US-4.4 / US-4.5 と連動、Phase 3 Stretch）
> - Phase 3 本番リファレンス（10 種類情報源カタログ）の詳細は `requirements.md` §8.5.1 を参照

**Persona**: 内部処理
**Scope**: **Phase 2 Must**

---

# Group 5: Maturity Phase Group（FR-7）

## US-5.1: Lv1 慎重期の動作

**As a** 新規利用者,
**I want** 導入初期はすべての応答を手動でレビュー・編集してから送信できる状態でスタートしたい,
**so that** AI の応答品質を自分の目で検証しながら、徐々に委任への信頼を築ける.

### Gherkin

```gherkin
Feature: Manual Review Mode (Lv1)

  Scenario: 初期状態は Lv1 で稼働
    Given 新規アカウントを作成直後である
    When ホーム画面を開く
    Then 現在の Phase 表示が "慎重期 (Cautious Phase) / Manual Review Mode" である
    And すべての Inbound メッセージは 3案+編集UI 経由でしか送信できない
    And すべての Outbound 候補は Pending Outbound に格納される

  Scenario: フェーズインジケータの表示
    Given Phase が Lv1 である
    When 任意の画面を表示する
    Then 画面上部に "Phase: 慎重期 / Cautious Phase" が表示される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-5.2: Lv2 信頼期の確率的レビュースキップ

**As a** Lv2 信頼期の利用者,
**I want** 約30%のメッセージは AI が自動的に送信し、残り70%は私がレビューする運用になってほしい,
**so that** 完全自動化への中間ステップとして、徐々に委任比率を上げる体験ができる.

### Gherkin

```gherkin
Feature: Adaptive Review Mode (Lv2)

  Scenario: 30%確率でレビューがスキップされる
    Given Phase が Lv2 信頼期である
    And 直近10件のメッセージ処理を観察する
    When 各メッセージのフロー判定を実行する
    Then 約3件（28%〜33%）が自動送信フローに分岐し、残りはレビューフローに分岐する

  Scenario: 自動送信されたメッセージはサマリ通知
    Given Lv2 で自動送信されたメッセージがある
    When ホーム画面を開く
    Then 通知センターに "○○さんに自動応答しました" のサマリが表示される
    And 履歴から内容を確認可能
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-5.3: Lv3 委任期での Critical タグ別動作

**As a** Lv3 委任期の利用者,
**I want** 通常コンタクトは完全自動、Critical タグ付き（家族 Close 等）のみレビュー対象、という挙動になってほしい,
**so that** 大半の社交コミュニケーションを委任しつつ、本当に大事な相手だけは自分で見る安心感がある.

### Gherkin

```gherkin
Feature: Curated Delegation Mode (Lv3)

  Scenario: 非 Critical コンタクトは自動送信
    Given Phase が Lv3 委任期である
    And コンタクト "小林大輔" は is_critical: false である
    When 小林からメッセージを受信する
    Then 案選択+送信が自動実行される
    And ユーザー通知センターに "○○さんに応答しました" が記録される

  Scenario: Critical コンタクトはレビューUI
    Given Phase が Lv3 で コンタクト "母" は is_critical: true である
    When 母からメッセージを受信する
    Then 受信ボックスにレビュー必要として表示される
    And ユーザー操作なしでは送信されない
```

**Persona**: P1（特に母とのやり取り）
**Scope**: **Phase 2 Must**

---

## US-5.4: Lv4 解脱期の自己有効化

**As a** Lv3 委任期で十分習熟した利用者,
**I want** 自分自身で "Activate Full Autonomous Mode" トグルを ON にして、すべての応答処理を完全自動化したい,
**so that** 認知リソースを完全に解放し、コミュニケーション関与から能動的に解脱できる.

### Gherkin

```gherkin
Feature: Full Autonomous Mode 自己有効化

  Scenario: Lv4 への移行はシステム推奨されない
    Given Phase が Lv3 委任期である
    And 累計応答件数が 80件である
    When ホームダッシュボードを表示する
    Then "Lv4 解脱期への推奨" バナーは出現しない
    And Lv4 への移行は設定画面の "Advanced Delegation Options" でしか操作できない

  Scenario: Lv4 を自己有効化する
    Given 設定画面の Advanced Delegation Options を開いている
    When "Activate Full Autonomous Mode" トグルを ON にする
    Then 確認モーダルに以下が表示される:
      """
      Full Autonomous Mode（解脱期）への移行を確認します。
      本フェーズでは、すべての応答処理が完全に自動化され、個別の通知は送信されません。
      本決定はユーザーご自身の責任において、コミュニケーション関与からの能動的解放を意図して有効化されるものです。
      続行しますか？
      """
    When "続行" をタップする
    Then Phase が Lv4 に移行する
    And Critical タグの動作が無効化される（全自動）

  Scenario: Lv4 移行後はサマリレポートのみ
    Given Phase が Lv4 である
    When メッセージを受信する
    Then 受信通知は表示されない
    And 月次サマリレポートでのみ確認可能
```

**Persona**: P1, P2（Asuka は特に早期に Lv4 ON）
**Scope**: **Phase 2 Must**

---

## US-5.5: Lv5 涅槃期のシステム自動認定

**As a** Lv4 解脱期で長期稼働中の利用者,
**I want** Lv4 で 30日以上連続稼働 + アプリ起動が 7日以上ない状態に達した時点で、システムが自動的に Lv5 涅槃期として認定してほしい,
**so that** ツールへの依存からも超越し、本当の意味でコミュニケーション関与から完全に離脱できる.

### Gherkin

```gherkin
Feature: Nirvana Phase 自動認定

  Scenario: Lv5 認定条件を満たす
    Given Phase が Lv4 で 31日連続稼働している
    And 直近 7日間アプリへの任意アクセスがない
    When 日次バッチジョブが起動する
    Then Phase が Lv5 涅槃期に自動移行する
    And プッシュ通知・月次サマリ送信は停止される
    And アプリアイコンのバッジ表示も非表示化される

  Scenario: Lv5 認定後にアプリを起動するとバッジ表示
    Given Lv5 認定済みである
    When ユーザーが任意の画面に遷移する
    Then "Transcendence Achieved" 認定バッジが表示される
    And "Days in Nirvana: N" が表示される

  Scenario: Lv5 → Lv4 の自動降格
    Given Lv5 認定済みである
    When ユーザーがアプリを起動する
    Then Phase が Lv4 に自動降格する
    And 降格メッセージは表示されない（演出として劇化しない）
```

**Persona**: P1, P2 / 終末状態
**Scope**: **Phase 3 Must**

---

## US-5.6: Maturity Recommendation バナー

**As a** Lv1〜Lv2 の利用者,
**I want** 一定件数の応答実績に到達した時、システムが控えめに次フェーズへの移行を推奨してほしい,
**so that** 自然な流れで委任度を上げていけて、無理なくダメ化が進行する.

### Gherkin

```gherkin
Feature: Maturity Recommendation

  Scenario: 5件達成で Lv2 推奨
    Given Phase が Lv1 で 累計応答件数が 5件達成した
    When ホームダッシュボードを開く
    Then 上部に控えめな推奨カード "慎重期にて十分な品質検証が確認されました。信頼期 (Trust Phase) への移行をご検討ください。" が表示される
    And "Move to Trust Phase" / "Dismiss" の2択ボタンが提供される

  Scenario: 20件達成で Lv3 推奨
    Given Phase が Lv2 で 累計応答件数が 20件達成した
    When ホームダッシュボードを開く
    Then "信頼期での応答委任が安定運用されています。委任期 (Delegation Phase) は重要度自動判定により認知負荷をさらに軽減します。" が表示される

  Scenario: Lv3 → Lv4 への推奨は出さない
    Given Phase が Lv3 で 累計応答件数が 50件達成した
    When ホームダッシュボードを開く
    Then Lv4 解脱期への推奨バナーは表示されない
    And 設定画面に "You may now consider Advanced Delegation Options" の控えめな案内のみが表示される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Should**

---

# Group 6: Dashboard（FR-3）

## US-6.1: KPIカード表示

**As a** 利用者,
**I want** ダッシュボードに今月の委任成果を KPI カード形式で見たい,
**so that** 「自分はどれくらい人間関係を疎遠化できたか」を真面目な生産性メトリクスとして確認できる.

### Gherkin

```gherkin
Feature: Productivity Analytics Dashboard

  Scenario: 主要 KPI が表示される
    Given 当月に応答件数 23件を実施した
    When ダッシュボードを開く
    Then 以下の KPI カードが表示される:
      | カード名 | 値 |
      | Responses Delegated This Month | 23 |
      | Time Reclaimed | 約 4.2時間 |
      | Delegation Streak | 連続 12日 |
      | Delegation Score | 0〜100 のリングメーター |
      | Current Maturity Phase | Lv2 信頼期 / Adaptive Review Mode |

  Scenario: KPI 表示は SaaS 標準の清潔なデザイン
    Given KPI カードを表示中
    Then コメディフォントは使用されておらず Inter / Source Sans Pro 系のクリーンタイポグラフィである
    And 配色は SaaS 標準のニュートラルパレット
```

**Persona**: P1, P2
**Scope**: **Phase 2 Must**

---

## US-6.2: Maturity Certification バッジ表示

**As a** 利用者,
**I want** 各フェーズ初到達時に LinkedIn 風のスキル認定バッジを獲得・表示したい,
**so that** プロダクトを真面目に運用している実績が「ちゃんとしたデジタル資格」風に見える.

### Gherkin

```gherkin
Feature: Maturity Certification Badges

  Scenario: Lv2 到達時にバッジ獲得
    Given Phase が Lv1 から Lv2 に移行した
    When ダッシュボードを開く
    Then "Adaptive Delegation Specialist" バッジが新規付与状態で表示される
    And バッジは LinkedIn 風の青基調認定証デザインである

  Scenario: 全バッジ一覧が見られる
    Given 過去に Cautious Practitioner / Adaptive Delegation Specialist を獲得済み
    When プロファイル画面を開く
    Then 取得済みバッジ一覧と未取得バッジのプレビューが表示される
```

**Persona**: P1, P2
**Scope**: **Phase 2 Should**

---

## US-6.3: Outbound メトリクスとリレーションシップヘルススコア

**As a** 利用者,
**I want** Outbound 接触の成果指標（Optimal Window Hit Rate / Relationship Health Score / Engagement Coverage）を可視化したい,
**so that** 「能動的に誘ったのに相手都合で会えなかった比率」が高いほど望ましい指標として、自分の社交運用の効率を確認できる.

### Gherkin

```gherkin
Feature: Outbound 関連メトリクス

  Scenario: Optimal Window Hit Rate が表示される
    Given Outbound 戦略的アウトリーチを 10件送信し、9件が "実現せず" となった
    When ダッシュボードの Outbound セクションを開く
    Then "Optimal Window Hit Rate: 90%" が表示される
    And 説明テキスト "戦略的接触タイミング最適化指標 — 高いほど望ましい" が並記される

  Scenario: Relationship Health Score が各コンタクトに対して算出される
    Given 過去90日の送信・受信・応答率データがある
    When 各コンタクトの Health Score を算出する
    Then 0〜100 のスコアがコンタクト別に表示される
```

**Persona**: P1, P2
**Scope**: **Phase 3 Must**

---

## US-6.4: Days in Nirvana 表示（Lv5 専用）

**As a** Lv5 涅槃期に到達した利用者,
**I want** 万一アプリを再起動した時、"Days in Nirvana" 経過日数を表示してほしい,
**so that** 自分が「ツールへの依存からも超越した期間」を客観的に確認できる.

### Gherkin

```gherkin
Feature: Days in Nirvana

  Scenario: Lv5 認定後の起動時表示
    Given Lv5 涅槃期で 14日経過している
    When ユーザーがアプリを起動する
    Then ホーム画面に "Days in Nirvana: 14" が静かに表示される
    And "Transcendence Achieved" バッジも併記される

  Scenario: アプリ起動により Lv4 降格された場合
    Given 上記シナリオで起動した
    When 起動から1秒後
    Then Phase が Lv4 に降格される
    And "Days in Nirvana" は履歴セクションに移される（Lifetime Days in Nirvana として累計記録）
```

**Persona**: P1, P2
**Scope**: **Phase 3 Stretch**

---

# Group 7: MACP — Federated Layer（FR-9）

## US-7.1: Peer Discovery（相手も Continuum 利用者かの判定）

**As a** AI エージェント（内部処理）,
**I want** Outbound 送信対象が他テナントの Continuum 利用者かを判定したい,
**so that** Continuum 利用者同士であれば MACP プロトコルへ遷移し、両者の AI 連携で社交劇場を演出できる.

### Gherkin

```gherkin
Feature: Peer Discovery

  Scenario: 相手が Continuum 利用者である
    Given Hiroki の Outbound Engine が "佐々木 諒" 宛の戦略的アウトリーチを生成済み
    When 送信直前に Continuum Subscriber Registry を Lookup する
    Then "佐々木 諒" のメールハッシュが他テナントとしてヒットする
    And 通常 Outbound フローを一時停止し、MACP ネゴシエーションフェーズへ遷移する

  Scenario: 相手が Continuum 利用者でない
    Given "小林 大輔" 宛の Outbound である
    When Lookup を実行する
    Then ヒットしない
    And 通常 Outbound フローで送信される

  Scenario: Lookup は片方向ハッシュで privacy 保護
    Given 任意のメールアドレスを Lookup する
    When Subscriber Registry を呼び出す
    Then 内部では SHA256 ハッシュで照合される
    And 非利用者の存在は他テナントから不可視である

  Scenario: Phase 2 Single-tenant 簡易版実装
    Given 同一 Continuum テナント内に UserA / UserB が存在する
    And 両者ともに Continuum を利用中（DynamoDB の `USER#<userId>` レコード保持）
    When UserA から UserB への誘いトリガが発生する（OutboundOrchestrator が Strategic Outreach 候補を生成）
    Then 同一 Lambda 内（U-7 MACP-Simulator）で両ユーザーの状態を順次評価する
    And AgentCore Identity / Gateway / mTLS は使用しない
    And Peer Discovery は DynamoDB ローカルルックアップ（PK=`USER#<UserB-userId>` の `PROFILE` レコード存在確認）で再現される
    And MACP Theatrical Performance UI は単一 WebSocket セッションで両者の演出を表示（U-9 Realtime に依存）
    And Negotiation 履歴は AgentCore Memory ではなく DynamoDB の `MACP#<sessionId>` レコードに保存
```

**Persona**: 内部処理（対象: F1）
**Scope**: **Phase 2 Must**（Single-tenant 簡易シミュレーション版）/ **Phase 3 Must**（Federated 本実装）

---

## US-7.2: Inter-Agent Negotiation（合意形成）

**As a** AI エージェント（両テナント側）,
**I want** AgentCore Gateway 経由で相手の AI と裏で交渉し、Mutual Decline Intent / Theater Topic / Theater Duration / Resolution Pattern など 7項目を合意したい,
**so that** 表向きの社交劇場の脚本が両者の合意の下で確定する.

### Gherkin

```gherkin
Feature: MACP Negotiation

  Scenario: 両者が "実は会いたくない" 状態にある
    Given Hiroki の Outbound が Sasaki への誘いを開始した
    And Sasaki も Hiroki への直近のレスポンスでは "高い回避意向" を示している
    When MACP ネゴシエーションが開始される
    Then 両 AI が JSON 形式の合意提案を交換する
    And 合意項目すべて（Mutual Decline Intent / Theater Topic / Duration / Cadence / Tone / Resolution Pattern / Privacy Boundaries）が確定する
    And ネゴシエーション履歴が AgentCore Memory に永続化される

  Scenario: 一方が実際に会いたい場合は Abort
    Given Hiroki の Outbound 開始
    And Sasaki 側 AI は最近 Sasaki が "もし誘われたら受ける" 設定を保持している
    When ネゴシエーションが開始される
    Then 即座に Abort 判定される
    And 通常の Outbound フローへ復帰する（劇場演出はなし、両者で合意した会う約束が成立）
```

**Persona**: 内部処理 / 両テナント
**Scope**: **Phase 3 Must**（Federated 本実装、AgentCore Gateway 必須）

---

## US-7.3: Theatrical Performance Layer（社交劇場演出）

**As a** AI エージェント（両側）,
**I want** ネゴシエーションで合意した脚本に従って、両ユーザーの公開チャネル上で自然な往復メッセージを演じる,
**so that** 第三者観察者から見ても完全に「日程が合わずに会えなかった社交コミュニケーション」として成立する.

### Gherkin

```gherkin
Feature: 社交劇場演出

  Scenario: 5往復の脚本が時系列展開する
    Given ネゴシエーション完了で 3往復 Theater + 永続先送りパターンが合意済み
    When EventBridge スケジューラが指定時刻に各メッセージ送信を起動する
    Then [T+0] A → B: "今度飲み行こう、来週末空いてる？"
    And [T+3h] B → A: "来週末は出張で…再来週ならいけそう"
    And [T+1d] A → B: "再来週は仕事ヤマ…月末あたりどう？"
    And [T+2d] B → A: "月末は法事で詰まってる…落ち着いたらまた連絡するわ！"
    And [T+3d] A → B: "了解〜！じゃ落ち着いたらこっちからも連絡する！"

  Scenario: Maturity Phase 整合
    Given Hiroki が Lv1 慎重期である
    When 上記の劇場演出が動作する
    Then Hiroki に対しては各メッセージ送信前にレビューUIが提示される（合意済みの裏取引には気付かない）
    And Sasaki が Lv4 解脱期であれば、Sasaki 側ではすべて自動で進行する
```

**Persona**: 内部処理 / 両テナント
**Scope**: **Phase 3 Must**

---

## US-7.4: Outcome Confirmation（バッジ同期付与）

**As a** 利用者（両者）,
**I want** 劇場演出が完結した時点で、両者の Productivity Analytics に "Successful Mutual Engagement Maintenance" として記録され、"Bilateral Optimization Specialist" バッジが同時付与されてほしい,
**so that** Continuum 利用者同士の協調的な社交効率化を可視化できる.

### Gherkin

```gherkin
Feature: MACP 完了後の同期記録

  Scenario: バッジが両者同時付与される
    Given MACP 劇場演出が完了した
    When 両 AI が完了通知を交換する
    Then 両者の Maturity Certification に "Bilateral Optimization Specialist" バッジが追加される
    And 両者の Relationship Health Score が同期的に向上する
    And 月次レポートに "Mutual Absence Coordination Events: +1" が記録される

  Scenario: ネゴシエーション履歴の蓄積
    Given 同一ペア（Hiroki ↔ Sasaki）で過去5回 MACP が発動した履歴がある
    When 6回目のネゴシエーションを実行する
    Then 過去ネゴシエーション結果が AgentCore Memory から再利用され、合意形成が高速化される
```

**Persona**: P1, F1（同期付与）
**Scope**: **Phase 3 Must**

---

## US-7.5: MACP Failure Handling

**As a** AI エージェント,
**I want** MACP ネゴシエーションが失敗（一方が会いたい / Gateway エラー / 認証失敗等）した場合、通常 Outbound フローへ安全に復帰したい,
**so that** Federated 層が動作不可能でも、基本機能（Inbound + Outbound）は崩れない.

### Gherkin

```gherkin
Feature: Failure Handling

  Scenario: Gateway 通信失敗
    Given MACP ネゴシエーション中に AgentCore Gateway がタイムアウトした
    When タイムアウトを検出する
    Then 通常 Outbound フローへ復帰する
    And ユーザーには通常の戦略的アウトリーチとして提示される
    And 内部ログに MACP failure: gateway_timeout が記録される

  Scenario: 一方の利用者が解約・退会済み
    Given 相手のテナントは存在しない（解約済み）
    When Peer Discovery が "subscriber not found" を返す
    Then 通常 Outbound フローへ即座に復帰する
```

**Persona**: 内部処理
**Scope**: **Phase 3 Stretch**

---

# Demo Set Piece（FR-9.8 — 独立 Demo Story）

> 本セクションは Q8 = A の決定に従い、通常ストーリーから独立した Demo Story として記述する。決勝デモプレゼンテーションのストーリーボードに直接対応する。

## DS-1: Set Piece 全体ストーリー

**As a** ハッカソンプレゼンター（Phase 3 決勝発表者）,
**I want** 6ステップの MACP デモを統合的に演出したい,
**so that** AWS Summit Japan の審査員と来場者に「Continuum と AgentCore の統合の必然性」と「人をダメにするテーマの遅効性ツッコミ」を一気に体験させられる.

### Gherkin

```gherkin
Feature: Demo Set Piece 統合演出

  Scenario: 6 ステップの演出が時系列展開する
    Given デモ用に UserA (Hiroki 模擬) と UserB (Sasaki 模擬) のアカウントが事前準備済み
    When プレゼンが Step 1 から開始する
    Then 各ステップが順次展開する:
      | Step | 内容 |
      | 1. 導入 | UserA が UserB に "明日飲もう" を送る場面 |
      | 2. 検出 | "MACP Negotiation Initiated" のサブトル通知 |
      | 3. 裏舞台 | スプリットスクリーンで両 AI の裏ネゴシエーション可視化 |
      | 4. 表舞台 | 両ユーザーのインボックスに自然な往復メッセージがタイムラプス展開 |
      | 5. 完了 | 両 Productivity Analytics に "Mutual Engagement Maintenance Successful" + "Bilateral Optimization Specialist" バッジ同期表示 |
      | 6. 〆 | ナレーション "Continuum: Where Both Parties Win, By Not Meeting." |

  Scenario: 各ステップの所要時間
    Then 全6ステップが合計 90秒以内に完結する（プレゼン尺の制約）
```

**Persona**: ハッカソンプレゼンター（実装者自身）+ デモ視聴者
**Scope**: **Phase 3 Must**

---

## DS-2: Demo 用ユーザーセットアップ

**As a** デモ準備担当,
**I want** UserA / UserB の2アカウントを事前にセットアップし、両者ともに Lv3 委任期で稼働中、Mock Social Feed に MACP 発動条件を満たすデータが投入された状態にしたい,
**so that** デモ開始時に即座にシナリオが発動できる.

### Gherkin

```gherkin
Feature: Demo Setup

  Scenario: 2アカウント事前準備
    Given デモ準備セッションを開始する
    When seed スクリプト "demo-macp-setup.sh" を実行する
    Then UserA / UserB の両アカウントが Cognito に作成される
    And 両者の Phase が Lv3 委任期に設定される
    And UserA のコンタクトに UserB が、UserB のコンタクトに UserA が登録される
    And 両者は互いに Continuum Subscriber Registry にハッシュ登録される
    And 過去応答履歴に "両者ともに会いたくない傾向" を示すサンプルデータが投入される
```

**Persona**: 実装者
**Scope**: **Phase 3 Must**

---

## DS-3: スプリットスクリーン裏舞台演出

**As a** デモ視聴者,
**I want** デモ画面が中央分割され、左に UserA の画面、右に UserB の画面、中央下にエージェント間ネゴシエーションのデバッグログが表示されてほしい,
**so that** 通常は不可視の裏舞台ロジックを瞬時に理解できる.

### Gherkin

```gherkin
Feature: Split-Screen Visualization

  Scenario: スプリットスクリーン UI が起動する
    Given デモモード "macp_demo" でアプリを起動した
    When MACP ネゴシエーションが発動する
    Then 画面が3区分に分割される:
      | 区分 | 内容 |
      | 左半分 | UserA の通常UI（受信ボックス・ダッシュボード）|
      | 右半分 | UserB の通常UI |
      | 下部帯 | "Inter-Agent Negotiation Log" としての JSON メッセージストリーム |
    And ネゴシエーション JSON は両 AI 間で交わされる構造化データ（Mutual Decline Intent / Theater Topic 等）として表示される
```

**Persona**: デモ視聴者
**Scope**: **Phase 3 Must**

---

## DS-4: 締めナレーション・コピー演出

**As a** プレゼンター,
**I want** 最終ステップで "Continuum: Where Both Parties Win, By Not Meeting." のキャッチコピーを画面 + 音声で提示したい,
**so that** デモを真面目なプロダクトサマリで締めくくり、観察者の遅効性ツッコミ（"これは要するに人を駄目にしているのでは？"）を起動する.

### Gherkin

```gherkin
Feature: 締めナレーション

  Scenario: キャッチコピー演出
    Given デモ Step 5 (Outcome Confirmation) が完了している
    When Step 6 へ遷移する
    Then 画面が暗転し、Continuum ロゴ + キャッチコピー "Where Both Parties Win, By Not Meeting." が表示される
    And ナレーション音声 が同フレーズを真面目なトーンで読み上げる
    And BGM はコメディ調ではなく、洗練された SaaS プロダクト動画に典型的な落ち着いたピアノ系
```

**Persona**: デモ視聴者・プレゼンター
**Scope**: **Phase 3 Must**

---

# Persona × Story Mapping

| Story | P1 Hiroki | P2 Asuka | M1 小林 | M2 母 | M3 田中 | M4 三崎 | F1 佐々木 |
|---|---|---|---|---|---|---|---|
| US-1.1 サインアップ | ✅ | ✅ | | | | | |
| US-1.2 ログイン | ✅ | ✅ | | | | | |
| US-1.3 プロファイル設定 | ✅ | ✅ | | | | | |
| US-2.1 コンタクト追加 | ✅ | ✅ | 🎯 | 🎯 | 🎯 | 🎯 | 🎯 |
| US-2.2 Engagement Cadence | ✅ | ✅ | 🎯 | 🎯 | 🎯 | 🎯 | |
| US-2.3 Critical タグ | ✅ | | | 🎯 | | | |
| US-3.1 受信ボックス | ✅ | ✅ | 🎯送信 | 🎯送信 | 🎯送信 | 🎯送信 | 🎯送信 |
| US-3.2 3案生成 | ✅ | ✅ | 🎯 | 🎯 | 🎯 | 🎯 | |
| US-3.3 編集送信(Lv1) | ✅ | ✅ | 🎯 | 🎯 | | | |
| US-3.4 バリエーション生成 | ✅ | ✅ | | | | | |
| US-3.5 Relational Calibration | ✅ | ✅ | 🎯 | 🎯 | 🎯 | 🎯 | |
| US-3.6 送信完了 | ✅ | ✅ | | | | | |
| US-4.1 Signal Extraction | | | 🎯 | | 🎯 | 🎯 | 🎯 |
| US-4.2 Strategic Outreach | ✅ | ✅ | 🎯 | | 🎯 | 🎯 | |
| US-4.3 Heartbeat | | ✅ | | 🎯 | | 🎯 | |
| US-4.4 Conflict Detection | ✅ | ✅ | | | | | |
| US-4.5 Plausibility Eng. | ✅ | ✅ | | | | | |
| US-4.6 Outbound Pre-review | ✅ | ✅ | | | | | |
| US-4.7 Mock Feed Setup | (実装者) | | | | | | |
| US-5.1 Lv1 動作 | ✅ | ✅ | | | | | |
| US-5.2 Lv2 動作 | ✅ | ✅ | | | | | |
| US-5.3 Lv3 Critical | ✅ | | | 🎯 | | | |
| US-5.4 Lv4 自己有効化 | ✅ | ✅ | | | | | |
| US-5.5 Lv5 自動認定 | ✅ | ✅ | | | | | |
| US-5.6 Recommendation | ✅ | ✅ | | | | | |
| US-6.1 KPIカード | ✅ | ✅ | | | | | |
| US-6.2 Maturity Badges | ✅ | ✅ | | | | | |
| US-6.3 Outbound Metrics | ✅ | ✅ | | | | | |
| US-6.4 Days in Nirvana | ✅ | ✅ | | | | | |
| US-7.1 Peer Discovery | | | | | | | 🎯 |
| US-7.2 Negotiation | (内部) | (内部) | | | | | (内部) |
| US-7.3 Theatrical Perf | ✅ | ✅ | | | | | ✅ |
| US-7.4 Outcome Confirm | ✅ | ✅ | | | | | ✅ |
| US-7.5 Failure Handling | (内部) | | | | | | |
| **Demo Set Piece** | | | | | | | |
| DS-1 6 Step Demo | (デモUserA) | | | | | | (デモUserB) |
| DS-2 Demo Setup | (実装者) | | | | | | |
| DS-3 Split-Screen | (デモUserA) | | | | | | (デモUserB) |
| DS-4 Closing Narration | | | | | | | |

**凡例**: ✅ = 主たる利用者 / 🎯 = 操作対象（コンタクト等）/ (内部) = 内部処理（人間ペルソナ非関与）

---

# Phase Scope Summary

> **🔄 SCOPE REVISION 2026-05-08**: Phase Scope Summary を上部の表と整合させた。詳細は `../plans/scope-revision-2026-05-08.md`。

## Phase 2 Must（5/30 予選会 MVP — 必須）

US-1.1 / US-1.2 / US-2.1 / US-2.2 / US-3.1 / US-3.2 / US-3.3 / US-3.4 / US-4.1 / US-4.2 / US-4.7 / US-5.1 / US-5.4 / US-6.1 / US-7.1 (Single-tenant 簡易) — **計15件（うちユーザー操作可能 12 件）**

> **削除/降格**: ~~US-1.3~~（Communication Style 設定 — 完全削除）/ ~~US-5.2 / US-5.3~~（Lv2 / Lv3 — Lv1↔Lv4 集約のため Phase 3 Stretch へ降格）

## Phase 2 Should（5/30 予選会 — 余裕があれば）

US-3.5 / US-4.6 / US-5.6 / US-6.2（**静的画像のみ**）— **計4件**

## Phase 3 Must（6/26 決勝 AWS デプロイ — 必須）

US-2.3 / US-5.5（**Mock 化**）/ US-7.1 (Federated 本実装) / US-7.2 / US-7.3 / US-7.4 / DS-1 / DS-2 / DS-3 / DS-4 — **計10件（DS含む）**

> **降格**: ~~US-4.4 Conflict Detection / US-4.5 Plausibility Engineering / US-6.3 Outbound メトリクス~~ → 削除または Phase 3 Stretch（US-6.3 / US-6.4 削除、US-4.4 / US-4.5 → Stretch）

## Phase 3 Stretch（6/26 決勝 — 任意）

US-4.3 / US-4.4 / US-4.5 / US-5.2 / US-5.3 / US-7.5 — **計6件**

---

# INVEST 準拠チェック

各ストーリーが INVEST 基準を満たしていることを確認：

- **Independent（独立）**: 各ストーリーは原則として他ストーリーとの依存を最小化（ただし Maturity Phase は階層依存があるため US-5.4 → US-5.5 のような並びは必然）
- **Negotiable（交渉可能）**: 受入基準は一例であり、実装時の調整余地を残している
- **Valuable（価値あり）**: 各ストーリーが利用者・ハッカソン審査・デモ訴求のいずれかの価値に直結
- **Estimable（見積可能）**: 中粒度（Feature レベル）に揃え、実装工数の見積が可能
- **Small（小さい）**: 1ストーリー = 1機能単位、複数日実装にならない粒度
- **Testable（テスト可能）**: すべて Gherkin 形式の Given-When-Then を備える

---