# P28-02「意味を保つ軽量化」仕様（候補 r02。未登録・未実行）

- 状態: 候補です。Root が原本の条件と照合して main に commit し、その実 SHA を base にしてから、通常の登録をします。
- 前提: P28-01 は正式に完了しています（Q `ae9ae47646434dd57fc21f3e8566d0d35b242ab1`、`execution/p28-01/P28_01_FORMAL_COMPLETION_AE9AE47.json` `f778ac8d…`）。その測定（full9 `db9d613`、r02、RESTART）と、製品 source 1407 を引き継ぎます。

## 1. 原本の条件（変更しない）

- 成果単位 P28-02（`work_packages.json` の P28.remaining_deliverables）
  - work: 失敗時拒否を含む同等性を先に固定し、snapshot変換・検証・コピー・経路接続の実測上位から改善する。
  - acceptance: 同条件の反復比較と全状態・全イベント一致を確認し、キャッシュの古さ・所有権・不正入力を検証する。
- P28 の横断条件6件（原文）: 原本条件とUI操作が一致 / Runtimeの実利用・会計・行動へ接続 / 途中保存・再起動で再現 / 異常/境界/中断を検証 / 関連回帰PASS / 要件別ログとソースハッシュを保存。
- パッケージの依存: P28 は P27 に依存し、P27 は in_progress です。この依存は、P28 パッケージを最終的に完了と判定するときの前提です。P28-02 の診断と作業を止める理由にはしません（既存の、人間による順序変更の許可を保持します）。P27 が完了したとは主張しません。
- 分母は 30/88 で、部分点はありません。現在の正式完了は 23/88、パッケージは 4/30 です。予算の false 6件（R0 の2件、P1 の2件、P2 の2件）は、そのまま保持します。

## 2. 事実と不足（数値を結びつけない）

- 実測（P28-01 から引き継ぐ。それぞれの区間の値で、互いに結びつけない）:
  - full9 の R: kernel の `process_real_delta` の1回の呼出し（frame）が、P1 x1 で平均 479.210 ms、P2 x3 で P95 5062.697 ms。
  - r02（headless・Ops OFF・x1。別の区間）: 外側の1分 advance が平均 826.6 ms、外側の snapshot が 77.6 ms（count 5）、保存は約 300 ms、読込は約 3.2 s。
- source から確定していること: 毎 tick の PUBLISH_SNAPSHOT で `create_snapshot()` が呼ばれます（`autoload/simulation_runtime.gd:12616-12621`）。ただし、r02 の 77.6 ms を、P1 の 479 ms の中の同じ呼出しの固定の費用として扱うことはしません（区間も条件も違うため）。
- 不足: 現在の source での、tick の中の phase ごとの wall 区間、snapshot・検証・コピーの内訳、経路の費用。推測で埋めません。

## 3. 段階A: `P28-02-DIAG`（診断。製品は変更しない。原本の加算は0）

### 3.1 live の状態の扱い

- live の Runtime の状態を変えてよいのは、次の2つだけです。それ以外の、状態を変える API の呼出し、製品の hook や関数の差し替えは禁止です。
  - fixture の最初の導入（`restore_snapshot` で入力 R を読み込む）。
  - 決められた `GameClock.advance_minutes(1)` による進行。
- 公開されている読取だけの API（`create_snapshot()` など）は、tick の外で呼んでかまいません。その後、live の全状態の `var_to_bytes` が、呼ぶ前と完全一致することを確かめます。一致しなければ失敗です。

### 3.2 tick の中の区間（受動的な観測。`scripts/core/simulation_kernel.gd:122-157`）

- `tick_started(m)` で tick の ID と、進行の前の分 m を記録します。
- APPLY_COMMANDS の `tick_phase_started` は、進行の前の分 m で発行されます。TIME_BOUNDARIES 以降の phase と `tick_completed` は、進行の後の分 m+1 で発行されます。phase を分で区切らず、tick の ID で結びつけます。
- 区間は、隣り合う信号の間の **inclusive な wall 区間**として記録します。各 handler の純粋な排他時間だとは主張しません。区間ごとの内容は次のとおりです。
  - I0: `tick_started` → APPLY_COMMANDS の開始
  - I1: APPLY_COMMANDS → TIME_BOUNDARIES（clock の進行、`_sync_calendar_fields`、`_handle_time_boundaries` を含む）
  - I2〜I10: TIME_BOUNDARIES → MANA → … → PUBLISH_SNAPSHOT の各開始の間
  - I11: PUBLISH_SNAPSHOT → `tick_completed`（`create_snapshot`、同期の signal である `snapshot_published` / `state_updated` の受け手、`snapshot_version` の更新を含む）
- observer 自身の費用: 各 callback の中で、自分の時間を別に計測して記録します。区間からは差し引きません（二重に数えないために、区間は「observer を含む」と明記します）。
- 経路: `PathService.path_query_measured(duration_us)`（`scripts/world/path_service.gd:4`、`:985`）に受動的に接続し、query の件数と時間を、その時点の区間に結びつけます。これは query の費用だけで、connector の更新や再構築の費用は含みません。query の時間を、connector 全体の費用へ広げて解釈しません。

### 3.3 tick の外の内訳（独立した inclusive の計測。合算して100%にしない）

