# 維持費の実装記録（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。

## 残件・制限

1. 旧06:00決算の移行対応を実装済み。00:00の独立した原子的境界で維持費を精算し、06:00では確定済み支払を再実行しない。Coordinatorの確定決算債務とRuntimeの現在債務を区別し、新しい未払いがあれば直ちに投資を止める。関連10本と3連続赤字15項目の回帰はPASS。
2. ユーザー回答「0.5%案を初期値として試験・調整する」を受け、通常登録19施設へ `ceil(建築費G × 0.005)`、最低1G/日を明示設定した。比較表と採用値は `upkeep-rate-proposals.json`。これは承認済みの初期バランスであり、原本記載値と混同しない。未登録の拡張定義は今回は変更していない。
3. 建設・休業設定・決算・ディスク保存・別プロセス起動後の読込は、実描画付き29項目PASS。UIの操作処理を呼び出す試験であり、マウスによる通し操作や破壊・摘発での休止を同じシナリオでは検証していない。翌日返済は通常Tick・保存復元でPASS（入金は建設費返金の制御した帳簿フィクスチャであり、自然売上試験とは区別）。インスペクターの実描画と維持費による3連続赤字終了は検証済み。
4. 同一ソースの全体回帰を frozen-regression/ に開始。実測の性能検証とWindowsビルド確認は別途継続する。
5. 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`。初回の試験失敗（配置ゾーンと保存操作履歴の比較条件）もログを保持している。