[takemi-ohama]

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

含む PR

• Fix: 共有の環境の UV_PROJECT_ENVIRONMENT を子へ漏らさず、状態の一覧の失敗で並列の計画を終えない（UV_PROJECT_ENVIRONMENT が子プロセスへ漏れ、利用者の uv run が NDF の共有の環境を作り直す（並列の計画が動いたまま finished で終わる） #2509 の即時修正）（Fix: 共有の環境の UV_PROJECT_ENVIRONMENT を子へ漏らさず、状態の一覧の失敗で並列の計画を終えない（#2509 の即時修正） #2651）
• ndf: リリース記録の版が v で始まる形で書かれていても、先頭の v を落とした版として読む（#2225 を実装する（スプリント lroot3-19） #2650）（スプリント lroot3-19 #2652）
• ndf: リリース後に実行するテストは、先頭の v を落とした版どうしを比べて選ぶ（#2225 を実装する（スプリント lroot3-19） #2650）（スプリント lroot3-19 #2652）
• Update: プロジェクト MVV を版 6 にする（Value 3 と「改訂」の節）（Update: プロジェクト MVV を版 6 にする（Value 3 と「改訂」の節） #2657）
• Fix: MVV の連続の提案のテストが秒の境で落ちる（Fix: MVV の連続の提案のテストが秒の境で落ちる #2661）
• Fix: 並列の計画の状態が消える 4 か所を止血する（carul の根本原因 A: 計画の状態（依頼・問い・役割・使う版）が計画より短命な入れ物にしか無く、再起動・作り直し・版の更新で消える #2647 の即時修正）（Fix: 並列の計画の状態が消える 4 か所を止血する（#2647 の即時修正） #2668）
• ndf プラグインの並列実行で状態の一覧の失敗が続くと、利用者へ問いが出る（#2509 を実装する（スプリント lroot4-1） #2671）（スプリント lroot4-1 #2673）
• Docs: 開発ループのテストのステップが、作業場所のテスト用コンテナが止まっているのを確かめずに走り、偽の失敗か出力なしの遅れで止まる #2567 の設計へ承認ゲート 1 の答えを反映し、ボリュームを既定で残す（Docs: #2567 の設計へ承認ゲート 1 の答えを反映し、ボリュームを既定で残す #2674）
• loop exclude で選定を取り直しても、承認とマージが済んだ設計の課題は順位によらず先頭に選ばれる（Fix: loop exclude の取り直しで承認した設計が先頭から落ちないようにする #2678）

チェックの結果

• 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 22:22 に ndf--v10.27.31 を出した）
版: 10.27.27 → 10.27.31（タグ ndf--v10.27.31。直前はタグ ndf--v10.27.27）
スプリント: PR #2633 / #2634 / #2636 / #2644 / #2645 / #2650 / #2651 / #2652 / #2654 / #2657 / #2658 / #2659 / #2661 / #2662 / #2668 / #2670 / #2671 / #2673 / #2674 / #2678

[takemi-ohama]

リリース後テスト

対象の版: 10.27.31（2026-11-06 22:22 JST に配布）
導入経路: 本番チャネル main（a564d374）から、隔離した HOME へ claude plugin marketplace add devbasex/ai-plugins・claude plugin install ndf@ai-plugins（codex も同じ）。手元の導入先 ~/.claude/plugins/cache/ai-plugins/ndf/10.27.31 はタグと一致

スプリント lroot4-1（#2509）。PR #2673 / #2671（と即時修正 #2651）の検証である。

