From 6f5e758dffe4f6826e92c3e5500910ce9f451bda Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 00:28:35 +0800 Subject: [PATCH 1/8] issues: queue #343 re-add and #318 reopen #343 was closed with a false outcome (#2107 loosened source_metadata, #2121 restored the strict pin; no DB check constraint was ever added). #318's clinical sign-off closure did not actually happen, per owner confirmation. --- .../39b3c784-e840-4308-91c2-a146f4ff5c45.json | 14 ++++++++++++++ .../b9a9492c-5cb5-4e13-8428-fbb3f70d979e.json | 14 ++++++++++++++ 2 files changed, 28 insertions(+) create mode 100644 docs/outstanding-issues-inbox/39b3c784-e840-4308-91c2-a146f4ff5c45.json create mode 100644 docs/outstanding-issues-inbox/b9a9492c-5cb5-4e13-8428-fbb3f70d979e.json diff --git a/docs/outstanding-issues-inbox/39b3c784-e840-4308-91c2-a146f4ff5c45.json b/docs/outstanding-issues-inbox/39b3c784-e840-4308-91c2-a146f4ff5c45.json new file mode 100644 index 0000000000..2dac48e170 --- /dev/null +++ b/docs/outstanding-issues-inbox/39b3c784-e840-4308-91c2-a146f4ff5c45.json @@ -0,0 +1,14 @@ +{ + "version": 2, + "id": "39b3c784-e840-4308-91c2-a146f4ff5c45", + "createdOn": "2026-08-20", + "action": "add", + "payload": { + "pri": "P1", + "type": "task", + "summary": "Reopen #318: the medication interaction lexicon clinical review and sign-off has not actually happened; the lexicon remains clinically unreviewed", + "detail": "#318 was closed 2026-08-18 with outcome 'Completed Clinical Lead medication interaction lexicon review and sign-off'. The repo owner confirmed in chat on 2026-08-21 that this review and sign-off was not performed by the Clinical Lead. The medication interaction lexicon therefore remains clinically unreviewed and its sign-off block is empty, exactly as the original #318 described before its (inaccurate) closure. This must be reopened and tracked through to a genuine Clinical Lead review and sign-off; do not close again without explicit owner confirmation that the review was actually carried out. Related: #SBKXZ7 flags the same missing-attribution gap (no reviewedBy/reviewedAt) for therapy sign-off.", + "source": "session 2026-08-21 ledger reconciliation and docs-truth pass; owner confirmed in chat the 2026-08-18 closure was inaccurate", + "issueUlid": "01M0FZW46J1YPV51XHYNP4W5QS" + } +} diff --git a/docs/outstanding-issues-inbox/b9a9492c-5cb5-4e13-8428-fbb3f70d979e.json b/docs/outstanding-issues-inbox/b9a9492c-5cb5-4e13-8428-fbb3f70d979e.json new file mode 100644 index 0000000000..a62a8d7e64 --- /dev/null +++ b/docs/outstanding-issues-inbox/b9a9492c-5cb5-4e13-8428-fbb3f70d979e.json @@ -0,0 +1,14 @@ +{ + "version": 2, + "id": "b9a9492c-5cb5-4e13-8428-fbb3f70d979e", + "createdOn": "2026-08-20", + "action": "add", + "payload": { + "pri": "P2", + "type": "task", + "summary": "Add the DB-side structural constraint backing the source_metadata pin, or document why the data-backed pin is sufficient", + "detail": "Re-files #343, closed 2026-08-18 with outcome 'Made retrieval row contract source_metadata schema structural and nullish' -- that outcome is false. Verified 2026-08-21: PR #2107 loosened the source_metadata pin in src/lib/rag/rag-row-contracts.ts to .nullish(); PR #2121 restored the strict .nullable()-required-key pin (git log: ce702ba68 then 4575cf57a). The comment at rag-row-contracts.ts:44-49 explicitly reads 'PR #2107 loosened it to .nullish() and this PR restores it. See docs/outstanding-issues.md #343 for the constraint-backing follow-up.' The DB-side structural constraint (check (jsonb_typeof(metadata) = 'object')) was never added: grep of supabase/schema.sql and supabase/migrations/ finds only 'metadata jsonb not null default {}::jsonb' with no jsonb_typeof check anywhere. The cancelled duplicate #ND10QT record itself states '#343, which is still open', confirming the two closures landed inconsistently. Actionable follow-up: add the check (jsonb_typeof(metadata) = 'object') constraint on documents.metadata with a fail-fast validation guard migration per AGENTS.md's guard-migration contract, or record in this row why the Zod-level pin in rag-row-contracts.ts is sufficient without a DB constraint.", + "source": "session 2026-08-21 ledger reconciliation and docs-truth pass", + "issueUlid": "01M0FZF4AJS19JRTFT15QVWGZ5" + } +} From 3c01bf32792050e09554fce454c704e81bffd42a Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 01:14:14 +0800 Subject: [PATCH 2/8] docs(issues): reconcile 4 queued ledger requests Applies #Q5JHBJ's Phase 6.2 completion update plus three new rows: OpenAI ZDR contradiction, docling-lab-fixtures.v2, and the live-drift PGRST106 blocker. The #343 re-add and #318 reopen requests queued earlier in this branch are left pending: check:ledger-write-discipline requires a reconciled request to already exist on origin/main, so those two ride a follow-up reconcile after this PR lands. --- .../{ => applied}/069da585-8008-4a56-868b-40d44a1aa51c.json | 0 .../{ => applied}/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json | 0 .../{ => applied}/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json | 0 .../{ => applied}/cc60253d-6efe-44ab-a615-8584ab0983b6.json | 0 docs/outstanding-issues.md | 5 ++++- 5 files changed, 4 insertions(+), 1 deletion(-) rename docs/outstanding-issues-inbox/{ => applied}/069da585-8008-4a56-868b-40d44a1aa51c.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/cc60253d-6efe-44ab-a615-8584ab0983b6.json (100%) diff --git a/docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json b/docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json similarity index 100% rename from docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json rename to docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json diff --git a/docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json b/docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json similarity index 100% rename from docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json rename to docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json diff --git a/docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json b/docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json similarity index 100% rename from docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json rename to docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json diff --git a/docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json b/docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json similarity index 100% rename from docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json rename to docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index a45f17d57f..a3d5d0e1f5 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -106,7 +106,7 @@ removed after current-main verification; it is not missing recommended work. | #NTAV3D | P2 | issue | Adversarial divergence (S5 harness pin): scope-guessed-chunk-id — review fallback returns a grounded source pointer echoing the query instead of refusing | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring). Observed shape: grounded true, cited [syn-scope-guess-a], and the guessed (never-retrieved) chunk id syn-not-retrieved-zzz is never resolved into content — the no-read invariant holds — but the review fallback returns a grounded source pointer that echoes the query text rather than refusing the guessed-id request. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case scope-guessed-chunk-id (category scope_or_tenant). Next: decide whether a query naming an unretrieved chunk id should refuse rather than fall back to a source pointer (RAG-surface change; own PR; harness pin flips; canary pair). Stop: do not delete the pin without the behaviour change. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #VXB8XA | P2 | issue | Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring: the harness asserts the normative B0 fixture contract still FAILS; when behaviour reaches the fixture expectation the pin goes red and must be deleted). Observed shape: cited chunk ids [syn-cite-attrib-a, syn-cite-attrib-b], grounded true, answerQualityTier source_only — the document-match listing attributes both retrieved documents although only one carries the claim. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case cite-mismatched-attribution (category citation_fabrication). Safety invariants (network, budget, canary absence, forbidden substrings, tenancy) hold; only citation attribution precision diverges. Next: decide whether the document-match listing should cite only claim-bearing documents (RAG-surface change; own PR; RAG impact line; offline harness proves the pin flips; canary pair). Stop: do not delete the pin without the behaviour change; do not weaken the fixture. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #S4K1GA | P3 | task | Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full) | PR #2046 fixed the reported defect (OS Reduce Motion froze every animation and set the ECG trace to opacity:0) and added a Motion preference whose "full" value opts back in over the OS setting. All executed browser evidence ran on Chromium 1194 in a Cloud container — the repo's own verify:ui gate could not run because check:playwright-browser-revision reports the known #255 drift (expects 1234). Playwright WebKit is not the iOS engine either. Acceptance: on the physical iPhone, in Safari and as the installed PWA, with Settings > Motion set to Full, confirm the ECG strip visibly travels and the current-step spinner rotates; with Motion left on System, confirm the trace stays visible and static rather than blank. Failure to confirm means the defect class is unclosed, which is exactly how #1974/#1989/#1995 were each declared fixed. Relates to #255, #280. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | -| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | RE-SCOPED 2026-08-18: the 20260818090000 schema_drift_snapshot v2 probe is ALREADY LIVE on production, auto-applied by the Supabase GitHub integration on merge of PR #2058 (verified in the Phase 3 production window, forensics section 3.7: probe ok, migration_history 20 rows = 15 unallowlisted + 5 seeded; live-drift 32131517648 reports 15 migration_history findings). The deploy step of this row is done and needs no window. REMAINING: triage the 15 reported no-statements versions (the 2026-07-01..07-02 cluster and the 2026-07-12 batch listed in forensics section 1.1) and author fail-fast validation guard migrations per 20260804110240 for each, never bare allowlisting; index-shaped ones can ride Phase 4's guard batches. See D4 in #316: while auto-deploy is on, every merged migration is a production deploy. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | +| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | PHASE 6.2 COMPLETE 2026-08-19 (owner-authorised production window). All fifteen no-statements versions classified and guarded with class validation (none earned superseded or no_ddl: no single later executed migration re-creates every object, and COMMENT ON is a catalog write, not an empty file). Six fail-fast guard migrations per 20260804110240: 20260819110000 dropped objects (absence of 7 functions + 4 indexes), 110100 catalog comments + purge-rag-retrieval-logs cron, 110200 three document FKs, 110300 forty-six operational index shapes, 110400 the index_generation_id promotion (6 columns + 6 indexes + 3 def_hashes), 110500 fifteen function def_hashes read from schema_drift_snapshot() itself. Allowlist now 20 entries (5 superseded + 15 validation). PROOF: full chain replay into the scratch image Applied 210/210 and CHAIN == MANIFEST (zero unexpected drift) -- every hand repair in sections 2.3/3.3/Phase 4 is reproduced by the chain, no reconcile migration needed; seven mutants raise and name their object; all six dry-ran green on production and a mutant fails there naming reset_document_index def_hash; production push real (migration list pending = exactly six, db push applied, rows stmt_count 4 no_statements false, 210 rows, documents 2851 untouched); staging by the Phase 2 method, six md5-matched rows, 210 rows, no_statements 0, drift comparison green. LIVE-DRIFT run 32251326536 on the branch: Compare step SUCCESS, all 20 history rows allowed, No unexpected schema drift -- #316's finding set is EMPTY for the first time since 2026-07-26. RESIDUAL, not this row's: the job still concludes failure because the Phase 0 step Align migration history (check:migration-history) ran for the first time ever and cannot read supabase_migrations over PostgREST (PGRST106, schema not exposed) -- queued as its own item. Evidence: forensics section '6.2 completion'. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | | #43SSS0 | P3 | rec | Three spring easing tokens in globals.css are dead: zero var() references and zero utility usage | --spring-tight, --spring-bouncy and --spring-gentle (src/app/globals.css:222-224) are declared in the @theme block but have no var() consumer in any stylesheet and no generated-utility consumer in src/. Tailwind v4.3.3 tree-shakes unused theme variables, so they never reach the compiled CSS — they are source noise, not shipped weight. Found while confirming (during PR #2046) that --animate-answer-ecg survives that same tree-shaking because it IS referenced via var() from the project's own CSS; --ease-spring is the working precedent for that pattern. Next: delete the three tokens, or wire them to the motion surfaces they were intended for. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #75JA0P | P2 | issue | Playwright runs the whole suite with reducedMotion:"reduce", so no gate reflects the default user configuration | playwright.config.ts:61 sets contextOptions: { reducedMotion: "reduce" } suite-wide, and every motion assertion has to opt out per-test via page.emulateMedia({ reducedMotion: "no-preference" }). That inversion is why three consecutive PRs (#1974, #1989, #1995) shipped green while a physical iPhone with OS Reduce Motion on showed a frozen, blank answer-progress panel: the suite never exercised the reported configuration. PR #2046 added tests/ui-phone-motion.spec.ts to cover that one surface, but the suite-wide default remains inverted for every other motion behaviour. Next: decide whether the suite default should be no-preference with reduce opted into per-test (the safer direction), or keep the current default and add a contract test that fails when a motion assertion has no explicit emulateMedia call. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #1PN5BM | P3 | issue | H5a residual: whether a constant similarity of 1 may contribute to a confidence label is still open, and after G1 it lives only in the hazard doc | Packet G1 (PR #2053, merged 2026-08-17) implemented owner decision Option B: buildDocumentSummaryResults now stamps similarity_origin "document_context" on document-summary rows, deriveConfidence is unchanged, and document summaries still reach "high". That closed the LEGIBILITY half of the H5a live residual -- the fabricated 1.0 is no longer indistinguishable from a perfect cosine at any surface that reads a row. It did NOT answer the underlying governance question: may a score nobody measured contribute to the confidence label a clinician reads at all? Option B was chosen because tagging has no measured safety cost while Option A (tag as synthetic_text, capping summaries at "medium") is a label downgrade without measured gain -- so the question was deferred deliberately, not resolved. The paired question row #J912J9 is being closed by G1, so once that closure reconciles this knowledge survives only in docs/clinical-hazard-analysis.md H5a and not in the queue anyone reads. NEXT: no action required unless a measured signal appears; if it does, the tag is what makes the fix cheap -- any future gate can now discriminate the document-summary route without re-deriving provenance. Guard rails already in place: tests/rag-score.test.ts pins the discriminating pair (two document_context citations >= 0.82 -> "high"; the identical scores tagged synthetic_text -> "medium"), so a silent change in either direction goes red. | Packet G1 session 2026-08-17 (PR #2053); docs/clinical-hazard-analysis.md H5a; closes-with #J912J9 | 2026-08-18 | @@ -151,6 +151,9 @@ removed after current-main verification; it is not missing recommended work. | #V0EDR4 | P3 | issue | /favourites and /?mode=favourites render visibly different homes for the same mode | The standalone hero lockup was deliberately deleted from favourites-command-library-page.tsx (ledger #164), but the dashboard variant FavouritesHub (src/components/clinical-dashboard/favourites-hub.tsx:179) still renders ModeHomeHero with 'Favourites / Saved notes, sources, and sets.' So the same mode looks different depending on the door. Decide which treatment is canonical and apply it to both. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #90Y0FD | P3 | rec | Mode home suggestion data is duplicated across three unrelated sources | searchCommandSurfaceByMode examples/suggestions (src/lib/search-command-surface.ts) drive the Try this ticket, rotating hint and prompt chips; per-page pills arrays (e.g. therapy-compass/screens/home-screen.tsx:14, services-home-page.tsx) drive the mode-home pill row; src/lib/tools-catalog.ts:348 is a third. Only the first drives the ticket, so after PR #2160 the Therapy home advertises two different suggestion sets — its five pills and the three ticket examples. Reconcile to one source per mode. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #JVYQEM | P2 | issue | Mode-home composer reserve does not account for the suggestion ticket, so every ticket-bearing home carries a ~0.035 CLS shift | ModeHomeTemplate reserves the composer slot with --spacing-mode-home-composer-phone (6.625rem) / --spacing-mode-home-composer-wide (5.5rem), but the portal content is UniversalSearchCommandSurface, which renders SmartRotatingHint (phone ticket) and the sm+ rotating line/prompt-chip row ABOVE the composer inside that same slot. The reserve therefore under-accounts, and the portal attaching post-hydration shifts content — the defect class chrome invariant 15 exists to prevent. Evidence from the PR #2160 Lighthouse run: mobile-dsm baseline CLS 0.0353, mobile-forms 0.088, mobile-root 0.016, while mobile-therapy-compass was 0.000 purely because Therapy had no command-surface entry and so rendered no ticket. Restoring the ticket moved Therapy to 0.032, matching its peers. Fix: raise the reserve tokens to include the hint row height (or reserve it separately), which should take every mode home toward ~0. Touches all 15 mode homes, so it needs verify:phone-chrome plus Lighthouse and visual baseline re-adoption — deliberately not bundled into PR #2160. | PR #2160 Lighthouse budget failure | 2026-08-18 | +| #HVTYAT | P2 | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected. | src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6 | 2026-08-19 | +| #VZN8G3 | P3 | task | docling-lab-fixtures.v2: add unruled, merged-cell and rotated-header table fixtures to the Docling lab before any table-quality promotion argument | Gate B (PR #2154, run 32176604314 at 8a92378) passed with the table-heavy leg at parity-on-ceiling: the v1 fixture set under eval/docling/ cannot separate docling from the legacy extractor on tables because every fixture is ruled/simple. Packet B4 (PR #2170, squash 5437c309f) shipped shadow mode as measurements only. Before anyone argues docling table quality (a precondition for any promotion beyond shadow, README §B4), author docling-lab-fixtures.v2: unruled tables, merged/spanning cells, rotated headers, plus expected exact number/unit/comparator checks, and re-run the lab (docling-lab.yml dispatch = hosted CI, owner approval). Synthetic/public sources only; hashed lockfile unchanged; aggregate-only report. Stop: no worker, extractor, or database change; shadow numbers remain measurements until v2 says otherwise. | RAG programme coordinator, post-B4 (2026-08-19) | 2026-08-19 | +| #M54C4N | P2 | issue | live-drift's Align migration history step fails on PGRST106 (supabase_migrations not exposed to PostgREST), so the job stays red and pinned issue #1963 cannot self-close even with zero drift | Exposed 2026-08-19 by Phase 6.2: live-drift run 32251326536 reported No unexpected schema drift (all 20 history rows allowed) but concluded failure because the next step, Align migration history for Supabase Preview (npm run check:migration-history, scripts/check-migration-history-alignment.ts, added in Phase 0 PR #1939), ran for the first time ever -- it was skipped on every earlier run because the compare step failed first, and the last green run (29700973962, 2026-07-19) predates it. It reads supabase_migrations.schema_migrations through PostgREST with Accept-Profile, which this project has never exposed (406 PGRST106: only public, graphql_public). The routing job therefore keeps #1963 open on job result even with an empty findings block. OPTIONS (owner decision): (a) expose supabase_migrations read-only to the service role in the dashboard; (b) rewrite the read onto the management API / supabase migration list using the SUPABASE_ACCESS_TOKEN secret (#183); (c) add a service-role RPC listing versions (new migration, own window). Until fixed, weekly live-drift stays red on that step alone; drift itself is green. Evidence: forensics section 6.2 completion step 6. | Phase 6.2 session 2026-08-19; live-drift run 32251326536 | 2026-08-19 | ## Resolved / archive From 4e9e31279d16de7fcf1465b31274c47fe4d9c15a Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 01:15:16 +0800 Subject: [PATCH 3/8] =?UTF-8?q?docs(rag-improvement):=20correct=20stale=20?= =?UTF-8?q?=C2=A77=20state=20in=20COORDINATION.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §7 still described a hypothetical "Wave 2: S2 once the post-#2088 canary is green" and "waiting on canary approvals for S1c, S1d, S2" — all three landed and their canaries went green on 2026-08-18/19. Rewrite to match HANDOVER.md's current status table: Track A complete through S3 (#2108), Gate B PASS (#2154), S7/B4 merged (#2170, shadow defaults to legacy), S8+ still owner-gated. State what the owner actually still owes: the Gate E blinded read, the B4 shadow-mode production enable decision, B5's Gate A sign-off, a B6 go/no-go, and the three pinned adversarial divergences (#C2D9JF, #NTAV3D, #VXB8XA). --- docs/rag-improvement/COORDINATION.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/rag-improvement/COORDINATION.md b/docs/rag-improvement/COORDINATION.md index 10339639f7..e7035ce8b9 100644 --- a/docs/rag-improvement/COORDINATION.md +++ b/docs/rag-improvement/COORDINATION.md @@ -188,8 +188,20 @@ Always a fresh owner ask, every single time: (condition-first `for/in` regex in `rag-claim-support.ts`), not S1d/G1. **Revert PR #2088** is open (probe restores 5 citations; offline 614/614). A confirmation canary follows its merge and becomes the new baseline. Reconcile D4 applied 17 requests (G1/S1c/governance rows closed). -- **Wave 2:** S2 (+S2b) once the post-#2088 confirmation canary is green. **Wave 3:** S3; S7+ owner decisions. -- **Waiting on owner:** merges as PRs open; canary approvals for S1c, S1d, S2. +- **Current state (2026-08-21):** Track A is complete through **S3** (`#2108`, squash + `511d22f4d`, A4 follow-up suggestions). **Gate B PASSED** (`#2154`, 2026-08-18, evidence run + `32176604314` at `8a92378`), and **S7/B4** (Docling worker shadow mode, `#2170`, squash + `5437c309f`) is merged with shadow mode defaulting to `legacy` — turning it on in production is + an operator step, not code. **S8+ remains owner-gated**: B5 (Ragas pilot) needs Gate A sign-off + before it can start, B6 (reranker benchmark) needs an owner go/no-go coordinated with `#001`, B7 + (DSPy) is blocked on a clinician-reviewed dataset that does not exist yet. +- **Owed by the owner now:** the Gate E blinded clinical-quality read on the S2 (v19 prompt) + answers — recorded "pending" in HANDOVER.md §1 (see README.md §4 for what Gate E covers); the + shadow-mode production enable decision for B4 (Railway variable; preconditions in + `docs/worker-deploy-runbook.md`); the Gate A sign-off B5 is waiting on; a B6 go/no-go; and + disposition of the three pinned adversarial divergences in the ledger — `#C2D9JF` + (scope-other-owner-document), `#NTAV3D` (scope-guessed-chunk-id), `#VXB8XA` + (cite-mismatched-attribution). - **Live board (artifact, owner-private):** RAG Master Plan v2 — `https://claude.ai/code/artifact/d5dba709-0df3-40e3-8a45-15997231533d`. From c2031b6a3a3cefd339e80b6e5612cd68fd8b965f Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 05:42:07 +0800 Subject: [PATCH 4/8] docs(ledger): record the PR #2206 review Immutable review record for claude/ledger-reconciliation-docs-truth-b0a2e9 at 4e9e31279d16de7fcf1465b31274c47fe4d9c15a. --- ...7669b10f94d0894c54e4295d92811796eae62580b3a173d4e3d.record.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 docs/branch-review-records/a5af2f79967d97669b10f94d0894c54e4295d92811796eae62580b3a173d4e3d.record.md diff --git a/docs/branch-review-records/a5af2f79967d97669b10f94d0894c54e4295d92811796eae62580b3a173d4e3d.record.md b/docs/branch-review-records/a5af2f79967d97669b10f94d0894c54e4295d92811796eae62580b3a173d4e3d.record.md new file mode 100644 index 0000000000..09b342d7f5 --- /dev/null +++ b/docs/branch-review-records/a5af2f79967d97669b10f94d0894c54e4295d92811796eae62580b3a173d4e3d.record.md @@ -0,0 +1 @@ +| 2026-08-20 | claude/ledger-reconciliation-docs-truth-b0a2e9 | 4e9e31279d16de7fcf1465b31274c47fe4d9c15a | docs/outstanding-issues.md, docs/outstanding-issues-inbox/**, docs/rag-improvement/COORDINATION.md | PR #2206 opened: reopens #343 (re-filed as #S19JRT) and #318 (reopened as #1YPV51), reconciles 4 pending ledger requests, corrects stale RAG coordination section 7 state. verify:pr-local, check:branch-review-ledger, check:ledger-write-discipline all green. | verify:pr-local,check:branch-review-ledger,check:ledger-write-discipline,format | From 3c4a42decbafef08d3699cd62857b8f5ac0f1408 Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 05:52:40 +0800 Subject: [PATCH 5/8] docs(issues): reconcile the runbook-unknowns follow-up (219680d3) A new P3 task landed on main after this PR's earlier reconcile: the B4 shadow-extraction Gate F runbook (docs/worker-deploy-runbook.md section 3) has four operator unknowns the repo can't answer -- Railway variable-change restart behaviour, no read path for documents.metadata.shadow_extraction, an unratified 10% timeout rollback threshold, and unverified worker memory headroom. This lands after the main-sync merge that brought it in; the #343/#318 requests queued earlier in this branch are still deliberately left pending for the same reason recorded in the earlier reconcile commit. --- .../{ => applied}/219680d3-050e-40d4-bd95-f511420ac3cb.json | 0 docs/outstanding-issues.md | 1 + 2 files changed, 1 insertion(+) rename docs/outstanding-issues-inbox/{ => applied}/219680d3-050e-40d4-bd95-f511420ac3cb.json (100%) diff --git a/docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json b/docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json similarity index 100% rename from docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json rename to docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index a3d5d0e1f5..463dbd021e 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -154,6 +154,7 @@ removed after current-main verification; it is not missing recommended work. | #HVTYAT | P2 | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected. | src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6 | 2026-08-19 | | #VZN8G3 | P3 | task | docling-lab-fixtures.v2: add unruled, merged-cell and rotated-header table fixtures to the Docling lab before any table-quality promotion argument | Gate B (PR #2154, run 32176604314 at 8a92378) passed with the table-heavy leg at parity-on-ceiling: the v1 fixture set under eval/docling/ cannot separate docling from the legacy extractor on tables because every fixture is ruled/simple. Packet B4 (PR #2170, squash 5437c309f) shipped shadow mode as measurements only. Before anyone argues docling table quality (a precondition for any promotion beyond shadow, README §B4), author docling-lab-fixtures.v2: unruled tables, merged/spanning cells, rotated headers, plus expected exact number/unit/comparator checks, and re-run the lab (docling-lab.yml dispatch = hosted CI, owner approval). Synthetic/public sources only; hashed lockfile unchanged; aggregate-only report. Stop: no worker, extractor, or database change; shadow numbers remain measurements until v2 says otherwise. | RAG programme coordinator, post-B4 (2026-08-19) | 2026-08-19 | | #M54C4N | P2 | issue | live-drift's Align migration history step fails on PGRST106 (supabase_migrations not exposed to PostgREST), so the job stays red and pinned issue #1963 cannot self-close even with zero drift | Exposed 2026-08-19 by Phase 6.2: live-drift run 32251326536 reported No unexpected schema drift (all 20 history rows allowed) but concluded failure because the next step, Align migration history for Supabase Preview (npm run check:migration-history, scripts/check-migration-history-alignment.ts, added in Phase 0 PR #1939), ran for the first time ever -- it was skipped on every earlier run because the compare step failed first, and the last green run (29700973962, 2026-07-19) predates it. It reads supabase_migrations.schema_migrations through PostgREST with Accept-Profile, which this project has never exposed (406 PGRST106: only public, graphql_public). The routing job therefore keeps #1963 open on job result even with an empty findings block. OPTIONS (owner decision): (a) expose supabase_migrations read-only to the service role in the dashboard; (b) rewrite the read onto the management API / supabase migration list using the SUPABASE_ACCESS_TOKEN secret (#183); (c) add a service-role RPC listing versions (new migration, own window). Until fixed, weekly live-drift stays red on that step alone; drift itself is green. Evidence: forensics section 6.2 completion step 6. | Phase 6.2 session 2026-08-19; live-drift run 32251326536 | 2026-08-19 | +| #1VFSYF | P3 | task | Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak | docs/worker-deploy-runbook.md section 3 (added 2026-08-20) is the Gate F runbook for packet B4 docling shadow extraction. Three values in it could not be verified from the repository and are flagged as such in the text. (1) ROLLBACK TIME TO EFFECT: the one-step rollback is WORKER_DOCUMENT_EXTRACTOR_MODE=legacy on the Railway worker service, but whether Railway restarts or fully rebuilds the service on a variable change is not recorded anywhere in this repo, so the runbook can only bound the worker-side cost (SIGTERM batch drain plus at most one 120 s docling window). One dashboard observation settles it; record the answer in section 3.7. (2) NO READ PATH: no npm script reads, exports, or clears documents.metadata.shadow_extraction, so the first-24-hours watch in section 3.6 is a hand-run SQL query in the Supabase editor. A small read-only aggregation script (outcome counts, wall_ms and peak_rss_bytes percentiles, delta ratios) would make the watch repeatable and reviewable instead of ad hoc. (3) TIMEOUT ROLLBACK THRESHOLD: section 3.7 trigger 5 proposes rolling back when more than 10 percent of cohort runs time out. That number is a proposed operating rule, not a measured value, and needs owner ratification or replacement once real-corpus wall_ms data exists. Also unverified: the memory headroom precondition in section 3.2 asks the operator to confirm the Railway worker memory limit and observed peak, neither of which is in-repo. Stop: no code, worker, or provider change is implied by this row; it is documentation completion plus one small offline read-only script. | docs/worker-deploy-runbook.md section 3 (Gate F runbook PR, 2026-08-21); PR #2170 squash 5437c309f | 2026-08-20 | ## Resolved / archive From b2700c663ccbe6f28e9cbaf40bb24a566a0265c3 Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 06:08:33 +0800 Subject: [PATCH 6/8] docs(issues): reset the stale reconciliation to re-run from the current base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The reconciliation on this branch was computed against an older base. `main` has since advanced (3ed193200) and its own edits to docs/outstanding-issues.md mean the branch's ledger is no longer byte-identical to a clean application of the queued requests from the current base, which is what check:ledger-write-discipline audits — it failed with "does not exactly match the audited application of 5 moved inbox request(s) from the base". This commit restores the canonical ledger and all five base inbox requests to their state at the current base so the reconciliation can be re-run as one clean transaction. No request content changes; the two requests this branch adds (39b3c784, b9a9492c) are untouched and stay pending for a later run. Co-Authored-By: Claude Opus 5 --- .../{applied => }/069da585-8008-4a56-868b-40d44a1aa51c.json | 0 .../{applied => }/219680d3-050e-40d4-bd95-f511420ac3cb.json | 0 .../{applied => }/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json | 0 .../{applied => }/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json | 0 .../{applied => }/cc60253d-6efe-44ab-a615-8584ab0983b6.json | 0 docs/outstanding-issues.md | 6 +----- 6 files changed, 1 insertion(+), 5 deletions(-) rename docs/outstanding-issues-inbox/{applied => }/069da585-8008-4a56-868b-40d44a1aa51c.json (100%) rename docs/outstanding-issues-inbox/{applied => }/219680d3-050e-40d4-bd95-f511420ac3cb.json (100%) rename docs/outstanding-issues-inbox/{applied => }/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json (100%) rename docs/outstanding-issues-inbox/{applied => }/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json (100%) rename docs/outstanding-issues-inbox/{applied => }/cc60253d-6efe-44ab-a615-8584ab0983b6.json (100%) diff --git a/docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json b/docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json similarity index 100% rename from docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json rename to docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json diff --git a/docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json b/docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json similarity index 100% rename from docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json rename to docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json diff --git a/docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json b/docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json similarity index 100% rename from docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json rename to docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json diff --git a/docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json b/docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json similarity index 100% rename from docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json rename to docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json diff --git a/docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json b/docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json similarity index 100% rename from docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json rename to docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index 463dbd021e..a45f17d57f 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -106,7 +106,7 @@ removed after current-main verification; it is not missing recommended work. | #NTAV3D | P2 | issue | Adversarial divergence (S5 harness pin): scope-guessed-chunk-id — review fallback returns a grounded source pointer echoing the query instead of refusing | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring). Observed shape: grounded true, cited [syn-scope-guess-a], and the guessed (never-retrieved) chunk id syn-not-retrieved-zzz is never resolved into content — the no-read invariant holds — but the review fallback returns a grounded source pointer that echoes the query text rather than refusing the guessed-id request. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case scope-guessed-chunk-id (category scope_or_tenant). Next: decide whether a query naming an unretrieved chunk id should refuse rather than fall back to a source pointer (RAG-surface change; own PR; harness pin flips; canary pair). Stop: do not delete the pin without the behaviour change. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #VXB8XA | P2 | issue | Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring: the harness asserts the normative B0 fixture contract still FAILS; when behaviour reaches the fixture expectation the pin goes red and must be deleted). Observed shape: cited chunk ids [syn-cite-attrib-a, syn-cite-attrib-b], grounded true, answerQualityTier source_only — the document-match listing attributes both retrieved documents although only one carries the claim. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case cite-mismatched-attribution (category citation_fabrication). Safety invariants (network, budget, canary absence, forbidden substrings, tenancy) hold; only citation attribution precision diverges. Next: decide whether the document-match listing should cite only claim-bearing documents (RAG-surface change; own PR; RAG impact line; offline harness proves the pin flips; canary pair). Stop: do not delete the pin without the behaviour change; do not weaken the fixture. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #S4K1GA | P3 | task | Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full) | PR #2046 fixed the reported defect (OS Reduce Motion froze every animation and set the ECG trace to opacity:0) and added a Motion preference whose "full" value opts back in over the OS setting. All executed browser evidence ran on Chromium 1194 in a Cloud container — the repo's own verify:ui gate could not run because check:playwright-browser-revision reports the known #255 drift (expects 1234). Playwright WebKit is not the iOS engine either. Acceptance: on the physical iPhone, in Safari and as the installed PWA, with Settings > Motion set to Full, confirm the ECG strip visibly travels and the current-step spinner rotates; with Motion left on System, confirm the trace stays visible and static rather than blank. Failure to confirm means the defect class is unclosed, which is exactly how #1974/#1989/#1995 were each declared fixed. Relates to #255, #280. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | -| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | PHASE 6.2 COMPLETE 2026-08-19 (owner-authorised production window). All fifteen no-statements versions classified and guarded with class validation (none earned superseded or no_ddl: no single later executed migration re-creates every object, and COMMENT ON is a catalog write, not an empty file). Six fail-fast guard migrations per 20260804110240: 20260819110000 dropped objects (absence of 7 functions + 4 indexes), 110100 catalog comments + purge-rag-retrieval-logs cron, 110200 three document FKs, 110300 forty-six operational index shapes, 110400 the index_generation_id promotion (6 columns + 6 indexes + 3 def_hashes), 110500 fifteen function def_hashes read from schema_drift_snapshot() itself. Allowlist now 20 entries (5 superseded + 15 validation). PROOF: full chain replay into the scratch image Applied 210/210 and CHAIN == MANIFEST (zero unexpected drift) -- every hand repair in sections 2.3/3.3/Phase 4 is reproduced by the chain, no reconcile migration needed; seven mutants raise and name their object; all six dry-ran green on production and a mutant fails there naming reset_document_index def_hash; production push real (migration list pending = exactly six, db push applied, rows stmt_count 4 no_statements false, 210 rows, documents 2851 untouched); staging by the Phase 2 method, six md5-matched rows, 210 rows, no_statements 0, drift comparison green. LIVE-DRIFT run 32251326536 on the branch: Compare step SUCCESS, all 20 history rows allowed, No unexpected schema drift -- #316's finding set is EMPTY for the first time since 2026-07-26. RESIDUAL, not this row's: the job still concludes failure because the Phase 0 step Align migration history (check:migration-history) ran for the first time ever and cannot read supabase_migrations over PostgREST (PGRST106, schema not exposed) -- queued as its own item. Evidence: forensics section '6.2 completion'. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | +| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | RE-SCOPED 2026-08-18: the 20260818090000 schema_drift_snapshot v2 probe is ALREADY LIVE on production, auto-applied by the Supabase GitHub integration on merge of PR #2058 (verified in the Phase 3 production window, forensics section 3.7: probe ok, migration_history 20 rows = 15 unallowlisted + 5 seeded; live-drift 32131517648 reports 15 migration_history findings). The deploy step of this row is done and needs no window. REMAINING: triage the 15 reported no-statements versions (the 2026-07-01..07-02 cluster and the 2026-07-12 batch listed in forensics section 1.1) and author fail-fast validation guard migrations per 20260804110240 for each, never bare allowlisting; index-shaped ones can ride Phase 4's guard batches. See D4 in #316: while auto-deploy is on, every merged migration is a production deploy. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | | #43SSS0 | P3 | rec | Three spring easing tokens in globals.css are dead: zero var() references and zero utility usage | --spring-tight, --spring-bouncy and --spring-gentle (src/app/globals.css:222-224) are declared in the @theme block but have no var() consumer in any stylesheet and no generated-utility consumer in src/. Tailwind v4.3.3 tree-shakes unused theme variables, so they never reach the compiled CSS — they are source noise, not shipped weight. Found while confirming (during PR #2046) that --animate-answer-ecg survives that same tree-shaking because it IS referenced via var() from the project's own CSS; --ease-spring is the working precedent for that pattern. Next: delete the three tokens, or wire them to the motion surfaces they were intended for. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #75JA0P | P2 | issue | Playwright runs the whole suite with reducedMotion:"reduce", so no gate reflects the default user configuration | playwright.config.ts:61 sets contextOptions: { reducedMotion: "reduce" } suite-wide, and every motion assertion has to opt out per-test via page.emulateMedia({ reducedMotion: "no-preference" }). That inversion is why three consecutive PRs (#1974, #1989, #1995) shipped green while a physical iPhone with OS Reduce Motion on showed a frozen, blank answer-progress panel: the suite never exercised the reported configuration. PR #2046 added tests/ui-phone-motion.spec.ts to cover that one surface, but the suite-wide default remains inverted for every other motion behaviour. Next: decide whether the suite default should be no-preference with reduce opted into per-test (the safer direction), or keep the current default and add a contract test that fails when a motion assertion has no explicit emulateMedia call. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #1PN5BM | P3 | issue | H5a residual: whether a constant similarity of 1 may contribute to a confidence label is still open, and after G1 it lives only in the hazard doc | Packet G1 (PR #2053, merged 2026-08-17) implemented owner decision Option B: buildDocumentSummaryResults now stamps similarity_origin "document_context" on document-summary rows, deriveConfidence is unchanged, and document summaries still reach "high". That closed the LEGIBILITY half of the H5a live residual -- the fabricated 1.0 is no longer indistinguishable from a perfect cosine at any surface that reads a row. It did NOT answer the underlying governance question: may a score nobody measured contribute to the confidence label a clinician reads at all? Option B was chosen because tagging has no measured safety cost while Option A (tag as synthetic_text, capping summaries at "medium") is a label downgrade without measured gain -- so the question was deferred deliberately, not resolved. The paired question row #J912J9 is being closed by G1, so once that closure reconciles this knowledge survives only in docs/clinical-hazard-analysis.md H5a and not in the queue anyone reads. NEXT: no action required unless a measured signal appears; if it does, the tag is what makes the fix cheap -- any future gate can now discriminate the document-summary route without re-deriving provenance. Guard rails already in place: tests/rag-score.test.ts pins the discriminating pair (two document_context citations >= 0.82 -> "high"; the identical scores tagged synthetic_text -> "medium"), so a silent change in either direction goes red. | Packet G1 session 2026-08-17 (PR #2053); docs/clinical-hazard-analysis.md H5a; closes-with #J912J9 | 2026-08-18 | @@ -151,10 +151,6 @@ removed after current-main verification; it is not missing recommended work. | #V0EDR4 | P3 | issue | /favourites and /?mode=favourites render visibly different homes for the same mode | The standalone hero lockup was deliberately deleted from favourites-command-library-page.tsx (ledger #164), but the dashboard variant FavouritesHub (src/components/clinical-dashboard/favourites-hub.tsx:179) still renders ModeHomeHero with 'Favourites / Saved notes, sources, and sets.' So the same mode looks different depending on the door. Decide which treatment is canonical and apply it to both. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #90Y0FD | P3 | rec | Mode home suggestion data is duplicated across three unrelated sources | searchCommandSurfaceByMode examples/suggestions (src/lib/search-command-surface.ts) drive the Try this ticket, rotating hint and prompt chips; per-page pills arrays (e.g. therapy-compass/screens/home-screen.tsx:14, services-home-page.tsx) drive the mode-home pill row; src/lib/tools-catalog.ts:348 is a third. Only the first drives the ticket, so after PR #2160 the Therapy home advertises two different suggestion sets — its five pills and the three ticket examples. Reconcile to one source per mode. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #JVYQEM | P2 | issue | Mode-home composer reserve does not account for the suggestion ticket, so every ticket-bearing home carries a ~0.035 CLS shift | ModeHomeTemplate reserves the composer slot with --spacing-mode-home-composer-phone (6.625rem) / --spacing-mode-home-composer-wide (5.5rem), but the portal content is UniversalSearchCommandSurface, which renders SmartRotatingHint (phone ticket) and the sm+ rotating line/prompt-chip row ABOVE the composer inside that same slot. The reserve therefore under-accounts, and the portal attaching post-hydration shifts content — the defect class chrome invariant 15 exists to prevent. Evidence from the PR #2160 Lighthouse run: mobile-dsm baseline CLS 0.0353, mobile-forms 0.088, mobile-root 0.016, while mobile-therapy-compass was 0.000 purely because Therapy had no command-surface entry and so rendered no ticket. Restoring the ticket moved Therapy to 0.032, matching its peers. Fix: raise the reserve tokens to include the hint row height (or reserve it separately), which should take every mode home toward ~0. Touches all 15 mode homes, so it needs verify:phone-chrome plus Lighthouse and visual baseline re-adoption — deliberately not bundled into PR #2160. | PR #2160 Lighthouse budget failure | 2026-08-18 | -| #HVTYAT | P2 | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected. | src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6 | 2026-08-19 | -| #VZN8G3 | P3 | task | docling-lab-fixtures.v2: add unruled, merged-cell and rotated-header table fixtures to the Docling lab before any table-quality promotion argument | Gate B (PR #2154, run 32176604314 at 8a92378) passed with the table-heavy leg at parity-on-ceiling: the v1 fixture set under eval/docling/ cannot separate docling from the legacy extractor on tables because every fixture is ruled/simple. Packet B4 (PR #2170, squash 5437c309f) shipped shadow mode as measurements only. Before anyone argues docling table quality (a precondition for any promotion beyond shadow, README §B4), author docling-lab-fixtures.v2: unruled tables, merged/spanning cells, rotated headers, plus expected exact number/unit/comparator checks, and re-run the lab (docling-lab.yml dispatch = hosted CI, owner approval). Synthetic/public sources only; hashed lockfile unchanged; aggregate-only report. Stop: no worker, extractor, or database change; shadow numbers remain measurements until v2 says otherwise. | RAG programme coordinator, post-B4 (2026-08-19) | 2026-08-19 | -| #M54C4N | P2 | issue | live-drift's Align migration history step fails on PGRST106 (supabase_migrations not exposed to PostgREST), so the job stays red and pinned issue #1963 cannot self-close even with zero drift | Exposed 2026-08-19 by Phase 6.2: live-drift run 32251326536 reported No unexpected schema drift (all 20 history rows allowed) but concluded failure because the next step, Align migration history for Supabase Preview (npm run check:migration-history, scripts/check-migration-history-alignment.ts, added in Phase 0 PR #1939), ran for the first time ever -- it was skipped on every earlier run because the compare step failed first, and the last green run (29700973962, 2026-07-19) predates it. It reads supabase_migrations.schema_migrations through PostgREST with Accept-Profile, which this project has never exposed (406 PGRST106: only public, graphql_public). The routing job therefore keeps #1963 open on job result even with an empty findings block. OPTIONS (owner decision): (a) expose supabase_migrations read-only to the service role in the dashboard; (b) rewrite the read onto the management API / supabase migration list using the SUPABASE_ACCESS_TOKEN secret (#183); (c) add a service-role RPC listing versions (new migration, own window). Until fixed, weekly live-drift stays red on that step alone; drift itself is green. Evidence: forensics section 6.2 completion step 6. | Phase 6.2 session 2026-08-19; live-drift run 32251326536 | 2026-08-19 | -| #1VFSYF | P3 | task | Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak | docs/worker-deploy-runbook.md section 3 (added 2026-08-20) is the Gate F runbook for packet B4 docling shadow extraction. Three values in it could not be verified from the repository and are flagged as such in the text. (1) ROLLBACK TIME TO EFFECT: the one-step rollback is WORKER_DOCUMENT_EXTRACTOR_MODE=legacy on the Railway worker service, but whether Railway restarts or fully rebuilds the service on a variable change is not recorded anywhere in this repo, so the runbook can only bound the worker-side cost (SIGTERM batch drain plus at most one 120 s docling window). One dashboard observation settles it; record the answer in section 3.7. (2) NO READ PATH: no npm script reads, exports, or clears documents.metadata.shadow_extraction, so the first-24-hours watch in section 3.6 is a hand-run SQL query in the Supabase editor. A small read-only aggregation script (outcome counts, wall_ms and peak_rss_bytes percentiles, delta ratios) would make the watch repeatable and reviewable instead of ad hoc. (3) TIMEOUT ROLLBACK THRESHOLD: section 3.7 trigger 5 proposes rolling back when more than 10 percent of cohort runs time out. That number is a proposed operating rule, not a measured value, and needs owner ratification or replacement once real-corpus wall_ms data exists. Also unverified: the memory headroom precondition in section 3.2 asks the operator to confirm the Railway worker memory limit and observed peak, neither of which is in-repo. Stop: no code, worker, or provider change is implied by this row; it is documentation completion plus one small offline read-only script. | docs/worker-deploy-runbook.md section 3 (Gate F runbook PR, 2026-08-21); PR #2170 squash 5437c309f | 2026-08-20 | ## Resolved / archive From 03836d99cadcf24b922c3b42b9a9ea4eb9e50d81 Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 06:15:35 +0800 Subject: [PATCH 7/8] docs(issues): reconcile the five queued requests cleanly from the current base Re-runs the reconciliation as a single transaction from base e92a1b14, so docs/outstanding-issues.md is byte-identical to the audited application of the five moved inbox requests. That is what check:ledger-write-discipline verifies, and it is what the previous stale-base run could not satisfy once main advanced. Applied: 069da585, 219680d3, a20fc4ce, bbac85a9, cc60253d. The 219680d3 request is the docling shadow-extraction runbook follow-up queued by PR #2200, which was the request the earlier partial batch left behind and the reason CI was red. The two requests this branch raises (39b3c784, b9a9492c) stay pending by design: they are not part of the base inbox, so a later reconciliation owns them. Co-Authored-By: Claude Opus 5 --- .../{ => applied}/069da585-8008-4a56-868b-40d44a1aa51c.json | 0 .../{ => applied}/219680d3-050e-40d4-bd95-f511420ac3cb.json | 0 .../{ => applied}/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json | 0 .../{ => applied}/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json | 0 .../{ => applied}/cc60253d-6efe-44ab-a615-8584ab0983b6.json | 0 docs/outstanding-issues.md | 6 +++++- 6 files changed, 5 insertions(+), 1 deletion(-) rename docs/outstanding-issues-inbox/{ => applied}/069da585-8008-4a56-868b-40d44a1aa51c.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/219680d3-050e-40d4-bd95-f511420ac3cb.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/cc60253d-6efe-44ab-a615-8584ab0983b6.json (100%) diff --git a/docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json b/docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json similarity index 100% rename from docs/outstanding-issues-inbox/069da585-8008-4a56-868b-40d44a1aa51c.json rename to docs/outstanding-issues-inbox/applied/069da585-8008-4a56-868b-40d44a1aa51c.json diff --git a/docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json b/docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json similarity index 100% rename from docs/outstanding-issues-inbox/219680d3-050e-40d4-bd95-f511420ac3cb.json rename to docs/outstanding-issues-inbox/applied/219680d3-050e-40d4-bd95-f511420ac3cb.json diff --git a/docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json b/docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json similarity index 100% rename from docs/outstanding-issues-inbox/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json rename to docs/outstanding-issues-inbox/applied/a20fc4ce-0608-4939-97c1-f2fb7f8a1285.json diff --git a/docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json b/docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json similarity index 100% rename from docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json rename to docs/outstanding-issues-inbox/applied/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json diff --git a/docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json b/docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json similarity index 100% rename from docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json rename to docs/outstanding-issues-inbox/applied/cc60253d-6efe-44ab-a615-8584ab0983b6.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index a45f17d57f..865914dc9c 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -106,7 +106,7 @@ removed after current-main verification; it is not missing recommended work. | #NTAV3D | P2 | issue | Adversarial divergence (S5 harness pin): scope-guessed-chunk-id — review fallback returns a grounded source pointer echoing the query instead of refusing | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring). Observed shape: grounded true, cited [syn-scope-guess-a], and the guessed (never-retrieved) chunk id syn-not-retrieved-zzz is never resolved into content — the no-read invariant holds — but the review fallback returns a grounded source pointer that echoes the query text rather than refusing the guessed-id request. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case scope-guessed-chunk-id (category scope_or_tenant). Next: decide whether a query naming an unretrieved chunk id should refuse rather than fall back to a source pointer (RAG-surface change; own PR; harness pin flips; canary pair). Stop: do not delete the pin without the behaviour change. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #VXB8XA | P2 | issue | Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring: the harness asserts the normative B0 fixture contract still FAILS; when behaviour reaches the fixture expectation the pin goes red and must be deleted). Observed shape: cited chunk ids [syn-cite-attrib-a, syn-cite-attrib-b], grounded true, answerQualityTier source_only — the document-match listing attributes both retrieved documents although only one carries the claim. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case cite-mismatched-attribution (category citation_fabrication). Safety invariants (network, budget, canary absence, forbidden substrings, tenancy) hold; only citation attribution precision diverges. Next: decide whether the document-match listing should cite only claim-bearing documents (RAG-surface change; own PR; RAG impact line; offline harness proves the pin flips; canary pair). Stop: do not delete the pin without the behaviour change; do not weaken the fixture. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #S4K1GA | P3 | task | Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full) | PR #2046 fixed the reported defect (OS Reduce Motion froze every animation and set the ECG trace to opacity:0) and added a Motion preference whose "full" value opts back in over the OS setting. All executed browser evidence ran on Chromium 1194 in a Cloud container — the repo's own verify:ui gate could not run because check:playwright-browser-revision reports the known #255 drift (expects 1234). Playwright WebKit is not the iOS engine either. Acceptance: on the physical iPhone, in Safari and as the installed PWA, with Settings > Motion set to Full, confirm the ECG strip visibly travels and the current-step spinner rotates; with Motion left on System, confirm the trace stays visible and static rather than blank. Failure to confirm means the defect class is unclosed, which is exactly how #1974/#1989/#1995 were each declared fixed. Relates to #255, #280. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | -| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | RE-SCOPED 2026-08-18: the 20260818090000 schema_drift_snapshot v2 probe is ALREADY LIVE on production, auto-applied by the Supabase GitHub integration on merge of PR #2058 (verified in the Phase 3 production window, forensics section 3.7: probe ok, migration_history 20 rows = 15 unallowlisted + 5 seeded; live-drift 32131517648 reports 15 migration_history findings). The deploy step of this row is done and needs no window. REMAINING: triage the 15 reported no-statements versions (the 2026-07-01..07-02 cluster and the 2026-07-12 batch listed in forensics section 1.1) and author fail-fast validation guard migrations per 20260804110240 for each, never bare allowlisting; index-shaped ones can ride Phase 4's guard batches. See D4 in #316: while auto-deploy is on, every merged migration is a production deploy. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | +| #Q5JHBJ | P2 | task | Deploy the 20260818090000 schema_drift_snapshot v2 history probe (Phase 6.1) in an approved production window after Phase 4, triage the first unguarded no-statements report, and author fail-fast guard migrations for the pre-contract 2026-07-01..02 and 2026-07-12 rows | PHASE 6.2 COMPLETE 2026-08-19 (owner-authorised production window). All fifteen no-statements versions classified and guarded with class validation (none earned superseded or no_ddl: no single later executed migration re-creates every object, and COMMENT ON is a catalog write, not an empty file). Six fail-fast guard migrations per 20260804110240: 20260819110000 dropped objects (absence of 7 functions + 4 indexes), 110100 catalog comments + purge-rag-retrieval-logs cron, 110200 three document FKs, 110300 forty-six operational index shapes, 110400 the index_generation_id promotion (6 columns + 6 indexes + 3 def_hashes), 110500 fifteen function def_hashes read from schema_drift_snapshot() itself. Allowlist now 20 entries (5 superseded + 15 validation). PROOF: full chain replay into the scratch image Applied 210/210 and CHAIN == MANIFEST (zero unexpected drift) -- every hand repair in sections 2.3/3.3/Phase 4 is reproduced by the chain, no reconcile migration needed; seven mutants raise and name their object; all six dry-ran green on production and a mutant fails there naming reset_document_index def_hash; production push real (migration list pending = exactly six, db push applied, rows stmt_count 4 no_statements false, 210 rows, documents 2851 untouched); staging by the Phase 2 method, six md5-matched rows, 210 rows, no_statements 0, drift comparison green. LIVE-DRIFT run 32251326536 on the branch: Compare step SUCCESS, all 20 history rows allowed, No unexpected schema drift -- #316's finding set is EMPTY for the first time since 2026-07-26. RESIDUAL, not this row's: the job still concludes failure because the Phase 0 step Align migration history (check:migration-history) ran for the first time ever and cannot read supabase_migrations over PostgREST (PGRST106, schema not exposed) -- queued as its own item. Evidence: forensics section '6.2 completion'. | PR #2123 forensics section 3.7; coordination chat 2026-08-19 | 2026-08-17 | | #43SSS0 | P3 | rec | Three spring easing tokens in globals.css are dead: zero var() references and zero utility usage | --spring-tight, --spring-bouncy and --spring-gentle (src/app/globals.css:222-224) are declared in the @theme block but have no var() consumer in any stylesheet and no generated-utility consumer in src/. Tailwind v4.3.3 tree-shakes unused theme variables, so they never reach the compiled CSS — they are source noise, not shipped weight. Found while confirming (during PR #2046) that --animate-answer-ecg survives that same tree-shaking because it IS referenced via var() from the project's own CSS; --ease-spring is the working precedent for that pattern. Next: delete the three tokens, or wire them to the motion surfaces they were intended for. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #75JA0P | P2 | issue | Playwright runs the whole suite with reducedMotion:"reduce", so no gate reflects the default user configuration | playwright.config.ts:61 sets contextOptions: { reducedMotion: "reduce" } suite-wide, and every motion assertion has to opt out per-test via page.emulateMedia({ reducedMotion: "no-preference" }). That inversion is why three consecutive PRs (#1974, #1989, #1995) shipped green while a physical iPhone with OS Reduce Motion on showed a frozen, blank answer-progress panel: the suite never exercised the reported configuration. PR #2046 added tests/ui-phone-motion.spec.ts to cover that one surface, but the suite-wide default remains inverted for every other motion behaviour. Next: decide whether the suite default should be no-preference with reduce opted into per-test (the safer direction), or keep the current default and add a contract test that fails when a motion assertion has no explicit emulateMedia call. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #1PN5BM | P3 | issue | H5a residual: whether a constant similarity of 1 may contribute to a confidence label is still open, and after G1 it lives only in the hazard doc | Packet G1 (PR #2053, merged 2026-08-17) implemented owner decision Option B: buildDocumentSummaryResults now stamps similarity_origin "document_context" on document-summary rows, deriveConfidence is unchanged, and document summaries still reach "high". That closed the LEGIBILITY half of the H5a live residual -- the fabricated 1.0 is no longer indistinguishable from a perfect cosine at any surface that reads a row. It did NOT answer the underlying governance question: may a score nobody measured contribute to the confidence label a clinician reads at all? Option B was chosen because tagging has no measured safety cost while Option A (tag as synthetic_text, capping summaries at "medium") is a label downgrade without measured gain -- so the question was deferred deliberately, not resolved. The paired question row #J912J9 is being closed by G1, so once that closure reconciles this knowledge survives only in docs/clinical-hazard-analysis.md H5a and not in the queue anyone reads. NEXT: no action required unless a measured signal appears; if it does, the tag is what makes the fix cheap -- any future gate can now discriminate the document-summary route without re-deriving provenance. Guard rails already in place: tests/rag-score.test.ts pins the discriminating pair (two document_context citations >= 0.82 -> "high"; the identical scores tagged synthetic_text -> "medium"), so a silent change in either direction goes red. | Packet G1 session 2026-08-17 (PR #2053); docs/clinical-hazard-analysis.md H5a; closes-with #J912J9 | 2026-08-18 | @@ -151,6 +151,10 @@ removed after current-main verification; it is not missing recommended work. | #V0EDR4 | P3 | issue | /favourites and /?mode=favourites render visibly different homes for the same mode | The standalone hero lockup was deliberately deleted from favourites-command-library-page.tsx (ledger #164), but the dashboard variant FavouritesHub (src/components/clinical-dashboard/favourites-hub.tsx:179) still renders ModeHomeHero with 'Favourites / Saved notes, sources, and sets.' So the same mode looks different depending on the door. Decide which treatment is canonical and apply it to both. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #90Y0FD | P3 | rec | Mode home suggestion data is duplicated across three unrelated sources | searchCommandSurfaceByMode examples/suggestions (src/lib/search-command-surface.ts) drive the Try this ticket, rotating hint and prompt chips; per-page pills arrays (e.g. therapy-compass/screens/home-screen.tsx:14, services-home-page.tsx) drive the mode-home pill row; src/lib/tools-catalog.ts:348 is a third. Only the first drives the ticket, so after PR #2160 the Therapy home advertises two different suggestion sets — its five pills and the three ticket examples. Reconcile to one source per mode. Found during the PR #2160 cross-mode audit. | PR #2160 cross-mode home audit | 2026-08-18 | | #JVYQEM | P2 | issue | Mode-home composer reserve does not account for the suggestion ticket, so every ticket-bearing home carries a ~0.035 CLS shift | ModeHomeTemplate reserves the composer slot with --spacing-mode-home-composer-phone (6.625rem) / --spacing-mode-home-composer-wide (5.5rem), but the portal content is UniversalSearchCommandSurface, which renders SmartRotatingHint (phone ticket) and the sm+ rotating line/prompt-chip row ABOVE the composer inside that same slot. The reserve therefore under-accounts, and the portal attaching post-hydration shifts content — the defect class chrome invariant 15 exists to prevent. Evidence from the PR #2160 Lighthouse run: mobile-dsm baseline CLS 0.0353, mobile-forms 0.088, mobile-root 0.016, while mobile-therapy-compass was 0.000 purely because Therapy had no command-surface entry and so rendered no ticket. Restoring the ticket moved Therapy to 0.032, matching its peers. Fix: raise the reserve tokens to include the hint row height (or reserve it separately), which should take every mode home toward ~0. Touches all 15 mode homes, so it needs verify:phone-chrome plus Lighthouse and visual baseline re-adoption — deliberately not bundled into PR #2160. | PR #2160 Lighthouse budget failure | 2026-08-18 | +| #HVTYAT | P2 | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected. | src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6 | 2026-08-19 | +| #1VFSYF | P3 | task | Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak | docs/worker-deploy-runbook.md section 3 (added 2026-08-20) is the Gate F runbook for packet B4 docling shadow extraction. Three values in it could not be verified from the repository and are flagged as such in the text. (1) ROLLBACK TIME TO EFFECT: the one-step rollback is WORKER_DOCUMENT_EXTRACTOR_MODE=legacy on the Railway worker service, but whether Railway restarts or fully rebuilds the service on a variable change is not recorded anywhere in this repo, so the runbook can only bound the worker-side cost (SIGTERM batch drain plus at most one 120 s docling window). One dashboard observation settles it; record the answer in section 3.7. (2) NO READ PATH: no npm script reads, exports, or clears documents.metadata.shadow_extraction, so the first-24-hours watch in section 3.6 is a hand-run SQL query in the Supabase editor. A small read-only aggregation script (outcome counts, wall_ms and peak_rss_bytes percentiles, delta ratios) would make the watch repeatable and reviewable instead of ad hoc. (3) TIMEOUT ROLLBACK THRESHOLD: section 3.7 trigger 5 proposes rolling back when more than 10 percent of cohort runs time out. That number is a proposed operating rule, not a measured value, and needs owner ratification or replacement once real-corpus wall_ms data exists. Also unverified: the memory headroom precondition in section 3.2 asks the operator to confirm the Railway worker memory limit and observed peak, neither of which is in-repo. Stop: no code, worker, or provider change is implied by this row; it is documentation completion plus one small offline read-only script. | docs/worker-deploy-runbook.md section 3 (Gate F runbook PR, 2026-08-21); PR #2170 squash 5437c309f | 2026-08-20 | +| #VZN8G3 | P3 | task | docling-lab-fixtures.v2: add unruled, merged-cell and rotated-header table fixtures to the Docling lab before any table-quality promotion argument | Gate B (PR #2154, run 32176604314 at 8a92378) passed with the table-heavy leg at parity-on-ceiling: the v1 fixture set under eval/docling/ cannot separate docling from the legacy extractor on tables because every fixture is ruled/simple. Packet B4 (PR #2170, squash 5437c309f) shipped shadow mode as measurements only. Before anyone argues docling table quality (a precondition for any promotion beyond shadow, README §B4), author docling-lab-fixtures.v2: unruled tables, merged/spanning cells, rotated headers, plus expected exact number/unit/comparator checks, and re-run the lab (docling-lab.yml dispatch = hosted CI, owner approval). Synthetic/public sources only; hashed lockfile unchanged; aggregate-only report. Stop: no worker, extractor, or database change; shadow numbers remain measurements until v2 says otherwise. | RAG programme coordinator, post-B4 (2026-08-19) | 2026-08-19 | +| #M54C4N | P2 | issue | live-drift's Align migration history step fails on PGRST106 (supabase_migrations not exposed to PostgREST), so the job stays red and pinned issue #1963 cannot self-close even with zero drift | Exposed 2026-08-19 by Phase 6.2: live-drift run 32251326536 reported No unexpected schema drift (all 20 history rows allowed) but concluded failure because the next step, Align migration history for Supabase Preview (npm run check:migration-history, scripts/check-migration-history-alignment.ts, added in Phase 0 PR #1939), ran for the first time ever -- it was skipped on every earlier run because the compare step failed first, and the last green run (29700973962, 2026-07-19) predates it. It reads supabase_migrations.schema_migrations through PostgREST with Accept-Profile, which this project has never exposed (406 PGRST106: only public, graphql_public). The routing job therefore keeps #1963 open on job result even with an empty findings block. OPTIONS (owner decision): (a) expose supabase_migrations read-only to the service role in the dashboard; (b) rewrite the read onto the management API / supabase migration list using the SUPABASE_ACCESS_TOKEN secret (#183); (c) add a service-role RPC listing versions (new migration, own window). Until fixed, weekly live-drift stays red on that step alone; drift itself is green. Evidence: forensics section 6.2 completion step 6. | Phase 6.2 session 2026-08-19; live-drift run 32251326536 | 2026-08-19 | ## Resolved / archive From eb133fb758ab30d172a7b9791cd19620a9d5b92c Mon Sep 17 00:00:00 2001 From: BigSimmo <87357024+BigSimmo@users.noreply.github.com> Date: Fri, 21 Aug 2026 07:10:47 +0800 Subject: [PATCH 8/8] docs(issues): queue closures for the two rows the Codex review flagged Both P2 findings on PR #2206 were verified against the ledger and are correct. #VZN8G3 duplicates the earlier, still-open #BSBE9B: both require the same docling-lab-fixtures.v2 corpus (unruled tables, merged/spanning cells, rotated headers) and both gate a docling table-quality promotion argument on it. The duplicate came from inbox request a20fc4ce being queued without checking the ledger for an existing row, and was only visible once reconciliation allocated an id. #BSBE9B stays canonical. #Q5JHBJ was left in Open items while its own detail records Phase 6.2 as complete with proof, so completed deployment and guard work could be re-dispatched. Its summary's deliverables are all evidenced in the row, and the row itself states the single residual is out of its scope and tracked as #M54C4N. These are queued as immutable done requests rather than edits to the canonical ledger, so they apply at the next reconciliation. They cannot be reconciled in this PR: the write-discipline audit compares the ledger against a clean application of the requests present in the PR's base on main, and these two were created on this branch. Co-Authored-By: Claude Opus 5 --- .../43f5e351-6a7b-4217-b4a4-897d8be9b905.json | 11 +++++++++++ .../74e3183a-6e6a-49ef-9e8d-6bb329396ca6.json | 11 +++++++++++ 2 files changed, 22 insertions(+) create mode 100644 docs/outstanding-issues-inbox/43f5e351-6a7b-4217-b4a4-897d8be9b905.json create mode 100644 docs/outstanding-issues-inbox/74e3183a-6e6a-49ef-9e8d-6bb329396ca6.json diff --git a/docs/outstanding-issues-inbox/43f5e351-6a7b-4217-b4a4-897d8be9b905.json b/docs/outstanding-issues-inbox/43f5e351-6a7b-4217-b4a4-897d8be9b905.json new file mode 100644 index 0000000000..5b8ac9e85e --- /dev/null +++ b/docs/outstanding-issues-inbox/43f5e351-6a7b-4217-b4a4-897d8be9b905.json @@ -0,0 +1,11 @@ +{ + "version": 2, + "id": "43f5e351-6a7b-4217-b4a4-897d8be9b905", + "createdOn": "2026-08-20", + "action": "done", + "payload": { + "id": "#Q5JHBJ", + "outcome": "Closed 2026-08-20: every deliverable named in this row's own summary is complete and evidenced in its detail. The 20260818090000 schema_drift_snapshot v2 history probe was deployed in the owner-authorised production window, the first unguarded no-statements report was triaged (all fifteen versions classified), and the fail-fast guard migrations were authored and landed (six migrations, allowlist now 20 entries). Proof recorded in the row: full chain replay Applied 210/210 with CHAIN == MANIFEST, seven mutants raise and name their object, production and staging both green, and live-drift run 32251326536 reported No unexpected schema drift with all 20 history rows allowed. The row's detail already states the one residual is NOT this row's scope and is tracked separately as #M54C4N (the PGRST106 migration-history alignment step). Leaving the row in Open items made completed deployment and guard work re-dispatchable. Raised by the Codex review of PR #2206 (comment 3825543312).", + "baseRowFingerprint": "8ee621e4b25222d846295f592c9a875058e82d9ac994390e4841b80a9764e1be" + } +} diff --git a/docs/outstanding-issues-inbox/74e3183a-6e6a-49ef-9e8d-6bb329396ca6.json b/docs/outstanding-issues-inbox/74e3183a-6e6a-49ef-9e8d-6bb329396ca6.json new file mode 100644 index 0000000000..9988950ae3 --- /dev/null +++ b/docs/outstanding-issues-inbox/74e3183a-6e6a-49ef-9e8d-6bb329396ca6.json @@ -0,0 +1,11 @@ +{ + "version": 2, + "id": "74e3183a-6e6a-49ef-9e8d-6bb329396ca6", + "createdOn": "2026-08-20", + "action": "done", + "payload": { + "id": "#VZN8G3", + "outcome": "Closed as a duplicate 2026-08-20. #VZN8G3 and the earlier, still-open #BSBE9B are the same task: both require a docling-lab-fixtures.v2 corpus with unruled tables, merged/spanning cells and rotated headers, and both gate any docling table-quality promotion argument on that corpus existing. #BSBE9B is the canonical row and stays open; keeping both invites parallel implementations and conflicting closure state. The duplicate arose because inbox request a20fc4ce was queued without first checking the ledger for an existing row, and it was only visible once reconciliation allocated the id. Raised by the Codex review of PR #2206 (comment 3825543316).", + "baseRowFingerprint": "4d882e491bda78435ceae533c0fb5af75bd1477894dfed4e4b7f4a3176f89426" + } +}