何を見つけたか
/ndf:cross-review と /ndf:cross-refactoring は、担当を「全ランタイム − ホスト」の 3 者から輪番で 2 者選ぶ。3 者が揃わない場面で、2 者を確保する規則が無い。
場面
いま起きること
1 者が認証できない
初期化ごと失敗する（#478 ）
1 者が利用上限に達している
認証の確認は通り、担当に当たったラウンドで NO_RESULT → 起動し直し → final=error（#619 ）
--only で 1 者に絞るそのラウンドの担当が 1 者になり、2 者で見る前提が崩れる
#598 / #537 は v10.13.0（2026-09-16）で解決した。plugins/ndf/scripts/lib/limits.py）が持ち、レビューの工程は 1200 秒になった。担当の CLI の監視の上限とは別に働く。
そのため「agy の打ち切りを避けるために外す」という場面は減った。 母集合を欠く理由として残るのは
実際に、マイルストーン 1 本の開発で 3 回止まった。
PR Fix: Codex Slack通知のメンション削除を修正 #40 final=error。単独で回し直して収束させた
PR Add: plan確定仕様書化スキルを追加 #43 refresh_token_invalidated で final=error。利用者の再ログイン待ちで中断
PR docs: 完了issue由来仕様とランタイム分離計画を整理 #44 cross-review を 1 度も開始できなかった 。「3 ラウンドに 2 回は codex が担当に当たるので必ず落ちる」と判断して開始を見送った
決めたい規則（利用者の指示）
各ラウンドで 2 者がレビューできることを最優先にする。 誰が担当かより、2 つの目で見ることを優先する文脈が分かれていれば、同じランタイムを 2 つ立ててよい。 別プロセス・別文脈なら独立した意見になるコードを書いたランタイム（ホスト）が担当に入ってよい。 輪番の形にはこだわらない他にランタイムが 1 つも無ければ、ホストを 2 つ走らせる形でよい
決めた規則をどこへ置くか
置き場所も決める。 規則が決まっても、置き場所が決まらなければ次に使う人へ届かない。
候補
何を置くか
plugins/ndf/scripts/lib/assignment.py担当の選び方そのもの（使える者の数で分岐する実装）
各 SKILL.md（cross-review / cross-refactoring）
手順として読む担当の決まり方と、渡す引数
docs/2 つの Skill が共有する規則の正本（同一ランタイム 2 つ・ホストの参加を許す判断の理由）
agy を収束ループの担当から外して codex と kiro で回す運用は、リポジトリのどこにも記録が無い。 CLAUDE.md は今も cross-refactoring を「ホストを除く 3 者 」、cross-review を両方 」と書く。docs/ndf-version-decisions.md にも agy を外した記録は無いgrep -rn 'agy を外' --include='*.md' . は issues/issue-624-478-648-design.md:196 の 1 件だけで、この課題で規則を決めたら、CLAUDE.md の記述も
どこで見つけたか
plugins/ndf/scripts/lib/assignment.py の review_pool() / review_assign()（母集合は常に 3 者、そこから輪番で 1 者を外す）plugins/ndf/skills/cross-review/scripts/state.py の init（check_auth が 1 件でも失敗すると die()）plugins/ndf/skills/cross-review/SKILL.md の「レビュワーの母集合」と --only（1 者へ絞る引数しか無い）
なぜこの変更の範囲外なのか
ideabase のマイルストーン 1（#30 #35 #36 #37 #39 ）の受け入れ条件は personal/ と worktime/ の振る舞いで、工程の手順そのものは対象外である。手順書と共通層を直さないと、次に使う人が同じ場所で止まる。
直さないと何が起きるか
担当のランタイムが 1 つでも使えないと、レビューの工程が開始できないか error で終わる。利用者が別の CLI へ再ログインするか、上限の回復（数日）を待つまで、開発が進まない。--host に嘘の値を渡して母集合をずらす回避策はあるが、記録に残る担当が実態と食い違う。
関連
由来
issue #478 （使える者だけで回せるようにする）の続き。ideabase のマイルストーン 1（PR takemi-ohama/ideabase#40 / #43 / #44 ）で 3 回停止した。
cross-refactoring での決定（2026-09-18 追記）
cross-refactoring では、既定の担当から agy を外し、ホストのランタイムを輪番へ入れる と決めた（利用者の指示）。提案も適用も codex / kiro / ホストの 3 者になる。この課題の「コードを書いたランタイム（ホスト）が担当に入ってよい」を、既定の構成として採った形である。
理由は実測にある。CLI の起動 199 回のうち、失敗したのは agy の 7 回（STALLED 4 回・NO_RESULT 3 回）だけで、提案の所要も agy が最も長かった（中央値 5 分。codex は 3 分、kiro は 2 分）。詳細は #664 の追記にある。
assignment.py は cross-review と共有しているため、この課題で決める共通の規則と食い違わないように揃える。
進行
モード: standard / 作業ツリー: .worktrees/feat/issue-727-participants / 計画: issues/issue-727-p6-participants-plan.md
閉じた理由
PR #793 で直り、ndf 10.16.0（2026-09-22、main / タグ ndf--v10.16.0、PR #810 ）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。
振り返り: #810 (comment)
何を見つけたか
/ndf:cross-reviewと/ndf:cross-refactoringは、担当を「全ランタイム − ホスト」の 3 者から輪番で 2 者選ぶ。3 者が揃わない場面で、2 者を確保する規則が無い。NO_RESULT→ 起動し直し →final=error（#619）--onlyで 1 者に絞る#598 / #537 は v10.13.0（2026-09-16）で解決した。 監視の上限は工程ごとの表
（
plugins/ndf/scripts/lib/limits.py）が持ち、レビューの工程は 1200 秒になった。担当の CLI の上限は、環境変数で解決した監視の上限 + 120 秒（既定 1320 秒）を導く。無進捗の許容は担当ごと
（codex 180 / agy 480 / kiro 480 / claude 900 秒）で、監視の上限とは別に働く。
そのため「agy の打ち切りを避けるために外す」という場面は減った。 母集合を欠く理由として残るのは
認証・利用上限・モデルの 404 である。
実際に、マイルストーン 1 本の開発で 3 回止まった。
final=error。単独で回し直して収束させたrefresh_token_invalidatedでfinal=error。利用者の再ログイン待ちで中断決めたい規則（利用者の指示）
決めた規則をどこへ置くか
置き場所も決める。 規則が決まっても、置き場所が決まらなければ次に使う人へ届かない。
plugins/ndf/scripts/lib/assignment.pySKILL.md（cross-review / cross-refactoring）docs/agy を収束ループの担当から外して codex と kiro で回す運用は、リポジトリのどこにも記録が無い。
CLAUDE.mdは今も cross-refactoring を「ホストを除く 3 者」、cross-review を「codex / agy の両方」と書く。
docs/ndf-version-decisions.mdにも agy を外した記録は無い（
grep -rn 'agy を外' --include='*.md' .はissues/issue-624-478-648-design.md:196の 1 件だけで、完了報告の書き方の話であり運用の宣言ではない）。この課題で規則を決めたら、
CLAUDE.mdの記述もあわせて直す。
どこで見つけたか
plugins/ndf/scripts/lib/assignment.pyのreview_pool()/review_assign()（母集合は常に 3 者、そこから輪番で 1 者を外す）plugins/ndf/skills/cross-review/scripts/state.pyのinit（check_authが 1 件でも失敗するとdie()）plugins/ndf/skills/cross-review/SKILL.mdの「レビュワーの母集合」と--only（1 者へ絞る引数しか無い）なぜこの変更の範囲外なのか
ideabase のマイルストーン 1（#30 #35 #36 #37 #39）の受け入れ条件は
personal/とworktime/の振る舞いで、工程の手順そのものは対象外である。手順書と共通層を直さないと、次に使う人が同じ場所で止まる。直さないと何が起きるか
担当のランタイムが 1 つでも使えないと、レビューの工程が開始できないか
errorで終わる。利用者が別の CLI へ再ログインするか、上限の回復（数日）を待つまで、開発が進まない。--hostに嘘の値を渡して母集合をずらす回避策はあるが、記録に残る担当が実態と食い違う。関連
available_reviewersの記録、明示的に外す引数（--exclude）を扱う。この課題で決める規則が、そちらの分岐の表（3 者 / 2 者 / 1 者 / 0 者）の中身になるassignment.pyを共有するため、規則は 1 つに揃えるNO_RESULT（missing）へ畳まれる。外すべき担当を見分ける検知由来
issue #478（使える者だけで回せるようにする）の続き。ideabase のマイルストーン 1（PR takemi-ohama/ideabase#40 / #43 / #44）で 3 回停止した。
cross-refactoring での決定（2026-09-18 追記）
cross-refactoring では、既定の担当から agy を外し、ホストのランタイムを輪番へ入れると決めた（利用者の指示）。提案も適用も codex / kiro / ホストの 3 者になる。この課題の「コードを書いたランタイム（ホスト）が担当に入ってよい」を、既定の構成として採った形である。
理由は実測にある。CLI の起動 199 回のうち、失敗したのは agy の 7 回（STALLED 4 回・NO_RESULT 3 回）だけで、提案の所要も agy が最も長かった（中央値 5 分。codex は 3 分、kiro は 2 分）。詳細は #664 の追記にある。
assignment.pyは cross-review と共有しているため、この課題で決める共通の規則と食い違わないように揃える。進行
モード: standard / 作業ツリー:
.worktrees/feat/issue-727-participants/ 計画:issues/issue-727-p6-participants-plan.md閉じた理由
PR #793 で直り、ndf 10.16.0（2026-09-22、
main/ タグndf--v10.16.0、PR #810）で配布した。リリース後テスト（#810 (comment) ）でこの課題の受け入れ条件はすべて合格した。振り返り: #810 (comment)