tmux の並列開発を計画から始める（並列の計画・レーンごとの引継ぎ文書・オーガナイザーへの指示書・--parallel で起動）

具体例

2026-11-02、利用者は 3 本の開発ループ（lroot2・lflow・lfactory2）を tmux のセッションとして手で起動した。起動の前に、3 本の引継ぎ文書（.ndf/handoff/loop-*.md）へ「3 本並列の決まり」（1 本のループが同時に流すプランは 2 本まで・合計 6 本、触る場所、取り込みの衝突は base-sync で解く）をそれぞれ手で書き写した。

起きたこと:

本番の配布がぶつかった。lflow が ndf v10.27.14 に lfactory2-3 と lroot2-5 の変更もまとめて出したため、lroot2 が出していた本番の Pull Request Release: ndf v10.27.13 を main へ #2420 は閉じることになった（伝言 .ndf/handoff/notice-to-lroot2.md）
統括役（relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346、v10.27.14）で ndf-spawn のブロックからセッションを起動できるようになったが、「並列開発をどう計画し、どう指示すれば始まるか」を定めた手順が無い。ndf-spawn の説明は relay.md の 1 節だけである
同時に動かせる数の上限 NDF_RELAY_MAX_NAMED（既定 3）は統括役も数える。取りまとめのセッションを独立させると、レーンは 2 本までになる

この課題が終わると、利用者は並列の計画を 1 度立て、/goal /ndf:development-workflow --parallel <計画名> と打てば、オーガナイザー（取りまとめのセッション）がレーンを起動し、各レーンが開発を始め、本番の配布はオーガナイザーが 1 本にまとめる。

依頼（原文）

relay.pyはtmuxによる並列セッションが可能となりましたが、並列開発を開始するためにどのような指示の仕方を出せばよいかの定義と受け皿が無いです。
tmuxセッションを複数利用した並列開発のためのSkillを作成し、

事前に並列開発計画を立て、並列数分の引継ぎメモを起こす

オーガナイザーに対する指示書を作成する

/goal /{skill} {オーガナイザーに対する指示書} と指定することでオーガナイザーがセッションを起動し、それぞれのセッションが開発を始める

というようなフローで動くようするのはどうでしょうか？

それ以外の案も検討して方式を確立してください

（書き手: 利用者、日付: 2026-11-02）

起票者の推定

利用者の原文に無く、起票者が決めた条件。判断の記録 83d49e0eb451（ask.py decide）。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。S5〜S7 は要求の工程（2026-11-02）で足した。

#	条件	推した出所	この要求での扱い
S1	新しい Skill を作らず、計画は `issue-plan-strategy`（実行計画）、起動は `development-workflow` の `--parallel <計画名>` で受ける	既存の Skill へ統合してから新設を考える方針。分割と並行の手順は `issue-plan-strategy` の担当（`parallel-work.md` の境界）。`--loop` が同じ形の前例	受け入れ条件 1・4
S2	オーガナイザーは起動の後も残り、レーンを監視し、本番の配布を 1 本にまとめる	11-02 の配布の衝突は、調整する役が無いと再発する	受け入れ条件 5・6
S3	レーンの最初の入力は開発ループ（`--loop <名>`）でも 1 スプリント（`#<課題>`）でもよい	11-02 の実運用はループ。スプリントも入力の違いだけで受けられる	受け入れ条件 2
S4	オーガナイザーは同時に動かせる数に数えない	開発のプランを流さず負荷が小さい。数えるとレーンが 2 本になり、実運用の 3 本を下回る	受け入れ条件 7
S5	原文の「オーガナイザーに対する指示書」を「並列の計画」（1 つの文書）と呼ぶ	用語集の「指示書」は `AGENTS.md` / `CLAUDE.md` などの規約の文書を指す（`docs/glossary/glossary.json`）。1 語 1 意味（Value 8）を守るため	用語・受け入れ条件 1〜4
S6	オーガナイザーを起動し直すと、`.ndf/parallel/<計画名>/` の記録から続ける	オーガナイザーもカットポイントで区間を切り替える。記録から続けられないと、配布の依頼を取りこぼす	受け入れ条件 11
S7	全レーンが止まり、処理していない配布の依頼が無ければ、オーガナイザーは要約を出して終わる	終わる条件が無いと、オーガナイザーが待ち続ける	受け入れ条件 12

