何を見つけたか
担当が投稿を終えた後、結果ファイルを書く前に監視の上限に達すると、投稿済みの指摘が状態ファイルに記録されない。
引き金は v10.13.0（#598 / #537）で緩んだが、無くなってはいない。 監視の上限はレビューの工程で
420 秒から 1200 秒になり（scripts/lib/limits.py）、下の再現例のように 420 秒で当たることは
なくなった。上限に達したときに記録が残らないという仕組みは変わっていない。 判定は「結果なし」として同じラウンドで担当を起動し直し、起動し直した担当が同じ論点を重ねて投稿する。
PR #578 の round 1（担当: agy / kiro）で起きた。
[agy] ⏰ agy TIMEOUT (420s) — hard timeout 420s reached (pid 30748)
{"agent": "agy", "status": "TIMEOUT", ... "progress_tail": "post: submit review", "result_exists": false}
→ 結果を残さなかったレビュアーがいる: agy。同じラウンドで 1 度だけ起動し直す。
[agy] ✅ agy OK (405s) — process exited; sentinel=False; result_exists=True
✅ agy: intent=REQUEST_CHANGES posted_as=COMMENT comments=1
✅ 新しい指摘が出なくなった。収束。
NEW_FINDINGS=0
| 実行 |
PR に投稿されたもの |
状態ファイルの review_findings |
| 1 回目（上限で停止） |
インライン 4 件（major 1 / minor 3）とレビュー本文 |
0 件 |
| 2 回目（起動し直し） |
インライン 1 件（1 回目の major と同じ論点）とレビュー本文 |
1 件（insufficient_evidence） |
1 回目の 3 件（minor）は判定の入力に一度も入らない。 分類も反証も通らないまま、未解決のスレッドとして PR に残る。最終スイープが拾うため失われはしないが、ループの中の修正の工程は通らない。同じ論点が 2 つのスレッドに分かれ、修正の担当が両方へ返信する。
どこで見つけたか
なぜこの変更の範囲外なのか
#545 の受け入れ条件は、設計 Pull Request の本文と設計文書の決定の見出しを揃えることに閉じており、cross-review の手順は変えない（#545 の設計の決定 7）。
直さないと何が起きるか
証拠集約の印が付いたラウンドで、反証の無い単独の major が数えられず収束することの再現は #624 にある。
由来
PR #578（issue #545）
関連
次の課題は、同じ出口（結果なし → 同じラウンドで起動し直す → final=error）を持つ。
原因と直す箇所はそれぞれ別で、1 件を直しても他は残る。
未着手のもの:
v10.13.0 で解決したもの:
進行
モード: standard / 作業ツリー: .worktrees/feat/issue-730-writes-to-conductor
閉じた理由
PR #801 で直り、ndf 10.16.0（2026-09-22、main / タグ ndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。
振り返り: #810 (comment)
何を見つけたか
担当が投稿を終えた後、結果ファイルを書く前に監視の上限に達すると、投稿済みの指摘が状態ファイルに記録されない。
引き金は v10.13.0（#598 / #537）で緩んだが、無くなってはいない。 監視の上限はレビューの工程で
420 秒から 1200 秒になり（
scripts/lib/limits.py）、下の再現例のように 420 秒で当たることはなくなった。上限に達したときに記録が残らないという仕組みは変わっていない。 判定は「結果なし」として同じラウンドで担当を起動し直し、起動し直した担当が同じ論点を重ねて投稿する。
PR #578 の round 1（担当: agy / kiro）で起きた。
review_findingsinsufficient_evidence）1 回目の 3 件（minor）は判定の入力に一度も入らない。 分類も反証も通らないまま、未解決のスレッドとして PR に残る。最終スイープが拾うため失われはしないが、ループの中の修正の工程は通らない。同じ論点が 2 つのスレッドに分かれ、修正の担当が両方へ返信する。
どこで見つけたか
pullrequestreview-5189163060と、その前の同じ agy の投稿）plugins/ndf/skills/cross-review/SKILL.md:255-261の Step 3 のJUDGE_RC -eq 7の分岐（起動し直した後にverify-findings（:248）とcritique-round.sh（:249）を通らずjudgeへ進む）（
plugins/ndf/scripts/lib/limits.py）が持ち、レビューの工程は 1200 秒になった。担当の CLI の上限は、環境変数で解決した監視の上限 + 120 秒（既定 1320 秒）を導く
なぜこの変更の範囲外なのか
#545 の受け入れ条件は、設計 Pull Request の本文と設計文書の決定の見出しを揃えることに閉じており、
cross-reviewの手順は変えない（#545 の設計の決定 7）。直さないと何が起きるか
_mark_evidence_round、state.py:3199。cmd_collect_critiquesの末尾で呼ぶ）は、1 回目の経路で反証を取り込んだ時点でラウンドに付く。起動し直した担当の指摘はその後に取り込まれるため、反証の対象にならないまま_new_finding_countの絞り込み（_counted_finding_keys、state.py:3674）にかかり、単独の major はinsufficient_evidenceへ落ちる。PR Docs: 設計 Pull Request の本文を設計文書の決定に揃える要求と設計（#545） #578 の 2 回目の 1 件がこれに当たる。cross-review: --only で 1 者だけのとき、反証する担当がおらず REQUEST_CHANGES の新しい指摘があっても収束と判定する #624 と同じ仕組みである証拠集約の印が付いたラウンドで、反証の無い単独の major が数えられず収束することの再現は #624 にある。
由来
PR #578（issue #545）
関連
--onlyで 1 者だけのとき、反証する担当がおらず新しい指摘があっても収束と判定する。収束の誤りの部分はこの課題と同じ仕組みで、cross-review: --only で 1 者だけのとき、反証する担当がおらず REQUEST_CHANGES の新しい指摘があっても収束と判定する #624 と一緒に直す。 この課題に固有に残るのは、投稿の重なりと、JUDGE_RC -eq 7の分岐が証拠集約を通らない点であるstate.py）が行う形にすれば「投稿済みで記録なし」が起きない次の課題は、同じ出口（結果なし → 同じラウンドで起動し直す →
final=error）を持つ。原因と直す箇所はそれぞれ別で、1 件を直しても他は残る。
未着手のもの:
NO_RESULT（missing）へ畳まれ、上限であることが出ない（CLI の利用上限）v10.13.0 で解決したもの:
--print-timeoutが 600 秒固定で、大きな差分では CLI が先に打ち切る（CLI の上限）進行
モード: standard / 作業ツリー:
.worktrees/feat/issue-730-writes-to-conductor閉じた理由
PR #801 で直り、ndf 10.16.0（2026-09-22、
main/ タグndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。振り返り: #810 (comment)