[takemi-ohama]

ndf v10.27.16 を main へ出す（開発版の PR #2488）。

🤖 Generated with Claude Code

[takemi-ohama]

振り返り（2026-11-04）

対象: スプリント lfactory3-1（issue #2439 / issue #2172 / issue #2405）。本番への配布は PR #2490（ndf 10.27.16）

開発ループ lfactory3 の周回 1 として、Factory のオーガナイザー（同じリポジトリで並行する実行の本番の配布を 1 本にまとめ、承認と問いを 1 か所に集める。#2439）と、スプリントの一覧と詳細の画面（#2172）を実装し、10.27.16 として配布した。#2405（再開したジョブへ変えた予算を届ける）は設計の Pull Request #2478 が開いたままで、実装のプランは流れていない。リリース後テストは 44 件のうち 34 件が合格、#2405 の 10 件は未配布のため保留である（記録 ）。

周回の費用は $40.252、所要は 11,137.7 秒（約 3.1 時間）。

何が起きたか

観点	事実
受け入れ条件	途中で変えた条件は無い。設計との違い 2 件を実装の PR #2483 に残した（差し戻しの理由 release_rejected を実行の終わりの理由に書かない・ループの実行が done で終わることを確かめる API 側のテストが無い）。前者は確定仕様（docs/specifications/ndf-factory-organizer.md の流れ 5）が実装と同じ形で書かれている
手戻り	設計 #2405: レビュー 2 ラウンド・指摘 2 件をすべて修正。実装 #2439: 静的解析と文書の検査でそれぞれ 1 回落ち、worker が 1 回で直した。実装 #2172: 手戻り 0。検査（スプリントの PR #2485 ）: cross-review が 4 ラウンドの上限に当たり、指摘 27 件をすべて直して未解決 0 件のまま終了コード 6 で検査ごと落ちた。再開して base-sync から通した
見落とし	実環境で人が見る手動確認 2 件（#2439・#2172）は、この実行から Factory の本番の系に触れられず未実施
範囲	選定は 18 件中 3 件（順位 2・品質の枠 1）。人の判断待ちの 5 件と容量で外した #2173 は選ばなかった
工程	設計 #2405 の要求の検査（requirements-check）が終了コード 2 で止まり、承認ゲート 1 の MVV 判定が「判定できない」になって人へ戻った（人は承認）。配布の依頼は並列の実行のまとめ（parallel-request）で関門を返し、オーガナイザーの配布へ回った

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

check-trigger.py stats --root /work/ai-plugins（10.27.15）の結果:

項目	値
トリガーの評価の回数	0
トリガーが立った回数	0
検査の回数（PR を指す検査）	55（55）
落ちた検査	36
検査の後に逃げた不具合	0（検査へ結び付いた 0）

このスプリントの検査は PR #2485 の 1 件で、記録は 2 行ある。1 行目は落ちた（指摘 27 件・修正 27 件・未解決 0 件・構造改善の適用 7 件、落ちた工程は「不明」）、2 行目はマージである。

閾値（.ndf/pace.json の triggers: score 10・common_weight 2・lines 3000・escapes 1・hours 24）は見直さない。 理由は 3 つ:

• トリガーは pace: fast で検査を間引くときだけ評価される。このスプリントは pace: auto で、検査を PR ごとに通したため、評価が 0 回である。立った回数と立たなかった回数が無く、閾値が高いか低いかを判定する材料が無い
• 逃げた不具合が 0 件なのは、不具合が無かったことを示していない。流出の記録（check-trigger.py escape）が 1 行も書かれておらず、0 件と未記録を区別できない
• 落ちた検査 36 件には、未解決 0 件のまま上限で落ちた回（このスプリントの スプリント lfactory3-1 #2485 を含む）と、再開の前に記録された回が混ざる。落ちた工程が「不明」の行があり、検査の厳しさの指標として読めない

これら 3 点はいずれも #2300（検査の記録の集計で閾値を見直せない）が扱っている。このスプリントでも同じ形が再現した。

context window の大きさ

conductor の 5 セッションを束ねた値。supervisor と worker は claude -p の別プロセスで動き、このセッションの記録には含まれない（費用は上の各フェーズの報告にある）。

層	フェーズ	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	目印
conductor	-	claude-opus-5-5	5	45278	95184	0	207184	割る候補

層	件数	固定費の合計	実作業の合計	総消費
conductor	5	226124	513001	739125
合計	5	226124	513001	739125

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

• conductor の「割る候補」: そのままにする。中継が周回を 5 セッションに分けて切っており、上限の目安 200,000 を超えたのは 1 セッション（207,184）の 1 回だけである

用語集の変化

glossary.py diff（PR #2485 の base から PR #2490 のマージまで）: 変化は無い。

承認ゲートの差し戻し

gate-rejections.py count（周回の状態ファイル）: 関門 1 が 0 件・関門 2 が 0 件。

MVV を見直すか

project-mvv.py signals（版 5）: 覆し 2 件（閾値 3。「反する疑い」か「判定できない」を人が通した 2 件）・判定できない 0 件（閾値 5、続けて 0 回・閾値 3）・流出不具合 0 件（閾値 3）。閾値を超えた兆候は無く、見直さない（判断の記録 507485571884）。

次に変えること

変えること	落とし先	状態
cross-review が未解決 0 件のまま上限に当たったとき、検査ごと落とさずに次の工程へ進める	次の変更で試すこと	#2370 として起票済み。このスプリントの #2485 で再現した
検査の記録から閾値を見直せるようにする（落ちた工程・流出の記録）	次の変更で試すこと	#2300 として起票済み
設計のプランで、要求の文書を書く前の要求の検査の終了コード 2 を、承認ゲート 1 の材料の欠けと読まない	次の変更で試すこと	#1502 ・ #2237 として起票済み。設計 #2405 で再現した

新しく起票するものは無い。3 件とも既存の課題が扱っており、別の課題に分けると同じ修正の場所を指す課題が増える。

途中で起票した課題

番号	何を見つけたか	見つけた場面
#2441	1 台の中のオーガナイザーが、Factory などの外の本番の Pull Request が開いている間は配布を組まずに待つ	設計中（#2439）
#2453	設計の結果の触るファイルが、分割した設計文書へのリンクを辿らず、実装のプランから変更対象が抜ける	設計中（#2439）

起票の取りこぼし: issue-file.py by-origin（起点の課題 3 件と PR #2483・#2484・#2485・#2488・#2490）で上の 2 件が見つかった。実装の PR #2483 に残した設計との違い 2 件は、確定仕様が実装と同じ形で書かれていること（1 件目）と、テストの追加だけで振る舞いは設計の決定 9 に合っていること（2 件目）から、起票の条件（利用者へ届いた不具合など）に当たらないと判断した。