Preserve approved pixel tower prototype as development baseline

docs/ARCHITECTURE.md

@@ -0,0 +1,56 @@
+# アーキテクチャ
+
+ゲームルールの正本は [GAME_SPECIFICATION.md](GAME_SPECIFICATION.md)、状態遷移・処理順・不変条件は [SYSTEM_SPECIFICATION.md](SYSTEM_SPECIFICATION.md)、重要な判断理由は [DESIGN_DECISIONS.md](DESIGN_DECISIONS.md) を参照する。本書はその仕様を現在のGodotプロジェクトへ配置するための技術構成を扱う。
+
+## 責務
+
+- `autoload/game_clock.gd`: 1分固定Tick、11段階の処理順、速度変更、一時停止
+- `autoload/game_state.gd`: 非Gold資源とUI向けGoldミラー、世界樹Rankなどの全体状態
+- `autoload/simulation_runtime.gd`: Command、各Service、Domain Event、Snapshotの唯一の実行時配線
+- `autoload/event_bus.gd`: UIとシミュレーション間の疎結合な通知
+- `scripts/core/`: Command Queue、Transaction、決定的RNG、ID、Save、Digest
+- `scripts/world/`、`scripts/construction/`: Cell正本、主要占有と独立した副占有、ROUTEからPathへの原子投影、密度・動的Cost付きPath Graph、Connector Queue、掘削・建築Job
+- `scripts/facility/`: 稼働状態、Queue、Service Slot、サービス境界
+- `scripts/inventory/`: Stack、Reservation、物流Request、Dispatcher
+- `scripts/mana/`: 歩行経路と独立した供給Network、蓄電、停電
+- `scripts/economy/`: Goldの正本となる複式台帳と資源Adapter
+- `scripts/guest/`、`scripts/staff/`: Need/Utility、実経路移動、Shift、Task Dispatcher
+- `scripts/relationship/`、`scripts/events/`: 関係指標、Shield、Route Lock、データ駆動EventとActor Lock
+- `scripts/authority/`: Heat、Incident、Evidence、監査巡回と処分境界
+- `scripts/defense/`: Raid Wave、戦闘参加者、扉・設備・目的物、Active Skill、撤退と結果境界
+- `scripts/operations/`: 06:00営業日締め・朝境界、需要と30分ごとの来客計画、未払・破綻をまとめる14日運営Coordinator
+- `scripts/progression/`: 累計条件、逐次Rank昇格、Map Bounds派生値、World拡張の原子境界
+- `scripts/core/save_service.gd`: 原子的Save、Autosave世代、Checksum検証、Migration/Recovery入口
+- `scripts/core/performance_budget.gd`: Simulation、Path、Save/Loadの診断用性能予算
+- `scripts/data/`、`data/facilities/`、`data/characters/`: MVP施設16種、客8クラス×4種族、雇用候補20人、ユニーク人物の厳密な静的定義境界
+- `scenes/`: 実Worldを表示する運営Dashboardと入力。ゲームルールを直接持たせない
+
+Runtime Snapshot v6はWorldとPathに加え、`excavation`、`spatial_subslots`、`route_projection`、`facility_infrastructure`を独立した正本として保持する。復元時はSpatial、base＋ROUTE、Path、Adapter、Projectorの順に候補を組み立て、全crosslinkが成立してからlive stateへ切り替える。旧v5の通路代理施設はこの候補内で実ROUTEへ移行する。
+
+建設完成は通知を一時保留し、施設登録または通路投影と全crosslinkの検証後にだけ外部signalを確定する。途中で失敗した場合は保留通知を破棄し、Construction、World、Path、Ledger、関連Serviceを直前Snapshotへ戻してSimulationを理由付きで停止する。
+
+## マップ座標
+
+施設の位置は `(x, y, layer)` で扱います。
+
+- `y > 0`: 地上ゾーン
+- `y = 0`: 境界ゾーン
+- `y < 0`: 地下ゾーン
+- `layer = FRONT`: 客が利用する表側
+- `layer = BACK`: 従業員、物流、管理設備が利用する裏側
+
+「地下だがフロントレイヤーにあるカジノ」のような組み合わせは正常です。地下とバックを同義として扱いません。
+
+## 実装する単位
+
+1. S0: 決定的Simulation基盤とAtomic Save
+2. S1: World、A*経路、施設建設
+3. S2: 施設Queue、在庫、物流、Mana、台帳
+4. S3: 欲求ベースの客AI、シフト、Task、疲労
+5. S4: 関係Event、Choice、Cost予約、Content Filter
+6. S5: 行政・監査、Evidence、処分の冪等適用、Wave単位の防衛
+7. S6: 保存世代、Migration、Recovery、性能予算
+
+実装順はSYSTEM_SPECIFICATION.mdの第22章、ゲームとしてのMVP合格条件はGAME_SPECIFICATION.mdの第18章、System TestはSYSTEM_SPECIFICATION.mdの第21章に従う。
+
+各機能は小さなシミュレーションとしてテストを先に用意し、画面から独立して検証できるようにします。

docs/ART_ASSET_PRODUCTION_SPECIFICATION.md

@@ -0,0 +1,271 @@
+# 画像アセット制作・差し替え仕様書
+
+## 1. 目的
+
+この文書は、本作に必要な画像を制作し、安全に差し替えるための正本とする。
+
+**2026-09-09更新：現在のマップは『The Tower SP』を参考にしたドット絵の断面表示を採用する。** 施設の内装と小さな人物の動きが主役で、Kenney Tiny Dungeon・Tiny Townの16px素材と専用のドット描画を使う。旧生成背景や人物Bustを現在のマップへ戻すための仕様ではない。操作と実装上の制約は [ドット絵表示と見学ガイド](PIXEL_TOWER_VISUALS.md) を参照する。
+
+画像の見た目は差し替え可能だが、ゲームの判定、施設座標、人物ID、保存データへ画像ファイル名やAtlas座標を保存してはならない。ゲーム側は`VisualThemeProfile`の意味IDから画像を取得する。
+
+## 2. 現在のアートディレクション
+
+- 世界樹の正面断面を大きく見せる。受付・客室・食堂などを内装で識別でき、小さな客と従業員の移動・待機・仕事が読める構成とする。
+- 基本素材はKenneyの16×16pxドット絵。Nearestフィルターを使い、通常表示では整数倍率を優先する。高解像度の絵をぼかして縮小した人物をマップの主役にしない。
+- 幹・葉・部屋・家具は同じドット密度と色調で専用描画する。主色は木色・クリーム・濃緑、裏方の補助色は青緑とする。
+- 管理UIは小さく平坦な枠と読みやすい日本語で構成する。建築パレットと運営・雇用の詳細は折りたたみ、初期表示では断面を広く見せる。
+- 素材追加時はまずKenneyを確認する。導入元URL・ライセンスを記録し、同梱Licenseを保存する。導入済み素材は [Kenney素材一覧](../assets/kenney/README.md) を参照する。
+- 参考にするのは断面を眺めて動線を改善する体験と視認性であり、既存作品の画像・キャラクター・ロゴ・固有UIを複製しない。
+- 本変更は表示の変更である。ゲームルール、施設定義、建築判定、経路判定、保存形式を変えない。
+
+### 2.1 旧生成テーマの制作参考
+
+以下のセル画調指定は旧`japanese_fantasy`テーマの背景・高解像度Icon・会話用画像向けに保持する。現在のマップ用16px素材には適用しない。
+
+- 世界観は「世界樹の内部で異世界の宿を営む、日本製ファンタジーRPG風の経営シミュレーション」とする。
+- 海外製ストラテジーの重い写実表現より、輪郭と色面が読みやすい手描きセル画調を優先する。
+- 主色は蜂蜜色の木、クリーム色の漆喰と羊皮紙、深い革色、苔色、古い真鍮とする。
+- 地下は抑えた紫、従業員経路は青緑、危険は赤、注意は琥珀色とする。
+- 成人向け要素は露骨な図像にせず、幕、夜色、宝石、紫照明などで示す。
+- 実在作品の固有キャラクター、ロゴ、UI、装飾パターンを複製しない。
+- 画像内へ文字、数字、ロゴ、透かしを入れない。文字はゲーム側で描画する。
+
+## 3. 技術要件
+
+### 3.1 現在のマップ用ドット素材
+
+| 項目 | 要件 |
+|---|---|
+| 基本素材 | Kenney Tiny Dungeon 1.0 / Tiny Town 1.1 |
+| 保存先 | `assets/kenney/tiny_dungeon/`、`assets/kenney/tiny_town/` |
+| 使用Atlas | 各`Tilemap/tilemap_packed.png`、192×176px、12列×11行 |
+| 1タイル | 16×16px、間隔なし。間隔あり版の17pxピッチと混同しない |
+| 描画 | sRGB・実Alpha PNG、Nearest、Mipmap無効 |
+| 倍率 | 通常は整数倍率。広い世界の全体表示では縮小を許容し、ズームで確認する |
+| 座標単位 | 表示セルは16×24の比率。素材Atlasの16×16とは別に扱う |
+| Theme接続 | `VisualThemeProfile.pixel_dungeon_tiles`、`pixel_town_tiles` |
+| アニメーション | 静止元絵の足・上下動・向きから生成。隣接する別人物を歩行フレームとして循環させない |
+
+Atlasを差し替える場合は`pixel_tower_art.gd`と`world_preview.gd`のタイル割り当ても確認する。世界座標・人物IDには画像座標を混ぜない。
+
+### 3.2 旧生成テーマ・高解像度画像
+
+以下の2048px・4×4・Mipmap指定は旧テーマ用であり、上記のKenney Atlasには適用しない。
+
+| 項目 | 要件 |
+|---|---|
+| 色空間 | sRGB |
+| 形式 | PNG。背景は不透明、Iconと人物は実Alpha透過 |
+| 基準表示 | 1440×810 |
+| 対応出力 | 1280×720、1920×1080、2560×1440、3840×2160 |
+| Atlas推奨寸法 | 2048×2048、4×4、1セル512×512 |
+| Icon余白 | 各セル外周12.5%以上を透明にする |
+| Mipmap | 旧生成テーマの高解像度画像は有効 |
+| 命名 | 小文字kebab-case＋版番号。例：`facility-icons-v3.png` |
+| 禁止 | JPEG、疑似チェッカー背景、セルを跨ぐ影、画像内文字、非整数セル寸法 |
+
+既存Atlasは1254×1254である。正式差し替えでは2048×2048を推奨する。寸法を変えた場合は`visual-theme-v1.tres`内の`AtlasTexture.region`も1セル512×512へ更新する。
+
+Alpha必須画像は画像編集ソフトで確認する。白やチェッカー模様を描いただけの画像は透明画像として受け入れない。
+
+## 4. 旧テーマに保持する生成画像
+
+この章の画像・生成指示は既存`visual-theme-v1.tres`の互換性と旧テーマの制作用に保持する。FRONT/BACKの大きな背景、人物Bust、装飾的なUI Skinは現在のドット絵マップと平坦なUIには使用しない。施設・管理・資源・操作の小さなUI Iconは引き続きTheme参照を利用している。ここでいう「現在」のファイル名は旧テーマ内の参照先を示す。
+
+### 4.1 FRONT表層背景
+
+- 意味ID：`front_world_background`
+- 現在：`assets/themes/japanese_fantasy/world-front-v1.png`
+- 推奨寸法：3840×2160、Alpha不要
+- 用途：中央マップのFRONT背景
+- 構図：正面視点の世界樹宿横断面。中央70%は施設、Grid、人物が重なるため低密度にする。
+- 必須：複数階の水平な木造床、世界樹の幹と枝、玄関、昼の空気感。
+- 禁止：斜め見下ろし、強い遠近、人物、文字、Grid線、完成済み大型家具。
+
+生成指示例：
+
+> 世界樹の内部に建つ異世界の宿。正面視点の16:9横断面、複数の水平な木造階、蜂蜜色の木材、クリーム色の壁、緑の葉、青空。中央70%は経営ゲームの施設・人物・格子を重ねるため低情報量で、床の高さが明確。日本製ファンタジーRPGの暖かな手描きセル画調。人物、UI、文字、ロゴ、透かし、斜め遠近なし。3840×2160。
+
+### 4.2 BACK裏層背景（旧テーマの根域表現）
+
+この背景の根域表現は旧テーマの美術上の構図であり、BACKを地下と同一視するゲームルールではない。地上／境界／地下のゾーンと、客用／裏方のレイヤーは独立する。
+
+- 意味ID：`back_world_background`
+- 現在：`assets/themes/japanese_fantasy/world-back-v1.png`
+- 推奨寸法：3840×2160、Alpha不要
+- 構図：FRONTと同じカメラ・床高の世界樹根域横断面。
+- 必須：太い根、掘削可能な空洞、業務通路、真鍮配管、暖色ランタン、控えめな紫水晶。
+- 禁止：ホラー表現、過度な暗さ、人物、文字、Grid線。
+
+生成指示例：
+
+> 世界樹の地下根域に作られた異世界宿の業務空間。正面視点の16:9横断面、水平な根の床、掘削可能な空洞、真鍮配管、暖色ランタン、抑えた紫水晶。中央70%は施設・人物・格子用に低情報量。表層背景と同じカメラと床高。日本製ファンタジーRPGの手描きセル画調。人物、UI、文字、ロゴ、透かしなし。3840×2160。
+
+### 4.3 施設Icon Atlas
+
+- 意味辞書：`facility_icons`
+- 現在：`facility-icons-v2.png`
+- 推奨：2048×2048、4×4、実Alpha透過
+- 表示：主に24～52px。各セルは施設を象徴する物体を1組だけ中央配置する。
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 受付 | 一般客室 | 大衆食堂 | 倉庫 |
+| 2 | 厨房 | 大浴場 | 従業員待機室 | 警備詰所 |
+| 3 | 酒場 | マッサージ室 | 客用昇降機 | 業務用昇降機 |
+| 4 | 従業員ドア | 客用通路 | 業務用通路 | 成人向け個室 |
+
+生成指示例：
+
+> 2048×2048の正確な4×4透明Atlas。各セル512×512。順序は、受付、一般客室、大衆食堂、倉庫／厨房、大浴場、従業員待機室、警備詰所／酒場、マッサージ室、客用昇降機、業務用昇降機／従業員ドア、客用通路、業務用通路、上品な成人向け個室。日本製ファンタジーRPGの暖かな手描きセル画Icon。外周12.5%以上を透明にし、小サイズでも輪郭が区別できる。文字、枠、人物、露骨な性表現、ロゴ、透かしなし。実Alpha透過。
+
+### 4.3.1 拡張施設Icon Atlas
+
+- 予定ファイル：`facility-expansion-icons-v1.png`
+- 推奨：2048×2048、4×4、実Alpha透過
+- ゲーム側状態：16施設の定義は追加済み。正式Iconと専用Systemが揃うまで通常建築パレットへ出さない。
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 上級客室 | 喫茶ラウンジ | 売店 | 診療所 |
+| 2 | 冒険者窓口 | 地下客室 | 地下貸切浴室 | 地下酒場 |
+| 3 | 闇市取引所 | 地下VIPサロン | 洗濯室 | 魔法冷蔵庫 |
+| 4 | 魔力制御室 | 整備工房 | 従業員宿舎 | 廃棄物処理室 |
+
+生成指示例：
+
+> 2048×2048の正確な4×4透明Atlas。上級客室、喫茶ラウンジ、売店、診療所／冒険者窓口、地下客室、地下貸切浴室、地下酒場／闇市取引所、地下VIPサロン、洗濯室、魔法冷蔵庫／魔力制御室、整備工房、従業員宿舎、廃棄物処理室の順に配置。一般地上施設は蜂蜜色と緑、地下客向け施設は夜色と抑えた紫、BACK施設は青緑と真鍮で区別する。日本製ファンタジーRPGの暖かな手描きセル画Icon。各セル外周12.5%以上を透明にし、16～32pxで識別可能。文字、枠、人物、露骨な性表現、ロゴ、透かしなし。実Alpha透過。
+
+### 4.4 管理・資源・操作Icon Atlas
+
+- 意味辞書：`navigation_icons`、`resource_icons`、`control_icons`
+- 現在：`system-icons-v2.png`
+- 推奨：2048×2048、4×4、実Alpha透過
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 従業員 | 施設・建築 | 商品 | 探索 |
+| 2 | 投資 | 帳簿 | FRONT表層 | BACK裏層 |
+| 3 | Gold | Mana | 資材 | Faith |
+| 4 | 警告 | 回転 | 掘削 | 保存 |
+
+生成指示例：
+
+> 2048×2048の正確な4×4透明Atlas。従業員、施設建築、商品、探索／投資、帳簿、FRONT表層、BACK裏層／金貨、マナ結晶、木材資材、信仰の花／警告ベル、回転矢印、つるはし、巻物への保存。暖色の日本製ファンタジーRPG Icon、統一した光源と線幅、16～32pxでも識別可能。各セル外周12.5%以上を透明にする。文字、セル枠、ロゴ、透かしなし。実Alpha透過。
+
+### 4.5 客・従業員Marker Atlas
+
+- 意味辞書：`guest_actor_markers`、`staff_actor_markers`
+- 現在：`actor-markers-v2.png`
+- 推奨：2048×2048、4×4、実Alpha透過
+- 年齢：全員を外見上も明確な成人として描く。
+- 用途：マップ上の小型Bust。会話Portraitとは分ける。
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 戦士客 | 魔術師客 | 盗賊客 | 聖職者客 |
+| 2 | 貴族客 | 商人客 | 異種族・異邦客 | 外交客 |
+| 3 | 受付・事務 | 料理人 | 清掃・保守 | 運搬人 |
+| 4 | 接客・施術 | 警備 | 酒場担当 | 医療担当 |
+
+生成指示例：
+
+> 2048×2048の正確な4×4透明Atlas。明確に成人の人物Bustを、戦士客、魔術師客、盗賊客、聖職者客／貴族客、商人客、異種族または異邦客、外交客／受付事務、料理人、清掃保守、運搬人／接客施術、警備、酒場担当、医療担当の順に配置。和製ファンタジーRPGの親しみやすい手描きセル画。16～24pxでも役割が色と輪郭で判別できる。全セルで同じ頭身、Bust範囲、光源。文字、枠、未成年、性的強調、露出、ロゴ、透かしなし。実Alpha透過。
+
+### 4.6 UI Skin Atlas
+
+- 意味辞書：`ui_skin_textures`
+- 現在：`ui-skin-v1.png`
+- 推奨：2048×2048、4×4
+- 用途：Nine-patch Panel、Button状態、選択枠、待機Badge、工事・経路・層境界。
+- PanelとButtonは四隅と縁を外周15%以内へ収め、中央60%を均一で伸縮可能にする。
+- 選択枠、警告枠、待機Badgeは実Alpha透過を推奨する。
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 外枠Panel | 木製Panel | 革Panel | 羊皮紙Panel |
+| 2 | Button通常 | Button Hover | Button選択 | Button無効 |
+| 3 | 選択枠 | 警告枠 | 待機Badge | 工事中Texture |
+| 4 | 客用経路Texture | 従業員経路Texture | FRONT境界飾り | BACK境界飾り |
+
+生成指示例：
+
+> 2048×2048の正確な4×4 UI Skin Atlas。外枠Panel、木製Panel、革Panel、羊皮紙Panel／Button通常、明るいHover、緑の選択、彩度を落とした無効／金の選択枠、赤の警告枠、琥珀色の丸い待機Badge、木板の工事中Texture／苔色の客用経路、青緑の従業員経路、木と葉のFRONT境界飾り、紫水晶と根のBACK境界飾り。日本製ファンタジーRPGの手描きUI。各セルは正面視点で独立し、影をセル外へ出さない。PanelとButtonの中央60%は低情報量でNine-patch伸縮可能。文字、数字、人物、施設、ロゴ、透かしなし。
+
+## 5. 次段階で制作する画像
+
+マップ向けには、同じ人物の歩行・待機・清掃・運搬・施設利用の専用フレームと、横断面に合う家具差分を先に増やす。現在の汎用静止タイルを加工した動きだけで全職種の作業を表現できるとは扱わない。以下のPortrait・一枚絵などの高解像度指定は、それぞれの画面用途に限って使用する。
+
+### 5.1 固有人物Portrait
+
+- 1人物1ファイル、推奨1536×2048、透明PNG。
+- 腰上、正面寄り3/4、視線と光源を統一する。
+- 通常、喜び、困り、怒り、負傷の5表情を同じ構図で制作する。
+- 最初の対象は`heroine_anri`と`rival_rai`。成人であることを明確にする。
+- 表情差分で服、顔、髪型、体格、カメラを変えない。
+
+### 5.2 一般人物会話Portrait
+
+- 客8クラス、従業員8役割群を各1024×1024以上で制作する。
+- Map Markerより情報量を増やすが、固有人物と誤認する固有装飾は避ける。
+
+### 5.3 商品・料理・素材Icon
+
+- 2048×2048の4×4透明Atlasをカテゴリ別に作る。
+- 1セル1品とし、正式な商品IDと順序が確定してから制作する。
+
+### 5.4 状態・需要・技能Icon
+
+- 状態異常、6欲求、4技能、営業状態、清潔、騒音、治安、物流を別Atlasにする。
+- 色だけに依存せず形でも区別する。
+
+### 5.5 Event背景・一枚絵
+
+- 通常Event背景は2560×1440、重要Eventは3840×2160、不透明PNG。
+- UI文字領域を空け、主要人物の顔へButtonや字幕が重ならない構図にする。
+- 成人向け差分は通常版と分離し、Content Filterで安全に置換できるようにする。
+
+### 5.6 Map装飾・Effect
+
+- ランタン、旗、葉、根、煙、湯気、魔法光、工事火花は個別透明PNGまたは等分Sprite Sheetにする。
+- Loop Animationはフレーム数、FPS、再生順を同名の`.md`へ記録する。
+- 装飾はCell境界と当たり判定へ影響させない。
+
+### 5.7 Title・Loading・Save
+
+- Title背景とLoading背景：3840×2160、文字なし。
+- Logo：横長透明PNG、推奨2048×1024。日本語題字は最終的に人手で確定する。
+- Save Thumbnailは実画面から生成するため固定画像を作らない。
+
+## 6. 差し替え手順
+
+1. 元ファイルを上書きせず、`-v2`、`-v3`のような新しい名前で置く。
+2. 解像度、Alpha、Atlas行列、余白を確認する。
+3. GodotへImportする。マップ用ドット素材はNearest・Mipmap無効、旧生成テーマの高解像度画像はMipmap有効にする。
+4. `visual-theme-v1.tres`を複製するか、新画像への参照だけを更新する。
+5. Atlas寸法を変更した場合は該当する`AtlasTexture.region`またはドット描画のタイル割り当てを更新する。
+6. 720p、基準解像度、1080p、1440p、4Kで確認する。
+7. 文字の可読性、Button状態、人物と施設の識別、Gridとの重なりを確認する。
+8. `make test-pixel-ui`でズーム・移動後の施設クリックと座標対応を確認し、`make capture-pixel`の時間差画像で人物と室内の重なりを確認する。
+9. Theme画像を一時的に空へした場合の不足表示を確認する。Kenney Atlasを外すと現在の人物は表示されないため、納品Themeでは両Atlas参照を必須とする。
+
+## 7. 納品時チェックリスト
+
+- [ ] 指定寸法とsRGBになっている。
+- [ ] 必要な画像は実Alpha透過である。
+- [ ] Atlasが対象の規格（現在のKenneyは12×11、旧生成テーマは4×4）に合い、セル寸法が整数である。
+- [ ] 行・列の順序がこの文書と一致する。
+- [ ] 影や装飾が隣のセルへ越境していない。
+- [ ] 誤った文字、数字、ロゴ、透かしがない。
+- [ ] 16～24pxでもIconと人物の役割を判別できる。
+- [ ] 旧テーマのNine-patchを制作する場合、Panel中央を伸ばしても不自然にならない。
+- [ ] FRONTとBACKが色だけでなく形と素材でも区別できる。
+- [ ] 成人人物が未成年に見えない。
+- [ ] 720pと4Kの両方で輪郭が破綻しない。
+- [ ] 既存作品の固有意匠を複製していない。
+
+## 8. 旧生成テーマ用の画像生成指示
+
+以下はセル画調の旧テーマ用である。現在のマップ素材を依頼するときは「16px基準のドット絵、正面断面、統一したピクセル密度、実Alpha透過、文字なし、歩行差分でも同じ人物を維持」と指定し、完成後に16px表示で人手確認する。
+
+> Production-ready game asset for a Japanese fantasy inn-management simulation. Warm hand-painted cel-shaded RPG style, strong small-size readability, consistent light source and perspective, no text, no letters, no numerals, no logos, no trademarks, no watermark. Keep all required empty areas low-detail. For transparent assets, output genuine alpha transparency rather than a painted checkerboard.