案の比較（新しい Skill・既存 Skill へ統合・オーガナイザーを置かない）は設計文書の「決定の記録」に置く。

目的

1 つのリポジトリで複数の開発の流れ（レーン）を同時に進めるとき、利用者が並列の計画を 1 度書いて 1 行で始められ、本番の配布がレーンどうしでぶつからない状態にする。11-02 の手作業（引継ぎ文書への決まりの書き写し・セッションの手での起動）と、配布の衝突（Pull Request 2420 を閉じた件）を繰り返さない。

前提

統括役・名前つきのラッパー・ndf-spawn・relay.py spawn/ls/attach/stop/restart は relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346 のとおりに動く（v10.27.14）
同時に流すプランの合計の上限は、環境変数 NDF_PARALLEL_MAX_PLANS で変えられ、既定は 6 本（2026-09-25 の実測。8 コア・30 GB。2026-11-03 の承認ゲート 1 で利用者が「設定にする」と決めた）
承認ゲートは 2 つのまま増やさない。並行したレーンの本番の配布は、承認ゲート 2 の 1 回の承認へまとめる（parallel-work.md の「承認は承認ゲートでまとめる」）
Claude Code だけで動く（ラッパーが Claude Code だけのため）。ラッパーの外・tmux が無いときは、手で起動するためのコマンドを示して終わる
本番の配布の中身は依頼の集合ではなく、develop に入ったコミットで決まる。依頼の有無によらず、承認したコミットまでに develop にある変更はすべて入る
レーンどうしは同じ develop へマージする。本番の配布は承認したコミットまでの develop を出すため、そこまでに develop にある他のレーンの変更も含む（承認資料にレーンごとの内訳を載せる）

対象範囲

含む:

並列の計画の形と、それを作る手順（issue-plan-strategy）
レーンごとの引継ぎ文書を作る手順
並列の計画の検査（スクリプト）
--parallel <計画名> の起動、レーンの起動、レーンの監視
配布の依頼の形と、オーガナイザーによるまとめ
同時に動かせる数の数え方（オーガナイザーを数えない）
計画名を指定した一括の停止

含まない:

別のマシン・別のコンテナにまたがる並列
統括役の起動の仕組みそのもの（relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346）
レーンの中の工程（loop.md・スプリントの手順は、配布の依頼の分岐と配布待ちの周回の扱い（受け入れ条件 6a）のほかは変えない）
Codex で動かす並列（ラッパーが Claude Code だけのため）

ドメインイベント

#	イベント	引き金	失敗したとき	順序の前提
E1	並列の計画を書いた	利用者が `issue-plan-strategy` で並列の計画を頼んだ	—	—
E2	レーンごとの引継ぎ文書を作った	E1 の手順の続き	同じ名前の引継ぎ文書が既にある: 上書きせず止め、名前を示す（受け入れ条件 2）	E1
E3	並列の計画を検査した	E1 の手順の最後と、E4 の直後	誤りがある: 統一 JSON レポートで項目を返し、レーンを起動しない（受け入れ条件 3・4）	E1
E4	オーガナイザーが起動した	利用者が `/goal /ndf:development-workflow --parallel <計画名>` と打った	計画名の並列の計画が無い: 起動せず、計画の置き場を示して終わる	E1
E5	レーンを起動した	E3 が通った。依存のあるレーンは、依存先のレーンが止まった時点	統括役が断った・tmux が無い: そのレーンを手で起動するコマンドを示す（受け入れ条件 9）	E3・E4
E6	レーンが開発を始めた	レーンが引継ぎ文書を読んだ	引継ぎ文書が無い: レーンは止まり、オーガナイザーが状態の変化として受け取る	E5
E7	レーンの状態が変わった（承認待ち・止まった）	レーンの工程	—	E6
E8	レーンが配布の依頼を置いた	レーンが承認ゲート 2 の手前に来た	—	E6
E9	オーガナイザーが承認ゲート 2 を求めた	E8 を受け取った	承認されない: 依頼を残し、依頼したレーンへ差し戻しを返す	E8
E10	本番を配布した	E9 の承認	配布が失敗した: 依頼を残し、依頼したレーンへ失敗を返す	E9
E11	依頼したレーンへ配布の結果を返した	E10 か E9・E10 の失敗	—	E9
E12	計画名を指定して全レーンを止めた	利用者の停止の指示	止まらないレーンがある: 名前を返す	E5
E13	オーガナイザーが終わった	全レーンが止まり、処理していない配布の依頼が無い	—	E7・E11

