Freeze Opus P28-02 equivalence contract before product optimization

2026-10-21 07:17:23 +09:00
parent dfe07eba27
commit 2549cf7d69
9 changed files with 584 additions and 0 deletions
@@ -0,0 +1,100 @@
 # P28-02-EQ 仕様（spec_ref の候補。製品の変更なし。原本の加算は0）
 - 状態: 候補です。Root が原本の条件と照合して、`docs/plans/original-completion-2026-10-02/execution/p28-02/eq/SPEC.md` として main に固定し、その実 SHA を base にしてから、通常の新規登録をします。
 - 前提:
  - P28-02-DIAG は正式に完了しています（Q `fdb309f3bc81529135915429d2432a6644696311`、`execution/p28-02/DIAG_FORMAL_COMPLETION_FDB309F.json` `7d83ec0e…`）。
  - OPT の契約の候補は `OPT_CONTRACT_T1.md` r02 です。この SPEC の §3〜§5 が、その r02 の E1 の範囲・改善の判定・順序を確定し、置き換えます。
 - 原本の条件: P28-02 の work と acceptance、横断条件6件は `execution/p28-02/SPEC.md` §1 のとおりで、変更しません。EQ は、OPT の前に同等性を固定するための補助の task で、原本の分母を増やしません（23/88、4/30）。
 ## 1. 目的と範囲
 - 原 work の「失敗時拒否を含む同等性を先に固定し」を、製品を変える前に、実行できる harness として凍結します。
 - allowed_paths は `docs/plans/original-completion-2026-10-02/execution/p28-02/eq/**` だけです。製品の source map の1407件は変更しません。
 - import の閉包:
  - RESTART の CLARIFICATION_02 D1 の6ファイル
  - DIAG の5ファイル（`execution/p28-02/diag/*`、読取専用）
  - 自分の allowed_paths の中のファイル
 ## 2. 成果物
 | ファイル | 役割 |
 |---|---|
 | `eq/run_eq.py` | Root が実行する native の driver です。`--check \| --run --readonly <元の p28-01-readonly> --fixture <reference.variant> --engine <Godot> --output <新しい dir>`。owned phase・guard・private profile・cleanup は、collector を読取専用で import して使います |
 | `eq/eq_probe.gd` | E1〜E5 の probe です。起動は DIAG の6段階（OPUS_STARTUP_LIFECYCLE_CLARIFICATION）に従います |
 | `eq/compare_versions.py` | 2つの版の記録を比べる比較器です（§3） |
 | `eq/check_eq.py` | report の checker です |
 | `eq/verify_eq.py` | `--project-root .` で、`$BUILD_OUTPUT_DIR/p28-02-eq-evidence` にある実際の bundle を結合します。bundle が無ければ失敗します |
 | `eq/test_eq.py` | engine を使わない unittest です |
 ## 3. 比較の層（OPT r02 の E1 を確定する）
 ### 3.1 同じ PID の中（観測の副作用が無いこと）
 - DIAG と同じ、**完全な** S/K/C 層を、各観測の前後で比べます。K 層には、性能の telemetry（`performance_budget` の `_samples`・`_totals`・`_sample_counts`）を含みます。C 層には、instance ID を含みます。
 - 前後で、bytes の完全一致を要求します。
 ### 3.2 版と版の間（全状態と全イベントの意味の比較）
 - **S 層**: `create_snapshot()` の全体を比べます。`var_to_bytes` の完全一致を第一とします。不一致の場合に限り、RESTART の修正8の完全な typed の正規表現で比べ、dict の列挙の順序だけの差の path を全て記録します。それ以外は不一致です。`latest_snapshot` も同じ方法で比べます。`latest_digest` は、文字列の完全一致で比べます。
 - **K 層**（版の間で比べる欄を、次のものに限ります）:
  - absolute_minute、speed、paused、snapshot_version
  - `_accumulator`（f64 の hex。手動の stepping では決定的）
  - `_skip_next_process`、`_pause_request_serial`、`_abort_current_tick_requested`、`_last_tick_advanced`
  - `_phase_handlers` の、phase ごとの handler ID の集合
  - `performance_budget._sample_counts` の metric ごとの**件数**（呼出しの回数で、決定的）
 - **K 層で、版の間では比べないもの**（理由: 実時間に依存し、同じ版の別の PID でも一致しないため）: `_samples` と `_totals` の時間の値。各 PID の実際の値は、全て raw に保持します。
 - **C 層**（版の間で比べる欄）:
  - `_mvp_manifest_cache_generation`
  - 「`_mvp_manifest_cache_catalog` が `runtime.mvp_content_catalog` と同じ object か」の真偽
  - `_mvp_manifest_cache` の `var_to_bytes`
 - **C 層で、版の間では比べないもの**（理由: プロセスごとに変わる値のため）: instance ID の数値そのもの。実際の値は raw に保持します。
 - **E2 の全イベント**: 開始の時点で、両方の版の domain_event の counter と published_ids の数が一致していることを要求します。そのうえで、event ID を**そのまま**対応させます（付け替えの対応表は作りません）。全ての欄の完全一致を要求します。開始の時点の counter が違えば、比較は不成立とし、失敗にします。
 - 比べない欄を黙って落とすことはしません。比べない欄と、その理由と、各版の実際の値を、比較の結果に全て記録します。SimulationDigest だけでの判定は不可です。
 ### 3.3 観測と、意図的な scenario 操作の境界
 - (a) **観測の区間**: 記録・比較・snapshot の取得などの観測そのものは、§3.1 のとおり、前後で完全な S/K/C が不変であることを要求します。
 - (b) **scenario の区間**: E3/E4/E5 のために列挙した操作だけは、観測の区間とは別の、専用の区間で行ってよいものとします。それぞれの区間には開始と終了の記録を付け、前後の S/K/C の変化、拒否の code、所有権の結果を、実際の値として記録します。列挙した操作は次のとおりです。
  - E3: 不正な入力を与えた `restore_snapshot`・`SimulationSnapshot.validate`・`load_from_path`
  - E4: 状態を変えるコマンド（建設のコマンドを1件、通常の command queue を通す）、tick の進行（`advance_minutes(1)`）、`restore_snapshot`、`load_from_path`、状態を変えないコマンド
  - E5: 返された値（`create_snapshot()` の戻り値、`latest_snapshot`、`snapshot_published` / `state_updated` の引数）の、入れ子の dict と配列の変更
 - (c) **製品の既存の失敗との区別**: E5 の操作によって live の状態が変わった場合（たとえば、`latest_snapshot` と signal の引数の aliasing。OPT r02 §3 で予想したもの）は、製品の既存の失敗として、変化した path と値を記録して保持します。これは harness による無断の変更ではありません。どの scenario の、どの操作の結果かを、記録の中で結びつけます。その scenario の後の検査は、新しい baseline から始めます。
 - (d) **禁止**: 上に列挙した scenario の操作以外の、状態の変更と、hook や関数の差し替え。起動の準備（OPUS_STARTUP_LIFECYCLE_CLARIFICATION の段階①②）と手動の stepping は、従来どおりです。
 - 原本の全状態・全イベント・受入の条件は減らしません。K/C の限定の例外（§3.2）も、そのままです。
 ## 4. 改善の判定（OPT の受入で使う。新しい数値の閾値は作らない）
 - 指標（PID または run ごとに1つの値）:
  - (a) I11：PID ごとの、測定30 tick の I11 の平均（inclusive の wall）
  - (b-1) P1：run ごとの、kernel の `simulation_x1` の budget_verdict の値（区間の標本の平均。collector の H1 の定義）
  - (b-2) P2：run ごとの、kernel の `simulation_x3` の budget_verdict の値（区間の標本の P95）
 - 前後それぞれ3つの値で、指標ごとに分類します:
  - **改善**: 後の版の3つの最大が、前の版の3つの最小より小さい。
  - **悪化**: 後の版の3つの最小が、前の版の3つの最大より大きい。
  - **差は確認できない**: それ以外（範囲が重なる）。
 - P95・最大・stall の最大、I0〜I10 の各区間の値は、記述として全て報告します。分類には使いません。
 - OPT の受入での扱い:
  - 「改善あり」と書いてよいのは、(a) が「改善」で、かつ (a)・(b-1)・(b-2) のどれも「悪化」でない場合だけです。
  - (a) が「改善」にならなければ、「改善を確認できない」として、OPT の変更を採用しません（原 work の「改善する」を満たさないため）。
  - (b) が「改善」でなくても、悪化でなければ構いません。そのまま記録します。
 ## 5. 順序と、harness の正しさと製品の受入の区別
 1. EQ の worker が S_eq を提出します（engine を使わない局所の unit の全件 PASS つき）。
 2. Root が、凍結した S_eq で native を実行します。phase は7つです:
   - import
   - parse-base と parse-wrapper（`--check-only`）
   - R-A、R-B（R の同じ版の2 PID）
   - O-A、O-B（O の同じ版の2 PID）
 3. Root が raw を結合して bundle を作り、`$BUILD_OUTPUT_DIR/p28-02-eq-evidence` に置きます。
 4. 正式の validation を行います。`p28-02-eq-unit` と `p28-02-eq-native-verify` の両方が必須です。
 5. 独立した新しい Opus がレビューします（非同期の配送）。
 6. prepare → Q_eq の資格の確認 → Root の委任による承認 → integration → final。
 - **before の記録**: OPT の比較で使う「変更の前の版」の EQ の記録は、手順2の S_eq の native です（製品の1407件は、変更の前と同じです）。Q_eq の資格の確認で、製品の source map・engine・入力・設定・EQ のファイルが一致した場合に限り、そのまま再利用します。一致しなければ、Q_eq でもう一度実行します。
 - **harness の正しさ**（EQ の受入の条件）: 同じ版の2 PID の間で、§3.2 の比較の差が0であること（決定性）。E3/E4/E5 の検査が実際に動いて、結果を記録していること。拒否試験がそろっていること。
 - **製品の結果**（EQ の受入の条件では**ない**）: 前の版での E3/E5 の結果は、事実として記録するだけです。失敗したもの（たとえば OPT r02 §3 で予想した E5 の外から内への aliasing）は、**既存の不具合**として一覧にし、PASS で補いません。それを直すのは OPT の範囲です。
 ## 6. 全ての失敗の保持
 - native・validation・review の失敗は、raw と SHA とともに保全し、成功に書き換えません。修正は、通常の repair で、同じ W で行います。
