Record original-alignment implementation and traceability checkpoint

Capture current source, content data, tests, asset licenses, and original-specification traceability. Original implementation remains incomplete. The accepted matching UI generation passed 154 suites and 12,253 checks, with eight rendered staff-contract screens reviewed. Latest native Windows and full-original acceptance remain outstanding.

Makefile

@@ -34,6 +34,10 @@ test-s0:
 	$(GODOT) --headless --path . --script res://tests/s0/test_runtime_integration.gd
 
 test-s1:
+	$(GODOT) --headless --path . --script res://tests/s1/test_dimension_batch_save.gd
+	$(GODOT) --headless --path . --script res://tests/s1/test_facility_resize_preview.gd
+	$(GODOT) --headless --path . --script res://tests/s1/test_weighted_resize_runtime.gd
+	$(GODOT) --headless --path . --script res://tests/s1/test_original_facility_dimensions.gd
 	$(GODOT) --headless --path . --script res://tests/s1/test_world_service.gd
 	$(GODOT) --headless --path . --script res://tests/s1/test_path_service.gd
 	$(GODOT) --headless --path . --script res://tests/s1/test_path_congestion.gd
@@ -46,7 +50,14 @@ test-s1:
 	$(GODOT) --headless --path . --script res://tests/s1/test_runtime_world_construction.gd
 
 test-s2:
+	$(GODOT) --headless --path . --script tests/environment/test_cleaning_access.gd
+	$(GODOT) --headless --path . --script tests/ui/test_cleaning_gameplay.gd
+	$(GODOT) --headless --path . --script tests/environment/test_runtime_cleanliness.gd
+	$(GODOT) --headless --path . --script res://tests/environment/test_facility_cleanliness.gd
+	$(GODOT) --headless --path . --script res://tests/s2/test_facility_upkeep_accrual.gd
+	$(GODOT) --headless --path . --script res://tests/s2/test_facility_upkeep_settlement.gd
 	$(GODOT) --headless --path . --script res://tests/s2/test_facility_service.gd
+	$(GODOT) --headless --path . --script res://tests/s2/test_service_start_slots.gd
 	$(GODOT) --headless --path . --script res://tests/s2/test_inventory_logistics.gd
 	$(GODOT) --headless --path . --script res://tests/s2/test_economy_service.gd
 	$(GODOT) --headless --path . --script res://tests/s2/test_ledger_backed_resources.gd
@@ -79,6 +90,13 @@ test-s6:
 	$(GODOT) --headless --path . --script res://tests/s6/test_runtime_save_lifecycle.gd
 
 test-mvp:
+	$(GODOT) --headless --path . --script res://tests/mvp/test_premium_room_guest_flow.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_premium_room.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_original_room_zones.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_upkeep_loss_streak.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_upkeep_legacy_midnight.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_runtime_upkeep.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_upkeep_construction_boundaries.gd
 	$(GODOT) --headless --path . --script res://tests/mvp/test_operations_coordinator.gd
 	$(GODOT) --headless --path . --script res://tests/mvp/test_mvp_content_catalog.gd
 	$(GODOT) --headless --path . --script res://tests/mvp/test_progression_service.gd
@@ -89,6 +107,26 @@ test-acceptance:
 	$(GODOT) --headless --path . --script res://tests/mvp/test_runtime_operations_acceptance.gd
 
 test-ui:
+	$(GODOT) --headless --path . --script res://tests/mvp/test_chapel_boundaries.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_chapel_gameplay.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_chapel_service.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_dashboard_coalescing.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_anri_floor_pricing.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_fine_cleaning_effect.gd
+	$(GODOT) --headless --path . --script res://tests/mvp/test_amelia_donations.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_anri_recruitment.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_layer_skin.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_world_tree_rank.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_rank_pointer.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_layer_presentation.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_original_build_pointer.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_dimension_migration_ui.gd
+	python3 tools/run_upkeep_ui_flow.py --godot "$(GODOT)"
+	$(GODOT) --headless --path . --script res://tests/ui/test_upkeep_inspector.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_staff_rest.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_staff_rescue.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_guest_observation.gd
+	$(GODOT) --headless --path . --script res://tests/ui/test_guest_decision_log.gd
 	$(MAKE) test-pixel-ui
 	$(GODOT) --headless --path . --script res://tests/ui/test_main_dashboard.gd
 	$(GODOT) --headless --path . --script res://tests/ui/test_staff_management.gd
@@ -98,6 +136,12 @@ test-ui:
 	$(MAKE) test-opening
 
 test-perf:
+	$(GODOT) --headless --path . --script res://tests/performance/test_facility_reachability.gd
+	$(GODOT) --headless --path . --script res://tests/performance/test_snapshot_ownership.gd
+	$(GODOT) --headless --path . --script res://tests/performance/test_world_snapshot_cache.gd
+	$(GODOT) --headless --path . --script res://tests/performance/test_lazy_digest.gd
+	$(GODOT) --headless --path . --script res://tests/performance/test_path_membership.gd
+	$(GODOT) --headless --path . --script res://tests/performance/test_system_optimization.gd
 	$(GODOT) --headless --path . --script res://tests/performance/test_digest_performance.gd
 	$(GODOT) --headless --path . --script res://tests/performance/test_perf_mvp_001.gd
 
@@ -122,6 +166,7 @@ capture-pixel:
 	$(GODOT) --path . --script res://tests/ui/capture_pixel_tower.gd
 
 test-pixel-ui:
+	$(GODOT) --headless --path . --script res://tests/ui/test_room_presentation.gd
 	$(GODOT) --headless --path . --script res://tests/ui/test_pixel_tower.gd
 
 .PHONY: test-opening capture-opening
@@ -161,6 +206,14 @@ capture-business:
 
 .PHONY: test-transport capture-transport preview-transport
 test-transport:
+	$(GODOT) --headless --path . --script res://tests/staff/test_dormitory_dimension_migration.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_staff_dormitory.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_dormitory_shift_cycle.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_shift_rush.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_staff_rest.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_rescue_elevator.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_staff_rescue.gd
+	$(GODOT) --headless --path . --script res://tests/staff/test_task_work_clock.gd
 	$(MAKE) test-stairs
 	$(GODOT) --headless --path . --script res://tests/world/test_elevator_topology.gd
 	$(GODOT) --headless --path . --script res://tests/transport/test_elevator_service.gd
@@ -201,3 +254,8 @@ export-macos:
 .PHONY: test-exported-opening
 test-exported-opening:
 	python3 tools/verify_exported_opening.py "$(WINDOWS_PCK)" --godot "$(GODOT)"
+
+# Exhaustive discovery includes comparison suites outside the ordinary smoke run.
+.PHONY: test-all
+test-all:
+	python3 tools/run_all_tests.py --godot "$(GODOT)"

README.md

@@ -8,7 +8,7 @@
 
 Godotが開いたら、右上の実行ボタンまたは `F5` でプロジェクトを起動できます。エディタを開かず直接実行する場合は `make run` を使用します。
 
