7.2 KiB
P28-02-DIAG repair2 実装提出
対象: P28-02-D1/D2/D3/D4。変更範囲はこの diag ディレクトリのみ。
製品、SPEC、TASK_INSTRUCTIONS、validation、予算、分母は変更していません。
git 書込み、engine 起動、他エージェント、Runner 操作は行っていません。
局所試験は engine 不使用の python3 test_diag.py。生出力は UNIT_OUTPUT.txt。
native import/parse/3 PID、正式 validation、独立レビューは未実行で、Runner/Root の担当です。
適用した補足（ユーザー DATA の全文）:
- OPUS_D2_SCOPE_CLARIFICATION:
5775e7b512d9e90dbcfbcb181f5b64dc0fa8207e0947c0a4a6a5c9195565f9bd - OPUS_STARTUP_LIFECYCLE_CLARIFICATION:
967aebf27ff412f7a16ce771ef7d68abf8cfde0bb76ed19cf6dbf2817ca7acc6 - SPEC strip SHA:
0420dd4d2a95db65adc685bca91b9ff686650af31675f193992d75909a676ac6
実装上の選択
- startup は pause → R の SHA と get_var(false) → restore → pause → main → 2 frame。 main の前後、各 frame 後、B0/B1、復元直後を記録します。speed 操作や resume はありません。
- warm と measurement は各30回の advance_minutes(1)、各回後に1 frame await。 tick ID、13本の信号境界、query を全件残します。I0〜I11 は checker が差分で算出します。 tick 完了後から次の tick 開始までの wall は独立欄です。warm は順位・統計から除きます。
- wall は observer を含む inclusive 値です。callback 自身の時間を別記し、引きません。 自身の最終時刻取得後の timing record の追加・return は自己費用の計測外です。
- 各区間について平均・nearest-rank P95・最大・N、query 件数・合計・統計を再計算します。 平均 wall の降順（同値時は区間番号）による3回の順位と一致結果を保持します。 query が0件なら件数・合計は実測0、query の平均等は null と理由にします。
- Runtime、GameState、Runtime が create_snapshot を呼ぶ32 service を各 N=5 で独立計測。 service 一覧と現在の製品 source の一致も unit で検査します。合算はしません。
- 各 sample 前後の S/K/C の bytes を probe 内で完全比較し、全層の SHA、K の値、C の状態、 差分 path を report に残します。S 不一致時のみ型・key・配列順を保持する正規形で差を説明し、 dict 列挙順だけの差も失敗扱いです。診断では OPT の同等性緩和を適用しません。
- C を S の観測前に読んで、観測自体の cache 書換えを隠さない構成です。 cache miss は値を保持したまま明記し、公開 catalog 読取から manifest の一致も検査します。 前後 C 完全一致の条件を満たさなければ失敗です。返却 manifest の top-level と配列を caller 側で変更して live が変わらないことも検査します。
- scratch は snapshot の deep copy と tree に追加しない Kernel/GameState です。 deep copy、SimulationSnapshot.validate、SimulationSnapshot.restore（envelope のみ）、 SaveService.save_snapshot/load_snapshot を各 N=5。load 用保存は計測外です。 各操作後に scratch のコンテナを変更して S/K/C が保たれることを検査し、 Kernel/GameState/budget の instance ID が解放後に無効であることを検査します。 保存先は guard 後の private user://p28_diag/scratch/ 配下です。
- Runtime 全体の restore は initialize が必要で、列挙された scratch API 外のため理由つき未測定。 Runtime 内部 validator と connector 再構築も、公開の独立観測境界がないため理由つき未測定。 envelope の値を Runtime 全体の値、query の値を connector 全体の値とは表記しません。
- SaveService は静的 API ですが、渡すデータと path は scratch だけです。静的な SaveService 自身の 診断 budget は更新されます。これは補足の S/K/C 境界には含まれません。live Kernel の budget は 全量比較の対象です。Runtime オブジェクトを scratch として起動したという主張はしません。
- observer は main と2 frame の準備後に接続します。指定4 signal に加え、autosave の発生を 記録する save_operation_completed にも受動接続し、終了前に全て元の接続一覧へ戻します。
- PID 内の C 同一性には instance ID を含めます。PID 間では ID の数値を比べず、同一 catalog を 指す関係・generation・manifest bytes を比較します。K の PID 間比較は補足に列挙された6項目 （minute、paused、pause serial、skip、snapshot version、handler 集合）です。K の全 SHA と budget の実測時間は PID 間の同一条件にしませんが、raw と PID 内の検査には全量残します。
- 初期条件不一致は値を raw に保持して失敗し、管制判断へ戻します。実測を補正しません。
Root の実行インターフェース（worker は実行しない）
凍結した S を checkout した環境で、以下の CLI を使います。--check は読取と計画の表示だけです。
--run は import → parse-base → parse-wrapper → diag-1 → diag-2 → diag-3 を順番に実行します。
python3 diag_p28_02.py --check|--run --readonly <p28-01-readonly> --fixture <reference.variant> --engine <Godot> --output <new-directory>
driver は6ファイルの依存 SHA を確認して collector を読取専用 import します。 RESTART の依存検査・owned raw 結合のコードを局所に適合して再利用していますが、 RESTART の Python 自体は import しません。追加 package、ネットワークは使いません。 全1407 source と提出した5コードファイルが frozen commit S と同じことを確認します。 private profile、guard、1800秒 owned timeout、audio close drain、cleanup は collector と同じ経路です。
成功時、driver が execution.json と、stage 以外の全ファイルを SHA/size で列挙した bundle.json を 作ります。これは Root による実行結果です。失敗時は execution.json を保存し、成功 bundle を作りません。 stage は Root に残し、各 phase の全 stage inventory を execution.json に記録します。 全 raw、owned receipts、guard、startup project、probe/wrapper、入力 manifest は bundle に含みます。 通常の profile ファイルも collector と同様に inventory を保存し、owned process cleanup と混同しません。
Root は出力一式（stage は省略可）を $BUILD_OUTPUT_DIR/p28-02-diag-evidence に置きます。
python3 verify_diag.py --project-root . は bundle 欠落を拒否し、全 raw/SHA/PID/guard/cleanup と
現候補の1407 source・5コードの一致を結合します。S の実測として記録し、Q の実測とは呼びません。
bundle 作成後にファイルを追加・編集すると inventory 不一致で拒否します。
原本加算は0、正式完了23/88、4/30、予算 false 6件を保持します。P27 完了は主張しません。 repair3: 最終の局所 unit を再実行して PASS（19件、0.780秒）。