cross-review: レビュー担当の CLI が利用上限に達すると NO_RESULT（missing）として起動し直し、上限であることが出ないまま error で終わる

[takemi-ohama]

何を見つけたか

/ndf:cross-review のレビュー担当（kiro）が CLI の月間の利用上限に達して応答しなかったとき、状態は NO_RESULT（理由 missing）になり、上限であることがどこにも出ない。 進行側は同じ担当を起動し直し、2 回目も同じ理由で落ちて、ループは final=error で終わった。

PR #601（issue #545）の cross-review、round 2（2026-09-13 10:56Z 開始）の実物である。

kiro の標準エラー（kiro-review-pr601-err.log）:

Monthly request limit reached

同じラウンドの状態ファイル（cross-review-pr601-state.json の rounds[-1]、抜粋）:

{"round":2,"reviewers":["codex","kiro"],
 "kiro":{"intent":"NO_RESULT","no_result_reason":"missing","posted_as":null},
 "critique_relaunched":["kiro"],"verdict":"no_result","relaunched":["kiro"]}

全体の final は error。

上限を読む仕組みは 2 つあるが、どちらもこの形を拾わない。

仕組み	何を読むか	拾わない理由
投稿の待ち行列（plugins/ndf/scripts/lib/post_queue.py の is_rate_limited）	GitHub への投稿の失敗	対象が GitHub の上限で、CLI の利用上限ではない
監視の早期の致命検知（plugins/ndf/scripts/lib/monitor.py の EARLY_ERROR_FATAL）	担当の CLI の err.log	上限の語が quota exceeded / rate limit exceeded に限られ、kiro の Monthly request limit reached に一致しない

一致したとしても、理由は missing のままになる。 state.py の NO_RESULT の理由は
missing / not_posted / no_verdict の 3 つで、監視の致命検知の結果を読まない。結果ファイルが無ければ
_read_review_result_file（state.py:2444）が missing を記録し、_die_no_result（:2436）が書き出す。

監視の結果はファイルに残る。 #662 は v10.13.0（2026-09-16）で解決した。 監視の結果は担当ごとの <stem>-monitor.json と
追記だけの monitor-outcomes.jsonl に残り、理由の語彙は
plugins/ndf/scripts/lib/monitor_outcome.py が持つ（ok / timeout / stalled /
early_error / missing / pidfile_bad の 6 語。usage_limit と cli_timeout は未実装）。

読む側がこれを読んでいない。 monitor.py の main（:944）が結果ファイルへ書く一方、state.py は
monitor_outcome を読み込んでおらず、NO_RESULT の理由は missing のままになる。

同じ形の検知漏れ

利用上限のほかにも、担当の CLI が err.log に理由を書いて終わるのに、早期の致命検知に一致せず、結果なし（missing）へ畳まれる形がある。

担当の CLI が書く文言	何が起きたか	課題
Monthly request limit reached	kiro の月間の利用上限	この課題
[agy] print timeout after 10m0s with turn in progress; returning partial output	agy 自身の実行時間の上限	#598 / #537（v10.13.0 で解決。--print-timeout は上限の表から導く）
ERROR: unexpected status 404 Not Found: The model ... does not exist ...	codex の設定が引けないモデルを指す	#461
"api_error_status":429 を含む行	claude の利用上限。cross-refactoring で同じ項目の再試行が 3729 回記録された	#647

_scan_early_fatal に各文言を 1 行だけ書いた err.log を渡した結果（plugins/ndf/scripts/lib で実行）:

'Monthly request limit reached' -> None
'Error: quota exceeded' -> Error: quota exceeded
'[agy] print timeout after 10m0s with turn in progress; retur' -> None
'ERROR: unexpected status 404 Not Found: The model `gpt-5.5` ' -> None
'{"type":"system","subtype":"api_retry","attempt":3,"error_st' -> None

None は一致なし（早期の致命ではない）を表す。対照として置いた Error: quota exceeded だけが致命として返る。

どこで見つけたか

