[takemi-ohama]

ndf v10.27.24 のリリース（prod）。対象の plugin: ndf

含む PR

• 設計の承認に「承認」と答えると、その設計の PR がマージされる（#2507 を実装する（スプリント lflow2-7） #2542）（スプリント lflow2-7 #2543）
• 開発ループの周回の境で、承認済みの設計の PR がマージし直される（#2507 を実装する（スプリント lflow2-7） #2542）（スプリント lflow2-7 #2543）
• 承認に答えた後、その時点の整理結果が一覧で表示される（#2507 を実装する（スプリント lflow2-7） #2542）（スプリント lflow2-7 #2543）
• 承認の答えの --by 引数が契約に含まれ、検査の対象になる（#2507 を実装する（スプリント lflow2-7） #2542）（スプリント lflow2-7 #2543）
• 差分の棚卸しで見積の無い経路に出る Issue は、起点より後に作られたものだけになる（#2315 を実装する（スプリント lflow2-8） #2546）（スプリント lflow2-8 #2547）
• 差分の棚卸しの各行に、プランの進行の記録から写した所要秒数・費用（ドル）・言語モデルが載る（#2315 を実装する（スプリント lflow2-8） #2546）（スプリント lflow2-8 #2547）
• depth compare で、所要秒数などの中央値を基準と比べられる（#2315 を実装する（スプリント lflow2-8） #2546）（スプリント lflow2-8 #2547）
• スプリントのまとめでは、プランの深さを記録するステップが、プランの進行の記録（--progress）と開発ループ・周回の番号（--loop・--lap）を受け取る（#2315 を実装する（スプリント lflow2-8） #2546）（スプリント lflow2-8 #2547）
• NDF の --budget-* に default を渡すと、その単位の予算がリポジトリの予算の既定に戻ります（#2406 を実装する（スプリント lfactory3-8） #2559）（スプリント lfactory3-8 #2561）
• Factory でループの予算の単位を空にすると、次のジョブからその単位にリポジトリの既定が使われます（#2406 を実装する（スプリント lfactory3-8） #2559）（スプリント lfactory3-8 #2561）
• Factory のループの画面では、空の予算の単位が「リポジトリの既定」と表示されます（#2406 を実装する（スプリント lfactory3-8） #2559）（スプリント lfactory3-8 #2561）
• 既定へ戻せない版では、Factory は予算の単位を空にする変更を受け付けず、画面に理由を表示します（#2406 を実装する（スプリント lfactory3-8） #2559）（スプリント lfactory3-8 #2561）
• リポジトリの設定で本番のブランチ（production_branch）を宣言していなくても、作業用の worktree をまだ作っていない段階で、リポジトリの既定ブランチを本番のブランチとして実行計画を組む（#2097 を実装する（スプリント lroot3-14） #2562）（スプリント lroot3-14 #2565）
• ndf の design で、設計の判断を下す前に外部の調査を行います。これが手順 2 になり、以降の手順は番号が 1 つずつ繰り下がります（#2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564）（スプリント lflow2-9 #2574）
• 設計文書のテンプレートに「外部の調査」の節があります。自前で作ると決めた事項には、比べた既存の候補を書く行があります（#2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564）（スプリント lflow2-9 #2574）
• 自前で作ると決めた事項に比べた候補が書かれていない設計文書は、ndf の設計の検査で指摘されます（#2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564）（スプリント lflow2-9 #2574）
• スプリントの設計の工程では、外部の調査の検査、指摘の修正、修正後の再検査が順に自動で実行されます（#2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564）（スプリント lflow2-9 #2574）
• ndf の pr-review で、レビューの観点に外部の調査の確認が入る（#2519 の 2 つ目: pr-review と cross-review に外部の調査の観点を足す（スプリント lflow2-9） #2572）（スプリント lflow2-9 #2574）
• ndf の cross-review で、設計 PR と実装 PR を見る担当へ外部の調査の確認の観点が渡る（#2519 の 2 つ目: pr-review と cross-review に外部の調査の観点を足す（スプリント lflow2-9） #2572）（スプリント lflow2-9 #2574）
• ndf の cross-review で、既定の分類を外すレビューのプロファイルを選んでも、外部の調査の確認の観点は残る（#2519 の 2 つ目: pr-review と cross-review に外部の調査の観点を足す（スプリント lflow2-9） #2572）（スプリント lflow2-9 #2574）
• ndf プラグインの開発ループは、人が送った停止のときだけ止める指示を置く（#2474 を実装する（スプリント lroot3-17） #2580）（スプリント lroot3-17 #2581）

チェックの結果

• check-doc-staleness: pass（documented skill counts and versions are up to date）
• validate-runtime-plugins: pass（runtime plugin validation passed）

🤖 Generated with Claude Code

[takemi-ohama]

配布の記録

段階: 本番（承認ゲート 2 の承認の後、2026-11-06 04:11 に ndf--v10.27.24 を出した）
版: 10.27.21 → 10.27.24（タグ ndf--v10.27.24。直前はタグ ndf--v10.27.21）
スプリント: PR #2403 / #2404 / #2410 / #2412 / #2538 / #2542 / #2543 / #2545 / #2546 / #2547 / #2551 / #2556 / #2558 / #2559 / #2561 / #2562 / #2564 / #2565 / #2570 / #2572 / #2573 / #2574 / #2580 / #2581

[takemi-ohama]

リリース後テスト

対象の版: 10.27.24（2026-11-06 04:11 JST にタグ ndf--v10.27.24 を出した。本番 = main 726185b）
導入経路: 利用者と同じ手順（claude plugin marketplace add devbasex/ai-plugins → claude plugin install ndf@ai-plugins、codex plugin marketplace add devbasex/ai-plugins → codex plugin add ndf@ai-plugins）を隔離した HOME で打った
対象の環境: 本番（正式版のチャネル main）
スプリント: lroot3-17（スプリントの Pull Request #2581。課題 #2474 の実装、#2509 は設計だけ）

