TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p07-01/SPEC.md

P07-01 雨と霧と自然天候 仕様（登録版 r01）

• 状態: 登録の前の仕様。Root が main の docs/plans/original-completion-2026-10-02/execution/p07-01/SPEC.md に固定し、その commit を base_commit にして通常の登録をする。登録・下書きは実装の受入ではない。原本への加算は whole-unit の final の後だけ。出典は同じフォルダの PROVENANCE.json。
• 前提: P04 は正式完了。ユーザーの指示（2026-10-23）「まずゲームとしての機能実装完了を優先して」「…統合試験の動作速度のチューニングを、今やるよりも機能実装の完了を優先して」により、機能の単位を先にする。P07-01 は P05-03 の人への問い（未回答）とは独立している。

1. 原本の条件（変えない）

• 原本 docs/traceability/original/BASELINE.txt 74 行（原文）: * **天候:** 雨（客足減・滞在延長）、嵐（新規客ゼロ）、マナの霧（魔法効率UP・興奮度UP）。 214 行（原文）: * **上部:** 資金・マナ・資材リソース、時間・天候、世界樹ランク。
• P07-01 の work: 雨の来客減・滞在延長、マナ霧、自然変化を実営業へ接続する。acceptance: 天候切替直前後、途中保存、自然来客の差を同条件で説明できる。
• P07 の acceptance のうちこの単位に当たる部分: 嵐で新規入館0、雨で来客減/滞在延長。天候変化の瞬間と保存再開が一致。
• 原子要件（P07）: AR.weather.rain_arrivals（雨で客足が減る）、AR.weather.rain_stay（雨で滞在が延長する）、AR.weather.fog_magic（マナの霧で魔法効率が上がる）、AR.weather.fog_excitation（マナの霧で興奮度が上がる）、AR.weather.storm_no_arrivals（嵐で新規客がゼロになる）、AR.ui.hud_weather（上部に天候を表示する）。
• 横断条件（P07）: 原本条件とUI操作が一致、Runtimeの実利用・会計・行動へ接続、途中保存・再起動で再現、異常/境界/中断を検証、関連回帰PASS、要件別ログとソースハッシュを保存、既存代表負荷の性能回帰を計測。

2. 決定（捏造しない）

• A13（ユーザーの決定。回答の時刻は記録に無く、Root の記録は 2026-10-23T18:07:36Z）: 天候の初期仕様。問い（原文は PROVENANCE.json）の3項目に、ユーザーが「この初期仕様で進める」と答えた。
  1. 毎朝 6 時に、晴れ 60%・雨 25%・マナ霧 10%・嵐 5% で抽選する。雨は 6 時間、霧は 4 時間、嵐は 2 時間続き、その後は晴れ。開始は 6〜20 時の 30 分刻み。
  2. 雨の間は新規来客を半分にする。帰宅予定の客は、雨が止むまで滞在を延長する（最大 4 時間）。
  3. マナ霧の「魔法効率上昇」は、世界樹とマナ炉の産出を 1.2 倍にする。「興奮度上昇」は、成人確認済みの客の性欲の増加を 1.5 倍にする。
• 出典の区分: 人が承認したのは、上の問いの3項目と、問いが詳細として示した実装案 p07-01-registration-proposal-r01/PROPOSAL.md（SHA-256 0772743a…a532）。実装案にある「切り捨て」と、下の §4 の抽選の手順・保存・移行・同時の扱いの詳細は、実装担当（Opus）の仕様の選択で、人の新しい承認として扱わない。
• 既存の決定のまま: 嵐の新規入館 0（原本の明示。今の実装を保つ）。A06（マナの貯蔵の上限 300 と 10 分の境界）は変えない。
• この単位で作らないもの: P07-02 の環境（採光・遮音・隠蔽・景観・清潔・騒音）、P07-03 の流行ニュース、天候の魔法以外への効果、D04 の他の値。

3. 今の実装（main 48d3b00）