@@ -0,0 +1,26 @@
 # P28-02-EQ worker 指示
 仕様は同じディレクトリの `SPEC.md` です。この指示と仕様は変更しないでください。
 - 作るもの（allowed_paths `docs/plans/original-completion-2026-10-02/execution/p28-02/eq/**` の中だけ）: SPEC §2 の6ファイルです。
 - 製品の source map の対象（autoload/scripts/scenes/data/tests/assets/tools と、直下の4ファイル）には、追加も変更も削除もしません。
 - 起動の6段階、S/K/C の検査、observer、scratch、cache の規則は、DIAG と同じです（OPUS_D2_SCOPE_CLARIFICATION と OPUS_STARTUP_LIFECYCLE_CLARIFICATION の全文を、Root が補足として渡します）。
 - E1〜E5 は、OPT_CONTRACT_T1 r02 §3 の場面と入力を使います。比較の層は SPEC §3 のとおりです。同じ PID の中は完全な K/C で、版の間は列挙した欄だけを比べ、比べない欄は理由と実際の値を記録します。
 - 既に分かっている落とし穴を避けること:
  - autoload の script の class_name を静的に参照しない（Runtime から動的に読む）。
  - Variant から `:=` で型を推論しない。
  - StringName の key は、文字の比較で並べる。
  - 一時ディレクトリは `BUILD_OUTPUT_DIR` か `tempfile.gettempdir()` の下に作る。
 - E3/E5 の検査が前の版で失敗しても、それは製品の事実です。PASS に補わず、SPEC §5 のとおり「既存の不具合」として記録します。harness の正しさの試験と、製品の結果を、混ぜないこと。
 - 拒否試験として、少なくとも次のものを置く:
  - 版の間の比較で、列挙していない欄を黙って落とすこと
  - instance ID の数値や時間の telemetry を、版の間で一致させようとすること
  - 開始の counter が違うのに比較を成立させること
  - SimulationDigest だけでの判定
  - SPEC §3.3 (b) に列挙した scenario の外での、状態を変える呼出し、hook の差し替え（scenario の中の列挙した操作は許可し、前後の変化を実際の値として記録する）
  - scenario の操作による live の変化を、記録せずに捨てること。その変化を harness の不具合として隠すこと（SPEC §3.3 (c)）
  - 欠損を 0 で補うこと
  - bundle の欠落
 - しないこと: engine の起動、git への書込み（commit を含む）、製品の変更、全回帰。
 - 提出前に、engine を使わない `python3 test_eq.py` を局所で実行して全件 PASS を確かめ、生出力を報告し、正式な JSON で提出します。
 - 承認された範囲の中の通常の実装上の選択は、worker が決めて IMPLEMENTATION.md に記録し、そのまま進めます。blocked にしてよいのは、原本の製品の仕様・数値・権限・課金・原本の受入に影響する未確定事項がある場合だけです。
