課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる #2228

依頼（原文）

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

課題を閉じる時点を 1 つにし、工程を通ってから閉じる（親 B）

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

起票時の本文（題「課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる」）:

何が困るか

課題が工程の途中で閉じる。閉じる経路が 3 つあり、どれも工程の通過を見ない。

子	閉じる経路
#2082	既定ブランチ宛の実装 PR の本文のclosing keywordsで、GitHub がマージの時点に閉じる
#2119	sprint-close.py が工程の通過を見ない。雛形の supervise_lib/sprint.close_plan は release-verify → close → retro の順で、振り返りの前に閉じる（progress-tracking/SKILL.md の「振り返りを通る変更では、retrospective が記録を投稿した後に閉じる」と食い違う）

修正レイヤー

課題を閉じる時点の正本。 progress-tracking の「スプリントを閉じる」を正本とし、sprint-close.py の入口で工程の通過を確かめる。sprint.close_plan の順序と、pr の宛先の表（closing keywordsを使う条件）をそれに従わせる。

完了条件

• 最終の工程を通っていない課題は、どの経路でも閉じない
• 閉じる順序が progress-tracking と雛形で一致する
• 工程の通過は親 A のレポートから判定できる（A に依存）

（書き手: 起票者、日付: 2026-10-31。利用者の指示の原文として扱わない。引用の中の「closing keywords」は、原文では用語集で廃した語で書かれていたものを用語集の語へ置き換えた）

子の課題:

• 既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082「既定ブランチ宛の実装 PR の本文のclosing keywordsで、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る」（volareinc/carmo-screening#342 の振り返りから起票）
• sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119「sprint-close.py が工程の通過を見ず、振り返りの前に課題を閉じる」（document-rebuild: 文書形式と目的に合わせて組み直し、読み手が理解し納得できるかを確かめる（#2086） #2086 の振り返りから起票。スプリント s2086 で、リリース後テストの前に document-rebuild: 文書形式と目的に合わせて組み直し、読み手が理解し納得できるかを確かめる（#2086） #2086 が閉じ、その後のリリース後テストで受け入れ条件 10 が不合格になったが閉じたまま残った）
• 親 A は 全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227「全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない」

起票者の推定

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

目的

• 課題が閉じた時点で、その実行の最終工程（棚卸しの前に最後に通る工程）が終わっているようにする。閉じた課題は棚卸しの対象から外れ、不合格の条件や未通過の工程が見えなくなるためである（sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119 の s2086 の経緯）
• 閉じる時点の決まりを 1 か所に置き、スクリプト・まとめのプラン・Pull Request の本文の規則がそれに従うようにする。今は文書の決まりと雛形の並びが食い違い、決まりを守るのは呼ぶ側（conductor・引継ぎ文書）の手順の並びに頼っている

前提

• 前提 1: この要求が扱う「閉じる経路」は次の 3 つである。(a) GitHub が Pull Request のマージの時点に、本文の closing keywords で課題を閉じる（既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082）、(b) sprint-close.py を、まとめのプラン・conductor・Skill の手順のどれかが打つ（sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119）、(c) sprint-close.py がボードの Status を Done にしたことで、ボードの Auto-close issue が課題を閉じる（(b) の中の 1 手で、(b) の判定を通らないと起きない）
• 前提 2: 「最終工程」は、progress-tracking の「スプリントを閉じる」の定義（棚卸しの前にその実行で最後に通る工程）と、development-workflow の工程表（workflow-common.sh の WF_STAGE_MATRIX）のモードごとの必須・条件付きの区分で決まる。light は 配布、standard と legacy-refactor と documentation は 振り返り、operation はその実行で通る条件付きの工程による
• 前提 3: 親 A（全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227）の結果 JSON の共通形式が先に入る。工程の通過を判定する材料は、全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227 の形式の結果（status が ok のもの）か、それと同じ版に入る記録から取る。今の通過記録（progress-record.sh が積むファイル）と本文の ## 進行 は「工程に入った時点」の記録で、工程を終えたことを表さないため、それだけで通過とは読まない
• 前提 4: --record-pr 0（本番の記録なし）と --record-pr unknown（記録の置き場が分からない）の今の扱いは変えない。工程の通過の判定は、その上に足す閉じる条件である
• 前提 5: 子の 2 件（既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082・sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119）の受け入れ条件は、この課題の受け入れ条件に含める（受け入れ条件 10）。設計はこの課題で 2 件をまとめて行い、実装の Pull Request を子ごとに分けるかは計画で決める
• 前提 6: 振り返りの記録は、記録の Pull Request のコメントとして投稿される（retrospective の今の決まり）。この要求はその置き場を変えない

