P04-01は、いま通常dispatchで同じa19737bのrepair_pendingからrepair_readyに進みました。repairs=3、max=null、原30/88変更なし。あなたが実際に読んだ承認4文書と記録済み判断を引き継ぎ、Codex実行開始の通常run判断をしてください。新規別タスク/重複実装は作らない。あなたの以下のrequest-repairの具体指示・検証条件・未読事項・原条件保持を、ワーカーに伝わるようrunのreasonにも保持してください。ワーカーは同じ既存checkoutとallowed_pathsだけでchecker/監査文書の最小修正。製品コードとエンジン実行は対象外。Rootが独立して現版境界の生証拠適用性/不足を検証します。P23 r14 collectorは既存のB-readerで画像倍率不一致によりfail、全プロセス終了済み。重い試験0、既存証拠複製も必要なものだけ。空き約1.7GiBのため作業前に必要容量を確認。新しい仕様/数値/帰属は決定しない。D05全体pendingを無条件failへ戻さず個別原条件で判定し、原条件も緩和しない。正式受入の加算は独立レビューと通常統合finalまで0です。許可済み個別上限撤廃を再質問しない。以下が実際の前の判断全文です。
【判断】a19737b に対する第3修正（repairs=2→3、max_repair_attempts=null）として request-repair を記録する。これは判断の記録だけである。今回は起動・dispatch・修正を行っていない。実際に発行するかはRunnerとオーナーの手続きに従う。オーナー承認4文書は .review-material/owner-d05-20261015/ の可視コピーを実際に読んだ。読めなかったもの: (a) shellがないため、4文書のsha256とbytes（D05_OWNER_APPROVAL 4583ee9a…/2073、README 7b1c8992…/1029、recheck 44b32fa2…/46479、OPUS候補 54cd8397…/6653）を再計算していない。値はマニフェストの記載として扱う。(b) 元パス（とりにく工房…）とbuild_dirは作業ディレクトリ外のため読めなかった。(c) 失敗した検証 runs/f2ad55a6…-validation.json も範囲外で、本文を読めていない。失敗理由は、checker:166 の無条件 raise による非0と推定する（未確認）。

【1. 確定した規則を3つに分ける】
(i) 今回承認された2条件（origin=direct_user_reply、formal_acceptance=false）
- D05-P04-DEPENDENCY: 関連施設が休業中は、開始済みサービスの進捗と課金を止める。予約とサービスIDは保持し、復帰後に完了・課金を1回だけ行う。停止の上限は新設しない。現行コードと一致する（facility_service.gd:425-446、_prepare_service_for_tick 853-866）。
- D05-P04-SHIFT-1800: [17:59,18:00) の作業は昼番に帰属する。18:00 tick で完了・課金を1回だけ確定し、その後に交代する。夜番は [18:00,18:01) から勤務する。現行の位相順（kernel:123-153 FACILITY_COMPLETION→AI_DECISIONS）と、shift_instance の半開区間に一致する。
(ii) 既存の権限で決まっている規則
- D-034（DESIGN_DECISIONS.md:252-258、承認済み PLAY-05）: 直接の休業操作では新規受付を止め、待機列の予約と在庫を返す。開始済みサービスは継続する。
- A01: 00:00 の保有時間按分による維持費。再確認しない。
- BASELINE:64/67 で18:00交代、:71/72 で00:00決算（売上−人件費・維持費・返済）が決まる。:183 でマナ枯渇時は全館機能停止。
- 営業時間による閉店は、Runtime から set_opening_hours を呼ぶ箇所がない。既定 [0,1440) のため到達しない。
(iii) 残る D05（EV／搬送停止、費用時点、日跨ぎ）。補完しないが、受入全体を止める根拠にもしない。条件ごとの扱いは次の通り。
- 費用時点：00:00ちょうどに完了したサービス売上を閉じた日・新しい日のどちらに帰属させるか。原本 :71/72 は決めていない。現行は「Day1 [0,1440) の決算→1440 の売上は新しい日」。原受入は「二重決算がない」なので、帰属方向は未確定のまま（pending）記録する。検証は帰属を問わず「売上・給与・維持費が各1回だけ計上される」不変条件に限る。到達ケース: 1440 のサービス完了と決算が同じ分に起きる場合、再送や別PID復元をまたぐ場合。
- 日跨ぎ：夜番 [18:00,06:00) の給与を 00:00 でどちらの決算に分けるか。依存先の休業による停止が 00:00 をまたぐ場合もここに入る。原本 :67/:72 は分割を規定していない。帰属は pending とし、受入は「各勤務分の支払いが1回だけ」と「停止をまたいでも完了・課金が1回、予約の孤立0」で検証する。既存の midnight 証拠は給与0の fixture なので、給与が0でない境界は新しく必要。
- EV停止：elevator_service.set_powered(279-288) で、停電時に昇降機の operational が false になる。原本 :183 からは停止まで決まり、乗車中の扱いは決まっていない。P04-01 の受入に届く経路は「予約を持った客が停止中の籠にいる → 予約の孤立」だけ。予約がいつ取得されるか（移動前か到着後か）は今回確認できなかった（未読）。worker が静的に確認する。到達するなら停電領域のケースとして「孤立0」を検証する。到達しないなら、根拠となる行を付けて対象外と記録する。
- 搬送停止：rescue_transport（Runtime:12023-12030、13000-）には課金も客の予約もない。医務室が OPERATING でなければ治療しないだけ。原本 :68/:110 は搬送が必要であることだけを定める。3つの受入（停止中課金・二重決算・予約孤立）には届かないので、対象外と根拠付きで記録する。P04-01 の7領域分母には加えない。

