TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p28-01/restart/DRAFT.md

P28-01-RESTART 最終草案（未登録・未実行）

• 状態: Desktop 管制による草案です。collector の final が出るまで、登録、worker の起動、engine の実行はしません。
• 目的: 原 P28 の横断条件「途中保存・再起動で再現」を、R と O のそれぞれについて、writer と reader を別PIDにした1組で示します。性能の数値はここでは比べません。
• 原本の扱い: collector だけでは原本に加算しません（22/88 のまま）。P28-01 の加算には、次の4つがすべて必要です。
  1. collector の final
  2. 実測
  3. RESTART の pair の PASS
  4. 証拠ゲート
• 予算の未達、200客での Operations ON、Windows は、未達のまま残します。

1. 範囲と入力

	writer（PID A）	reader（PID B、別の engine プロセス）
R（602分、Ops OFF）	SPEC §4.3 と同じ起動（autoload への復元 → main の追加 → _set_speed(1)）。実際の clock 経路で10ゲーム分、または simulation_overloaded までの短い方を進め、clock が止まった状態で保存する	新規開始で main を追加（_ready の Ops 開始結果をそのまま記録）→ UI の読込で R の保存を読む
O（新規開始、Ops ON）	新規開始の main で実際の x1 を進める。最初の実際の arrival（下の §4）が起きた後の最初の分で、clock を止めて保存する。上限は120ゲーム分	R と同じ

• 保存には、main の実際の手動保存 main._save_manual_at_path(path, name) を使います（main.gd:2243 → save_to_path :4195 → _perform_checkpoint_save）。
• 読込には、main の実際の読込 main._load_manual_at_path(path, true) を使います（main.gd:2288 → load_from_path :4223）。
• 保存先は private user:// だけで、通常 player の保全を前後で照合します。

2. 成否の取り方（_save_manual_at_path は bool、_load_manual_at_path は void）

• _save_manual_at_path（main.gd:2243）は bool を返し、_load_manual_at_path（main.gd:2288）は void です。

• 保存の bool 戻り値は記録し、signal の ok と一致することを要求します。ただし、bool の true だけで成功とはしません。

• 保存も読込も、成否は下の signal、latest_save_operation_result、実状態の3つで判定します。

• 呼出しの前に、SimulationRuntime.save_operation_completed（:9）へ受動的に接続しておきます。

• 成否は、次の3つがそろったときに成功とします。

  1. signal の result（ok、code、operation、save_id、saved_absolute_minute）
  2. 直後に読んだ latest_save_operation_result。§3 の IO イベントの payload と一致すること
  3. 実際の状態。clock の absolute_minute が saved_absolute_minute と一致し、§3 の比較が成立すること

• 読込の void 戻り値も、保存の bool 戻り値の true も、それだけでは成功とみなしません。signal が来なければ、失敗として原記録を残します。保存の bool と signal の ok が食い違えば、不整合として失敗にします。

• latest_save_operation_result は create_snapshot()（simulation_runtime.gd:521-583）に含まれません。そのため状態比較の対象にはせず、別欄に記録して IO イベントの payload との一致だけを確かめます。

3. IOイベントの狭い対応規約（広い削除は禁止）

3.1 事実

• snapshot の中の場所
  • systems.runtime.domain_events = {version, published_ids, recent_events}（scripts/core/domain_event_stream.gd:96-112）
    • published_ids は、これまでに公開した全 ID を文字列で sort した配列で、上限はありません。
    • recent_events は直近の最大256件（RECENT_EVENT_LIMIT、:6）。append のとき、256件を超えると先頭が1件落ちます（:58-60）。
  • systems.runtime.id_generator.counters["domain_event"]（キーは String、値は int）
• 正式な保存と読込の完了時には、_complete_save_operation（:4734）が _publish_actor_event（:12558）を1回だけ呼びます。このとき採番される ID は1つで、E = "domain_event.%012d" % (c + 1) です（id_generator :13-18）。ここで c は package の snapshot P の counter です。
  • writer のイベントの型は SAVE_CHECKPOINT_SUCCEEDED、reader は SAVE_LOADED です。
  • どちらも source_system=save_service、entity_ids=[]、payload は _save_event_payload(result) です。
  • writer と reader は同じ P から採番するので、E は同じ ID になります。

3.2 期待状態の構成と、全状態の完全一致

除外して合わせるのではなく、P に IO イベント ev を1件だけ規則どおり適用した期待値 X(P, ev) を作り、実際の snapshot 全体と完全一致（typed var_to_bytes）させます。

• id_generator.counters["domain_event"] = P の値 + 1。他の counter はすべて P と同じ。
• published_ids = sort(P.published_ids ∪ {E})。E は P に含まれていてはいけません。
• recent_events は P.recent_events の長さで分けます。
  • 256 未満のとき: P.recent_events に ev を末尾に足したもの
  • 256 のとき: P.recent_events の先頭1件を落とし、ev を末尾に足したもの。落ちた先頭1件は、全内容を原記録に残します。
