同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（issue-upkeep の判定「ルートコーズ」）。再現手順と観測は各子 issue にある。
修正レイヤー
担当 1 回の起動の結末（結果ファイルの有無と、監視が打ち切った理由）を読み、起動し直してよいかを返す契約。
- 結末の語彙は
plugins/ndf/scripts/lib/monitor_outcome.py、早期の致命の検知は monitor.py の EARLY_ERROR_FATAL にある
- cross-review の
state.py（_read_review_result_file）も cross-refactoring の refactor_lib/gitfacts.py（read_result）も語彙を読まず、結果ファイルの有無だけで判断する（Skill 側で monitor_outcome を読むコードは 0 件）
EARLY_ERROR_FATAL は Monthly request limit reached や "api_error_status":429 の行に一致しない
read_result が die で進行を決める向きは #728 が持つ。
採る手
- 移動（
move_responsibility）: 結果なしの判断を、各 Skill の結果ファイルの読み取りから共通層の結末へ移す
- 新設: 利用上限（
usage_limit）の語彙と検知の文言
子 issue
| 子 issue |
現象レイヤー |
観測 |
| #619 |
cross-review の結果の読み取り |
担当の CLI が利用上限に達すると missing として起動し直し、上限であることが出ないまま error で終わる |
| #647 |
cross-refactoring の適用ラウンド |
利用上限で停止し続ける担当を検知せず、同じ群を再試行し続ける |
完了条件
- 両 Skill が共通層の結末を読み、利用上限を理由として出し、同じラウンドでの起動し直しを止める
- 利用上限の実際の出力（上の 2 形式）を検知することを検査が確かめる
- 各子 issue の再現手順を実行し、現象が出ないことを確かめる（子 issue はその時点の棚卸が「閉じてよい」で閉じる）
進行
モード: standard / 作業ツリー: .worktrees/feat/issue-729-outcome-vocabulary / 計画: issues/issue-729-619-584-implementation-plan.md
開いたままの理由
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 のリリース後テストで G3 の手動確認が不合格だった（結末の共通語彙は入ったが、codex と claude のテキスト出力の文言を照合の表が持たず、理由が失われていた）。表を埋めたのが #811 で、#820 で直した。
担当 1 回の起動の結末を共通の語彙で読み、利用上限の理由が失われないことを、利用者の環境と同じ導入経路で確かめた。
振り返り: #832 (comment)
同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（
issue-upkeepの判定「ルートコーズ」）。再現手順と観測は各子 issue にある。修正レイヤー
担当 1 回の起動の結末（結果ファイルの有無と、監視が打ち切った理由）を読み、起動し直してよいかを返す契約。
plugins/ndf/scripts/lib/monitor_outcome.py、早期の致命の検知はmonitor.pyのEARLY_ERROR_FATALにあるstate.py（_read_review_result_file）も cross-refactoring のrefactor_lib/gitfacts.py（read_result）も語彙を読まず、結果ファイルの有無だけで判断する（Skill 側でmonitor_outcomeを読むコードは 0 件）EARLY_ERROR_FATALはMonthly request limit reachedや"api_error_status":429の行に一致しないread_resultがdieで進行を決める向きは #728 が持つ。採る手
move_responsibility）: 結果なしの判断を、各 Skill の結果ファイルの読み取りから共通層の結末へ移すusage_limit）の語彙と検知の文言子 issue
missingとして起動し直し、上限であることが出ないままerrorで終わる完了条件
進行
モード: standard / 作業ツリー:
.worktrees/feat/issue-729-outcome-vocabulary/ 計画:issues/issue-729-619-584-implementation-plan.md開いたままの理由
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 のリリース後テストで G3 の手動確認が不合格だった（結末の共通語彙は入ったが、codex と claude のテキスト出力の文言を照合の表が持たず、理由が失われていた）。表を埋めたのが #811 で、#820 で直した。
mainへ、タグndf--v10.16.1）read_launch_outcomeが返すstatus/exit_code/reason/relaunch_same_agentの 4 つが、11 形すべてでそろう（EARLY_ERROR/ 4 /usage_limit/False）。記録: Release: ndf v10.16.1 #831 (comment)担当 1 回の起動の結末を共通の語彙で読み、利用上限の理由が失われないことを、利用者の環境と同じ導入経路で確かめた。
振り返り: #832 (comment)