docs(issues): correct #316's next step — Phase 3 has no executable entries (#316)

[BigSimmo]

Summary

#316 reads NEXT: Phase 3 RPC reconciliation. That is not executable as written, and correcting it before the knowledge is lost is the whole point of this PR.

• Phase 3's prerequisite in docs/database-remediation-playbook.md is the Phase 1 dossier with "10 diffs classified".
• docs/audit/live-drift-forensics-2026-08.md §1.2 records all ten as UNCLASSIFIED, with "per-function diff hunks still pending".
• Phase 3's own pasted prompt says any UNCLASSIFIED entry "stays untouched and is escalated to me".

So Phase 3 has zero executable entries today, and a production window would accomplish nothing. The real next step is a read-only window to finish Phase 1.2 — far cheaper and lower-risk than the production window this row's wording implies.

This is documentation only: one queued inbox request, cumulative over #316's existing detail rather than replacing it. No code, schema, migration, or live call. The Supabase MCP server was unauthenticated in this session, so the read-only work this row now points at could not have been done here even with approval.

A hypothesis prepared offline that should shorten that read-only window

• def_hash is computed in migration 20260706200000 as md5 of pg_get_functiondef with block comments, line comments and all whitespace stripped — it does not strip SET attributes, which pg_get_functiondef renders.
• 20260724000000_optimize_rpc_work_mem.sql applies ALTER FUNCTION … SET work_mem = '64MB' to exactly eight of the ten UNCLASSIFIED functions.

So one read-only query — does live carry that attribute on those eight? — plausibly classifies 8 of 10 in a single step. If live lacks it, those eight are repo-ahead but non-behavioural for answer content (a planner memory setting affects latency, not ordering or content), so they would not need the full eval-canary pair Phase 3's repo-ahead rule assumes.

Recorded explicitly as a hypothesis, not a finding: live state was never read. The two outliers, match_document_chunks_text_v2 and match_document_index_units_hybrid_v2, are absent from that migration and need their own diffs; their canonical migrations are named in the request.

One discarded line of reasoning, recorded so nobody repeats it

"The drift manifest never mentions work_mem" proves nothing either way. supabase/drift-manifest.json stores only signature, def_hash and acl per function and never stores body text at all, so its silence is not evidence. I nearly used it as evidence before checking the manifest's actual shape.

Verification

• npm run verify:pr-local — docs route. Worth reporting honestly: it first failed, because check:ledger-write-discipline correctly refused to give a verdict on a then-uncommitted inbox request ("this gate compares two committed refs… a pass would mean nothing"). After committing, it passes:

ledger write discipline self-test passed.
Ledger write discipline passed for d0276718477c..HEAD.

• npm run check:branch-review-ledger: 880 live table records + 1206 archived + 226 immutable … no conflict markers, mojibake, heading records, or duplicates.
• npm run check:outstanding-issues: 341 rows (97 open, 244 archived), unique display and durable ids … no ids deleted from base d0276718477c. Inbox: 12 pending request(s), 189 applied.

No provider-backed gate was run and none applies — no code, schema, or migration changed. verify:ui is not applicable and is not runnable in this container regardless (Playwright ships chromium-1194 against a pinned 1234, #255/#312), so no browser coverage is implied.

Risk and rollout

• Risk: low. One documentation request file. It changes no runtime behaviour, no schema, and no generated artefact. The residual risk is editorial — that the correction itself is wrong — which is why every claim cites the exact playbook section, forensics section, or migration filename it comes from, and why the work_mem hypothesis is labelled as unverified rather than asserted.
• Rollback: git revert either commit, or cancel the queued request before reconciliation runs. Nothing depends on the file.
• Provider or production effects: None. No Supabase, OpenAI, deployment, or environment access; the Supabase MCP connector was unauthenticated in this session.

Notes

• RAG surface flagged, not touched. The RPCs this row concerns are protected retrieval surface. Nothing under src/lib/rag/**, the retrieval RPCs, the eval harness, or the golden fixture was edited, so no RAG impact: line is required (classifyPullRequestFiles returns ragRanking: false). Any actual Phase 3 work still needs the flag-before-editing step, the RAG impact: line, and per-RPC approval the playbook already specifies.
• #316 stays open, and its two real blockers are unchanged: your approval for a read-only window, and authorising the Supabase MCP connector via claude.ai connector settings in an interactive session.
• Run npm run issues:reconcile on its own serialized branch once the session's PRs have landed. There are 12 pending requests; two of them update #318, and they happen to apply in the safe order because reconcile sorts by UUID filename (46750cbf before the cumulative db498cc1) — worth a glance at reconcile time, since that ordering is coincidence rather than design.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PZL59KVSBWURMKvfc9mbJr

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[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: 53 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 93 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour.

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: f566f2e8-d2bc-4bb1-be34-4674a7fe8854

📥 Commits

Reviewing files that changed from the base of the PR and between d027671 and 192b70f.

📒 Files selected for processing (2)

• docs/branch-review-records/9c51e4a42ec2ecfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md
• docs/outstanding-issues-inbox/855d03b3-61a8-4a81-ad31-80d996dd581a.json

---

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

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