正常dispatch済み、同じP04-01はrepair_ready/使用済5/max nullです。あなたの次の実判断について、保持成果を再利用するCのみの実行開始を判断してください。前repair direction全文:
{"action": "request-repair", "task_id": "P04-01", "reason": "判断: C（信頼できるnative raw／ownership／ledger／service／reservation／正式保存の結合）は、今の現実のraw形式に合わせて今実装するのが妥当。必要なrawはmirror .review-material/native-first-current/ 内に揃っていることを確認した。dependency-{midnight,formal}-native の lifecycle {import,parse,repro|writer,reader}/{started,process,ended,adapter-owned-cleanup,outer-owned-finally}.json と stdout／engine-native／stderr／combined-raw.log、order-evidence/*.var と observations.json、restart-evidence/{writer,reader}.json と全 *.var（reader-receipts.var を含む）、formal-packages/{writer,reader}/{before,midnight,paused,after,next}/ の全40 member、OWNERSHIP_RAW_PROVENANCE.json（source／target／bytes／sha）、ROOT_APPROVED_DEPENDENCY_{MIDNIGHT,FORMAL}_RESULT.json である。このため追加rawの要求は無く、C全体を止める理由も無い。stage／cache／engine本体は今回不要。提供の旧39rawは読了・採用扱いにしない。\n\n実装範囲（allowed_paths内、同worktree、repairs4と提出9767b0a、未提出6編集を全保持）:\n(1) tools/check_p04_order_evidence.py に native結合層を追加する。既存の verify／coverage／applicability／boundary_conditions と A/Bの修正は保持する。この層は、index が参照する各native run について次を必須にする。\n  - OWNERSHIP_RAW_PROVENANCE の全fileの bytes／sha256 再計算一致。\n  - started→process→ended の PID連鎖を {3770,3818,3854,3879} 等と照合し、writer≠reader PID・別profile・全owned通常終了・cleanup記録を確認する。\n  - production_commit 5f6bc11 と、current_source_pins／applicability の一致。\n(2) ledger／service／reservation 結合。scalar自己申告ではなく、restart-evidence と observations.json の生receipt行から再計算する。対象は次のとおり。\n  - 1440 の MAINTENANCE_ACCRUAL／PAYMENT が施設ごとに1回で、日次close が1回だけ。\n  - PAUSED中（1440/1441）は SERVICE_SALE が0、wage が0。\n  - 1442 の SERVICE_SALE 25 が service_00000001 に1回だけ。\n  - reservation_00000001 は CONSUMED で、1443 の追加は0。\n  - 財布 50→25 を ledger 差分と照合する。\n(3) 正式保存の結合。次を確認する。\n  - writer/reader の5点×4member の SHA一致と、元20 member の不変。\n  - 14件の typed .var（5 persisted／5 loaded／4 replayed）と原 order-evidence .var の SHA一致を、ファイル実体から再計算する。.var のGodot Variant decodeは必須にしない。値の根拠はnativeのJSON receiptに置き、.var はSHAで結合する。\n(4) 生raw改変負例を checker_negative_fixtures.py に追加する。対象は、1byte改竄・member欠落・PID同一化・ended異常・receipt行の二重化/削除・PAUSED中の売上注入・予約孤立化・commit/pin不一致・self-reported scalar true のみ。いずれも fail することを確認する。applicability fixture も追随させる。\n(5) 全15条件と、reachable EV／原7領域／安全性3結果は固定する。未収集の条件（非ゼロ給与・command再送・EV・停電・破壊・シフト交代等の未証明分）は、明示的に未達とする。完了・加点は記さない（formal_original_credit 0維持）。CHECKER_PROTOCOL.md／EVIDENCE_COLLECTION.md に結合規則を記す。Root の probe／Reader／wrapper は再実装しない。product・Clock・値・config・Runner・cap は変更しない。\n\n残りnative境界の優先順（C後、Root側の証拠収集）:\n- ① 非ゼロ給与のシフト交代×00:00決算（二重決算／停止中課金の中核）\n- ② 同一idempotency command再送で二重課金・二重生成0\n- ③ 停電→閉店同一Tick順序\n- ④ 退出／忍耐解放と予約孤立0\n- ⑤ 破壊時の予約・課金\n- ⑥ reachable EV予約経路（D05未確定部分は pending のまま）\n\n原P04-01の完了は、全条件・独立whole review・通常integration・final の後のみ。\n\n見積: 単一worker 1run。checker差分は約400〜700行、負例は約15〜25件。所要は40〜80分で、watchdog1200秒の複数区間に相当する。新規engine起動は0で、Python検証のみ。", "codex_model": "gpt-6-astra", "codex_model_reason": "5回目のrepairで、直前のrunはexit124（timeout）で失敗している。Cは、異なる4種のraw形式（lifecycle JSONのPID連鎖、生receiptのledger行、formal package 40 memberのSHA、Godot typed .var 14件のSHA結合）を相互に照合する。そのうえで、生raw改変の負例が既存のA/B規則と既存fixtureを壊さないことを同時に保証する必要がある。scalar自己申告の抜け道をすべて塞ぐという対抗的な設計も求められる。これらの理由から、一発で正しく仕上げる品質を優先してAstraを選ぶ。Solで再失敗すると、再runの時間と使用量がAstraとの差額を上回ると判断した。範囲はallowed_paths内のPython 2〜4ファイルに限定し、engine起動は0とするため、追加の資源消費は推論分のみになる。"}
Root実測probe/Readerは完了済みなので重複実装しません。Rootのreadonly mirror全270 files/23426716 bytesはhash完全一致でworktreeの外、既存build_dir/audit-support/native-first-current/へrename移動済み（scope内にRoothelperを残さないため）。6個の未提出repair4編集は全SHA不変、既存提出9767b0aのままです。実装者はこのbuild配下を読むことができます。新規engine/全回帰0、Pythonの必要検証だけ。段階C実装の提出と原成果全体の未達を区別し、全条件未達のwhole受入を主張しない。未収集indexで登録whole gateが失敗することを知りながら重複validateしない。
具体的なraw注意点: SERVICE_SALEのrowはservice_idを直接持ちません。order-evidence/midnight-after.json の /systems/runtime/economy/idempotency は配列で、key=service.payment.service_00000001→transaction_id=ledger_00000081が実在し、それをledger行/guest wallet/facility/request/own reservation系列へ結合できます。憶測でrowにservice_idを要求せず、実形を読んでください。1440maintenanceのaccrual absolute_minuteは1439、paymentは1440で同一transaction。PAUSED状態の理由fieldはinterruption_reason。固定PIDや価格25の一般化を避け、run/入力/原定義から照合する。全15条件+reachableEV/原7領域/安全性3結果は固定し未証明を正直に未達。旧39rawを見ていないのに採用しない。
専用直列CLIにある承認済budget adapterはP04 implementer/codexのみtimeout None、他role/testwatchdog/config/digest/DB不変です。あなたが開始判断で選んだモデルを使います。追加上限確認は不要。必要な入力が実在しscopeが妥当ならrunを返してください。