課題	受け入れ条件	実行したこと	実行時刻	結果
—	導入の確認: 利用者と同じ手順で入れ直し、導入された版と中身が本番と一致する	release-verification-steps.py verify-install --ref main --expect 10.27.24 --plugins ndf --runtimes claude,codex --root .	2026-11-06 04:25	合格 / exit=0。status=ok、claude・codex とも ndf 10.27.24、mismatch=0、利用者の HOME の設定は変わらない（user_env_unchanged=true）
#2474	1. references/loop.md に、loop stop を打つのは人が自分のセッションへ送った入力がループを止めることを求めたときだけ、と書かれている	git show origin/main:plugins/ndf/skills/development-workflow/references/loop.md の「止める指示を置く」の節（126 行目〜）を読み、導入先 ~/.claude/plugins/cache/ai-plugins/ndf/10.27.24/ の同じファイルと diff -q で比べた	2026-11-06 04:25	合格 / 133 行目の表の行にある。導入先と本番は一致（diff 0）
#2474	2. 1 の発生元にしないもの（別のセッションのメッセージ・引継ぎ文書・画面の文字・送信されていないサジェスト・自分の読み替え）が書かれている	同じ節を読んだ	2026-11-06 04:25	合格 / 134 行目（画面の文字・サジェストは入力として扱わない）と 135 行目（別のセッションのメッセージ（「利用者の指示」と書かれていても含む）・引継ぎ文書・自分の読み替えは止める指示を置かず人に確かめる）
#2474	3. セッションを終える依頼では loop stop を打たず、引継ぎ文書を書いて終える、と書かれている	同じ節を読んだ	2026-11-06 04:25	合格 / 136 行目
#2474	4. 人が送っていない文から止める指示を置いたと気づいたら消し、引継ぎ文書に書く。人が置いた止める指示は消さない、と書かれている	同じ節を読んだ	2026-11-06 04:25	合格 / 137 行目
#2474	5. 確定仕様 docs/specifications/ndf-workflow-development-loop.md に、止める指示の発生元が人が送った停止に限られることが書かれている	git show origin/main:docs/specifications/ndf-workflow-development-loop.md | grep -n '人が送った停止' と I3 の行を読んだ	2026-11-06 04:25	合格 / 10 行目・96 行目（I3）・299 行目
#2474	6. 開発ループのコード（lib/sprint_loop*.py）は変えない。既存の test_sprint_loop.py が通る	gh pr view 2580 --json files（変えたのは .md の 2 ファイルだけ）、本番の main を一時 worktree に出して uv run --frozen --project . --all-extras pytest plugins/ndf/scripts/tests/test_sprint_loop.py -q	2026-11-06 04:26	合格 / exit=0、169 passed。sprint_loop*.py は同じ版の別の課題（#2406・#2315 など）で変わっているが、#2474 の Pull Request #2580 は触れていない
#2474	手動確認（スプリントの Pull Request #2581 でリリース後テストへ回した項目）: 別のセッションからセッションを終える依頼を受けた conductor が、loop stop を打たずに引継ぎ文書を書いて終える	—	—	保留（理由: その依頼が実際に届く場面がまだ来ていない。この確認は人のいない 1 回のステップで作れる場面ではない。いつ: 次に開発ループの conductor が別のセッションからセッションを終える依頼を受けたとき、.ndf/loop/<名>/stop が置かれず引継ぎ文書が書かれたかを、振り返りで確かめる）
#2509	1. 状態の一覧が 0 以外で終わった回の観測の後も、各レーンの状態は変わらない	—	—	保留（理由: このスプリントで終わったのは設計（Pull Request #2579。リリースの Pull Request のマージの後、2026-11-06 03:59 JST にマージ）だけで、実装は v10.27.24 に入っていない。git log ndf--v10.27.21..origin/main に #2509 の変更は 0 件。いつ: 実装を出す版のリリース後テスト）
#2509	2. 一覧が 0 以外で終わる間、parallel.py run は finished を返さず、耐久の記録にも残らない	—	—	保留（理由: 同上。実装が未リリース。いつ: 実装を出す版のリリース後テスト）
#2509	3. 一覧が 0 で終わり起動済みのレーンの行が無いときは止まったと読む（既存の振る舞い）	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	4. 一覧の失敗が停滞の区切りより長く続くと、問いを 1 件出す	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	5. deps.require() で起動し直したスクリプトの子プロセスの env に UV_PROJECT_ENVIRONMENT が無い	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	6. 子プロセスで別のプロジェクトの uv run を打っても、共有の環境の pyvenv.cfg が変わらず import psutil が通る	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	7. ラッパーが起動する子の claude の環境変数に、共有の環境を指す UV_PROJECT_ENVIRONMENT が無い	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	8. 利用者が自分で設定した UV_PROJECT_ENVIRONMENT は、子プロセスと子の claude へそのまま渡る	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	9. 1〜8 の回帰テストが plugins/ndf/scripts/tests/ にあり、変更前は落ち変更後は通る	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）
#2509	10. 起動し直した後の子プロセスが別のグループのパッケージを要るとき、自分で起動し直して動く（test_deps.py が通る）	—	—	保留（理由: 同上。いつ: 実装を出す版のリリース後テスト）

マージ前に未検証として残した項目: スプリントの Pull Request #2581 の「手動確認」の 1 件だけ（上の表の保留の行）。ほかに完了報告の「未検証の項目」は無い。

合否: #2474 は合格（受け入れ条件 6 件すべて合格。手動確認 1 件は保留）。#2509 は保留（実装が未リリースのため 10 件すべて保留）。導入の確認は合格
起票したもの: なし

🤖 Generated with Claude Code

[takemi-ohama]

リリース後テスト

対象の版: 10.27.24（2026-11-06 04:11 JST にタグ ndf--v10.27.24 を出した。本番 = main 726185b）
導入経路: 利用者と同じ手順（claude plugin marketplace add devbasex/ai-plugins → claude plugin install ndf@ai-plugins、codex plugin marketplace add devbasex/ai-plugins → codex plugin add ndf@ai-plugins）を隔離した HOME で打った
対象の環境: 本番（正式版のチャネル main）。Factory のサービスは配布の対象に入っていないため、Factory の側は main 726185b のコードのテストで確かめた
スプリント: lfactory3-8（スプリントの Pull Request #2561、実装 #2559。課題 #2406「Factory の開発ループで予算の欄を空にするとリポジトリの既定の予算へ戻す」）

NDF の CLI の確かめ方: 導入先 ~/.claude/plugins/cache/ai-plugins/ndf/10.27.24/scripts/sprint-state.py を、本番の .ndf/ を写した一時のリポジトリ（.ndf/pace.json の loop.budget を laps=5,usd=40 にし、hours は宣言しない）で打ち、.ndf/loop/<名前>/loop.json の budget と budget_history を読んだ。