課題	受け入れ条件	実行したこと	実行時刻	結果
—	導入の確認: 利用者と同じ手順で入れ直す	release-verification-steps.py verify-install --ref main --expect 10.27.31 --runtimes claude,codex --root .	2026-11-07 03:59	合格 / exit=0。claude・codex とも 10.27.31、内容の不一致 0、利用者の HOME の設定は不変
#2509	1. 一覧の失敗の回の観測の後も、各レーンの状態は同じである	並列の計画 2 レーンの実行中に共有の環境から psutil を抜き、relay.py ls を実際に失敗させた（下の「確かめ方」）	2026-11-07 04:04	合格 / ls は exit=3。失敗の観測 59 回はすべて code=3・行は空で、その間レーンを止まったと読まず計画は続いた。単体 test_a_failed_ls_keeps_lane_states_and_the_last_observation も通過
#2509	2. 一覧の失敗の間は finished を返さず、耐久の記録にも残らない	同じ実行で parallel.py wait と耐久の記録の workflow_status を見た	2026-11-07 04:06	合格 / 失敗の間は PENDING（レーンの実体は 04:05 に止まっていたが終わらなかった）。finished は一覧が戻った後の 04:07
#2509	3. 一覧が 0 で終わり起動済みのレーンの行が無いときは止まったと読み、全レーンがそう読めたら終える	psutil を入れ直して一覧を戻した。行が無い形は test_char_lane_missing_from_ls_counts_as_stopped_and_finishes	2026-11-07 04:07	合格 / 成功の観測 1 回で finished（la・lb とも stopped）。実機の行は stopped の行で、行が無い形はテストで確かめた
#2509	4. 失敗が区切りより長く続くと問いを 1 件出し、本文に終了コードと標準エラーの末尾 1 行が入り、同じ区切りで重ねない	NDF_PARALLEL_STALL_MINUTES=1・NDF_PARALLEL_POLL=2 で parallel.py wait	2026-11-07 04:05	合格 / 04:05:58 に 1 件、次の区切りの 04:06:59 に 2 件目。本文は「1 分続けて失敗している（終了コード 3: ndf-relay: ラッパーの環境（…）が無い。…）」。一覧が戻ると問いは 0 件
#2509	5. deps.require() で起動し直したスクリプトの子プロセスの env に UV_PROJECT_ENVIRONMENT が無い	配布物の supervise.py run のステップで env（素の /usr/bin/python3 から起動し、起動し直しを踏んだ）	2026-11-07 04:02	合格 / 該当 0 行。VIRTUAL_ENV が共有の環境を指すことで起動し直しを確認。レーン 2 本のステップでも 0 行
#2509	6. requires-python の合わない別のプロジェクトで uv run --project を打っても共有の環境が変わらず import psutil が通る	上のステップで requires-python = ">=3.13,<3.14" のプロジェクトへ uv run --project（共有の環境は 3.14.4）	2026-11-07 04:02	合格 / exit=0。そのプロジェクトの .venv（3.13）で動いた。pyvenv.cfg の中身（md5 c1b05082）と更新時刻（19:02:34 UTC）は不変、import psutil は 7.2.2
#2509	7. ラッパーの子の claude の環境変数に共有の環境を指す値が無い（古い版から継いだ場合も）	実物の relay.py run を tmux で起動し、子の環境を記録。親に ~/.cache/ndf/venv/10.27.16 を指す値を付けた	2026-11-07 04:08	合格 / 付けた場合も、並列の計画のオーガナイザーとレーン 2 本も該当 0 行
#2509	8. 利用者の値はスクリプトの子プロセスとラッパーの子の claude へそのまま渡る	UV_PROJECT_ENVIRONMENT=<別の置き場> を付けて supervise.py run と relay.py run	2026-11-07 04:08	合格 / どちらの子にも同じ値が届いた。注記: 統括役が既に居るときの 2 本目の relay.py run は統括役へ頼む経路で、頼んだ側の環境変数ではなく統括役の環境を継ぐため、値は届かなかった。この条件はラッパーが外さないことを見るものと読み、今回の変更の前からの経路として不合格にしていない
#2509	9. 回帰テストがあり、変更前のコードで失敗し、変更後で通る	タグ 10.27.31 の test_parallel_run.py・test_deps.py・test_relay.py を、10.27.31 のコードと 10.27.27 のコードへ当てた	2026-11-07 04:01	合格 / 10.27.31 は 522 passed・exit=0。10.27.27 は対象 15 件中 13 failed。通った 2 件は変更前から正しい振る舞いの確認（条件 3 の既存の振る舞い、条件 8 のラッパーの子へ利用者の値が渡ること）
#2509	10. 起動し直した後の子が別のグループを要るとき、その子が自分で起動し直して動く	supervise.py run のステップから deps.require("notify") のスクリプトを起動（共有の環境に slack_sdk が無い状態から）	2026-11-07 04:07	合格 / exit=0。slack_sdk 3.44.1 を import できた。test_deps.py も通過
—	手動確認（PR #2673 からリリース後テストへ回した項目・承認資料の未検証の項目）: 並列の計画を 2 レーン以上で流し、レーンのスプリントが uv run --project <x> を打った後も pyvenv.cfg の更新時刻が変わらない	実物の parallel.py start・relay.py・supervise.py・tmux・uv で 2 レーンを流し、各レーンのステップが別のプロジェクトへ uv run --project を打った	2026-11-07 04:04	合格 / 2 本とも exit=0 で各自の .venv（3.13）で動き、更新時刻は不変。違い: 本物の claude は使わず起動の口だけ差し替えた。carul のリポジトリでは流していない。本物の共有の環境 ~/.cache/ndf/venv/10.27.31 の更新時刻も 22:59 JST 以後変わっていない（lroot2 が 10.27.31 で動いている）
—	マージ前の未検証: PR #2671 の「落ちたテストの名前と件数は未確認」	範囲テストの記録 16-test-limited.out から 5 件を特定し、10.27.31 のコードで再実行（test_relay.py の guard 2 件・test_1644_…・test_one_record_adds_less_than_a_second・test_limit_wait_is_not_counted_as_slow）	2026-11-07 04:09	合格 / 記録の分類はフレーキー 2・既存失敗 3・変更起因 0。再実行は 5 passed・exit=0。単独の再実行であり、全体テストの負荷の下での再現は見ていない
—	設計の未確認: VIRTUAL_ENV と PATH が子へ渡っても共有の環境を変えない	条件 5・6 と同じ実行で確かめた	2026-11-07 04:02	合格 / VIRTUAL_ENV は共有の環境を指したままで、uv run --project は相手の .venv を使った。素の python3 が共有の環境で動く点は設計どおり変えていない
—	設計の未確認: ラッパーの中身が見つからないときのパススルーは継いだ値を外さない	—	—	保留（理由: 設計で「外さない」と決めた経路で、レーンはここを通らない。実施の予定は無い）
—	設計の未確認: 実験版 deps-trial.py・hook-trial.py の起動し直しは対象外	—	—	保留（理由: 既定の振る舞いから参照されない。本体へ移すときに同じ形へそろえ、そのときに確かめる）

