# 過去の blocked 記録（repair2 で解消済み）

OPUS_STARTUP_LIFECYCLE_CLARIFICATION により、以下の pause の質問も解消しました。
この文書は履歴です。現在の実装・検証状況は IMPLEMENTATION.md と UNIT_OUTPUT.txt を参照してください。
以下の「未提出」「未実行」は、当時の状態を記録したものです。

## P28-02-DIAG: repair1 起動時の pause 呼出しの適用範囲

## repair1 の判断

OPUS_D2_SCOPE_CLARIFICATION により、以前の S/K/C の比較境界の質問は
解消しました。以下の以前の記録は履歴であり、現在の阻害理由ではありません。

残る確認は、起動準備で probe が `GameClock.set_paused(true)` を呼んでよいかです。
補足の「collector の SPEC §4.3 と同じ順序」に参照される
`execution/p28-01/SPEC.md` の §4.3 手順2は、autoload 準備後、R の復元前に
この呼出しを要求しています。一方、P28-02 の SPEC §3.1 と TASK_INSTRUCTIONS は、
live を変更できる API を fixture の restore と `advance_minutes(1)` のみに
限定しています。補足は main の追加を明示していますが、probe によるこの
pause 呼出しの例外は明示していません。

`scripts/core/simulation_kernel.gd:175-178` の `set_paused(true)` は
`paused` と `_pause_request_serial` を変更します。後者は今回明示された K 層の
対象です。したがって、読取 API とみなすことはできません。
main の `_ready` による副作用は明示された main 追加に伴うものとして扱えますが、
それとは別の probe の呼出しについて、許可を独自に広げません。

必要な確定は、collector §4.3 手順2の pause を起動準備の例外として許すのか、
DIAG ではその手順を省略して restore → main 追加とするのか、の一点です。
collector の windowed 実行や速度設定を DIAG に持ち込む要求ではありません。

確認した SPEC の strip SHA は
`0420dd4d2a95db65adc685bca91b9ff686650af31675f193992d75909a676ac6`、
raw SHA は `f58378b6cb317478f9d26776d0a236804f4ac80789d93f1555133298e4328d24`。
TASK_INSTRUCTIONS の raw SHA は
`b9b635b2598aee32efac662aa21d21fc88f55fbfdc6097cf07483e7fa5d32a7d` と一致しました。

実装 S は未提出、unit と native は未実行、PASS の主張はありません。
git 書込み、他エージェント起動、Runner 操作、製品変更は行っていません。

## 以前の記録（S/K/C の質問は解消済み）

対象 base: `8c06c3b44235a52f35898b1f6263e8ee064af256`。
実装提出ではなく、仕様判断への差戻しです。受入の達成は主張しません。

## 必要な判断

SPEC §3.1・§3.3 と D2 の「live の全状態」は、
`SimulationRuntime.create_snapshot()` が返す保存対象の全状態を指すのか、
snapshot に含まれない内部状態も指すのかを確定してください。

前者なら、返された Dictionary 全体の `var_to_bytes` 完全一致を比較範囲として
明記する必要があります。後者なら、内部状態の対象と観測方法
（Object 参照、循環参照、signal 接続、性能計測状態などの扱いを含む）が必要です。
worker が独自に対象を除外して「全状態一致」と報告することはしません。

## base のソースで確認した根拠

- `scripts/core/simulation_kernel.gd:39-46` に性能計測状態、`_accumulator`、
  `_skip_next_process`、handler 登録、pause serial などが存在します。
  同ファイル `clock_snapshot()`（209-215行）は `absolute_minute`、`speed`、
  `paused`、`snapshot_version` の4項目だけを返します。
- `scripts/core/simulation_snapshot.gd:6-14` は、この `clock_snapshot()` と
  GameState の snapshot を取り込みます。
- `autoload/simulation_runtime.gd:521-585` の `create_snapshot()` は
  上記 envelope に各 system の保存用 snapshot を追加します。
  同ファイル134-136行の `_mvp_manifest_cache_catalog`、
  `_mvp_manifest_cache_generation`、`_mvp_manifest_cache` は含まれません。
- 同ファイル560行から呼ぶ `_create_mvp_content_manifest()` は、
  11189-11195行で cache hit を判定し、miss 時にはこの内部キャッシュを書き換えます。
  したがって `create_snapshot()` の結果を前後で比較するだけでは、
  その呼出しによる内部キャッシュの変更を検出できません。

これは実際の測定区間で cache miss が発生したという報告ではありません。
warm 30分によって cache が構築される可能性はあります。しかし、cache hit の場合も、
snapshot の bytes 一致が証明する範囲と「全状態」の要求範囲を確定する必要があります。
読み取り API としての `get_property_list()` / `get()` による独自走査を採る場合も、
参照や実行時メタデータをどこまで含めるかは、この受入境界の判断になります。

## 確認済み事項と作業状態

- AGENTS.md、SPEC.md、TASK_INSTRUCTIONS.md と RESTART CLARIFICATION_02 を読取。
- SPEC の `sha256(text.strip())` は契約値
  `0420dd4d2a95db65adc685bca91b9ff686650af31675f193992d75909a676ac6` と一致。
  raw-bytes SHA との差を阻害理由にはしていません。
- 許可された外部 Python 依存6ファイルの SHA は CLARIFICATION_02 D1 とすべて一致。
- tick ID による結合、inclusive 区間、observer 別記録の仕様に不足は見つかっていません。
- scratch を構成できない項目は理由つき未測定にする規定があるため、
  その可否自体を今回の阻害理由にはしていません。
- 変更はこの `diag/BLOCKED.md` のみ。driver・probe・checker・verify・unit 試験は未実装。
- unit 試験、engine、正式 validation は未実行。PASS の主張はありません。
  指定 tmp 配下の一時ディレクトリ作成・削除の確認のみ実施しました。
- git 書込み、他エージェント起動、Runner 操作、製品変更は行っていません。