同じ9767b0aのrequest-repairを通常dispatchし、repair_ready、実カウンタ4/max nullです。元の受入・allowed_pathsを維持してrun開始判断をお願いします。あなたの前判断を下記に全文保持します。判断をworkerへ渡すrun reasonは省略せず具体的にしてください。追加のユーザー指示を優先します: 関連条件を安全にまとめ、重複試験と再実装を避けます。前判断の「1 case=1 process、16+1個の実行」は必須原条件ではありません。同じ実行で複数の条件を証明できるなら束ね、状態/seed/receipt分離と正式Reader別PIDは維持する。15+EVは条件の被覆であって、プロセス件数を増やす目標にしない。旧証拠39件も具体的適用性が成立する部分は再利用する。
probeを新規製品testsへ置く権限拡大は不要です。既存guarded native wrapperは、元の製品source_mapを保持し、private stageに実診断QAを既存testpathへ明示上書きしてselected_source_map/QA_overrides/marker/全parse/source+profile不変/owned cleanupを記録しています。この先例のPython10文書とGD probeは .review-material/native-existing-sources/ にbyte一致コピーし、実体は build_dir/audit-support/p04-native-existing-sources/ にも置きました。古い1299 pinやr03の誤期待は実行せず負履歴として保全してください。これを実際に読んで、既存基盤を再実装しないでください。workerが必要な診断probe/collectorソースを制作する場合も execution/p04-01/** 内だけに置き、Rootが独立してnative収集を実行します。製品と既存testsは変更しない。engine実行はworkerには許可されていません。collectorを新設するより既存wrapperのRoot継続用に必要な差分・実行契約を確定し、足りないprobeだけ作ります。
登録Runtimeと現在Runtimeで2種の証拠が必要なら、その理由と再利用できる有限条件を明示し、原則は最終の正確な版での検証を優先する。別候補のreceiptのSHAを書き換えて流用せず、実行元/登録版/tested版/統合版を区別してください。新nonceやログ文字列だけをnative真正性の代用にせず、既存guarded owned_outerの起動・終了・隔離・source/settings/input/engine guardへ結合すること。無限repairや同じ自己申告checker検証の繰返しで済ませず、P04原条件を本当に閉じる実用的なprobe/収集契約まで今回の同じ修正に含めてください。
先の実Opus判断全文:
【sourceで確認した事実】(1) registered-validation.json: p04-acceptance exit 1。stdoutは {"machine_verified":false,"error":"missing/outside file: index.json"}、stderrは0バイト。checkerの意図どおりのfail-closedで、p04-evidence/index.jsonが無いことだけが原因。Rootが合格入力を捏造した形跡はない。(2) POST_P18: 20個の順序関数本体はbytes一致20/20。spec pin 6件のうち5件は一致し、Runtimeのみ登録d52a995と現在7f01b2dc(5f6bc11)で不一致。(3) checkerの216-217行目は spec.current_source_pins を index.source_map に無条件で等置し、215行目はsource_mapを実checkoutと照合する。このため現mainへ通常統合したtreeでは必ず 'immutable source pin' で落ちる設計欠陥がある。(4) REACH_REFSは固定行番号。現Runtimeでは _execute_create_staff_task が6733→6740行へ+7行ずれており、'reachability source text' でも落ちる。(5) receipt、raw_origin=engine、observation内countsはすべてindex提供者のJSON自己申告。checkerは実プロセス・native実行・台帳・保存同一性を独立に証明していない(PID/exit_codeもJSON値)。(6) 必須はREQUIRED15条件(power_stop, destruction_stop, dependency_stop, shift_completion, recovery_completion, same_minute_replay, closure_release, exit_release, patience_release, paused_midnight, midnight_settlement, midnight_replay, save_restore, night_staff_absent, overtime_task)とEV予約到達ケース1件。raw engine証拠は16件すべて0件。transportはreach=false根拠のみ必要。r03は誤期待を含む負履歴なので合格証拠に使えない。

【修正指示(allowed_paths内: tools/check_p04_order_evidence.py と execution/p04-01/**)】
A. 版の役割分離。spec.current_source_pinsは削除・緩和せず「registered_pins」として扱う。各pinについて、checkerが自分で `git show <task.base_commit deb1bcb>:<path>` のsha256を計算してspec値と一致させ、原本へ追跡する。tested版はsource_map=実checkoutとする。登録≠testedの場合だけ、次をcheckerが自分で計算する場合に限り適用性を認める: (i) 固定20順序関数の本体bytesが一致すること(関数抽出規則はchecker内に固定)。(ii) `git diff base..HEAD -- <path>` の変更関数集合を算出し、index.applicability_delta の自己申告と完全一致すること。(iii) 変更関数のうち境界経路に関わるもの(relationship restore/schema、path/arrival、save/restore)には、それぞれ対応するengine case IDが必須であること。上記以外の不一致はstaleとしてfail。古いpinを現行として偽装してはならない。
B. REACH_REFSを行番号から (path, func名, 本文行のsha256アンカー) に変更し、tested source上で解決する。
C. 自己申告を排除する。各count条件は、observation内のスカラーに加えて、state artifactの生台帳/予約配列(service/settlement単位のdump)へのcount_eqまたはsame_literalを必須にする。case receiptにはargv、Root生成nonce、probe sourceのsha(source_mapに必須)を要求する。stdoutとnative_logに nonce+case_id+after sha のengine出力行があることもcheckerが検査する。save_restoreは、restore後のstate dumpがsave前の台帳・予約とsame_literalで一致すること、および別PIDであることを必須にする。
D. 証拠生成の契約を EVIDENCE_COLLECTION.md に確定する。Root既存のguarded native wrapper(power/formal/midnight)とtyped stateを再利用し、1ケース1プロセスで `godot --headless --path <candidate> --script <probe> -- --case <id> --nonce <n> --out $BUILD_OUTPUT_DIR/p04-evidence/<id>/` とする。ケースは15+EVの16件と、restoreの別PID1件。不足するprobeだけを追加する。全回帰は実行しない。
E. checker_negative_fixturesへ負例を追加する: 登録pinの偽装、git diffと申告の差、行ずれ、nonce欠落、台帳とcountsの不一致、restore stateの差。あわせて、登録=testedとdelta合法の2つの正対照を用意する。

【未検証・Root/Owner判断】probeを製品tests/配下に置くにはallowed_paths外の変更が必要で、オーナー判断になる。execution/p04-01/配下からwrapperで読み込めるかは未検証。適用条件: worker修正 → current main基準の候補でRootが16+1件の証拠を収集 → validate → 別セッションでの独立レビュー → 通常統合。D05未確定の帰属は決めない。D034/A01は再承認しない。3受入結果・7領域・30/88は不変、部分点0。容量の見込み: workerはPython1ファイル(約+200行)と文書で1回。Root収集は17 headless実行(各数分以内)。