用語

用語	意味
並列の計画	1 つのリポジトリで同時に進めるレーンの一覧と、レーンに共通の決まりを書いた 1 つの文書。オーガナイザーが読む。名前（計画名）を持つ
レーン	並列の計画の下で、名前つきのラッパー 1 本が進める開発の流れ。最初の入力は開発ループかスプリントの 1 つ
オーガナイザー	`--parallel <計画名>` で起動した conductor の役割。レーンを起動・監視し、配布の依頼をまとめて本番の配布を 1 本にする。統括役（ラッパーの役）とは別
配布の依頼	レーンが承認ゲート 2 の手前で、本番の配布をオーガナイザーへ頼む 1 件の依頼（DBOS のメッセージ）

受け入れ条件

issue-plan-strategy が並列の計画を作る手順を持つ。並列の計画は、レーンごとに名前・最初の入力・触る場所・同時に流すプランの本数・始める条件（他のレーンへの依存）を決め、1 つの文書に書く
並列の計画を作る手順が、レーンの数だけ引継ぎ文書を作る。レーンに共通の決まり（プランの本数の配分・触る場所・配布の担当）は並列の計画の 1 箇所に置き、引継ぎ文書は並列の計画を参照する（各文書へ写さない）。同じ名前の引継ぎ文書が既にあれば上書きせずに止める
並列の計画をスクリプトが検査する。レーンの数が上限を超える・プランの本数の合計が 6 を超える・名前の形が違う・依存先が並列の計画に無いか循環する・触る場所が重なる（重なりは警告）を、統一 JSON レポートで返す。誤りがあれば終了コードは 0 以外
/goal /ndf:development-workflow --parallel <計画名> で起動したセッションがオーガナイザーになり、検査を通った並列の計画のレーンをすべて起動する（依存のあるレーンは依存先が止まってから）。各レーンは引継ぎ文書を読んで開発を始める。検査に誤りがあれば、レーンを 1 本も起動しない
オーガナイザーは、レーンの状態が変わる（承認待ち・止まった・配布の依頼）まで、スクリプトで待つ。手書きのループや前景の sleep で待たない
並列の計画の下のレーンは、本番の配布を自分で行わず、オーガナイザーへ依頼する。配布のために他のレーンを待たない。 依頼が届いた時点で流れている配布が無ければ、オーガナイザーは直ちに配布を組む。配布の中身は依頼の集合ではなく、承認資料を作る時点の develop の SHA で決まる（main..<SHA>）。承認の答えを受けた時点で develop が提示した SHA より進んでいれば、加わった範囲を添えて同じ承認ゲート 2 を 1 回だけ出し直す（「新しい範囲で出す」「最初の範囲だけ出す」「差し戻す」）。出し直しの後に develop が進んでも、出すのは出し直しで承認した SHA である。develop へのマージは保留しない（レーンの開発版の配布と確認を止めない）。承認した SHA より後に develop へ入った変更・届いた依頼は次の配布になる（今の配布が終わった直後に組む）。範囲に入っていたレーンには、依頼の有無によらず配布済みと版を返し、そのレーンは本番を出し直さずに続きの工程（振り返り・まとめ）へ進む。並列の計画の外で動くループ・スプリントの配布も、受け入れ条件 6b の規則（承認したコミットを release/v<版> から出す）で動く。それ以外の手順は変わらない
6a. レーンは配布の依頼を置いた後、答えを待たずに次の周回（スプリント）へ進む。配布待ちの周回の課題は次の周回の選定に入れない。答えが届いたら、レーンは周回の境で配布待ちの周回の残りの工程（リリース後テスト・振り返り・課題を閉じる・棚卸し）を流してから続ける。差し戻されたら、その周回を今の差し戻しの扱いで締める
6b. 承認した SHA をそのまま出せるよう、本番チャネルへの PR の規則を改める。main 宛の PR は「develop から出たものだけ」から「develop に含まれるコミットだけ」にし、head を release/v<版>（承認したコミット + 版を上げたコミット。先に develop へマージ済み）とする。scripts/check-pr-base.sh・release-steps.py の本番の PR・release: 承認した時点のコミットを控えず、承認の後に開発版のチャネルへ入った変更が本番へ届きうる #815 の承認の照合・AGENTS.md の Git 運用ルール・docs/versioning-and-distribution.md を合わせて直す。版を上げたコミットを develop へ戻すときの版数の衝突は配布のステップが本番の版を取って解く
6c. 並列の計画の下では、承認ゲート 1（設計の承認）と承認ゲート 2 の問いはオーガナイザーだけが出す。レーンは AskUserQuestion で止まらない。設計の承認が要るとき、レーンはオーガナイザーへ依頼を送り、その課題を人の判断待ちへ移して残りの課題か次の周回へ進む（ループでないレーンは依頼の後に終わり、承認の後にオーガナイザーが起こし直す）。オーガナイザーは届いている設計の承認の依頼を 1 回の問いにまとめ、答えの時点で新しい依頼が届いていれば続けて問う。承認の後の操作（承認ラベル・設計 Pull Request のマージ・loop answer）は受け入れ条件 6f のとおり持ち主のレーンが行い、その課題は次の周回の選定へ戻る。承認ゲートの外の問いも受け入れ条件 6d のとおりオーガナイザーへ集める
6d. 並列の計画の下のレーンでは、承認ゲートの外の区分つきの問い（費用・取り消せない操作・規約・レッドライン・人にしかできない操作）も、問いの hook がオーガナイザーへ送る。レーンはその作業を質問待ちにして別の作業へ進み、答えが届いたら周回の境で再開する。オーガナイザーは承認ゲートの問いと同じ回にまとめて出し、答えをレーンへ返す。人にしかできない操作は relay.py attach <レーン> の案内を問いの一覧に出す
6e. 差し戻しの後に直す作業は、変更の持ち主のレーンが行う。オーガナイザーが行うのは、問いを集める・示す・答えを配ることと、本番の配布だけである。設計の承認の答えに「直して出し直す」（指摘つき）を足し、レーンは次の周回でその課題を最優先に選んで同じ設計 Pull Request を直し、承認の依頼を送り直す（「やらない」は今の差し戻しの扱い）。承認された設計 Pull Request のマージもレーンが行う。配布の差し戻しは、指摘をレーンごとに返し、該当するレーンが直す Pull Request か外す revert の Pull Request を develop へ入れ、次の配布で出す。直すレーンが終わっていれば、オーガナイザーが起こして答えを渡す
6f. オーガナイザーは作業を持たない。答えの後の処理は持ち主のレーンが行い、オーガナイザーは答えを送るだけである。持ち主のレーンが終わっていれば、オーガナイザーは relay.py restart <名前> で起こすだけにする。持ち主のいない共有の作業（本番の配布のプランの実行・その失敗の対応・版数の衝突の解消）は、その時だけの一時レーンが行う。一時レーンは同時に 1 本までで、同時に動かせる数（NDF_RELAY_MAX_NAMED）を 1 本だけ超えてよい。作業が終われば自分で止まり、結果をオーガナイザーへ返す。同時に流すプランの合計（6 本）には数えない
6g. 一時レーンの失敗もオーガナイザーへ問いを集める。直せない失敗は 6d の経路で問いになり、一時レーン自体が止まればオーガナイザーが見つけて問う。main へのマージの後に止まった配布は、差し戻しを選ばせず続きから流す
6h. 異常系を次のとおり扱う: オーガナイザーのセッションが切り替わっても進行のプロセスは残り、打ち直しで二重にならない／同じ計画の二重起動を断る／一定の時間動かないレーンを問う／配布を差し戻した変更が develop に残る間は、オーガナイザーは自動で配布を組まず資料に示す／同じ原因の問いは 1 つにまとめて答えを配る／手元の作業が待ちだけになったレーンは止まり、答えで起こされる／レーンの間で課題とマイルストーンが重なれば検査の誤りにする／メインディレクトリの git の操作はレーンの間で 1 本ずつにする／設計の直しが 3 回続けば方針を問う／答えに問いの時点の印を付け、前提が変わっていればレーンは問い直す／止まったレーンの配布待ちのまとめは計画を終えるときに一時レーンで流す／配布の途中の停止は配布を終えてから止める／利用上限で全レーンが止まれば 1 回だけ知らせる
オーガナイザーのセッションは NDF_RELAY_MAX_NAMED に数えない。既定のままで、オーガナイザー 1 本とレーン 3 本が同時に動く
計画名を指定して全レーンを止められる。1 本のレーンだけを止めるのは今の relay.py stop <名前> で行う
ラッパーの外・tmux が無いときは、オーガナイザーはレーンを起動せず、手で起動するためのコマンド（レーンごとの 1 行）を示して終わる
relay.md の ndf-spawn の節と用語集から、並列の計画の手順へ辿れる
オーガナイザーを起動し直すと、.ndf/parallel/<計画名>/ の記録から続ける。起動済みのレーンを二重に起動せず、処理していない配布の依頼を取りこぼさない
全レーンが止まり、処理していない配布の依頼が無ければ、オーガナイザーはレーンごとの結果（配布した版・止まった理由）を要約して終わる

