スプリントの検査で cross-review が未解決 0 件のまま上限や error で終わると検査ごと落ち、conductor が手で review を飛ばして再開する #2370

何を見つけたか

スプリントの検査（4-check のプラン）で、cross-review が上限（final: max_rounds）や final: error で終わると、未解決の指摘が 0 件でも検査ごと落ちる。その後、conductor が手でプランを流し直し、2 回目も落ちると review を通らずに base-sync から再開してマージへ進めている。プランの外の手当てである。

スプリント lroot-2（スプリントの PR #2363 ）の例:

見送った 3 件（重複を除くと 2 件。runtimes.json と project.json の読み順。認可 C2 に当たる）は、利用者の方針を受けて同じ PR の f806ae5 で直っている。

検査の記録（check-trigger.py stats、2026-11-02 の 37 回）でも、同じ形（落ちた検査の後に同じ PR の検査が merged になる）が PR #2152・#2192・#2209・#2247・#2250・#2268・#2283・#2312・#2318・#2363 に出ており、同じ手当ては 2 度目を超えている（プロジェクト MVV の Value 4「同じ手当てが 2 度目になった時点で、雛形へ入れる課題を起こす」）。

なぜ困るか

• 検査の review にかかる時間（lroot-2 では 11-01 21:12〜11-02 00:14 JST の約 3 時間）のうち、2 回目の 4 ラウンドは、未解決 0 件のまま上限に当たった後の追加であった
• 「未解決 0 件で上限に当たった」ときに通すか止めるかを conductor がその場で決めており、判断の記録が残らない

直し方の案

• 検査のプランが cross-review の結果（unresolved・final）から、「未解決 0 件・見送りは起票済みか同じ PR で直した」なら次の工程へ進む / そうでなければ人へ戻す、を分岐として持つ
• 落ちた工程「不明」は 検査の記録の集計で閾値を見直せない: トリガーの評価が 0 回・落ちた工程が「不明」・流出不具合の記録が 0 行 #2300 の 2 と同じ原因で、ここでは扱わない
• 結果の契約（ok / gate / stopped）は大方針 異常系・ログ・回復とデータ・入出力の形を 1 つの実行の核へ集め、異常系の課題 103 件を型ごとにまとめて解く #2335 の柱 結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337 が決めるため、その契約の上で分岐を書く

受け入れ条件

• 未解決 0 件で cross-review が上限に当たったとき、検査のプランが conductor の手当て無しに次の工程へ進むか、理由を付けて止まる
• どちらへ進んだかと理由が、検査の記録に残る

見つけた場面

スプリント lroot-2（#2335 #2336）の振り返り（/ndf:retrospective）。本番へ出した PR #2367 。記録は .ndf/loop/lroot/lap-2/sprint/4-check-state/progress.jsonl と ~/.local/state/ndf/checks/devbasex__ai-plugins.jsonl

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

lroot-2 は契約の一覧と構造チェック（#2336）を作った。検査のプランの分岐（supervise_lib/templates.py の検査の雛形）は変えていない