• ev は、event_id が E、型・source・entity_ids・minute は実際の値で、payload は signal の result から作ったもの（= latest_save_operation_result）です。
• 上記3つのパス以外は、P とバイト単位で同じでなければなりません。

3.3 比較の種類

比較	規約
a. writer の保存直前 create_snapshot() と P（SaveService.load_snapshot(path) で読んだもの。runtime は変えない）	完全一致。不一致なら、差のあるパスの全一覧を残して止め、判断に戻す
b. writer の保存直後と X(P, ev_save)	完全一致
c. reader の読込直後と X(P, ev_load)	完全一致
d. 継続 K 分の各分 t について、writer_t と reader_t	全状態の完全一致。違ってよいのは、recent_events の中の event_id E の要素1件だけです。E がまだ直近256件の窓の中にある間は、reader 側のその要素を writer 側のものに置き換えた状態が、writer_t と完全一致しなければなりません。窓から落ちた後は、置き換えなしで完全一致です。published_ids と counter は、置き換えなしで一致します。置き換えた両方の要素は全内容を記録します

• digest は SimulationDigest.compute で計算し、上の比較が成立した状態について記録します。digest 同士の一致だけで比較の代わりにはしません。
• 規約の外で違う箇所が1つでもあれば失敗です。差のあるパスの一覧を返します。規約を広げるには、新しい判断が必要です。

4. Operations の境界と、実際の進行

• O の writer は、390分の時点で次のものを記録します。
  • 実際の clock
  • get_operations_report()（coordinator の current_minute、population）
  • 処理済みの arrival 分
  • 実際に来館した guest-auto の数
  • その間の domain_events
• 保存できるのは、実際の arrival（来館数 > 0）が起きた後だけです。境界に到達しただけで、arrival を処理したことにはしません。120分までに arrival が起きなければ no_arrival_within_cap とし、Ops 境界の項目は null と理由にします。
• 継続 K:
  • 各側で clock を止めた状態にして、advance_minutes(1) を1回ずつ呼びます（止めた状態での手動の stepping、simulation_kernel.gd:104-119）。
  • 呼出しの前後で absolute_minute を照合し、進まなければ stop_reason=no_tick_advance で止めます。
  • 実際の K は、実際に進んだ分の数です。両側の実際の K が一致することを要求し、K=30 のときだけ30分と表記します。

5. 異常と境界（最小限）

1. 改ざんした保存の原子的な拒否: package のコピーで world.bin の1バイトを反転させます。UI の読込が拒否され、試行の前後で runtime の全 snapshot が完全に一致することを確かめます。
2. 止まった状態での保存（R）: overload で止まった writer の保存は、読込後の reader も止まった状態であること、backlog を消費しないことを確かめます。
3. Ops の境界をまたぐ（O）: 継続 K の d. の比較が、次の arrival 境界で重複も欠落もないことを示します。

6. 静的な禁止検査（collector の check_probe は丸ごと import しない）

区間	許可するもの	禁止するもの	用途
UI 区間（起動、実際の clock、UI での保存と読込）	_set_speed、_save_manual_at_path、_load_manual_at_path、受動的な接続	advance_、set_paused(false)、clear(、spawn_guest、SimulationRuntime.new、initialize(、enable_production_	状態と IO の観測だけ。性能値は出さない
決定性区間	単一の func deterministic_step() の中の GameClock.advance_minutes(1) だけ。呼び出せるのは UI 区間が終わって clock が止まった後だけ	Time.get_ticks_usec と *_us の統計欄、および上の UI 区間の禁止 token（許可した1つを除く）	writer と reader の比較だけ。性能・予算・速度には使わない

checker の拒否試験は、少なくとも次のものです。

• deterministic_step の外での advance
• 決定性区間から出た timing 値
• 呼出し回数で K を数えること
• 規約外のパスの除外や置き換え
• cap が256のときに「末尾1件の除外」として扱うこと
• E 以外のイベントの置き換え
• 読込の void 戻り値や、保存の bool の true だけで成功とみなすこと
• 保存の bool と signal の ok の食い違いを見逃すこと
• 境界に到達しただけで arrival を処理したとみなすこと
• signal が来ていないのに成功とすること

7. 実装と実行

• 置き場所: docs/plans/original-completion-2026-10-02/execution/p28-01/restart/**（source map の外）。
• 前後で source map が1407件のまま一致することを照合し、正式全192の証拠を維持します。製品を変えた場合は全 roster をやり直す必要があり、旧証拠は流用できません。
• 登録: collector の baseline C1〜C9 は凍結されているので、別の小さな project と task（P28-01-RESTART）として登録します。
  • spec_ref はこの草案を Git で追跡する文書にしたものです。
  • worker は通常の Runner worker、レビューは独立した Opus です。
  • 統合済みの collector の owned-phase の実行、guard、private profile は、読取専用で import します。
• 実行: Root が、実測と並べて R に2プロセス、O に2プロセスを、owned PID と raw の結合つきで実行します。