142 lines
9.5 KiB
Markdown
142 lines
9.5 KiB
Markdown
# 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を別途完走する必要がある。
|