• plugins/ndf/skills/cross-review/scripts/state.py （NO_RESULT の判定と起動し直し）
• plugins/ndf/scripts/lib/monitor.py の EARLY_ERROR_FATAL（:114-126）
• マイルストーン v10.11.0 の並列実行中、PR 設計 Pull Request の本文の決めたことの節を設計文書と突き合わせる（#545） #601 の cross-review round 2。利用者がプランを変更し、kiro の応答を確かめてから再開した

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

マイルストーンの対象は各 issue の受け入れ条件に閉じており、cross-review の担当の失敗の分類はどれにも含まれない。発見時は #545 の担当が再開を優先し、起票しないまま進んだ（振り返りで取りこぼしとして拾った）。

直さないと何が起きるか

• 上限は起動し直しても解けないため、起動し直すたびに時間と相手の CLI の枠を無駄に使う
• 利用者に届く理由が missing だけで、プランの変更で解けるのか、CLI の不調なのか、結果ファイルの書き出しの遅れ（cross-review: 結果ファイルの書き出しを待たずに NO_RESULT と判定して中断する #584）なのかを区別できない。PR 設計 Pull Request の本文の決めたことの節を設計文書と突き合わせる（#545） #601 では進行側がエラーログを開いて初めて分かった
• 残りの担当だけで回す判断（cross-review: レビュワーが 1 者でも欠けると初期化ごと失敗する — 使える者だけで回せるようにする #478 が扱う形）へ進む手がかりにもならない

直し方

土台は入っている。 監視の結果は担当ごとの <stem>-monitor.json と追記だけの
monitor-outcomes.jsonl に残る。残るのは次の 3 つである。

残る作業	現状
理由の語彙を 2 つ足す	monitor_outcome.py の REASONS は 6 語で、usage_limit と cli_timeout は未実装（今は early_error と missing へ落ちる）
検知の文言を足す	EARLY_ERROR_FATAL（monitor.py:114-126）は kiro の Monthly request limit reached に一致しない
読む側を接続する	state.py は monitor_outcome を読み込まず、_die_no_result（:2436）と _read_review_result_file（:2444）が missing / not_posted / no_verdict しか記録しない

• 利用上限は起動し直しても解けないため、理由が usage_limit のときは起動し直さずに止めて報告する判断もここに置ける（cross-refactoring の cross-refactoring: 実装担当が停止し続ける項目で適用ラウンドが無限に再試行される #647 と共通）
• 同じ接続で、cross-review: 結果ファイルの書き出しを待たずに NO_RESULT と判定して中断する #584 の「監視が止めたのか、終了後に結果が無かったのか」の切り分けと、cross-review / cross-refactoring が共有する CLI の確認が認証だけを見るため、モデルを引けない CLI がラウンドを 1 つ潰して中断する #461 の原因表示も片付く

由来

PR #617（ndf v10.11.0 の配布）の振り返り。発生は PR #601（issue #545）の cross-review。

関連

次の課題は、同じ出口（結果なし → 同じラウンドで起動し直す → final=error）を持つ。
原因と直す箇所はそれぞれ別で、1 件を直しても他は残る。

• cross-review の agy へ渡す --print-timeout が 600 秒固定で、大きな差分のレビューが終わらない #537 — agy へ渡す --print-timeout が 600 秒固定で、大きな差分では CLI が先に打ち切る（CLI の上限）
• レビュー本文だけに指摘を書いた担当が「結果なし」と扱われ、届いている指摘で収束が止まる #548 — レビュー本文だけに指摘を書くと、インラインが 0 件のため結果なしと扱われる（投稿の形）
• cross-review: 投稿の後に監視の上限へ達した担当の指摘が記録されず、起動し直した担当が同じ指摘を重ねて投稿する #583 — 投稿の後に監視の上限へ達すると投稿済みの指摘が記録されず、起動し直した担当が重ねて投稿する（上限と投稿の順序）
• cross-review: 結果ファイルの書き出しを待たずに NO_RESULT と判定して中断する #584 — 結果ファイルが揃う前に結果なしと判定する（結果ファイルの書き出しの時点）
• cross-review: agy がハードタイムアウト420秒で常に打ち切られる（stall既定480秒が到達不能） #598 — 監視のハードタイムアウト 420 秒が、担当ごとの無進捗の許容より短い（監視の上限）