@@ -0,0 +1,119 @@
 # P28-02 の改善の契約：T1（snapshot の変換・コピー）だけを先に（候補 r02。DIAG の通常の final の後に、Root が照合してから登録する）
 - 状態: 候補です。登録、worker、engine、新しい試験は、まだ行いません。根拠は DIAG の S `d6ce6dd` の bundle です（DIAG の正式な独立レビューは、そのセッションの結果だけを待ちます）。
 - 原本の条件: P28-02 の work、acceptance、横断条件6件は、`execution/p28-02/SPEC.md` §1 のとおりで、変更しません。原本は 23/88、4/30 のままです。新しい数値、原本の分母、保護、課金は変更しません。
 ## 1. T1 だけにする判断
 - 原 work は「snapshot変換・検証・コピー・経路接続の**実測上位から**改善する」で、4つの分類の全てを変えることは求めていません。
 - T1（I11 PUBLISH_SNAPSHOT、平均 約 81 ms/tick。tick の外の Runtime の create_snapshot の独立の計測が 約 77 ms）は、分類「snapshot変換・コピー」に直接あてはまり、分類にはっきり入るものの中で、実測で最も上位です。
 - T2（I10 の中の PathService の query）は、「経路接続」に探索を含めるかどうかの解釈の差があるので、今回は選びません。その理由は、受入の記録に残します。
 - I4 は、分類の根拠が無いので、範囲の外です。
 - whole-unit の独立レビューが、この選定は不十分だと判断した場合は、changes_requested として受けます。
 ## 2. 2つの task と、source の範囲（1407 の固定への適合）
 - **P28-02-EQ**（製品の変更なし）: allowed_paths は `docs/plans/original-completion-2026-10-02/execution/p28-02/eq/**`。同等性の harness・driver・checker・試験と、比較の collector（§4）を置きます。import の閉包は、RESTART の D1 の6ファイル、DIAG の5ファイル（読取専用）、自分のファイルだけです。
 - **P28-02-OPT**（製品の変更あり）: 変えてよいのは、次の**既存**の製品ファイルだけです。**新しいファイルを追加すること、ファイルを削除することは、source map の対象（autoload/scripts/scenes/data/tests/assets/tools と、直下の4ファイル）では禁止**です。
  - `autoload/simulation_runtime.gd`（`_publish_snapshot`、`create_snapshot`、`latest_snapshot`、`latest_digest` の周辺）
  - `scripts/core/simulation_snapshot.gd`
  - `scripts/world/world_service.gd`
  - `scripts/world/route_subslot_path_adapter.gd`
  - `scripts/world/path_service.gd`（`create_snapshot` の部分）
  - `scripts/core/command_queue.gd`（`create_snapshot` の部分）
  - OPT の試験は `docs/plans/original-completion-2026-10-02/execution/p28-02/opt/**`（source map の外）に置き、EQ の harness と一緒に実行します。
 - 理由: 既存の DIAG の driver（`diag_p28_02.py:101`）と RESTART の `restart_pair.py:189` は、source の件数を `== 1407` で固定しています。OPT が source の件数を変えなければ、両者を**変更せずに**、OPT の S でもそのまま実行できます。両者は、実際の commit と source map を全部記録するので、別の版の測定を、元の版の 1407 の測定として装うことにはなりません。全 roster の suite の数も、192 のまま変わりません。
 - EQ の比較の collector（`eq/compare_versions.py`）は、次のことを確かめます。追加、欠落、登録されていない差分が1つでもあれば、拒否します。
  - before の全 source map は、登録の base の product source map で、1407件・SHA `651f7036…`。
  - after の全 source map の差分の集合が、上の OPT の許可ファイルのうち、実際に変更したものと完全に一致すること。追加と欠落は0件。
  - after の版の EQ・DIAG・collector・RESTART のファイルの bytes が、それぞれの固定した SHA と一致すること。
 ## 3. 同等性 E1〜E5（EQ で凍結する。R と O の両方で行う）
 - 共通: R は DIAG と同じ起動の6段階を使います。O は新規開始（Ops ON、360分）を使います。B1 の後、K=30分を手動の stepping で進めます。
 - **E1 全状態**:
  - 範囲: S 層、`latest_snapshot`、`latest_digest`、K 層、C 層。
  - 時点: B1 と、30分の各 tick の最後。
  - 比較: `var_to_bytes` の完全一致を第一とします。不一致の場合に限り、RESTART の修正8の完全な typed の正規表現で比べ、dict の列挙の順序だけの差の path を全て記録します。それ以外の差は不一致です。
 - **E2 全イベント**:
  - B1 の直後から、30分目の tick_completed の後まで、`DomainEventStream.subscribe(&"*", …)` で、全件を上限なく、全ての欄とともに順序どおりに記録します。終わったら `unsubscribe` します。
  - 開始の時点の counter と published_ids の数の一致、終了の時点の counter の一致を確かめます。
  - tick ごとの `snapshot_published` / `state_updated` の回数と順序も一致させます。
 - **E3 失敗時の拒否**:
  - 対象の API: `restore_snapshot`、`SimulationSnapshot.validate`、`load_from_path`。
  - 入力: key の欠落、型の違い、範囲外の値、重複した ID、改ざんした `world.bin`。
  - 要求: code が変更の前と同じであること。拒否の前後で、S/K/C 層と全イベントが不変であること。load の失敗が `X(B, SAVE_LOAD_FAILED)` と完全一致すること。
 - **E4 キャッシュの古さ**:
  - 場面: 状態を変えるコマンド、tick、`restore_snapshot`、`load_from_path`、状態を変えないコマンド。
  - 要求: それぞれの直後の `create_snapshot()` と `latest_snapshot` が、変更の前の版の同じ場面と E1 の方法で一致すること。
 - **E5 所有権**:
  - 対象: `create_snapshot()` の戻り値、`latest_snapshot`、`snapshot_published` / `state_updated` の引数。
  - 外から内: 入れ子の dict と配列を外から変更しても、内部の状態、次の `create_snapshot()`、`latest_digest` に影響しないこと。
  - 内から外: 内部の更新（次の tick）の後も、既に返した値が変わらないこと。
 - **現在の source の E5 の読取確認**:
  - `_publish_snapshot`（`simulation_runtime.gd:12617-12621`）は、`latest_snapshot` と**同じ dict の object** を、`snapshot_published` と `state_updated` に渡しています。
  - `latest_digest` は、遅延して `latest_snapshot` から計算されます（`:151-156`）。
  - したがって、受け手が引数の dict を変更すると、`latest_snapshot` が変わり、まだ計算していない digest もその変更を反映します。現在の受け手（`main.gd:973-976`、`world_preview.gd:2018-2039`）は引数を使っていないので、実際の誤動作は観測されていません。しかし、E5（外から内）の試験は、**現在の source で失敗すると予想します**。
 - **判定の扱い**:
  - harness の正しさは、前の版どうしを比べて差が0であること（決定性）で確かめます。これは E の合格とは別のことで、「全 E の合格」とは扱いません。
  - E3 と E5 は、版ごとの絶対の検査です。前の版で失敗したもの（上の E5 を含む）は、**既存の不具合として記録**します。その修正が OPT の許可範囲にあるもの（上の E5 は `simulation_runtime.gd` の中）は、OPT に含めます。許可範囲の外のものは、判断に戻します。
  - OPT の後の版では、全ての E の合格を要求します。
 ## 4. 比較（全て pin する。Root が実行し、版を明記する）
 共通の引数:
 - `--readonly <collector の元の runtime の build/p28-01-readonly（元の manifest の destination root）>`
 - `--fixture artifacts/original-completion-2026-10-02/p28-current1299-runtime-scale-build-candidate-native-r01/fixture/reference.variant`（`eb4f7700…`）
 - `--engine /Applications/Godot.app/Contents/MacOS/Godot`（`c7cccbf8…`）
 `--output` は毎回新しいものにします。各実行は、その版の凍結した checkout（HEAD の検査済み）で行います。
 | 比較 | 前の版 | 後の版 | 実行するもの | engine の phase の数 |
 |---|---|---|---|---|
 | (a) phase の比較（headless、手動の stepping） | 既存の DIAG の native の bundle（S `d6ce6dd`、3 PID）を**再利用**します。条件: 製品の source map が `651f7036…` で、DIAG の5ファイル・engine・fixture・設定が一致すること | OPT の S で `python3 docs/plans/original-completion-2026-10-02/execution/p28-02/diag/diag_p28_02.py --run <共通> --output artifacts/original-completion-2026-10-02/p28-02-opt/phase-after-<S>-r01` を1回実行（3 PID） | DIAG の driver（変更なし） | 後の版の1回で6（import、parse 2つ、diag 3つ） |
 | (b) frame の予算の比較（windowed、`process_real_delta`） | 既存の full9（`db9d613`、製品の source map は同じ `651f7036…`）を1回分として**再利用**し、残りの2回を `collect_p28_01.py --run <共通> --output …/frame-before-r0{2,3}` で実行 | OPT の S で `collect_p28_01.py --run <共通> --output …/frame-after-<S>-r0{1,2,3}` を3回実行 | 受入済みの collector（変更なし） | 新規5回×9（import、parse 2つ、R0・P1・P2・O0・P3・P4）= 45 |
 | (c) RESTART | — | OPT の S で `python3 docs/plans/original-completion-2026-10-02/execution/p28-01/restart/probe/restart_pair.py --run <共通> --output …/restart-after-<S>-r01` | RESTART の driver（変更なし） | 7 |
 | (d) 関連回帰 | — | OPT の S で `python3 tools/run_all_tests.py --project-root <凍結した S の checkout> --godot /Applications/Godot.app/Contents/MacOS/Godot --output …/full-roster-<S>-r01` | 正式の runner（192 suite） | 約194 |
 | EQ | EQ の final の Q で、`eq/run_eq.py --run <共通> --output …/eq-before-r01` | OPT の S で、同じコマンドで `--output …/eq-after-<S>-r01` | EQ の harness（凍結） | EQ の設計による（R と O、各1 PID 以上） |
 - (b) で全 phase が必要な理由: collector の PHASES は固定で、P1/P2 の前の R0 は、stage0 の外挿の入力です（collector の H6）。O の phase だけを外すには collector を変えるか、PHASES を差し替える必要があり、それは正式の経路ではなくなります。O の phase の値は記録しますが、T1 の判定には使いません。
 - P1/P2 を各3 PID にするには、collector を3回実行する必要があります（1回の実行で、P1 と P2 の PID はそれぞれ1つ）。前の版は、既存の full9 を1回分として数え、重複を避けます。
 - **証拠の判定**:
  - 実測の値（前後の平均・P95・最大・各 PID の値）をそのまま示します。新しい数値の目標は作りません。
  - 「改善した」と書いてよいのは、I11（と、(b) の P1/P2 の kernel の標本）で、後の版の3 PID が前の版の3 PID と重ならずに低い場合だけです。重なる場合は「差は確認できない」と書きます。この規則は管制の提案で、独立レビューの確認を受けます。
  - 予算の false 6件は、改善が無ければそのまま残します。
  - E1〜E5 が1つでも崩れた変更は、採用しません。
 ## 5. S での実行と Q での再利用（実行した版を偽らない）
 - (a)(b)(c)(d) と EQ の後の値は、OPT の**提出された S** で実行し、「S で実行した」と記録します。Q で実行したとは呼びません。
 - integration の後の Q で再利用してよいのは、次の全てが一致する場合だけです。それ以外は、Q で必要な検証をやり直します（source が変われば、全 roster と (a)(b)(c) を Q で実行します）。
  - 製品の source map の全件（件数と、各ファイルの SHA）
  - 試験の roster（`tests/**/test*.gd` の集合と SHA）
  - marker の契約（`completion_marker_contracts.json` の SHA）
  - `project.godot` と `export_presets.cfg`
  - engine の SHA
  - 入力の fixture
  - collector・DIAG・RESTART・EQ・OPT の各ファイルの bytes
  - runner（`tools/run_all_tests.py` と `tools/regression/*`）の SHA
  - 実行に使った readonly の入力
 - integration で main 側の他の変更が source map に入った場合は、再利用しません。
 ## 6. 依存の順序
 1. DIAG が通常の final に達する。
 2. Root が、この契約を原本の条件と照合して、main に固定する。
 3. EQ の登録 → 実装 → validation → 独立レビュー → 統合 → final。
 4. Root が、EQ の final の Q で EQ の前の値を取る（前の版の E3/E5 の失敗は、既存の不具合として記録する）。(b) の前の版の2回を実行する。
 5. OPT を登録して実装する（許可された既存の製品ファイルだけ。前の版の E の失敗のうち、範囲の中のものの修正を含む）。
 6. 提出された S で、Root が EQ の後の値、(a)、(b) の後の3回、(c)、(d) を実行する。
 7. OPT の validation（unit と、全ての bundle の verify）。
 8. 独立した新しい Opus が、原本の work と acceptance、横断条件6件、U1/U2 を whole-unit としてレビューする。
 9. 統合 → Q での再利用の資格の確認（§5）→ final。
 10. 台帳で 23→24。
 ## 7. 担当
 - EQ と OPT: codex `gpt-6-astra`。
 - レビュー: 独立した新しい `claude-opus-5-5`（Desktop、非同期の配送）。
 - native、比較、全 roster の実行: Root。