docs/DESIGN_DECISIONS.md

@@ -0,0 +1,229 @@
+# 設計判断記録
+
+本書はGAME_SPECIFICATION.mdで採用した重要判断と、その理由を記録する。過去案へ戻す場合は、影響範囲を確認して新しい判断を追記する。
+
+## D-001 地上／地下とFRONT／BACKを別軸にする
+
+- 状態: 採用
+- 判断: Y軸のゾーンと、奥行きの業務レイヤーを完全に分離する。
+- 理由: 旧文書では「表」が合法地上と客用空間の両方を指し、地下カジノが表施設なのか裏施設なのか判断できなかった。
+- 影響: 施設はzoneとlayerを必ず別フィールドで持つ。
+
+## D-002 主人公を従業員ユニットにしない
+
+- 状態: 採用
+- 判断: 主人公は一施設へ現場介入できる経営者として扱い、スタッフ枠を占有しない。
+- 理由: 神視点の間接操作と「主人公を同室配置」の記述が矛盾していたため。
+- 影響: 移動時間、個人行動ポイント、主人公能力値が必要になる。
+
+## D-003 標準速度の1日を現実12分にする
+
+- 状態: 採用
+- 判断: 現実30秒をゲーム内1時間とする。
+- 理由: 旧案の1日4分では、夕方ラッシュ、通知、シフト、関係イベントへ対応する時間が不足する。高速化はx2とx4で提供する。
+- 影響: 試作GameClockと操作UIを30秒／時間、x1／x2／x4へ同期済み。
+
+## D-004 通貨は一つ、違法性はHeatで表現する
+
+- 状態: 採用
+- 判断: 表金と裏金を分けない。
+- 理由: 二重残高と資金洗浄はUI負荷が高く、建築と動線の中心体験を薄める。違法収益の代償はHeatで十分に表現できる。
+- 影響: 違法サービスは収益と同時にHeatを発生させる。
+
+## D-005 風紀度と全館清潔度を廃止する
+
+- 状態: 採用
+- 判断: 風紀度をReputation、Heat、局所治安へ分け、清潔度はセル単位にする。
+- 理由: 一つの全体値が、客層、犯罪、衛生、監査を同時に動かしており原因が読めなかった。
+- 影響: レポートでは局所値の集計を表示するが、ゲーム判定は可能な限り現場値を使う。
+
+## D-006 破産結果を性別で分けない
+
+- 状態: 採用
+- 判断: 暴動、逃走、装備精算、契約化を性格、戦闘力、信用、ポリシーで決める。
+- 理由: 性別固定は客AIとして不自然で、プレイヤーが結果を予測・操作できない。
+- 影響: 性別は外見、好み、成人関係、妊娠可否など必要な箇所だけに用いる。
+
+## D-007 自由雇用者は売却できない
+
+- 状態: 採用
+- 判断: 契約移転の対象は、成人隷属契約など明示状態を持つユニットだけとする。
+- 理由: 旧文書内で一般従業員の売却可否が矛盾していた。
+- 影響: 雇用区分と契約状態をデータで明確に分ける。
+
+## D-008 愛の盾を好感度と別保存する
+
+- 状態: 採用
+- 判断: Shield MaxはAffectionから算出し、現在Shieldは別値として攻防に使う。
+- 理由: 好感度そのものを攻撃で減らすと、長期関係と短期防御の意味が混ざる。
+- 影響: Shieldは時間だけでは減らず、接触イベントでのみ損耗する。
+
+## D-009 重要ルートは閾値だけで確定させない
+
+- 状態: 採用
+- 判断: 50と80の境界では明示イベントとプレイヤーへの予告を要求する。
+- 理由: 見ていない場所の自動計算だけで取り返しのつかない結果になると、経営判断ではなく不意打ちになる。
+- 影響: 関係状態は数値とイベントフラグの両方を持つ。
+
+## D-010 決闘勝利で関係履歴を全消去しない
+
+- 状態: 採用
+- 判断: 勝利効果はRival Bond -20、Shield +30、接近禁止とする。
+- 理由: 一回の勝負で長期進行を0へ戻せると、日常の配置管理が無意味になる。
+- 影響: Rival Bond 80以上は通常決闘では解決できない。
+
+## D-011 ヒロイン一人の離脱を即時ゲームオーバーにしない
+
+- 状態: 採用
+- 判断: 離脱は経営能力と物語分岐の損失として扱う。
+- 理由: 20～30時間の経営ゲームで一人の自動進行が全セーブを終わらせると、実験的な経営を妨げる。
+- 影響: ゲームオーバーは経営破綻、世界樹喪失、明示された最終章へ限定する。
+
+## D-012 CorruptionとRival Bondを独立させる
+
+- 状態: 採用
+- 判断: 禁忌への適応と、特定ライバルへの関係を別軸にする。
+- 理由: 地下勤務を選ぶだけで自動的にNTRへ進むと、地下経営と純愛維持を両立できない。
+- 影響: 高Corruptionかつ高Affectionの忠誠型サブ分岐を許可する。
+
+## D-013 全登場人物の成人条件をデータで保証する
+
+- 状態: 採用
+- 判断: 成人向け行為、成人労働、契約取引に関わる人物は成人確認済みフラグを必須とする。
+- 理由: 世代システムと成人向け要素を同一作品で扱うため、境界を実装上も曖昧にしない必要がある。
+- 影響: 未成年期は非性的な人口データのみ。成人化は明示的な時間経過後に行う。
+
+## D-014 MVPは14日間の垂直スライスにする
+
+- 状態: 採用
+- 判断: Rank 1～3、ヒロイン1人、ライバル1人、100客を対象とする。
+- 理由: 全仕様を薄く作るより、本作固有の二層動線と関係リスクが面白いかを先に検証する。
+- 影響: 世代、大規模戦争、7人分のシナリオはMVP後に実装する。
+
+## D-015 成人向けルートを設定で無効化可能にする
+
+- 状態: 採用
+- 判断: NTR、強制性の強い展開、妊娠などを個別設定する。
+- 理由: プレイヤーの嗜好差が大きく、望まないルートを避ける管理負担をゲーム難易度に含めるべきではない。
+- 影響: 無効化時の代替イベントを必ず用意し、進行不能にしない。
+
+## D-016 1ゲーム分の固定TickとCommand Queueを採用する
+
+- 状態: 採用
+- 判断: Simulationの状態変更は1ゲーム分の固定Tick境界で、順序付けしたCommandを通して行う。
+- 理由: 画面更新速度や入力TimingによってAI、収支、イベント結果が変わると、再現TestとSave復旧が成立しない。
+- 影響: UIは状態を直接変更せずCommandを発行し、同一Tick内の処理順を固定する。
+
+## D-017 人物移動はSoft Collisionにする
+
+- 状態: 採用
+- 判断: 通路Cellを一人だけが占有するHard Reservationではなく、密度を移動Costと速度へ反映する。
+- 理由: 多人数が狭い縦動線へ集中する本作では、Hard Reservationは相互待ちと永久停止を起こしやすい。
+- 影響: 混雑は視覚と効率低下で表現し、施設入口、座席、昇降機だけ明示Slotを予約する。
+
+## D-018 在庫・料金・Service開始を原子的に処理する
+
+- 状態: 採用
+- 判断: 在庫Reservation、料金決済、Service Slot確保、状態遷移を一つのTransactionで確定する。
+- 理由: 途中失敗時にItemだけ消える、料金だけ取る、座席だけ埋まる不整合を防ぐため。
+- 影響: 取消は履歴削除ではなく、Reservation解除と逆取引で表現する。
+
+## D-019 SaveはSnapshot方式を採用する
+
+- 状態: 採用
+- 判断: 全状態Snapshotと短い診断Journalを保存し、完全なEvent Sourcingは採用しない。
+- 理由: 任意時点再生より、通常のSave容量、Load速度、Migrationの理解しやすさを優先する。
+- 影響: 決定性確認用のCommand ReplayはTest機能として持つが、製品Saveの復元方式にはしない。
+
+## D-020 RNGをSystem別Streamへ分離する
+
+- 状態: 採用
+- 判断: 客判断、Event、行政、戦闘、生成を別の決定的RNG Streamで処理する。
+- 理由: 無関係な客が一人増えただけで監査や重要Eventの乱数結果まで変わる連鎖を避けるため。
+- 影響: Seedだけでなく各StreamのStateとCounterをSaveする。
+
+## D-021 監査は監査官の巡回と視認で判定する
+
+- 状態: 採用
+- 判断: 監査発生後の発見は全館一括抽選ではなく、監査官の移動、視線、帳簿、証言、既知証拠で判定する。
+- 理由: FRONT/BACK動線と隠蔽設計を監査対策へ接続し、処罰の理由をプレイヤーが追跡できるようにする。
+- 影響: 監査官はPathServiceを使い、証拠ごとに発見元と位置を保存する。
+
+## D-022 日次の金融締めを00:00、朝の運用境界を06:00に分ける
+
+- 状態: D-031により廃止
+- 判断: 売上・原価・賃金・維持費・未払金の日次締めとDaySummary確定は日付境界の00:00に行う。06:00はシフト交代、個人AP回復、監査抽選、朝Event、その後のAutosaveだけを行う。
+- 理由: 日付と財務期間の境界を一致させ、同じ売上や費用がどの日に属するかを一意にする。同時に、06:00の人物・監査処理と保存を重い金融処理から分離する。
+- 影響: 23:59から00:00で保留Service確定、Ledger照合、未払判定、DaySummaryをこの順で行う。05:59から06:00のTestは財務締めを再実行しないことも検証する。
+
+## D-023 世界樹Rankは1段階ずつ原子的に昇格する
+
+- 状態: 採用
+- 判断: Rankは条件を満たした次段階へだけ上げる。World拡張、Path再構築、GameState、進行履歴を一つの原子的境界として扱う。
+- 理由: デバッグ用の直接Rank指定を製品Commandへ残すと、解禁条件を飛ばせるだけでなく、Map Boundsだけが先に広がる部分適用を起こし得るため。
+- 影響: 累計Faithと累計客を現在値から分離し、昇格Requestを冪等化する。Rollback不能時は自動再試行せず隔離し、保存復旧を要求する。
+
+## D-024 客の欲求を6軸へ統一し、安全・交流を文脈へ分離する
+
+- 状態: 採用
+- 判断: 永続する客欲求はHunger、Sleep、Hygiene、Medical、Leisure、Intimacyの6種だけとする。安全は危険評価と強制行動、交流は好み・同行者・接客・関係Eventの文脈として扱う。
+- 理由: ゲーム仕様の6欲求と実装の旧5欲求が不一致で、Safetyの不安値が負傷・病気、Socialの孤独値が成人向けIntimacyと混同され得た。原因と解決施設が異なる値を同じ軸へ載せると、客の選択理由とバランス調整が読めなくなる。
+- 影響: GuestService SnapshotをVersion 2へ上げる。Version 1だけは`rest→sleep`、`fun→leisure`、`social→intimacy`、`safety→medical`、`hygiene=0`として原子的に移行する。旧名は通常の生成・更新・候補入力では拒否し、Intimacyの時間帯Contextは成人確認済みDefinitionに限定する。
+
+## D-025 境界施設は配置anchorでZoneを判定する
+
+- 状態: 採用
+- 判断: BOUNDARY施設は配置anchorを`y = 0`へ固定し、Footprintが地上側へ広がることを許可する。ただし地下側へのはみ出しは拒否する。ABOVE_GROUND／UNDERGROUND施設は全占有Cellを指定Zone内へ固定する。
+- 理由: 仕様上の受付はFRONT／境界かつ4×2であり、全Cellを`y = 0`へ要求すると正規データの施設が原理的に建設不能になる。一方、地下施設の一部だけを未掘削地上へ逃がす配置は許可できない。
+- 影響: Placement Previewと建設確定は同じZone規則を使い、地下CellにはZoneとは別に全Cell掘削済み条件を適用する。
+
+## D-026 人物配置リスクPreviewは読み取り専用にする
+
+- 状態: 採用
+- 判断: 配置確定前の接触時間、Shield攻撃候補、発火可能Event、Route Lock警告、回避案は、既存状態と提案Shiftから生成する純粋なPreviewとして計算する。Previewだけで関係値やLockを変更しない。
+- 理由: 画面を開いた順序や候補の比較回数で関係進行が変わると、配置判断の再現性が失われる。Route Lockは取り返しのつかない境界なので、予測結果から暗黙確定してはならない。
+- 影響: 接触区間は半開区間のunionで二重計上を防ぎ、同一actor・同一shift IDの提案だけを置換する。Content Filterは表示だけを変え、risk、cost、cooldown、Lockの機械的結果は変えない。
+
+## D-027 採用費と運営費戻しを日次分類で明示する
+
+- 状態: 採用
+- 判断: 契約時の採用費は日給と分離して運営費へ計上し、運営費の戻しは同期間費用の相殺として扱う。相殺超過だけをexpense recovery収益へ振り替える。
+- 理由: 採用費を賃金へ入れるとStaffの日次発生額と二重計上になり、運営費戻しを客向け返金へ入れると符号が逆になる。どちらもunknown categoryのままでは正常な雇用後の日次締めが停止する。
+- 影響: `STAFF_SIGNING_COST→cost_of_goods`、`OPERATING_REFUND→cost_of_goods相殺`を固定し、相殺超過はanomaly付きで`revenue`へ入れる。それ以外の未知categoryはfail-closedを維持する。
+
+## D-028 通路施設は副占有からPathへ投影し、未完成の垂直Topologyを推測しない
+
+- 状態: 採用
+- 判断: 客用通路と業務用通路は主要施設占有と共存する`ROUTE` subslotとして実Pathへ投影する。従業員ドアは職員権限付きFRONT↔BACK Connectorにする。昇降機は、同階隣接Edgeを安全に抑制する垂直Topologyが完成するまで明示的に無変更拒否する。
+- 理由: 通路proxyを主要占有だけで完成扱いにすると、地図には存在しても移動不能になる。一方、現在の平面Graphへ昇降機Connectorだけを足すと、通常隣接Edgeが待ち時間や停止状態を迂回し、運行規則が無効になる。
+- 影響: 建設完成・撤去はProjectorを通してSpatial、Path、Connectorを一つの原子的境界として更新する。未対応昇降機は`UNSUPPORTED_VERTICAL_TOPOLOGY`を返し、どの依存状態も変更しない。
+
+次の実装契約（未実装）:
+
+- `PathService`の通常WALK Edgeは同じ`y`の`x±1`だけとし、`y`が変わる移動は明示Connectorだけに限定する。実A*、到達不能理由の診断探索、復旧地点検索に同じ規則を適用し、別階への暗黙テレポート候補を作らない。
+- 客用／業務用昇降機は回転0度に固定し、同じ`x`・同じFRONT/BACK内の`origin → origin + (0, 1, 0)`を双方向ELEVATOR Connectorにする。全FootprintはROUTEとして各階から乗降点へ到達可能にする。
+- 客用はFRONT、容量4、待機8、1階10分、一般利用。業務用はBACK、容量8、待機16、1階5分、`staff`権限とする。停止・停電中も通常WALKで迂回できてはならない。
+- 待機列、現在階、CabinState、運行状態は`PathService`所有の可変値とし、ProjectorはID、端点、権限、容量、所要時間など不変部分だけを照合する。乗車中または待機中の撤去は無変更拒否する。
+- 保存意味が変わるため、Path v4、Projector v2、Runtime v7として明示移行する。v6に存在し得る未投影の完成昇降機は、v7移行時に安定IDで投影し、片側だけ生成された状態を許可しない。
+- maintenance Mana 5／6を実Consumerへ登録し、Brownout／OUTAGEをConnector運行状態へ同期する。完成・撤去・停電・Save復元はConstruction、World、Spatial、Path、Mana、通知を一つのrollback境界で検証する。
+
+## D-029 境界PauseはTickのhard stopとして扱う
+
+- 状態: 採用
+- 判断: catch-up中の境界失敗、rollback隔離、日次照合待ち、破綻がPauseを要求したら、同一Frameの残りTickと次の時刻加算を止める。境界分までClockが進んだ失敗は、その分の後続段階だけを再開時に1回実行する。
+- 理由: Pause flagだけを立てて既に算出したTick数を走らせると、Coordinatorの保留分とClockがずれ、保存不能になる。Clockを巻き戻すと、先に確定したCommandと通知の時刻が過去へ取り残される。
+- 影響: running中のCommandは到達予定分をeffective minuteとしてClock加算前に確定する。速度変更と手動stepはhard stopを解除せず、再開は専用の確認境界を通す。
+
+## D-030 複数DomainEventは履歴確定後に一括配信する
+
+- 状態: 採用
+- 判断: Transactionが生成したDomainEventは全件を先に検証・履歴Commitし、その後で固定順にSubscriberへ配る。配信中の再入EventはBatch末尾へ送る。
+- 理由: 1件ずつ検証と通知を交互に行うと、後続ID衝突時に先行通知だけが外へ残り、状態rollback後の再試行で二重通知になる。
+- 影響: UIと不可逆な外部処理はService固有signalではなくCommit済みDomainEventまたはTick Snapshotを使う。Batch拒否は履歴・通知とも無変更となる。
+
+## D-031 営業日と日次決算の境界を06:00に統合する
+
+- 状態: 採用
+- 判断: 暦日は00:00に更新する一方、宿の営業日は06:00から翌日05:59までとする。日次決算は翌06:00に行い、その後に昼番開始、個人AP回復、監査抽選、朝Event、Autosaveを処理する。
+- 理由: 夜間の宿泊、酒場、地下営業を途中の00:00で分断せず、一続きの夜営業として同じDaySummaryへ含める。朝昼営業と夜営業の交代時に会計と運営判断をまとめる方が、宿の経営感覚と一致する。
+- 影響: DaySummaryの期間は`Day N 06:00 <= minute < Day N+1 06:00`となる。05:59から06:00の境界では財務締めを最初に一度だけ確定し、失敗時は昼番開始以降を保留する。旧D-022は廃止する。

