TheTree_mock/docs/plans/original-completion-2026-09-29/execution/MANA_INTEGRATION.md

P06 マナ枯渇・全館停止の実行準備

2026-09-29。状態: 全館停止のRuntime接続と停電境界試験をローカル制作コピーへ反映済み。反映後の関連7本とmake checkがPASS。以下の準備時記録より末尾の進捗を優先する。原本全実装完了ではない。

実証した差異

原本B-9.1はマナ枯渇で全館機能停止を要求する。artifacts/mana-2026-09-29/probe_zero_reserve.gd は通常建設コマンドで受付を完成させ、その後に診断用として残量だけを0へ変更して時計を進める。490分時点で残量0、施設power_available=true、マナ網のgeneration=100、allocated=1を観測した。人員不足で受付そのものは未稼働だが、必要な電力停止条件が成立していない。これは診断フィクスチャであり、通常プレイの受入結果とは区別する。

証拠: artifacts/mana-2026-09-29/zero-reserve-probe.json と .log。

既存処理と接続先

• GameStateのmanaは初期100の所持資源。ManaNetworkServiceの初期供給源は出力100で別管理。Runtimeの施設配電は10分周期の網評価でのみ変わり、所持マナ0を参照しない。
• _advance_mana はstate_changesに現れた施設だけpower_availableを更新する。全館停止は差分の有無や施設の消費量0に左右されてはならない。
• FacilityServiceはpower_available=falseで開始済みサービスを一時停止し、復帰時の再開処理を持つ。破壊・摘発のsuspension_reasonは独立して保持する必要がある。
• KitchenProductionServiceはNO_POWER判定済み。枯渇がこのフラグへ届くこと、途中バッチと材料の所有権が保たれることを検証する。
• _advance_elevators は各モジュールの網状態を参照する。全館停止とのAND条件が必要。ElevatorService.set_poweredには最寄り有効停止階への退避と、有効停止階がない場合の保持処理が既存。新たなテレポート規則を作らずこの契約を使う。
• _operations_arrival_boundary は現在人口上限だけを捕捉する。停止時の入館抑止は決定的な境界として接続し、客IDや乱数の二重消費を防ぐ。
• _advance_inventory_and_logistics は期限切れと配送を毎分進める。停電で時間・腐敗・費用を止めず、新規配送と搬送中荷物、救護同伴の扱いを分ける。

原子受入と実装順

ID	条件	現状
MNA-01	供給・消費・余剰・不足が整数で一致し、負残量を作らない	残量コンポーネント33項目PASS。施設別需要の集計/Runtime接続は残
MNA-02	残量0なら消費0の施設を含め全館停止	差異再現済み
MNA-03	既存サービス・厨房の進捗/課金/材料が停止し再開で重複しない	接続未検証
MNA-04	EV乗客・救護同伴者が安全な階へ戻るか保持され、所有権が消えない	網停電の既存処理あり、全館接続未実装
MNA-05	停止中の入館・新規物流を抑止し、在庫期限・時計・経費は進む	未実装
MNA-06	復旧しても破壊・摘発の休止を解除しない	既存状態分離あり、全館接続未検証
MNA-07	枯渇直前/直後/復旧直前の保存復元が一致	未実装
MNA-08	旧保存の残量を保全し、過去の消費を遡及適用しない	v11移行設計が必要
MNA-09	HUDで残量・供給/消費・停止理由・復旧条件が分かる	未実装
MNA-10	通常営業で自然に枯渇・復旧し、Windows配布版で再現	未検証

数値非依存の残量計算・保存契約を実装した。次はRuntimeへ順次接続する。GameStateと専用サービスに残量を二重保持するなら照合を必須とし、どちらを正とするか曖昧にしない。新しい停止理由・更新順・移行はP03/P04にも記録する。

未指定値

D04の局所確認として、初期100・上限100・10分ごと世界樹供給5・既存maintenance_manaを同周期消費する試験開始案をユーザーへ質問した。未回答。確定値・原本記載値として本番へ適用しない。稼働中の消費条件、全館停止中は供給を蓄積して復旧可能にすること、同一境界で消費と再開を繰り返さないことを計算契約の試験対象にする。

残量コンポーネントの実装

scripts/mana/mana_reserve_balance.gd はレートや周期を決めず、呼出側から各区間の供給総量・需要総量を受け取る。供給を需要へ使用した後の余剰を容量まで蓄積し、供給不足と容量超過を別々に返す。保存には容量・残量・時刻・最後の収支を保持し、収支不一致や未知フィールドは拒否する。失敗時に既存状態を変更しない。同一時刻・同一入力は再送扱い、同一時刻で異なる入力は拒否。

