リリース記録の PR を、まとめのプランを組む時点でなく実行の時点で解決する #2230

依頼（原文）

この課題は、起票者（AI）が子の 2 件（#2044・#2121）をまとめて起こした親の課題である。利用者の指示の原文は課題にも記録にも見当たらない（2026-10-31 の利用者の方針 5 点〔--loop を残す・codex / agy / kiro への配布を cross 系に絞る・全工程で統一した JSON レポート・並列に強く・テストを削る〕には、リリース記録の PR を決める時点の項目が無い）。マイルストーン「26 自律実行の信頼性」の説明の主題 4 と、起票時の本文を写す。

リリース記録の PR を、プランを組む時点でなく実行の時点で決める（親 D）

（書き手: 起票者〔マイルストーンの説明に AI が書いた主題。利用者の発言の原文ではない〕、日付: 2026-10-31）

起票時の本文（題「リリース記録の PR を、まとめのプランを組む時点でなく実行の時点で解決する」）:

何が困るか

まとめ（sprint-close）のプランが、リリース記録の PR をプランを組む時点で決める。merge・手動の経路やループの経路では、その時点に記録の PR がまだ無い。

子	経路
#2044	merge・手動の経路。close_waves が最終の検査・リリース・まとめを 1 つのキューに組み、record_pr_ref が unknown を返す
#2121	開発ループの承認ゲート 2 の後のまとめが、配布の記録の PR を読まない

修正レイヤー

supervise_lib/sprint_routes.record_pr_ref と close_plan。 記録の PR を、プランを組む時点ではなく実行の時点で解決する（supervise_lib/queue.py の {queue_pr:<名>} の解決を広げる）。

受け入れ条件

• どの経路でも、まとめのステップが実行の時点で記録の PR を解決する
• 解決できないときは unknown で進めず、止まる（親 A の規則に従う）

（書き手: 起票者、日付: 2026-10-31。利用者の指示の原文として扱わない）

子の課題:

• new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044「new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る」（new close: merge・manual の経路で本番まで出たスプリントも、まとめの close が --record-pr 0 で閉じる条件を見ずに課題を閉じる #1875 の設計の工程で範囲外として起票、2026-10-17。受け入れ条件 3 件を持つ）
• 開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121「開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない」（development-workflow: 棚卸しの結果から次のスプリントを決めて自動で始め、スプリントを繰り返す開発ループのモードを持つ #2089 の cross-review で見送った 2 件から起票、2026-10-25。問題 1〔--record-pr が配布の記録の PR でない〕と問題 2〔manual ステージを含む経路で、まとめが手作業の前に走りうる〕を持つ）
• 親 A は 全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227「全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない」

この要求は、人へ問わずに進める起動（AI の起動指示、2026-11-01: 「人へ問わずに進め、決められない点は前提か未決として課題の本文へ書く」）で書いた。決められない点は「前提」と「未決」に置く。

起票者の推定

利用者の指示の原文が無いため、題・本文の条件はどれも起票者の推定である。そのうち要求の形を決める条件を並べる。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

• 本番まで届けて受け入れ条件を満たしたスプリントで、リリースの経路（雛形・昇格・merge・手で届ける・検証の環境だけ・開発ループの周回）にかかわらず、まとめの close がリリース記録を読んで課題を閉じられるようにする（今は merge・手で届ける経路で毎回手で閉じ、開発ループでは検査のスプリント PR を記録として読む）
• 記録の PR が見つからないとき、まとめが「閉じずに ok」で先へ進まず、止まって理由を返すようにする（親 A の規則）

前提

• 前提 1: 直す層は、まとめのプランが記録の PR を決める箇所（supervise_lib/sprint_routes.record_pr_ref・supervise_lib/sprint.close_plan）と、ステージを流す時点の差し込みの解決（supervise_lib/queue_fill.py）、開発ループのまとめの組み立て（lib/sprint_loop.gate2_pipeline・lib/sprint_loop_gate.build_close）である。sprint-close.py の閉じる条件（--with-verification・最終工程の記録）は変えない
• 前提 2: merge・手で届ける経路でも、release の手順はリリース記録（## 配布の記録）を Pull Request に残す（plugins/ndf/skills/release/SKILL.md の「出力物」: リリースの PR の本文、PR を作らない形ではスプリントの最後にマージした PR へコメント）。この課題はその記録を読む側を直し、記録を書く手順の形は変えない（記録の PR の番号を置く場所を足すかは未決 1）
• 前提 3: 「実行の時点」は、まとめのステージ（close の queue）がそのプランを流し始める時点を指す。まとめのプランを組む時点（supervise.py new close・new sprint の組み立て、開発ループの承認ゲート 2 の時点）に記録の PR が無くてもよい
• 前提 4: 届けない経路だけのスプリント（記録の PR が 0。sprint_routes.RECORD_NONE）は、記録を読まずに閉じる今の扱いを変えない
• 前提 5: 呼ぶ側が --record-pr <番号> を明示して new close を打ったときは、その番号を使う今の扱いを変えない

対象範囲

含む:

• merge（merged-by-check）・手で届ける・検証の環境だけ（production: false の行だけ）・手動反映の本番系の昇格の経路で、まとめの close が unknown でなく、実行の時点に解決したリリース記録の PR を受け取る（new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044）
• 開発ループ（sprint-state.py loop）の承認ゲート 2 の後のまとめが、検査のスプリント PR でなく、本番のリリース記録の PR を受け取る（開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121 の問題 1）
• 記録の PR を解決できないとき、まとめのステップが止まり、課題を開いたまま ok で返さない
• 上の経路で記録の PR が解決できたときに、まとめのリリース後テストのステップがその PR を受け取る

含まない:

• 開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121 の問題 2（manual ステージを含む経路で、手作業を終えるまでまとめを始めない並びの直し）。子の 開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121 で扱う。この課題では、記録が無い時点で走ったまとめが止まることだけを保証する
• リリース記録の形（lib/dist_record.py・progress-tracking の「配布の記録」の表）と、記録を書く release-steps.py record の出力の変更
• sprint-close.py の閉じる条件（配布の段階・リリース後テスト・最終工程の記録）の変更
• 雛形・昇格の経路で、本番のプランが飛ばされた（最終の検査で変更が無い）ときの扱い
• 課題を閉じる時点と順序（親 B の 課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる #2228）、結果の共通形式そのもの（親 A の 全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227）

ドメインイベント

用語

受け入れ条件

• 1. merge（merged-by-check）・手で届ける・検証の環境だけの経路のスプリントで、supervise.py new sprint / new close が組むまとめの close のステップは --record-pr unknown を持たず、ステップを流す時点でリリース記録（## 配布の記録）を置いた PR の番号を --record-pr に受け取る（new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044 の受け入れ条件 1）
• 2. 開発ループの承認ゲート 2 の後のまとめの close は、止まった記録の values.pr（検査のスプリント PR）でなく、本番のリリース記録を置いた PR の番号を --record-pr に受け取り、配布して閉じる条件を満たした課題を閉じる（開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121 の受け入れ条件 1）
• 3. 受け入れ条件 1・2 の経路で記録の PR を解決したとき、まとめのリリース後テストのステップは同じ PR の番号を受け取る
• 4. まとめのステップを流す時点で記録の PR が見つからないとき、まとめは止まる（close を走らせないか、close が 0 でない終了コードで終わる）。課題は開いたまま残り、まとめの報告の結果は「完了」にならない。止まった理由に、探した経路と見つからなかったことが載る（new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044 の受け入れ条件 2）
• 5. どの経路のまとめのプランも、--record-pr unknown を組まない
• 6. 雛形（{queue_pr:release-prod}）と昇格（{queue_pr:promote}）の経路のまとめのプランの内容と、それを流したときの close の引数・出力は変わらない（new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044 の受け入れ条件 3）
• 7. 届けない経路だけのスプリントのまとめ（--record-pr 0）と、--record-pr <番号> を明示した new close の振る舞いは変わらない
• 8. 開発ループを使わない起動の出力と終了コードは、受け入れ条件 1・4・5 で変わる部分のほかは変わらない（開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121 の受け入れ条件 3）

非機能の条件

影響

検証手段

前提とする取り決め

境界

MVV との突き合わせ

反する疑いは無い。Value 6（根本原因の場所で直す: 子の 2 件を記録の PR を決める層で直す）、Value 5（どのプロジェクトでも使える形: 経路はリリースの宣言から決まり、ai-plugins の形を埋め込まない）、Value 2（利用者の手を止めない: 本番まで届けたスプリントの課題を手で閉じなくてよくなる）に沿う。記録が見つからないときに止まるのは、共通原則の優先順位（承認資料と記録の正しさを効率より上に置く）と親 A に沿う。

未決

1. 記録の PR を実行の時点で解決する手段。 候補は (a) queue の {queue_pr:<名>} の探し場所を広げる（開発ループのまとめは本番のプランと別の queue・別のディレクトリにある）、(b) 手で行うリリースのステージ・merge の経路の導入の確認に、リリース記録を置いた PR の番号を記録するステップを足し、まとめがそれを読む（new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044 の直し方の案）、(c) まとめの close の前に、スプリントの PR を指すリリース記録を GitHub から探すステップを置く。設計（design）で決める
2. sprint-close.py --record-pr unknown の受け付けを残すか。 まとめのプランは組まなくなる（受け入れ条件 5）。手で打つ入口として残すか、親 A に合わせて止まる（ok で返さない）値にするか、受け付けをやめるかを設計で決める

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-01 01:19
• 作業場所の用意 — 2026-11-01 02:53
• 設計 — 2026-11-01 01:21
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-11-01 02:53
• 実装 — 2026-11-01 02:54
• 構造改善 — 2026-11-01 05:23
• 実装レビュー — 2026-11-01 06:24
• 完了判定 — 2026-11-01 03:16
• Pull Request — 2026-11-01 03:29
• 確定仕様化 — 2026-11-01 07:43
• 後片付け — 2026-11-01 07:42
• 配布 — 2026-11-01 07:24
• 体裁レビュー
• リリース後テスト — 2026-11-01 07:59
• 振り返り — 2026-11-01 08:07
• 棚卸し — 2026-11-01 08:21

振り返り: #2352 (comment)