mvv-gate: 設計のプランで、設計の前に打った requirements-check の exit 2 を材料に読み、関門 1 の助言が unknown になる #1502

何を見つけたか

設計 PR の本文の「テスト」の表が、on_fail で分岐した run ステップの exit を最終の結果として載せる。 MVV 判定はこの本文を材料に読む下流で、同じ誤りを引き継いで unknown を返す。

スプリント m1483 の設計プラン（supervise.py new sprint --design 1483 1436 --state ...、ndf 10.17.45、2026-09-29）で、関門 1 の助言の MVV 判定（mvv-gate.py check --gate design --advise）が 2 本とも「判定できない（unknown）」になった。

• 設計のプランは先頭で spec-copy.py check <課題> issues/issue-<課題>-requirements.md を打つ。写しがまだ無いので終了コード 2 になる。これは想定どおりの動きで、次の requirements のステップが写しを作る
• 判定は、この最初の exit 2 を「requirements-check が止まった」と読んだ。そのうえで「要求の写しが本文と揃っているか確かめられない」を理由に unknown を返した（PR 1499・1500 の MVV 判定のコメント）
• 関門の時点で spec-copy.py check を打ち直すと、2 本とも「本文と一致する」で通った

今の作り

• 設計のプランは先頭で requirements-check（plugins/ndf/scripts/supervise_lib/sprint_waves.py:157-162 、on_fail: requirements ）を打つ。写しがまだ無いときの exit 2 は、要求を書くステップへ進むための分岐である
• review の後には requirements-recheck（sprint_waves.py:77 、設計のプランのレビューの修正が要求の写しだけを手で直し、課題の本文（正）と写しが食い違ったまま進む #1769 ）が写しと課題の本文の一致を確かめ直す。ただし PR 本文を作る pr ステップ（sprint_waves.py:192 ）はそれより前にある
• pr ステップの本文は plugins/ndf/scripts/supervise_lib/pr.py:255-258 の _machine_body が作る。state.results の run ステップを全部（分岐の exit 2 の requirements-check を含む）「テスト」の表へ載せる
• MVV 判定（sprint_waves.py:389（ndf 10.21.0） の check --gate design --pr {pr} と、助言の判定）は plugins/ndf/scripts/mvv-gate.py:116,135 で gh pr view の本文をそのまま材料にする。よって本文の表の誤りが MVV 判定へ渡る

直さないと何が起きるか

normal では助言なので、承認の材料が 1 つ欠けて見えるだけで済む。pace: auto / fast では、関門 1 の MVV 判定が毎回 unknown になり、人の承認へ戻る。MVV の事前承認で関門を通すという仕組みが、設計のプランでは働かない。

期待する振る舞い

PR 本文の「テスト」の表は、分岐のための非 0 を失敗として載せない。例えば、on_fail で分岐した run ステップの exit を「写しがまだ無い（要求を書くステップへ進む）」として載せる。または、後の再確認（requirements-recheck）の結果で置き換える。MVV 判定は PR 本文を読むので、本文が直れば同じ形で直る。

由来

スプリント m1483（#1483・#1436）の承認ゲート 1

同じ根で見つけたこと（2026-09-30、スプリント m1316）

設計 PR #1515 の本文の「テスト」の表が、先頭の requirements-check の exit 2 を最終の結果として載せ、「requirements-check は通っていません。実行した場所や時点を確かめてから再実行する必要があります」と書いた。design ブランチの写しで spec-copy.py check 1316 を打ち直すと「本文と一致する」で通る。PR 本文の生成も、MVV 判定と同じく requirements のステップより後の状態を渡す対象に含める。

直す場所

• 現象レイヤー: mvv-gate の関門 1 の助言（unknown）と、設計 PR の本文の「テスト」の表
• 修正レイヤー: plugins/ndf/scripts/supervise_lib/pr.py の _machine_body が作る「テスト」の表
• 修正方針: 向きの修正。表が分岐のための非 0 を失敗として載せず、後の再確認の結果で置き換えるようにする。MVV 判定と PR 本文の両方が同じ形で直る