対象範囲

含む:

• progress-tracking の「スプリントを閉じる」を閉じる時点の正本として、「最終工程を終えてから閉じる」の判定の材料と順序を書く
• sprint-close.py の入口で、課題ごとに最終工程を終えたかを判定し、終えていない課題を閉じない
• まとめのプラン（supervise_lib/sprint.py の close_plan と sprint_close_steps.py）の並びを正本に合わせる
• pr の宛先の表と「closing keywords は本文だけに書く」を、既定ブランチ宛の Pull Request で closing keywords を残さない形にする。closing keywords を持たない Pull Request から閉じる課題を集める手段（--issues か、それに代わるもの）を sprint-close.py に持たせる
• 正本を写している文書（retrospective・release-verification・release・development-workflow の references）の参照の付け替え

含まない:

• 利用者が手で gh issue close や GitHub の画面で閉じること（NDF の経路ではない）
• 棚卸しが「やらない」と決めた課題を not planned で閉じること（backlog-refinement の no-work.md。工程を通らずに閉じるのが意図の経路で、最終工程の判定の対象にしない）
• check-trigger.py が Pull Request を閉じること（課題ではない）
• 親 A（全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227）の結果 JSON の形式そのものの変更
• 他のリポジトリ（例: volareinc/carmo-screening）の既存の課題・Pull Request の書き直し

ドメインイベント

用語

受け入れ条件

各条件の末尾の括弧は、確かめる時期と手段を表す。

• 1. progress-tracking の「スプリントを閉じる」が、課題を閉じてよい条件として「その課題の最終工程を終えたこと」と、それを判定する材料（未決 1 で決めるもの）を定める。retrospective・release-verification・release・pr・development-workflow の references は閉じる時点と順序の決まりを写さず、この節を指す（マージ前: grep で、閉じる時点の決まりを持つ文書がこの節の 1 か所であることを見る）
• 2. 最終工程を終えていない課題（例: 振り返りを通るモードで振り返りの記録が無い）を含めて sprint-close.py --record-pr <記録のPR> --issues <番号> を打つ → --with-verification の有無にかかわらず、その課題は閉じず、ボードも Done にならず、結果 JSON の items に kept_open と、終えていない工程の名前を含む reason で載る（マージ前: gh と判定の材料を差し替えたテスト）
• 3. 最終工程を終えたかを判定する材料が読めない（置き場が無い・読めない・ok の結果が無い）課題で同じコマンドを打つ → 終えたとは読まず、その課題は閉じず、kept_open か failed で理由つきで載り、結果 JSON の status は ok にならない（全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227 の読む側の規則に従う）（マージ前: テスト）
• 4. 最終工程を終え、リリース後テストの行がすべて合格の課題で --with-verification を付けて打つ → 今と同じく受け入れ条件へ [x] を付けてボードを Done にし、閉じる（退行しない）。--record-pr 0 と --record-pr unknown の今の扱いも変わらない（マージ前: 既存のテストと追加のテスト）
• 5. 振り返りを通るモードで supervise.py new close が書くまとめのプランの steps の id を、next のつながりの順に並べる → リリース後テスト（配布の記録があるとき）→ 振り返り → 課題を閉じる → 棚卸しの順になり、progress-tracking の「スプリントを閉じる」の表と一致する（マージ前: プランを組んで並びを見るテスト）
• 6. 振り返りを通らないモード・経路（light、振り返りを通らない operation）のまとめのプランでも、課題を閉じるステップはその経路の最終工程のステップの後、棚卸しのステップの前にある（マージ前: テスト）
• 7. 開発の起点（.ndf/worktree.json の base_branch、無ければ既定ブランチ）が既定ブランチと同じ構成で、課題の Pull Request を NDF の手順（pr-steps.py create / update）で作る → でき上がった Pull Request の本文に、マージで課題を閉じる closing keywords（Closes / Fixes / Resolves と活用形）が残らない（既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082 の受け入れ条件 1）（マージ前: 一時のリポジトリの構成で pr-steps.py を流すテスト）
• 8. 上と同じ構成で、スプリントの Pull Request（既定ブランチ宛）を NDF の手順で作る → 同じく closing keywords が本文に残らない。その Pull Request だけから成るスプリントで sprint-close.py --record-pr <記録のPR> --prs <番号> --dry-run を打つ → 対象の課題が kept_open（参照だけの課題）や終了コード 2（集めた課題が 0 件）にならず、閉じる対象（最終工程を終えていれば would_close）として判定される（既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082 の受け入れ条件 2・3）（マージ前: テスト）
• 9. 開発の起点が既定ブランチと違う構成（このリポジトリの develop 宛）では、今と同じく本文の closing keywords が残り、sprint-close.py がそこから課題を集める（退行しない。既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082 の受け入れ条件 4）（マージ前: 既存のテストと追加のテスト）
• 10. 子の 2 件（既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082・sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119）が、それぞれの受け入れ条件を満たして閉じている（子の課題で確かめ、この課題では閉じていることを見る）
• 11. この版の後の最初のスプリントの仕上げで、引継ぎ文書や conductor の手順の並びに関わらず、どの課題もその最終工程の記録より前に閉じない（リリース後: スプリントの課題の closedAt と、振り返りの記録のコメントの投稿時刻（振り返りを通らない経路ではその経路の最終工程の記録の時刻）を比べる）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-10-31 11:33
• 作業場所の用意 — 2026-10-31 13:00
• 設計 — 2026-10-31 11:47
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-10-31 13:00
• 実装 — 2026-10-31 13:01
• 構造改善 — 2026-10-31 18:37
• 実装レビュー — 2026-10-31 22:28
• 完了判定 — 2026-10-31 16:12
• Pull Request — 2026-10-31 16:25
• 確定仕様化 — 2026-11-01 00:29
• 後片付け — 2026-11-01 00:28
• 配布 — 2026-11-01 00:00
• 体裁レビュー
• リリース後テスト — 2026-11-01 00:28
• 振り返り — 2026-11-01 01:03
• 棚卸し — 2026-11-01 01:16

