通常repair10がrepair_readyになりました。同じS2aの開始判断をお願いします。workerへ最新run.reasonが直接渡るので以下のあなたの具体指示を自己完結で再掲してください（単に前判断参照不可）。context adapterは不要です。
表現の明確化2点: 「check-only」はPython wrapperの--check-onlyでありGodot --check-only/--version含めengine起動は0。Godot parseはRoot nativeの通常phaseでのみ行う。またS2aには停電・休業停止を加えないので、1440の売上/給与/維持費があるledger全体を0とassertしない。停止中課金0はその実停止条件を満たす別のprobeの受入条件として保持し、S2aの原不足を隠す集計をしない。二重決算0/孤立予約0と実sale/payroll/upkeep/duty joinが今回の実測対象。実体原values/原勤務/原45分は既存templateから読む。payroll取引数は1を定数代入せず実settlementと勤務行をjoinして導出する。
資料の実絶対prefix: /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/p04-whole-closure-r01/current-patterns/ 。S1原3ファイルは同task source checkout/docs/plans/original-completion-2026-10-02/execution/p04-01/s1/。Root採用済み実S1結果は同build/audit-support/p04-whole-closure-r01/ROOT_S1_NATIVE_R02_RESULT.json、Source1338、engine4全owned終了。実新code-ready提出まではRootはengineを起動しない、workerもengine0。
あなたの記録済み判断:
{"action": "request-repair", "task_id": "P04-01", "reason": "repair10 = S2a（コード準備のみ）。Rootの製品root fresh plan + native 1回で00:00の実決算境界を測れるようにする。S2全体を1回にまとめる案は採らない。夜番不在/残業は勤務生成と時刻条件が別系統で、変数が倍になり失敗時の切り分けが難しくなるため。これらはS2bとして残件に明記する。\n\n【対象ファイル（allowed内の新規のみ）】docs/plans/original-completion-2026-10-02/execution/p04-01/s2/ 配下に次の3点:\n(1) p04_s2a_midnight_probe.gd\n(2) run_s2a_native.py\n(3) S2_ROOT_RUN.md\ntools/check_p04_order_evidence.py、A/checker/C/protocol、既存のs1/*、製品source、DB/契約/base/分母は編集しない。\n\n【再利用（新たに作らない）】\n- wrapper骨格は s1/run_s1_native.py の strict 契約をそのまま流用する（import/関数呼び出しまたは同一手順の複写）。手順: source_refs→明示QA1→private source/cache別inode→import/parse各1→Writer→別PID Reader→owned finally/全guard。check-onlyではengine 0、private profile読取 0。\n- probeのセットアップは BUILD_OUTPUT_DIR/audit-support/p04-whole-closure-r01/current-patterns/ の次のファイルを直接読んで流用する: paid-shift-midnight-r01.gd、paid-shift-midnight-formal-r01.gd、idempotency-paid-formal-r01.gd と、対応する *-native-r01.py。具体的には本番operations有効化、公的hire/勤務割当、料理材料1、原価格・原45分で予定1440完了。\n- 唯一の違いは「1439で依存厨房を閉じる」停止を行わないこと。これにより実1440売上を発生させる。\n- QAは原public helper・原数値・原勤務枠（hire 120/135 等）をそのまま使う。snapshot内部を書き換えて期待値を作らない。未知の挙動を定数で埋めない。\n\n【case（各1、seed固定、独立fresh state）】\n- C1 midnight_sale_payroll_upkeep: 実際に1440で完了する売上を発生させ、同じadvanceで00:00決算を実行する。採取するもの: 売上取引ID・serviceID・予約ID、給与（staff_id/dayをShiftInstanceにjoinしたpayroll settlement取引数。行数や分数で代用しない）、維持費、day_summary、ledger全行、shifts差分。\n- C2 same_minute_recall: current_minute==1440の状態で、公開 OperationsCoordinator.advance_to(1440)（scripts/operations/operations_coordinator.gd:361）を実際に再呼び出しする。CommandResultの戻り値（ok/code/payload）、全typedSnapshotの前後、ledger、day_summary、payroll、shifts、Idempotency記録をすべて採取する。1443から過去1440を呼ぶ方式や、request再送で代用することは禁止。\n- C3 formal_restore: C1後の状態を正式SaveServiceでWriterが保存し、別PIDのReaderが復元する。確認するもの: 原slot/Readerコピーの全member SHA一致、原ファイル不変、typedSnapshot完全一致、ledger/payroll/day_summary一致、復元後に再決算が増えないこと（再advance_toの実結果を採取）。\n\n各branchで記録するもの: seed、入力、日、時刻、実取引ID、serviceID、予約ID、実勤務分差分、ledger全行、command結果。出力形式はJSON閲覧用＋typedvarの両方。停止中ledger 0、孤立予約 0、二重決算 0 を実測値で判定し、FAILも原値のまま記録する。\n\n【S2_ROOT_RUN.md】Root向けの1回実行手順、出力先 BUILD_OUTPUT_DIR/p04-s2a-native-r01/、guard一覧、S2b残件（夜番不在、残業）、そしてこれは原P04完成加点0・独立whole受入前の準備資料であることを明記する。\n\n【worker検証】py_compile と、Godot check-only parse の宣言手順のみ。engine実行 0、全回帰 0、手動commit 0。S1は再実行しない。未実装を外部block理由にしない。完了は自己確定せず、作成ファイルと残件を提出する。", "codex_model": "gpt-6.1-sol", "codex_model_reason": "gpt-6.1-solで足りる。作業の大半は、既存のS1 strict wrapperとpaid-shift-midnight系のGD/pyパターンを組み合わせることで、新規ファイルは3つに限られる。workerの検証もpy_compileとcheck-onlyだけで、engine実行はない。範囲をS2aに絞ったので、1回あたりの推論量はS1修復のときより小さい。設計上の難しい点（1440での実際の同minute再呼出し、payroll join条件、停止しないcase）は今回の指示で具体的に固定してあり、上位モデルの探索力に頼る必要は低い。上位モデルにすると時間と使用量が増えるのに、品質の差は小さいと見る。"}
