docs(wp18): WP-18 の完了記録を ADR へ移管し計画書を残作業のみに整理 - #374
Conversation
- ADR-066 に § 実走観測 2 を追記 (2026-08-08 の停止側実測。AUTONOMY_ENABLED の variable 側 3 状態が完備し、残るのは config 側の実走のみ) - ADR-072 の残課題から stale bullet を削除 (外部設定は § 外部設定の実体 に 記録済み) - harness-improvement-plan.md の WP-18 節を圧縮 (着手前決定 / PR 構成 / PR chain 宣言 / 受け入れ基準の達成記録を ADR-072 へ参照付け替え)。 WP-17 残課題と全体像の表も実測結果に同期 - todo housekeeping: 完了済みの順位 378-381 / 384 を削除、順位 374 の 作業計画を実態へ更新、順位 382 の依存解消を反映 - 順位 392 を登録: push パイプラインの terminal outcome を telemetry へ 記録し失敗回数・原因を機械集計可能にする (WP-18 失敗頻度分析の follow-up) - 採用率測定の開始起点を「スモーク完走後 (決定 11 の実測まで、保留中の トークン露出は含めない)」と決定 (2026-08-09 ユーザー判断)
|
Warning Review limit reached
Next review available in: 57 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
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 |
Summary
AUTONOMY_ENABLEDの variable 側 3 状態が完備、残るのは config 側の実走のみ)harness-improvement-plan.mdの WP-18 節を 74 行 → 24 行へ圧縮。着手前決定 / PR 構成 / PR chain 宣言 / 受け入れ基準の達成記録を ADR-072 へ参照付け替えし、残作業だけを表に残したContext
harness-improvement-plan.mdは ephemeral 計画書で、全 WP 完了後に自身を削除することを最終目標とする (同ファイル冒頭 + § 完了条件と退役手順)。知識移管は順位 117 の 3 ステップ原則 (permanent 先行作成 → 参照付け替え → ephemeral から削除) に従う。WP-18 は実装・スモークがほぼ完了して本番稼働に入ったため、完了記録を永続成果物へ移して計画書を残作業のみの状態へ戻した。2026-08-01 のスリム化 (WP-15 / WP-14) と同じ操作の WP-18 版にあたる。移管先を新規 ADR ではなく既存 ADR への追記としたのは、WP-18 の設計・決定・検証記録が既に ADR-072 (夜間ループ本体) / ADR-071 (背圧) に揃っているため。今回追記が必要だったのは ADR-066 だけで、2026-08-08 の停止側実測が同 ADR の bounded lifetime trigger (b) の状態網羅を埋めたにもかかわらず未記帳だった。
順位 392 は本セッションで実施した WP-18 失敗頻度分析の follow-up。分析の過程で、パイプライン失敗の回数・原因に構造化記録が無く、定量を
.takt/runs/のディレクトリ数から推定せざるを得ないことが判明した (08-07 は 18 run / 1 PR = ベースライン 1.9 の約 9 倍)。失敗の主因は監視・自動 fix 経路が積む空コミットによる bookmark ずれ (7 回観測、順位 386) など既登録の問題で、新規の再発防止策は不要と判断した。残るギャップが観測手段そのものだったため、これのみ登録している。採用率 2 週間測定の開始起点は「スモーク完走後」を維持し、完走の定義を決定 11 の実測完了までとした (意図的保留のトークン露出 probe は完走条件に含めない — 含めると測定開始が無期限に従属するため)。
Validation
pnpm pushpre-push review: verdict=APPROVE (simplicity / security とも、1 iteration・1m56s、fix step の発生なし)rust-lint-testは skip)pnpm lint:docs: OK (preamble + cross-ref + priority-inversion)References