Document inline Claude review fallback

[justin808]

Summary

• allow a bounded inline Claude Code review as the preferred fallback when the hosted claude-review Action is queued, stale, or unavailable
• document Sonnet and a budget cap for token-conscious fallback review
• keep the same merge-blocker triage bar and require evidence in the PR body or merge handoff

Validation

• bin/validate

[coderabbitai]

Warning

Review limit reached

@justin808, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 54 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1cb6a77a-e548-4703-b2cd-03a9aadd9238

📥 Commits

Reviewing files that changed from the base of the PR and between 0e0a23e and 655aca6.

📒 Files selected for processing (2)

• CHANGELOG.md
• workflows/pr-processing.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/inline-claude-review-fallback

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 728fa5d848

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Code Review

This PR adds a bounded inline Claude Code review as the preferred fallback when the hosted claude-review check is unavailable, and documents a fallback precedence order (Claude Code → Cursor Bugbot → Codex). The goal is sound, but the new text introduces three substantive weaknesses in the merge-gate rules and two portability issues.

Findings (most severe first)

1. Self-attestation loophole — local CLI identity invoked by the merge actor (line 1460)
The new third identity option lets the merge actor run claude -p … themselves and self-certify the review. The existing rule at line 1454 already prohibits an authoring agent from finalizing its own 8/10 score ("Two sessions running under the same GitHub account … do not satisfy this requirement"). A "local CLI identity invoked by the merge actor" creates a structurally equivalent loophole on the fallback path with no analog restriction. At minimum, the text should require the local invocation be performed by a different identity than the PR author, mirroring the existing self-finalization prohibition.

2. stale and queued bypass triggers contradict line 1344 (line 1458)
Line 1344 (unchanged) says: "Do not merge while a relevant review check is queued, in progress, stale for an older head SHA." Line 1458 now says claude-review being "stale" or "queued behind an obsolete run" is sufficient to invoke fallback. Without a precise, machine-checkable definition of "obsolete run" (e.g., "a run whose head SHA does not match the current PR head SHA per the Checks API"), a merge actor can interpret a queued current-head run as "obsolete" and bypass it. The two rules need to be reconciled with clear criteria.

3. unavailable and stale bypass triggers carry no evidence requirement (line 1458)
The old text listed four specific, verifiable failure causes (quota exhaustion, hard limit, HTTP 503, HTTP 429 after retry) and required "exact error evidence recorded in the PR body." The new text prepends unavailable, stale, and queued behind an obsolete run — but the evidence requirement ("exact evidence recorded in the PR body or merge handoff") reads as applying to all listed conditions, while "merge handoff" is not defined anywhere in the document (the document defines "batch handoff" at line 759, but "merge handoff" is a novel term with no format or location specified). A merge actor can claim the check was "unavailable" with no auditable evidence.

4. Hardcoded $1 budget and specific tool names are portability violations (line 1459)
The example claude -p --model sonnet --max-budget-usd 1 embeds a concrete dollar figure as if it were a canonical default. AGENTS.md states: "When a workflow needs repo-specific values, name the corresponding AGENTS.md seam key instead of embedding an example command." The budget cap is a consumer-policy value that belongs behind a seam key (e.g., fallback-review-budget-usd). Similarly, naming Cursor Bugbot and the exact codex review --base origin/<base> command in a shared workflow violates "Do not hardcode consumer repo commands … in shared skills" — not all consumers have these tools.

5. Example command omits how to supply the diff (line 1459)
claude -p --model sonnet --max-budget-usd 1 with "the current branch diff" is not a runnable example — it shows the flags but not the invocation pattern (piped diff + prompt string). A merge actor copying this verbatim will get a command that either hangs on stdin or reviews nothing, producing a vacuous result that satisfies the fallback gate without actually reviewing the diff.

[justin808]

Address-review summary

Scan scope: full PR history; no previous address-review summary cutoff was present.

Mattered

• Addressed the queued/stale review fallback consistency issue in 0081da6306f3cdeeadc2f94535d63998286c2453.
• Addressed the local fallback self-attestation issue in 0081da6306f3cdeeadc2f94535d63998286c2453.
• Addressed the fallback evidence and final-handoff wording issue in 0081da6306f3cdeeadc2f94535d63998286c2453.
• Addressed the fallback portability and runnable Claude CLI example issue in 0081da6306f3cdeeadc2f94535d63998286c2453.
• The Claude issue-level review summary duplicated the inline findings above; covered by the same commit.

Optional

• None.

Skipped

• CodeRabbit rate-limit/status comment: non-actionable for this lane.
• Codex review summary body: boilerplate; its actionable inline thread was handled above.

Validation: git diff --check -- CHANGELOG.md workflows/pr-processing.md passed; bin/validate passed.

Current-head checks note: validate and claude-review were still queued after the bounded 180s wait, so this PR remains waiting on current-head checks/review.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0081da6306

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[justin808]

Address-review summary

Scan scope: review activity after previous summary at 2026-06-30T10:08:14Z.

Mattered

• Addressed the current-head report-only Claude fallback example thread in 25d9f1b834346b4ea7bc9de46f29b68d7a22f214.

Optional

• None.

Skipped

• None.

Validation: git diff --check -- CHANGELOG.md workflows/pr-processing.md passed; bin/validate passed.

Current-head checks note: checks were re-triggered by 25d9f1b834346b4ea7bc9de46f29b68d7a22f214; final readiness still depends on refreshed pr-ci-readiness.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 25d9f1bf23

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Review: Document inline Claude review fallback

This PR documents a fallback path for the claude-review gate — when the hosted Action is queued, stale, or unavailable, agents can now run a bounded inline claude -p review — and relaxes Rule 4 of the Review Completion Gate to treat older-head stale checks as advisory rather than hard blocks. The policy intent is sound, but several clauses create correctness gaps or undermine the auditability invariants they're meant to enforce.

Findings (most severe first)

