正常dispatch済みrepair_ready/使用済8/max null、保持3filesの未検証Aはそのまま、提出547の既存Cは保持です。あなたのS1先行の限定方向を開始するrun/wait判断を返してください。実修正方向全文:
{"action": "request-repair", "task_id": "P04-01", "reason": "【判断】repair8を依頼する（理由は外部blockではなく未実装）。REPAIR7_IMPLEMENTATION_STATUS.mdを読みました。残作業1〜4（S1/S2/S3のprobeとwrapper、全条件collector、target側config/input/env照合、fixtureと自己blob検査）はどれも実装上の未完成で、仕様不足ではありません。D05の未確定部分は従来どおりpendingのままです。オーナーが示したS1先行の順序に同意します。理由は、S1が現在0/16のうちEV、power_stop、recovery_completion、closure_release系の実状態をまとめて初めて生み出し、S2/S3とcollectorのraw形式の基準になるからです。これより良い順序は見当たりません。前判断は保持します（原P04全体閉鎖、原15条件+EV、7領域、安全性3結果、30/88、部分点0、既存C、全生証拠）。版役割Aの変更は未検証で、合格としません。\n\n【repair8の範囲（S1コード準備のみ。原P04 wholeは未達と明記すること）】\n0. 前提: tools/check_p04_order_evidence.pyとCHECKER_PROTOCOL.mdの未コミット変更は、そのまま保持し今回は編集しない（A改良よりS1実測を優先）。REPAIR7_IMPLEMENTATION_STATUS.mdには「S1準備に移行、A未検証」を追記するだけにする。\n1. 新規ファイルはallowed_paths内の docs/plans/original-completion-2026-10-02/execution/p04-01/s1/ に置く。\n (a) p04_s1_ev_power_probe.gd: build_dir/audit-support/p04-native-existing-sources のGD probe templateと tests/transport/test_runtime_transport.gd:94-149、tests/staff/test_rescue_elevator.gd の構築とShape/Actorを再利用する。public commandsだけで次を作る: staffに実task.required_itemsの予約がtravel前に発生 → EV搭乗 → reserve枯渇による停電 → 対象施設の直接休業と予約release → 安全到着（有効stopに1回のみ、teleportなし）→ 給電復帰。着床不能時の保持（remaining_minutes不変）も別caseで行う。各caseのseed、before/after、生ledger行、予約配列、trip/elevator report、domain event、service IDをobservations JSONとtyped .varで出力する。phaseはwriter（正式保存直前の状態）とreader（別PIDで正式復元した直後の状態）。不変条件のassertは「停止中の課金行0」「予約の孤立0」「到着1回」に限る。費用帰属・金額・EV停止規則は新たに決めず、生値の記録のみにする。\n (b) run_s1_native.py: 唯一の実行入口。既存wrapperの順序を保つ: r.source_refs → QA明示override 1件 → r.copy_source private stage → bootstrap → cacheを`cp -c`して別inodeを確認 → import/parse各1回 → writer → 別PIDのreader → finallyでowned_outer.finish_captured → fixed_guard。保存物: source_before/after、selected map、parse-paths、contracts、phase receipt、started/ended、outer-owned-finally、execution.json、PID集合。--check-onlyはengineを起動せず、入力の実在・SHA・plan出力だけを行う。\n (c) S1_ROOT_RUN.md: Rootがそのまま実行する正確なコマンド、出力path、raw一覧、期待するexit。\n2. worker側の検証: python3 -m py_compile と run_s1_native.py --check-only のみ。engine起動0、コミット0。\n3. 正常な終了応答: 提出物のpathとSHA256、実行済みの静的確認と出力、Root用コマンド。「S1コード準備完了・未実測・原P04 whole未達」と明記する。足りないrawや足りないexact-templateがあれば具体的pathだけを列挙し、未実装をblock理由にしない。\n\n【Rootの実行計画】S1提出を受けて資源を確認 → --check-only → Godotで実run1回（import/parse、writer、readerの別PID）→ rawを保存 → 失敗したら同じS1範囲で修理。\n\n【後続の依存】S1 raw → S2（midnight_settlement/replay、paused_midnight、night_staff_absent、shift_completion、overtime_task）→ S3（exit/patience/closure、destruction_stop、dependency_stop、same_minute_replay、save_restore）→ collector（verified_conditionsを全rawから動的導出。仮データ禁止）→ A仕上げ（candidate_treeをindex値だけで比較せず、integration/finalの実HEAD treeと実FSに結合し、古いtreeで未検証のproduct変更を隠せなくする）→ 登録validate → 独立whole review → prepare-integration。どのstageの完了も原成果の完了とはしない。", "codex_model": "gpt-6.1-sol", "codex_model_reason": "既定のgpt-6.1-solを選びます。repair7が未完成に終わった主因はモデル能力より範囲の大きさです（A+3stage+collectorを1runで扱った）。今回はS1の3ファイルに絞り、templateと参照テストの具体的な行範囲、wrapperの既存順序、出力物を固定しています。新規の設計判断はほぼありません。静的確認だけで終わり、Godotの実行で問題が見つかってもRootの実測から短い修理で直せます。astraに上げるほど品質に差が出るとは見込めず、時間と使用量の増加に見合いません。S1の実測後、collector/Aの結合で横断的な整合が難しくなった時点でastraを再検討します。"}
追加の承認待ちは不要、Rootは原P04全体閉鎖を継続します。モデルを既定Solにした判断を保持します。今回コード準備の出力はS1の3ファイルと状態追記だけ。A/collector/S2/S3全実装を今度の終了条件に混ぜて未完成blockにしない。ただし、S1準備の必須3ファイルは静的確認/--check-onlyと正確なRootコマンドまで終えて正常提出応答に到達させる。原P04 wholeは未達と明記。入力は既存build_dir/audit-support/p04-whole-closure-r01（current-patterns/strict wrapperと正式SaveService、existing-probes/power/他）、native-first-current、p04-current-native-series-r01の3系統。欠けたexact templateがある場合のみ具体的pathを述べる。S1の実行が可能なら予測原合格を主張せずcodeを提出。Rootがengineを実行して実rawを得ます。worker自身engine/全回帰0。
注意: python3 -m py_compileは-Bだけでpycを止められないので、PYTHONPYCACHEPREFIXをtask build内の専用cacheへ指定し、Source checkoutに__pycache__/新binaryを残さない。既存Runtime/clock/policy/balance/基点/DB/config/権限/料金の変更0。normal test watchdogは維持。非rootRepoのモデルcache TTL警告を口実にRoot境界を広げず、作業の実失敗と区別する。