非機能の条件

大項目	条件
可用性	オーガナイザーが止まっても、レーンは動き続ける。配布の依頼を置いたレーンは、結果が返るまで待つ（受け入れ条件 11 で再開する）
性能・拡張性	同時に流すプランの合計は `NDF_PARALLEL_MAX_PLANS`（既定 6 本）まで（前提 2）。レーンの数の上限は `NDF_RELAY_MAX_NAMED` に従う
運用・保守性	検査・待ち・停止のスクリプトは統一 JSON レポートを返す。並列の計画と配布の依頼はメインディレクトリの `.ndf/parallel/<計画名>/` に置き、コミットしない
システム環境	Claude Code とラッパー（relay.py）と tmux があるときだけ起動まで行う（前提 4）

影響

対象	影響
公開インタフェース	変わる。`development-workflow` の引数に `--parallel <計画名>` が増え、`relay.py` に計画名で止める指定が増える。既存の引数・サブコマンドの振る舞いは変えない（互換あり）
データ	`.ndf/parallel/<計画名>/` を新しく置く。既存の `.ndf/handoff/`・`.ndf/loop/` の形は変えない
既存の振る舞い	統括役の上限の判定が、オーガナイザーの印を持つラッパーを数から外す。ループ・スプリントの配布の手前に、並列の計画の下のときだけ依頼の分岐が入る