1. Condition 3 in the fallback trigger list is a misplaced standalone "or" branch (line 1458 in diff)
The four auditable conditions are grammatically parallel semicolon-separated "or" alternatives. Condition 3 — "the obsolete queued run can be identified by head SHA and run/check URL" — has no independent meaning as a bypass trigger; it is an evidence-quality sub-requirement that only applies when condition 2 is already satisfied ("the only visible check/run is for an older head SHA and no current-head run is queued or in progress"). An agent reading the list literally can cite condition 3 alone to proceed with a fallback, skipping the critical "no current-head run queued" verification in condition 2. Fix: demote condition 3 to a parenthetical inside condition 2.

2. Two new seam keys (Fallback review model, Fallback review budget) are undiscoverable (line 1459 in diff)
The workflow names two new consumer-resolvable AGENTS.md seam keys but neither is listed in this repo's Agent Workflow Configuration section in AGENTS.md. The established precedent is that every seam key (e.g., Default simplify model) appears in that section with a n/a default. Without the entries, consumer repo maintainers scanning AGENTS.md will not know these keys exist; the workflow silently falls to an unspecified ad-hoc cap, producing inconsistent review coverage across repos.

3. "final batch handoff" as a valid evidence location weakens the auditability trail (lines 1458, 1460 in diff)
The old fallback-conditions bullet required evidence "recorded in the PR body" — a GitHub-persisted, publicly accessible artifact. The new text adds "or the final batch handoff" as a third equivalent option. A batch handoff is a document authored by the same agent running the merge, is not independently verifiable after the session ends, and is not accessible to external auditors on GitHub. The self-attestation prohibition in the third bullet covers the review result, but the same agent can still self-record the condition that unlocks the fallback in its own handoff. Preferring a GitHub-visible artifact (PR body or timestamped PR comment) for the trigger condition would close this gap.

4. "Distinct reviewer" clause does not inherit the same-App-account rule from line 1587 (line 1460 in diff)
Line 1587 explicitly rules out same-account, same-App-bot invocations: "Two sessions running under the same GitHub account, including separate invocations of the same GitHub App bot, do not satisfy this requirement." The new clause in the third bullet says only "not the PR authoring agent and not the merge actor self-attesting their own work." A reader applying only that bullet could conclude a second claude[bot] invocation (different session, same App installation) qualifies as "distinct." The two rules use different scoping language and are not cross-referenced, leaving the same-App loophole invisible to anyone following only the fallback-review path.

5. Rule 4 timing-window: point-in-time Checks API poll is not race-proof (line 1344 in diff) — PLAUSIBLE
The stale-check bypass path requires recording "evidence that no current-head run is still queued or in progress." GitHub Actions has a propagation delay between a push event and the corresponding check run appearing in the Checks API. An agent can poll, see nothing queued, self-record that observation, and proceed — while the actual claude-review run for the current head SHA is being scheduled. The rule does not require a re-poll or wait window before treating the evidence as valid.

6. Named fallback tools replaced by undefined "equivalent fallback review" (line 1458 in diff)
The old bullet explicitly named Cursor Bugbot or Codex review as acceptable fallbacks — both tools with verifiable identities in the Checks API or as collaborators. The new text accepts "an equivalent fallback review" without naming any required tool or verifiable identity class. Any informal document could be self-classified as "equivalent," undermining the identity-verification step that follows.

7. "Deliberately bounded cap" is unspecified when seam keys are absent (line 1459 in diff)
When a consumer repo does not define Fallback review budget, agents are told to "choose a deliberately bounded cap and record it" with no floor, ceiling, or default. Two agents on the same repo could choose $0.10 and $50 respectively and both be technically compliant. A concrete default (e.g., "default to 1.00 USD unless the repo config specifies otherwise") would make the fallback deterministic.

[claude]

Review: Document inline Claude review fallback

This PR widens the auto-merge fallback gate in two ways: it expands the trigger conditions beyond capacity failures (adding "no current-head check visible" and "only older-head check visible" as triggers), and it introduces an inline Claude Code CLI invocation as the preferred fallback reviewer. The CHANGELOG entry is accurate and the prose is otherwise well-structured, but the expanded fallback conditions introduce four actionable concerns.

---

Finding 1 — Evidence recording in "final batch handoff" breaks the GitHub-visible audit trail (HIGH)

Lines 1591 and 1593, workflows/pr-processing.md

The old rule required fallback evidence in the PR body and reviewer identity in the GitHub review record or a timestamped PR comment — both durable, GitHub-API-visible locations. The new rule adds "the final batch handoff" as a third option for both. Per the workflow's coordination-backend design (lines 770, 831–833), batch handoffs can route to a private backend rather than a GitHub PR comment. A merge actor querying via gh pr view or gh pr checks cannot reach that backend, so the independent-finalizer requirement and the fallback conditions can be satisfied by evidence that is invisible to any future auditor or downstream merge actor.

Suggested fix: Add a constraint that the batch-handoff destination is a timestamped PR comment or GitHub review object, not only a private coordination backend, when it is being used as auto-merge evidence.

---

Finding 2 — Self-attestation guard is split from the CLI example it governs (MEDIUM)

Lines 1592 → 1593, workflows/pr-processing.md

Bullet 2 (line 1592) presents a syntactically complete, actionable inline review command — resolve seam keys, run the piped claude -p invocation — with no forward pointer to any restriction. Bullet 3 (line 1593) is where the critical guard lives: "Local CLI fallback evidence qualifies for auto-merge only when a distinct reviewer or finalizer, not the PR authoring agent and not the merge actor self-attesting their own work, records the invocation..." The authoring agent is exactly the entity most likely to be running this review (it is in the environment, has the diff, and bullet 2 reads as a self-contained instruction). Without a forward pointer in bullet 2, the guard in bullet 3 is easily missed.

