本番のプランの verify が導入の確認だけを流して「リリース後テスト」を通ったと記録し、受け入れ条件ごとの記録が無いためスプリントを閉じる工程で課題が閉じない #2288

何を見つけたか

スプリント m26-1（ndf v10.27.2）の本番のプラン（supervise.py が書く 8-release-prod.json）は、verify ステップ（stage: リリース後テスト）で release-verification-steps.py verify-install --ref main --expect 10.27.2 --runtimes claude,codex,kiro だけを流し、exit 0 で次へ進んだ。プランはこれで「リリース後テスト」を通ったと記録し、conductor も済んだと扱った。

しかし release-verification の手順 2・3（受け入れ条件ごとの確認と、配布の記録の PR への ## リリース後テスト の記録の投稿）は行われていない。その結果、仕上げのフェーズで sprint-close.py --record-pr 2281 --with-verification --dry-run を打つと、スプリント課題 12 件すべてが kept_open（理由「本番の版のリリース後テストの記録が無い」）になり、課題を閉じられなかった。スプリント PR #2268 の本文の「手動確認」が「リリース後テストへ回す」とした 2 件（#2227 の承認資料の検査の結果・#2229 の一時の worktree の片付け）も、誰も実施していなかった。

どこで見つけたか

• 本番のプラン: /work/ai-plugins/.ndf/tmp/sprint-m26-1/8-release-prod.json の verify ステップ、結果 /work/ai-plugins/.ndf/tmp/sprint-m26-1/8-release-prod-state/11-verify.out
• 配布の記録の PR Release: ndf v10.27.2 #2281 （## 配布の記録 のコメントはあるが ## リリース後テスト が無い）
• 仕上げのフェーズ（振り返り → スプリントを閉じる）での sprint-close.py の dry-run

なぜこの変更の範囲外なのか

m26-1 の受け入れ条件は、工程の結果を統一した JSON で返すこと（#2227）と実行をまたぐ状態の寿命と持ち主（#2229）を扱い、本番のプランがリリース後テストのどこまでを流すかはどの条件にも入っていない。根拠: Vision（2 回の承認には未検証のまま残ることがそろって届く）・Value 7（判断の理由を残す）（MVV 版 3）

直さないと何が起きるか

本番のプランで流すスプリントは毎回、受け入れ条件ごとの確認が抜けたまま「リリース後テスト済み」と記録され、スプリントを閉じる工程で課題が閉じない。閉じないことに気づかずに --with-verification を外して閉じると、確かめていない条件が終わったように見える。

由来

PR #2282

依頼の書き手

上の「何を見つけたか」〜「由来」は、起票者（課題を書いた AI）が 2026-10-31 に、配布の Pull Request #2282 の作業の中で範囲外の課題として書いた本文である（書き手: 起票者、日付: 2026-10-31）。利用者の指示の原文は無い。下の要求は、この本文と、本文の末尾の「状況」「リリース後テストの取り直し」の記録（書き手: 起票者、日付: 2026-11-01）から組み立てた。

解釈: 課題の本文の進行で「リリース後テスト」に印が付いているなら、配布の記録の Pull Request に受け入れ条件ごとの記録（## リリース後テスト）がある状態にする。導入の確認だけを流したステップを「リリース後テスト」と記録しないこと（受け入れ条件 1〜4、合格済み）と、印を記録より先に付けないこと（受け入れ条件 5〜7、未達）の 2 つで満たす。

起票者の推定

題・本文のうち、利用者の指示の原文に無く、起票者が推して足した条件。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

• 課題の本文の進行の「リリース後テスト」の印を、受け入れ条件ごとに確かめた記録があることの印にする。印を見た人とスプリントを閉じる工程が、確かめていない条件を確かめたものと取り違えない状態にする

前提

• 前提 1: 受け入れ条件 1〜4 は、2026-11-01 の取り直しで合格した（記録: Release: ndf v10.27.5 #2328 (comment) ）。この変更では作り直さず、退行しないことだけを確かめる
• 前提 2: 受け入れ条件 5 の文言は変えない。進行の印は今、ステップを流す前に付く（supervise_lib/state.py の record_stage を supervise_lib/engine.py の _run_step がステップの実行の前に呼ぶ）。「リリース後テスト」の工程に限って、印を付ける時点をステップが ok で終わった後へ移せば、文言のまま満たせる
• 前提 3: 課題 進行の「リリース後テスト」の印が、記録を投稿するステップの開始で付き、記録より先になる #2356（進行の「リリース後テスト」の印が記録より先に付く）は、この課題の受け入れ条件 5 の不合格を起票したものであり、受け入れ条件 6・7 は 進行の「リリース後テスト」の印が、記録を投稿するステップの開始で付き、記録より先になる #2356 の受け入れ条件 1・2 と同じ振る舞いを指す。同じ変更で両方を満たす
• 前提 4: ステップの ok は、プランの実行の核が返すステップの結果（結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337 が契約をそろえる結果）で判定する。結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337 が先に入って結果の形が変わっても、「ok で終わった」の意味は変わらない

対象範囲

含む:

• 本番のプランと仕上げのフェーズのプランで、stage が「リリース後テスト」のステップの進行の印を付ける時点
• 受け入れ条件 1〜4 の退行の確認

含まない:

• 振り返りなど、ほかの記録を投稿する工程の印の時点（同じ型だが、この課題の受け入れ条件に無い。未決 1）
• release-verification の手順そのもの（受け入れ条件ごとの確認の中身・記録の形）
• sprint-close.py の判定の変更
• 進行の印を付けるスクリプト（projects-sync.sh・progress-record.sh）の書式

ドメインイベント

用語

受け入れ条件

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

• 1. supervise.py の雛形が書く本番のプラン（release-prod）を組む → 導入の確認（release-verification-steps.py verify-install）だけを流すステップは、stage を「リリース後テスト」として記録しない。stage が「リリース後テスト」のステップは、受け入れ条件ごとの確認と、配布の記録の Pull Request への ## リリース後テスト の投稿を行うステップである（マージ前: プランを組んで各ステップの stage と中身を見るテスト）（2026-11-01 合格、前提 1）
• 2. 開発版のプラン（release）の verify ステップは、今と同じく stage「配布」で記録される（退行しない。supervise_lib/release_templates.py の _release_verify_steps が dev のとき「配布」を返す今の振る舞いを前提にする）（マージ前: テスト）（2026-11-01 合格、前提 1）
• 3. 配布の記録の Pull Request に ## リリース後テスト の記録が無い間に sprint-close.py --record-pr <記録のPR> --with-verification --dry-run を打つ → 今と同じく、課題は理由「本番の版のリリース後テストの記録が無い」の kept_open になる（退行しない）（マージ前: 既存のテスト）（2026-11-01 合格、前提 1）
• 4. 雛形どおりに本番 → 仕上げ（リリース後テスト → スプリントを閉じる）まで流す → sprint-close.py --with-verification を打つ前に、配布の記録の Pull Request に ## リリース後テスト の記録が投稿されており、スプリント Pull Request の「手動確認」でリリース後テストへ回した項目もその記録に行として載る（リリース後: この版の後の最初のスプリントで、配布の記録の Pull Request のコメントを見る）（2026-11-01 合格、m26-3 の Release: ndf v10.27.6 #2351 ）
• 5. 上と同じスプリントで、課題の本文の進行の「リリース後テスト」に印が付いた時点で、配布の記録の Pull Request に ## リリース後テスト の記録がある（印と記録が食い違わない）（リリース後: 課題の進行の時刻とコメントの時刻を比べる）
• 6. stage が「リリース後テスト」のステップを流し、ステップが ok で終わる → 課題の本文の進行の「リリース後テスト」の印は、ステップが ok で終わった後に付き、ステップを始めた時点では付かない（マージ前: 印を付けるスクリプトを差し替えたテストで、呼ばれた順を見る）
• 7. 同じステップが ok で終わらない（失敗する・承認ゲートで止まる・利用上限で止まる）→ 進行の「リリース後テスト」に印が付かない。同じプランをやり直してステップが ok で終われば、そのときに 1 回だけ付く（マージ前: テスト）
• 8. stage が「リリース後テスト」以外のステップの印は、今と同じくステップを始めた時点で付く（退行しない）（マージ前: 既存のテスト）

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-02 07:35
• 作業場所の用意 — 2026-10-31 13:00
• 設計 — 2026-11-02 07:37
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-11-02 07:44
• ドキュメントレビュー
• 計画 — 2026-10-31 13:00
• 実装 — 2026-10-31 13:01
• 構造改善 — 2026-10-31 18:37
• 実装レビュー — 2026-10-31 22:28
• 完了判定 — 2026-10-31 13:04
• Pull Request — 2026-10-31 13:42
• 確定仕様化 — 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:17

振り返り: #2320 (comment)

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

• 条件 1〜3 は合格。m26-3 の本番のプラン（8-release-prod.json）でも verify の進行は「配布」だった
• 条件 4 は合格。記録の PR Release: ndf v10.27.6 #2351 の ## リリース後テスト は close より前に投稿され、スプリント PR スプリント m26-3 #2348 の手動確認の 2 件を行として載せた
• 条件 5 は文言どおりには満たせない。進行の印は工程に入った時点の記録（課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる #2228 の前提 3）であり、m26-3 では「リリース後テスト」の印が release-verify のステップに入った時点、記録の投稿はそのステップの終わりの頃だった。条件 5 の文言の書き換えは人の判断を待つ

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

記録: #2328 (comment)

• 条件 1〜4: 合格（4 は m26-3 で、## リリース後テスト が close より前に投稿され、手動確認の 2 件も行に載った）。条件 5: 不合格。進行の印はステップの開始（07:59）に付き、記録はそのステップの中で後から投稿される（supervise_lib/engine.py の _run_step）。修正は 進行の「リリース後テスト」の印が、記録を投稿するステップの開始で付き、記録より先になる #2356
• 開いたままの理由: 合格でない条件が残る（sprint-close.py --record-pr 2328 --with-verification の結果は kept_open）