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.
7.9 KiB
維持費の実装記録(2026-09-29)
状態:P05は進行中。通常営業・旧06:00決算移行・インスペクターを接続。日額0.5%の初期バランスをユーザーが選択し、3営業日試験は49項目PASS。原本全実装の完了報告ではない。
確定仕様と原本
原本 docs/traceability/original/BASELINE.txt 70–72行(00:00決算と維持費)、188行(支出)。ユーザー回答「保有時間で按分・不足分繰越(推奨)」を upkeep-policy.json に記録した。
完成時点から撤去時点までの保有時間を対象にする。閉店・休止中も対象。接客施設だけでなく、完成済みの通路等の設備も対象。建設中は対象外。
日額 × 保有分数を整数で保持し、1440で割った整数Gを精算する。端数は次の精算に持ち越す。未払いでも費用を認識し、支払可能額との差を債務として保持する。撤去後も既発生の費用・債務・端数を消さない。
通常の00:00決算では既存の給与支払いを先に実行し、残金から施設ID順に維持費を支払う。旧版の移行中は維持費を00:00に支払い、元の給与精算は06:00に保持する。これは実装上の優先順であり、原本に明記された細則ではない。
実装経路
| 対象 | 内容 |
|---|---|
| FacilityUpkeepAccrual | 分単位の正確な計上、日跨ぎ、履歴、版付き保存 |
| FacilityUpkeepSettlement | 費用・未払・現金の複式記帳、再送の重複防止、端数・未払い繰越 |
| SimulationRuntime | コマンド・建設完了より前に前分の保有時間を計上。日次決算で精算し、施設別損益へ反映 |
| Runtime保存 v10 | v1–v9は読み込み時刻から計上開始。台帳・精算証憑・計上履歴の照合。不正保存は既存状態を変えず拒否 |
| 決算ロールバック | 精算後に費目判定等が失敗しても、帳簿・現金・給与・維持費の証憑をまとめて復元 |
| OperatingLedgerPanel | 維持費の現金支払と未払いを表示。営業損益の維持費と区別 |
毎分の未払い照合で精算履歴全体を複製しない読み取りAPIを設けた。性能改善の測定結果としてはまだ扱わない。
原子受入項目
| ID | 条件 | 主な証拠 |
|---|---|---|
| UPK-01 | 建設中はゼロ、完成した瞬間までの時間を遡って請求しない | test_upkeep_construction_boundaries |
| UPK-02 | 完成済み施設・通路の保有分数を計上 | 同上、test_runtime_upkeep |
| UPK-03 | 閉店・休止でも計上し、撤去後は増えない | test_runtime_upkeep、計上サービス試験。休業UI・別プロセス復元は test_upkeep_closed_ui(操作処理を経由) |
| UPK-04 | 00:00に費用と支払を別の台帳行で記録 | test_runtime_upkeep |
| UPK-05 | 未払いでも費用を損益に反映し、未払い合計に算入 | test_runtime_upkeep |
| UPK-06 | 前日の未払いを翌日に支払い、返済を費用として二重計上しない | test_facility_upkeep_settlement、test_runtime_upkeep(翌日00:00返済、二重費用なし、保存復元) |
| UPK-07 | 撤去しても過去の費用と未払いを維持 | test_facility_upkeep_settlement、test_runtime_upkeep |
| UPK-08 | 端数を失わず、分刻みと一括計算が一致 | test_facility_upkeep_accrual |
| UPK-09 | 同一精算の再送で二重請求しない | test_facility_upkeep_settlement、保存再開試験 |
| UPK-10 | 23:59/00:00の保存復元が一致 | test_runtime_upkeep |
| UPK-11 | 旧保存へ過去の費用を遡及請求しない | test_runtime_upkeep、移行試験 |
| UPK-12 | 精算後の異常で関連状態を原子的に復元 | test_runtime_upkeep |
| UPK-13 | 帳簿表示が実際の支払・未払いに一致 | test_runtime_upkeep(Control生成) |
| UPK-14 | 維持費を含む3連続赤字の通常Tick終了 | test_upkeep_loss_streak:15項目PASS(通常建設、3日精算、終了直前/直後の保存) |
| UPK-15 | 旧06:00帳簿を保持して維持費を00:00精算 | test_upkeep_legacy_midnight:23項目PASS。巻き戻し・再試行・中間債務の投資制限も検証 |
| UPK-16 | 施設インスペクターの日額・精算前・未払い | test_upkeep_inspector:実描画7項目PASS、画像確認済み |
検証の扱い
ログは artifacts/upkeep-2026-09-29/ に保存する。全体試験の初回失敗ログを残し、修正後は recheck-*.log に分ける。初回に旧版番号の期待値で失敗したことを隠さない。
単体:計上38、精算51項目。結合:通常Tick/保存/未払い/翌日返済/ロールバック40、通常建設・撤去17項目。既存:Runtime決算51、14日受入46、コンテンツ108、設備162項目のPASSを観測した。全体回帰の初回93本は実装中の変更をまたぐ探索実行であり、同一ソース凍結版の証拠とは扱わない。初回の旧版期待値3件は修正後にPASS、物流の600秒打切りは1800秒上限で再試験し796.36秒・49項目PASS。その後の関連10本も全PASS。承認済み0.5%の3営業日試験も790.60秒・49項目PASS。
残件・制限
- 旧06:00決算の移行対応を実装済み。00:00の独立した原子的境界で維持費を精算し、06:00では確定済み支払を再実行しない。Coordinatorの確定決算債務とRuntimeの現在債務を区別し、新しい未払いがあれば直ちに投資を止める。関連10本と3連続赤字15項目の回帰はPASS。
- ユーザー回答「0.5%案を初期値として試験・調整する」を受け、通常登録19施設へ
ceil(建築費G × 0.005)、最低1G/日を明示設定した。比較表と採用値はupkeep-rate-proposals.json。これは承認済みの初期バランスであり、原本記載値と混同しない。未登録の拡張定義は今回は変更していない。 - 建設・休業設定・決算・ディスク保存・別プロセス起動後の読込は、実描画付き29項目PASS。UIの操作処理を呼び出す試験であり、マウスによる通し操作や破壊・摘発での休止を同じシナリオでは検証していない。翌日返済は通常Tick・保存復元でPASS(入金は建設費返金の制御した帳簿フィクスチャであり、自然売上試験とは区別)。インスペクターの実描画と維持費による3連続赤字終了は検証済み。
- 同一ソースの全体回帰を frozen-regression/ に開始。実測の性能検証とWindowsビルド確認は別途継続する。
- P05の借金・税、他の作業パッケージはこの変更で完了した扱いにしない。
0.5%初期値の3営業日試験結果
通常の開始資金5,000Gから建設・雇用・仕入れ・自然来客・宿泊・物流・途中保存復元を行い、49項目PASS。維持費のない比較試験と食事売上3,000G・宿泊売上1,200G・配送数は一致した。
維持費合計50Gを支払い、未払い0G。最終資金は比較試験2,855Gから2,805Gへ50G減少し、支払額と一致。精算証憑・整数按分と端数繰越・費用台帳・3日分の損益を compare_upkeep_trial.py で照合し全項目PASS。詳細は artifacts/upkeep-2026-09-29/rate-0-5-percent-reconciliation.json。
この配置・シードの3営業日では資金不足にならないため、0.5%の初期値を維持する。長期バランス、別の施設構成、Windows実機の受入まで合格したとは扱わない。
営業設定の説明へ、休業中も施設維持費が発生することを追加。tools/run_upkeep_ui_flow.py で保存側と読込側を別のGodotプロセスとして起動でき、make test-ui に組み込んだ。証拠: closed-ui-process-flow/result.json と closed-ui-read.png。初回の試験失敗(配置ゾーンと保存操作履歴の比較条件)もログを保持している。