過去の 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 操作、製品変更は行っていません。

6.1 KiB Raw Blame History Unescape Escape