NDF Factory: オーガナイザーを Factory の側で実装し、同じリポジトリで並行する実行の本番の配布を 1 本にまとめ、承認と問いを 1 か所に集める #2439

具体例

2026-11-02、3 本の開発ループ（lroot2・lflow・lfactory2）が 1 台のコンテナの tmux で動き、本番の配布がぶつかった。lflow が ndf v10.27.14 に他の 2 本の変更もまとめて出し、lroot2 の本番の Pull Request #2420 を閉じた。#2436（tmux の並列開発を計画から始める）は、これを 1 台の中のオーガナイザーで防ぐ。

Neural Development Factory で同じ 3 本を Web から始めると、周回ごとに別の実行ジョブで動く。ジョブはそれぞれ別のコンテナと別の clone を持つ（ECS の managed・byok、または利用者の手元のマシン #2189）。#2347（開発ループと並行する実行の調整）は、実行を起こす時点で課題・マイルストーン・NDF の版・同時の数の取り合いを守る。一方、承認ゲート 2 と本番の配布は実行ごとに出る。そのため 11-02 と同じ衝突が、同じリポジトリの実行ジョブの間で起きる。#2436 のオーガナイザーは 1 台の SQLite（DBOS）に閉じるので、この衝突を防げない。

Factory では、実行ジョブ 1 本が #2436 のレーン 1 本に当たる（ジョブの中で動くのはスプリント 1 本の conductor で、tmux のレーンは並ばない）。したがって Factory に要るのは #2436 の上位のまとめ役ではない。#2436 と同じオーガナイザーの役割を、レーン = 実行ジョブとして Factory の側で担う実装である（2026-11-02 の利用者の指摘で定義を改めた）。

この課題が終わると、同じリポジトリで並行する Factory の実行の本番の配布は、Factory のオーガナイザーが 1 本にまとめる。承認ゲート 2 は 1 回で済む。承認ゲートの外の問いも、リポジトリごとに 1 か所に並ぶ。

依頼（原文）

今回設計したオーガナイザーの挙動は同一コンテナ内の並列についての挙動ですが、Neural Development Factoryではさらにその上位にランナー間単位のオーガナイザーが必要になりそうです。検討して今の設計に組み込むか、別の設計PRを起こしてください

（書き手: 利用者、日付: 2026-11-02。#2436 の設計 PR #2437 の承認ゲート 1 の前）

用語が混乱してきた。1コンテナ=1ランナーっていう考え方でいいんだっけ？
それとも複数コンテナ起動できるマシン単位で1ランナー？

多分、今回のオーガナイザーの方が範囲が広くなっちゃってるね。「上位のオーガナイザー」の定義を変えないとダメかも

というより、全体のヒエラルキーを定義しないとダメかも。

Factory のオーガナイザーと 1 台の中のオーガナイザー は、対等という以上に排他ですね。
Factoryで動くときには1台の中のオーガナイザーは動かない。

Factoryのオーガナイザーは「1台の中のオーガナイザーの仕事全て+ランナー制御等固有の仕事」がその役割になるはず

（書き手: 利用者、日付: 2026-11-02。続けて受けた 2 つの指摘）

起票者の推定

利用者の原文に無く、起票者（conductor）と要求の工程が推して足した条件。S1〜S5 は起票者の判断の記録 09a63a07a4a5（ask.py decide）による。S6〜S11 は要求の工程が、人へ問わずに最も筋の通る案として選んだ。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

同じリポジトリで並行する Factory の実行どうしで、本番の配布をぶつけずに 1 本へまとめる。承認と問いを、リポジトリごとに 1 か所で答えられるようにする。あわせて、#2436 の階層の定義（確定仕様 https://github.com/devbasex/ai-plugins/blob/develop/docs/specifications/ndf-parallel-organizer.md ）が Factory の側へ割り当てた語の衝突 2 つを解く。

前提

