[takemi-ohama]

#2436 で求められている、tmux で並列開発を計画から始める仕組みの設計文書を追加しました。並列の計画から複数のレーンを起動し、本番の配布を 1 本にまとめる設計です。要求のコピーを置き、用語集に 4 語を足しています。

利用者向けの変化

• 無し

移行の手順

• 無し

変更の要点

• 要求のコピー（issues/issue-2436-requirements.md ）を置きました。
• 設計文書（issues/issue-2436-design.md ）を追加しました。
  • 並列の計画から複数のレーンを起動する手順を書いています。
  • 本番の配布を 1 本にまとめる手順を書いています。
  • 長い文は分けています。
  • レーンを開始するコマンドは表にまとめています。
• 設計上の判断を issues/issue-2436-design-decisions.md に記録しました。
• 用語集（docs/glossary.md と docs/glossary/glossary.json ）に 4 語を足しました。
• 変更は文書だけです。5 ファイルで 717 行の追加、削除はありません。

テスト

supervise.py の run のステップで確認しました。

ステップ	終了コード	結果
用語集の照合（glossary）	0	宣言と用語集が揃っている
要求のコピーの検査（requirements-check）	2	停止。issues/issue-2436-requirements.md を読めない（No such file or directory）

要求のコピーの検査は、ファイルが見つからないとして停止しました。変更の統計ではこのファイルを追加しています。停止の原因は未確認で、マージ前に検査を再実行して確かめます。

モード: standard / 通した工程: 設計 → 要求と受け入れ条件 → ドキュメント再構成 → ドキュメントレビュー

🤖 Generated with Claude Code

決めたこと

issues/issue-2436-design-decisions.md

• 決定 1: 計画と起動の受け皿を既存の手順へ寄せるため、新しい Skill を作らず issue-plan-strategy と development-workflow の --parallel で受ける
• 決定 2: 11-02 の配布の衝突を繰り返さないため、オーガナイザーを置き、起動の後も残して本番の配布を 1 本にまとめる
• 決定 3: 機械が検査でき、ループの記録と同じ扱いにするため、並列の計画の正本を plan.json（pydantic のモデル）にし、plan.md を描画にする
• 決定 4: 統括役の作業ディレクトリの読み方に揃えるため、オーガナイザーの印を作業ディレクトリの役割のファイルで持つ
• 決定 5: レーンの最初の入力を変えずに済ませるため、レーンかどうかをラッパーの名前と動いている計画の照合で決める
• 決定 6: レーンの工程を変えずに配布だけを差し替えるため、本番のステージを組む 1 つの関数でだけ配布の依頼のプランへ置き換える
• 決定 7: 承認ゲートを増やさないため、まとめた配布の承認は今の本番のプランの承認ゲート 2 をそのまま使う
• 決定 8: 統括役を並列の計画から独立させるため、計画名での停止を relay.py ではなく parallel.py stop に置く
• 決定 9: 計画の大きさを起動の前に確かめられる形にするため、レーンの数の上限を NDF_RELAY_MAX_NAMED から読み、依存のあるレーンも数える
• 決定 10: オーガナイザーの手順を記録から決まる 1 手に絞るため、進行を耐久ワークフロー 1 本にし、AI は承認ゲート 2 の提示だけを担う
• 決定 11: ラッパーの外では配布をまとめずに今の振る舞いへ戻すため、手で起動した計画では耐久ワークフローを始めない
• 決定 12: 自分で書く部品を減らすため、並列の進行を DBOS の耐久ワークフローとメッセージで作り、検査を pydantic と graphlib で行う
• 決定 13: レーンの変更はすでに develop にあるため、配布の中身を依頼の集合ではなく承認資料を作る時点の develop のコミットで決める
• 決定 14: 承認の答えの時点で develop が進んでいれば 1 回だけ出し直し、出し直しで承認したコミットを出す
• 決定 15: 本番チャネルへの Pull Request は develop に含まれるコミットだけにし、head を release/v<版> にする
• 決定 16: 並列の計画の下では承認ゲートの問いをオーガナイザーへ集める
• 決定 17: オーガナイザーは問いと本番の配布の取りまとめだけを持ち、直す作業は持ち主のレーンへ戻す
• 決定 18: 承認ゲートの外の問いも、問いの hook でオーガナイザーへ送る
• 決定 19: オーガナイザーは作業を持たず、答えの後の処理は持ち主のレーン、共有の作業は一時レーンが行う
• 決定 20: 異常系は、検知を耐久ワークフローの観測と問いの依頼の印に寄せ、扱いを問いか持ち主のレーンへ返す形に揃える
• 決定 21: 範囲を 1 台の中に閉じ、レーンとオーガナイザーの間の依頼と答えの形を NDF の契約として公開する