docs/DEVELOPMENT_PLAN.md

@@ -0,0 +1,149 @@
+# The Tree 全体制作計画
+
+作成日: 2026-09-09  
+基準: The Tower SPを参考にしたドット絵の断面経営ゲーム。ローカル制作版を正本とする。  
+状態: 2026-09-09 ユーザー承認済み。P0の基準点確保とP1の通常営業の最小ループから実施する。
+
+## 1. 目指す体験と計画の前提
+
+プレイヤーが施設と動線を設計し、自律的な客・従業員の営みを観察し、混雑や経営上の問題を改善する。世界樹の地上／地下と、客用FRONT／業務用BACKが、その判断に意味を持つ。小さな人物が動く断面を主画面とし、管理画面は判断に必要なときに開く。
+
+直近の目標を「初見で30分遊べる宿」、次を「14ゲーム日を遊び切れるMVP」、その後を「製品版」とする。既存仕様の本編20～30時間、全要素50時間以上は製品版の設計目標であり、現状の達成実績ではない。序盤の試遊で実際の面白さと進行速度を確かめてから、後半の制作量を見積もる。
+
+仕様の正本は [GAME_SPECIFICATION.md](GAME_SPECIFICATION.md)、状態・保存の規約は [SYSTEM_SPECIFICATION.md](SYSTEM_SPECIFICATION.md)。仕様との相違を修正する際は [DESIGN_DECISIONS.md](DESIGN_DECISIONS.md) に根拠を残す。計画に書いた案を、既存ルールの変更確定として扱わない。
+
+締切・制作人数・専用素材の発注範囲は未指定のため、現時点では暦日の納期を約束しない。P1の通常運営確認とP2の縦移動試作を終えた時点で、実績に基づく作業量・日程を更新する。進捗はファイル数やテスト数だけでなく、各段階の完成条件で判定する。
+
+## 2. 現在地
+
+| 領域 | 確認できていること | 次に埋める差 |
+|---|---|---|
+| 外観・操作 | ドット断面、家具、Kenney人物の簡易歩行、状態表示、コンパクトUI、ズーム・パン | 専用動作、施設ごとの視認性、混雑・稼働の見せ方、実描画性能 |
+| シミュレーション | 時間、建設、在庫・物流、経済、客AI、従業員、イベント、監査、保存の基盤 | 自律厨房生産・補充・配送と通常操作の接続。各Serviceの存在と日常運営の完成を区別 |
+| 縦移動 | Path側にConnector・Queue等の部品が存在 | 階間の通常隣接経路抑制、建設との接続、昇降・乗降、保存復元の統合 |
+| 見学版 | 実施設7件と通路、従業員4人、自然来客が動く | 見学は食材32個を用意した保存なしの再現場面。通常ゲームの完成とは区別 |
+| 運営UI | 建設・掘削・雇用候補・施設情報・イベント選択・手動保存等 | 配属・勤務変更、仕入れ・在庫、価格・営業方針、比較しやすい損益、保存枠等 |
+| 長期検証 | 24時間の統合検証、14日の運営境界比較等は実装記録あり | 全AIを含む20,160分の実Tick、各A/B比較、実描画を伴う負荷確認 |
+| 制作管理 | ローカル版と元Drive版が存在 | 現状GitにHEADがなく制作ファイルが未追跡。作業基準点と復旧手順を確立 |
+
+直前の外観改修では起動確認とUI・カメラの359項目が通過した。この計画作成時に全システムテストを再実行したわけではなく、359項目の結果も14日MVPやWindows性能の合格を意味しない。
+
+[IMPLEMENTATION_STATUS.md](IMPLEMENTATION_STATUS.md) と [PLAYTEST_GUIDE.md](PLAYTEST_GUIDE.md) には旧画面の説明が残っている。現在の外観・操作は [PIXEL_TOWER_VISUALS.md](PIXEL_TOWER_VISUALS.md) を参照し、P0で資料を揃える。
+
+## 3. 段階別の制作計画
+
+| 段階 | 目的・主な成果 | 依存 | 完成条件 |
+|---|---|---|---|
+| P0 制作の基準点 | ローカル正本、Git基準コミット、再現手順、仕様と現状の差分一覧 | なし | 同じ版を復元して起動・試遊でき、優先課題に根拠と確認方法がある |
+| P1 最初の宿を経営 | 通常開始、建設、雇用と配属、厨房・仕入れ・配送、価格、日次収支、保存 | P0。単一階部分はP2と並行可 | デバッグ操作や見学用在庫に頼らず、画面操作だけで3営業日を運営・保存再開できる |
+| P2 上下移動と混雑 | 客用・業務用の基本昇降機、階間経路、乗降と行列、混雑の可視化 | P0 | 3階以上で実乗降し、設備・動線の改善で待ち時間と離脱が減る |
+| P3 暮らしと導入体験 | 歩行・接客・食事・清掃・運搬等の動作、施設美術、音、序盤ガイド、使いやすさ | 素材調査はP0から。完成判定はP1・P2後 | 初見30分で建設・雇用・営業・動線改善を一巡し、人物の行動と問題の理由を理解できる |
+| P4 The Tree固有の判断 | 地下掘削と営業、FRONT/BACK改善、昼夜シフト、Heatと監査、人物関係 | P1・P2。P3と反復 | 合法／地下、表／裏、人物配置の選択に観測できる利点と代償がある |
+| P5 14日MVP | ランク1～3、16施設、人物・客データ、14日シナリオ、調整と受入 | P1～P4 | 既存MVP合格条件とS14実Tick・A/B比較・保存復元・描画性能を満たす |
+| P6 製品版への拡張 | ランク4～7、拡張施設、研究・投資・探索等、物語と結末、正式素材 | P5と試遊評価 | 既存製品仕様の必要機能と本編が通しで遊べ、後半にも新しい判断がある |
+| P7 配布・発売準備 | Windows配布物、設定、セーブ枠、互換性、長期QA、製品情報・素材整理 | 配布試験はP1から。出荷判定はP6後 | クリーンな対象PCで導入・起動・継続でき、出荷を妨げる不具合がない |
+
+最短の依存経路は P0 → P1＋P2 → P3の序盤合格 → P4 → P5 → P6 → P7。アート・音・検証シナリオの準備は、依存するルールが固まったものから並行する。
+
+## 4. 優先タスクと実装単位
+
+### P0：基準点を残す
+
+- **BASE-01** 現行ローカル版の変更一覧・生成物・外部素材ライセンスを確認し、Git初期コミットとバックアップ復旧手順を用意する。元Drive版は照合が終わるまで復旧候補として残す。
+- **BASE-02** 通常開始・見学・テスト・Windows書き出しのコマンドを整理し、現状記録と試遊ガイドをドット版へ更新する。
+- **BASE-03** 「実装済み」「画面へ未接続」「仕様との相違」「未検証」を分けた課題台帳を作る。UIの準備中項目を製品機能の完成として数えない。
+
+### P1：通常プレイで運営を完結させる
+
+- **PLAY-01** 初期資金・資材で成立する序盤手順を検証する。受入用の初期施設一式と通常初期予算の整合を確認し、配置済み施設・初期支給・建設費の扱いを明記する。受付、客室、食堂、厨房、必要な通路と従業員を、通常の建設・雇用コマンドで整える。
+- **PLAY-02** 雇用後の施設配属、再配属、日勤／夜勤、休憩、人員不足の確認を画面から操作できるようにする。
+- **PLAY-03** 仕入れ→倉庫→厨房→接客施設→消費の一巡を確立する。発注費、欠品、容量超過、期限切れ、配送失敗を同じ経営ループで扱う。
+- **PLAY-04** 食堂の消費物と厨房の生産物を仕様・データ・実装で揃える。客の注文を前提としない厨房生産の実行経路を接続する。現状の食材消費と、仕様の料理ポイント／食器の差を調べ、採用方式と移行を設計判断に残す。
+- **PLAY-05** 価格、営業／休業、施設別売上・費用、給与、未払、前日差を操作・比較できるようにする。受付の直接収入の有無、宿泊の入金時点、各施設の価格・所要時間、維持費等の支出・分類も正本と揃える。「お金が減った理由」を確認できるUIを作る。
+- **PLAY-06** 途中保存と再起動後の続行を通常フローに組み込み、建設中・配送中・行列中の状態を検証する。
+
+最初に翌朝までの1営業日を通し、昇降機の実装と並行して仕入れ・生産・配送を広げる。段階全体の完成条件は、見学用コマンドや無料補充を使わず3営業日を続けられ、欠品・人手不足・経路不足に対処できること。黒字にできる基準手順と、改善を怠ると悪化する比較手順を両方残す。
+
+### P2：The Tower SPを参考にした縦移動の核
+
+- **MOVE-01** 同一階の徒歩、垂直接続、FRONT/BACK接続の経路規則を整理する。設備がない階へ隣接セルだけで通れてしまう経路を抑制する。既存の通路・保存との互換方針を先に決める。
+- **MOVE-02** 昇降路・停止階・車両定員・待機要求を扱う最小運行モデルを作り、既存PathのQueue部品へ接続する。最初は基本運行1方式とし、高度な複数方式・ワープはMVP外とする。
+- **MOVE-03** 施設建設・延伸・撤去・客用／業務用の権限を統合する。建てられるが乗れない状態を残さない。
+- **MOVE-04** 待つ→乗る→昇降→降りるを描画する。乗客が徒歩と車内に同時表示されないよう、運行状態に結び付ける。
+- **MOVE-05** 停止・満員・撤去・経路変更・保存途中の乗客を検証する。永久行列、重複乗車、閉じ込めを解消する。
+- **MOVE-06** 同じ需要・施設数・乱数で、移動設備の改善前後を比較する。人物の数を減らさずに待ち時間が改善することを画面と数値で示す。
+
+この段階で、階数を増やすほど移動設計が重要になることを確かめる。移動が面白くなる前に、多数の施設や後半シナリオを量産しない。
+
+### P3：眺める楽しさと初見の遊びやすさ
+
+- **LIFE-01** 歩く／待つ／利用する／眠る／清掃する／運ぶ／休憩するの意味を、実状態と動作一覧で定義する。向き、足元、利用位置、車内表示の基準を固定する。
+- **LIFE-02** 共通人物で専用の歩行・作業フレームを先行制作し、縮小・拡大・混雑で確認してから職種・客層へ展開する。髪色や衣装だけでなく、仕事道具と行動で識別できるようにする。
+- **LIFE-03** MVP26施設を「外形と家具で種類が分かる」「営業・混雑・故障が分かる」という順で仕上げる。世界樹は成長・地下・昼夜による変化を加える。
+- **LIFE-04** Kenneyを優先してUI音・環境音・汎用素材を選び、足りない固有部分を制作する。音量設定を用意し、頻繁な効果音が重ならないよう調整する。
+- **UX-01** 建設可能範囲、費用、接続、必要人員、欠品の案内を揃える。配属・在庫・会計など、日常の判断を少ない操作で行えるようにする。
+- **UX-02** 建築と経営の序盤ガイドを作る。既存のDay 1～5解禁表との整合をとり、説明の再閲覧、スキップ、失敗からの回復を用意する。
+- **UX-03** マウスに加え、トラックパッドや中ボタンのない環境でもパン・ズームできる代替操作を整える。日本語可読性、拡大時のドット、色以外の状態表示を確認する。
+
+完成条件は初見試遊で「建てる→人が来る→困りごとを見つける→改善する」を30分以内に経験できること。操作が分からず止まった箇所と、判断に必要だった情報を記録して改善する。
+
+### P4：地下・裏方・人物関係を結び付ける
+
+- **TREE-01** ランク1→2→3、地下掘削、支え、施設解禁の導線を接続する。地下とBACKを混同しない表示と説明を作る。
+- **TREE-02** 裏方の搬送・厨房・勤務経路を改善すると、表の混雑や接客待ちも改善するよう、同一条件の比較で検証する。
+- **TREE-03** 地下営業の追加収益、Heat、監査予告、対策費を見える形でつなぐ。地上・地下のどちらか一方だけが常に有利になる調整を避ける。
+- **TREE-04** MVPのヒロイン1人・ライバル1人について、配置・同一勤務・接触からイベントが生まれる実接続を完成させる。
+- **TREE-05** 人物配置の事前警告、関係変化の理由、重要分岐の確認、イベント後の復帰を一巡させる。本文・肖像・会話演出は少数イベントで形式を決める。
+- **TREE-06** 成人向けコンテンツの設定と代替イベントを接続し、設定を変更しても14日の進行が途切れないことを確認する。
+
+### P5：14日MVPを合格させる
+
+範囲は既存仕様に合わせる。14ゲーム日、ランク1～3、地上・境界・地下、FRONT/BACK、施設16種、客8クラス×4種族、自由雇用候補20人、同時活動客100人、描画試験の従業員30人、ヒロイン1人とライバル1人、昼夜勤務、清掃・物流・警備・Mana、決算・監査・保存・コンテンツ設定を対象とする。
+
+- **MVP-01** Day 1～3の開業、Day 4～6の混雑、Day 7の保存、Day 8～10のBACK改善、Day 11～13の地下営業、Day 14の結果を通す。
+- **MVP-02** 全AI・イベント・監査・経路移動を含め20,160分を省略せず実行する。途中保存を挟んでも最終状態が一致することを確認する。00:00の暦日境界と06:00の営業日決算境界は、両方を独立した保存再開試験として残す。
+- **MVP-03** [MVP_ACCEPTANCE_SCENARIOS.md](MVP_ACCEPTANCE_SCENARIOS.md) の混雑・BACK・合法／地下・関係の比較を満たす。特に混雑改善の移動P95 15%以上短縮、BACK物流の中央値20%以上短縮などの既存境界を使う。
+- **MVP-04** 具体的なWindows 11基準機を決め、100客＋30従業員の実描画を計測する。既存受入は1280×720、x1／x4、平均55fps以上・1% low 45fps以上・入力反映100ms以下である。製品仕様の1920×1080で通常60fps・最低30fpsの目標は別に測る。停止時間、保存サイズと日次処理も確認する。シミュレーションのみの負荷試験を描画性能の代用にしない。
+- **MVP-05** 初見プレイヤーが30分以内に「地上／地下」と「FRONT／BACK」の違いを説明でき、14日完走後に自分の改善判断を振り返れるか試遊する。
+
+### P6・P7：製品版を作って配布できる形にする
+
+MVP後、試遊で残った課題と既存の製品仕様を照合して後半を区切る。全体エンディングは仕様§3.1の3種と§3.6の4種で記述が異なるため、台本量を確定する前に整理する。ランク4～7、拡張施設、研究・投資・探索、人物と物語、各結末を、遊べる章またはランク帯ごとに追加する。ヒロイン全員や大量のイベントを一括発注する前に、1人分の実装・文章・アート・QAの制作量を測る。
+
+タイトル画面、ニューゲーム、続きから、設定、手動10枠と自動3世代の保存UI、回復候補の提示、操作説明、クレジットを製品フローへ統合する。Windows書き出し・入力・日本語表示・初回起動・保存先・DPI・低性能GPUの確認は小規模なうちから行い、最終段階で初めて試さない。
+
+仕様の時間倍率から、14日は停止なしのx1で168分、x4で42分になる。本編20～30時間と14日MVPは別の検証単位とし、操作・観察・会話・待ち時間を分けて実測する。後半を単なる資金待ちや同じ建築の反復で引き延ばさない。
+
+販売先、価格、正式タイトル、音声・翻訳、製品用の告知素材は別途決定する。選定した配布先の最新要件は、その時点で確認する。計画作成のために発売日や販売先を推測して固定しない。
+
+## 5. 並行作業と変更の進め方
+
+- **本体実装**は一度に主機能を1つ進める。共有されるRuntime・Path・保存形式の変更は順序を揃えて統合する。
+- **素材制作**は、確定した表示寸法・状態一覧から着手する。Kenney調査、ライセンス記録、共通動作、固有素材の順に進める。
+- **QA・試遊**は実装と並行して確認シナリオを準備する。機能変更では意味のある失敗・再開・保存ケースを確認し、単純な装飾変更に過剰なテストを増やさない。
+- 各作業は「問題・プレイヤーへの変化・依存・担当ファイル・完成条件・確認結果」を残す。レビュー後に小さく統合し、動く基準点を維持する。
+- 大きいMain／WorldPreview／Runtimeは追加する機能の境界に合わせて少しずつ分割する。全体を書き直す作業を前提にしない。
+- 機能追加のたびに、通常開始と見学の両方を確認する。見学だけで動く実装を通常ゲームの完成としない。
+
+## 6. 優先するリスクと対応
+
+| リスク | 対応する段階・方針 |
+|---|---|
+| 上下の通路が昇降機を迂回し、移動設計に意味が出ない | P2で階間経路の規則を先に直す。保存互換と閉じ込め復旧を同じ変更で扱う |
+| 本体には処理があっても画面から使えない | P1の通常開始3日運営を基準に、配属・仕入れ・経営操作を優先する |
+| 仕様と仮データがずれたまま施設を増やす | P1で厨房・食堂の入出力と役割を揃え、安定した型から横展開する |
+| 見た目の完成と長期運営の完成を混同する | 各段階の完成条件、実Tick受入、初見試遊を別々に記録する |
+| ドット表現が増えると描画が重くなる | P3から可視範囲・更新頻度・動作数を計測し、P5でWindows実機の負荷条件を満たす |
+| 施設・人物・文章の量産が先行して修正量が膨らむ | 基本運行1方式、MVP26施設、人物関係1組で先に形式と面白さを確かめる |
+| 旧版を戻せず保存データも読めなくなる | P0の版管理、保存形式変更時の移行、更新前バックアップ、途中再開テスト |
+
+## 7. 次回の着手順
+
+1. **BASE-01～03**：現行版の復元可能な基準点と、実装／画面／仕様の差分を確定する。
+2. **PLAY-01～02、PLAY-05の最小部分**：建てる→雇う・配属する→宿泊の売上→翌朝の給与・決算を、通常画面だけで一巡させる。
+3. **MOVE-01～03**：階間経路を整理し、基本昇降機1基で建設→待機→乗車→移動→降車を接続する。
+4. **PLAY-03～04**：厨房生産・発注・実搬送を、確定した配属と会計へ接続する。ルール確定後の素材・UI部分は縦移動の制作と並行できる。
+5. **MOVE-04～06、PLAY-05～06**：断面アニメーション、混雑改善、停止・撤去・保存再開、3営業日の継続運営を確認する。
+6. **LIFE-01～04、UX-01～03**：専用動作と説明・音・日常操作を整え、初見30分の試遊へ渡す。
+
+最初のレビューは「通常操作だけで初売上と翌朝の決算を迎える宿」。次のレビューは「3階の宿を客が昇降機で往復し、混雑を改善できる場面」とする。機能・見た目・操作を一緒に確かめ、以後の日程と素材制作量を更新する。

