受け入れ条件の前提と文言の確認がリリース後テストまで遅れる（退行しない条件の前提を今の振る舞いで確かめず、マージ前に確かめられる条件も未実施に並ぶ）

何を見つけたか

スプリント m1914（ndf v10.22.0）のリリース後テストで、マージ前に確かめられた受け入れ条件の食い違いが 2 件、リリースの後に初めて見つかった。

CI の無いリポジトリで、スプリントの検査のプランが cross-review の unverified（exit 2）と on_fail: abort で毎回止まる #1593 の受け入れ条件 6 は「退行しない」の条件で、「cross-review が収束しない（final が approved 以外）か駆動が stopped を返したときは、review の on_fail: abort のとおり止まる」と書く。しかし final が max_rounds・oscillation のときは、変更前（10.21.0）から止まらない（cross-review が収束しない（final が max_rounds・oscillation）のに駆動が ok を返し、スプリントの検査の review が止まらない #2143）。条件が前提にした「今の振る舞い」が、事実と違っていた
昇格のプランが、導入の確認をしたコミットと違う先頭を本番チャネルへマージしうる #1529 の受け入れ条件 9（promote --help が承認ゲート 2 へ戻ることを書く）は、help を 1 度読めばマージ前に確かめられた。テストは引数名が出ることしか見ていなかった（merged-steps.py promote の --help が、照合が食い違ったときに承認ゲート 2 へ戻ることを書いていない（#1529 の条件 9） #2142）

承認資料の「未実施のリリース後テスト」には、4 課題の受け入れ条件 31 件がすべて並んでいた。マージ前に確かめられた条件と、リリースの後でしか確かめられない条件の区別が無かった。

どこで見つけたか

PR #2138（ndf v10.22.0 のリリース）のリリース後テストのコメント、issues/approval-ndf-v10.22.0.md の「未検証・残る危険」、スプリント m1914 の振り返り。

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

スプリント m1914 の 4 課題は、どれも工程（requirements-design・quality-gates）の手順を変える課題ではない。振り返りの「次に変えること」で、次の変更で試すこととして残す。根拠: MVV 版 3（判断の範囲は目の前の変更に限る）。

直さないと何が起きるか

前提の誤った「退行しない」条件は、リリース後テストで初めて崩れる。マージ前に確かめられた文言の欠けは、リリースまで残る。本番に出てから課題が増え、元の課題を閉じられない。

起票者の推定

requirements-design で「退行しない」条件を書くときは、今の振る舞いを 1 度実行して前提を確かめる（推した出所: 今回の CI の無いリポジトリで、スプリントの検査のプランが cross-review の unverified（exit 2）と on_fail: abort で毎回止まる #1593 の条件 6）
quality-gates の完了報告で、受け入れ条件ごとにマージ前に確かめたか、リリースの後でしか確かめられないかを分け、承認資料の「未実施のリリース後テスト」には後者だけを載せる（推した出所: issues/approval-ndf-v10.22.0.md の 31 行）

由来

PR #2139

未実施に並ぶ仕組み

受け入れ条件に印を付けるのは sprint-close.py の 1 か所だけで、リリース後テストの後である。release_lib/materials.read_unverified は印の無い条件をすべて「未実施のリリース後テスト」に載せるため、マージ前に確かめた条件も並ぶ。承認資料の該当行数は 10.24.0 が 19、10.25.0 が 7、10.26.0 が 20、10.26.1 が 21。

直す場所は、quality-gates の完了報告で条件ごとに「マージ前に確認済み」と「リリースの後でしか確かめられない」を分けて記録すること、その記録を read_unverified が読むこと、requirements-design で「退行しない」条件の前提を今の振る舞いで確かめること。条件ごとの検証の結果は親 #2227 の工程のレポートに載せる。

関連: #2143（例）・#2166（経路の違う記録を根拠にした）