OPUS_STARTUP_LIFECYCLE_CLARIFICATION（P28-02-DIAG。base 8c06c3b44235a52f35898b1f6263e8ee064af256。OPUS_D2_SCOPE_CLARIFICATION の全文（S/K/C 層、observer、scratch、main の追加）はそのまま有効で、その上に起動から終了までの境界を確定する。原本の条件、SPEC、TASK_INSTRUCTIONS、baseline、製品の値は変更しない）

原則
- SPEC §3.1 の「live を変えてよいのは fixture の導入と advance_minutes(1) だけ」は、測定の区間（段階③〜⑤）の禁止として扱う。測定の前の準備（段階①②）では、下に列挙した公開の呼出しだけを行ってよい。準備による状態の変化は、その全てを raw に記録する。準備の変化を、測定の副作用や測定時間として扱わない。
- 列挙した呼出し以外に、製品の状態を変える呼出し、製品の値の変更、関数や hook の差し替えは行わない。

段階① autoload と fixture の準備（collector の measure_p28_01.gd:283-334 と同じ順序。同じ guard と private profile の bootstrap を使う）
- 許可する呼出し:
  - GameClock.set_paused(true)
  - FileAccess で代表入力 R を開き get_var(false)（SHA eb4f7700… を照合）
  - SimulationRuntime.restore_snapshot(<R>)
  - 復元の後の GameClock.set_paused(true)
- set_paused(true) は、実時間の _process による tick を止め、時間を手動の stepping だけで進めるための準備である（simulation_kernel.gd:104-121 で、止まった状態の advance_minutes は正当な手動の stepping として進む）。set_paused(true) は paused と _pause_request_serial を変えるので、その前後の K 層の値を記録する。
- 記録: restore の戻り値、復元後の S 層の SHA、K 層、C 層。

段階② main の追加（headless）と、手動 stepping の制御
- 許可する呼出し: main.tscn を instantiate して root に add_child する。その後 process_frame を2回 await する（focus の deferred 処理のため）。
- main の _ready の副作用（save policy の設定、Ops の開始の試行。R では INVALID_START_TIME になる）は、そのまま記録する。
- process_frame の間に kernel の _process が _skip_next_process を消費することがある（process_real_delta は skip を paused より先に確かめる）。これも準備の変化として記録する。
- 禁止: _set_speed、_toggle_pause、set_paused(false)。clock は段階②から段階⑥まで、ずっと paused=true のままにする。
- この段階の終わりに、baseline B0（S/K/C 層の SHA）を固定する。observer の接続はここで行い、接続の前後の get_connections() を記録する。

段階③ warm（30分）
- GameClock.advance_minutes(1) を30回呼ぶ。1回ごとに process_frame を1回 await する（main の deferred 処理を、tick の区間の外に出すため）。
- 各呼出しの前後で absolute_minute を照合し、進まなければ失敗にする。
- observer の記録は warm の区間として取り、統計には入れない。
- 終わりに baseline B1（S/K/C 層の SHA、absolute_minute=632、C 層の cache の状態）を固定する。C 層の規則 (a) は、ここで確かめる。

段階④ 測定（30分）
- 段階③と同じ方法で30分を進める。I0〜I11 の inclusive の区間、observer の自分の費用、path_query_measured を記録する。
- tick と tick の間の frame の wall（tick_completed から次の tick_started まで）は、別の欄に記録し、どの phase にも帰属させない。
- この段階の中の、状態を変える呼出しは advance_minutes(1) だけ。

段階⑤ tick の外の S/K/C 検査と内訳の測定（clock は paused のまま）
- 測定の前の S/K/C を記録する。そのあと、SPEC §3.3 の N=5 の計測と、使い捨ての scratch の操作を行う。測定の後の S/K/C が、測定の前と完全一致すること（C 層は D2 の規則 (b)(c)）。
- この段階では、時間を進めない。

段階⑥ 切断、解放、終了
- observer を切断し、各 signal の接続が段階②の接続の前に戻ったことを確かめる。scratch の object を解放し、instance ID が無効になったことを確かめる。
- 終了は collector の K1 と同じく get_root().close_requested.emit() で行い、audio の drain の結果を記録する。owned の cleanup は collector の run_private_engine と同じ。

3 PID の条件の一致
- 3つの PID の間で、次のものが一致することを要求する: 入力の SHA、段階①の復元後の S 層の SHA、B0 と B1 の S 層の SHA、K 層（absolute_minute、paused、_pause_request_serial、_skip_next_process、snapshot_version、handler の集合）、C 層の状態、main の _ready の Ops の結果。
- 一致しない項目があれば、その事実と値を記録して判断に戻す（3回の比較は成立しないものとして扱う）。時間の値（区間の wall）は、一致を要求せずに比べる。

worker の裁量（微小な確認ごとに止めないための指示）
- 承認された範囲の中の通常の実装上の選択は、worker が判断して、その理由を BLOCKED.md ではなく実装の記録に残して進める。例: 関数の分け方、名前、report の構造、試験の合成データ、await の配置、記録の書式、上に列挙した許可済みの呼出しの使い方。
- blocked にしてよいのは、原本の製品の仕様・数値・権限・課金・原本の受入に影響する未確定事項がある場合だけ。その場合は、具体的な箇所と、選択肢を示す。

その他（SPEC、TASK_INSTRUCTIONS、C1、両 validation、engine・製品変更・全回帰・commit の禁止、測れない項目を理由つきの未測定にすること）は、すべて従来どおり。