Suggested fix: Add a parenthetical to bullet 2 — e.g., "(see the independent-finalizer requirement below before recording this as auto-merge evidence)" — or consolidate the restriction into bullet 2 itself.

---

Finding 3 — No minimum wait before declaring "no current-head run queued" (MEDIUM)

Line 1591, workflows/pr-processing.md

The new fallback condition "the only visible claude-review check/run is for an older head SHA and no current-head run is queued or in progress" requires confirming a negative from the GitHub Checks API. Check-run creation is asynchronous with push events; the API can return zero results for several minutes after a push. The CI Polling section (lines 1367–1402) does not specify any minimum wait window, retry count, or freshness threshold before concluding no run is queued. An agent querying immediately after a push satisfies this condition and triggers an inline fallback before the real claude-review run appears, resulting in a duplicate secondary review and an unnecessary gate bypass.

Suggested fix: Add a wait/retry requirement — for example, "wait at least N minutes or re-poll M times after the push before concluding no current-head run is queued" — or cross-reference the CI Polling section's UNKNOWN guidance explicitly.

---

Finding 4 — Rule 4 cross-reference creates a reading hazard for condition (a) (LOW)

Line 1477, workflows/pr-processing.md

Rule 4 says older-head checks "can justify a fallback path only when the auto-merge fallback rule below records the current head SHA, stale run/check URL, and evidence that no current-head run is queued." But condition (a) of the auto-merge fallback ("no current-head claude-review check is available from the Checks API") involves no stale check at all — there is no URL to record. Rule 4 scopes to "Older-head review checks" so it does not logically apply to condition (a), but that scope boundary is not stated explicitly, and a sequential reader applying Rule 4 to condition (a) encounters an impossible recording requirement.

Suggested fix: Tighten Rule 4's scope clause to "when a stale older-head check is the only claude-review artifact visible" so readers understand it does not govern the no-check-at-all case.

[claude]

Code Review

This PR documents an inline Claude Code review as an additional fallback path when the hosted claude-review check is unavailable, queued, or stale. The policy additions to workflows/pr-processing.md are thoughtfully guarded with an independent-reviewer rule and explicit trigger conditions. However, the review surfaces several issues worth addressing before merge.

Confirmed issues

Review Completion Gate rule 4 (line 1477) — stale-bypass cross-reference is underspecified. Rule 4 says stale older-head checks can "justify a fallback path only when the auto-merge fallback rule below records the current head SHA, stale run/check URL, and evidence from repeated polling." But "evidence from repeated polling" elides the two material constraints defined 115 lines later at line 1592: at least two queries separated by at least 90 seconds and recorded before the fallback result is used. An agent following rule 4 in isolation may satisfy the abbreviated checklist while violating the actual standard. See inline comment.

Fallback trigger evidence in a PR comment (line 1592) — deletable post-merge. Allowing the trigger record in a "timestamped PR comment" (instead of only the PR body) weakens the audit trail. PR comments can be deleted by any write-access collaborator after merge with no trace; PR body edits are preserved in GitHub's edit timeline. If the evidence can be erased, the contemporaneous-recording requirement loses its post-merge auditability value. See inline comment.

Plausible issues

--disallowedTools "mcp__*" glob (line 1593) — likely a silent no-op. The Claude CLI --disallowedTools documented syntax uses ToolName(args-pattern) for argument matching (e.g. Bash(git *)), not bare prefix globs on tool names. mcp__* is undocumented and almost certainly treated as the literal tool name mcp__*, which matches nothing. The repo's own .github/workflows/claude-code-review.yml uses the full exact name mcp__github_inline_comment__create_inline_comment, not a glob. If this fails silently, MCP write-capable tools are not blocked during what is documented as a read-only review. See inline comment.

--strict-mcp-config without --mcp-config (line 1593) — undefined isolation guarantee. The flag is documented as "only use MCP servers from --mcp-config." Without an accompanying --mcp-config, whether this means "empty set (all MCP disabled)" or "no restriction (flag is a no-op)" is unspecified by the CLI help. If it degrades to no-op, MCP servers from a project .mcp.json or global config load unimpeded. See inline comment.

90-second polling interval (line 1592) — may be too short. GitHub Actions queue delays routinely exceed 90 seconds under load. Two polls 90 seconds apart may conclude no current-head claude-review run is coming when one is merely queued, triggering premature fallback authorization and a conflict when the real run arrives. See inline comment.

Preference ordering (line 1593) — inline Claude Code listed as preferred over repo-configured reviewers. Repo-configured automated reviewers produce results anchored in the GitHub Checks API (tamper-evident); inline Claude Code review results live only in PR comments (deletable, self-reported). Inverting this preference makes the weaker evidence path the default. See inline comment.

[claude]

Review: Document inline Claude review fallback

This PR documents bounded inline Claude Code as a fallback when the hosted claude-review check is stale or fails for capacity/quota reasons. It replaces two terse auto-merge bullets with five detailed ones covering trigger evidence, eligibility, CLI invocation, and reviewer identity, and rewrites Review Completion Gate rule 4 to give older-head checks a fallback path rather than a hard block.

The expanded protocol is directionally sound, but five issues survived verification — two are correctness/safety concerns that could let a PR merge before a review completes or make the new feature permanently unusable.

---

Findings (most severe first)

1. Rule 4 converts an unconditional in-progress block into a waivable gate — line 1344

The old rule blocked merge unconditionally on any check "in progress, stale for an older head SHA." The new text reclassifies an older-head check that is actively running as "stale/advisory history" and satisfies the gate with an explicit maintainer waiver that can be issued in seconds. This creates a race: push fixup → older-head reviewer mid-run and about to post blockers → maintainer waives → merge → reviewer finishes post-merge. The auto-merge path has guards (current-head checks complete + final re-poll), but the human-merge + waiver path in rule 4 has none.

2. Rule 4 references a "final re-polling bullet" that does not exist — line 1344

