同じP04-01の9767b0a提出を再監査して具体的な次の指示を決めてください。Rootはchecker/製品/spec/Runnerのどれも直接変更していません。現Runnerは登録validate実行後のrepair_pendingです。今回エンジン/worker/repairは起動しない読取判断のみ。まず .review-material/d05-current-9767b0a/ のSOURCE_MANIFEST.json、POST_P18_CURRENT_SOURCE_APPLICABILITY.json、registered-validation.json と stdout/stderr を読み、actual failを確認してください。出力は「p04-evidence/index.json が無い」で、Rootは合格入力を捏造していません。checkerの10反例は実装者確認のみ、Rootも独立確認予定です。P18 backendは同じmainに通常統合・final済み、現main 5f6bc11d6bb6e92d22d787989b219fef3a435bc1。Rootは登録版対current版の20順序関数を全行bytes比較し20/20一致、spec6pinsは5一致/Runtimeのみ不一致を再確認しました。登録Runtime d52a995と現Runtimeは異なり、今のchecker:verifyはspec.current_source_pinsの全値をcurrent sourceへ無条件等置するため、現mainに普通に統合すると必ず stale/immutable pinで落ちる設計です。REACH_REFSの固定行番号もcurrent Runtimeにはずれます。現Runtime全文のSHA一致コピーをcurrent-source/autoload/へ置き、原本は変更していません。原P04条件・仕様・契約の意味を緩和せず、古いpinを現行として偽装せず、DB直接編集・policy/hook回避・別プロジェクト重複実装もせずに、正しい現在版の証拠と通常統合が可能になる最小の正規手順を具体化してください。既存specが適用性比較を意図するなら登録版pinとactual tested sourceの役割を明示して必ず原本に追跡する設計が必要で、単なるpin検査削除は不可です。今の固定必須15条件+到達するEV予約のraw証拠不足を正確に分けてください。raw_origin=engineや自己申告countsだけで真のnative実行/状態・台帳・保存同一性が証明されるのかも独立に判断し、必要なら証拠生成argvとRootの収集手順を確定してください。Rootは既存のguarded native phase基盤、p04-01-shift-end-repro-r03.gd（古い誤期待を含む負履歴）、power/formal/midnightの既存wrapperとtyped状態を保持しており、全回帰の再実行より有限境界の再利用/不足追加を優先します。承認D05二件とD034/A01は確定、未確定帰属を決めずに安全性の必須原条件を証明する。3受入結果・7領域・30/88不変、部分点0。次の修正指示は実行可能な具体ファイル・検証・独立レビュー・current統合の適用条件・容量/時間を示し、sourceの事実と提案と未検証は区別してください。
