## 受入テストケース：なぜシナリオから生成するのか（[/vspec:accept](../../../README.md#commands)）

[English](../../en-US/theory/acceptance.md) | [中文](../../zh-CN/theory/acceptance.md) | [日本語](../../ja-JP/theory/acceptance.md)

受入を「機能チェックリスト」として書くと、現実のリスクを取りこぼしがちです。主経路だけになり、例外/ロールバック/並行/権限/境界条件が抜ける。さらに変更後の回帰範囲が静かに漂流します。

visual-spec が受入ケースをシナリオ駆動で生成するのは、シナリオが実行可能性と検証可能性に必要な構造を自然に持ち、分析からデリバリーまでを 1 本の追跡可能な背骨でつなげられるからです。

### 機能一覧よりシナリオが受入の骨格に向く理由

- シナリオは「実行可能な操作 + 検証可能な期待結果」の組であり、受入ケースの形に直結する
- 分岐を強制的に覆える：例外、ロールバック、並行衝突、権限不足、依存失敗、境界入力など
- 前提条件と状態が明示される：受入の穴は機能名ではなく、状態/権限/データ範囲の曖昧さで起きやすい

### シナリオ駆動が協作コストを下げる

- 共通言語：業務・開発・QA が同じシナリオ集合で「完了」を議論できる
- 追跡可能：各受入ケースが対応シナリオ/機能点へ回指でき、レビュー/回帰/不具合切り分けが速い
- 変更に強い：シナリオや制約が更新されたら、[/vspec:accept](../../../README.md#commands) の再生成で漂流を防げる

### visual-spec ワークフローとの対応

- [/vspec:new](../../../README.md#commands) が flows/scenarios を出し、不確実性を未解決事項として残す
- [/vspec:detail](../../../README.md#commands) が権限/検証/相互作用/ログ/通知などを実装可能粒度に落とす
- [/vspec:accept](../../../README.md#commands) が scenarios + details を構造化受入ケースへ変換（JSON：`/test/验收用例/acceptance_cases.json`）し、`/test/testcase_reader.html` を出力する
- [/vspec:script](../../../README.md#commands) が JSON 用例から Playwright スクリプト骨格を生成（`/test/playwright/`）

### 最小カバレッジ（推奨）

各機能点は最低限、以下を含める：

- 主経路
- 例外/失敗（検証失敗、権限不足、依存失敗、並行衝突）
- 境界（上下限、空/未入力、列挙境界、最大長）
- 権限（RBAC：コントロール単位、データ範囲フィルタ）
