並列の計画: オーケストレーターからレーンへの指示が伝わらない（直して出し直すの指摘が設計に渡らない、ほか） #2510

起票者の推定

この課題の本文（下の「依頼（原文）」）は、開発ループの記録と設計 PR を調べた AI が書いた。利用者の指示の原文は、本文の節「設計の承認ゲート 1 での利用者の指摘（直して出し直す）」（2026-11-05）だけである。そのため、その節に無い本文の条件は起票者の推定として扱い、承認ゲート 1 で利用者が確かめる。その節にある条件（「2026-11-05 の追加の形」の 3 つを要求に足すこと、自動の出し直しの上限）は利用者の指示として扱い、この表に載せない。

依頼（原文）

書き手: 起票者（開発ループの記録と設計 PR を調べた AI）、日付: 2026-11-05。下は要求を書く前の課題の本文の全文である。利用者の指示の原文（書き手: 利用者、オーガナイザーが写した、2026-11-05）は、この本文の末尾の節「設計の承認ゲート 1 での利用者の指摘（直して出し直す）」にあり、ここへは写さない。

何が起きたか

開発ループで、承認ゲート 1 の答え「直して出し直す」（loop answer --revise --note <指摘ファイル>）の指摘が、出し直しの設計に反映されない。同じ指摘を 2 回送っても反映されなかった。

課題	設計 PR	指摘を送った時刻	出し直しの中身
#2344	#2482	14:50Z、21:09Z（同じ指摘を、直す箇所を名指しして再送）	どちらの回も、指摘の後のコミットはレビューの指摘への手当てだけ。要求・受け入れ条件 1・決定 4・設計の I3・I7 は元のまま
#2338	#2497	21:09Z	指摘の後の 3 コミット（22:17〜22:28Z）は、ドキュメント再構成とレビュー 4 ラウンド目への対応だけ。範囲（60 ファイル・PR 7 本・3 スプリント）は元のまま

原因

1. 指摘が設計のプランに入らない。 周回 9 の設計のプラン（/work/ai-plugins/.ndf/loop/lroot3/lap-9/sprint/1-design-2338.json）に、指摘の中身（監視が先に別の早期の警告を出していると、非致命にした permission_denials の件数を警告に残さない #2059・検査の記録の集計で閾値を見直せない: トリガーの評価が 0 回・落ちた工程が「不明」・流出不具合の記録が 0 行 #2300 に絞る など）が無い。設計の手順は指摘を読まずに、前の設計 PR をレビューの指摘だけで直した
2. 指摘を書いた節が上書きで消える。 loop answer --revise は指摘を loop.json の人の判断待ちの行（note）と、課題の本文の節「人の判断待ち（開発ループ <名>）」に書く（lib/sprint_loop.py の apply_answer → mark_issue）。次の周回で同じ課題を再び人の判断待ちへ移すと、同じ節が「答え: まだ」で上書きされ、指摘が本文から消える。今の 1 回の実行を識別子 1 つで追える記録とログにそろえる #2338 の本文には、指摘がどこにも残っていない

影響

直して出し直すたびに 1 周回を使い、設計も人の承認も同じことを繰り返す。lroot3 の周回 2〜4・7〜9 の多くがこの形で使われた（#2507 の周回の表）。

直し方の案

1. 出し直しの設計のプランに、指摘の全文を入力として渡す（設計の worker の起動指示に「この指摘を満たすように直す。満たせない項目は理由を書く」として載せる）
2. 指摘を課題の本文の残る節（「直して出し直す」の履歴の節。回ごとに追記し、上書きしない）に書く。設計の手順はその節を読む
3. 出し直しの設計 PR の本文に「指摘への対応」の表（指摘ごとに直した・直せない理由）を置く。オーガナイザーが承認を問うときに、そのまま材料にする

受け入れ条件

1. loop answer --revise --note の指摘の全文が、次の周回の設計のプランの入力に入る
2. 課題の本文の指摘の履歴は、次の周回で人の判断待ちへ移しても消えない
3. 出し直しの設計 PR の本文に、指摘ごとの対応の表がある

