TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p14-03-route-wait/EVIDENCE_MATRIX.md

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 を待ちます。