feat(nightly-todo): draft PR 作成後に CodeRabbit レビューを明示トリガーする (ADR-072 決定 11) - #367
Conversation
…定 11) 2026-08-08 の schedule 初回実走 (PR #365) で、夜間 draft PR が**永久にレビュー されない**ことが確定したため対処する。 ## 2 つの正しい設定が繋いだ時にだけ衝突していた - .coderabbit.yaml は reviews.auto_review.drafts: false (ADR-019 の無料枠クォータ設計) - ADR-052 / ADR-072 は夜間ループを draft PR で止める (commitment 点の手前) どちらも単体では正しい。組み合わせると夜間 PR にレビューが付かず、さらに ADR-067 の Phase B は issue_comment / pull_request_review で起動するため **Phase B も永久に 発火しない**。ADR-072 § 欠点 は「Phase A が起動しない可能性」を書いていたが、原因を CodeRabbit の起動条件に求め、**自リポジトリの設定**を見ていなかった。 ## drafts: true ではなく明示トリガーを採る drafts: true は ADR-019 が解いたレート消費を戻す。ready 化は ADR-052 の commitment 点を 侵す。採ったのは draft PR 作成後に `@coderabbitai review` を 1 回だけ投稿する形で、 ADR-019 が fix push に対して既に採っている構成と同型。レート消費は 1 PR 1 回。 token は App のものを使う。job の GITHUB_TOKEN は pull-requests: read しか持たず、 書き込みを戻すと決定 8 § 副次効果 (agent が触れる唯一の資格情報を read-only にした) を 巻き戻すため。 ## 決定 10 の red 分類の例外にする レビュー起動は成果物が出来た後の助言層であり、ADR-043 の「fail-closed はゲート関数のみ、 助言層は fail-open」に従い continue-on-error で受ける。ここで red にすると 「draft PR は正しく出来たのにレビュー起動だけ失敗した夜」が「本当に壊れた夜」と同色に なる。無音にはせず Report outcome に request_review を出し、失敗時は [NIGHTLY_WARN] で 手動投稿を促す。 ## 実走スモークの記帳 schedule 初回実走で 8 項目中 5 項目が充足した (AUTONOMY_ENABLED の完全一致起動 / claude/nightly-* の ref 作成 / **App token 作成 PR に ci.yml の 2 OS run が紐づくこと** = 決定 8 の核心 / 決定 7 の照合が誤検知しないこと / publish の rsync が過不足なく運ぶこと)。 1 項目は不成立と判明 (Phase B 自動起動)、2 項目は未観測 (トークン露出・停止側)。 **スモークを dispatch で始める前に本番 schedule が先に消化した**点は残課題に記帳した。 AUTONOMY_ENABLED を立てると schedule も同時に有効になるため、観測装置の準備前に無人 run が 始まる構造だった。 ## 未検証 CodeRabbit が bot (App) 投稿の `@coderabbitai review` に反応するかは未確認。bot 同士の ループを避けて他 bot のコメントを無視する実装は珍しくない。次回の夜間 run で最優先に 実測し、無反応なら 3 択で再判断する (ADR-072 § 残課題)。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
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:
📝 WalkthroughWalkthroughdraft PR 作成後に CodeRabbit へ明示的なレビュー要求を 1 回送信します。要求失敗は workflow を失敗させず、警告として報告します。ADR と改善計画に実走結果および残課題を反映します。 ChangesNightly CodeRabbit review request
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant NightlyWorkflow
participant GitHubAPI
participant CodeRabbit
NightlyWorkflow->>GitHubAPI: draft PR にレビュー要求コメントを投稿
GitHubAPI->>CodeRabbit: `@coderabbitai` review
NightlyWorkflow->>NightlyWorkflow: 成否を Report outcome に表示
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 バックストップ)
Applicable Findings (Critical / High / Major)(該当なし) Applicable Findings (Medium 以下)(該当なし) Filtered (not applicable)(該当なし) 軽量サマリー (レビュー指摘 0 件のため)
次のアクション
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/nightly-todo.yml (1)
482-484: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win
gh pr commentに時間上限を設定してください。
continue-on-errorは非ゼロ終了を吸収しますが、応答停止を終了させません。
この呼び出しがハングすると、job のtimeout-minutes: 60までReport outcomeに到達せず、手動案内も出ません。
timeoutなどで短い上限を設定し、タイムアウトをrequest_review=failureとして報告できるようにしてください。提案修正
- gh pr comment --repo "${{ github.repository }}" "$BRANCH" --body "`@coderabbitai` review" + timeout 60s gh pr comment --repo "${{ github.repository }}" "$BRANCH" --body "`@coderabbitai` review"この指摘は同 job の
timeout-minutes: 60と、追加された外部 API 呼び出しの経路に基づきます。🤖 Prompt for 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. In @.github/workflows/nightly-todo.yml around lines 482 - 484, Set a short execution limit around the gh pr comment invocation in the workflow’s request_review step, using the existing shell error handling so a timeout produces a nonzero status and is reported as request_review=failure while allowing the job to continue to its outcome reporting.
🤖 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/adr/adr-072-nightly-todo-loop.md`:
- Around line 320-338: Align the smoke-test item count across the observation
table in docs/adr/adr-072-nightly-todo-loop.md:320-338 and the acceptance
summary in docs/harness-improvement-plan.md:223-225. Either count all 9 table
rows and update the 5/1/2 totals accordingly, or explicitly mark the
coderabbitai[bot] allowlist row as an excluded supplementary record and make
both documents state that exclusion consistently.
In `@docs/harness-improvement-plan.md`:
- Line 172: WP-18 の進捗記述を、allow 経路が 2026-08-08 の schedule run
で完了した現状と一貫するよう更新してください。`実走スモーク未実施`、`まだ 1 度も走っていない`、`実走スモークは未実施`
の記述を修正するか、過去時点の記録であることを明示し、計画書内で状態が矛盾しないようにしてください。
---
Nitpick comments:
In @.github/workflows/nightly-todo.yml:
- Around line 482-484: Set a short execution limit around the gh pr comment
invocation in the workflow’s request_review step, using the existing shell error
handling so a timeout produces a nonzero status and is reported as
request_review=failure while allowing the job to continue to its outcome
reporting.
🪄 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: db1dd1f1-cfad-4c56-931c-d593d94e1d90
📒 Files selected for processing (3)
.github/workflows/nightly-todo.ymldocs/adr/adr-072-nightly-todo-loop.mddocs/harness-improvement-plan.md
| ### 実走スモーク — allow 経路は **schedule の初回実走で成立** (2026-08-08) | ||
|
|
||
| 反復は [ADR-067](adr-067-phase-b-unattended-fix-push.md) § 段 2 の知見 2 に従い、**マージせずブランチ ref への `workflow_dispatch`** で行う。`dry_run` 入力でゲート通過まで走らせて push を止められるようにしてある。 | ||
| **スモークは `workflow_dispatch` で意図的に始める前に、schedule (03:00 JST) の初回実走が先に成立した。** 2026-08-07 18:19 UTC の run が台帳の順位 203 を選び、draft PR [#365](https://github.com/aloekun/claude-code-hook-test/pull/365) (`claude/nightly-203`) の作成まで完走した。 | ||
|
|
||
| スモークで同梱観測する項目: | ||
| **この順序は褒められたものではない。** 受け入れ基準の中核である実走検証を、人間が観測装置を用意した dispatch ではなく**本番の無人 run が先に消化した**形になっている。結果的に成功したが、失敗していれば観測の準備が無いまま夜間に壊れた成果物が出ていた。ここでの教訓は、`AUTONOMY_ENABLED` を立てた時点で schedule も同時に有効になるという事実が、スモーク計画に織り込まれていなかったこと (§ 残課題)。 | ||
|
|
||
| | 観測項目 | 出所 | | ||
| |---|---| | ||
| | WP-17 残課題: Phase B の自動起動経路が成立するか | [ADR-067](adr-067-phase-b-unattended-fix-push.md) § 検証記録 | | ||
| | WP-17 残課題: `coderabbitai[bot]` allowlist の要否 | 同上 | | ||
| | **`cargo` サブプロセスから `CLAUDE_CODE_OAUTH_TOKEN` / `GITHUB_TOKEN` が見えるか** | pre-push security review の warning | | ||
| | 決定 7 の照合が実 runner 上でも通ること (誤検知で毎晩止まらないこと) | 本 ADR § integrity 機構の drill | | ||
| | **App token で作った draft PR に `ci.yml` の 2 OS run が紐づくこと** | 決定 8 (仕様は公式で確認済み、実環境での成立は未観測) | | ||
| | Actions variable `AUTONOMY_ENABLED` が `true` ちょうどで設定されており job が起動すること | ADR-066 § 決定 2 (完全一致要件) | | ||
| | `claude/nightly-*` の **ref 作成**が App token で通ること (ruleset の除外が creation にも効くこと) | ADR-067 段 0 の ruleset。Phase B が観測したのは既存ブランチへの update のみ | | ||
| | `publish/` の clone + rsync が実 runner で成立し、`work/` の変更が過不足なく運ばれること | 決定 9 (`--delete` による削除の反映を含む) | | ||
| | 観測項目 | 出所 | 結果 (2026-08-08) | | ||
| |---|---|---| | ||
| | Actions variable `AUTONOMY_ENABLED` が `true` ちょうどで設定されており job が起動すること | ADR-066 § 決定 2 (完全一致要件) | **充足** — job が起動し完走 | | ||
| | `claude/nightly-*` の **ref 作成**が App token で通ること (ruleset の除外が creation にも効くこと) | ADR-067 段 0 の ruleset。Phase B が観測したのは既存ブランチへの update のみ | **充足** — `claude/nightly-203` が新規作成された | | ||
| | **App token で作った draft PR に `ci.yml` の 2 OS run が紐づくこと** | 決定 8 (仕様は公式で確認済み、実環境での成立は未観測) | **充足** — PR の author は `nightly-todo-aloekun[bot]`、`rust (ubuntu-latest)` / `rust (windows-latest)` がいずれも success。承認待ちにならなかった | | ||
| | 決定 7 の照合が実 runner 上でも通ること (誤検知で毎晩止まらないこと) | 本 ADR § integrity 機構の drill | **充足 (1 run)** — 誤検知せず publish へ到達。毎晩の安定性は継続観測 | | ||
| | `publish/` の clone + rsync が実 runner で成立し、`work/` の変更が過不足なく運ばれること | 決定 9 (`--delete` による削除の反映を含む) | **充足** — commit は 1 ファイル 18 行追加・削除ゼロで、順位 203 の指定範囲と完全に一致 | | ||
| | WP-17 残課題: Phase B の自動起動経路が成立するか | [ADR-067](adr-067-phase-b-unattended-fix-push.md) § 検証記録 | **不成立と判明** — CodeRabbit が draft を自動レビューしないため起動契機のコメント自体が発生しない (決定 11 で対処) | | ||
| | WP-17 残課題: `coderabbitai[bot]` allowlist の要否 | 同上 | **判定不能** — 上記より CodeRabbit のイベントが発生していない。決定 11 の明示トリガーが効いてから再判定 | | ||
| | **`cargo` サブプロセスから `CLAUDE_CODE_OAUTH_TOKEN` / `GITHUB_TOKEN` が見えるか** | pre-push security review の warning | **未観測** — 使い捨ての `build.rs` を仕込む専用 run が要る (§ 残課題) | | ||
| | **停止側: `AUTONOMY_ENABLED` が `'false'` / 未設定で何も作られないこと** | ADR-066 の 3 状態。#364 で受け入れ基準へ追加 | **未観測** — allow 経路しか走っていない | | ||
|
|
||
| **`workflow_dispatch` + `dry_run` は依然として必要である。** 残る 2 項目 (トークン露出・停止側) は本番 schedule では観測できない。反復は [ADR-067](adr-067-phase-b-unattended-fix-push.md) § 段 2 の知見 2 に従い、**マージせずブランチ ref への `workflow_dispatch`** で行う。 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
実走スモークの項目数を両文書で同じ定義にしてください。
5 項目充足 / 1 項目不成立 / 2 項目未観測 は 8 項目の集計です。
一方、docs/adr/adr-072-nightly-todo-loop.md の観測表には 9 行あります。
allowlist 行を補助記録として除外するなら、その扱いを表と集計に明記してください。除外しないなら集計値を更新してください。
docs/adr/adr-072-nightly-todo-loop.md#L320-L338: 9 行の観測表と「8 項目」の定義を一致させる。docs/harness-improvement-plan.md#L223-L225:5/1/2の acceptance summary を修正するか、補助行の除外を明記する。
この指摘は両文書の観測表と acceptance summary の突合に基づきます。
📍 Affects 2 files
docs/adr/adr-072-nightly-todo-loop.md#L320-L338(this comment)docs/harness-improvement-plan.md#L223-L225
🤖 Prompt for 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.
In `@docs/adr/adr-072-nightly-todo-loop.md` around lines 320 - 338, Align the
smoke-test item count across the observation table in
docs/adr/adr-072-nightly-todo-loop.md:320-338 and the acceptance summary in
docs/harness-improvement-plan.md:223-225. Either count all 9 table rows and
update the 5/1/2 totals accordingly, or explicitly mark the coderabbitai[bot]
allowlist row as an excluded supplementary record and make both documents state
that exclusion consistently.
| | 順位 | 内容 | Tier | 期限 | | ||
| |---|---|---|---| | ||
| | 374 | 実走スモーク(`workflow_dispatch` の `dry_run` から開始、観測 8 項目) | 🚀 1 | 次に着手する作業 | | ||
| | 374 | 実走スモーク(**allow 経路は 2026-08-08 の schedule 実走で充足**。残りは停止側 3 状態とトークン露出の 2 項目で、`workflow_dispatch` の専用 run が要る) | 🚀 1 | 次に着手する作業 | |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
WP-18 の実走状態を古い要約にも反映してください。
Line 172 は allow 経路が 2026-08-08 の schedule run で充足したと記録しています。
一方、Line 157 は 実走スモーク未実施、Line 165 は まだ 1 度も走っていない、Line 198 は 実走スモークは未実施 と記載しています。
これらを更新するか、過去時点の記録であることを明示してください。
現状の計画書は同じ WP-18 の状態を二通りに示します。
この指摘は docs/harness-improvement-plan.md の WP-18 進捗記述と更新後の受け入れ基準の突合に基づきます。
🤖 Prompt for 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.
In `@docs/harness-improvement-plan.md` at line 172, WP-18 の進捗記述を、allow 経路が
2026-08-08 の schedule run で完了した現状と一貫するよう更新してください。`実走スモーク未実施`、`まだ 1
度も走っていない`、`実走スモークは未実施` の記述を修正するか、過去時点の記録であることを明示し、計画書内で状態が矛盾しないようにしてください。
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)(該当なし) Applicable Findings (Medium 以下)
Filtered (not applicable)(該当なし) 次のアクション
|
|
Tip For best results, initiate chat on the files or code changes.
3 件はいずれも Minor または Trivial であり、現時点ではマージをブロックしません。 次回の更新では、次の項目を同時に修正すると整合します。
また、bot が投稿した You are interacting with an AI system. |
どちらも妥当と判断して対応。指摘本文はいずれも **anchor 以外の箇所も名指し**して おり、要約 (anchor 1 箇所) だけでは範囲を取り違えるところだった。 ## #1 実走スモークの項目数が両文書で不一致 (adr-072:338) 観測表は 9 行あるのに、計画書の集計は「8 項目 / 5 充足・1 不成立・2 未観測」= 8 件 だった。#364 で受け入れ基準へ停止側 1 件を足した際、ADR の表には行を足したが集計側を 更新していなかった。 母数を 9 件 (起票時の 8 + #364 追加の停止側 1) と ADR 側に明記し、計画書の集計を 5 充足 / 1 不成立 / 1 判定不能 / 2 未観測 へ修正した。allowlist 行は「判定不能」として 独立に数える (除外して 8 件に揃えるのではなく、状態を持つ 1 件として扱う)。 ## #2 WP-18 の実走状態が古い要約に残っていた (harness-improvement-plan:172) 受け入れ基準表は 2026-08-08 の実走を反映済みだったが、同じ文書の別セクションが 「実走スモーク未実施」「まだ 1 度も走っていない」と矛盾したままだった。指摘本文が L157 / L165 / L172 / L198 の 4 箇所を名指ししていたため、すべて更新した。 - 見出し: 「3 PR マージ済 (2026-08-07、実走スモーク未実施)」→「実装 land 済 + allow 経路の実走成立 (2026-08-08)」 - 残作業 2 系統の 1 番目: 「まだ 1 度も走っていない」→ allow 経路成立、残るのは 停止側とトークン露出の 2 項目 - PR 3 の記述: 「実走スモークは未実施」→ 初回実走で allow 経路成立、step 数も 17 → 18 (決定 11 の step 追加を反映) あわせて「allow 経路は workflow_dispatch ではなく schedule の本番 run が先に 消化した」ことを本文にも明記した。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CodeRabbit Minor 2 件への対応に加え、ユーザー実測 2 件を記帳する。 ## 停止側の実走が充足した (順位 374 の中核) 2026-08-08 にユーザーが AUTONOMY_ENABLED を `false` と未設定の 2 状態で workflow_dispatch し、**2 回とも job が skip** されることを確認した。ブランチ・ draft PR・App token のいずれも作られていない。確認後 `true` へ復旧済み。 **dry_run はオフ (= push / PR 作成をする設定) で実行している。** AUTONOMY_ENABLED が `true` でなければ job の if: で止まるため dry_run は判定に関与しないが、あえて 「作る気満々の設定」で回すことで「dry_run だから作られなかったのでは」という解釈の 余地を消している。 これで WP-17 の残課題 (明示的 false と未設定が実走未観測、ADR-066 bounded lifetime) も 同時に埋まった。スモーク 9 項目のうち残るは **トークン露出 1 項目**のみ。 ## 外部設定の実体を記録した (順位 384) ADR-051 が課す 3 点のうち (2) 期待値の組み合わせ表を § 外部設定の実体 として新設し、 (1) 相互参照コメントを workflow の App token step と kill-switch の if: へ入れた。 (3) 両側同一 PR は本 PR で成立している。 **付与権限は決定 8 の設計意図と完全に一致していた** — Contents R/W, PR R/W, Metadata Read-only, Workflows **No access**。Workflows が無いことは .github/workflows/** を含む push が権限層でも通らないことを意味し、決定 6 の 禁止リストと二重の防御になっている。 秘密値そのものは記録していない。記録したのは名称・登録先の別 (variable / secret)・ インストール範囲・権限・欠落時の倒れ方・再構築手順のみ。 **未確定として残したもの**: App の作成日 (設定ページに表示が無く、必要になれば Audit log から引く)、資格情報欠落時に run が red で終わるか (fail-closed 側は step の if: 連鎖から構造的に言えるが、色は実際に落としてみないと確定しない)。 ## CodeRabbit Minor 2 件 どちらも妥当。指摘本文はいずれも anchor 以外の箇所も名指ししており、要約 (anchor 1 箇所) だけでは範囲を取り違えるところだった。 - 実走スモークの項目数が両文書で不一致 → 母数を 9 件と ADR に明記し集計を修正 - WP-18 の実走状態が古い要約に残存 → 本文が名指しした 4 箇所すべてを更新 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3ee756d to
e97fbcc
Compare
いずれも「実コードを確認せず断定していた」箇所で、実装を verify して直した。 ## #1 (harness-plan) WP-11 の「誤検知」→「設計どおりの保守的 deny」 evaluate_scope_guard の allowlist は allowlist_from_paths(findings.map(f.file)) = finding の anchor 位置だけで、remedy が別ファイルなら含まない (ADR-054 も欠点として 明記)。#366 の BLOCK は誤検知ではなく設計どおりの保守的 deny。本採用の判定基準を 「この保守的 deny を誤検知に数えない」よう明確化する、と修正。 ## #2 (todo.md/todo3-7) breadcrumb の todo20/todo2-20 残存 docs バッチで更新し漏れた参照を補完。todo.md 冒頭の使い分けを todo21 + summary2 まで、 todo3-7 の「todo2-20」を todo2-21 へ。全 docs で todo2-20 残存ゼロを確認。 ## #3 (todo21:58) heads(::@ & bookmarks()) の複数返り @ に複数 bookmark が付くと複数コミットを返し clone --head / PR 選択が多対象になる。 trunk 除外 + 単一 bookmark へ絞る (現行 is_trunk_bookmark 除外と同規律) 必要を追記。 ## #4 (todo21:102) 388 の「race」断定を撤回 reconcile_takt_output → copy_feedback_report は find_latest_run_dir で run dir を 選ぶ (mod.rs:147 / takt.rs:84)。単純な write race と断定せず、latest 特定のずれ / パス不一致 / 前後関係を「まず特定する」形へ。#367 では実体が run dir に存在した。 ## 検証 pnpm lint:docs OK / markdownlint 0 error。scope guard・feedback reconcile の実装を 実際に読んで記述と一致させた。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(todo): WP-18 セッションの観測を順位 385-388 へ登録し todo21.md を新設 (Phase 2) WP-18 の PR 作業 (#364〜#370) で実測した自動化経路の運用問題を todo へ登録し、 384 完了削除・todo ローテーション・WP-11 記録を 1 バッチにまとめる。 ## todo21.md 新設 (todo20.md が 56KB = 50KB 閾値超過) 新規追加先を todo20.md → todo21.md へ移行。breadcrumb を持つ 5 ファイル (todo.md / todo8 / todo10 / todo13 / todo14) の「現在の追加先」ポインタと、 数詞「22つ/todo2-20」を持つ 8 ファイル (todo3-11) を 23つ/todo2-21 へ更新。 ## 順位 385-388 (2026-08-08 実測、todo21.md) - 385 (T3): cli-pr-monitor lock の liveness check 欠落 (復帰窓 30 分) - 386 (T2): 監視・自動 fix 経路の空コミットで bookmark ずれ → merge/push 失敗。 **本セッションで 7 回観測**、生成元確定、深さ非依存 revset が本命の対処 - 387 (T2): 自動 fix は push が BLOCK されてもローカル作業コピーを書き換える - 388 (T3): post-merge-feedback の完了判定が書き込みと race し誤 failed marker いずれも post-merge feedback には構造的に入らない (feedback の入力は PR diff と レビュー指摘で、ツール自身の運用中の事象は拾わない)。 ## 順位 384 完了・削除 外部設定の実体は ADR-072 § 外部設定の実体 に記録済み (#369/#370)。todo20.md の full エントリと summary2 の行を削除し、完了記録の 1 行に置換。 ## WP-11 記録 (harness-improvement-plan) #366 で enforce 下の scope guard 誤検知を 1 件観測。anchor と remedy が別ファイルの 指摘は構造的に必ず BLOCK される。本採用判定の前に判定基準の再定義が要ることを記録。 ## 検証 pnpm lint:docs OK (preamble + cross-ref + priority-inversion — 数詞 23 整合を含む) / markdownlint 127 files 0 error。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: CodeRabbit 指摘 4 件に対応 — 実装確認のうえ断定を訂正 (#371) いずれも「実コードを確認せず断定していた」箇所で、実装を verify して直した。 ## #1 (harness-plan) WP-11 の「誤検知」→「設計どおりの保守的 deny」 evaluate_scope_guard の allowlist は allowlist_from_paths(findings.map(f.file)) = finding の anchor 位置だけで、remedy が別ファイルなら含まない (ADR-054 も欠点として 明記)。#366 の BLOCK は誤検知ではなく設計どおりの保守的 deny。本採用の判定基準を 「この保守的 deny を誤検知に数えない」よう明確化する、と修正。 ## #2 (todo.md/todo3-7) breadcrumb の todo20/todo2-20 残存 docs バッチで更新し漏れた参照を補完。todo.md 冒頭の使い分けを todo21 + summary2 まで、 todo3-7 の「todo2-20」を todo2-21 へ。全 docs で todo2-20 残存ゼロを確認。 ## #3 (todo21:58) heads(::@ & bookmarks()) の複数返り @ に複数 bookmark が付くと複数コミットを返し clone --head / PR 選択が多対象になる。 trunk 除外 + 単一 bookmark へ絞る (現行 is_trunk_bookmark 除外と同規律) 必要を追記。 ## #4 (todo21:102) 388 の「race」断定を撤回 reconcile_takt_output → copy_feedback_report は find_latest_run_dir で run dir を 選ぶ (mod.rs:147 / takt.rs:84)。単純な write race と断定せず、latest 特定のずれ / パス不一致 / 前後関係を「まず特定する」形へ。#367 では実体が run dir に存在した。 ## 検証 pnpm lint:docs OK / markdownlint 0 error。scope guard・feedback reconcile の実装を 実際に読んで記述と一致させた。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Summary
@coderabbitai reviewを 1 回だけ自動投稿する step を追加(ADR-072 決定 11)Context
Why: 2026-08-08 の schedule 初回実走(#365 =
claude/nightly-203)で、夜間 draft PR が永久にレビューされないことが確定した。原因は 2 つの設定の衝突で、どちらも単体では正しい:
.coderabbit.yamlのreviews.auto_review.drafts: false(ADR-019 の無料枠クォータ設計)繋いだ結果、夜間 PR にレビューが付かない。さらに ADR-067 の Phase B は
issue_comment/pull_request_reviewで起動するため、Phase B も永久に発火しない。ADR-072 § 欠点 は「Phase A が起動しない可能性」を予測していたが、原因を CodeRabbit の起動条件に求め、自リポジトリの設定を見ていなかった。Scope decision:
drafts: trueは ADR-019 が解いたレート消費を戻す。ready 化は ADR-052 の commitment 点を侵す。採ったのは明示トリガーで、これは ADR-019 が fix push に対して既に採っている構成と同型(自動増分レビューを止め、明示@coderabbitai reviewを 1 回投稿)。レート消費は 1 PR あたり 1 回に留まる。token は App のものを使う。job の
GITHUB_TOKENはpull-requests: readしか持たず、書き込みを戻すと決定 8 § 副次効果(agent が触れる唯一の GitHub 資格情報を read-only にした)を巻き戻すため。本 step は決定 10 の red 分類の例外として
continue-on-errorで受ける。レビュー起動は成果物が出来た後の助言層であり、ADR-043 の「fail-closed はゲート関数のみ、助言層は fail-open」に従う。無音にはせずReport outcomeにrequest_reviewを出し、失敗時は[NIGHTLY_WARN]で手動投稿を促す。todo 系列は本 PR に含めない(追ってドキュメント PR にまとめる方針)。
Validation
pnpm pushpre-push review: verdict=APPROVE(simplicity / security 両 facet)。simplicity 側がif: steps.publish.outcome == 'success'はapp-token/dry_runを推移的にガードすることを独立検証しているlintPASS (1.9s) /testPASS (3.3s) /buildPASS (1.1s) /rust-lint-testPASS (61.2s)continue-on-error= fail-open であることを機械的に確認)pnpm lint:docsOK /markdownlint126 files 0 error@coderabbitai reviewに反応するか。bot 同士のループを避けて他 bot のコメントを無視する実装は珍しくない。次回の夜間 run で最優先に実測し、無反応なら 3 択で再判断する(ADR-072 § 残課題)。失敗しても fail-open なので夜間ループ本体は止まらないReferences
Summary by CodeRabbit
新機能
ドキュメント