Compare commits

...
Author SHA1 Message Date
Agent Control Runner fe44f55075 P24-02: 操作と通知の全受入 2026-10-17 15:07:07 +09:00
Agent Control Runner 78f7cba7a9 P24-02: 操作と通知の全受入 2026-10-17 14:49:39 +09:00
Agent Control Runner bd3a134051 P24-02: 操作と通知の全受入 2026-10-17 14:07:06 +09:00
Agent Control Runner 9641ed52de P24-02: 操作と通知の全受入 2026-10-13 15:31:14 +09:00
Agent Control Runner 666c87bd7d P24-02: 操作と通知の全受入 2026-10-13 12:53:16 +09:00
Takeshi 1a5abc6516 docs: freeze next P24-02 complete operations and notification acceptance 2026-10-13 09:45:20 +09:00
Takeshi b84c3499d1 docs: formally close P24-03 with reviewed integration and final evidence 2026-10-13 09:41:59 +09:00
Agent Control Runner 0a759f13ae Merge commit '4cefcff849d4dc1211caa5066e24bfae666cc2f4' into HEAD 2026-10-13 09:36:08 +09:00
Takeshi 41a5acbd43 test: complete Runner support and independent P24 acceptance evidence 2026-10-13 09:35:52 +09:00
Takeshi acc0df7ee2 test: retain exact Runner validation and P24 packet preservation evidence 2026-10-13 09:25:31 +09:00
Takeshi 8001b11558 docs: resume authorized P24 closure without redundant approval wait 2026-10-13 09:08:06 +09:00
Takeshi 6a7c032a4d docs: audit P24 packet proposal against exact blobs and malformed inputs 2026-10-13 08:58:51 +09:00
Takeshi 570f686e45 docs: hold unaccepted P13 repair and prioritize validated P24 closure 2026-10-13 08:53:46 +09:00
Takeshi e6e96d86d7 docs: record authorized isolated Runner repair and Claude auth dependency 2026-10-13 08:07:19 +09:00
Takeshi 231b3bd857 docs: preserve P08 feasibility without inventing construction values 2026-10-13 04:02:15 +09:00
Takeshi 256253343f docs: prove full-content P13 review packet dedup proposal 2026-10-13 03:57:29 +09:00
Takeshi e7aafdce39 docs: preserve final P13-03 records and scoped submission recovery proposal 2026-10-13 03:51:55 +09:00
Takeshi 5f766c5bf1 docs: preserve P13-03 gate failures and bounded final repair inputs 2026-10-13 03:45:23 +09:00
Takeshi 1f6c46d9f5 docs: start original P13-03 and preserve spec hash repair evidence 2026-10-13 03:33:42 +09:00
Takeshi e1a1651e15 docs: freeze original P13-03 content difference acceptance contract 2026-10-13 03:25:14 +09:00
Takeshi 470b8fe06c docs: record bounded D05 fee save and logistics diagnostic 2026-10-13 03:22:32 +09:00
Takeshi aec7a2e1ee docs: clarify unapproved mana arithmetic and furnace capacity options 2026-10-13 03:16:04 +09:00
Takeshi 52ee6bec9e docs: pin D05 daily boundary and paired elevator observations 2026-10-13 03:14:47 +09:00
Takeshi 3170e9c28a docs: preserve D05 diagnostic review and bounded followups 2026-10-13 03:10:12 +09:00
Takeshi c3e4c68b97 docs: trace D05 elevator rescue and purchase callbacks 2026-10-13 03:09:20 +09:00
Takeshi 149c302234 docs: trace D05 facility and emergency-stop scope 2026-10-13 03:07:22 +09:00
Takeshi 67d37c3e0b docs: draft unapproved D05 boundary decision options 2026-10-13 03:05:23 +09:00
Takeshi a257976ae2 docs: record P04 submitted preflight limits and failed acceptance 2026-10-13 03:02:18 +09:00
Takeshi 9444b43d3f docs: record final P04 repair protocol and input delivery 2026-10-13 02:55:37 +09:00
Takeshi 94642345b5 docs: preserve P04 audit and verified repair inputs 2026-10-13 02:48:14 +09:00
Takeshi d3ae1d227d docs: measure complete P24 reviewer packet under unchanged cap 2026-10-13 02:42:27 +09:00
Takeshi 7097eadf41 docs: record managed P04 audit start without acceptance credit 2026-10-13 02:39:15 +09:00
Takeshi deb1bcb237 docs: freeze P04 order audit inputs and original acceptance scope 2026-10-13 02:35:44 +09:00
Takeshi 339a118895 docs: retain updated planning validation pins 2026-10-13 02:30:08 +09:00
Takeshi 25467ac502 docs: record P24 exact-candidate validation and review proposal 2026-10-13 02:29:39 +09:00
Agent Control Runner 4cefcff849 P24-03: 選択と保存の受入 2026-10-13 01:20:44 +09:00
Agent Control Runner c2b8772e23 P24-03: 選択と保存の受入 2026-10-13 01:14:19 +09:00
Takeshi 243a3593bb docs: preserve P24 native failure and diagnostic evidence 2026-10-13 01:11:19 +09:00
Agent Control Runner 9c711860a8 P24-03: 選択と保存の受入 2026-10-13 00:57:32 +09:00
Takeshi 286730f88c docs: record P24 start and correct implementation role after read-only loop 2026-10-13 00:46:32 +09:00
Takeshi 9b2ee480a8 docs: freeze original P24-03 selection acceptance contract 2026-10-13 00:34:53 +09:00
Takeshi 4fb8312a33 docs: preserve unapproved mana proposal and independent review findings 2026-10-13 00:29:38 +09:00
Takeshi 5536bc0411 docs: freeze reuse-only repair contract for mana proposal 2026-10-13 00:19:30 +09:00
Takeshi 73cda6b867 docs: preserve unaccepted P06 audit and reconcile current status 2026-10-13 00:12:48 +09:00
Takeshi 0bdc4886cf docs: freeze owner-requested mana proposal contract 2026-10-13 00:06:47 +09:00
Takeshi 74fc69698a docs: record managed Claude decision and P06-01 audit dispatch 2026-10-12 23:45:56 +09:00
Takeshi dff514c774 docs: freeze original P06-01 contract and retained evidence for Runner 2026-10-12 23:39:00 +09:00
Takeshi 02d047c72a docs: reorder acceptance work and prepare managed AI handoff 2026-10-12 23:27:58 +09:00
Takeshi e58c5f5e17 Track build evidence omitted by the default Git ignore rules 2026-10-12 15:48:53 +09:00
Takeshi 2a53dbb596 Record current guest projection cost and whole-state evidence 2026-10-12 15:46:06 +09:00
Takeshi 381083dcaf Preserve whole-state comparison and current performance disposition 2026-10-12 15:14:16 +09:00
Takeshi 8b6e515dbf Preserve repaired validation capture candidate and reviewed local evidence 2026-10-12 14:51:08 +09:00
Takeshi 21fce14419 Preserve rejected r340 candidate and explicit remaining acceptance work 2026-10-12 14:32:50 +09:00
Takeshi 6a709be988 Preserve reviewed current phase diagnostic and correct P23-02 bottleneck scope 2026-10-12 14:14:42 +09:00
Takeshi ce36e98dde Preserve reviewed input-copy candidate and reconcile P23-02 acceptance ledger 2026-10-12 13:48:14 +09:00
Takeshi 083dbe8d02 Preserve reviewed S6 and whole-state evidence for native hot-loop candidate 2026-10-12 13:18:25 +09:00
Takeshi 6f91d35667 Preserve reviewed native hot-loop candidate and finite acceptance evidence 2026-10-12 13:08:08 +09:00
Takeshi 58a3534bf9 Preserve reviewed current native diagnostic and exact whole-state evidence 2026-10-12 12:41:19 +09:00
Takeshi 0cbe2641ff Verify native Guest batch local and full snapshot equivalence with reviewed evidence 2026-10-12 12:05:56 +09:00
Takeshi f710119423 Implement isolated native Guest candidate batch and preserve reviewed host build evidence 2026-10-12 11:13:51 +09:00
Takeshi c8b730e6a2 Preserve current native residual diagnostic and reviewed Guest work contract 2026-10-12 10:42:26 +09:00
Takeshi 8291273392 Verify ready-route boundary and finite reentry equivalence with versioned acceptance gaps 2026-10-12 10:12:33 +09:00
Takeshi c2a736b46e Preserve full four-group root verification for semantic integration 2026-10-12 09:52:13 +09:00
Takeshi 8e0d8ef32a Verify ready-route conversion fallbacks and actual mid-call script replacement 2026-10-12 09:51:34 +09:00
Takeshi 8b4e6b99aa Record ready-route whole equivalence and retain unadopted candidate with acceptance gaps 2026-10-12 09:36:37 +09:00
Takeshi aae045d3c6 Preserve ready-route candidate and reviewed finite evidence through r305 preparation 2026-10-12 09:27:48 +09:00
Takeshi 17390c9b0d Record guest normalization equivalence and decline adoption without whole performance gain 2026-10-12 09:05:02 +09:00
Takeshi 6a80649a7f Preserve unadopted guest need normalization candidates and finite verification 2026-10-12 08:49:28 +09:00
Takeshi f69cb05c07 Preserve codec trial evidence and retain prior performance implementation parent 2026-10-12 08:25:32 +09:00
Takeshi 603354f89a Preserve unadopted integer window codec candidate and static review checkpoint 2026-10-12 07:50:07 +09:00
Takeshi 21d89b988d Record pure tag projection impact and whole-save equivalence with unmet performance budget 2026-10-12 07:38:10 +09:00
Takeshi 6b40805e64 Record pure tag projection local acceptance and preserve remaining P23-02 gates 2026-10-12 07:21:51 +09:00
Takeshi 529047836f Record residual profiling and pure tag projection host build with remaining acceptance gates 2026-10-12 07:00:49 +09:00
Takeshi fd4b48b94b Record native WALK impact and whole-save equivalence with unmet performance budget 2026-10-12 06:18:11 +09:00
Takeshi 32be96ac76 Record finite native WALK equivalence and remaining P23-02 gates 2026-10-12 06:07:04 +09:00
Takeshi c67facdf48 Record native WALK provider host build and remaining P23-02 validation 2026-10-12 05:37:27 +09:00
Takeshi 8d55771647 Record P23-02 budget impact and whole-save equivalence 2026-10-12 05:03:58 +09:00
Takeshi 5055cc990b Record finite native Budget equivalence and remaining P23-02 gates 2026-10-12 04:47:42 +09:00
Takeshi 1c9ec77812 Record P23-02 native budget candidate and verified host build 2026-10-12 04:22:51 +09:00
Takeshi c34a7d3c6b Record bounded P23-02 performance-budget callback diagnostics 2026-10-12 04:09:52 +09:00
Takeshi d7b6608d0a Record P23-02 whole-save equivalence and decline unproven optimization 2026-10-12 03:56:49 +09:00
Takeshi 5516997fe1 Record P23-02 cached path equivalence and corrected candidate evidence 2026-10-12 03:39:45 +09:00
Takeshi ebf0fbe04b Record P23-02 internal diagnostics and remaining acceptance gaps 2026-10-12 03:11:40 +09:00
Takeshi 999a8b5e97 Record P23-02 local names validation and remaining acceptance gaps 2026-10-12 02:30:42 +09:00
Takeshi dc2ccccb36 Record P23-02 cache key validation and remaining acceptance gaps 2026-10-12 01:45:24 +09:00
Takeshi 89392846b7 Record P23-02 tag helper validation and candidate disposition 2026-10-12 01:01:47 +09:00
Takeshi e2d9144cca Record P23-02 travel ownership validation and whole-tick evidence 2026-10-12 00:10:49 +09:00
Takeshi 4013249135 Record P23-02 reconstruction equivalence and whole-tick disposition 2026-10-11 23:25:17 +09:00
Takeshi 3fe0b20207 Record P23-02 impact validation and reconstruction build evidence 2026-10-11 22:41:17 +09:00
Takeshi f7189923dd Record P23-02 boundary and whole-tick comparison evidence
Integrate the reviewed r195 boundary checks and r196 whole-tick comparison while retaining all unmet acceptance gates. Correct the need-relief fixture description to six zero-valued fields; no candidate adoption or additional unit completion is claimed.
2026-10-11 22:02:35 +09:00
Takeshi b9866afa02 Record P23-02 native guest pipeline validation and remaining gates 2026-10-11 21:18:49 +09:00
Takeshi 19daef97d3 Record P23-02 residual diagnostics and input structure audit 2026-10-11 20:35:41 +09:00
Takeshi 002400a080 Record P23-02 budget validation and remaining performance work 2026-10-11 20:03:41 +09:00
Takeshi fefe7d847f Record P23-02 repeated performance results and next candidate 2026-10-11 19:19:19 +09:00
Takeshi b1253fb066 Record P23-02 residual diagnostics and elevator index review 2026-10-11 18:36:44 +09:00
Takeshi a172288223 Record P23-02 cache validation and remaining performance gates 2026-10-11 18:00:49 +09:00
Takeshi 2be3b9cab9 Record P23-02 game validation and cache investigation progress 2026-10-11 17:16:46 +09:00
Takeshi d853b91b0b Record P23-02 native SDK validation and remaining acceptance gates 2026-10-11 16:37:47 +09:00
Takeshi b84bade045 Save The Tree implementation and acceptance work in progress
Preserve production code, regression fixtures, audio assets and provenance, test infrastructure, and the original-completion plan and progress ledger. Final game and Windows acceptance remain pending; excluded local artifacts and native experiments are not part of this snapshot.
2026-10-11 15:58:00 +09:00
Takeshi 39f6068461 Add supply auto-purchase and preserve save recovery state 2026-10-02 07:35:03 +09:00
Takeshi 285528b7a3 Expose pending service pricing in facility UI
Show normal usage fees separately from the unspecified desire-match surcharge. Preserve free reception and omit guest pricing from warehouse and cleaning rooms.

