ci(drift): route live-drift failures to a pinned issue and trigger on migrations

[BigSimmo]

Summary

Phase 0 of docs/database-remediation-plan.md — repo-side enablement only. No hosted Supabase access of any kind was used, and no Supabase code, migration, or RAG surface is touched.

• Drift-failure routing (plan step 0.1). A new drift-routing job creates or updates a single pinned issue titled Live drift check failing (label live-drift-failure) carrying the captured drift finding lines plus the run URL. Repeated failures update that same issue in place and add a short "still failing" comment, rather than stacking new issues. The next green run comments the resolution and closes it. Modelled on the existing rolling-issue pattern in .github/workflows/ops-digest.yml.
• Least-privilege split. Workflow-level permissions stays contents: read. issues: write is granted only to drift-routing, which runs a single inline actions/github-script step and never checks out or executes repository code. The live-drift job that runs npm ci and the drift scripts keeps contents: read and gains no new permission.
• Finding capture. Compare live schema drift now tees its output (with an explicit set -o pipefail, since the default step shell is bash -e without it, which would otherwise mask a failing check:drift behind tee's exit code). An if: always() step greps the line shapes emitted by scripts/check-drift.ts:280-311 into a job output. When a run dies before the comparison — missing secret, identity guard — the issue says so explicitly rather than implying a clean schema.
• Post-migration trigger (plan step 0.2). live-drift also runs on pushes to main touching supabase/migrations/** or supabase/schema.sql, so drift is checked within minutes of the change that could cause it instead of up to a week later.
• Evidence scaffold (plan step 0.4). docs/audit/live-drift-forensics-2026-08.md gains dated, empty, headed sections for Phases 1–5, each naming its approval requirement.

workflow_dispatch, the weekly 30 18 * * 0 schedule, the secret preflight, and concurrency.cancel-in-progress: false are all unchanged.

Two corrections to the task as written

1. The tracking anchor is #316, not #312. The playbook says to resolve the anchor by exact title and "never assume an ID". #316 is the P1 titled "Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing". #312 is an unrelated P3 about check:playwright-browser-revision. The ledger update targets #316.
2. The forensics doc already existed as a 5-line stub, so it was extended rather than created — the smallest change meeting the Phase 0 definition of done.

RAG impact

Not required, and stated explicitly: classifyPullRequestFiles returns ragRanking: false and clinicalRisk: false for this diff (operationalRisk: true, from .github/workflows/**). No file under src/lib/rag/**, no match_* RPC, no ranking, selection, eval-harness, or golden-fixture surface is touched.

Smallest-change choices made where the task was open-ended

• Findings are passed to the routing job via a job output rather than an upload/download-artifact pair — no additional pinned actions, no new script file, and no docs/scripts-index.md entry to maintain. Capped at 80 lines to bound the issue body.
• Extraction is an inline grep in the workflow rather than a new scripts/*.mjs, to avoid adding a gate/doc-index surface for six lines of pattern matching.
• The pinned issue is found by label, not title, so a human retitling it does not orphan it and start a second thread.

Verification

• npm run verify:pr-local

PR-local verification summary:
- completed: check:runtime, check:installed-lock-parity, format:changed, sitemap:check,
  docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links,
  check:branch-review-ledger, check:outstanding-issues, check:ledger-write-discipline,
  check:github-actions, check:ci-scope, check:gitleaks-pinned, check:ci-triage,
  check:pr-policy, check:gate-manifest, check:skills, check:pr-mergeability,
  check:verification-plan, test:ci-workflows
- failed: (none)
- not reached: (none)

Its test:ci-workflows leg: Test Files 14 passed (14) / Tests 302 passed (302).

• npm run check:github-actions — GitHub Actions pin check passed.
• npm run format run and the result committed. Independently confirmed on the two changed files: npx prettier --check → All matched files use Prettier code style!

Additional local proof beyond the required gates, since the repo has no YAML parser in its dependency tree and its workflow checks are text-based:

• Parsed the workflow with PyYAML and asserted structure: triggers ['workflow_dispatch', 'schedule', 'push']; push: {"branches": ["main"], "paths": ["supabase/migrations/**", "supabase/schema.sql"]}; concurrency: {"group": "live-drift-check", "cancel-in-progress": false}; workflow permissions: {"contents": "read"}; live-drift job-level permissions null (inherits read-only); drift-routing permissions {"contents": "read", "issues": "write"}; secret preflight step still present.
• Extracted the embedded github-script body and ran node --check on it → syntax OK.

Not run, with reasons: verify:ui (no UI, routing, styling, or browser behaviour changed). verify:release, check:production-readiness, and all eval:* gates (provider-backed; this phase is explicitly hosted-access-free). Lint, typecheck, the full unit suite, and the RAG fixture scan were skipped by verify:pr-local itself as recognised low-risk scope, and the build as having no build-affecting changes.

The one Phase 0 definition-of-done item deliberately left to the operator: the playbook asks that a forced workflow_dispatch failure be observed producing the pinned issue. Dispatching the workflow is provider-backed and touches live Supabase, so it is out of scope for this phase's constraints and is recorded as outstanding in the forensics doc.

Risk and rollout

• Risk: Low. The change is additive to a scheduled/manual workflow that runs on no pull request. The routing job cannot affect the drift verdict — it only reads needs.live-drift.result and writes an issue; if the script itself throws, that job fails visibly without changing the drift job's outcome. The new push trigger is path-filtered to supabase/migrations/** and supabase/schema.sql on main only, and cancel-in-progress: false means added runs queue behind the weekly one rather than cancelling it. The one behavioural change inside the existing job is set -o pipefail on the drift step, which makes a check:drift failure more likely to be reported, not less.
• Rollback: git revert the single commit. Nothing is stateful and no migration, schema, or manifest is involved. If only the routing is unwanted but the trigger is worth keeping, delete the drift-routing job and the Capture drift findings step; the live-drift job then behaves exactly as it does on main today. A pinned issue left open after a revert can simply be closed by hand.
• Provider or production effects: None. No Supabase call, no workflow dispatch, no eval, no deployment change. Once merged, the workflow will — on its own schedule or on a migration push — open one GitHub issue in this repository on failure; that is the intended effect of the change.

Notes

• npm run format also reformatted 31 files unrelated to this change, including src/lib/rag/rag-cache.ts, src/lib/rag/rag-provider.ts, scripts/ci-change-scope.mjs, and several components and docs (mostly union-type and prose reflow). That is pre-existing formatting drift on main, not produced by this diff. All of it was reverted and is not in this PR, which keeps the diff to the two intended files and avoids dragging protected RAG surfaces into a docs/workflow change. Worth a separate follow-up: main currently does not satisfy a whole-tree prettier --check.
• This container ships Node 22 and Node 20; the repo requires Node 24.x with engine-strict, so the first npm ci failed EBADENGINE and left tsx unresolvable, which failed check:runtime. Node 24.19.0 was installed via the container's nvm and the dependencies reinstalled cleanly (npm ci --include=dev exit 0, npm 11.17.0) before the gates above were run. Repository code was not changed to accommodate the environment.

---

Generated by Claude Code

[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 ↗︎.

[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: 43 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: 79149378-8f96-4529-98b9-9a114c10aa9c

📥 Commits

Reviewing files that changed from the base of the PR and between 87fa452 and 3b313d5.

📒 Files selected for processing (3)

• .github/workflows/live-drift.yml
• docs/audit/live-drift-forensics-2026-08.md
• docs/outstanding-issues-inbox/17e1baf4-7d8f-4494-acd6-a845ade305ca.json

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/db-remediation-phase-0-wfaiyl

---

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d20e7d9096

ℹ️ 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".

[BigSimmo]

@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/db-remediation-phase-0-wfaiyl at starting commit 5e4b5fd; 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/db-remediation-phase-0-wfaiyl, 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.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 5e4b5fdb29

ℹ️ 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".