sprint-close がリリース後テストの「対象の版:」に v の付いた版を読めず、課題を閉じない #2225

何を見つけたか

リリース後テストの記録の 対象の版: を v10.26.1（…） と v を付けて書くと、sprint-close.py --with-verification がそのブロックを読めず、kept_open・理由「本番の版のリリース後テストの記録が無い」を返す。

• 配布の記録（PR Release: ndf v10.26.1 #2218 の本文）は 版: 10.26.0 → 10.26.1 で、lib/dist_record.py の parse_record は本番の版を 10.26.1 と読む
• リリース後テストのコメント（Release: ndf v10.26.1 #2218 (comment) ）は 対象の版: v10.26.1（2026-10-31 08:52 JST に…） で、_strip_note の後は v10.26.1 になる
• _pick_verify_block は b["ver"] == version の完全一致で探し、外れると「対象の版が版数でないブロック」だけへ落とす。v10.26.1 は _EXPLICIT_VERSION（v?\d+\.\d+\.\d+）に当たるため、そこでも外れて None になる

実行: python3 sprint-close.py --record-pr 2218 --with-verification（2026-10-31、ndf 10.26.1）→ {"number": 2171, "result": "kept_open", "reason": "本番の版のリリース後テストの記録が無い"}

どこで見つけたか

#2171 の振り返りの後の「スプリントを閉じる」（progress-tracking）。plugins/ndf/scripts/lib/dist_record.py の _pick_verify_block（develop では 115〜128 行）と _strip_note（47〜49 行）、plugins/ndf/skills/release-verification/SKILL.md の 115 行（対象の版: <配布した版>（<配布した時刻>））

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

#2171 の受け入れ条件は factory/ の契約と受け口だけで、NDF の配布の記録の読み取りを含まない。#2171 は実環境の保留 5 行で開いたままにする判断のため、この不具合が今回の結論を変えてはいない。根拠: NDF の共通原則の「判断の範囲は目の前の変更・操作に限る」（MVV 版 3）

直さないと何が起きるか

リリース後テストの書き手が v を付けると、すべての条件が合格でも課題が閉じず、受け入れ条件の印も付かない。理由の文が「記録が無い」のため、書いた記録が読めていないことに気づきにくい。

起票者の推定

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

由来

PR #2218

依頼（原文）

依頼の原文は、この本文の上の「何を見つけたか」から「由来」までの節である（書き手: 起票者、日付: 2026-10-31。#2171 の振り返りの後の「スプリントを閉じる」で、課題を書いた AI が不具合の記録として書いた。利用者の指示の原文ではない）。

人へ問わずに進め、決められない点は前提か未決として課題の本文へ書く。

（書き手: AI の起動指示、日付: 2026-11-05。この要求を書く工程の起動指示）

解釈: リリース後テストの記録の書き手が「対象の版」を v10.26.1 のように先頭に v を付けて書いても、v を付けない 10.26.1 と同じ版として読まれ、スプリントを閉じる判定（課題を閉じる・受け入れ条件に印を付ける）に使われるようにする。

目的

• リリース後テストで全条件が合格した課題が、版の書き方（先頭の v の有無）だけを理由に開いたまま残らない状態にする
• 書いた記録が読まれなかった理由を、「記録が無い」と取り違えずに済む状態にする

用語

前提

• 前提 1: そろえる表記の揺れは、版の先頭の小文字の v 1 文字の有無だけである。大文字の V、ndf--v10.26.1 のようなタグ名、前後の余分な語は、この課題では版として読まない（いずれも記録の書き方の手順 release-verification が示す形 対象の版: <配布した版>（<配布した時刻>） から外れる。実際に書かれた例は PR Release: ndf v10.26.0 #2195・PR Release: ndf v10.26.1 #2218 の v 付きの 2 件だけで、ほかの形は見つかっていない）
• 前提 2: 先頭の v を落とす規則は、対象の版と本番の版の両方へ同じように当てる。読み取りの規則を 1 か所（リリース記録を読む共通の部品）に置き、比べる側ごとに写さない
• 前提 3: 本番の版の読み取り結果（スプリントを閉じる処理・リリース記録の重複の確認・プランの版の差し込みが使う値）は、版: の行に v が付いていても v を付けない形で返す。これらの使い手は v を付けない版を前提に比べている（リリース記録を書く側は v を付けずに書く）ため、返す形を変えても既存の記録の読み取り結果は変わらない
• 前提 4: この課題は柱の課題 機械が読む出力を 1 行 JSON にそろえ、Markdown と本文の見出しから判定しない #2340（機械が読む出力を 1 行 JSON にそろえ、本文の見出しから判定しない）の子の課題である。機械が読む出力を 1 行 JSON にそろえ、Markdown と本文の見出しから判定しない #2340 は人が書いた本文から読む値を機械用のブロックへ移す。この課題は移す前の今の読み取りで、表記の揺れを吸収するところまでを扱う。機械が読む出力を 1 行 JSON にそろえ、Markdown と本文の見出しから判定しない #2340 の仕組みが入った後も、この課題の受け入れ条件 7・8 の再現の手順は 機械が読む出力を 1 行 JSON にそろえ、Markdown と本文の見出しから判定しない #2340 の子の課題の確認にそのまま使える
• 前提 5: リリース後テストの記録の書き方の手順（release-verification の「出力物」）は変えない。読む側が v の有無を吸収するので、書き手へ v を付けないよう求める規則を足さない（Value 5: 要らない決まりを足さない）

