Factory の開発ループ: 再開したジョブへ変えた予算を届ける #2405

依頼（原文）

何をするか

Factory の開発ループで、承認待ち・利用上限待ちの間に画面で予算を変えても、再開したジョブ（START=resume）は古い予算のまま進む。再開したジョブへ変えた予算を届ける。

経緯

• スプリント lfactory2-3 の検査で、クロスレビューが上限（4 ラウンド）に達して後へ回した指摘（スプリント lfactory2-3 #2397 、factory/api/src/runs/control.ts:400、major）
• 今の NDF には再開したループへ予算を渡す口が無く、上書きできるのはループを始めるときの --budget-* だけ（NDF Factory: 開発ループ・並行する実行の調整・ジョブの中の区切りと利用上限・手元のランナーの同時実行数・ループの見え方を定義する #2347 の設計の決定 14）

決めること

• ランナーが再開の前に NDF の loop start --budget-* を打ち直すか、再開の指示へ予算を足すか

受け入れ条件

• 承認待ちの間に予算を変えたループを再開すると、NDF の止まる条件の判定が新しい予算で行われる（テストで確かめる）

（書き手: 起票者、日付: 2026-11-02。スプリント lfactory2-3 の検査で後へ回した指摘を、AI が起票の記録として書いた本文である。利用者の指示の原文は含まない）

起票者の推定

依頼の全文が起票者の文であるため、題と本文の条件をすべてここに並べる。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

• Factory の利用者が、承認待ちや利用上限待ちで止まっている開発ループの予算を画面で変えたとき、ループが再開した後に NDF がその予算で止まるかを判定する状態にする
• 画面に出る「予算の残り」と、NDF が止まる判定に使う予算を食い違わせない

前提

• 前提 1: 周回の間（between_laps）に変えた予算は、次の周回のジョブ（START=loop）の指示の LOOP_BUDGET から --budget-* として NDF へ渡っており、この課題では変えない。根拠: factory/runner/src/runtime.ts の loopPrompt が LOOP_BUDGET を --budget-<単位> <値> へ並べ、factory/runner/src/loop.test.ts の「--budget-laps 3 --budget-usd 60」の例がそれを確かめている
• 前提 2: NDF のループの記録（.ndf/loop/<名>/loop.json）は既にあるループにも loop start <名> --budget-* で予算を上書きでき、変わったときだけ予算の履歴（budget_history）に 1 行足す（plugins/ndf/scripts/lib/sprint_loop.py の apply_budget）。ただし既にあるループへの loop start は、止まった記録を解く手続き（承認ゲート 2 の答えの処理・周回の締め・予算超過の判定し直し）も同時に行う（同じファイルの cmd_start・resume_stopped）
• 前提 3: NDF の止まる条件の判定は、周回を締めるときにループの記録の予算と締めた周回の消費の和を比べる（plugins/ndf/scripts/lib/sprint_loop_record.py の予算の判定）。したがって conductor を起こす前にループの記録の予算が新しい値になっていれば、その後の判定は新しい予算で行われる
• 前提 4: 実行ジョブの指示の契約（factory/contracts/schemas/run-job-instruction.schema.json）は、ループの実行の resume に LOOP_BUDGET を載せることを既に許している。契約の形は変えない
• 前提 5: 予算をループの記録へ反映できなかったときは、conductor を起こさずにジョブを失敗で終える。古い予算のまま進めると、この課題が直す食い違いをそのまま残すためである。人の判断待ちへの答えを書けなかったとき（factory/runner/src/runtime.ts の answerLoop）と同じ扱いにする

対象範囲

含む:

• 承認の答えによる再開（APPROVAL_REQUEST_ID のある START=resume）で、Factory のループの今の予算を NDF のループの記録へ反映すること
• 利用上限の後の再開（APPROVAL_REQUEST_ID の無い START=resume）で、同じく反映すること
• 反映を確かめる自動テスト（Factory のサービスとランナー、必要なら NDF のスクリプト）
• 確定仕様（docs/specifications/ndf-factory-dev-loops.md ほか）の予算の変更の記述を、再開のジョブにも届くことに合わせる

含まない:

• 動いているジョブ（running）の途中で予算を届けること。変えた予算は次に作るジョブ（再開か次の周回）で届く
• 画面で予算の単位を空にした（制限を外した）ときに、NDF の予算を既定へ戻すこと。今の NDF の --budget-* は値の上書きだけを持ち、外す口が無い。周回のジョブでも同じ制約があり、別の課題で扱う
• 止まった（stopped）・取り消した（cancelled）ループの再開。決定 14 のとおり終わりの状態であり、続きは新しいループで始める
• 予算の変更の画面と API（updateBudget）の形の変更

ドメインイベント