Rule 4 directs merge actors to satisfy "the trigger, reviewer-identity, and final re-polling bullets in the auto-merge list below." The trigger and reviewer-identity bullets exist as discrete list items. The re-poll step is not a bullet — it is a clause buried mid-sentence inside the trigger bullet. A merge actor scanning for a discrete "final re-polling" bullet finds nothing and may skip the final Checks API re-poll, creating the exact race the re-poll is meant to prevent.

3. claude-review default has no machine-readable AGENTS.md seam key — line 1458

AGENTS.md Editing Rules require naming a seam key rather than embedding a value. This line calls claude-review the "portable default" and says consumers can override it in their AGENTS.md, but no key (e.g., Configured Claude review check) exists in the Agent Workflow Configuration table. Consumers whose check is named differently have no structured slot to set and no seam-key anchor for agents to look up.

4. Inline Claude opt-in is required but no opt-in mechanism is defined — line 1460

"Silence in AGENTS.md is not permission" — but this PR never documents what explicit permission looks like. The Agent Workflow Configuration table in AGENTS.md has no Inline Claude fallback key, no Fallback review model key, and no Fallback budget USD key. The feature is effectively blocked for all consumer repos with no documented unlock path.

5. Two shell safety gaps in the example CLI command — line 1461

(a) ${fallback_budget_usd} can silently expand to empty, passing --max-budget-usd "" to the CLI and removing the budget cap the text declares mandatory. (b) "Use pipefail" for the direct-pipe variant is incomplete — pipefail sets $? but does not abort execution without set -e or an explicit error check, so a broken diff silently continues into the review.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 71b5b3228c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b1d0fa523e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Code Review

This PR documents a bounded inline Claude Code review as a fallback when hosted review checks are stale or unavailable, and tightens the human-merge Review Completion Gate for older-head checks. The intent is sound, but several issues need attention before this is usable by consumer repos.

Findings (most-severe first)

1. --strict-mcp-config has no version-check fallback instruction (security, line 1594)
The invocation bullet gives an explicit safe-exit for --tools "" — "use its documented no-tool equivalent or do not use inline Claude as auto-merge evidence" — but gives no equivalent fallback for --strict-mcp-config. A CLI version that silently ignores the flag passes the stated pre-invocation check and runs with full MCP access, defeating the isolation guarantee while appearing compliant. Either add a parallel "or do not use inline Claude as auto-merge evidence" clause for --strict-mcp-config, or note that --mcp-config '{"mcpServers":{}}' alone is sufficient.

2. Review gate seam key conflated with GitHub CI check context name (portability, line 1591)
Consumer repos are told to "define that [check] name under their AGENTS.md Review gate policy." But Review gate in both the shared and fixture AGENTS.md holds a pre-push CLI command (e.g., codex review), not a Checks API context name. The override instruction sends maintainers to the wrong seam; the check-name lookup would never find the right value. A new named seam key (e.g., Claude review check name) is needed.

3. No AGENTS.md seam keys defined for inline-fallback opt-in or budget (portability, line 1593)
The bullet requires consumer repos to "explicitly enable an inline Claude fallback" and configure "a fallback review model or budget" via their AGENTS.md, but neither the shared AGENTS.md nor the consumer fixture defines any such key. The feature is unreachable as documented because there is no canonical key name for consumer repos to use.

4. Rule 4 cross-references bullets by informal labels that don't exist (correctness, line 1477)
Rule 4 instructs: "also require the inline-fallback opt-in, verified-diff, isolation, budget, output, and attestation bullets below." None of the five new auto-merge bullets self-identify with any of those labels. An agent following rule 4 cannot resolve which bullet is "the output bullet" vs. "the attestation bullet."

5. Embedded CLI command violates the AGENTS.md editing rule (altitude, line 1594)
AGENTS.md says "name the corresponding AGENTS.md seam key instead of embedding an example command." The claude -p --safe-mode ... command is embedded verbatim in prose. Every consumer install will need to update the command in prose each time a CLI flag changes. The procedure should live in a helper script or skill file with the prose pointing to it.

6. RC-only score is an undefined term (clarity, line 1477)
"Ordinary human merges do not inherit the RC-only score..." introduces the compound RC-only score without definition. The Accelerated RC section discusses a numeric score, but never under that name. The term appears only once with no anchor.

7. Rule 4 routes human mergers into auto-merge-only bullets, creating a circular exclusion (correctness, line 1477)
Rule 4 tells human-merge actors with a stale check to satisfy "the trigger, reviewer-identity, and final re-polling bullets in the auto-merge list below." Those bullets include the inline Claude CLI path, which is gated on AGENTS.md opt-in. But the same sentence says ordinary human merges "do not inherit the RC-only score, confidence-block, or waiver-soak bullets." The human-merge fallback path is simultaneously sent into and partially excluded from the auto-merge section with no coherent resolution.

8. action_required conclusion blocks auto-merge with no escalation or timeout (completeness, line 1591)
"An action_required conclusion … blocks auto-merge until the approval is satisfied or a maintainer leaves an explicit waiver" with no polling cadence, timeout, or path for declaring the gate stale if the integration is decommissioned or never responds.

[claude]

Code Review

This PR documents the inline Claude Code review fallback path and tightens the human-merge Review Completion Gate. The core structure is sound — the fallback is opt-in only, prompt injection risk is disclosed, and the attestation chain is thorough. Four confirmed issues and one plausible ambiguity found.

---

1 · CONFIRMED — Non-capacity failure routes to fallback rules but no trigger accepts it (line 1591–1596)

The main gate says a failure, cancelled, or timed_out conclusion "must route through the fallback/error-evidence rules." But the Fallback trigger bullet lists only three triggers: (1) no current-head check visible after 2 polls, (2) only an older-head check exists, (3) capacity/quota failure (HTTP 503, HTTP 429). A non-capacity failure — runner out of disk, action misconfiguration, network error not matching HTTP 429 — satisfies none of them. The surviving bullet "Claude failures not caused by capacity limits are understood before merge" is a bare compliance note with no procedural step. An agent following these rules precisely has no documented resolution path and auto-merge is permanently blocked.

