ci(review): review the design sweep's stacked PRs, not just the first one

[guarzo]

What

Adds reviews.auto_review.base_branches: ["design-sweep/.*"] to .coderabbit.yaml.

Why

base_branches defaults to empty, and empty means automatic review fires only on PRs targeting the default branch. The design-sweep-loop skill opens one PR per round based on the previous round's branch, so every PR in a sweep stack except the first was out of scope.

Observed on the 2026-08-06 unattended run:

PR	Base	CodeRabbit
#133	main	Review rate limited
#134	design-sweep/2026-08-06-2	Review skipped — reviews are disabled for this base branch
#136	design-sweep/2026-08-06-3	Review skipped — reviews are disabled for this base branch
#137, #138	stacked	Review rate limited

The quiet part is that gh pr checks prints CodeRabbit pass for a skipped review exactly as it does for one that ran and found nothing. An unattended run reports a second opinion it never received. The one real finding on #134 surfaced only because the review was requested by hand — and a manual request is not subject to the base-branch scope, which is how we know the two are separate mechanisms.

Scope choice

design-sweep/.* rather than .*, so this does not also enable review on the ad-hoc worktree-* branches that occasionally serve as a base for stacked work.

The account-wide rate limit that hit the same run is a separate problem and is not addressed here — that one is a fair-usage throttle, not configuration. It has been handled on the skill side by waiting out the limit before re-requesting.

Verification

• npm run format:check — All matched files use Prettier code style!
• YAML parses; base_branches lands under reviews.auto_review alongside drafts and the ignore_* keys.
• No TypeScript touched, so npm test / npm run typecheck are not implicated and were not run.

Not yet confirmed end-to-end: the mechanism rests on CodeRabbit's documented default and its own skip message. Proof is the next stacked PR opened after this merges — if it gets an automatic review, this worked.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 52 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: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2924be47-ac81-4501-bd82-c227041a5dfa

📥 Commits

Reviewing files that changed from the base of the PR and between ea65e2c and ddc1ac6.

📒 Files selected for processing (1)

• .coderabbit.yaml

---

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