広げた範囲: オーケストレーターからレーンへの指示が伝わらない（利用者の指示で検討、2026-11-05）

「直して出し直す」の指摘は 1 つの例である。2026-11-04〜05 の計画 p3 では、次の形が起きた。

送ったもの	届いたか	落ちた場所
設計の承認（approved）	記録には届いた	承認の後のマージに持ち主がいない（#2507）
直して出し直すの指摘（note）	記録には届いた	設計のプランが読まない。本文の節は次の周回で上書きされる（この課題）
同じ問いへの答え	行き違いで再送が来た	答えが届く前に、レーンが同じ問いを送った
引継ぎ文書の書き換え（ループ名・予算）	届いた	レーンが起こし直しのときに読むので伝わった

共通の原因: 答えは記録（loop.json・耐久のイベント）には届く。しかし、その値を読んで動く側が決まっていない値がある。レーンが指示どおりに動いたかを確かめる手順も無く、人が設計を読んで初めて気づいた。

直し方の案

• A. 読む側を決める（元を断つ）: 答えの種類ごとに、読んで動く手順を 1 つ決める。承認はオーガナイザーが設計 PR をマージする（開発ループ: 承認した設計 PR を誰もマージせず、実装に進めないまま周回の予算が尽きる #2507）。直して出し直すは、指摘の全文を設計のプランの入力に入れる（上の 1・2）。予算は loop start --budget-* で上書きする
• B. 届いたかを確かめる（漏れを拾う）: 出し直しの設計 PR の本文に「指摘への対応」の表を置く（上の 3）。オーガナイザーは人に問う前に、指摘と表を突き合わせる。足りなければ人に聞かず、直して出し直すへ自分で戻す（同じ指摘のまま、届かなかった項目を名指しする）
• C. 指示の通り道を 1 本にまとめる: 承認・指摘・止める・予算などを、種類を持つ 1 つのメッセージにする。レーンは周回の境で読んで「当てた」を記録し、当てていない指示はオーガナイザーの wait に出す。A・B の上位の形だが大きな作り直しになるので、A・B で効き目を確かめてから要否を決める

推奨は A と B を両方入れること。

受け入れ条件（足すもの）

4. オーガナイザーは、出し直しの設計の承認を人に問う前に、指摘と「指摘への対応」の表を突き合わせる。届いていない項目があれば、人に問わずに直して出し直すへ戻す
5. 答えの種類（承認・直して出し直す・やらない・予算・止める）ごとに、読んで動く手順が 1 つ決まっていて、手順書（references/parallel.md・loop.md）に書かれている
6. 直して出し直す指摘を持つ課題の設計のプランでは、要求の写しが一致して requirements-check が 0 を返しても要求のステップが流れ、起動指示に指摘の本文が入る（テストで確かめる）
7. 直して出し直す指摘を持つ課題の MVV 判定（mvv-gate.py check --gate design）の材料に指摘の本文が入り、指摘と食い違う設計は「従う」にならない（テストで確かめる）

同じ根を持つ課題

• 開発ループの「直して出し直す」指摘が設計のプランへ渡らず、指摘を反映しない設計が承認ゲート 1 を MVV 判定で通る #2494: 開発ループ lflow2 の周回 3 で、設計のプランで cross-review が上限到達（未解決 0 件）を返すと MVV 判定を飛ばし、承認ゲート 1 が「判定できない」になる #2388 の出し直しの設計が要求のステップを飛ばし、指摘を反映しないまま MVV 判定「従う」で承認ゲート 1 を通った（設計 PR 設計のプラン: 上限で終わった cross-review も、未解決 0 件なら MVV 判定へ進める（#2388） #2479 ）。受け入れ条件 6・7 はこの例から来る
• 出し直しの周回の設計プランが、設計 PR の最新から始まらず指摘も設計の指示へ渡さない #2489: 開発ループ lroot3 の周回 2 で、実行の持ち主と後片付けを核に持たせ、残骸と並行の衝突で止まらないようにする #2342 の出し直しの設計の指示に指摘が入らなかった。同じ課題の、作業ブランチが設計 PR の最新から始まらない点は 出し直しの周回の設計プランが、設計 PR の最新から始まらず指摘も設計の指示へ渡さない #2489 が持つ