Validation: 155 suites / 12,310 checks; focused 700 checks; strict state and event equivalence; 16 normal and compact FRONT/BACK captures.
2026-10-01 02:43:39 +09:00
Takeshi 5dde0c5ec2 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.
2026-09-30 23:52:24 +09:00
Takeshi 6077e02ebe Add universal macOS release build with exported opening verification 2026-09-10 00:07:16 +09:00
Takeshi 6aa7397c2e Track the exported opening regression script UID 2026-09-10 00:00:38 +09:00
Takeshi 7121092794 Fix facility discovery in exported builds and verify first construction 2026-09-09 23:59:24 +09:00
Takeshi fb4ad23190 Add explicit stairs and measure elevator congestion with real actors 2026-09-09 14:26:38 +09:00
Takeshi e246ce382b Record the verified transport recovery point 2026-09-09 12:58:57 +09:00
Takeshi 0f12c748e9 Connect physical elevators and staff commutes to construction, saves, and cutaway UI 2026-09-09 12:58:40 +09:00
Takeshi 4d72de8973 Record business policy acceptance, economy results, and recovery point 2026-09-09 12:06:29 +09:00
Takeshi b3b82ef03e Add business pricing and closure controls with compatible digest optimization 2026-09-09 12:04:12 +09:00
2370 changed files with 810462 additions and 1277 deletions
+1
View File
@@ -0,0 +1 @@
@AGENTS.md
+129
View File
@@ -14,12 +14,14 @@ test:
$(MAKE) test-s2
$(MAKE) test-s3
$(MAKE) test-supply
$(MAKE) test-business
$(MAKE) test-s4
$(MAKE) test-s5
$(MAKE) test-s6
$(MAKE) test-mvp
$(MAKE) test-acceptance
$(MAKE) test-ui
$(MAKE) test-transport
$(MAKE) test-perf
test-s0:
@@ -32,8 +34,13 @@ 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_snapshot_transit_guard.gd
$(GODOT) --headless --path . --script res://tests/s1/test_path_congestion.gd
$(GODOT) --headless --path . --script res://tests/s1/test_construction_service.gd
$(GODOT) --headless --path . --script res://tests/s1/test_excavation_service.gd
@@ -44,7 +51,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
@@ -73,10 +87,20 @@ test-s5:
test-s6:
$(GODOT) --headless --path . --script res://tests/s6/test_save_operations.gd
$(GODOT) --headless --path . --script res://tests/s6/test_save_preflight.gd
$(GODOT) --headless --path . --script res://tests/s6/test_save_recovery_preservation.gd
$(GODOT) --headless --path . --script res://tests/s6/test_runtime_snapshot_serialization.gd
$(GODOT) --headless --path . --script res://tests/s6/test_performance_budget.gd
$(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
@@ -87,13 +111,43 @@ 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
$(GODOT) --headless --path . --script res://tests/ui/test_supply_management.gd
$(GODOT) --headless --path . --script res://tests/ui/test_supply_auto_purchase_ui.gd
$(GODOT) --headless --path . --script res://tests/ui/test_business_management.gd
$(GODOT) --headless --path . --script res://tests/ui/test_elevator_management.gd
$(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
test-perf-full:
@@ -106,6 +160,7 @@ check:
export-windows:
mkdir -p build/windows
$(GODOT) --headless --path . --export-release "Windows Desktop"
$(MAKE) test-exported-opening
# Pixel cutaway: interactive disposable inn, capture and input regression.
.PHONY: preview-pixel capture-pixel test-pixel-ui
@@ -116,6 +171,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
@@ -132,6 +188,10 @@ test-supply:
$(GODOT) --headless --path . --script res://tests/supply/test_supply_save_migration.gd
$(GODOT) --headless --path . --script res://tests/supply/test_supply_logistics_bridge.gd
$(GODOT) --headless --path . --script res://tests/supply/test_supply_management_service.gd
$(GODOT) --headless --path . --script res://tests/supply/test_supply_auto_purchase.gd
$(GODOT) --headless --path . --script res://tests/supply/test_normal_auto_purchase_chain.gd
$(GODOT) --headless --path . --script res://tests/supply/test_supply_auto_purchase_boundaries.gd
$(GODOT) --headless --path . --script res://tests/supply/test_supply_auto_purchase_destruction.gd
$(GODOT) --headless --path . --script res://tests/supply/test_normal_supply_chain.gd
capture-supply:
@@ -139,3 +199,72 @@ capture-supply:
preview-supply:
THE_TREE_SUPPLY_PREVIEW=1 $(GODOT) --path . --script res://tests/supply/test_normal_supply_chain.gd
.PHONY: test-business
test-business:
$(GODOT) --headless --path . --script res://tests/s2/test_facility_pricing.gd
$(GODOT) --headless --path . --script res://tests/business/test_business_operations.gd
$(GODOT) --headless --path . --script res://tests/business/test_business_closure.gd
.PHONY: preview-business capture-business
preview-business:
THE_TREE_BUSINESS_PREVIEW=1 THE_TREE_SUPPLY_PREVIEW=1 $(GODOT) --path . --script res://tests/supply/test_normal_supply_chain.gd
capture-business:
THE_TREE_BUSINESS_UI_CAPTURE=1 $(GODOT) --path . --script res://tests/ui/test_business_management.gd
.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
$(GODOT) --headless --path . --script res://tests/staff/test_staff_commute.gd
$(GODOT) --headless --path . --script res://tests/transport/test_transport_save.gd
$(GODOT) --headless --path . --script res://tests/transport/test_transport_density_migration.gd
$(GODOT) --headless --path . --script res://tests/transport/test_transport_boundaries.gd
$(GODOT) --headless --path . --script res://tests/transport/test_runtime_transport.gd
capture-transport:
THE_TREE_TRANSPORT_CAPTURE=1 $(GODOT) --path . --script res://tests/transport/test_runtime_transport.gd
preview-transport:
THE_TREE_TRANSPORT_PREVIEW=1 $(GODOT) --path . --script res://tests/transport/test_runtime_transport.gd
.PHONY: test-stairs test-transport-comparison
test-stairs:
$(GODOT) --headless --path . --script res://tests/world/test_path_vertical_policy.gd
$(GODOT) --headless --path . --script res://tests/world/test_path_transit_density.gd
$(GODOT) --headless --path . --script res://tests/world/test_stair_infrastructure.gd
$(GODOT) --headless --path . --script res://tests/world/test_legacy_stairs.gd
$(GODOT) --headless --path . --script res://tests/transport/test_runtime_stairs.gd
$(GODOT) --headless --path . --script res://tests/ui/test_stair_transport_details.gd
test-transport-comparison:
$(GODOT) --headless --path . --script res://tests/transport/test_transport_comparison.gd
$(GODOT) --headless --path . --script res://tests/transport/test_runtime_transport_comparison.gd
# Check the actual shipped data outside this checkout, including first build.
WINDOWS_PCK ?= build/windows/TheTree.pck
MACOS_APP ?= build/macos/TheTree.app
.PHONY: export-macos
export-macos:
mkdir -p build/macos
$(GODOT) --headless --path . --export-release "macOS" "$(MACOS_APP)"
python3 tools/verify_exported_opening.py "$(MACOS_APP)/Contents/Resources/The Tree.pck" --godot "$(GODOT)"
.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)"
+1 -1
View File
@@ -8,7 +8,7 @@
Godotが開いたら、右上の実行ボタンまたは `F5` でプロジェクトを起動できます。エディタを開かず直接実行する場合は `make run` を使用します。
通常の新規ゲームは一時停止から始まります。左上の開業ガイドに沿って受付・客室・通路を建て、「従業員」で雇用・配属・毎日の勤務帯を決めます。「帳簿」で翌朝06:00の決算を確認できます。具体的な最小宿の建て方は [試遊ガイド](docs/PLAYTEST_GUIDE.md#通常uiで最初の宿を開業する) を参照してください。
通常の新規ゲームは一時停止から始まります。左上の開業ガイドに沿って受付・客室・通路を建て、「従業員」で雇用・配属・毎日の勤務帯を決めます。「帳簿」で毎日00:00の決算を確認できます。具体的な最小宿の建て方は [試遊ガイド](docs/PLAYTEST_GUIDE.md#通常uiで最初の宿を開業する) を参照してください。
## ドット絵の世界樹を見る
+3
View File
@@ -0,0 +1,3 @@
#!/bin/zsh
# 同伴救護・待機室休息を反映した検証済みドット版
open -n '/Users/korizatou114/Projects/とりにく工房ゲーム制作部/build/macos/TheTree-Labor-2026-09-29.app'
Binary file not shown.
@@ -0,0 +1,24 @@
[remap]
importer="wav"
type="AudioStreamWAV"
uid="uid://qpe5mfy3o1cw"
path="res://.godot/imported/tree_theme_back_candidate.wav-1af8eac19cfe5ccb9a16a9a74b171ffd.sample"
[deps]
source_file="res://assets/audio/bgm/tree_theme_back_candidate.wav"
dest_files=["res://.godot/imported/tree_theme_back_candidate.wav-1af8eac19cfe5ccb9a16a9a74b171ffd.sample"]
[params]
force/8_bit=false
force/mono=false
force/max_rate=false
force/max_rate_hz=44100
edit/trim=false
edit/normalize=false
edit/loop_mode=0
edit/loop_begin=0
edit/loop_end=-1
compress/mode=0
Binary file not shown.
@@ -0,0 +1,24 @@
[remap]
importer="wav"
type="AudioStreamWAV"
uid="uid://dr4atdrw3iv1o"
path="res://.godot/imported/tree_theme_front_candidate.wav-dd40d47f468b616e1eb3517c0056cc0c.sample"
[deps]
source_file="res://assets/audio/bgm/tree_theme_front_candidate.wav"
dest_files=["res://.godot/imported/tree_theme_front_candidate.wav-dd40d47f468b616e1eb3517c0056cc0c.sample"]
[params]
force/8_bit=false
force/mono=false
force/max_rate=false
force/max_rate_hz=44100
edit/trim=false
edit/normalize=false
edit/loop_mode=0
edit/loop_begin=0
edit/loop_end=-1
compress/mode=0
+22
View File
@@ -0,0 +1,22 @@
Interface Sounds (1.0)
Created/distributed by Kenney (www.kenney.nl)
Creation date: 11-02-2020
------------------------------
License: (Creative Commons Zero, CC0)
http://creativecommons.org/publicdomain/zero/1.0/
This content is free to use in personal, educational and commercial projects.␍
Support us by crediting Kenney or www.kenney.nl (this is not mandatory)
------------------------------
Donate: http://support.kenney.nl
Patreon: http://patreon.com/kenney/
Follow on Twitter for updates:
http://twitter.com/KenneyNL
Binary file not shown.
+19
View File
@@ -0,0 +1,19 @@
[remap]
importer="oggvorbisstr"
type="AudioStreamOggVorbis"
uid="uid://cg3ltmy3l1tut"
path="res://.godot/imported/bong_001.ogg-036c448bb5d6a2a3d929d1a393030267.oggvorbisstr"
[deps]
source_file="res://assets/audio/ui/bong_001.ogg"
dest_files=["res://.godot/imported/bong_001.ogg-036c448bb5d6a2a3d929d1a393030267.oggvorbisstr"]
[params]
loop=false
loop_offset=0
bpm=0
beat_count=0
bar_beats=4
Binary file not shown.
+19
View File
@@ -0,0 +1,19 @@
[remap]
importer="oggvorbisstr"
type="AudioStreamOggVorbis"
uid="uid://b6gxkug03pmia"
path="res://.godot/imported/click_001.ogg-faef30153c7c6ab499289b7b03f0bade.oggvorbisstr"
[deps]
source_file="res://assets/audio/ui/click_001.ogg"
dest_files=["res://.godot/imported/click_001.ogg-faef30153c7c6ab499289b7b03f0bade.oggvorbisstr"]
[params]
loop=false
loop_offset=0
bpm=0
beat_count=0
bar_beats=4
Binary file not shown.
@@ -0,0 +1,19 @@
[remap]
importer="oggvorbisstr"
type="AudioStreamOggVorbis"
uid="uid://csfga2avhq4ul"
path="res://.godot/imported/confirmation_001.ogg-3e5a493cd453540435a25930de468964.oggvorbisstr"
[deps]
source_file="res://assets/audio/ui/confirmation_001.ogg"
dest_files=["res://.godot/imported/confirmation_001.ogg-3e5a493cd453540435a25930de468964.oggvorbisstr"]
[params]
loop=false
loop_offset=0
bpm=0
beat_count=0
bar_beats=4
Binary file not shown.
+19
View File
@@ -0,0 +1,19 @@
[remap]
importer="oggvorbisstr"
type="AudioStreamOggVorbis"
uid="uid://cwdh8pkwvyuf2"
path="res://.godot/imported/error_008.ogg-41fd046ecd9f266bdea4813897127346.oggvorbisstr"
[deps]
source_file="res://assets/audio/ui/error_008.ogg"
dest_files=["res://.godot/imported/error_008.ogg-41fd046ecd9f266bdea4813897127346.oggvorbisstr"]
[params]
loop=false
loop_offset=0
bpm=0
beat_count=0
bar_beats=4
+38
View File
@@ -0,0 +1,38 @@
{
"official_page": "https://kenney.nl/assets/interface-sounds",
"official_archive_sha256": "f2193d072726d6758a5f7871b2dcc54dcce0d5c35c6f0a62f92549b327c81232",
"license": {
"name": "Creative Commons Zero, CC0",
"official_url": "https://creativecommons.org/publicdomain/zero/1.0/",
"path": "assets/audio/ui/License.txt",
"sha256": "f7966c773bbed0eca6a9c75081c44a178b38eae112724dbb5fdfbd4192d118a9",
"original_byte_preserved": true
},
"assets": [
{
"role": "click",
"path": "assets/audio/ui/click_001.ogg",
"sha256": "ccfb7fa0cccdd9faec0eb16033c732b1e308d139d80f799161495d58f7adcdb9",
"bytes": 4876
},
{
"role": "success",
"path": "assets/audio/ui/confirmation_001.ogg",
"sha256": "063564703b6094d70718a3e787a55cc9141611e4ecd6b6637f8828f79b4a8c3a",
"bytes": 8968
},
{
"role": "refusal",
"path": "assets/audio/ui/error_008.ogg",
"sha256": "eba17ecb2a426bfd4a8a6acff5f8a86202b6424a77af0fd842e37809a1ab6d81",
"bytes": 9215
},
{
"role": "notification",
"path": "assets/audio/ui/bong_001.ogg",
"sha256": "d21d0f0b782445db579d11e2506b24cd1ac9d664ee33aeaf807761aa7b6fd710",
"bytes": 4848
}
],
"usage": "UI click, committed action success/refusal, new foreground notification"
}
+20
View File
@@ -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);
}
+1
View File
@@ -0,0 +1 @@
uid://duedneo846yck
@@ -1,4 +1,4 @@
[gd_resource type="Resource" script_class="VisualThemeProfile" load_steps=74 format=3]
[gd_resource type="Resource" script_class="VisualThemeProfile" load_steps=75 format=3]
[ext_resource type="Script" path="res://scripts/ui/visual_theme_profile.gd" id="1_theme"]
[ext_resource type="Texture2D" path="res://assets/themes/japanese_fantasy/world-front-v1.png" id="2_front"]
@@ -207,6 +207,10 @@ region = Rect2(627, 940.5, 313.5, 313.5)
atlas = ExtResource("5_system")
region = Rect2(940.5, 940.5, 313.5, 313.5)
[sub_resource type="AtlasTexture" id="F_stairs"]
atlas = ExtResource("8_pixel_dungeon")
region = Rect2(48, 48, 16, 16)
[resource]
script = ExtResource("1_theme")
pixel_dungeon_tiles = ExtResource("8_pixel_dungeon")
@@ -216,18 +220,25 @@ 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"),
"guest_elevator": SubResource("F22"),
"service_elevator": SubResource("F23"),
"guest_stairs": SubResource("F_stairs"),
"service_stairs": SubResource("F_stairs"),
"staff_door": SubResource("F30"),
"guest_corridor": SubResource("F31"),
"service_corridor": SubResource("F32"),
File diff suppressed because it is too large Load Diff
+496 -20
View File
@@ -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"
]
}
]
}
+1 -1
View File
@@ -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",
+8
View File
@@ -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
}
+1
View File
@@ -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
+3 -2
View File
@@ -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
@@ -20,8 +21,8 @@ required_roles = Array[StringName]([&"cook", &"server", &"attendant"])
primary_skill = &"cooking"
capacity = 12
queue_capacity = 24
base_service_minutes = 15
base_service_minutes = 45
base_quality = 55
base_price = 35
base_price = 25
inventory_inputs = {&"ingredient/basic_meal": 1}
tags = Array[StringName]([&"dining", &"social"])
+1 -1
View File
@@ -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
+28
View File
@@ -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"])
@@ -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"])
+4 -2
View File
@@ -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
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
@@ -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 = &"guest_stairs"
display_name = "客用階段"
description = "上階の踊り場を設置し、直下の表層通路へつなぐ階段。客と従業員が待たずに昇り降りする。"
zone = 0
layer = 0
footprint = Vector2i(1, 1)
allowed_rotations = Array[int]([0])
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
staff_max = 0
capacity = 3
queue_capacity = 0
base_service_minutes = 1
base_quality = 50
base_price = 0
tags = Array[StringName]([&"guest_access", &"movement", &"route_subslot", &"schema_facility_proxy", &"stairs", &"vertical_connector"])
@@ -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 = &"service_stairs"
display_name = "業務用階段"
description = "上階の踊り場を設置し、直下の裏層通路へつなぐ従業員専用の階段。物資運搬にも使う。"
zone = 0
layer = 1
footprint = Vector2i(1, 1)
allowed_rotations = Array[int]([0])
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
staff_max = 0
capacity = 2
queue_capacity = 0
base_service_minutes = 1
base_quality = 50
base_price = 0
tags = Array[StringName]([&"movement", &"route_subslot", &"schema_facility_proxy", &"staff_only", &"stairs", &"vertical_connector"])
+1
View File
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
+4 -3
View File
@@ -11,7 +11,7 @@ description = "全ての客のチェックインと精算を処理する、境
category = &"guest_service"
service_types = Array[StringName]([&"check_in", &"check_out"])
default_service_type = &"check_in"
service_profiles = {&"check_in": {&"duration_minutes": 8, &"base_quality": 60, &"base_price": 20, &"capacity_units": 1, &"need_effects": {&"sleep": 0}}, &"check_out": {&"duration_minutes": 6, &"base_quality": 60, &"base_price": 0, &"capacity_units": 1, &"need_effects": {&"sleep": 0}}}
service_profiles = {&"check_in": {&"duration_minutes": 20, &"base_quality": 60, &"base_price": 0, &"capacity_units": 1, &"need_effects": {&"sleep": 0}}, &"check_out": {&"duration_minutes": 6, &"base_quality": 60, &"base_price": 0, &"capacity_units": 1, &"need_effects": {&"sleep": 0}}}
zone = 2
layer = 0
footprint = Vector2i(4, 2)
@@ -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
@@ -30,9 +31,9 @@ staff_max = 3
required_roles = Array[StringName]([&"receptionist"])
capacity = 8
queue_capacity = 16
base_service_minutes = 8
base_service_minutes = 20
base_quality = 60
base_price = 20
base_price = 0
opening_schedule = {&"morning": true, &"day": true, &"night": true}
policy_schema = {&"price_mode": {&"type": &"enum", &"default": &"standard"}, &"vip_priority": {&"type": &"bool", &"default": false}}
cleanliness_decay_per_service = 1
+26
View File
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
+1
View File
@@ -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
+3 -2
View File
@@ -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
@@ -20,5 +21,5 @@ capacity = 2
queue_capacity = 4
base_service_minutes = 720
base_quality = 50
base_price = 80
base_price = 120
tags = Array[StringName]([&"lodging", &"quiet"])
+1
View File
@@ -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
+1
View File
@@ -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
+5 -1
View File
@@ -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フィルターを使い、通常表示では整数倍率を優先する。高解像度の絵をぼかして縮小した人物をマップの主役にしない。
- 幹・葉・部屋・家具は同じドット密度と色調で専用描画する。主色は木色・クリーム・濃緑、裏方の補助色は青緑とする。
+55
View File
@@ -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実機や未実装ルートの完走を今回の完了範囲に含めない。
+39
View File
@@ -247,3 +247,42 @@
- 人員データ: 倉庫の必要役割を既存雇用候補の `porter` に合わせる。食堂は既存の `cook`/`server` を維持して `attendant` を追加し、接客係Iris/Junoも配属できるようにする。候補に存在しない役割だけを要求して厨房と食堂の同時営業を阻む状態を解消する。
- 保存と撤去: 生産計画、進行中バッチ、予約ID、進捗と時刻を保存し、復元済みInventoryの所有者・品目・数量・依頼者・用途・期限と照合する。有効な生産計画または進行中バッチがある厨房は解体対象にできない。停止済みかつバッチがない計画は解体成功後に削除する。
- 仕様差: 正本の「料理ポイント+食器在庫」、食器・清掃用消耗品の購入と消費、廃棄物回収の通常操作は後続の仕様調整へ残す。今回の基本料理を料理ポイントへ暗黙に読み替えない。食堂の現行15分/35Gと正本45分/25G、受付の直接収入、宿泊決済時刻、倉庫のRank解禁条件も、この供給接続では改定しない。
## D-034: 通常営業の価格・休業操作とv1照合処理の軽量化
- 日付: 2026-09-09。承認済みPLAY-05の実装。
- 価格: 奉仕60%/安価80%/標準100%/高価150%/ぼったくり250%。Gは整数、0.5Gを切り上げる。UI、客の候補評価、Runtimeの新規見積は同じ規則を使う。受付済み・サービス中の価格と方針は受付時のコピーを維持し、後から変更しない。
- 基準値: 新設受付を無料・20分、一般客室を120G、大衆食堂を25G・45分へ正本§7.6に合わせる。受付を同じ客が何度も訪れて直接売上を増やす動作を解消し、自然な候補ではチェックインを1回までにする。厨房・倉庫等は既存の無料設定を維持する。
- 保存互換: Runtime v7とDigest v1は維持する。価格・開閉は既存Policyへ格納する。既存保存の非受付施設は保存された基準価格・時間を引き継ぐ。受付では保存された施設の基準価格が20Gでも新規見積は0Gにする。旧受付で受付済みの20G見積、過去の台帳、サービス中の時間は遡及修正しない。旧施設を現行基準へ一括変更する移行は今回行わない。
- 営業: business_openは既存operator_openへ反映する。休業は新規受付を止め、待機客の予約・在庫を返して再判断させる。開始済みサービスは既存の完了処理を続ける。全グループの所有参照・遷移上限を事前確認し、休業による退列では忍耐を消費しない。厨房・物流の既存開閉判定も同じoperator_openを参照する。配車後でも積込時に荷元を再確認し、休業なら未積込の予約を解いて再試行する。積込済みの貨物は納品先が営業中なら配送を完了できる。休業だけで雇用や給与は止めない。
- 満足: 既存のサービス品質による満足サンプルへ価格補正(+10,+5,0,-5,-20)を追加する。P1では期待品質を共通50とし、品質が20以上上回ると負の補正を半減する。-2.5は-3へ丸める。品質への反応度quality_sensitivityを期待品質と取り違えない。客別期待品質、待ち時間・好み等を含む正本§8.5の全式、宿泊前払いと追加精算は後続へ残す。
- 表示: 営業パネルの当日費用は当該施設をsourceとする運営費の記帳で、給与配賦を含む確定利益ではない。給与配賦・施設別利益は06:00の帳簿で確認する。需要は客の予算とUtilityへ実反映するが、予測人数を算出していない段階で架空の人数予測を表示しない。
- 性能: Snapshotの履歴・項目・検証頻度を減らさず、Digest呼出しの中だけで同じ辞書キー構成の符号化と順序を再利用する。String/StringNameを分け、上限を設ける。値や可変コンテナの出力をキャッシュしない。旧v1実装をテスト参照として残し、全対応型・衝突・変更・深さ・拒否条件のバイト一致を検証する。測定の約2倍はDigest単体であり、実ゲームのfps改善率ではない。
- 検証記録: [P1営業設定](qa/P1_BUSINESS_MANAGEMENT.md)。P1全体・初見30分・昇降機・Windows性能の完成判定とは分ける。
## D-035 昇降機を建設・乗客・通勤へ接続する
- 状態: 採用(2026-09-09。P2の基本運行。改善前後比較と全階間経路規則は継続)
- 運行: 同じ幅・x座標・レイヤーで縦に連結した完成モジュールを1本の昇降路とし、1台のかごを共有する。客用は4人・1階10分、業務用は8人・1階5分。扉の処理は各端で固定2分と乗降人数分。古い要求を優先し、同じ出発階・目的階の客をまとめる基本方式とする。途中階の相乗りを行うSCAN方式は未実装。
- 経路: Path v4に所有者付きの縦徒歩抑制領域を保存する。昇降路の全占有マスでは上下の徒歩Edgeを作らず、同じ階の横アクセスと運行Connectorを使う。既存の昇降路以外の上下通路は階段相当として維持する。全世界の階間徒歩抑制と明示的な階段施設への移行はMOVE-01の残課題とする。客用と業務用の権限を分け、BACKはstaff権限を必須にする。
- 位置: 乗車中はPathとActorの論理位置を乗車元の停留所に保持し、実際の移動時間と降車処理が終わってから到着階へ更新する。画面では乗車中の人物を地上から隠してかごに描く。この段階では乗車中の人数が乗車元の混雑密度に残る。車内を別空間として扱う密度改善は残課題。
- 工事と停止: 人が乗車・待機している、またはかごが運行中の昇降路は延伸・撤去を拒否する。空の昇降路の延伸開始後は新規乗車を完了まで保留する。運行停止や電力喪失は待機要求を解除し、乗客を最寄りの有効停留所へ避難させる。有効停留所がなければかご内で保持して復旧を待つ。プレイヤーの運行許可と魔力供給は別に保存し、通電だけで停止設定を解除しない。
- 通勤: 通常UIの継続配属は到着までCOMMUTINGとする。同じ階の勤務施設内または横に接する経路に到着してから稼働人員と勤務実績へ反映する。階の上下隣接だけでは到着・荷物の受渡しとしない。混雑による歩行距離の端数は持ち越す。運搬員は勤務ごとに倉庫へ出勤後、配送先から次便を受けられるが、不在の倉庫には人員を計上しない。勤務終了時は位置を保持し、帰宅の瞬間移動は行わない。
- 保存: Runtime v8にElevatorServiceの状態、要求、かご、扉、残り時間、運行設定を保存する。Path、Actor、建設モジュールの所有関係を検証し、Operationsと建設の巻き戻しにも含める。旧v7以前の昇降機のない保存は移行し、厨房の導入境界は引き続きv7。旧配属の論理人員は物理位置へ合わせて移行し、新しい保存の幽霊人員は拒否する。継続計画のない旧単日Shiftには従来の論理出勤を保持する。
- 素材: 既存のKenney人物を車内でも使い、レール・扉・かごは既存のコード描画によるドット表現へ追加する。外部画像の新規導入はない。
- 撤去の保存修正: 施設撤去の成功時は対応する完成済み工事を現役の工事一覧と進捗時刻表から取り除く。これまで完成工事だけが残り「完成施設がない」と保存検証で拒否されていた。IDの最大値、台帳、DomainEventの履歴は維持し、工事IDを再利用しない。延伸後の部分撤去・全撤去と、失敗時の巻き戻しを検証する。
## D-036 明示階段と車内密度、旧通路の一回限りの移行
- 状態: 採用(2026-09-09。承認済みMOVE-01・02・06の続き)。D-035の「昇降路以外は上下徒歩を維持」を新ゲームについて更新する。
- 新ゲーム: Pathの全階間WALKを禁止し、階段CONNECTORまたは物理昇降機を通る。左右の同階通路、staffドア、昇降路の所有者付き遮断は維持する。独立Path部品は旧呼出し互換のため既定false、Runtimeは必ずtrue。
- 階段: 客用40G・通行容量3、業務用50G・容量2、双方資材0・建設10分・維持魔力0。1×1の上部踊り場を置き、同じx/layerの一つ下の通行可能セルへ双方向接続する。業務用はstaff権限を要求する。下部足場は先に完成させ、依存する階段があれば撤去を拒否する。
- 移動: 新階段は1階cost150・通常速度で1.5ゲーム分。1分tickの移動creditを繰越し、2階を3分で移動する。途中の1000~1499creditは階段端点でのみ保存できる。閉塞で端点に留まっていても保存でき、撤去で使えなくなった端数は切り詰める。経路評価のcostと実移動を接続するが、「3階以内を優先」の距離別選好は今回追加しない。
- 保存: Runtime v9/Path v5。Runtime v8以下の正当な旧Path3/4等を読み、既存の垂直WALK辺のみを `legacy.stairs:<layer>:<x>:<lower_y>` CONNECTORへ一度だけ実体化する。旧通路のcost100・空accessを維持し、古いBACKの権限も変更しない。新しい階段施設へ無償で置換する方式ではなく、既設接続を独立所有する。Pathと所有記録を厳密照合する。
- 撤去: 旧接続は端点消失・昇降路への変更で除去し、その位置へ後から普通の通路を作っても再生成しない。Construction・Operations・Rankの巻戻しにはPathと旧階段所有者を同時に含める。階間の復旧誘導も実際の接続があるセルだけを候補にする。
- 車内: BOARDEDの実Actorを床の混雑人数から除外する。待機者は床に数える。位置の所有アンカーは降車まで乗車元へ残し、車内所有・描画・密度はその状態から導く。旧v4保存では旧方式の全Actor密度が正しいことを先に検証し、その後に乗客を除く。新v5の保存はtransit集合と密度の双方を厳密照合する。
- 表示・測定: 乗車確定時にELEVATOR_BOARDEDを記録する。選択詳細の平均・P95は保持中の直近256出来事から過去60分の乗車を抽出したサンプルであり、全履歴の集計とは表示しない。現在の最長待ちは実待機者から算出する。比較試験は別の完全traceで48人全員を記録し、UIの保持上限に依存しない。
- 比較の範囲: 同Seed・需要traceで客用昇降機1台と2台を比較。自然来客AI、離脱改善、3階以上の混雑比較やS14の総合合格とは区別する。追加設備代・資材・維持魔力、および動的再経路選択による実歩数増も結果に含める。
+30 -12
View File
@@ -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項目も合格した。部品の接続、単日成立、段階全体の完成を区別する。
## 状態の読み方
@@ -32,10 +38,10 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
| ID | 実装済みの根拠 | 未接続・仕様差・検証残と次の確認 |
|---|---|---|
| PLAY-01 | **最小ループ実装済み・単日確認**。初期Gold 5,000/資材50、通常UIの建築経路で受付1・一般客室2・通路7、アカネ雇用・配属、自然来客の宿泊320G、翌06:00決算まで確認。`test_first_operating_day.gd` | 受入は見学Fixture・無料在庫・客挿入なし。**供給込み3営業日も自動確認/バランス調整残**。受付売上6,020G等の数値を正本と照合し、受付の直接収入と価格・営業Policyを調整する |
| PLAY-02 | **通常UI接続済み・個別API103項目/単日確認**。雇用済み一覧、配属・再配属・未配属、DAY/NIGHT継続計画、変更不可・経路・定員等の理由、予約Commandと保存復元。StaffService v4、D-032 | 実通勤と到着後の稼働はMOVE-07へ分離。現在は経路存在を検証して論理配属し、人物位置は変えない。5職員・複数施設・3営業日の継続配属は供給受入で確認。実通勤と人手不足への人手試遊は残る |
| PLAY-02 | **通常UI接続済み・個別API103項目/単日確認**。雇用済み一覧、配属・再配属・未配属、DAY/NIGHT継続計画、変更不可・経路・定員等の理由、予約Commandと保存復元。StaffService v4、D-032 | 実通勤と到着後の稼働はMOVE-07へ接続済み。5職員・複数施設・3営業日の継続配属は供給受入で確認。実通勤と人手不足への人手試遊は残る |
| PLAY-03 | **通常UI接続済み**。完成倉庫への有料購入、容量・期限・予約、実porter TaskとPathによる倉庫→厨房→食堂。物流81項目、管理処理84項目、商品UI37項目の回帰 | 仕入れは倉庫への即納。外部業者の納期、継続自動購入、複数品目、正本の食器・消耗品は後続。経路断・満杯・腐敗・担当不能での保持/再試行/返送を検証 |
| PLAY-04 | **自律生産接続済み・140項目確認**。明示設定した厨房で原料4→料理4、15稼働分、目標在庫、入力予約・出力容量・期限・中断復帰を扱う。見学用の無料在庫に依存しない | **仕様差をD-033で明記**。今回の原料/基本料理を維持し、料理ポイント+食器、食堂価格・所要時間との統一は残す |
| PLAY-05 | **日次帳簿UI接続済み・単日確認**。06:00営業日、入出金と建築、確定売上・運営費・給与・利益・前日差・未払・施設別損益を表示。翌朝給与120G、未払0、照合一致 | **操作未接続/仕様差・調整残**。価格・営業/休業Policy UI、受付の直接収入、宿泊の決済・記帳時点、維持費分類を正本と照合。受付売上6,020G・全利益6,040Gは製品バランス合格ではない |
| PLAY-04 | **自律生産接続済み・140項目確認**。明示設定した厨房で原料4→料理4、15稼働分、目標在庫、入力予約・出力容量・期限・中断復帰を扱う。見学用の無料在庫に依存しない | **仕様差をD-033で明記**。今回の原料/基本料理を維持し、料理ポイント+食器は残す。食堂価格・所要時間はD-034で新設25G/45分に統一 |
| PLAY-05 | **日次帳簿UI接続済み・単日確認**。06:00営業日、入出金と建築、確定売上・運営費・給与・利益・前日差・未払・施設別損益を表示。翌朝給与120G、未払0、照合一致 | **価格・営業UI接続済み**。5段階の見積・客の選択と満足・新規受付停止・忍耐を減らさない退列・途中保存。新設受付0G/20分、客室120G、食堂25G/45分へ修正。宿泊前払い・維持費・初見の改善試遊は残る。D-034と営業設定QA参照 |
| PLAY-06 | **Runtime v7と配送途中Save復元を確認**。厨房計画・バッチ、Request・Task・carrier・貨物・予約を照合。旧v6移行20項目、商品UIの待機購入も再読込後に一度だけ確定 | 建設中・行列中・配送中を組み合わせた再起動の人手試遊、手動10枠UIと製品の保存導線は残る |
追加の供給受入では初期予算から倉庫・厨房・食堂と職員5人を運営し、3日とも給与645G・未払0・照合差0を確認した。食堂売上4,200G、原料360G、実配送81便。配送途中のディスクSaveと最終Snapshotを復元。詳細は [供給検証記録](qa/P1_SUPPLY_CHAIN.md)。価格・営業Policy・改善対照試遊が残るためP1全体は未合格とする。
@@ -44,27 +50,33 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
## P2:上下移動と混雑
完成条件: 3階以上で実乗降し、同じ人数・需要のまま設備と動線の改善で待ち時間・離脱が減ること。**現在は運行未統合。**
完成条件: 3階以上で実乗降し、同じ人数・需要のまま設備と動線の改善で待ち時間・離脱が減ること。**基本運行・明示階段・実通勤を統合済み。同需要48人の設備比較を追加。自然来客の離脱比較は継続。**
| ID | 実装済みの根拠 | 未接続・仕様差・検証残と次の確認 |
|---|---|---|
| MOVE-01 | `path_service.gd` の隣接経路、Connector、アクセス権、`facility_infrastructure_projector.gd` の通路・職員ドア投影 | **仕様との相違/未統合**。同一階の徒歩と設備による垂直移動を分け、通常隣接Edgeで階間を迂回する経路を抑制。旧通路・Saveからの移行を決める |
| MOVE-02 | PathにElevator状態、有限Queue、要求重複防止、停止時迂回、停滞検知の部品 | **未統合**。昇降路、停止階、車両、定員、待機要求を1方式の運行モデルへつなぐ。部品のQueue試験だけで昇降機完成としない |
| MOVE-03 | 昇降機Definitionがパレットにある。現在のRuntimeは安全なTopology未統合として建設を拒否 | **画面へ未接続/未検証**。建設・延伸・停止階変更・撤去・客用/業務用権限を運行へ統合する |
| MOVE-04 | `world_preview.gd` の徒歩補間と人物の小型描画 | **未実装**。待つ→乗る→昇降→降りるの運行状態を表示し、車内と徒歩の重複を防ぐ。見学の上階通路移動は乗降試験ではない |
| MOVE-05 | Path単体の停止・Queue・停滞検知とSnapshot試験 | **未検証**。統合した車両で満員、撤去、経路変更、車内Save復元を試験し、永久行列・二重乗車・閉じ込めを解消 |
| MOVE-06 | 既存の混雑密度/容量表示、[MVP受入](MVP_ACCEPTANCE_SCENARIOS.md)の比較条件 | **未検証**。同一Seed・需要・人数・施設数で改善前後を比較し、画面と移動時間P95・離脱で記録する |
| MOVE-07 | **計画と経路検証のみ接続済み**。通常UIの配属は継続計画を保存し、経路が存在するかを検証。人物のcurrent_cellは変更しない | **未統合**。勤務開始→実通勤→職場到着→人員稼働をつなぎ、移動中や不到達の人物を到着済み人員として扱わない。再配属・夜勤・Save復元を含める |
| MOVE-01 | **統合済み**。新ゲームは全階間の通常徒歩を禁止し、客用/業務用階段を通常建設。旧上下通路を一度だけ階段接続へ移行 | 1階150cost・1.5分の端数移動、下部足場の撤去防止、旧接続の撤去後無再生成。3階以内優先の特別経路規則は未導入。D-036 |
| MOVE-02 | **基本運行接続済み**。同じ昇降路を1台で運行、客用4人/業務用8人、扉・実移動時間・FIFO同目的地のまとめ乗り | 途中階の相乗り、同一昇降路の複数かご運行は未実装。車内人数は床密度から除外し、待機者だけ乗場の混雑に数える |
| MOVE-03 | **建設・UI接続済み**。連結モジュール、停止階、空車時延伸・撤去、BACK権限、魔力供給、停止/再開 | 通常初期予算から4停止階の建設を受入。工事中の新規乗車は完了まで保留 |
| MOVE-04 | **運行描画接続済み**。実かご、扉、Kenney乗客、待機表示。乗車中は徒歩側の重複表示を除外 | 施設ごとの専用アニメーション、混雑時の人物配置は改善を継続 |
| MOVE-05 | **基本異常系・保存検証済み**。満員、停止、延伸拒否、安全な降車、停留所閉塞、所有不整合、途中Saveの厳密再生 | 階段途中の保存、旧v8保存移行、待機/乗車中の再生を確認。全AIの長期大量需要と帰宅は継続 |
| MOVE-06 | **限定条件の比較済み**。同Seed・48人・480分・同一最短歩行距離で客用昇降機1台→2台。実Actorの総移動P95は224→73分、両方48人到着 | 固定需要の実移動比較であり自然来客AIではない。未完了0→0で離脱改善は未検証。途中階・夕方混雑・BACK物流等のS14条件は継続。[比較QA](qa/P2_STAIRS_AND_COMPARISON.md) |
| MOVE-07 | **実通勤接続済み**。同じ階の職場へ到着してから稼働。混雑端数、再配属、夜勤、運搬員出勤、Saveと旧論理配属の移行 | 帰宅経路と出退勤演出、移動設備改善による遅刻削減の対照試遊は未実施 |
## 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、停止 | 実状態に基づく歩行/待機/利用/睡眠/清掃/運搬/休憩の一覧と利用位置を確定する |
| LIFE-02 | **試作実装済み/専用素材未制作**。Kenney静止画の足スライス・上下動・左右反転。衣服の継ぎ目修正済み | 専用歩行・作業フレームを共通人物で確認し、縮小、拡大、混雑、職種識別を満たしてから展開 |
| LIFE-03 | **一部実装済み**。`pixel_tower_art.gd` の施設別家具、昼夜背景、世界樹の枝葉。現在の対象はMVP16施設 | 種類、営業、混雑、故障を家具と状態で識別できること。計画の施設数はMVP16種へ統一済み |
| LIFE-04 | **素材一部導入/音未接続**。Kenney Tiny Town/Tiny Dungeonの公式素材とCC0原文保存 | UI音・環境音をKenney優先で選定し、音量設定と頻発音の重複抑制を確認 |
| UX-01 | **一部実装済み・通常UI接続**。配置・掘削Preview、停止理由、待機・人員、継続配属、日次帳簿、有料仕入れ・厨房設定・配送理由 | 価格・営業方針の設定と、初見プレイヤーが各理由から対処できる導線を仕上げる |
| UX-01 | **一部実装済み・通常UI接続**。配置・掘削Preview、停止理由、待機・人員、継続配属、日次帳簿、有料仕入れ・厨房設定・配送理由 | 価格・営業方針も接続済み。初見プレイヤーが各理由から対処できる導線を試遊で確認する |
| UX-02 | **最小ガイド実装済み・単日確認**。実状態に応じる6段階、通常操作へのボタン、折り畳み、達成履歴・Save復元 | Day 1〜5解禁との整合、スキップ、複数失敗からの回復、初見30分で改善まで到達する試遊は残る |
| UX-03 | **一部実装済み/未接続**。ホイール、中ボタン、Home、キーボード開閉、Pixel・カメラ回帰 | 中ボタンなし・トラックパッド代替操作、日本語可読性、拡大時のドット、色以外の状態判別を実入力で確認 |
@@ -106,3 +118,9 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
2. MOVE-01〜03の階間経路と基本昇降機、MOVE-07の実通勤・到着後稼働を統合する。現在の論理配属で人物移動を完成扱いにしない。
3. PLAY-03/04の有料発注・厨房生産・実配送は接続済み。PLAY-05の価格・営業Policy・会計仕様を揃え、欠品・人員・経路の改善比較と初見試遊へ進む。
4. 通常開始と保存なし見学の両方で表示・操作を確認し、最小宿の成功をP1全体完成やWindows製品合格としない。供給機能の最新検証は [供給検証記録](qa/P1_SUPPLY_CHAIN.md) を参照。
営業設定と価格調整、旧v1とバイト一致するDigest軽量化を追加した。最新結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。過去の受付収入を含む数字は履歴であり、現行の収益バランスを示さない。
営業設定追加後の通常供給3営業日も49項目合格。受付売上0G、食堂3,000G・宿泊1,200G、給与未払0、残金2,895G。初日の契約金を除く2・3日目は各+715G。実装 `b3b82ef`。
P2の基本昇降機・実通勤の証跡は [P2_TRANSPORT.md](qa/P2_TRANSPORT.md)、階段・車内密度・48人比較は [P2_STAIRS_AND_COMPARISON.md](qa/P2_STAIRS_AND_COMPARISON.md)。自然来客の離脱とS14条件を含む対照試遊が残るためP2全体を合格とはしない。
+8 -4
View File
@@ -2,7 +2,7 @@
作成日: 2026-09-09
基準: The Tower SPを参考にしたドット絵の断面経営ゲーム。ローカル制作版を正本とする。
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。有料仕入れ・厨房・実配送を通常UIへ接続し、部品・UI・配送途中保存の検証は合格。通常予算からの供給込み3営業日も45項目合格。価格・営業Policy、性能と初見試遊は継続課題。
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。有料仕入れ・厨房・実配送を通常UIへ接続し、部品・UI・配送途中保存の検証は合格。通常予算からの供給込み3営業日も45項目合格。価格・営業Policyを通常UIへ接続し、基準料金と受付無料化、Digest互換の軽量化を追加した。検証は [営業設定記録](qa/P1_BUSINESS_MANAGEMENT.md) を参照。宿泊精算、長期描画性能、改善比較と初見試遊は継続課題。
## 1. 目指す体験と計画の前提
@@ -19,10 +19,10 @@
| 領域 | 確認できていること | 次に埋める差 |
|---|---|---|
| 外観・操作 | ドット断面、家具、Kenney人物の簡易歩行、状態表示、コンパクトUI、ズーム・パン | 専用動作、施設ごとの視認性、混雑・稼働の見せ方、実描画性能 |
| シミュレーション | 時間、建設、在庫・物流、経済、客AI、従業員、イベント、監査、保存の基盤 | 自律厨房生産・補充・配送と通常操作の接続。各Serviceの存在と日常運営の完成を区別 |
| 縦移動 | Path側にConnector・Queue等の部品が存在 | 階間の通常隣接経路抑制、建設との接続、昇降・乗降、保存復元の統合 |
| シミュレーション | 時間、建設、在庫・物流、経済、客AI、従業員、イベント、監査、保存の基盤 | 供給と営業Policyは通常操作へ接続。宿泊前払い・維持費・改善対照試遊を継続 |
| 縦移動 | 建設から共有かご、待機・乗降、実移動、停止、保存へ接続。昇降路の上下徒歩を抑制 | 全階間の規則、途中階相乗り、車内混雑密度の分離、同需要での改善比較 |
| 見学版 | 実施設7件と通路、従業員4人、自然来客が動く | 見学は食材32個を用意した保存なしの再現場面。通常ゲームの完成とは区別 |
| 運営UI | 建設・掘削・雇用候補・継続配属/勤務変更・施設情報・開業の手引き・日次帳簿・イベント選択・手動保存。通常初期予算で最小宿の単日成立と保存復元を確認 | 実通勤・到着後の稼働、仕入れ・在庫、価格・営業方針、保存枠、3営業日の継続運営 |
| 運営UI | 建設・掘削・雇用候補・継続配属/勤務変更・施設情報・開業の手引き・日次帳簿・イベント選択・手動保存。通常初期予算で最小宿の単日成立と保存復元を確認 | 実通勤・到着後の稼働、保存枠、宿泊精算、初見での継続運営 |
| 長期検証 | 24時間の統合検証、14日の運営境界比較等は実装記録あり | 全AIを含む20,160分の実Tick、各A/B比較、実描画を伴う負荷確認 |
| 制作管理 | P0完了。ローカル正本を基準コミット `423fd6d` と完全履歴bundleへ保存。別ディレクトリ復元、Godot読込、Pixel回帰238項目を確認し、復旧手順と課題台帳を整備 | 今後の統合ごとに検証済み基準点とバックアップを更新する。元Drive版との全内容照合は未完了のため復旧候補として保持 |
@@ -150,3 +150,7 @@ MVP後、試遊で残った課題と既存の製品仕様を照合して後半
6. **LIFE-01~04、UX-01~03**:専用動作と説明・音・日常操作を整え、初見30分の試遊へ渡す。
最初のレビューは「通常操作だけで初売上と翌朝の決算を迎える宿」。次のレビューは「3階の宿を客が昇降機で往復し、混雑を改善できる場面」とする。機能・見た目・操作を一緒に確かめ、以後の日程と素材制作量を更新する。
2026-09-09 営業設定追加後の通常3営業日は49項目合格。受付無料、食堂3,000G・宿泊1,200G、未払0、残金2,895Gで継続。価格操作・保存は接続済みとし、次はP2の実通勤と基本昇降機、P1の宿泊精算・改善比較・初見試遊を進める。
2026-09-09 P2の基本昇降機と実通勤を接続。通常初期予算で4停止階の建設と自然客の乗降を検証する。MOVE-01は昇降路内の抑制まで、MOVE-06の改善対照試験は未実施。詳細は [昇降機QA](qa/P2_TRANSPORT.md) とD-035を参照。
+12
View File
@@ -193,3 +193,15 @@ version 2では、ID形式、Access範囲、Upgrade件数、営業時間キー
| 拡張16施設 | 1 | 通常パレット未解放、順次移行 |
次の移行順は、一般客室・食堂・酒場・浴場、倉庫・警備、通路・昇降機、地下拡張施設とする。売上施設を先に移行すると、客AI・価格・在庫の縦断検証を早い段階で固定できる。
## 明示階段(D-036、2026-09-09)
基礎16施設と任意拡張16施設の定義順は保持し、追加インフラ2種を `data/facilities/infrastructure/` と `FacilityCatalog.INFRASTRUCTURE_FACILITY_PATHS` に分ける。通常Runtimeの登録数と建築パレットは基礎16+階段2の18種。既存Registryの既定ディレクトリ単独走査は基礎16のまま。
| ID | 表示 | サイズ | 設置層 | 建設G/資材/分 | 通行容量 | cost/維持魔力 |
|---|---|---:|---|---|---:|---|
| guest_stairs | 客用階段 | 1×1 | FRONT | 40/0/10 | 3 | 150/0 |
| service_stairs | 業務用階段 | 1×1 | BACK | 50/0/10 | 2 | 150/0 |
置くセルが上部踊り場で、同じx/layerのy-1へ接続する。下部足場が必要。業務用はstaff権限。旧保存の既設階段は施設定義へ置換せず、旧速度・権限を持つ別の接続所有記録として保存する。
+36 -5
View File
@@ -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営業日は別の完成条件として残る。
@@ -141,7 +143,7 @@
- 上部HUDに営業日、時刻、時間帯、来客、宿泊予定、所持金、Mana、資材、Faith、Heat、停止、x1/x2/x4を表示する。
- 実World Cell、占有、工事、施設、Guest、StaffをFRONT/BACK別に描く。ホイールでカーソル基準ズーム、中ボタンドラッグでパン、Homeで全体表示、Gで格子と実混雑表示を切り替える。
- PathServiceの密度/容量を緑・黄・赤の経路に、FacilityServiceの待機人数を小さなBadgeに表示する。施設クリックで右パネルを開き、状態、reason、待機列、Service、配置人員を確認する。
- MVP施設16種を選べる下部の横スクロール建築パレット、回転、配置Preview、失敗理由、建設Commandを接続。客用/業務用昇降機は安全な階間Topologyが未統合のため、現在は建設を拒否する。
- MVP施設16種と階段2種を選べる下部の横スクロール建築パレット、回転、配置Preview、失敗理由、建設Commandを接続。客用/業務用昇降機と明示階段は通常建設・実移動へ統合済み。
- 掘削モードでは費用、入口接続、支保、Rank/運営gate、進捗を表示し、FRONT/BACK同時解放Commandへ接続する。
- 雇用候補20人の氏名、役割、勤務帯、契約金、日給、4技能を表示。原子的な雇用、未払/破綻gate、二重クリック防止、予約実行結果、保存したCommand履歴との整合を扱う。その後のP1追加で、雇用済み人物の配属・再配属、DAY/NIGHTの継続勤務計画、未配属、反映予定と変更不可理由を通常UIへ接続した。配属先までの経路を検証するが、実通勤して到着してから稼働する経路は未統合。
- 本番運営の明示起動、個人AP、未払給与、前日損益、要確認/破綻、失敗境界の再試行表示、foreground Eventの日本語Choice、下部の手動Save/Loadを接続する。P1追加で6段階の「開業の手引き」と、営業日選択、現金入出金、建築出金、確定損益、給与・未払、施設別損益、照合を示す帳簿を接続した。建築出金と営業利益を分け、内部のcost_of_goodsは雇用契約金等を含むため「運営費」と表示する。
@@ -163,7 +165,7 @@
- 受付売上6,020G、全体営業利益6,040Gという現結果はバランス合格ではない。受付の会計上の役割、価格、宿泊料金の決済・売上記帳タイミングは仕様との差を調整する必要がある。
- 配属は繰返し計画をStaffService v4へ保存し、過去の勤務区間を保持してShiftを分割する。旧v3は計画なしで互換復元する。設計判断はD-032を参照。
- `make test-opening` で単日受入、`make capture-opening` で `artifacts/first-operating-day/{opening,staffed,first-close}.png` を生成する。自動受入は通常UI処理を呼び出すもので、初見プレイヤーの試遊合格とは区別する。
- P1全体は未合格。供給経路は下記へ追加した。価格・営業方針、正本との会計統一、初見プレイヤーの3営業日試遊は残る。配属は経路存在の事前検証と論理確定であり、人物位置を変えず、職場到着後の稼働はMOVEへ追加する。
- P1全体は未合格。供給経路は下記へ追加した。価格・営業方針は下記へ追加した。宿泊精算・維持費の会計統一、初見プレイヤーの3営業日試遊は残る。配属は経路存在の事前検証と論理確定であり、人物位置を変えず、職場到着後の稼働はMOVEへ追加する。
### P1追加:仕入れから食堂まで
@@ -189,7 +191,7 @@
- 全Actor AI、全Event、監査、経路移動を含む20,160分の実TickによるS14-CORE受入
- ユニーク2人の配置・接触判定と、そこから生成する14日Event列
- 通常隣接Edgeを安全に抑制する垂直Topologyと、客用/業務用昇降機
- 昇降機の途中階相乗り、同一昇降路の複数かご、自然来客・多階層混雑の改善比較
- 配置と同一Shiftから関係Event候補を生成する接触判定と事前リスクPreview
- 夕方混雑、FRONT/BACK比較、健全/地下収支を直接比較するScenario Test
- 100客・30従業員の実描画Frame試験
@@ -204,3 +206,32 @@
試遊の手順は `PLAYTEST_GUIDE.md`、仕様とTestの対応は `TEST_MATRIX.md` を参照する。各Systemのテストは画面Nodeに依存せずheadlessで実行でき、新しいSystemを追加する際はSnapshot、Atomic Restore、決定性Testを同じ変更に含める。
14日受入の共通Fixtureと数値境界は `MVP_ACCEPTANCE_SCENARIOS.md` に固定する。
## P1 営業設定とDigest軽量化(2026-09-09)
- 「営業」パネル、価格5段階、見積の固定、客の選択・満足への反映、休業と待機客の再判断、稼働中サービスの継続を接続した。厨房・物流は既存operator_openへ同期する。
- 新設受付0G/20分、客室120G、食堂25G/45分。旧施設の基準値と受付済み見積はD-034に従って保存互換を維持する。
- Snapshot全項目・履歴を保持したまま、Digestの呼出し内辞書キー再利用と型付き文字列配列を最適化。旧v1出力との一致を検証し、模擬履歴5,000件のSHA計算中央値は281.294→133.455msだった。
- 合格範囲、通常運営の再検証、残る精算・性能・試遊課題は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。この追加をP1全体や昇降機の完成とはしない。
新料金の供給込み3営業日は49項目合格。受付収入0G、食堂3,000G・宿泊1,200G、給与未払0・照合差0、残金2,895G。営業・休業・配送中の保存と再開、既存回帰も成功終了。実装コミット `b3b82ef`。
## P2 基本昇降機と実通勤(2026-09-09)
- 客用/業務用モジュールから共有かごと停止階を構築。待機、定員、乗降、階移動、停止/再開、魔力不足、保存再開をRuntimeへ接続した。
- 断面に実際のかごとKenney人物を表示する。完成した昇降機を選ぶと現在階・目的階・人数・待機・魔力と運行操作が出る。
- 継続配属は歩いて職場へ到着してから稼働する。運搬も同じ階のアクセス点で受渡しし、上下階越しの到着や受取を防ぐ。
- Path v4/Runtime v8。旧保存移行、乗車途中の復元、変更拒否の原子性を検証する。
- この保存点の詳細と実測は [昇降機QA](qa/P2_TRANSPORT.md)。全階間徒歩規則・車内密度・固定需要比較は次項のv9で追加した。P2全体の完成とは扱わない。
## P2 階段・車内密度と同需要比較(2026-09-09)
- 客用/業務用階段を通常建設・Kenneyアイコン・断面・選択詳細へ接続。新ゲームは階段か昇降機で階を移動し、上に普通の通路を置くだけでは移動できない。
- Runtime v9/Path v5。旧上下通路を一度だけ既設階段として保持する。階段途中の端数、旧乗車中の密度移行、撤去と巻戻しを保存へ接続する。
- 車内の人物を床密度から除外。昇降機詳細には最近の乗車記録の平均・P95待ちと現在の最長待ちを表示する。
- 同じ48人を480分流す実GuestRuntime比較では1台→2台で平均待ち105.60→23.58分、総移動P95 224→73分、両方48人到着。追加建設1500G・資材15・維持魔力5。2台側では動的な経路再選択で5人に迂回が発生し、その時間も含めた。
- 通常開業・供給の上階動線も明示階段に更新。自然来客の離脱、途中階相乗り、帰宅、S14の多条件比較は継続する。設定根拠はD-036、検証は [階段と比較QA](qa/P2_STAIRS_AND_COMPARISON.md)。
階段追加後の通常3営業日も49項目合格。食堂3000G・宿泊1200G、原材料配送30便・料理72便、残金2855G、3日とも未払0・照合済み。旧版の残金2895Gと比較すると新しい階段2セルの追加費用40Gを反映している。初日ガイドは実Pathで到達を判定し、描画・営業・保存再開41項目も成功。
+20
View File
@@ -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版は今回再配布していない。
+15 -5
View File
@@ -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席を表示。待機室は到着済みの非番従業員を室内に描画し、休憩人数を表示する。状態ラベルも実際の移動・到着に連動する。
+46 -14
View File
@@ -12,10 +12,13 @@
| エディター | `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出力 |
| 昇降機の乗降を試遊 | `make preview-transport` | 通常予算から4停止階を建設。自然に来た客の乗車場面で停止。保存なし |
| 階段・車内密度・旧保存の検証 | `make test-stairs` | 上下移動の規則、階段途中保存、互換移行、UIを検証 |
| 同需要の昇降機比較 | `make test-transport-comparison` | 同じ48人・480分で1台と2台を比較、全員traceを保存 |
| 通常開業の画面を出力 | `make capture-opening` | 同じ単日受入を描画し、開始・配属後・決算のPNGを生成 |
見学は実施設7件と通路、従業員4人をRuntimeコマンドで組み立て、食堂へ食材32個を用意した再現場面です。保存・読込・自動保存は無効で、通常の初期状態には反映しません。準備中は少し待ってから操作します。PNGの生成には描画可能なデスクトップ環境が必要です。
@@ -39,7 +42,7 @@
| 開業ガイドを折り畳む | マップ左上の「開業の手引き」の見出しをクリック |
| FRONT/BACK切替 | 下部の「客用・表層」「裏方・裏層」、または `Tab` |
| 一時停止/再開 | 上部の「停止/再開」、または `Space` |
| 速度変更 | 上部のx1/x2/x4、または `1`、`2`、`4` |
| 速度変更 | 上部のx1/x2/x3、または `1`、`2`、`3` |
| 拡大・縮小 | マップ上でホイール。カーソル付近を基準に拡縮 |
| 断面を移動 | マップ上で中ボタンドラッグ |
| 全体表示に戻す | `Home` |
@@ -56,7 +59,7 @@
4. `G`で格子と混雑を表示し、施設をクリックして右側の営業状態・待機・人員と照合します。
5. `Tab`でBACKの厨房を確認します。中ボタンドラッグとズームを試した後、`Home`で全体表示へ戻します。
この見学は収支・補充・配送の完成を保証する試験ではありません。昇降機の乗降は未実装で、見学の上下移動は既存の通路接続を使っています。
この見学は収支・補充・配送の完成を保証する試験ではありません。昇降機の実乗降を見る場合は `make preview-transport` を使います。
## 通常UIで最初の宿を開業する
@@ -65,33 +68,33 @@
次は単日受入と同じ小さな宿です。座標は `(x, y)`、すべてFRONTです。画面では `y=0` が地表の1F、`y=2` が3F、`y=3` が4Fに当たります。`G`で格子を出し、空きセルを選ぶと右パネルで座標を確認できます。配置するたびに停止し、完工を待つと進めやすくなります。
1. `B`で「受付」を選び、`(-8, 0)`へ配置します。受付は4×2セルを占有します。`Space`で再開して120ゲーム分進め、完成したら再び停止します。
2. 「一般客室」を `(-8, 2)` と `(-6, 2)` に1室ずつ配置します。完成した受付のすぐ上、左右に並ぶ2室です。同時に「客用通路」を `(-4, 1)` へ配置し、60ゲーム分進めます。
3. 「客用通路」を `(-4, 2)` へ配置し、10ゲーム分進めます。続いて客室の上側をつなぐように `(-8, 3)`、`(-7, 3)`、`(-6, 3)`、`(-5, 3)`、`(-4, 3)` へ置き、さらに10ゲーム分進めます。通路は合計7セルです。
2. 「一般客室」を `(-8, 2)` と `(-6, 2)` に1室ずつ配置します。完成した受付のすぐ上、左右に並ぶ2室です。同時に「客用階段」を `(-4, 1)` へ配置し、60ゲーム分進めます。
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` です。開始画面、配属後、翌朝の帳簿を比較できます。
@@ -137,3 +140,32 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
6. 食材は24時間、料理は12時間で期限切れになるため、翌営業日にも必要量を仕入れます。仕入れ費用・給与・食堂売上は「帳簿」に反映されます。
厨房の自動生産を停止すると追加の原料補給と調理が止まります。予約済みの配送と、すでに作った料理の食堂への出庫は続きます。在庫・運搬中の荷物・有効な生産計画が残る施設は解体できません。
## 料金と営業の試遊
`make preview-business` で、通常予算から建てた供給可能な宿を開く。Spaceで再開し、左「営業」から食堂の料金を変える。値上げ前に受付済みの客は元の見積額を払い、新しく検討する客には新料金が反映される。休業すると新規受付が止まり、待機客は別の施設を探す。すでに利用中の客はサービスを完了する。給与は休業中も発生する。
商品で仕入れ・厨房・配送、帳簿で00:00の給与と施設別利益を確認する。この試遊は保存なし。新設の標準料金は食堂25G・客室120G・受付無料。旧保存の既存施設は保存された基準料金を引き継ぐ。検証結果は [営業設定QA](qa/P1_BUSINESS_MANAGEMENT.md)。
## 昇降機と通勤の試遊
`make preview-transport` で、通常初期資源から建設した4停止階の宿を開く。検証と保存再開の確認後に一時停止して表示する。Spaceで再開し、客が扉の前で待ち、かごで上階へ移る様子を見る。完成した昇降機をクリックすると、現在階・人数・待機列と停止/再開の操作が出る。保存先は試験専用、通常の自動保存は無効。
新規ゲームでは、客用昇降機を同じx座標で上へ積み重ねると停止階を延ばせる。運行・待機中の延伸と撤去は拒否するため、空になってから着工する。工事中の新規乗車は完成まで待機する。通常の配属後は、従業員が同じ階の職場まで歩いてから施設が稼働する。
## 階段と昇降機を使う
上下階の移動には階段または昇降機を使います。階段は上の階へ置く1セルの施設です。同じxの一つ下のセルに通路・地表などの足場を先に用意します。客用は40G、業務用は50G、建設10分・資材と維持魔力は不要です。通常速度では1階を1.5ゲーム分で昇り降りし、業務用は従業員だけが使えます。
完成した昇降機をクリックすると、かごの現在階、人数、待機人数、運行の停止/再開が表示されます。最近の乗車記録の平均待ちと95%の待ち時間、現在の最長待ちも確認できます。平均・95%は保持中の乗車サンプルなので、詳しい集計範囲は表示のツールチップを確認してください。
以前のセーブの上下通路は、読み込むと「既設の階段」として同じ移動時間・利用権限で使えます。小さな階段マークをクリックして接続階を確認できます。その足場を撤去した後に新しい普通の通路を置いても階段は戻らないため、必要なら階段施設を建設します。
## 非番の休息と救護
非番の体力回復には、稼働中の裏層の待機室と到達経路が必要です。従業員は実際に移動してから休憩します。体力0の従業員には、医務室と医療職テッサを用意してください。患者と救護者は業務用EVの二人分の席を使用し、同じ便で乗降します。
[労務・同伴救護の検証](traceability/original/LABOR_COMPLETION_2026-09-29.md)
+7
View File
@@ -27,6 +27,7 @@ bundleはこの基準点までの完全なGit履歴を保持します。作成
|---|---|---|
| 通常開業ガイド・継続配属・単日決算 | `29a660a` | `the-tree-first-operating-day-2026-09-09.bundle` |
| 有料仕入れ・厨房・実配送・商品パネル | `627b200` | `the-tree-supply-chain-2026-09-09.bundle` |
| 価格・営業設定・受付無料化・Digest軽量化 | `b3b82ef`(先端は最終検証記録も含む) | `the-tree-business-management-2026-09-09.bundle` |
供給版bundleは実装後の最終検証記録まで含む。先端は `git bundle list-heads` で確認する。SHA-256は同名の `.bundle.sha256` ファイルに記録する。供給版の復元・試遊では、下の基準版bundleのファイル名を供給版へ置き換え、インポート後に `make test-supply` または `make preview-supply` を使う。3タブのPNGと検証ログはGit外の `artifacts/supply-chain/` にあり、bundleには含まれない。
@@ -102,3 +103,9 @@ make preview-pixel
- 復元先の `test_pixel_tower.gd` が **238項目合格**。カメラ、実施設クリック、停止、Simulation不変等の回帰。
この復旧確認では、全System試験、通常ゲームのセーブ上書き、Windows書き出し、復元先での目視見学は行っていません。`/tmp` の検証コピーは長期バックアップではなく、長期の復旧元は上表のbundleです。
営業設定版は `the-tree-business-management-2026-09-09.bundle` と同名 `.bundle.sha256` を使用する。`git bundle list-heads` の `HEAD` がこの保存点のコミット。復元後は `make check test-business`、試遊は `make preview-business`。画像・検証ログは `artifacts/business-management/` に別保管し、bundleへは含めない。
昇降機・実通勤版の実装コミットは `0f12c74`。`the-tree-transport-2026-09-09.bundle` と同名 `.bundle.sha256` を使用し、`git bundle list-heads` の `HEAD` で資料更新を含む最終保存点を確認する。復元後は `make check test-transport test-ui`、試遊は `make preview-transport`。Runtime v8/Path v4。検証結果は [P2昇降機QA](qa/P2_TRANSPORT.md)、画像とログは `artifacts/transport/` に保存し、bundleには含めない。
階段・車内密度・同需要比較版は `the-tree-stairs-2026-09-09.bundle` と同名 `.bundle.sha256` を使用する。保管先は同じ `/Users/korizatou114/Projects/the-tree-backups/`。`git bundle list-heads` の `HEAD` で最終保存点を確認する。Runtime v9/Path v5、基礎施設16+明示階段2。旧v8の上下通路と乗車中の密度を移行する。復元後は `make check test-transport`、数値比較は `make test-transport-comparison`、試遊は `make preview-transport` または `make preview-pixel`。検証記録は [P2階段と比較QA](qa/P2_STAIRS_AND_COMPARISON.md)。以前のbundleは上書きせず残す。
+50
View File
@@ -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失敗は修正前の検証履歴として残す。
+9
View File
@@ -104,3 +104,12 @@ System単体の合格と、ゲームとしてのMVP合格を混同しないた
- ヒロイン/ライバルの配置変更前に、接触・Shield・EventリスクPreviewが変化することを確認する。
- 100客、30従業員を表示した状態で基準PCの実Frame rateを測定する。
- 初見Playtestで地上/地下とFRONT/BACKの違いを30分以内に説明できるか観察する。
## P2 明示階段と車内混雑(Runtime v9/Path v5)
- `make test-stairs`: 全階間Path policy、transit密度、階段投影と下部足場、一回限りの旧通路移行、実移動端数と保存、占有中の撤去拒否、階段と待ち統計のUI。
- `make test-transport`: 上記に加え、既存の実かご・実通勤・工事勤務境界・自然4停止階の乗降、旧乗車中保存の密度移行を検証。
- `make test-transport-comparison`: 同Seed/同需要48人/480分で1台と2台を比較。Path+かご版と実GuestRuntime版を区別し、P95・全員の完了・実歩数・途中再生・設備費を記録。
- `make test-opening`/`make test-supply`: 上階動線を明示階段へ更新した通常初期予算の営業。Guideは実Path到達を使う。
- 条件・数値・限界は [P2階段と比較QA](qa/P2_STAIRS_AND_COMPARISON.md)。固定需要比較を自然来客の離脱改善やS14全条件の合格としない。
+62
View File
@@ -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基準機での長時間実測を完了したという意味ではない。狭い室内や長い列では全員を重ねて描かず人数表示にまとめる。施設ラベルは遠景で省略されるため、詳細確認は「営業階」または選択・拡大で行う。
+72
View File
@@ -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や通しデバッグ完了を新たに宣言するものではない。
@@ -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の改善実装完了を区別する。
+17 -5
View File
@@ -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操作中は選択肢を再構築しない。画面を閉じれば断面の観察へ戻る。
@@ -120,3 +120,15 @@ Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を
配送は施設名、品目数量、担当者、状態、待機理由を表示する。現在の配送を優先し、完了履歴は直近10件まで表示する。食堂未建築でも厨房への配送は表示する。帳簿・従業員等と同時に常設せず、Escで閉じて断面へ戻る。
実装: `scripts/ui/supply_management_panel.gd`。検証: `tests/ui/test_supply_management.gd`。詳細と画面は [供給検証記録](qa/P1_SUPPLY_CHAIN.md) を参照。
### 営業設定(P1)
左の「営業」は商品・勤務・帳簿と排他の管理パネル。施設を選び、価格5段階と営業状態を確定する。見積額、満足補正、受付済み価格の維持、休業時の待機/利用中の挙動、給与が続くことを表示する。受付や倉庫は開閉のみ。施設ごとの未確定入力は切替で保持する。Escで閉じる。
施設別の当日記帳は確定給与配賦を含む営業利益と区別し、00:00の帳簿へ誘導する。1280×720では既存の縦スクロールを使う。試遊は `make preview-business`、通常データの保存を更新せずSpaceで時間を再開できる。
## 従業員の休息・救護表示(2026-09-29)
体力と休息先への移動・到着、気絶後の救護待ち・迎え・搬送・治療を従業員パネルに表示する。待機室内の人物・休憩人数、医務室の患者、救護EVの2席は実際のRuntime状態から描画する。
@@ -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を読むコードを追加した」だけで完了にしない。
@@ -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項目の対応、依存先存在、循環なしを機械検証した。これは計画の整合性検証であり、ゲーム実装の合格ではない。
@@ -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の必要資産数確定、最初の縦断実装の実績で再レビューする。
@@ -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全項目、原本全実装は未完了。
@@ -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.
@@ -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チェックで別に検証。
@@ -0,0 +1,10 @@
# アンリの通常加入・料金補正に関するユーザー決定
今回の会話でユーザーが以下を明示承認した。
1. 「従業員画面で無料加入を選ぶ」。新規ゲーム開始時の自動在籍や未指定イベント条件に置き換えない。
2. 「利用料金を20%増やし、客の支払額と施設収入を一致させる」。架空の追加収益や補助金として20%を生成しない。
原本の配置フロア全施設への効果、雇用/維持費無料、解雇売却不可は維持する。加入処理、画面、配属、料金見積もり、財布/台帳、途中保存の接続は未完了。この文書は実装完了を示さない。
接続時の既存コード課題: staff_hire_payload と雇用済みID復元検査は一般候補のみを受け付ける。雇用後検査が FREE_HIRE 固定。候補UIと管理UIの表示名参照も一般候補のみ。アンリの innkeeper 職種と施設の required_roles の整合を明示し、一般職の偽装で代用しない。保存マニフェストの通常候補20件とユニークの別ID一覧を維持して、雇用済み集合の解釈を拡張する必要がある。
@@ -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`。
@@ -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.
@@ -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.
@@ -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 に効いていたとは報告しない。
@@ -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同一ビルド未検証。
@@ -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.
@@ -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
@@ -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.
@@ -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.
@@ -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.
@@ -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実機や長期営業、すべての建設/撤去/勤務交代の組合せを受入済みとはしない。清掃専用モーション、満足度/汚染伝播、原本の他の残件は継続中。
@@ -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件の証拠は前のソースに対するもので、今回は変更対象の関連試験と通し再検証を実施した。
@@ -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実機、性能予算の完了を意味しない。
@@ -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` を参照。上記の「未実装」は基礎モデル段階の記録として保持する。
@@ -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ネイティブ、全原本、性能予算、長期プレイの合格を示すものではない。
@@ -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固定の全件合格とは扱わない。
@@ -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完了とは判定しない。
@@ -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.
@@ -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.
@@ -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`へ保全。清掃員室の登録と一般客室・上級客室・従業員寮のゾーン修正を現行定義で再取得した。全施設一覧への入口と定義値の監査であり、登録数を完成数とは扱わない。
@@ -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。
@@ -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。
@@ -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.
@@ -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も保全している。
@@ -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.
@@ -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実機、性能予算、長期プレイを合格とは扱わない。
@@ -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参照。

Some files were not shown because too many files have changed in this diff Show More