MP-01-r02: 承認用マナ契約候補の作成（原88成果の完了ではない）

docs/plans/original-completion-2026-10-02/execution/mana-proposal/PROPOSAL.md

@@ -0,0 +1,81 @@
+# 未承認・製品未反映：MP-01 マナ契約候補
+
+承認用の候補案です。P06-01の受入や原88成果の完了を意味せず、分母にも加えません。製品・人物・資源・仕様原本・台帳は変更していません。正式試験と別セッションレビューはRunnerが実施します。
+
+## 根拠と区別
+
+原本 `docs/traceability/original/BASELINE.txt` 9.1は枯渇時の全館停止、10.6はマナ炉6×3・裏地下・奴隷消費を規定します。6.1/6.5の代替不可能・解雇売却不可・原則ロストしない人物は投入から除外します。数値、容量、生成周期、炉の収率は原本にありません。
+
+現実装 `autoload/game_state.gd` の初期mana=100は残量です。`autoload/simulation_runtime.gd` のSTARTER_MANA_OUTPUT=100はネットワーク供給能力であり、100 Mana/10分という承認済み生成率ではありません。`maintenance_mana` は完成施設のconsumer需要に登録され、`mana_network_service.gd` の10ゲーム分周期で配電されます。これは現時点で残量から差し引く維持エネルギーではありません。ネットワークの優先配電・75%の縮退・10分の停止保持と、全館のreserve>0ゲートは別です。Runtimeの定期マナ更新はネットワーク評価と電力投影であり、有限残量helperの定期生成消費接続ではありません。
+
+`tests/s2/test_mana_reserve_balance.gd` の残量7・容量10・時刻360、時刻370の生成5・需要8→残量4は試験入力です。承認済み製品値ではなく、今回その試験を実行していません。現sourceの生バイトSHA256はJSONのsource_pins辞書（リポジトリ相対path→SHA256）、区分は別のsource_provenanceに記録しました。候補の来歴はcandidate、原本・実装・fixtureと区別しています。
+
+## 承認する候補範囲
+
+| 案 | 初期Mana | 容量Mana | 世界樹生成Mana/10ゲーム分 |
+|---|---:|---:|---:|
+| 推薦 | 100 | 300 | 20 |
+| 慎重 | 100 | 200 | 10 |
+| 余裕 | 200 | 600 | 40 |
+
+全て未承認です。推薦は現初期残量100を維持する候補であり、100を原本値と主張しません。容量300は初期の3倍の有限バッファ、生成20は下記の通常需要16を4だけ上回り、全定義一基ずつの需要63には足りない設計上の選択です。周期10は現配電評価境界への整合を理由に提案します。全ゲームのバランス保証ではありません。
+
+換算案は各完成・保有施設のmaintenance_manaを1周期のMana消費量とし、D=Σ(基数×定義値)とします。閉店・停止中も維持需要を計上し、枯渇による需要免除と無償復帰の振動を避けます。撤去・破壊済みは除外します。金維持費の承認A01と同一契約ではなく、別途承認するマナ案です。Manaは整数、時刻はゲーム内分、初回は初期時刻360から370までの一周期です。現実時間10秒=ゲーム内1時間との関係を生成量へ重複換算しません。
+
+B=直前残量、C=容量、G=その周期の世界樹生成、F=確定した炉生成、D=需要。
+
+- available=B+G+F
+- consumed=min(available,D)
+- shortage=D-consumed
+- overflow=max(0,available-consumed-C)
+- after=min(C,available-consumed)
+
+需要を賄ってから余剰を蓄積し、超過は明記して破棄します。after=0では需要ゼロ施設も含め全館停止。供給そのものは停止館外の世界樹から復帰可能とし、次の境界でafter>0かつ局所配電条件成立の場合だけ再開します。ネットワークstorageと残量を二重計上しません。ネットワーク供給100をGとして足すこともしません。供給能力・局所切断と残量の二つのゲートを保ちます。
+
+## 需要と計算比較
+
+JSONはdata/facilities配下の全37定義を列挙します。chapel、cleaning_room、general_store、infirmaryの4施設はmaintenance_mana省略のため、scripts/data/facility_definition.gdのFacilityDefinitionの現default=0を根拠に0と明示し、未定義施設のunknownとは区別します。各行のpath・definition_id・observed_maintenance_manaを入力に、全定義一基ずつの合計は63です。定義の存在を通常登録・稼働とみなしません。
+
+歴史監査CURRENT_FACILITY_AUDIT.mdにある対応定義なし13施設（VIPスイート、ドミトリー、レストラン、屋台、カジノ、闘技場、高級ソープ、SM拷問室、覗き部屋、地下牢、マナ炉、ワープ、魔法砲台）は需要unknownです。魔力制御室3×2は原本マナ炉6×3の代替ではありません。現在の定義一覧と歴史監査の登録数も混同しません。
+
+比較は候補式の計算のみです。F=0、初期時刻360、10分刻み。低負荷D=2（食堂一基）、通常D=16（食堂・厨房・大浴場・客EV・受付・警備員詰所各一基）、需要超過D=63（全37定義各一基）を120分計算します。zero・capacityは10分、供給喪失復帰は30分。全入力、各周期結果、shortage/overflowはJSONに保存しています。
+
+| 条件 | 推薦の結果 | 慎重の結果 | 余裕の結果 |
+|---|---:|---:|---:|
+| 低負荷120分 | 300 Mana | 196 Mana | 600 Mana |
+| 通常120分 | 148 Mana | 28 Mana | 488 Mana |
+| 需要超過120分 | 0 Mana | 0 Mana | 0 Mana |
+| 初期0・通常需要10分 | 4 Mana | 0 Mana | 24 Mana |
+| 初期満容量・低負荷10分 | 300 Mana | 200 Mana | 600 Mana |
+| 生成0→0→通常・需要16、30分 | 72 Mana | 62 Mana | 192 Mana |
+| 通常10分後、同分再送 | 104 Mana | 94 Mana | 224 Mana |
+
+推薦の需要超過は100→57→14→0、3周期目にshortage29、その後は毎周期shortage43。通常は100+12×(20−16)=148。供給喪失復帰は100→84→68→72。初期0は生成20−需要16=4で次境界復帰、慎重案は生成10でshortage6、停止を維持します。満容量では需要を支払った余剰のみoverflow。余裕案のB=200、G=40、D=63では8周期後が200−8×23=16、9周期目は16+40=56に対し需要63でshortage7、初めて0になります（時刻450）。12周期後も0です。
+
+同分再送は全案とも保存済み結果の返却だけで残量不変。同じ分で異なる入力は拒否します。局所供給線だけ喪失する場合もpower_available=falseを投影し、残量が正でも停止します。復帰は局所配電の停止保持条件を満たした評価境界で行い、残量が0なら再開しません。これらは設計比較で、実機受入結果ではありません。
+
+## 炉の候補
+
+原本寸法・裏地下を維持。所有する一般奴隷1名→100 Mana、一炉につき次の10分境界で一回の明示投入を提案します。ユニーク・代替不可能・売却不可・保護対象・ヒロイン・ライバル、客、一般従業員、分類不明な拘束者は除外。適格性が不明なら拒否します。自動投入は行わない案です。
+
+人物の適格性は未決定で、上記の対象分類も承認待ちです。推薦候補は自然生成と維持需要支払後のbase_after=min(C,max(0,B+G−D))を求め、所有・適格性・炉稼働・空き容量C−base_afterが100以上か再検証します。人物除去、Mana加算、投入IDと境界・対象ID・適格性根拠・前後残量の履歴を一つの保存可能な原子操作として確定する案です。拒否時は人物・マナ等を何も消費しません。容量不足では投入せず、人物を消費してoverflowを捨てる案にしません。確定前中断は無変更で取消、確定後中断は保存receiptから復帰して再消費しません。枯渇中の炉は稼働しないため世界樹で先に復帰します。これは将来実装契約の候補で、今回は実際の人物消費も資源変更もありません。
+
+C=300、G=20、D=16、F=100を仮に式へ投入すると、B=200では200+20+100−16=304→overflow4、B=196では300→overflow0、B=300では404→overflow104です。これは算術比較で、容量不足の実取引を許可する意味ではありません。推薦の需要支払後判定ではB=200のbase_after204・空き96は拒否（F=0、残量204）、B=196のbase_after200・空き100は受理（残量300）、B=300は拒否（残量300）です。
+
+別案は生成後・需要支払前のmin(C,B+G)で空きを判定し、上記3例の空きは80・84・0で全て拒否します。需要支払後の推薦候補とこの別案の選択は未承認です。どちらも人物・マナ・receiptを原子的に変更し、同じ取引の再送で二度適用しない案です。
+
+## 更新順序と保存
+
+D05はdecisions.jsonのpendingです。現順序はAPPLY_COMMANDS→TIME_BOUNDARIES→MANA→CONSTRUCTION→LOGISTICS→FACILITY_COMPLETION→VITALS_AND_ENVIRONMENT→INCIDENTS_AND_EVENTS→FACILITY_QUEUES→AI_DECISIONS→PUBLISH_SNAPSHOT。推薦はこのphase列を保持し、MANA内で入力snapshot→自然生成→維持需要支払→空き容量判定→炉取引のstage→最終残量計算→局所配電→全館ゲート→receipt確定とします。
+
+00:00の既承認Gold維持費は閉店・停電でも所有時間に応じて精算し、マナ停止を理由に取り消しません。06:00/18:00の勤務境界は保持。マナ評価後の物流・サービス完了・queueは確定電力を参照する案です。未完了サービスを完了として課金せず、EV/搬送は位置・荷物・ID・ルートを保持して停止、復帰で重複搬送しない案。日跨ぎ完了・費用時点・移動中の具体処理はD05承認前に製品へ接続しません。
+
+旧GameStateは非負値を復元でき0を許し、get_resourceで欠落も0として参照されます。0は現在の投影では停止であり、無制限・満量の証拠ではありません。ネットワークsnapshot版1、save format1/2は新しい残量容量・生成率契約の承認を意味しません。
+
+移行案は適用元版と新domain版を明示し、preview・検証済みbackup後に原子的適用。明示旧0は0・停止を維持。正値は承認容量内のみ保持。欠落、曖昧、負値、非整数、容量超過は拒否して元保存・live状態を保持し、黙って切り詰めません。新保存は残量・容量・最後の境界/flow・炉receipt・配電投影を保持。同境界同入力は再消費・イベント再発行なし、異入力/逆行は拒否。時間飛びは各10分境界を順に処理し、offline生成は別承認なしには行いません。
+
+## 不足・承認待ちと検証
+
+D04の値と換算、D05の境界処理、炉の対象判定・収率・履歴、新保存domain版と移行元適用条件を承認範囲として分けます。未定義13施設の需要、実際の配置基数、全ゲームの性能・経済バランスは未確定です。原P06-01は未達を維持します。
+
+静的に参照sourceと計算を確認した成果です。正式proposal-consistency試験・別Claudeレビュー・承認・統合・完了確定はRunnerに委ね、合格を自己宣言しません。