今の回避（2026-11-05）

#2338 と #2344 の本文に、節「設計の承認ゲート 1 での利用者の指摘（直して出し直す）」として指摘を写した。この節は上書きされない。設計の手順は課題の本文を読むので、これで届く見込みである。

• 2026-11-05 の結果: 本文の節に書き込んでも、1 回の実行を識別子 1 つで追える記録とログにそろえる #2338 の 3 回目の出し直し（lroot3 周回 11）は範囲が元のままだった。設計の手順は課題の本文の節も読んでいない。利用者の判断で 1 回の実行を識別子 1 つで追える記録とログにそろえる #2338（PR NDF のスクリプト: 1 回の起動を実行の識別子 1 つで、1 つの記録から始まりから終わりまで追えるようにする（#2338） #2497）は差し戻し、この課題を直した後に選び直す。プランは値でなく参照を持ち、実行の直前に解決して照合する #2344（PR プランの参照: プランを作り直さずに版・記録の PR を流す直前の値で使い、承認時の値と食い違えば止まる（#2344） #2482）も次に出し直されたら差し戻す
• 2026-11-05 の追加の形: 承認がレーンの記録に当たらない。 開発ループ: 止める指示を人が送った停止だけから置く（人が送っていない文から置かれた止める指示が、再開後の境で user_stop を起こした） #2474 の承認（parallel.py answer --approved、01:3xZ）が lroot3 の loop.json に入らず、「人の判断待ち・答え無し」のまま lroot3 は waiting_only で止まった。オーガナイザーが loop answer lroot3 2474 --approved --pr 2501 を直接打って回避した
• 2026-11-05 の追加の形: マージで先頭が変わると承認の依頼が再送される。 オーガナイザーが develop を取り込んでマージした設計 PR（差分の棚卸し: 見積の段階をそのスプリントの課題だけに付け、縮んだ所要をコマンド 1 本で確かめる（#2315） #2526）について、レーンは先頭の SHA の違いを新しい設計と見て、承認の依頼を再送した。取り込みのコミットだけの違いなら、承認を引き継ぐ形がよい
• 2026-11-05 の追加の形: 計画の前のループの承認待ちがオーガナイザーに届かない。 ループ lroot2（計画 p3 の前）で承認待ちになった設計 PR 4 本（NDF のエントリポイント: どの終わり方でも ok / gate / stopped と決まった終了コードで返り、欠けと失敗を ok と読まない（#2337） #2412・リリース後テスト: 利用者の設定ディレクトリのプラグインを変えずに確かめ、変わったら止まる（#2401） #2404・Agent の supervisor: 起動する ndf:worker に、いま通している工程の規則の Skill が届く（#2399） #2403・設計の結果の食い違い: 止まった理由のメッセージだけで、そろえる設計文書と項目が分かる（#2361） #2410、11/02 から）は、計画 p3 の questions に一度も出なかった。lroot3 はそれを「判断待ち」として除外し続け、柱の土台 結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337 が止まったまま後続の 4 本も実装で止まった。オーガナイザーが記録を読んで見つけ、利用者に問うた

目的

• 人が承認ゲート 1 で「直して出し直す」と答えて送った指摘を、次の周回の設計が必ず読み、指摘ごとに直したか・直せない理由を示した状態で人へ戻す
• 指摘が届いていない出し直しの設計を、人が読む前に機械と AI が見つけて戻す。人が同じ指摘を 2 回送ることを無くす
• 人の答え（承認・直して出し直す・やらない・予算・止める）ごとに、その答えを読んで動く手順を 1 つに決める
• 並列の計画で、オーガナイザーが送った承認がレーンのループの記録に必ず当たり、当たらなかったときはオーガナイザーが知る
• 取り込みのコミットだけで設計 PR の先頭が動いても、同じ設計の承認を人へ問い直さない
• 計画を始める前のループで承認待ちになった設計を、オーガナイザーの問いの一覧に出し、人の判断が要る設計を埋もれさせない