合否: 合格（受け入れ条件 10 件すべて合格。条件に結び付かない行は 6 件で、4 件合格・2 件保留）
起票したもの: なし

確かめ方

• 本物のレーンと共有の環境に触れないよう、隔離した HOME（~/.cache/ndf/venv/10.27.31 もその中）で配布物の scripts/ をそのまま動かした。差し替えたのは NDF_RELAY_CLAUDE だけで、差し替えた claude は環境変数を記録して supervise.py run を流す。待ちを縮めるため NDF_PARALLEL_POLL=2・NDF_PARALLEL_STALL_MINUTES=1 を付けた。
• 共有の環境は課題の再現と同じ uv sync --frozen --no-managed-python … --inexact で作った。条件 1〜4 の失敗は、課題の再現と同じくラッパーの extras を抜いて作った（NDF_PARALLEL_RELAY の差し替えは使っていない）。
• 配布版と前の版のテストは、タグを git archive で取り出した手元のコピーで実行した。

[takemi-ohama]

振り返り（2026-11-07）

対象: スプリント lroot4-1 — issue #2509 / 実装の PR #2671 / スプリントの PR #2673 / 配布の PR #2683（ndf v10.27.31）

並列の計画で状態の一覧（relay.py ls）の失敗が続くときに、利用者へ問いを 1 件出す仕組みを作った。失敗した回の観測を捨てること、NDF が設定した UV_PROJECT_ENVIRONMENT を子プロセスへ渡さないことは、先に即時修正の PR #2651 で入っており、このスプリントの実装は問いの仕組みと回帰テストである。