【2. 最小差分の手順（allowed_paths 内だけ）】
workerの最初の変更: tools/check_p04_order_evidence.py:166 の無条件の D05 raise を削除する。別の包括的な pending に付け替えることもしない。代わりに checker 内に固定した必須条件レジストリを置き、条件ごとに判定する。
- レジストリは index から受け取らない。各条件を authority に対応付ける: BASELINE 行、D-034、A01、承認された2条件（sha256 4583ee9a… の authority artifact を必須にする）。
- 必須条件は次の通り:
  - 停止中課金0（停電、破壊、依存先休業）
  - 完了課金1回（18:00、復帰後、同じ分の再送）
  - 予約孤立0（閉店、退出、patience、停止の00:00またぎ）
  - 決算1回（00:00、再送、正式保存→別PIDでの復元）
  - 夜番不在時の 18:01 WAITING_FOR_STAFF
  - 既存の残業タスク（staff_service:1409-1412）
- 判定ルール:
  - authority が pending の条件は失敗にする。
  - 費用時点と日跨ぎは、帰属を pending と記録したうえで「1回だけ」の不変条件を必須ケースにする。
  - EV と搬送は reach=false と静的根拠 artifact が揃って初めて通す。根拠がなければ失敗にする。
  - 各必須条件には engine 由来の case と invariant を最低1つずつ要求する。
- 出力: すべて満たした場合でも machine_verified=true、formal_acceptance=false とし、exit 0 にする。正式受入はRunnerの検証とレビューで決まる。
- 次に、ORDER_AUDIT.md と order-audit.json を最小限追記する。authority を (i)(ii)(iii) に分ける。blocker の「D05 closure/18:00 未承認」を承認済みへ更新し、承認は試験合格を意味しないと明記する。EV と搬送の到達性を静的に判定した結果を書く。CHECKER_PROTOCOL.md の「常に非0」を改める。
- 既存証拠の再利用: 39 artifact は旧 Runtime 2d7e2cea 上の証拠である。順序関数20本は本体が一致しているので、旧監査の数え方（29）と混ぜずに20本として再監査する。Runtime の差分は経路・候補・到着見積もりの4 hunk で、PathService も変わっている。そのため、経路や到着に依存する停電・破壊・退出の各ケースだけ、現版の適用性を確認する。適用できない場合に限り、Runner/root が新しい有限の境界証拠を作る。worker は engine を実行しない（spec の規定）。
- 注意: この worktree の Runtime は d52a995、production(50b2dbe) は 4696df4a で一致しない。統合の前に、この差分（建設プレビューと事前条件の共通化）が20関数に届かないことを再確認する必要がある。

【3. 検証argv】
- worker（engine なし）: python3 -m py_compile tools/check_p04_order_evidence.py
- 負例fixture（一時ディレクトリを BUILD_OUTPUT_DIR にする）: BUILD_OUTPUT_DIR=<tmp> python3 tools/check_p04_order_evidence.py --verify-only で、次の場合に非0になることを確認する: index欠落、重複キー、symlink、hash不一致、stale pin、未実行 receipt、pending authority、必須条件の欠落、EV/搬送の根拠なし reach=false、承認文書の hash 不一致。
- Runner: p04-acceptance（BUILD_OUTPUT_DIR=<build_dir> python3 tools/check_p04_order_evidence.py --verify-only）。

【4. 独立レビュー】
worker と commander から独立した別セッションのレビュアーが、原P04-01の全条件と7領域、(i)(ii)(iii) の分離、反例 fixture、20関数の適用性を確認する。nativeWindows は条件ごとに pending とする。統合と台帳はRunnerの通常手順に従う。既存契約、7領域、3つの受入結果、分母30/88は維持し、正式完了の加算は0とする。
