sprint-close: --with-verification を付け忘れると、リリース後テストに不合格の行を持つ課題も閉じる #2293

何を見つけたか

sprint-close.py は --with-verification を付けたときだけ閉じる条件 2（その課題のリリース後テストの行がすべて合格で、受け入れ条件の番号のすべてに合格の行がある）を判定する。リリース後テストを通る経路（振り返りを通る経路を含む）で、呼ぶ側が --with-verification を付け忘れて sprint-close.py --record-pr <記録のPR> --issues <番号> を打つと、リリース後テストに不合格・保留の行を持つ課題も閉じる。

付け忘れに限らない。plugins/ndf/skills/retrospective/SKILL.md の「スプリントを閉じる」は、プランの外で振り返りを直接通すときに --final-stage 振り返り だけを書き、--with-verification を書いていない。手順どおりに打っても条件 2 を見ない。v10.27.6 で sprint-close.py --record-pr 2351 --issues 2164,2230 --final-stage 振り返り --dry-run を打つと、リリース後テストに保留の行を持つ 2 件が would_close になる（--with-verification を付けると kept_open）。

どこで見つけたか

• plugins/ndf/scripts/sprint-close.py の _closing_blocker（verify = a.with_verification or a.final_stage == STAGE_VERIFY の行で、条件 2 を見るかを引数だけで決める。v10.27.6 で確認）
• plugins/ndf/skills/progress-tracking/SKILL.md の「スプリントを閉じる」（--with-verification: リリース後テストを通る経路で付ける）
• 課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる #2228 の設計（issues/issue-2228-design.md の「未確認のまま残ること」）

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

#2228 は課題を閉じる時点（最終工程の記録を確かめてから閉じる）を扱い、受け入れ条件 4 で --with-verification の今の扱いが変わらないことを求めている。条件 2 を既定で見るかは、この受け入れ条件と別の契約の変更になる。#2228 の設計は、最終工程がリリース後テストの経路（--final-stage リリース後テスト）でだけ条件 2 を必ず見る。根拠: 共通原則「判断の範囲は目の前の変更・操作に限る」/ Value 6（MVV 版 3）

直さないと何が起きるか

conductor や担当が手で打つ経路で付け忘れると、リリース後テストで不合格になった受け入れ条件を持つ課題が閉じ、棚卸しの対象から外れる（#2119 の s2086 と同じ見え方）。まとめのプランの close は --with-verification を付けるため、プランを通る経路では起きない。

起票者の推定

• 直し方の候補: 配布の記録が番号で渡され、その版のリリース後テストの記録があるときは、--with-verification を付けなくても条件 2 を見る（推した出所: 課題を閉じる時点を 1 つにし、最終の工程を通ってから閉じる #2228 の設計の決定 3 を振り返りの経路へ広げる考え）
• 起きる経路はプランの外（手で打つ経路と Skill の担当）に限る（推した出所: supervise_lib/sprint_close_steps.py の _close_step が --with-verification を付けている）

受け入れ条件（起票者の推定）

• 1. 記録の PR にその課題のリリース後テストの行があれば、--with-verification の有無にかかわらず条件 2 を見る（上の dry-run が kept_open を返す）
• 2. リリース後テストの表が無い記録（--final-stage 配布・--record-pr 0）では、今と同じく条件 2 を見ない
• 3. まとめのプランの close の出力は変わらない

由来

issue #2228