対象範囲

含む:

• 対象の版と本番の版を比べるときに、先頭の v の有無を同じ版として扱うこと
• 本番の版の読み取り結果を、v を付けない形にそろえること
• PR Release: ndf v10.26.1 #2218（NDF Factory: contracts と進捗の受け口 #2171）と PR Release: ndf v10.26.0 #2195（NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170）の記録が、本番の版のリリース後テストの記録として読まれることの確認

含まない:

• 実際に版数が食い違う記録（対象の版を 10.26.2 と誤記したなど）で出る理由の文「本番の版のリリース後テストの記録が無い」を言い換えること。原因が書き手の誤記であり、表記の揺れとは別の不具合である。本文の値を機械用のブロックへ移す 機械が読む出力を 1 行 JSON にそろえ、Markdown と本文の見出しから判定しない #2340 で扱う
• 大文字の V・タグ名など、前提 1 の外の書き方を読むこと
• リリース後テストの記録の書き方の手順の変更（前提 5）
• NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170 を閉じること。この課題の修正が入った後に、NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170 のスプリントを閉じる工程で判定する
• 設計のクラス図と非機能設計表。変更はリリース記録を読む共通の部品の関数の中に収まり、型（クラス）を足さず変えない。仕様に非機能の条件が無い

ドメインイベント

E3 だけが変わる。E1・E2・E4 の振る舞いは変えない。

受け入れ条件

• 1. リリース記録の 版: が 10.26.0 → 10.26.1 で、リリース後テストの記録の 対象の版: が v10.26.1（注記） のとき、リリース記録の読み取り（parse_record）は、そのリリース後テストのブロックを使うブロックとして返す
• 2. リリース記録の 版: が v10.26.0 → v10.26.1 で、対象の版: が 10.26.1 のときも、受け入れ条件 1 と同じブロックを返す。このとき読み取った本番の版は 10.26.1（v を付けない）である
• 3. 開発版の版数でも同じに扱う: 版: の出した版が 10.17.69-dev.1 で 対象の版: が v10.17.69-dev.1 のとき、そのブロックを返す
• 4. 退行しない: 対象の版: が v10.17.69-dev.1 で本番の版が 10.17.68 のときは、そのブロックを本番の検証に使わない（版数の違うテストを使わない規則を保つ）
• 5. 退行しない: 本番の版に一致するブロックが無く、対象の版が版数でない（main c427284 など）ブロックが最後のリリース記録より後にあるときは、今と同じくそのブロックを返す（sprint-close: 版数を上げない配布で、配布の記録の「版」とリリース後テストの「対象の版」の形が違い、スプリントの課題をすべて kept_open にする #1789 の規則を保つ）。段階が「配布なし」の記録の選び方も変わらない
• 6. リリース記録を書く側が書いた記録（v を付けない版）を読んだ結果は、修正の前後で変わらない。リリース記録の重複の確認（同じ版・同じ PR の記録が既にあるか）とプランの版の差し込みの既存のテストが、修正の後も通る
• 7. python3 plugins/ndf/scripts/sprint-close.py --record-pr 2218 --with-verification --dry-run の出力で、NDF Factory: contracts と進捗の受け口 #2171 の行の理由が「本番の版のリリース後テストの記録が無い」でない
• 8. python3 plugins/ndf/scripts/sprint-close.py --record-pr 2195 --with-verification --dry-run の出力で、NDF Factory: Cognito の認証（Google・GitHub）とプランごとの利用量 #2170 の行の理由が「本番の版のリリース後テストの記録が無い」でない

影響

検証手段

修正の前の実測（2026-11-05、develop の ffa7e1cf8）: 受け入れ条件 7 のコマンドは {"number": 2171, "result": "kept_open", "reason": "本番の版のリリース後テストの記録が無い"}、受け入れ条件 8 のコマンドは {"number": 2170, "result": "kept_open", "reason": "本番の版のリリース後テストの記録が無い"} を返した。同じ形の記録を組んで parse_record を呼ぶと、対象の版: 10.26.1 ではブロックが返り、対象の版: v10.26.1 では返らない（verify_block が None）。

前提とする取り決め

境界

未決

無し。決められない点は前提 1〜5 に書いた。

進行

モード: — / 進め方: auto

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