課題	受け入れ条件	実行したこと	実行時刻	結果
—	導入の確認: 利用者と同じ手順で入れ直し、導入された版と中身が本番と一致する	release-verification-steps.py verify-install --ref main --expect 10.27.24 --plugins ndf --runtimes claude,codex --root .	2026-11-06 04:28	合格 / exit=0。status=ok、claude・codex とも ndf 10.27.24、mismatch=0、利用者の HOME の設定は変わらない（user_env_unchanged=true）
#2406	1. 費用の予算 10 USD で始めたループの費用の欄を空にすると、次の周回の後、ループの記録の費用の予算がリポジトリの loop.budget.usd になる	NDF: sprint-state.py loop start rv1 --budget-usd 10 の後に loop start rv1 --budget-usd default。Factory: npx vitest run api/src/runs/loops.test.ts runner/src/loop.test.ts web/src/pages/loops.test.tsx contracts/tests/definitions.test.ts（「空にした単位を次の周回の指示へ default として載せる」「default もそのまま --budget-<単位> default で渡す」）	2026-11-06 04:29	合格 / exit=0。記録の budget.usd が 10.0 → 40（宣言の値）。Factory は指示が LOOP_BUDGET=laps=default,usd=default,hours=default になり契約の検査を通る（4 ファイル 158 件が通った）
#2406	2. 締めた周回の費用の和が 15 USD（古い予算 10 以上・既定未満）のとき、budget_usd の止まる条件を記録しない	pytest plugins/ndf/scripts/tests/test_sprint_loop.py -q -k "budget or default"（test_budget_default_returns_the_unit_to_the_repository_default_and_judges_with_it：費用 15 の周回の後 stop が無い）	2026-11-06 04:29	合格 / exit=0（15 件が通った）
#2406	3. loop.budget に宣言が無い単位を既定へ戻すと、組み込みの既定（周回 3・費用 60・時間 24）になる	NDF: loop start rv1 --budget-hours 5 の後に loop start rv1 --budget-hours default（hours は宣言なし）。上の pytest の test_budget_default_uses_builtin_defaults_for_undeclared_units	2026-11-06 04:29	合格 / exit=0。budget.hours が 5.0 → 24
#2406	4. 承認待ちのループの単位を空にした後、承認の答えで作られた再開のジョブでも記録の予算が既定の値になる	—	—	保留（理由: 再開のジョブへ予算を届ける経路は #2405「再開したジョブへ変えた予算を届ける」の範囲で、#2405 は未マージ（OPEN）。実装 #2559 の「設計と違う点」で持ち越した。#2405 のリリース後テストで確かめる）
#2406	5. 既定へ戻す指示で予算が変わったときは履歴に 1 行だけ足し、変わらないとき（既に既定・新しいループ）は足さない	NDF: 上の rv1 で --budget-usd default を 2 回続けて打った。新しいループ loop start rv2 --budget-usd default	2026-11-06 04:29	合格 / exit=0。rv1 の履歴は 1 回目で 1 行増え、2 回目は増えない。rv2 は予算 laps=5,usd=40,hours=24・履歴 0 行
#2406	6. 予算の単位が空のループは、一覧と詳細の予算の残りにリポジトリの既定に従う文言を出し、「掛けない」と出さない。文言は翻訳のファイルに置く	main の factory/web/src/i18n/ja.json を読んだ（followsDefault「{{units}}はリポジトリの既定」・budgetPlaceholder「空ならリポジトリの既定」）。上の vitest の web/src/pages/loops.test.tsx（一覧に「掛けない」が無いことを確かめる）	2026-11-06 04:29	合格 / exit=0
#2406	7. 既定へ戻す手段の無い版では、値のあった単位を空にする変更を画面と API で断り理由を出す。値の変更・空のままは断らない	上の vitest の api/src/runs/loops.test.ts（「既定へ戻せない版では…409 で断り、値の変更と空のままの単位は受ける」）と web/src/pages/loops.test.tsx（「断られると、版を差し込んだ理由を予算の欄に出す」）。文言 budgetResetUnsupported を ja.json で読んだ	2026-11-06 04:29	合格 / exit=0
#2406	8. 3 つの単位すべてに値のあるループの周回と再開は、指示・引数・記録の予算がこれまでと変わらない	上の vitest（api/src/runs/loops.test.ts の「予算を変えると次の周回の指示へ写り…」、runner/src/loop.test.ts の「宣言した予算で起動する」）と上の pytest	2026-11-06 04:29	合格 / exit=0。再開のジョブは #2405 が未マージで予算を載せる経路が無く、これまでと同じ（変わっていない）
#2406	9. 予算の欄をすべて空にして始めたループは、これまでどおり NDF の既定の予算で動く	NDF: 予算の引数なしで loop start rv3	2026-11-06 04:29	合格 / exit=0。予算 laps=5,usd=40,hours=24（宣言と組み込みの既定）・履歴 0 行
#2406	10. 「既定へ戻す」の値が数でも default でもないとき、記録を変えずに引数の誤りとして断る	NDF: loop start rv1 --budget-usd abc	2026-11-06 04:29	合格 / exit=2。数か default を渡す: 'abc' を出し、rv1 の予算と履歴は変わらない
#2406	手動確認（スプリントの Pull Request #2561 でリリース後テストへ回した）: Factory のループの費用の予算を入れて 1 周回した後に欄を空にし、次の周回の後のループの記録の予算と予算の履歴を見る	—	—	保留（理由: 動いている Factory のサービスでループを 1 周回すことが、このステップの環境（CLI だけ・人が見ていない）ではできない。Factory の配布は ndf の配布に含まれず、配布の記録にも Factory の反映の記録が無い。NDF の側は上の 1・5 で、Factory の指示の組み立ては上の vitest で確かめた。Factory の本番へ反映した後に、人が画面で 1 周回して確かめる）
#2406	マージ前の未検証（実装 #2559 の「設計と違う点」）: loop budget --budget-usd default の副命令と、.ndf/pace.json を読めないときに終了コード 1 で断るテスト（設計のテストの I2）	—	—	保留（理由: 副命令 loop budget は #2405 で足すもので、まだ無い。#2405 のリリース後テストで確かめる）

合否: 保留（12 行中 9 行が合格・3 行が保留・不合格 0。受け入れ条件 10 件のうち 9 件が合格、4. は #2405 待ちで保留）
起票したもの: なし（保留の 2 行は既存の #2405 が持つ）

[takemi-ohama]

振り返り（2026-11-06）

対象: スプリント lroot3-17 — issue #2474 / issue #2509 / スプリントの PR #2581 / 配布の PR #2586（ndf v10.27.24）

開発ループ lroot3 の周回 17 で、2 件を選んだ。#2474（開発ループが止める指示を置くのを、人が自分のセッションへ送った停止に限る）は、手順書 references/loop.md と確定仕様を直して v10.27.24 で出した。#2509（並列の計画で、利用者の uv run が NDF の共有の Python 環境を作り直す）は、設計 Pull Request #2579 が承認ゲート 1 で承認されたが、実装はこのスプリントに入らなかった（下の「何が起きたか」）。

何が起きたか