-通常の新規ゲームは一時停止から始まります。左上の開業ガイドに沿って受付・客室・通路を建て、「従業員」で雇用・配属・毎日の勤務帯を決めます。「帳簿」で翌朝06:00の決算を確認できます。具体的な最小宿の建て方は [試遊ガイド](docs/PLAYTEST_GUIDE.md#通常uiで最初の宿を開業する) を参照してください。
+通常の新規ゲームは一時停止から始まります。左上の開業ガイドに沿って受付・客室・通路を建て、「従業員」で雇用・配属・毎日の勤務帯を決めます。「帳簿」で毎日00:00の決算を確認できます。具体的な最小宿の建て方は [試遊ガイド](docs/PLAYTEST_GUIDE.md#通常uiで最初の宿を開業する) を参照してください。
 
 ## ドット絵の世界樹を見る
 

TheTree-ドット版を起動.command

@@ -0,0 +1,3 @@
+#!/bin/zsh
+# 同伴救護・待機室休息を反映した検証済みドット版
+open -n '/Users/korizatou114/Projects/とりにく工房ゲーム制作部/build/macos/TheTree-Labor-2026-09-29.app'

assets/shaders/layer_lens.gdshader

@@ -0,0 +1,20 @@
+shader_type canvas_item;
+render_mode unshaded;
+
+uniform sampler2D screen_texture : hint_screen_texture, repeat_disable, filter_nearest;
+uniform vec2 extent = vec2(1.0);
+uniform vec2 center = vec2(0.5);
+uniform float progress : hint_range(0.0, 1.0) = 0.0;
+
+void fragment() {
+	vec2 delta = (UV - center) * extent;
+	float distance_px = length(delta);
+	float radius = progress * length(extent);
+	float band = 1.0 - smoothstep(0.0, 28.0, abs(distance_px - radius));
+	float fade = 1.0 - progress;
+	vec2 direction = delta / max(distance_px, 1.0);
+	vec2 offset = direction * sin((distance_px - radius) * 0.18) * band * 4.0 * fade * SCREEN_PIXEL_SIZE;
+	vec4 scene = texture(screen_texture, SCREEN_UV + offset);
+	scene.rgb += vec3(0.18, 0.28, 0.22) * band * fade;
+	COLOR = vec4(scene.rgb, 1.0);
+}

assets/shaders/layer_lens.gdshader.uid

@@ -0,0 +1 @@
+uid://duedneo846yck

assets/themes/japanese_fantasy/visual-theme-v1.tres

@@ -220,13 +220,18 @@ back_world_background = ExtResource("3_back")
 world_art_opacity = 0.94
 grid_overlay_opacity = 0.22
 facility_icons = {
+"cleaning_room": SubResource("F12"),
+"chapel": SubResource("F12"),
 "reception": SubResource("F00"),
 "standard_room": SubResource("F01"),
+"premium_room": SubResource("F01"),
 "cafeteria": SubResource("F02"),
 "warehouse": SubResource("F03"),
 "kitchen": SubResource("F10"),
 "public_bath": SubResource("F11"),
 "staff_waiting_room": SubResource("F12"),
+"staff_dormitory": SubResource("F01"),
+"infirmary": SubResource("F12"),
 "security_station": SubResource("F13"),
 "tavern": SubResource("F20"),
 "massage_room": SubResource("F21"),

data/characters/mvp_staff_candidates.json

@@ -2,25 +2,501 @@
   "schema_version": 1,
   "content_type": "staff_candidates",
   "entries": [
-    {"id":"staff_akane","display_name":"アカネ","age":24,"adult_verified":true,"role_id":"receptionist","daily_wage":120,"signing_cost":180,"preferred_shift":"day","traits":["friendly"],"skills":{"combat":15,"operation":42,"service":68,"underworld":5},"permitted_task_tags":["reception","service"]},
-    {"id":"staff_bardo","display_name":"バルド","age":38,"adult_verified":true,"role_id":"receptionist","daily_wage":135,"signing_cost":220,"preferred_shift":"night","traits":["calm"],"skills":{"combat":22,"operation":55,"service":62,"underworld":18},"permitted_task_tags":["reception","service"]},
-    {"id":"staff_chika","display_name":"チカ","age":27,"adult_verified":true,"role_id":"cook","daily_wage":145,"signing_cost":250,"preferred_shift":"day","traits":["cleanly"],"skills":{"combat":8,"operation":76,"service":32,"underworld":4},"permitted_task_tags":["cooking","supply"]},
-    {"id":"staff_doran","display_name":"ドラン","age":44,"adult_verified":true,"role_id":"cook","daily_wage":160,"signing_cost":300,"preferred_shift":"night","traits":["mentor"],"skills":{"combat":20,"operation":82,"service":28,"underworld":12},"permitted_task_tags":["cooking","supply"]},
-    {"id":"staff_eri","display_name":"エリ","age":22,"adult_verified":true,"role_id":"cleaner","daily_wage":90,"signing_cost":100,"preferred_shift":"day","traits":["cleanly"],"skills":{"combat":6,"operation":61,"service":35,"underworld":3},"permitted_task_tags":["cleaning","maintenance"]},
-    {"id":"staff_fugo","display_name":"フゴ","age":31,"adult_verified":true,"role_id":"cleaner","daily_wage":100,"signing_cost":130,"preferred_shift":"night","traits":["night_owl"],"skills":{"combat":18,"operation":65,"service":22,"underworld":20},"permitted_task_tags":["cleaning","maintenance"]},
-    {"id":"staff_gina","display_name":"ジーナ","age":29,"adult_verified":true,"role_id":"porter","daily_wage":110,"signing_cost":150,"preferred_shift":"day","traits":["careful"],"skills":{"combat":28,"operation":70,"service":20,"underworld":10},"permitted_task_tags":["logistics","rescue","supply"]},
-    {"id":"staff_haru","display_name":"ハル","age":21,"adult_verified":true,"role_id":"porter","daily_wage":95,"signing_cost":100,"preferred_shift":"night","traits":["night_owl"],"skills":{"combat":24,"operation":58,"service":25,"underworld":28},"permitted_task_tags":["logistics","rescue","supply"]},
-    {"id":"staff_iris","display_name":"イリス","age":26,"adult_verified":true,"role_id":"attendant","daily_wage":130,"signing_cost":210,"preferred_shift":"day","traits":["friendly"],"skills":{"combat":10,"operation":38,"service":74,"underworld":8},"permitted_task_tags":["bath","room_service","service"]},
-    {"id":"staff_juno","display_name":"ユノ","age":33,"adult_verified":true,"role_id":"attendant","daily_wage":140,"signing_cost":240,"preferred_shift":"night","traits":["calm"],"skills":{"combat":12,"operation":45,"service":78,"underworld":22},"permitted_task_tags":["bath","room_service","service"]},
-    {"id":"staff_klaus","display_name":"クラウス","age":36,"adult_verified":true,"role_id":"guard","daily_wage":155,"signing_cost":280,"preferred_shift":"day","traits":["short_tempered"],"skills":{"combat":82,"operation":34,"service":18,"underworld":16},"permitted_task_tags":["defense","escort","security"]},
-    {"id":"staff_lina","display_name":"リナ","age":30,"adult_verified":true,"role_id":"guard","daily_wage":150,"signing_cost":260,"preferred_shift":"night","traits":["night_owl"],"skills":{"combat":77,"operation":38,"service":25,"underworld":30},"permitted_task_tags":["defense","escort","security"]},
-    {"id":"staff_marc","display_name":"マルク","age":41,"adult_verified":true,"role_id":"guard","daily_wage":170,"signing_cost":330,"preferred_shift":"any","traits":["mentor"],"skills":{"combat":88,"operation":46,"service":20,"underworld":25},"permitted_task_tags":["defense","escort","security"]},
-    {"id":"staff_nadia","display_name":"ナディア","age":28,"adult_verified":true,"role_id":"bartender","daily_wage":145,"signing_cost":240,"preferred_shift":"night","traits":["merchant_minded"],"skills":{"combat":20,"operation":48,"service":76,"underworld":35},"permitted_task_tags":["bar","service","supply"]},
-    {"id":"staff_otto","display_name":"オットー","age":35,"adult_verified":true,"role_id":"bartender","daily_wage":150,"signing_cost":270,"preferred_shift":"night","traits":["friendly"],"skills":{"combat":26,"operation":52,"service":79,"underworld":32},"permitted_task_tags":["bar","service","supply"]},
-    {"id":"staff_petra","display_name":"ペトラ","age":25,"adult_verified":true,"role_id":"masseur","daily_wage":145,"signing_cost":260,"preferred_shift":"day","traits":["careful"],"skills":{"combat":8,"operation":35,"service":81,"underworld":18},"permitted_task_tags":["adult_service","massage","service"]},
-    {"id":"staff_quinn","display_name":"クイン","age":32,"adult_verified":true,"role_id":"masseur","daily_wage":160,"signing_cost":320,"preferred_shift":"night","traits":["underworld_savvy"],"skills":{"combat":18,"operation":40,"service":84,"underworld":55},"permitted_task_tags":["adult_service","massage","service"]},
-    {"id":"staff_rika","display_name":"リカ","age":23,"adult_verified":true,"role_id":"clerk","daily_wage":105,"signing_cost":140,"preferred_shift":"day","traits":["merchant_minded"],"skills":{"combat":5,"operation":67,"service":58,"underworld":7},"permitted_task_tags":["accounting","reception","trade"]},
-    {"id":"staff_sven","display_name":"スヴェン","age":39,"adult_verified":true,"role_id":"maintenance","daily_wage":125,"signing_cost":190,"preferred_shift":"any","traits":["careful"],"skills":{"combat":32,"operation":74,"service":16,"underworld":15},"permitted_task_tags":["construction","maintenance","repair"]},
-    {"id":"staff_tessa","display_name":"テッサ","age":34,"adult_verified":true,"role_id":"medic","daily_wage":165,"signing_cost":340,"preferred_shift":"any","traits":["calm"],"skills":{"combat":14,"operation":69,"service":63,"underworld":12},"permitted_task_tags":["medical","rescue","service"]}
+    {
+      "id": "staff_akane",
+      "display_name": "アカネ",
+      "age": 24,
+      "adult_verified": true,
+      "role_id": "receptionist",
+      "daily_wage": 120,
+      "signing_cost": 180,
+      "preferred_shift": "day",
+      "traits": [
+        "friendly"
+      ],
+      "skills": {
+        "combat": 15,
+        "operation": 42,
+        "service": 68,
+        "underworld": 5
+      },
+      "permitted_task_tags": [
+        "reception",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_bardo",
+      "display_name": "バルド",
+      "age": 38,
+      "adult_verified": true,
+      "role_id": "receptionist",
+      "daily_wage": 135,
+      "signing_cost": 220,
+      "preferred_shift": "night",
+      "traits": [
+        "calm"
+      ],
+      "skills": {
+        "combat": 22,
+        "operation": 55,
+        "service": 62,
+        "underworld": 18
+      },
+      "permitted_task_tags": [
+        "reception",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_chika",
+      "display_name": "チカ",
+      "age": 27,
+      "adult_verified": true,
+      "role_id": "cook",
+      "daily_wage": 145,
+      "signing_cost": 250,
+      "preferred_shift": "day",
+      "traits": [
+        "cleanly"
+      ],
+      "skills": {
+        "combat": 8,
+        "operation": 76,
+        "service": 32,
+        "underworld": 4
+      },
+      "permitted_task_tags": [
+        "cooking",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_doran",
+      "display_name": "ドラン",
+      "age": 44,
+      "adult_verified": true,
+      "role_id": "cook",
+      "daily_wage": 160,
+      "signing_cost": 300,
+      "preferred_shift": "night",
+      "traits": [
+        "mentor"
+      ],
+      "skills": {
+        "combat": 20,
+        "operation": 82,
+        "service": 28,
+        "underworld": 12
+      },
+      "permitted_task_tags": [
+        "cooking",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_eri",
+      "display_name": "エリ",
+      "age": 22,
+      "adult_verified": true,
+      "role_id": "cleaner",
+      "daily_wage": 90,
+      "signing_cost": 100,
+      "preferred_shift": "day",
+      "traits": [
+        "cleanly"
+      ],
+      "skills": {
+        "combat": 6,
+        "operation": 61,
+        "service": 35,
+        "underworld": 3
+      },
+      "permitted_task_tags": [
+        "cleaning",
+        "maintenance"
+      ]
+    },
+    {
+      "id": "staff_fugo",
+      "display_name": "フゴ",
+      "age": 31,
+      "adult_verified": true,
+      "role_id": "cleaner",
+      "daily_wage": 100,
+      "signing_cost": 130,
+      "preferred_shift": "night",
+      "traits": [
+        "night_owl"
+      ],
+      "skills": {
+        "combat": 18,
+        "operation": 65,
+        "service": 22,
+        "underworld": 20
+      },
+      "permitted_task_tags": [
+        "cleaning",
+        "maintenance"
+      ]
+    },
+    {
+      "id": "staff_gina",
+      "display_name": "ジーナ",
+      "age": 29,
+      "adult_verified": true,
+      "role_id": "porter",
+      "daily_wage": 110,
+      "signing_cost": 150,
+      "preferred_shift": "day",
+      "traits": [
+        "careful"
+      ],
+      "skills": {
+        "combat": 28,
+        "operation": 70,
+        "service": 20,
+        "underworld": 10
+      },
+      "permitted_task_tags": [
+        "logistics",
+        "rescue",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_haru",
+      "display_name": "ハル",
+      "age": 21,
+      "adult_verified": true,
+      "role_id": "porter",
+      "daily_wage": 95,
+      "signing_cost": 100,
+      "preferred_shift": "night",
+      "traits": [
+        "night_owl"
+      ],
+      "skills": {
+        "combat": 24,
+        "operation": 58,
+        "service": 25,
+        "underworld": 28
+      },
+      "permitted_task_tags": [
+        "logistics",
+        "rescue",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_iris",
+      "display_name": "イリス",
+      "age": 26,
+      "adult_verified": true,
+      "role_id": "attendant",
+      "daily_wage": 130,
+      "signing_cost": 210,
+      "preferred_shift": "day",
+      "traits": [
+        "friendly"
+      ],
+      "skills": {
+        "combat": 10,
+        "operation": 38,
+        "service": 74,
+        "underworld": 8
+      },
+      "permitted_task_tags": [
+        "bath",
+        "room_service",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_juno",
+      "display_name": "ユノ",
+      "age": 33,
+      "adult_verified": true,
+      "role_id": "attendant",
+      "daily_wage": 140,
+      "signing_cost": 240,
+      "preferred_shift": "night",
+      "traits": [
+        "calm"
+      ],
+      "skills": {
+        "combat": 12,
+        "operation": 45,
+        "service": 78,
+        "underworld": 22
+      },
+      "permitted_task_tags": [
+        "bath",
+        "room_service",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_klaus",
+      "display_name": "クラウス",
+      "age": 36,
+      "adult_verified": true,
+      "role_id": "guard",
+      "daily_wage": 155,
+      "signing_cost": 280,
+      "preferred_shift": "day",
+      "traits": [
+        "short_tempered"
+      ],
+      "skills": {
+        "combat": 82,
+        "operation": 34,
+        "service": 18,
+        "underworld": 16
+      },
+      "permitted_task_tags": [
+        "defense",
+        "escort",
+        "security"
+      ]
+    },
+    {
+      "id": "staff_lina",
+      "display_name": "リナ",
+      "age": 30,
+      "adult_verified": true,
+      "role_id": "guard",
+      "daily_wage": 150,
+      "signing_cost": 260,
+      "preferred_shift": "night",
+      "traits": [
+        "night_owl"
+      ],
+      "skills": {
+        "combat": 77,
+        "operation": 38,
+        "service": 25,
+        "underworld": 30
+      },
+      "permitted_task_tags": [
+        "defense",
+        "escort",
+        "security"
+      ]
+    },
+    {
+      "id": "staff_marc",
+      "display_name": "マルク",
+      "age": 41,
+      "adult_verified": true,
+      "role_id": "guard",
+      "daily_wage": 170,
+      "signing_cost": 330,
+      "preferred_shift": "any",
+      "traits": [
+        "mentor"
+      ],
+      "skills": {
+        "combat": 88,
+        "operation": 46,
+        "service": 20,
+        "underworld": 25
+      },
+      "permitted_task_tags": [
+        "defense",
+        "escort",
+        "security"
+      ]
+    },
+    {
+      "id": "staff_nadia",
+      "display_name": "ナディア",
+      "age": 28,
+      "adult_verified": true,
+      "role_id": "bartender",
+      "daily_wage": 145,
+      "signing_cost": 240,
+      "preferred_shift": "night",
+      "traits": [
+        "merchant_minded"
+      ],
+      "skills": {
+        "combat": 20,
+        "operation": 48,
+        "service": 76,
+        "underworld": 35
+      },
+      "permitted_task_tags": [
+        "bar",
+        "service",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_otto",
+      "display_name": "オットー",
+      "age": 35,
+      "adult_verified": true,
+      "role_id": "bartender",
+      "daily_wage": 150,
+      "signing_cost": 270,
+      "preferred_shift": "night",
+      "traits": [
+        "friendly"
+      ],
+      "skills": {
+        "combat": 26,
+        "operation": 52,
+        "service": 79,
+        "underworld": 32
+      },
+      "permitted_task_tags": [
+        "bar",
+        "service",
+        "supply"
+      ]
+    },
+    {
+      "id": "staff_petra",
+      "display_name": "ペトラ",
+      "age": 25,
+      "adult_verified": true,
+      "role_id": "masseur",
+      "daily_wage": 145,
+      "signing_cost": 260,
+      "preferred_shift": "day",
+      "traits": [
+        "careful"
+      ],
+      "skills": {
+        "combat": 8,
+        "operation": 35,
+        "service": 81,
+        "underworld": 18
+      },
+      "permitted_task_tags": [
+        "adult_service",
+        "massage",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_quinn",
+      "display_name": "クイン",
+      "age": 32,
+      "adult_verified": true,
+      "role_id": "masseur",
+      "daily_wage": 160,
+      "signing_cost": 320,
+      "preferred_shift": "night",
+      "traits": [
+        "underworld_savvy"
+      ],
+      "skills": {
+        "combat": 18,
+        "operation": 40,
+        "service": 84,
+        "underworld": 55
+      },
+      "permitted_task_tags": [
+        "adult_service",
+        "massage",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_rika",
+      "display_name": "リカ",
+      "age": 23,
+      "adult_verified": true,
+      "role_id": "clerk",
+      "daily_wage": 105,
+      "signing_cost": 140,
+      "preferred_shift": "day",
+      "traits": [
+        "merchant_minded"
+      ],
+      "skills": {
+        "combat": 5,
+        "operation": 67,
+        "service": 58,
+        "underworld": 7
+      },
+      "permitted_task_tags": [
+        "accounting",
+        "reception",
+        "trade"
+      ]
+    },
+    {
+      "id": "staff_sven",
+      "display_name": "スヴェン",
+      "age": 39,
+      "adult_verified": true,
+      "role_id": "maintenance",
+      "daily_wage": 125,
+      "signing_cost": 190,
+      "preferred_shift": "any",
+      "traits": [
+        "careful"
+      ],
+      "skills": {
+        "combat": 32,
+        "operation": 74,
+        "service": 16,
+        "underworld": 15
+      },
+      "permitted_task_tags": [
+        "construction",
+        "maintenance",
+        "repair"
+      ]
+    },
+    {
+      "id": "staff_tessa",
+      "display_name": "テッサ",
+      "age": 34,
+      "adult_verified": true,
+      "role_id": "medic",
+      "daily_wage": 165,
+      "signing_cost": 340,
+      "preferred_shift": "any",
+      "traits": [
+        "calm"
+      ],
+      "skills": {
+        "combat": 14,
+        "operation": 69,
+        "service": 63,
+        "underworld": 12
+      },
+      "permitted_task_tags": [
+        "medical",
+        "rescue",
+        "service"
+      ]
+    },
+    {
+      "id": "staff_uma",
+      "display_name": "ウマ",
+      "age": 28,
+      "adult_verified": true,
+      "role_id": "cleric",
+      "daily_wage": 130,
+      "signing_cost": 210,
+      "preferred_shift": "day",
+      "traits": [
+        "calm"
+      ],
+      "skills": {
+        "combat": 10,
+        "operation": 38,
+        "service": 74,
+        "underworld": 8
+      },
+      "permitted_task_tags": [
+        "service"
+      ]
+    }
   ]
 }

data/characters/mvp_unique_characters.json

@@ -13,7 +13,7 @@
       "preferred_shift": "day",
       "traits": ["friendly", "unique", "unsellable"],
       "skills": {"combat": 24, "operation": 66, "service": 82, "underworld": 18},
-      "mechanical_effects": {"assigned_floor_patience_loss_multiplier_bp": 9000}
+      "mechanical_effects": {"assigned_floor_revenue_multiplier_bp": 12000}
     },
     {
       "id": "rival_rai",

data/environment/cleaning_policy.json

@@ -0,0 +1,8 @@
+{
+  "schema_version": 1,
+  "initial_cleanliness": 100,
+  "maximum_cleanliness": 100,
+  "clean_at_or_below": 75,
+  "work_minutes": 8,
+  "recovery_per_completed_task": 25
+}

data/facilities/adult_private_room.tres

@@ -24,6 +24,7 @@ construction_cost = {&"gold": 1500, &"materials": 14}
 build_minutes = 240
 weight_per_cell = 2
 upgrade_costs = Array[Dictionary]([{&"gold": 750, &"materials": 8}, {&"gold": 1500, &"materials": 14}])
+maintenance_gold = 8
 maintenance_mana = 3
 power_priority = 45
 staff_min = 1

data/facilities/cafeteria.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(4, 2)
 construction_cost = {&"gold": 800, &"materials": 12}
 build_minutes = 180
 weight_per_cell = 2
+maintenance_gold = 4
 maintenance_mana = 2
 staff_min = 2
 staff_max = 4

data/facilities/expansion/black_market.tres

@@ -9,7 +9,7 @@ display_name = "闇市取引所"
 description = "希少品を高値で扱う地下取引施設。収益と引き換えに警戒と監査リスクを持つ。"
 zone = 3
 layer = 0
-footprint = Vector2i(3, 2)
+footprint = Vector2i(4, 2)
 construction_cost = {&"gold": 1600, &"materials": 12}
 build_minutes = 270
 weight_per_cell = 2

data/facilities/expansion/chapel.tres

@@ -0,0 +1,28 @@
+[gd_resource type="Resource" script_class="FacilityDefinition" load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://scripts/data/facility_definition.gd" id="1"]
+
+[resource]
+script = ExtResource("1")
+id = &"chapel"
+display_name = "礼拝堂"
+description = "礼拝と寄付を通じて信仰を育む施設。聖職者の配置が必要。"
+zone = 0
+layer = 0
+footprint = Vector2i(4, 3)
+construction_cost = {&"gold": 1200, &"materials": 12}
+build_minutes = 180
+maintenance_gold = 6
+staff_min = 1
+staff_max = 2
+required_roles = Array[StringName]([&"cleric"])
+primary_skill = &"service"
+customer_capacity = 8
+capacity = 8
+queue_capacity = 8
+base_service_minutes = 60
+base_price = 20
+faith_per_service = 1
+service_types = Array[StringName]([&"worship"])
+default_service_type = &"worship"
+tags = Array[StringName]([&"worship", &"leisure"])

data/facilities/expansion/cleaning_room.tres

@@ -0,0 +1,24 @@
+[gd_resource type="Resource" script_class="FacilityDefinition" load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://scripts/data/facility_definition.gd" id="1"]
+
+[resource]
+script = ExtResource("1")
+id = &"cleaning_room"
+display_name = "清掃員室"
+description = "清掃員が清掃へ向かうための裏層の拠点。"
+zone = 0
+layer = 1
+footprint = Vector2i(2, 1)
+construction_cost = {&"gold": 350, &"materials": 4}
+build_minutes = 60
+maintenance_gold = 2
+staff_min = 1
+staff_max = 2
+required_roles = Array[StringName]([&"cleaner"])
+primary_skill = &"operation"
+customer_capacity = 0
+capacity = 0
+queue_capacity = 0
+base_price = 0
+tags = Array[StringName]([&"cleaning", &"staff_support"])

data/facilities/expansion/premium_room.tres

@@ -7,16 +7,18 @@ script = ExtResource("1")
 id = &"premium_room"
 display_name = "上級客室"
 description = "富裕客と長期滞在客向けの静かな地上客室。一般客室より高い品質と料金を持つ。"
-zone = 1
+zone = 0
 layer = 0
-footprint = Vector2i(3, 2)
+footprint = Vector2i(4, 1)
 construction_cost = {&"gold": 900, &"materials": 10}
 build_minutes = 150
 weight_per_cell = 2
+maintenance_gold = 5
 maintenance_mana = 1
 staff_min = 0
 staff_max = 0
 capacity = 2
+customer_capacity = 2
 queue_capacity = 2
 base_service_minutes = 720
 base_quality = 70

data/facilities/expansion/staff_dormitory.tres

@@ -7,17 +7,19 @@ script = ExtResource("1")
 id = &"staff_dormitory"
 display_name = "従業員宿舎"
 description = "勤務の合間に従業員が睡眠と長時間休息を取るBACK居住区画。"
-zone = 1
+zone = 0
 layer = 1
-footprint = Vector2i(4, 2)
+footprint = Vector2i(2, 1)
 construction_cost = {&"gold": 650, &"materials": 8}
 build_minutes = 150
 weight_per_cell = 1
+maintenance_gold = 4
 maintenance_mana = 1
 power_priority = 35
 staff_min = 0
 staff_max = 0
 capacity = 12
+customer_capacity = 0
 queue_capacity = 0
 base_service_minutes = 360
 base_quality = 58

data/facilities/guest_corridor.tres

@@ -14,6 +14,7 @@ construction_cost = {&"gold": 20, &"materials": 0}
 build_minutes = 10
 weight_per_cell = 1
 pass_through = true
+maintenance_gold = 1
 maintenance_mana = 0
 power_priority = 10
 staff_min = 0

data/facilities/guest_elevator.tres

@@ -14,6 +14,7 @@ construction_cost = {&"gold": 1500, &"materials": 15}
 build_minutes = 300
 weight_per_cell = 3
 pass_through = true
+maintenance_gold = 8
 maintenance_mana = 5
 power_priority = 85
 staff_min = 0

data/facilities/infrastructure/guest_stairs.tres

@@ -15,6 +15,7 @@ construction_cost = {&"gold": 40, &"materials": 0}
 build_minutes = 10
 weight_per_cell = 1
 pass_through = true
+maintenance_gold = 1
 maintenance_mana = 0
 power_priority = 10
 staff_min = 0

data/facilities/infrastructure/service_stairs.tres

@@ -15,6 +15,7 @@ construction_cost = {&"gold": 50, &"materials": 0}
 build_minutes = 10
 weight_per_cell = 1
 pass_through = true
+maintenance_gold = 1
 maintenance_mana = 0
 power_priority = 10
 staff_min = 0

data/facilities/kitchen.tres

@@ -23,6 +23,7 @@ construction_cost = {&"gold": 700, &"materials": 10}
 build_minutes = 180
 weight_per_cell = 2
 upgrade_costs = Array[Dictionary]([{&"gold": 350, &"materials": 6}, {&"gold": 700, &"materials": 12}])
+maintenance_gold = 4
 maintenance_mana = 2
 power_priority = 80
 staff_min = 1

data/facilities/massage_room.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(2, 1)
 construction_cost = {&"gold": 800, &"materials": 8}
 build_minutes = 120
 weight_per_cell = 1
+maintenance_gold = 4
 maintenance_mana = 2
 power_priority = 50
 staff_min = 1

data/facilities/public_bath.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(6, 2)
 construction_cost = {&"gold": 1200, &"materials": 16}
 build_minutes = 240
 weight_per_cell = 2
+maintenance_gold = 6
 maintenance_mana = 4
 power_priority = 65
 staff_min = 1

data/facilities/reception.tres

@@ -23,6 +23,7 @@ construction_cost = {&"gold": 500, &"materials": 8}
 build_minutes = 120
 weight_per_cell = 2
 upgrade_costs = Array[Dictionary]([{&"gold": 250, &"materials": 4}, {&"gold": 500, &"materials": 8}])
+maintenance_gold = 3
 maintenance_mana = 1
 power_priority = 100
 staff_min = 1

data/facilities/rescue/infirmary.tres

@@ -0,0 +1,26 @@
+[gd_resource type="Resource" script_class="FacilityDefinition" load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://scripts/data/facility_definition.gd" id="1"]
+
+[resource]
+script = ExtResource("1")
+id = &"infirmary"
+display_name = "医務室"
+description = "基本仕様書に基づく医務室。費用・能力値は調整値。"
+zone = 0
+layer = 1
+footprint = Vector2i(4, 2)
+construction_cost = {&"gold": 640, &"materials": 8}
+build_minutes = 80
+staff_min = 0
+staff_max = 2
+capacity = 0
+queue_staff_min = 0
+staff_max = 2
+capacity = 0
+base_service_minutes = 30
+base_quality = 50
+base_price = 0
+tags = Array[StringName]([&"medical", &"staff_only"])
+
+maintenance_gold = 4

data/facilities/security_station.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(2, 2)
 construction_cost = {&"gold": 900, &"materials": 10}
 build_minutes = 180
 weight_per_cell = 2
+maintenance_gold = 5
 maintenance_mana = 2
 power_priority = 90
 staff_min = 1

data/facilities/service_corridor.tres

@@ -14,6 +14,7 @@ construction_cost = {&"gold": 25, &"materials": 0}
 build_minutes = 10
 weight_per_cell = 1
 pass_through = true
+maintenance_gold = 1
 maintenance_mana = 0
 power_priority = 10
 staff_min = 0

data/facilities/service_elevator.tres

@@ -14,6 +14,7 @@ construction_cost = {&"gold": 2200, &"materials": 20}
 build_minutes = 360
 weight_per_cell = 3
 pass_through = true
+maintenance_gold = 11
 maintenance_mana = 6
 power_priority = 95
 staff_min = 0

data/facilities/staff_door.tres

@@ -14,6 +14,7 @@ construction_cost = {&"gold": 100, &"materials": 1}
 build_minutes = 30
 weight_per_cell = 1
 pass_through = true
+maintenance_gold = 1
 maintenance_mana = 0
 power_priority = 95
 staff_min = 0

data/facilities/staff_waiting_room.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(4, 2)
 construction_cost = {&"gold": 400, &"materials": 6}
 build_minutes = 120
 weight_per_cell = 1
+maintenance_gold = 2
 maintenance_mana = 0
 power_priority = 30
 staff_min = 0

data/facilities/standard_room.tres

@@ -7,12 +7,13 @@ script = ExtResource("1")
 id = &"standard_room"
 display_name = "一般客室"
 description = "冒険者と一般市民向けの基本的な宿泊施設。"
-zone = 1
+zone = 0
 layer = 0
 footprint = Vector2i(2, 1)
 construction_cost = {&"gold": 350, &"materials": 5}
 build_minutes = 60
 weight_per_cell = 1
+maintenance_gold = 2
 maintenance_mana = 0
 staff_min = 0
 staff_max = 0

data/facilities/tavern.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(4, 2)
 construction_cost = {&"gold": 1000, &"materials": 12}
 build_minutes = 240
 weight_per_cell = 2
+maintenance_gold = 5
 maintenance_mana = 2
 power_priority = 55
 staff_min = 2

data/facilities/warehouse.tres

@@ -13,6 +13,7 @@ footprint = Vector2i(4, 2)
 construction_cost = {&"gold": 450, &"materials": 10}
 build_minutes = 180
 weight_per_cell = 2
+maintenance_gold = 3
 maintenance_mana = 0
 staff_min = 1
 staff_max = 3

docs/ART_ASSET_PRODUCTION_SPECIFICATION.md

@@ -2,7 +2,9 @@
 
 ## 1. 目的
 
-この文書は、本作に必要な画像を制作し、安全に差し替えるための正本とする。
+この文書は、本作に必要な画像の制作・差し替え手順を定める派生資料とする。基本仕様の原本はユーザー指定の基本仕様書であり、差異がある場合は原本を優先する。
+
+2026-09-29: [原本別の素材実在・必要枠台帳](plans/original-completion-2026-09-29/execution/assets/README.md)を追加。既存素材とコード描画の候補は、完成認定と区別して記録する。
 
 **2026-09-09更新：現在のマップは『The Tower SP』を参考にしたドット絵の断面表示を採用する。** 施設の内装と小さな人物の動きが主役で、Kenney Tiny Dungeon・Tiny Townの16px素材と専用のドット描画を使う。旧生成背景や人物Bustを現在のマップへ戻すための仕様ではない。操作と実装上の制約は [ドット絵表示と見学ガイド](PIXEL_TOWER_VISUALS.md) を参照する。
 
@@ -10,6 +12,8 @@
 
 ## 2. 現在のアートディレクション
 
+2026-09-28: ユーザー提供の『The Tower 2』実ファイルを追加参考として確認した。[素材の観察結果と現実装との差分](THE_TOWER_2_REFERENCE_2026-09-28.md) に沿って、部屋の利用状態・家具に対応した人物位置・待機列・観察時の画面構成を改善する。画像から確認できた事実と未確認の実行時挙動を区別する。ゲーム仕様はユーザー指定の基本仕様書と施設パラメータ訂正を優先する。
+
 - 世界樹の正面断面を大きく見せる。受付・客室・食堂などを内装で識別でき、小さな客と従業員の移動・待機・仕事が読める構成とする。
 - 基本素材はKenneyの16×16pxドット絵。Nearestフィルターを使い、通常表示では整数倍率を優先する。高解像度の絵をぼかして縮小した人物をマップの主役にしない。
 - 幹・葉・部屋・家具は同じドット密度と色調で専用描画する。主色は木色・クリーム・濃緑、裏方の補助色は青緑とする。

docs/DEBUG_COMPLETION_2026-09-27.md

@@ -0,0 +1,55 @@
+# 全件修正・通しデバッグ（2026-09-27）
+
+## 原因と修正
+
+職員配置UIの4件の失敗は、テスト用建物の上下移動を客用通路だけで構成していたことが原因。実装済みの明示的な階段必須ルールではその客室へ到達できず、開業ガイドは正しく「道をつなぐ」を返していた。
+
+`test_staff_management.gd` を、初日営業の受入試験と同じく客用階段で上下をつなぐ配置へ修正した。期待値を緩めたり、到達判定・配置条件を無効にしたりしていない。途中までの階段では配属案内へ進まない負例を追加。昼勤・配属解除・夜勤予定の従来の4判定も維持し、47項目が成功した。
+
+`test_first_operating_day.gd` はディスク保存からのロード後、翌朝120分の営業を継続してから同じチェックポイントを再実行し、客・従業員・会計・イベントを含む状態digestが一致する検証を追加した。
+
+## 全件実行の範囲
+
+`tests/**/test*.gd` と `tests/run_tests.gd` を全件確認。`test_kernel_and_save.gd` は単独起動用ではなく `run_tests.gd` から呼び出すため、重複起動せず内包試験として実行する（ソース側79エントリーポイント）。書き出したPCKを必要とする `tests/export/test_exported_opening.gd` は配布アプリ生成後に別途実行。通常の `make test` の呼び出しに含まれていなかった交通比較試験も対象とする。
+
+再実行用に `tools/run_all_tests.py` と `make test-all` を追加した。失敗で後続試験を打ち切らずログと一覧を残し、1件でも失敗すれば非ゼロで終了する。ユーザーの通常セーブを使わず、既存試験の専用保存先を使用する。
+
+## 通しデバッグの範囲
+
+全ソース試験成功後、通常の描画を有効にした実シーンで、次を順番に確認し、すべて成功した。
+
+1. 初期資金から受付・客室・階段を建設し、雇用・配属、自然入客、宿泊売上、翌朝決算、ディスク保存・ロード、翌朝の営業継続と一致再実行。
+2. 初期資金から倉庫・厨房・食堂を建設し、食材購入、運搬員の実移動、調理、配膳、自然入客の売上、搬送途中の保存復元、3営業日の仕入れ・給与・会計照合。
+3. エレベーターの建設・増設、実際の乗車・到着、乗車途中の保存復元。
+4. 客と職員のドットアニメーションの連続描画。
+
+これは自動操作・実描画による上記シナリオのデバッグであり、未実装のシナリオ内容や全ルートを完走した意味ではない。各結果・画像・ログは `artifacts/debug-2026-09-27/` に保存する。
+
+全件試験内の3営業日供給受入: 49項目成功。食堂売上3,000G、原材料配送30便、料理配送72便、残金2,855G。約746秒で完了。これは全件通過後の描画付き再検証とは別に記録する。
+
+## 全件試験結果
+
+ソース側79エントリーポイント・6,850チェック、全件PASS。配布PCK起動13チェック、2万セルのフル負荷試験24チェックも全件PASS。`all-tests-summary.json` に重複のないソース側集計を保存。全件成功を確認後に描画付きの通しデバッグを開始した。
+
+配布アプリ本体はソース外の `/tmp` を作業場所として `--headless --quit-after 5` で正常起動・終了（終了コード0）を確認した。初回の検証用 `--main-pack` 指定はreleaseテンプレートの仕様により拒否されたため、その試行を合格に数えず、通常の内蔵PCK起動で再確認した。配布PCKの13項目は別途開発用Godotから実行して合格。
+
+## 通しデバッグの最終結果
+
+|描画付きシナリオ|結果|
+|---|---|
+|新規開始〜翌朝決算〜保存ロード〜翌朝の営業継続・一致再実行|46チェック成功|
+|仕入れ・実搬送・調理・販売・3営業日の給与と会計照合|49チェック成功|
+|昇降機建設・増設・乗車・到着・途中保存と客の重複描画防止|32チェック成功|
+|ドットアニメーション|72フレーム取得、実画像を確認|
+
+供給シナリオの描画あり・なしで、所持金2,855G、食堂売上3,000G、宿泊売上、配送件数（原材料30便・料理72便）、3日分の決算が一致。3日とも帳簿照合済み・給与未払0。画面は開業案内、ロード後の翌朝帳簿、厨房、配送、昇降機内の乗客、客・職員のアニメーションを確認した。
+
+今回の全件修正と上記範囲の通しデバッグを完了した。既知の4失敗は解消され、通し実行で新たな失敗は発生しなかった。テスト対象ソースのハッシュが実行後も一致することを確認済み。
+
+- [全件集計](../artifacts/debug-2026-09-27/all-tests-summary.json)
+- [完了記録](../artifacts/debug-2026-09-27/completion.json)
+- [通しアニメーション](../artifacts/debug-2026-09-27/walkthrough.gif)
+- [翌朝の帳簿画面](../artifacts/debug-2026-09-27/opening-images/second-morning.png)
+- [昇降機の画面](../artifacts/debug-2026-09-27/elevator-cabin.png)
+
+起動先は `build/macos/TheTree-Verified-2026-09-27.app`。ローカルとGoogle Drive双方の `TheTree-ドット版を起動.command` をこの検証済み版へ更新した。旧アプリと通常プレイのセーブは保持している。Windows実機や未実装ルートの完走を今回の完了範囲に含めない。

docs/DEVELOPMENT_BACKLOG.md

@@ -1,5 +1,11 @@
+> 原本優先: 利用者指定の基本仕様書と施設パラメータ訂正が本書に優先します。現在の差異・未完了項目は [原本との実装対応](traceability/original/IMPLEMENTATION_STATUS.md) を参照してください。
+
+2026-09-29救護追記: 医療職の回収→裏通路・扉・階段での搬送→医務室治療、体力/救護状態UI、保存復元を接続。[検証記録](traceability/original/STAFF_RESCUE_VERIFICATION_2026-09-29.md)。同伴エレベーター乗車と待機室での休息を追加実装。[続報](traceability/original/LABOR_COMPLETION_2026-09-29.md)。
+
 # 制作課題台帳
 
+2026-09-29追記: 原本B-4.2の最大欲求優先AIを実装し、HUDへ来客観察パネルを追加。関連627項目を再検証し、配布版を更新した。[検証記録](traceability/original/GUEST_AI_VERIFICATION_2026-09-29.md)。天候等は継続残件。救護搬送の現行版統合は下記参照。
+
 更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。その後、有料仕入れ・厨房の自律生産・実配送を通常の商品UIへ接続した。供給込み3営業日の自動受入45項目も合格した。部品の接続、単日成立、段階全体の完成を区別する。
 
 ## 状態の読み方
@@ -58,6 +64,12 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
 
 ## P3：営みと初見の操作
 
+2026-09-29追記: T2-V01〜V05の表示改善を実装。施設状態・室内利用位置・共用通路の待機列・初期カメラと営業階への復帰・実乗客と満員表示を接続した。[最新検証と配布版](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。下記の9月28日の残件記述は履歴。P1〜P5全体、Windows実機性能、原本の未実装項目が完了したという意味ではない。
+
+実機記録の受領後: [Windows実機レビュー](THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md) に基づき、T2-V03の一部として「画面移動」ボタンと左ドラッグを実装。建設・掘削との排他切替、Esc解除、ドラッグ取り残し防止を関連370項目で確認。初期カメラ・列・施設状態・混雑表現の改善は引き続き残件。
+
+2026-09-28追加: ユーザー提供の『The Tower 2』を参考資料として確認。[T2-V01〜V05](THE_TOWER_2_REFERENCE_2026-09-28.md) を表示改善の残件とする。施設状態の内装表現、施設別利用位置と待機列、初期カメラ、昇降機の混雑表現を順に改善する。参照調査は完了、これらの改善実装・受入は未完了。LIFE-02の古い足スライス方式は現在の横向き専用ポーズへ置換済みであり、[2026-09-27の描画変更記録](PIXEL_ANIMATION_2026-09-27.md) を現状の根拠とする。
+
 | ID | 現在地 | 次の完了判定 |
 |---|---|---|
 | LIFE-01 | **一部実装済み**。Runtime位置、サービス中位置の描画投影、待機・利用・作業Badge、停止 | 実状態に基づく歩行／待機／利用／睡眠／清掃／運搬／休憩の一覧と利用位置を確定する |

docs/IMPLEMENTATION_STATUS.md

@@ -1,8 +1,10 @@
 # 実装状況
 
-この文書は仕様書そのものではなく、現在のコードがどこまで到達しているかを記録する。ゲームルールの正本は `GAME_SPECIFICATION.md`、System境界と不変条件の正本は `SYSTEM_SPECIFICATION.md` とする。
+この文書は仕様書そのものではなく、現在のコードがどこまで到達しているかを記録する。利用者指定の基本仕様書が原本であり、`GAME_SPECIFICATION.md` と `SYSTEM_SPECIFICATION.md` は派生資料として扱う。現行の判定は [原本との対応](traceability/original/IMPLEMENTATION_STATUS.md) を参照。
 
-更新日: 2026-09-09。ドット断面版の基準コミットは `423fd6dd2e75da926e38b35ac8c435e462b168d9`。復旧方法は [RECOVERY_GUIDE.md](RECOVERY_GUIDE.md)、承認済み制作計画の課題と検証残は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) を参照する。
+以下は2026-09-09時点の履歴。00:00決算・x3・同伴救護・待機室休息の現行記録は [労務検証](traceability/original/LABOR_COMPLETION_2026-09-29.md) と原本対応表を優先する。
+
+旧更新日: 2026-09-09。ドット断面版の基準コミットは `423fd6dd2e75da926e38b35ac8c435e462b168d9`。復旧方法は [RECOVERY_GUIDE.md](RECOVERY_GUIDE.md)、承認済み制作計画の課題と検証残は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) を参照する。
 
 以下のSystem別一覧は既存の実装・試験記録を引き継いでいる。直前のドット版変更では起動とUI・カメラの359項目、その後の配属APIでは103項目の個別確認記録がある。P1追加後に `make check` と `make test` の全構成ターゲットを2群に分けて実行し、全件が成功終了した。追加の配属API103項目、スタッフ画面44項目、通常開業35項目も合格。対象と制約は [P1単日検証記録](qa/P1_FIRST_OPERATING_DAY.md) に記録した。通常初期予算での最小宿は単日受入・保存復元を確認したが、14日MVP、Windows実機性能、通常操作だけによる3営業日は別の完成条件として残る。
 

docs/PIXEL_ANIMATION_2026-09-27.md

@@ -0,0 +1,20 @@
+# ドットアニメーション表示の修正（2026-09-27）
+
+通常の制作先 `/Users/korizatou114/Projects/とりにく工房ゲーム制作部` を変更した。Google Drive側の旧ソースは混在を避けて上書きせず、ローカルの修正版アプリを開く `TheTree-ドット版を起動.command` を双方に配置した。
+
+## 変更
+
+既存の部屋・家具・階層のドット断面表示とKenney素材を維持し、人物を専用の横向き16×18グリッド描画に変更。静的アトラスの足部分の移動から、8段階の脚・腕・上下動による歩行へ置き換えた。清掃、作業、食事、荷物運搬、睡眠、気絶を状態に応じて描き分ける。左右反転、既存の移動補間・速度・一時停止に対応。シミュレーションの位置や経済は変更しない。
+
+既存Kenney素材には横向きの専用歩行フレームがないため、人物のみコードで独自のポーズを描画する。Kenneyの部屋用素材とライセンスは保持。The Towerの画像・キャラクターは使用していない。
+
+## 検証
+
+- ピクセル表示・カメラ等の既存試験238項目、ダッシュボード121項目成功。
+- `make check` 成功。
+- 1440×810、2倍ズームの実運営画面を確認。6秒・12fpsの72フレームを取得し、72枚すべて異なることとワールド領域の変化を確認。ポーズ別の網羅的映像受入ではない。
+- macOSアプリを書き出し、ソース非依存のPCK起動・初回建設13項目成功。今回は描画変更の関連試験を行い、ゲーム全体の全試験は再実行していない。
+
+[動画プレビュー](../artifacts/pixel-animation-2026-09-27/preview.gif) / [確認画像](../artifacts/pixel-animation-2026-09-27/preview.png)
+
+起動用アプリ: `build/macos/TheTree-Pixel-2026-09-27.app`。過去の配布アプリは上書きしていない。Windows版は今回再配布していない。

docs/PIXEL_TOWER_VISUALS.md

@@ -22,8 +22,11 @@ make test-pixel-ui  # ドット表示・カメラ・実施設クリックの回
 
 | 操作 | 動作 |
 |---|---|
+| 上部の来客ボタン | 客を選び、四欲求・所持金・忍耐・現在の目的地を確認 |
 | ホイール | カーソル付近を基準に拡大・縮小 |
 | 中ボタンドラッグ | 断面を移動 |
+| 画面移動ボタン → 左ドラッグ | 断面を移動。再度ボタンを押すかEscで解除。建設・掘削選択時も解除 |
+| 営業階 | 現在の層の建設済み施設にカメラを合わせる（最大200%） |
 | Home | 全体表示へ戻す |
 | G | 格子と混雑表示を切り替え |
 | B | 建築パレットを開閉 |
@@ -31,27 +34,34 @@ make test-pixel-ui  # ドット表示・カメラ・実施設クリックの回
 | H | 雇用候補を開閉 |
 | Tab | 客用の表層 / 裏方の裏層を切り替え |
 | E / R | 掘削モード / 建築物を回転 |
-| Space / 1・2・4 | 停止・再開 / 時間倍率を変更 |
+| Space / 1・2・3 | 停止・再開 / 時間倍率を変更 |
 | Esc | 雇用候補・使用中のツールを解除。ツール未使用時はパネルも閉じる |
 | 施設をクリック | 営業・待機列・人員などの実状態を右側に表示 |
 
-初期状態では建築パレットと運営詳細を閉じ、マップを広く見せる。詳細はマップ右側に重ねて開く。判断が必要なイベントは詳細パネルを開き、選択肢を表示する。案内は下部に常時表示する。
+初期状態では建築パレットと運営詳細を閉じ、空の宿は入口付近を200%で表示する。施設がある場合は施設範囲へ合わせる。プレイ中は自動でカメラを追従させず、必要な時に「営業階」を押す。詳細はマップ右側に重ねて開く。判断が必要なイベントは詳細パネルを開き、選択肢を表示する。案内は下部に常時表示する。
 
 ## 現在の表示
 
 - 世界樹、空、幹、葉、床と室内をドット主体で描く。受付のカウンター、客室のベッド、食堂の卓、厨房などを施設ごとに描き分ける。
 - 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上の実在人物で、移動元と現在セルの間を補間する。同じ元絵の足のずらし・上下動・左右反転で歩行を表現し、待機・利用・作業の小さな状態表示を添える。停止中はアニメーションも止まり、人物位置は確定セルを表示する。
+- 客と従業員はRuntime上の実在人物で、移動元と現在セルの間を補間する。独自の横向きドット人物の歩行・待機・食事・睡眠・清掃・作業・運搬ポーズで表現する。停止中はアニメーションも止まり、人物位置は確定セルを表示する。
 - UIは濃緑・クリーム・木色の小さな平坦な枠を使用する。従来の高解像度生成背景・人物Bust・装飾Skinは現在のマップに使用しない。小型のUIアイコンは既存Theme参照を残す。
 - ズーム・移動・表示レイヤー・格子の切替は描画側だけで扱う。建築の占有セルや保存データの形式は変えない。
 
 ## 制約と次の制作
 
-- Kenneyの導入パックは静止画である。現在の歩行はコードによる元絵の加工であり、手描きの歩行・食事・清掃・運搬の専用アニメーションは今後追加する。Atlasで隣にいる別人物を歩行差分として再生していない。
-- エレベーター本体の昇降・乗降・待ち行列を含む運行は未実装。施設カタログの昇降機は接続の試作用で、見学では既存の上階通路を使って人物の行動を確認する。
+- 人物は `pixel_people.gd` の独自ポーズを使う。Kenneyは家具・小物などに使用し、原作ゲームから抽出した画像は配布物に含めない。
+- エレベーターは実運行・乗降と連動する。待機者は歩ける乗り場の外側へ並べ、実乗客はかご内だけに描画する。定員・満員・停止と待機人数を表示する。入りきらない人数は重ねず「他N人」で示す。
 - 見学は在庫を用意した再現用の運営場面であり、収支・配送・混雑の完成度を保証する受入試験ではない。キャプチャにはその時点の実状態が出る。
 - 施設ラベルは表示幅・選択・ホバーに応じて省略する。大きい世界を全体表示すると縮小されるため、人物の動きはズームして確認する。
 
 表示の主な実装は`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`は実受付の建設・完工を経由して、ズームと移動後の占有セル命中、表裏の選択、地下を含む座標往復、停止時アニメーション、描画操作前後のシミュレーションダイジェスト不変を確認する。
 
 接客・宿泊サービス中の客は、経路上のアクセスセルから施設内の利用位置へ描画上だけ投影する。経路探索、権威セル、保存状態は変更しない。
+
+2026-09-29: 未稼働は暗い内装、破壊・摘発後の休止は閉鎖線と文字、稼働中は実利用人数と照明で識別する。利用位置と家具を共通化し、人物を同じ枠へ循環配置しない。`customer_capacity` と在庫容量は区別する。描画は稼働状態・料金・休止解除条件を変更しない。[実装・検証記録](THE_TOWER_2_COMPLETION_2026-09-29.md)。
+
+
+2026-09-29: 救護中の患者を担当医療職の位置に重ねて表示し、医務室治療中はベッドに表示。治療人数は実タスクから集計。従業員パネルに体力と救護段階を表示。
+
+2026-09-29続報: 業務用EVは患者と救護者の2席を表示。待機室は到着済みの非番従業員を室内に描画し、休憩人数を表示する。状態ラベルも実際の移動・到着に連動する。

docs/PLAYTEST_GUIDE.md

@@ -12,7 +12,7 @@
 | エディター | `make editor` | 開いた後に実行ボタンまたはF5で起動 |
 | 建設済みの宿を見学 | `make preview-pixel` | 受付、食堂、厨房、客室、通路、実際の客・従業員を用意。保存なし |
 | 時間差の画像を出力 | `make capture-pixel` | `artifacts/pixel-tower/` にPNG 2枚と運営状態JSONを生成 |
-| 通常開業の単日受入 | `make test-opening` | 見学Fixtureなしで通常UIのCommand経路を使い、初売上・翌06:00・保存復元を検証 |
+| 通常開業の単日受入 | `make test-opening` | 見学Fixtureなしで通常UIのCommand経路を使い、初売上・00:00決算・翌朝・保存復元を検証 |
 | 仕入れ・厨房・配送をすぐ試遊 | `make preview-supply` | 初期予算から通常建設・実購入した宿を12:20まで進め、停止して開く。Spaceで再開。保存なし |
 | 有料仕入れ・厨房・配送の検証 | `make test-supply` | 通常予算から供給を接続し、配送途中保存と3営業日の運営を検証 |
 | 稼働中の商品パネルを撮影 | `make capture-supply` | 通常建設・実購入で用意した初日の仕入れ／厨房／配送をPNG出力 |
@@ -42,7 +42,7 @@
 | 開業ガイドを折り畳む | マップ左上の「開業の手引き」の見出しをクリック |
 | FRONT／BACK切替 | 下部の「客用・表層」「裏方・裏層」、または `Tab` |
 | 一時停止／再開 | 上部の「停止／再開」、または `Space` |
-| 速度変更 | 上部のx1／x2／x4、または `1`、`2`、`4` |
+| 速度変更 | 上部のx1／x2／x3、または `1`、`2`、`3` |
 | 拡大・縮小 | マップ上でホイール。カーソル付近を基準に拡縮 |
 | 断面を移動 | マップ上で中ボタンドラッグ |
 | 全体表示に戻す | `Home` |
@@ -72,29 +72,29 @@
 3. 「客用階段」を `(-4, 2)` へ配置し、10ゲーム分進めます。続いて「客用階段」を `(-4, 3)` に、「客用通路」を `(-8, 3)`、`(-7, 3)`、`(-6, 3)`、`(-5, 3)` に置き、さらに10ゲーム分進めます。階段は3セル、横の通路は4セルです。
 4. `Esc`で建築を解除します。左の「従業員」から「候補を見る」または `H` で雇用候補を開き、受付係のアカネを雇用します。契約金と日給を確認してください。
 5. 「雇用済み」を開いてアカネを選び、配属先を建てた受付、勤務帯を「日勤 06:00〜18:00」にして「配属・勤務帯を変更」を押します。成功表示を確認し、時間進行中の予約Commandなら次の処理まで待ちます。勤務帯は翌日以降も繰り返す計画として保存されます。
-6. `Space`で再開し、必要なら `1`または`4`で速度を選んで、自然に到着した客の宿泊を観察します。現在の宿泊サービスは完了時に売上を記帳するため、到着直後に宿泊売上が出るとは限りません。客が来ない・利用されない場合は施設を選び、接続と人員の理由を確認します。
-7. 翌朝06:00まで進め、左の「帳簿」で第1営業日の確定値を選びます。売上、運営費（契約金等）、給与、営業利益、未払、施設別損益、照合結果を確認します。00:00はまだ同じ営業日です。
+6. `Space`で再開し、必要なら `1`または`3`で速度を選んで、自然に到着した客の宿泊を観察します。現在の宿泊サービスは完了時に売上を記帳するため、到着直後に宿泊売上が出るとは限りません。客が来ない・利用されない場合は施設を選び、接続と人員の理由を確認します。
+7. 00:00まで進め、左の「帳簿」で第1営業日の確定値を選びます。売上、運営費（契約金等）、給与、営業利益、未払、施設別損益、照合結果を確認します。00:00に前日を締め、06:00に再度締めることはありません。
 8. 通常モードの下部「保存」で結果を確認し、その後に時間を進めて「読込」を押します。時刻、配属計画、決算、開業達成表示が保存時点へ戻ることを確かめます。手動UIは `user://saves/manual_ui` の1枠です。
 
 この経路はUIの建築・雇用・配属処理から実行する自動受入で確認しています。受入の途中保存は通常スロットへ触れず、専用 `user://tests/first_operating_day_<process_id>/restore-check` を使用して復元後に整理します。実ユーザーによる初見30分の試遊合格や、見学Fixtureを使わない3営業日の完成とは別の判定です。
 
-現在の配属は経路が存在することを事前検証してから論理的に確定します。配属操作だけで人物の位置は変えず、職場まで実際に通勤して到着後に人員として稼働する統合は今後のMOVE課題です。
+現在の配属は経路が存在することを事前検証してから論理的に確定します。配属操作だけで人物の位置は変わりません。職場まで実際に通勤し、到着後に稼働人数へ加わります。
 
 ## 単日確認の結果と読み方
 
-Seed `424242`、通常初期予算、受付1・一般客室2・通路7・アカネ1人の受入で、次を確認しました。客・サービスの直接挿入、無料の在庫追加、見学Fixtureは使っていません。
+Seed `424242`、通常初期予算、受付1・一般客室2・客用階段3・通路4・アカネ1人の受入で、次を確認しました。客・サービスの直接挿入、無料の在庫追加、見学Fixtureは使っていません。
 
 | 確認項目 | 結果 |
 |---|---|
-| 自然来客による宿泊売上 | 320G |
-| 受付売上 | 6,020G |
-| 翌06:00の給与 | 120G |
+| 自然来客による宿泊売上 | 240G |
+| 受付売上 | 0G |
+| 00:00の給与 | 120G |
 | 未払給与 | 0G |
-| 全体の営業利益 | 6,040G |
+| 全体の営業利益 | -60G |
 | 帳簿照合 | 一致 |
 | 専用テスト保存からの復元 | 決算値・配属・開業達成を復元 |
 
-受付売上が大きく、現在の数値は製品版の黒字基準や推奨バランスではありません。価格、受付の会計上の役割、宿泊料金の決済・記帳タイミングは仕様との差を調整する必要があります。建築出金は資金増減として表示し、営業利益から分けています。また、06:00の給与支払は新営業日の現金出金に、前営業日の給与費用は確定決算に表示されます。
+2026-09-29の描画付き受入結果です。契約金180Gと給与120Gを差し引いた営業利益は-60G。建築出金は資金増減として表示し、営業利益から分けています。これは固定シナリオの検証値であり、推奨バランスではありません。日次決算・給与計上は00:00です。
 
 `make capture-opening` の出力は `artifacts/first-operating-day/opening.png`、`staffed.png`、`first-close.png` です。開始画面、配属後、翌朝の帳簿を比較できます。
 
@@ -146,7 +146,7 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
 
 `make preview-business` で、通常予算から建てた供給可能な宿を開く。Spaceで再開し、左「営業」から食堂の料金を変える。値上げ前に受付済みの客は元の見積額を払い、新しく検討する客には新料金が反映される。休業すると新規受付が止まり、待機客は別の施設を探す。すでに利用中の客はサービスを完了する。給与は休業中も発生する。
 
-商品で仕入れ・厨房・配送、帳簿で翌06:00の給与と施設別利益を確認する。この試遊は保存なし。新設の標準料金は食堂25G・客室120G・受付無料。旧保存の既存施設は保存された基準料金を引き継ぐ。検証結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。
+商品で仕入れ・厨房・配送、帳簿で00:00の給与と施設別利益を確認する。この試遊は保存なし。新設の標準料金は食堂25G・客室120G・受付無料。旧保存の既存施設は保存された基準料金を引き継ぐ。検証結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。
 
 ## 昇降機と通勤の試遊
 
@@ -162,3 +162,10 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
 完成した昇降機をクリックすると、かごの現在階、人数、待機人数、運行の停止／再開が表示されます。最近の乗車記録の平均待ちと95%の待ち時間、現在の最長待ちも確認できます。平均・95%は保持中の乗車サンプルなので、詳しい集計範囲は表示のツールチップを確認してください。
 
 以前のセーブの上下通路は、読み込むと「既設の階段」として同じ移動時間・利用権限で使えます。小さな階段マークをクリックして接続階を確認できます。その足場を撤去した後に新しい普通の通路を置いても階段は戻らないため、必要なら階段施設を建設します。
+
+
+## 非番の休息と救護
+
+非番の体力回復には、稼働中の裏層の待機室と到達経路が必要です。従業員は実際に移動してから休憩します。体力0の従業員には、医務室と医療職テッサを用意してください。患者と救護者は業務用EVの二人分の席を使用し、同じ便で乗降します。
+
+[労務・同伴救護の検証](traceability/original/LABOR_COMPLETION_2026-09-29.md)

docs/SYSTEM_PERFORMANCE_2026-09-27.md

@@ -0,0 +1,50 @@
+# システム処理の精査と軽量化（2026-09-27）
+
+対象は通常制作先 `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。既存のドット人物アニメーション変更を保持した。
+
+## 精査結果と変更
+
+|対象|確認した処理|対応|
+|---|---|---|
+|PathService._run_a_star|最小コスト候補を毎回全件走査。昇降機等の接続がある場合はヒューリスティック0となり、広い候補集合を繰り返し走査する|問い合わせ内だけの最小ヒープへ変更。同コスト時のx/y/層の順序、より良い親による再探索、動的混雑コスト、アクセス権、通行停止を維持。古い候補は取り出し時に棄却|
+|WorldPreview._service|セルの位置計算からRuntimeの全プロパティ一覧を何度も生成・走査|1回の描画内で取得済みサービスを再利用|
+|WorldPreview._world_bounds / _cell_dimensions / get_map_rect|同一フレームの全セルで同じ境界・拡大率・矩形を再計算|描画開始で空にしたキャッシュを共有し、描画終了で破棄。カメラ操作・保存復元・Runtime再設定を跨いで保持しない|
+|Runtime._publish_snapshot / create_snapshot|毎分の各システム状態と履歴の複製・digest生成|保存整合性・イベント配信・決定性に関わるため頻度を変えない。既存digest性能テストを確認対象にした|
+|FacilityService.advance_one_minute|施設状態評価、稼働中サービスの更新・完了・補充|完了コールバック中の変更検査と処理順を維持。今回は業務更新の省略を行わない|
+|Runtime._advance_runtime_path_traffic|客・職員の決定的順序での移動、昇降機待ち|順序を維持。内部で利用する経路探索の改善を適用|
+
+ヒープの領域は問い合わせ終了で解放される。描画キャッシュは次フレームまで残さない。セーブ形式・ゲーム内時間の進み方・料金・キャラクターの位置は変更していない。
+
+## 計測方法
+
+同じプロセス内で変更前の線形探索と変更後を比較。1,200セル、固定シードの120経路、通行停止・動的コスト・層間接続・アクセス拒否を含む。経路配列、コスト、到達不能理由、最終スナップショットが一致することを検証した。旧アルゴリズムはテスト用fixtureに限定して保持。
+
+描画は1200×700の実SubViewportを使用。初期世界、停止中、描画命令発行のCPU時間を35フレーム測定し、先頭5フレームを除外。同じ画像になることをピクセル比較した。GPU時間・画面全体のFPS・長時間運営の総所要時間の測定ではない。
+
+追加試験 `tests/performance/test_system_optimization.gd` は282項目。カメラ0.5/1/2/4倍で座標の一致も比較する。`make test-perf` に組み込んだ。時間の絶対値をテストの成否条件にせず、機器負荷による不安定な失敗を避ける。
+
+## 既存の失敗
+
+`tests/ui/test_staff_management.gd` の職員配置ガイドに関する4項目が失敗。軽量化前のPathServiceとWorldPreviewを戻した独立コピー `/tmp/thetree-performance-baseline` でも同じ4項目が失敗することを確認した。これを軽量化の成功に含めず、既存テストの失敗として別件に残す。
+
+計測・検証ログは `artifacts/performance-2026-09-27/`。新アプリは `build/macos/TheTree-Optimized-2026-09-27.app`。旧版アプリは上書きせず保持する。
+
+## 計測結果
+
+|対象|変更前|変更後|条件|
+|---|---:|---:|---|
+|経路120件・3回の中央値|1,417 ms|908 ms|約36%短縮。3回の比率は0.638〜0.650|
+|描画CPUの中央値|74.251 ms|1.272 ms|初期世界30フレーム。画像は完全一致|
+|描画CPUのp95|77.452 ms|1.290 ms|GPU・全体FPSを除く|
+
+絶対時間は開発マシンの負荷に左右される。ゲーム全体が同じ割合で速くなったことを示す数値ではない。
+
+`make check`、macOS書き出し、配布PCKの初回建設13項目を通過。起動コマンドは新しい軽量化版アプリへ更新済み。
+
+## 最終検証結果
+
+経路・ワールド、職員・客、保存、運営、UI、初日運営、digest・性能試験を実行。重複した比較ベンチマーク3回と配布PCK試験を除き、集計は3,651チェック、うち3,647成功・既存の4失敗。失敗は上記の職員配置ガイドに限定。追加282項目はこの集計に含む。詳細は `artifacts/performance-2026-09-27/regression-results.json`。`make test` 全体の実行ではない。
+
+## 後続修正
+
+上記の既存4失敗は、階段必須仕様に対して試験用建物が上下を通路だけで接続していたことが原因だった。試験用建物に実階段を配置し、未接続時の負例も追加して修正済み。後続の全79エントリーポイント・6,850チェックはすべて成功。詳細は [全件修正・通しデバッグ](DEBUG_COMPLETION_2026-09-27.md) を参照。上記の3,647成功・4失敗は修正前の検証履歴として残す。

docs/THE_TOWER_2_COMPLETION_2026-09-29.md

@@ -0,0 +1,62 @@
+# The Tower 2を参考にした表示改善：実装と検証
+
+2026-09-29。対象は参照調査で整理したT2-V01〜V05。制作・書き出しは `/Users/korizatou114/Projects/とりにく工房ゲーム制作部` で実施した。原本全体の完成とは区別し、原本の未実装項目は [実装対応表](traceability/original/IMPLEMENTATION_STATUS.md) に残す。
+
+## 変更した動作
+
+| ID | 実装結果 | 根拠 |
+|---|---|---|
+| T2-V01 | 未稼働は暗い内装と閉鎖線、破壊・摘発後の休止は遮断線と文字、稼働は利用人数と照明で表示。実サービスの顧客IDを集計する | `room_presentation.gd`、状態別の実描画、94項目の表示回帰 |
+| T2-V02 | 客室・飲食施設の家具と利用位置を共通化。実利用者を安定したID順で置き、描画枠を循環させない。待機列は歩行可能な隣接通路へ配置し、隣接する列同士も同じ場所を使わない。収まらない人数は「他N人」で示す | 狭い部屋・6人・9人の列・複数入口の共有通路の回帰。従業員は実際に現地にいる時のみ作業台へ表示 |
+| T2-V03 | 新規開業は入口付近を200%で表示。「営業階」で建設済み施設へ合わせ、Homeで全体へ戻せる。画面移動ボタン・左ドラッグを維持 | 通常予算の開業53項目、Pixel243項目、Dashboard127項目。拡大と座標命中、解像度変更、各操作モードを確認 |
+| T2-V04 | 実際の待機者は乗り場外、乗車中はかご内だけへ描画。実乗客数・定員・満員・停止を表示し、待機人数と分離 | 実ElevatorServiceへ9件を要求し、4人乗車・5人待機の描画を確認。輸送と保存の既存回帰も実行 |
+| T2-V05 | 停止・速度・ズーム・表裏切替・保存復元を回帰。手動読込では表示用の移動履歴を破棄して復元状態から再描画。同一状態の描画時間を比較 | 下記の全体試験・実描画・測定・配布物確認 |
+
+利用人数には `customer_capacity` を使い、保管量・生産量の `capacity` や待機人数と混同しない。描画は料金や稼働条件を変更せず、休止の自動解除も追加しない。原作ゲームの画像・実行ファイルは配布物に含めず、独自人物と既存Kenney素材を使う。
+
+## 検証結果
+
+全83本の試験は、修正後の再試験を含めて **83本PASS・未解決の失敗0**。最終集計は [verification-summary.json](../artifacts/tower2-completion-2026-09-28/verification-summary.json) に保存した。初回は82本PASS・供給シナリオ1本に修正前の列配置の型エラーを記録。最終コードで当該シナリオを再実行し、49項目・エラー0・終了コード0を確認した。初回ログは削除せず、再試験への対応を最終集計に記録している。
+
+- 3営業日の通常供給シナリオ: **49項目PASS**。自然来客の食堂売上3,000G、原料配送30便・料理配送80便、現金2,855G。各日の給与未払0・帳簿照合一致、配送途中のディスクSaveと最終状態の復元を確認。
+- 新しい室内・列・実乗車・復元・カメラ回帰: **94項目PASS**。
+- 通常初期予算から建設・雇用・営業・決算・翌朝までの実描画付き受入: **53項目PASS**。
+- `make check` と `git diff --check`。エディター読み込みと通常起動を確認。
+- macOS / Windowsの出力PCKをソースフォルダーに依存しない別ディレクトリで検証: **各13項目PASS**。全18施設の読込、受付選択、実建設、500G支出、完工、次の案内を確認。
+- macOS配布実行ファイルを実描画で起動して正常終了。Windows向けEXE/PCKは書き出し済みだが、今回のWindows実機起動・入力・FPS測定は未実施。
+
+### 描画時間
+
+Apple M4 / Godot 4.7.2 / Compatibility / 1440×810 / 200%表示。同じ一時停止中の状態を、変更前と変更後で各80フレーム描画し、先頭10を除く70点を比較。前後のSimulationDigest一致も確認した。
+
+| 表示人数 | 変更前 中央値 / P95 | 変更後 中央値 / P95 |
+|---|---|---|
+| 6人 | 1.750 / 1.915 ms | 1.928 / 2.041 ms |
+| 200人 | 4.390 / 4.595 ms | 4.431 / 4.550 ms |
+
+200人の中央値増加は約0.9%。施設の状態と列情報を一描画内で共有し、輸送レポートも一度だけ取得する。これは `_draw` のCPU処理時間であり、GPUを含む全フレーム時間・Windows性能・長時間AI負荷の達成値ではない。200人は計測用に作成した静止した実GuestRuntimeであり、200人が自律営業した記録ではない。同時に他の回帰試験も動いていたため微小差を性能改善とは断定しない。
+
+## 実画面と記録
+
+- [稼働中](../artifacts/tower2-completion-2026-09-28/operating.png)
+- [未稼働](../artifacts/tower2-completion-2026-09-28/inactive.png)
+- [摘発後の休止](../artifacts/tower2-completion-2026-09-28/suspended.png)
+- [裏層](../artifacts/tower2-completion-2026-09-28/back.png)
+- [乗り場の待機列](../artifacts/tower2-completion-2026-09-28/lift-queue.png)
+- [4人乗車・5人待機](../artifacts/tower2-completion-2026-09-28/lift-full.png)
+- [通常開業の翌朝](../artifacts/tower2-completion-2026-09-28/opening-images/second-morning.png)
+- [描画測定JSON](../artifacts/tower2-completion-2026-09-28/draw-benchmark.json)
+
+状態比較画像は条件を固定した描画Fixture。昇降機画像では実Runtimeの有料建設後に検証用9人を生成し、魔力供給をFixtureから有効にして実輸送要求を発行した。通常経営での自然来客・魔力供給の受入とは区別する。通常開業53項目と供給の通し試験は別の実シナリオで確認する。
+
+## 配布ファイル
+
+- macOS: `build/macos/TheTree-Tower2-2026-09-29.app`
+- 起動用: `TheTree-ドット版を起動.command`（ローカルとDrive側の既存起動リンクを更新）
+- Windows: `build/TheTree-Windows-Tower2-2026-09-29.zip`。展開後 `build/windows-tower2-2026-09-29/TheTree.exe` を起動し、同梱PCKを同じフォルダーに置く。
+
+以前のビルドは保存したまま。証跡・ハッシュは上記artifactsフォルダーに保存する。
+
+## 残る範囲
+
+今回のT2表示改善は、原本の全施設・経済・人物物語・天候・全ランクの統合実装や、Windows基準機での長時間実測を完了したという意味ではない。狭い室内や長い列では全員を重ねて描かず人数表示にまとめる。施設ラベルは遠景で省略されるため、詳細確認は「営業階」または選択・拡大で行う。

docs/THE_TOWER_2_REFERENCE_2026-09-28.md

@@ -0,0 +1,72 @@
+# The Tower 2：提供ファイルの確認とThe Treeへの適用
+
+2026-09-29追記: T2-V01〜V05の実装・最新の検証範囲は [表示改善の完了記録](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。以下は2026-09-28時点の調査・受領記録として保存する。
+
+確認日: 2026-09-28。ユーザー提供のゲームファイルを、断面表示・人物表現・施設状態の見せ方の参考として調査した。ゲームの仕様は引き続き [基本仕様書原本](traceability/original/BASELINE.txt) とユーザーの施設パラメータ訂正を優先する。本書の改善案は実装完了を意味しない。
+
+追記: Windows側で作成された実機記録を受領し、[操作・動作の確認結果とThe Treeへの反映](THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md) を追加した。以下はそれ以前の静的調査記録。T2-V03の操作モード明示部分として「画面移動」ボタンと左ドラッグを実装済み。その他の残件は継続する。
+
+## 取得・調査範囲
+
+- [提供元のGoogle Driveファイル](https://drive.google.com/file/d/1ea5OeYIuvThC5YtTutjdbGlrZYF03QF4/view)
+- ファイル名: `The Tower 2.zip`、240,984,598 bytes、530エントリ。
+- SHA-256: `cf111aff88d59de6854f4bfbddff2af62b5345f3d4c67bf4c3f52a111e3fdec1`
+- 保存先: `/Users/korizatou114/Projects/reference-materials/the-tower-2/`。ZIP・抽出画像はゲームの配布用アセットに追加していない。
+- 主な内容: Windows実行ファイル1、DLL4、施設等の `.t2p` 338、MOV50、AVI10。一般的なPDF・HTML・TXT形式の説明書は一覧に見当たらない。
+- 選定した11ファイルから509リソースを列挙し、134ビットマップをPNGに変換。変換エラー0。施設・人物・昇降機・UIの主要画像を目視確認した。全338プラグインの精査ではない。
+- Windows実行環境が現在のMacにないため、ゲーム本体は未実行。フレーム順序、切替条件、歩行速度、経路選択、運行ロジック、実画面の配置は未検証。
+- `S02.avi` は240×180・15fps・28.8秒。抽出した画面は人物中心の映像で、ビル経営の操作画面ではない。ゲームプレイ映像として扱わない。
+
+再確認用の外部資料:
+
+- [ZIP全体の一覧](/Users/korizatou114/Projects/reference-materials/the-tower-2/archive-inventory.json)
+- [リソース一覧と画像寸法](/Users/korizatou114/Projects/reference-materials/the-tower-2/resource-inventory.json)
+- [代表画像の拡大比較](/Users/korizatou114/Projects/reference-materials/the-tower-2/inspect/selected-details.png)
+- [読み取り・画像変換スクリプト](/Users/korizatou114/Projects/reference-materials/the-tower-2/tools/inspect_resources.py)
+
+## 素材から直接確認したこと
+
+以下のIDはWindowsリソースの「種別/番号/言語」。画像全体の寸法であり、ゲーム内の表示倍率ではない。
+
+| 根拠 | 確認できた表現 | The Treeで参考にする点 |
+|---|---|---|
+| `Cafe.t2p`、`2/1000/1041`、96×108 | カウンター・椅子・棚のある内装と、人物の少ない／多い内装の差分が縦に並ぶ | 飲食施設は実際の利用人数を家具周辺に配置して見せる。看板だけで種類を区別しない |
+| `Office.t2p`、`2/1000/1041`、72×336 | 机・椅子・端末など、複数の内装と明暗差分 | 施設の用途が小さな断面でも読める家具配置。明暗差分の実際の切替条件は未確認 |
+| `Single.t2p`、`2/1000/1041`、32×240 | ベッド主体の小部屋に、明暗・寝具等の差分 | 客室の利用・睡眠・清掃状態を部屋内で伝える。各差分が何の状態に対応するかは未確定 |
+| `StdElev.t2p`、`2/200/1041`、28×160 | 空のかご、人物1人・複数人が入ったかご、停止を想起させる記号 | 乗車密度を可視化する。かごの人物は実乗客に対応させる |
+| `Sinjyuku.t2p`、`2/300/1041`、`2/350/1041`、各16×216 | 横向き人物の複数の手足の姿勢。ほかにも多数の人物画像がある | 小さい人物でも姿勢と向きで行動を伝える。画像の並びだけから再生順・fpsは決めない |
+| `T2.exe`、文字列32771〜32773 | 100%・50%・25%の表示倍率のラベル | 近景の営みと遠景の全体把握を両立する。The Treeの倍率を同じ値にする必然性はない |
+
+## 現在のThe Treeとの比較
+
+比較には、現在のソースと [2026-09-27の実描画キャプチャ](../artifacts/midnight-2026-09-27/opening-images/first-close.png) を用いた。キャプチャは今回の変更後の画面ではない。
+
+すでにあるもの:
+
+- `pixel_people.gd`: 横向き16×18の独自人物。歩行・待機・食事・清掃・作業・運搬・睡眠・気絶の姿勢。
+- `world_preview.gd`: 実位置に基づく移動補間、サービス利用中の室内描画、かごと乗客・扉の描画、待機人数表示。これらを未実装として作り直さない。
+- `pixel_tower_art.gd`: 施設別の家具、世界樹の断面、Kenney素材。世界樹の色調と表裏層は本作固有の表現として維持する。
+
+改善が必要な箇所:
+
+- 部屋の描画に利用人数や稼働状態が渡っておらず、稼働は主に小さい色ランプで示す。家具・照明・人の組み合わせから状態を読める余地がある。
+- サービス利用位置は共通の4枠循環。狭い部屋や5人以上の利用で同じ位置に重なり得る。施設ごとの利用場所・実定員に合わせる必要がある。
+- 待機人数のバッジと同一セルの人物オフセットはあるが、入口・乗り場に沿った整列を優先した表現ではない。
+- かごの人物描画には表示人数の上限がある。人数が上限を超えた際にも、密度と実人数を読み取れるようにする。
+- 開業時のキャプチャでは稼働している部屋が小さく、未開発の幹と管理パネルが大きい。初期カメラと詳細パネルを改善し、運営中の断面を眺めやすくする。
+
+## 次の実装・受入項目
+
+これは提供素材の分析から定めた改善順序であり、原作ゲーム内部の仕様を再現したものではない。
+
+| ID | 優先度 | 作業 | 完了を判定する画面・動作 |
+|---|---|---|---|
+| T2-V01 | 高 | 客室・食堂・受付の状態を内装、照明、家具と実利用者で表現 | 同じ施設で未稼働／稼働／破壊・摘発後の休止を識別。実利用0人／少数／満員の差を確認。休止から勝手に復帰させない |
+| T2-V02 | 高 | 施設別の利用位置と入口付近の待機列 | 小部屋・5人以上・複数入口・同じ階の隣接施設で人物が重ならず、待機者と利用者が区別できる |
+| T2-V03 | 高 | 初期カメラと観察時のUI占有面積を調整 | 通常初期予算から作る宿で、歩行・着席・就寝を拡大操作なしでも追える。管理パネル開閉・解像度変更で配置操作がずれない |
+| T2-V04 | 中 | 昇降機の乗り場待機と乗車密度を改善 | 待機→乗車→移動→降車を追え、乗車中の人物が廊下に重複しない。満員・停止も判別できる |
+| T2-V05 | 共通 | 人数・画面状態別の描画検証と性能測定 | 停止／速度変更／ズーム／表裏切替／保存復元で表示と実状態が一致。描画のための架空客や経済変更を追加せず、混雑時のフレーム時間を同条件で比較 |
+
+実装時は独自のドット表現と既存Kenney素材を使う。施設の「顧客同時利用最大人数」は保管・生産等にも使う `capacity` と区別し、待機列の人数とも混同しない。原本・ユーザー指定で未設定の料金加算率や休止解除条件を、参考ゲームから推定して確定しない。
+
+今回の変更は参考資料の取得・分析と制作資料への反映まで。ゲームコード、保存形式、配布アプリは変更していない。したがってゲームの全件PASSや通しデバッグ完了を新たに宣言するものではない。

docs/THE_TOWER_2_WINDOWS_REVIEW_2026-09-28.md

@@ -0,0 +1,47 @@
+# The Tower II Windows実機記録の受領と反映
+
+2026-09-29追記: T2-V01〜V05の実装・最新の検証範囲は [表示改善の完了記録](THE_TOWER_2_COMPLETION_2026-09-29.md) を参照。以下は2026-09-28時点の調査・受領記録として保存する。
+
+2026-09-28。ユーザーがWindows側で作成した実機確認資料を受領し、レポート全文・時刻ログ・主要スクリーンショットを確認した。本チャットでWindowsゲームを再操作した結果ではなく、提供された検証証拠のレビューである。
+
+## 受領物
+
+- [提供ZIP](https://drive.google.com/file/d/1ds7StSFXKCgILOHqt05RCO3BYSEn6e5J/view): `The-Tower-II-reference-record.zip`、10,674,377 bytes。
+- SHA-256: `4d0fd7f4c1e904b41444f0d6b7bf2b941049c02b915d3ab1efaf181f0ec632e1`。
+- スクリーンショット78枚、Markdown/HTMLレポート、時刻ログ、新規セーブ334,412 bytes。
+- セーブSHA-256は添付レポートの値と一致: `5a1f072eeaf8dcee364fa403235f45646ecb0bdef33c3fb9b3e3665f511ffca8`。
+- [受領レポート全文](/Users/korizatou114/Projects/reference-materials/the-tower-2/windows-reference-record/tower2-evidence/report.md)。元のZIP・画像・セーブは外部参考資料フォルダに保存し、配布ゲームへ混入させていない。
+
+## 確認された範囲と限界
+
+新宿西口副都心、ロビー＋オフィス7区画＋昇降機1基で、建設・手のひらドラッグ・倍率変更・一時停止と再開・人物の列・かご移動・別名保存後のアプリ再起動と読込が記録されている。
+
+| 記録 | 判断 |
+|---|---|
+| ロビーの階制限、下階からはみ出す建設の拒否、工事から内装への変化 | 配置制約と施工状態を操作直後に伝えることが重要。原作の制約や金額をThe Treeに追加する根拠にはしない |
+| 手のひらで約162pxのドラッグ、同程度の画面移動 | 移動ツールを明示し、左ボタンだけで断面を探索できる操作を採用する |
+| 倍率ツールの右クリックで寸法約半分、左クリックで元へ戻る | 概観と近景の行き来ができる。既存The Treeのカーソル基準ホイールズームを維持する |
+| 低速で20.263実秒に40ゲーム分 | 約1.97ゲーム分/秒は当該端末・区間のみの観測値。全速度や歩行フレームの確定値として使わない |
+| 1階の列、かご内人物、4階へのかご移動、後の列解消 | 移動需要を断面の人物で見せる。個体追跡、定員、乗降順序、満員の積み残しは未確認 |
+| 11:42に停止保存し、再起動後最初の画像が11:44・再生中。資金79,745万円、人口42人を復元 | 配置・主要数値の復元の証拠。人物ごとの状態・乱数の厳密復元や停止状態の維持を検証済みとはしない |
+
+画像 `21-boarding-0.png` の乗り場の列と上階のかご、`23-zoom-out-0.png` の広域表示、`28-reopened-2.png` の時刻・資金・人口をこのチャットでも目視確認した。レポートと画像の間の動作を新たな実測として補わない。
+
+## 今回実装した操作改善
+
+The Treeの下部ツールバーに「画面移動」ボタンを追加した。有効中は左ドラッグで断面を移動し、施設選択・建設クリックを送らない。もう一度押すかEscで通常操作に戻る。建設・掘削との切り替えは排他的とし、既存の中ボタンドラッグ、カーソル基準ズーム、Homeの全体表示も維持する。
+
+ドラッグ中にアプリのフォーカスを失った場合や、画面外でボタンを離してから戻った場合は移動を解除する。カメラ操作でシミュレーション時間やRuntime状態は変えない。
+
+変更先: `scenes/main/main.gd`、`scenes/main/world_preview.gd`。画像素材の追加やゲームルールの変更はない。
+
+## 検証
+
+- [カメラ・描画・実施設選択の回帰](../artifacts/tower2-reference-2026-09-28/pixel.log): 243項目PASS。左ドラッグ、誤選択抑止、画面外での解除、フォーカス喪失、操作後のRuntimeダイジェスト一致を含む。
+- [ダッシュボード回帰](../artifacts/tower2-reference-2026-09-28/dashboard.log): 127項目PASS。ボタン・建設・掘削・Escの切り替え、1280×720〜3840×2160の既存レイアウトチェックを含む。
+- [実描画](../artifacts/tower2-reference-2026-09-28/preview.png): 1440×810で下部ボタンと断面の表示を目視確認。時刻の異なる2枚を生成。
+- ゲーム全体の全試験は今回再実行していない。配布アプリも今回更新していないため、変更確認にはローカル制作フォルダから `make run` を使う。修正後のWindows実機操作は未実施。
+
+## 残る改善
+
+[T2-V01〜V05](THE_TOWER_2_REFERENCE_2026-09-28.md) のうち、今回完了したのはT2-V03の操作モード明示部分。部屋の状態表現、施設別利用位置と待機列、初期カメラ、昇降機の混雑表現、混雑時の性能比較は未完了。提供された原作の実機検証完了と、The Treeの改善実装完了を区別する。

docs/UI_OPERATION_SPECIFICATION.md

@@ -12,7 +12,7 @@
 
 | 領域 | 現在の情報・操作 | 表示状態 |
 |---|---|---|
-| 上部 | 営業日、時刻、時間帯、来客、宿泊予定、資金、Mana、資材、Faith、Heat、停止、x1／x2／x4 | 常設の小型HUD |
+| 上部 | 営業日、時刻、時間帯、来客、宿泊予定、資金、Mana、資材、Faith、Heat、停止、x1／x2／x3 | 常設の小型HUD |
 | 左側 | 従業員、施設、商品、探索、投資、帳簿の入口 | 常設の細いカテゴリ列。入口があるだけの準備中項目を含む |
 | 中央 | 世界樹の断面、施設の室内、客、従業員、工事、待機、混雑、6段階の開業手引き | 手引きは左上の見出しで折り畳める。断面を広く使用 |
 | 右側 | 運営概要、施設状態、雇用候補／雇用済み人物の配属、帳簿、要対応イベント | `I`、カテゴリ、施設選択で必要な内容を開く重ね表示。初期は閉じる |
@@ -79,15 +79,15 @@
 
 商品、探索、投資の準備中案内を完成した経営機能として説明しない。
 
-## 7. 時間進行と06:00決算
+## 7. 時間進行と00:00決算
 
 時間操作は上部の時計の近くへ置き、停止・通常・2倍・4倍を一操作で切り替える。重要な選択肢では右パネルを開き、選択と解決後の停止解除を接続する。
 
-Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を別の境界として扱う。帳簿は当営業日の現金入出金・うち建築・給与支払と、選んだ確定営業日の売上・運営費・給与・その他費用・利益・前日差・未払・照合・施設別損益を表示する。建築による資金減少を営業赤字と混同しない。06:00の給与現金支払が新営業日の出金、費用が前営業日の決算に属する点を案内する。
+Runtimeでは00:00に前営業日を締め、給与を計上する。06:00の朝運用では決算を重複させない。帳簿は当営業日の現金入出金・うち建築・給与支払と、選んだ確定営業日の売上・運営費・給与・その他費用・利益・前日差・未払・照合・施設別損益を表示する。建築による資金減少を営業赤字と混同しない。00:00の給与現金支払が新営業日の出金、費用が前営業日の決算に属する点を案内する。
 
-開業の手引きは受付→客室→接続→配属→初宿泊売上→翌朝決算の6段階を実状態から示す。達成後は売上と決算の履歴を先に評価し、夜間の勤務外や配属変更だけで達成が消えないようにする。Save復元では新しいServiceから読み直す。手引きは状態を書き換えず、ボタンから通常の建築・従業員・時間・帳簿操作へ進める。
+開業の手引きは受付→客室→接続→配属→初宿泊売上→00:00決算の6段階を実状態から示す。達成後は売上と決算の履歴を先に評価し、夜間の勤務外や配属変更だけで達成が消えないようにする。Save復元では新しいServiceから読み直す。手引きは状態を書き換えず、ボタンから通常の建築・従業員・時間・帳簿操作へ進める。
 
-通常初期予算での宿泊売上320G、翌06:00の給与120G・未払0・照合一致・専用保存復元を単日確認した。受付売上6,020Gと全利益6,040Gの現結果は調整対象で、価格や宿泊の決済時点を今回のUI追加で改定していない。厨房・補給・実配送を含む3営業日運営、初見試遊、製品バランスは残る。
+2026-09-29の描画付き開業受入では、通常初期予算から宿泊売上240G・受付売上0G・給与120G・営業利益-60G・未払0・照合一致と翌朝の保存再開を確認した。製品バランスと初見の人手試遊は別の判定とする。
 
 帳簿は表示中だけ更新し、日付のPopup操作中は選択肢を再構築しない。画面を閉じれば断面の観察へ戻る。
 
@@ -126,4 +126,9 @@ Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を
 
 左の「営業」は商品・勤務・帳簿と排他の管理パネル。施設を選び、価格5段階と営業状態を確定する。見積額、満足補正、受付済み価格の維持、休業時の待機／利用中の挙動、給与が続くことを表示する。受付や倉庫は開閉のみ。施設ごとの未確定入力は切替で保持する。Escで閉じる。
 
-施設別の当日記帳は確定給与配賦を含む営業利益と区別し、06:00の帳簿へ誘導する。1280×720では既存の縦スクロールを使う。試遊は `make preview-business`、通常データの保存を更新せずSpaceで時間を再開できる。
+施設別の当日記帳は確定給与配賦を含む営業利益と区別し、00:00の帳簿へ誘導する。1280×720では既存の縦スクロールを使う。試遊は `make preview-business`、通常データの保存を更新せずSpaceで時間を再開できる。
+
+
+## 従業員の休息・救護表示（2026-09-29）
+
+体力と休息先への移動・到着、気絶後の救護待ち・迎え・搬送・治療を従業員パネルに表示する。待機室内の人物・休憩人数、医務室の患者、救護EVの2席は実際のRuntime状態から描画する。

docs/plans/original-completion-2026-09-29/FIRST_INCREMENT.md

@@ -0,0 +1,34 @@
+# 初回の実装単位：維持費を通常営業へ接続する
+
+計画の最初の実装単位。2026-09-29に着手。進捗・試験証拠・残件は [実装記録](execution/UPKEEP_IMPLEMENTATION.md) を参照。
+
+## 着手条件
+
+P00–P04の必要部分を完了し、費用計上時点・未払い・閉店中/休止中の扱いをD04/D05で整理する。原本が未指定の金額を勝手に本番値として確定しない。既存の00:00決算・3連続赤字・保存復元を保護する。
+
+## 5つの小さな変更
+
+| 順 | 変更 | 主な対象 | 受入 |
+|---|---|---|---|
+| E01 | 運用費の仕様と例 | 原子要件台帳、未設定値台帳 | 営業/閉店/休止/日跨ぎ別の期待計上を具体的な台帳例にする |
+| E02 | 版付きの課金状態 | 保存/移行サービス、FacilityInstance周辺 | 旧セーブ読込時に過去費用を二重徴収しない。途中保存から再開可能 |
+| E03 | 一度だけ計上する処理 | 新規の運用費サービス、EconomyService | 同一営業日/施設/費目の再送で重複しない。資金不足時の債務処理が決まった規約通り |
+| E04 | Runtimeと00:00決算へ接続 | SimulationRuntime、OperationsCoordinator | 通常Tickの支出が施設別帳簿・現金・損益と一致。3連続赤字の既存判定を維持 |
+| E05 | UIと縦断検証 | OperatingLedgerPanel、BusinessManagementPanel | 通常建設→営業→閉店/休止→00:00→保存→再起動を操作し内訳一致 |
+
+各変更で影響する既存試験を実行し、E05で全体回帰を実行する。いきなり借金・税・天候まで同時に入れず、維持費の一連の経路を完成させてからP05の次の費目へ進む。
+
+## 具体的な試験ケース
+
+- 稼働施設1件と複数件で費目・施設・総額が一致する。
+- 建設中/閉店/休止/破壊/撤去の日跨ぎを仕様通り処理する。
+- 23:59保存→00:00→ロード再開で計上結果が一致する。
+- 課金直前/直後に保存し、再送でも二重課金しない。
+- 資金不足・部分支払い・未払いの扱いと翌日の処理が一致する。
+- 既存セーブ移行で過去確定日の収支を書き換えない。
+- 追加費用による黒字→赤字、連続2回→3回の終了を検証する。
+- 画面上の費目合計、台帳総額、施設別損益の照合差額が0。
+
+## この単位の完了証拠
+
+要件ID、変更ソース、採用した費用規約、試験ログ、代表セーブ、実画面、ソースハッシュを同じ検証記録へまとめる。「maintenance_goldを読むコードを追加した」だけで完了にしない。

docs/plans/original-completion-2026-09-29/IMPLEMENTATION_PLAN.md

@@ -0,0 +1,462 @@
+# 原本準拠・全実装に向けた作業計画 v2
+
+作成: 2026-09-29。状態: 自己レビュー反映済みの計画。実装着手・完了を示すものではない。
+
+## 1. 目標と前提
+
+保存済み原本75要件群（機能・内容71、工程4）と会話で追加された施設主要10項目を、通常プレイ・保存復元・UI・配布版の証拠まで追跡する。原本の最新再取得はP00で行う。今回の計画は2026-09-29監査に基づく。
+
+対象はローカル制作コピー `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。既存の変更を保全し、Driveコピーを制作対象にすり替えない。The Towerは操作/観察体験の参考であり、提供ゲームの画像・音・プログラムを取り込む前提にはしない。
+
+現状: 検証済み8、一部実装52、実装あり全受入未検証2、該当機能未実装9、工程4。原本30施設は通常登録12・定義のみ3・対応定義なし15。90スイートPASSと全原本実装は別。75群は粒度が異なるため完成率の分母にしない。
+
+本計画は全原本の対応先を落とさず記録するが、露骨な性的場面や性的強要の表現制作は具体化しない。該当内容は未制作のまま台帳で識別し、非露骨なイベント構造・状態・資産管理とは分ける。未制作内容が残る限り原本全実装とは認定しない。
+
+## 2. 完了条件
+
+各原子要件について、(1)原本条件、(2)定義、(3)実行サービス、(4)通常UI入口、(5)保存/移行、(6)境界試験、(7)画面/配布版、(8)証拠が揃うこと。関係しない項目は理由付きN/Aとし、未実装をN/Aにしない。
+
+最終条件は、対応漏れ0・未承認の原本差異0・現仕様で必須の値の未設定0（明示的に未設定の拡張仕様は除く）・未制作必須資産0・重大不具合0・Windows実機の同一ビルド合格。工程4件は機能PASSから除き、現在の工程達成と過去日程の達成を区別する。ユーザーが内容を変更した場合は変更承認を記録し「改訂仕様準拠」と表記する。
+
+## 3. 実装順序と到達点
+
+| 段階 | 作業 | 到達点・次段階への条件 |
+|---|---|---|
+| 0 | P00–P02 | 原本/要件/既存回帰の基準を固定。決定待ちを切り分ける。 |
+| 1 | P03–P04、P22 | 保存契約・更新順・素材仕様が揃い、手戻りを減らす。 |
+| 2 | P05–P07 | 費用・停電・天候が実際の営業へ作用する。 |
+| 3 | P08–P14、P23 | 原本施設の配置と営業、交通、レイヤー画面が通常操作で通る。 |
+| 4 | P15–P19、P24 | 客/職員/人物/関係/イベントの状態と操作がつながる。 |
+| 5 | P20–P21、P25–P26 | 進行・防衛・演出・制作内容を完成へ接続する。 |
+| 6 | P27–P29 | 横断試験→性能/長期プレイ→Windows配布版→最終監査。 |
+
+段階番号は見通しであり、厳密な着手条件は各パッケージの依存関係。P08はP03後、P22はP01後、P23はP08/P22後に先行できる。これは作業順の分離であり、エージェントへの並列委任を自動的に許可するものではない。
+
+主要な長い依存経路は P00→P01/P02→P03→P04→P05/P06→P09→P12/P14→P15→P16→P17→P18→P19→P20→P26→P27→P28→P29。素材制作・仕様回答も同程度に納期へ影響し得る。
+
+## 4. 作業パッケージ
+
+規模は暫定の技術作業人日: S=1–3、M=3–7、L=7–15。1人日は担当者の集中作業量の単位であり、AIの実行時間や日数保証ではない。Lは着手時に縦に完結する変更へ分割する。以下の受入は共通完了条件に追加する。
+
+### P00 原本・作業対象の固定
+
+- 段階: 0 / 規模: S（1–3人日、暫定）
+- 前提: なし
+- 原本: B-1.1, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 指定Drive原本を再照合し差分を保存。ローカル制作コピーの全ソース・現在のセーブ形式・既存成果物を識別する。今回計画の原本は保存版であり最新取得済みとは扱わない。
+- 受入: 原本SHAと変更履歴、制作対象、現在の実装証拠が再現可能。原本更新があれば影響要件を再評価。
+- 決定待ち: なし
+
+### P01 原子要件と受入台帳
+
+- 段階: 0 / 規模: M（3–7人日、暫定）
+- 前提: P00
+- 原本: B-1.1, B-1.2, B-1.3, B-1.4, B-1.5, B-1.6, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 75複合要件を単独判定できる条件へ分割。原本の各文、追加10項目、UI入口、Runtime、保存、試験、資産、完了責任を対応付ける。
+- 受入: 全原本文に対応先があり、未設定・未実装・未検証が別状態。派生仕様の独自ルールを確定仕様に昇格させない。
+- 決定待ち: D01, D02, D03, D04, D05, D06, D07, D08, D09, D10
+
+### P02 既存機能の回帰基準
+
+- 段階: 0 / 規模: M（3–7人日、暫定）
+- 前提: P00
+- 原本: B-3.1a, B-3.1b, B-3.3, B-3.4a, B-3.4b, B-4.2, B-4.3c, B-5.4
+- 実装: 時計、停止中建設、最高欲求、混雑、決算、赤字終了、救護/EV同伴/休息の既存証拠を新規開発の基準にする。必要な代表セーブを固定。
+- 受入: 日付・入力・乱数・セーブを固定して再実行できる。既存PASS8群を新仕様導入で失わない。
+- 決定待ち: なし
+
+### P03 保存形式と移行契約
+
+- 段階: 1 / 規模: L（7–15人日、暫定）
+- 前提: P01, P02
+- 原本: B-2.1, B-4.1, B-5.2, B-6.3, B-7.2, B-8.1, B-9.1
+- 実装: 施設、会計、客、職員、関係値、天候の新項目を版管理。原本と異なる関係値は一対一変換を仮定せず旧値を保全。移行は検証成功時のみ確定する。
+- 受入: 旧版/欠損/未知版/破損/途中書込の試験。失敗時に元セーブを変更しない。新しい状態は途中保存から同一結果で再開。
+- 決定待ち: D06, D07
+
+### P04 更新順序・責務の整理
+
+- 段階: 1 / 規模: M（3–7人日、暫定）
+- 前提: P03
+- 原本: B-1.3, B-1.4, B-3.2, B-9.2
+- 実装: 一分更新、00:00決算、時間帯・天候更新、施設稼働判定、客選択の適用順を仕様化。新機能は分離サービスで実装しRuntimeから接続。全体の一括書換えはしない。
+- 受入: 同一Tickでの閉店/停電/退出/課金順が決定的。コマンド再送で二重課金・二重生成しない。
+- 決定待ち: D05
+
+### P05 全収支・維持費・税・借入
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-3.4a, B-3.4b, B-9.1, B-9.2, B-9.3
+- 実装: 表/裏収入区分、維持費、返済元本/利息、税、未払いを帳簿に接続。金庫上限・購買・銀行のサービス契約を先に作る。決算損益と現金収支を区別。
+- 受入: 3営業日の費目別総額が台帳・施設別・資金と一致。借入元本を売上にしない。支払い失敗/再送/復元/3赤字を検証。
+- 決定待ち: D04, D05
+
+### P06 マナ枯渇と全館停止
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-2.6, B-9.1, B-10.6, B-10.7
+- 実装: 供給/蓄積/消費と世界樹初期源の扱いを整理。全館停止時のサービス、EV、物流、救護、入館と安全な復帰を接続。休止状態は停電復旧で解除しない。
+- 受入: 残量境界、停止中利用者、EV乗車中、搬送中、同日復旧を試験。停止中の売上や生産が無条件に継続しない。
+- 決定待ち: D04, D05
+
+### P07 天候・流行・環境
+
+- 段階: 2 / 規模: L（7–15人日、暫定）
+- 前提: P04
+- 原本: B-2.3, B-2.6, B-3.2, B-3.5, B-4.5, B-11.1
+- 実装: 雨/嵐/マナ霧、流行ニュース、ゾーンの採光/遮音/隠蔽、景観/清潔/騒音を段階導入。係数と乱数系列を保存しHUDと予測へ表示。
+- 受入: 嵐で新規入館0、雨で来客減/滞在延長。天候変化の瞬間と保存再開が一致。環境変更に応じて満足度と対象売上が変わる。
+- 決定待ち: D04, D05
+
+### P08 施設寸法・既存配置の整合
+
+- 段階: 3 / 規模: M（3–7人日、暫定）
+- 前提: P03, P01
+- 原本: B-2.1, B-8.1, B-10.1, B-10.2, B-10.3, B-10.4, B-10.5, B-10.6, B-10.7
+- 実装: 上級客室4×1、宿舎2×1、闇市場4×2へ原本準拠。30施設を正規IDで管理し類似施設を代用扱いしない。旧占有・支持・接続の移行を検証。
+- 受入: 新規建設の寸法/層/地上地下が全30件で一致。旧施設の拡縮で重複・経路断を起こさず、解消不能な移行は元データを保つ。
+- 決定待ち: D06
+
+### P09 施設共通契約と追加10項目
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P05, P06, P08
+- 原本: B-8.1, B-8.2, B-8.3, B-8.5, B-9.2
+- 実装: 人数専用上限、staff_min/max、3稼働状態、関連施設、サービス属性、価格、施設レベルを統合。全35既存定義を点検し原本30施設の値を台帳化。
+- 受入: 本番UI→コマンド→Runtime→人数/料金→台帳→保存まで接続。不一致属性でも利用可能。待機者と利用者を混同せず、人数超過/停止中課金/勝手な休止復帰を防ぐ。
+- 決定待ち: D01, D02, D03, D04, D05
+
+### P10 宿泊・飲食施設の完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09
+- 原本: B-8.2, B-10.1, B-10.2
+- 実装: 一般/上級/VIP/ドミトリー、食堂/レストラン/酒場/屋台を建設・厨房・在庫・従業員・客AI・UIへ接続。高層/景観要件と厨房依存を含む。
+- 受入: 各施設を通常パレットから建設して一営業日利用し、必要条件喪失と再開、売上、人数上限、保存を検証。
+- 決定待ち: D04
+
+### P11 衛生・娯楽・礼拝施設
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09, P07
+- 原本: B-8.2, B-10.3
+- 実装: 浴場/カジノ/闘技場/礼拝堂の役割、利用、収支、職種、信仰への接続を実装。機能ごとの通常UIを用意。
+- 受入: 4施設が定義だけでなく通常営業できる。礼拝の信仰をランク条件へ接続し、停止・退店・精算を再現。
+- 決定待ち: D04, D05
+
+### P12 バックヤード施設完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09
+- 原本: B-2.4, B-5.3, B-5.4, B-8.3, B-10.5
+- 実装: 宿舎・清掃員室を追加し厨房/倉庫/待機/警備/医務を統一契約へ移行。リネンシュート・隠し扉の動線も個別に追跡する。
+- 受入: 7施設と追加設備の職員行動、客の侵入禁止、在庫/清掃/休息/救護を通常プレイで検証。重複救護と孤立物資が残らない。
+- 決定待ち: D04, D05
+
+### P13 特殊・地下施設の非描写システム接続
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P09, P12
+- 原本: B-1.6, B-2.5, B-8.2, B-8.3, B-10.4, B-10.6
+- 実装: 原本にある地下/特殊施設の配置、アクセス制御、役割、会計、イベント状態を接続。覗き部屋は対象施設背面と裏通路寸断、地下牢/マナ炉は明示状態遷移として追跡。表現資産は別工程。
+- 受入: 特殊条件が建設時と運用時の両方で効く。無効配置や失われた対象への操作を拒否。イベント状態を保存でき、実装範囲と未制作内容を分けて報告。
+- 決定待ち: D04, D05, D08
+
+### P14 垂直交通・ワープ完成
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P06, P09
+- 原本: B-2.4, B-4.3a, B-4.3b, B-4.3c, B-8.4, B-10.7
+- 実装: 客/業務EV、階段にマナワープと費用を追加。待ち時間の経路費用、容量、職員アクセス、停止時退避を統一。魔法砲台はP21で接続。
+- 受入: 全交通を通常建設し経路選択・実移動を検証。待ち時間増で別経路を選択。ワープ中/EV中保存、マナ不足、救護同伴時の人数を検証。
+- 決定待ち: D04, D05
+
+### P15 客の全パラメータ・時間帯AI
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P07, P10, P11, P14, P13
+- 原本: B-3.2, B-4.1, B-4.2, B-4.4, B-4.5, B-9.4
+- 実装: 戦利品、清潔度と汚染伝播、クラス/種族反応、朝夕の移動目的、依存と信用限度の非描写状態処理を追加。最大欲求選択を維持。
+- 受入: 一般/貴族/聖職者/エルフ/魔族等で期待行動を再現。朝下り/夕上りの目的地分布、清潔伝播、装備処分・破産状態を保存再開まで検証。
+- 決定待ち: D04, D05, D08
+
+### P16 雇用・職種・労務完成
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P12, P15, P13
+- 原本: B-5.1, B-5.2, B-5.3, B-5.4, B-5.5
+- 実装: 雇用区分別費用、全職種業務、生成時特性、獲得/退職/処分の非描写状態処理を整理。乱数特性は生成時に固定しセーブへ保存。
+- 受入: 求人から配置・業務・休息・精算・退職まで通常UIで通る。費用/忠誠/特性効果の変化が可視化され、ロードで特性が再抽選されない。
+- 決定待ち: D04, D05, D08
+
+### P17 ユニーク7名・固有効果・成長
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P16, P05, P11
+- 原本: B-1.5, B-6.1, B-6.2, B-6.3, B-6.4, B-6.5
+- 実装: 7ヒロインと指定ライバル、無料/削除禁止、業務EXP/Lv99、固有パッシブを実装。アンリの配置階売上+20%など原本の明示数値を優先。衣装/超過勤務/離脱を状態として接続。
+- 受入: 7名全員で固有効果の適用前後、配置変更/同時配置、99上限、削除禁止を試験。24時間警告から継続/中止ができ、保存復元で効果を重複適用しない。
+- 決定待ち: D04, D07, D08
+
+### P18 関係パラメータ・盾・確定遷移
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P03, P17
+- 原本: B-7.1, B-7.2, B-7.3
+- 実装: 原本の感情値と盾の非描写シミュレーションを専用モデルに分離。好感度と盾最大、軽減、接触、閾値、ルート固定を接続。既存の汎用関係値を黙って同義変換しない。
+- 受入: 境界値・盾破壊前後・同配置/別配置・一度確定したルートの再読込を試験。操作と表示の値が一致し、旧セーブ移行の意味を説明できる。
+- 決定待ち: D04, D07, D08
+
+### P19 イベント・決闘・行動・履歴基盤
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P18, P05
+- 原本: B-7.1, B-7.4, B-7.5, B-7.6, B-11.3
+- 実装: 原本の決闘種別、プレイヤー行動、結果、履歴、人物外見状態を非描写のデータ/遷移/画面として実装。専用カメラは証拠IDとイベント基盤を接続。内容制作はP26に分離。
+- 受入: 各分岐が到達可能で勝敗/費用/盾/履歴を一度だけ反映。中断・対象離脱・取消・ロード後も矛盾なし。専用画面は中立テスト内容で操作を検証。
+- 決定待ち: D04, D07, D08
+
+### P20 ランク・信仰・物語進行
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P05, P11, P15, P19
+- 原本: B-1.1, B-1.2, B-1.3, B-1.4, B-1.5, B-6.4, B-6.5, B-8.1, B-8.5
+- 実装: 信仰/評判/裏影響、ランク条件、施設/方針/スキル解放、章とエンドを接続。条件評価APIだけでは進行完了としない。
+- 受入: デバッグで条件値を直接書き込まず新規ゲームから最終ランクと本編終点へ到達。条件未達の理由が画面で分かり、分岐復元が一致。
+- 決定待ち: D04, D08
+
+### P21 防衛・監査・銀行・砲台
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P05, P13, P14, P17
+- 原本: B-1.3, B-6.4, B-6.5, B-9.3, B-10.7, B-11.4
+- 実装: 原本の脅威発生から警告、準備、戦闘、能動スキル、魔法砲台、結果、施設損傷・休止へ接続。返済滞納と襲撃を接続。
+- 受入: API直呼びでなく通常営業から発生。勝利/敗北/退避/破壊・摘発/復元を検証。敗北で意図しない恒久ロストや勝手な休止解除がない。
+- 決定待ち: D03, D04, D05, D08
+
+### P22 素材台帳・量産仕様の先行確定
+
+- 段階: 1 / 規模: M（3–7人日、暫定）
+- 前提: P01
+- 原本: B-12.1, B-12.3, B-12.4, B-13.1, B-13.2, B-13.3, B-13.4, B-13.5
+- 実装: 全施設Lv1〜3×表裏、7人物、状態差分、背景、UI、音響の必要枠を列挙。既存Kenney素材と新規制作を区別しサイズ/命名/ライセンス/差替契約を定義。
+- 受入: 各資産が利用要件・画面・状態・制作者・仮素材/完成品に紐付く。必要数未確定のまま完成時期を断定しない。
+- 決定待ち: D08, D09
+
+### P23 タワー画面・レイヤー演出
+
+- 段階: 3 / 規模: L（7–15人日、暫定）
+- 前提: P08, P22
+- 原本: B-2.2, B-11.1, B-11.4, B-12.1, B-12.2, B-12.4
+- 実装: 非選択層の半透明/ワイヤー、波紋切替、上下移動/ズーム/視認性、原本に沿ったHUD配置と表裏スキンを実装。座標変換と選択判定を共通化。
+- 受入: 切替前後に選択・クリック座標が一致。パン/ズーム中の建設、異層施設の視認性、連続切替、速度x3で破綻しない。
+- 決定待ち: D09, D10
+
+### P24 インスペクター・通知・操作完成
+
+- 段階: 4 / 規模: L（7–15人日、暫定）
+- 前提: P09, P15, P16, P18, P23, P19
+- 原本: B-11.1, B-11.2, B-11.3, B-11.4, B-13.4
+- 実装: シフトのドラッグ配置、欲求/思考ログ、感情/盾、料金内訳、稼働阻害理由、接続線、フキダシ、カットインを接続。クリックによる代替操作も用意。
+- 受入: 無効ドロップで状態を壊さず理由を表示。保存後も対象選択を回復。ログの説明と実際の選択が一致。モーダル/停止/再開の入力を検証。
+- 決定待ち: D09
+
+### P25 ドット人物・施設差分・音響接続
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P22, P23, P12, P17
+- 原本: B-12.1, B-12.3, B-12.4, B-13.2, B-13.3, B-13.4, B-13.5
+- 実装: 状態駆動の歩行/作業/搬送/休息、施設Lv差分、背景、表裏BGMクロスフェード、環境/操作音を接続。実シミュレーションの状態を演出源にする。
+- 受入: 停止中は人物移動が進まない。搬送/休息は実位置に一致。音量/連続切替/ロードで二重再生しない。完成資産の欠損とライセンス記録漏れ0。
+- 決定待ち: D08, D09
+
+### P26 シナリオ・立ち絵・内容資産の制作受入
+
+- 段階: 5 / 規模: L（7–15人日、暫定）
+- 前提: P19, P20, P22
+- 原本: B-1.1, B-1.5, B-1.6, B-7.5, B-7.6, B-12.1, B-12.3, B-13.1, B-13.5
+- 実装: 全章・人物別ルート・終点・台詞・立ち絵・音声を台帳で制作/接続/受入。成人向け内容は表現仕様と制作可否を別途確認し、今回は非露骨な構造・資産管理・分岐検証のみ計画対象とする。
+- 受入: 仮素材や未制作の場面を完了扱いしない。全必要分岐と資産の欠損を一覧化。制作できない内容は原本との差分として残し、全実装完了を宣言しない。
+- 決定待ち: D08, D09
+
+### P27 統合・境界・障害復旧試験
+
+- 段階: 6 / 規模: L（7–15人日、暫定）
+- 前提: P10, P11, P12, P13, P14, P15, P16, P17, P18, P19, P20, P21, P24, P25, P26
+- 原本: B-1.1, B-1.3, B-14.4
+- 実装: 新規営業/停電/嵐/救護/決算/破産/襲撃/ルート進行の横断シナリオを実施。代表地点で保存・終了・起動を挟む。失敗を再現ケースに固定。
+- 受入: 全原子要件に合否証拠。進行不能・セーブ破損・帳簿不整合・原本との未承認差異0。未設定や未制作をスキップPASSしない。
+- 決定待ち: D01, D02, D03, D04, D05, D06, D07, D08, D09, D10
+
+### P28 性能・操作感・長期バランス
+
+- 段階: 6 / 規模: L（7–15人日、暫定）
+- 前提: P27
+- 原本: B-1.1, B-3.1a, B-4.3a, B-4.3c, B-11.1, B-12.1, B-14.4
+- 実装: 既存高負荷条件でCPU/経路/描画/保存を測定。通常プレイのラッシュ/満室/負荷ピークと長期経済を評価。20〜30時間本編・50時間以上全攻略は実プレイ記録で確認。
+- 受入: 既存性能予算と新しいWindows描画目標を満たす。到達不可能な収支/信仰/ランク条件なし。高速自動再生だけでプレイ時間・操作感を合格にしない。
+- 決定待ち: D04, D08, D10
+
+### P29 Windows実機・配布版・最終監査
+
+- 段階: 6 / 規模: M（3–7人日、暫定）
+- 前提: P28
+- 原本: B-1.1, B-14.1, B-14.2, B-14.3, B-14.4
+- 実装: 実EXEで新規→建設→営業→保存→終了→再起動→継続を操作。入力/表示倍率/音/日本語パス/回復を確認し、ビルドとソースのハッシュを固定。75要件と追加仕様を最終再監査。
+- 受入: 同一リリース候補のソース試験・PCK試験・Windowsネイティブ試験・プレイ記録・資産台帳が揃う。原本差異0で初めて全実装完了。工程の過去納期達成は別判定。
+- 決定待ち: D10
+
+## 5. 工数と日程の扱い
+
+30パッケージの技術作業単純合計は **180–390人日**。監査ベースの粗い仮置きで、確度は低い。制作量未確定の脚本/絵/音声、外部発注待ち、ユーザー判断待ち、実プレイ時間は含めていない。P26の見積は台帳・接続・受入の技術作業のみ。予備枠として技術作業の30%を別途確保する案とし、P01/P22後に実績で見直す。
+
+人数や稼働率が未指定のため固定の発売日を置かない。各マイルストーン後に残工数・回答待ち・制作待ちを再見積する。原本の2027年12月マスターアップは比較対象の目標であり、本計画から達成可能と断定しない。
+
+## 6. 決定待ち台帳
+
+未設定値をコードの都合で確定しない。まず影響、選択肢、推奨案、検証方法を具体化し、関連実装へ固定する直前に必要事項をまとめて確認する。現在は計画作成のため、回答を待って全作業を止める必要はない。
+
+| ID | 決める事項 | 決まるまで進められること | 固定が必要になる地点 |
+|---|---|---|
+| D01 | 欲求一致加算の額/率、不足基準、属性割当、複数属性/重複 | 計算契約、未解決状態、非一致利用、テスト入力を実装 | P09の本番課金。未設定を0円確定と扱わない |
+| D02 | 全施設の顧客専用上限・職員上限、Lv別の変化 | 人数集計、上限超過拒否、データ表を作る | P09/各施設の本番値。capacityから転記しない |
+| D03 | 休止からの復帰、関連施設の複数指定/AND/ORを採用するか | 現指定の永続休止・単一関連先を維持し接続試験 | 新しい解除/複数条件を追加する前。未設定のままなら追加しない |
+| D04 | 原本にない経済/天候/環境/役割/技能/成長/依存係数 | 原本明示数値を固定し、未指定値の比較試験を作る | バランス用本番データの凍結前 |
+| D05 | 全館停止中の搬送/EV安全処理、費用計上時点、日跨ぎ順序 | 状態遷移案・矛盾ケース・台帳例を作る | P04–P06の更新規約固定前 |
+| D06 | 寸法変更で重なる旧配置と旧拡張定義の移行方法 | 移行プレビュー、バックアップ、拒否時の原状保持 | 移行不能な既存セーブへの適用前 |
+| D07 | 旧5関係値から原本3値への意味付け、既存進行の扱い | 新旧を保存し、新規ゲームの原本モデルを作る | 旧プレイ進行の変換前。推測変換しない |
+| D08 | ルート/章/イベントの内容、成人向け範囲、制作可能な資産、必要量 | 非露骨な状態/分岐/中立テスト資産で接続検証 | P19/P20/P26の内容凍結前。未制作を完成扱いしない |
+| D09 | 立ち絵/ドット/音/声の品質と制作担当・予算・権利 | Kenney等既存素材の台帳、差替契約、必要枠の算出 | 外部発注/完成素材受入前 |
+| D10 | Windows対象機スペック/解像度/描画目標と最終評価者 | 手元環境の性能・機能を計測 | 性能合否とP29。未接続端末を確認済みとしない |
+
+D03のようにユーザーが明示的に未設定とした拡張仕様は「決定がないと現仕様を実装できない」わけではない。単一依存・解除なしで現要件を満たし、新たな挙動を発明しない。
+
+## 7. 検証計画
+
+| 層 | 検証対象 | 合格証拠 |
+|---|---|---|
+| 仕様/データ | 75群の原子条件・30施設・追加10項目・資産 | 対応表、寸法/層/属性/役割検査、未設定台帳 |
+| 部品 | 価格/会計/人数/条件/経路/関係/成長 | 境界/失敗/重複試験。実装をなぞるだけの試験は作らない |
+| Runtime | 通常Tick、コマンド、停止、実利用、損益 | 同一シードの実行ログと整合性検査 |
+| 保存 | 更新前後/営業中/乗車/搬送/イベント/日付境界 | 復元後同一再生、不正入力の原状保持、旧版移行 |
+| UI | 通常メニューから操作し結果を観察 | 実描画の入力・画像・状態一致。サービス直呼びで代替しない |
+| 配布 | ビルドに同梱されたデータ | ソース/ビルドハッシュ、PCK試験、Windows実EXE操作ログ |
+| 長期 | 新規から本編完走/全分岐/経済/負荷 | 実プレイ記録、到達性表、性能計測、未解決不具合一覧 |
+
+P02でWindows基準環境を準備し、P10/P14/P23/P24で部分実機確認を行う。P10/P17/P20では初期/中盤/終盤のプレイ試行を行い、問題を最後まで持ち越さない。更新・経路・描画の変更は代表負荷を都度計測する。利用できない環境の結果は未検証として残す。
+
+各パッケージでは関連試験を先に行い、統合点で全体回帰を実行する。全体PASS後に通しデバッグへ進み、修正が入った場合は該当回帰と通しシナリオを再実施する。過去ログを現在ビルドの証拠として無条件に使い回さない。
+
+横断シナリオ: (A)新規→開業→3日決算、(B)雨→嵐→霧→回復、(C)停電とEV乗車/救護の同時発生、(D)昼夜交代ラッシュと休息、(E)施設依存喪失/破壊/摘発/保存復元、(F)最高欲求と行列/価格/階層、(G)返済滞納→襲撃→結果、(H)ランク解放と全施設、(I)人物進行と全分岐、(J)旧版移行と最終配布。
+
+## 8. 性能と互換性の基準
+
+既存コードの基準を継続する: simulation_x1平均4ms、simulation_x3 P95 12ms、path_query P95 2ms、主スレッド停滞最大50ms、保存最大5秒、読込最大8秒。これらはシミュレーション等の予算であり描画FPS保証ではない。対象ハードと描画目標はD10で別定義する。
+
+既存の20,000マス/200客/50従業員/150施設を回帰条件とし、最終ランクで必要な規模が上回る場合は新しい負荷条件も追加。計測機・ビルド・シード・速度・観測区間・P95/最大値を保存する。メモリは複数回のロード/場面遷移後に安定するかを確認し、持続増加を調べる。
+
+サイズ変更、関係値変更、マナ/会計変更は別移行段階とする。旧セーブを上書きしてから検証しない。移行に失敗したデータを「復旧成功」として進めない。
+
+各パッケージの実装担当はコードと完了証拠を作成し、受入担当が原本条件を確認する。素材/内容の制作担当はP22/P26で確定する。人数・実名は未割当であり、並列体制や独立レビューを既に確保したとは扱わない。
+
+## 9. 初回実装時に行う順番
+
+1. P00で原本/ローカルソース/セーブの識別を固定する。
+2. P01で最初に経済・マナ・施設追加仕様の原子受入を作る。残りも台帳から落とさない。
+3. P02の既存回帰を確認し、P03の保存変更を先に実装する。
+4. P04の00:00・天候・停止・課金の順序を決め、P05を維持費→台帳→決算→UIの小さな縦断変更として通す。
+5. P06、P07へ進み、P08/P22の独立準備も順次行う。未回答項目に依存しない作業を継続する。
+
+最初の維持費実装は `FIRST_INCREMENT.md` に5つの変更と具体的な受入ケースへ分割した。
+
+この順番は今回の計画であり、バックグラウンド実行や定期実行の設定は行っていない。
+
+## 10. 自己レビューと改訂
+
+別紙 `SELF_REVIEW.md` に初案の問題点とv2の修正を記録。主な改訂は、保存移行の前倒し、経済/マナを施設量産の前に配置、素材設計の先行、通常UIと内容制作の分離、Windows実機と実プレイの独立ゲート、未設定値の局所ブロック化。
+
+## 11. 原本75要件の作業対応
+
+| 原本ID | 要件 | 実装/検証パッケージ |
+|---|---|---|
+| B-1.1 | 基本情報・Windows・2D・20〜30時間/50時間以上 | P00, P01, P20, P26, P27, P28, P29 |
+| B-1.2 | 地上/地下の二面性経営・観察介入・権威/富 | P01, P20 |
+| B-1.3 | 建設→集客→収益→管理→拡張防衛 | P01, P04, P20, P21, P27 |
+| B-1.4 | 二層・自律AI・渋滞・信仰と依存 | P01, P04, P20 |
+| B-1.5 | 世界観・主人公・7ヒロイン3運命 | P01, P17, P20, P26 |
+| B-1.6 | 成人向けルートと経営的搾取 | P01, P13, P26 |
+| B-2.1 | グリッド・Y正負・支持・領域拡張 | P03, P08 |
+| B-2.2 | 同座標Front/Back・半透明/ワイヤー表示 | P23 |
+| B-2.3 | 客エリアと景観/清潔/騒音の満足度効果 | P07 |
+| B-2.4 | バックヤード・職員ドア・客通行禁止 | P12, P14 |
+| B-2.5 | 覗き部屋の配置制約・通路寸断・証拠収集 | P13 |
+| B-2.6 | 地上/地下の採光・マナ・遮音・隠蔽ボーナス | P06, P07 |
+| B-3.1a | 10秒=1時間、Pause/x1/x2/x3 | P02, P28 |
+| B-3.1b | アクティブポーズ中も建設・指示 | P02 |
+| B-3.2 | 4時間帯と朝下り/夕上り/夜行動 | P04, P07, P15 |
+| B-3.3 | 昼夜シフト・体力0気絶・救護・通勤混雑 | P02 |
+| B-3.4a | 毎日00:00に決算レポート | P02, P05 |
+| B-3.4b | 3回連続赤字でゲームオーバー | P02, P05 |
+| B-3.5 | 雨・嵐・マナの霧・流行ニュース | P07 |
+| B-4.1 | 所持金/戦利品・四欲求・忍耐/清潔/依存 | P03, P15 |
+| B-4.2 | 最大欲求優先と距離/行列/価格選択 | P02, P15 |
+| B-4.3a | A*とエレベーター待ち時間コスト | P14, P28 |
+| B-4.3b | 4種垂直移動のゲーム内利用 | P14 |
+| B-4.3c | 重なり時速度50%低下 | P02, P14, P28 |
+| B-4.4 | 依存Lv3退店拒否・装備売却・性別別破産 | P15 |
+| B-4.5 | 貴族/聖職者/エルフ/魔族のAI特性 | P07, P15 |
+| B-5.1 | 一般雇用と奴隷の費用/耐性/売却区別 | P16 |
+| B-5.2 | 体力/ストレス/忠誠/技能/ランダム特性 | P03, P16 |
+| B-5.3 | 接客/裏方/救護/防衛等の職種 | P12, P16 |
+| B-5.4 | シフト休息と気絶回収 | P02, P12, P16 |
+| B-5.5 | 求人/市場/破産捕獲・退職金/売買価格 | P16 |
+| B-6.1 | ユニーク無料・高成長・解雇売却不可 | P17 |
+| B-6.2 | 7ヒロインの指定固有効果とライバル | P17 |
+| B-6.3 | 基礎技能と業務EXP・Lv99 | P03, P17 |
+| B-6.4 | 配置パッシブ・任意発動・ルート別スキル | P17, P20, P21 |
+| B-6.5 | 24時間勤務警告・衣装補正・限定離脱 | P17, P20, P21 |
+| B-7.1 | 三感情・盾・決闘の3ルート運命 | P18, P19 |
+| B-7.2 | 好感/淫乱/NTR・好感度=盾最大・淫乱軽減 | P03, P18 |
+| B-7.3 | 同配置接触→盾破壊→NTR上昇→不可逆陥落 | P18 |
+| B-7.4 | 3種決闘・勝利追放/隷属/盾回復・敗北確定 | P19 |
+| B-7.5 | 会話/デート/隔離・覗き・薬による各ルート | P19, P26 |
+| B-7.6 | 履歴・妊娠/父親・刻印立ち絵 | P19, P26 |
+| B-8.1 | 隣接/通路必須とLv拡張 | P03, P08, P09, P20 |
+| B-8.2 | 表層全施設・飲食と厨房セット | P09, P10, P11, P13 |
+| B-8.3 | 裏層全施設と特殊設備 | P09, P12, P13 |
+| B-8.4 | EV/階段/ワープ/通路/職員ドア | P14 |
+| B-8.5 | Lv解放の価格/食材/混浴/ハード/イカサマ設定 | P09, P20 |
+| B-9.1 | 表金/裏金・マナ全館停止・資材 | P03, P05, P06 |
+| B-9.2 | 全収益/人件費/維持/仕入/借金/ランク税 | P04, P05, P09 |
+| B-9.3 | 受付/金庫/購買/闇銀行 | P05, P21 |
+| B-9.4 | 依存客の娯楽優先・信用超過の破産拘束 | P15 |
+| B-10.1 | 宿泊施設の寸法/層/ゾーン | P08, P10 |
+| B-10.2 | 飲食施設の寸法/層/ゾーン | P08, P10 |
+| B-10.3 | 衛生/娯楽施設の寸法/層/ゾーン | P08, P11 |
+| B-10.4 | アングラ施設の寸法/層/ゾーン | P08, P13 |
+| B-10.5 | バックヤード施設の寸法/層/ゾーン | P08, P12 |
+| B-10.6 | 特殊施設の寸法/層/ゾーン | P06, P08, P13 |
+| B-10.7 | インフラ/防衛施設の寸法/層/ゾーン | P06, P08, P14, P21 |
+| B-11.1 | 資源/時間/天候/Rank・下部切替・スクロールズーム | P07, P23, P24, P28 |
+| B-11.2 | Policy/ドラッグ配置・欲求/思考/感情グラフ/盾 | P24 |
+| B-11.3 | カメラ入口・覗きアングル/撮影/介入 | P19, P24 |
+| B-11.4 | グリッド/接続警告・フキダシ/ログ・カットイン | P21, P23, P24 |
+| B-12.1 | 二面性・高精細ドットとアニメ立ち絵 | P22, P23, P25, P26, P28 |
+| B-12.2 | 魔法レンズ風の波紋切替 | P23 |
+| B-12.3 | SD各モーション・立ち絵破損/汚れ/刻印差分 | P22, P25, P26 |
+| B-12.4 | 表裏UIスキン・BGMクロスフェード・環境音/SE | P22, P23, P25 |
+| B-13.1 | 立ち絵/CG/差分 | P22, P26 |
+| B-13.2 | SDモーション/エフェクト | P22, P25 |
+| B-13.3 | Lv1〜3表裏タイル/背景 | P22, P25 |
+| B-13.4 | 表裏スキン/感情/覗き素材 | P22, P24, P25 |
+| B-13.5 | BGM/環境/操作/成人向けSE/声 | P22, P25, P26 |
+| B-14.1 | 2026/03〜08 プロトタイプ | P00, P01, P29 |
+| B-14.2 | 2026/09〜2027/02 アルファ | P00, P01, P29 |
+| B-14.3 | 2027/03〜08 ベータ/成人向け | P00, P01, P29 |
+| B-14.4 | 2027/09〜12 ポリッシュ | P00, P01, P27, P28, P29 |
+
+追加施設10項目は全件P09が統合責任を持ち、費用はP05、稼働/マナはP06、寸法はP08、施設データはP10–P13、UIはP24と連携する。
+
+計画整合性は `plan_validation.json` を参照。全75要件と追加10項目の対応、依存先存在、循環なしを機械検証した。これは計画の整合性検証であり、ゲーム実装の合格ではない。

docs/plans/original-completion-2026-09-29/SELF_REVIEW.md

@@ -0,0 +1,35 @@
+# 計画の自己レビューと改訂記録
+
+2026-09-29。作成者自身によるレビュー。独立した第三者レビューや実装検証を行ったという意味ではない。
+
+初案の骨格は「基盤→経済→施設→AI/人物→演出→総合試験」。この順序を、既存セーブ、通常UI、制作物、原本未設定事項、納期を壊さないかという観点で見直した。下表の修正はv2へ反映済み。
+
+| No. | 初案・検討時の問題 | v2へ反映した修正 | 確認方法 |
+|---|---|---|---|
+| R01 | 75複合要件への紐付けだけでは、一部条件を落としても完了にできる | P01で原文単位の原子受入を作り、最後は全条件ANDで判定 | 原文行→原子条件→実装→証拠を検査 |
+| R02 | 寸法や関係値を先に変えると旧セーブを破壊し得る | P03で移行契約を先行。P08/P18に保全・不一致時拒否を追加 | 配置重複/支持喪失/意味不明な変換の試験 |
+| R03 | 施設量産後に維持費・マナを接続すると収支と稼働条件を作り直す | P09の前提をP05/P06/P08とする | 施設量産の着手時に共通契約の受入を確認 |
+| R04 | P15の破産状態とP16の獲得処理が対象施設より先行できていた | P15/P16の依存にP13を追加 | DAG検査、通常配置先まで通す受入 |
+| R05 | P24の専用イベントUIがイベント操作APIより先行できていた | P24の依存にP19を追加 | UIから選択→費用/結果→保存を確認 |
+| R06 | 最後にまとめてWindows検証すると入力・描画の問題が遅れて発覚 | P02でWindows基準環境を準備し、P10/P14/P23/P24で部分実機確認 | 実EXEの操作証拠。接続不能時は未検証と記録 |
+| R07 | 性能と長期バランスが最終工程に偏る | 更新/経路変更ごとに代表負荷、P10/P17/P20でプレイ試行を追加 | プロファイルと初期/中盤/終盤の収支・操作記録 |
+| R08 | 未設定の複数依存や休止解除を、全実装に必須の新機能と誤解し得る | D03は拡張時のみ決定。現仕様の単一依存・解除なしは実装可能 | 最終未設定0の条件を「現仕様で必須の値」に限定 |
+| R09 | 料金APIがあるだけで加算完了にできる | P09で本番属性・不足判定・人数・見積・実請求・台帳・ロードを一連で受入 | 仮値の単体試験とは別に本番データで操作する |
+| R10 | 素材制作を後回しにすると必要数と外部待ちが最終日程を支配する | P22をP01直後から着手可能に。P26の技術と内容制作を分離 | 未制作枠/制作担当/ライセンスの台帳 |
+| R11 | 声・CG・露骨な内容を技術パッケージに隠して全実装を約束し得る | 内容制作可能範囲を明示し、未制作を残件として扱う | 仮素材や制作範囲外をPASSにしない |
+| R12 | 大きなパッケージの概算を確定納期と誤読し得る | 180–390人日は粗い技術概算と明記。制作・実プレイ・待ち・予備枠を分離 | P01/P22後、各節目で実績に基づき再見積 |
+| R13 | 定義登録数19を原本30施設の充足数と混同し得る | 原本30施設と既存35定義の対応を別表で管理 | 通常登録/パレット/役割/寸法を別列で検査 |
+| R14 | 項目の担当が曖昧で最後に証拠だけ残らない | 各作業に実装・受入・制作の役割を記載。担当者の実名割当は未指定のまま | 完了証拠作成を実装担当の作業に含める |
+| R15 | 原本が変わるとこの計画の前提が古くなる | P00で再照合し、監査SHAを計画に保持 | 差分が出た要件のみ影響分析し再計画 |
+
+## 修正後の検査
+
+- 全75要件に作業の対応先がある。
+- 追加施設10項目に対応先がある。
+- 存在しない依存ID、循環依存はない。
+- 検証済み8群を作り直し対象にせず、回帰対象として維持している。
+- 仕様未設定、コード未実装、内容未制作、実機未検証を別に扱っている。
+- 新規ゲームの正常系だけでなく、旧セーブ・中断・失敗・復旧を各受入に含めている。
+- 計画の整合性とゲームの実装完了を混同していない。
+
+実行結果は `plan_validation.json`。以上で計画の抜け漏れが絶対にないことを保証するものではない。P01の原子要件化、P22の必要資産数確定、最初の縦断実装の実績で再レビューする。

docs/plans/original-completion-2026-09-29/execution/ACTOR_SELECTION_RESTORE.md

@@ -0,0 +1,11 @@
+# 従業員・来客の選択復元
+
+2026-09-30。P24の「保存後も対象選択を回復」を従業員管理と来客観察へ接続。施設等の選択とは別の任意保存情報として、各実在IDと画面の開閉を保存する。手動保存とRuntimeが実行するチェックポイントは同じ情報収集処理を使う。
+
+成功した厳格読込・復旧候補読込で各IDを独立検証し、実際に読み込んだ候補の対象を表示する。閉じていた観察画面も表示せずに対象を復元できるよう、画面生成と表示を分離。存在しないID・不正型・過長ID・未知版・旧形式はゲーム進行を壊さず通常表示へ戻す。読込失敗では現在の選択と表示を保持。未確定の配属・シフト入力は保存対象としない。
+
+通常の候補ボタンで2名を雇用し、独立した来客2名をRuntimeの生成コマンドで作成。来客は境界試験用の制御された到着であり、自然入館の受入とは扱わない。通常の従業員ボタン・来客プルダウンを操作し、手動保存、厳格読込、画面破棄/再生成、閉じた画面、2世代の実自動保存候補、失敗、旧版/不正な任意情報を検証。100項目PASS。実描画101項目PASS、画像でバルドの詳細、来客selection_guest_b、所持金910G・食欲83を確認。関連7スイート552項目PASS。
+
+ゲーム状態の照合では測定時間を含む通知データだけを除外。読込試行が診断イベントIDを1個採番する場合はその増分を明示照合し、他の採番器・乱数・業務状態は保持して比較する。初回のサービス直接生成は財布等のRuntime横断契約を欠いたため、正しい生成コマンドへ検証用入力を修正。修正前ログを保全した。検証ドライバーの最初の停止はダッシュボードのPASS出力形式を認識しなかったためで、ゲーム試験の失敗ではない。双方の合格形式を読めるよう修正した。
+
+証拠: artifacts/actor-selection-2026-09-30/。main.before.gd、main.diff、before*.log、headless.log、rendered.log、targeted.json、verification.json、restored-actor-inspectors.png。最新144スイート全件PASS、全件PASS後の実描画開業通し103項目PASS。追加の別プロセス選択復元は書込103・読込13＝116項目PASSし、保存された両ID・画面の開閉、ゲーム状態JSONと型付きdigestが一致した。証拠: artifacts/actor-selection-restart-2026-09-30/。Windows更新は同梱PCK12回・計2,094項目PASS、ZIP CRC/同梱SHA一致で完了（CURRENT_WINDOWS_PACKAGE.md）。同一ビルドWindows実機、P24全項目、原本全実装は未完了。

docs/plans/original-completion-2026-09-29/execution/ADAPTER_VALIDATION_CACHE.md

@@ -0,0 +1,10 @@
+# Route adapter validation cache
+
+P28 partial performance work. Route invariant validation now retains one private successfully parsed snapshot, like the facility projector. A fresh serialized snapshot is compared by complete content on each call; changed records/revisions/quarantine state are re-parsed. Live source/graph checks remain outside the cache. Restore still always invokes the strict parser. All snapshot arrays are independently allocated, and no save schema changes were made. This adds memory for one retained adapter snapshot; maximum-history memory acceptance remains outstanding.
+
+Evidence:
+- Route adapter184 checks PASS, including unchanged/repaired history, fingerprint corruption without a revision change, mutated exported containers and independently changed/repaired live graph.
+- Facility projector192, Runtime infrastructure162 and Runtime integration20 checks PASS on this production change. The integration suite covers disk save/load and deterministic replay.
+- Small production headless fixture: adapter validation average1.423ms →0.424ms; nested projector validation2.536ms →1.533ms; x1 average16.348ms →14.359ms; x3 P9560.411ms →53.828ms.
+
+Performance budgets4ms/12ms remain failed. No high-load/GPU/Windows acceptance is claimed. Source/log hashes: adapter-cache-validation.json. Performance reports: production-projector-cache.json and production-adapter-cache.json. Snapshot-component diagnostic completed: production-snapshot-costs.json. Snapshot total average7.999ms; OperationsCoordinator.create_snapshot3.622ms; whole-snapshot deep copy1.095ms. These standalone component samples are not an additive phase decomposition. Source inspection identifies recursive tree/shape validation plus serialization in OperationsCoordinator; its corruption rejection contract must remain intact in the next optimization.

docs/plans/original-completion-2026-09-29/execution/AMELIA_DONATIONS.md

@@ -0,0 +1,17 @@
+# アメリアの寄付金3倍
+
+原本6.2「寄付金3倍」、6.4「配置するだけで自動発動」を礼拝堂の価格経路へ接続。ユニーク雇用・聖職者・ID heroine_amelia の人物が配属された礼拝堂を対象とし、他の礼拝堂や宿泊料金へは波及しない。出勤状態ではなく配置を参照する。
+
+既存の寄付を礼拝サービス料金として扱う契約に沿い、価格方針適用後の寄付額を3倍、その後に既存のアンリ配置階補正を一度適用。標準20Gは60G、アンリ併用では72G。客の支払額と施設売上は一致し、受理済みの見積は料金変更や保存復元で書き換わらない。営業画面の現在値・変更後予測・効果説明にも反映。
+
+通常加入の初期能力・加入条件は未設定のまま。試験では register_staff によるユニーク人物fixtureを使用し、その後の配置は従業員画面、来客は通常AI、礼拝・支払・信仰加算はRuntimeで動かした。アメリアの通常加入、回復速度2倍、人物の全実装を完了と扱わない。
+
+検証: 専用macOS実描画39チェックPASS。料金60G、別施設・別職種・一般雇用への非適用、アンリ併用72Gと解除、礼拝中に90Gへ変更しても受理済み60G維持、復元、客支出と帳簿一致、信仰は寄付額に関係なく完了ごと1を検証。営業画面gameplay.pngで60G・寄付金3倍・信仰+1を目視確認。
+
+関連回帰: 通常礼拝堂16、アンリ48、営業画面72チェックPASS。初回2回の専用試験は信仰を1で固定していたため失敗した。他の自律客も礼拝を完了して信仰2となっており、礼拝完了件数との一致に改めた。失敗ログも保持する。
+
+証拠: artifacts/amelia-donations-2026-09-29/。全原本・Windows・長期プレイは未完了。通し再起動の最終結果は追記する。
+
+## 通し検証完了
+
+実描画の別プロセス再起動: 書込80・読込17の計97チェックPASS、両方終了コード0。書込62.68秒・読込47.65秒。source-change.jsonは空、write/read-gameplay.json一致。通常開業・3回決算の回帰であり、アメリア固有の効果試験は上記39チェックで別に検証。

docs/plans/original-completion-2026-09-29/execution/ANRI_APPROVED_INTEGRATION.md

@@ -0,0 +1,10 @@
+# アンリの通常加入・料金補正に関するユーザー決定
+
+今回の会話でユーザーが以下を明示承認した。
+
+1. 「従業員画面で無料加入を選ぶ」。新規ゲーム開始時の自動在籍や未指定イベント条件に置き換えない。
+2. 「利用料金を20%増やし、客の支払額と施設収入を一致させる」。架空の追加収益や補助金として20%を生成しない。
+
+原本の配置フロア全施設への効果、雇用／維持費無料、解雇売却不可は維持する。加入処理、画面、配属、料金見積もり、財布／台帳、途中保存の接続は未完了。この文書は実装完了を示さない。
+
+接続時の既存コード課題: staff_hire_payload と雇用済みID復元検査は一般候補のみを受け付ける。雇用後検査が FREE_HIRE 固定。候補UIと管理UIの表示名参照も一般候補のみ。アンリの innkeeper 職種と施設の required_roles の整合を明示し、一般職の偽装で代用しない。保存マニフェストの通常候補20件とユニークの別ID一覧を維持して、雇用済み集合の解釈を拡張する必要がある。

docs/plans/original-completion-2026-09-29/execution/ANRI_FLOOR_PRICING.md

@@ -0,0 +1,27 @@
+# アンリの配置フロア料金+20%を実行処理へ接続
+
+ユーザー承認の料金方式を実装。正規加入したアンリの職種 innkeeper と UNIQUE 属性を確認し、通常の従業員配置コマンドで施設へ管理配置する。staff_max と経路の検査は維持する。女将は運搬員などの専門職に変換せず、施設の稼働最低人数には数えない。保存復元側にも同じ管理配置の職種例外を適用した。
+
+適用範囲は確定した施設配置のY座標が同じフロアの全施設（表裏双方）。原本「配置するだけ」のため予定として保持される配置から導出し、通勤完了・勤務時間を新たな発動条件にしない。配置解除／配置施設不在で補正なし。同じ人物の効果を積み重ねない。基準料金に営業方針の倍率を適用した後、12000bpを一度適用し、既存料金と同じ整数Gの四捨五入を使う。無料受付は0のまま。
+
+自律客の候補見積もり、通常サービス申請の既定価格、営業画面の現行価格と方針変更プレビューを共通計算へ接続。営業画面に「アンリ配置フロア：利用料金＋20%」を表示する。受付後は従来通り ServiceRequest／ServiceInstance の価格を固定する。
+
+Runtime22項目PASS: 通常建設した上級客室と同階裏層倉庫、業務階段、正規加入、到達可能な管理配置、別階への非適用、264Gの受付／実サービス完了／財布減算／同額施設売上／台帳整合、途中保存と解除後の220G復帰を確認。女将が倉庫の運搬員として稼働人数を満たさないことも確認。支払試験は明示的なゲスト財布・サービス申請の制御fixtureであり、自律客の来館から最終退館までの実プレイではない。
+
+macOS描画ありUI19項目PASS: 無料加入と保存、通常画面で受付へ女将を配置、大浴場の24G表示、150%方針の設定後36G表示、効果の説明を確認。画像 anri-floor-assigned.png を視認した。既存営業UI65／従業員UI87もPASS。最初のRuntime試験で保存時の職種照合の不一致を検出し修正した。試験側の誤った台帳API名も修正済み。
+
+証拠は artifacts/facility-dimensions-2026-09-29/anri-floor-validation.json。初回の今回画像取得で旧 anri-recruited.png が更新されたため、旧加入マニフェストの画像ハッシュは歴史的証拠。現行画像は専用名へ分離した。
+
+残件: 自律来館からの通し営業、配置変更／夜勤等の追加境界、他6名の固有効果・成長・物語、Windows同一ビルド。P17全体／全原本の完了ではない。
+
+## 自律客の利用と支払の追加確認
+
+Runtime試験を36項目へ拡張し全PASS。通常の建設コマンドで表層階段を追加し、アンリを再配置。客の初期欲求・所持金を制御して生成した後、目的地・経路・価格を指定せず、客自身の選択、階段移動、利用開始、264Gでの宿泊完了を確認した。移動途中の保存を復元すると利用開始時の全スナップショットが一致する。財布の減算264Gと施設売上264Gも一致し、完了後の保存復元・台帳整合が通る。ランダム来館から退館までの実プレイ受入を完了した意味ではない。
+
+同じ版で加入UI17項目もheadlessでPASS。今回の変更は追加試験・証拠・進捗記録であり、追加の本体修正は不要だった。証拠: `artifacts/facility-dimensions-2026-09-29/anri-autonomous-validation.json`。
+
+## 配置変更・夜勤・撤去境界
+
+Runtime試験48項目PASS。同じアンリを上階の昼勤配置から地上階の夜勤配置へ変更し、旧階の料金が220Gへ戻り、新階だけが12000bpとなることを確認。staff_max=0の客室への変更は拒否され、元の配置・補正が保持される。配置中の倉庫撤去はSTAFF_ASSIGNEDで拒否され、施設と効果を保持する。夜勤配置の全スナップショットを3回復元しても完全一致し、補正が累積しない。元の階への再配置でも同じ料金へ戻る。これは予定配置の切替試験であり、一晩の勤務行動すべてを検証したものではない。
+
+今回追加した境界では本体不具合は検出されず、本体コードの変更はない。ログ: `artifacts/facility-dimensions-2026-09-29/anri-placement-boundaries.log`。

docs/plans/original-completion-2026-09-29/execution/ANRI_INTEGRATED_UI_REGRESSION.md

@@ -0,0 +1,9 @@
+# Anri integrated UI regression
+
+make test-ui GODOT=/opt/homebrew/bin/godot completed in 106.08 seconds with exit code 0. Godot 4.7.2, macOS, headless. Source hashes remained unchanged throughout the run.
+
+20 direct scripts passed 992 checks. The separate-process upkeep save/write and read phases also passed. The direct scripts cover Anri pricing (48), recruitment (17), layer skin, rank, pointer controls, migration, upkeep inspector, rest, rescue, guest observer, room/pixel presentation, dashboard, staff, supply, business, elevator and first operating day (59). The latter includes opening, time progression and daily settlement.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/anri-full-ui.log and anri-full-ui-result.json (source hashes). The fresh-process evidence was copied to anri-upkeep-write.log, anri-upkeep-read.log and anri-upkeep-result.json in that directory.
+
+This proves the UI regression scope only, not full original acceptance, Windows native behavior, visual acceptance, all characters/facilities, long-term progression or performance compliance. Known production performance failures and remaining work packages remain open.

docs/plans/original-completion-2026-09-29/execution/ANRI_OPENING_GUIDE_ROLE.md

@@ -0,0 +1,11 @@
+# Opening guide must require receptionist coverage
+
+Confirmed a user-visible integration defect: the guide counted any repeating work assignment at reception as receptionist coverage. Anri can be placed there for her floor passive but is excluded from required operational staffing. Consequently the guide could invite the player to wait for sales while no receptionist was assigned. The same error survived load.
+
+The guide now checks the facility definition's required roles before counting active staff, repeating plans or legacy shifts. It still accepts an actual receptionist's off-duty recurring plan and does not alter simulation staffing or Anri's floor price effect.
+
+Before-fix evidence: anri-guide-before.log reports 22 checks with 2 failures (manager mistaken for receptionist, including after load). After-fix Anri UI coverage: 22 checks PASS. The first-operating-day scenario additionally places Anri via staff controls after constructing reachable rooms, verifies the displayed guide remains on staff recruitment and the floor multiplier remains 12000, then restores the ordinary scenario and continues natural arrival, sales and settlement. Read its completed log for acceptance; no synthetic guest was added to that operating-day scenario.
+
+Evidence directory: artifacts/facility-dimensions-2026-09-29. This fix does not complete other unique characters, full original acceptance or Windows validation.
+
+Completed: Anri recruitment UI 22 checks PASS and first operating day 63 checks PASS, both exit code 0. Source/log hashes recorded in anri-guide-validation.json.

docs/plans/original-completion-2026-09-29/execution/ANRI_ORIGINAL_EFFECT.md

@@ -0,0 +1,11 @@
+# アンリの固有効果定義を原本へ修正
+
+原本 B-6.2 は「配置フロアの全施設売上+20%」、B-6.4 は配置によるパッシブ発動を指定。従来の mvp_unique_characters.json は assigned_floor_patience_loss_multiplier_bp=9000 とし、忍耐減少を軽減する別効果を定義していた。この値は原本準拠ではない。
+
+現在のアンリ定義を assigned_floor_revenue_multiplier_bp=12000 へ修正し、カタログのホワイトリストと heroine 必須効果を同じキーへ変更した。旧忍耐キーの不在と12000、返却データの防御コピー、係数の検証を試験する。人物ID、年齢、他の未承認バランス値、ライバル効果はこの修正で変更しない。
+
+検証: MvpContentCatalog213、Runtime content/progression108項目 PASS。後者は通常候補雇用、カタログ保存マニフェスト、改ざん拒否、24時間保存再生を含む。Runtime のマニフェストは人物IDを保持し効果の辞書を保存していないため、この定義修正に伴う保存形式変更はない。ソースとログの SHA-256 は anri-original-definition-validation.json。
+
+重要な残件: 現 Runtime は unique_characters を通常の hire_staff_candidate に接続しておらず、アンリの配置も売上倍率も営業処理に適用しない。この変更は定義差異の是正のみで、B-6.2／P17 の実装完了ではない。単なる料金+20%で「売上+20%」を代用してよいとも決めていない。通常の加入／配置導線、原本全7名と職種、無料／解雇不可、施設・フロア範囲、シフトとの関係、価格と売上補正の会計契約、保存復元、表示、通常営業の受入が必要。
+
+次の作業では既存の一般雇用とユニーク加入を区別し、原本に数値のない加入条件等を仮定せずに接続契約を整理する。忍耐効果が元から Runtime に効いていたとは報告しない。

docs/plans/original-completion-2026-09-29/execution/ANRI_RECRUITMENT.md

@@ -0,0 +1,11 @@
+# アンリの無料加入を通常UIへ接続
+
+ユーザー指定の「従業員画面で無料加入」を実装。一般候補20名のカタログ区分を保ち、加入可能一覧へ承認済みのアンリだけを加えた。ライバル加入条件は追加しない。アンリは女将 innkeeper／UNIQUE、契約金0／日給0、既存定義の技能・希望勤務帯で加入する。未定の業務適性は一般職の偽装や任意タグで代用しない。
+
+既存の検証済み雇用トランザクションを再利用し、保存の加入済みID検査と人物属性の照合を UNIQUE に対応させた。登録の迂回は引き続き拒否し、加入済みアンリの欠落・FREE_HIREへの降格を復元時に拒否する。一般求人のID一覧と保存マニフェストの区分は変更しない。管理画面はユニーク定義の名前と女将の職種名を表示する。
+
+通常画面のボタンから申請→重複送信拒否→手動保存→対照状態へ復元→読込→次の時間更新で加入→加入後保存・読込を検証。アンリ本人のUNIQUE属性、所持金不変、日給0、加入済み表示、退職拒否、不正な保存の原状保持を確認。headless13、macOS描画あり15項目PASS。anri-recruited.pngを視認し、アンリ（女将）・日給G0・未配属を確認した。
+
+関連回帰: catalog213、Runtime content116（24時間保存再生を含む）、dashboard139、staff UI87項目PASS。ダッシュボードの候補数期待値は一般20+アンリ=21へ更新。初回画像取得は試験がパネルを閉じてしまっていたため、可視性を明示検査するよう修正して再取得した。
+
+証拠とSHA-256: artifacts/facility-dimensions-2026-09-29/anri-recruitment-validation.json。通常配属とフロア料金+20%はまだ接続していないため、固有効果・P17・全原本の完了ではない。Windows同一ビルド未検証。

docs/plans/original-completion-2026-09-29/execution/BUSINESS_CUSTOMER_COUNTS.md

@@ -0,0 +1,7 @@
+# Business panel counts people separately from services
+
+The business report exposed active service/request counts, but the panel labelled them as people. This undercounted multi-person services and queues. Added active_customer_count (FacilityInstance.customer_count), queued_customer_count (distinct guest IDs from queued requests), and customer_capacity to the read model. Existing active_count/queued_count retain their service/request semantics. The panel now uses actual people and explicitly displays the customer-only limit;0 and unspecified(-1) remain distinct. No capacity values, billing, service lifecycle, or saved fields were changed.
+
+Controlled grouped UI fixture: one active service/two people and one queued request/three people; explicit limit3, unspecified and zero; original fixture restored before later tests. This verifies display/read-model semantics, not a new group-arrival gameplay feature. Business UI72 checks passed headless and native macOS; chapel16 passed; original facility control result is recorded in the validation file. Native1280x720 screenshot visually reviewed: labels and actions remain inside scrollable sidebar.
+
+Evidence: artifacts/business-people-2026-09-29/validation.json and logs/screenshots. Prior full128 suite and3-day run predate this display-only change. Facility customer values and other original implementation gaps remain open.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_ANRI_WINDOWS_PACKAGE.md

@@ -0,0 +1,12 @@
+# Chapel/Anri Windows development package
+
+Built the current local production source using Godot4.7.2 Windows Desktop export into `build/windows/chapel-anri-2026-09-29`. Export exited0; EXE is PE32+ x86-64. Production-source/asset hashes were captured before export and remained unchanged through verification. This is an incremental development package, not completion of P29 or the original specification.
+
+Validation ran each external test driver from an empty temporary directory with `--main-pack`, so game data/implementation came from the PCK rather than the checkout. Opening test explicitly verified absence of raw source project/definition files:28 PASS. Anri normal recruitment/assignment/fee/SaveLoad:22 PASS. Chapel normal construction/cleric/guest/worship/payment/Faith/SaveLoad:16 PASS. The same packed chapel scenario rendered on macOS:17 PASS; packed-chapel.png was visually inspected. These are repeated/overlapping scopes, not83 independent acceptance requirements. No Windows EXE was executed.
+
+Source regression reference:127 source suites completed before the latest ledger label correction; the correction was subsequently covered by97 checks in the rendered two-process three-close flow. Keep those scopes separate from PCK tests. Performance budgets, full original facilities/stories/assets and Windows native acceptance remain open.
+
+Pack contains EXE, PCK, Japanese README with current feature/verification boundaries and Windows smoke steps, BUILD_MANIFEST.json, existing Kenney licenses/source records, and Godot license/third-party notices obtained from the installed engine's license APIs. ZIP CRC verified. Build/source/screenshot results are retained under `artifacts/chapel-package-2026-09-29`.
+
+ZIP: build/windows/TheTree-Windows-chapel-anri-2026-09-29.zip
+SHA-256: 08c759e8d4cca0268fdd4d3be0f3f9d79bf390f9cd6deb8749d95dd6dfca6ba5

docs/plans/original-completion-2026-09-29/execution/CHAPEL_APPROVED_INTEGRATION.md

@@ -0,0 +1,27 @@
+# Chapel integration - approved balance and first service boundary
+
+User explicitly approved the proposed initial trial values: construction 1200G, materials12, duration180min; simultaneous customers8; cleric minimum1 and staff maximum2; worship60min, donation20G, completion Faith+1; daily upkeep6G. Original specifies footprint4x3, FRONT. Values are initial trial balance, not original numeric requirements. Queue capacity8, default quality50 and no mana upkeep are provisional inherited/implementation choices, not stated original values.
+
+Implemented a staged chapel Resource at data/facilities/expansion/chapel.tres and a nonnegative FacilityDefinition.faith_per_service property (default0). DefinitionRegistry rejects negative reward values. Runtime completion now applies the faith resource and progression faith_lifetime metric at the existing service settlement boundary after inventory/payment/output checks. Failure rolls back inventory, economy, resources and progression; the service does not complete. Existing definitions have zero reward. Duplicate paid completion is rejected by the existing payment idempotency key and terminal services do not re-complete after restore.
+
+The staged test explicitly adds the chapel to its registry, constructs via normal build command, and uses controlled staff availability and payer wallet. It checks dimensions, approved values, unstaffed closure, service start, no early payment/reward, midway restore, donation20G, Faith+1 and lifetime+1, completed reload without duplicate, exact replay, and failed progression with payment rollback and one recovered reward. This is not normal recruitment or autonomous guest acceptance.
+
+Remaining before normal catalog exposure: cleric recruitment with appropriate wage/hiring balance, catalog/save compatibility, normal construction palette and role labels, autonomous worship selection/arrival/queue/payment, staff-loss interruption, capacity8, upkeep6G and UI faith explanation, native screenshots and Windows. Do not count the chapel as a normally playable completed facility yet.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/chapel-service.log, chapel-existing-cycle.log, chapel-anri-pricing.log. Their completed outputs are authoritative for pass counts.
+
+## Normal catalog and cleric recruitment
+
+Chapel is now registered in the original-facility catalog and main construction palette. A licensed existing theme icon is reused as a placeholder, not claimed as completed chapel art. Added regular cleric staff_uma with Japanese role label. Hiring210G/day wage130G and service skill74 use the existing attendant candidate's initial balance; these staff values are implementation trial values, not original or user-approved facility figures. Original20 candidates remain unchanged. Catalog manifest v2 adds exactly this candidate. The exact historical v1 manifest remains accepted only without the new candidate already present/hired; arbitrary missing IDs are rejected.
+
+New normal-scene test uses construction/hire/assignment controls, actual clerk commuting/staff projection and controlled arrival followed by autonomous guest selection, arrival, worship,20G payment and Faith/lifetime+1. It also covers original manifest migration, malformed manifest rejection and in-service/completed save. It does not prove random-arrival frequency, all-day economics, guest capacity8 or staff-loss interruption.
+
+Native macOS verification completed: 17 chapel gameplay checks PASS, with screenshot chapel-gameplay.png visually reviewed. The business panel shows20G per use and Faith+1 per worship completion; HUD Faith1 and today's revenue20G match actual settlement. Chapel art remains generic placeholder room art. Before the final business-text and malformed-legacy-row guard changes, the complete make test-ui passed (including 14 chapel gameplay checks); final targeted native gameplay, business and content tests cover those last changes.
+
+## Capacity and loss of cleric coverage
+
+Added tests/mvp/test_chapel_boundaries.gd using normal catalog construction, real cleric hire/assignment/attendance and controlled wallets/service requests for capacity boundaries. Eight services start and a ninth waits separately. A normal unassignment triggers WAITING_FOR_STAFF with frozen progress; no early donation or Faith occurs. The paused state and grace deadline restore exactly, and continued absence fails service without reward/charge. Restoring the staffed checkpoint then completes all nine requests for180G and Faith9, never exceeding8 simultaneous users. These first35 assertions passed.
+
+The same test continues in a separate fresh operating game (required06:00 start), builds and staffs a chapel and advances two normal days without inserting guests/services. It checks partial-day upkeep, the full-day6G rate, natural donation/Faith reconciliation and close/reload boundaries. Its final log, not this plan text, is the authority for full acceptance. An initial fixture attempted to enable operations midway, violating the existing start-time contract; corrected to a new game without changing production rules.
+
+Completed boundary/operating run: 46 checks PASS, exit0. First partial-day upkeep3G and next full-day upkeep6G; positive natural donation revenue equals Faith*20, lifetime Faith matches held Faith, ledger balanced and no Runtime failure latch. Both midnight boundaries and second-day completed close restore successfully. Evidence: chapel-boundaries-validation.json. This is one seed over two days, not a long-term economy or Windows acceptance.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_FULL_REGRESSION.md

@@ -0,0 +1,21 @@
+# Full source regression after chapel integration
+
+Started tools/run_all_tests.py with Godot4.7.2 and output artifacts/chapel-full-regression-2026-09-29. all-tests.json is incremental and does not establish full completion until the runner exits. Source hashes at launch are in source-start.json. The runner excludes exported-package tests and the kernel module invoked by run_tests.gd. A separate packaged-build acceptance is still required.
+
+Read-only audit identified obsolete21-facility expectations in Runtime integration, Runtime stairs and exported opening. The two source tests were independently run before changing them and each failed only on that old count. Updated expected count to22, including chapel, and added explicit chapel registration assertion. Targeted reruns: Runtime integration21 checks PASS; stairs67 checks PASS. Export expectations updated for the future rebuilt pack; no exported package has been verified by this action.
+
+Only these three test files changed after source-start.json during the sweep; the production source was not changed by this regression repair. The full runner will later execute the corrected source tests. Preserve before/after logs instead of treating the original failure as a gameplay defect. Final source hashes and the complete result must be checked when the runner finishes.
+
+Runner exec session18695 was confirmed live during this turn, processing test_chapel_boundaries.gd. Continue polling the same session; do not restart solely because a poll times out.
+
+## Public catalog lookup correction during regression
+
+Read-only audit found that `FacilityCatalog.by_id` omitted ORIGINAL_FACILITY_PATHS. Chapel was therefore registered in normal Runtime construction but returned null from this common query. Expanded the lookup to include original-facility paths without altering baseline/optional expansion lists. Added a contract test that every normally registered resource resolves to the identical definition through the public lookup. Before: one failure out of310 (chapel only). After:310 PASS, exit0. Evidence: catalog-lookup-repair.json and before/after logs.
+
+The sweep had already run the previous266-check registry test when this correction was made. Production catalog and registry test are two additional files changed since source-start.json, beyond the three count-repair test files. Therefore retain the sweep result and this targeted correction as distinct evidence; do not claim the sweep alone covered one frozen final source revision. No production caller of by_id was found in scenes, scripts or autoload besides the catalog definition; normal Runtime builds its own registry from explicit paths.
+
+## Completed source sweep
+
+Runner session18695 exited0. All127 unique source suites passed with zero failures. Recomputed discovery matches executed paths exactly (no missing or unexpected suite). `completion.json`, `all-tests.json` and `source-end.json` retain the result. Five previously documented files differ from launch hashes: three count repairs plus catalog lookup and its regression test. The latter's final310-check run separately passes. This is combined regression evidence, not a single immutable-source full sweep. Export/PCK and Windows are not included. New paired restart-debug fixture/runner were prepared separately and were not part of this discovery list.
+
+After this successful sweep, started rendered `run_opening_restart_flow.py` into artifacts/opening-restart-debug-2026-09-29. Read its result.json and phase logs for completion; launch alone is not acceptance.

docs/plans/original-completion-2026-09-29/execution/CHAPEL_ROOM_PRESENTATION.md

@@ -0,0 +1,9 @@
+# Chapel room presentation
+
+Replaced the generic chapel table with code-native furnishings: a world-tree glass motif, altar with cloth and candles, and paired pews separated by a central aisle. Visitor anchors share the furniture layout, cap at8 visible people, reserve upper wall space for the altar, and adapt to canonical4x3 and rotated3x4 footprints. Suppressed the generic upper-wall worker counter in this room. Simulation position, service state and finances are untouched.
+
+Asset sourcing: inspected the existing Kenney Tiny Town/Tiny Dungeon package inventory and existing renderer conventions. Existing packs and character/environment sprites remain under their recorded CC0 licenses (assets/kenney/sources.json and package License.txt). New altar/window/pew geometry is authored in scripts/ui/pixel_tower_art.gd rather than imported bitmap media. No new external assets or rights were introduced. The palette icon still reuses an existing generic theme icon.
+
+Tests cover8 anchors and non-overlap at0.5/1/2/4 scale and rotated footprint, alongside existing room state/pixel behavior. Native gameplay captures the real worship visitors,20G revenue and Faith1 in chapel-art.png. This is an initial chapel visual, not completion of the original Lv1-3 asset set, all animation states, audio or Windows acceptance.
+
+Evidence directory: artifacts/facility-dimensions-2026-09-29, chapel-art-rooms.log, chapel-art-pixel.log, chapel-art-native.log, chapel-art.png. The first art capture reused chapel-gameplay.png, so the older normal-validation screenshot hash is historical; the current art evidence now has its own filename and the capture harness supports THE_TREE_CHAPEL_CAPTURE_PATH for future preservation.

docs/plans/original-completion-2026-09-29/execution/CLEANING_ACCESS_FOLLOWUP.md

@@ -0,0 +1,15 @@
+# 清掃の経路・表示追補
+
+2026-09-29。清掃先の最初の通行可能セルが孤立すると、別の入口が到達可能でも作業を開始できなかった。未割当の予約で到達可能な入口を選び直し、移動中の経路喪失時も同じ仕事の目的地を再評価するよう修正。到達可能な既存目的地は維持する。すべて孤立した場合は移動せず待機し、再接続後に再開する。汎用の行き詰まり救済による移動をこの待機には適用しない。
+
+保存検証では、清掃目的地が施設に接する正しい位置かという条件と、その時点で歩けるかという条件を分けた。経路喪失中の待機先は幾何的に妥当な位置を維持できる。作業中の床が通行不能になれば作業を中断する。承認された8分/25回復などの値は変更していない。
+
+清掃員室の営業画面を「清掃業務を有効にする」「顧客利用なし・清掃員の業務拠点」に変更し、停止時は途中作業も中断すると説明。料金のない施設を顧客受付として案内しない。
+
+証拠: `artifacts/cleaning-access-2026-09-29/targeted.json` の6スイートがPASS。経路6項目は実PathServiceと配置を限定したfixtureで、孤立入口/代替/全閉塞/保存対象位置/再接続/対象撤去を検証。通常Mainの建設・雇用・配置・清掃・中断・保存再開は82項目PASS。営業画面・通勤・snapshot ownershipも再試験。`source-hashes.json`に最終ソースを固定。
+
+実描画の追加結果は同ディレクトリ `native.log` と `cleaning-room-ui.png`。この再実行は同じ操作シナリオであり、独立した受入項目として重複加算しない。
+
+全体回帰は既存セッション59503を継続しており、再起動していない。実行中に本追補のソース変更が入ったため、`cleanliness-runtime-2026-09-29/source-start.json` と同一の固定ソースで全件通過した証拠にはしない。本追補後の関連再試験と、既存全体回帰の結果を別々に扱う。全体終了後に失敗を確認し、最終候補の全体確認・通しデバッグへ進む。
+
+なお経路fixtureだけでWindows実機や長期営業、すべての建設/撤去/勤務交代の組合せを受入済みとはしない。清掃専用モーション、満足度/汚染伝播、原本の他の残件は継続中。

docs/plans/original-completion-2026-09-29/execution/CLEANING_ANIMATION.md

@@ -0,0 +1,19 @@
+# 清掃アニメーションと実作業の一致
+
+P25 / B-12.3、B-13.2 の部分対応。清掃員の職種とWORKING状態だけでモップ姿勢を選ぶ表示を修正。実際のfacility_cleanタスクがWORKINGで、現地・依存元施設・移動状態等の作業条件を満たす場合だけ清掃姿勢を選ぶ。拠点の待機はidle、移動は既存の歩行表示を使う。
+
+既存PixelPeopleの独自描画モップ姿勢を利用し、外部素材の追加はない。保存形式・清掃の数値・課金には変更なし。
+
+通常画面を通す清掃テスト90チェックPASS（待機、移動、現地作業、保存復元、完了、中断を含む）。macOS実描画版は画像保存1件を加え91チェックPASS。停止中のアニメーションとシミュレーション分離を含むpixel_tower、room_presentation、staff_rest、staff_rescueの4スイートPASS。working.pngで実位置と清掃中0/8分の表示を確認した。
+
+証拠: artifacts/cleaning-animation-2026-09-29/。表示修正後の営業・決算・別プロセス再起動の通し再検証は同フォルダopening-restartで実行中。以前の132スイート合格は表示修正前の証拠であり、今回の全体回帰とは数えない。全P25、全原本、Windows実機の完了を意味しない。
+
+## 再起動検証で判明した清潔度の順序不整合
+
+opening-restartとrestart-diagnosisは再起動時の状態ダイジェスト比較で失敗。3日分の会計は一致したが、診断用に保存したwrite-gameplay.json/read-gameplay.jsonではfacility_cleanliness.facilitiesの最初の2施設だけが逆順だった。StringNameキーの既定ソートに依存していたため、清潔度スナップショットと清掃予約対象列挙をStringへの変換による明示的比較へ変更した。旧データの施設配列順は受け入れ、出力を正規順序へ揃える。schemaや数値の変更はない。
+
+生成ID32件と逆順保存入力の回帰を追加。清潔度モデル49チェック、Runtime、清掃経路、清掃UI90チェックの4スイートPASS。比較から清潔度や配列を除外せず、通しデバッグをrestart-fixedで再実行中。失敗ログも保持している。
+
+## 修正後の通し検証完了
+
+restart-fixedは両プロセス終了コード0、書込側80・読込側17の合計97チェックPASS。全ゲーム状態ダイジェスト、保存したJSON状態、3回決算の一致を確認。source-change.jsonは空で実行中のソース変更なし。修正前の失敗は隠さず保持した。全体回帰132件の証拠は前のソースに対するもので、今回は変更対象の関連試験と通し再検証を実施した。

docs/plans/original-completion-2026-09-29/execution/CLEANING_APPROVAL_RECHECK.md

@@ -0,0 +1,9 @@
+# 清掃承認値の現行実装再確認
+
+2026-09-29。清掃員室・清掃業務は回答済みの初期試験値を維持。施設定義は2×1・裏層、350G・資材4・60分、清掃員1人必須／上限2人、顧客0・料金0・維持費2G/日。ポリシーは初期100・上限100、75以下で予約、現地8分、完了時25回復。未定義の汚れ量は補完していない。
+
+現行ソースで再実行: 清掃モデル49、Runtime29、経路6、通常UI清掃90、合計174チェック、失敗0。通常UI清掃試験は建設・雇用・配置・実到着・8分作業・保存再現・最終作業前の閉店／停電中断を含む。
+
+macOS実描画の通し検証は書込側80・別プロセス再読込側17、合計97チェックPASS、双方終了コード0。書込62.34秒、読込47.89秒。ゲーム状態JSON一致、試験中ソース変更なし。2日目朝の画面で日本語帳簿とドット施設・人物を確認。
+
+証拠: `artifacts/cleaning-approved-recheck-2026-09-29/`。今回の追加機能実装ではなく、承認値の反映済み確認と現行コードの再検証。清掃固有試験と開業・再起動試験は別シナリオ。原本全項目、長期プレイ、Windows実機、性能予算の完了を意味しない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_APPROVED_FOUNDATION.md

@@ -0,0 +1,31 @@
+# 清掃員室・清掃業務の承認済み初期試験値と実装状況
+
+2026-09-29。ユーザー回答 `call_6ktCNjGSwiR0e3x5HukIZKfA` の項目0・1はいずれも「この初期値で試験・調整する」。再承認は不要。原本未指定の数値を原本由来として扱わず、試験用の承認値として管理する。
+
+## 承認内容
+
+清掃員室: 原本指定2×1・裏層。建築350G、資材4、工期60分、清掃員1人必須・配置上限2人、顧客同時利用0人、利用料なし、維持費2G/日。
+
+清掃: 清潔度0〜100・初期100。既存の `cleanliness_decay_per_service` を利用完了時に適用。75以下で予約。現地で8分作業し、完了時25回復、上限100。未定義施設の汚れ量は補完しない。
+
+## 今回の成果
+
+- `data/facilities/expansion/cleaning_room.tres`: 上記初期値の施設定義。通常カタログ・建設パレットへはまだ登録していない。
+- `data/environment/cleaning_policy.json` と `scripts/environment/facility_cleaning_policy.gd`: 承認値と厳格な読込・検証。欠損、未知版、非整数、不正な境界は既存値を変更せず拒否。
+- `scripts/environment/facility_cleanliness_service.gd`: 利用・清掃完了IDによる重複反映防止、上下限、順序を保持する履歴、保存復元、破損時の原子性、施設削除。
+- `tests/environment/test_facility_cleanliness.gd`: 47 checks、0 failures。Godot4.7.2、macOS headless。`Makefile` test-s2に登録。
+- 証拠: `artifacts/cleanliness-foundation-2026-09-29/approved-policy.log`。初期の新クラスキャッシュ未更新による失敗ログも保存。editor import後にモデル試験が通過し、今回ポリシー検証追加後の47項目も通過。
+
+## 次の接続と完了条件（未実装）
+
+1. Runtimeの施設登録・利用完了・撤去と清潔度を接続。建設・撤去・営業トランザクション失敗時に清潔度も巻き戻す。単体モデルを通常動作済みとは扱わない。
+2. Runtime保存版12を追加し、天候版11の条件を独立定数へ切り出す。旧版は既存施設を100で初期化。新版欠損・孤立施設・不正履歴を拒否。旧版試験データから新項目を除く。
+3. 稼働中の清掃員室に配置された清掃員、実到着、現地8分作業、25回復を接続。閾値75、重複予約、経路なし、勤務交代、休止、停電、撤去、途中保存を検証。既存デモの清掃タスクを本機能の完了と取り違えない。
+4. 通常カタログ・パレット、施設詳細の清潔度と清掃状況、ドット表示を接続。通常UIの建設→雇用→配置→清掃→保存再開を実証。
+5. 関連回帰と通しデバッグ、現在ビルドの配布・Windows実機確認。全原本実装の認定は引き続き未達。
+
+今回の47項目は基礎モデル・定義・設定の検証であり、Runtime統合、清掃員室の通常営業、描画、Windowsの合格ではない。P07/P09/P12/P16/P24は完了に変更しない。
+
+## 接続後の更新
+
+通常ゲーム接続が進んだため、現在の成果と残件は `CLEANING_RUNTIME_INTEGRATION.md` を参照。上記の「未実装」は基礎モデル段階の記録として保持する。

docs/plans/original-completion-2026-09-29/execution/CLEANING_REGRESSION_RECHECK.md

@@ -0,0 +1,21 @@
+# 清掃統合後の全体回帰と現行ソース再確認
+
+全体回帰セッション59503は終了コード1で完了。131スイートのうち130がPASS、`tests/ui/test_main_dashboard.gd` が139チェック中2失敗。建設パレットとアイコン付きボタンの期待値が22のまま残っていたため、通常登録済み23施設に合わせて修正した。従業員候補の22件という別の期待値は維持。
+
+途中で経路・清掃員室表示の修正が入ったため、全体回帰が同一ソースで実行されたとは認定しない。`artifacts/cleaning-regression-final-2026-09-29/recheck.py` が、最後の共通実装変更より後にログを新規作成して開始した105スイートの合格を保持し、それ以前の25件・失敗した画面試験・新規経路試験の計27件を現行ソースで再実行している。テスト自身の変更は当該エントリを再実行対象にし、Makefileの追加は直接起動されるGodotスイートの実装変更とは区別。
+
+再確認の実行ハンドル26042。`selection.json`に根拠、`rechecks.json`に進捗、`source-start.json`にソース識別を記録。終了時は全132件の網羅性・失敗0・再確認中の全対象ソース不変を `verification.json` で確認する。現時点は実行中で、全132件PASSとはまだ言わない。
+
+この確認が通ってから `tools/run_opening_restart_flow.py --rendered` を新しい証拠ディレクトリで実行し、3回決算とプロセスを終了した後の再起動・ロード・継続の一致を検証する。原本の全実装やWindows実機の完了を意味しない。
+
+## 再確認の完了
+
+27件の再実行が全件PASSで終了コード0。保持105件と合わせて132/132件を網羅し、失敗0・未実行0。`verification.json`で再確認開始/終了のソースハッシュ一致を確認した。
+
+実描画の通しデバッグを `artifacts/cleaning-opening-restart-2026-09-29` へ開始（実行ハンドル19187）。このシナリオは通常開業・3回決算・別プロセスでの再読込を対象とし、清掃員の派遣固有シナリオは別の清掃UI試験で検証している。完了結果は後記。
+
+## 実描画の通しデバッグ結果
+
+macOS / Godot 4.7.2、実描画で書込側80・再起動側17の合計97チェックPASS、両プロセス終了コード0。通常開業から3回決算し、2日目08:00の保存を別プロセスで読み込んだ継続結果が一致。ゲーム状態比較では計測時間を含むdomain_eventsだけを除外し、他の状態・ID・乱数を比較した。
+
+各日損益は-64G、+346G、+346G。3決算すべて帳簿照合一致。`source-change.json`は空配列で実行中の対象ソース変更なし。再起動後3回目決算の画像も確認し、日本語帳簿・施設名・金額の表示を確認した。証拠は`artifacts/cleaning-opening-restart-2026-09-29/`のresult.json、write.log、read.log、expected.json、3画像。Windowsネイティブ、全原本、性能予算、長期プレイの合格を示すものではない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_RUNTIME_INTEGRATION.md

@@ -0,0 +1,40 @@
+# 清掃の通常ゲーム接続（2026-09-29）
+
+作業対象: ローカル制作コピー。承認値は `CLEANING_APPROVED_FOUNDATION.md` を継承。P03/P07/P09/P12/P16/P24の増分実装であり、各パッケージや全原本の完了判定ではない。
+
+## 接続内容
+
+- 清掃員室を通常カタログ・建設パレットへ登録。2×1裏層、350G・資材4・60分、清掃員1〜2人、顧客0人、維持費2G/日。通常登録施設は22→23。
+- 通常建設完了で清潔度100を作成。定義済みの利用後汚れ量を成功したサービス精算に含める。未定義の汚れ量は追加しない。撤去で当該状態・履歴と未完了の清掃作業を除去。
+- 75以下で `facility_clean` タスクを一施設一件予約。稼働中の清掃員室へ実出勤した清掃員を既存Staff/Shift/Path/Taskで派遣し、到着後8分で25回復。移動中・未完了作業には回復なし。完成IDで二重反映を防止。
+- 出張清掃中の職員は清掃員室の業務従事者として稼働を維持する。一般の固定勤務地職員の在席判定は変えない。閉鎖・停電で作業を取り消し、部分回復を与えず、汚れた施設は待機予約へ戻す。
+- 清掃の時間は通常のゲーム時間で進む。ユーザー向け汎用タスクコマンドで生成や進捗の早送りはできない。
+- Runtime保存版12。天候の導入版11を独立定数として維持。旧版は既存施設を100から開始し、過去の利用から汚れを推測しない。新版では欠落・孤立した施設や存在しない完了履歴を拒否。清掃中の人員・仕事・位置、完成後の効果履歴を復元。
+- 建設・撤去・Operations/Event/Authority/Defenseの施設を含む巻き戻しトークンへ清潔度を含める。
+- 営業画面に清潔度と清掃待ち・移動・作業分数を表示。清掃員室には既存パレットを用いた自作コード描画の棚・モップ・バケツを追加。アイコンは既存テーマのF12を再利用し、新しい外部素材は取り込んでいない。
+
+## 証拠と範囲
+
+`artifacts/cleanliness-runtime-2026-09-29/`:
+
+- `focused.log`: Runtime cleanliness 29項目PASS。通常受付建設・利用・汚れ・再開・v11移行・破損拒否・巻き戻し・撤去。清掃員派遣接続前の段階試験。
+- `targeted.json`: 関連18スイートPASS。天候、旧版移行、交通、維持費、決算、礼拝、snapshot ownership、営業画面。これも派遣接続前の段階試験で、最終ソースの全体合格とは区別。
+- `gameplay-boundaries.log`: 操作を含む81項目PASS。通常Main建設・雇用・配置を使用。汚れを直接書き換えず、25件の実サービス完了を発生させた。利用要求の投入は制御された財布/要求fixtureであり、25人全員の自然入館を検証したものではない。通常客の入館も並行して動作し、清掃後は再び汚れる。
+- `gameplay-native.log`: macOS OpenGL実描画、同81項目＋画像保存1項目＝82項目PASS。1280×720の営業画面で清潔度97を視認確認（清掃後に通常の客が再利用）。
+- `capture-extra.log`: 同じ操作シナリオを実描画で再実行、81項目PASS。`cleaning-working.png`に清潔度75・清掃中0/8分、`cleaning-room.png`に裏層の室内を確認。重複実行を独立受入数として加算しない。
+- `full-regression/`: 最終変更後の全ソース回帰を実行中。実行ハンドル59503。完了前に全件PASSとしない。
+- `source-start.json`: 全体回帰開始時の対象ソースSHA-256。
+
+最初のUI試験の2失敗は、清掃後の新規利用による汚れを考慮せず100維持を期待したため。回復の完了記録が一件だけ存在することと、UIがその時点の実値を表示することへ受入条件を修正。ゲーム内の汚れ量は変更していない。
+
+## 継続する確認・調整
+
+- 全体回帰の完了確認、失敗修正、現在ソース識別、3営業日・再起動の通しデバッグ。
+- 清掃員室に残る汎用営業文言「受付」を業務に合わせる。
+- 複数入口のうち一部が孤立する配置、途中の経路喪失、休止・勤務交代・対象撤去・再開の追加境界試験。現在の予約先は安定順の最初の通行可能セルであり、別の入口だけが到達可能なケースの再選択を改善する。
+- 人物の清掃専用動作、全レベル・表裏の完成素材、清潔度から満足度/客の汚染伝播への原本接続は未完了。
+- 現行Windows配布物は今回の変更を含まない。今回の実描画はmacOSであり、Windows実機確認の代替ではない。
+
+## 経路・文言の追補
+
+複数入口の再選択と清掃員室専用文言を実装。`CLEANING_ACCESS_FOLLOWUP.md`を参照。全体回帰の途中変更があるため、開始時SHA固定の全件合格とは扱わない。

docs/plans/original-completion-2026-09-29/execution/CLEANING_WINDOWS_PACKAGE.md

@@ -0,0 +1,25 @@
+# 清掃業務反映 Windows 開発確認版 — 2026-09-29
+
+制作元: `/Users/korizatou114/Projects/とりにく工房ゲーム制作部`。
+配布: `build/windows/TheTree-Windows-cleaning-2026-09-29.zip`。
+Godot 4.7.2、Windows x86_64 PE32+ EXEと外部PCK。通常施設23種。
+
+承認された清掃員室・清掃業務の初期値、移動・現地作業・中断・保存復元・清潔度表示を配布用データへ反映。既存の礼拝堂・アンリも含む。フィーネとアメリアの効果は含むが通常加入は未接続。
+
+## 配布物に対する検証
+
+- 空の一時ディレクトリからPCKを読み、ソース側へのフォールバックを排除。
+- `tools/verify_exported_opening.py`: 起動・建設・ディスク保存復元28チェックPASS。
+- `tests/ui/test_cleaning_gameplay.gd`を外部ドライバーとして使用: 清掃91チェックPASS（元90に隔離確認1を追加）。
+- 同じドライバーのmacOS描画あり実行: 92チェックPASS（スクリーンショット保存1を追加）。画面の日本語、清潔度、清掃業務の専用操作を目視確認。
+- 清掃試験は作業途中のスナップショット復元と再実行一致、閉店・停電時の中断、二重完了防止を含む。
+- EXE形式確認、ZIP CRC、同梱ファイルSHA256、ビルド前後の追跡ソース変更なしを確認。
+- エンジンバージョンとKenney素材が前回配布と同じためライセンスを継承し、素材出典ファイルのハッシュ一致を確認。
+
+証拠: `artifacts/cleaning-package-2026-09-29/` の export.log、packed-opening.log、packed-cleaning.log、packed-cleaning-rendered.log、packed-cleaning.png、外部ドライバー、source-start/end.json、build-validation.json。
+
+## 検証範囲の限界
+
+この版のWindows実機操作は未実施。macOSで同じPCKを検証した結果をWindowsネイティブ検証と扱わない。
+ソース側137スイートの検証内訳と描画あり通し97チェックは CURRENT_FULL_REGRESSION.md を参照し、今回のPCK検証とは区別する。
+原本30施設のうち通常実装16、定義のみ1、未対応13等が残る。原本全実装・長期プレイ・性能受入およびP29完了とは判定しない。

docs/plans/original-completion-2026-09-29/execution/COMPACT_OPERATIONS_HUD.md

@@ -0,0 +1,15 @@
+# Compact operations HUD projection
+
+Measured the main dashboard refresh: approximately9.75ms, including3.64ms spent obtaining a complete OperationsCoordinator snapshot for a short status label. Added get_dashboard_summary on the coordinator and get_operations_dashboard_report on Runtime. They return only live flags, action points, total arrears, terminal/loss/legacy status and the latest close day/profit. UI uses this compact API with old-report fallback for fixtures. Full reports and save snapshots are unchanged. Returned dictionaries/arrays are newly allocated and contain no mutable references to stored summaries.
+
+Dashboard136 checks PASS. Same production fixture: operations text average3635us before /11.75us after; full x1 average34.410ms /30.374ms. x3 P95124.341ms /122.392ms, still above12ms. No claim of budget compliance or GPU/Windows performance.
+
+Opening/save/replay test completed with58 checks,0 failures,exit0 (compact-operations-opening.log), including10 new projection-equivalence and defensive-copy checks. Evidence: compact-operations-ui.log, production-ui-costs.json, production-compact-operations.json.
+
+## Pause/speed projection follow-up
+
+The dashboard still fetched the full operations snapshot inside `_update_pause_and_speed`. Added `deferred_runtime_minute` to the compact API and switched this consumer to it, retaining fallback for older fixtures. No simulation or save contract changed.
+
+Targeted dashboard139 checks PASS,exit0: includes injected deferred-state warning/retry labels and clear-to-resume checks. These validate projection/display, not a complete fault-recovery scenario. Production diagnostic (`production-compact-pause.json`) reports x1 average22.057ms, x3 P9575.145ms, dashboard refresh2.009ms. Compared with the preceding compact-text run30.374ms/122.392ms, the measured update is faster; both budgets remain failed. Runs are headless, small fixture, no GPU/Windows acceptance. Guide subprofile (`production-guide-costs.json`) measured refresh1.115ms, so it did not explain the whole previous dashboard cost.
+
+Latest initial-day/save/replay test completed with59 checks,0 failures,exit0 (`compact-pause-opening.log`), including the added deferred-field equivalence check. Previous58-check pass applies to the preceding increment.

docs/plans/original-completion-2026-09-29/execution/COMPOSED_INFRASTRUCTURE_VALIDATION.md

@@ -0,0 +1,11 @@
+# Reuse composed infrastructure validation without skipping live guards
+
+Current-scene measurement identified snapshot publication and infrastructure validation as major synchronous costs. A trial homogeneous-key shortcut in Operations canonical-collision inspection passed its254 checks but produced no clear improvement (snapshot component2429.85→2416.4us, whole snapshot6656.8→7311.85us). That trial was fully reverted; the retained Operations source is byte-identical to the before copy.
+
+Retained change: Runtime infrastructure crosslink validation no longer independently repeats Spatial and RouteAdapter invariant checks when the active FacilityInfrastructureProjector already validates those exact bound services. Added a read-only identity-binding query. Different bindings and quarantine retain the independent source/adapter checks; all projector-owned history validation, live graph/managed namespace checks, excavation, route-cell and construction crosslinks remain. No revision-only cache, validation limit removal, update-rate change or snapshot-format change was introduced.
+
+Additional integration cases use counted dependencies to verify one source/adapter audit, exact object binding, raw source/adapter corruption rejection, quarantine fallback and different-binding fallback. Current targeted results: infrastructure180, projector192, ordinary opening/SaveLoad/replay63 checks PASS, total435. Existing rollback/callback/strict restore cases remain included in the two infrastructure suites.
+
+Single paired small-scene measurement: construction phase2515.5→1877.025us (~25% lower), x1 average13309.8→12849.475us (~3.5% lower), x3 P9548441→46529us (~3.9% lower). Seed424242,40 samples per speed, macOS Godot4.7.2 headless, deferred UI refresh included, autosave disabled. These are not repeated statistical estimates or full-load/Windows results. Budgets4ms/12ms remain FAILED; snapshot publication remains the larger remaining cost.
+
+Evidence: artifacts/runtime-profile-2026-09-29/validation.json and referenced profiles/logs. The chapel/Anri Windows ZIP was produced before this optimization and has not been rebuilt in this step. Original completion and P28 acceptance remain open.

docs/plans/original-completion-2026-09-29/execution/CURRENT_FACILITY_AUDIT.md

@@ -0,0 +1,54 @@
+# 原本30施設・現行登録監査
+
+通常登録 16、定義のみ 1、対応定義なし 13。通常登録全23件のうち原本30施設以外は7件。
+
+登録状態と読込済み定義の監査。実営業・保存移行・完成資産・Windows・全要件の受入完了は証明しない。
+
+対応定義の寸法・層の不一致: 0件。人数専用上限が未設定: 13件。capacityから人数値を転記していない。高層・背面・騒音・サービス条件は別途受入が必要。
+
+| 原本 | 施設 | ID | 登録 | 寸法 / 層 / ゾーン | 顧客人数上限 |
+|---|---|---|---|---|---|
+| 10.1 | 一般客室 | standard_room | 通常登録・パレット掲載 | 2×1 / FRONT / ANY | 未設定 |
+| 10.1 | 上級客室 | premium_room | 通常登録・パレット掲載 | 4×1 / FRONT / ANY | 2 |
+| 10.1 | VIPスイート | — | 対応定義なし | 未定義 | 未設定 |
+| 10.1 | ドミトリー | — | 対応定義なし | 未定義 | 未設定 |
+| 10.2 | 大衆食堂 | cafeteria | 通常登録・パレット掲載 | 4×2 / FRONT / ANY | 未設定 |
+| 10.2 | レストラン | — | 対応定義なし | 未定義 | 未設定 |
+| 10.2 | 酒場 | tavern | 通常登録・パレット掲載 | 4×2 / FRONT / ANY | 未設定 |
+| 10.2 | 屋台 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 大浴場 | public_bath | 通常登録・パレット掲載 | 6×2 / FRONT / ANY | 未設定 |
+| 10.3 | カジノ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 闘技場 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.3 | 礼拝堂 | chapel | 通常登録・パレット掲載 | 4×3 / FRONT / ANY | 8 |
+| 10.4 | 風俗個室 | adult_private_room | 通常登録・パレット掲載 | 2×1 / FRONT / UNDERGROUND | 未設定 |
+| 10.4 | 高級ソープ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.4 | SM拷問室 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.4 | 闇市場 | black_market | 定義のみ | 4×2 / FRONT / UNDERGROUND | 未設定 |
+| 10.5 | 厨房 | kitchen | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 倉庫 | warehouse | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 待機室 | staff_waiting_room | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.5 | 従業員寮 | staff_dormitory | 通常登録・パレット掲載 | 2×1 / BACK / ANY | 0 |
+| 10.5 | 警備員詰所 | security_station | 通常登録・パレット掲載 | 2×2 / BACK / ANY | 未設定 |
+| 10.5 | 清掃員室 | cleaning_room | 通常登録・パレット掲載 | 2×1 / BACK / ANY | 0 |
+| 10.5 | 医務室 | infirmary | 通常登録・パレット掲載 | 4×2 / BACK / ANY | 未設定 |
+| 10.6 | 覗き部屋 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.6 | 地下牢 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.6 | マナ炉 | — | 対応定義なし | 未定義 | 未設定 |
+| 10.7 | 蔓の昇降機 | guest_elevator | 通常登録・パレット掲載 | 2×2 / FRONT / ANY | 未設定 |
+| 10.7 | 業務用EV | service_elevator | 通常登録・パレット掲載 | 3×2 / BACK / ANY | 未設定 |
+| 10.7 | ワープ | — | 対応定義なし | 未定義 | 未設定 |
+| 10.7 | 魔法砲台 | — | 対応定義なし | 未定義 | 未設定 |
+
+## 未接続施設
+
+対応定義なし: VIPスイート、ドミトリー、レストラン、屋台、カジノ、闘技場、高級ソープ、SM拷問室、覗き部屋、地下牢、マナ炉、ワープ、魔法砲台。
+
+定義のみ: 闇市場。
+
+## 次の受入
+
+未定義施設は寸法・層だけでなく経済値、人数、業務、通常操作、保存を接続する。登録済み施設は未設定人数とサービス属性、営業時間・停止・経路・客/職員行動を個別検証する。施設追加のたびにこの監査を再実行する。
+
+再現: `python3 tools/run_facility_audit.py --godot /opt/homebrew/bin/godot --output artifacts/facility-audit-current-2026-09-29`。原本SHA・入力ソースSHA・取得中の変更なしは同ディレクトリのsource-start/end/change.jsonを参照。
+
+前回の15施設登録時点の記録は`FACILITY_AUDIT_BEFORE_CLEANING.md`へ保全。清掃員室の登録と一般客室・上級客室・従業員寮のゾーン修正を現行定義で再取得した。全施設一覧への入口と定義値の監査であり、登録数を完成数とは扱わない。

docs/plans/original-completion-2026-09-29/execution/CURRENT_FULL_LOAD.md

@@ -0,0 +1,15 @@
+# 現行ソースの指定規模・部品統合負荷試験
+
+更新注記: GUIDE_ASSIGNMENT_SCAN.mdの受付担当検索の軽量化は本記録より後の変更。本記録の全回帰・配布・負荷結果にこの変更を含めない。
+
+2026-09-29。PERF-MVP-001 full tierをmacOS/Apple M4、Godot4.7.2、headlessで実行。検証済み軽量化版ソースから差分0。終了コード0、24項目PASS、スキップ0。
+
+実初期値: 20,000マス、200客、50職員、150施設、行列500、物流200、選択待ちイベント50。1,440分（x3、480フレーム）を完走。物流200件完了、在庫非負、貸借一致、部品スナップショット復元を確認。行列最大待ち46分、物流最大待ち4分。
+
+x3平均6.948ms、P95 7.419ms（基準12ms）、最大22.204ms（主スレッド停滞基準50ms）。経路P95 0.037ms（基準2ms、5760回中の末尾512件の窓）。全シミュレーション3.365秒。
+
+限界: public APIで各部品を組み合わせた専用ハーネスであり、本番SimulationRuntime・スナップショット公開・UI更新・描画を測定しない。物流更新はハーネスが担う。初期の行列と物流は処理後補充せず、終了時は双方0件。イベントは選択待ち50件。このPASSを継続満員・実営業・GPU・Windowsの合格へ拡張しない。x1、全体保存/読込所要時間、長期プレイもこの試験の対象外。
+
+現行本番デモではx1平均9.372ms、x3 P95 32.728msで目標未達（SNAPSHOT_CALL_REUSE.md）。異なる試験の数値を直接の改善率として比較しない。次の性能作業は本番Runtimeの統合更新・状態公開・UIコストを対象とし、本番規模での持続負荷受入は別途必要。
+
+証拠: artifacts/full-load-current-2026-09-29/{full.log,report.json,verification.json}。実行: godot --headless --path . --script res://tests/performance/test_perf_mvp_001.gd -- --full。

docs/plans/original-completion-2026-09-29/execution/CURRENT_FULL_REGRESSION.md

@@ -0,0 +1,13 @@
+# 防衛画面表示更新・全回帰と通し検証
+
+2026-09-30。148/148スイートPASS、657.68秒。欠落・余分・重複・失敗・実行中ソース変更0。新Event防衛186項目、表示/選択105項目を含む。
+
+macOS実描画の新規開業・3回決算・保存・終了・別プロセス再起動は83＋20＝103項目PASS（48.06秒/32.18秒）。4日目00:00、所持金4,228G、帳簿一致、営業利益＋346Gを実画像で確認した。
+
+同じ凍結ソースの関連描画5実行453項目PASS。全回帰の同じソース実ログ5件720項目を参照し、新実行扱いしない。Event処理で生成した襲撃のviewport操作・戦闘途中保存・別プロセス再開は34＋32＝66項目PASS。状態JSONとtyped digest一致、全DomainEvent/採番/乱数を保全する。Save/Loadの2種類のI/O観測type/payloadのみ明示normalizationする。
+
+防衛画面の実OptionButtonと概要には事件名と保存された元の発生日/時刻が表示され、完全IDはmetadataと選択に保持される。write/readの途中・終了の4実観測とnonce・state比較が合格、human_readable_defense_labels=true。実画像で520pxの窓幅と内部ID非表示を確認した。初回は新しい通しdriverの4bool変数の型推論でコンパイル失敗し、型注釈だけを直して再試験した。本番変更は0、失敗ログはfirst-parse-failure/へ保全している。
+
+現在ソースと同じWindows版の隔離export・18PCK実行2,926項目・ZIP CRC/ファイルSHA検証がPASS。PCK描画はmacOSで実施。Windowsネイティブ操作、原本全実装、通常脅威producer、性能予算、高負荷/長期プレイは未完了。
+
+証拠: artifacts/full-regression-after-event-defense-labels-2026-09-30/、artifacts/event-defense-labels-related-2026-09-30/、artifacts/event-defense-labels-restart-2026-09-30/。source-end SHA256: 0395e515c1cb090408c11c7235b36f8b2015bf350fe412b2d894b286b249ef6c。

docs/plans/original-completion-2026-09-29/execution/CURRENT_PERFORMANCE.md

@@ -0,0 +1,9 @@
+# Current performance regression
+
+make test-perf and make test-perf-full both exited0 with no script errors. Path/camera compatibility282 checks PASS; digest compatibility/performance71 checks PASS; smoke24 and full24 fixture checks PASS.
+
+Full fixture: 20,000 cells, 200 guests, 50 staff, 150 facilities, 500 queued customers, 200 logistics requests and 50 active events, simulated1440 minutes at x3. Simulation x3 P95=7.845ms (budget12ms), path query P95=0.036ms (budget2ms), maximum measured main-thread batch22.037ms (budget50ms). No checks skipped.
+
+This harness composes public domain APIs and orchestrates logistics itself. It does not measure the production SimulationRuntime tick, rendered UI, GPU frame time, Windows, natural campaign play or long-term balance. Geometry helper and digest microbenchmarks are likewise not frame-rate guarantees. These passing measurements do not close P28.
+
+Evidence: artifacts/facility-dimensions-2026-09-29/current-performance-validation.json with host, full reports and log hashes. No production code changed in this measurement increment.

docs/plans/original-completion-2026-09-29/execution/CURRENT_WINDOWS_PACKAGE.md

@@ -0,0 +1,11 @@
+# 防衛画面表示更新・Windows開発確認版
+
+2026-09-30。build/windows/TheTree-Windows-event-defense-labels-2026-09-30.zip を作成した。Godot 4.7.2・debug export・Windows x86_64 PE32+。Runtime13、設定済みイベントからの防衛準備生成、事件名・元の発生日/時刻表示、完全IDによる操作と保存を含む。
+
+ZIP: 73,203,090 bytes、SHA256 2e22d793d113fa3f2eba4839d6812ec69f9762bdfe86c8804b943f79f4b1bad4。PCK SHA256 acd46e235282212392c99db43851285cea33afd1912b960ef92eec796c4616d8。ZIP CRC・全同梱ファイルSHA・5ライセンス/出典・マニフェスト・ソース変更0を検証した。
+
+ソース148/148 PASS、開業・3決算・保存・別process再起動103、関連実描画453、イベント防衛保存再開66項目PASS。同梱PCKだけを読む隔離環境の18実行2,926項目PASS（headless2,468、macOS実描画458）。全18実行が同一PCK SHA、4枚captureを検証し、防衛画面と自動保存復旧画像を目視した。ソースの851実行入力を普通copyし、本体のeditor importなしで隔離exportした。import/exportでcopy・本体ソースの変更0。
+
+Windowsネイティブ操作は未確認。通常営業から盗賊・暴動・借入滞納・摘発を自動生成するproducer、原本未指定値の決定、全施設・人物・物語・資産、性能予算・長期プレイは未完了。開発確認版であり、全原本受入や最終リリースとは扱わない。
+
+証拠: artifacts/windows-event-defense-labels-release-prep-2026-09-30/。表示修正前のsealed event-defense世代準備は実行せず保全した。旧Runtime12 ZIPも保全している。

docs/plans/original-completion-2026-09-29/execution/DASHBOARD_REFRESH_COALESCING.md

@@ -0,0 +1,9 @@
+# Dashboard refresh coalescing
+
+Main scene snapshot notifications now schedule one deferred dashboard refresh per batch rather than rebuilding the same dashboard for every simulated minute before rendering. Snapshot publication and simulation still run each tick. Elevator pending-command synchronization, pause/speed status and daily-close detection remain synchronous. Explicit user action refreshes remain immediate. Existing UI assertions passed without timing changes.
+
+A counted main-scene subclass verifies three minutes still advance, three publications result in one deferred refresh, no empty duplicate refresh, the next frame refreshes again, display work cannot mutate the snapshot, and checkpoint replay remains identical: 10 checks PASS. Registered in make test-ui after it ran separately. The existing full make test-ui passed 992 direct checks plus 37 fresh-process upkeep checks (exit 0), including first operating day and daily-close UI.
+
+The production diagnostic now flushes pending dashboard work INSIDE each timed batch. This prevents deferred work from being hidden outside measurement. Previous retained key-budget-after baseline versus this run: x1 average 13487.4 -> 13774.475 us (no improvement demonstrated); x3 P95 51750 -> 43334 us (about 16 percent lower in this pair). Small scenario, seed 424242, 40 samples per speed, macOS Godot 4.7.2 headless. This excludes GPU rendering, is a single comparison, and is not Windows or full-load acceptance. Both production budgets still FAIL.
+
+Evidence in artifacts/facility-dimensions-2026-09-29: dashboard-coalescing-ui.log, dashboard-coalescing-test.log, dashboard-coalescing-profile.json, dashboard-coalescing-validation.json, and copied dashboard-coalescing-upkeep-* logs. Full original completion remains unproven.

docs/plans/original-completion-2026-09-29/execution/DEFENSE_CLOCK.md

@@ -0,0 +1,13 @@
+# 防衛画面・通常時計による攻防
+
+2026-09-30。本番の防衛画面と ACTIVE 攻防の自動進行を接続した。新しい敵・戦闘間隔・準備締切を確定せず、既存レイドの保存済み round_minutes と取引境界を使用する。準備と次波開始は既存の明示操作を維持。
+
+通常管理の防衛ボタンと警戒欄から参加者、対象施設、撤退方針、開始、次波、撤退を操作できる。選択した incident と画面の開閉を手動/自動保存へ記録する。ロード前の確認をロード後の別 queue へ適用しない。無料の敵消去となる準備取消ボタンはレビューで削除した。
+
+通常時計の防衛 phase は due raid を安定したID順に1回ずつ解決する。手動の実取引失敗を同分の自動成功で隠さず、履歴再送だけでは正当な due round を抑止しない。明示IDを持つ旧有効セーブとの採番衝突を避け、ID空間の枯渇・技能費用・RNG・施設/職員結果の失敗時に巻き戻す。自動失敗では時計を停止し、同分に再試行しない。成功 restore では一時実行 guard を消去する。
+
+初回の新自動周期試験188項目PASS、既存Runtime防衛162項目PASS。最新関連のheadless 1,703項目（同じ固定ソースの全回帰内で再実行した自動周期188項目を含む）と実描画5実行403項目PASS、実行中の入力差分0。証拠は `artifacts/defense-autonomy-2026-09-30/`。初回自動周期ログ後の変更は試験説明コメントだけで、最新全回帰で再実行する。独立静的レビューは `artifacts/defense-autonomy-independent-review-2026-09-30/`。
+
+全回帰146/146スイートPASS、全合格後の開業・3回決算・別プロセス再開103項目PASS。さらに戦闘途中の保存から別プロセスで同じ攻防・損傷・資金・乱数・IDへ到達する描画通し試験19＋19＝38項目PASS。スクロールとviewport入力で通常防衛操作を確認した。同じソースのWindows PCKも16実行2,559項目PASS、ZIP生成と全同梱ファイルSHA検証が完了。Windows実機は未確認。
+
+P21全体は未完了。脅威は試験fixtureで生成し、通常営業からの盗賊/暴動/銀行滞納発生、実敵コンテンツ、実技能/UI、魔法砲台、開始演出は未接続。原本全実装、同一Windows実機、性能予算、長期プレイを合格とは扱わない。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_HUD.md

@@ -0,0 +1,21 @@
+# 防衛状態のタワー画面表示
+
+2026-09-29。P21/P24の警告表示を接続。DefenseServiceの現在状態から準備中・戦闘中・次波待ちを集計し、上部警戒欄へ襲撃件数、運営画面へ状態別件数を表示する。準備中も従業員配置がロックされるため集計に含める。終了済みの履歴は進行中件数に含めない。ツールチップで配属制限を説明する。
+
+集計は戦闘履歴・参加者の全コピーを作らず、状態ごとの件数だけを返す。保存形式や襲撃発生条件、戦闘数値は変更なし。Runtimeの状態公開を受け、取消と保存復元でも表示を更新する。
+
+関連試験: 防衛507、Runtime防衛135、ダッシュボード149、macOS実描画150チェックPASS、全プロセス終了コード0。実描画は同じUIシナリオの再試験＋画像保存確認。準備中の表示、取消、復元、古いツールチップ解除、次波待ちと戦闘の区別、終結後除外、読み取りで原本状態を変更しないことを検証。1440×810の画像で上部・運営画面の日本語が収まることを目視。
+
+証拠: artifacts/defense-hud-2026-09-29/。preparing.png、ログ、targeted-verification.json。
+
+未完: 通常営業からの襲撃発生、準備・戦闘操作UI、借入滞納との接続、砲台と能動スキル、Windows実機。今回のUI試験はRuntimeコマンドで脅威を用意しており、通常営業での発生は証明しない。前回140全回帰・配布ZIPは今回の表示追加前のソースを対象とする。
+
+## 全回帰で検出した配置操作への影響と修正
+
+初回全回帰は140スイート中139PASS・1FAIL。従業員UIの防衛取消後の再ドラッグが2ケース失敗したため、通し検証は実行しなかった。失敗ログはartifacts/full-regression-after-defense-hud-2026-09-29/に保存。
+
+襲撃の開始/終了で運営サマリーの行数を増減させると、その下の従業員ボタンが移動し、次のドラッグ開始位置が変わっていた。防衛サマリーを0件時も常設することで行の位置を固定。上部の襲撃警告は0件時に解除する。画面側の試験も0件表示を確認するよう更新。
+
+修正後: 従業員UI131チェックがheadlessとmacOS実描画の両方でPASS。ダッシュボード実描画150、更新集約10チェックPASS。全プロセス終了コード0。layout-fix-verification.json参照。修正後の全回帰は別ディレクトリfull-regression-after-defense-hud-fixed-2026-09-29で再実行し、初回失敗記録を上書きしない。
+
+修正後の全140スイートおよび実描画通し97項目もPASS。CURRENT_FULL_REGRESSION.md参照。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_HUMAN_LABELS.md

@@ -0,0 +1,11 @@
+# 防衛戦の原因・発生日時表示
+
+2026-09-30。通し再起動画像で、83文字の内部raid IDが選択欄と概要に表示され、想定520pxの窓幅が約796pxへ広がることを確認した。
+
+本番報告に保存済みevent_sourceのsource_kindとcreated_atをowned scalarとして渡し、画面には原因と発生日・時刻を表示する。同原因・同時刻の複数事件は決定的な一覧順の番号で区別する。内部IDから原因を推測しない。未知または手動登録は「防衛戦」、日時がない場合は「時刻不明」。選択metadata、コマンド対象、UI保存値には完全IDを保持する。
+
+OptionButtonは最長項目への自動拡張を止め、長い表示には省略と人間向けtooltipを使う。独立した隔離コピーで関連6試験1,244項目＋実描画106項目＝1,350項目PASS。実画像は日本語原因・日時で520px内に表示する。検証された3ファイルをSHA比較とバックアップ後に制作コピーへ反映した。
+
+修正後の全148回帰、開業再起動103、関連描画453、事件表示を含む防衛再開66項目がPASS。Windows同梱PCKの18実行2,926項目がPASS。Windowsネイティブ操作は未確認。通常営業からの脅威発生、全P21、全原本完成を証明する変更ではない。
+
+証拠: artifacts/event-defense-labels-integration-2026-09-30/、artifacts/event-defense-ui-presentation-audit-2026-09-30/。

docs/plans/original-completion-2026-09-29/execution/DEFENSE_PREPARATION_CANCEL.md

@@ -0,0 +1,17 @@
+# 防衛準備中の取消と未登録目標
+
+2026-09-29。P21/P27の不具合修正。PREPARINGの襲撃は目標施設の登録前でも妥当な状態だが、取消後の検証が「全目標登録済み」を要求していたため、cancel_defense_raidが拒否され従業員の防衛ロックを解除できなかった。
+
+CANCELLEDかつstarted_at == -1の、実際に戦闘を開始していない場合だけ目標登録完了の条件を免除する。戦闘開始時の全目標登録条件、開始後の取消・保存検証、その他の不変条件は維持。保存形式と数値の変更なし。
+
+新規回帰で目標未登録・2目標中1件登録の双方を修正前に再現（before.log、2 failures）。修正後は取消成功、未開始・0ラウンドの維持、架空の施設を生成しないこと、JSON保存復元、取消再送の不変性を検証。開始済みに改変した破損保存は原状を保って拒否する。
+
+防衛サービス494、Runtime135、従業員UI131、保存ライフサイクル96の計856チェックPASS。従業員UIは目標登録済み/未登録の双方で、ドラッグ中の防衛登録→拒否→実ファイル保存/読込→取消→再配置まで確認。macOS実描画も131チェックPASS（同一シナリオ）。通常営業からの襲撃発生の合格ではない。
+
+証拠: artifacts/defense-preparation-cancel-2026-09-29/。全140スイートはfull_verify.py、実行ハンドル64718で開始。対象ソースの開始/終了SHAを比較し、全件PASSかつソース変更0の場合だけ実描画の開業・3決算・再起動フローへ進む。進捗はartifacts/full-regression-after-defense-2026-09-29/suites/all-tests.json、最終結果はverification.json。現在は実行中であり全体PASSとはしない。
+
+既存Windows配布版は今回の修正未反映。Windows実機、全原本機能・資産、性能予算、長期プレイは未完了。
+
+完了追補: 実行ハンドル64718は正常終了。全140スイートPASS、漏れ/重複/ソース変更0。続けて実描画の開業・決算・再起動97チェックPASS、ゲーム状態一致。CURRENT_FULL_REGRESSION.md参照。
+
+配布追補: 上記検証済みソースのWindows開発確認版を作成し、同梱PCK655チェックを検証。CURRENT_WINDOWS_PACKAGE.md参照。Windows実機は未検証。

docs/plans/original-completion-2026-09-29/execution/DIGEST_SCALAR_CACHE.md

@@ -0,0 +1,9 @@
+# Bounded per-call scalar digest cache
+
+SimulationDigest now reuses canonical encodings for integers (up to512 values), short strings and StringNames (separate type-tagged caches, up to256 values each, length<=128). Caches exist only for one canonical encoding call. Mutable containers and floats are not cached; the v1 byte format and digest contract are unchanged.
+
+Final compatibility75 checks PASS, including reference-byte equality, dictionary order/type tags, depth/invalid values, long histories, cache saturation and changed inputs across calls. Synthetic5000-record history median129.949ms versus272.166ms in the original reference encoder; this ratio includes earlier optimizations and is not the gain from this patch alone.
+
+Same production scenario diagnostic: x1 average63.616ms before /62.711ms after, x3 P95 234.396ms before /228.869ms after; digest average26.328ms before /25.983ms after. Single-run differences are small and may include timing noise; no substantial production performance improvement is established. Both remain outside the4ms/12ms budgets. Main performance defect remains open.
+
+Evidence: digest-scalar-final.log, production-scalar-profile.json and production-scalar-profile.log under artifacts/facility-dimensions-2026-09-29. Next work should address the dominant complete snapshot/digest traversal and redundant infrastructure work without weakening replay correctness.

docs/plans/original-completion-2026-09-29/execution/EVENT_DEFENSE_INTEGRATION.md

@@ -0,0 +1,17 @@
+# Event → Defense の実行・保存契約
+
+2026-09-30。制作ソースへ適用済み。現在、全148スイートと同一ソースの描画・別プロセス再開・配布版を検証中。これらの完了は各最新証拠で別に判定する。
+
+明示された原因ID・脅威種別・完全な戦闘テンプレートを、実際のEvent処理から防衛準備状態へ接続する。敵の強度・周期・標的を補完せず、職員配属や戦闘開始も代行しない。通常の防衛画面で準備し、既存のゲーム時計で戦闘を進める。
+
+EventInstanceとactionの組から安定した襲撃IDを作り、乱数・採番・プレイヤーコマンドを消費しない。再送は進行中の損傷・名簿・退避方針を保つ。異なるテンプレートによる同IDの置換は拒否する。後続actionや実際の料金確定が失敗すると、新しい襲撃とその公開履歴を巻き戻す。以前の戦闘の同時刻再試行制御と失敗診断は保持する。
+
+Runtime保存形式13へ更新し、形式12の必須清掃データを維持する。イベント原因・元テンプレートと保存された襲撃の不変構成を照合し、周期・波の強度・上限等の不一致を確定前に拒否する。合法な退避方針変更や戦闘進行は復元できる。旧手動襲撃にイベント履歴を捏造しない。
+
+隔離候補の18関連スイート2,022項目と、拡張4スイート366項目を実行してPASS。後者の新Event専用試験は最終186項目。両段階には重複実行があるため合算を独立要件数にしない。初回の追加失敗試験は非終端ラウンドで終端callbackを期待して3件失敗した。終端を発生させる試験値へ修正して再実行した記録を残し、ゲームの不具合修正とは扱わない。
+
+独立レビューで、未知のserialized actionを整数clampで新しい破壊的actionへ変換する不具合と、元テンプレートのdigestだけを見て実際の襲撃構成を照合しない不具合を修正した。未知actionを除去して成功扱いすることも防ぐ。
+
+本実装は通常脅威producerの完成ではない。男性の所持金0・高依存、盗賊、世界樹の銀行滞納、監査の原因を同一条件に読み替えない。性別・通常利用の依存増加・原因episode・承認済み敵テンプレート等は残件。原本未指定の数値を試験値から本番へ転記していない。警告/カットインは将来commit後の通知として接続する必要があり、取消不能な同期signalを完成UIの証拠にしない。
+
+実装・適用の証拠: `artifacts/event-defense-integration-2026-09-30/`。独立レビュー: `artifacts/defense-event-bridge-independent-review-2026-09-30/`。通常producerの現物監査: `artifacts/defense-bankruptcy-producer-audit-2026-09-30/`。原本全実装、全P21、性能目標、高負荷/長期プレイ、同一版Windows実機は未完了。

docs/plans/original-completion-2026-09-29/execution/EVENT_HISTORY_SNAPSHOT_CACHE.md

@@ -0,0 +1,9 @@
+# Event ID snapshot ordering cache
+
+DomainEventStream converts committed IDs to typed Strings and uses native lexical sort. It caches that sorted ID list until a successful nonempty publish batch or successful restore. Every snapshot returns a separate array; callers cannot mutate the cache. Recent event payloads continue to serialize live and no published ID is discarded. Invalid batch/restore leaves canonical state intact.
+
+Domain-event33 checks PASS, including10 added cache/Unicode/order/defensive-copy/restore tests and existing atomic/reentrant publication tests. Runtime integration20 checks PASS, including disk digest round trip, pending-command single execution and deterministic24-hour replay.
+
+Production small-scenario profile: x1 average33.704ms, x3 P95136.757ms, snapshot creation average7.954ms. No clear whole-update speed improvement over the prior lazy-digest measurement; x3 was slower in this run. This cache removes repeated sorting when history has not changed, but does not establish production budget compliance. Budgets remain failed.
+
+Evidence under artifacts/facility-dimensions-2026-09-29: event-id-cache-regression.log, event-cache-runtime-regression.log, production-event-cache-profile.json. Full UI and Windows not rerun for this increment.

docs/plans/original-completion-2026-09-29/execution/EXACT_CELL_SET_VALIDATION.md

@@ -0,0 +1,9 @@
+# Exact cell-set crosslink validation
+
+Found a correctness issue while reviewing the remaining P28 validation overhead. Runtime._same_vector3i_set checked that every actual cell appeared in the expected set, but did not reject repeated actual cells. Equal-length arrays [A,B] and [A,A] were incorrectly accepted. The validator now removes each matched expected cell, rejecting duplicates/missing cells while retaining order independence and layer/type checks. This affects infrastructure world/route/projection crosslink checks; no schema or intended valid-save behavior changed.
+
+Runtime infrastructure168 checks PASS,exit0, including6 new equality boundary cases (reorder, duplicate actual, duplicate expected, empty, wrong layer, wrong type). Log: exact-cell-set-runtime.log.
+
+Also investigated fusing OperationsCoordinator snapshot validation and conversion. Existing230 coordinator checks passed, but small production measurements showed only3.622ms→3.459ms in coordinator serialization and x3 P9553.431ms→54.428ms. The experiment was reverted completely to the pre-experiment source (byte comparison confirmed). No new fused implementation is retained. Diagnostic reports remain as historical experiment evidence, not a performance acceptance result.
+
+Full make test-ui completed with exit0, unchanged source hashes and no ERROR/SCRIPT ERROR/FAIL markers. Log: post-validation-cache-full-ui.log; result: post-validation-cache-ui-result.json. Includes17 direct Godot scripts and independent upkeep write/read processes. Headless UI acceptance covers this source snapshot; Windows/native rendering and whole-original completion are not proven. Original P00–P29 scope, high-load and Windows acceptance remain incomplete.

docs/plans/original-completion-2026-09-29/execution/FACILITY_AUDIT_BEFORE_CLEANING.md

@@ -0,0 +1,52 @@
+# 原本30施設・現在の登録対応（2026-09-29）
+
+原本10.1–10.7を再照合し、通常Runtimeの登録一覧、建設パレット、FacilityCatalog.by_idが返す定義を実行して照合した。通常登録15、定義のみ1、対応定義なし14。通常カタログ全22件のうち7件はこの30施設以外であり、原本施設の代用として数えない。登録済みは全受入完了を意味しない。
+
+対応定義16件の寸法・層は原本と一致する。地上/地下・高層・背面・騒音などの追加条件、実営業、保存移行、専用画像は別途受入が必要。一般客室・上級客室・従業員寮のABOVE_GROUND制限は原本10章の層指定だけでは正当化できず、残る配置差異として精査する。
+
+人数専用customer_capacityが未設定（-1）の対応定義は13件。FacilityInstance.can_accept_customersはこの場合に人数専用上限を適用せず、available_slotsは既存capacityからサービス数を計算する。保管量・生産量と人数を混同した値を確定しない。バックヤード等の0指定、旅客交通の乗員容量との区分、施設ごとの人数値を整理する必要がある。
+
+対応定義16件すべてでservice_attributeは空欄。属性・一致加算のモデルが存在しても、全施設で追加仕様を運用済みとは判定しない。加算額・不足基準・複数属性等は未設定のまま残す。
+
+原本対応表original_facility_mapping.jsonを独立させ、旧監査facilities.jsonは歴史的証拠として保全した。礼拝堂をchapelへ対応付け、素材台帳もこの現行表を入力にする。これで礼拝堂の必要枠が未対応施設として生成される不整合を防ぐ。新表は対応関係のみを保持し、稼働検証状態はruntime-facilities.jsonで別管理する。
+
+証拠: artifacts/facility-audit-2026-09-29/runtime-facilities.json、summary.json、source-hashes.json、runtime-audit.log、capture-runtime-facilities.gd。再現はローカル制作コピーから `godot --headless --path . --script res://artifacts/facility-audit-2026-09-29/capture-runtime-facilities.gd`。この取得スクリプトは監査時の対応表（旧監査＋礼拝堂）を固定して再現するものであり、将来の新規施設を自動対応させるものではない。
+
+次の優先作業: 人数専用値と層/ゾーン差異の解消、未接続施設の通常プレイ統合。現在の全体回帰中は本体ソースを固定し、完了後に保存・再起動を含む通しデバッグを先に行う。
+
+| Original | Facility | ID | State | Dimensions / Layer | Customer limit |
+|---|---|---|---|---|---|
+| 10.1 | 一般客室 | standard_room | normal + palette | 2x1 / FRONT | unspecified |
+| 10.1 | 上級客室 | premium_room | normal + palette | 4x1 / FRONT | 2 |
+| 10.1 | VIPスイート | - | missing definition | - | unspecified |
+| 10.1 | ドミトリー | - | missing definition | - | unspecified |
+| 10.2 | 大衆食堂 | cafeteria | normal + palette | 4x2 / FRONT | unspecified |
+| 10.2 | レストラン | - | missing definition | - | unspecified |
+| 10.2 | 酒場 | tavern | normal + palette | 4x2 / FRONT | unspecified |
+| 10.2 | 屋台 | - | missing definition | - | unspecified |
+| 10.3 | 大浴場 | public_bath | normal + palette | 6x2 / FRONT | unspecified |
+| 10.3 | カジノ | - | missing definition | - | unspecified |
+| 10.3 | 闘技場 | - | missing definition | - | unspecified |
+| 10.3 | 礼拝堂 | chapel | normal + palette | 4x3 / FRONT | 8 |
+| 10.4 | 風俗個室 | adult_private_room | normal + palette | 2x1 / FRONT | unspecified |
+| 10.4 | 高級ソープ | - | missing definition | - | unspecified |
+| 10.4 | SM拷問室 | - | missing definition | - | unspecified |
+| 10.4 | 闇市場 | black_market | definition only | 4x2 / FRONT | unspecified |
+| 10.5 | 厨房 | kitchen | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 倉庫 | warehouse | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 待機室 | staff_waiting_room | normal + palette | 4x2 / BACK | unspecified |
+| 10.5 | 従業員寮 | staff_dormitory | normal + palette | 2x1 / BACK | 0 |
+| 10.5 | 警備員詰所 | security_station | normal + palette | 2x2 / BACK | unspecified |
+| 10.5 | 清掃員室 | - | missing definition | - | unspecified |
+| 10.5 | 医務室 | infirmary | normal + palette | 4x2 / BACK | unspecified |
+| 10.6 | 覗き部屋 | - | missing definition | - | unspecified |
+| 10.6 | 地下牢 | - | missing definition | - | unspecified |
+| 10.6 | マナ炉 | - | missing definition | - | unspecified |
+| 10.7 | 蔓の昇降機 | guest_elevator | normal + palette | 2x2 / FRONT | unspecified |
+| 10.7 | 業務用EV | service_elevator | normal + palette | 3x2 / BACK | unspecified |
+| 10.7 | ワープ | - | missing definition | - | unspecified |
+| 10.7 | 魔法砲台 | - | missing definition | - | unspecified |
+
+## 配置差異の追記
+
+一般客室・上級客室・従業員寮の地上限定差異は`ORIGINAL_ROOM_ZONES.md`で修正/関連検証済み。この表の登録数・清掃員室未対応表示は監査時点の記録で、清掃員室の後続統合を反映していない。最新の清掃統合は`CLEANING_RUNTIME_INTEGRATION.md`を参照。

docs/plans/original-completion-2026-09-29/execution/FACILITY_DIMENSION_MIGRATION.md

@@ -0,0 +1,108 @@
+# P08 施設寸法移行の事前確認
+
+原本の上級客室4×1、従業員寮2×1、闇市場4×2に対し、現拡張定義は3×2、4×2、3×2。調査はfacility-dimension-preflight.json参照。
+
+## 実装済み
+
+`facility_resize_preview.gd` はWorldServiceと現施設の明示された旧占有を受け、変更後のセル、追加/削除セル、衝突、未掘削、境界外、地下制約、支持喪失を返す。現在定義から旧占有を推測せず、旧形または変更後の形と保存の占有所有者が一致することを要求する。別WorldServiceへ複製して検証するため、成功/失敗どちらでも元ワールドの占有と版番号を変更しない。90/270度では寸法軸を交換し、層を保持。
+
+14項目PASS: 上級客室の3×2→4×1、重なり拒否、上階の支持喪失、旧占有の矛盾/重複/不正ID/回転拒否、裏層の回転した寮、地下闇市場の未掘削/掘削後/境界外を実WorldServiceで確認。証拠 `artifacts/facility-dimensions-2026-09-29/validation.json`。
+
+## 適用前に必要な処理
+
+この判定のgeometry_okは寸法とWorldServiceの抽象的支持モデルの部分判定であり、移行実行許可ではない。ready_to_applyは常にfalse。特に周辺施設の実定義別重量、経路と職員/客の位置、建設中ジョブ、FacilityService/Construction/Pathの相互参照、バックアップと原子的保存への接続は残る。全ゲートを省略してプレビュー結果を本番へ書き戻してはならない。
+
+定義の寸法・既存セーブはまだ変更していない。次はRuntimeから実重量/経路/旧配置を捕捉する移行プレビューへ接続し、変更できない配置を元データを保ったまま示す。P08全体および原本30施設の通常建設対応は未完了。
+
+
+## 実重量とRuntimeへの接続
+
+WorldService.validate_supportへ任意の占有者別重量を追加した。指定のない既存呼出は従来どおり。未登録ID・負/非整数重量は拒否し、支持モデルと保存状態を変更しない。闇市場の拡張で、従来の簡略重量では合格するが隣接施設の実重量を加えると容量超過になる例を検証した。
+
+Runtime.preview_facility_dimension_migrationは完成施設と現定義を読み、全完成施設のweight_per_cellで判定する。削除予定セルにいる客/職員と建設ジョブを報告し、実状態は変更しない。形状・支持のプレビューが通ってもready_to_applyはfalseで、移動経路/建設中/保存取引のゲートが残る。
+
+試験は既存の拡張定義を明示登録し、受付を通常建設した上に旧3×2の上級客室を通常コマンドで建設。最初は地上専用施設をロビー階へ置いて拒否されたため配置を修正した。削除セル上の職員検出は、通常通行できない旧座標を診断入力として設定した限定試験。通常歩行・配置移行の受入とは区別する。初回の建設失敗と通行不能セルへの登録失敗ログも保持。
+
+実重量/Runtime14項目、WorldService60、Construction105、Runtime建設37項目がPASS。証拠 weighted-final-validation.json。施設定義の寸法と既存セーブは未変更。次は経路と実占有の事前検証、UI、適用トランザクションへ接続する。
+
+## Construction migration candidate (2026-09-29)
+
+Added prepare_construction_candidate: validate source, copy world, resize ownership, update facility and source-job cells together, then validate via ConstructionService.restore_snapshot. Active jobs are supported; costs, progress and timestamps are retained. Runtime preview exposes the candidate. No live state or disk write occurs.
+
+Validation: Runtime 22 checks and geometry 14 checks PASS. Initial retry changed world revision; fixed by skipping occupancy replacement when already resized. Initial failure log retained. Active-job fixture covers progress zero only; partially built continuation remains unverified.
+
+Remaining: valid actor relocation and routes, other Runtime crosslinks, partial-job continuation, backup and atomic application, UI and canonical dimensions. This is not full migration acceptance.
+
+## Partial construction and full snapshot candidate (2026-09-29)
+
+Runtime now assembles world, construction and operational facility geometry into a copied full snapshot. Actors on removed cells require relocation before assembly. ready_to_apply remains false: caller still needs isolated validation, route/actor checks and disk backup/atomic commit.
+
+Focused suite: 33 checks PASS; geometry suite: 14 PASS. Partial construction now advances 7 minutes before migration, restores, rejects duplicate work for the saved minute, completes exactly once, preserves original cost/start/duration and restores after completion. Full snapshot candidate for an unoccupied premium room restores through a separate Runtime with the fixture expansion registry. This is one fixture, not all-facility or route relocation acceptance.
+
+Evidence: full-snapshot-candidate.log and full-candidate-geometry.log. Canonical definitions, normal palette registration, actor relocation, route continuation and disk migration are still incomplete.
+
+## Route preservation gate (2026-09-29)
+
+prepare_facility_dimension_snapshot now restores its candidate into an isolated Runtime using the source definition registry. It compares entrance access, guests targeting the facility and staff workplace access using production route queries. Loss of existing reachability rejects the candidate; moving guests with a changed destination require explicit retargeting. No live actor relocation or disk write occurs.
+
+40 focused checks PASS; make check exits 0. Controlled topology cases prove that removing an upper facility row can lose access even when the path graph itself is unchanged, and that an alternative entrance still requires updating the moving guest target. The first fixture omitted the vertical connector, causing two expected-reachability failures; explicit connector setup fixes the fixture. Initial failure retained. Controlled graph/guest edits are route-unit fixtures, not normal UI play evidence. The earlier valid full Runtime restore is tested separately.
+
+Still pending: staff commute/task and elevator-in-flight migration acceptance, real actor relocation, automatic route retargeting, disk backup/atomic commit/UI, canonical definition changes and all-30 normal construction acceptance. The gate does not turn these remaining items into completion.
+
+## Candidate guest retargeting (2026-09-29)
+
+Added an all-or-nothing replan batch for isolated candidate guests. Every guest must still be MOVING with the expected old destination, a reachable replacement and no active elevator trip. Only path_handle target and graph revision change. Position, wallet, service state and movement credit remain untouched. Runtime candidate preparation applies the batch, captures/restores the resulting candidate again, and repeats access comparison. Live source and disk are unchanged.
+
+46 focused checks PASS, 91 existing Runtime path/traffic checks PASS, make check exit0. Controlled topology fixture checks invalid second replan rollback, stale-plan rejection, retained guest fields and production movement toward the replacement lower entrance. This is not normal construction/UI or a full moving-guest save migration scenario; those remain unverified. No in-flight EV retargeting or physical actor relocation is claimed.
+
+## Canonical dimensions applied (2026-09-29)
+
+Changed expansion definitions: premium_room 4x1 FRONT, staff_dormitory 2x1 BACK, black_market 4x2 FRONT underground, matching original chapter 10. Costs, duration and other fields unchanged. These expansion definitions are still outside the normal palette registry; normal all-30 construction remains incomplete.
+
+The old premium_room resource is archived under tests/fixtures/legacy_premium_room.tres. Migration tests reserve using this explicit old resource, then switch to current definitions before progress, candidate generation and restore. Thus legacy occupancy is tested against corrected definitions instead of leaving production data at old sizes. Existing saves are not rewritten.
+
+New-construction tests use real WorldService/ConstructionService and a funded test budget. All three definitions at four rotations reserve, finish, pay once and restore:63 checks PASS. Legacy Runtime migration:47 PASS. Definition registry:266 PASS. Content catalog:212 PASS. make check exits0. Migration/geometry/new-dimension tests are now included in make test-s1. Earlier preflight records are historical evidence of the old mismatch.
+
+Remaining: normal palette and role integration, all30 original facilities, actor relocation, staff tasks/EV migration, full moving-guest save acceptance, backup/atomic application and UI. Canonical dimension correction alone does not complete P08.
+
+## Verified disk migration (2026-09-29)
+
+SaveService.replace_snapshot_with_backup reuses the existing package migration transaction for same-format domain changes. It requires a valid candidate and an exact expected-source match, checksum-verifies candidate and backup, and atomically promotes using the existing recovery protocol. Repeated identical migration preserves the initial backup. Different package versions require their format migration first.
+
+Runtime.migrate_facility_dimensions_at_path loads an explicit path into an isolated Runtime, prepares/validates the dimension candidate and routes, then replaces the package with backup. It does not change live Runtime. Tests use unique disposable user save paths, not production saves.
+
+56 focused checks PASS,127 SaveService regression checks PASS; make check passed before the final format guard, and final Godot suites compiled that guard. Tests prove backup snapshot/bytes, repeat migration, stale-source and invalid-candidate rejection, separate-Runtime reload and live-state preservation. Existing save regression covers interruption/failed migration paths.
+
+This completes the explicit disk API for accepted candidates, not the whole migration user flow. Actor relocation, EV/tasks, normal UI invocation and post-migration load flow, all30 normal construction remain incomplete.
+
+## Staff rest and assigned-task migration gates (2026-09-29)
+
+Route preservation now includes off-duty workers whose selected rest facility is resized, even without a workplace assignment. Pending/assigned tasks targeting the facility or its rescue destination must retain exact state and a valid destination in the resized facility access cells. Assigned-task reachability uses normal staff routing; rescue tasks use the same backyard restriction as production movement. Changed task destinations require coordinated migration and are rejected for now rather than silently retained.
+
+25 focused checks PASS in dormitory-migration-tasks.log. A HEAD-version legacy4x2 dormitory fixture is built through normal construction and service stairs, then registry switches to canonical2x1. A worker resting on the valid upper stair landing preserves position through full snapshot migration and physically descends to the new lower entrance after resume. Blocking the lower entrance rejects migration without changing source. An old-upper-entry task rejects with TASK_DESTINATION_CHANGED. A retained-entry task assigned through StaffService preserves its exact snapshot after candidate restore. This covers an assigned/reserved task, not every working logistics/rescue case.
+
+Existing premium/disk migration56 checks PASS; make check exit0. Remaining: physical actors on removed cells, coordinated task retargeting, in-flight elevator/rescue/logistics acceptance, migration UI/load flow, all30 normal facility acceptance. No production save changed.
+
+## Whole-save completed-facility batch (2026-09-29)
+
+migrate_facility_dimensions_at_path now accepts an omitted facility ID to migrate all mismatched completed facilities. It loads once into an isolated Runtime, prepares/restores each candidate there, and commits only the final snapshot through one verified backup transaction. Already-canonical facilities are skipped. Failed candidate restores the isolated original and leaves disk/live state untouched. Active legacy construction is explicitly reported as requiring migration, not silently skipped.
+
+23 batch checks PASS (batch-save-final.log): premium room and dormitory old definitions built normally, one backup retains both originals, final full Runtime restores both corrected sizes, repeat preserves initial backup. A valid task at the second facility's removed entrance rejects the batch after the first candidate; rollback and unchanged formal save/live state/previous backup are verified. Existing single-facility/disk suite56 PASS. make check passed before final unchanged-shape skip; final Godot batch compiles and exercises that change.
+
+Remaining: active-job full Runtime migration, joint spatial rearrangements requiring coordinated ordering, actor relocation/task retargeting/in-flight transport, normal UI/load flow and all30 facility acceptance. Sequential candidate validation is not a general simultaneous layout solver. Tests use disposable saves; production saves untouched.
+
+## Active construction included in Runtime/disk batch (2026-09-29)
+
+Active legacy jobs now join the batch target list. Their world reservations and construction snapshots are converted by the existing geometry/weight gate, then validated in an isolated full Runtime before promotion. They do not fabricate an operating facility before completion. Paid cost, work units, progress and timestamps are retained.
+
+active-job-runtime.log:63 checks PASS. A normally started legacy premium-room job advances7minutes, is saved to a disposable package and batch-migrated with backup. The full migrated Runtime restores the four-cell reservation with original progress/cost, advances normally to an operating4x1 room, and restores after completion. Original partial-job backup remains exact. Completed batch23 and dormitory rest/task25 regression checks PASS; make check exit0.
+
+The earlier ACTIVE_CONSTRUCTION_MIGRATION_REQUIRED limitation is removed for candidates accepted by these gates. This evidence covers the premium partial-job fixture, not every mixed-job/actor/transport layout. Remaining: coordinated spatial ordering, actors on removed cells and lost task destinations, in-flight transport/rescue/logistics, normal migration UI/load flow and all30 facility acceptance.
+
+## Migration review and load UI (2026-09-29)
+
+The bottom toolbar now provides 読込 ▾ → 旧寸法を修正して読み込む. Preview loads the saved package into an isolated Runtime, validates the complete candidate, and lists affected facilities and target sizes before confirmation. Cancel clears the pending token. Confirmation requires the original preview digest; a changed save is rejected before migration. Successful promotion retains the source backup and strictly loads the migrated formal save, without falling back to an old backup while claiming migration success. Ordinary load retains its existing recovery behavior.
+
+Native macOS rendered UI handler flow:13 checks PASS, including cancel, changed-source rejection, original backup equality, corrected live room and already-current handling. Screenshot migration-dialog.png visually inspected: facility name,4×1 target, backup and unsaved-progress explanation, cancel/confirm buttons readable. Dashboard regression136 and batch-save regression23 checks PASS. These are rendered UI signal-handler tests using a controlled legacy fixture; OS pointer input and Windows execution were not tested. Makefile test-ui includes the new flow.
+
+Remaining: coordinated spatial ordering, actors on removed cells, task retargeting, in-flight transport/rescue/logistics, all30 facilities and Windows acceptance. P08 remains in progress.

docs/plans/original-completion-2026-09-29/execution/FACILITY_REACHABILITY.md

@@ -0,0 +1,21 @@
+# 施設到達可否の表示処理軽量化 — 2026-09-29
+
+## 変更
+
+開業ガイドは到達可否しか表示しないが、従来は施設の全候補入口から最安経路を選ぶ詳細レポートを取得していた。
+Runtime に `is_facility_reachable` を追加し、到達可能な候補が一つ見つかれば終了する。候補生成を Guest AI と共用し、入口、アクセス禁止、通行制約は同じとする。状態キャッシュは追加せず、遮断や復元後もその時点の経路で判断する。
+実際の客の移動は従来の最安経路選択を維持。保存形式・ゲーム内経済・施設数に変更なし。
+
+## 検証
+
+- 新規回帰 `tests/performance/test_facility_reachability.gd`: 33チェックPASS。実際に建設した複数階施設で既存詳細レポートとの一致、存在しない施設、アクセス禁止、入口遮断、保存復元を確認。
+- 既存のインフラ統合180、スナップショット所有権89、清掃アクセス6チェックPASS。
+- 同一プロセス・同一状態・順序を交替する100回の計測（各回はデモ全施設の一巡）: 詳細レポート平均6222.41µs/P95 6391µs、到達可否平均4222.04µs/P95 4335µs。平均約32%短縮。
+- 計測機: macOS Apple M4、Godot 4.7.2、headless。小規模デモのこの照会処理だけの測定であり、全体Tick予算やWindows描画性能の合格ではない。
+
+証拠: `artifacts/facility-reachability-2026-09-29/` の comparison.json、comparison-summary.json、関連試験ログ、変更前ソース。
+通しデバッグの結果は同ディレクトリの opening-restart に保存する。
+
+前回の Windows-cleaning ZIP は変更前のソースを固定した成果物であり、この軽量化を含むとは扱わない。
+
+描画あり通しデバッグ: 書込80＋再起動読込17＝97チェックPASS（62.91秒＋48.00秒）。実行中のソース変更なし、再起動前後のゲーム状態JSON一致。3営業日の決算まで完走し、再起動後の3日目決算画面を目視確認。

docs/plans/original-completion-2026-09-29/execution/FINE_CLEANING_EFFECT.md

@@ -0,0 +1,13 @@
+# フィーネの清掃速度・作業更新の接続
+
+原本6.2の清掃速度3倍をRuntimeへ接続。heroine_fine・UNIQUE・cleanerが一致する作業者は毎分3作業単位、通常は1。8単位の清掃は1分刻みのゲーム時間では3分目に完了する（2分時点6/8）。到着前の移動速度や他業務は変更しない。回復25・一度だけ適用・途中取消の回復なしは維持。清掃状況は3倍速と残り実時間を表示する。
+
+実装中の検証で汎用StaffService更新が先に1単位進め、Runtimeの清掃専用判定が同分重複扱いで走らない点を発見。汎用更新に進捗ポリシーを設け、清掃は0としてRuntime側へ委ねた。出勤・施設稼働・取消を確認後、作業量を一度だけ進める。既存の物流の外部駆動契約は変更しない。
+
+採用UI・初期能力は未指定で確認待ち。通常カタログにフィーネを追加していない。テストではregister_staffコマンドでUNIQUE/cleanerの本人を登録し、実際のUI配置・移動・汚れ・清掃を検証する。これは通常募集からの加入完了の証拠ではない。暗殺確率UP、成長、他固有効果・人物素材も残件。
+
+関連6スイートPASS: Fine効果、通常清掃UI、StaffService、通勤、物流ブリッジ、救護UI。通常8分/固有3分・途中保存同一再生・完了直前の閉鎖/停電・一般雇用/別職種への誤適用防止を含む。実描画と3日営業の別プロセス再起動は実行中。証拠: artifacts/fine-cleaning-effect-2026-09-29/。
+
+## 実描画・再起動結果
+
+固有效果95チェック、実描画は画像取得を加え96チェックPASS。working.pngで3倍速・残り3分を確認。通常開業から3回決算、別プロセスの保存再開97チェックPASS。source-change.jsonは空、両プロセスのゲーム状態JSONも一致。通常加入への接続は依然未完了で、募集経路・初期値の回答が必要。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_AFTER_GUEST_LOG.md

@@ -0,0 +1,25 @@
+# 現行ソースの全回帰 — 来客判断ログ追加後
+
+139ソーススイートを単一のソース状態で実行し、139PASS・失敗0。所要798.08秒。実行対象と実行結果の完全一致、未実行0、重複0、開始・終了のソースハッシュ一致を確認した。
+対象は `tests/run_tests.gd` と `tests/**/test*.gd`。RefCountedのkernelモジュールはrun_testsから実行し、配布PCK専用試験は別工程。
+
+来客判断履歴・候補除外理由・経路到達判定の軽量化を含む現行コードの回帰証拠。原本全実装・Windows実機・実プレイ時間・全体性能予算の達成を示すものではない。
+
+証拠: `artifacts/full-regression-after-guest-log-2026-09-29/` の expected-tests.json、all-tests.json、全ログ、source-start/end.json、verification.json。
+全件PASS後の描画あり通し検証は同ディレクトリの opening-restart/ へ記録する。
+
+前回の137スイート（136合格＋期待値修正後1合格）の経緯は FULL_REGRESSION_BEFORE_GUEST_LOG.md に保存した。今回の139スイートは単一走査ですべて合格した。
+
+## 独立した調査
+
+顧客人数0で生産できないという初期仮説は、顧客向けサービスと厨房生産を混同していた。KitchenProductionServiceの全fixtureを顧客人数0にした追加試験141チェックがPASSし、仮説を棄却した。本番の人数判定は変更していない。ZERO_CUSTOMER_PRODUCTION_BUG.md参照。
+
+## 全回帰後の通しデバッグ完了
+
+描画あり80＋17＝97チェックPASS。書込・読込の両プロセス終了コード0。ソース変更なし、write/read-gameplay.json一致。通常開業から3回決算、終了・再起動後の継続を確認。
+
+現行差分の追記: この139スイート一括実行後にサービス開始結果の枠番号を修正した。変更後の関連回帰・通しデバッグは SERVICE_START_SLOTS.md を参照。この一括結果を変更後140スイートの合格として扱わない。
+
+追加差分: 従業員ドラッグがロード前後をまたがないよう修正した。変更後の回帰証拠は STAFF_DRAG_LOAD.md を参照。
+
+追加差分: インフラ投影の重複した経路状態検査を削減。変更後の関連回帰・性能・通し検証は PROJECTOR_SINGLE_LIVE_CHECK.md を参照。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_ACTOR_SELECTION.md

@@ -0,0 +1,9 @@
+# 現行ソースの全回帰 — 自動保存・直接読込の選択復元後
+
+2026-09-30。143/143スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計1039.40秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込49.98秒、再読込36.28秒、終了コードともに0。ゲーム状態の比較は一致。再起動後の画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+証拠: artifacts/full-regression-after-selection-autosave-2026-09-30/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。以前の記録はFULL_REGRESSION_BEFORE_SELECTION_AUTOSAVE.md。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格ではない。現在のWindows配布版は選択復元の変更を含まない。後続変更として従業員・来客の選択復元を実装し、100項目・実描画101項目・関連552項目PASS。この143スイートの証拠には含めず、最新144スイートの全回帰と通しを再実行する。ACTOR_SELECTION_RESTORE.mdを参照。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_DEFENSE_AUTONOMY.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — 従業員・来客選択復元後
+
+2026-09-30。144/144スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計762.12秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込49.68秒、再読込36.90秒、終了コードともに0。ゲーム状態JSON一致。再起動後の画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+追加の従業員・来客選択復元も、別プロセス書込103項目・読込13項目、計116項目PASS。実際の保存データで選択IDと画面の開閉、ゲーム状態JSONと型を含むdigestの一致を確認。読込側画像を目視確認。
+
+証拠: artifacts/full-regression-after-actor-selection-2026-09-30/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。別プロセス選択復元はartifacts/actor-selection-restart-2026-09-30/。以前の143スイート記録はFULL_REGRESSION_BEFORE_ACTOR_SELECTION.mdへ保全。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格を示さない。Windows配布版の更新は別検証で進める。選択復元の変更と対象試験はACTOR_SELECTION_RESTORE.mdを参照。
+
+後続変更: 防衛操作画面を実装し、対象54・実描画55・関連1,250項目PASS。上記144スイートはこの変更前の証拠。自律戦闘の接続を続け、変更後の全回帰・通しを再実行する。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_DEFENSE_HUD.md

@@ -0,0 +1,15 @@
+# 現行ソースの全回帰 — 防衛準備中取消修正後
+
+更新注記: 防衛HUD追加（DEFENSE_HUD.md）はこの記録・配布版の後の変更。追加後の関連試験はPASS。追加後の全回帰・通し・再配布は別途確認する。
+
+2026-09-29。140ソーススイートを単一ソース状態で実行し、140PASS・失敗0。スイート実行時間合計783.63秒。期待対象と結果は完全一致し、未実行・余分な実行・重複は各0。開始/終了のソースハッシュ差分0。
+
+対象はtests/run_tests.gdとtests/**/test*.gd。RefCountedのkernelモジュールはrun_testsから実行し、配布PCK専用試験は別工程。サービス開始時の枠番号、ロード前後のドラッグ無効化、インフラ投影の重複検査削減、従業員の配属阻害理由表示、防衛準備中取消の修正を含む。
+
+全件PASS後に実描画の通しデバッグを実行。通常開業・3回決算・保存・終了・別プロセス再起動・継続が80＋17＝97チェックPASS。write/read両プロセス終了コード0、実行中ソース変更0、write-gameplay.jsonとread-gameplay.json完全一致。再起動後の決算画像も目視し、3日目利益+346G、帳簿照合一致、日本語表示を確認。
+
+証拠はartifacts/full-regression-after-defense-2026-09-29/。expected-tests.json、suites/all-tests.jsonと全ログ、source-start/end.json、source-change.json、coverage-verification.json、verification.json、opening-restart/を参照。
+
+前回139スイートの記録はFULL_REGRESSION_AFTER_GUEST_LOG.mdへ保全。今回の全回帰はソース版の検証であり、Windows配布版はこの修正をまだ含まない。Windows実機、未実装の原本機能・資産、長期実プレイ、全体性能予算の合格を示すものではない。NEXT_MECHANICS_AUDIT.mdに仕入れ補正と通常防衛UIの未実装を現行ソースから追記した。
+
+配布追補: 上記検証済みソースのWindows開発確認版を作成し、同梱PCK655チェックを検証。CURRENT_WINDOWS_PACKAGE.md参照。Windows実機は未検証。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_EVENT_DEFENSE.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — catalog manifest cache
+
+2026-09-30。147/147スイートPASS。欠落・余分・重複・失敗・実行中入力差分0。合計708.21秒。新cache専用試験は79項目PASSで、旧146スイートも全件保持。
+
+全件PASS後、macOS実描画で新規開業・3回決算・保存・終了・別プロセス再起動・継続を83＋20＝103項目PASS。書込46.55秒、読込34.92秒、ゲーム状態JSON一致。再起動画像を目視確認し、4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+同じ凍結ソースで関連描画5実行・403項目PASS（職員131、自動保存76、施設選択39、人物選択101、防衛画面56）。全回帰の実headless4ログを同じソースの証拠として参照し、484項目を再実行扱いにしない。
+
+戦闘途中の別プロセス保存・復元は19＋19＝38項目PASS。有料受付建設、通常採用、viewportのスクロール・クリックによる登録/開始/次波操作、ゲーム時間による2波撃退を確認。途中・最終の全ゲーム状態JSONと型付きdigestが一致。書込2.87秒、読込2.62秒。脅威作成だけ開示fixture。読込後の撃退画面と自動保存復旧画面を目視確認。
+
+証拠: artifacts/full-regression-after-manifest-cache-2026-09-30/、artifacts/manifest-cache-related-2026-09-30/、artifacts/manifest-cache-defense-restart-2026-09-30/。現在source-end SHA256: c09bc629442d319a3e4b928859213d23735943cfb32d91855f50380d5724449d。前146スイートの証拠は FULL_REGRESSION_BEFORE_MANIFEST_CACHE.mdへ保全。変更と測定は MVP_CATALOG_MANIFEST_CACHE.md を参照。
+
+既存試験と今回の通し試験の合格であり、原本全実装、通常脅威発生、性能予算、高負荷/長期プレイ、同じ版のWindows実機は未完了。Windows配布は別証拠に記録。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_EVENT_LABELS.md

@@ -0,0 +1,13 @@
+# Event → Defense・全回帰と通し確認
+
+2026-09-30。148/148スイートPASS。欠落・余分・重複・失敗・実行中ソース変更0。合計670.50秒。新Event専用試験186項目を含む。
+
+全件PASS後、macOS実描画で新規開業・3回決算・保存・終了・別プロセス再起動を83＋20＝103項目PASS（43.89秒/32.84秒）。ゲーム状態JSON一致、4日目00:00・帳簿一致・営業利益＋346Gを目視確認。
+
+同じ凍結ソースで関連描画5実行403項目PASS。全回帰の同じソース実ログ5件670項目を参照し、再実行扱いしない。Event queue/時計から生成された襲撃のviewport操作・戦闘途中保存・終了・別プロセス再開は22＋20＝42項目PASS。全ゲーム状態とtyped digest一致、全domain event/採番/乱数を保全し、Save/Loadの2種類のI/O観測type/payloadのみ明示normalization。
+
+通し画像で防衛画面に長い内部IDが露出する問題を発見。これを修正するため、現在の画面受入は完了としない。現在ソースと同じWindows版のexport/PCK検証は未実行。封印済み配布準備は実行せず、表示修正後に新証拠世代で検証する。
+
+証拠: artifacts/full-regression-after-event-defense-2026-09-30/、artifacts/event-defense-related-2026-09-30/、artifacts/event-defense-restart-2026-09-30/。source-end SHA256: 319b76d51c268a64e6ea1cddf8e2b0a02b05cfb87730749394ecb985a1fdeac1。
+
+原本全実装、通常脅威producer、性能予算、高負荷/長期プレイ、同じ版のWindows実機は未完了。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_GUEST_LOG.md

@@ -0,0 +1,17 @@
+# 現行ソースの全回帰と期待値修正
+
+全137ソーススイートを実行し、136合格・1失敗でランナー終了コード1。実行中ソース変更なし、未実行0、重複0をverification.jsonで確認。失敗ログを消去せず残す。
+
+失敗はtests/s0/test_definition_registry.gdのANYゾーン一覧にstandard_roomが無いこと。原本準拠の地上限定解除は既に実装・地下建設検証済みだったが、この期待値が古いままだった。一般客室をANY一覧へ追加して312チェックPASS、地下配置の回帰も40チェックPASS。
+
+修正前後のハッシュ差は当該テスト1ファイルのみ。製品コード・共通試験コードは不変。保持136合格＋修正済み1合格により現行137スイートの合格を網羅した。単一の全件PASS走査ではないことをcorrected-verification.jsonに明記。
+
+証拠: artifacts/current-full-regression-2026-09-29/。expected-suites.json、all-tests.json、各ログ、source-start/end.json、verification.json、corrected-source.json、corrected-verification.json。
+
+対象はtests/run_tests.gdおよびtests配下のtest*.gd。RefCountedのkernelモジュールはrun_tests経由、配布PCK試験は別工程。全原本実装・Windows実機・製品性能予算・長期プレイの合格ではない。
+
+全スイートの結果確定後、同じ製品ソースで実描画の開業・3回決算・別プロセス再起動を開始。実行ハンドル38791、出力opening-restart/。この通し結果は完了後に追記する。
+
+## 通し検証完了
+
+書込80・読込17、合計97チェックPASS。両プロセス終了コード0。書込63.11秒、読込48.00秒。source-change.jsonは空配列、write/read-gameplay.json一致。通常開業・3回決算・アプリ終了後の再起動継続まで確認した。全原本・Windows・長期プレイの合格ではない。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_MANIFEST_CACHE.md

@@ -0,0 +1,11 @@
+# 現行ソースの全回帰 — 防衛画面・自動進行後
+
+2026-09-30。146/146スイートPASS。欠落・余分・重複・失敗・実行中入力差分0。合計743.93秒。
+
+全件PASS後のmacOS実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込48.18秒、読込35.76秒、終了コード0。ゲーム状態JSON一致。再起動後画像で4日目00:00、帳簿一致、営業利益＋346Gを確認。
+
+続く戦闘途中の別プロセス保存復元は、実際の有料受付建設・通常採用・スクロールとviewportクリックによる参加/対象登録/開始・2分後の通常UI保存・終了・再起動・残り間隔・次波クリック・時計による撃退まで19＋19＝38項目PASS。書込3.22秒、読込2.33秒。途中と最終の全ゲーム状態JSONと型付きdigestが一致し、採番・乱数・資金・職員・施設を保持。脅威作成のみ開示fixture。画像4枚のうち読込後の撃退画面を目視確認。前のスクロール位置の画像も保全。
+
+証拠: artifacts/full-regression-after-defense-autonomy-2026-09-30/ (coverage-verification.json、source-start/end/change.json、verification.json、suites、opening-restart)。戦闘再開は artifacts/defense-autonomy-restart-2026-09-30/。対象と静的レビューは DEFENSE_CLOCK.md を参照。以前の144スイート結果は FULL_REGRESSION_BEFORE_DEFENSE_AUTONOMY.md へ保全。
+
+この結果は実装済みの試験と現在の2通しシナリオの合格。原本全実装、通常脅威発生、性能予算、長期プレイ、同じビルドのWindows実機は未完了。Windows配布更新は別証拠で記録する。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_SELECTION_AUTOSAVE.md

@@ -0,0 +1,11 @@
+# 現行ソースの全回帰 — 手動選択復元・受付担当検索改善後
+
+2026-09-29。141/141スイートPASS。失敗・未実行・余分な実行・重複・ソースハッシュ差分0。合計678.83秒。
+
+全件PASS後の実描画通し試験は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で83＋20＝103項目PASS。書込46.53秒、再読込34.53秒、終了コードともに0。ゲーム状態の比較は一致。保存読込後の受付の選択枠と詳細表示を画像でも確認。
+
+証拠: artifacts/full-regression-after-selection-restore-2026-09-29/。coverage-verification.json、source-start/end.json、verification.json、opening-restart/。以前の記録はFULL_REGRESSION_BEFORE_SELECTION_RESTORE.md。
+
+この結果は全原本実装・Windows実機・長期プレイ・性能予算の合格ではない。現在のWindows配布版はこれらの変更を含まない。
+
+後続変更: 自動保存・直接読込の選択復元を追加中。この全回帰結果には含まない。

docs/plans/original-completion-2026-09-29/execution/FULL_REGRESSION_BEFORE_SELECTION_RESTORE.md

@@ -0,0 +1,13 @@
+# 現行ソースの全回帰 — 営業履歴スナップショット軽量化後
+
+更新注記: GUIDE_ASSIGNMENT_SCAN.mdの受付担当検索の軽量化とSELECTION_RESTORE.mdの手動選択復元は本記録より後の変更。本記録の全回帰・配布・負荷結果にこの変更を含めない。
+
+2026-09-29。140/140スイートPASS、失敗・未実行・余分な実行・重複はすべて0。実行時間合計674.21秒。開始/終了および確認時のソースハッシュ差分0。
+
+全件PASS後の実描画通し検証は、新規開業・3回決算・保存・終了・別プロセス再起動・継続で80＋17＝97項目PASS。書込46.57秒、再読込34.75秒、双方終了コード0。ソース差分0、write-gameplay.jsonとread-gameplay.json一致。再起動後画面で3日目利益+346G、帳簿照合一致、日本語とドット施設・人物を確認。
+
+証拠: artifacts/full-regression-after-snapshot-reuse-2026-09-29/ の全ログ、expected-tests.json、coverage-verification.json、source-start/end.json、source-change.json、verification.json、opening-restart/。前回記録はFULL_REGRESSION_BEFORE_SNAPSHOT_REUSE.md。変更内容と個別性能測定はSNAPSHOT_CALL_REUSE.md。
+
+これは既存のソース試験と開業シナリオの合格であり、全原本実装・長期プレイ・性能予算・Windows実機の合格ではない。全スイート実行時間は性能基準の判定に使用しない。
+
+同一ソースからWindows開発確認版を生成。隔離PCK1,527項目、同PCKのmacOS実描画従業員操作132項目PASS。Windows実機は未確認。CURRENT_WINDOWS_PACKAGE.md参照。