repair7はまだdispatchしていません。前判断のB/C/Dと既存成果を保持し、Aの「オーナー判断/baseの扱い」について、契約基点やDB/configを変えない具体的な候補をRootが実証しました。これを読んで開始方向を確定してください。必要のない再承認待ちは作りません。前判断全文:
{"action": "request-repair", "task_id": "P04-01", "reason": "正常repair_pending(6回使用/max null)、547の登録validate失敗(e445…、exit1/index.json無し)は正規の結果として受領。再検査せず、修理7を1件だけ依頼する。原15条件+EV/7領域/期待値/30-88/部分点0は変更しない。\n\n【A 版の識別】check_p04_order_evidence.py:730 の `native.production_commit == head` は廃止し、次の4つを別々の役割として扱う。\n- registered=deb1bcb(仕様pin)\n- execution_origin=9767b0a\n- tested_product=実測したnative product commit 5f6\n- checker=HEAD(新しい役割。tools/docsだけを含む)\n\nindex.versionsの`tested`は製品版を意味させ、checkerのSHAを入れない。\n(1) tested_productの製品manifestをGit objectから直接計算する。対象はautoload/scripts/data/scenes/project設定など、ゲームを構成する全path→blob(1338件)。これをnative runner-inputのsource_before/selected_source_map、config/input/environmentのpinと全件照合する。metadataだけのGit差では、engineの再実行を要求しない。\n(2) source_delta/applicabilityは registered→tested_product で計算する(HEADでは計算しない)。ORDER_FUNCTIONSとREACH_REFSはtested_productのbytesで照合する。\n(3) checkoutの製品manifestも計算し、tested_productと1件でも違えば明示エラーで失敗する。stage flag・条件付き見逃し・旧1299件との同一視はしない。547系列(deb1bcb製品)のcheckoutではこの検査は正当に失敗する。\n(4) 段階別に証明されるもの:\n- registered validate: raw完全性、条件ごとのnative結合、registered→P差分coverage、checkout=P\n- review: 独立したwhole判定\n- integration/final: main969+差分の候補が製品manifest=Pであることを同じcheckerで再証明\n→オーナー判断が必要な点: 現在のtask baseのままでは(3)が成立しない。P等価の製品上で登録validateする手段(base/候補の扱い)は、オーナーの判断事項としてdocsに記す。DBやdigestの直接更新、偽のSHAは使わない。\n\n【B duty_payments】key名と期待値1は維持する。新しい通貨項目は作らない。CHECKER_PROTOCOLで次のとおり定義する。\n- 定義: 決算日のpayroll settlement取引のうち、行がShiftInstance.record_duty_minute(scripts/staff/shift_instance.gd:139)の勤務recordとstaff_id/day単位で結合するもの(原本72の人件費が勤務に基づくこと)の件数。\n- collectorはrawのpayroll行と勤務recordを結合して数を再計算する。結合できなければ失敗とし、値を緩めない。\n- 借金返済: 原本72に記載がある。製品に融資の機構はなく、維持費の未払い(arrears)の支払い(facility_upkeep_settlement.gd:212、MAINTENANCE_PAYMENT)がupkeep_paymentsに入るだけ。融資返済は根拠不足のgapとして記録し、新設しない。\n\n【C】\n- shift_completion: minute1080の証拠はROOT_APPROVED_SHIFT_CURRENT_RESULT+approved-shift-current-r01.gdを使う。paid完了1442は転用しない。\n- 再送6ペア: same_minute_replayだけに使う。\n- midnight_replay: 同じminuteの決算APIを再度呼ぶ実測(settlement/payroll/upkeepの行の増分0、二重のidempotency無し)を新しく取るまでpending。\n\n【D probe】existing-probesとcurrent-patternsを最小差分で拡張し、stageごとに1回の実行にまとめる。\n- S1(同じseed): power_stop+closure_release+EV。同じTickで停電と直接休業。D-034の開始済み継続と待機予約のreleaseを区別する。staff taskがitemを予約→travel→EV set_powered(false)→arrivalまで。\n- S2(夜番seed): night_staff_absent(1081 WAITING_FOR_STAFF)+overtime_task(interrupt_level0の実taskと勤務record 1回)+midnight_replay+duty結合。\n- S3: exit/patience/destructionは別case・同じseed系列。全typed stateを保存し、正式なSaveService Writer/Readerを別PIDで実行する。\n\n【collectorの規則】\n- 出力はderivedと明記し、engineのrawと区別する。\n- 各条件の値はactor/service/予約/帳簿/同minute/保存復元のrawを結合して再計算する。\n- verified_conditionsは固定の3件ではなく、結合が成立した条件から導く。\n- 実測前に予測値やcountsを書いたindexは作らない。\n- D05の細則(EV停止の帰属、停電と休業の厳密な順序、費用の時点)はpendingと明記する。\n\n【順序】worker実装→Rootが資源を確認してS1→S2→S3を順に実測(全回帰とengineはRootが実行)→collector→登録validate→独立したwhole review→prepare-integration/final。全caseの収集が終わるまでwhole合格とは言わない。\n\n【workerへの前提】allowed_paths内だけを変更する(checker/collector/probe/wrapper/docs)。Cの既存部分(native_ledger/ownership/saves)は再利用し、作り直さない。\n\n【Rootから供給してほしい物】\n- 5f6のnative runner-input/source_before\n- 登録checkerの呼出し実体\n- strict wrapperとSaveServiceのtemplate\n- 既存の39 raw(必要な分)\n\n【見積】worker 1session(約3-5M input token)。Root側のnative実行は3 stage×約3-5 process(import/parse/repro/writer/reader)を順に実行する。", "codex_model": "gpt-6-astra", "codex_model_reason": "今回の修理はastraが必要な難しさと判断する。\n- 範囲が広い: 版の役割を4つに分ける製品manifestの意味設計、duty結合の定義、3stageのGDScript probe(EV予約→travel→停電→到着、同minute決算の再呼出し、正式なsave/restore)、rawの結合から条件ごとに再計算するcollector、を1つの整合した設計で作る必要がある。\n- 不整合の前例: 前回sol想定の判断のあとで、version identityとduty_paymentsの不整合が見つかった。\n- 失敗の損失が大きい: 修理は既に6回使っている。ここで誤ると、Rootのnative実測と独立reviewをやり直すことになる。\nastraは時間と使用量が増えるが、この損失を防ぐ価値の方が大きい。"}