観点	事実	記録
範囲	#2509 の実装のプランが流されず、#2474 だけで配布まで進んだ。設計の結果を読むステップ（16:59 UTC）が develop を読んだ時点で、#2509 の設計 Pull Request #2579 はまだマージされていなかった（マージは 18:59 UTC）。ステップは「設計の結果を読めなかった設計の課題: #2509（今の振る舞いで流す）」を ok で返した	.ndf/loop/lroot3/lap-17/sprint/3-design-results-state/01-design-results.out、lap-17/done-2.json
手戻り（#2509 の設計）	要求の検査（requirements-check）が終了コード 2（要求の文書が無い）で止まった。設計の cross-review は上限の 3 ラウンドに達した（指摘 3 件、すべて修正済み、未解決 0）。MVV 判定は「判定を読めない」で、利用者が承認した。費用 $7.008・1,718 秒	lap-17/sprint/1-design-2509-state/report.md
手戻り（#2474）	前の周回で、承認ゲート 1 で 1 回「直して出し直す」と答えた（判定を読めない）。周回 6 は要求の検査の失敗で 1 周回を使った（#2507 の本文）。この周回の実装は費用 $1.066・2,470 秒、スプリントの検査は cross-review 2 ラウンド・指摘 1 件（修正済み）・$0.734・1,122 秒	.ndf/loop/lroot3/laps.md、lap-17/sprint/5-impl-2474-state/report.md、6-check-state/report.md
見落とし	#2474 の受け入れ条件 6 件はリリース後テストで合格。手動確認 1 件（別のセッションからセッションを終える依頼を受けた conductor が loop stop を打たない）は、その場面がまだ来ていないため保留。#2509 の 10 件は実装が未リリースのため保留	リリース後テストの記録
工程	#2509 は設計の後、実装・検査・配布を通っていない。#2474 は実装 → Pull Request → 検査 → 配布 → リリース後テストを通った	課題の本文の工程表

要求の検査の終了コード 2 は既知の形である。 要求の文書を書く前に検査が走り、MVV 判定が「判定を読めない」になる（#1502）。このスプリントでも #2509 で起き、MVV 判定を読めない承認ゲートになった。新しい起票はしない。

検査の記録と閾値

check-trigger.py stats --root /work/ai-plugins（10.27.21）の集計:

項目	値
トリガーの評価（check-trigger.py eval）の回数	0
トリガーが立った回数	0
検査の回数（すべて Pull Request を対象）	66
うち結果が failed の回	38
検査の後に逃げた不具合（流出不具合）の記録	0
このスプリントの検査（PR #2581）	2 ラウンド・指摘 1 件・修正 1 件・見送り 0 件

閾値（.ndf/pace.json の triggers: 点数 10・変更量 3,000 行・流出不具合 1・期限 24 時間）は変えない。 理由は 2 つある。

• 評価の記録が 0 件で、閾値を動かす材料が無い。 このリポジトリのループは進め方 auto で動いており、auto はトリガーを評価しない（references/pace.md の 163 行目）。スプリントの Pull Request ごとに検査が必ず 1 回入るため、閾値はいまの進め方では使われていない
• 流出不具合の 0 件は「逃げた不具合が無い」ことを示さない。 流出不具合は、直すプランを --escape-of <持ち込んだ PR> で流したときだけ記録される。66 回の検査に結び付いた記録は 0 件で、記録の経路が使われたかは未確認である。閾値の見直しの材料にするには、まず記録が残ることを確かめる必要がある

failed の 38 回は、同じ Pull Request の検査が収束せずに止まり、打ち直して merged になった回を含む（例: PR #2452 は failed 5 回の後に merged）。打ち直しの回数は閾値ではなく、#2343（上限と再試行の方針を 1 つの宣言に集める）の範囲である。

context window の大きさ

conductor のセッションの識別子が記録に無く、skill-stats --agents では測っていない（未計測）。代わりに、各フェーズのレポートが記録した費用と時間を載せる。

フェーズ	結果	秒	費用	worker
設計 #2509	関門	1,718	$7.008	修正 6・判断 2
設計の結果を読む	完了	6	$0.000	0
スプリントのブランチ	完了	6	$0.000	0
実装 #2474	完了	2,470	$1.066	修正 3・判断 1
検査	完了	1,122	$0.734	修正 2・判断 0
配布	完了	240	$0.000	0

目印（束ねる候補・割る候補・worker を使いすぎ）は測っていないため判断しない。費用の 80% は、実装に使われなかった #2509 の設計である。

用語集の変化

glossary.py diff（PR #2581 の base c8dceba8 → merge db6a8b2d）: 変化は無い。

承認ゲートの差し戻し

gate-rejections.py count（#2509・#2474・PR #2581・#2579・#2501、状態ファイル lap-17/state.json）: 関門 1 が 0 件・関門 2 が 0 件。

周回の記録（laps.md）には、#2474 の承認ゲート 1 で「直して出し直す」の答えが 1 件ある。開発ループの答えが差し戻しの記録へ入らない形で、既知の #2400 に当たる。

MVV を見直すか

project-mvv.py signals（版 5）:

兆候	件数	閾値
覆し	11	3
判定できない	0（続けて 0 回）	5（続けて 3 回）
流出不具合	0	3

覆しが閾値を超えた。内訳（~/.local/state/ndf/project-mvv-signals.jsonl の版 5 の行）は、MVV 判定が「判定を読めない（unknown）」だった承認ゲート 1 を利用者が通したものが 9 件、「従わない（not_follow）」を利用者が通したものが 2 件（関門 1・関門 2 が 1 件ずつ）である。

改訂するかは利用者の判断を待つ。 この工程は人に問えない実行で、改訂の承認（C7）を AI が決めない。判断の材料:

• 9 件は MVV の中身ではなく、判定を読めなかったこと（mvv-gate: 設計のプランで、設計の前に打った requirements-check の exit 2 を材料に読み、関門 1 の助言が unknown になる #1502 の要求の検査の終了コード 2 と、判定の出力の読み取り）から来ている。MVV の文言を変えても減らない見込みで、直す場所は判定の側（mvv-gate: 設計のプランで、設計の前に打った requirements-check の exit 2 を材料に読み、関門 1 の助言が unknown になる #1502・結果の契約をそろえ、失敗・未収束・判定できないを ok で返す経路を無くす #2337）である
• 2 件の「従わない」を通した判断は、MVV の Value の書き方が実態とずれている兆候の可能性がある。改訂の要否はこの 2 件の中身で決まる

推奨: 9 件は判定の側の不具合として扱い、MVV の改訂の材料から外す。2 件の中身を見て、改訂するかを決める。

次に変えること

変えること	落とし先	状態
承認した設計の結果を読めないとき、その課題の実装を外したまま ok で配布へ進まない	次の変更で試すこと（起票）	#2596 として起票
承認した設計 Pull Request を、承認の答えと同時にマージする（上の不具合の引き金）	次の変更で試すこと（起票済み）	既存の #2507
検査のトリガーの閾値	変えない	評価の記録が 0 件で材料が無い（上の「検査の記録と閾値」）
MVV の改訂	利用者の判断	上の「MVV を見直すか」

途中で起票した課題

番号	何を見つけたか	見つけた場面
#2510	並列の計画で、オーケストレーターからレーンへの指示が伝わらない	#2474 の設計（PR #2501）
#2596	承認した設計の結果を読めないと、その課題の実装を外したまま ok で配布へ進む	この振り返り

issue-file.py by-origin（由来 7 件・上流リポジトリ込み）で集めた課題は #2509・#2474・#2510 の 3 件で、取りこぼしは上の #2596 の 1 件だった。

[takemi-ohama]

リリース後テスト