- snapshot の変換: live で `create_snapshot()` 全体を N=5 回、各 service の `create_snapshot()` をそれぞれ N=5 回、別々に計測します。各値は独立した inclusive の計測で、排他的な内訳として足し合わせることはしません。N=5 は r02 の試行数に揃えたもので、R で1回約 80 ms のため負荷が小さいことが根拠です（製品の値ではありません）。
- 検証・コピー・保存・読込: live の状態は使いません。使い捨ての scratch で、公開されている restore・save・load・validator だけを使います。
  - scratch に渡すのは、live の snapshot の deep copy です。保存先は private user:// の scratch の path です。
  - 各操作を N=5 回計測します。
  - 終わった後に、live の全状態が一致すること、scratch から live への参照の漏れや副作用が無いことを確かめます。
  - 公開の API だけで scratch を作れない場合（autoload に触れる必要がある場合）は、その項目を理由つきの未測定にして、判断に戻します。
- 粒度: 製品の内部で分けられない変換・検証・コピーは、測れる粒度（たとえば「restore 全体」）のまま記録します。分けたことにはしません。
- 値: 正当に測れた 0 は 0 として記録します。測れなかったものは null と理由にします。欠損を 0 で補うことは拒否します。

### 3.4 条件と順序

- 入力・engine・machine は P28-01 の R と同じです（入力 `eb4f7700…`、engine `c7cccbf8…`、Mac16,10）。headless で実行します。
- 区間: warm 30分、測定30分。別の PID で3回行います。3回の間で、区間の順位が一致したかを記録します。
- 実行の順序（P08/P18 の通常の方式を再利用する）:
  1. worker が S を提出します（局所の unit 試験の全件 PASS つき）。
  2. Root が、凍結した S を隔離した stage で、import・parse・DIAG の3 PID を native で実行します。
  3. Root が raw を結合し、bundle を作ります。
  4. 登録した validation（unit と、bundle に対する native-verify の両方）を実行します。
  5. 別の新しい Opus が、全4条件と全 raw をレビューします。
  6. prepare → 候補の source と測定した S の一致の資格確認 → Root の委任による承認 → integration → final。
  - native は、測定した実際の S のものとして記録します。最終候補 Q で測ったとは表記しません。資格確認で、Q と S の source・設定・engine・入力が一致することを確かめます。

## 4. 段階B: `P28-02-OPT`（DIAG の後に、根拠をもとに登録する）

- 対象: DIAG で実測の上位になったもののうち、原 work の4つの分類（snapshot の変換・検証・コピー・経路接続）に入るものだけです。選ぶのは管制で、DIAG の表を根拠に記録します。上位が4分類の外にあった場合は、原 work の範囲の外なので、判断に戻します。
- 同等性を先に固定します（変更の前に、試験として凍結する）:
  - **E1 全状態**:
    - まず `var_to_bytes` の完全一致を確かめます。
    - 一致しない場合に限り、RESTART の修正8で確定した完全な typed の正規表現と比べます。これは、dict の key を文字で並べ（衝突は拒否）、全ての key と値の `typeof` と配列の順序と値を保つものです。それで一致すれば「dict の列挙の順序だけの差」として、その path を記録します。
    - それ以外の差は不一致です。SimulationDigest だけでの判定は不可です。
  - **E2 全イベント**:
    - `DomainEventStream.subscribe(&"*", &"p28_02_equivalence_observer", …)`（`scripts/core/domain_event_stream.gd:5`、`:17`、配送は `:76-85`）で受動的に記録し、全件を上限なく、順序・型・payload・ID・counter とともに保持します。
    - subscriber の登録が snapshot を変えないこと（`create_snapshot` の範囲の外）を確かめ、終わったら `unsubscribe` します。
    - recent_events（直近256件）の一致だけを、全イベントの一致として扱うことはしません。
  - **E3 失敗時の拒否**: 不正な入力（改ざん、型の違い、欠けた key、範囲外、重複した ID）が、変更の前と同じ code で、原子的に拒否されること。
  - **E4 キャッシュの古さ**: 無効化の全ての経路（コマンド、tick、restore、load）で、古い値を返さないこと。
  - **E5 所有権**: 公開した値を外から変更しても内部に影響せず、その逆も無いこと。
- 比較は2種類に分けて固定します:
  - (a) phase の比較: DIAG と同じ区間（headless、`advance_minutes`）で、変更の前と後を別の PID で各3回。`advance_minutes` では `performance_budget.record_simulation_frame` が呼ばれず、`_samples` が空になるため、この比較では kernel の予算の値を使いません。
  - (b) frame の予算の比較: 製品の経路 `process_real_delta` を通る、受入済みの collector の windowed の P1（x1）と P2（x3）を、変更の前（現在の Q）と後で、別の PID で各3回。kernel 定義の標本で比べます。
- RESTART の native の pair を1回行い、保存と再開の再現が保たれることを確かめます。製品の source が変わるので、最終候補で正式の全 roster を1回実行します。
- 予算は P28-02 の受入の条件ではありません。実測をそのまま記録し、false は合格に補いません。同等性 E1〜E5 が1つでも崩れた変更は採用しません。
- 独立レビュー: 原 work と原 acceptance、横断条件6件、補助の U1/U2 を、whole-unit として判定します。

## 5. 共通の制約

- 予算値、原本の分母、横断条件の原文は変更しません。Runner 本体、権限、認証、課金も変更しません。修正回数の上限は null で、API の課金はしません。容量待ちは再導入しません。