• scripts/environment/weather_timeline.gd: 種類 clear・rain・storm・mana_fog、予定の切り替え（schedule、MAX_PENDING 4096）、時刻の前進、保存と復元（VERSION 1）。確率と効果は持たない。
• autoload/simulation_runtime.gd: 時刻の境界の最初（simulation_runtime.0_weather → _advance_weather）で天候を進める。来客の計画の受付（_operations_arrival_boundary）は、嵐の間 capacity_remaining を 0 にする。新しい客の帰りの予定は一律 planned_exit_at = 今 + 720（3109 行と guest_service.gd 131 行）、帰りの判定は 9038 行。保存される乱数の系列は RNG_STREAM_IDS（78 行〜。world・guest_spawn など9本）で、旧 save に defense の系列が無い時は world_seed から作る前例がある（1322〜1324 行）。get_weather_report は今の種類と分だけを返す。
• scripts/mana/mana_reserve_cycle.gd: 10 分ごとの境界で、世界樹の産出 WORLD_TREE_GENERATION 20、マナ炉の産出 FURNACE_YIELD 100、上限 300（A06）。
• scripts/guest/guest_service.gd 330〜367 行: 性欲（intimacy）の増減の計算。成人確認は guest_definition.gd の adult_verified。
• scenes/main/main.gd: 上部の天候の表示（晴れ・雨・嵐・マナの霧）。予報は無い。
• ゲームの中で天候を予定する経路（自然天候）は無く、試験だけが schedule を呼ぶ。雨・霧の効果は無い。

4. 挙動

• 4.1 自然天候（A13-1）:
  • 毎日 06:00 の時刻の境界で1回だけ抽選する。新しいゲームでは、開始の日の 06:00 にも抽選する。
  • 保存される乱数の系列 weather を RNG_STREAM_IDS に足して使う。
  • 種類: 0〜99 の整数を1つ引き、0〜59 晴れ、60〜84 雨、85〜94 マナの霧、95〜99 嵐。
  • 晴れ以外では、開始の時刻を 06:00〜20:00 の 30 分刻みの 29 個から1つ引く。開始の時刻に切り替え、続く時間（雨 360 分・霧 240 分・嵐 120 分）の後に晴れへ切り替える。予定は weather_timeline.schedule で行い、保存される。
  • 最も遅い終わり（20:00 開始の雨で翌 02:00）は、次の 06:00 の抽選より前なので、日をまたいで予定が重ならない。開始が 06:00 の時は、同じ境界で切り替える。
  • 抽選の結果（日、種類、開始、終わり）を出来事 WEATHER_FORECAST_DRAWN として記録する。
• 4.2 雨の来客（A13-2）: 雨の間の来客の計画の境界では、計画の新規の人数を半分（切り捨て）にする。嵐の 0 と、マナや定員の今の上限は先に効く。晴れと霧では変えない。
• 4.3 雨の滞在（A13-2）:
  • 雨の間に帰りの時刻（planned_exit_at）になった客は、帰りを、その雨の終わりの時刻か、元の帰りの予定 + 240 分の早い方まで延ばす。
  • 延長は客ごとに1回だけで、元の予定と延長の後の予定を保存する。延長の後の時刻には、天候に関わらず今の規則で帰る。
  • 嵐と霧では延ばさない。
• 4.4 マナの霧（A13-3）:
  • 魔法効率: 霧の間のマナの 10 分の境界では、世界樹の産出を floor(20 × 1.2) = 24、マナ炉の産出を floor(100 × 1.2) = 120 にする。炉の受け入れの判定（空きが産出以上）も、その境界の産出の量で行う。上限 300 は変えない。
  • 興奮度: 霧の間、adult_verified の客の性欲の増加（その計算の正の増分）を floor(増分 × 1.5) にする。減少と、成人確認の無い客は変えない。
  • 霧の外では元に戻る。
• 4.5 嵐（原本）: 今の新規入館 0 を保つ。自然天候の嵐でも同じ。
• 4.6 上部の表示と予報（AR.ui.hud_weather）:
  • 今の天候に加えて、その日の次の切り替え（種類と時刻）を出す（get_weather_report に足す）。
  • 雨・嵐・霧の時は効果を短く案内する（雨: 来客が半分・帰りを最大 4 時間延ばす、嵐: 新規来客なし、霧: マナの産出と成人客の性欲が増える）。
  • UI は今の部品のままにし、完成の見た目は求めない。
• 4.7 同時の扱い（D05 の範囲の実装の契約）:
  • 天候は今どおり時刻の境界の最初に進めるので、同じ分の来客の計画・帰りの判定・マナの境界・締めより先に効く。
  • 予定の重複・過去の時刻・上限を超えた予定は、今の weather_timeline の規則で拒む。

5. 保存と移行

