実物が増えたため、同じP04-01の次の1アクションを再判断してください。前判断e2ad09eab7b240df8698771ce8223de0のprobe作成repairはdispatchしていません。Rootが待ち時間中に同じprobeを用意し、重複workerを避けました。repairs4、提出9767b0a、未提出6編集は全保持です。承認D05は変更しません。
今回実際に読むもの：.review-material/native-first-current/ROOT_APPROVED_DEPENDENCY_MIDNIGHT_RESULT.json、ROOT_APPROVED_DEPENDENCY_FORMAL_RESULT.json、approved-dependency-midnight.gd、approved-dependency-formal.gd、dependency-formal-native/execution.json、dependency-formal-native/restart-evidence/{writer,reader}.json、dependency-midnight-native/order-evidence/observations.json、OWNERSHIP_RAW_PROVENANCE.json。新しいrawは同mirror内に全保持。lifecycle/log/bootstrap全96ファイルもサイズ制限なくbyte一致供給。正式保存packageもdependency-formal-native/formal-packages/{writer,reader}/{before,midnight,paused,after,next}/へ全40memberを供給。stage/cache/engine本体は現在のcanonical rawに保持し、必要なら具体的pathを挙げれば追加供給できます。
Root実測：現在main5f6bc11/1338 source。依存厨房だけ公開set_facility_policy business_open=false。1439/1440/1441はsame service_00000001/reservation_00000001、elapsed44/45、財布50。1440/1441でPAUSED、実production日次close1440/maintenance4/wage0。1441に公開同idempotency keyで厨房復帰し1442でCOMPLETED/elapsed45/財布25/SERVICE_SALE25一回・予約CONSUMED、1443追加0。全typed snapshot replay一致。別runで公開SaveService Writer3854が5状態を正式保存、Reader3879が別profile/PIDで全memberをcopy/loadし、1439→1440→1441→同公開reopen→1442→1443を実行。5loaded/5persisted/4replayedの全14型付きVARが原nativeの各SHAと一致。元5save×4members=20は一切不変、copy先20とも全SHA一致。4owned PID3770/3818/3854/3879全通常終了、source/default profile/doc4不変。69/0と53/0,142/0は実測件数で原成果加点0。18:00の先行実測も維持。非ゼロ給与・command再送・EV等へ証明を拡張しません。
次はC（信頼できるnative raw/ownership/ledger/service/reservation/formal保存結合）を、この現実のraw形式に合わせて完成させるのが妥当か判断してください。既存A/Bの良い修正を保持し、Cとそれに必要な生raw改変負例のみを同worktreeで実装させたい。scalar自己申告だけの合格を拒否し、全15条件+reachable EV/原7領域/安全性3結果は固定、未収集条件は正しく未達にする。今回Rootが作ったprobe・Readerを再実装しない。存在しない39旧rawを読了/採用したとは言わない。必要rawが明確ならexact pathだけ求め、全体がないことを理由にC実装全体を止めない。原成果の完了は全条件/独立wholeレビュー/正常integration/final後のみ。
Runnerの900秒LLM予算は、あなたが認めたowner task-only adapterを専用直列CLIへ適用済み。config/digest/DBの直接編集0。対象P04/implementer/codexだけNone、finally元dict同値/同一性をassert。対象外role/task/project、例外復元、test timeout不変をstub検証、通常statusでconfig digest正常を確認。新worker起動0。通常scope/cleanup/検証/watchdog1200/モデル判断/料金は維持。ユーザーの全個別上限撤廃許可を再質問しません。
必要最小の次の実装範囲、残りのnative境界の優先順、担当モデル（既定Sol、必要な時だけあなたがAstra）、資源/所要見積をreasonへ具体化してください。RootはC実装と競合するコードを編集せず、読取証拠整備を続けます。予算や試験数ではなく原P04-01を閉じるための順序を判断してください。