検証手段

項目	手段
テスト	`uv run --frozen --project . --all-extras pytest plugins/ndf/scripts/tests -q -n 4`（検査・待ち・上限の数え方・計画名での停止・再開の単体テスト）
静的解析	`python3 scripts/check-skill-frontmatter.py`、`python3 plugins/ndf/scripts/instructions-check.py --root .`、`claude plugin validate .`
用語	`python3 plugins/ndf/scripts/glossary.py check --file issues/issue-2436-requirements.md` が当たり 0 件
手動確認	リリース後テストで、tmux のある端末から 2 レーンの並列の計画を `--parallel` で起動し、両レーンが始まること・配布の依頼が 1 回の承認ゲート 2 にまとまることを見る

前提とする取り決め

項目	参照先 / 決めたこと
プロジェクト構造	Skill の手順は `plugins/ndf/skills/issue-plan-strategy/`・`development-workflow/` の本文と references、スクリプトは `plugins/ndf/scripts/`（統括役は `relay_lib/`）。新しい Skill を作らない（S1）
コーディング規約	`AGENTS.md` の「最小限のコード実装」、`plugins/ndf/skills/AUTHORING.md`。待ちは `waiting.md` の形
テスト戦略	スクリプトの判定（検査・上限・停止・再開）は単体テストで担保する。`.md` の文言を照合するテストは書かない。起動から配布までの通しはリリース後テストで見る

境界

区分	内容
常に行う	既存テストの実行、統一 JSON レポートの形に合わせる、用語集への 4 語の追加
確認してから行う	`development-workflow` の引数と統括役の上限の判定の変更（承認ゲート 1・2 で人が見る）
行わない	統括役の起動の仕組みの作り直し、レーンの中の工程の変更（配布の依頼の分岐を除く）、別のマシンにまたがる並列

未決

項目	誰が決めるか	期限
オーガナイザーの印の持ち方（環境変数か登録簿の役割か）	設計の工程	承認ゲート 1
並列の計画の書式（Markdown の表か JSON か）と、レーンが自分が並列の計画の下にいると知る方法	設計の工程	承認ゲート 1
レーンの数の上限を `NDF_RELAY_MAX_NAMED` から読むか、別に持つか	設計の工程	承認ゲート 1

設計の手がかり（起票者が調べたこと）

