merge-when-green: 自動反映の本番チャネルへのマージで、承認ゲート 2 で見た先端と merge-approved がマージする先端を照合しない #2147

何を見つけたか

経路 merge で宛先が自動反映の本番チャネルのとき、merge-when-green の承認ゲート 2 の停止（merged_lib/merge.py の gate_stop）は、止まる時点の Pull Request の先端を承認資料にも結果にも残さない。続け方の next（merge-when-green <n> --gate-approved user、プランでは --from merge-approved）も照合の引数を持たないため、承認の後に Pull Request の先端が進むと、利用者が見ていないコミットが本番チャネルへ入る。

• merge-when-green 自体は --expect-head <SHA> を持つ（merged-steps.py 470 行）が、承認ゲート 2 の停止の側がその材料を残さず、プランも渡さない
• pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 が pace: normal の昇格（経路 promote）について同じ欠けを直す。経路 merge だけが照合を持たない状態が残る

確かめたもの: develop（d98516e5）の plugins/ndf/scripts/merged_lib/merge.py の gate_stop（74〜100 行）と merge_when_green（210 行〜）。

どこで見つけたか

#2104 の設計 PR #2145（issues/issue-2104-design.md の「未確認のまま残ること」の 1 行目、issues/issue-2104-requirements.md の未決 3）。conductor が設計 PR の承認の前に起票すると決めていた。

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

#2104 の受け入れ条件は経路 promote の昇格のプランだけを対象にする。経路 merge は止まる関数と続け方のプランが違う。根拠: Value 3（MVV 版 3。判断の範囲は目の前の変更に限る）

直さないと何が起きるか

delivery で経路 merge を組み、宛先が自動反映の本番チャネルのリポジトリで、承認ゲート 2 で承認した中身と本番チャネルへ入る中身が食い違いうる。

起票者の推定

• pace: normal の昇格で、承認ゲート 2 で見た先端と promote-approved がマージする先端を照合しない #2104 の決定 1（承認資料に「承認したコミット」の行を material_row で置き、material_sha で読む）と同じ形で直せる（推した出所: PR 昇格の承認の後のマージ: 承認ゲート 2 で利用者が見た先端だけを本番チャネルへ入れる（#2104） #2145 の設計文書）

由来

PR #2145