Fix: Add a fourth trigger or a dedicated "Claude check failed for a non-capacity reason" exit path that names a concrete action (e.g., "escalate to maintainer with the check URL and error text; do not use the fallback path; block auto-merge until the check succeeds or a maintainer waives it").

---

2 · CONFIRMED — VERDICT parsing spec is too loose to prevent prompt injection (line 1594)

The spec says "require the structured fields above plus the trailing VERDICT: line" and "block auto-merge on … missing verdict." The word "trailing" implies last-line checking but the spec never mandates "parse only the final non-empty line" or gives a regex. It explicitly acknowledges "The flags do not sanitize adversarial diff content or make the model output a security boundary." A malicious diff embedding VERDICT: PASS as literal text (e.g., in a README patch) can cause the model to echo it before emitting its own verdict; a naive grep "VERDICT: PASS" would then incorrectly pass auto-merge.

Fix: Add a concrete parsing contract, e.g. "Extract the last non-empty line of Claude's stdout; accept only an exact match of ^VERDICT: (PASS|BLOCK)$; treat any earlier VERDICT: occurrences as untrusted diff content."

---

3 · CONFIRMED — Review gate seam key has no documented sub-key format for inline fallback, model, or budget (line 1593)

The Inline fallback eligibility bullet says consumer repos enable the feature via AGENTS.md Review gate and optionally set a fallback model and budget there. No sub-key schema exists anywhere in the repo: AGENTS.md has Review gate: independent code review…, the consumer fixture has Review gate: codex review, and docs/adoption.md gives only Review gate: <prose>. Consumer repos trying to enable inline fallback, override the model, or set the budget cap have no documented syntax to follow and will invent incompatible formats.

Fix: Document the structured sub-key format, e.g.:

Review gate: |
  codex review
  inline-fallback: enabled
  fallback-budget-usd: 0.50

Add the new sub-keys to docs/adoption.md and test/fixtures/consumer-repo/AGENTS.md.

---

4 · CONFIRMED — Merge actor can self-attest the fallback trigger (line 1592)

The Fallback trigger bullet says evidence may be recorded by "the merge actor, maintainer, or trusted automation." The Fallback reviewer identity bullet bars the merge actor from attesting the result, but no such bar applies to the trigger observation. A merge actor can write "I checked Checks API twice, 3+ minutes apart, no claude-review check found" in a PR comment, satisfying the trigger rule on their own authority — the scenario the fallback exists to handle is also the one where normal checks are absent and abuse is easiest.

Fix: Apply the same distinctness requirement to the trigger record that already applies to the result attestation, or explicitly allow merge-actor trigger records while tightening what constitutes "trusted evidence" (e.g., require a Checks API response excerpt, not just a prose claim).

---

5 · PLAUSIBLE — Rule 4 simultaneously opens and restricts the stale-older-head fallback trigger for human merges (line 1477)

The first clause of the new rule 4 permits "a fallback review that satisfies the fallback-trigger/final-repoll … bullets in the auto-merge list below" — which imports trigger 2 (stale older-head check) as a valid human-merge path. The final sentence of the same rule restricts that exact trigger: "In the auto-merge flow only, a stale older-head … check/run can open the fallback path." Both clauses are in the same paragraph. An agent trying to human-merge a PR with a stale older-head review faces directly contradictory guidance. The human-merge carveout ("Ordinary human merges do not inherit … waiver-soak") correctly exempts RC-only bullets, but does not resolve whether trigger 2 itself is available for human merges.

Fix: Either exclude trigger 2 from the cross-reference in rule 4 (list only triggers 1 and 3 as valid for human merges), or add a sentence clarifying "For human merges, triggers 1 and 3 apply; trigger 2 (stale older-head) is available only in the auto-merge flow."

[claude]

Bug: non-capacity failure is routed to fallback rules but no trigger accepts it.

The end of this bullet sends failure, cancelled, and timed_out conclusions to "the fallback/error-evidence rules." But the Fallback trigger bullet (next line) lists only three triggers: (1) no current-head check after two polls, (2) only an older-head check exists, (3) quota/capacity failure (HTTP 503 / HTTP 429). A non-capacity failure — runner disk-full, action misconfiguration, non-429 network error — matches none of them.

The surviving old bullet "Claude failures not caused by capacity limits are understood before merge" is a bare compliance note with no procedural step and no exit path. An agent following these rules precisely is stuck: the gate says route through fallback rules, but no fallback trigger accepts the case.

Suggestion: Add a fourth trigger or a dedicated "non-capacity failure" exit: e.g., "the current-head check failed for a non-capacity reason — escalate to a maintainer with the check URL and error text; do not use the fallback path; block auto-merge until the check succeeds or a maintainer waives it."

[claude]

Security: merge actor can self-attest the trigger condition.

This bullet allows "the merge actor, maintainer, or trusted automation" to record trigger evidence. The Fallback reviewer identity bullet (line 1462) bars the merge actor from attesting the result, but no equivalent distinctness requirement applies here to the trigger observation. A merge actor can write "I checked the Checks API twice, 3 minutes apart, no claude-review check found" in their own PR comment and satisfy this rule unilaterally — precisely the scenario where normal checks are absent and self-serving claims are easiest to make.

Suggestion: Either apply the same distinctness requirement to trigger evidence (trigger record must not be authored by the merge actor), or require that trigger claims include verifiable evidence (e.g., a Checks API response URL or excerpt) rather than a prose assertion.

[claude]

Portability gap: Review gate seam key has no documented sub-key format for inline fallback, model, or budget.