根本原因の親:

• 担当 1 回の起動の結末を共通の語彙で読み、利用上限などの理由が失われる形を根本原因の場所で直す #729 — 担当 1 回の起動の結末を共通の語彙で読む。理由の語彙（usage_limit / cli_timeout）と、state.py が monitor_outcome を読む接続はこちらが持つ

検知の部分が重なる課題:

• cross-review / cross-refactoring が共有する CLI の確認が認証だけを見るため、モデルを引けない CLI がラウンドを 1 つ潰して中断する #461 — 認証は通るがモデルを引けない codex がラウンドを潰す（モデルの 404）
• cross-refactoring: 実装担当が停止し続ける項目で適用ラウンドが無限に再試行される #647 — cross-refactoring で claude の 429 を早期の致命として検知できず、再試行を重ねる。検知は共通層の monitor.py で重なる

初期化の時点で近い課題:

• cross-review: レビュワーが 1 者でも欠けると初期化ごと失敗する — 使える者だけで回せるようにする #478 — レビュワーが 1 者でも欠けると初期化ごと失敗する（初期化の時点。こちらはラウンドの途中）。認証は通るが実行で落ちる担当を外す手段もここで扱う

進行

モード: standard / 作業ツリー: .worktrees/feat/issue-729-outcome-vocabulary / 計画: issues/issue-729-619-584-implementation-plan.md

• 要求と受け入れ条件 — 2026-09-15 13:45
• 作業場所の用意 — 2026-09-15 12:44
• 設計 — 2026-09-15 13:45
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-09-15 13:46
• ドキュメントレビュー — 2026-09-15 13:46
• 計画 — 2026-09-19 10:53
• 実装 — 2026-09-19 11:01
• 構造改善 — 2026-09-19 11:45
• 実装レビュー — 2026-09-19 19:48
• 完了判定 — 2026-09-19 19:57
• Pull Request — 2026-09-19 11:41
• 確定仕様化 — 2026-09-21 20:53
• 後片付け — 2026-09-21 20:51
• 配布 — 2026-09-22 14:17
• 体裁レビュー
• リリース後テスト — 2026-09-22 15:06
• 振り返り — 2026-09-22 15:38

開いたままの理由

PR #791 で直し、ndf 10.16.0（2026-09-22、main / タグ ndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）の手動確認（#619 の再現）が不合格だった。kiro の文言と claude の JSON の 429 は理由「利用上限」で起動し直さないが、codex の実物の文言（You've hit your usage limit…、exceeded retry limit, last status: 429）と claude のテキスト出力の文言は missing になり、同じラウンドで起動し直す。#811 を直して確かめ直してから閉じる。

振り返り: #810 (comment)

閉じる理由（2026-09-22）

10.16.0 のリリース後テストで手動確認が不合格だった（kiro と claude の JSON は usage_limit になるが、codex の実物の文言と claude のテキスト出力は missing で relaunch_same_agent=True のままだった）。原因は #811 として切り出し、#820 で直した。

• 直した Pull Request: cross-review / cross-refactoring: codex と claude が利用上限で止まっても同じラウンドで起動し直され、PATH に読めないディレクトリがあると始まらない → 上限を理由として報告して起動し直さず、CLI が欠けても使える者だけで始まる（#811 #813） #820（監視が codex と claude（テキスト出力）の利用上限の文言を読まず、同じラウンドで起動し直す #811 の修正）
• 配布: ndf v10.16.1（2026-09-22T21:41Z に main へ、タグ ndf--v10.16.1）
• リリース後テスト: AC13・AC14 合格。codex の 2 形と claude のテキスト出力の 5 形が理由「利用上限」で止まり、同じラウンドで起動し直さない（relaunch_same_agent=False）。10.16.0 で合格していた 4 形も退行していない。記録: Release: ndf v10.16.1 #831 (comment)

振り返り: #832 (comment)