E4 と人の判断待ちへの答えの書き込み（既存）の順序は、どちらが先でも結果が同じになることを設計で確かめる（未決 2）。

用語

受け入れ条件

• 1. 承認待ち（awaiting_approval）のループの予算を変えた後に、承認の答えで作られた再開のジョブでは、conductor を起こす前に NDF のループの記録の予算が変えた値になっている（ランナーのテストで、記録の予算を読んで確かめる）
• 2. 利用上限待ち（awaiting_reset）の実行のループの予算を変えた後に、リセット時刻の後に作られた再開のジョブでも、受け入れ条件 1 と同じになる
• 3. 予算を下げて再開した場合、締めた周回の消費の和が新しい予算以上になった周回の締めで、NDF が budget_<単位> の止まる条件を記録する（例: 費用の予算を 60 から 40 へ下げ、消費の和 50 で締めると budget_usd で止まる）
• 4. 予算を上げて再開した場合、古い予算なら止まっていた消費の和でも NDF は止まる条件を記録しない（例: 費用の予算を 40 から 100 へ上げ、消費の和 50 で締めると止まらない）
• 5. 再開のジョブの指示に載る予算は、そのジョブを作った時点の Factory のループの予算である（サービスのテストで、requestResume と resumeAfterReset の両方の指示に LOOP_BUDGET が載ることを確かめる）
• 6. 予算が変わっていないときは、予算の履歴に行を足さない。変わったときは 1 行だけ足す
• 7. 予算を反映する操作は、ループの記録の予算と予算の履歴のほかを変えない。止まった記録の解除・周回の締め・承認ゲート 2 の答えの処理は、conductor が前回の続きから進めるときに既存のとおり 1 回だけ起きる
• 8. 予算をどの単位も宣言していないループの再開では、ループの記録の予算を変えない
• 9. ループに属さない実行の再開のジョブは、指示も振る舞いも変わらない（LOOP_BUDGET を載せない）
• 10. ループの記録へ予算を反映できなかったとき、ランナーは conductor を起こさずにジョブを失敗で終え、理由をジョブの出力に残す

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-04 08:06
• 作業場所の用意
• 設計 — 2026-11-04 08:09
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-11-04 08:15
• ドキュメントレビュー
• 計画
• 実装
• 構造改善
• 実装レビュー
• 完了判定
• Pull Request — 2026-11-04 14:37
• 確定仕様化 — 2026-11-04 14:30
• 後片付け — 2026-11-04 15:02
• 配布
• 体裁レビュー
• リリース後テスト — 2026-11-04 14:58
• 振り返り — 2026-11-04 14:58
• 棚卸し — 2026-11-04 15:02

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

• 判定: unknown（承認ゲート 1）
• 理由: 設計の中身は MVV に沿っている。再開のジョブへ変更後の予算を届ける。予算の上書きは既存の apply_budget の 1 か所に寄せる（Value 7）。決まった手順は conductor に任せず、ランナーが終了コードで成否を決める（Value 5）。どれも Mission と Vision の「人の判断が要る所だけで止まる」開発ループの正しさに寄与する／要求の検査（requirements-check）が終了コード 2 で止まった。対象の issues/issue-2405-requirements.md は PR に含まれているのに読めず、原因は確認されていない。要求と受け入れ条件が検査を通るかは材料から決められない。Value 1 は自動テストで守り、確かめていないものを済んだと扱わないことを求める。そのため、検査が止まったまま関門を自動で通すかは人へ戻す／決定 6 は、副命令が無い NDF（終了コード 2）では反映せずに続ける。版を固定した既存の実行の再開を止めない判断で、共通原則の「人を守る」と Value 1 に沿う。ただし argparse は値の誤りでも終了コード 2 を返すため、渡した予算の値の誤りも「副命令が無い」と読まれて素通りしうる。この点は設計の確認事項として残る／秘密・認証・利用者のデータ・戻せない操作・他のリポジトリへの公開・.ndf/ や CLAUDE.md の書き換えには当たらない（C1〜C8）。配布物の取得元と版の規則も変えない（P1）。API と画面の間で操作の差は生まない（スプリント Value 4）／決定 6 の確認コマンドは実行して確かめてある（Value 4）。未確認のまま残ること（実物の通し、古い版の実行の数）は表に明記してある（Value 8）。配布の後に確かめる項目は判定の対象にしない
• 根拠の項目: Mission, Vision, Value 1, Value 4, Value 5, Value 7, Value 8, C1, C3, C4, C5, C7, P1, スプリント Value 4
• 設計 Pull Request: Factory の開発ループ: 承認待ち・利用上限待ちの間に変えた予算で、再開した後の止まる判定を行う（#2405） #2478
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.15/scripts/sprint-state.py loop answer lfactory3 2405 --approved|--rejected|--revise --note <指摘ファイル>

振り返り: #2490 (comment)