待ちの部品 wait_until が上限の時刻に最後の照会を打たず、上限の最大 2 分前に CI 待ちを打ち切る #2224

何を見つけたか

scripts/lib/waits.py の wait_until は、次に眠る秒を足すと上限を超える時点で止まる（_stop_by_idle: idle_for + upcoming_sleep > max_wait）。上限の時刻に最後の照会を打たないため、間隔が最大の 120 秒まで伸びた後は、上限の最大 119 秒を使わずに「結論を得られない」で終わる。

m2171 の検査のフェーズで、cross-refactoring の最終ゲート（refactor_lib/gate_ci.py の ci_gate）が次の出力で終了コード 4 になり、検査のプランが abort した。

❌ チェック ...（160082c / 待ち 1042 秒・照会 14 回 / 上限 1154 秒） の結論を得られませんでした（上限までに終わらない、または照会に失敗）。判断が要ります

上限 1154 秒のうち 112 秒が残っていた。同じコミットのチェックはすべて success で、最後の pytest は 2026-10-30T17:49:47Z に終わっている（gh api repos/devbasex/ai-plugins/commits/160082c5c7c7107f26c708041803fbdefad5f920/check-runs）。conductor が検査のプランを続き（6-check-resume.log）から流し直して通した。

どこで見つけたか

• PR スプリント m2171 #2209（スプリント m2171）の検査のフェーズ。.ndf/tmp/sprint-m2171/6-check.log の理由の行と 6-check-state/04-refactor.out の末尾
• plugins/ndf/scripts/lib/waits.py の _stop_by_idle（34〜38 行）と wait_until（87〜129 行）。呼ぶ側は plugins/ndf/scripts/lib/test_triage.py の wait_check（437 行）

なぜこの変更の範囲外なのか

#2171 の受け入れ条件は factory/ の契約と進捗の受け口だけで、NDF の待ちの共通部品を含まない。#1631 は「CI の待ちの上限（ci_wait_timeout）の決め方」を含まないと明記しており、この課題は上限の値でなく上限の使い切り方である。根拠: NDF の共通原則の「判断の範囲は目の前の変更・操作に限る」（MVV 版 3）。

直さないと何が起きるか

wait_until を使うすべての待ち（最終ゲートの CI 待ち・wait_check を呼ぶ検査）が、上限の値より最大 2 分早く打ち切られる。CI の所要が上限に近いスプリントでは、通るはずの検査が「判断が要る」で止まり、conductor がプランの外で流し直す手当てが要る（#1426 の「プランの外の手当て」を増やす）。

起票者の推定

• 直し方として、最後の眠りを上限までの残りに縮めて上限の時刻に 1 回照会する形が考えられる（推した出所: waits.py の _stop_by_idle を読んだ起票者の判断）
• 影響は wait_until の呼び出し元すべてに及ぶ（推した出所: retry_call も同じ _stop_by_idle を使う、waits.py 70 行）

由来

PR #2209