振り返り: #2320 (comment)

状況（2026-11-01、v10.27.6）

• 条件 1〜9 は v10.27.5 のリリース後テスト（Release: ndf v10.27.5 #2328 ）で合格
• 条件 11 は v10.27.5 の後の最初のスプリント m26-3 で観測できる。new close: merge・手動の経路のスプリントで、リリース記録の PR をまとめの close へ渡す手段が無く、課題が --record-pr unknown で開いたまま残る #2044（09:20:55Z）・開発ループの承認ゲート 2 の後のまとめが配布の記録の PR を読まない → 本番の後に記録の PR を解いてまとめを組む（#2089） #2121（09:20:59Z）は振り返りの記録（Release: ndf v10.27.6 を main へ #2352 、09:14:47Z）の後に閉じ、スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164・リリース記録の PR を、まとめのプランを組む時点でなく実行の時点で解決する #2230 は保留の行を理由に kept_open で残った。合格の行は記録の PR Release: ndf v10.27.5 #2328 へまだ足していない
• 条件 10 は子の 既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082（条件 5: carmo-screening で 1 スプリント）が閉じるまで満たせない。保留の行を拾い直して閉じる工程は リリース後テストで「次のスプリントで確かめる」と保留にした条件を、次のスプリントで拾い直す工程が無く、課題が開いたまま残る #2330 が持つ

リリース後テストの取り直し（2026-11-01 17:39 JST）

記録: #2328 (comment)

• 条件 1〜9・11: 合格（11 は m26-3 で、どの課題も振り返りの記録 Release: ndf v10.27.6 を main へ #2352 (comment) より後に閉じた）。条件 10: 保留。sprint-close: 最終工程を通っていない課題を、リリース後テストの前に閉じないようにする #2119 は閉じたが、既定ブランチ宛の実装 PR の本文の閉じる語で、マージの時点に課題が閉じ、仕上げの工程と受け入れ条件のチェックが閉じた課題に残る #2082 が条件 5 の保留で開いたまま
• 開いたままの理由: 合格でない条件が残る（sprint-close.py --record-pr 2328 --with-verification の結果は kept_open）