再確認（ndf 10.21.0、2026-10-25）

• 設計 PR cross-refactoring: ファイルのパスを受けない範囲テストのテンプレートで改修の範囲テストが毎回落ち、修正のラウンドを使い切る → 着手前にテンプレートを試して止まり、直す箇所が出る（#1630） #2098 （2026-10-24、設計 cross-refactoring の範囲テストが変わったファイルのディレクトリを discover し、テストを tests/ にだけ置くプロジェクトで落ちて fix を繰り返す #1630）の本文の「テスト」の表に requirements-check | 2 | stopped と「マージの前に原因を確かめる必要があります」が載った。同じ現象の再発である
• 同じ supervise_lib/pr.py の _machine_body の表の last[:120] が 実装のプランの design-tests が、設計で改名を決めたテストを止まりと判定せず、止まった理由を全文で残す #2118 の切れの原因でもあり、まとめて直せる

同じ現象の観測（2026-10-31〜11 月）

• 開発ループ l20261031 の 1 周目（2026-10-31）で、hook: 承認ゲートの外の問い合わせを止めて AI に判断させ、費用がかかる判断だけを人へ回す #2206 の設計 PR hook: 承認ゲートの外の問い合わせを止め、AI が決められない問いだけを人へ回す（#2206） #2234 の承認ゲート 1 の MVV 判定が unknown になった。理由は「requirements-check が exit 2 で止まり、issues/issue-2206-requirements.md を読めていない」。進捗の記録では requirements-check が exit 2（00:33:11 UTC）、requirements が 0（00:35:55）、requirements-recheck が 0（01:16:09、本文と一致）、mvv が 10（unknown、01:16:45）の順だった。この周回は 3 件とも人へ戻った
• 開発ループ lflow の周回 1（2026-11-02）で、設計のプラン 3 本（relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346・開発ワークフローに「見直し」と「大整理」を足す: 棚卸しを毎スプリントの差分の棚卸し・数回に 1 回の見直し・十数回に 1 回の大整理（根本原因の発見と組み直し、後回しの再評価）に分ける #2315・NDF: 200K固定・工程境界の無条件再起動を見直し、費用と品質で継続を判断する方式を比較検証する #2262）のすべてで requirements-check が exit 2 で止まり、後の requirements-recheck は 3 本とも本文と一致した。開発ワークフローに「見直し」と「大整理」を足す: 棚卸しを毎スプリントの差分の棚卸し・数回に 1 回の見直し・十数回に 1 回の大整理（根本原因の発見と組み直し、後回しの再評価）に分ける #2315（PR backlog-refinement: 棚卸しを 3 つの深さで回し、ニーズとシーズの調査から課題を足せるようにする（#2315） #2379）と NDF: 200K固定・工程境界の無条件再起動を見直し、費用と品質で継続を判断する方式を比較検証する #2262（PR NDF の再起動の方針: 試行方式を選ぶと工程境界で継続か再起動かを容量と費用で決め、現行方式と比べられる（#2262） #2385）の MVV 判定は unknown になり、理由の 1 つにこの exit 2 を挙げた
• 異常系・ログ・回復とデータ・入出力の形を 1 つの実行の核へ集め、異常系の課題 103 件を型ごとにまとめて解く #2335 の設計 PR NDF のスクリプト: すべての入口が 1 つの実行の核と契約の一覧を通り、異常系の不具合を型ごとに防げるようにする（#2335） #2359 と relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346 の設計 PR relay の統括役の結合テスト: tmux を使う 4 件が手元と CI で毎回走り、落ちたときに原因を読める（#2346） #2524 の関門 1 の MVV 判定が、どちらも「requirements-check が exit 2 で止まった」を理由に unknown を返した（各課題の本文の「人の判断待ち」の節）