前提

• 前提 1: 設計のプランに渡す指摘は、その課題について送られた全回の出し直しの指摘とする（最新の 1 回だけにしない）。前の回の指摘を満たした状態を、次の回の設計で崩さないためである。別の開発ループで送った回も含める。ループが替わると前のループの指示が届かない形は、この課題の受け入れ条件 12 と同じ根を持つためである
• 前提 2: 指摘の項目は、--note に渡したファイルの箇条書き（- / *）と番号付きの行を 1 項目として数える。どちらも無ければ全文を 1 項目とする。「指摘への対応」の表はこの項目ごとに 1 行を持つ
• 前提 3: 出し直しの指摘と「指摘への対応」の表の突き合わせ（受け入れ条件 5）は、人の判断待ちの行へ移す共通の経路で行う。並列の計画のオーガナイザーが問う場合と、並列でない開発ループの conductor が問う場合の両方に効く（Value 7。直す場所を経路ごとに分けない）
• 前提 4（利用者の決定、2026-11-05）: 人へ問わずに直して出し直すへ自分で戻すのは、人の出し直し 1 回につき 1 回までとする。2 回目も届いていない項目が残れば、届いていない項目を添えて人へ問う
• 前提 5: 課題の本文の「出し直しの指摘の履歴」の節を書けなかった（GitHub の書き込みの失敗）ときも、ループの記録の人の判断待ちの行に指摘が残り、設計のプランは記録から指摘を読む。本文の節は人が読むための写しで、設計のプランの入力の正本はループの記録とする
• 前提 6: 予算の答えは、既にある loop start --budget-* / sprint-state.py loop budget（予算の反映）が読んで動く手順とし、この課題で新しい経路を作らない。止めるの答えは、既にある loop stop が置く止める指示を周回の境で読む手順とする
• 前提 7: 「取り込みのコミットだけの違い」は、問いの時点の先頭から今の先頭までに足されたコミットがすべて起点ブランチ（.ndf/worktree.json の base_branch）を取り込むマージコミットで、かつ設計 PR が変える設計文書と要求の写し（issues/issue-<番号>-*.md）の中身が問いの時点の先頭と同じであることで判定する。判定できない（照会の失敗・履歴を辿れない）ときは、今どおり問い直す
• 前提 8: 「前のループ」は、同じリポジトリの開発ループの記録（.ndf/loop/<名>/loop.json）のうち、計画のレーンでないループすべてとする。名前の付け方や順序で前後を決めない。レーンのループが「人の判断待ち」を理由に選定から外す課題の待ちは、どのループの記録にあっても対象に入る
• 前提 9: 開発ループ: 止める指示を人が送った停止だけから置く（人が送っていない文から置かれた止める指示が、再開後の境で user_stop を起こした） #2474 の承認がレーンの記録に当たらなかった原因は、この要求の時点で特定していない。依頼の id の打ち直し（設計 PR の先頭が動いたときに依頼を送り直すと、行の依頼の id が新しい id に置き換わり、古い id への答えが行に当たらない）が候補の 1 つである。受け入れ条件 10 は原因によらず観測できる形で書き、原因の特定は設計で行う

対象範囲

含む:

• 出し直しの指摘を、次の周回の設計のプランの要求のステップと設計のステップの起動指示へ入れる
• 出し直しの指摘を持つ課題では、要求の写しが一致しても要求のステップを流す
• 課題の本文に、回ごとに追記して上書きしない「出し直しの指摘の履歴」の節を置く
• 出し直しの設計 PR の本文に「指摘への対応」の表を置く
• 人の判断待ちの行へ移す前に、出し直しの指摘と「指摘への対応」の表を突き合わせ、届いていない項目があれば直して出し直すへ戻す
• 承認ゲート 1 の MVV 判定（mvv-gate.py check --gate design）の材料へ出し直しの指摘を入れる
• 答えの種類ごとの、読んで動く手順の表を development-workflow の references/parallel.md・references/loop.md に書く
• オーガナイザーの答え（parallel.py answer）がレーンのループの記録に当たらないときに、黙って捨てずにオーガナイザーへ知らせる
• 取り込みのコミットだけで設計 PR の先頭が動いたときに、設計の承認の依頼を送り直さず、問いの時点の依頼への答えを当てる
• 計画を始めるときと周回の境で、前のループの答えがまだの人の判断待ちを、オーガナイザーの問いの一覧へ送る

含まない:

• 承認・指摘・止める・予算を種類つきの 1 つのメッセージにまとめる作り直し（元の本文の直し方の案 C）。この課題の効き目を確かめてから要否を決める
• 承認の後に設計 PR をマージする持ち主を決めること（開発ループ: 承認した設計 PR を誰もマージせず、実装に進めないまま周回の予算が尽きる #2507 が持つ）
• 出し直しの作業ブランチが設計 PR の最新から始まらない点（出し直しの周回の設計プランが、設計 PR の最新から始まらず指摘も設計の指示へ渡さない #2489 が持つ）
• 1 回の実行を識別子 1 つで追える記録とログにそろえる #2338（PR NDF のスクリプト: 1 回の起動を実行の識別子 1 つで、1 つの記録から始まりから終わりまで追えるようにする（#2338） #2497）・プランは値でなく参照を持ち、実行の直前に解決して照合する #2344（PR プランの参照: プランを作り直さずに版・記録の PR を流す直前の値で使い、承認時の値と食い違えば止まる（#2344） #2482）の選び直しと差し戻し。この課題の配布の後に、利用者が選び直す
• 答えが届く前にレーンが同じ問いを送る行き違い（元の本文の表の 3 行目）。答えの読み手を決める範囲の外である
• 前のループの記録を、計画のレーンへ移す・合わせること。問いの一覧へ出すだけで、答えは今どおりその記録のループへ当てる
• 設計 PR の本文のテストの欄の書き直し（利用者の指摘の 3）。要求ではなく、設計 PR を出し直す手順で行う

ドメインイベント

用語

受け入れ条件

