Takeshi
5dde0c5ec2
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.
5.4 KiB
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.