保存版1のコンポーネント試験 tests/s2/test_mana_reserve_balance.gd は33項目PASS。証拠は artifacts/mana-2026-09-29/reserve-balance.log。供給を先に容量で切り捨てると同一区間の需要に使えるマナを失うため、需要充足→余剰蓄積の順を採用した。これは計算契約であり、原本明示値として扱わない。

まだRuntimeから呼ばれていないため、MNA-02の不具合は未修正。本番供給量・消費間隔は未決定。既存の維持費回帰対象240ファイルは変更していないが、この新規コンポーネント2ファイルはその回帰には含まれず、別の上記試験で検証した。

全館給電条件の反映コンポーネント

scripts/mana/mana_power_projection.gd を追加。残量>0と網のACTIVE/DEGRADEDをANDで判定し、消費者ノードを持たない無消費施設にも残量0を適用する。施設の営業方針・耐久・依存先・休止理由には書き込まない。供給不足の理由だけを更新し、変化がなければ状態更新を繰り返さない。

tests/s2/test_mana_power_projection.gd は実FacilityService/ManaNetworkServiceを使って14項目PASS。残量0の全施設停止、消費0の停止、摘発休止の維持、手動閉店の維持、部分給電、復元後の復旧、負数入力拒否を確認した。初回に試験定数名がGodot組み込みProjectionと衝突し、修正後にPASS。ログ power-projection.log と power-projection-recheck.log を保持。

Runtimeへの接続は未完了で、通常プレイの残量0不具合はまだ解消していない。接続時には全ての正消費施設を先にマナ網へ登録すること、電力フラグの正本をこの投影処理に統一することが必要。呼出中の外部コールバック失敗はRuntimeの既存トランザクションに含めて扱う。EV・入館・物流の停止はこの施設フラグだけで完了扱いにしない。

Runtime接続の作業用コピー

固定ソース回帰を混在させないため、mana-staging.json の作業用コピーで実Runtimeへ接続した。毎分の施設給電、無消費施設の停止、EV給電、新規入館の上限0、新規補給生成の抑止、開始直前の残量確認、完成直後の停電反映を追加。物流の搬出/搬入可否へpower_availableを接続し、期限切れ処理と搬送中荷物の所有権は保持する。

test_runtime_mana_depletion.gd 15項目PASS。通常建設した受付と一般客室を使い、10分周期の外でも残量0で停止すること、全Runtime保存復元、供給回復後の破壊休止維持を確認した。残量の変更は診断入力であり、自然な消費・回復のバランス試験ではない。

初回に建設完了から最初の配電評価までの既存契約を変えて営業回帰が失敗した。未評価ノードの既存状態を保持し、残量0だけは必ず優先する修正後、既存営業循環52項目がPASS。営業と物流の関連試験もPASSし、EV回帰は継続中。詳細は作業用コピーの mana-validation-recheck/results.json。制作コピーへの反映は未実施。パッチは artifacts/mana-2026-09-29/staged-runtime/runtime-integration.patch。

次の受入は、実乗車中のEV枯渇、利用中サービスの課金/一時停止、荷物搬送中の停電。数値未回答を理由にこれらを省略しない。新しい有限残量計算コンポーネントの周期・供給・消費への接続と保存契約も未完了。

停電境界の追加受入（作業用コピー）

• 接客循環58項目PASS。利用中の停電で5分間の進捗と財布・材料所有数を保持し、停電保存を復元後、配電評価と接客完了を待って25Gを一度だけ課金した。最初の試験は未評価ノードの復旧を3分後と仮定して失敗。既存の10分配電境界を待つ試験へ修正しPASS。初回失敗ログも保存している。
• 物流109項目PASS。積載済み8個を停電中30分保持し、納入0、保存復元と所有権照合を確認。復旧後に一度だけ納入して積荷0・納入先8となる。
• EV37項目PASS。実乗車中に残量を0へ変更し、有効停止階への緊急到着イベントが各乗客に一度だけ発生すること、経路要求の解消、停電保存復元と再給電を確認した。救護同伴者や有効停止階なしの全館停電は別途残る。

証拠: artifacts/mana-2026-09-29/staged-runtime/outage-validation.json と同階層のログ。残量変更のみ診断入力であり、自然な消費・回復ではない。本番の供給量・消費間隔は未回答で適用していない。P06全体、画面・配布版受入の完了を意味しない。

更新順の確認（P04連携）

SimulationKernelの順序はコマンド→時刻境界→MANA→建設→物流→施設完了→生体/環境→事件→施設待機列→AI→公開保存。施設完了でサービス、続いて厨房を更新する。AIでEV、その後救護を更新する。したがってMANAで給電を確定してから同じ分の物流・接客・生産・EVへ適用される。建設はMANAの後なので、新規完成施設にも残量0を登録時に反映する。入館境界は施設状態の更新待ちにせず残量を直接確認する。