@@ -0,0 +1,39 @@
 OPUS_D2_SCOPE_CLARIFICATION（P28-02-DIAG。base 8c06c3b44235a52f35898b1f6263e8ee064af256 の SPEC §3.1・§3.3、D2 の「live の全状態」の境界を確定する。原本の条件、SPEC、TASK_INSTRUCTIONS、baseline は変更しない。TASK_INSTRUCTIONS の全指示は従来どおり守る）
 この確定の位置づけ
 - 「全状態」を、製品が保存する状態（S 層）と、それに関わる、名前を挙げた有限の内部状態（K 層・C 層）の和として定める。対象を独自に除外することも、無差別な走査を足すこともしない。比較は、tick の外の各計測（snapshot の変換、scratch の restore・save・load・validator）の前と後で行う。
 - 製品の値や仕様の変更の承認ではない。診断の観測の副作用が無いことを確かめるための、比較の範囲の具体化である。
 S 層: 製品が保存する状態（必須）
 - SimulationRuntime.create_snapshot() が返す Dictionary の全体を、var_to_bytes で完全一致させる（SimulationDigest だけでは不可）。
 - 差がある場合は、RESTART の修正8で確定した typed の正規表現（文字順の key、衝突は拒否、typeof・配列の順序・値を保つ）で path を特定して報告する。dict の列挙の順序だけの差も、path つきで記録する。
 K 層: kernel の、保存されない内部状態（名前を挙げたものだけ。get() で受動的に読む）
 - GameClock: absolute_minute、speed、paused、snapshot_version、_accumulator（f64 の hex）、_skip_next_process、_pause_request_serial、_abort_current_tick_requested、_last_tick_advanced。
 - _phase_handlers: phase ごとの handler ID の集合を、文字で並べた一覧として比べる。Callable の同一性は比べない。
 - performance_budget: _sample_counts、_totals、_samples（metric ごとの配列）。tick の外の計測でこれらが変われば、失敗にする。
 - 前後で完全一致を要求する。
 C 層: Runtime の内部キャッシュ（create_snapshot が書き換えうるもの。autoload/simulation_runtime.gd:134-136、:11183-11200）
 - _mvp_manifest_cache_generation、_mvp_manifest_cache_catalog の同一性（get_instance_id）、_mvp_manifest_cache の var_to_bytes。
 - 規則:
  - (a) 計測の前に cache が満たされていること（generation が現在の catalog の get_manifest_generation() と一致）を記録する。満たされていなければ、計測の外で create_snapshot() を1回呼んで満たし、その事実を記録する（cache が埋まったのは、計測より前の準備としてである）。
  - (b) 計測の区間の中で cache miss（generation か catalog の変化、または cache の bytes の変化）が起きたら、その計測の標本に cache_miss_in_sample=true を付けて記録する。値は捨てず、cache の再構築を含む inclusive の値として扱う。黙って除外したり、平均に混ぜて隠したりしない。
  - (c) 計測の後の C 層が、計測の前と完全一致すること。(b) の miss があった場合は、その後の cache が、現在の catalog から作った manifest と一致することを確かめる。古い値や他の値が残っていれば失敗にする。
 - これは、P28-02-OPT の E4（キャッシュの古さ）と E5（所有権）の診断側の前提である。create_snapshot() が cache の deep copy を返すことも記録する（:11185-11199）。
 observer の副作用の検査（有限）
 - 診断が接続する signal（tick_started、tick_phase_started、tick_completed、path_query_measured）について、接続の前と、切断した後で、各 signal の get_connections() の件数と、接続先の object と method の一覧が一致すること（診断の分は除く）。
 - 診断で DomainEventStream に subscribe した場合は、unsubscribe の後に、subscriber の一覧が元に戻っていること。
 scratch の参照の漏れの検査
 - scratch に渡すのは、live の snapshot の deep copy だけ。scratch の操作の後で、S 層・K 層・C 層が完全一致すること。scratch の Runtime や関連の object を解放した後に、それらの instance ID が is_instance_id_valid で無効になっていること。scratch の path は private user:// の下に限る。
 起動の構成（未指定だった点の確定）
 - 代表入力 R は、collector の SPEC §4.3 と同じ順序で既定の autoload に復元し、main を追加する（headless）。こうすることで、同期の受け手（state_updated などに接続する main 側の処理）が、実際のゲームと同じように I11 の inclusive の区間に入る。保存の policy による autosave が区間の中で起きたら、事実として記録する。
 対象の外（理由つき）
 - Object の参照や循環の無差別な走査、engine・描画・OS の状態、node の木の全体: 製品の永続状態でも、P28-02 の計測で変わりうる内部状態でもないため対象外とする。上の K 層・C 層・observer・scratch の検査で、診断の副作用は検出できる。
 報告
 - 各計測の前後の S/K/C 層の SHA と一致の結果、cache の状態、observer の接続の件数、scratch の解放を、report に記録する。測れない項目は、理由つきの未測定にする（0 で補わない）。上記で決めきれない不足は、具体的な箇所を示した場合に限り blocked にする。
