P28-02-DIAG: 意味を保つ軽量化：実測上位の特定（受動的な診断）
This commit is contained in:
Agent Control Runner
@@ -0,0 +1,83 @@
|
||||
# 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秒）。
|
||||
Reference in New Issue
Block a user