設計で実装を複数の Pull Request に分けると決めても、スプリントの実装のプランは課題ごとに 1 本で組まれ、食い違いで止まらない #2539

何を見つけたか

設計で「実装は複数の Pull Request に分ける」と決めて承認ゲート 1 を通しても、スプリントの実装のプランは課題ごとに 1 本で組まれる。実装はそのまま 1 本の Pull Request になる。どの工程も、この食い違いで止まらない。

• 設計: NDF Factory: 画面で行える操作を API と MCP からも同じく行える（機能から起こした配列の入出力・委任の認証・追記だけの操作の記録） #2384 の設計文書（ndf v10.27.19 の時点の設計文書 issues/issue-2384-design.md の 493 行目（いまのリポジトリには無い。git show ndf--v10.27.19:issues/issue-2384-design.md で読める）。確定仕様は docs/specifications/ndf-factory-agent-access.md）は「設計は 1 本、実装は 4 本の Pull Request に分ける（決定 15）」と書き、承認ゲート 1 で承認された
• 実装のプラン: スプリント lfactory3-4 の実装のプランは NDF Factory: 画面で行える操作を API と MCP からも同じく行える（機能から起こした配列の入出力・委任の認証・追記だけの操作の記録） #2384 につき 1 本だった（.ndf/loop/lfactory3/lap-4/sprint/3-impl-2384.json）
• 結果: 実装は PR #2384 を実装する（スプリント lfactory3-4） #2512 の 1 本で、79 ファイル・追加 5,758 行・削除 1,876 行になった
• 食い違いに気づいたのはリリース後テストで、配布した後だった（ Release: ndf v10.27.19 #2531 (comment) ）

どこで見つけたか

スプリント lfactory3-4 の振り返り（PR #2532）。材料はリリース後テストの記録と、上の設計文書・実装のプラン・PR #2512 の規模。

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

振り返りは進め方の記録と起票の取りこぼしを拾う工程で、スプリントのプランの組み立て（実装の段を課題ごとに作る雛形）を直す工程ではない。直す場所は、設計の結果から実装のプランを作る処理である。根拠: Value 2（人が判断できる量に収める）・Value 8（判断の理由を残す）・スプリント Value 1（MVV 版 5）。

直さないと何が起きるか

• 承認ゲート 1 で人が承認した分け方が、実装で黙って変わる。承認資料（設計）と実際の変更が食い違う
• 1 本の Pull Request が人の読み切れる量を超え、レビューと承認ゲート 2 の判断が重くなる（PR #2384 を実装する（スプリント lfactory3-4） #2512 は 79 ファイル）
• 食い違いがリリース後まで見つからない。分けるか 1 本にするかの判断を、配布の前に誰も行わない

起票者の推定

• 設計の分割の決定を実装のプランへ写すか、写せないときは実装の前に止めて人へ戻すのが正しい直し方である（推した出所: 振り返りの判断。利用者の指示には無い）
• 決定 15 は承認ゲート 1 で「4 本に分ける」として承認されたと読める（推した出所: 同じ設計文書の 493 行目は「承認ゲート 1 で利用者が決める」と書き、承認の答えに分け方への言及は無い）

由来

PR #2532