[takemi-ohama]

🤖 cross-review | round 1 | codex | REQUEST_CHANGES

モデルの起動済み判定と配布依頼の締切を、後続の処理手順と一致させてください。

[takemi-ohama]

🤖 cross-review | round 1 | kiro | APPROVE

ドメインモデルの節と用語集の差分を確認。コンテキスト（3 つ）・集約（持ち主が各 1 つ）・不変条件・ドメインイベント（E1〜E13 が要求の番号と受け手を引き継ぐ）・用語（4 語）は内部で矛盾せず、用語集 docs/glossary.md と docs/glossary/glossary.json の追加 4 語は設計の用語表と一致していた。critical / major の基準に当たる修正アクションは見つからなかった。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 1 | commit e5f8972

対応件数: critical=0 / major=2 / minor=0（合計 2 件）
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

[takemi-ohama]

🤖 cross-review | round 2 | claude | REQUEST_CHANGES

まとめた配布の本番のプランが、同じプランの中の freeze のステップの結果を既存の {queue_pr:<名>} で受ける設計になっており、既存の差し込みの仕組みでは流れない。受け渡しの仕組みを設計に定める必要がある。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | REQUEST_CHANGES

I9 の締切の作り直し（freeze のステップと prs=["{queue_pr:parallel-freeze}"]）に、同じプランの中の run ステップの結果を同じプランの {queue_pr:…} で受けられないという食い違いがある。実装する人が設計どおりに組むと、まとめた配布のプランが差し込みを埋められず、流されずに止まる。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 2 | commit bca2aad

対応件数: critical=0 / major=2 / minor=0（合計 2 件）
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

[takemi-ohama]

🤖 cross-review | round 3 | claude | REQUEST_CHANGES

まとめた配布を 2 つのプランに分けた設計で、連番ごとのプランの置き場が決まっておらず 2 回目の配布が前の確定の結果で流れうる点と、新しく変える queue_fill.py が実装の範囲（触るファイル）から漏れている点を直してください。

[takemi-ohama]

🤖 cross-review | round 3 | codex | APPROVE

今回の差分に、critical / major に該当する新規の修正指摘はありません。判断の根拠: Value 1・Value 6・Value 10。

[takemi-ohama]

🔧 /ndf:fix サマリ | commit 08722e6

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: NONE

[takemi-ohama]

承認ゲート 1: 差し戻し（2026-11-02、利用者）。理由: 既存の並列実行制御パッケージを調べた結果、オーガナイザーの状態・配布の依頼と答え・待ち・打ち直しからの再開は、すでに依存にある DBOS Transact 3.1.0（耐久ワークフロー、send / recv、set_event / get_event）で行い、計画の形の検査は pydantic、依存の循環は graphlib で行う設計へ直す。機械学習・実験計画系（Optuna・Hydra の launcher・Ray Tune・scipy）、DAG 系（doit・Snakemake・Luigi・Prefect）、tmuxp、GitHub merge queue は採らない（理由は設計の決定の記録へ書く）。直した設計で承認を求め直す。

[takemi-ohama]

🤖 cross-review | round 4 | codex | REQUEST_CHANGES