設計の工程はこれを出発点にし、比べた結果を「決定の記録」へ書く。

論点	調べた事実	起票者の見立て
案の比較	A: 新しい Skill（依頼の形）／B: 既存 Skill へ統合（S1）／C: オーガナイザーを置かず、計画の手順が `ndf-spawn` のブロックを並べて出すだけ	B。C は 11-02 の配布の衝突を防げない
オーガナイザーの居場所	端末で最初に打った `claude` のラッパーが統括役（`relay_lib/hub.py`）。上限の判定は `Hub.judge` の `now.count >= max_named()` だけで、統括役も数える	オーガナイザーは統括役のセッションで動かし、印（環境変数か登録簿の役割）を持つラッパーを数から外す
レーンの起動	応答の ```ndf-spawn <名前> のブロック（中身が最初の入力）か `relay.py spawn --name <名前> --json -- <入力>`	スクリプトから `relay.py spawn` を打つ（結果を JSON で受け取れる）
監視	`relay.py ls --json` が名前・状態（running / awaiting_approval / stopped）を返す。待つコマンドは無い	状態が変わるか配布の依頼が届くまで戻らない待ちのコマンドを足す（`supervise.py wait` と同じ使い方）
配布のまとめ	レーンのループの `pipeline` は開発版 → 承認ゲート 2 → 本番まで流す（`loop.md`）。11-02 は先に出したレーンが develop にある他のレーンの変更も出した	並列の計画の下では、レーンは承認ゲート 2 の手前で依頼のファイル（メインディレクトリの `.ndf/parallel/<計画名>/`）を置いて待ち、オーガナイザーが 1 回の承認ゲート 2 で 1 本の本番を出し、レーンへ結果を返す
置き場	引継ぎ文書は `.ndf/handoff/`（`handoff.md`）、ループの記録は `.ndf/loop/<名>/`。どちらもメインディレクトリに置きコミットしない	並列の計画と配布の依頼は `.ndf/parallel/<計画名>/`、レーンの引継ぎ文書は今の名前（ループなら `loop-<名>.md`）のままにする
語	「統括役」は relay.py のハブ（ラッパー）を指す。実行主体の 3 層は conductor → supervisor → worker	「オーガナイザー」は並列の計画を受け持つ conductor の役割名として用語集へ足す。統括役と混ぜない

進行

モード: —

要求の変更（2026-11-02、利用者）

複数の周回ループを動かしている中で、リリースするのに他のループを待つのは避けたいです。
承認待ちの間に他のループも承認待ちに入ったらまとめる。そうでなければ1本だけでリリースする、といった動きを希望

（書き手: 利用者、日付: 2026-11-02。受け入れ条件 6 をこれに合わせて直した）

もうdevelopに入ってきちゃってるので難しくない？ developからmainへのpushやめて個別branchをmainにpushする？

（承認待ちの間に develop が進んだら差分を添えて出し直す案に対して）これ、別にいらないか。1つづつ承認すれば十分。これをやることで処理が複雑になりそう

（書き手: 利用者、日付: 2026-11-02。受け入れ条件 6 を、develop の SHA で中身を決め 1 回ずつ承認する形に直した。個別ブランチを main へ出す案は採らない（判断の記録 52cea1acb30e）。承認待ちの間に束ねる扱いは取り下げた）

3を入れるのと入れないのと、どちらがより良いか、配布の迅速さや複雑さの観点から再検討してください。

（書き手: 利用者、日付: 2026-11-02。比べた結果、出し直しを 1 回までに限って入れると起票者が決めた（判断の記録 e5f2287fe5ac）。人の答え待ちが 10 分〜40 時間で、本番のプランの 14〜23 分より長いため。承認ゲート 1 で確かめる）

夜中寝ているときなどはすべての周回ループが承認待ちに入ってしまうこともあるので、まとめて一回の方がたすかるのは確かですね

この形が可能なら、承認を待っているあいだ、次のsprintを実行することが可能ですね

（書き手: 利用者、日付: 2026-11-02。受け入れ条件 6a を足した）

（起票者、2026-11-02: 本番の配布が develop の先頭しか出せない（release-steps.py の _merge_prod_pr、#815 の check_approved）ため、受け入れ条件 6 の出し直しを「答えの時点からマージを保留する」形に直した。判断の記録 49188f42741e。承認ゲート 1 で確かめる）