docs/FACILITY_DATA_DESIGN.md

@@ -0,0 +1,195 @@
+# 施設詳細データ設計
+
+- 文書ID: DATA-FACILITY-001
+- 版: 0.2.0
+- 状態: 実装基準
+- 最終更新日: 2026-08-27
+
+## 1. 目的と正本範囲
+
+本書は、施設の静的定義、設置後の可変状態、日次・累計統計を分離し、施設追加やバランス変更でセーブデータを壊さないための正本である。ゲームルールは`GAME_SPECIFICATION.md`、実行順と障害時処理は`SYSTEM_SPECIFICATION.md`を優先する。
+
+施設の数値は次の3層へ分ける。
+
+| 層 | 所有者 | 例 | 保存 |
+| --- | --- | --- | --- |
+| Definition | コンテンツ | サイズ、建設費、提供サービス、必要職種 | `.tres`。原則不変 |
+| Instance | セーブデータ | 座標、レベル、耐久、配置職員、行列、現在Policy | Snapshotへ保存 |
+| Statistics | 運営履歴 | 当日売上、処理客数、平均待ち時間、事故数 | 日次締めで集約して保存 |
+
+Definitionへ「現在の汚れ」や「今日の売上」を置かず、Instanceへ表示名や基礎価格を複製しない。実行中サービスだけは開始時の価格、品質、所要時間、PolicyをSnapshotとして保持する。
+
+## 2. Schema Version
+
+| version | 用途 | 検証 |
+| --- | --- | --- |
+| 1 | 既存施設の互換読込 | 従来必須値のみ |
+| 2 | 詳細施設定義 | 本書の詳細項目を厳密検証 |
+
+`definition_schema_version = 2`を宣言した定義は、不足値を暗黙補完しない。古い定義はversion 1のまま読み込めるため、施設を1件ずつ検証して移行できる。versionを上げるだけの一括変換は禁止する。
+
+## 3. FacilityDefinition version 2
+
+### 3.1 識別・分類
+
+| フィールド | 型 | 規則 |
+| --- | --- | --- |
+| `id` | StringName | 小文字snake_case、永続的に変更しない |
+| `display_name` | String | UI表示名 |
+| `description` | String | プレイヤー向け説明 |
+| `category` | StringName | `lodging`、`guest_service`、`production`等 |
+| `service_types` | Array[StringName] | 施設が提供できるサービスID。1件以上 |
+| `default_service_type` | StringName | `service_types`内の既定サービス |
+| `service_profiles` | Dictionary | 全service typeに1対1で対応 |
+| `tags` | Array[StringName] | 検索、隣接、ルール判定用の一意なID |
+
+### 3.2 配置・接続
+
+| フィールド | 規則 |
+| --- | --- |
+| `zone` / `layer` | 地上・境界・地下とFRONT・BACKを別軸で指定 |
+| `footprint` | 未回転状態の幅・高さ。各辺1以上 |
+| `allowed_rotations` | 0/90/180/270の重複なし配列 |
+| `guest_access_offsets` | 客がサービスへ入るFootprint内セル |
+| `staff_access_offsets` | 職員・物流が入るFootprint内セル |
+| `required_connection_tags` | 稼働に必須の通路・ネットワーク種別 |
+| `preferred_adjacency_tags` | 効率や選好の加点候補 |
+| `forbidden_adjacency_tags` | 配置拒否または重大減点となる隣接 |
+
+Access offsetは未回転Footprintの左上を`(0, 0)`として記述し、配置時にoriginとrotationからWorld座標へ変換する。通過設備を除く施設は、客用または職員用Accessを最低1つ持つ。
+
+### 3.3 建設・維持・成長
+
+`construction_cost`はGoldとMaterials、`build_minutes`は工期、`weight_per_cell`は構造負荷を表す。`demolition_refund_percent`は未予約資産に対する標準返却率で、事故・強制撤去補正は実行時に別途適用する。
+
+`max_level`は1～5、`upgrade_costs`はLv1→2から順に正確に`max_level - 1`件を持つ。アップグレード後もDefinitionは変えず、Instanceの`level`とレベル別補正式で性能を求める。
+
+維持費は`maintenance_gold`、Manaは`maintenance_mana`、停電時の配電順は`power_priority`で表す。
+
+### 3.4 人員・営業
+
+`staff_min`未満では新規サービスを開始せず、`staff_max`を超える職員を稼働人員へ数えない。`required_roles`は必要職種、`primary_skill`は品質計算の主技能である。
+
+`opening_schedule`は次の3キーだけを持つ。
+
+| キー | 意味 |
+| --- | --- |
+| `morning` | 06:00の日次境界から始まる朝営業 |
+| `day` | 昼営業 |
+| `night` | 夜営業 |
+
+日次締めは06:00に行い、同じ境界で前夜営業を閉じて朝営業へ切り替える。具体的な時刻帯はClockの正本に従い、Definitionへ時刻を重複保持しない。
+
+### 3.5 Service Profile
+
+各`service_profiles[service_type]`は次の5項目を必須とする。
+
+| 項目 | 型・範囲 | 意味 |
+| --- | --- | --- |
+| `duration_minutes` | int、1以上 | 1回の基礎所要時間 |
+| `base_quality` | int、0～100 | 人員・環境補正前の品質 |
+| `base_price` | int、0以上 | Policy補正前の基礎価格 |
+| `capacity_units` | int、1以上 | 同時処理人数または1バッチの生産単位 |
+| `need_effects` | Dictionary[StringName, int] | 欲求ごとの変化量、各-100～100 |
+
+`need_effects`は負値を欲求不足の解消、正値を悪化として統一する。厨房のような中間生産は、客の欲求を直接変えないため0を指定し、実際の在庫産出は`inventory_outputs`で表す。
+
+例:
+
+```gdscript
+service_types = [&"check_in", &"check_out"]
+default_service_type = &"check_in"
+service_profiles = {
+    &"check_in": {
+        &"duration_minutes": 8,
+        &"base_quality": 60,
+        &"base_price": 20,
+        &"capacity_units": 1,
+        &"need_effects": {&"sleep": 0},
+    },
+    &"check_out": {
+        &"duration_minutes": 6,
+        &"base_quality": 60,
+        &"base_price": 0,
+        &"capacity_units": 1,
+        &"need_effects": {&"sleep": 0},
+    },
+}
+```
+
+旧`base_service_minutes`、`base_quality`、`base_price`、`capacity`はversion 1と現Runtimeの互換入口として当面残す。version 2の新規処理はservice profileを正本とし、移行期間中は既定profileと旧値の差分をテストで監視する。
+
+### 3.6 在庫・環境・リスク
+
+- `inventory_inputs` / `inventory_outputs`: 1サービスまたは1バッチの予約・産出量。
+- `cleanliness_decay_per_service` / `noise_per_service` / `heat_per_service`: 完了時の発生値。
+- `beauty_effect` / `security_effect` / `concealment_effect`: 設置中の環境寄与。
+- `incident_weights`: 事故IDと非負の相対重み。確率そのものではない。
+
+### 3.7 Policy
+
+`policy_schema`はPolicy IDごとに型と既定値を宣言する。
+
+```gdscript
+&"reservation_only": {&"type": &"bool", &"default": true}
+&"price_mode": {&"type": &"enum", &"default": &"standard"}
+&"quality_target": {&"type": &"int", &"default": 55}
+```
+
+現在の必須キーは`type`と`default`で、typeは`bool`、`enum`、`int`のいずれかとする。選択肢、最小・最大、解禁Level、変更猶予は次のSchema拡張で追加し、未知キーを読込側で勝手に解釈しない。
+
+### 3.8 客層・成人向け安全境界
+
+`allowed_guest_tags`と`forbidden_guest_tags`は候補抽出の入口であり、予約・入室・サービス開始の3地点で再検証する。`adult_content = true`の施設は必ず`adult_only`タグと、一般向け表示へ置換できる`content_replacement_id`を持つ。置換先は成人向け施設を参照してはならない。
+
+### 3.9 解禁と統計
+
+`unlock_rank`は1～7、`research_requirements`は全件満足を原則とする。`statistics_keys`は施設固有の収集項目を宣言し、共通の売上・稼働率と分離する。定義に存在しない統計キーをセーブから消さず、旧版履歴として読取専用保持する。
+
+## 4. FacilityInstance
+
+Instanceは最低限、次を持つ。
+
+- 識別: `instance_id`、`definition_id`、`created_at`
+- 配置: `origin`、`rotation`、`occupied_cells`
+- 成長: `level`、`durability`
+- 稼働: `state`、`state_reasons`、`opening_override`
+- 人員: `assigned_staff_by_shift`、`active_staff_ids`
+- 接客: `queue_entries`、`active_services`
+- 運営: `policy_current`、`policy_pending`
+- 資源: `local_inventory_id`
+- 集計: `statistics_today`、`lifetime_statistics`
+
+Instanceは必ず`definition_id`から現行Definitionを引き、Definition変更で処理中サービスが変わらないよう、開始済み`ServiceInstance`だけは算出済みSnapshotを持つ。
+
+## 5. 日次履歴
+
+06:00の日次締めで`statistics_today`から`FacilityDaySummary`を生成する。推奨キーは次の通り。
+
+- `business_date`、`facility_instance_id`、`definition_id`、`level`
+- `open_minutes`、`active_minutes`、`downtime_by_reason`
+- `services_started`、`services_completed`、`services_failed`
+- `guest_processed`、`average_wait_minutes`、`average_quality`
+- `gross_revenue`、`refunds`、`maintenance_cost`、`net_contribution`
+- `inventory_consumed`、`inventory_produced`、`spoilage_quantity`
+- `incidents_by_type`、`heat_generated`
+
+日次履歴は締め後に書換えず、修正は訂正レコードで行う。Definitionのバランス変更後も過去の売上や品質を再計算しない。
+
+## 6. 検証と失敗方針
+
+Definition Registryは起動時に全定義を検証し、致命的エラーの定義を検索・建築候補へ公開しない。エラーはcode、definition ID、resource path、field、messageを持ち、順序を決定的にする。
+
+version 2では、ID形式、Access範囲、Upgrade件数、営業時間キー、Service Profile、Policy型、成人向け置換境界を必須検証する。欠損を0や空配列へ補完して稼働させない。
+
+## 7. 現在の移行状況
+
+| 施設 | version | 詳細化の狙い |
+| --- | --- | --- |
+| 受付 | 2 | 複数サービス、客・職員Access、価格Policy |
+| 厨房 | 2 | BACK生産、入力・出力、バッチ単位 |
+| 成人向け個室 | 2 | 夜営業、客層制限、成人向け置換、リスク |
+| その他MVP 13施設 | 1 | 互換読込中 |
+| 拡張16施設 | 1 | 通常パレット未解放、順次移行 |
+
+次の移行順は、一般客室・食堂・酒場・浴場、倉庫・警備、通路・昇降機、地下拡張施設とする。売上施設を先に移行すると、客AI・価格・在庫の縦断検証を早い段階で固定できる。