依頼 ID の一意性、提示を選んだ後のブランチ作成、衝突解消後の承認照合、公開後の失敗判定、一時レーンの問いの送信資格を設計に定めてください。判断の根拠: C4・Value 2・Value 4・Value 6。

[takemi-ohama]

🤖 cross-review | round 4 | kiro | APPROVE

並列開発の設計（要求・設計本体・決定・配布規則・レーンのループ・承認集約・異常系の 6 文書と用語集 4 語）を全 9 ファイル確認。差し込みの受け渡し（{queue_prs:present} / {queue_approved:present} を提示のプランの work/prs.txt と承認資料から埋める二段プラン）・連番ごとの置き場（releases/<連番>/<提示>/）・起動済み判定を成功に限る（I7）・I9 の締切の統一は、前のラウンドで出た major がすべて反映済みであることを確認した。queue_fill.py の既存差し込みの仕組み・check-pr-base.sh の現行の引数と判定・merged-steps.py promote の head が develop である点を実コードで突き合わせ、設計の記述と一致した。用語集 docs/glossary.md と docs/glossary/glossary.json の追加 4 語は設計・要求の用語表と一致し、「配布の依頼」の意味の変更もそろっている。状態（plan.json・耐久ワークフローのメッセージ/イベント・release/v<版>・work/prs.txt）ごとに書き手と読み手が並び、二重書き・読み先行・失敗後の読みの矛盾は見つからなかった。critical / major の基準（利用者経路の誤動作・秘密/認可/データ/戻せない操作・トークン/時間/回数の増加・実装者が違うものを作る食い違い）に当たる新規の修正アクションは無い。

[takemi-ohama]

🤖 cross-review | round 1 | codex | REQUEST_CHANGES

延期の中間通知と最終回答の契約を分け、I10 の「1 回だけ返す」と整合させてください。判断の根拠: Value 4・Value 6。

[takemi-ohama]

🤖 cross-review | round 1 | kiro | REQUEST_CHANGES

ドメインモデルの節と用語集の差分を確認。コンテキスト（4 つ）・集約（持ち主が各 1 つ）・不変条件（I1〜I19）は内部で矛盾せず、用語集の追加 4 語（並列の計画・レーン・オーガナイザー・配布の依頼）の意味は設計の用語表と一致していた。ドメインイベントの番号が要求（E1〜E13）と設計（E1〜E15）で E9 以降ずれて衝突している点を 1 件、下に指摘する。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 1 | commit 7d63835

対応件数: critical=0 / major=7 / minor=0（合計 7 件）
決着: 7 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

[takemi-ohama]

🤖 cross-review | round 2 | claude | REQUEST_CHANGES

延期の知らせを別のイベント defer-<依頼> に分けたが、その読み手とした parallel.py await の契約（終了コード・出力）に知らせを受けたときの振る舞いが無い。待ち続けるのか返るのかを定める必要がある。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | APPROVE

前のラウンド（27f8d90）からの差分 3 ファイルを確認。(1) I10 の deferred を、最終の答え answer-<依頼> と知らせ defer-<依頼> に分けた変更、(2) ドメインイベントの番号を要求（E1〜E13）に合わせ、設計で足した 2 イベントを枝番 E8a・E9a にした変更。どちらも前ラウンドの major の反映で、3 ファイル（design.md・design-approvals.md・design-lane-loop.md）と要求（issue-2436-requirements.md）の間で書き手・読み手・番号・意味が一致していた。新しい critical / major に当たる修正アクションは見つからなかった。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 2 | commit f174b60

対応件数: critical=0 / major=1 / minor=0（合計 1 件）
決着: 1 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

[takemi-ohama]

🤖 cross-review | round 3 | claude | APPROVE

前のラウンドの指摘（await が知らせ defer-<依頼> を受けたときの振る舞い）は、待ち続ける・終了コード 3 で metrics.deferred に載せる形で定まり、I10・イベントの表（302 行）・レーンのループの行 5 と食い違いは無い。critical / major に当たる新しい修正アクションは無い。

