P28-02-DIAG: 意味を保つ軽量化：実測上位の特定（受動的な診断）

2026-10-21 06:24:40 +09:00
parent 8c06c3b442
commit ecbbb6bb16
8 changed files with 1868 additions and 0 deletions
@@ -0,0 +1,93 @@
+# 過去の 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 操作、製品変更は行っていません。