From c2b3ba41fcca0364bd7241ca2a0bfa393c8bcd80 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 17 Aug 2026 08:07:37 +0000 Subject: [PATCH 1/2] =?UTF-8?q?docs(issues):=20correct=20#316's=20next=20s?= =?UTF-8?q?tep=20=E2=80=94=20Phase=203=20has=20no=20executable=20entries?= =?UTF-8?q?=20(#316)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `#316` reads `NEXT: Phase 3 RPC reconciliation`, and that is not executable as written. Phase 3's prerequisite in the playbook is the Phase 1 dossier with "10 diffs classified"; the forensics doc records all ten as UNCLASSIFIED with "per-function diff hunks still pending", and Phase 3's own pasted prompt says an UNCLASSIFIED entry stays untouched and is escalated. 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. Left as a queued inbox request so the next session is not aimed at a phase that cannot start; rows going stale this way is what `#328` records. Also carries a hypothesis prepared offline that should shorten that read-only window. `def_hash` is md5 of `pg_get_functiondef` with comments and whitespace stripped, and it does not strip `SET` attributes; migration 20260724000000_optimize_rpc_work_mem.sql applies `SET work_mem` to exactly eight of the ten UNCLASSIFIED functions. One read-only query could therefore classify 8 of 10 in a single step, and if live lacks the attribute those eight are repo-ahead but non-behavioural for answer content, so they would not need the eval-canary pair Phase 3's repo-ahead rule assumes. Recorded explicitly as a hypothesis: live state was never read. The two `_v2` outliers are absent from that migration and need their own diffs; their canonical bodies are named in the request. Also records one discarded line of reasoning so it is not repeated: "the drift manifest never mentions work_mem" proves nothing either way, because supabase/drift-manifest.json stores only signature, def_hash and acl per function and never stores body text. No live call was made and no retrieval surface was touched — the Supabase MCP server was unauthenticated in this session. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01PZL59KVSBWURMKvfc9mbJr --- .../855d03b3-61a8-4a81-ad31-80d996dd581a.json | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 docs/outstanding-issues-inbox/855d03b3-61a8-4a81-ad31-80d996dd581a.json diff --git a/docs/outstanding-issues-inbox/855d03b3-61a8-4a81-ad31-80d996dd581a.json b/docs/outstanding-issues-inbox/855d03b3-61a8-4a81-ad31-80d996dd581a.json new file mode 100644 index 0000000000..6454db200a --- /dev/null +++ b/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." + } +} From 192b70fdb7697da9372045e937bf5ba2f3e5e2f5 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 17 Aug 2026 08:08:53 +0000 Subject: [PATCH 2/2] docs(ledger): record the #316 offline capture handoff review Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01PZL59KVSBWURMKvfc9mbJr --- ...cfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 docs/branch-review-records/9c51e4a42ec2ecfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md diff --git a/docs/branch-review-records/9c51e4a42ec2ecfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md b/docs/branch-review-records/9c51e4a42ec2ecfa3a149a7471ccf09a55e29ae5f28ced52926f38c6d96f97b2.record.md new file mode 100644 index 0000000000..91f49a7d9f --- /dev/null +++ b/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). |