正常dispatch済みrepair_ready/使用済7/max null、提出547とclean既存成果を保持。原P04全体閉鎖に向けたあなたの実修正方向全文は次の通りです。初期判断(B/C/DとS1/S2/S3仕様):
{
  "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は時間と使用量が増えるが、この損失を防ぐ価値の方が大きい。"
}

最終判断(名前付き実製品target採用と事実訂正):
{"action": "request-repair", "task_id": "P04-01", "reason": "修理7を1件だけ依頼します(dispatchはまだで、repair_pendingの正規の遷移です)。前回判断のB/C/D、collectorの規則、順序、Rootからの供給物、原15条件+EV、7領域、期待値、30-88、部分点0、通常のscopeチェックはそのまま維持します。Cの既存部分(native_ledger/ownership/saves)は再利用し、作り直しません。変更はAの確定とBの事実訂正の2点だけです。\n\n【A 確定: 「名前付きの実製品target」方式を採用】\nROOT_PROSPECTIVE_PRODUCT_COMPOSITION_R01.json を読み、内容を確認しました。\n- main 9694f50 と提出 5475391 を実Gitのmerge-treeで合成し、tree 904bbb7f… を作っています。\n- そのtreeのblobから、native source_before の全1338path・67895232 bytesを独立に再ハッシュしました。\n- worker差分の15pathはすべて登録scope(tools/docs)内で、製品pathとの重複は0件です。\n- 元のworktree、HEAD、契約、DB、configは変わっておらず、engineの実行は0回です。\nしたがって前回判断の「baseはオーナー判断待ち」は撤回し、checker/collectorに次の内容で実装させます。\n\n役割の分離:\n- registered = deb1bcb(契約・pinの基点で、変更しない)\n- execution_origin = 9767b0a\n- checker = 実際に走らせたchecker sourceのcommitとそのbytes\n- product_target = {main_anchor, submitted, composed_tree} の名前付きの組。index.versions.tested には product_target と tested_product の製品manifest digest を入れ、checkerのSHAを製品のSHAとして記録しません。\n\ncheckerが自分で照合する実体:\n(a) main_anchor と submitted から `git merge-tree --write-tree` を再計算し、composed_tree と一致させます。Rootの数値は転記しません。\n(b) composed_tree の全pathを走査し、両方向の完全性を確認します。\n  - native source_before の1338件は、path→blob sha256 と bytes で1件ずつ一致すること。\n  - tree側にあって1338件にないpathは、すべて登録済みの tools/docs scope に分類できること。分類できないpathがあれば失敗とします。\n  - submitted による変更pathと製品pathが重なっていれば失敗とします。\n(c) Rootの実証ではsource_beforeしか照合していないため、次の照合を追加します(これが今回補う実体照合です)。\n  - config/input/environment のpinと、native runner-input の実ファイルが一致すること。\n  - selected_source_map は、宣言されたQA overrideの1test差分だけを source_before と別に持ち、その他は source_before と一致すること。\n(d) checkerのbytesが candidate/submit の該当blobと一致すること。\n(e) source_delta/applicability、ORDER_FUNCTIONS、REACH_REFS は registered→composed_tree の製品bytesで計算します。current_source_pins の原pinからの差分は coverage として明示し、pinそのものは書き換えません。\n(f) 古い1299件のcheckoutを1338件と同一視しません。stageフラグで比較をoffにしません。metadataだけのSHA差では engine を再実行しません。\n- integration/final の段階では、実際の統合候補treeに対して同じ (a)〜(e) を再実行し、このtarget・raw全体との厳密な一致を要求します。product差分がある候補を未検証で通しません。\n- 承認前にmainを更新しません。DBやdigestの直接更新、偽のSHAも使いません。\n\n【B 事実訂正】\n「製品に融資の機構はない」とした前回の判断は誤りでした。次のとおり実在することを確認しました。\n- autoload/simulation_runtime.gd:297 に repay_loan_principal の executor 登録がある。\n- 同じファイルの :3554 に本体関数、:5821 に executor 関数があり、LOAN_PRINCIPAL_REPAID を financing_principal_outflows に分類している。\n- tests/mvp/test_original_midnight_settlement.gd:211-239 に返済の実テストがある(Root提示)。\nこのため、融資返済を根拠不足のgapとして記録するのはやめます。docsには「公開返済APIとledger分類は存在し、自動返済や全UIの完成は主張しない」と、確認済みの事実だけを書きます。duty_payments は前回の定義(payroll と ShiftInstance の勤務recordを staff_id/day で結合した件数、期待値1)のままです。新しい通貨項目や金額は作りません。\n\n【C 維持】\n- Rootの新しいpaid/再送の証拠は候補証拠として扱い、minute1080の完了や同minute決算APIの再呼出しには転用しません。\n- midnight_replay は実測を取るまで pending のままです。\n\n【順序】\nworker実装 → RootがS1→S2→S3を実測 → collector → 登録validate(checker 547系列+product_target=composed tree) → 独立したwhole review → prepare-integration/final。全caseの収集が終わるまで、whole合格とは言いません。", "codex_model": "gpt-6-astra", "codex_model_reason": "前回判断と同じく、astraが必要な難しさと判断します。\n- 今回は難しさが増えている: 版の役割分離が、merge-treeの再計算、tree全pathの両方向の完全性分類、config/input/environment と selected_source_map のQA差分の照合、checker bytesの照合にまで広がりました。これに duty の結合、3stageのGDScript probe、rawを結合して再計算するcollector を加え、1つの整合した設計で作る必要があります。\n- 不整合の前例: 版の識別と融資の事実誤認という不整合が、続けて見つかっています。\n- 失敗の損失が大きい: 修理は既に6回使っています。ここで誤ると、Rootのnative実測と独立reviewをやり直すことになります。\nastraは時間と使用量が増えますが、この損失を防ぐ価値の方が大きいと判断します。"}
全体の開始判断(run/wait)を返してください。追加承認待ちを作らず、実在する資材と登録scopeで進めます。Rootはworkerが書くchecker/collector/probeを直接編集しません。
実際の入力の場所:
- build_dir/audit-support/p04-whole-closure-r01/ : Commander用21+資料をbyte完全一致でworktree外へ移動済み。current-patterns/に実strict wrapper・正式SaveService WriterReader・新shift/paid/再送probe、existing-probes/にpower/exit/destruction/patience、ROOT_PROSPECTIVE_PRODUCT_COMPOSITION_R01.json。
- build_dir/audit-support/native-first-current/ : Cが実検証した元3runのraw/所有/正式40member/全typed/state、補正済みSOURCE_MANIFESTとPOST_P18_CURRENT_SOURCE_APPLICABILITY、旧bytes=root-corrections-r02/。
- build_dir/audit-support/p04-current-native-series-r01/ : 新paid/再送の4run全raw・lifecycle・保存package、402files/55890946 bytesをSHA完全一致・別inode CoWコピー済み。stage/cache/engine本体は元canonicalに保持。SOURCE_MANIFEST.json、REGISTERED_VALIDATION_REFERENCE.json（固定argv/timeout）、production-runner/run_all_tests.py（現本番実体）。既存39rawは読了扱いにしない。必要な追加rawは具体的pathだけ指定。

