Repository navigation
スプリント m1914 - #2133
スプリント m1914#2133
Conversation
雛形の経路で本番のブランチがあれば、配布の後に「関門 2」（gate）と「本番」（release-prod、
then_of なし）を置く。本番のプランは plan_sprint_release にチャネルと版を渡して組み、
出す PR は {queue_pr:check}、MVV 判定は置かない。承認ゲート 2 の文は関門 2 の gate へ移し、
本番のブランチが無いときは今のまま配布で終えて next に理由を書く。
sprint.py の 500 行の上限のため、利用者の承認の文の関数を sprint_waves.py へ移した。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
waiting.md の手順 8・9、agent-layers.md の仕上げ・リリースの行、relay.md の例を、 new sprint が書き出す「関門 2」と「本番」のステージに合わせた。本番のプランを new release --channel prod で手で作る記述は、単発のリリースの説明だけに残す。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
merged-steps.py promote に --expect-head-from <導入の確認の承認資料> を足し、資料の確かめたコミットを merge-when-green の --expect-head と同じ照合に使う。読めなければ gh を呼ばずに 2 で止まる。 昇格のプランの fast / auto の promote は、mvv と同じ VERIFY_MATERIAL を渡し、落ちたら handoff で承認ゲート 2 へ戻る。 確かめたコミットの行の形と読み取りは lib/approved_commit.py の verified_line / verified_sha に置き、verify_markdown もそれで書く。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
着手前のテストの後に、scope_command を持つテストの suite ごとにテストのファイルを最大 2 本入れて 1 回走らせる。判定が ok でなければ、当たった suite・今のテンプレート・入れたパス・直す箇所を出し、 状態ファイルを作らずに終了コード 4 で止まる。記録は <tmp_dir>/template-check.json と状態ファイルの template_checks に残す。 - test_strategy: probe_paths / template_verdict / ProbeVerdict（選び方と判定の純粋な関数） - refactor_lib/template_check.py: 候補の収集・実行・記録（新設） - commands/setup.py: _verify_init から呼び、記録を状態へそのまま置く - 既存の init のテストは試走を対象なしとして通し、試走は test_template_check.py で見る Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…に書く（#1630） - project_lib/model.py の Suite の説明に、改修の範囲テスト・CI に任せる戦略の着手前のテスト・静的解析ごとの {paths} に入るパスと、init の試走で止まることを書き、project.schema.json を作り直した - project-analysis.md の test の行に、unittest を例にファイルを受ける scope_command の書き方と、手元で確かめた終了コードを書いた - cross-refactoring の SKILL.md の終了コード 4 の理由に、テンプレートの試走で止まる場合を足した Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- verify_commands は種別・雛形の誤りを先に当て、strategy を書かずどの suite も command と
scope_command を持たない宣言（{"suites": []} を含む）では None を返す
- 最終スイープの指示を組めないときの Stop の理由文に止めた所を名指しする
- 駆動の件数へ最後のラウンドの継続的統合の判定 ci と理由 ci_reason を足す
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
結果 JSON が stopped で metrics.exit が整数のとき、止まった理由の要約の後ろへ 「（元の終了コード N）」を添える。abort へ回したときの直前のステップの要約にも当てる。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
drive.py の先頭で review_lib を読むと、scripts/ を sys.path に持たない呼び出し元 （supervise のテストなど）で読み込みが失敗する。review_paths と同じく counts の中で読む。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
check-script-structure の same-name 違反（_candidates / run / summary）を解く。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
promote の --expect-head-from の説明を詰め、script-structure の行数の上限を超えないようにする。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…#1529） Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#1914 を実装する（スプリント m1914）
#1630 を実装する（スプリント m1914）
#1529 を実装する（スプリント m1914）
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#1593 を実装する（スプリント m1914）
手順 0 の check が「古い」（解析器の版 1 < 2・ワークフローと指示書の変更）を返したため、 measure → 答え → write を通した。手の値（test・delivery・issues・ndf_policies）は引き継いだ。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
supervise の中で全体テストを走らせると、NDF_USAGE_SOURCE / NDF_USAGE_KIND が入ったまま test_runtime_specific_usage_shapes が「名乗りが無い」ことを確かめて落ちる。fixture の fake_clis で 4 つの NDF_USAGE_* を外す。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fix: test_usage_capture の偽の CLI に呼び出し元の環境変数を持ち込まない
…#compare_approved 段 3（配布の PR の外のコミット I3）を _outside_of_prs、段 4（先端までの外のコミット I9）を _outside_to_tip として抽出した。読めないときは None を返し、compare_approved は undecidable を返す。 Item-Id: I-001 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…rge_when_green マージの実行部（pin の組み立て・gh pr merge・競合の判定・失敗の emit・merged の記録）を _merge_pr として抽出し、merge_when_green から呼ぶ形にした。 Item-Id: I-002 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ts/refactor_lib/template_check.py#_check_one 試走の起動部（残り時間の判定・run_within・launch.stop）を _run_probe として抽出し、 (結果, 走らせなかった理由) を返す形にした。記録の辞書の組み立ては _check_one の末尾に残した。 Item-Id: I-003 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…commit.py#verified_sha 確かめたコミットの行の前後の文言を _VERIFIED_HEAD / _VERIFIED_MID / _VERIFIED_TAIL に置き、 書く側の verified_line と読む側の _VERIFIED_RE をこの定数から組み立てるようにした。 Item-Id: I-004 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…y#no_prod_stage 本番のブランチの有無の判定を has_prod_branch として抽出し、sprint_plans の分岐と no_prod_stage の両方から呼ぶ形にした（評価の順序は変えていない）。 Item-Id: I-005 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…/sprint_waves.py#user_gate_cmd sprint_state_path を sprint.py から sprint_waves.py へ移し、sprint_waves.py の str(Path(a.state).resolve()) の 4 か所をこれに置き換えた。sprint.py は sprint_waves から読み込む。 Item-Id: I-006 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ring/scripts/refactor_lib/template_check.py#_reference 試走の基準の値を test_strategy.py の REFERENCE_GREEN / REFERENCE_RED / REFERENCE_NONE に置き、 template_verdict の比較と _reference の戻り値・比較をこの定数へ置き換えた。値は変えていない。 Item-Id: I-007 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…robe_roots paths の要素の正規化を _root_of、全体を指すかの判定を _is_whole_root として抽出し、 _declares_whole と probe_roots の両方から使う形にした。 Item-Id: I-008 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ine.py#_result_summary
metrics を先に 1 度だけ読み、isinstance の判定と重なっていた `or {}` を外した。
Item-Id: I-009
Impl-Runtime: claude
Impl-Model: claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…toring/scripts/refactor_lib/template_check.py#check_templates check_templates が _check_one へ渡す文字列キーの dict を、frozen の dataclass _ProbeContext に 置き換え、_check_one の ctx["..."] を属性参照にした。 Item-Id: I-010 Impl-Runtime: claude Impl-Model: claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_VERIFIED_RE の組み立てを ruff format の形（1 行）へ整えた。中身の式は変えていない。 Item-Id: I-004 Impl-Runtime: claude Impl-Model: default
…proved lint の違反は approved_commit.py の _VERIFIED_RE（I-004 の行）の整形だけで、I-004 の修正で解消した。 compare_approved の抽出（I-001）には直す箇所が無いため、変更の無いコミットで記録する。 Item-Id: I-001 Impl-Runtime: claude Impl-Model: default
…r_gate_cmd sprint_state_path を足した sprint_waves.py が 503 行になり、行数の上限（500 行）を超えた。 sprint_state_path を新しいモジュール supervise_lib/state_path.py へ移し、sprint_waves.py と sprint.py はそこから読み込む。本体は変えていない（500 行に収まる）。 Item-Id: I-006 Impl-Runtime: claude Impl-Model: default
…r_gate_cmd 前回の修正で足した supervise_lib/state_path.py が、パッケージのモジュール一覧の設計 （test_supervise_layout の test_package_has_the_designed_modules）に無いため落ちた。 sprint_state_path を既存の supervise_lib/plan.py（supervise_lib を何も import しないので 循環しない）へ移し、state_path.py を消す。sprint.py と sprint_waves.py は plan から読み込む。 本体は変えていない。 Item-Id: I-006 Impl-Runtime: claude Impl-Model: default
改修計画 — devbasex/ai-plugins #2133
改善項目I-001 —
|
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| long_method | extract_method | major | high | claude | 採用 | 2 |
なぜ: docstring の 5 段（読める・祖先・配布の PR の外のコミット I3・先端までの外のコミット I9・木の比較）を 1 関数で通しで行い、認知的複雑度が対象範囲で最大の 32。段 3・4 の外のコミットの集め方だけが反復と内包を重ね、ここが読む負荷の大半を占める
手順: 1. 段 3 を _outside_of_prs(root, approved, allowed) -> list[str] | None（None は読めない）として抽出する
2. 段 4 を _outside_to_tip(root, approved, tip, allowed) -> list[str] | None として抽出する
3. compare_approved は outside = _outside_of_prs(...)、None なら v を返し、空なら _outside_to_tip(...) を呼ぶ形にする
4. 段 5（木の比較）は短いので残す
5. test_approved_commit.py と test_release_approved_commit.py を走らせる
I-002 — plugins/ndf/scripts/merged_lib/merge.py#merge_when_green
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| long_method | extract_method | major | medium | claude | 採用 | 1 |
なぜ: 1 関数に宛先の判定の差し込み・待ち・gh pr merge の実行と失敗の扱い・マージの記録・後片付けの分岐が同居している（55 行・認知的複雑度 17）。マージの実行部は待ちとも後片付けとも別の理由で変わる（--expect-head の照合や --match-head-commit の扱い）
手順: 1. if not any(... already_merged ...) の中身（pin の組み立て・gh pr merge・競合の判定・失敗の emit・merged の記録）を _merge_pr(root, a, n, watch, items, waits) として抽出し、items への追記をそこで行う
2. merge_when_green から呼ぶ形に書き換える
3. test_sprint_close_merge_green.py と merge-when-green を通すテストを走らせる
I-003 — plugins/ndf/skills/cross-refactoring/scripts/refactor_lib/template_check.py#_check_one
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| long_method | extract_method | major | medium | claude | 採用 | 1 |
なぜ: 1 関数に候補の選定・直す箇所の決定・基準の判定・上限の残りの計算と試走の起動・判定・記録の辞書の組み立てが同居している（認知的複雑度 13・44 行）。試走の起動部（残り時間の判定・run_within・launch.stop）だけが入れ子の分岐を持ち、他の段階と変わる理由が違う
手順: 1. 試走の起動部を _run_probe(command, work, log, budget) -> tuple[Optional[ts.Outcome], str]（結果と not_run の理由）として抽出する。command が None なら (None, NO_FILES)、残りが 1 秒未満なら (None, NO_TIME)
2. 記録の辞書の組み立てを _row(suite, pick, index, fix_at, command, result, reference, verdict, log) へ移すか、_check_one の末尾に残す（引数が増えすぎるなら残す）
3. _check_one から 1 を呼ぶ形に書き換える
4. test_template_check 系（check_templates を通すテスト）を走らせる
I-004 — plugins/ndf/scripts/lib/approved_commit.py#verified_sha
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| duplication | consolidate_duplication | minor | medium | claude | 採用 | 2 |
なぜ: 確かめたコミットの行の形が、書く側の verified_line の f-string と読む側の _VERIFIED_RE の正規表現に 2 回書かれている。文言を片方だけ直すと、書いた資料を verified_sha が読めず promote が EXIT_UNREADABLE で止まる
手順: 1. 行の前後の文言を _VERIFIED_HEAD = "- ベースブランチ " / _VERIFIED_MID = " の先頭: "/_VERIFIED_TAIL = "。導入の確認はこのコミットで走らせた" の定数に分ける
2. verified_line をこの定数から組み立てる
3. _VERIFIED_RE を re.escape した定数から組み立てる（\S+ と ([^]*)` の部分はそのまま）
4. test_approved_commit.py の verified_line → verified_sha の往復のテストを走らせる
I-005 — plugins/ndf/scripts/supervise_lib/sprint.py#no_prod_stage
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| duplication | extract_method | minor | medium | claude | 採用 | 1 |
なぜ: 『本番のブランチが無いので本番のステージを置かない』の条件 not getattr(a, "production_branch", None) が sprint_plans の分岐と no_prod_stage に別々に書かれている。no_prod_stage は sprint_plans がその分岐を通ったかを言い直しているだけで、片方の条件が変わると next の文とステージの組み立てが食い違う
手順: 1. has_prod_branch(a) -> bool（bool(getattr(a, "production_branch", None))）を抽出する
2. sprint_plans の分岐を if not has_prod_branch(a): に書き換える
3. no_prod_stage を pace == "normal" and not closing and has_release_template(a) and not has_prod_branch(a) に書き換える
4. test_supervise.py / test_supervise_new.py を走らせる
I-006 — plugins/ndf/scripts/supervise_lib/sprint_waves.py#user_gate_cmd
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| duplication | consolidate_duplication | minor | medium | claude | 採用 | 3 |
なぜ: 状態ファイルの絶対パス str(Path(a.state).resolve()) が sprint_waves.py に 5 か所（user_gate_cmd・advise_design_steps・plan_mvv_design の 2 か所・handoff_step の引数）ある。sprint.py には同じ処理の sprint_state_path があり、この PR で user_gate_cmd を sprint.py から移したときに sprint_state_path(a) が手書きの式へ戻った。同じ知識が 2 つのモジュールに分かれ、片方だけ直されうる
手順: 1. sprint_state_path を sprint.py から sprint_waves.py へ移す（sprint_waves は sprint を import しないので循環は起きない）
2. sprint_waves.py の 5 か所の str(Path(a.state).resolve()) を sprint_state_path(a) に置き換える（shlex.quote で包む箇所は包んだまま）
3. sprint.py は sprint_waves から sprint_state_path を import し、自前の定義を消す
4. test_supervise / test_supervise_new / test_supervise_pace_verify を走らせ、書き出すプランが変わらないことを確かめる
I-007 — plugins/ndf/skills/cross-refactoring/scripts/refactor_lib/template_check.py#_reference
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| magic_value | introduce_named_constant | minor | medium | claude | 採用 | 1 |
なぜ: 試走の基準の値 "green" / "red" / "none" が _reference（template_check.py）と template_verdict（test_strategy.py の reference == "green"）に文字列のまま書かれ、組の定義が無い。読み手と書き手が別モジュールにあり、片方の綴りが変わっても気づけない
手順: 1. test_strategy.py の PROBE_* の並びに REFERENCE_GREEN = "green" / REFERENCE_RED = "red" / REFERENCE_NONE = "none" を置く
2. template_verdict の比較と、_reference の戻り値・比較をこの定数へ置き換える
3. 値は変えない（記録の JSON の reference の値は同じ）
4. test_lib_test_strategy.py と template_check のテストを走らせる
レビューで確かめるテストの差分: plugins/ndf/scripts/lib/test_strategy.py（機械で期待値が変わったか決まらなかった）
I-008 — plugins/ndf/scripts/lib/test_strategy.py#probe_roots
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| duplication | extract_method | minor | low | claude | 採用 | 1 |
なぜ: suite の paths の要素を str(p).strip().rstrip("/") で正規化して (".", "") を全体とみなす規則が、_declares_whole と probe_roots に別々に書かれている（どちらもこの PR で追加）。『全体を指す paths の要素』の判定が 2 か所に分かれる
手順: 1. _root_of(p) -> str（strip と末尾の / を外す）と _is_whole_root(r) -> bool（r in (".", "")）を抽出する
2. _declares_whole を not suite.paths or any(_is_whole_root(_root_of(p)) for p in suite.paths) に書き換える
3. probe_roots を _root_of と _is_whole_root を使う形に書き換える
4. test_lib_test_strategy.py の probe 系のテストを走らせる
レビューで確かめるテストの差分: plugins/ndf/scripts/lib/test_strategy.py（機械で期待値が変わったか決まらなかった）
I-009 — plugins/ndf/scripts/supervise_lib/engine.py#_result_summary
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| deep_nesting | flatten_conditional | minor | low | claude | 採用 | 1 |
なぜ: code = (res.get("metrics") or {}).get("exit") if isinstance(res.get("metrics"), dict) else None は metrics を 2 回読み、or {} が isinstance の判定と重なって冗長。1 行に条件式と短絡が重なり、何を確かめているかが読みにくい
手順: 1. metrics = res.get("metrics") を先に取り、code = metrics.get("exit") if isinstance(metrics, dict) else None に分ける
2. 戻り値の判定はそのまま
3. test_supervise_stop_exit.py を走らせる
I-010 — plugins/ndf/skills/cross-refactoring/scripts/refactor_lib/template_check.py#check_templates
| 兆候 | 手法 | 重要度 | 等級 | 提案元 | 状態 | コミット |
|---|---|---|---|---|---|---|
| primitive_obsession | introduce_parameter_object | minor | low | claude | 採用 | 1 |
なぜ: check_templates が baseline・work・scope・decl・flag・tmp_dir を文字列キーの dict（ctx）に詰めて _check_one へ渡し、_check_one は ctx["baseline"] などの文字列キーで取り出す。キーの綴り違いは実行時まで分からず、どの値が入るかが型から読めない
手順: 1. @dataclass(frozen=True) class _ProbeContext: baseline, work, scope, decl, flag, tmp_dir を定義する
2. check_templates で dict の代わりに _ProbeContext を作る
3. _check_one の ctx["..."] を属性参照へ置き換える
4. テストを走らせる
指標の測定
- 状態: written / 言語とツールの対応: 既定（.ndf/code-metrics.json は無い） / 所要: 50.2 秒（使えた時間 270 秒 / 上限 270 秒）
- 指標のファイル: /tmp/ndf-worktrees/devbasex--ai-plugins/rf2133/work/.cross_refactoring/code-metrics-rf2133.md
| 言語 | ツール | 版 | ランナー | ファイル | 秒 | 結果 |
|---|---|---|---|---|---|---|
| python | ruff-complexipy | ruff 0.16.9 / complexipy 8.0.1 | uvx | 378 | 1.1 | 測った |
| shell | — | — | — | 13 | — | unsupported_language |
| 重複: python | symilar | pylint 4.0.9 | uvx | 378 | 44.7 | 測った（38 箇所） |
| 重複: shell | jscpd | jscpd 4.3.0 | npx | 13 | 3.3 | 測った（0 箇所） |
時間の上限
| 値 | 中身 |
|---|---|
| 提案の枠の終わり（監視の上限 = 残り + 余裕） | 2026-10-25T05:00:57+00:00 |
| 改修計画の枠の終わり（同上） | 2026-10-25T05:09:57+00:00 |
| テストの追加の終わり = 実装の終わり − Σ（採っていて未検証の項目の実装の見積り） | 2026-10-25T05:12:53+00:00 |
| 実装の終わり = 最終ゲートの修正の打ち切り − バッファ − Σ（採っていて未検証の項目の検証の見積り） | 2026-10-25T05:25:53+00:00 |
| 直しの試行の打ち切り | 2026-10-25T05:33:23+00:00 |
| 想定最大時間の終わり H（子プロセスはすべてここまでに止まる） | 2026-10-25T05:48:48+00:00 |
| 確かめの開始の締め切り = H − 確かめの見込み（最終ゲート修正と打ち切りの後の取り消しもここまで） | 2026-10-25T05:38:53+00:00 |
| 確かめの見込み（秒。最終ゲートの確かめ 1 回。バッファの最終ゲートの全体テスト） | 595 |
| 最終ゲート修正 1 回の見込み（秒。バッファの final_fix。起動は今 + この値が確かめの開始の締め切り以前のときだけ） | 330 |
| 指標の測定の上限（秒。提案の枠の中から割く） | 270 |
| 着手前のテスト 1 回の上限（秒） | 1272 |
| 範囲テスト 1 回の上限（秒） | 1783 |
| 手元の全体テスト 1 回の上限（秒） | 1272 |
| CI の待ちの上限（秒） | 888 |
| 余裕（秒。手順の上限と CLI の上限に足す） | 270 |
入力: 予算 90 分 / 全体テストの所要 w 424.0（ci-steps） / 着手前の実測 x 594.2 / CI の壁時計 c 296.0 / 範囲テストの所要 s None（—） / 戦略 local-full
無音の打ち切りは手順の監視の上限と同じ値である。項目ごとの期限は持たない（実装を止めるのは実装の終わりだけ）。
見送った提案
（なし）
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 1 | claude | REQUEST_CHANGES
pace: normal で新しく置いた「関門 2」のステージの文が、承認の記録（release-steps.py approve）を書く手順を持たないため、文どおりに「本番」を打つと本番のプランが release のステップで承認ゲートに止まる。1 件を直す。
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 1 | claude-2 | REQUEST_CHANGES
pace: normal の new sprint に足した「関門 2 → 本番」の経路で、承認の記録（release-steps.py approve --by user）を書く手順がどこにも無く、本番のプランが bump〜snapshot を済ませた後の release で承認ゲート（10）に止まる。関門 2 のステージの文に approve の手順を足す。
本番のプランの release --channel prod --approval は承認資料に承認の記録が無いと gate（10）で止まるため、 承認されたら approve で記録してから「本番」のステージの command を打つ形にする（PR #2133 のレビュー指摘）。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
develop の design_read で sprint_waves.py が 505 行になり（上限 500）、sprint.py の HERE が使われなくなった。 関門の文の関数（user_gate_cmd・normal_gate_1・normal_gate_2・normal_gate_2_stage）を sprint_routes.py へ移し、 sprint.py の使われない import を外す。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | round 1 | commit 2889d45対応件数: critical=0 / major=2 / minor=0（合計 2 件） CI は develop とのマージ結果で失敗していた（sprint_waves.py が 505 行・sprint.py の HERE が未使用）。develop を取り込み、関門の文の関数を sprint_routes.py へ移して直した。手元で全テスト 5734 件・lint・構造チェックが通る |
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 2 | claude | REQUEST_CHANGES
関門 2 のステージの文が承認資料を相対パス（issues/approval--v.md）で渡すため、approve の解決先が conductor の作業場所の git の根に依存する。本番のプランと同じリポジトリの根からの絶対パスにする 1 件を直す。
差分の外を指す指摘
plugins/ndf/scripts/supervise_lib/sprint_routes.py:930[major] [major / 正確性]normal_gate_2_stageが承認資料をissues/approval-<plugin>-v<prod>.mdの相対パスで approve へ渡している。approveは相対パスを作業場所の git の根（git_root）から解くため、conductor が worktree（AGENTS.md が作業場所とする.worktrees/<ブランチ>）で打つと、開発版の facts（cwd: repo）が書いたメインディレクトリの資料ではなく worktree 側を探して失敗し、承認の記録を書けない。同じ資料を本番のプランの release は<repo>/issues/...の絶対パスで読んでいるので、normal_gate_2_stageに repo を渡し、文の資料のパス（提示する資料と--approval）を{repo}/issues/approval-...mdの絶対パスにする。
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 2 | claude-2 | APPROVE
round 1 の指摘（関門 2 のステージの文に承認の記録 release-steps.py approve を本番の前に打つ手順が無い）は 2889d45 で normal_gate_2_stage に入り、テストも順序を縛っている。範囲の 42 ファイルに、基準に当たる新しい指摘は無い。
normal_gate_2_stage が承認資料を相対パスで approve へ渡していたため、worktree で打つと 作業場所の git の根から解かれ、開発版の配布が書いた資料を見つけられなかった。 本番の release と同じ material_path で絶対パスにする。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | round 2 | commit b830399対応件数: critical=0 / major=1 / minor=0（合計 1 件） レビュー本文の指摘への返事:
|
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 3 | claude | APPROVE
round 2 の指摘（関門 2 の文の承認資料を相対パスで渡す）は b830399 で normal_gate_2_stage が material_path(repo, ...) の絶対パスを使う形になり、テストも絶対パスを縛っている。範囲の 43 ファイルに、基準に当たる新しい指摘は無い。
takemi-ohama
left a comment
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 3 | claude-2 | APPROVE
round 2 の指摘（関門 2 の文の承認資料が相対パス）は b830399 で material_path による /issues/approval--v.md の絶対パスになった。repo は本番のプランの release と同じ値（sprint_plans の worktree の解決）で、fixture も一致する。範囲の 43 ファイルに、基準に当たる新しい指摘は無い。
🔧 /ndf:fix サマリ | commit (なし)対応件数: critical=0 / major=0 / minor=0（合計 0 件） |
|
配布の verify で見つけた範囲外の不具合を、#2140 として残した。 |
スプリント m1914 の課題を develop へ取り込む。
利用者向けの変化
pace: normalのnew sprintは、承認ゲート 2 と本番のステージを含むスプリントの目録を書き出す（#1914 を実装する（スプリント m1914） #2122）sprint.jsonを持つ進行中のスプリントでは、new release --channel prodで本番のプランを作れる（#1914 を実装する（スプリント m1914） #2122）cross-refactoringの init は、範囲テストのテンプレートを試しに走らせます。ファイルを受け取らないテンプレートであれば、init はそこで止まります。（#1630 を実装する（スプリント m1914） #2123）development-workflowの宣言の契約に、{paths}に入るパスの種類が書かれています。（#1630 を実装する（スプリント m1914） #2123）development-workflowの宣言の契約に、ファイルを受けないランナーの書き方が書かれています。（#1630 を実装する（スプリント m1914） #2123）移行の手順
課題と設計
コミット
変更の統計
テスト（supervise.py の run のステップ）
集めた実装の PR
閉じる課題
Closes #1529
Closes #1593
Closes #1630
Closes #1914
手動確認
pace: normalのスプリントの承認ゲート 2 の後に、conductor がsprint.jsonの本番のステージのcommandだけで本番の配布を流せたか（リリース後テストで確かめる）discover -s {paths}を宣言に書いた再現のリポジトリ（または takemi-ohama/novel の写し）で/ndf:cross-refactoringを走らせ、受け入れ条件 1・2 の止まり方と出力を見るsupervise.py queueで流し、報告を見る。リリース後テストで確かめるモード: standard / 通した工程: 実装 → Pull Request
🤖 Generated with Claude Code