Complete #108's prerequisite and correct its branch list - #1403
Conversation
Re-verified the five branches against the live remote before touching anything, which mattered: claude/clinical-kb-pwa-review-asi3wb and claude/dazzling-blackwell-f348d0 are already gone, deleted by someone with the permission this session lacks and surfaced only by `git remote prune`. The list is three, not five, and #108 said five. The remaining three are still at exactly the recorded HEADs, and the proof was re-run and strengthened. For each, tree(tip) == tree(merge-base) byte-for-byte, so the branch nets zero content change from where it forked and nothing on it is absent from main. That is stronger than either check the cleanup guide names: --cherry-pick still reports 13/6/4 patch-unique commits on them, which is the squash-merge false positive the guide warns about, and none is an ancestor of main, so an ancestry --merged check would miss them too. A completed `branch-cleanup` row keyed to its own HEAD is now appended for each, which is the step that had to happen while the objects still exist — resolveHead refuses a HEAD that is not a commit in the repository, so the reverse order is unexecutable. check:branch-review-ledger passes at 1272 records with union merge intact. The refs can now be deleted safely at any time. Deletion itself is still blocked and is not mine to unblock: `git push origin --delete` exits 1 with HTTP 403 from the session git proxy, with recentRelayFailures empty, so it is credential scope rather than a relay fault; and the GitHub MCP set exposes create_branch but no delete-branch capability. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012YRCXgX4AWZ579bKN6sk6b
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:7 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 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 Run ID: 📒 Files selected for processing (2)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:7e63d1538e
ℹ️ 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".
Uh oh!
There was an error while loading. Please reload this page.
Codex raised a P2 on PR #1403: marking these HEADs `branch-cleanup` suppresses future inspection while the rows themselves report 13/6/4 patch-unique commits, and tree equality between tip and merge-base only proves the branch's changes cancel in its final snapshot, not that each unique patch reached main. The conclusion does not hold for these branches, and measuring it settles which it is. For all three, the merge-base is an ANCESTOR of main — so tree(tip) == tree(merge-base) means every byte at the tip exists in main's own history. The changes did not cancel; they landed. The branches merged main in after their own PRs were squash-merged, which is why their diffs went empty. Checked concretely on the largest: the feature commit's new files (src/components/document-viewer/use-document-view-density.ts, use-printable-disclosures.ts, tests/document-view-density.dom.test.tsx) are present on origin/main as byte-identical blobs, and the 13 "unique" commits are six merges of main plus seven commits whose content is on main. But the procedural half of the finding was right. My original rows recorded tree equality WITHOUT recording that the merge-base is an ancestor of main — and tree equality alone does not imply the content is on main, since a tip could match an off-main commit. The proof was sound and the record of it was not. These superseding rows carry the full chain. The original exact-scope rows are left in place, so hasCompletedCleanupReview still resolves them; the ledger is append-only and this adds evidence rather than revising history. Verified: ancestry measured for all three merge-bases (855aa29, 79d1c87, b274048), not inferred from the one I had checked. check:branch-review-ledger passes at 1282 records with union merge intact. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012YRCXgX4AWZ579bKN6sk6b
Uh oh!
There was an error while loading. Please reload this page.
Second conflict in docs/outstanding-issues.md in under an hour, same shape: main re-padded the table so the hunk spanned every row, while only two rows differed. Took main's #108 (completed by #1403) and kept this branch's #115 closure. #116 does not collide — main's next-id was still 116. This recurrence is the case #116 itself describes: while conflicted, the PR ran no CI at all and nothing said so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Akwz3Sdms8uJ5AkDt3CduY
Summary
Two documentation files, no code. This does the part of
#108that is doable in-session and corrects the part of it that was wrong.The list was wrong, and re-verifying against the live remote is what caught it.
#108named five branches awaiting deletion. Two —claude/clinical-kb-pwa-review-asi3wbandclaude/dazzling-blackwell-f348d0— are already gone, deleted by someone with the permission this session lacks, and they surfaced only asgit remote pruneoutput while I was pushing something unrelated. Acting on the stale list would have meant chasing two refs that no longer exist.The remaining three are still at exactly the recorded HEADs, and the proof is now stronger than the guide's own checks:
tree(tip) == tree(merge-base)--cherry-pickmaincodex/document-reader-condensed-viewb5cdbf30cursor/page-anchored-search-composer-30ee7ff134cacursor/pr-1379-babysit-ledger-9365be2de03fIdentical trees mean each branch nets zero content change from where it forked, so nothing on it is absent from
main. Both of the signalsdocs/branch-cleanup-guide.mdnames would have been misleading here:--cherry-pickreports 13/6/4 patch-unique commits (the squash-merge false positive the guide's own preamble warns about), and none is an ancestor ofmain, so an ancestry--mergedcheck misses them too. Tree equality is decided by neither patch-ids nor ancestry, which is why I used it.The ordering prerequisite is now satisfied. A completed
branch-cleanuprow keyed to its own HEAD is appended for each of the three. That had to happen while the objects still exist —resolveHeadrunsgit rev-parse --verify <sha>^{commit}and refuses a HEAD that is not a commit in the repository, so append-after-delete is unexecutable. The refs can now be deleted safely at any time, in any order.Deletion is still blocked, and it is not mine to unblock.
git push origin --deleteexits 1 with HTTP 403 from the session git proxy;recentRelayFailuresis empty, so this is credential scope rather than a relay fault. A tool search confirms the GitHub MCP set exposescreate_branchbut no delete-branch capability. The three refs need the GitHub UI or a session whose credentials permit ref deletion — nothing else is required first.Verification
npm run check:branch-review-ledger—Branch review ledger guard passed: 1272 table records (67 under the 2026-07-29 machine-readable contract), union merge active, six cells each, no conflict markers, mojibake, heading records, or duplicates.npm run ledger:lookupfor each of the three before appending — all threeNOT REVIEWED at this HEAD and scope, so no duplicate rows were created.npm run ledger:appendrather than hand-written, perAGENTS.md.npm run docs:check-links—docs link check passed: 1375 repo path references resolve.docs/outstanding-issues.mdintegrity: 115 rows, 115 unique ids, none added or dropped.npx prettier --checkon both files —All matched files use Prettier code style!git ls-remote origin refs/heads/<branch>rather than local tracking refs, which is how the two deletions were found.verify:cheapnot run: the diff is two markdown files with no code, and both files' dedicated guards are green above.npm run check:production-readinessnot run: no clinical workflow, privacy, environment, Supabase, source-governance or deployment change.Risk and rollout
branch-cleanupledger rows, which mark those HEADs as reviewed so a later sweep stops resurfacing them — intended, and appended only after per-branch content proof.--supersede), not an edit. Reverting this PR'sdocs/outstanding-issues.mdchange is safe on its own.Clinical Governance Preflight
Not applicable to this diff. The changed paths are
docs/outstanding-issues.mdanddocs/branch-review-ledger.md;classifyPullRequestFilesreportsclinicalRisk: falsefor both. No ingestion, answer generation, search/ranking, source rendering, document access, privacy or clinical output behaviour changed.Notes
RAG impact: no retrieval behaviour change — no file under
src/lib/rag/**, clinical-search, retrieval-selection, released-search-order, ranking-config, answer-ranking, the eval harness, the golden fixture, or the retrieval RPCs is touched.The branch was restarted from the post-#1402
main, so this is a new branch and a new PR rather than a reopen.Worth recording for whoever picks
#108up: the two already-deleted branches are the argument for re-verifying a stored branch list againstgit ls-remotebefore acting on it, not against local remote-tracking refs. That is the same class of mistake as#109— trusting a local view of remote state — and it is why the list was three rather than five.🤖 Generated with Claude Code
https://claude.ai/code/session_012YRCXgX4AWZ579bKN6sk6b
Generated by Claude Code