# P14-03 混雑と経路選択：証拠

作業内容は「客用・業務用EV、階段、ワープの待ち時間をA*費用へ反映する」です。受入条件は「ラッシュ、相乗り、50%減速、救護同伴、経路喪失を、実際の位置と人数で検証する」です。

候補は、実装 `0754f41` に次の修正を加えた正確版です。正確な commit は ACCEPTANCE.json に記録します。
- 保存契約 v2
- 乗車中の客の退館修正
- 試験の強化

## 製品の変更

1. **EVの待ち時間を shaft 全体で数える。** 同じ籠で別の階の組を待っている人も、1人あたり1分（ORTHOGONAL_MOVE_COST）として各接続の `dynamic_cost` に公開します。更新するのは、乗車の要求・取消の時と、籠の毎分処理の時です。同じ階の組の行列、満員の籠1回あたり2分、移動階数×階あたり時間は、これまでどおり `estimate_elevator_wait_cost` が数えます。
2. **保存契約を v2 にする。** ElevatorService の snapshot version を 1 から 2 に上げます。
   - v1 は旧版の保存で、昇降機の `dynamic_cost` は常に0でした。v1 は0のときだけ受理し、読込後に待ち時間を導出します。
   - v2 は、行列から導いた値との完全一致を必須にします。全0を含めて、一致しなければ原子的に拒否します。
   - 旧版 `50ceca0` が書き出した本物の保存（`tests/fixtures/p14-03/legacy_rush_v1`）で移行を確認しました。
3. **乗車中の客は籠の中で判断・退館しない。** 乗車中（BOARDED）の客は、籠が有効な階に降ろすまで判断も退館もしません。試験で再現した欠陥は、乗車中に退館を決めた客が乗車中のまま消えるものでした（1094分）。修正後は1115分に1階で降車し、そのあと退館します。

## A*費用

| 移動手段 | 内訳 |
|---|---|
| EV（客用・業務用） | 基本費用＋移動階数×階あたり時間＋同じ組の待ち行列＋shaft の他の組の待ち人数×1分 |
| 階段 | 費用150（移動は半速の2分）＋セルの混雑費用 |
| ワープ | 費用400＋到着先セルの混雑費用。停止中・残量不足のときは除外 |
| 通路 | 定員を超えた1人ごとに75。2人以上が重なると移動速度は50% |

## 証拠（`tests/transport/test_route_wait_choice.gd`。full は119 checks、`-- writer` は39、`-- reader` は7）

| 観点 | 確認したこと |
|---|---|
| ラッシュ | 実際の客12人が籠Aで3階行きを待つと、0→1階の経路は籠Bへ迂回します。籠Aの0→1階の接続は12人分の待ちを費用に含みます。登録した従業員が実際に歩き、籠Bに乗り、籠Aには乗らずに目的地へ着きます。取消後は、待ち費用がちょうど消えます。 |
| 保存・再開 | v2 の保存は完全に往復します。v2 の待ち費用を0や300に改ざんした保存は、原子的に拒否されます。旧版 v1 の本物の保存は移行し、v2 として往復します。v1 に非0値を入れた改ざんは拒否されます。別PIDで再開すると、同じ従業員が同じ物理経路を歩き、全状態の digest が一致します。 |
| 相乗り | 実際の客6人が目的地を持ち、Runtime 自身が乗車を要求します。同時に乗るのは定員4人以内です。全員の乗車が終わり、乗車中に退館を指示された1人を除く5人は、存在したまま1階の乗り場 (4,1,0) にいます。退館を指示された1人も、1階で降車してから退館します。 |
| 経路喪失 | 籠Bを撤去すると、経路は籠Aに切り替わります。実際に歩く従業員も籠Aで目的地へ着きます。撤去後の状態も保存・往復します。 |
| 業務用EV | 裏層の業務用 shaft は従業員専用です。実際の従業員4人が並ぶと、A*費用が上がります。 |
| 階段 | 階段で2階をつなぎ、上の乗り場に客6人がいると、階段経路の費用が上がります。 |
| ワープ | 出口に客6人がいると、ワープ経路の費用が上がります。 |
| 50%減速 | 実際の客5人での確認は `tests/s3/test_runtime_path_traffic.gd:146-158`（定員を超えると半速になり、2分目までに必ず進む）です。`test_path_congestion` は PathService 単体での混雑費用と経路回避の試験です。 |
| 救護同伴 | `test_rescue_elevator` で、2人組が同じ籠を予約し、乗車中の保存・読込が完全に一致し、停止時は2人一緒に降りることを確認します。ワープの2人分課金は P14-02 のレビュー（コード確認）です。 |

## 主張しないこと

- 階段（150、2分）とEV（階あたり10分）の費用の釣り合いは変えていません。近くに階段があればEVより優先されます。
- ワープ到着先の定員4は、混雑費用以外では扱いません。
- 退館中の客は位置に関係なく次の分に消えます（既存の仕組み。P06-02 の非主張）。今回の修正は、乗車中だけに限ったものです。
- Windows 実機は、適用ありの未検証として残します。

## レビュー後の確定（2026-10-20）

- **代表性能 r02**（`artifacts/original-completion-2026-10-02/p14-03-representative-perf-r01/run-r02`）
  - 収集と機能検証は合格し、版間の比較も成立しました（両版とも checks>0、failures 0）。
  - **絶対予算との合格判定は、これとは別にします。** x1 の1分 tick は平均約 827 ms（両版）で、4 ms の予算を超えています。経路、save、load は予算内です。
  - 版間の差分は42ファイルで、P14 だけではありません。そのため「P14 単独の影響はない」とは断定しません。
- **r01 の失敗**: save と load の20件は、probe が保存先を artifacts 配下の絶対パスにしたことによる `UNSAFE_PATH` 拒否でした（save-diag-r01）。製品の欠陥ではなく、計測側の誤りです。
- **試験への注入**: ラッシュの12人と業務用EVの4人は、試験から `request_trip` で直接並ばせています。実際に歩くのは迂回する従業員だけです。進行中に経路を失った actor の再計画は、この suite では試験していません。
- **新PID pair suite**（`test_new_pid_pairs`）: 子プロセスは正式全回帰の外側捕捉の対象外です。正式な別PIDの証拠は Root の pair（10 PID）です。
- **レビュー依頼書の表記**: `REVIEW_REQUEST.md` は提出時のまま保全しています。71行の「r02実行中・結果欄は空欄」は提出前の古い記載で、実値は同じ文書の74〜79行にあります。性能の「両版が合格しなければ比較不成立」は収集と機能検証の成立を指すもので、絶対予算の合格を意味しません。
- **独立Opus レビュー**: PASS（`p14-03-whole-unit-review-r01/review-output.md`）。正式完了は Runner の final を待ちます。