開発ループ lroot4 の周回 1 には #2616 と #2567 も選ばれていたが、設計の承認待ちのため実装から外れ、周回 2 へ回った。

何が起きたか

観点	事実	記録
受け入れ条件	途中で変えた条件は無い。リリース後テストは受け入れ条件 10 件すべて合格（2 レーンの実機確認を含む）。不合格 0 件	PR #2683 のリリース後テストのコメント
範囲	課題の本文の条件のうち、finished で終わった計画の打ち直し（S6）は設計どおり含めなかった。即時修正との分担は課題の本文のとおりで、範囲を広げた判断は無い	課題の本文、PR #2651
手戻り（実装）	構造の検査の行数超過で 1 回、この変更が起こしたテストの失敗で 1 回、修正へ戻った。どちらも同じ計画の中で解けた	5-impl-2509-state/report.md
手戻り（レビュー）	cross-review は 2 ラウンド。指摘 1 件（重大度 major）を直した。更新前から一覧の失敗が続いていた計画を再開すると、耐久の記録の再生中に問いの呼び出しが挿入されて再開できなくなる不具合で、記録に can_ask を足して解いた	PR #2673 のレビュー、コミット 311402f
所要	実装の計画 13,656 秒・$4.321 のうち、範囲テスト 2 回の 8,410 秒（62%）がテストの待ちだった。検査の計画は 5,003 秒・$1.207	5-impl-2509-state/report.md、6-check-state/report.md
工程	構造改善は通らなかった。着手前のテストが上限 1,591 秒で終わらず、init-timeout で飛ばした。課題の進行の欄には「構造改善」の時刻が付くため、欄だけでは飛ばしたことが読めない	検査の記録の refactor_skipped
見落とし	PR #2671 の本文は落ちたテストの名前を「未確認」と書いた。名前は範囲テストの記録にあり、リリース後テストが 5 件を特定して単独の再実行で通した（フレーキー 2・既存失敗 3・変更起因 0）。全体テストの負荷の下での再現は未確認	PR #2683 のリリース後テストのコメント
記録	課題の進行の欄で、Pull Request・確定仕様化・後片付け・リリース後テスト・棚卸しの時刻は実装より前の 2026-11-05（UTC）のままである。周回 lroot3-17 のまとめが、実装の入っていないこの課題にも記録したためである。この経路の起点は #2596 が扱う	課題の本文、前回の振り返り

リリース後テストの注記が 1 件ある。統括役が既に居るときの 2 本目の relay.py run は統括役の環境を継ぐため、利用者が設定した UV_PROJECT_ENVIRONMENT が届かない。このスプリントの変更の前からある経路で、受け入れ条件 8 の不合格にはしていない。

検査の記録と閾値

閾値は見直さない。見直す材料が無いためである。 check-trigger.py stats（2026-11-07 JST に実行）の結果は次のとおり。

数	値
トリガーの評価	0 回（立った 0 回）
検査	80 回（すべて PR を指す検査）。うち落ちた 44 回（構造改善 25・不明 17・レビュー 1・マージ 1）
検査の後に逃げた不具合	1 件（結び付いた 0 件）
このスプリントの検査（PR #2673）	1 回でマージ。2 ラウンド・指摘 1 件・直した 1 件・見送り 0 件。結び付いた流出 0 件

検査した PR 37 本のうち件数を読める 31 本を PR ごとの最大値で集めると、指摘は合計 248 件（中央値 2 件）、ラウンドの中央値は 2、指摘 0 件は 7 本、見送りは合計 41 件だった。残り 6 本は件数が記録に載っていない。