@@ -0,0 +1,50 @@
 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 の禁止、測れない項目を理由つきの未測定にすること）は、すべて従来どおり。
@@ -0,0 +1,56 @@
 [
  {
    "id": "P28-02-EQ1",
    "requirement_id": "P28-02",
    "text": "E1 全状態: 観測の区間では、同じ PID の中で完全な S/K/C の前後の一致を確かめる（SPEC §3.3 (a)）。版の間では、S 層・latest_snapshot・latest_digest と、SPEC §3.2 に列挙した K/C の欄を比べる。比べない欄は理由と実際の値を記録し、SimulationDigest だけで判定しない。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  },
  {
    "id": "P28-02-EQ2",
    "requirement_id": "P28-02",
    "text": "E2 全イベント: DomainEventStream.subscribe('*') で B1 の後から30分の最後まで、全件を上限なく記録し、開始の counter が一致する場合だけ、event ID をそのまま対応させて全ての欄を比べる。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  },
  {
    "id": "P28-02-EQ3",
    "requirement_id": "P28-02",
    "text": "E3 失敗時の拒否: restore_snapshot・SimulationSnapshot.validate・load_from_path に、欠けた key・違う型・範囲外・重複した ID・改ざんした world.bin を与え、code と、拒否の前後の S/K/C と全イベントを記録して検査する。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  },
  {
    "id": "P28-02-EQ4",
    "requirement_id": "P28-02",
    "text": "E4 キャッシュの古さと E5 所有権: SPEC §3.3 (b) の専用の scenario の区間で、列挙した操作（コマンド・tick・restore・load・状態を変えないコマンド、返した値の入れ子の変更）だけを行い、前後の変化と双方向の非干渉を実際の値として記録して検査する。前の版での失敗（たとえば E5 の aliasing）は、既存の不具合として記録する（PASS で補わない。harness の無断の変更とは区別する）。列挙の外の状態の変更と、hook の差し替えは禁止。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  },
  {
    "id": "P28-02-EQ5",
    "requirement_id": "P28-02",
    "text": "harness の正しさ: R と O の、同じ版の2 PID の間で、版の間の比較の差が0であること。compare_versions.py が、before の source map と OPT の許可された差分の集合を完全に固定し、追加・欠落・登録されていない差分を拒否すること。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  },
  {
    "id": "P28-02-EQ6",
    "requirement_id": "P28",
    "text": "提出された S_eq の native（import、parse 2つ、R-A・R-B・O-A・O-B）を Root が実行し、owned PID・private profile・guard・cleanup・source map 1407・全 raw と SHA を結合する。Q で測ったとは表記しない。",
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ]
  }
 ]
@@ -0,0 +1,7 @@
 {
  "project": "the-tree-p28-02-eq",
  "models": {"implementer": "codex gpt-6-astra", "reviewer": "claude-opus-5-5 (fresh, Desktop async delivery)"},
  "policy_alignment": "After normal registration, align max_llm_runs 20 -> null with the existing owner script protocol (policy lock, config digest, backups, unchanged rows and baseline, normal Runner reopen), recorded honestly as an owner-delegated decision under the existing human removal of per-item caps. max_repair_attempts stays null.",
  "unchanged": ["models of existing projects", "permissions", "auth", "billing and API fallback", "quota fallback rule (structured provider quota only, once, same role, Antigravity claude-opus-5-5-high)"],
  "original": {"completed": 23, "denominator": 88, "packages_completed": 4, "package_denominator": 30, "eq_credit": 0}
 }
@@ -0,0 +1,111 @@
 {
  "status": "candidate; not registered, dispatched or run. Root verifies it against the original conditions, fixes eq/SPEC.md and eq/TASK_INSTRUCTIONS.md to main, and fills base_commit with that actual SHA.",
  "tracked_paths_to_commit": {
    "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/SPEC.md": "eq-registration-proposal-r01/SPEC.md",
    "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/TASK_INSTRUCTIONS.md": "eq-registration-proposal-r01/TASK_INSTRUCTIONS.md"
  },
  "register_project": {
    "project": "the-tree-p28-02-eq",
    "repo": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部",
    "worktrees": "/Users/korizatou114/Projects/TheTree-managed-worktrees/p28-02-eq",
    "baseline_file": "eq-registration-proposal-r01/ACCEPTANCE_BASELINE.json",
    "validations": {
      "p28-02-eq-unit": {
        "argv": [
          "{python}",
          "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/test_eq.py"
        ]
      },
      "p28-02-eq-native-verify": {
        "argv": [
          "{python}",
          "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/verify_eq.py",
          "--project-root",
          "."
        ]
      }
    },
    "validation_note": "native-verify reads the Root-built bundle at $BUILD_OUTPUT_DIR/p28-02-eq-evidence and fails when it is absent; unit PASS alone never accepts."
  },
  "register_task_contract": {
    "id": "P28-02-EQ",
    "title": "意味を保つ軽量化：同等性の先行固定（harness）",
    "requirement_ids": [
      "P28-02",
      "P28"
    ],
    "acceptance_ids": [
      "P28-02-EQ1",
      "P28-02-EQ2",
      "P28-02-EQ3",
      "P28-02-EQ4",
      "P28-02-EQ5",
      "P28-02-EQ6"
    ],
    "spec_ref": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/SPEC.md",
    "base_commit": "TBD: actual main SHA that adds eq/SPEC.md and eq/TASK_INSTRUCTIONS.md",
    "worker": "codex",
    "allowed_paths": [
      "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/**"
    ],
    "depends_on": [],
    "resource_locks": [
      "p28-02-eq"
    ],
    "validation_ids": [
      "p28-02-eq-unit",
      "p28-02-eq-native-verify"
    ],
    "max_repair_attempts": null
  },
  "native_contract": {
    "executor": "Root only, after the worker submits S_eq",
    "argv": [
      "python3",
      "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/run_eq.py",
      "--run",
      "--readonly",
      "<collector original runtime build/p28-01-readonly (original manifest destination root)>",
      "--fixture",
      "artifacts/original-completion-2026-10-02/p28-current1299-runtime-scale-build-candidate-native-r01/fixture/reference.variant",
      "--engine",
      "/Applications/Godot.app/Contents/MacOS/Godot",
      "--output",
      "artifacts/original-completion-2026-10-02/p28-02-eq/native-<S_eq>-r01"
    ],
    "phases": [
      "import",
      "parse-base",
      "parse-wrapper",
      "R-A",
      "R-B",
      "O-A",
      "O-B"
    ],
    "pins": {
      "fixture_sha256": "eb4f770071eb07cd7e136fe54c3f78768cc8de7a4264e62a9af1f06a8f90f9bd",
      "engine_sha256": "c7cccbf8fb143e34e02fd6521e09be2c2b974f0d5db080b19071c9c570718ccf",
      "product_source_map_sha256": "651f703621c8ed06a724709f75d8bc05b1eef2988c3b3d5d3466096a3f759bf0",
      "machine": "Mac16,10"
    },
    "bundle_place": "$BUILD_OUTPUT_DIR/p28-02-eq-evidence"
  },
  "sequence": [
    "worker submits S_eq (local unit PASS)",
    "Root native on frozen S_eq (7 phases)",
    "Root raw join and bundle",
    "formal validation: p28-02-eq-unit + p28-02-eq-native-verify (both required)",
    "fresh independent Opus review, async delivery",
    "prepare -> Q_eq qualification (product map, engine, input, settings, EQ files equal) -> Root delegated approval -> integration -> final",
    "the S_eq native is the OPT 'before' EQ record; reused only when the Q_eq qualification holds, otherwise rerun on Q_eq",
    "then the two remaining frame-before collector runs on Q_eq (OPT_CONTRACT_T1 r02 section 4 (b))"
  ],
  "assignment": {
    "worker": "codex",
    "model": "gpt-6-astra",
    "reason": "Astra built DIAG and RESTART with the same lifecycle, S/K/C, owned-phase and import-closure machinery and already hit and fixed this repo's GDScript pitfalls; EQ reuses all of them.",
    "reviewer": "fresh independent claude-opus-5-5 via Desktop async delivery"
  },
  "failure_retention": "All native, validation and review failures are kept with raw and SHA and never rewritten as success; fixes go through the normal repair on the same W.",
  "credit": "EQ adds 0; P28-02 moves 23->24 only after OPT, its whole-unit review, integration, final and the ledger."
 }
@@ -0,0 +1,76 @@
 {
  "at_jst": "2026-10-21T07:15:27.303190+09:00",
  "actual_Opus_governor_session": "local_a7f85421-3eed-4482-8030-c0dca669573a",
  "actual_Opus_request": "303; actual response304 prepared five concrete proposal files",
  "scope": "Original P28-02 same scope; EQ support only, original credit zero",
  "copies": [
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/SPEC.md",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-registration-proposal-r01/SPEC.md",
      "bytes": 10693,
      "sha256": "3791ccdcb87e8d71fe9205e1e692ebca9e0f974ea3b5fbc4fbb3943882131f1c",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/TASK_INSTRUCTIONS.md",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-registration-proposal-r01/TASK_INSTRUCTIONS.md",
      "bytes": 2961,
      "sha256": "f9937c3c7dff5a25ada453365d26c87fecf009d29518724f0c1e67d2b18afff3",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/registration/REGISTRATION_PROPOSAL.json",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-registration-proposal-r01/REGISTRATION_PROPOSAL.json",
      "bytes": 4733,
      "sha256": "9590fc853a4df8d50cc0d269d23bd9c844dc6931590ff6f24ebf95bb54a8d135",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/registration/ACCEPTANCE_BASELINE.json",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-registration-proposal-r01/ACCEPTANCE_BASELINE.json",
      "bytes": 2981,
      "sha256": "84628bc21205387f8a7143031bdc50c9f68a767d350e6c34b32e0ba1c7059337",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/registration/CONFIG_PROPOSAL.json",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-registration-proposal-r01/CONFIG_PROPOSAL.json",
      "bytes": 821,
      "sha256": "775fbbb97cda8b4d4991defdf7871b0fc79f489f4dea34c1733d4830426cf1df",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/references/OPUS_D2_SCOPE_CLARIFICATION.txt",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/OPUS_D2_SCOPE_CLARIFICATION.txt",
      "bytes": 5598,
      "sha256": "5775e7b512d9e90dbcfbcb181f5b64dc0fa8207e0947c0a4a6a5c9195565f9bd",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/references/OPUS_STARTUP_LIFECYCLE_CLARIFICATION.txt",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/OPUS_STARTUP_LIFECYCLE_CLARIFICATION.txt",
      "bytes": 5996,
      "sha256": "967aebf27ff412f7a16ce771ef7d68abf8cfde0bb76ed19cf6dbf2817ca7acc6",
      "byte_identical": true
    },
    {
      "target": "docs/plans/original-completion-2026-10-02/execution/p28-02/eq/references/OPT_CONTRACT_T1.md",
      "source": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/OPT_CONTRACT_T1.md",
      "bytes": 13952,
      "sha256": "ad9f3d76f3500b39263fb898d7c64588b4b47c9e11b456f938195261fd054d16",
      "byte_identical": true
    }
  ],
  "existing_tracked_readonly_references": [
    "docs/plans/original-completion-2026-10-02/execution/p28-01/restart/SPEC_CLARIFICATION_01.md",
    "docs/plans/original-completion-2026-10-02/execution/p28-01/restart/SPEC_CLARIFICATION_02.md"
  ],
  "registration_and_worker_not_started": true,
  "original_completed": 23,
  "original_total": 88,
  "packages_completed": 4,
  "packages_total": 30,
  "product_files_changed": [],
  "actual_Opus_scenario_clarification": "Request305/actual response306; SPEC3.3 and TASK/AC boundaries explicitly distinguish observation and intentional E3/E4/E5 scenarios",
  "pre_clarification_full_bytes_preserved": "/Users/korizatou114/Projects/とりにく工房ゲーム制作部/artifacts/original-completion-2026-10-02/p28-02-root-control-r01/eq-proposal-pre-scenario-clarification-preserved"
 }