docs/FACILITY_LIST.md

@@ -0,0 +1,125 @@
+# 施設一覧・レイヤー分類
+
+## 1. 分類ルール
+
+本作では「地上／地下」と「FRONT／BACK」は別の概念とする。
+
+- **地上／境界／地下**：世界樹内の物理的な高さ。`zone`で制約する。
+- **FRONT**：客が利用・目撃できる営業面。
+- **BACK**：従業員、物流、警備、設備だけが利用する裏面。
+
+したがって、地下にある客向け酒場は「地下・FRONT」、地上にある厨房は「地上・BACK」である。保存データと経路判定では、この2軸を混同しない。
+
+状態記号：
+
+- **実装済**：MVP定義へ登録され、建設・保存・施設Systemから参照可能。
+- **制限あり**：定義済みだが、専用Systemが未完成で一部機能を制限している。
+- **拡張定義済**：追加用データ、数値、配置制約まで定義済み。MVPの既存Saveを守るため通常建築パレットにはまだ出さない。
+
+## 2. 地上層・一般客向けFRONT施設
+
+### 現行MVP
+
+| 施設 | ゾーン | サイズ | 主な役割 | 状態 |
+|---|---|---:|---|---|
+| 受付 | 境界 | 4×2 | チェックイン、精算、来客導線の起点 | 実装済 |
+| 一般客室 | 地上 | 2×1 | 基本宿泊 | 実装済 |
+| 大衆食堂 | 任意 | 4×2 | 低価格の食事、大人数処理 | 実装済 |
+| 大浴場 | 任意 | 6×2 | 清潔・休息需要 | 実装済 |
+| 酒場 | 任意 | 4×2 | 夜営業、飲食、交流 | 実装済 |
+| マッサージ室 | 任意 | 2×1 | 疲労・ストレス回復 | 実装済 |
+| 客用通路 | FRONT | 1セル | 客動線 | 実装済 |
+| 客用昇降機 | FRONT | 2×2 | 客の上下階移動 | 制限あり：垂直Topology待ち |
+
+`任意`の施設は地下FRONTにも設置できるが、成人限定施設ではない。一般客向けとして地上へ置くのが標準運用となる。
+
+### 追加拡張
+
+| 施設 | ゾーン | サイズ | 主な役割 | 追加理由 |
+|---|---|---:|---|---|
+| 上級客室 | 地上 | 3×2 | 富裕客・長期滞在、高単価宿泊 | 客室の価格帯を作る |
+| 喫茶ラウンジ | 地上 | 3×2 | 朝昼の休息、軽食、交流 | 朝昼営業の弱さを補う |
+| 売店 | 境界 | 3×2 | 旅用品、薬、土産販売 | 宿泊以外の客単価を増やす |
+| 診療所 | 任意FRONT | 3×2 | 客・従業員の治療 | Medical需要と負傷回復を接続する |
+| 冒険者窓口 | 境界 | 3×2 | 依頼、探索、護衛、情報 | 宿経営と探索Systemを接続する |
+
+## 3. 地下層・客向けFRONT施設
+
+地下FRONTは、客が利用する営業空間だが、地上一般層より夜間・高単価・限定・裏社会需要が強い。BACKと異なり、客の経路、待機列、満足度、目撃、監査対象になる。
+
+### 現行MVP
+
+| 施設 | ゾーン | サイズ | 主な役割 | 状態 |
+|---|---|---:|---|---|
+| 成人向け個室 | 地下 | 2×1 | 年齢確認済み成人向け予約サービス | 実装済 |
+
+### 追加拡張
+
+| 施設 | ゾーン | サイズ | 主な役割 | リスク・特徴 |
+|---|---|---:|---|---|
+| 地下客室 | 地下 | 2×1 | 夜行性種族、静けさを好む客の宿泊 | 地下一般客の滞在基盤 |
+| 地下貸切浴室 | 地下 | 3×2 | 少人数・高品質の予約入浴 | 高単価、低回転 |
+| 地下酒場 | 地下 | 3×2 | 夜間交流、希少酒、裏社会客 | 警戒と騒音が増えやすい |
+| 闇市取引所 | 地下 | 3×2 | 希少品と高利益取引 | Heat・Suspicion・監査リスク |
+| 地下VIPサロン | 地下 | 4×2 | 成人富裕客向け高級限定サービス | 年齢確認、複数人員、高価格 |
+
+地下貸切浴室と地下客室は成人限定ではない。`adult_only`が付くのは成人向け個室と地下VIPサロンだけとする。
+
+## 4. 裏レイヤー・従業員用BACK施設
+
+BACK施設は客が直接利用せず、FRONT施設の処理能力、清潔、在庫、安全、魔力を支える。地上にも地下にも置ける施設と、地下へ固定する設備を分ける。
+
+### 現行MVP
+
+| 施設 | ゾーン | サイズ | 主な役割 | 状態 |
+|---|---|---:|---|---|
+| 厨房 | 任意BACK | 4×2 | 食材から料理を生産 | 実装済 |
+| 倉庫 | 任意BACK | 4×2 | 食材・資材・装備の保管 | 実装済 |
+| 待機室 | 任意BACK | 4×2 | 従業員の待機と短時間休憩 | 実装済 |
+| 警備詰所 | 任意BACK | 2×2 | 事故・喧嘩・侵入への出動 | 実装済 |
+| 裏通路 | BACK | 1セル | 従業員・物流・救護経路 | 実装済 |
+| 業務用昇降機 | BACK | 3×2 | 人員・物資の上下階搬送 | 制限あり：垂直Topology待ち |
+| 従業員ドア | FRONT↔BACK | 1×1 | 職員限定の層間接続 | 実装済 |
+
+### 追加拡張
+
+| 施設 | ゾーン | サイズ | 主な役割 | 追加理由 |
+|---|---|---:|---|---|
+| 洗濯室 | 任意BACK | 3×2 | 使用済み布類から清潔なリネンを生産 | 客室・浴場の清潔ループを作る |
+| 魔法冷蔵庫 | 任意BACK | 3×2 | 食材保存、期限切れ損失の軽減 | 厨房物流を深くする |
+| 魔力制御室 | 地下BACK | 3×2 | 蓄積、優先配電、Brownout対策 | Mana Networkの中核にする |
+| 整備工房 | 任意BACK | 3×2 | 修理、部品、建築支援 | 耐久・故障Systemを支える |
+| 従業員宿舎 | 地上BACK | 4×2 | 睡眠、長時間休息、夜勤交代 | Shiftと疲労を施設へ接続する |
+| 廃棄物処理室 | 地下BACK | 3×2 | 廃棄物、汚れ、事故リスクの抑制 | 清潔と物流に出口を作る |
+
+## 5. 接続設備の扱い
+
+| 設備 | 接続 | 利用者 | 注意 |
+|---|---|---|---|
+| 客用通路 | FRONT内 | 客、接客中従業員 | 主要占有と共存するROUTE subslot |
+| 裏通路 | BACK内 | 従業員、物流、救護 | 職員専用ROUTE subslot |
+| 従業員ドア | FRONT↔BACK | 従業員 | 同座標の両Layerを結ぶ |
+| 客用昇降機 | FRONTの上下階 | 客、接客中従業員 | 有限Queueと停止時迂回が必要 |
+| 業務用昇降機 | BACKの上下階 | 従業員、物資、救護 | 高容量・高優先の設備 |
+
+## 6. 実装優先順位
+
+1. **診療所、洗濯室、魔法冷蔵庫**：既存のMedical、Inventory、期限、清潔へ接続しやすい。
+2. **上級客室、喫茶ラウンジ、地下客室**：一般経営と朝昼夜の収益差を増やせる。
+3. **魔力制御室、整備工房、従業員宿舎**：Mana、耐久、疲労の運用を深める。
+4. **冒険者窓口**：探索Systemの画面と報酬構造が必要。
+5. **地下酒場、闇市、地下VIPサロン**：Heat、Evidence、監査、成人確認を完全接続してから解放する。
+6. **客用／業務用昇降機**：垂直Topology完成後に建設制限を解除する。
+
+## 7. アセット制作順序
+
+追加施設Iconは2048×2048の別4×4 Atlasとして制作する。並び順は次の通り。
+
+| 行 | 列1 | 列2 | 列3 | 列4 |
+|---|---|---|---|---|
+| 1 | 上級客室 | 喫茶ラウンジ | 売店 | 診療所 |
+| 2 | 冒険者窓口 | 地下客室 | 地下貸切浴室 | 地下酒場 |
+| 3 | 闇市取引所 | 地下VIPサロン | 洗濯室 | 魔法冷蔵庫 |
+| 4 | 魔力制御室 | 整備工房 | 従業員宿舎 | 廃棄物処理室 |
+
+正式Iconがない間は通常建築パレットへ追加しない。既存Iconの流用によって施設を誤認させない。

docs/IMPLEMENTATION_STATUS.md

