同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（issue-upkeep の判定「ルートコーズ」）。再現手順と観測は各子 issue にある。
修正レイヤー
600 秒を超える外部プロセスの待ちの道具。
背景起動と区切った待ちを持つ bg-wait.sh は plugins/ndf/skills/cross-review/scripts/ にあり、他の Skill から使えない（冒頭のコメントも「いま使うのは cross-review だけ」と書く）
cross-refactoring の骨組みは monitor.py を前面で呼ぶ（plugins/ndf/skills/cross-refactoring/SKILL.md:322 / :331 / :343 / :365）
外部 CLI の待ちと配布の照会ループは、この親の範囲から外して送る。
待ち
送り先
external-ai / qa-security-scan / agents/corder.md の上限の無い until のループ（5 か所）
#869 （#852 の external-ai.sh run が上限つきの monitor.py で待つ）
release/references/completion-check.md の sleep 5 の照会ループ#862 （release.py verify-published）
#829 の設計の記録（issues/issue-829-830-design-decisions.md:55-62）は、この 4 文書のループの書き換えを #731 へ送っている。その書き換えは #869 （3 文書）と #862 （completion-check.md）が持つ。
採る手
bg-wait.sh を移す PR は #844 （#829 の実装）のマージの後に作る。waiting.md の「600 秒を超えるなら bg-wait.sh」に移動先を書くためである。
「区切りで応答を終えない」の規則は、plugins/ndf/skills/development-workflow/references/agent-layers.md の supervisor の規則 4（「待ちで応答を終えない。待ちの道具から戻った後、同じ応答の中で次の段へ進む」）と「報告が無いまま終わったとき」（v10.15.0）に置かれた。#829 の実装（PR #844 ）は待ち方の規約を development-workflow/references/waiting.md に置く。この親で残るのは道具の移動と、2 つの収束ループの待ち方の統合である。各 Skill は規則を写さず、waiting.md と agent-layers.md を指す。
子 issue
子 issue
現象レイヤー
観測
#656 cross-review / cross-refactoring を委ねたサブエージェント
ラウンドの待ちで応答を終えて止まる
#345 （external-ai と qa-security-scan の上限の無い待ち）は #869 の重複（→ #869 ）。#656 には、#844 の waiting.md が送った「他の作業が無いまま待つときの手」も残る。
完了条件
bg-wait.sh が共通層 plugins/ndf/scripts/lib/ にあり、cross-review と cross-refactoring の 2 つの収束ループが使うcross-refactoring/SKILL.md の骨組みが monitor.py を前面で呼ばない（grep -n 'monitor.py' plugins/ndf/skills/cross-refactoring/SKILL.md の当たりが bg-wait.sh run の中だけになる）until のループが残らないことの確認（grep -rn "until " plugins/ndf/skills --include=*.md）は external-ai / corder / qa-security-scan: 外部 CLI の起動と待ちを external-ai.sh run の 1 行にする #869 各子 issue の再現手順を実行し、現象が出ないことを確かめる（子 issue はその時点の棚卸が「閉じてよい」で閉じる）
関連
#560 （最初の読み手）、#869 / #852 （外部 CLI の待ち）、#862 （配布の照会）、#870 （drive。bg-wait.sh を共通層への残りの移行に数える）、#829 （PR #844 、waiting.md）
同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（
issue-upkeepの判定「ルートコーズ」）。再現手順と観測は各子 issue にある。修正レイヤー
600 秒を超える外部プロセスの待ちの道具。
bg-wait.shはplugins/ndf/skills/cross-review/scripts/にあり、他の Skill から使えない（冒頭のコメントも「いま使うのは cross-review だけ」と書く）monitor.pyを前面で呼ぶ（plugins/ndf/skills/cross-refactoring/SKILL.md:322/:331/:343/:365）外部 CLI の待ちと配布の照会ループは、この親の範囲から外して送る。
agents/corder.mdの上限の無いuntilのループ（5 か所）external-ai.sh runが上限つきのmonitor.pyで待つ）release/references/completion-check.mdのsleep 5の照会ループrelease.py verify-published）#829 の設計の記録（
issues/issue-829-830-design-decisions.md:55-62）は、この 4 文書のループの書き換えを #731 へ送っている。その書き換えは #869（3 文書）と #862（completion-check.md）が持つ。採る手
move_responsibility）:bg-wait.shをplugins/ndf/scripts/lib/へ移し、monitor.py --phaseと組にする。最初の読み手は cross-refactoring の駆動（cross-review / cross-refactoring: SKILL.md に埋め込んだ駆動の bash を scripts/ へ出す #560 が切り出す）で、同じ PR で入れる。 cross-review の参照も付け替えるconsolidate_duplication）: 2 つの収束ループ（cross-review / cross-refactoring）の待ち方をその道具へ寄せるbg-wait.shを移す PR は #844（#829 の実装）のマージの後に作る。waiting.mdの「600 秒を超えるならbg-wait.sh」に移動先を書くためである。「区切りで応答を終えない」の規則は、
plugins/ndf/skills/development-workflow/references/agent-layers.mdの supervisor の規則 4（「待ちで応答を終えない。待ちの道具から戻った後、同じ応答の中で次の段へ進む」）と「報告が無いまま終わったとき」（v10.15.0）に置かれた。#829 の実装（PR #844）は待ち方の規約をdevelopment-workflow/references/waiting.mdに置く。この親で残るのは道具の移動と、2 つの収束ループの待ち方の統合である。各 Skill は規則を写さず、waiting.mdとagent-layers.mdを指す。子 issue
#345（external-ai と qa-security-scan の上限の無い待ち）は #869 の重複（→ #869）。#656 には、#844 の
waiting.mdが送った「他の作業が無いまま待つときの手」も残る。完了条件
bg-wait.shが共通層plugins/ndf/scripts/lib/にあり、cross-review と cross-refactoring の 2 つの収束ループが使うcross-refactoring/SKILL.mdの骨組みがmonitor.pyを前面で呼ばない（grep -n 'monitor.py' plugins/ndf/skills/cross-refactoring/SKILL.mdの当たりがbg-wait.sh runの中だけになる）untilのループが残らないことの確認（grep -rn "until " plugins/ndf/skills --include=*.md）は external-ai / corder / qa-security-scan: 外部 CLI の起動と待ちを external-ai.sh run の 1 行にする #869 の受け入れ条件が持つ関連
#560（最初の読み手）、#869 / #852（外部 CLI の待ち）、#862（配布の照会）、#870（drive。
bg-wait.shを共通層への残りの移行に数える）、#829（PR #844、waiting.md）