対象の版: ndf 10.27.24（本番。タグ ndf--v10.27.24、main 726185bc。2026-11-06 04:11 JST に配布）
導入経路: 利用者と同じ手順（隔離した HOME で claude plugin marketplace add devbasex/ai-plugins → claude plugin install ndf@ai-plugins、Codex は codex plugin marketplace add → codex plugin add ndf@ai-plugins）。受け入れ条件は、導入した版と一致を確かめた main 726185bc の中身で確かめた
対象にしたスプリント: lflow2-9（#2519。実装 PR #2564・#2572、スプリント PR #2574）

課題	受け入れ条件	実行したこと	実行時刻	結果
—	導入の確認: 利用者と同じ手順で入れ直し、版と中身を確かめる	release-verification-steps.py verify-install --ref main --expect 10.27.24 --plugins ndf --runtimes claude,codex	2026-11-06 04:18	合格 / exit=0。claude・codex とも ndf 10.27.24、前の正式版のタグ ndf--v10.27.21 からの変更の中身の不一致 0、利用者の HOME の設定は変わっていない
#2519	1. design の手順に外部の調査があり、3 種類ごとに調べるかを決め、調べない種類に理由を 1 行残す	design/SKILL.md の「2. 外部の調査を通す」と references/external-survey.md の「2. 調べる対象を決める」を読んだ	2026-11-06 04:19	合格。3 種類（標準・仕様 / 主要な製品 / ライブラリとサービス）と「調べない種類には、理由を 1 行残す」がある
#2519	2. 雛形に外部の調査の節があり、3 つの表と確かめられなかったことの欄を持ち、どの表の行も出典の列を持つ	design-template.md の ## 外部の調査 を読んだ	2026-11-06 04:19	合格。STD / PRD / LIB の 3 表すべてに出典の列（{URL・パス・コマンド}（{取得日}））、小見出し「確かめられなかったこと」がある
#2519	3. ライブラリとサービスの表が版・ライセンス・保守の状態・要件を満たすかの列を持つ	同上	2026-11-06 04:19	合格。版・ライセンス・最後のリリースの日付・終了のアナウンス・要件を満たすかの列がある
#2519	4. 調べる量の上限があり、当たったら止めて残りを確かめられなかったことへ書く	external-survey.md の「4. 調べる量の上限」を読んだ	2026-11-06 04:19	合格。種類ごとの候補 6 件・取得の試み 30 回。当たったら止め、理由「上限」で書く
#2519	5. 取得できなかった対象を推定で埋めず、URL か検索の語と理由を書く。investigation-rules と食い違わない	external-survey.md の取得できなかった対象の節を読んだ	2026-11-06 04:19	合格。否定の結論は試した検索の語と結果を添えたときだけ書く（investigation-rules の「否定的結論にはエビデンス必須」を指す）
#2519	6. 省ける条件があり、省いた理由を設計の書き先に 1 行残す。決められないときは通す	external-survey.md の「1. 通すか省くかを決める」と deliverables.md を読んだ	2026-11-06 04:19	合格。3 つの省ける条件、省く: <理由> の 1 行、「省けるか決められないときは通す」がある
#2519	7. decisions.md に作り方（自前 / ライブラリやサービス / 標準）と、自前で作る決定には比べた候補を並べることがある	decisions.md の「作り方と比べた候補」を読んだ	2026-11-06 04:19	合格
#2519	8. 自前で作る決定に比べた候補が無い設計文書を、機械の検査と設計 PR のレビューの観点が指摘する	一時のリポジトリに 3 つの設計文書を置き design-survey.py check --issue <番号> を打った。レビューの観点は pr-review/SKILL.md の「外部の調査の確認」を読んだ	2026-11-06 04:20	合格。候補が無い決定: exit=1・no_candidates 1 件。候補を並べた決定: exit=0。省く: で省いた文書: exit=0。レビューの観点の表に「自前で作る決定に比べた候補が無い」がある（レビューの担当が実際に指摘するかは下の手動確認の行）
#2519	9. MVV が無い・調査の項目が無いプロジェクトでも働き、手順・検査・観点の文が MVV の項目を参照しない	grep -nE 'MVV|Value [0-9]' を external-survey.md・design-survey.py・pr-review の観点の節へ打った。上の 8 の一時のリポジトリには .ndf/ も MVV も無い	2026-11-06 04:20	合格。当たりは external-survey.md の「MVV に調査の項目があるかに依らず」の 1 行だけで、項目は参照していない。MVV の無いリポジトリで検査が働いた
#2519	10. 既存の設計文書があっても機械の検査が落ちない	design-survey.py check --file issues/*design*.md（本番の中身の 39 件）と test_design_survey.py::test_existing_issue_documents_pass	2026-11-06 04:20	合格 / exit=0。文書 39 件・決定 226 件で指摘 0
#2519	11. 退行しない: frontmatter の検査・claude plugin validate .・全体テストが通り、雛形は 500 行以内	本番の commit 726185bc を detached の worktree に取り出して python3 scripts/check-skill-frontmatter.py / claude plugin validate . / uv run --frozen --project . --all-extras pytest . -q -n 4 / wc -l design-template.md	2026-11-06 04:21〜04:33	合格。frontmatter exit=0、validate exit=0（Validation passed with warnings）、全体テスト 11532 passed・4 skipped・exit=0（710 秒）、雛形 318 行
#2519	12. pr-review の観点に、設計 PR で候補が無い・出典が無い・古い・節が無い / 省いた理由が無いを指摘にすると書かれている	pr-review/SKILL.md の ### 外部の調査の確認 を読んだ	2026-11-06 04:21	合格。設計 PR の 4 行（節・自前で作る決定・出典（取得日が 90 日以上前）・確かめられなかったこと）がある
#2519	13. 実装 PR の側に、設計の作り方・比べた候補に沿っているかを見ることと 3 つの例が書かれている	同上	2026-11-06 04:21	合格。ライブラリを使うとした機能を自前で作った / 作り方の行が無い自前の部品 / 比べた候補に無い新しい依存、の 3 つがある
#2519	14. cross-review が全担当へ渡す観点に 12・13 と同じ観点が載り、review_focus.py の単体テストで設計 PR・実装 PR に載り、ドキュメントだけの PR に載らない	pytest plugins/ndf/skills/cross-review/tests/test_review_focus_external_survey.py（7 件）と全体テスト	2026-11-06 04:20	合格。観点の文は pr-review の節をそのまま読む（review_focus.py の _external_survey_review）。設計・実装 PR に載る / ドキュメントだけの PR に載らない / プロファイルで既定の分類を外しても残る、のテストが通った
#2519	15. 担当が自分で外部を調べ、出典を添えて指摘してよい。取得できないときは推定で指摘せず、URL か検索の語と理由を書く	pr-review/SKILL.md の「外部を調べるときの規則」を読んだ（14 のとおり担当へ同じ文が渡る）	2026-11-06 04:21	合格
#2519	16. 担当が調べる量に上限があり観点に書かれ、design と違う値なら理由が設計にある	同上と issues/issue-2519-design.md の決定 13	2026-11-06 04:21	合格。1 ラウンド 10 回。design の 30 回と違う値は、設計の決定 13（調べる対象を自前で作る決定・新しい依存・古い行に絞る）に理由がある
#2519	17. 実装が 2 つの PR に分かれ、どちらも単独でテストが通り、1 つ目を先にマージする	gh pr view 2564 / gh pr view 2572（マージ時刻とテストの欄）	2026-11-06 04:18	合格。#2564（design の手順と検査）2026-11-05 23:06 JST、#2572（pr-review と cross-review の観点）2026-11-06 00:20 JST の順。どちらも範囲を絞ったテストが exit 0
—	マージ前に未検証として残した項目（#2564 の残リスク）: 設計文書に名前の出るテスト 1 件が HEAD に無い（design-tests が exit 1）	本番の中身で test_review_focus_external_survey.py の有無と実行を確かめた	2026-11-06 04:20	合格。該当のテストは 2 つ目の PR #2572 で入り、本番に在って 7 件が通った（#2572 の design-tests は 3 件すべて HEAD にあると報告）
—	スプリント PR #2574 の「手動確認」でリリース後テストへ回した項目（#2519 の検証手段）: NDF の外のプロジェクトで design を 1 回通し、外部の調査の節が出典つきで埋まる・自前で作る決定に候補が並ぶ・取得できなかった対象が確かめられなかったことへ載る。同じプロジェクトで cross-review を 1 回通し、観点の指摘か、指摘 0 件の理由が出る	—	—	保留（理由: この工程は ai-plugins の中で人が見ないまま回しており、NDF の外のリポジトリで設計 PR を出すことは他のリポジトリへの公開（C5）に当たるため行わなかった。いつ: 次に NDF の外のプロジェクト（例: volareinc/carul）で 10.27.24 以降の design と cross-review を通したとき、その設計 PR で確かめる）

