====================================================================
依頼77：同じ条件・同じ種で2回回して、記録が一致するかを見た（コードは変えていません）
2026-11-03 11:22〜11:37
====================================================================

結論（一行）
  一致しない。6組とも、店の時刻 約1,040〜2,620 秒までは同じで、そこから人の譲り（1〜数コマ）でずれ始め、
  終わりには主な数字が大きく揺れる（入店待ち 最大 ±0.73 分・料理の待ち 最大 1.16 分・
  30秒以上の止まり 24 対 6・動けなくなった 12 対 0・rescues 18 対 2）。

--------------------------------------------------------------------
0. 始める前の確かめ
--------------------------------------------------------------------
  ・依頼76：「済み」にあり、結果は「完了」（2026-11-03 11:21）。
    ただし 76 の中の 180 回は、76 自身の止める決まりで回していない（確かめの1回だけ）。
    今回は「76 は済み・報告あり」とみて進めた（決めてほしいこと 3）。
  ・Unity エディタ・night_runner・rec_runner：動いていない（Unity Hub だけ開いていた）。
  ・KIOXIA：マウント済み。unity_ledger_v1.lock：無し。
  ・ServiceSim の保留：0（cs:63 - head）。
  ・実行ファイル：Builds/headless（build_id cs63_20261103_1114・pending 空）。作り直していない。

--------------------------------------------------------------------
1. 回し方
--------------------------------------------------------------------
  ・条件：fam_p1_s4_r2_a42（③）・fam_p5_s4_r2_a42（⑦）× 種 0・3・7。
    普通の混み具合（42組/時）・スタッフ真ん中（4人）・
    すれ違い入・待機場所へ戻る入・入口番入・持ち場入・案B切・一方通行切・1本道切・立ち往生の助け 入。
  ・queue：make_queue.py --conditions fam_p1_s4_r2_a42,fam_p5_s4_r2_a42 --seeds 0,3,7 --label det_a / det_b
    （/tmp/req77/q/det_a.json・det_b.json）
  ・night_runner.py --parallel 4 --night 20261103 --label det_a（続けて det_b）--no-retry
    同時 4 本は依頼76 と同じ（10/26 busycheck で決めた N=4）。6 回なので、どちらも
    「4本 → 残り2本」の同じ並びで走った。
  ・12 回すべて completed・終了コード 0。1回の実時間 3.1〜4.0 分。
  ・出力：KIOXIA service_sim/unity/20261103_det_a_cs63_*・20261103_det_b_cs63_*（_passon_sbret_ek_post_rescue）
  ・比べ方：/tmp/req77/compare.py・first2.py・rt.py（読むだけ）。
    外した列：trips.csv の plan_ms_max（道を引いた実時間）、summary.json の written_at。
    （run_info.json は比べる対象外。wall_seconds・run_label が違うのは当たり前）

--------------------------------------------------------------------
2. 6組の結果
--------------------------------------------------------------------
  8つの記録（trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json）は、
  **6組とも、8つ全部が一致しなかった**。行の数から違う（例 ⑦種0 の people_jams 1315 行 対 257 行）。

  最初にずれた所（時刻でいちばん早いもの。店の時刻 = 回の中の秒）

  組            最初のずれ（記録・行・列・値 a → b）
  ------------------------------------------------------------------------------------------
  ③ 種0   2373.26 秒  yields 83行  客→ロボット2号機 の譲りの x 5.4214 → 5.4207
                      （次は trips 2593 秒発の往復 total_s 90.40 → 90.65、stops 2697.5 秒 duration_s 3.6 → 3.85）
  ③ 種3   1043.21 秒発の往復  trips 8行  min_clearance_m 0.5532 → 0.5906
                      1072 秒 groups 13行 seated_s 1072.14 → 1072.59
                      1085.80 秒 yields 8行  スタッフ Staff01→2号機 の譲り t_s 1085.804 → 1085.754（1コマ）
  ③ 種7   2312.25 秒  rescues 13行  walk_m 16.3883 → 16.3918
                      （2354 秒発の往復 min_clearance_m 0.026 → 0.0386、2396.08 秒 yields 客→1号機 x 5.0767 → 5.0816）
  ⑦ 種0   2593.32 秒発の往復  trips 33行  distance_m 34.1402 → 34.2451
                      2624.31 秒 yields 103行  スタッフ Staff02→1号機 の譲り t_s 2624.305 → 2624.355（1コマ）
  ⑦ 種3   1043.01 秒発の往復  trips 8行  min_clearance_m 0.508 → 0.4947
                      1085 秒 groups 14行 seated_s 1085.403 → 1085.303、1139.01 秒 yields スタッフ Staff02→2号機 x 0.8227 → 0.8
  ⑦ 種7   2178 秒ごろ dishes 33行 ready_s（料理の出る時刻）2276.4 → 2178.1
                      2231.52 秒 yields 94行  客→2号機 の譲り t_s 2231.521 → 2231.572（1コマ）、waited_s 2.85 → 2.7

  ・それより前は、ロボットの位置（robot_track、5 秒ごと）・timeline・yields・stops とも小数4桁まで同じ。
  ・ずれ始めは、どの組も「人（スタッフか客）がロボットに譲る」所か、人の位置で、
    大きさは 0.05 秒（1コマ）や数 mm。そこから連鎖して広がる。

  summary.json の主な数字（a / b）

  組      入店待ち(分)    料理の待ち(分)  30秒以上の止まり  動けなくなった  rescues  往復      店の中(分)
  ---------------------------------------------------------------------------------------------------------
  ③ 種0   1.736 / 1.382   1.548 / 1.625   24 / 18           12 / 0          15 / 10  111 / 109  176.9 / 173.9
  ③ 種3   1.979 / 1.603   2.144 / 1.447   26 / 17            6 / 6          17 / 12  110 / 123  183.6 / 178.6
  ③ 種7   2.790 / 3.522   1.692 / 1.741   33 / 30           10 / 10         25 / 26  118 / 117  196.0 / 196.9
  ⑦ 種0   1.355 / 1.347   1.220 / 1.297   24 / 6             3 / 0          18 / 2   120 / 118  173.2 / 171.8
  ⑦ 種3   1.476 / 1.447   2.853 / 1.689   24 / 12            0 / 0          21 / 7   101 / 121  195.8 / 178.0
  ⑦ 種7   3.106 / 3.570   1.627 / 1.690   21 / 19            1 / 4          17 / 14  122 / 121  195.7 / 196.2

  （30秒以上の止まり = stops.csv の duration_s ≧ 30 の行数。動けなくなった = summary の stops.stuck_count）
  参考：依頼76 の確かめの回（同じ実行ファイル・⑦種7・同時1本で起動）は
        入店待ち 3.516・料理の待ち 1.660・30秒以上の止まり 44・動けなくなった 10・rescues 35・往復 127。
        ⑦種7 は3回で rescues 35 / 17 / 14 と揺れている。

  揺れの大きさ（2回の差）
    入店待ち     0.01〜0.73 分（大きい方から見て 1〜21%）
    料理の待ち   0.05〜1.16 分（同 3〜41%）
    30秒以上の止まり  2〜18 回
    動けなくなった    0〜12 回
    rescues           1〜16 回
    往復              1〜20 回

