P04-01次のS3コード準備を具体的に設計し実モデル選定してrun判断してください。state repair_ready used16/maxnull。最新提出29a641c540430cfc7ea24498b242c9afa30686c1のRoot製品1338 S2b native r02は import98696/parse98744/Writer98770/Reader98810全PASS、owned4終了/全guard0。night1081 WAITING_FOR_STAFF/NIGHT0/wallet50不変/元予約ACTIVE保持、overtime1078→79worked+1/overtime0、79→80/80→81 worked0/overtime+1、両PID同分publicguard不変、formal6slots(48members原+copy)、12phase .var対の全bytesSHA一致、Reader境界2tick・safe卸し完了/退勤の全Runtime typed replayまで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は同build/p04-s2b-native-r02/。S1r02/S2ar03も保持し再実行0。原P04全体未達、原成果加点0。新29a初回必須wholevalidateだけ一度(index未収集FAIL)→通常repair16、同版反復なし。
残る原frozen5条件 power_stop/destruction_stop/closure_release/exit_release/patience_release のS3を、既存cafeteria fixture共通化で安全にまとめる案を判断する。7branches程度を一つのGD/strictwrapper/Writer+Readerでできればimport/parse1回で効率的。過大なら実行可能な有限S3a/S3bを選び、未完成を外部block理由にせず正常code-ready提出する。S3全体が安全にまとまる理由は全caseが同じActorHardening cafe/helperと元の16:00境界で、S2bの2系統fixtureより共通性が高いため。実Opusが価値/依存/残工数から判断すること。
【既存資料を7本すべて供給/全byteSHA検証済み】絶対ディレクトリ /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/p04-s3-existing-source-r01/ に SOURCE_MANIFEST.json と以下（不存在や未供給はない。workerは最初にSHA確認）:
- 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）
old GDの実public操作/seed/構築/原定義値を再利用する。古い1299固定wrapperや承認前18:00失敗predicateは再利用しない。現行 sourceW tests/s3/test_runtime_actor_hardening.gd と tests/fixtures/required_kitchen_setup.gd を使う。元fixtureの厨房は物理配置FLEXで、自然hire/unlock証拠とは別。product修正0。
【S3候補scenarioと不変受入】
1) power+direct closure: power templateのscheduled public change_resourcesで960に有限mana reserveを枯渇（開始済service原45分の残り1）。同Tickにtarget自身のpublic business_open=falseを適用し、開始済serviceとqueued requestの別々の元ID/実予約を追う。queuedBは959に実Guest+publiccreate_service_requestを作り、clockを進める前に実待機/在庫予約を確認すれば、施設capacityやstaff値を弄らず作れる。食事在庫2など必要な試験入力は原publicstock helperで準備し、価格/所要時間は定義から。960/961停止中課金0/進捗保持/開始済同予約、待機Bの予約release once/stock返却/忍耐不消費/noorphanを観測する。元の正のreserveをpublic commandで戻し、targetは休業のまま開始済Aが962に1回完了・課金、追加tickの重複0を確認。D034の直接休業は開始済み継続、D05依存休業はpauseという区別を守る。powerで厨房も止まるのでreasonがRELATED_FACILITY_INACTIVEを先に示してもNO_POWER文字列へ捏造しない。
2) exit2branches: 元exit templateの完了960→通常退出（支払1回、翌despawn重複0）と、959queueからpublicleave_facility_queueを960へ予約しadmission前に1回release・課金0。原planned_exit、wallet、在庫、reservation IDsを実測し、request/guest/serviceの所有を追う。
3) patience: 元traveler.base_patienceをそのまま用い、サーバー不足の実QUEUINGで通常tickにより忍耐が尽きる。自動abandon→再判断→通常退出/Despawnの各境界、原予約1回release/noactiveorphan/stock返却/支払0。patience値やelapsed snapshotを手で書換えない。元templateのplanned_exitが先に短絡しない条件も維持。
4) destruction2branches: 元public register_event_definition/enqueue_eventによる診断用automatic Event（DEFENSE/foregroundfalse/durability0）。offset0では960のFACILITY_COMPLETIONが後段Event破壊より先に完了して支払1回（停止中課金には数えない）。offset1の未完了は960破壊後961にFAILED・予約release once・課金0。前後のevent instance/service/request/予約/ledgerを実測。新しいproduction Event/数値/破壊ルールを作らない。
【共通契約】
各branch fresh Runtime+clock+state、seedと入力明示、元public commandの実結果/ID、実Actor/Service/Request/予約/ledger+payment idempotency、phase順と全typed snapshotを出す。enum snapshotはString定義を確認しint変換しない。7領域/安全性3結果/原15+EV/30-88/部分点0維持。assertをexpected scalar表へ書いて合格させずrawから検証。ケースの規約が原本/承認済みにない部分は捏造せず具体的に残す。
formalは各必要なbefore/after/next/recovered点をpublicSaveServiceでWriter保存、別PID/profile Readerで全member原/copy SHA/原不変/全Runtime typed一致。Readerで境界前の正式loadから通常clock/同じpublic recovery commandで再生し、Writer全typed状態とphase順に一致させる。future recovery commandのidempotency key/command ID/_serial、元reserveなど必要外部probe入力も保存し、Readerが初期serial0で過去setup commandのkeyを再利用しない。snapshotsの内部書換えや比較対象削除は禁止。
S2bでcoordinator_nilが出た教訓: これら元fixtureは本番Operationsをenableしない。無関係なget_day_summary等を無条件に呼ばず、実absenceと正式snapshotのdisabled{}を記録する（新たにenableして回避しない）。全Runtime snapshotは常に無加工比較。全Variant callは明示型、:=推論を避ける静的確認を必須とする。
既存のs2b/run_s2b_native.pyのstrict guardを再利用: source_refs→QA1明示override→private source/cache別inode→import/parse各1→Writer→別PIDReader→ownedfinally+全source/defaultprofile/pin/cache guard。check-onlyはPythonwrapper engine0/privateprofile0。原raw(typedvar+JSON)を各point一度ずつ保存し、branch/indexはpath/SHA参照を使って全snapshotを巨大aggregateへ何重コピーしない。内容の要約置換/省略はしない。stage/cacheもcaseごとに複製しない。
allowed新規 docs/plans/original-completion-2026-10-02/execution/p04-01/s3/ 配下の必要最小限probe/wrapper/Root手順。旧s1/s2/s2b/A/checker/C/protocol/product/DB/契約/base/分母/権限/課金編集0。collector/A仕上げはS3rawの後。worker検証はpy_compile/Pythonwrapper--check-only(engine0)と型/参照の静的確認まで、全回帰/手動commit0で正常code-ready提出。Rootがcurrent製品1338freshplan/native1回で実測。仕様や未知feeを決めない。モデルは既定Solと必要時Astraを、あなた実Opusがこの統合負荷/品質/時間/使用量を見て決めて理由を回答。run.reasonはworkerへ自己完結の具体指示と全絶対pathを含め、contextadapterを増やさない。
