Repository navigation
承認資料の検査の結果が、やり直した refactor の落ちた試行の値を読んで採用 14 件を 0 件と書き、cross-review の見送り 2 件を 7 行に重ねる #2129
Description
何を見つけたか
本番 10.21.0 の承認資料 issues/approval-ndf-v10.21.0.md の ## 検査の結果 が、検査のプランの記録と 2 か所で食い違った。
| 項目 | 承認資料 | 検査の記録 |
|---|---|---|
| リファクタリング | 採用 0 件 / 取り消し 0 件（34 行） |
refactor は 3 回走った（6-check-state/progress.jsonl）。1 回目（08:52 JST）は着手前のテストが 180 秒で打ち切られ、2 回目（08:58）は予算 30 分が下限 43 分に届かず、どちらも何もせず落ちた。3 回目（09:45、--budget-minutes 60）が「項目 14・採用 14・取り消し 0・見送り 17」で完了した（01-refactor.out）。0 件は落ちた試行の値と見える（04-refactor.out は 180 秒の打ち切りの出力） |
| cross-review の見送り | 「見送った指摘 7 件」で 7 行（26〜33 行） | 中身は 2 件（record-pr の指摘が 5 行、manual ステージの指摘が 2 行。行番号の有無と違いだけで同じ文面） |
notes --check-state が同じステップの複数の試行のうち完了した回ではない回を読み、レビューの見送りをラウンドごとに重ねて並べているように見える（原因は未確認）。
どこで見つけたか
/work/ai-plugins/issues/approval-ndf-v10.21.0.mdの 26〜34 行~/.local/state/ndf/sv/s2089/6-check-state/01-refactor.out・04-refactor.out- development-workflow: 棚卸しの結果から次のスプリントを決めて自動で始め、スプリントを繰り返す開発ループのモードを持つ #2089 の振り返り
なぜこの変更の範囲外なのか
#2089 は開発ループのモードを足す変更で、承認資料の組み立て（release-steps.py notes）は受け入れ条件に無い。根拠: Value 2「承認を求めるときは判断の材料を資料に集めてから求める」・Value 10 の但し書き「承認資料に載せる材料の正しさには当てない」（MVV 版 3）
直さないと何が起きるか
承認ゲート 2 で利用者が読む材料が、実際に行ったリファクタリングを「0 件」と示し、見送りを 3.5 倍に見せる。利用者は問い直さずに 1 回で決められない（Vision）。pace: auto の MVV 判定も同じ材料を読む。
起票者の推定
- 見送りの重複は、レビューの見送りをラウンドごとに重ねて並べているため（推した出所: 記録の値の突き合わせ）
- 修正レイヤーは親 全工程の結果を統一した JSON レポートにし、失敗・未収束・未記録を ok で返さない #2227 の結果の読み方（
statusがokの試行だけを値として採る）。issues/approval-ndf-v10.26.1.mdも「採用 0 件」で、再発の疑いがある
由来
issue #2089
受け入れ条件
- 検査の状態ディレクトリに
refactorの試行が複数あり（NN-refactor.out）、番号の最大の試行の結果 JSON がstatus: ok以外で、ほかの試行がstatus: okのとき →release-steps.py notes --check-stateの## 検査の結果のリファクタリングの行は、okの試行の値（承認資料の検査の結果が、やり直した refactor の落ちた試行の値を読んで採用 14 件を 0 件と書き、cross-review の見送り 2 件を 7 行に重ねる #2129 の例では採用 14 件）を載せる - 同じステップに
status: okの試行が 1 つも無いとき → 落ちた試行の値（採用 0 件 / 取り消し 0 件 など）を載せず、そのステップがokで終わっていないことを示す - 試行が 1 回だけで
status: okのとき → 今と同じ値を載せる（退行しない） - cross-review の結果 JSON の
itemsに、pathとsummaryが同じでlineの有無か値だけが違う見送り（kind: deferred）が複数あるとき →## 検査の結果の見送りはその指摘を 1 行で書き、件数も 1 件と数える（承認資料の検査の結果が、やり直した refactor の落ちた試行の値を読んで採用 14 件を 0 件と書き、cross-review の見送り 2 件を 7 行に重ねる #2129 の例では 7 件でなく 2 件） pathかsummaryが違う見送りは → 今と同じく別の行で、別の件として数える（退行しない）
進行
モード: — / 進め方: auto
- 要求と受け入れ条件
- 作業場所の用意 — 2026-10-31 03:59
- 設計
- 素材の収集と出典の確定
- ドキュメント再構成
- ドキュメントレビュー
- 計画 — 2026-10-31 03:58
- 実装 — 2026-10-31 05:34
- 構造改善 — 2026-10-31 07:37
- 実装レビュー — 2026-10-31 09:12
- 完了判定 — 2026-10-31 05:39
- Pull Request — 2026-10-31 05:50
- 確定仕様化 — 2026-10-31 10:59
- 後片付け — 2026-10-31 10:57
- 配布 — 2026-10-31 10:33
- 体裁レビュー
- リリース後テスト — 2026-10-31 10:56
- 振り返り — 2026-10-31 11:00
- 棚卸し — 2026-10-31 11:21
振り返り: #2282 (comment)
Activity
[-]承認資料の検査の結果が、やり直した refactor の最後の試行だけを読んで採用 14 件を 0 件と書き、cross-review の見送り 2 件を 7 行に重ねる[/-][+]承認資料の検査の結果が、やり直した refactor の落ちた試行の値を読んで採用 14 件を 0 件と書き、cross-review の見送り 2 件を 7 行に重ねる[/+]takemi-ohama commentedon Oct 25, 2026
ndf v10.22.0 の承認資料（スプリント m1914）で再発した。承認資料の「リファクタリング: 採用 0 件 / 取り消し 0 件」は、実績の採用 10 件と食い違っていた。
.ndf/tmp/sprint-m1914/6-check-state/に01-refactor.outと04-refactor.outがある。01 はstatus: ok・adopted 10・final_gate: passedで、state.jsonのlogの refactor の counts もこの値である。04 は検査の経路を戻ってやり直した refactor で、refactor.py init が終了コード 4 で止まった（着手前のテスト 594 秒で予算超過）。metricsは{exit: 4}だけであるrelease_lib/materials.pyのlast_resultは番号の最も大きい*-refactor.outを読む。このため 04 の stopped の結果を拾い、adoptedが無いので 0 と書いたstate.jsonのlogの counts（check-trigger.pyのfindings_ofと同じ読み方）を正とするか、stopped の結果を飛ばすと直る見込み。Merge pull request #2260 from devbasex/feat/issue-2129-m26-1
Merge: develop を取り込み、スプリント m26-1 との衝突と食い違いを解く
takemi-ohama commentedon Oct 31, 2026
スプリント（26 自律実行の信頼性のスプリントを閉じる）を通りました