[takemi-ohama]

🤖 cross-review | round 3 | codex | APPROVE

今回の差分に、critical / major に該当する新規の修正指摘はありません。判断の根拠: Value 1・Value 4・Value 6・Value 10。

[takemi-ohama]

🔧 /ndf:fix サマリ | commit (なし)

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 0 件 / 見送り: 0 件 / 却下: 0 件
CI: NONE

[takemi-ohama]

🤖 cross-review | round 4 | codex | REQUEST_CHANGES

人の承認後の提示の完了手順、版の観測元とworktreeの起点の分離、質問待ちの課題の選定除外、一時レーンの名前の割り当てを設計に定めてください。判断の根拠: Value 2・Value 4・Value 5・Value 6・Value 10。

[takemi-ohama]

🤖 cross-review | round 4 | kiro | APPROVE

並列開発の設計（要求・設計本体・決定・配布規則・レーンのループ・承認集約・異常系・階層の 8 文書と用語集 4 語）の全 10 ファイルを確認。前のラウンド（round 4 まで）で出た major はすべて反映済みで、この範囲の差分に critical / major の基準（利用者経路の誤動作・秘密/認可/データ/戻せない操作・トークン/時間/回数の増加・実装者が違うものを作る食い違い）に当たる新規の修正アクションは見つからなかった。実コードとの突き合わせ: (1) queue_fill.py の既存差し込み（{queue_pr}/{queue_state} の正規表現と results_named の named() の末尾一致）と、設計の新差し込み {queue_prs:present}/{queue_approved:present} が同じ queue 行の present→release の 2 ステージで解決される経路が一致（present.json の stem=present が named("present") に当たり、release.json は当たらない）。(2) check-pr-base.sh の現行の引数（$#==1 で head_ref、起点は .ndf/worktree.json の base_branch、ls-remote の末尾一致対策）と、設計の改定（第 2 引数に head の SHA を足し merge-base --is-ancestor で祖先を判定）が矛盾しない。(3) 配布の答えを待つ副命令が延期の知らせ defer-<依頼> で返らず answer-<依頼> を待ち続ける契約（I10）と、ループの境の表（行 5）・まとめた配布の状態図が一致。最新コミット 7d0f6e3 は用語の定義表・終了コード 10 の言い換え・生成物 glossary.md の追記という説明の精緻化のみで、振る舞いの変更は無い。用語集 docs/glossary.md と docs/glossary/glossary.json の追加 4 語は設計・要求の用語表と一致していた。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 4 | commit c12874b

対応件数: critical=0 / major=4 / minor=0（合計 4 件）
決着: 4 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

[takemi-ohama]

🤖 cross-review | round 5 | claude | REQUEST_CHANGES

確定の後の 3 手で提示のプランの approve を --answer-from releases/<n>/<k>/answer.json --by user に定めたため、MVV 判定が通る経路でも approve が空の答えの記録を読んで承認ゲート（10）で終わり、本番のプランが流れない。MVV が通す経路の承認の記録の扱いを定める必要がある。

[takemi-ohama]

🤖 cross-review | round 5 | kiro | REQUEST_CHANGES

round 4 の 4 件（487 の確定後の手順・release-rule の起点のコミットと版の判定の分離・lane-loop の保留の周回・I1 の一時レーンの名前）の反映を確認。起点のコミットと起点の分離（paths.py・queue_fill.py・release_templates.py の触るファイルを含む）、保留の周回の 3 か所の一致、一時レーンの名前の 32 字と予約形は実コードと矛盾しなかった。ただし 487 の確定後の 3 手のうち手順 2（提示のプランを approve のステップから再開）が、MVV 判定を持つ提示のプランに存在しない approve のステップを前提にしている major を 1 件、下に指摘する。

[takemi-ohama]

🔧 /ndf:fix サマリ | commit 2276b1e

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: NONE