@@ -0,0 +1,180 @@
+# 実装状況
+
+この文書は仕様書そのものではなく、現在のコードがどこまで到達しているかを記録する。ゲームルールの正本は `GAME_SPECIFICATION.md`、System境界と不変条件の正本は `SYSTEM_SPECIFICATION.md` とする。
+
+## 実装・自動検証済み
+
+### S0: 決定的Simulation基盤
+
+- 1ゲーム分固定Tickと11段階の処理順
+- Command Queue、priority、予約時刻、処理後も保持する受理ID／idempotency対応、旧Queue Snapshot移行
+- 原子的State Transaction
+- subsystem別の決定的RNG Stream
+- Stable ID、全件検証後に一括Commitする再入安全なDomain Event Batch、Simulation Digest
+- Directory単位のAtomic Save、Checksum、backup、Load直後の時刻維持
+- 同一Seed・Command列を24時間再生したDigest一致
+
+### S1: 世界・建設
+
+- `(x, y, layer)` Cell、ZoneとFRONT/BACKの分離
+- Rank 1〜7の非破壊World拡張
+- Occupancy、掘削、構造支持Component
+- 決定的A*、Path Cache、明示Connectorと利用権限
+- セル容量・密度・動的Cost、Soft Collision、混雑回避
+- Cost低下・通行再開時のCache失効、権限別の正確な経路Cost、無関係な障害を除いた不到達理由
+- Elevator稼働状態と有限Queue、Request／Unit二重登録防止、停止時迂回、30分停滞検知と安全復旧候補
+- Placement検証、ConstructionJob、取消、完成、撤去
+- 建設完了通知の保留・確定・破棄境界。完成処理の検証中は外部通知を出さず、成功時だけ順序を保って一度ずつ公開する
+- 硬度別の地下掘削Job、入口までの接続、支保条件、中断再開、FRONT／BACK同時解放
+- 地下施設の全Footprint掘削済み検証と、Zoneを跨ぐFootprintの拒否
+- 境界施設はanchorを境界へ固定し地上側へのFootprint展開を許可、地上／地下施設は全Footprintを指定Zoneへ厳格固定
+- 主要施設占有と独立して同一Cellへ共存できるROUTE／DECORATION／UTILITYの3種subslot、複数Cell横断、Path投影用query、厳密Snapshot
+- ROUTE subslotの追加・置換・撤去とPath graphを原子的に同期し、失敗時の双方復元、revision／stale判定、冪等再送、隔離まで扱うAdapter
+- 完成した客用通路／業務用通路を実ROUTEへ、従業員ドアを職員専用FRONT↔BACK Connectorへ原子的に投影・撤去する境界。安定ID、crosslink、exact rollback、隔離、厳密Snapshotを含む
+- Runtime v6で掘削、subslot、Path投影、施設投影を1分Tick・Rank拡張・建設完了・撤去・Saveへ統合。Runtime v5の旧代理施設を決定的に実ROUTEへ移行する
+- World、Path、Constructionを含むSnapshot往復
+
+### S2: 施設・在庫・物流・Mana・経済
+
+- Facility状態の優先評価と複数reason
+- 営業時間、Policy Snapshot、priority Queue、Capacity Slot
+- Service開始・進行・中断・完了Callback
+- owner別Inventory Stack、FEFO Reservation、期限切れ、監査修復、既定IDの再利用を防ぐTombstone
+- 入力fingerprint付き冪等性、競合する一括操作の事前拒否、全件原子rollback
+- Logistics Request、貨物所有権移転、決定的Dispatcher、候補外になった運搬人の予約積載保持
+- 歩行Graphと独立したMana Network、優先供給、蓄電、Brownout、復旧保持
+- Goldを直接代入しない複式Ledger、逆仕訳、部分返金、日次照合
+- 建設費・撤去返金とLedgerの原子的Adapter
+- 原料予約から施設Serviceと売上記帳までの統合Cycle
+- Cycle途中のSave→Load→再実行でDigest完全一致
+- §7.6のMVP施設16種をStable ID付きDefinitionとして登録・Schema検証
+- 施設詳細Schema version 2を追加。静的Definitionと可変Instance／日次履歴の境界、Access、Upgrade、営業時間、Policy、環境・リスク、客層、解禁、統計、サービス種別ごとの時間・品質・価格・処理単位・欲求効果を定義し、Registryで厳密検証
+- 受付、厨房、成人向け個室を詳細Schemaへ先行移行し、複数接客・BACK生産・夜間成人向け営業の3類型を自動検証。その他MVP 13施設と拡張16施設は互換Schema version 1で段階移行可能
+- MVP互換性を保つ拡張施設16種を`data/facilities/expansion/`へ分離して定義。地上一般向け5種、地下FRONT5種、BACK6種についてZone／Layer、建設費、Footprint、人員、容量、時間、価格、在庫、Risk Tagを固定し、通常建築パレットへの解放前に個別検証できるCatalog境界を追加
+
+### S3: 客・従業員
+
+- 6種のGuest Need（Hunger／Sleep／Hygiene／Medical／Leisure／Intimacy）、Utility、状態遷移、実経路を1セル／分で移動
+- 旧5欲求Saveだけの決定的移行、現行経路での旧Need名・欠落・混在拒否、成人確認付き昼夜Intimacy
+- 所持金と未決済予約を考慮した施設選択
+- Queue、Service、退出、経路失敗の安全な復旧
+- Staffの複数Shift、Task Dispatcher、実移動、疲労と危険作業制約
+- 雇用区分、人物別日給、ID順の日次給与入力、当日発生と繰越債務を分けた部分清算、退職者の未払給与別台帳、旧Saveの互換移行
+- 清算ID／日付／入力fingerprintによる二重発生防止と、派生合計まで照合する給与履歴Snapshot
+- 勤務終了、施設人員喪失、Service猶予と失敗の連動
+- Guest／Staffのnamespaced Path投影、密度同期、固定小数点混雑速度、30分停滞復旧
+- Guest／Staff／Facility／Inventory／Ledgerの24時間決定的再生
+- 破損Snapshotと孤児参照を副作用なしで拒否
+
+### S4: 関係・Event
+
+- Affection、Trust、Fear、Corruption、Rival Bond、Shield
+- Shield攻撃、反復Penalty、段階閾値、Route Lock確認境界
+- データ駆動Condition／Action／Choice
+- foreground Event排他、Actor Lock、Cost escrow
+- Content FilterのFADE／REPLACE／DISABLE
+- 選択二重送信、Actor欠落、Action失敗、Save途中再開の安全な復旧
+- Threshold発火と24時間exact replayのRuntime統合
+- 配置確定前に共有施設・重複時間、Shield攻撃候補、発火可能Event、Route Lock警告、施設／時間の回避案を決定的に比較する読み取り専用Preview
+
+### S5: 行政・監査
+
+- Heat、Suspicion、Incident重複排除、日次減衰とactive-case下限
+- Evidenceの位置、視線、到達、証言、既知施設による発見根拠
+- 監査予告、専用RNG、監査官の実Path巡回、到達不能時の安全退出
+- 証拠点による処分、罰金の複式台帳反映、`resolution_id`二重適用防止
+- Authority全Command、Domain Event、Snapshot、原子的RestoreのRuntime統合
+- 毎日06:00評価、途中Save、24時間exact replay
+- Raid Wave、明示参加者と画面外戦力、扉・設備・目的物のラウンド更新
+- 防衛Score、疲労・奇襲・複数入口、Active Skill、撤退方針、複数Wave
+- Round再送、操作種別付き解決ID、外部効果／RNG rollback、厳密な時刻契約
+- Cancel終了の原子反映、Wave別侵入口、防具軽減、途中Save、JSON輸送、破損Snapshot拒否
+- Defense全10 Command、専用RNG、Skill費用、Staff／Facility損害、Raid排他LockのRuntime統合
+- 終了Raidの履歴化と後続治療／修理、scheduled Command時刻、Runtime v1からDefense付きv2への決定的移行
+
+### S6: 保存・運用の基礎
+
+- 正式Saveを維持する3世代Autosave
+- Checksum付きRecovery候補と明示的Recovery Load
+- N→N+1の連続Migration RegistryとMigration前backup
+- Migration／Autosave回転中断の自己修復とRecovery候補
+- 保存root・親directory・非package・package内symlink越境を全Load入口で拒否するパス安全性
+- 通常Saveのrename中断マーカーと自己復旧、Autosave世代縮小時の検証済み候補だけを安全に整理
+- 安定Save ID、完全Manifest既定値、Thumbnail生成と上書き時のidentity保持
+- 実行画面だけが有効化する本番Autosave policyと、Test／独立Runtimeの保存先分離
+- 毎日06:00の固定境界Checkpoint、3世代回転、手動保存Queue、復旧候補の検査・明示Load
+- Load直後の時刻保持と、壊れたTask／終了Event Lockだけを対象とする原子的なRecovery限定修復
+- 正式、backup、移行前、Autosaveの各候補をRuntime全Domainへ隔離復元し、ゲームとして成立する最初の候補だけを採用する復旧fallback
+- Saveより厳しいContent FilterをLoadで弱めない安全な統合と、不明enumの厳密拒否
+- Simulation、Path、Save、Load、stallの実測付き性能予算Collector
+- PERF-MVP-001の正確なFixtureと24時間Harness。完全条件を3回連続24/24合格（x4 P95 8.14～8.45ms、最大停止予算も合格）。これは独立Service合成の論理負荷であり、Runtime全Domainや実描画Frameの計測とは区別する
+
+### 14日運営Coordinator基盤
+
+- 暦日は00:00に更新し、06:00に前営業日の日次締めと朝運用境界を固定順で一度だけ実行
+- 需要の60分更新と30分ごとの来客計画、fixed-point carry、収容・来客上限
+- DaySummary、前日差、7日移動平均、施設別損益、未払解消と3回連続破綻
+- 外部Domainのcapture／validate／apply／rollback境界、14日間の省略なしexact replay、Snapshot v3と旧版移行
+
+### MVP人物・進行データ境界
+
+- 客8クラスと種族4種を別軸にした32通りの成人確認済みGuestDefinition生成
+- 自由雇用候補20人の固定ID、成人確認、役割、契約費、日給、4技能、許可業務
+- ヒロイン`heroine_anri`とライバル`rival_rai`の相互参照、固有効果、通常売却禁止タグ
+- 不明field／tag、重複ID、成人未確認、18歳未満、孤児参照、型の暗黙変換を全体fail-closedで拒否
+- Rank 1～7の逐次条件、累計Faith／客、地上・地下稼働条件、派生MapBounds、冪等昇格Request
+- World拡張用capture／apply／rollback境界、rollback失敗時の隔離、厳密Snapshot往復
+- 32 Guest定義のRuntime登録、候補雇用時の契約費・日給・Shift・Pathの一括確定、重複雇用防止
+- 累計Faith／累計客の実取引連動、Rank昇格とWorld／Path／GameStateの原子的確定、旧Runtime Rank 1保存の安全な移行
+
+### 操作画面
+
+- V3モックを基準にした暖色の木・革・羊皮紙UI。上部の常設HUD、左の管理カテゴリ、中央の生きたMap、右の施設Inspector、下部の建築パレットへ領域を分離
+- 表層の世界樹宿と地下根域の製品向け背景アセットを導入。背景Texture、UI Palette、重ね描画Opacityを`VisualThemeProfile`へ分離し、Main SceneのTheme指定だけで一括交換可能。Theme欠落時は手続き描画へ安全にFallbackする
+- 施設16種、管理カテゴリ6種、資源4種、表裏層・掘削・回転・保存などの操作アイコンを、実透明の4×4 Atlas Assetとして導入。UIは安定IDから`VisualThemeProfile`の割り当てを取得し、画像名やAtlas座標を直接参照しないため、後からTheme単位または個別割り当てで交換可能
+- 施設Iconを中央Mapの完成施設・建設中施設・配置Previewへも接続。占有CellとHit Testは従来どおりWorldServiceを正とし、Iconは占有範囲中央へ視覚的に重ねるだけなのでSimulationとSave互換性を維持する。選択中の施設／工事は右Inspectorにも同じTheme Iconを表示
+- 客8クラスと従業員8役割群の成人キャラクターMarkerを実透明4×4 Atlasとして導入。客種別／従業員役割の安定IDからTheme割り当てを解決し、派生客種別はクラス接頭辞へ、未知IDは既定MarkerへFallbackする
+- 外枠・木・革・羊皮紙Panel、Button 4状態、選択／警告枠、待機Badge、工事中、客／従業員経路、FRONT／BACK境界装飾を4×4 UI Skin Atlasとして導入。主要Panel、全Button、Map経路、工事中Cell、待機Badgeを意味ID経由で接続し、Theme欠落時は従来のStyleBoxFlat／手続き描画へFallbackする
+- 外部の画像生成AIで正式素材を再制作するための`ART_ASSET_PRODUCTION_SPECIFICATION.md`を追加。現在接続済みの全画像について推奨解像度、Alpha、Atlas順序、生成指示、差し替え手順、納品判定を固定した
+- 1440×810を基準解像度として、`canvas_items`／`expand`／fractional stretchとHiDPIを有効化。背景、施設、共通操作、人物AtlasにはMipmapを生成し、720p・1080p・1440p・4Kで同一UI構造を維持する
+- 上部HUDへ営業日、時刻、時間帯、来客、宿泊予定、所持金、Mana、資材、Faith、Heat、一時停止、x1／x2／x4を常設
+- 実World Cell、占有、工事、施設、Guest、StaffのFRONT／BACK別描画
+- PathServiceの実密度／容量から緑・黄・赤の混雑経路を描画し、FacilityServiceの実待機列をMap上の数字Badgeとして表示
+- 施設選択と状態、reason、待機列、Service、配置人員の表示
+- 仕様表のMVP施設16種を選べる画面下部の横スクロール建設パレット
+- 回転、配置Preview、重なり等の失敗理由、建設Command
+- 掘削モード、正式な費用・入口接続・支保Preview、Rank／運営gate、進捗表示、FRONT／BACK同時解放Command
+- 時間、一時停止、x1／x2／x4、Event、Heat、手動Save／Load
+- 本番運営の明示起動、個人AP、未払給与、前日損益、要確認／破綻状態、失敗境界の再試行表示
+- 検証済み雇用候補20人の一覧。氏名、役割、勤務帯、契約金、日給、4技能を表示し、原子的な雇用Command、未払／破綻gate、二重クリック防止、即時／予約実行結果、Save済みCommand履歴からの再試行連番復元へ追従する
+- foreground Eventの日本語Choiceボタン、安定した選択Command、解決後の停止解除と選択欄消去
+- 1280×720、1440×810、1920×1080、2560×1440、3840×2160で、左Navigation／中央Map／右Inspector／下部Paletteの位置関係を含むLayout自動検証
+
+## 統合済みの運営縦断
+
+- 14日運営CoordinatorをEconomy／Guest／Staff／Facility／Authority／Eventへ接続し、06:00の営業日締め・朝処理、給与、未払、3回連続支払不能による破綻までRuntimeから実行する
+- 人物カタログを使った自動来客・雇用時の日給と、累計客／Faith／稼働施設によるRank条件を日次運営へ接続する
+- 実Simulation Tickによる24時間連続運転、選択待ち停止再開、Save復元、部分給与、破綻後no-opを受入試験で確認する
+- 14日20,160分については運営境界を加速した連続／Day 7復元の一致を確認する。全Actor AIを含む20,160回の実Tick受入とは区別する
+- 掘削と客用通路／業務用通路／従業員ドアをRuntime v6へ統合し、完成失敗時のConstruction・World・Path・通知を一括で戻す
+
+## MVP垂直スライスとして残る範囲
+
+現在は、安全に保存・再生できる「操作可能なSystem縦断」であり、14日MVPの内容完成ではない。次の範囲は引き続き必要となる。
+
+- 全Actor AI、全Event、監査、経路移動を含む20,160分の実TickによるS14-CORE受入
+- ユニーク2人の配置・接触判定と、そこから生成する14日Event列
+- 通常隣接Edgeを安全に抑制する垂直Topologyと、客用／業務用昇降機
+- 配置と同一Shiftから関係Event候補を生成する接触判定と事前リスクPreview
+- 夕方混雑、FRONT／BACK比較、健全／地下収支を直接比較するScenario Test
+- 100客・30従業員の実描画Frame試験
+- 製品用アート、音響、物語本文、完全なチュートリアル、バランス調整
+
+## 実行方法
+
+    make test
+    make check
+    make run
+
+試遊の手順は `PLAYTEST_GUIDE.md`、仕様とTestの対応は `TEST_MATRIX.md` を参照する。各Systemのテストは画面Nodeに依存せずheadlessで実行でき、新しいSystemを追加する際はSnapshot、Atomic Restore、決定性Testを同じ変更に含める。
+14日受入の共通Fixtureと数値境界は `MVP_ACCEPTANCE_SCENARIOS.md` に固定する。

docs/MVP_ACCEPTANCE_SCENARIOS.md

@@ -0,0 +1,141 @@
+# 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を別途完走する必要がある。

docs/PIXEL_TOWER_VISUALS.md