合否: 合格（#2519 の受け入れ条件 17 件すべて合格。ほかに導入の確認とマージ前の未検証の 1 件が合格、外のプロジェクトでの手動確認 1 件は保留）
起票したもの: なし

[takemi-ohama]

振り返り（2026-11-06）

対象: スプリント lflow2-9 — issue #2519 / 設計 PR #2523 / 実装 PR #2564・PR #2572 / スプリント PR #2574 / 配布 PR #2586（main へは PR #2587）/ 確定仕様化 PR #2590

design に、設計の判断の前に業界の標準・主要な製品・既存のライブラリを調べ、決定の記録に「作り方」と「比べた候補」を残す手順を足した。あわせて、自前で作る決定に比べた候補が無い設計文書を指摘する検査（design-survey.py）と、pr-review・cross-review のレビューの観点を足した。実装は、設計の手順と検査（PR #2564）と、レビューの観点（PR #2572）の 2 つの PR に分けた。

本番の 10.27.24 で受け入れ条件 17 件がすべて合格した（リリース後テストの記録）。NDF の外のプロジェクトで design と cross-review を 1 回ずつ通す手動確認 1 件は保留にした。外のリポジトリで設計 PR を出すことは他のリポジトリへの公開（共通原則 C5）に当たり、人が見ていない工程では行わないためである。次に volareinc/carul などで 10.27.24 以降の design を通したときに、その設計 PR で確かめる。

この記録を配布の PR #2586 に置くのは、まとめのプランの後片付けのステップがこの PR を記録の PR として読むためである。

何が起きたか

時刻は JST で書く。

観点	事実
設計の承認ゲート 1	2 周回かかった。周回 6 では MVV 判定が読めず（根拠の項目が空）、利用者が 2026-11-05 12:24 に「直して出し直す」と答えた。中身の指示は、外部の調査の確認を design だけでなく pr-review と cross-review にも入れることだった（範囲を広げる指示）。周回 7 で設計を作り直し、2026-11-05 13:36 に MVV 判定が「従う」を返した
「従う」でも人を待った	周回 7 の MVV 判定は「従う」だったが、判定のステップは「関門の記録を書けない（関門 1 は MVV 判定の通過を取り消した）」で人へ戻した。利用者の承認は 2026-11-05 21:17 で、7 時間 41 分待った。周回 6 の出し直しで関門 1 の自動の通過が取り消されたままになったことが原因と読める。これが意図した振る舞いかは未確認
実装の手戻り	1 つ目の PR #2564 で 2 か所が落ちた。1 つは設計文書に名前の出るテストが手元に無いという検査（終了コード 1）で、該当のテストは 2 つ目の PR #2572 で入る。未検証として残し、リリース後テストで本番に 7 件あって通ることを確かめた。もう 1 つは文書の検査（終了コード 1）で、修正 1 回で通った。2 つ目の PR #2572 は全ステップが 1 回で通った
検査（PR #2574）	構造改善の提案 24 件のうち 6 件を採り、18 件を見送った。実装レビューは 2 ラウンドで、指摘 2 件を 2 件とも直した。落ちた回は 0 回
費用と時間	周回 9（実装から配布まで）は 4.956 ドル・12,194.7 秒。内訳は実装 1 が 1.539 ドル、実装 2 が 2.535 ドル、検査が 0.882 ドル、開発版の配布は 0 ドル。周回 6・7 の設計は他の課題と同じ周回で回したため、#2519 だけの費用は分けられない
見落とし	リリース後テストでの不合格は 0 件。マージ前に踏めなかった経路は、上の保留 1 件（NDF の外のプロジェクトでの実際の利用）だけ
範囲	範囲を広げたのは周回 6 の利用者の指示だけである。広げた分は 2 つ目の PR に分け、1 回の承認で読む量を抑えた
工程	飛ばした工程は無い。配布の承認ゲート 2 は人が承認した

起票の取りこぼし

0 件。次の 3 つで確かめた。

• issue-file.py by-origin を、起点の issue と PR 5 本（design: 設計の判断の前に外部の標準・主要な製品・既存のライブラリを調べ、自前で作る決定に比べた候補を残す（#2519） #2523・#2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564・#2519 の 2 つ目: pr-review と cross-review に外部の調査の観点を足す（スプリント lflow2-9） #2572・スプリント lflow2-9 #2574・Release: ndf v10.27.24 #2586）を由来に打った。上流リポジトリも検索したが、返ったのは design: 設計の前に外部の最新動向・事実上の標準・既存のライブラリを調べ、判断に反映する手順を足す #2519 自身の 1 件だけだった
• PR #2519 の 1 つ目: design の外部の調査の手順と検査（スプリント lflow2-9） #2564・#2519 の 2 つ目: pr-review と cross-review に外部の調査の観点を足す（スプリント lflow2-9） #2572・スプリント lflow2-9 #2574 の本文を「範囲外・やらないこと・起票・見送・後へ回・保留・未検証」で検索した。該当は 0 行だった
• リリース後テストの記録は「起票したもの: なし」だった

