==================================================================== 依頼79：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す 2026-11-03 11:52　始める前の確かめで止めた（コード・実行ファイル・台帳はどれも触っていない） ==================================================================== 始める前の確かめ ・Unity：動いている。依頼78（人の動きを部品として切り出す）の別の作業が同時に走っていて、 Unity をバッチで起動し、試しのコンパイルをしている（ログ /tmp/req78_compile.log） ・night_runner・rec_runner：動いていない ・KIOXIA：マウント済み。unity_ledger_v1.lock：無し ・ServiceSim の保留：0 ではない（cs:63 head の上に 10 件）。依頼78 の作業中の変更 変更：Experiment/HeadlessRun.cs・ExperimentRunner.cs・TripLogger.cs・Service/JamWatcher.cs・ People/PersonRobotYield.cs・tools/night_runner.py 新規：People/PersonPart.cs・CurrentPersonPart.cs（と .meta） → 「Unity が動いていない」「保留 0」の2つが違うので、依頼のとおり手を止めた やったこと ・上の確かめと、依頼76・77 の報告を読んだだけ ・台帳の退避もしていない（回していないため） 変えたファイル ・この報告ファイルだけ 決めてほしいこと 1. 依頼78 と依頼79 の順番。どちらも人の道・PersonRobotYield・HeadlessRun・ExperimentRunner・ TripLogger を触るので、同時には進められない。依頼78 の check-in（または取りやめ）が終わってから 依頼79 を回すか、依頼79 を先にするか 2. 依頼78 は「中身を変えずに切り出す」なので、依頼79 で人の道を同期にすると 78 の基準が変わる。 78 の後に 79 を回すなら、そのままでよいか 判定：止めた（決めてほしいことあり） ==================================================================== 依頼79b：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す 2026-11-03 11:56〜12:00　「0. 先に片付けること」で止めた（コード・実行ファイル・台帳はどれも触っていない） ==================================================================== 結論（一行） 依頼78 の書きかけは保留として残っていなかった。11:53:14 に cs:64 として check-in 済みで、 そのあと実行ファイル2つ（headless_part64・rec13_part64）を作り、試しの回も1つ始めていた。 cs:63 の状態に戻すには「戻すための check-in」か「作業場所を cs:63 に切り替える」のどちらかが要る。 どちらも依頼の「check-in はしない」「保留を取り消す」の範囲を外れるので、そこで止めた。 -------------------------------------------------------------------- 0. 先に片付けること で見たもの -------------------------------------------------------------------- ・バッチの Unity：残っていなかった。Unity のコンパイル用の裏方（VBCSCompiler、11:52〜11:53 起動の3つ） だけ残っていたので終わらせた。Unity エディタ・night_runner・rec_runner・ServiceSim.app も動いていない ・ServiceSim の作業場所：cs:64 - head、保留 0 cs:64　2026/11/03 11:53:14 コメント「依頼78：人の動きを差し替えられる部品として切り出す（IPersonPart・最初の部品 current＝ 今の動きそのもの。PersonRobotYield・JamWatcher は当てはめと記録だけ。-ssPersonPart、 summary.json・trips.csv に person_part）」 変更：ExperimentRunner.cs・HeadlessRun.cs・TripLogger.cs・PersonRobotYield.cs・JamWatcher.cs・ tools/make_queue.py・tools/night_runner.py 新規：People/PersonPart.cs・CurrentPersonPart.cs（と .meta） （依頼にあった10件に make_queue.py が加わった11件） ・依頼78 が作った実行ファイル（どちらも cs64_20261103_1153・pending 空） Builds/headless_part64（11:53:40）・Builds/rec13_part64（11:53:46） ・Builds/headless：今も cs63_20261103_1114（pending 空）。依頼どおり ・KIOXIA に依頼78 が残したもの（台帳には書いていない） night/20261103_part_p/（11:54） 20261103_part_p_cs64_fam_p1_r0_s0_passon_sbret_ek_post_rescue_stopped（11:54・途中で止まった回） archive/unity_ledger_v1_pre_part_20261103/（11:53・台帳の退避） ・台帳 unity_ledger_v1.csv：1671 行・md5 f4bdbeb5ddd45c8b6f7c93a08a15f865（依頼77 の終わりと同じ。変わっていない） ・unity_ledger_v1.lock：無し。KIOXIA：マウント済み -------------------------------------------------------------------- やったこと -------------------------------------------------------------------- ・上の確かめと、依頼76・77・79 の報告を読んだ ・残っていた Unity のコンパイル用の裏方3つを終わらせた ・コードの戻し・1・2・3 はしていない。台帳の退避もしていない（回していないため） ・依頼78 が KIOXIA に残したフォルダと実行ファイルは消していない 変えたファイル ・この報告ファイルだけ（下に書き足した） -------------------------------------------------------------------- 決めてほしいこと -------------------------------------------------------------------- 1. cs:64（依頼78）をどう扱うか a. 取りやめる：cs:63 の中身に戻す check-in（例 cs:65「依頼78 を取り消す」）をしてよいか。 そのうえで依頼79b を cs:65 の上で進める b. 残す：cs:64 の上で依頼79b を進める（依頼78 は「中身を変えずに切り出す」だが、 動きが本当に変わっていないかは確かめられていない。途中で止められた作業のため） c. 作業場所だけ cs:63 に切り替えて進める（あとの check-in が cs:64 と枝分かれになるので勧めない） 2. 依頼78 が残した Builds/headless_part64・Builds/rec13_part64・KIOXIA の part_p のフォルダ3つを消すか残すか 3. 1 が決まれば、依頼79b を最初からやり直すか 判定：止めた（決めてほしいことあり） ==================================================================== 依頼79c：同じ種で同じ結果にし、立ち往生の助けを瞬間移動なしに直す 2026-11-03 12:00〜12:45　check-in：cs:65（戻し）・cs:66・cs:67　build_id cs67_20261103_1226（保留 0） ==================================================================== 結論 ・1（同じ種で同じ結果）は合格。③⑦ × 種0・3・7 を 2 回ずつ、同時1本・同時4本の両方で回し、 8つの記録（trips・stops・people_jams・yields・contacts・rescues・give_ups・summary.json）が 12 組とも 1 行も違わなかった。1本の回と4本の回どうしでも同じ ・2 は入れた。止まっている台の方を動かす・スタッフは瞬間移動しない（「移した」0 回） ・ただし 3 の⑦種7 で「同じ所で何度も助けが要る」が残った（待機場所で 2 回ずつ 2 組。前は 8 回ずつ 2 組）。 今の動かし先の決め方では、止まっている台が 0.02 m しか動かないため。依頼どおりそこで止めた -------------------------------------------------------------------- 0. 先に片付けること -------------------------------------------------------------------- ・cs:65「依頼78 の取りやめ。cs:63 の中身に戻す」を check-in（作業場所は切り替えていない） 変えた 7 ファイルを cs:63 の中身で上書きし、新しい 4 ファイル（PersonPart.cs・CurrentPersonPart.cs と .meta）を消した ・確かめ：保留 0、Unity エディタ・night_runner・rec_runner は動いていない（Unity Hub だけ）、 cs:63 と cs:65 のファイル一覧が同じ（345 件）、変えた 7 ファイルの中身が cs:63 と 1 字も違わない、 Builds/headless は cs63_20261103_1114 ・Builds/headless_part64・Builds/rec13_part64・KIOXIA の part_p のフォルダは消していない ・始める前：KIOXIA マウント済み、unity_ledger_v1.lock なし、 台帳を archive/unity_ledger_v1_pre_det_rescue_20261103/ に退避（1671 行・md5 f4bdbeb5ddd45c8b6f7c93a08a15f865） -------------------------------------------------------------------- 1. 同じ条件・同じ種なら同じ結果 -------------------------------------------------------------------- 直したこと（3つ） (a) 人の道を同期で引く切り替え（ExperimentPlan.detCheckSyncPeoplePaths）を今の標準（入）にした。 .asset と既定を入にし、画面なしの回は HeadlessRun が毎回入れ直す（.asset に頼らない） (b) 同期の回は、Unity の裏方の作業（job）の流れを 0 本にし、全部を1本の流れで順に回す （JobsUtility.JobWorkerCount = 0。回し終わりに元へ戻す）。 ★ (a) だけでは一致しなかった。1コマごとの指紋で探すと、③種0 の 1921.8 秒で、Staff01 の位置・速さ・道・ 近くの客の様子がまったく同じなのに、よけ方を入れた向き（desiredVelocity）だけが回によって (0.119,-0.636) と (0.154,-0.702) に分かれた。人のよけ方（NavMeshAgent の局所回避）を Unity が 何本もの流れで同時に計算していて、その順番が Mac の忙しさで変わるのが元だった。(b) でここが消えた run_info.json の det_check に「sync_people_paths=入 / job_workers=0」と出る (c) 往復を終えた台を待機場所へ下げる agent の道（GoStandby）も、同期の回は同期で引くようにした（同じ種類の元） ・(b) を入れたら 1 回の実時間が 3〜4 分 → 1.2〜1.5 分に縮んだ（同時4本でも 2 分前後） ・調べ用に -ssDetFrames on（det_frames.csv）・-ssDetPeople 秒,秒（det_people.csv）を足した（ふだんは出ない） 確かめ（cs:67 の Builds/headless・night_runner・--no-retry） 同時1本：det1a・det1b（各 6 回）／同時4本：det4a・det4b（各 6 回）。24 回すべて completed・終了コード 0 比べ方：外したのは plan_ms_max と summary.json の written_at だけ（/tmp/req79/cmp.py） 結果： 同時1本の 2 回 6 組とも 8 つ全部一致 同時4本の 2 回 6 組とも 8 つ全部一致 1本の回と4本の回 6 組とも 8 つ全部一致 （参考に dishes・groups・timeline・robot_track・passes・requeues も全部一致） 記録：night/20261103_det79_det1a・_det1b・_det4a・_det4b -------------------------------------------------------------------- 2. 立ち往生の助けの決まり -------------------------------------------------------------------- ・相手が往復を終えて止まっている台（Idle・往復おわり）なら、止まっている台の方を動かす。 動かす先の決め方は今のまま（呼んだ台の道の先 4 m から 2 台の半径＋0.1 m 以上離れた、いちばん近くの空いた所）。 止まっている台は動かした所で次の仕事を待つ（道は引かない） ・助けに行くスタッフ（ふさがれて 3 秒近づけないとき。細い通路のときだけ） (1) 動かす台の反対側に立つ点まで、ふさいでいる所（前の人・ロボット）を通らずに行ける道を 人用の面を 0.2 m のマスにして探し、あれば途中の点をたどって回り込む（新しい PeopleDetour.cs） (2) なければ通路の入口（店の形の entrance）へ下がり、その通路に人がいなくなったら入る (3) 向かい始めて 60 秒たっても着けなければ、その人は仕事に戻り、助けは板へ戻る。 着けなかった人は同じ助けを取らず、次に手が空いた別の人が取る（全員が着けなければ、また全員が取れる） 助けでは「あきらめた」3 回目の「移した」を使わない ・rescues.csv の列の最後に足した：handoffs（着けずに交代した回数）・handoff_s（交代した人が使った秒）・ entrance_wait_s（入口で待った秒）・detours（回り込んだ回数）。summary.json の stuck_rescue にも合計 ・summary.json に teleports（回のたびの瞬間移動の回数）を足した： guest_escape（客の逃がし弁）・trip_timeout_reset（1往復の打ち切りの置き直し）・ staff_after_3_tries（料理などを運べず3回で移す）・rescue_staff（助け。0 のはず） ・助け以外の瞬間移動の決まりは変えていない -------------------------------------------------------------------- 3. ⑦ fam_p5・種7・ロボット2台の確かめ（rescue79・同時1本・completed・実時間 1.4 分） -------------------------------------------------------------------- 出力 20261103_rescue79_cs67_fam_p5_r2_s7_passon_sbret_ek_post_rescue （同じ種なら同じ結果になったので、det の ⑦種7 の 4 回とも 1 行も違わない） 助けの数：呼んだ 17・動かした 14・自分で動き出して取り消し 1・往復が終わって取り消し 2 相手：ロボット2号機 7・客 5・スタッフ 4・ロボット1号機 1 解けるまで（止まり始めから）中央 51.3 秒・最短 33.9・最長 118.8 依頼76 の 16 回の詰まり（待機場所の手前・受け渡し口の近く） 受け渡し口の近く (15.7, 5.0)：呼び出し 0 回（出なくなった） 待機場所の手前：1号機が自分の待機場所の 0.35 m 手前 (16.56, 5.94) で、待機場所 (17.53, 5.90) に 止まっている2号機を前のセンサーに見て止まる形は残った。2号機を動かすようになったが、 動いた距離は 0.017〜0.026 m。2 回ずつ 2 組（8869〜8941 秒・9169〜9219 秒）助けが入り、 9156 秒からの止まりは 104 秒続いて、2号機が次の往復に出た 9235 秒にやっと解けた わけ：1号機の道は自分の待機場所で終わるので、2号機はもとから「道から 0.6 m 以上外れた所」にいる。 決め方どおりだと、いちばん近い隣のマスへ 0.02 m 動かすだけになる。 一方、体どうしの間は 0.47 m で、前のセンサーの長さ 0.6 m より短いので、1号機は止まったまま 助けに行ったスタッフ 瞬間移動：0 回（give_ups に助けの「移した」「あきらめた」なし。teleports.rescue_staff 0） 着けずに交代 1 回：1163.6 秒、待機場所の2号機へ Staff04 が 60 秒着けず交代、次の人が着いた （歩いた秒 73.7・解けるまで 118.8 秒）。細い通路ではないので、回り込み・入口で待つは働いていない 細い通路 A01 の助け 2 回（4834・5154 秒）は、どちらも交代なしで着いた（歩いた秒 22.5・2.8） 回り込んだ 0 回・入口で待った 0 秒（この回では (1)(2) が働く場面が無かった） 30 秒以上の止まり 16 回・60 秒以上 4 回（うち 3 回は待機場所の上の形） 助け以外の瞬間移動（この回） 客の逃がし弁 15・1往復の打ち切りの置き直し 2・スタッフが3回で移した（片付け）2・助け 0 -------------------------------------------------------------------- 4. 変えたファイルと版 -------------------------------------------------------------------- cs:65 依頼78 の取りやめ（cs:63 の中身に戻す） cs:66 People/PeopleDetour.cs（と .meta）だけ（check-in のやり方を誤り、新しいファイルだけが先に入った） cs:67 cs:66 の続き。Experiment/ExperimentPlan.cs・ExperimentPlan.asset・ExperimentRunner.cs・HeadlessRun.cs・ TripLogger.cs、People/PeopleNav.cs・StaffAgent.cs、Robot/ServingRobotController.cs、Service/ServiceOps.cs 実行ファイル：Builds/headless と Builds/rec14_det67（どちらも build_id cs67_20261103_1226・unity_cs cs:67・保留 0） tools/*.py は変えていない -------------------------------------------------------------------- 5. 台帳 -------------------------------------------------------------------- 1671 行 → 1716 行（追記だけ。列は 59 のまま。先頭 1671 行の md5 は f4bdbeb5… で始める前と同じ） 終わったあとの md5 04d9e503b10b16b11cc5ac885b0f10da。鍵ファイルは残っていない ★ 注意：追記 45 行のうち 20 行（run_folder が 20261103_t1a〜t5b_cs65_…）は、原因を探すために check-in 前の作りかけの実行ファイル（/tmp/ss79_t1〜t5）で回したもの。実行ファイルが自分で台帳に書くため入った。 unity_cs は ServiceSim/cs:65 と出ているが、中身は cs:65 と同じではない。基準データには使わないでください 残り 25 行：det1a・det1b・det4a・det4b 各 6・rescue79 1（cs:67） -------------------------------------------------------------------- 決めてほしいこと -------------------------------------------------------------------- 1. 待機場所で止まっている台を動かす先の決め方。今の決め方（呼んだ台の道から 2 台の半径＋0.1 m 外れた いちばん近い所）だと 0.02 m しか動かず、詰まりが解けない。案： a. 止まっている台を動かすときだけ、呼んだ台の道の先に前のセンサーの長さ（0.6 m）も足した範囲から外す b. 止まっている台は、もう1台の待機場所から離れた決まった空き場所へ動かす c. 待機場所どうしの間（中心どうし約 0.76 m）を店の形で広げる d. 自分の待機場所のすぐ手前（例 0.5 m 以内）で止まっている台にふさがれたら、そこで往復を終えたとみなす 2. 台帳に入った作りかけの 20 行（t1a〜t5b）の扱い（台帳は追記だけなので、印の付け方を決める） 3. 同期の回で Unity の裏方を1本の流れにしたこと（(b)）をこのまま標準にしてよいか。動きの意味は変えていないが、 人のよけ方の細かい値は前の版と同じにはならない（前の版の数字とは並べて比べられない） 判定：止めた（決めてほしいことあり）