• 前提 1: レーンとオーガナイザーの間の依頼と答えの形は、tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436（tmux の並列開発を計画から始める）が NDF の契約 plugins/ndf/contracts/forms/parallel-request.json として公開し、ndf v10.27.15 で配布した（develop に plugins/ndf/scripts/parallel.py と契約がある）
• 前提 2: NDF の側の切り替え口（本番の配布を自分で組まずに配布の依頼を出す）は、この課題が plugins/ndf/ に作る。NDF_ORGANIZER_DIR・NDF_ORGANIZER_LANE で外のオーガナイザーのレーンと判定する（確定仕様 docs/specifications/ndf-factory-organizer.md の「NDF の切り替え口」）
• 前提 3: 承認の依頼の保存・通知・答えの経路は NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173 のものを使う。この課題は、まとめた配布を 1 件の承認の依頼（種類 ゲート 2）として載せる
• 前提 4: 衝突を解く改名は、ndf-factory の文脈の語だけを対象にする。ndf-workflow の「プラン」（plan.json）は変えない
• 前提 5: 配布の実行ジョブは、リポジトリを登録したアカウントの実行として数える（S11）。利用量の表示と料金の上限での扱いは未決 1 で決める
• 前提 6: 同じリポジトリで同時に動く実行の数は、今の上限（concurrent_repo_runs）のまま変えない
• 前提 7: 受け入れ条件 10 の「parallel.py init・start・run が NDF_FACTORY_RUN を見て断る」処理と、NDF_FACTORY_RUN の契約の宣言は、この課題の NDF の側の変更に含めた。plugins/ndf/scripts/lib/parallel_external_cli.py が NDF_FACTORY_RUN があれば init・start・run を終了コード 1 で断り、契約は plugins/ndf/contracts/env/NDF_FACTORY_RUN.json にある（確定仕様 docs/specifications/ndf-factory-organizer.md の I68、docs/specifications/ndf-parallel-organizer.md の「対象範囲」）

対象範囲

含む:

• Factory のオーガナイザー: 同じリポジトリの実行が出す配布の依頼・承認ゲート 1／2 の依頼・問いの依頼を集め、答えを持ち主の実行へ返す
• ランナーの翻訳: tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436 の契約の依頼を、Factory の進捗の事象へ写す
• 配布の実行ジョブ: まとめた本番の配布を流し、結果を返して終わる専用の実行ジョブ
• 承認の依頼の一覧への載せ方（データと API。リポジトリごとに 1 つ）
• 語の衝突のうち Factory の側の 2 つの改名: マシン単位の 手元のランナー と、アカウントの契約の種類の「プラン」

含まない:

• 1 台の中の並列のオーガナイザー（tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436）
• 実行を起こす時点の課題・マイルストーンの取り合い（NDF Factory: 開発ループ・並行する実行の調整・ジョブの中の区切りと利用上限・手元のランナーの同時実行数・ループの見え方を定義する #2347）
• 承認の依頼の保存と通知の経路（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173）
• 複数のループの承認の依頼の一覧の画面（NDF Factory: 取り込みの衝突（base_conflict）と、複数のループの承認の依頼の一覧が Web の画面に出ない（#2347 の受け入れ条件 7・13 の残り） #2430）
• 手元のマシンの登録（NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189）
• 発表資料（docs/presentations/）と記事（docs/articles/）の語。どちらも書いた日時点の記録である
• ホットフィックス（並列の外の配布の経路）

ドメインイベント

用語

オーガナイザーは役割の名前で、並行するレーンの本番の配布を 1 本にまとめ、問いを集め、答えの後の作業を持ち主のレーンへ返す。実装は 1 台の中（#2436。レーン = tmux のセッション）と Factory（この課題。レーン = 同じリポジトリの実行ジョブ）の 2 つで、上下ではなく排他である。Factory の実行ジョブの中では 1 台の中のオーガナイザーは動かない（2026-11-02 の利用者の指摘）。Factory のオーガナイザーの仕事は、1 台の中のオーガナイザーの仕事すべて（配布を 1 本にまとめる・問いを集める・答えの後の作業を持ち主へ返す・共有の作業を一時レーンへ渡す）に、Factory 固有の仕事（ランナーの制御＝実行ジョブの起動・停止・答えでの再開、実行の枠と手元のマシンの枠、ジョブをまたぐ状態の置き場）を足したものである（同日の利用者の指摘）。語の定義は #2436 の変更が用語集へ足す。「上位のオーガナイザー」という呼び方は使わず、「Factory のオーガナイザー」と呼ぶ。

この課題で新しく決める語（Factory のオーガナイザーの部品の名前、マシン単位の手元の受け手の新しい名前、アカウントの契約の種類の新しい名前）は設計で決め、同じ変更で用語集へ足す。

受け入れ条件

配布のまとめ:

• 1. 同じリポジトリで並行する 2 本以上の実行が承認ゲート 2 に達したとき、本番の Pull Request は 1 本だけ作られる。範囲に入った実行は、どれも同じ本番の Pull Request と版を配布の結果として記録に持つ
• 2. 配布の依頼が届いた時点で流れている配布が無ければ、他の実行の依頼を待たずに配布の範囲を決め、承認の依頼を作る。同じリポジトリの実行が 1 本だけのときも同じ経路を通り、承認の依頼 1 件と本番の Pull Request 1 本になる
• 3. 配布の範囲は、承認資料を作る時点の develop の先頭のコミット（main..<SHA>）で決まる。範囲に入った実行は、依頼を出したかどうかの印つきで承認資料に並ぶ
• 4. 承認の答えの時点で develop が提示したコミットから進んでいれば、承認資料を作り直し、加わった範囲を添えて承認の依頼を 1 回だけ出し直す。出し直しへの答えでは比べず、出し直しで承認したコミットを出す
• 5. 配布が流れている間に届いた依頼と develop へ入った変更は、今の配布の後に組む次の配布になる。同じリポジトリで同時に流れる配布は 1 本までである
• 6. 本番の配布は、範囲に入った実行のどれでもない、配布専用の実行ジョブで流れる。配布専用の実行ジョブは結果を返して終わり、同じリポジトリで同時に 1 本までである
• 7. 承認待ちの間も、範囲に入った実行は答えを待たずに次の周回へ進める（ジョブを終えて費用を止める今の形のまま）
• 8. 同じリポジトリに、Factory の外で作られた本番の Pull Request（head が release/v で始まり、宛先が main）が開いている間は、Factory のオーガナイザーは配布を組まずに待ち、待ちの理由を承認の依頼の一覧の記録に残す。閉じた後の最初の見回りで配布を組む

承認と問いの集約:

• 9. 承認ゲート 1 の依頼と承認ゲートの外の問い（種類 判断）は、リポジトリごとに 1 つの一覧として API から取れる。答えは持ち主の実行（持ち主の実行が終わっていれば、そのループの次の周回）へ届く
• 10. Factory の実行の中では tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436 のオーガナイザーを起動しない。ランナーは実行ジョブの環境に NDF_FACTORY_RUN=1 を立て、parallel.py init・run はそれを見て断る（tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436 の設計の階層の文書）。実行の中の NDF は本番の配布を自分で組まず、配布の依頼を tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動） #2436 の契約の形で出し、ランナーがその依頼を進捗の事象へ写す
• 11. 承認ゲートの承認は、今と同じく人だけが確定できる。API と MCP からは、まとめた配布の承認の依頼と材料を読めるが、承認を確定できない（退行しない）

障害と再開:

• 12. Factory のオーガナイザーの処理が途中で止まっても、次の見回りが記録から続きを再開する。1 件の依頼に答えは 1 回だけ返り、同じ範囲で本番の Pull Request が 2 本作られることは無い
• 13. main へのマージの後に止まった配布は、差し戻しを選べず「続きから流す」だけを出す

語の衝突:

• 14. 用語集の ndf-factory の文脈で、マシン単位で複数の実行ジョブを受け取る手元の受け手に、「ランナー」と別の語が付く。もとの 手元のランナー は廃止した語として用語集に残り、glossary.py check が拾う。Factory の確定仕様・factory/ の説明文・画面の文言（factory/web/src/i18n/）に、廃止した語が残らない
• 15. 用語集の ndf-factory の文脈で、アカウントの契約の種類が「料金プラン」になる。ndf-workflow の「プラン」（plan.json）とは別の語として並ぶ。Factory の確定仕様・factory/ の説明文・画面の文言に、契約の種類を指す裸の「プラン」が残らない
• 16. 改名で、コードの識別子・API の項目名・保存済みのデータの項目名は変わらない（factory/ の型検査とテストが変更前と同じく通る）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-02 21:40
• 作業場所の用意 — 2026-11-03 03:40
• 設計 — 2026-11-02 21:45
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-11-02 22:03
• ドキュメントレビュー
• 計画 — 2026-11-03 03:40
• 実装 — 2026-11-03 03:40
• 構造改善 — 2026-11-04 10:52
• 実装レビュー — 2026-11-04 11:33
• 完了判定 — 2026-11-04 09:02
• Pull Request — 2026-11-04 09:24
• 確定仕様化 — 2026-11-04 14:29
• 後片付け — 2026-11-04 15:02
• 配布 — 2026-11-04 12:57
• 体裁レビュー
• リリース後テスト — 2026-11-04 14:58
• 振り返り — 2026-11-04 14:58
• 棚卸し — 2026-11-04 15:02

振り返り: #2490 (comment)

残っていること

実装は ndf v10.27.16 で配布した（実装の Pull Request #2483 ）。残るのは検証手段の手動確認（同じリポジトリで 2 本の開発ループを Factory で回し、承認ゲート 2 が 1 件だけ一覧に出て、本番の Pull Request が 1 本だけ作られることを見る）だけである。Factory の実環境のインフラは private リポジトリが作るため、この確認を行う時期は private リポジトリ側のインフラの課題が持つ。