検査で見送った構造改善の提案 18 件は、Value 3（残りを新しい Issue へ送ることを既定にしない）に従って起票しない。確定仕様の「既知の限界」の 4 行（上限の値・作り方の行の書き漏れ・取得の手段・設計文書の探索）は、NDF の外での利用を数えてから見直すものなので、これも起票しない。

検査の記録の集計と閾値の見直し

check-trigger.py stats --root /work/ai-plugins の出力（2026-10-25 から 2026-11-05 までの記録）を次の表にまとめた。

項目	値
トリガーの評価	0 回（立った 0 回）
検査	66 回。すべて PR を指す検査で、対象の PR は 28 本。マージ 28 回・落ちた 38 回
PR ごとの落ちた回数	0 回が 12 本、1 回が 5 本、2 回が 3 本、3 回が 6 本、4 回と 5 回が 1 本ずつ
指摘の件数（件数を持つ 27 行）	指摘 331 件（中央値 5・最大 62）。直した 251 件・見送った 67 件・却下した 13 件。ラウンドの中央値は 3（最大 12）。指摘 0 件の行が 6 行
このスプリントの検査（PR #2574）	指摘 2 件・直した 2 件・ラウンド 2・落ちた 0 回
検査の後に逃げた不具合	0 件（結び付いた 0 件・結び付かない 0 件）

閾値（.ndf/pace.json の点数 10・変更量 3,000 行・流出不具合 1 件・期限 24 時間）は見直さない。 理由は 3 つある。

1. 閾値を測った記録が無い。 トリガーの閾値を使うのは進め方 fast だけで、このリポジトリのループが使う auto は評価を呼ばない（development-workflow の references/pace.md の「スプリントを始める」）。auto はスプリントごとに PR を指す検査を 1 回通す。66 回の検査はすべてこの形で、トリガーの範囲の材料にならない。pace.md の「記録の読み方と閾値の見直し」は「検査を 5 回回した後に閾値を見直す」と定めており、数える対象の評価はまだ 0 回である
2. 逃げた不具合の件数は 0 件だが、記録の経路がほとんど使われていない。 流出の行は、直すプランを new fix --escape-of で組んだときだけ書かれる。記録の全 66 行に流出の行は 0 行で、MVV の兆候の流出不具合も 0 件である。リリース後テストの不合格を別の経路で直した変更があれば数えられていない。数えられていない件数があるかは未確認で、残リスクとして残す
3. このスプリントの検査は閾値と関係なく 1 回で通った。 指摘 2 件・落ちた 0 回で、検査の回数を増やす・減らす理由になる事実は無い

閾値を見直すのは、fast でループを回して評価が 5 回以上たまった後とする。

context window の大きさ

conductor のセッション 1 つを測った（skill-stats.py --agents）。このセッションは開発ループ lflow2 の全周回（2,252 分）を通しており、周回 9 だけの値には分けられない。 周回 9 の実作業の大半は supervise.py が起動した claude -p のステップで、この表の層には入らない。

層	フェーズ	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	目印
conductor	-	claude-opus-5-5	1	45175	781249	0	826424	割る候補
supervisor	その他	claude-haiku-5-5	1	40971	37376	1	78347	束ねる候補
supervisor	その他	claude-opus-5-5	37	38488	23957	34	159068	束ねる候補
worker	その他	claude-opus-5-5	3	38583	31921	2	80943

層	件数	固定費の合計	実作業の合計	総消費
conductor	1	45175	781249	826424
supervisor	38	1467008	1097584	2564592
worker	3	115241	99337	214578
合計	42	1627424	1978170	3605594

フェーズ	supervisor	supervisor の実作業	worker の件数	supervisor と worker の固定費の合計	目印
その他	13	25442	1	84862	worker を使いすぎ
その他	15	38062	2	124293	worker を使いすぎ

• conductor の「割る候補」: そのままにする。開発ループは 1 つの conductor が周回をまたいで回す形で、最大充填は 826,424 で中継の再起動の範囲に収まっている。周回 9 だけで割る判断の材料は、この測定からは取れない
• supervisor の「束ねる候補」: そのままにする。38 件のうち 34 件は実作業が固定費より小さいが、フェーズが読めず（38 件とも「その他」）、どの工程の起動かを分けられない。束ねる先を決める材料が無い
• 「worker を使いすぎ」の 2 行: そのままにする。worker は合わせて 3 件で、固定費の合計は 115,241 である。全体の総消費 3,605,594 に比べて小さい

用語集の変化

設計 PR #2523 の起点からマージまでの差分である。スプリント PR #2574 には変化が無い。

コンテキスト	足した語	廃止した語	意味を変えた語
ndf-workflow	外部の調査・自前で作る決定・確かめられなかったこと・作り方・比べた候補	無し	無し

承認ゲートの差し戻し

• gate-rejections.py count --sprint（周回 9 の状態ファイル）: 未記録。周回 9 は関門 1 を通らない周回で、範囲に承認ゲートの答えの行が無い
• gate-rejections.py count --issue 2519 --pr 2523 --pr 2574 --pr 2587: 関門 1 が 0 件・関門 2 が 0 件
• ただし、実際には関門 1 で 1 回差し戻されている。 周回 6 の「直して出し直す」（2026-11-05 12:24、範囲を pr-review と cross-review へ広げる指示）は開発ループの待ちの記録に残っているが、差し戻しの記録には書かれていない。差し戻しの記録の答えは「承認」53 件・「差し戻し」2 件だけで、「直して出し直す」は 1 件も無い。この数え漏れは #2400（開発ループの承認ゲート 1 で「直してから出し直す」と答えても差し戻しの記録に残らず、振り返りの差し戻しが 0 件になる）として起票済みで、このスプリントはその実例の 1 つである

MVV を見直すか

project-mvv.py signals の集計（版 5）は次のとおりである。

兆候	件数	閾値
覆し（判定できないか従わないを利用者が通した）	11	3
判定できない	0（続けて 0 回）	5（続けて 3 回）
流出不具合	0	3

覆しが閾値を超えた。ただし、同じ 11 件について、スプリント lroot3-17 の振り返り（ #2586 (comment) ）が 2026-11-06 04:33 に改訂の承認を利用者へ問うている。このスプリントは覆しを 1 件も足していない（周回 7 の #2519 は判定「従う」を利用者が承認した）。この振り返りでは改訂を問わず、その問いへの利用者の答えに従う。 同じ問いを重ねても、人が答える数が増えるだけで材料は増えないためである（根拠: Value 2・Value 3・C7）。判断は ask.py decide で記録した。

次に変えること

変えること	落とし先	状態
開発ループの「直して出し直す」を差し戻しとして数える	gate-rejections.py と開発ループの答えの記録（sprint-state.py loop answer --revise）	#2400 として起票済み。このスプリントの周回 6 を 2 例目の実例として挙げる
検査の閾値	.ndf/pace.json の閾値	変えない。auto は評価を呼ばず、閾値を測った記録が無い。fast で評価が 5 回たまってから見直す
出し直しの後の「従う」が人を待つ振る舞い	次の変更で確かめること	変えない。人が一度止めた関門を機械が通さない形は、上位の原則「人を守る」に沿うと読める。意図した振る舞いかは未確認で、同じ待ちが続けて出たら、その時点の材料で起票するかを決める