• 1. 課題に出し直しの指摘が 1 回以上ある状態で次の周回の設計のプランを組むと、要求のステップと設計のステップの起動指示に、その課題の全回の出し直しの指摘の全文が入る。起動指示は「この指摘を満たすように直す。満たせない項目は理由を書く」の旨を含む（テストで確かめる）
• 2. 出し直しの指摘を持つ課題の設計のプランでは、要求の写しが課題の本文と一致して requirements-check が 0 を返しても、要求のステップが流れる（テストで確かめる）
• 3. 直して出し直すの答えを当てるたびに、課題の本文の「出し直しの指摘の履歴」の節へ、回数・日付・設計 PR・指摘の全文が 1 回分ずつ追記される。その課題を次の周回で人の判断待ちへ移して判断待ちの節を書き直した後も、前の回の指摘が本文に残る（テストで確かめる）
• 4. 出し直しの設計 PR の本文に「指摘への対応」の表があり、出し直しの指摘の項目（前提 2）ごとに 1 行を持つ
• 5. 出し直しの設計を人の判断待ちの行へ移す前に、出し直しの指摘の項目と「指摘への対応」の表を突き合わせる。表が無い・行の無い項目がある・対応の欄が空の項目があるときは、人に問わずに、届いていない項目を名指しした直して出し直すへ戻す。戻すのは人の出し直し 1 回につき 1 回まで（前提 4）で、上限に達したら届いていない項目を添えて人へ問う（テストで確かめる）
• 6. 出し直しの指摘を持つ課題の承認ゲート 1 の MVV 判定（mvv-gate.py check --gate design）の材料に、出し直しの指摘の全文が入る。判定の問いは、指摘の項目を満たさない設計を「従う」にしないことを含む（テストで確かめる）
• 7. references/parallel.md と references/loop.md に、答えの種類（承認・直して出し直す・やらない・予算・止める）ごとに、その答えを読んで動く手順を 1 つずつ示す表がある。両方の文書で同じ表を写さず、片方が正本で、もう片方は正本を指す
• 8. 出し直しの指摘を持たない課題の設計のプランは変わらない。要求の写しが一致すれば要求のステップを飛ばし、起動指示に指摘の欄が入らない（テストで確かめる）
• 9. 直して出し直す以外の答え（承認・やらない）を当てたときの、承認の記録・ラベル・人の判断待ちの節の振る舞いは変わらない（既存のテストが通る）
• 10. parallel.py answer <計画名> <依頼> --approved を送ると、持ち主のレーンの次の周回の境で、そのレーンのループの記録の該当する人の判断待ちの行に承認が当たる。レーンの記録が waiting_only で止まっていても当たる。設計 PR の先頭が動いて依頼を送り直した後に、送り直す前の依頼へ答えた場合も、取り込みのコミットだけの違い（受け入れ条件 11）なら当たる。当てる行が見つからないときは、答えを捨てずに、依頼の id と理由がオーガナイザーの parallel.py wait の出力に出る（テストで確かめる）
• 11. 設計の承認の依頼を送った後に設計 PR の先頭が動いても、動いた分が取り込みのコミットだけ（前提 7）なら、レーンは依頼を送り直さず、問いの時点の依頼への答えを当てる。設計文書か要求の写しを変えるコミットが含まれるときと、判定できないときは、今どおり新しい先頭で問い直す（テストで確かめる）
• 12. 計画を始めるときとレーンの周回の境で、前のループ（前提 8）の記録にある答えがまだの人の判断待ちの行が、オーガナイザーの問いの一覧（parallel.py wait の questions）に、ループの名前・課題・設計 PR を添えて出る。同じ行を 2 回出さない。その問いへの答えは、その行を持つループの記録へ当たる（テストで確かめる）
• 13. レーンのループが「人の判断待ち」を理由に選定から外した課題は、その待ちを持つ行がオーガナイザーの問いの一覧に出ている（受け入れ条件 12 の行と同じものか、レーン自身の依頼）。問いの一覧に出ていない待ちを理由に外し続けることが無い（テストで確かめる）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

設計の承認ゲート 1 での利用者の指摘（直して出し直す）

（書き手: 利用者の答えをオーガナイザーが写した、日付: 2026-11-05。出し直しの設計はこの節を満たすように直す。この節は上書きしない）

利用者の判断（2026-11-05）: 直して出し直す。A・B の部分はこのままでよい。

1. 課題 並列の計画: オーケストレーターからレーンへの指示が伝わらない（直して出し直すの指摘が設計に渡らない、ほか） #2510 の本文の「2026-11-05 の追加の形」の 3 つを、要求と設計に足す:
   (a) 承認がレーンの記録に当たらない（開発ループ: 止める指示を人が送った停止だけから置く（人が送っていない文から置かれた止める指示が、再開後の境で user_stop を起こした） #2474 の承認が lroot3 の loop.json に入らず waiting_only で止まった。オーガナイザーが loop answer を直接打って回避）
   (b) 取り込みのコミットだけで設計 PR の先頭が変わると、承認の依頼が再送される（差分の棚卸し: 見積の段階をそのスプリントの課題だけに付け、縮んだ所要をコマンド 1 本で確かめる（#2315） #2526）。取り込みのコミットだけの違いなら承認を引き継ぐ
   (c) 計画の前のループ（lroot2）の承認待ちが、計画 p3 の questions に出ない（NDF のエントリポイント: どの終わり方でも ok / gate / stopped と決まった終了コードで返り、欠けと失敗を ok と読まない（#2337） #2412・リリース後テスト: 利用者の設定ディレクトリのプラグインを変えずに確かめ、変わったら止まる（#2401） #2404・Agent の supervisor: 起動する ndf:worker に、いま通している工程の規則の Skill が届く（#2399） #2403・設計の結果の食い違い: 止まった理由のメッセージだけで、そろえる設計文書と項目が分かる（#2361） #2410 が 11/02 から埋もれ、柱の土台 結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337 が止まった）。計画を始めるときと周回の境で、レーンの前のループの承認待ちをオーガナイザーへ送る