@@ -0,0 +1,57 @@
+# ドット絵表示と見学ガイド
+
+2026-09-09時点。『The Tower SP』を参考に、世界樹の断面・施設の内装・小さな人物の営みを中心に見せる。ゲームルールや通常の新規ゲーム条件は変更していない。
+
+## 起動と確認
+
+ローカル制作フォルダで実行する。
+
+```sh
+make preview-pixel  # 建設済みの宿を操作して眺める
+make capture-pixel  # 時間差の画面2枚と状態JSONを保存
+make test-pixel-ui  # ドット表示・カメラ・実施設クリックの回帰確認
+```
+
+`make run`は通常ゲームを起動する。`make preview-pixel`は、受付・食堂・厨房・客室と上階通路を組み、雇用した従業員と実際の来客で運営する専用見学モードである。起動時に施設の建設と時間進行を行うため、準備に少し時間がかかる。
+
+見学は保存なし。自動保存を無効にし、画面の保存・読込ボタンも無効にする。通常の新規ゲームを完成済みの宿へ置き換えない。見学用の食堂には食材32個を明示的に用意し、通常の在庫処理で消費させる。
+
+キャプチャは`artifacts/pixel-tower/pixel-tower.png`、`pixel-tower-later.png`、`pixel-tower-state.json`を生成する。既定では18ゲーム分を隔てた2枚となり、実際の客・従業員・営業状態をJSONと照合できる。PNG出力には描画可能なデスクトップ環境が必要。
+
+## 操作
+
+| 操作 | 動作 |
+|---|---|
+| ホイール | カーソル付近を基準に拡大・縮小 |
+| 中ボタンドラッグ | 断面を移動 |
+| Home | 全体表示へ戻す |
+| G | 格子と混雑表示を切り替え |
+| B | 建築パレットを開閉 |
+| I | 運営・選択中施設の詳細を開閉 |
+| H | 雇用候補を開閉 |
+| Tab | 客用の表層 / 裏方の裏層を切り替え |
+| E / R | 掘削モード / 建築物を回転 |
+| Space / 1・2・4 | 停止・再開 / 時間倍率を変更 |
+| Esc | 雇用候補・使用中のツールを解除。ツール未使用時はパネルも閉じる |
+| 施設をクリック | 営業・待機列・人員などの実状態を右側に表示 |
+
+初期状態では建築パレットと運営詳細を閉じ、マップを広く見せる。詳細はマップ右側に重ねて開く。判断が必要なイベントは詳細パネルを開き、選択肢を表示する。案内は下部に常時表示する。
+
+## 現在の表示
+
+- 世界樹、空、幹、葉、床と室内をドット主体で描く。受付のカウンター、客室のベッド、食堂の卓、厨房などを施設ごとに描き分ける。
+- Kenneyの[Tiny Dungeon](https://kenney.nl/assets/tiny-dungeon)と[Tiny Town](https://kenney.nl/assets/tiny-town)を人物・小物・庭木に利用する。16×16px素材、Nearest、Mipmap無効で表示する。配布元とCC0ライセンスは[素材一覧](../assets/kenney/README.md)と各パックの`License.txt`に記録している。
+- 客と従業員はRuntime上の実在人物で、移動元と現在セルの間を補間する。同じ元絵の足のずらし・上下動・左右反転で歩行を表現し、待機・利用・作業の小さな状態表示を添える。停止中はアニメーションも止まり、人物位置は確定セルを表示する。
+- UIは濃緑・クリーム・木色の小さな平坦な枠を使用する。従来の高解像度生成背景・人物Bust・装飾Skinは現在のマップに使用しない。小型のUIアイコンは既存Theme参照を残す。
+- ズーム・移動・表示レイヤー・格子の切替は描画側だけで扱う。建築の占有セルや保存データの形式は変えない。
+
+## 制約と次の制作
+
+- Kenneyの導入パックは静止画である。現在の歩行はコードによる元絵の加工であり、手描きの歩行・食事・清掃・運搬の専用アニメーションは今後追加する。Atlasで隣にいる別人物を歩行差分として再生していない。
+- エレベーター本体の昇降・乗降・待ち行列を含む運行は未実装。施設カタログの昇降機は接続の試作用で、見学では既存の上階通路を使って人物の行動を確認する。
+- 見学は在庫を用意した再現用の運営場面であり、収支・配送・混雑の完成度を保証する受入試験ではない。キャプチャにはその時点の実状態が出る。
+- 施設ラベルは表示幅・選択・ホバーに応じて省略する。大きい世界を全体表示すると縮小されるため、人物の動きはズームして確認する。
+
+表示の主な実装は`scenes/main/world_preview.gd`、専用の家具描画は`scripts/ui/pixel_tower_art.gd`、UIは`scenes/main/main.gd`。見学シナリオは`scripts/ui/pixel_tower_demo.gd`、出力処理は`tests/ui/capture_pixel_tower.gd`にある。回帰テスト`tests/ui/test_pixel_tower.gd`は実受付の建設・完工を経由して、ズームと移動後の占有セル命中、表裏の選択、地下を含む座標往復、停止時アニメーション、描画操作前後のシミュレーションダイジェスト不変を確認する。
+
+接客・宿泊サービス中の客は、経路上のアクセスセルから施設内の利用位置へ描画上だけ投影する。経路探索、権威セル、保存状態は変更しない。

docs/PLAYTEST_GUIDE.md

@@ -0,0 +1,58 @@
+# 試遊ガイド
+
+このガイドは、現在のプロトタイプで画面操作とSimulation連動を短時間で確認するためのものです。
+
+## 起動
+
+Godot 4.7系を用意し、プロジェクト直下で次を実行します。
+
+    make editor
+
+Godotが開いたら右上の実行ボタンを押します。エディターを介さず起動する場合は次を使います。
+
+    make run
+
+## 基本操作
+
+| 操作 | マウス／キー |
+|---|---|
+| 施設を選ぶ | 左側の建設パレット |
+| 配置候補を確認・建設 | 地図上へ移動／左クリック |
+| 施設の詳細を表示 | 建設選択を解除して施設を左クリック |
+| 施設を回転 | `R` |
+| 建設選択を解除 | `Esc` |
+| 地下掘削モード | 画面下の「掘削」、または `E` |
+| 雇用候補を開く／閉じる | 左側の「候補を見る」、または `H` |
+| FRONT／BACK切替 | 画面下のボタン、または `Tab` |
+| 一時停止／再開 | 画面下のボタン、または `Space` |
+| 速度変更 | `1`、`2`、`4` |
+| 手動保存／読込 | 画面右下の「保存」「読込」 |
+
+## 最初の確認手順
+
+1. 一時停止した状態で「受付」を選び、中央の境界階へ配置します。
+2. 「一般客室」を地上側、「大衆食堂」を空いているFRONTセルへ配置します。
+3. `4`で時間を進め、工事表示が完成施設へ変わることを確認します。
+4. `Esc`で建設を解除し、完成施設を選びます。営業状態、待機列、サービス数、配置人員が左側へ表示されます。
+5. `Tab`でBACKへ切り替え、「倉庫」を配置します。FRONTとBACKの占有が別管理であることを確認します。
+6. 「保存」を押し、建設や時間を進めてから「読込」を押します。保存時点へ戻れば成功です。
+
+`H`で雇用候補を開くと、20人の氏名、役割、勤務帯、契約金、日給、接客・運営・戦闘・裏社会の技能を比較できます。「雇用する」を押すと契約金が一度だけ支払われ、候補は雇用済み表示へ変わります。時間進行中に押した場合は次のCommand処理で確定し、処理中の二重送信は行いません。未払給与または破綻状態では新しい契約を拒否し、保存後に再起動しても過去の操作IDと衝突せず再試行できます。
+
+世界樹Rank 2へ到達すると「掘削」を選べます。地下の候補へカーソルを合わせると費用、資材、所要時間、入口接続、支保条件を確認でき、クリックするとFRONT／BACKを同時に掘削します。Rank不足や未払給与などで開始できない場合は、理由を画面へ表示します。
+
+建設パレットは上下にスクロールでき、MVP施設16種をすべて選べます。客用通路、業務用通路、従業員ドアは完成時に実際のROUTE／職員専用経路へ変換されます。客用／業務用昇降機は安全な階間経路が未実装のため、現時点では資源を消費せず建設を拒否します。
+
+配置できない場合は、範囲外、ゾーン不一致、レイヤー不一致、重なり、支持不足、資源不足のいずれかが画面へ表示されます。
+
+## 自動検証
+
+全Systemと操作画面の回帰試験:
+
+    make test
+
+エディター読み込みとメイン画面の起動確認:
+
+    make check
+
+現在はSystem実装と操作可能な運営画面を検証する段階です。最終アート、音響、物語コンテンツ、全施設、完全なチュートリアル、製品版バランスは今後の制作範囲です。

docs/TEST_MATRIX.md

@@ -0,0 +1,106 @@
+# 自動テスト対応表
+
+この表は、仕様上の主要な不変条件をどのHeadless Testで検証しているかを示す。ゲームルールの正本ではなく、実装の回帰防止範囲を確認するための索引である。
+
+## 実行
+
+全件:
+
+    make test
+
+段階別:
+
+    make test-s0
+    make test-s1
+    make test-s2
+    make test-s3
+    make test-s4
+    make test-s5
+    make test-s6
+    make test-mvp
+    make test-acceptance
+    make test-ui
+    make test-perf
+    make test-perf-full
+
+構文、Autoload、Main Sceneの読み込み確認:
+
+    make check
+
+## 対応表
+
+| 段階 | Test | 主な検証対象 |
+|---|---|---|
+| S0 | `tests/run_tests.gd` | Clock、GameState、基本Snapshot、Atomic Save |
+| S0 | `tests/s0/test_definition_registry.gd` | Definition Schema、重複ID、参照検証 |
+| S0 | `tests/s0/test_command_transaction.gd` | Command順序、処理後も残る受理ID／冪等Key履歴、旧Snapshot移行、厳密復元、Transaction rollback |
+| S0 | `tests/s0/test_determinism.gd` | 24時間再生、RNG Stream、Digest一致 |
+| S0 | `tests/s0/test_stable_id_generator.gd` | 安定ID、Save/Load後の連番 |
+| S0 | `tests/s0/test_domain_events.gd` | Domain Event順序、再配送境界、Batch全件先行Commit、無変更拒否、再入配信順、配信中Restore拒否 |
+| S0 | `tests/s0/test_runtime_integration.gd` | Runtime Command、Snapshot、復元原子性 |
+| S1 | `tests/s1/test_world_service.gd` | Zone/Layer、Occupancy、支持、Rank拡張 |
+| S1 | `tests/s1/test_path_service.gd` | 決定的A*、権限Edge、Cache失効 |
+| S1 | `tests/s1/test_path_congestion.gd` | 密度Cost、Soft Collision、Cache低下側失効、Connector権限別Cost、Elevator Request一意性、停止時迂回、退場Cleanup、30分停滞 |
+| S1 | `tests/s1/test_construction_service.gd` | Placement、費用、取消、完成、撤去、完成通知の保留／確定／破棄、通知中の再入拒否 |
+| S1 | `tests/s1/test_excavation_service.gd` | 硬度別費用・時間、入口接続、支保、中断再開、二層解放、厳密Snapshot |
+| S1 | `tests/s1/test_spatial_subslot_service.gd` | ROUTE／DECORATION／UTILITY独立共存、複数Cell、crosslink、revision、Path query、外部検証境界、厳密Snapshot |
+| S1 | `tests/s1/test_route_subslot_path_adapter.gd` | base＋ROUTEのPath投影、追加・置換・撤去の原子更新、到達性、revision、隔離、厳密Snapshot |
+| S1 | `tests/s1/test_facility_infrastructure_projector.gd` | 完成した客用／業務用通路と職員扉の実Path投影、利用権限、安定ID、撤去、replay、crosslink、exact rollback、隔離、厳密Snapshot、未対応昇降機の無変更拒否 |
+| S1 | `tests/s1/test_runtime_infrastructure_integration.gd` | Runtime v6、掘削29／30分境界、建設通知順、通路・職員扉完成／撤去、失敗時signalゼロ、Rank拡張、v5代理施設移行、破損Saveの原子的拒否 |
+| S1 | `tests/s1/test_runtime_world_construction.gd` | World/Path/Construction統合とReplay |
+| S2 | `tests/s2/test_facility_service.gd` | 状態優先、Queue、Slot、中断、原子的完了 |
+| S2 | `tests/s2/test_inventory_logistics.gd` | FEFO、Reservation、Cargo所有権、入力fingerprint冪等性、ID Tombstone、Carrier予約負荷、原子Batch |
+| S2 | `tests/s2/test_mana_network_service.gd` | 優先供給、Brownout、蓄電、復旧保持 |
+| S2 | `tests/s2/test_economy_service.gd` | 複式Ledger、冪等取引、逆仕訳、残高監査 |
+| S2 | `tests/s2/test_ledger_backed_resources.gd` | GameState資源とLedgerの原子的Adapter |
+| S2 | `tests/s2/test_runtime_operations_cycle.gd` | 入荷からService売上までの完全Cycle |
+| S3 | `tests/s3/test_guest_service.gd` | SYS-GST-001〜007、6欲求、旧5欲求移行、成人境界、Utility、退出復旧 |
+| S3 | `tests/s3/test_staff_service.gd` | SYS-STF-001〜006、複数Shift、Task原子性、雇用区分、日給、退職者未払台帳 |
+| S3 | `tests/s3/test_staff_payroll_operations.gd` | 当日日給と繰越債務、部分清算、退職後債務、日次冪等性、厳密履歴Snapshot |
+| S3 | `tests/s3/test_runtime_actor_cycle.gd` | Guest/Staff/Facility/Inventory/Ledgerの24時間統合 |
+| S3 | `tests/s3/test_runtime_actor_hardening.gd` | 実移動、残高予約、勤務終了、破損Snapshot拒否 |
+| S3 | `tests/s3/test_runtime_path_traffic.gd` | Guest/StaffのPath密度投影、固定小数点混雑速度、30分停滞復旧、旧Runtime移行、Dispatcher相互照合 |
+| S4 | `tests/s4/test_relationship_event_service.gd` | SYS-REL-001〜004、SYS-EVT-001〜004、限定Lock修復、Content Filter enum厳密復元 |
+| S4 | `tests/s4/test_placement_risk_preview_service.gd` | 同一施設・Shift接触時間、Shield／Event候補、Route Lock警告、Content Filter不変、決定的回避案、fail-closed入力 |
+| S4 | `tests/s4/test_runtime_relationship_events.gd` | Choice pause、Cost escrow、Actor欠落、exact Replay |
+| S5 | `tests/s5/test_authority_service.gd` | SYS-AUT-001〜004、Heat、Evidence、Inspection |
+| S5 | `tests/s5/test_defense_service.gd` | Wave、参加者、扉、設備、目的物、Skill、撤退、Snapshot |
+| S5 | `tests/s5/test_runtime_authority_cycle.gd` | Path/LOS/Ledger/Authority統合とexact Replay |
+| S5 | `tests/s5/test_runtime_defense_cycle.gd` | 全10 Command、専用RNG、Skill費用、Staff／Facility損害、Raid排他Lock、途中Save、原子rollback |
+| S6 | `tests/s6/test_save_operations.gd` | Autosave世代・縮小、Migration、Checksum Recovery、package内symlink拒否、rename中断復旧 |
+| S6 | `tests/s6/test_performance_budget.gd` | x1/x4、Path、Save/Loadの性能予算判定 |
+| S6 | `tests/s6/test_runtime_save_lifecycle.gd` | 06:00日次保存、3世代、Recovery、読込原子性、限定修復、Content Filter統合 |
+| MVP | `tests/mvp/test_operations_coordinator.gd` | 06:00営業日締め・朝境界、需要・自動来客、7日平均、未払・破綻、14日exact replay |
+| MVP | `tests/mvp/test_mvp_content_catalog.gd` | 客8クラス×種族4種、雇用候補20人、ユニーク2人、成人境界、厳密Schema、全体fail-closed |
+| MVP | `tests/mvp/test_progression_service.gd` | Rank 1～7条件、累計値、逐次昇格、原子的World境界、冪等性、rollback隔離、Snapshot |
+| MVP | `tests/mvp/test_runtime_content_progression.gd` | 32 Guest定義、候補雇用・契約費・日給・Shift・Path、未払時の無変更拒否、累計値、Rank拡張、旧Runtime移行、Runtime v6、24時間再生 |
+| MVP | `tests/mvp/test_runtime_operations_integration.gd` | 本番運営の明示有効化、06:00営業日境界、実来客、給与・未払・破綻、Runtime v6、14日運営境界再生 |
+| MVP | `tests/mvp/test_runtime_operations_acceptance.gd` | 実Tick 24時間、選択待ち停止再開、Save・Command再送、部分給与、破綻、破綻後no-op、14日運営境界の連続／Day 7復元一致 |
+| UI | `tests/ui/test_main_dashboard.gd` | 2解像度Layout、本番運営表示、雇用候補20人の表示と即時／予約雇用・二重送信防止・保存済み操作連番復元、座標変換、建設、掘削モード／Preview／Command、施設選択、前景Event Choice、手動Save/Load |
+| PERF | `tests/performance/test_perf_mvp_001.gd` | 独立Service合成の24時間負荷Smoke。`PERF_MVP_FULL=1`で仕様上限の完全Fixture。Runtime全Domain・UI・実描画Frameは別受入 |
+
+## 横断的な合格条件
+
+各System追加時は、少なくとも次を同じ段階のTestへ含める。
+
+- 不正入力を副作用なしで拒否する。
+- 外部境界の途中失敗を原子的に巻き戻す。
+- 同じCommandまたは解決IDを再送しても二重適用しない。
+- Snapshotを完全往復でき、破損Snapshotの拒否が既存状態を変えない。
+- 同一Seed、同一Command列、同一開始Snapshotから同一Digestへ到達する。
+- Actor、Task、Reservation、Queue、Ledger、Event Lockに孤児参照を残さない。
+
+性能Scenarioは機能回帰とは分離して測定する。時間超過時にもTickやEntityを間引いて合格扱いにはしない。
+
+## MVP受入として未完了のScenario
+
+System単体の合格と、ゲームとしてのMVP合格を混同しないため、次は別の受入Scenarioとして追加する。
+数値境界、共通Fixture、A/B分岐条件は `MVP_ACCEPTANCE_SCENARIOS.md` を正本とする。
+
+- 全Actor AI、Event、監査、Path移動を含む20,160回の実Tickで14ゲーム日を完走する。現在の14日自動試験は運営境界を加速しており、実Tick受入の代替にはしていない。
+- 夕方混雑を、施設追加前後と動線改善前後で同一Seed比較する。
+- FRONTだけの動線と適切なBACK動線を、物流時間・従業員移動・客待ち時間で比較する。
+- 健全営業と地下営業を、Heat対策費込みの14日利益で比較する。
+- ヒロイン／ライバルの配置変更前に、接触・Shield・EventリスクPreviewが変化することを確認する。
+- 100客、30従業員を表示した状態で基準PCの実Frame rateを測定する。
+- 初見Playtestで地上／地下とFRONT／BACKの違いを30分以内に説明できるか観察する。

docs/UI_OPERATION_SPECIFICATION.md

@@ -0,0 +1,96 @@
+# UI・操作仕様書
+
+## 1. 目的
+
+メイン画面を離れずに、宿の観察、問題発見、建築、改善までを完結できる経営シミュレーションUIとする。
+
+操作感は、施設配置が人流へ影響し、その結果を画面上の混雑、待機列、稼働率として観察できることを中心に置く。外観は、暖色の木、革、真鍮、羊皮紙を使った日本製ファンタジーSLG調とし、写実的な西洋ストラテジー表現は避ける。
+
+## 2. 画面の固定領域
+
+| 領域 | 常時表示する情報 | 主な操作 |
+|---|---|---|
+| 上部 | 営業日、時刻、時間帯、来客、宿泊、資金、主要資源、評判、警戒 | 停止、通常、2倍、4倍 |
+| 左側 | 従業員、施設、商品、探索、投資、帳簿 | 管理モード切替 |
+| 中央 | 世界樹の断面、施設、客、従業員、経路、待機列 | 選択、建築、追跡、移動、拡大縮小 |
+| 右側 | 選択対象の状態、容量、待機、担当者、清潔、当日売上 | 詳細表示、営業切替、担当変更 |
+| 下部 | 建築カテゴリ、施設カード、費用、占有サイズ | 建築、回転、解体、取消 |
+| 右下 | 現在の目標、重要通知 | 目標詳細、通知位置へ移動 |
+
+中央マップの可視面積を優先し、通常の管理パネルは画面幅の35%を超えて中央を覆わない。
+
+## 3. 基本操作ループ
+
+1. 中央マップで宿の営業を観察する。
+2. 待機人数、赤い経路、警告通知から問題を発見する。
+3. 施設または人物を選び、右側で原因を確認する。
+4. 左側の施設ボタンまたは下部の建築カードから対策を選ぶ。
+5. 半透明の建築予告をマップ上へ直接配置する。
+6. 営業を再開し、待機時間と経路色の変化を確認する。
+
+施設の建築、選択、情報確認のために別画面へ移動させない。人物編成、商品詳細、帳簿など一覧性が必要な機能だけを専用画面または大型パネルにする。
+
+## 4. 建築操作
+
+- 施設カード選択後、カーソル位置に半透明の完成予想を表示する。
+- 建築可能は緑、条件不足は黄、建築不可は赤で示す。
+- 建築不可の場合は、資金不足、接続不足、未掘削、占有衝突などの理由をカーソル付近へ一行表示する。
+- 同種の床、通路、壁、装飾はドラッグによる連続配置を許可する。
+- 右クリックまたはEscで建築を取り消す。
+- 回転後も建築カードの選択状態を維持する。
+- 解体前に対象、返金額、停止する経路を予告する。
+- 人物が利用中の施設は即時消去せず、退避完了後に解体する。
+
+## 5. 観察表示
+
+通常表示では装飾を優先し、問題が起きた場所だけ小さな待機表示を出す。管理表示では次のオーバーレイを切り替えられる。
+
+| 表示 | 色と内容 |
+|---|---|
+| 混雑 | 緑＝快適、黄＝やや混雑、赤＝混雑または通行不能 |
+| 客経路 | 客用通路と主要目的地 |
+| 従業員経路 | 裏通路、搬送経路、勤務先までの移動 |
+| 清潔 | 施設と通路の清潔度ヒートマップ |
+| 騒音 | 発生源と距離減衰 |
+| 治安・警戒 | 犯罪、目撃、監査リスク |
+| 物流 | 倉庫、予約在庫、搬送中の物資 |
+
+待機列は人数だけでなく推定待ち時間を保持する。通常は人数を表示し、選択または警告状態で推定時間を展開する。
+
+## 6. 人物と施設の選択
+
+- 客を選ぶと、現在の目的、行き先、経路、欲求、残り忍耐を表示する。
+- 従業員を選ぶと、勤務先、移動中か勤務中か、疲労、担当、次の休憩を表示する。
+- 施設を選ぶと、営業状態、容量、利用中、待機、担当者、清潔、在庫、当日売上を表示する。
+- 選択対象をもう一度押すと追跡を開始し、中央マップが対象へ緩やかに追従する。
+- 警告通知を押すと原因地点へ移動し、関係する施設または人物を選択する。
+
+## 7. 時間進行と06:00決算
+
+- 時間操作は時計の近くへ置き、停止、通常、2倍、4倍を一操作で切り替える。
+- 重要な選択肢、経営破綻、監査結果など即時判断が必要な場合だけ自動停止する。
+- 06:00に前営業日を締め、夜営業の結果まで含めて決算する。
+- 決算は画面全体を長時間塞がず、まず収入、支出、利益、前日差、警告だけを短く表示する。
+- 詳細帳簿は任意で開く。閉じると朝営業が動いている中央マップへ戻る。
+
+## 8. 視覚ルール
+
+- 上位情報は太い木枠または革タブ、詳細情報は明るい羊皮紙パネルに載せる。
+- 正常は緑、注意は黄、危険は赤、地下固有情報は紫を基本色とする。
+- 小さな数値へ筆文字を使わない。日本語本文と数値は太く読みやすい書体を使う。
+- アイコンには可能な限り日本語ラベルまたはツールチップを併記する。
+- 成人向け施設は露骨な図像を常設せず、紫の照明、幕、宝石、夜の装飾で区別する。
+- 固有作品のボタン、アイコン、キャラクター、画面寸法を複製しない。
+- 背景画像、UI配色、背景とGridの合成率は`VisualThemeProfile`から取得し、Simulation、Save、施設Definitionへ画像Pathを保存しない。
+- 施設、管理カテゴリ、資源、共通操作のIconも`VisualThemeProfile`から安定IDで取得する。Icon Atlasの画像Pathと切り出し位置はTheme資源だけが保持し、Simulation、Save、施設Definitionへ保存しない。
+- Map上の完成施設、建設中施設、配置Preview、および右Inspectorは同じ施設IDのIconを共有する。建設中は暖色半透明、配置可能Previewは緑系半透明、配置不可Previewは赤系半透明とし、占有Cellの状態色と選択枠を隠さない。
+- Map上の客は客クラス、従業員は役割群に対応する成人キャラクターMarkerをThemeから取得する。同一Cellでは決定的な位置ずらしで重なりを軽減し、未登録IDやTheme欠落時も従来の図形MarkerへFallbackする。
+- 主要Panel、Button状態、選択／警告枠、待機Badge、工事中、経路、層境界の外装は`ui_skin_textures`から意味IDで取得する。伸縮PanelとButtonはNine-patchとして描画し、画像がない場合は既存の色・枠・図形へFallbackする。
+- UIの設計基準は1440×810とし、HiDPIと`canvas_items`拡縮で720p、1080p、1440p、4Kへ対応する。横長画面の余白は中央Mapへ配分し、固定領域の最小可読サイズを維持する。Theme TextureはMipmapを生成し、縮小時のちらつきと輪郭崩れを抑える。
+- Theme Textureが未設定または読込不能な場合は、操作不能にせず手続き的な背景色とGridへFallbackする。
+
+## 9. モック基準
+
+実装時の構成基準は `assets/mockups/the-tree-main-gameplay-visual-mock-v3-tower-style.png` とする。
+
+画像内の文字、数値、施設サイズはレイアウト検証用であり、正式なゲームデータは各仕様書とデータ定義を正とする。

docs/data/CHARACTER_CATALOG.md

@@ -0,0 +1,87 @@
+# MVP人物・来客カタログ
+
+この文書は14日MVPで使用する静的な人物データの索引である。ゲームルールの正本は `GAME_SPECIFICATION.md`、機械処理の正本は `SYSTEM_SPECIFICATION.md` とし、実データは `data/characters/` のJSONを正本とする。
+
+## データ境界
+
+- 客クラスと種族は別データとし、8クラス×4種族の32組合せを生成できる。
+- 自由雇用候補20人は固定ID、成人確認済み年齢、役割、日給、契約金、4技能、許可業務を持つ。
+- MVPのユニーク人物はアンリとライの2人とし、相互の`counterpart_id`を必須にする。
+- 全IDは表示名から独立したlowercase snake_caseとする。セーブやイベント参照にはIDだけを使う。
+- JSONはSchema 1として厳密検証する。不明フィールド、不明タグ、重複ID、不足技能、18歳未満、成人未確認、孤児参照が一件でもあればカタログ全体を公開しない。
+- 14日MVPで参照されるID集合は固定する。同数の別IDへ差し替えて既存セーブ・イベント参照をすり替えることも許可しない。
+- JSONは1文書1 MiB、深さ64、10万値までとし、同一Object内の重複KeyはUnicode escape表現を含めて構文解析前に拒否する。検証エラーは最大256件で打ち切りを明示し、不正データによるメモリ増幅を防ぐ。
+- IDは64文字、表示名は80文字までとし、表示名の制御文字、経路の`..`、非有限数、JSONで正確に往復できない巨大数を受け入れない。
+- 倍率は浮動小数ではなくbasis pointで保持する。`10000`が1.00倍、`9000`が0.90倍である。
+- 客クラスの`need_rates`は`hunger`、`sleep`、`hygiene`、`medical`、`leisure`、`intimacy`の6 Keyを必須とする。種族の`need_rate_modifiers`もこの6 Key以外を許可しない。
+- Hygieneは汚れ、Medicalは負傷・病気、Intimacyは成人確認と昼夜Contextで変化させるため、MVP静的データの基礎値は0とする。安全は`risk_tolerance`と候補Risk、交流は選好・GroupFit・関係Eventへ分離する。
+
+## 客クラス8種
+
+| ID | 表示 | 主な需要・判断特性 |
+|---|---|---|
+| `warrior` | 戦士 | 忍耐と危険許容が高く、食事・酒場を優先 |
+| `mage` | 魔法使い | Manaと静かな施設を好み、騒音を忌避 |
+| `rogue` | 盗賊 | 夜・地下を好み、警備を避ける |
+| `cleric` | 聖職者 | 信仰と清潔を重視し、違法・地下への感度が高い |
+| `noble` | 貴族 | 高予算・低忍耐・高品質要求・VIP需要 |
+| `merchant` | 商人 | 交易と価格差を重視 |
+| `outsider` | 亜人・魔族客 | 夜行性傾向と地下嗜好を持つ来客枠 |
+| `diplomat` | 外交官 | 高品質・安全・VIP対応を要求 |
+
+`outsider`は種族そのものではない。たとえば`outsider_human`も生成可能だが、通常の需要構成では獣人・魔族の出現重みを高くする。種族と職業を同一軸に戻さないための互換クラス名である。
+
+## 種族4種
+
+| ID | 表示 | 成人基準 | 主な補正 |
+|---|---|---:|---|
+| `human` | 人間 | 18 | 基準値 |
+| `elf` | エルフ | 20 | Mana・静穏嗜好、忍耐増、危険許容減 |
+| `beastfolk` | 獣人 | 18 | 食事需要、忍耐、危険許容がやや高い |
+| `demonfolk` | 魔族 | 20 | 夜・地下嗜好、危険許容が高い |
+
+種族は所持金、忍耐、危険許容、嗜好、欲求増加率だけを補正する。性別や種族を破産結果、基本能力、成人契約の可否へ直結させない。
+
+## 自由雇用候補20人
+
+| ID | 表示 | 年齢 | 役割 | 希望番 | 日給G |
+|---|---|---:|---|---|---:|
+| `staff_akane` | アカネ | 24 | 受付 | 昼 | 120 |
+| `staff_bardo` | バルド | 38 | 受付 | 夜 | 135 |
+| `staff_chika` | チカ | 27 | 調理 | 昼 | 145 |
+| `staff_doran` | ドラン | 44 | 調理 | 夜 | 160 |
+| `staff_eri` | エリ | 22 | 清掃 | 昼 | 90 |
+| `staff_fugo` | フゴ | 31 | 清掃 | 夜 | 100 |
+| `staff_gina` | ジーナ | 29 | 運搬 | 昼 | 110 |
+| `staff_haru` | ハル | 21 | 運搬 | 夜 | 95 |
+| `staff_iris` | イリス | 26 | 接客 | 昼 | 130 |
+| `staff_juno` | ユノ | 33 | 接客 | 夜 | 140 |
+| `staff_klaus` | クラウス | 36 | 警備 | 昼 | 155 |
+| `staff_lina` | リナ | 30 | 警備 | 夜 | 150 |
+| `staff_marc` | マルク | 41 | 警備 | 任意 | 170 |
+| `staff_nadia` | ナディア | 28 | 酒場 | 夜 | 145 |
+| `staff_otto` | オットー | 35 | 酒場 | 夜 | 150 |
+| `staff_petra` | ペトラ | 25 | 施術 | 昼 | 145 |
+| `staff_quinn` | クイン | 32 | 施術 | 夜 | 160 |
+| `staff_rika` | リカ | 23 | 事務 | 昼 | 105 |
+| `staff_sven` | スヴェン | 39 | 保守 | 任意 | 125 |
+| `staff_tessa` | テッサ | 34 | 医療 | 任意 | 165 |
+
+雇用時には静的データから`role_id`、4技能、許可業務、日給、通常雇用種別を実行時従業員へ投影する。希望番はSchedule作成側へ、年齢・成人確認・契約金は雇用Commandの検証境界へ渡し、コンテンツ条件を実行時の暗黙知にしない。これにより、カタログから生成した従業員の日給が実行時に0へ脱落することを防ぐ。
+
+## ユニーク人物
+
+| ID | 表示 | 種別 | 年齢 | 役割 | 対応人物 | 初期機械効果 |
+|---|---|---|---:|---|---|---|
+| `heroine_anri` | アンリ | ヒロイン | 25 | 女将 | `rival_rai` | 配置階の忍耐減少を0.90倍 |
+| `rival_rai` | ライ | ライバル | 29 | 影響者 | `heroine_anri` | Shield攻撃8、夜間+4 |
+
+両者は`unique`かつ`unsellable`であり、通常の売却・自由雇用解雇へ流さない。関係値50・80の境界は静的効果だけでは越えず、予告付きの明示イベントを必要とする。
+
+ユニーク人物の機械効果Keyは既知の効果だけを許可し、ヒロイン用とライバル用を相互に流用しない。倍率は0.25～3.00、MVPのShield攻撃値は0～100へ制限する。自由雇用候補へ`unique`または`unsellable`を付与することも、ユニーク人物から両タグを外すことも拒否する。
+
+## 実装上の次境界
+
+静的カタログは、内容の欠落や危険な人物データを起動時に検出するところまでを担当する。自動来客でのクラス・種族出現重み、雇用画面、アンリとライの同一施設・同一シフト接触判定は、運営Coordinatorと実行環境を接続した後に行う。
+
+客個体の年齢、性別、社会ランク、危険度はアーキタイプではなく生成個体の責務である。現在の`GuestDefinition`は成人確認済みフラグまでを受け取るため、個体生成を接続する際は、選択種族の`adult_age`以上の実年齢を生成・保存し、年齢不詳の個体を成人向け判定へ流さない検証を追加する。

docs/data/FACILITY_CATALOG.md

@@ -0,0 +1,20 @@
+# MVP施設カタログ実装メモ
+
+`GAME_SPECIFICATION.md` 7.6の16施設を、`FacilityDefinition`の現在の項目へ対応付けている。
+
+施設の地上一般／地下FRONT／BACK分類と、MVP互換性を保った追加16施設は`docs/FACILITY_LIST.md`を正本とする。追加施設は`data/facilities/expansion/`へ分離し、通常のMVP Registry scanと建築パレットにはまだ含めない。
+
+詳細Schema version 2のフィールド、Definition／Instance／日次履歴の責務分離、移行規則は`docs/FACILITY_DATA_DESIGN.md`を正本とする。
+
+## 現スキーマと実行時投影
+
+- 客用昇降機・業務用昇降機は `vertical_connector`、従業員ドアは `cross_layer_connector` を持つ。従業員ドアはBACK側を配置基準とし、完成時に同座標FRONTとの職員専用Connectorへ投影する。
+- 客用通路・裏通路は `route_subslot` と `schema_facility_proxy` を持つ1セル建設定義として受け付ける。完成後は通常の稼働施設へ登録せず、主要占有と共存するROUTE subslotと実Pathへ投影する。
+- 客用／業務用昇降機は、安全な垂直Topologyが未実装のため、Runtimeの建設確定前に資源・状態を変えず明示拒否する。
+- 「常時」「出動依存」「移動」のように固定サービス時間を持たない施設は、正の時間を必須とする現スキーマに合わせ、1分を状態更新・通過の最小単位としている。
+- 厨房の「15分で4食」は `base_service_minutes = 15` と `inventory_outputs` の4食で表現する。
+- 受付、厨房、成人向け個室は詳細Schema version 2へ移行済み。複数サービスは`service_profiles`で個別の時間、品質、価格、処理単位、欲求効果を持つ。
+
+## 既存試作値
+
+既存の受付、大衆食堂、一般客室には、統合済みの経済・来客回帰試験が依存する試作調整値がある。今回は互換性を維持し、仕様表との差分（受付の処理時間と直接料金、大衆食堂の処理時間と料金、一般客室の料金）は後続のバランス移行で扱う。