正常validateを5475391に初回1回実施しました。report e7910689a6654902b14e573c908681ab-validation.json、実check e445eb626dac4265bcc3a8bd3392f987、exit1/missing index.json/whole false。taskは正常repair_pending、使用済6/max null。再検査しません。
今回の原P04-01全体閉鎖に向けた次のrequest-repair判断を具体化してください。作業用資料は .review-material/p04-whole-closure-r01/ に21ファイル/約220KBで用意。SOURCE_MANIFESTの全copyは原ファイルSHA一致、計画用でraw全一式ではありません。Cソースと最新docsは現在547提出checkoutから直接読めます。原15条件+reachableEV/7領域/安全性3結果/全30-88/部分点0固定。既存Cを捨てず、collectorと不足probeを一つの全体計画で進め、原成果を閉じることを優先します。
重要な技術的不整合を先に解決してください。
A. 現check verify()末尾は native[production_commit] == head を無条件必須。現C提出547の製品は登録base deb1bcb系列で、実測は現本番5f6の1338 source（最新版main969の製品source全一致）です。新たなchecker/docs commitはゲームsourceが同じでもGit SHAが変わるため、このままでは正しいrawも検証と通常integration/finalを通せません。A/Bのregistered/execution_origin/tested/integrationの意味とnative product commit/checker commitを明確に分離し、元の原本とscopeを守る具体策を出してください。実測版のproduct source/config/input/environment全一致を実体から検証し、metadata-only Git差を根拠にengineを再実行する必要をなくす。一方、旧worker1299と本番1338の不一致を隠して同じ版とは呼ばない。正常登録validate→review→integration→finalの各段階に何がどの版で証明されるかを明記し、DB/config digest直接更新、偽のcommit名、scope拡大、型/値変更、source無影響の憶測、条件付き見逃しをしない。必要なら現正常Runner/登録checkerの呼出し実体をさらに供給します。
B. REQUIRED.midnight_settlement は duty_payments=1 が固定ですが、リポジトリの文字列検索でこの語はchecker1箇所のみ。原本71/72は人件費・維持費・借金返済、A01は維持費按分。Shift.record_duty_minute という勤務実績はあるが追加のduty payment通貨項目は確認できません。このfieldを捏造せず、元の根拠に沿った実測可能な定義/対応を明記してください。原15条件を削減したり期待値1を緩和しない。根拠がない別の支払いや未承認の金額を新設しない。
C. 直前reasonのRoot paidケースはservice完了1442なので、shift_completion(minute1080)の証明に転用しない。1080の証拠は別のROOT_APPROVED_SHIFT_CURRENT_RESULT.jsonとcurrent-patterns/approved-shift-current-r01.gdに存在。service requestの再送6ペアは二重生成/課金0を証明しますが、同minute決算APIの再呼出しは未実測です。midnight_replayをそれだけで合格にしない。
D. 次の不足caseを既存probeからまとめて実行可能にする: power_stop/closure_release（同Tick停電+直接休業、D-034開始済み継続と待機予約release区別）、night_staff_absent/overtime_task（未完了サービス、interrupt_level0の実taskと実勤務record）、exit_release/patience_release/destruction_stop（別case/seed系列と全typed state保存）、reachableEV（実item reservation→travel→EV powerstop→arrival）。既存ソース: existing-probes/ のpower/exit/destruction/patience、本番current-patterns/ の新shift/paid/再送とstrict wrapper/正式SaveService WriterReader。後段はRootが実nativeを実行し、actor/サービス/予約/帳簿/同minute/保存復元の全生状態とowned receiptを得る。1case1processにせず、安全にまとめられる条件は同stageでまとめる。実測前に予測PASSやcountsを書いたindexは作らない。
求める修正範囲: allowed_paths内で、上記の版識別問題を正しく解いたchecker/collector、必要な残caseプローブと既存wrapperの最小差分、現実のrawからのみindexを構築する仕組み。collector出力はderivedであることと原engine rawの区別を守り、native結合で条件ごとに再計算しなければ通らないようにする。全回帰・engineはworkerが実行せずRootで資源確認して順次実測する。C/古い証拠を再実装しない。Rootで必要なraw/templateのexact pathを挙げれば供給できる。まだ未確定のD05細則はpendingを明記し、そのために原本の安全性全ケースを一括停止しない。
(1) 段階別の実装・Root実測・独立whole review・通常統合finalまでの順序、(2) 今回1workerに渡す具体的な成果物/前提/必要rawと関連resource見積、(3) あなたが選ぶCodexモデルを返してください。全ケースcollectionが終わる前にwhole index合格とは主張しない。
