docs: WP-18 の運用問題 5 件と feedback 採用分 10 件を登録し計画書を再編成 - #384
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughWP-17/WP-18の状態と完了条件を更新しました。運用上の問題を整理し、関連タスク、検証規約、安全装置、hook制御の計画を追加しました。 ChangesWP-17/WP-18運用ドキュメント
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
diff 概要
Applicable Findings (Critical / High / Major)該当なし(指摘が存在しないため) Applicable Findings (Medium 以下)該当なし Filtered (not applicable)該当なし 次のアクション
|
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/harness-improvement-plan.md`:
- Around line 213-214: WP-18 の完了条件を更新し、未確定スモーク (a)/(b) の扱いを明示する。Phase B 本体への到達と
coderabbitai[bot] allowlist
の要否について、完了要件に含めるか、非ブロッカーとして除外する場合は見送りまたは移管先と期限を併記し、採用率測定およびスモーク (c)
に関する既存条件との整合性を保つ。
In `@docs/todo-summary2.md`:
- Line 161: 順位411の要約を詳細計画と整合させ、`docs/todo-summary2.md`
の「正しいコマンドを提示」を「正しい対処を提示」に変更してください。`docs/todo21.md`
の計画に代替コマンドを追加する変更は行わず、既存の非適用理由・最小修正・例外判断を含むメッセージ方針に合わせてください。
In `@docs/todo21.md`:
- Around line 308-316: 完了判定と report コピーを対象 PR に紐づけ、別 PR
の結果を採用しないよう更新してください。`copy_feedback_report` では最新 run を選ぶだけでなく `pr_number` が一致する
report のみをコピーし、`run_takt_workflow` の成功終了に加えて task
label、`context.json`、report、reconciliation の PR 番号一致を検証して完了と判定してください。timeout
や失敗終了は完了扱いにしないでください。
- Around line 522-545: 既存のカスタムルール設定を確認し、旧語彙の reject 対象 extensions に yaml を含めて
rs、toml、yml と同様に YAML 設定ファイルも検査対象にする。作業計画の extensions 指定と完了基準を更新し、YAML config
内の旧語彙も hook が reject する挙動を明記する。
- Around line 611-633: 作業計画と完了基準で、cargo fmt の検出対象範囲を明確に定義してください。cargo fmt
の完全一致のみをブロックする場合は、その限定を明記し、cargo fmt --all
などを対象外として扱うことを示してください。複数の実行形態を拒否する場合は、正規化・解析方針と対応する fixture 追加を basic.rs
のルールおよび関連テスト計画に反映してください。
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1e36bbb1-1dbe-40e8-87e0-5b0fe8c04816
📒 Files selected for processing (3)
docs/harness-improvement-plan.mddocs/todo-summary2.mddocs/todo21.md
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)
Applicable Findings (Medium 以下)
Filtered (not applicable)該当なし 次のアクション
|
あわせて post-merge feedback (#376/#377/#380/#381/#382) の採用分 10 件を順位 402-411 へ 登録した。2026-08-10 に採用候補を系統別へ分類し、ユーザーが採否を決定したもの。 採用: 系統 A (観測の完全性) 3 件 / 系統 B (重複実装の予防) 3 件 / 系統 C (shell・config パースの安全性) 3 件 却下: 系統 D (workflow セキュリティ標準化) / 系統 E (PAT 失効監視) — 様子見 形を変えて採用: 系統 F — 「CLAUDE.md に rustfmt 非適用の方針を書く」ではなく 「cargo fmt を PreToolUse でブロックする」(順位 411) 系統 F の変更理由 (ユーザー判断): 規約は CLAUDE.md に書いた時点で毎セッション読まれ コンテキストを圧迫するが、PreToolUse hook は発火するまでコストがゼロで、ブロックと 同時に正しいコマンドをフィードバックできる。読み手は規約を覚えていなくても正しい経路へ 到達する。ADR-042 の mechanizable 判定を満たすため機構側が正しい。 **この非対称は現行 ADR-042 に無い**。同 ADR の判断基準は「機械判定できるか」「投資対効果」 が中心で、「規約は常時コンテキストを消費し hook は発火時のみ」という観点が明示されて いない。ルール追加を検討するたびに効く一般則なので、順位 411 の作業範囲に ADR-042 への 追記を含めた。 ## 計画書 (harness-improvement-plan.md) の WP-18 節を再編成 **WP-18 で生んだ問題と、WP-18 の運用で日常的に踏む問題を WP-18 の外へ押し出さない** (2026-08-10 ユーザー方針) ため、残作業を 3 区分へ分けて完了条件を明示した。 従来は観測と派生タスクが 1 表に混在し、WP-18 の完了に何が要るのかが読み取れなかった。 - (1) 観測待ち — 機構は整備済みで事象か期限を待つもの - (2) 運用問題の対処 — WP-18 が生んだ (基準 1) / WP-18 の運用で踏む潜在バグ (基準 2)。 順位 397 / 398-400 / 401 / 410。**完了条件に含める** - (3) WP-18 外の派生 — 順位 396 / 411 / 402-409 等。完了条件に含めない (3) を完了条件から外すのは、§ 7 の退役条件が「全 WP が完了または見送り」である以上、 リポジトリ全体の一般則を WP-18 に紐づけると計画書が永久に退役できなくなるため。 ただし**優先度が低いという意味ではない** — 順位 396 (flaky テスト) と 411 (cargo fmt ブロック) はいずれも高優先度で、WP-18 とは独立に早期着手する旨を明記した。 あわせて古い記述を実測に合わせた: - 見出しの「実装・スモークは 2026-08-08 までにほぼ完了」→ 決定 16 という新規実装が 2026-08-10 に入ったため「観測中 + 運用問題の対処中」へ - 「前 2 者は順位 394 後の run で判定できる」→ 順位 394 は完了済みで実際の前提は決定 16。 同一ファイル内の自己矛盾だった - WP-17 残課題節にも同じ「順位 394 後の run」が残っていたため同期。あわせて 「代替解は draft 廃止」が誤りだったことも記録した ## todo 側 - 順位 396 を Tier 2 → **Tier 1** へ格上げ (ユーザー判断)。単発の Severity では Tier 2 相当だが、flaky テストは「また flake だろう」という読み替えを生み実バグの見落とし 経路になるため。両 OS matrix (ADR-065) の信号品質を守る意味で早期に潰す - 順位 411 に早期着手の根拠を追記 (cargo fmt は反射的に実行されやすい) - **却下を negative result として記録**: 系統 D / E は様子見。trunk 保護の drift 対処 2 件は却下 (予防側は順位 405 で押さえた / 共有 lib 化は network isolation 設計と 抵触しうる)。**再採用条件は「同型の drift が今後も再発する場合」**と明記した --- CodeRabbit レビュー対応 (#384、5 件すべて修正) --- 1. WP-18 完了条件でスモーク未確定の扱いが不明確 (Major) (c) だけを非必須と書き (a)(b) の扱いが無かった。(a)(b) は事象待ちで**自力で発生させ られない**ため、条件に含めると WP を閉じられない。3 件すべてを非ブロッカーとし、 理由と移管先・期限を表で明記した。(a)(b) は 2026-11-06 時点で未観測なら 「機会が来なかった」として見送り ADR-067 の bounded lifetime へ委ねる。 2. 順位 411 の要約が詳細計画と不一致 (Minor) summary は「正しいコマンドを提示」だが、cargo fmt に**代替コマンドは存在しない** (手で直すのが正)。「正しい対処を提示」へ変更し、詳細側にもその旨を明記した。 3. 順位 398 の完了判定を対象 PR に束縛すべき (Major) 「report 生成を完了根拠にする」案が不十分だった。copy_feedback_report は find_latest_run_dir で最新 run を選ぶだけで **pr_number と照合していない**ため、 別 PR の report を現在の PR の {pr_number}.md へコピーし得る。また takt の終了は timeout や失敗でも起こるので終了した事実は report 完成を証明しない。実装を読んで 裏付けたうえで、完了判定には「成功終了」と「対象 PR のものであること」の両方が 要る旨を追記した。本セッションで実際に context.json が別 PR を指していた事象とも 同型である。 4. 旧語彙 lint の extensions から yaml が漏れている (Minor) 拡張子は eq_ignore_ascii_case の文字列一致で **yml と yaml は別物**。本リポジトリは .github/workflows/*.yml と .coderabbit.yaml の両方を持つため、yaml を落とすと 後者が未検査になる。両方を対象に加え、理由も併記した。 5. cargo fmt の検出対象が未定義 (Major) 完全一致だけでは cargo fmt --all / cargo +stable fmt / rustup run stable cargo fmt / cargo-fmt が素通りする。作業計画の先頭に「検出範囲を先に決める」を追加し、完了基準に 「完全一致に限定する場合は素通りする形態を明記する」ことを求める形にした。 いずれも実物 (takt.rs の実装 / linter の拡張子判定 / リポジトリ内の .yml と .yaml の 共存) を確認したうえで妥当と判断している。
88ce812 to
3857039
Compare
CodeRabbit レビュー対応 (5 件すべて修正)
1. スモーク未確定の扱いご指摘のとおりでした。(c) だけを非必須と書き、(a)(b) の扱いが抜けていたため、そのままでは完了条件を満たせません。 3 件すべてを非ブロッカーとして扱い、理由と移管先・期限を表で明記しました。特に (a)(b) は 事象待ちで自力では発生させられない(docs 指摘の出る夜間 PR に当たるまで観測できない)ため、条件に含めると WP を閉じられなくなります。2026-11-06 時点で未観測なら「機会が来なかった」として見送り、ADR-067 の bounded lifetime へ委ねる形にしました。 3. 完了判定の PR 束縛 — 実装を読んで裏付けましたこれは重要な指摘で、私が書いた対処案がそのままでは不十分でした。 // src/cli-merge-pipeline/src/feedback/takt.rs
pub fn copy_feedback_report(repo_root: &Path, pr_number: u64) -> Result<PathBuf, String> {
let latest = find_latest_run_dir(&runs_dir, TAKT_WORKFLOW) // ← 最新 run を選ぶだけ
.ok_or("post-merge-feedback の run dir が見つかりません")?;
...
let target = target_dir.join(format!("{}.md", pr_number)); // ← 番号は出力先にしか使わない
本セッションで実際に同型の事象が起きています — #382 の marker が出た時点で 4.
|
Summary
Context
Why (運用問題): 2026-08-10 に夜間ループの PR を人間がマージする経路を初めて通したところ、5 件の運用問題が出た。実装が終わっても運用が回るとは限らないことの実例で、いずれもこのセッションまで記録されていなかった。
pnpm merge-prが夜間 PR (remote 専用ブックマーク) を検出できない。gh pr mergeは hook でブロックされるため逃げ道が無い--feedback-onlyが同じガードに阻まれ復旧手段として機能しないWhy (計画書の再編成): 従来の残作業表は観測と派生タスクが 1 表に混在し、WP-18 の完了に何が要るのか読み取れなかった。2026-08-10 のユーザー方針「WP-18 で生まれた問題は WP-18 で処理する / 潜在バグでも使い勝手に影響するなら WP-18 のうちに直す」を、判定基準つきの 3 区分として実装した。
(3) を外したのは、§ 7 の退役条件が「全 WP が完了または見送り」である以上、リポジトリ全体の一般則を紐づけると計画書が永久に退役できなくなるため。ただし優先度が低いという意味ではなく、順位 396 / 411 は高優先度で WP-18 とは独立に早期着手する旨を明記した。
想定外に見つかった不整合: 指摘済みの矛盾 (「前 2 者は順位 394 後の run で判定できる」) を直す過程で、WP-17 の残課題節にも同じ記述が残っていることに気づいた。同じ行の「代替解は順位 394 の draft 廃止」も誤りのままだったため、真の原因 (author が bot) と決定 16 による解決に書き換えた。
系統 F の変更理由 (ユーザー判断): 「CLAUDE.md に rustfmt 非適用の方針を書く」ではなく「
cargo fmtを PreToolUse でブロックする」に変更した。規約は毎セッション読まれコンテキストを圧迫するが、hook は発火するまでコストがゼロで、ブロックと同時に正しいコマンドをフィードバックできる。ADR-042 の mechanizable 判定を満たす。この非対称は現行 ADR-042 に無いため、順位 411 の作業範囲に ADR-042 への追記を含めた。Scope decision: docs のみ。実装は各順位の着手時に行う。運用問題と feedback 採用分を 1 PR にまとめたのは、どちらも本セッション由来の todo 登録で分ける実益が薄いため。
Validation
pnpm lint:md(127 files) /pnpm lint:docs: 0 errorpnpm pushpre-push review: simplicity / security とも approved順位 394 後の runの残存が 0 件であることを確認 (計画書内の自己矛盾を解消)References
Summary by CodeRabbit