docs(ledger): record post-merge audit of PR #1614 (RAG index restore)

[BigSimmo]

Summary

• Requested review: audit the ~21 PRs merged into main over the previous 20 hours for regressions and design-system issues.
• This PR carries the one durable artifact of that review: a docs/branch-review-ledger.md row recording the post-merge audit of PR fix: restore RAG search health indexes #1614 ("fix: restore RAG search health indexes"), a protected RAG-surface change.
• Finding for fix: restore RAG search health indexes #1614: pass — the migration is a guard-only assertion (no DDL, no ranking/RPC behaviour change), correctly classified ragRanking: false by pr-policy.mjs, so no RAG impact: line or eval-canary was required. tests/supabase-schema.test.ts green (74/74). One pre-existing P2 (already tracked as issue #248: no in-repo proof the live indexes exist yet) and one P3 doc nit (renumber note inconsistency) — both non-blocking.
• The other 20 PRs in the window were reviewed but needed no code changes; findings are summarized in the conversation, not in this diff. Full findings recap below for the record.

RAG impact

RAG impact: no retrieval behaviour change — this PR only appends a ledger record; the underlying reviewed commit (a24f74fdf0134487a03dce37dd9f1e9bd18502f5, already on main) is itself a guard-only migration with no ranking/RPC/DDL change, confirmed via pr-policy.mjs's classifyPullRequestFiles returning ragRanking: false.

Full review recap (informational, not part of this diff)

Confirmed and already-fixed regression: PR #1616 ("ui: complete and activate the v2 design system") globally activated the v2 token layer, which included a blue --command token that contradicted the pre-existing, documented color contract (docs/redesign/permanent-colour-direction.md: "graphite for command"). No automated gate caught it — scripts/design-system-contract-utils.mjs doesn't assert literal token colour values, and all 14 production-surface visual-regression baselines were "not-committed / pending approval" at merge time. The regression was live on main (auto-deploys to production) for ~7 hours until PR #1630 reverted it cleanly (verified: no residual blue-token instances remain anywhere in the repo). Recommend tracking "design-system contract has no literal-token-value assertion + baselines not gated at merge" as a follow-up in docs/outstanding-issues.md.

UI hotfix chain (#1615, #1630, #1621, #1629, #1628, #1633, #1635): internally consistent, no conflicts between fixes, no min-h-11 regressions reintroduced, no masked test flakes.

Mockups + editable pins feature (#1618, #1605, #1631): clean. #1631 (real feature, not a mockup) has correct button wiring, tokens, tap targets, <Link>-based navigation, and solid test coverage across 5 test files.

Infra/docs/tooling batch (#1617, #1625, #1627, #1624, #1622, #1620, #1623, #1632, #1634): clean. Sentry-credential scrub (#1622) is real and enforced in 3 places with no leaked secret values. Pre-push gate change (#1620) adds a proper 4th guard, fails closed, doesn't conflict with the existing format/drift/auto-merge guards. Cloud/MCP boundary PRs (#1617/#1625/#1627/#1623) actually strengthen the credential boundary rather than weaken it.

Test plan

• npm run check:migration-role — pass (cited by reviewing subagent)
• npx vitest run tests/supabase-schema.test.ts — 74 passed
• npm run check:outstanding-issues — 253 rows, unique ids, next-id above highest
• npm run check:branch-review-ledger — 607 live + 1206 archived records, merge driver active, no conflicts/duplicates/mojibake

🤖 Generated with Claude Code

https://claude.ai/code/session_01EGgb4y8raYMDE4mAXUGmT6

---

Generated by Claude Code

[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:35 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

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: CHILL

Plan: Pro

Run ID: 0afb74e7-5ba0-447a-8faf-eb8af605da1d

📥 Commits

Reviewing files that changed from the base of the PR and between 6e04add and 1b171cd.

📒 Files selected for processing (1)

• docs/branch-review-ledger.md

---

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

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.