docs: prlanded records for #1204/#1215/#1220 + fix the prlanded landing check#1229
Conversation
…t main Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 47 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 (2)
✨ 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 |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
2 participants
Documentation only, from running
/prlandedon the merged #30 search-correctness work.Ledger records.
docs/branch-review-ledger.mdhad no landing record for PRs #1204, #1215, or #1220, so this appends one row each with the squash SHA, what landed, and how it was verified. All three were confirmed landed by tree comparison against their squash commits (eb443dfd,b2d794c5,e7e60c6d), each identical to its branch tip. The #1220 row also records the merge friction worth remembering: agithub-actions[bot]branch-sync merge landed on the PR branch every 10–20 minutes, and every bot-authored head producedaction_requiredworkflow runs, so the three required checks never reported and both a normal and an--adminmerge were refused. Runs on agent-pushed heads execute normally, so the resolution was to push an own-authored head and merge on green.Skill fix. Step 2 of
.claude/skills/prlanded/SKILL.mdtold you to rungit diff --stat origin/main...<branch>. Three-dot diffs from the merge base, which after a squash is still the pre-mergemain, so it replays the branch's own delta and reports a false orphan on every fresh merge — it did exactly that today for #1220, on a branch whose content demonstrably landed. Replaced with a two-dot tree comparison against the squash commit, which stays correct after other PRs land onmain, plus a note explaining why the three-dot form is wrong here.RAG impact: no retrieval behaviour change — documentation and skill text only.
Checks:
npm run check:branch-review-ledger(925 records, union merge active, no duplicates),npm run format:changed,npm run docs:check-links,npm run verify:cheap(387 test files, 3431 tests).