実証は .review-material/p04-whole-closure-r01/ROOT_PROSPECTIVE_PRODUCT_COMPOSITION_R01.json。実Git merge-treeでmain9694f50と提出547を合成したtree=904bbb7fbf49afafcca9527c42ee617244981f20を作り、実native source_before全1338path/67895232 bytesをそのtreeのGit blobから独立再ハッシュし全SHA一致を確認。worker差分15pathは全て登録済みtools/docs scope内、native製品pathとの重複0。元worktree/HEAD/契約/DB/config/実Sourceは不変、engine0。これは正常integrationや受入完了ではなく、具体的な合成製品のbyte証明です。source_beforeは宣言QA override前の製品/試験baseで、selected_source_mapは明示QAの1test差分を別に持つことも維持します。
オーナー側の方針候補: registered validateにおけるchecker(547)と、受入対象product(現main+登録scopeの変更を合成したtree)を分ける。古い1299 checkoutを1338と呼ばず、実合成対象の全製品manifest==実測品source_before/設定/input/environmentを必須にする。各段階でcheckerの実byteもcandidate/submitと一致を確認する。元contract base deb1bcb/current_source_pins原pin/原15条件/30-88と通常scopeチェックは変更しない。正常review/integration/finalでは実統合候補の製品manifestとこのtarget/raw全体を同じ仕組みで厳密比較する。承認前にmainを更新せず、product差分がある候補を未検証で通さない。stageフラグで比較をoffにせず、常に「名前付き実製品target＋その実体byte」を検証する。metadataだけのchecker SHA差で無意味なengine再実行もしない。正常Runnerのreport SHAは実際に走ったchecker sourceのSHAであり、rawのgame product SHAと同じだと偽らない。
この方式が完全な証明として不足なら、何の具体的な実体照合が必要かを示し補ってください。単に古いhost checkout !=productで待機にせず、実際に受入対象となる合成品は全byte一致であることを活用してください。Rootはこの証明をpreparedし、原受入の検証強度と独立reviewは一切下げません。範囲内の通常候補合成/証拠役割の設計として妥当なら、この方法をchecker/collectorの修正指示へ取り込んでください。
もう1点の事実訂正: 「製品に融資の機構はなく」という断言は広すぎます。現在本番autoload/simulation_runtime.gd:297はrepay_loan_principal executor登録、:5828に実行関数、:3586等でLOAN_PRINCIPAL_REPAIDが存在し、tests/mvp/test_original_midnight_settlement.gd:211-239に公開返済/同key再送拒否/保存後拒否の実コードがあります。全融資UIや自動返済の完成を主張しませんが、未調査で機構全体が無いというgapは記録しないでください。duty_paymentsは前判断の実勤務recordとpayrollの結合定義を保持し、新通貨項目や金額を作らない。
今回の次の1修正方向を、Cを再実装せず全原P04 closureへ進める形で返してください。Rootの新paid/再送は候補証拠であり1080完了や同minute決算API再呼出しへ転用しない。残S1/S2/S3とcollector、正式WriterReader、全条件の独立whole reviewまでの順序は維持。モデルはあなたが選択。
