実行前の件数訂正だけお願いします。実state repair_ready used16/maxnull、worker16は未起動です。Root依頼の「7branches程度」という数え方をそのまま採ってしまったが、実際の列挙は B1(power+direct closure)=1、B2a/B2b(exit)=2、B3(patience)=1、B4a/B4b(destruction)=2 の合計6実ケースです。fallbackも3+3=6で整合します。原frozen5条件/7領域/15+EV/30-88/部分点0は不変、架空の7thcaseや新条件を足して数を合わせないでください。7という数は原受入の要件ではなくRootの計数誤りです。あなたの実記録されたrun判断を6実ケースに訂正して、同じ自己完結のscope/具体指示/絶対path/モデル理由を再掲したrun判断を返してください。scope・検証・金額・権限を追加変更しない。古い判断JSONは履歴として保持し、訂正判断だけをdispatchします。
先行するあなたの実判断:
{"action": "run", "task_id": "P04-01", "reason": "repair_ready（16回使用、上限なし）。最新提出 29a641c540430cfc7ea24498b242c9afa30686c1 でRootのS2b native r02は全PASS（根拠: /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/p04-whole-closure-r01/ROOT_S2B_NATIVE_R02_RESULT.json、raw: /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/p04-s2b-native-r02/）。S1r02/S2ar03/S2b r02は保持し、再実行しない。原P04全体は未達のまま、原成果の加点は0。残る原frozen 5条件（power_stop/destruction_stop/closure_release/exit_release/patience_release）について、S3のcode-ready一式を正常に提出するのが今回の作業。\n\n判断: 一括S3で進める。共通fixture1つ、GDプローブ1本、strict Python wrapper 1本で7branchesをまとめ、import/parseは各1回、Writer1回、別PID Reader1回にする。理由は、全caseが同じActorHardening cafe/helperと元の16:00境界を使い、S2bの2系統fixtureより共通性が高いこと。もしbranch単位の分離（fresh Runtime/clock/state）がGD内で保てない具体的な理由が見つかった場合だけ、S3a=power+exit2（3branches）とS3b=patience+destruction2（3branches）に分ける。その場合も両方をcode-readyで提出し、未完成を外部block理由にしない。\n\n【worker手順（自己完結）】\n0) 最初に /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/p04-s3-existing-source-r01/SOURCE_MANIFEST.json を読み、次の7本の全byte SHA256を照合する: p04-01-power-completion-boundary-r01.gd、p04-01-exit-boundary-r01.gd、p04-01-automatic-patience-r01.gd、p04-01-destruction-completion-boundary-r02.gd、test_business_operations.gd、test_business_closure.gd、DESIGN_DECISIONS.md（D-034は252-262行、特に258行）。不一致ならその事実だけを報告する。\n1) 旧GDから再利用するのは、実public操作・seed・構築手順・原定義値に限る。旧1299固定wrapperと、承認前の18:00失敗predicateは使わない。現行の tests/s3/test_runtime_actor_hardening.gd と tests/fixtures/required_kitchen_setup.gd を使う（厨房は物理配置FLEXで、自然hire/unlockの証拠とは区別する）。product修正は0。\n2) 新規ファイルは docs/plans/original-completion-2026-10-02/execution/p04-01/s3/ 配下だけに置く: p04_s3_closure_probe.gd、run_s3_native.py、S3_ROOT_RUN.md の最小構成。旧s1/s2/s2b/A/checker/C/protocol/product/DB/契約/base/分母/権限/課金は編集0。run_s3_native.py は docs/plans/original-completion-2026-10-02/execution/p04-01/s2b/run_s2b_native.py のstrict guardを踏襲する: source_refs→QA1明示override→private source/cacheは別inode→import/parse各1→Writer→別PID Reader→owned finally＋全source/default profile/pin/cache guard。--check-only は engine0/private profile0。\n3) branches（各branchでfresh Runtime＋clock＋stateを使い、seed/入力/public command結果/IDを明示記録）:\n B1 power+direct closure: power templateのscheduled public change_resourcesで、960に有限mana reserveを枯渇させる。同Tickでtarget自身にpublic business_open=falseを適用。queuedBは959に実Guest＋public create_service_requestで作り、clockを進める前に待機と在庫予約を実測する。capacity/staff値は弄らない。食事在庫は原public stock helperで準備し、価格/所要時間は定義から取る。期待: 960/961は停止中課金0・進捗保持・開始済Aは同じ予約のまま。Bは予約release once・stock返却・忍耐不消費・no orphan。その後public commandで元の正のreserveに戻すと、休業のままAが962に1回だけ完了・課金し、追加tickで重複0。D-034（直接休業でも開始済は継続）とD05依存の休業pauseを区別する。reasonがRELATED_FACILITY_INACTIVEの場合はそのまま記録し、NO_POWERに捏造しない。\n B2a exit: 元templateで960に完了→通常退出、支払1回、翌tickのdespawn重複0。\n B2b exit: 959のqueueからpublic leave_facility_queueを960へ予約し、admission前に1回release・課金0。planned_exit/wallet/在庫/reservation IDsを実測し、request/guest/serviceの所有を追跡する。\n B3 patience: 元のtraveler.base_patienceを使い、サーバー不足の実QUEUINGで通常tickにより忍耐が尽きる。自動abandon→再判断→通常退出/Despawnの各境界で、予約release1回・active orphanなし・stock返却・支払0を確認する。patience値/elapsedの手書換えは禁止。planned_exitが先に短絡しない条件も維持する。\n B4a destruction offset0: 元public register_event_definition/enqueue_eventによる診断用automatic Event（DEFENSE/foreground false/durability0）。960のFACILITY_COMPLETIONが後段のEvent破壊より先に完了し、支払1回（停止中課金に数えない）。\n B4b destruction offset1: 960破壊→961にFAILED、予約release once、課金0。B4a/B4bとも、前後のevent instance/service/request/予約/ledgerを実測する。新しいproduction Event/数値/破壊ルールは作らない。\n4) 共通契約: phase順と全Runtime typed snapshotを無加工で出す。enumはString定義を確認し、int変換しない。全Variant callは明示型にし、:= 推論は使わない（静的確認必須）。本番Operationsはenableしない。get_day_summary等の無関係呼出は無条件に行わず、実absenceと正式snapshotのdisabled{}を記録する（S2bのcoordinator_nilの教訓）。assertはexpected scalar表で合格させず、rawから検証する。原本/承認済みにない規約は捏造せず、pendingとして具体的に記録する。7領域/安全性3結果/原15+EV/30-88/部分点0は維持。\n5) formal: 必要なbefore/after/next/recovered各点をpublic SaveServiceでWriterが保存する。Readerは別PID/profileで、全memberの原/copy SHA・原不変・全Runtime typed一致を確認する。さらに境界前の正式loadから、通常clockと同じpublic recovery commandで再生し、Writerの全typed状態とphase順に一致させる。future recovery commandのidempotency key/command ID/_serialと、元reserve等の外部probe入力も保存する。Readerは初期serial0で過去setupのkeyを再利用しない。snapshotの内部書換えや比較対象の削除は禁止。raw（typed var＋JSON）は各point一度だけ保存し、branch/indexはpath/SHA参照にする。巨大aggregateへの多重コピー、要約置換、省略はしない。stage/cacheもcaseごとに複製しない。\n6) worker検証: py_compile、python run_s3_native.py --check-only（engine0）、型/参照の静的確認まで。全回帰とnative実行は0。commit/branch操作は0。collector/A仕上げはS3 rawの後で行う。S3_ROOT_RUN.mdにRoot手順（current製品1338、fresh plan、native 1回、出力先 /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/p04-s3-native-r01/）と残gapを記載して、正常code-ready提出とする。", "codex_model": "gpt-6-astra", "codex_model_reason": "今回は1本のGD/wrapperに4系統7branchesを収める統合作業。対象はpower/mana枯渇と直接休業の同Tick区別（D-034とD05）、guest queue/exit予約、実tickのpatience枯渇、Event破壊とFACILITY_COMPLETIONの順序で、それぞれ別サブシステムにまたがる。加えて全branchで、Writer/別PID Reader両方の正式Save/Load、recovery commandのidempotency/serial保存、無推論の明示型GDが必要になる。S2bは2系統fixtureでもrepair反復が多かった。今回は規模も相互依存もそれ以上で、Root native実行は1回ごとのコストが高い。初回でcode-ready品質を出せば、時間と使用量の総量はSolより少なくなると判断し、Astraを選ぶ。"}