途中で起票した課題

無し（起票の取りこぼしも 0 件。「起票の取りこぼし」を参照）。

[takemi-ohama]

リリース後テスト

対象の版: 10.27.24（2026-11-06 04:11 JST にタグ ndf--v10.27.24 を出した。本番 = main 726185b）
導入経路: 利用者と同じ手順（claude plugin marketplace add devbasex/ai-plugins → claude plugin install ndf@ai-plugins、codex plugin marketplace add devbasex/ai-plugins → codex plugin add ndf@ai-plugins）を隔離した HOME で打った
対象の環境: 本番（正式版のチャネル main）
スプリント: lroot3-14（スプリントの Pull Request #2565。課題 #2097 は実装 #2562 まで入った。#2516 は設計 Pull Request #2558 だけがマージされ、実装はこの版に入っていない）

#2097 の確かめ方: 導入先 ~/.claude/plugins/cache/ai-plugins/ndf/10.27.24/scripts/supervise.py を、一時の git リポジトリ（bare の origin と clone、git remote set-head origin main、.ndf/worktree.json は {"base_branch":"main"} だけ、.ndf/supervise.json の release は form: package-plugin・plugin: foo・runtimes: [claude]）で打った。new sprint を含む条件は、導入した版と一致を確かめた main 726185b のテスト plugins/ndf/scripts/tests/test_production_default_branch.py でも確かめた。

課題	受け入れ条件	実行したこと	実行時刻	結果
—	導入の確認: 利用者と同じ手順で入れ直し、導入された版と中身が本番と一致する	release-verification-steps.py verify-install --ref main --expect 10.27.24 --plugins ndf --runtimes claude,codex --root .	2026-11-06 04:45	合格 / exit=0。status=ok、claude・codex とも ndf 10.27.24、mismatch=0、利用者の HOME の設定は変わらない（user_env_unchanged=true）
#2097	1. production_branch の無いリポジトリで、まだ作っていない worktree を渡した new release --channel prod が終了コード 0・status: ok で、approve・snapshot・release・verify を持つプランを書く	supervise.py new release --version 1.0.0 --prs 1 --channel prod --worktree <clone>/.worktrees/release/v1.0.0 --out before.json（worktree は未作成）	2026-11-06 04:46	合格 / exit=0・status=ok。ステップは approve, bump, bump-others, changelog, notes, snapshot, release, record, verify, cleanup, judge, fix, judge-record
#2097	2. 1 のプランで、本番の配布の確認に使うブランチが main である	before.json の verify の --ref を読んだ	2026-11-06 04:46	合格 / --ref main
#2097	3. worktree を作った後に同じコマンドを打っても、1 と同じステップの並びのプランを書く	git worktree add .worktrees/release/v1.0.0 -b release/v1.0.0 の後に同じコマンドで after.json を書き、ステップの id の並びを比べた	2026-11-06 04:46	合格 / exit=0、並びが一致
#2097	4. origin の HEAD も main / master も production_branch も --production-branch も無いと、今と同じく止まり、文面が 3 つの出所を挙げる	既定ブランチ trunk・git remote set-head origin -d の clone で同じコマンド	2026-11-06 04:46	合格 / exit=2。本番の配布に要る本番のブランチが無い（--production-branch・.ndf/worktree.json の production_branch・既定ブランチ（origin/HEAD → main / master））
#2097	5. まだ作っていない worktree を渡した new sprint（pace: normal・fast・auto）が承認ゲート 2 と本番を置き、「承認ゲート 2 と本番は置いていない」の案内を出さない	main 726185b で pytest plugins/ndf/scripts/tests/test_production_default_branch.py -q（test_sprint_puts_gate_2_and_production_before_the_worktree_exists の normal・fast・auto）	2026-11-06 04:46	合格 / exit=0、13 passed（3 つの進め方とも通過）
#2097	6. 退行しない。宣言・引数の値を本番に使い、ai-plugins のメインディレクトリで打った new release --channel prod のプランが変更の前後で同じ JSON になる	(a) --production-branch prodx を付けて打った (b) .ndf/worktree.json に production_branch: stable を書いて打った (c) ai-plugins のメインディレクトリで、スプリントのマージ直前（436e2d10）の plugins/ndf と導入した 10.27.24 のそれぞれで new release --version 9.9.9 --prs 1 --channel prod --worktree .worktrees/release/v9.9.9 を打ち、プラグインの置き場のパスをそろえて比べた	2026-11-06 04:47	合格 / (a) --ref prodx (b) --ref stable (c) 前後とも exit=0、JSON は一致
#2097	7. 1 の宣言で、リリースの経路の判定（lib/delivery.py）とリリースプランの本番のブランチが同じ値になる	1 の clone で導入先の lib/delivery.py の load_delivery('.').production を読み、1 のプランの verify の --ref と比べた。あわせて 5 の pytest の test_template_and_route_decision_use_the_same_production_branch	2026-11-06 04:47	合格 / どちらも main。テストも通過
#2516	1. テストの関数を持たない test_*.py は試走の候補に入らない	—	—	保留（理由: この版には設計 Pull Request #2558 の文書だけが入り、実装は入っていない。導入先の refactor_lib/pathkinds.py の is_test_path('lib/test_helpers.py') は今も True を返す。実装が配布された版のリリース後テストで実施する）
#2516	2. --scope の配下にテストの関数を持たない test_*.py しか無いとき、テストの置き場所とみなされない	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	3. 「再現の手順」と同じ条件で init がテンプレートの試走で止まらず、scope_command を直す案内も出ない	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	4. テストの関数を持つ test_*.py は今までどおり試走の候補とテストの置き場所の判定に入る	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	5. 行数と危険度の判定で、テストの関数を持たない test_*.py はプロダクションコードとして数えられる	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	6. Python 以外の言語の名前の形とディレクトリの名前による判定の結果は変わらない	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	7. 全体テストが通る	—	—	保留（理由: 1 と同じ。実装が配布された版で実施する）
#2516	手動確認（課題の「検証手段」）: 配布の後、#2369 の Pull Request #2515 の検査のプランで init が試走で止まらず、template-check.json の判定が ok である	—	—	保留（理由: 実装が配布されていないため。実装が配布された版のリリース後テストで実施する）

マージ前に未検証として残した項目: #2097 は課題の「検証手段」の手動確認が「無し」で、スプリントの Pull Request #2565 と実装 #2562 にも未検証の項目は無い。#2516 の手動確認は上の最後の行。

合否: #2097 は合格（受け入れ条件 7 件すべてと導入の確認が合格）。#2516 は保留（受け入れ条件 7 件と手動確認 1 件。実装がこの版に入っていない）
起票したもの: なし（#2516 は開いたままで、実装は今後のスプリントで行う）