同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（issue-upkeep の判定「ルートコーズ」）。再現手順と観測は各子 issue にある。
修正レイヤー
参加する CLI が実行できるかを確かめ、使える者から担当を割り当てる共通層。 場所は plugins/ndf/scripts/lib/auth.py の check_auth（36 行目）と assignment.py の review_pool / review_assign / assign（78 / 95 / 114 行目）である。
check_auth は認証の成否だけを見て、1 件の失敗で die する。モデルを引けるか・更新トークンが生きているかは見ないassignment.py は母集合を「全ランタイム − ホスト」の定数から作り、使える者を入力に取らない- cross-review（
state.py の init）と cross-refactoring（refactor_lib/commands/setup.py の cmd_init）の両方が、この層を使う
設計 issues/issue-624-478-648-design.md の決定 10 は、共通層のうち review_assign だけを cross-review 側で変え、cross-refactoring を #664 へ切り出す。この親の完了条件は、共通層を 1 度に直す形をとる。
採る手
移動（move_responsibility）。使える者の決定を、各 Skill の初期化の関門から共通層の割り当てへ移す。
cross-refactoring の既定の母集合は codex / kiro / ホストとし、agy を外す（#664 / #687 の 2026-09-18 の決定。CLI の起動 199 回のうち失敗は agy の 7 回だけで、提案の所要も agy が最も長かった）。提案も適用もこの 3 者で回す。cross-review と共有する assignment.py で規則を 1 つにし、ホストが codex / kiro のとき（母集合が 2 者）の扱いは #687 の規則（各ラウンド 2 者を確保する。同一ランタイム 2 つ・ホストの参加を許す）に従う。
子 issue
| 子 issue |
現象レイヤー |
観測 |
| #687 |
担当の割り当ての規則 |
担当が揃わないときに、各ラウンド 2 者を確保する規則が無い |
| #478 |
cross-review の init |
レビュワーが 1 者でも欠けると、初期化ごと失敗する |
| #664 |
cross-refactoring の init と適用ラウンド |
担当を外す引数が無く、使える者が 2 者だとレビュー担当が 1 者になる |
| #461 |
cross-review の init（認証の確認） |
モデルを引けない CLI を通し、ラウンドを 1 つ潰して中断する |
完了条件
- 共通層が「最小の呼び出しが通るか」で使える者を決めて返し、割り当てがその一覧から担当を選ぶ
- cross-review と cross-refactoring の両方がこの層だけを通り、片方にだけ古い形が残らない
CLAUDE.md の cross-refactoring の節（「ホストを除く 3 者」「参加する 4 者から輪番」）と cross-refactoring/SKILL.md の「担当の決め方」を、実装後の母集合に合わせる- 各子 issue の再現手順を実行し、現象が出ないことを確かめる（子 issue はその時点の棚卸が「閉じてよい」で閉じる）
進行
モード: standard / 作業ツリー: .worktrees/feat/issue-727-participants / 計画: issues/issue-727-p6-participants-plan.md
閉じた理由
PR #793 #800 で直り、ndf 10.16.0（2026-09-22、main / タグ ndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。
振り返り: #810 (comment)
同じ根本原因を持つ課題（子 issue）を、現れている場所ではなく根本原因の場所で直すための親 issue である（
issue-upkeepの判定「ルートコーズ」）。再現手順と観測は各子 issue にある。修正レイヤー
参加する CLI が実行できるかを確かめ、使える者から担当を割り当てる共通層。 場所は
plugins/ndf/scripts/lib/auth.pyのcheck_auth（36 行目）とassignment.pyのreview_pool/review_assign/assign（78 / 95 / 114 行目）である。check_authは認証の成否だけを見て、1 件の失敗でdieする。モデルを引けるか・更新トークンが生きているかは見ないassignment.pyは母集合を「全ランタイム − ホスト」の定数から作り、使える者を入力に取らないstate.pyのinit）と cross-refactoring（refactor_lib/commands/setup.pyのcmd_init）の両方が、この層を使う設計
issues/issue-624-478-648-design.mdの決定 10 は、共通層のうちreview_assignだけを cross-review 側で変え、cross-refactoring を #664 へ切り出す。この親の完了条件は、共通層を 1 度に直す形をとる。採る手
移動（
move_responsibility）。使える者の決定を、各 Skill の初期化の関門から共通層の割り当てへ移す。cross-refactoring の既定の母集合は codex / kiro / ホストとし、agy を外す（#664 / #687 の 2026-09-18 の決定。CLI の起動 199 回のうち失敗は agy の 7 回だけで、提案の所要も agy が最も長かった）。提案も適用もこの 3 者で回す。cross-review と共有する
assignment.pyで規則を 1 つにし、ホストが codex / kiro のとき（母集合が 2 者）の扱いは #687 の規則（各ラウンド 2 者を確保する。同一ランタイム 2 つ・ホストの参加を許す）に従う。子 issue
initinitと適用ラウンドinit（認証の確認）完了条件
CLAUDE.mdの cross-refactoring の節（「ホストを除く 3 者」「参加する 4 者から輪番」）とcross-refactoring/SKILL.mdの「担当の決め方」を、実装後の母集合に合わせる進行
モード: standard / 作業ツリー:
.worktrees/feat/issue-727-participants/ 計画:issues/issue-727-p6-participants-plan.md閉じた理由
PR #793 #800 で直り、ndf 10.16.0（2026-09-22、
main/ タグndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。振り返り: #810 (comment)