TheTree_mock/docs/MVP_ACCEPTANCE_SCENARIOS.md

MVP 14日受入シナリオ

この文書は、System単体テストを通過した実装を「14日遊べるゲーム」として受け入れるための判定契約である。ゲームルールは GAME_SPECIFICATION.md、System不変条件は SYSTEM_SPECIFICATION.md を正本とし、本書は同じ初期状態を分岐して比較するScenario、計測値、合否境界を固定する。

1. 共通実行契約

• Seedは20260827、開始時刻はDay 1 06:00、終了時刻はDay 15 06:00（正味20,160分）とする。
• Simulationは1分を省略せず、通常実行、途中Save再開、同一SnapshotからのA/B分岐で同じCommand列を使う。
• 自動来客は客クラスと種族を別々に決定し、生成済みの複合GuestDefinition IDを保存する。
• Player GoldはEconomy Ledgerだけを正本とし、給与、罰金、建設、売上、返金を日次分類へ一度だけ計上する。
• 各30分境界と、06:00の日次締め・朝処理直後に横断Invariantを検査する。
• 比較Scenarioでは分岐後も、比較対象以外の需要、価格、従業員、Seed、Event入力を同一にする。
• 表示Frame性能はSimulation受入と分離し、同じ論理Snapshotを描画Fixtureへ渡して測る。

2. 共通Fixture

2.1 人口と需要

• 客クラス8種すべてを需要表に含める。
• 種族4種はguest_id + class_id + world_seedから決定的に巡回し、長期偏りを最大1人差に抑える。
• 06:00～10:00をMORNING、10:00～16:00をDAY、16:00～20:00をEVENING、20:00～06:00をNIGHTとして扱う。
• 通常上限は同時客100人、30分境界の新規到着上限は10人とする。
• 夕方は食事・酒場・入浴の合成需要を日中より高くし、経路密度差が観測できる入力に固定する。

2.2 従業員

• 自由雇用候補20人のうち、受付、調理、給仕、清掃、物流、警備、保守を少なくとも1人ずつ雇用する。
• 日勤・夜勤を重複なしで作成し、日給は人物カタログ値を使う。
• 退職者は翌日以降の給与対象から外し、既発生の未払額だけを別債務として保持する。

2.3 施設と経路

• Rank 1開始時は受付、食堂、標準客室、倉庫、厨房、客用通路、従業員待機所を配置する。
• FRONTだけでも到達可能な基準Layoutと、BACKの業務通路を追加した改善Layoutを同一Snapshotから作る。
• 地下営業分岐では酒場、マッサージ室、成人向け個室、警備拠点を段階的に追加する。
• 客用／業務用通路と従業員ドアは完成時に実ROUTE／職員専用Connectorへ投影する。同一階比較でも従業員ドアの権限分離を受入対象に含める。昇降機を必要とする階間比較は、通常隣接Edgeを抑制する垂直Topologyの完成後に別Scenarioへ昇格する。

3. S14-CORE: 14日連続運営

3.1 日程

期間	運営テーマ	必須観測
Day 1～3	合法営業の立上げ	到着、Queue、Service、給与、日次締め
Day 4～6	夕方需要増加	密度、移動時間、待ち時間、離脱
Day 7	中間保存	05:50 Save、06:10 Load、Digest比較
Day 8～10	BACK動線改善	物流と従業員移動のA/B差
Day 11～13	地下営業	追加収益、Heat、監査、対策費
Day 14	終了判定	収支、滞納、関係、全参照整合

3.2 合格条件

1. 20,160分を欠落、二重Tick、クラッシュ、永久停止なしで処理する。
2. 30分を超えて停滞したActorは同じTickで復旧処理へ移り、60分以内に移動再開または理由付き退出へ到達する。
3. Guest、Staff、Path projection、movement credit、Task、Reservation、Service、Event Lock、Ledgerに孤児参照を残さない。
4. 06:00の日次締め・朝処理、60分需要更新、30分到着を各予定時刻につき一度だけ記録する。
5. DaySummaryの分類合計、施設別損益、未払、7日平均がLedgerと再計算一致する。
6. 3回連続支払不能のときだけBANKRUPTとなり、以後の建設・投資・新規到着を停止する。
7. 同一Seed・同一Command列を2回実行した最終Digestが一致する。

4. S14-CONGESTION: 夕方混雑の改善

Day 4 15:30のSnapshotから次へ分岐する。

• A: 施設と通路を変更しない。
• B: ボトルネックを迂回する客用通路を1本追加し、同じ施設数、価格、需要、人員を維持する。

16:00～20:00について、Actorごとの経路要求時刻から到着時刻までをtravel_minutes、Queue参加からService開始までをwait_minutesとして測る。途中退出は上限値に丸めず、別件数として残す。

合格条件:

• Bの客移動P95がAより15%以上短い。
• Bのセル最大密度超過分の累計がAより20%以上少ない。
• BのService完了数がA以上で、経路不能件数は増えない。
• 改善が需要減少やActor間引きによるものではないことを、到着計画ID列の一致で確認する。

5. S14-BACK: FRONT/BACK業務動線

Day 8 06:00のSnapshotから次へ分岐する。

• A: 物流担当と従業員が客用FRONT通路を共用する。
• B: 倉庫、厨房、対象施設をBACK業務通路で接続する。

Day 8～10について測定し、次をすべて満たす。

• Bの物流Request作成から納品までの中央値がAより20%以上短い。
• Bの従業員Task割当から作業開始までのP95がAより15%以上短い。
• Bの客待ち時間P95がA以下である。
• BでもStaff専用EdgeをGuestが利用せず、FRONT/BACKの権限違反が0件である。
• 従業員ドアの完成・撤去を各1回行い、完成時だけStaffにCost 120のFRONT↔BACK経路が存在し、撤去失敗時はROUTEとConnectorの片側だけを残さない。

6. S14-LEGALITY: 合法営業と地下営業

Day 10 06:00のSnapshotから次へ分岐する。

• HEALTHY: 合法施設だけを営業する。
• UNDERGROUND: 地下施設を追加し、同じ基本需要に地下需要を加える。

Day 10～14の比較では、operating_profitを売上－原価－給与－維持－Mana費、risk_adjusted_profitをoperating_profit－罰金－監査対応費－事件復旧費として定義する。

合格条件:

• 対策費計上前のUNDERGROUND operating_profitはHEALTHYより高い。
• UNDERGROUNDのHeatまたはSuspicionがHEALTHYより高く、EvidenceまたはIncidentに追跡可能な発生根拠がある。
• risk_adjusted_profitではUNDERGROUNDが毎回自動的に優位にならず、同一入力で少なくとも1日は差が反転または10%以内へ縮小する。
• 罰金と対策費を重複計上せず、処分resolution IDの再送で金額が変わらない。

7. S14-RELATIONSHIP: 配置リスクの予測

ヒロインとライバルを同じShift・同じ施設へ配置する分岐と、時間または施設を分ける分岐を比較する。

合格条件:

• 配置確定前Previewに、接触予定分数、Shield攻撃候補、発火可能Event、回避案を表示できる。
• 高接触分岐だけでRival BondまたはShield関連候補が増え、その根拠に共有施設と重複時間が含まれる。
• Route Lockは警告を伴う確認Commandなしに確定しない。
• Content FilterがREPLACEまたはDISABLEでも関係値、Cost、Lock、Cooldownの機械的結果は一致する。

8. S14-SAVE: 途中保存とRecovery

• Day 7 23:50に正式Saveし、Day 8 00:10まで進めた最終状態を記録する。
• 23:50からLoadして同じCommand列を再実行し、00:10のClock、Gold、Queue、関係値、Path密度、Operations境界履歴、最終Digestを一致させる。
• checksum-validだがDomain-invalidな正式候補と、Domain-validなbackupを同時に置き、Recoveryがbackupへ自動fallbackすることを確認する。
• 全候補がDomain-invalidなら、Load前のlive state、pause、Content Filterを1フィールドも変更せず失敗する。

9. PERF-DISPLAY: 表示性能

• 論理Fixtureは100客、30従業員、MVP施設16種、FRONT/BACK両層とする。
• 基準PC、解像度1280×720、x1とx4を各5分測定し、最初の30秒をwarm-upとして除外する。
• 平均55fps以上、1% low 45fps以上、入力から表示反映まで100ms以下を合格とする。
• Simulation Tick遅延、描画Frame遅延、Save停止を別々に記録し、平均値だけで瞬間停止を隠さない。

10. 失敗時の記録

失敗レポートには最低限、Seed、Scenario ID、分岐名、絶対分、直前Command ID、境界処理名、関連Entity ID、Invariant code、直前の有効Snapshot digestを含める。自動修復を行った場合は修復対象と根拠を列挙し、Gold、施設、関係Route Lockを推測で作り直して合格扱いにしてはならない。

11. 現時点の自動化状況

tests/mvp/test_runtime_operations_acceptance.gdでは、実Simulation Tickを1,440回進める24時間受入と、20,160分分の運営境界を加速した14日受入を分けている。前者は選択待ちの停止再開、Save復元、Command再送、部分給与、3回連続支払不能、破綻後no-opまで実Tickで確認する。後者は連続実行とDay 7復元のOperations Snapshot／Digest一致を確認する。

14日側はActor AI、Path移動、全Event、監査を20,160回更新するS14-COREそのものではない。第3章の合格を宣言するには、同じFixtureで省略なしの全Runtime Tickを別途完走する必要がある。