docs(issues): reconcile the inbox batch, correcting a false #310 row on main - #1961
Conversation
Runs `npm run issues:reconcile` from a fresh base off origin/main (0011a05), applying all 35 pending requests with 5 cancellation decisions. The motivating case is #310, which main was carrying with a false statement. Request 8621298b ("NOT REACHABLE ON MAIN ... The whole matcher is gone") had been applied, while the cancellation queued against it was lost in the PR #1943 squash. The correcting closure 00428ff0 survived as a pending request, so this reconcile applies it: #310 now records that 247a359 re-landed the matcher with typoDistanceLimit >=5 -> 1 and both regression tests, and the false text is gone from the file. The lost cancellation was deliberately NOT re-filed. Its target is already in applied/, so planRequestBatch would reject it with "cancel request targets missing pending request" and block every future reconcile. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122UC4BL5R39kz41WbBYcPj
This session ran `npm run format` in a container with no node_modules. Prettier resolved through npx as 3.8.1 while the repo pins ^3.9.6 (lockfile 3.9.6), and the older binary rewrote 31 files nobody had touched — including src/lib/rag/rag-cache.ts, src/lib/rag/rag-provider.ts and src/lib/openai.ts, which would have flipped a docs-only PR into ragRanking/clinicalRisk scope under classifyPullRequestFiles. It was an artifact, not drift: `npx prettier@3.9.6 --check` on the same files reports them clean. The reformat was reverted and never committed; this row records the trap so a later uninstalled session does not repeat it, and proposes pinning the binary in format/format:changed or failing closed on a lockfile mismatch. Same failure class as archived row #87 (knip findings from an uninstalled worktree), but worse: knip only reports, format writes, so the false result arrives already applied to the working tree. Filed as a pending request rather than folded into the preceding reconcile: a reconcile must only consume requests already present on its base, and check:ledger-write-discipline rejects the bundle otherwise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122UC4BL5R39kz41WbBYcPj
|
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: 5 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 997d0b2f2a
ℹ️ 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".
|
Final review summary Final PR head: The original 35-request reconciliation and #310 correction were already present in the current base. I performed the required base-preserving sync, retaining only the legitimate new pending Prettier-version-trap request, and recorded the current-base review. An independent fresh-context Codex review confirmed no remaining final-tip P0/P1/reproducible P2. The CodeRabbit #331/#333 P2 was valid historically but is already addressed by the current base’s serialized inbox requests; I replied with the request evidence and resolved the thread. The stale lexicon report remains tracked upstream, not in this PR’s final diff. Decisive local checks: docs-link, ledger inbox, ledger self-test, ledger guard, and diff check passed. Exact-head CI is green: Secret Scan, SAST, and CI The PR was not merged. Final merge is left to the user. |
2 participants
Summary
npm run issues:reconcilefrom a fresh base offorigin/main(0011a05), applying all 35 pending requests with 5 cancellation decisions. Pending drops to 1 (the request added in the second commit); applied rises to 129.#310, whichmainwas carrying as a false statement. Request8621298b("NOT REACHABLE ON MAIN AS OF 2026-08-13 … The whole matcher is gone") had been applied, while the cancellation queued against it was lost in the PR docs(issues): close #310 — the fuzzy catalogue cap already landed on main #1943 squash. The correcting closure00428ff0survived as a pending request, so this reconcile applies it.grep -c "NOT REACHABLE ON MAIN AS OF 2026-08-13"now returns 0, and#310records that247a359re-landed the matcher withtypoDistanceLimit >= 5 → 1plus both regression tests.Why the lost cancellation was not re-filed
Deliberate, and verified rather than assumed. Its target
8621298bis already inapplied/, soplanRequestBatchrejects it:Re-landing it would block every future reconcile. The closure alone is sufficient, and is what corrects the row.
Why the two commits are separate
A reconcile may only consume requests already present on its base. Folding the new Prettier request into the same branch made
check:ledger-write-disciplinefail:That check is correct and the first attempt was resequenced rather than worked around — the reconcile now consumes only base requests, and the new request rides as its own separately revertible commit.
Verification
npm run check:outstanding-issues—Ledger inbox check passed: 1 pending request(s), 129 applied./Outstanding-issues guard passed: 334 rows (99 open, 235 archived), unique ids, next-id=337 above the highest, no merge driver, no ids deleted from base 0011a058fd1d.npm run check:ledger-write-discipline—Ledger write discipline passed for 0011a058fd1d..HEAD.npx prettier@3.9.6 --checkon the new request file —All matched files use Prettier code style!. The pinned version is used explicitly;docs/outstanding-issues.mdis Prettier-ignored (.prettierignore:47).Would reconcile … with 5 cancellation decision(s), and the batch composition recomputed against the 35 requests actually onmainas 13 closures, 6 updates, 6 additions, plus the 5 cancellations.Verification not run: npm run verify:pr-local— this container runs Node v22.22.2 against a repo requiring 24.x with nonode_modules, socheck:runtimefails atresolve-tsx-clibefore the plan starts. Its selector classifies this scope as recognised low-risk docs; the ledger-specific checks that actually cover this diff were run individually and are quoted above. CI runs the real gate.UI verification not run:no UI, routing, styling, or browser behaviour changed.Risk and rollout
docs/outstanding-issues.md, the canonical cross-session ledger. The transaction is tool-generated and validated bycheck:ledger-write-discipline, which enforces that the canonical diff exactly equals the recorded reconciliation transaction. The main hazard is a concurrent reconcile from another session; nothing here should be resolved with GitHub's "Update branch" button.git revertthe reconcile commit restores the prior ledger and returns the applied records to pending; the two commits are independently revertible before merge.Clinical Governance Preflight
Not applicable — measured, not assumed.
classifyPullRequestFilesreturnsclinicalRisk: false,operationalRisk: false,ragRanking: false,ui: falsefordocs/**paths. NoRAG impact:line is required; nothing undersrc/lib/rag/**is touched. Note the subject of#310is clinical (catalogue drug-name matching), but the correction records a fix that already shipped in247a359— no clinical behaviour changes in this diff.Notes
claude/fuzzy-search-reland-cap-aobmqx, whose PR docs(issues): close #310 — the fuzzy catalogue cap already landed on main #1943 has already merged. A new branch was used because rebuilding that branch required a reset and force-push; this route needed neither.#310correction is the reason this is worth landing promptly: until it merges, the clinical-safety ledger tells any reader that the fuzzy-matcher hazard is live and unfixed, when it was fixed by247a359.🤖 Generated with Claude Code
https://claude.ai/code/session_0122UC4BL5R39kz41WbBYcPj