This bullet requires consumer repos to "explicitly enable inline Claude fallback" and optionally configure a fallback model and budget cap via their AGENTS.md Review gate. No sub-key schema is documented anywhere: this repo's AGENTS.md has Review gate: independent code review…, the consumer fixture has Review gate: codex review, and docs/adoption.md gives only Review gate: <prose>. Consumer repos trying to follow this instruction will invent incompatible formats, and agents cannot distinguish "silence" from "explicit grant."

The check-name override path in the preceding bullet has the same gap: "define that name under their AGENTS.md Review gate policy" but no sub-key form is specified.

Suggestion: Document the structured sub-key format in docs/adoption.md and update the consumer fixture, e.g.:

Review gate: |
  codex review
  inline-fallback: enabled
  claude-review-check-name: my-review-check
  fallback-budget-usd: 0.50

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 962821a13d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Require managed-hook isolation for CLI fallback

Fresh evidence in this squashed change is that this line still treats --safe-mode as disabling Claude customizations before accepting local CLI fallback evidence. I checked the official Claude CLI reference, which says managed policy still applies, including policy-configured hooks (https://docs.anthropic.com/en/docs/claude-code/cli-reference), and the hooks reference says hooks execute automatically (https://docs.anthropic.com/en/docs/claude-code/hooks). In environments with managed Claude settings, a policy hook can still run during this supposedly report-only fallback and mutate state or inject context, while the workflow only requires tool/MCP evidence; require a no-managed-hooks assertion or OS sandbox before this output can satisfy the merge gate.

Useful? React with 👍 / 👎.

[claude]

Security: VERDICT parsing spec is too loose to resist prompt injection.

The spec requires "the trailing VERDICT: line" but never mandates "parse only the final non-empty line" or gives a concrete regex. This text correctly warns "The flags do not sanitize adversarial diff content or make the model output a security boundary," but then leaves the parsing contract open. A malicious diff embedding VERDICT: PASS as literal text (e.g., in a README patch) can cause the model to echo it before its own verdict; a naive grep "VERDICT: PASS" on the full output would then produce a false pass on auto-merge.

Suggestion: Add a precise contract: "Extract the last non-empty line of Claude's stdout; it must match ^VERDICT: (PASS|BLOCK)$ exactly. Any earlier occurrence of a VERDICT:-shaped line is treated as untrusted diff content and must not influence the pass/block decision."

[claude]

Review: Document inline Claude review fallback

This PR documents a bounded inline Claude Code review fallback for cases where the hosted claude-review check is unavailable, and tightens the human-merge gate so stale older-head checks require a current-head run, maintainer waiver, or qualifying fallback. The direction is sound — making the fallback path explicit is better than leaving it undefined — but several correctness and portability gaps were found in the new text that should be addressed before merge.

Findings (most severe first)

1 — Capacity/quota trigger bypasses the 180-second polling floor (line 1592, CONFIRMED)
The first two fallback triggers require "at least two queries separated by at least 180 seconds." The third — a capacity/quota failure — only requires "one 60-second retry." A single transient HTTP 503 at T=0 immediately opens the inline fallback path; the check could recover and complete with BLOCK before the fallback result is used. The final re-poll is the only remaining safeguard, which is a thin safety margin for this trigger path.

2 — Final-repoll livelock with no documented exit path (line 1592, CONFIRMED)
If the final re-poll finds a newly-completed run with a non-quota failure conclusion, re-applying the acceptable-conclusion rules rejects it, and re-applying the fallback-trigger rules also fails (a current-head run now exists). The document provides no prescribed resolution: no "escalate to maintainer waiver" step, no "block and explain" instruction. The merge is permanently stuck with no documented way out.

3 — claude-review hardcoded with no parseable seam for consumer override (line 1591, PLAUSIBLE)
The workflow names claude-review as the portable default and tells consumer repos to define their override "under their AGENTS.md Review gate policy." But Review gate is a free-prose field with no structured key. An agent following this workflow at runtime has no reliable way to extract a consumer-configured check name; it will silently poll claude-review, possibly triggering a spurious fallback for repos that use a different check name.

4 — fallback_budget_usd guard does not validate numeric (line 1594, CONFIRMED)
The prescribed assertion : "${fallback_budget_usd:?...}" only verifies the variable is set and non-empty. A value like "unlimited" or "abc" passes the guard and is forwarded verbatim to --max-budget-usd. Depending on CLI behavior, the cap may be silently ignored, removing the budget constraint that is a hard precondition for using inline Claude as auto-merge evidence.

5 — Non-empty file check required by prose but absent from example command (line 1594, CONFIRMED)
The text requires verifying ${verified_diff_file} is non-empty "immediately before invoking Claude," but the example shows < "${verified_diff_file}" with no preceding [ -s ... ] || exit 1. Implementers copying the example verbatim skip the guard; an empty diff causes Claude to produce a vacuous VERDICT: PASS.

6 — Human-merge waiver path has no polling-wait floor (line 1477, CONFIRMED)
The old text blocked merge entirely while a check was "stale for an older head SHA." The new text allows an immediate maintainer waiver once all older-head runs reach a terminal state, with no minimum wait before new current-head runs appear in the Checks API. The 180-second polling floor exists only in the auto-merge fallback trigger bullet, not in the human-merge path.

7 — --tools "" has no prescribed test for silent-ignore (line 1594, CONFIRMED)
The text says to verify the CLI supports the --tools "" flag or fall back, but no test is prescribed (no --help grep, no dry-run exit-code check). An older CLI version that silently ignores the flag leaves built-in tools enabled during the review with no error signal — contrary to the isolation guarantee the bullet intends to establish.

[claude]

The new option (b) — "an explicit maintainer waiver after every older-head reviewer run has reached a terminal state" — has no minimum observation window before the waiver is valid. The old text blocked merge entirely while a check was "stale for an older head SHA." Under the new text a maintainer can waive immediately after seeing a stale result, before any current-head runner has had time to appear in the Checks API.

The 180-second polling floor exists in the auto-merge fallback-trigger bullet but is not carried into the human-merge path. Consider adding a minimum polling wait here (or explicitly stating that human-merge waivers are intentionally lighter-weight) so the intent is unambiguous.

[claude]

Portability gap: claude-review check name has no parseable seam.

Consumer repos are told to define their override "under their AGENTS.md Review gate policy," but Review gate is a free-prose field (e.g., "independent code review for non-trivial workflow or helper changes"). There is no structured seam key like Review check name that an agent can extract reliably at runtime.

An agent following this workflow in a consumer repo that uses a different check name must either parse unstructured prose or silently fall back to claude-review, potentially polling the wrong check and triggering a spurious fallback.

Recommend adding a dedicated structured seam key (e.g., Review check name: claude-review) to the AGENTS.md template so agents can read it deterministically, and updating the seam doctor to validate it.

[claude]

Two issues with the fallback trigger logic:

1. Asymmetric polling floor for the capacity/quota trigger.
Triggers 1 and 2 (check absent, check stale) both require "at least two queries separated by at least 180 seconds." Trigger 3 (capacity/quota failure) requires only "one 60-second retry." A single transient HTTP 503 at T=0 immediately opens the fallback path; the check could recover and complete at T=10s with BLOCK. The final re-poll is the only remaining gate, which is thin protection for a path with significant consequences.

Consider requiring the same two-query / 180-second minimum for the capacity/quota trigger, or explicitly documenting why a shorter window is acceptable for that case.

2. Livelock when the final re-poll finds a non-quota failure conclusion.
The text says "if the final poll finds a completed current-head run, re-apply the acceptable-conclusion and fallback-trigger rules." If the newly-completed run has conclusion failure (not caused by quota/capacity), re-applying acceptable-conclusion rejects it, and re-applying fallback-trigger rules also fails (a current-head run now exists and it's not a qualifying failure). There is no documented exit path: no "escalate to maintainer waiver" instruction, no "block and explain" step. The merge is stuck indefinitely with no prescribed resolution.

Add an explicit out for this state, e.g., "if re-application of both rule sets fails, block auto-merge and require a maintainer waiver or a fresh current-head reviewer run."

[claude]

Three issues with the invocation requirements:

1. fallback_budget_usd guard does not validate numeric.
The prescribed assertion : "${fallback_budget_usd:?fallback_budget_usd must be set to a non-empty number}" only verifies the variable is set and non-empty. A value of "unlimited" or "abc" passes the guard and is forwarded verbatim to --max-budget-usd. Depending on CLI behavior the cap may be silently ignored, removing the budget constraint that is a hard precondition for using inline Claude as auto-merge evidence. Consider adding a numeric check, e.g.:

[[ "${fallback_budget_usd}" =~ ^[0-9]+(\.[0-9]+)?$ ]] || { echo "fallback_budget_usd must be a number"; exit 1; }

2. Non-empty file check required by prose but absent from the example command.
The text says to "verify the file is non-empty immediately before invoking Claude," but the example shows < "${verified_diff_file}" with no preceding guard. Implementers copying the example verbatim will skip the check; an empty diff produces a vacuous VERDICT: PASS. The example should show the guard explicitly, e.g.:

[ -s "${verified_diff_file}" ] || { echo "diff file is empty"; exit 1; }

3. --tools "" flag has no prescribed test for silent-ignore.
The text says to verify the CLI supports the flag "or do not use inline Claude as auto-merge evidence," but no concrete test is given (no --help grep, no dry-run exit-code check). An older CLI that silently ignores --tools "" leaves built-in tools enabled with no error signal, undermining the isolation guarantee. Add a prescribed verification step, e.g., claude --help | grep -q '\-\-tools'.

[claude]

Review: Document inline Claude review fallback

This PR generalizes the Review Completion Gate and auto-merge section to support a bounded inline Claude Code fallback when hosted review checks are unavailable, and tightens the stale-older-head-SHA rules. The overall security posture is thoughtful — tool isolation, MCP isolation, budget cap, and distinct-reviewer requirements are all present. However there are several concrete issues in the CLI flag documentation and the AGENTS.md seam design that need addressing before this is safe to follow verbatim.

Verified findings (most severe first):

1. --safe-mode misattributed as disabling built-in tools (workflows/pr-processing.md:1594) — The prose says "while --safe-mode disables Claude customizations, built-in tools are disabled." Per claude --help, --safe-mode explicitly does NOT disable built-in tools: "Auth, model selection, built-in tools, and permissions work normally." Tool disabling is done solely by --tools "". A reader following the prose summary instead of the example command could omit --tools "", leaving full Bash/Edit/Read access active during adversarial-diff review.

2. verified_diff_file has no :? guard in the example command (workflows/pr-processing.md:1594) — The budget variable uses "${fallback_budget_usd:?fallback_budget_usd must be set…}" but the diff file redirect uses bare < "${verified_diff_file}". An unset or empty variable silently opens /dev/stdin; Claude then reviews nothing and can return VERDICT: PASS. Add : "${verified_diff_file:?verified_diff_file must be set to a non-empty path}" before the invocation, matching the budget guard pattern.

3. git diff exits 0 on empty output; pipefail doesn't catch an empty diff (workflows/pr-processing.md:1594) — For the pipe invocation path the doc says "use pipefail and check the diff command status." git diff always exits 0, even when there is no diff (e.g. a PR whose commits were already in the base). pipefail only catches non-zero exits, so an empty stream passes silently and Claude returns a vacuous VERDICT: PASS. The guidance should also require checking that the captured diff is non-empty before invoking Claude.

4. Review gate seam key has no structure for a CI check-name override or an inline-fallback opt-in (workflows/pr-processing.md:1591, 1593) — Line 1591 tells consumer repos to "define that name under their AGENTS.md Review gate policy"; line 1593 says "the consumer repo's AGENTS.md Review gate explicitly enables inline Claude fallback." The key in this repo is prose (independent code review…) and in the consumer fixture it is a tool command (codex review). Neither format has a slot for a CI check name or a boolean permission flag. Agents and helpers have no machine-readable way to extract either value. The AGENTS.md seam spec needs documented sub-fields (e.g. review-check-name, inline-claude-fallback) before this protocol is actionable.

5. Item 4's bullet-alias cross-references don't match any labeled auto-merge bullet (workflows/pr-processing.md:1477) — "Ordinary human merges do not inherit the RC-only score, confidence-block, or waiver-soak bullets." None of these are bold-titled standalone bullets in the auto-merge list. The score bullet (line 1588) says "Score is at least 8/10" with no "RC-only" label; "confidence-block" and "waiver-soak" are embedded in prose within unlabeled bullets. An agent resolving these aliases cannot determine which bullets are excluded from human-merge scope.

6. Mixing positional prompt arg with stdin redirect has undefined behavior in some Claude CLI versions (workflows/pr-processing.md:1594) — The example claude -p … -- "<prompt>" < "${verified_diff_file}" passes the review prompt as a positional argument while redirecting the diff via stdin. Whether the CLI reads both or ignores stdin when a positional prompt is provided is not guaranteed across versions. If stdin is ignored, the diff is not reviewed and the model responds to the prompt alone, potentially returning VERDICT: PASS. Require a post-invocation check (e.g. that the output references diff content or has a non-trivial word count) to detect this silently.

7. Waiver path for stale older-head checks is deadlocked when the reviewer run is stuck in-progress (workflows/pr-processing.md:1477) — The new rule requires "an explicit maintainer waiver after every older-head reviewer run has reached a terminal state." A run stuck in-progress (crashed runner, no final status) never reaches a terminal state. There is no timeout, force-cancel step, or escalation path documented. The PR is indefinitely blocked for human merge with no documented resolution.

8. --permission-mode plan misleadingly described as providing a "no-edit review-only run" (workflows/pr-processing.md:1594) — plan mode requires human confirmation for tool calls; in non-interactive -p mode this approval cannot be answered, so tool calls fail at runtime rather than being structurally blocked. The actual tool isolation comes from --tools "". The current description ("used here only for a no-edit review-only run") could lead implementors who add only --permission-mode plan (without --tools "") to believe they have tool isolation when they don't.

[claude]

--safe-mode does not disable built-in tools — prose misattributes tool isolation

The sentence reads: "while --safe-mode disables Claude customizations, built-in tools are disabled, and MCP is isolated…" This implies --safe-mode is responsible for all three effects. Per claude --help, it is not: "--safe-mode — Start with all customizations … Auth, model selection, built-in tools, and permissions work normally."

Built-in tool isolation comes solely from --tools "". A reader who internalizes the prose summary (rather than copying the example verbatim) could omit --tools "", leaving Bash/Edit/Read active against untrusted diff content.

Fix: clarify which flag does what — e.g., "--safe-mode disables Claude customizations (CLAUDE.md, skills, hooks, plugins); --tools "" disables built-in tools; --mcp-config and --strict-mcp-config isolate MCP."

---

verified_diff_file is missing a :? guard in the example

The example shows < "${verified_diff_file}" with no guard. The budget variable gets "${fallback_budget_usd:?fallback_budget_usd must be set to a non-empty number}", but verified_diff_file has no equivalent. An unset or empty variable silently redirects from /dev/stdin; Claude then reviews nothing and can return VERDICT: PASS.

Add a matching guard before the invocation:

: "${verified_diff_file:?verified_diff_file must be set to a non-empty path}"

---

pipefail does not catch an empty diff on the pipe path

The guidance says "use pipefail and check the diff command status." git diff always exits 0, even when there is no diff (e.g. a PR whose commits are already in the base, or a diff between identical trees). pipefail only traps non-zero pipe exits. An empty stream passes silently; Claude returns a vacuous VERDICT: PASS with nothing to block on.

The guidance should also require checking that the captured or piped diff is non-empty before invoking Claude, e.g. [[ -s "${verified_diff_file}" ]] || { echo "empty diff"; exit 1; }.

[claude]

Review gate seam key has no structure for a CI check-name override or an inline-fallback opt-in

This line tells consumer repos to "define that name under their AGENTS.md Review gate policy." The Inline fallback eligibility bullet (line 1460) adds a second requirement: "the consumer repo's AGENTS.md Review gate explicitly enables inline Claude fallback / Silence in AGENTS.md is not permission."

But the Review gate key's documented format — in this repo (independent code review for non-trivial workflow or helper changes) and in the consumer fixture (codex review) — stores prose or a tool command. Neither format has a slot for:

• a CI check name (e.g. my-claude-review vs the default claude-review)
• a boolean inline-fallback opt-in

Without a documented sub-field format, agents and helpers have no machine-readable way to extract either value. The override is silently ignored and claude-review is always assumed; the inline-fallback path is permanently ineligible for any consumer repo that doesn't invent its own ad-hoc format.

The AGENTS.md seam spec needs documented sub-keys before this protocol is actionable, e.g.:

- **Review gate**: `codex review`; review-check-name: `my-claude-review`; inline-claude-fallback: true

[claude]

Bullet-alias cross-references in item 4 are unresolvable

Item 4 says: "Ordinary human merges do not inherit the RC-only score, confidence-block, or waiver-soak bullets unless AGENTS.md says they do."

None of these aliases map to a bold-titled standalone bullet in the auto-merge list:

• "RC-only score" — the score bullet reads "Score is at least 8/10" (no "RC-only" label)
• "confidence-block" — the confidence block concept appears in two prose-embedded bullets (not a named bullet)
• "waiver-soak" — the waiver-soak window appears in an unlabeled bullet

An agent resolving these aliases cannot determine which bullets are excluded from human-merge scope. If the auto-merge list is reordered or any bullet is split, the aliases silently point at the wrong content.

Fix: either give each referenced bullet a bold label that exactly matches the alias used here, or enumerate the excluded bullets by their actual opening text.