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

docs/branch-review-records/9c51e4a42ec2ecfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md

@@ -0,0 +1 @@
+| 2026-08-17 | PR (branch claude/p1-316-phase3-blocked-capture, #316 offline capture) | c2b3ba41fcca0364bd7241ca2a0bfa393c8bcd80 | one #316 inbox request (855d03b3). No code, no schema, no migration, no live call; Supabase MCP unauthenticated this session. | Offline capture only, no remediation performed. Corrects this row's NEXT: Phase 3 RPC reconciliation is NOT executable as written, because Phase 3's prerequisite is the Phase 1 dossier with 10 diffs classified and the forensics doc records all ten UNCLASSIFIED with per-function hunks still pending, while Phase 3's own prompt forbids touching an UNCLASSIFIED entry. Phase 3 therefore has zero executable entries and a production window would accomplish nothing; the real next step is a READ-ONLY window finishing Phase 1.2. Carries a testable hypothesis prepared offline: def_hash is md5 of pg_get_functiondef with comments and whitespace stripped and does NOT strip SET attributes, and migration 20260724000000 applies SET work_mem to exactly eight of the ten UNCLASSIFIED functions, so one read-only query could classify 8 of 10 at once; if live lacks the attribute those eight are repo-ahead but non-behavioural for answer content and would not need the eval-canary pair the repo-ahead rule assumes. Explicitly a hypothesis - live state was never read. The two _v2 outliers are absent from that migration and need their own diffs, with their canonical migrations named. Also records a discarded line of reasoning so it is not repeated: 'the manifest never mentions work_mem' proves nothing, because drift-manifest.json stores only signature, def_hash and acl and never body text. Protected RAG retrieval surface flagged; no edit made to it. | verify:pr-local docs route: 10 checks completed then check:ledger-write-discipline correctly refused on the then-uncommitted request; re-run after committing passed - 'Ledger write discipline passed for d0276718477c..HEAD'. check:outstanding-issues and check:branch-review-ledger passed. No provider-backed gate run and none applicable: no code, schema or migration changed. verify:ui not applicable and not runnable here (Playwright chromium-1194 vs pinned 1234, #255/#312). |

docs/outstanding-issues-inbox/855d03b3-61a8-4a81-ad31-80d996dd581a.json

@@ -0,0 +1,10 @@
+{
+  "version": 2,
+  "id": "855d03b3-61a8-4a81-ad31-80d996dd581a",
+  "createdOn": "2026-08-17",
+  "action": "update",
+  "payload": {
+    "id": "#316",
+    "detail": "Combined 2026-08-14 update, superseding the two partial requests cancelled in this same batch. PHASE 0 CLOSED including the forced-dispatch proof its definition of done required: live-drift dispatched on main (Actions run 31813064485) failed at the drift step, the always() capture step still ran, the migration-history step correctly skipped, and the separate drift-routing job then created issue #1963 \"Live drift check failing\" carrying the label, run URL, job result, trigger and the full findings block. Routing is now also covered offline by tests/live-drift-workflow.test.ts, mutation-verified. INCIDENT REPAIR, owner-approved in-session: the two retrieval-critical indexes documents_title_trgm_idx and document_chunks_content_trgm_idx were restored with CREATE INDEX CONCURRENTLY plus ANALYZE, both indisvalid and indisready at 648 kB and 68 MB, re-verified afterwards by an independent read-only query. Before and after supabase_rpc_latency_ms 31610 to 1535 on the text fast path and 8519 hybrid, with match_document_chunks_text_v2 at 14 ms. No repo schema change was needed because the definitions were already codified. CORRECTED FIGURES measured 2026-08-14, superseding the 2026-08-09 numbers this row was opened with: 10 match_* def_hash mismatches (unchanged), 20 missing_live indexes rather than 21, and the same 2 unexpected_live. ATTRIBUTION STILL OPEN: migration 20260705180000 recorded 14 executed statements so it was not mark-applied, and the 20260804110240 guard validates four other indexes and never checks this pair, so it gives no existence bound for 2026-08-04. The drop window is therefore 2026-07-05 to 2026-08-02 and the dashboard audit-history pairing remains owner action; #248 stays open. NEXT: Phase 3 RPC reconciliation before Phase 4, per the plan's ordering that the change which can alter clinical answers precedes the ones that only speed them up. Evidence: docs/audit/live-drift-forensics-2026-08.md. OFFLINE ANALYSIS 2026-08-17 (no live call made; Supabase MCP was unauthenticated in that session). THIS ROW'S 'NEXT: Phase 3' IS NOT EXECUTABLE AS WRITTEN - correcting it is the point of this update. Phase 3's prerequisite in docs/database-remediation-playbook.md is the Phase 1 dossier with '10 diffs classified', and docs/audit/live-drift-forensics-2026-08.md section 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 the owner. So Phase 3 currently has ZERO executable entries and a production window would accomplish nothing. THE ACTUAL NEXT STEP IS A READ-ONLY WINDOW to finish Phase 1.2, which is far cheaper and lower risk than the production window this row's wording implies. Do not request a production window first. TESTABLE 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. Migration 20260724000000_optimize_rpc_work_mem.sql applies ALTER FUNCTION ... SET work_mem = '64MB' to exactly EIGHT of the ten UNCLASSIFIED functions (match_document_chunks_hybrid, match_document_embedding_fields_hybrid, match_document_index_units_hybrid, match_document_memory_cards_hybrid, match_document_memory_cards_hybrid_v2, match_document_chunks_text, match_document_lookup_chunks_text, match_document_table_facts_text). So one read-only query - does live carry SET work_mem on those eight - plausibly classifies 8 of 10 in a single step, and if live lacks it they 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. This is a HYPOTHESIS, not a finding: live state was never read. The two remaining 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 bodies are in 20260717160000_optimize_owner_public_retrieval.sql, 20260713020000_owner_plus_public_retrieval.sql and 20260717162000_bound_versioned_retrieval_match_count.sql. DISCARDED REASONING, recorded so nobody repeats it: 'the drift manifest never mentions work_mem' is NOT evidence for or against the hypothesis, because supabase/drift-manifest.json stores only signature, def_hash and acl per function and never stores body text at all. Flag before editing: this whole surface is protected RAG retrieval, so any actual change needs the RAG-surface flag, the PR RAG impact line, and per-RPC approval as the playbook already specifies."
+  }
+}