2. 自動で出し直す上限は、人の出し直し 1 回につき 1 回で決める（利用者の決定）。「利用者が決めること」から外し、決定の記録へ移す
3. PR 本文のテストの欄（requirements-check）を、再確認の結果（ok）に直す

進行

モード: standard / 進め方: auto / 作業ツリー: /work/ai-plugins/.worktrees/sprint/lflow3-3

• 要求と受け入れ条件 — 2026-11-05 07:51
• 作業場所の用意 — 2026-11-06 22:35
• 設計
• ドキュメント再構成 — 2026-11-05 08:07
• ドキュメントレビュー
• 計画 — 2026-11-06 22:35
• 実装 — 2026-11-06 22:36
• 構造改善 — 2026-11-07 08:48
• 実装レビュー — 2026-11-07 11:22
• 完了判定 — 2026-11-06 23:22
• Pull Request — 2026-11-07 05:06
• 確定仕様化 — 2026-11-08 10:16
• 後片付け — 2026-11-08 10:50
• デプロイ
• リリース後テスト — 2026-11-08 10:45
• 振り返り — 2026-11-08 10:45
• 棚卸し — 2026-11-08 10:50

人の判断待ち（開発ループ lflow2）

• 判定: not_follow（承認ゲート 1）
• 理由: Value 1（確かめていないものを済んだと記録しない）: PR 自身のテスト表で、要求の検査（requirements-check）が exit 1 で止まっている。仕様のコピー（issues/issue-2510-requirements.md）の 8 節（何が起きたか・原因・影響・直し方の案・受け入れ条件 ほか）が課題の本文と食い違うまま、作り直しと再実行を済ませずに設計の承認へ出している／Value 2（承認を求めるときは判断の材料を先に集める）・Value 3（承認資料の正しさ）: 設計はこのコピーの受け入れ条件 1〜13 と要求の前提 1・5・7・9 を根拠に組まれている。コピーが本文と食い違ううちは、承認資料が正しいとは言えない／Value 8（正本を 1 か所に置き、写さずに指す）: 要求の正本は 並列の計画: オーケストレーターからレーンへの指示が伝わらない（直して出し直すの指摘が設計に渡らない、ほか） #2510 の本文で、PR の中の写しがそれと揃っていない／設計の中身は Mission と Vision に沿う。決定 1〜11 は根本原因の場所で直し（Value 7）、判定を git の差分とスクリプトに寄せ（Value 5）、決めた理由を残している（Value 8）。一方、6 ファイル・1019 行の追加は、人が 1 回の承認で読み切れる量（Value 2）として大きい／必ず人の承認が要る操作には当たらない。秘密・認証・利用者のデータ・戻せない操作・他のリポジトリへの公開・.ndf の書き換え・GitHub Issues 以外への書き込み・配布物の取得元の変更を含まず、前のループの記録へも loop answer で答えを当てるだけである
• 根拠の項目: Value 1, Value 2, Value 3, Value 8, Value 7, Value 5, Mission, Vision
• 設計 Pull Request: 開発ループと並列の計画: 人の答え（出し直しの指摘・承認・前のループの待ち）を、読んで動く側へ確実に届ける（#2510） #2538
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.21/scripts/sprint-state.py loop answer lflow2 2510 --approved|--rejected|--revise --note <指摘ファイル>

振り返り: #2796 (comment)