実装上の重要な精密化（.review-materialではなく上記build資料を読む）:
1. ROOT_PRODUCT_SOURCE_ROLE_CLARIFICATION_R01.jsonとSOURCE_SELECTION_AND_NON_PRODUCT_REFERENCE.json。実source_refsはtoolsも含む。main969の選択source集合はraw1338と完全一致し、実合成treeで選択sourceに増えるのは tools/check_p04_order_evidence.py だけ（新checker-roleとして別blob検証）。tree全体には既存の非選択3139paths（README/.gitignore/.editorconfig/.vscode/無関係docs等）がある。これら既存非製品metadataまでworker allowed_paths内だと要求すると常時failになる。main_anchorから不変の既存metadataとして明示分類し、新/変更pathは全て登録scope必須。選択sourceの全両方向一致とsource_before/selected QA差分の証明は弱めない。未知の追加ゲームsourceをmetadataへ逃がさない。tree全pathの分類は行うが、既存metadataと新worker差分は区別する。
2. git merge-tree --write-treeはobject生成を伴う。canonical repository/refs/HEAD/historyはworkerも検証も一切書換えない。必要ならtask許可内の一時object directoryと元object storeのreadonly alternatesで再計算し、canonical Git書込み0を保つ。source/contract/DB/config/権限を変えない。通常提出はRunnerが行い、workerがcommitしない。未commit checkerの自己blob一致等、提出後にしか確定しないfull検査は未実施と正直に記録し、Rootが実提出後・実測後に検証する。テストのためのstage flagやskipで本番gateを通さない。
3. 全4役割のblob/tree/manifest実体照合を保ち、checker metadataだけのSHA差でnativeを再実行せず、integration/finalの実候補で製品またはQA/collectorに関係するbyteが違えば失敗とする。Rootの証明904bbb…は547を用いた実例であり、今後の新提出/新mainの実treeを自分で再計算する。
4. S1→S2→S3は関連caseを安全にまとめる。現source authorityと実templateを再利用し、1case1processを目標にしない。可能なら同じQA scriptのmodeで実測→正式Writer→別PIDReader、import/parseは同stageに1回ずつ。case/seed/全状態/owned receiptを保持。Rootが資源確認してengineを実行し、workerはengine/全回帰0。collectorは実rawなしでは未達とし、derivedとengine rawを区別して全条件を再計算。仮count/予測PASS/indexで全体を通さない。
5. raw/contextへの追加1GiB等の物理コピーは不要。必要なRootコードや原検証sourceはGit objectまたは現built資料で読めます。予算/回数は既存許可内、normal test watchdogは維持。原15条件+EV/7領域/安全性3結果/30-88/部分点0と独立whole reviewを維持。範囲内の実装に集中し、基点変更や曖昧なowner承認を理由に入力済み作業全体を止めない。