--------------------------------------------------------------------
3. 原因の当たり（直していない）
--------------------------------------------------------------------
  (A) 本命：人の道の計算が非同期（10/25 の v11 確かめ B と同じ元）
      ・人（スタッフ・客）は NavMeshAgent.SetDestination（非同期）で道を引く
        （People/PeopleNav.cs:130。同期で引く切り替え PeopleNav.SyncPaths /
         ExperimentPlan.detCheckSyncPeoplePaths は今も既定で切）。
      ・道が引けるまで pathPending の間、譲るかの判断（PersonRobotYield.cs:780）と
        着いたかの判断（StaffAgent.cs:209・GuestAgent.cs:177）がそのコマを飛ばす。
      ・何コマかかるかは Mac の忙しさで変わる。今回の最初のずれも、6組中5組が
        「人がロボットに譲る」所の 1コマ（0.05 秒）か数 mm で、この形と合う。
  (B) 同時に回す本数（4本）：忙しさを通して (A) のコマ数を変える。
      10/26 busycheck で「動けなくなった・助けた・ロボット分担」が本数で動くと分かっている。
      今回は2回とも同じ並び（4本→2本）だが、OS の割り当てまでは同じにならない。
      1本ずつで2回回したら一致するかは、今回は見ていない。
  (C) 人の局所回避（Unity の RVO・ワーカースレッド）、物理の問い合わせの返る順番：
      可能性は残るが、1,000 秒以上小数4桁まで一致していたので毎コマ効く形ではない。
  (D) 実時間に頼った処理：見た範囲では動きには使っていない。
      GridPlanner の Stopwatch は plan_ms_max の記録だけ。Time.realtimeSinceStartup は
      1回の上限（今回どれも 4 分で、上限に届いていない）と起動待ちだけ。
  (E) 乱数：すべて System.Random(種から決まる値) で、組ごとに別の列（GroupManager.NewGroupRng）。
      来方（arrive_s）は2回で同じだったので、乱数の使い方はずれの元ではない。
  ・ずれ始めがどの組も約17〜44分後なのは、ロボットと人が細い所で出会う場面が増える時間帯からと見ている。
    そこから止まり・助け・卓の空き方が連鎖して、終わりの数字が上の表の幅で揺れる。

--------------------------------------------------------------------
4. 台帳・そのほか
--------------------------------------------------------------------
  ・台帳：1659 → 1671 行（det_a 6・det_b 6、どれも completed・59 列）。
    始める前の md5 69510edef7fe2a792ba5e27a62421310（依頼76 の終わりと同じ）、
    終わったあと f4bdbeb5ddd45c8b6f7c93a08a15f865。先頭 1659 行の md5 は始める前と同じ。
    退避：archive/unity_ledger_v1_pre_det_20261103/
  ・night/20261103/ は今回新しくできたフォルダ。det_a と det_b を同じ night 名で回したので、
    そこの judge.md・judge.csv・queue.json は det_b のもので上書きされている（runner_log.txt は両方）。
  ・変えていない：コード・params・数字・実行ファイル・台帳の列と今までの行。

--------------------------------------------------------------------
5. 依頼78 の合格の決め方に向けて
--------------------------------------------------------------------
  ・今の作り（同時4本）では「記録が1行も違わない」を合格の線にはできない。
    切り出す前と後の実行ファイルで同じ種を回しても、上の表の幅で揺れるのが普通。
  ・使えそうな線（どれにするかはエイイチが決める）
    a) 先にずれの元（A）を止めて一致する作りにしてから、「1行も違わない」で比べる
       （同期の切り替えはコードにあるが、入れると動きが変わる＝基準が変わる）
    b) 揺れはそのままにして、複数の種・複数回の幅で比べる（例：前後で中央の差が、
       今回の 2回の差の幅に入るか）
    c) 1本ずつで回せば一致するかを先に確かめる（今回は見ていない）
