feat(review-request): bot 作成 PR へ人間資格情報で CodeRabbit レビューを要求する - #380
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:
📝 WalkthroughWalkthroughBot 作成 PR を対象とする ChangesCodeRabbit レビュー要求
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant GitHub
participant GitHubActions
participant GitHubAPI
participant CodeRabbit
GitHub->>GitHubActions: Bot 作成 PR の opened イベント
GitHubActions->>GitHubActions: 実行条件を確認
GitHubActions->>GitHubAPI: `@coderabbitai` review を投稿
GitHubAPI->>CodeRabbit: レビュー要求を通知
loop 最大20回、30秒間隔
GitHubActions->>GitHubAPI: PR コメントを確認
GitHubAPI-->>GitHubActions: CodeRabbit bot コメント
end
Possibly related issues
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)該当なし(レビュー指摘 0 件) Filtered (not applicable)該当なし 差分概要 (レビュー指摘が無いための軽量サマリー)
次のアクション
|
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 @.github/workflows/review-request.yml:
- Around line 80-84: Update the review-request workflow condition to require
both vars.AUTONOMY_ENABLED == 'true' and the [autonomy] enabled value from
autonomy-config.toml, while preserving the existing bot, head repository, and
base repository checks.
- Around line 131-133: 投稿ステップで作成したレビュー依頼コメントの ID を取得して保存し、後続の応答検証でその ID
を基準にするよう更新してください。COUNT の gh api 呼び出しは --paginate --slurp を使い、jq 内で CodeRabbit
コメントかつ .id が REQUEST_COMMENT_ID より大きいものだけを対象にしてください。判定対象の CodeRabbit マーカーは
pr-monitor の定義と、この step が待つレビュー開始または後続マーカーに統一してください。
- Around line 69-71: Update the review-request workflow around the `@coderabbitai`
review posting step to make requests idempotent: before posting, query the pull
request’s existing issue comments for the same PAT actor and identical
review-request content, and skip posting when a match exists. Keep posting
enabled when no matching comment is found; do not rely on concurrency for
deduplication.
🪄 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: 63ff6771-7bb9-4ea8-aa4e-cd854cdf3a07
📒 Files selected for processing (1)
.github/workflows/review-request.yml
🤖 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. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
workflow=".github/workflows/review-request.yml"
if [[ -f "$workflow" ]]; then
nl -ba "$workflow" | sed -n '1,220p'
else
printf 'Missing expected workflow: %s\n' "$workflow"
fd -HI '^review-request\.ya?ml$' .github 2>/dev/null || true
fi
printf '\n--- Candidate autonomy and ADR files ---\n'
fd -HI -t f '(^autonomy-config\.toml$|ADR-066|adr.*066|cli-autonomy-gate)' . 2>/dev/null || true
printf '\n--- References to gate/config/ADR ---\n'
rg -n -i -C 3 \
'(cli-autonomy-gate|AUTONOMY_ENABLED|\[autonomy\]|autonomy-config\.toml|ADR[- ]?066)' \
. \
-g '!**/.git/**' \
-g '!**/node_modules/**' \
-g '!**/dist/**' \
-g '!**/build/**' || trueLength of output: 1034 🏁 Script executed: #!/bin/bash
set -euo pipefail
workflow=".github/workflows/review-request.yml"
if [ -f "$workflow" ]; then
awk '{ printf "%6d\t%s\n", NR, $0 }' "$workflow" | sed -n '1,220p'
else
printf 'Missing expected workflow: %s\n' "$workflow"
find .github -type f \( -name 'review-request.yml' -o -name 'review-request.yaml' \) -print 2>/dev/null || true
fi
printf '\n--- Candidate autonomy and ADR files ---\n'
find . -type f \
\( -iname 'autonomy-config.toml' -o -iname '*adr*066*' -o -iname '*cli-autonomy-gate*' \) \
-not -path '*/.git/*' \
-not -path '*/node_modules/*' \
-not -path '*/dist/*' \
-not -path '*/build/*' \
-print 2>/dev/null || true
printf '\n--- References to gate/config/ADR ---\n'
grep -RInE \
--exclude-dir=.git \
--exclude-dir=node_modules \
--exclude-dir=dist \
--exclude-dir=build \
-e 'cli-autonomy-gate' \
-e 'AUTONOMY_ENABLED' \
-e '\[autonomy\]' \
-e 'autonomy-config\.toml' \
-e 'ADR[- ]?066' \
. 2>/dev/null || trueLength of output: 37805
この 3 件を修正するまで、この workflow は merge-ready ではありません。 You are interacting with an AI system. |
CodeRabbit は PR の author が bot なら自動レビューをスキップする (公式挙動 "Auto Review Skipped — Bot user detected")。夜間ループ (ADR-072) の PR は App token で作られるためこれに該当し、レビューが一度も付かない状態だった。 2026-08-10 に経路を全て実測し、人間 identity のコメント投稿が唯一の経路だと確定した: | 経路 | 結果 | |---|---| | bot 作成 PR の auto_review | skip (#379 が 10 時間超 無反応) | | bot が @coderabbitai review を投稿 | 無視 (#373 が 10 時間 無反応) | | 人間が @coderabbitai review を投稿 | 動く (#373 は 4 秒、#378 は 5 秒) | | CodeRabbit を reviewer に要求 | GitHub API が 422 (App は collaborator でない) | | PR を reopen | 無効 (状態遷移では skip が解除されない) | | 設定で bot を許可 | schema.v2.json に該当キーが存在しない | これは ADR-072 決定 15 の前提 (draft をやめれば auto_review に乗る) が誤りだった ことも意味する。ブロック要因は draft ではなく author が bot であることだった。 ## 設計 nightly-todo.yml の中には置かない。あの job は未信頼の agent が実装を書き cargo test がそれを実行する job で、決定 5 (Bash 非付与) / 決定 8 § 副次効果 (agent の GITHUB_TOKEN を read-only 化) が守っている面である。さらにスモークで 唯一未解決なのが「cargo サブプロセスへのトークン露出」であり、そこへ人間資格情報を 置くと未解決の露出リスクの対象が広がる。本 workflow は agent を動かさない。 PAT は fine-grained で Pull requests: write のみ (対象リポジトリ 1 つ、期限付き)。 決定 8 が PAT を却下した理由は push が ruleset backstop を bypass する点だったが、 この PAT は push もマージもできない (Contents: write が必要) ため懸念は成立しない。 pull_request_target は public リポジトリでは fork PR からも起動し secrets へ 到達できるため、(a) checkout しない (b) run: へ展開するのは PR 番号 (整数) だけ (c) fork PR を条件で除外する、の 3 点で攻撃面を閉じた。タイトル・本文・ブランチ名は 一切シェルに入れない (cli-stale-branch-scan で塞いだのと同じクラスの脆弱性)。 起動条件は 4 つの AND で fail-closed: author が Bot / fork でない / base が本リポジトリ / AUTONOMY_ENABLED が true。author は login 直書きではなく user.type == 'Bot' で 判定する (App 改名で黙って止まらないため)。kill-switch は ADR-066 の既存 1 拠点に 相乗りし、停止操作を増やしていない。 ## 投稿しただけで成功としない 決定 11 の失敗の本質は「投稿できたか」しか見ておらず、bot 投稿が無視されている事実に 10 時間気づけなかったことにある。本 workflow は投稿後に CodeRabbit の反応を確認し、 無ければ red で落とす。照会の一時失敗は「反応なし」と読み替えず、判定は deadline 到達時のみ行う (API blip で偽の red を出すと本当に反応しない夜と区別できなくなる)。 ## 検証 - YAML パース OK、checkout step 0 件 - run: 内への ${{ }} 直接展開なし (すべて env 経由) - env に攻撃者制御フィールドなし (title/body/head.ref/user.login のいずれも不使用) - markdownlint 0 error / cli-docs-lint OK - 実走検証はマージ後に dispatch で行う (本 PR には含まれない) --- CodeRabbit レビュー対応 (#380、3 件すべて修正) --- 1. kill-switch の config 面が抜けていた (Major) ADR-066 の kill-switch は Actions variable と autonomy-config.toml の 2 面 AND だが、 workflow 式ではリポジトリ内ファイルを読めないため variable 面しか見ておらず、 enabled = false にしても投稿できてしまった。既定ブランチの config を API で読む step を追加 (checkout はしない。PR ブランチ側ではなく既定ブランチから読むのは ADR-072 と 同じ信頼境界 — 自律 actor が自分の停止フラグを書き換える経路を作らない)。 「意図した停止」は green、「読めなかった」は red と分けた (決定 10 と同じ分類)。 2. 投稿が冪等でなかった (Major) opened は PR ごとに 1 回だが、run の手動 re-run や検証失敗後の再実行で二重投稿に なりうる。ADR-019 § 再トリガー抑止ガードのとおり同一 HEAD への再投稿はレート枠を 消費するだけで、無料枠運用では実害がある。既存要求があれば再投稿せず、その id を 起点に検証だけ行う。 3. 反応検証が不正確だった (Major) PR 上の CodeRabbit コメント総数を見ていたため、過去の skip 通知や別要求への反応が 1 件でもあれば成功と誤判定した。また既定 1 ページ (30 件) しか見ていなかった。 要求コメントの id を起点に、それより新しいコメントだけを --paginate で数える形へ。 ## レビュー提案どおりに書かず実測で確定させた点 指摘 3 は `--paginate --slurp` + `--jq` を提案していたが、**gh 2.95.0 では --slurp と --jq は併用できない** (実測でエラー)。提案のまま書いていれば実行時に壊れていた。 --paginate 単体は jq をページごとに適用して出力を連結するため、id をストリームで出し shell 側で畳む形に変えた。全ページを取りこぼさないことを実 PR (#378) で確認済み。 あわせて jq の test("@coderabbitai\s+review") はパースエラーになったため、正規表現を 使わない contains("@coderabbitai review") を採用した (失敗経路を減らす)。 ## 検証 - awk のセクション判定を実 config で確認 ([autonomy] 内の enabled だけを拾い、 他 section の同名キーとコメント行を拾わないことを合成データでも確認) - jq/--paginate の件数判定を実 PR (#378) で確認 (since=0 で 3 件、巨大値で 0 件) - YAML パース OK / checkout 0 件 / run: への直接展開なし / env に攻撃者制御なし
9c8a18e to
15fe007
Compare
CodeRabbit レビュー対応 (3 件すべて修正)
1. kill-switch の config 面ご指摘のとおりです。ADR-066 の kill-switch は Actions variable と workflow 式からはリポジトリ内ファイルを読めないため、job 内の step で API から読む形にしました。PR ブランチではなく既定ブランチから読みます — 自律 actor が自分の停止フラグを書き換えて自己解除する経路を作らないためで、ADR-072 と同じ信頼境界です (checkout はしません)。 あわせて「意図した停止」と「読めなかった」を分けました。前者は green で終え、後者は red にします (ADR-072 決定 10 と同じ分類)。読めないまま素通りさせると、kill-switch が効いているのか壊れているのか run 一覧から区別できなくなります。 2. 冪等性
3. 応答検証の精度これも実害のある指摘でした。PR 上の CodeRabbit コメント総数を見ていたため、過去の skip 通知や別要求への反応が 1 件でもあれば成功と誤判定します。既定 1 ページ (30 件) しか見ていない点も同様です。要求コメントの id を起点に、それより新しい CodeRabbit コメントだけを数える形へ変更しました (comment id は単調増加)。 ただし提案どおりには実装できませんでした
提案のまま書いていれば実行時に壊れていました。 同様に 観測 (総数依存・1 ページ依存) は正確でしたが、修正手段は実測しないと通らないものでした。 pre-push review で追加検出した 1 件自前のレビューが、上記 1 の実装に残っていた fail-open を検出しました。
検証
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
workflow=".github/workflows/review-request.yml"
printf '%s\n' '--- Workflow outline and contents ---'
if [[ -f "$workflow" ]]; then
ast-grep outline "$workflow" --items all || true
nl -ba "$workflow" | sed -n '1,240p'
else
fd -HI '^review-request\.ya?ml$' .github 2>/dev/null || true
fi
printf '%s\n' '--- Relevant configuration and ADR files ---'
fd -HI -t f '(^autonomy-config\.toml$|^adr-066.*|^adr-072.*|^adr-019.*)' . 2>/dev/null
printf '%s\n' '--- Gate and request/response references ---'
rg -n -i -C 4 \
'(AUTONOMY_ENABLED|^\[autonomy\]|^enabled\s*=|cli-autonomy-gate|review-request|`@coderabbitai` review|REQUEST_COMMENT_ID|--paginate|coderabbitai\[bot\])' \
.github docs autonomy-config.toml \
-g '!**/.git/**' 2>/dev/null || trueLength of output: 1219 🏁 Script executed: #!/bin/bash
set -euo pipefail
workflow=".github/workflows/review-request.yml"
echo '--- Workflow ---'
if [ -f "$workflow" ]; then
sed -n '1,240p' "$workflow"
else
find .github -type f \( -name 'review-request.yml' -o -name 'review-request.yaml' \) -print 2>/dev/null
fi
echo '--- Matching config and ADR paths ---'
find . -type f \
\( -name 'autonomy-config.toml' -o -iname 'adr-066*' -o -iname 'adr-072*' -o -iname 'adr-019*' \) \
-not -path '*/.git/*' -print 2>/dev/null
echo '--- Relevant excerpts ---'
grep -RInE -C 4 \
--exclude-dir=.git \
--include='*.yml' --include='*.yaml' --include='*.toml' --include='*.md' \
'AUTONOMY_ENABLED|^\[autonomy\]|^enabled[[:space:]]*=|cli-autonomy-gate|`@coderabbitai` review|REQUEST_COMMENT_ID|--paginate|coderabbitai\[bot\]' \
.github docs . 2>/dev/null | sed -n '1,520p'Length of output: 64074 🏁 Script executed: #!/bin/bash
set -euo pipefail
echo '--- ADR-066 ---'
sed -n '1,300p' docs/adr/adr-066-autonomy-global-kill-switch.md
echo '--- cli-autonomy-gate source candidates ---'
find src -type f \( -iname '*autonomy*gate*' -o -path '*/cli-autonomy-gate/*' \) -not -path '*/target/*' -print 2>/dev/null
echo '--- Gate interface and config parsing references ---'
grep -RInE -C 3 \
--exclude-dir=target --exclude-dir=.git \
'(cli-autonomy-gate|struct .*Args|enum .*Operation|AUTONOMY_ENABLED|autonomy-config\.toml|enabled)' \
src/cli-autonomy-gate src/lib-autonomy-policy 2>/dev/null | sed -n '1,420p'Length of output: 38418
ただし、次の 2 件は未解決です。
この 2 件が残るため、現時点では merge-ready ではありません。 ✏️ Learnings added
You are interacting with an AI system. |
あわせて 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 への 追記を含めた。
あわせて 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 が今後も再発する場合」**と明記した
あわせて 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 の 共存) を確認したうえで妥当と判断している。
あわせて 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 の 共存) を確認したうえで妥当と判断している。
Summary
@coderabbitai reviewを 人間資格情報で 1 回投稿する workflow を新設。新規 1 ファイル (143 行) のみで既存 workflow は無変更nightly-todo.ymlの中には置かない — あの job は未信頼 agent が実装を書きcargo testがそれを実行する job で、未解決のトークン露出リスクの対象に人間資格情報を加えたくないためpull_request_targetの攻撃面を 3 点で封じた: checkout しない /run:へ展開するのは PR 番号 (整数) だけ / fork PR を条件で除外Context
Why: ADR-072 決定 15 は「draft をやめれば
auto_reviewの初回レビューに自然に乗る」を前提にしていたが、この前提が誤りだった。ブロック要因は draft ではなく author が bot であること。決定 15 で draft を廃止した後も、夜間 PR にレビューは付かなかった。Trigger: 2026-08-10 に経路を全て実測して確定した。
auto_review@coderabbitai reviewを投稿@coderabbitai reviewを投稿schema.v2.json全数確認)人間 identity のコメント投稿が唯一の経路であることは、消去法ではなく上表すべての実測で確定した。
PAT を許容できる根拠: ADR-072 決定 8 が PAT を却下したのは「オーナー権限で ADR-067 の ruleset backstop を bypass する」ためだったが、本 PAT は fine-grained で Pull requests: write のみ (対象リポジトリ 1 つ、期限付き) であり、push もマージもできない (どちらも Contents: write が必要)。したがって決定 8 の懸念は成立しない。
決定 11 の教訓の反映: 決定 11 は「投稿できたか」しか観測せず、bot 投稿が無視されている事実に 10 時間気づけなかった。本 workflow は効果 (CodeRabbit の反応) を観測する。照会の一時失敗は「反応なし」と読み替えず、判定は deadline 到達時のみ行う。
author 判定を login 直書きにしない理由:
nightly-todo-aloekun[bot]を直書きすると App 改名で黙って発火しなくなる。user.type == 'Bot'で判定する。Scope decision: workflow のみ。ADR-072 決定 15 の前提訂正・ADR-019 の quota 注記・ADR-051 の PAT 実体記録・計画書の更新は、実走検証の結果を見てから PR 2 で行う。
Validation
run:内への${{ }}直接展開なし (すべて env 経由) — 機械的に走査して確認title/body/head.ref/user.loginのいずれも不使用)pnpm lint:md(127 files) /pnpm lint:docs: 0 errorpnpm pushpre-push review: simplicity / security とも approvedgh workflow run nightly-todo.ymlで bot PR を作り、本 workflow が自動起動して CodeRabbit が反応することを確認するReferences
Summary by CodeRabbit