停止・復旧は給電条件のみを更新し、破壊/摘発の休止理由を解除しない。毎分判定しても給電と減力理由が変わらない施設は状態更新を発行しない。既存の障害復旧suffixも同じMANA→建設→物流→施設の順序を呼ぶ。残量計算を将来MANAへ接続する際は、供給/消費の確定をこの給電投影より前に置く必要がある。まだ未接続なのでこの記録を有限残量収支の受入完了とはしない。

ローカル制作コピーへの反映

維持費の固定ソース回帰98本が終了。240ファイルのSHAが開始時と一致した。97本は初回PASS、営業管理UIの説明文期待値だけ1件失敗し、「給与と施設維持費」へ更新した試験を本体で再実行して60項目PASS。初回結果は上書きせず artifacts/upkeep-2026-09-29/frozen-regression/final-gate.json に再試験と併記。

その後、作業用コピーの8対象ファイルについて本体の変更前SHAと候補SHAを照合して反映した（UI期待値修正1、マナ対応7）。mana-staging.json のproduction_applied=trueを参照。現在の本体は既存の98本回帰時から変更されているため、あの98本をマナ統合後の全体PASSとは扱わない。反映後の部品/Runtime/接客/積荷/EV/性能試験とmake checkは artifacts/mana-2026-09-29/production-integration へ記録する。

反映後の7本は全PASS、make checkも終了コード0。部品33/14、Runtime15、接客58、物流109、EV37項目を再確認し、性能回帰もPASS。対象8ファイルのSHAが作業用コピーの検証済み候補と一致することを確認した。未完了条件は前述のとおり。

厨房・救護同伴・HUDの追加受入

制作コピーで追加検証。厨房は通常建設と購入配送済み8個の食材、雇用・配置した調理職員を使用。調理3分の時点で残量を0にし、30分の停電中にバッチID・予約・進捗が不変、原料8/完成品0、完全保存復元後の復旧で原料4/完成品4となることを確認した。物流試験全体121項目PASS。

救護同伴の実乗車中に残量を0にし、職員と患者が同じ有効停止階へ退避。20分停止しても患者は未治療で位置保持、完全保存復元が一致。給電回復後は同じ患者の救護・治療が完了し、所有権の不整合なし。救護EV試験全体30項目PASS。患者の体調とマナ0は診断入力であり自然発症/自然枯渇ではない。

HUDは残量0を「マナ 0・停止」と警告色で表示。ツールチップで停止範囲、残量と配電の回復、破壊・摘発の休止は解除されないことを説明。復旧で通常表示・元のテーマ色へ戻る。実描画のダッシュボード131項目PASS、outage-hud.pngを目視確認。サービス直呼びの代用画面ではなく本番シーンだが、OSのポインター操作/Windows受入は未実施。

証拠: artifacts/mana-2026-09-29/kitchen-rescue-ui-validation.json。有限残量の自動収支/供給・消費表示/旧保存への新収支モデル移行/通常営業での自然枯渇復旧は未完了。有効停止階が全て失われた場合の停電受入も残る。

有効停止階なしの停電（Runtime境界）

test_runtime_transport.gd に実乗車中の全停止階封鎖→残量0の受入を追加。安全な降車先がない間は乗車状態と経路所有権を保持し、20分経過しても残り移動時間を進めない。全Runtimeの保存復元が完全一致することを確認する。その後、停止階の封鎖と停電を解除して移動を再開し、乗車要求と経路要求が残らず、復旧後も保存できることを確認する。これは交通障害と残量の診断入力を用いるRuntime試験であり、通常プレイの自然枯渇を証明しない。結果は artifacts/mana-2026-09-29/no-landing-outage.log を参照。

旧保存の残量0境界

維持費導入前のv9形式フィクスチャ（新規建設後、旧形式への変換とupkeep項目の除去）を使用。残量0・古い給電フラグありの状態を読込し、入力セーブを変更せず残量/時刻/停止を保全。読込以前の維持費を課さず、最初のTick前でも新規入館の許容数は0。再開後はMANAがサービス・物流・EVより先に古い給電状態を停止へ反映する。負のマナを入れた破損保存は現在の完全スナップショットを変えず拒否した。Runtimeマナ試験21項目PASS。

注意: 古い給電フラグそのものは停止中の読込直後に書き換えず、次のTickで更新する。即時正規化した保存への移行や、新たな有限マナ収支モデルの移行まで検証したわけではない。証拠 artifacts/mana-2026-09-29/legacy-zero-save-validation.json。