docs(db): refresh the playbook phase status and repair the tracking anchor

[BigSimmo]

Summary

Two stale pointers in the playbook's context briefing. Both sit above everything else in the file, so they misdirect a fresh session before it reads a single phase.

1. The phase status block described a world two phases out of date

It still said Phase 1.2 was "outstanding and gating Phase 3" and named "complete Phase 1.2, then the Phase 2 staging-parity rehearsal" as the next step. Both have landed:

• Phase 1 complete — 1.1 (20260705180000 not mark-applied; the dashboard audit-history pairing is still owner action, so #248 stays open), 1.2 in PR docs(db): Phase 1.2 RPC divergence dossier — all ten match_* mismatches classified (#316) #2087 (all ten mismatches attribute-only SET work_mem, zero body divergence, zero repo-ahead, zero UNCLASSIFIED), 1.3 whole-schema done with the remaining index sizing folded into Phase 5.
• Phase 2 complete — PR Replay the migration chain onto staging to parity, and record that the chain does not reproduce schema.sql (Phase 2, #056) #2093. Staging at full migration parity, and check:drift against staging red with 19 items. Recorded as the finding the phase existed to produce, not a failure of it; a re-measure is owed once staging carries 20260818090000.
• Phase 6 repo-side complete, migration deploy still owed. Phase 4 partial (2 restored, 20 missing, 2 unexpected undispositioned). Phase 5 partial. Phase 7 not started.

The block now defers to docs/database-remediation-coordination.md as the live board rather than becoming a second status source 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 the same file still assumes. A session reading top-to-bottom would otherwise reach a prompt asking for per-RPC canary approvals that are no longer needed.

The Phase 3 prompt and the traps list are deliberately untouched. The reframing and its owner decisions live on the coordination board; restating them here would recreate exactly the drift this PR repairs.

2. The tracking anchor's exact-title lookup could no longer match

The playbook instructs sessions to resolve the anchor by exact title, and quoted "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".

Worth naming the mechanism, because it is a small trap in itself: the "21" was preserved on purpose in #1979 precisely because it was the lookup key, and correcting the row title — right in itself — is what broke it. Updated to the current title and verified character-for-character against the row on main.

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
- failed: (none)
- not reached: (none)

• Anchor text diffed against git show origin/main:docs/outstanding-issues.md for #316 — exact match.
• npm run format run and committed.

Documentation-only scope, so the gate correctly stayed on the focused docs route.

Not run:verify:ui, provider-backed gates — nothing here touches UI or a provider.

RAG impact

Not required: documentation only. No file under src/lib/rag/**, no match_* RPC, no ranking, selection, eval-harness or fixture surface. The RPC findings are summarised, not changed.

Risk and rollout

• Risk: None to runtime. One markdown file, context-briefing prose only.
• Rollback:git revert the single commit.
• Provider or production effects: None.

Notes

• No issues:update queued, deliberately.#316 and #056 are owned by other running chats; a second pending mutation on either row would make the inbox refuse the whole batch — the failure mode fixed in fix(ledger,guard): survive parallel reconciles and rewritten history #1978 and documented in the traps list.
• A third item from the same review — the trap wrongly claiming 20260724120000_table_facts_plpgsql_execute.sql contains no create or replace function — needed no work here: PR docs(db): Phase 1.2 RPC divergence dossier — all ten match_* mismatches classified (#316) #2087 already corrected it at playbook lines 81–86, including why it matters (that recreate is what resets the work_mem20260724000000 sets). I had repeated the dossier's "the playbook itself was not edited" note without re-reading the playbook; re-fetching showed the fix was already in place.

---

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:38 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 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: 2ec8c39c-0184-4b83-a149-7a4c1765808a

📥 Commits

Reviewing files that changed from the base of the PR and between 2ee95a6 and c52b8c8.

📒 Files selected for processing (1)

• docs/database-remediation-playbook.md

---

_{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 ↗︎.