• 5.1 自然天候の状態（最後に抽選した日と、その日の予定）、系列 weather、客の延長の記録を保存する。同じ process の保存の往復と別の process の再開で同じ状態になり、抽選・延長・霧の効果を二重に行わない。
• 5.2 旧 save（自然天候の状態と系列 weather が無い）:
  • 今の天候と予定をそのまま保つ。
  • 系列 weather は world_seed から作る（defense の系列の既存の移行と同じ形）。
  • 読み込みの後の最初の 06:00 から抽選を始める。過去の日の抽選はさかのぼらない。客の延長の記録は無しとして読む。
• 5.3 不正な天候の状態（知らない種類、範囲の外の時刻、重なる予定、延長の上限を超えた記録）は拒否し、読込の前の状態を保つ。

6. 受入条件（acceptance_baseline の本文と同じ）

• P07-01-F1 自然天候: 毎日 06:00 に1回だけ、§4.1 の確率・開始の時刻・続く時間で天候が自然に予定され、同じ world_seed と同じ操作で同じ天候の列になる。新しいゲームの開始の日も抽選され、旧 save は §5.2 のとおり移行する。
• P07-01-F2 雨の来客: 雨の間の来客の計画の新規の人数が、同じ条件の晴れの半分（切り捨て）になり、嵐の 0 と定員・マナの上限を壊さない。
• P07-01-F3 雨の滞在: 雨の間に帰りの時刻になった客が、雨の終わりか元の予定 + 240 分の早い方まで1回だけ残り、その後は今の規則で帰る。嵐と霧では延びない。
• P07-01-F4 嵐: 自然の嵐を含め、嵐の間の新規入館が 0。
• P07-01-F5 マナの霧: 霧の間のマナの境界で世界樹 24・マナ炉 120（上限 300 のまま）、成人確認済みの客の性欲の増加が floor(×1.5) になり、霧の外と成人確認の無い客は変わらない。
• P07-01-F6 表示と予報: ゲームの本物の Runtime と Main の上部の表示で、今の天候・次の切り替え（種類と時刻）・効果の案内が Runtime の値と一致する。
• P07-01-F7 保存と再開: 天候の切り替えの直前・直後・途中の保存を、同じ process と別の process で読み、天候・予定・系列・来客・滞在の延長・霧の効果が同じになり、二重に効かない。旧 save は §5.2 で読め、不正な状態は §5.3 で拒否して状態を保つ。
• P07-01-F8 回帰: 関連の回帰（狭い roster と再開の2段）と最終の S の全 roster（既存の代表負荷の性能の suite を含む）が PASS。既存の試験の期待値の変更は EXPECTATION_CHANGES.json に変更前後と根拠を一覧にする。元の失敗を保存し、未解決の試験を除いて PASS にしない。

7. 開示

• 実装案の「切り捨て」と §4・§5 の詳細は、実装担当の選択（§2）。
• 興奮度は性欲（intimacy）の増加に当てた。今の客の種類の多くは性欲の増加が 0 なので、霧の効果は増加が正の成人確認済みの客にだけ表れる。
• 予報はその日の予定だけを出し、翌日以降は出さない（翌日の抽選は翌朝 06:00）。UI は今の部品のまま。Windows の実機は後。
• 性能の調整はしない（横断条件の性能回帰の計測は、全 roster の既存の性能の suite の結果で見る）。

8. 検証

• validation p07-weather: tools/run_p07_weather_tests.py --output {build_dir}/p07-weather-evidence。P05-02 の tools/run_p05_funds_tests.py と同じ guarded の段の手順を、この作業の中で作る。
• 狭い roster:
  • 新しい suite tests/environment/test_p07_weather_runtime.gd（F1〜F7）。
  • 既存の tests/environment/test_runtime_weather.gd・test_weather_timeline.gd・test_weather_recovery.gd・tests/mvp/test_runtime_operations_integration.gd・tests/s2/test_runtime_operations_cycle.gd・tests/s2/test_runtime_mana_reserve.gd・tests/s2/test_mana_reserve_cycle.gd・tests/s3/test_guest_service.gd・tests/s6/test_runtime_save_lifecycle.gd・tests/s6/test_runtime_snapshot_serialization.gd・tests/ui/test_main_dashboard.gd。
  • 再開の2段: tests/environment/test_p07_weather_restart_1_write.gd（天候の途中で保存。生成ファイルは handoff だけ）と ..._2_read.gd（別の process で読む）。
• その後: 正式の validation → 最終の S の全 roster を1回 → fresh な独立レビュー（whole-unit）。速度の調整の作業と、微小な変更ごとの全回帰はしない。