Files
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

7.9 KiB
Raw Permalink Blame History

維持費の実装記録(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。初回の試験失敗(配置ゾーンと保存操作履歴の比較条件)もログを保持している。