• .ndf/pace.json の triggers（score 10・common_weight 2・lines 3000・escapes 1・hours 24）は一度も読まれていない。 閾値を読むのは pace: fast のトリガーの評価だけで、このリポジトリのスプリントは pace: auto で評価を通らない（plugins/ndf/scripts/supervise_lib/sprint.py の auto_sprint_plans）。記録 81 行の内訳は検査 80 行・流出 1 行・評価 0 行である
• 検査を減らす材料も無い。 件数を読める 31 本のうち 24 本で指摘が出ている
• 流出 1 件は実際より少ない数である。 記録されるのは --escape-of で組んだ修正だけで、配布済みの不具合を直した PR Fix: 共有の環境の UV_PROJECT_ENVIRONMENT を子へ漏らさず、状態の一覧の失敗で並列の計画を終えない（#2509 の即時修正） #2651 は載っていない
• 流出 1 件が検査へ結び付かない。 PR #2678 は持ち込んだ PR を実装の #2507 を実装する（スプリント lflow2-7） #2542 と記録した。検査の行が範囲に持つのはスプリントの スプリント lflow2-7 #2543 だけなので、理由が no_check（検査が無い）になる。スプリント lflow2-7 #2543 は検査を通っている（2026-11-05 16:43 JST マージ・指摘 6 件）

context window の大きさ

周回 1 の conductor の 2 セッションを測った。#2616 と #2567 の設計の待ちを含む。claude -p で動く worker はこの測定に入らない。

層	フェーズ	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	目印
conductor	-	claude-opus-5-5	2	42530	189108	0	239939	割る候補
supervisor	その他	claude-opus-5-5	5	43566	82516	0	184991
supervisor	その他	claude-sonnet-5-5	1	45444	43029	1	88473	束ねる候補

層	件数	固定費の合計	実作業の合計	総消費
conductor	2	85061	378215	463276
supervisor	6	249943	499766	749709
合計	8	335004	877981	1212985

フェーズ	supervisor	supervisor の実作業	worker の件数	supervisor と worker の固定費の合計	目印

フェーズごとの表は空である（supervisor 6 件のフェーズを読めなかった）。

• conductor（割る候補）: そのまま。すでに 2 セッションに切れており、1 周回の待ちが長いことによる充填で、作業の切り方を変える材料にならない
• supervisor の sonnet（束ねる候補）: そのまま。該当は 1 件で、実作業 43,029 は固定費 45,444 と同程度である

承認ゲートの差し戻し

関門 1 が 0 件、関門 2 が 0 件。#2509 の設計は周回 lroot3-17 で判定を読めず、利用者が承認した（差し戻しではない）。

MVV を見直すか

見直さない。版 6 の兆候はどれも閾値を超えていない: 覆し 2 件（閾値 3）・判定できない 1 件（閾値 5）・続けて 1 回（閾値 3）・流出不具合 1 件（閾値 3）。流出不具合の数は上の節のとおり --escape-of の経路だけを数えている。

次に変えること

変えること	落とし先	状態
検査のトリガーの閾値	変えない	評価が 0 回で材料が無い。測らずに変えない（Value 4）
材料が足りないことを stats が出し、毎回の振り返りで同じ結論を書かない	次の変更で試すこと（起票済み）	#2300 の受け入れ条件 1。今回の実測を本文へ追記
流出不具合の持ち込み元が実装の PR でも、それを集めたスプリントの PR の検査へ結び付ける	次の変更で試すこと（起票済み）	#2300 へ 5 つ目の穴として追記
範囲テストの待ちと、着手前のテストの上限	変えない	テストの重さは #2291 が扱う。上限は打ち切りの履歴から次回 4,773 秒へ上がる見込みで、手当てが要らない
統括役の経路で利用者の値が届かないこと	変えない	このスプリントの変更の前からある経路で、この経路の不具合の報告は #2509 の本文とコメントに無いため起票しない（Value 3）

途中で起票した課題

このスプリントから出た課題は無い。issue-file.py by-origin（由来 4 件・上流リポジトリ込み）で見つかったのは #2509 自身だけである。レビューの見送りは 0 件、リリース後テストの起票は無し、設計に残した「範囲外」は VIRTUAL_ENV の扱いの 1 件で、要求の前提 4 で確かめて変えないと決めたものである。取りこぼしは無かった。