docs(adr): bot 作成 PR がレビューされない制約と identity 分離による解決を記録 - #382
Merged
Conversation
2026-08-10 の実測で、夜間 PR にレビューが付かない原因が判明した。ADR-072 決定 15 は 「draft をやめれば auto_review に乗る」を前提にしていたが、これは誤りで、実際の ブロック要因は PR の author が bot であることだった。draft 廃止後も #379 は draft=false のまま 10 時間 26 分 無反応だった。 ## ADR-019: CodeRabbit の挙動の真実源を置く 「CodeRabbit がいつレビューするか」の真実源を ADR-019 に集約した。CodeRabbit は bot 作成 PR を自動スキップする組み込み挙動を持ち (公式 "Auto Review Skipped — Bot user detected")、設定では制御できない。6 経路すべての実測表を残した: - bot 作成 PR の auto_review → skip - bot が @coderabbitai review を投稿 → 無視 - 人間が投稿 → 動く (4〜5 秒) - CodeRabbit を reviewer に要求 → HTTP 422 (App は collaborator でない) - PR を reopen → 無効 - 設定で bot を許可 → スキーマに該当キーが無い (全数確認) ignore_usernames は除外専用で allowlist 方向は無く、本リポジトリでは未設定なので 原因ではない。skip 通知の有無は判断材料にならない (本リポジトリでは通知すら出ず、 プラン差か実装差かは未解明) ことも明記した。 ## ADR-072: 決定 15 の前提訂正と決定 16 の新設 決定 15 は維持する。レビューが付かない理由の説明は誤っていたが、commitment 点を マージ 1 点へ集約する判断は ADR-052 原則 2 の改訂として独立に成立している。 教訓として、症状と目に付いた差分 (draft) を因果で結んだこと、drafts: false という もっともらしい説明が実在したことが誤診を後押ししたこと、対処後に同じ症状が続くかを 確かめる前に「解決した」と記録したことを残した。 決定 16 (新設): レビュー要求だけを人間 identity で出す。PR の作成者は bot のまま 維持し、変えるのは「誰がレビューを頼むか」だけ。PAT は Pull requests: write のみで push もマージもできないため、決定 8 が却下した「push に使う PAT」には当たらない。 nightly-todo.yml の中に置かない理由を信頼境界として記録した。あの job は未信頼 agent が 実装を書き cargo test がそれを実行する job で、スモーク未解決の「cargo サブプロセスへの トークン露出」の対象でもある。そこに人間資格情報を置かない。決定 8 § 帰結の 「資格情報を足すと、その step で何が実行されうるかを洗い直す」の 2 例目にあたる。 pull_request_target の攻撃面 (fork PR から secrets へ到達) と封じ方、kill-switch を 2 面とも見る実装、投稿しただけで成功としない検証も記録した。決定 11 の失敗の本質は 助言層を fail-open にしたことではなく、効果の観測を用意しなかったことである。 実走検証 (2026-08-10): PR 作成から CodeRabbit 反応まで 15 秒、完全自動。検証 step は 実際に働いた (1 回目は反応なし、2 回目で検出)。 ## スモーク未確定 (a)(b) の位置づけが変わった Phase B 本体の到達と coderabbitai[bot] allowlist の要否は、いずれも「CodeRabbit が 夜間 PR にコメントすること」を起動契機とするため、レビューが付かない間は観測機会 そのものが無かった。決定 16 でレビューが毎回付くようになり、未確定の理由が 「機構が無い」から「事象待ち」へ変わった。 ## 採用率測定の開始起点が確定 2026-08-10。1 件目は #381。中間確認 2026-08-24、判定期限 2026-11-06。 CODERABBIT_TRIGGER_PAT の実体 (権限・対象・期限・失効時の倒れ方) を ADR-072 § 外部設定の実体へ記録した (ADR-051 決定 1)。秘密値そのものは記録しない。
|
Warning Review limit reached
Next review available in: 34 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 (3)
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 |
Owner
Author
|
@coderabbitai review |
|
Owner
Author
|
@coderabbitai review |
|
Owner
Author
|
@coderabbitai review |
|
aloekun
added a commit
that referenced
this pull request
Aug 10, 2026
あわせて 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 への 追記を含めた。
aloekun
added a commit
that referenced
this pull request
Aug 10, 2026
あわせて 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 が今後も再発する場合」**と明記した
aloekun
added a commit
that referenced
this pull request
Aug 10, 2026
あわせて 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 の 共存) を確認したうえで妥当と判断している。
aloekun
added a commit
that referenced
this pull request
Aug 10, 2026
あわせて 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 の 共存) を確認したうえで妥当と判断している。
This was referenced Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.coderabbit.yamlからは制御できない。6 経路すべての実測表を残したauto_reviewに乗る」は誤りで、実際のブロック要因は author が bot であることだった。決定そのものは維持する (commitment 点の集約は独立に成立)Context
Why: 決定 15 で draft を廃止した後も夜間 PR にレビューが付かなかった。#379 は
draft=falseのまま 10 時間 26 分 無反応で、人間作成の #376 / #377 が 33 秒 / 18 秒で反応するのと決定的に異なっていた。確定した制約 (すべて実測):
auto_review@coderabbitai reviewを投稿@coderabbitai reviewを投稿ignore_usernamesは除外専用で allowlist 方向が無く、本リポジトリでは未設定なので原因ではない。skip 通知の有無は判断材料にならない (本リポジトリでは通知すら出ず、プラン差か実装差かは未解明)。決定 15 を維持する理由: レビューが付かない理由の説明は誤っていたが、「commitment 点をマージ 1 点に集約する」判断は ADR-052 原則 2 の改訂として独立に成立しており、draft へ戻す理由が無い。
教訓として残したこと: 症状 (レビューが付かない) と目に付いた差分 (draft である) を因果で結んだ。
drafts: falseというもっともらしい説明が実在したことが誤診を後押しした。draft を外した後に同じ症状が続くかを確かめる前に「解決した」と記録したのが誤りで、対処の効果は対処後の観測でしか確かめられない。決定 16 の核心 — 資格情報を agent の job から隔離する:
nightly-todo.ymlは未信頼 agent が実装を書きcargo testがそれを実行する job で、スモーク未解決の「cargoサブプロセスへのトークン露出」の対象でもある。そこに人間資格情報を置かない。決定 8 § 帰結が書いた「資格情報を足すと、その step で何が実行されうるかを洗い直す」一般則の 2 例目にあたる。PAT が決定 8 の却下に当たらない理由:
Pull requests: writeのみで push もマージもできない (どちらもContents: writeが必要)。決定 8 の却下は「PAT 一般」ではなく「push に使う PAT」に対するものだった。Scope decision: docs のみ。実装は PR #380 で land 済み。
Validation
pnpm lint:md(127 files) /pnpm lint:docs: 0 errorpnpm pushpre-push review: simplicity / security とも approved。docs-only 判定でrust-lint-testは正しく skipCODERABBIT_TRIGGER_PATの実体 (権限・対象・期限・失効時の倒れ方) を ADR-072 § 外部設定の実体 へ記録 (ADR-051 決定 1)。秘密値そのものは記録しないReferences