リリース後テストの起動指示が根拠に指した配布の記録が条件の経路を通ったかを確かめず、#2104 の昇格の経路が実機で一度も通らないまま残る #2166

何を見つけたか

リリース後テストの起動指示で、conductor が「10.24.0 の配布記録を根拠にしてよい」と書いた。#2104 の受け入れ条件 1〜3 が求めるのは pace: normal の昇格の経路（merged-steps.py promote / --from promote-approved）だが、10.24.0 の本番は release-steps.py release の経路で出ており、昇格の経路を通っていない。リリース後テストの担当は経路の違いに気付き、条件 1〜3 を単体テストだけの合格として記録した（#2160 (comment) ）。

• 起動指示が根拠を指すときに、その記録が条件の経路を通ったかを conductor が確かめる手順が無い
• このため、pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 の条件 1〜3（承認ゲート 2 の先端と promote-approved がマージする先端の照合）は、実機の経路でまだ一度も通っていない

どこで見つけたか

スプリント m2087 の振り返り（リリース PR #2160）。リリース後テストの記録は上の URL。

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

#2104 の受け入れ条件は照合の実装を扱い、リリース後テストの起動指示の書き方は扱わない。また、昇格の経路を実機で通すには pace: normal で昇格する配布が要り、このスプリントの配布の経路では作れない。根拠: Value 1（まず届ける。開発版のチャネル・導入の確認・自動テストで守る）（MVV 版 3）

直さないと何が起きるか

• 起動指示の根拠が条件の経路と違っても、リリース後テストの担当が気付かなければ、通っていない経路が合格と記録される
• pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 の照合は、次に pace: normal で昇格するまで実機で確かめられないまま残る。pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 は閉じるため、この課題が確かめる段取りを持つ

起票者の推定

• conductor の起動指示（development-workflow の references/agent-layers.md のリリース後テストの起動）で、根拠に使う記録を指すときに、その記録が通った経路の名前（release-steps.py release / merged-steps.py promote など）を添える（推した出所: 今回の経緯）
• pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 の条件 1〜3 は、次に pace: normal で昇格する配布のリリース後テストで確かめる（推した出所: 起動指示の材料 3 と、リリース後テストの記録）

由来

PR #2160