結果を読む共通の関数（step_read.py の試行と置き場の読み方）を製品のコードが使わず、承認資料は試行の選び方を自前の last_result に持ち続ける #2289

何を見つけたか

手順のスクリプトの結果を読む側の共通の関数（plugins/ndf/scripts/lib/step_read.py の pick_ok_attempt・open_place・place_stop）を、製品のコードがどこからも呼んでいない。呼んでいるのはテストだけである（grep -rn "pick_ok_attempt\|open_place\|place_stop" plugins/ndf --include=*.py で tests と定義以外の当たりが 0 件）。同じモジュールの not_ok_reason・process_if_not_ok は sprint-close.py・supervise_lib/state.py が使っている。

承認資料の組み立ては、試行の選び方を plugins/ndf/scripts/release_lib/materials.py の last_result(prefer_ok=True) に自前で持ち続けている。ok の試行が無ければ最後の試行の結果を返す作りで、pick_ok_attempt（ok の試行が無ければ値を返さず no_ok_attempt を返す）と振る舞いが違う。呼ぶ側が status を見て「どの試行も ok で終わっていない」と書くため、今は誤った値は出ていない。

どこで見つけたか

スプリント m26-1（v10.27.2）の確定仕様化で、docs/specifications/ndf-step-result-gaps-and-reading.md をコードと照らしたとき。設計（#2227 の決定 4）は「既存の last_result の置き換えは #2129 で行う」としていたが、#2129 は prefer_ok を足す形で直した。

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

確定仕様化はコードを変えず、今のコードに合わせて仕様を書く工程である。読み手を step_read へ移すのはコードの変更で、テストを伴う。根拠: Value 6（形の検査と読む規則を 1 か所に置く）（MVV 版 3）

直さないと何が起きるか

試行の選び方が step_read.py と materials.py の 2 か所にあり、新しい読み手がどちらを手本にするかで振る舞いが分かれる。last_result を手本にすると、status を見ない読み方（#2129 の不具合の形）がまた生まれうる。使われない 3 つの関数は保守の対象だけが増える。

起票者の推定

• 「materials.last_result を step_read.pick_ok_attempt へ置き換えるのが望ましい」（推した出所: 全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227 の設計の決定 4。step_read を消す選択もありうる）
• 無し（ほかは grep とコードの読み取りで確かめた事実）

由来

issue #2227