ci(lexicon): gate the generated lexicon report, and correct the remediation records - #1979
Conversation
…iation records Two follow-ups from the Phase 0 close-out review. check:medication-lexicon-report ran in the local verify:pr-local chain but in no CI job at all — a grep across .github/workflows returned nothing. It is the last step of the local chain, so it failed every local preflight while every required check stayed green, which is how the generated file rotted on main until three independent branches tripped over it. That is the open half of #333. It now runs in static-pr under the same scope.static_heavy_changed condition verify-pr-local.mjs already uses, so CI and the local chain agree. The plan and playbook still described the 2026-08-09 world. Corrected to the 2026-08-14 measurement from dispatch run 31813064485: 10 RPC def_hash mismatches (unchanged), 20 missing_live indexes rather than 21, 2 unexpected_live (unchanged), with documents_title_trgm_idx and document_chunks_content_trgm_idx no longer among the missing. Phase 0 is marked complete, Phase 1 partial with 1.2 (the RPC dossier) called out as the gate for Phase 3, and Phase 4 partial. Phase 3 is named as the next step. Both documents now say to check the open-PR list for the surface before starting a phase (#292): Phase 0 was built twice independently on 2026-08-14, and a duplicate in Phase 3 or 4 spends an approved production window and eval-canary budget rather than just tokens. The ledger row title is quoted verbatim in the playbook and still contains "21" on purpose — the playbook resolves the tracking anchor by exact title, so editing the quote would break that lookup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BKNFogaYfCQBvFVqFQnfRt
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:30 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 (6)
Comment |
Merge-safe inbox request; docs/outstanding-issues.md is untouched and is reconciled separately after this PR lands. Both halves of the row are addressed: the regeneration in #1951 and the CI wiring in this PR. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BKNFogaYfCQBvFVqFQnfRt
…rchived #333 was closed by another session while this branch was in flight, so the queued done request was invalid and made applyRequestBatch throw with "#333 is already archived", red-lining docs:check-links for this branch. Removing the request rather than cancelling it is the correct mechanism here: the file only ever existed on this branch and never reached main, so its removal nets to zero against the write-discipline guard's base. Verified: ledger write discipline passes and docs:check-links is green again. My pre-check was too weak and is worth recording. I checked that no competing mutation targeted #333 and that a #333 row existed, but the existence grep matched the ARCHIVED row. The check that mattered was whether the row was still in the open table. The substance is unaffected: the CI wiring in this PR is what #333 asked for, and the row's own closure note already records it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BKNFogaYfCQBvFVqFQnfRt
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:3ebe802629
ℹ️ 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.
Uh oh!
There was an error while loading. Please reload this page.
BigSimmo
commented
Aug 15, 2026
@codex resolve actionable Codex review findings for this pull request and current head using the repository instructions. This is the pull request's single automatic repair pass: do not perform a fresh review, create new standalone findings, or request another review. Work only the existing unresolved Codex threads on the current head. The only repository destination is BigSimmo/Database, and the only branch destination is the pull request head branch claude/ledger-guard-ci-followups at starting commit 9278f96; never publish fixes to a detached or synthetic work branch and never create a stacked pull request. Use the authenticated GitHub connector to commit each approved fix to BigSimmo/Database:claude/ledger-guard-ci-followups, then verify that the pull request head contains the published commit before reporting success. Always fix P0 and P1 findings. For P2 and lower findings, fix only clear, scoped, low-risk issues; otherwise disposition them with a concise reason. For a fixed thread, reply with as the first line and as the second line. For a no-code disposition, use followed by . These result markers authorize the workflow to close that exact thread only after it verifies a fixed commit is the pull request head; a local-only commit is not a fix. If publication or verification fails, do not use either result marker, do not claim success, and leave the thread open with the blocker. If human input or new authorization is required, do the same. Finish only after every actionable thread is fixed or dispositioned and closed, or explicitly left open for a human decision. Do not update the branch from main, address unrelated reviews, broaden scope, or create more than one scoped fix commit. Do not use external APIs, paid services, credentials, dependency changes, or broad refactors unless explicitly authorized. Add targeted tests where behavior changes and run the narrowest relevant validation. |
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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.
…nchor Two stale pointers in the playbook's context briefing, both of which misdirect a fresh session before it reads anything else. The phase status block still said Phase 1.2 was outstanding and gating Phase 3, and named "complete 1.2, then Phase 2" as the next step. Both have since landed: 1.2 in PR #2087 (all ten mismatches attribute-only SET work_mem, zero body divergence, zero repo-ahead, zero UNCLASSIFIED) and Phase 2 in PR #2093 (staging at full parity, check:drift against staging red with 19 items — the finding the phase existed to produce, with a re-measure owed once staging carries 20260818090000). Phase 6 is repo-side complete with its migration deploy still owed. The block now records that and defers to docs/database-remediation-coordination.md as the live board rather than becoming a second source of truth beside it. It also flags that Phase 3 has been reframed: zero repo-ahead bodies means no eval canary, which the Phase 3 prompt further down this file still assumes. That prompt and the traps list are deliberately left untouched here — the reframing and its owner decisions belong to the coordination board, and duplicating them would recreate the drift this change is repairing. The tracking anchor quoted the row title "Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge". The row has since been retitled to "Live DB has 20 currently missing repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing", so the exact-title lookup the playbook instructs could no longer match. The "21" was preserved deliberately in #1979 because it was the lookup key; correcting the row is what broke it. Anchor updated to the current title, verified character for character against the row on main. No issues:update queued: #316 and #56 are owned by other running chats, and a second pending mutation on either row would make the inbox refuse the batch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BKNFogaYfCQBvFVqFQnfRt
Summary
The two remaining follow-ups from the Phase 0 close-out review. Companion to #1978 (the ledger and push-guard defects); independent of it, based directly on
main.check:medication-lexicon-reportnow runs in CI. It previously ran in no CI job at all — a grep across.github/workflows/returned zero hits. It sits at the end of the localverify:pr-localchain, so it failed every local preflight while every required check stayed green. That asymmetry is exactly how the generated file rotted onmainuntil three independent branches tripped over it, and it is the open half of#333.The CI gate
Added to
static-prunder the samescope.static_heavy_changedcondition thatscripts/verify-pr-local.mjs:133already uses, so CI and the local chain now ask the same question. A stale clinical-facing generated artefact blocks a merge instead of only annoying whoever is handing off.#333framed this as a real choice — wire it into CI, or drop it fromverify:pr-localso it stops failing preflights it does not gate. Wiring it in is the right half: the staleness it detects is genuine, and the file is a clinical artefact.The records
Corrected to the 2026-08-14 measurement from dispatch run
31813064485:match_*RPC bodiesmissing_liveindexesunexpected_liveindexesdocuments_title_trgm_idxanddocument_chunks_content_trgm_idxare removed from the missing list — both were restored in the 2026-08-14 incident window and independently re-verifiedindisvalid/indisready(648 kB and 68 MB).Phase statuses now reflect reality: Phase 0 complete, Phase 1 partial (1.1 and 1.3 done in the owner-authorised window; 1.2, the RPC dossier, outstanding and gating Phase 3), Phase 4 partial (two indexes restored, ~20 remain). Both documents now state plainly that Phase 3 is next, per the plan's own ordering — the change that can alter clinical answers precedes the ones that only speed them up.
Both also now carry the instruction to check the open-PR list for the surface before starting a phase (
#292). Phase 0 was independently built twice on 2026-08-14; a duplicate in Phase 3 or 4 spends an approved production window and eval-canary budget, not just tokens.Deliberate non-change: the ledger row title quoted in the playbook still reads "…missing 21 repo-defined indexes". The playbook resolves the tracking anchor by exact title, so editing the quote would break that lookup. The corrected figures sit alongside it.
Verification
npm run verify:pr-localnpm run check:github-actions→GitHub Actions pin check passed.npm run check:ci-scope→CI change scope self-test passed.npm run docs:check-links→docs link check passed: 1772 repo path references resolve.Not run:
verify:ui(no UI change); provider-backed gates (nothing here touches a provider). No new action is introduced, so no new pin review is required.RAG impact
Not required: no file under
src/lib/rag/**, nomatch_*RPC, no ranking, selection, eval-harness or fixture surface. The RPC mismatches are described in the docs, not changed.Risk and rollout
main, and adds no action or permission.git revertthe single commit. Reverting restores the previous (unwired) gate and the stale figures; nothing is stateful.Notes
guard-pushbase resolution. The two are independent and can land in either order.SUPABASE_ACCESS_TOKENin environment secrets (#183) — dashboard work, values not handled here.Generated by Claude Code