From e9b9a47643c1540cea4f56e6b38ff89d1f909d02 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 22 Oct 2026 07:48:25 +0000 Subject: [PATCH 1/2] Reconcile 25 ledger inbox requests after the 21-22 Oct merges Serialized reconcile on fresh main (4a790082d). Applies the queued add, done and update requests from the answer safety, structure, teaching, content currency, security and main CI work; audit records move to inbox/applied. Co-Authored-By: Claude Opus 5.5 (1M context) Claude-Session: https://claude.ai/code/session_01Jchk5iTkeUyPRUoCHyWei6 --- data/outstanding-issues-snapshot.json | 186 +++--------------- .../0f1769a2-d7cc-444c-b7ff-59179853ef8d.json | 0 .../1b14ad72-1683-433b-949b-2bce7a45923a.json | 0 .../33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json | 0 .../39ef3988-1134-4d05-a585-fa5f86e1ef14.json | 0 .../3b568825-8cf8-433b-8443-a6718b48c55e.json | 0 .../3d3374d8-c284-4d8e-995e-abc4df0210ed.json | 0 .../4f15ebaf-d311-4971-a52f-46e26a2a963d.json | 0 .../62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json | 0 .../7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json | 0 .../7b5351a4-f139-4c45-bf18-8a13b620d834.json | 0 .../91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json | 0 .../92708603-cb8b-4630-8dc0-b3aedf1e8dde.json | 0 .../b0662870-5af2-4013-9898-e3ef56020acf.json | 0 .../b0e14314-8066-44b1-9134-17e4bc6f0d12.json | 0 .../bc284aef-c833-44ee-8b87-c054b4b41559.json | 0 .../c9aed1b4-cba9-43ea-9054-22856e929d20.json | 0 .../d7678153-b6d7-4571-8f46-48f4a59ca47a.json | 0 .../df98fa18-944a-4669-ac12-83cea502f1ee.json | 0 .../e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json | 0 .../e914e120-58ce-42c0-a286-e9a134989246.json | 0 .../e9b59bb8-6de5-4041-a086-c6d01bae8593.json | 0 .../eed86710-2875-44cf-80bf-8a79dc8fe069.json | 0 .../f1ce20e3-cf02-40e2-a370-bf0047f686d0.json | 0 .../f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json | 0 .../f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json | 0 docs/outstanding-issues.md | 44 +++-- 27 files changed, 53 insertions(+), 177 deletions(-) rename docs/outstanding-issues-inbox/{ => applied}/0f1769a2-d7cc-444c-b7ff-59179853ef8d.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/1b14ad72-1683-433b-949b-2bce7a45923a.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/39ef3988-1134-4d05-a585-fa5f86e1ef14.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/3b568825-8cf8-433b-8443-a6718b48c55e.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/3d3374d8-c284-4d8e-995e-abc4df0210ed.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/4f15ebaf-d311-4971-a52f-46e26a2a963d.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/7b5351a4-f139-4c45-bf18-8a13b620d834.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/92708603-cb8b-4630-8dc0-b3aedf1e8dde.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/b0662870-5af2-4013-9898-e3ef56020acf.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/b0e14314-8066-44b1-9134-17e4bc6f0d12.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/bc284aef-c833-44ee-8b87-c054b4b41559.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/c9aed1b4-cba9-43ea-9054-22856e929d20.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/d7678153-b6d7-4571-8f46-48f4a59ca47a.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/df98fa18-944a-4669-ac12-83cea502f1ee.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/e914e120-58ce-42c0-a286-e9a134989246.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/e9b59bb8-6de5-4041-a086-c6d01bae8593.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/eed86710-2875-44cf-80bf-8a79dc8fe069.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/f1ce20e3-cf02-40e2-a370-bf0047f686d0.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json (100%) rename docs/outstanding-issues-inbox/{ => applied}/f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json (100%) diff --git a/data/outstanding-issues-snapshot.json b/data/outstanding-issues-snapshot.json index db6c7e42f0..2b3393f6aa 100644 --- a/data/outstanding-issues-snapshot.json +++ b/data/outstanding-issues-snapshot.json @@ -1,16 +1,16 @@ { "version": "outstanding-issues-snapshot-v2", "ledger_revision": { - "committed_at": "2026-10-17" + "committed_at": "2026-10-21" }, "counts": { - "open": 108, - "p1": 17, - "p2": 56, - "p3": 35, + "open": 94, + "p1": 14, + "p2": 49, + "p3": 31, "queued": 5, "pending": 0, - "resolved": 818 + "resolved": 834 }, "queue": [ { @@ -133,15 +133,6 @@ "source": "RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17", "added": "2026-08-17" }, - { - "id": "#VXB8XA", - "priority": "P2", - "type": "issue", - "summary": "Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one", - "detail": "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.", - "source": "RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17", - "added": "2026-08-17" - }, { "id": "#6GW95D", "priority": "P3", @@ -403,15 +394,6 @@ "source": "2026-09-16 Sentry/Railway investigation", "added": "2026-09-16" }, - { - "id": "#TN512M", - "priority": "P1", - "type": "issue", - "summary": "Three systems correctly detect production failures and report to nobody: the live monitor, Sentry, and CI on main", - "detail": "UPDATE 2026-09-26: CI ON MAIN CONFIRMED END TO END. The owner confirmed at 10:56Z that main-failure issue #3092 (a real red main, opened 09:45Z) reached his GitHub app Inbox through the owner assignment from PR #3017; #T82ND3 closed on that evidence. The live monitor, eval-canary, live-drift and ingestion-autopilot use the same assign-the-owner path, so the channel is proven, but none of those has yet been seen to fire since #3017. Sentry alert routing is still unaddressed. Close once Sentry routes to the owner (or the owner decides it need not). PRIOR DETAIL: UPDATE 2026-09-25: OWNER DECISION on the channel: phone notifications through the GitHub mobile app. Shipped in PR #3017: live-domain-monitor, CI on main, eval-canary, live-drift and ingestion-autopilot now assign the repository owner (best-effort, the alert still opens if assignment is refused) on open and on update, so every opening and later comment notifies the owner. Close condition unchanged: one real or deliberately triggered failure must be seen to reach the owner's phone. Sentry alert routing is still unaddressed (Sentry MCP was unreachable). PRIOR DETAIL: REVIEW 2026-09-25 (offline audit of current main; no provider access): The close condition now has a negative answer: during the 27-hour production deploy stall on 2026-09-21/22, monitor issue #2973 was opened and updated and nobody acted on it. GitHub-issue routing is proven to fire but not to reach a person. Next action: choose a channel that reaches the owner (phone push, Slack or page). Fact fix: live-monitor routing shipped in #2877 (28dabe0c3), not #2884 (which covered CI on main and eval). The stall's own root cause is tracked separately (inbox add of 2026-09-22); CI on main is #T82ND3. PRIOR DETAIL: TWO OF THE THREE SYSTEMS NOW REPORT, as of 2026-09-18. (1) LIVE MONITOR: live-domain-monitor.yml had no failure handling at all — a grep for issue, notify or any conditional step returned nothing, which is why a real catalogue outage went unreported for about eighteen hours. PR #2884 (merged) gave it the eval-canary failure-issue step. (2) SENTRY: PR #2890 (merged) fixed log delivery across Next's bundle split, so application logs actually reach Sentry rather than being dropped at the boundary. (3) CI ON MAIN is tracked as #T82ND3 and also shipped in #2884. WHAT REMAINS: none of the three has been confirmed against a real production failure — all were verified by workflow tests, not by watching one fire. Dedupe was reviewed (label-based find-or-create, so a flake cannot spawn an issue per run) but likewise not observed under load. Close once a genuine outage has produced a notification someone acted on.", - "source": "Direct reads of live-domain-monitor run history, Sentry issue list, and ledger #T82ND3; session 01XGpedMgoXWK3U3fn2TWTzR, 2026-09-17.", - "added": "2026-09-17" - }, { "id": "#CD63JW", "priority": "P3", @@ -448,15 +430,6 @@ "source": "Live latency review session 2026-09-17", "added": "2026-09-17" }, - { - "id": "#E6142T", - "priority": "P2", - "type": "issue", - "summary": "The PWA update notice may overlap page content on non-answer pages, and the services search mode has no mode-noun stop list", - "detail": "UPDATE 2026-09-25 (PR C, rebuilt on main after PR #3019): Part 1 (PWA update notice overlap) is CLOSED by owner ruling 2026-09-25: leave the notice where it is. Part 2 (services mode nouns in modeSearchWords) REMAINS OPEN and was deliberately not shipped, because on main it has no observable effect: modeSearchWords in src/lib/smart-search-intent.ts is read only by smartSearchContentTerms, which is called only for calculators, factsheets and dictionary (calculator-filters.ts, factsheets-data.ts, dictionary.ts). The services ranker (src/lib/service-ranker.ts) and universal search call smartSearchExpansions, which returns curated rule terms only and never reads modeSearchWords, so adding service/services/pathway(s)/program/referral there changes no services result. It becomes meaningful only if services search starts consuming smartSearchContentTerms (e.g. a required-term filter, which owner decision 18 excluded from PR C). NEXT: close as won't-fix, or keep it parked until such a consumer exists.", - "source": "PR #2860 working notes; code read of src/app/globals.css:3698-3712 and src/lib/smart-search-intent.ts at origin/main 6f0a3d444; session 01B5auxdz8JsfzSnDezMWz1n, 2026-09-17.", - "added": "2026-09-17" - }, { "id": "#YBJVM7", "priority": "P2", @@ -502,15 +475,6 @@ "source": "session 2026-09-20 /ledger sweep — nine-agent repo maturity review", "added": "2026-09-20" }, - { - "id": "#QKW3KN", - "priority": "P2", - "type": "task", - "summary": "rag-extractive-answer.ts is now the largest file in the repo at 5268 lines and is not on the monoliths backlog", - "detail": "Add it to docs/maturity-backlog-workorders.md section X3 as a fourth tracked monolith and extract the isSourceBound* predicate cluster first. Why: it grew ~30% in under three weeks (4042 lines at the 2026-09-02 audit) while all three tracked monoliths shrank, so the one file getting worse is the one nothing is watching. It also carries 10 narrowly-scoped isSourceBound* query predicates, a pattern that adds a bespoke function per answer-quality bug rather than generalising. Owner: assistant. Confidence: high - line counts verified 2026-09-20. Depends on: nothing. NOTE CORRECTED 2026-09-20 after a Codex review on PR #2930 caught the original wording overstating the contract. RAG-ranking surface, and the two requirements are NOT the same trigger: the flag-it-first rule applies to EVERY edit here, including a rename or a comment (AGENTS.md 'RAG ranking protection' -> 'Flag it'), but the live eval-canary before/after pair is required only when retrieval, ranking or ordering BEHAVIOUR changes ('Canary for behaviour'). The extraction proposed above is behaviour-preserving, so on its own it needs the flag and not the canary. This distinction is load-bearing rather than pedantic: canary dispatches are provider-backed (~USD 1-2) and need the owner's explicit approval each time, so stating the canary as unconditional would either stall this work behind an approval it does not need or spend money to prove nothing moved. If an extraction does turn out to alter ordering, the canary requirement applies in full and the clamped-score and comparator-key contracts still hold.", - "source": "session 2026-09-20 /ledger sweep — nine-agent repo maturity review; note corrected after Codex review on PR #2930", - "added": "2026-09-20" - }, { "id": "#PM71Z1", "priority": "P2", @@ -525,7 +489,7 @@ "priority": "P1", "type": "issue", "summary": "Medication and therapy records carry zero source links while their footers tell the clinician to check the linked source", - "detail": "UPDATE 2026-10-10: PR #3398 proposed WA-first sources in src/data/medication-source-links.json: wa-health-clozapine-guideline-2024 for clozapine, and the Australian Prescriber lithium article plus its correction for lithium-carbonate-ir-sr. They render nothing until the owner adopts and signs off those register records. Valproate, other anticonvulsants and QTc-risk drugs still have no proposal. UPDATE 2026-09-25: step 1 shipped in PR #3017. The medication footer no longer promises a linked source (it points to current Australian product information or the local guideline); the therapy footer points to the sources named under Source & review status. OWNER DECISION: default source per medication is the TGA Product Information, plus WA guidelines where they exist; engineering proposes, owner confirms, high-risk medicines first (clozapine, lithium, valproate and other anticonvulsants, QTc/overdose-risk drugs). Real links still need the data-model change described below. PRIOR DETAIL: /medications/[slug] has 0 anchors in
on all four tabs; /therapy-compass/[slug] the same. Footer on every tab: 'verify every dose and interaction against the linked source'. acamprosate states Max 1998 mg/day, a serum creatinine >120 micromol/L contraindication, Half-life 13-28.4 h and an unattributed EFFICACY: MODERATE tile; the only provenance is one prose sentence on tab 4 below the fold. Root cause: medication-records.ts:118-126 derives governance from a free-text src section with no URL or document id. /dictionary and /factsheets do this correctly. Fixing properly is a database migration plus clinical governance.", + "detail": "UPDATE 2026-10-22: second high-risk batch proposed (PR from thread 'Medication source links'). src/data/medication-source-links.json now maps 74 of 330 medicines (was 26): other anticonvulsants, gabapentinoids, oral antipsychotics, QTc-prolonging antiemetics, TCAs and other overdose-risk antidepressants, benzodiazepines and Z-drugs, buprenorphine, S8 stimulants, ketamine, propranolol and clonidine, each to its TGA PI search link, plus the WA Monitored Medicines Prescribing Code and ScriptCheckWA for stimulants, alprazolam, buprenorphine, ketamine and gabapentinoids. Also captured WA High Risk Medication Management Policy MP 0131/20 v2.0 (candidate, unmapped). Nothing renders until the owner signs. OWNER DECISION 2026-10-22: the live TGA PI search is the PI source, signed once per medicine with no fixed version (docs/decisions/2026-10-22-tga-pi-live-search-source.md), because www.ebs.tga.gov.au robots.txt disallows all automated retrieval. All 71 TGA PI records are now candidates under dateModel live_product_information. Next action: owner signs the records and the mappings (sign-off batch in the project files), then a separate adoption decision. UPDATE 2026-10-10: PR #3398 proposed WA-first sources in src/data/medication-source-links.json: wa-health-clozapine-guideline-2024 for clozapine, and the Australian Prescriber lithium article plus its correction for lithium-carbonate-ir-sr. They render nothing until the owner adopts and signs off those register records. Valproate, other anticonvulsants and QTc-risk drugs still have no proposal. UPDATE 2026-09-25: step 1 shipped in PR #3017. The medication footer no longer promises a linked source (it points to current Australian product information or the local guideline); the therapy footer points to the sources named under Source & review status. OWNER DECISION: default source per medication is the TGA Product Information, plus WA guidelines where they exist; engineering proposes, owner confirms, high-risk medicines first (clozapine, lithium, valproate and other anticonvulsants, QTc/overdose-risk drugs). Real links still need the data-model change described below. PRIOR DETAIL: /medications/[slug] has 0 anchors in
on all four tabs; /therapy-compass/[slug] the same. Footer on every tab: 'verify every dose and interaction against the linked source'. acamprosate states Max 1998 mg/day, a serum creatinine >120 micromol/L contraindication, Half-life 13-28.4 h and an unattributed EFFICACY: MODERATE tile; the only provenance is one prose sentence on tab 4 below the fold. Root cause: medication-records.ts:118-126 derives governance from a free-text src section with no URL or document id. /dictionary and /factsheets do this correctly. Fixing properly is a database migration plus clinical governance.", "source": "session 2026-10-10 /ledger sweep, PR #3398 (merged 2026-10-09 as 6f9203d55)", "added": "2026-09-20" }, @@ -551,8 +515,8 @@ "id": "#MSJT12", "priority": "P1", "type": "issue", - "summary": "Production deploys stopped landing for 27 hours on 2026-09-21; root cause unknown and GitHub-issue monitor routing still did not drive action", - "detail": "Second occurrence of the Railway deploy-rollback failure mode first seen 2026-09-11..09-14 (24 consecutive rollbacks, documented in scripts/check-live-deployment-freshness.mjs and docs/deployment-architecture.md 'Readiness: what /api/health/ready may and may not ask'). Measured 2026-09-22 from GitHub deployment statuses: the Database service in the production environment last landed a deploy at 2026-09-21T05:59Z (3a43f808d) and did not land another until 2026-09-22T09:15Z (76bf29ffa, PR #2978). In between, four production deployments were created for ef257fa5c, f44ae5397, 56b123509 and 373046b76 and every one went in_progress -> inactive without ever reaching success. All four built cleanly in the Docker image build workflow, live-drift was green on the 2026-09-21 migrations, and Railway built PR preview environments normally throughout, so the integration, the image and the database are all ruled out. That leaves Railway-side deploy/start/healthcheck rejection, which is the documented mechanism: each healthcheck attempt gets ~10s against /api/health/ready and a container that cannot answer inside the window is discarded and rolled back, leaving the previous deploy serving. Confirming which of the four failed and why needs the Railway deployment logs for the production environment, which no agent session has had access to. Production recovered on its own and no fix was applied, so the trigger is unknown and can recur. Separately confirmed NOT a fault: nine main commits in the same window got a staging deploy but no production deploy at all - all nine touched no path matched by watchPatterns in railway.app.json, which is correct filtering. Alerting clarification (rewrites a false claim in the original draft of this request): live-domain-monitor.yml already has monitor-routing (issues: write + actions/github-script) as of #2884 / ledger #TN512M, and it DID fire during this stall — pinned issue #2973 ('Live domain monitor failing', label live-monitor-failure) was opened 2026-09-21T12:40Z, updated on later red runs including the deployment-freshness failure at 2026-09-22T06:47Z, and closed on the next green run at 2026-09-22T12:41Z. So 'nothing routes a red monitor run' is false. What remains unverified for human delivery: despite #2973 being open and repeatedly commented for ~24 hours of the stall, the gap was still found only because a human inspected GitHub deployment statuses, not because anyone acted on the pinned issue. That matches the #TN512M residual ('Close once a genuine outage has produced a notification someone acted on') and the workflow comment that owner failure emails arrive unread. Durable next actions: (1) pull Railway production deployment logs for the four inactive deploys and record the reject reason; (2) treat this stall as the missing #TN512M real-outage evidence that GitHub-issue routing alone is insufficient delivery, and decide a human-reachable path (page/Slack/owner push) before adding more probes. Pairs with #HYSWAF (Railway deploys every main push without waiting for required checks) and #TN512M.", + "summary": "Production deploys stopped landing for 27 hours on 2026-09-21; likely cause Railway Wait for CI skipping deploys while main CI was red", + "detail": "UPDATE 2026-10-21 (read-only GitHub deployment statuses and Actions run times; no Railway access): LIKELY CAUSE FOUND, and it is not a healthcheck rollback. Each of the four stuck production deploys went from in_progress to inactive within 5 to 6 seconds of that commit's CI workflow run on main concluding failure: ef257fa5c CI failed 10:12:32Z, deploy inactive 10:12:37Z; f44ae5397 10:31:12Z / 10:31:18Z; 56b123509 16:48:48Z / 16:48:54Z; 373046b76 17:36:52Z / 17:36:58Z. That is Railway's documented Wait for CI behaviour (a failed workflow run skips the deploy at once; docs/deployment-architecture.md). 3a43f808d, which triggered no CI run, deployed normally. 76bf29ffa began deploying at 09:08Z on 2026-09-22, three minutes before its own CI run failed at 09:11Z, which fits a manual deploy or Wait for CI being switched off then. So the stall was most likely Wait for CI enabled on the production service while CI on main was red (release-browser-matrix Firefox/WebKit, Lighthouse and PR required failures). This is inferred from timing only and stays provisional until Railway deployment logs or the setting history confirm it. By 2026-09-27 the setting read source.checkSuites false. The same signature recurs on 2026-10-21: 3b4518fdb went inactive at 07:10:45Z, seven seconds after its Docker image build run failed at 07:10:38Z, so Wait for CI appears to be on again and any red workflow run on a main commit skips the production deploy (handed to the Alert root causes work, #3685). Next action, owner: read the Wait for CI setting on the Railway app and worker services and confirm; then decide per #HYSWAF whether it stays on, which requires main CI to stay green. PRIOR DETAIL (its healthcheck-rollback explanation is superseded by the timing evidence above): Second occurrence of the Railway deploy-rollback failure mode first seen 2026-09-11..09-14 (24 consecutive rollbacks, documented in scripts/check-live-deployment-freshness.mjs and docs/deployment-architecture.md 'Readiness: what /api/health/ready may and may not ask'). Measured 2026-09-22 from GitHub deployment statuses: the Database service in the production environment last landed a deploy at 2026-09-21T05:59Z (3a43f808d) and did not land another until 2026-09-22T09:15Z (76bf29ffa, PR #2978). In between, four production deployments were created for ef257fa5c, f44ae5397, 56b123509 and 373046b76 and every one went in_progress -> inactive without ever reaching success. All four built cleanly in the Docker image build workflow, live-drift was green on the 2026-09-21 migrations, and Railway built PR preview environments normally throughout, so the integration, the image and the database are all ruled out. That leaves Railway-side deploy/start/healthcheck rejection, which is the documented mechanism: each healthcheck attempt gets ~10s against /api/health/ready and a container that cannot answer inside the window is discarded and rolled back, leaving the previous deploy serving. Confirming which of the four failed and why needs the Railway deployment logs for the production environment, which no agent session has had access to. Production recovered on its own and no fix was applied, so the trigger is unknown and can recur. Separately confirmed NOT a fault: nine main commits in the same window got a staging deploy but no production deploy at all - all nine touched no path matched by watchPatterns in railway.app.json, which is correct filtering. Alerting clarification (rewrites a false claim in the original draft of this request): live-domain-monitor.yml already has monitor-routing (issues: write + actions/github-script) as of #2884 / ledger #TN512M, and it DID fire during this stall — pinned issue #2973 ('Live domain monitor failing', label live-monitor-failure) was opened 2026-09-21T12:40Z, updated on later red runs including the deployment-freshness failure at 2026-09-22T06:47Z, and closed on the next green run at 2026-09-22T12:41Z. So 'nothing routes a red monitor run' is false. What remains unverified for human delivery: despite #2973 being open and repeatedly commented for ~24 hours of the stall, the gap was still found only because a human inspected GitHub deployment statuses, not because anyone acted on the pinned issue. That matches the #TN512M residual ('Close once a genuine outage has produced a notification someone acted on') and the workflow comment that owner failure emails arrive unread. Durable next actions: (1) pull Railway production deployment logs for the four inactive deploys and record the reject reason; (2) treat this stall as the missing #TN512M real-outage evidence that GitHub-issue routing alone is insufficient delivery, and decide a human-reachable path (page/Slack/owner push) before adding more probes. Pairs with #HYSWAF (Railway deploys every main push without waiting for required checks) and #TN512M.", "source": "Claude session 2026-09-22; GitHub deployment statuses for Database/production; live-domain-monitor runs 35639421619/35696377977/35728663173 and issue #2973 routing evidence; Codex review on PR #2982", "added": "2026-09-22" }, @@ -570,7 +534,7 @@ "priority": "P1", "type": "task", "summary": "Clinical eval battery misses high-risk scenarios: no hepatic, older-adult, interaction or false-premise cases (audit F14 + F15)", - "detail": "OWNER DECISION 2026-09-25: approved. Engineering drafts the 20 cases (question, key facts a correct answer must contain, facts it must not state, expected source); the owner reviews and corrects them before any are added to the harness. A first draft of all 20 was delivered to the owner on 2026-09-25 as a Word document (not committed: clinical content awaiting review). Verified offline by topic count over src/lib/rag/rag-eval-cases.ts (101 cases): hepatic 0, older adult/elderly 0, drug interaction 0, unsafe/false premise 0, Mental Health Act 1, QTc 2, pregnancy 3, paediatric 2. Owner recommendation (2026-09-25): start with ~20 clinician-reviewed cases (3 pregnancy/breastfeeding, 3 renal/hepatic, 2 older adults, 2 QTc, 2 lithium/clozapine monitoring, 2 overdose, 2 interactions, 2 MHA, 2 false-premise where the right answer corrects the premise); engineering drafts expected key facts + source, owner reviews. Adding golden cases touches the eval harness (RAG-protected surface): flag before editing, and live canary dispatches need approval.", + "detail": "UPDATE 2026-10-21 (answer safety hardening thread, verified offline on main 81ba5aefa): 18 of the 20 cases are wired into answerQualityEvalCases as high-risk- on the owner go-ahead of 2026-10-10, with verbatim evidence pinned by tests/high-risk-eval-cases-draft.test.ts. Two stay out as source_needed: breastfeeding-lithium and hepatic-valproate, because no WA passage for either is held in the repository. Draft expected facts for both were sent to the owner for correction on 2026-10-21 (not approved). Next: owner corrects the drafts and approves a free read-only fetch of the KEMH lithium breastfeeding and CG.MHSP.Valproate passages into a fixture, then the two cases are wired in. PRIOR DETAIL: OWNER DECISION 2026-09-25: approved. Engineering drafts the 20 cases (question, key facts a correct answer must contain, facts it must not state, expected source); the owner reviews and corrects them before any are added to the harness. A first draft of all 20 was delivered to the owner on 2026-09-25 as a Word document (not committed: clinical content awaiting review). Verified offline by topic count over src/lib/rag/rag-eval-cases.ts (101 cases): hepatic 0, older adult/elderly 0, drug interaction 0, unsafe/false premise 0, Mental Health Act 1, QTc 2, pregnancy 3, paediatric 2. Owner recommendation (2026-09-25): start with ~20 clinician-reviewed cases (3 pregnancy/breastfeeding, 3 renal/hepatic, 2 older adults, 2 QTc, 2 lithium/clozapine monitoring, 2 overdose, 2 interactions, 2 MHA, 2 false-premise where the right answer corrects the premise); engineering drafts expected key facts + source, owner reviews. Adding golden cases touches the eval harness (RAG-protected surface): flag before editing, and live canary dispatches need approval.", "source": "Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access", "added": "2026-09-25" }, @@ -579,7 +543,7 @@ "priority": "P2", "type": "task", "summary": "Source-conflict and jurisdiction behaviour has no deliberate tests; owner to confirm the tier rule (audit F16)", - "detail": "OWNER DECISION 2026-09-25: confirmed the existing tier order (WA validated > Australian national > other Australian state > supplementary, within a relevance band) and asked for two additions: a superseded source is never used as evidence, and a clinically material WA-vs-national disagreement is disclosed with both sources shown. Found 2026-09-25: outdated sources are currently KEPT and shown with a danger-severity OUTDATED warning (src/lib/source-governance.ts), and authority conflict in source-authority-registry.ts means publisher-metadata mismatch, not clinical disagreement. Both additions change retrieval/answer behaviour: flag before editing and run a live canary pair (owner approval, about USD 1-2) around the change. A rule already exists: src/lib/australian-source-priority.ts ranks wa_validated < australian_national < australian_state < supplementary WITHIN a relevance band, and tracks authorityConflictCount. Only 3 eval cases touch conflict/superseded sources. Owner recommendation (2026-09-25): confirm that order, add (a) superseded versions never used as evidence and (b) disclose both sources when WA and national disagree on something clinically material. Next action: owner confirms the rule, then add conflict/currentness/attribution cases. Ranking is RAG-protected: flag before editing and require a canary pair for any ordering change.", + "detail": "UPDATE 2026-10-21 (answer safety hardening thread, offline): tier-rule tests added to tests/australian-source-priority.test.ts (WA ahead of national ahead of other states ahead of supplementary at equal relevance, relevance always wins across bands, supplementary padding dropped once two Australian documents suffice). Both owner additions remain unbuilt: (a) outdated sources are only penalised in rag-second-stage.ts and warned about in the sealed src/lib/source-governance.ts, so they can still carry a claim; (b) buildSourceConflictSection (src/lib/rag/source-conflict-section.ts) only compares uploaded_local with australian_public, and uploaded_local retrieval is fail-closed (#9V1TJ5), so a WA versus national public disagreement is never disclosed. Both are answer-behaviour changes: RAG notice, canary pair and hazard reseal needed; plan sent to the owner 2026-10-21. PRIOR DETAIL: OWNER DECISION 2026-09-25: confirmed the existing tier order (WA validated > Australian national > other Australian state > supplementary, within a relevance band) and asked for two additions: a superseded source is never used as evidence, and a clinically material WA-vs-national disagreement is disclosed with both sources shown. Found 2026-09-25: outdated sources are currently KEPT and shown with a danger-severity OUTDATED warning (src/lib/source-governance.ts), and authority conflict in source-authority-registry.ts means publisher-metadata mismatch, not clinical disagreement. Both additions change retrieval/answer behaviour: flag before editing and run a live canary pair (owner approval, about USD 1-2) around the change. A rule already exists: src/lib/australian-source-priority.ts ranks wa_validated < australian_national < australian_state < supplementary WITHIN a relevance band, and tracks authorityConflictCount. Only 3 eval cases touch conflict/superseded sources. Owner recommendation (2026-09-25): confirm that order, add (a) superseded versions never used as evidence and (b) disclose both sources when WA and national disagree on something clinically material. Next action: owner confirms the rule, then add conflict/currentness/attribution cases. Ranking is RAG-protected: flag before editing and require a canary pair for any ordering change.", "source": "Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access", "added": "2026-09-25" }, @@ -619,24 +583,6 @@ "source": "Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access", "added": "2026-09-25" }, - { - "id": "#R2FNTJ", - "priority": "P3", - "type": "rec", - "summary": "CME: curated WA learning-opportunity directory with event freshness and bundle/employer-access checks", - "detail": "Review items F23, F38, D21. Separate provider, programme, event and recorded resource; expire past events, flag cancellations, keep historical pages apart; show 'included in your workshop' or 'available through your employer' before suggesting a purchase. Needs ongoing content upkeep and source-register ownership, so decide who maintains it before building.", - "source": "Master product review 2026-09-26 (thread: Review master review ideas); cross-checked against main 004ab6301", - "added": "2026-09-26" - }, - { - "id": "#JYH1FH", - "priority": "P1", - "type": "issue", - "summary": "1,935 documents display Locally reviewed with no recorded reviewer, and nobody knows if a person marked them", - "detail": "MEASURED 2026-09-25 from the live audit-source-governance --json run (operator-run; this session had no credentials). The report carries clinical_validation_status_counts locally_reviewed 1935, unverified 130 across 2065 clinical governance documents. src/lib/document-filter-model.ts renders locally_reviewed to clinicians as 'Locally reviewed' and src/lib/answer-client-payload.ts treats it as an authority level beside approved, so this is a review claim shown to the people using the system. The same report said reviewer_attribution reviewed_record_count 0 over 3907 records with passed true, because isRecordMarkedReviewed read review_status only and required the exact string 'reviewed'. PR #3028 fixed the detector, so the next live run will examine those 1935 documents for the first time. WHAT THIS ROW IS FOR, and it is not the code fix: nobody has established whether those 1935 were marked locally_reviewed by a person or in bulk by an import. If by import, the badge overstates what happened and the honest repair is to the records rather than to any gate; fixing the detector only makes the question visible. NEXT ACTION, owner: run npm run audit:source-governance -- --json on a machine with credentials and read unattributed_reviewed_record_count; then decide person-vs-import, which is a governance judgement and not an agent decision. Offline code path verified; live consequence unmeasured.", - "source": "Nine-issue packet follow-through session, 2026-09-25; live audit output pasted by the owner", - "added": "2026-09-25" - }, { "id": "#T9PRB9", "priority": "P2", @@ -646,15 +592,6 @@ "source": "Owner-approved timing probe 2026-09-26 (thread: Clean up task list)", "added": "2026-09-26" }, - { - "id": "#46VNY9", - "priority": "P1", - "type": "task", - "summary": "Repair the 1,935 'Locally reviewed' labels: owner confirmed 2026-09-26 they came from a bulk import, not a reviewer", - "detail": "UPDATE 2026-10-09: the repair migration supabase/migrations/20260926170000_repair_import_stamped_locally_reviewed.sql merged to main in PR #3111 (2026-09-27). Merging to main applies migrations to the live database, so it should already have run, but live application is NOT verified. Next action, provider-backed so it needs owner approval: confirm the post-merge live-drift run for that commit passed both check:drift and check:migration-history, then read the 1,935 documents' validation basis to confirm the relabel landed. Close this and #JYH1FH only after both checks. PRIOR DETAIL: UPDATE 2026-10-06: SQL migration supabase/migrations/20260926170000_repair_import_stamped_locally_reviewed.sql is written, dry-run verified, and tested offline. Awaits live Supabase execution to update the 1,935 rows. Close this and #JYH1FH once applied.", - "source": "Owner answer in Claude Code session 2026-09-26 (session_018CR3YcCWjJk2fyzTNYmMi4)", - "added": "2026-09-26" - }, { "id": "#8CKX6F", "priority": "P2", @@ -682,15 +619,6 @@ "source": "Split from #P00HDB after a Codex review of PR #3112, 2026-09-26", "added": "2026-09-26" }, - { - "id": "#4JTTQ7", - "priority": "P2", - "type": "task", - "summary": "Post-merge eval-canary compare for the dead-stem RAG commit (661ccbb64)", - "detail": "34 retrieval/chunking/extraction regexes now match real word forms. Baseline: canary run #105 on 67d961107 (already failing on main, see #J8SJQ9), so compare retrieval metrics (doc/content recall 1.0, per-case rr) rather than pass/fail. Regression: revert 661ccbb64 alone. Also glance at answer grouping and document categories in the app (commit d6dd6f0f9).", - "source": "Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q", - "added": "2026-09-27" - }, { "id": "#H69FNZ", "priority": "P2", @@ -700,60 +628,15 @@ "source": "Latency, network, Railway and wiring review 2026-09-27 (Claude Code session claude/repo-latency-network-review-zcqd5c), offline code read against main 7f8312f2c; no provider access", "added": "2026-09-27" }, - { - "id": "#K55VBV", - "priority": "P3", - "type": "issue", - "summary": "nltk GHSA-8mgp-746c-j5xp (high) has no patched release; transitive via medspacy-quickumls", - "detail": "This one advisory is the 2 high Dependabot alerts (requirements.txt and requirements-cloud.txt). Affected APIs (TransitionParser, AveragedPerceptron, PerceptronTagger save/load) are not called by the worker. Next: bump when nltk ships a fix.", - "source": "Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q", - "added": "2026-09-27" - }, - { - "id": "#HD1C6W", - "priority": "P2", - "type": "task", - "summary": "Owner clinical re-review: word-form fix withheld from three sealed hazard-control files", - "detail": "Dead stems inside \\b...\\b never match: answer-verification.ts:1480 escalat; rag-claim-support.ts:267 escalat, :1108 escalat/initiat/recommend; source-text-sanitizer.ts:48 escalat/contraindicat/prescrib, :61 escalat/prescrib. Edits reverted because these paths are sealed in docs/clinical-hazard-controls.json. Next: owner reviews the one-line changes, then re-apply and run npm run governance:seal-hazard-controls.", - "source": "Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q", - "added": "2026-09-27" - }, { "id": "#MAAXAX", "priority": "P3", "type": "rec", "summary": "Teaching Assessments: tokenized magic-link or external supervisor access flow", - "detail": "Visiting hospital supervisors frequently lack hospital clinical accounts. Build a tokenized magic-link / secure invite flow so supervisors can complete and sign EPA forms without full accounts.", + "detail": "21 Oct 2026, Teaching and CME PR: durable store public.teaching_epa_magic_links (migration 20261021190000, drafted with owner approval; merge only after the owner's own yes), server routes /api/teaching/assessments/magic-links and the respond route on the durable store, doctor and supervisor screens labelled as feedback to copy into CLA, not an official RANZCP sign-off. Next: owner merges; then confirm live-drift passes, and keep /teaching/assessments/respond/* and its API open to signed-out visitors when the 1 Nov sign-in gate lands. Follow-ups: retire the old PUT registration route and the process-memory store once nothing uses them; consider a retention purge for completed or expired links.", "source": "PR #3302 post-merge audit", "added": "2026-10-06" }, - { - "id": "#WVS32F", - "priority": "P3", - "type": "rec", - "summary": "Teaching: organisers have no view of who did not attend (attendance-gap views)", - "detail": "Owner product decision needed (raised in the Teaching Mode polish, PR #3200). Organise shows the register and an attendance download, but nothing lists members with no check-in across sessions. Privacy-sensitive: decide who may see it (organiser only?), over what period, and the honest wording ('no check-in recorded', never 'missed'). Next action: owner decides scope and audience; then design on Organise using existing attendance reads, with personal-practice review before build.", - "source": "Session 2026-10-02, PR #3200", - "added": "2026-10-02" - }, - { - "id": "#ZTDZ4Z", - "priority": "P3", - "type": "rec", - "summary": "Teaching: no in-app QR scanner; check-in relies on the phone's own camera app", - "detail": "Owner product decision needed (raised in the Teaching Mode polish, PR #3200). Today attendees scan the projector QR with the phone camera or type the 6-digit code; the Today button was renamed 'Check in with code' so it does not promise a scanner. Next action: owner decides whether an in-app scanner (camera permission, BarcodeDetector or a library, fallback to typed code) is worth building; if yes, design it inside the Today hero action, keep typed-code fallback, add no new route without wiring.", - "source": "Session 2026-10-02, PR #3200 / #3204", - "added": "2026-10-02" - }, - { - "id": "#F3B2XC", - "priority": "P2", - "type": "task", - "summary": "Check the live Tall Man drug lettering list against the ACSQHC National Tall Man list", - "detail": "src/lib/medications/tall-man.ts is live on medication search and record pages but was never checked against the official list. Doubtful: citaloPRAM/escitaloPRAM and fluPENtixol/zucloPENthixol capitalise the shared stem so they do not separate the pair, CLONazepam differs from ISMP clonazePAM, and VALproate, midazolAM, temazePAM, oxazePAM need checking. Matching is exact-name only. Needs owner verification.", - "source": "PR 3538 review, 15 Oct 2026", - "added": "2026-10-15" - }, { "id": "#H38M3Y", "priority": "P3", @@ -772,15 +655,6 @@ "source": "PsychSift audit review (16 audit reports) checked against main 4382217, 2026-10-13", "added": "2026-10-13" }, - { - "id": "#SAKCD9", - "priority": "P2", - "type": "task", - "summary": "Ranking-snapshot date gate will fail around 3 Nov 2026 if the automated snapshot-refresh PR is not merged (audit H5-1)", - "detail": "The snapshot was refreshed to 4 Oct, so the automatic checks pass today. .github/workflows/ranking-snapshot-refresh.yml runs after each weekly Eval Canary on main and opens a refresh PR once the snapshot is 14 days old, reusing the canary artifact with no provider calls. Next: watch for that PR (expected from about 18 Oct) and get it reviewed and merged before the 30-day expiry; it touches a RAG ranking fixture, so follow docs/rag-behaviour/ and the canary rules. Only if no refresh PR appears (canary failing or not running) does a new paid eval, with the owner's explicit approval, become necessary.", - "source": "Audit 2026-10-08, rechecked against main 2026-10-13", - "added": "2026-10-13" - }, { "id": "#JVQ1HA", "priority": "P2", @@ -853,15 +727,6 @@ "source": "Audit 2026-10-08, rechecked against main 2026-10-13", "added": "2026-10-13" }, - { - "id": "#54XJ7D", - "priority": "P2", - "type": "task", - "summary": "Shift-swap approval checks the team rules only in the browser, not on the server (audit L4E-F2)", - "detail": "Needs a database migration and an owner decision between blocking the swap and asking the manager to acknowledge. A migration merged to main reaches the live database within seconds, so schedule the merge inside an approved window.", - "source": "Audit 2026-10-08, rechecked against main 2026-10-13", - "added": "2026-10-13" - }, { "id": "#54N8ZN", "priority": "P2", @@ -934,15 +799,6 @@ "source": "Regulatory readiness audit 2026-10-20 (/mnt/project-files/reviews/2026-10-20-regulatory-launch-readiness.md)", "added": "2026-10-20" }, - { - "id": "#TBTNGB", - "priority": "P2", - "type": "issue", - "summary": "Lighthouse budget grades and refreshes from a single sample per route, so slow runners fail unrelated PRs", - "detail": "On 21 Oct 2026 a slow-runner window (~15:00Z) failed Lighthouse on #3749 (server-only) and #3752 (CSS-only); all routes' TBT rose together and #3749 passed on rerun (desktop search 956 ms vs 964 ms baseline). The dispatch refresh (run 39625188079, artifact lighthouse-baseline-refresh-39625188079, main 8c03823) is also one sample: desktop-root 1584 ms vs ~935-955 ms typical, so it was not committed. Proposal: take the median of three graded samples per route in scripts/run-lighthouse-budget.mjs for both grading and --update refresh, keeping tolerances unchanged and the two-confirmation rule for breaches.", - "source": "Main CI and test reliability thread, 21 Oct 2026", - "added": "2026-10-21" - }, { "id": "#PYWRTX", "priority": "P3", @@ -1041,6 +897,24 @@ "detail": "Owner decision 17 Oct 2026 21:37 AWST: #WFYDV6 must stay open; PR #3609 archived it without the required sign-off. src/components/forms/wa-mha-form-print.tsx (PR #3538) was reworded on 16 Oct (Form 6B now a report to the Chief Psychiatrist; Non-Statutory Study Layout header), but section lists, the 7-day pre-expiry examination and copy recipients remain unverified and no legal or clinical sign-off is recorded. Nothing imports or renders it; it must stay unwired. Delete it once the 30-day dead-code window passes (after 13 Nov 2026) unless legal and clinical sign-off is obtained first. (Previously archived 2026-10-16: Fixed statutory discrepancies and branding in-place in src/components/forms/wa-mha-form-print.tsx: replaced Form 6B Chief Psychiatrist consent wording with statutory post-order Report to the Chief Psychiatrist wording matching form-register.ts, replaced official WA Department of Health branding with an explicit Non-Statutory Study Layout header and warning banner, and updated tests/wa-mha-form-print.dom.test.tsx (retaining the file per the 30-day dead-code policy). | Note: Reopened 17 Oct 2026 by owner decision (21:37 AWST): archived by PR #3609 without the required legal and clinical sign-off; tracked again as an open P1 row. The form stays unwired until sign-off.)", "source": "PR 3538 review, 15 Oct 2026; owner decision on PR #3609, 17 Oct 2026; reopened in place with the ledger reopen action (PR #3627), replacing duplicate row #Z12CBC", "added": "2026-10-17" + }, + { + "id": "#J0AY9D", + "priority": "P2", + "type": "issue", + "summary": "Guideline-change re-review covers only the 34 medications in the source link map", + "detail": "PR #3746 makes a medication page and its interactions due for review now when a register source they cite has a confirmed change. It reads src/data/medication-source-links.json, which maps 34 of 330 medications. The other records cite their sources (TGA PI, PBS, DACAS) only as free text, and those sources are not in the register, so no change event can reach them. They still get the 12-month date. Next action: register each medicine's sources, then map them with owner confirmation, high-risk medicines first, alongside #05WXHX.", + "source": "PR #3746 Codex review 2026-10-22", + "added": "2026-10-22" + }, + { + "id": "#7B6MMM", + "priority": "P2", + "type": "issue", + "summary": "The WA valproate guideline (CG.MHSP.Valproate.pdf) is not in the live corpus, although an answer-quality eval case expects it", + "detail": "Read-only live query 2026-10-21 (owner-approved free read, answer safety hardening thread): no document in public.documents has a title or file name containing 'valpro' other than the registry JSON records. quality-valproate-pregnancy-contraindication in src/lib/rag/rag-eval-cases.ts lists CG.MHSP.Valproate.pdf as an expected file, and the high-risk case hepatic-valproate (#ZZ4RAP) cannot be sourced without it. The only hepatic valproate passage found was BMJ Best Practice 'Bipolar disorder in adults' p130, whose licence is unconfirmed. Next: owner supplies the WA guideline PDF for ingestion (same path as the CAMHS ADHD guideline, #018); no re-index of existing documents is needed.", + "source": "Answer safety hardening thread, 2026-10-21, read-only Supabase query", + "added": "2026-10-21" } ], "pending": [] diff --git a/docs/outstanding-issues-inbox/0f1769a2-d7cc-444c-b7ff-59179853ef8d.json b/docs/outstanding-issues-inbox/applied/0f1769a2-d7cc-444c-b7ff-59179853ef8d.json similarity index 100% rename from docs/outstanding-issues-inbox/0f1769a2-d7cc-444c-b7ff-59179853ef8d.json rename to docs/outstanding-issues-inbox/applied/0f1769a2-d7cc-444c-b7ff-59179853ef8d.json diff --git a/docs/outstanding-issues-inbox/1b14ad72-1683-433b-949b-2bce7a45923a.json b/docs/outstanding-issues-inbox/applied/1b14ad72-1683-433b-949b-2bce7a45923a.json similarity index 100% rename from docs/outstanding-issues-inbox/1b14ad72-1683-433b-949b-2bce7a45923a.json rename to docs/outstanding-issues-inbox/applied/1b14ad72-1683-433b-949b-2bce7a45923a.json diff --git a/docs/outstanding-issues-inbox/33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json b/docs/outstanding-issues-inbox/applied/33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json similarity index 100% rename from docs/outstanding-issues-inbox/33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json rename to docs/outstanding-issues-inbox/applied/33fdcec2-d4b3-49dd-b7f5-d0c9c5e6cdad.json diff --git a/docs/outstanding-issues-inbox/39ef3988-1134-4d05-a585-fa5f86e1ef14.json b/docs/outstanding-issues-inbox/applied/39ef3988-1134-4d05-a585-fa5f86e1ef14.json similarity index 100% rename from docs/outstanding-issues-inbox/39ef3988-1134-4d05-a585-fa5f86e1ef14.json rename to docs/outstanding-issues-inbox/applied/39ef3988-1134-4d05-a585-fa5f86e1ef14.json diff --git a/docs/outstanding-issues-inbox/3b568825-8cf8-433b-8443-a6718b48c55e.json b/docs/outstanding-issues-inbox/applied/3b568825-8cf8-433b-8443-a6718b48c55e.json similarity index 100% rename from docs/outstanding-issues-inbox/3b568825-8cf8-433b-8443-a6718b48c55e.json rename to docs/outstanding-issues-inbox/applied/3b568825-8cf8-433b-8443-a6718b48c55e.json diff --git a/docs/outstanding-issues-inbox/3d3374d8-c284-4d8e-995e-abc4df0210ed.json b/docs/outstanding-issues-inbox/applied/3d3374d8-c284-4d8e-995e-abc4df0210ed.json similarity index 100% rename from docs/outstanding-issues-inbox/3d3374d8-c284-4d8e-995e-abc4df0210ed.json rename to docs/outstanding-issues-inbox/applied/3d3374d8-c284-4d8e-995e-abc4df0210ed.json diff --git a/docs/outstanding-issues-inbox/4f15ebaf-d311-4971-a52f-46e26a2a963d.json b/docs/outstanding-issues-inbox/applied/4f15ebaf-d311-4971-a52f-46e26a2a963d.json similarity index 100% rename from docs/outstanding-issues-inbox/4f15ebaf-d311-4971-a52f-46e26a2a963d.json rename to docs/outstanding-issues-inbox/applied/4f15ebaf-d311-4971-a52f-46e26a2a963d.json diff --git a/docs/outstanding-issues-inbox/62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json b/docs/outstanding-issues-inbox/applied/62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json similarity index 100% rename from docs/outstanding-issues-inbox/62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json rename to docs/outstanding-issues-inbox/applied/62c5cf9f-95c6-4a40-9112-6f63ac631d9b.json diff --git a/docs/outstanding-issues-inbox/7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json b/docs/outstanding-issues-inbox/applied/7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json similarity index 100% rename from docs/outstanding-issues-inbox/7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json rename to docs/outstanding-issues-inbox/applied/7b394fc8-e60e-4f2c-ab32-9dfa5be1522a.json diff --git a/docs/outstanding-issues-inbox/7b5351a4-f139-4c45-bf18-8a13b620d834.json b/docs/outstanding-issues-inbox/applied/7b5351a4-f139-4c45-bf18-8a13b620d834.json similarity index 100% rename from docs/outstanding-issues-inbox/7b5351a4-f139-4c45-bf18-8a13b620d834.json rename to docs/outstanding-issues-inbox/applied/7b5351a4-f139-4c45-bf18-8a13b620d834.json diff --git a/docs/outstanding-issues-inbox/91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json b/docs/outstanding-issues-inbox/applied/91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json similarity index 100% rename from docs/outstanding-issues-inbox/91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json rename to docs/outstanding-issues-inbox/applied/91517e43-e8e9-4fe4-a23d-7a8a7dc9553c.json diff --git a/docs/outstanding-issues-inbox/92708603-cb8b-4630-8dc0-b3aedf1e8dde.json b/docs/outstanding-issues-inbox/applied/92708603-cb8b-4630-8dc0-b3aedf1e8dde.json similarity index 100% rename from docs/outstanding-issues-inbox/92708603-cb8b-4630-8dc0-b3aedf1e8dde.json rename to docs/outstanding-issues-inbox/applied/92708603-cb8b-4630-8dc0-b3aedf1e8dde.json diff --git a/docs/outstanding-issues-inbox/b0662870-5af2-4013-9898-e3ef56020acf.json b/docs/outstanding-issues-inbox/applied/b0662870-5af2-4013-9898-e3ef56020acf.json similarity index 100% rename from docs/outstanding-issues-inbox/b0662870-5af2-4013-9898-e3ef56020acf.json rename to docs/outstanding-issues-inbox/applied/b0662870-5af2-4013-9898-e3ef56020acf.json diff --git a/docs/outstanding-issues-inbox/b0e14314-8066-44b1-9134-17e4bc6f0d12.json b/docs/outstanding-issues-inbox/applied/b0e14314-8066-44b1-9134-17e4bc6f0d12.json similarity index 100% rename from docs/outstanding-issues-inbox/b0e14314-8066-44b1-9134-17e4bc6f0d12.json rename to docs/outstanding-issues-inbox/applied/b0e14314-8066-44b1-9134-17e4bc6f0d12.json diff --git a/docs/outstanding-issues-inbox/bc284aef-c833-44ee-8b87-c054b4b41559.json b/docs/outstanding-issues-inbox/applied/bc284aef-c833-44ee-8b87-c054b4b41559.json similarity index 100% rename from docs/outstanding-issues-inbox/bc284aef-c833-44ee-8b87-c054b4b41559.json rename to docs/outstanding-issues-inbox/applied/bc284aef-c833-44ee-8b87-c054b4b41559.json diff --git a/docs/outstanding-issues-inbox/c9aed1b4-cba9-43ea-9054-22856e929d20.json b/docs/outstanding-issues-inbox/applied/c9aed1b4-cba9-43ea-9054-22856e929d20.json similarity index 100% rename from docs/outstanding-issues-inbox/c9aed1b4-cba9-43ea-9054-22856e929d20.json rename to docs/outstanding-issues-inbox/applied/c9aed1b4-cba9-43ea-9054-22856e929d20.json diff --git a/docs/outstanding-issues-inbox/d7678153-b6d7-4571-8f46-48f4a59ca47a.json b/docs/outstanding-issues-inbox/applied/d7678153-b6d7-4571-8f46-48f4a59ca47a.json similarity index 100% rename from docs/outstanding-issues-inbox/d7678153-b6d7-4571-8f46-48f4a59ca47a.json rename to docs/outstanding-issues-inbox/applied/d7678153-b6d7-4571-8f46-48f4a59ca47a.json diff --git a/docs/outstanding-issues-inbox/df98fa18-944a-4669-ac12-83cea502f1ee.json b/docs/outstanding-issues-inbox/applied/df98fa18-944a-4669-ac12-83cea502f1ee.json similarity index 100% rename from docs/outstanding-issues-inbox/df98fa18-944a-4669-ac12-83cea502f1ee.json rename to docs/outstanding-issues-inbox/applied/df98fa18-944a-4669-ac12-83cea502f1ee.json diff --git a/docs/outstanding-issues-inbox/e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json b/docs/outstanding-issues-inbox/applied/e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json similarity index 100% rename from docs/outstanding-issues-inbox/e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json rename to docs/outstanding-issues-inbox/applied/e08a84e9-e919-4544-9e0e-0047bbd5e6a2.json diff --git a/docs/outstanding-issues-inbox/e914e120-58ce-42c0-a286-e9a134989246.json b/docs/outstanding-issues-inbox/applied/e914e120-58ce-42c0-a286-e9a134989246.json similarity index 100% rename from docs/outstanding-issues-inbox/e914e120-58ce-42c0-a286-e9a134989246.json rename to docs/outstanding-issues-inbox/applied/e914e120-58ce-42c0-a286-e9a134989246.json diff --git a/docs/outstanding-issues-inbox/e9b59bb8-6de5-4041-a086-c6d01bae8593.json b/docs/outstanding-issues-inbox/applied/e9b59bb8-6de5-4041-a086-c6d01bae8593.json similarity index 100% rename from docs/outstanding-issues-inbox/e9b59bb8-6de5-4041-a086-c6d01bae8593.json rename to docs/outstanding-issues-inbox/applied/e9b59bb8-6de5-4041-a086-c6d01bae8593.json diff --git a/docs/outstanding-issues-inbox/eed86710-2875-44cf-80bf-8a79dc8fe069.json b/docs/outstanding-issues-inbox/applied/eed86710-2875-44cf-80bf-8a79dc8fe069.json similarity index 100% rename from docs/outstanding-issues-inbox/eed86710-2875-44cf-80bf-8a79dc8fe069.json rename to docs/outstanding-issues-inbox/applied/eed86710-2875-44cf-80bf-8a79dc8fe069.json diff --git a/docs/outstanding-issues-inbox/f1ce20e3-cf02-40e2-a370-bf0047f686d0.json b/docs/outstanding-issues-inbox/applied/f1ce20e3-cf02-40e2-a370-bf0047f686d0.json similarity index 100% rename from docs/outstanding-issues-inbox/f1ce20e3-cf02-40e2-a370-bf0047f686d0.json rename to docs/outstanding-issues-inbox/applied/f1ce20e3-cf02-40e2-a370-bf0047f686d0.json diff --git a/docs/outstanding-issues-inbox/f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json b/docs/outstanding-issues-inbox/applied/f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json similarity index 100% rename from docs/outstanding-issues-inbox/f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json rename to docs/outstanding-issues-inbox/applied/f2e5b2bc-8d0d-4b8c-86a6-a93dfa6cdc7e.json diff --git a/docs/outstanding-issues-inbox/f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json b/docs/outstanding-issues-inbox/applied/f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json similarity index 100% rename from docs/outstanding-issues-inbox/f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json rename to docs/outstanding-issues-inbox/applied/f4f9f0cd-7579-4f7e-8beb-6c30ee1fc5cb.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index af63bab857..61539011ec 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -85,7 +85,6 @@ removed after current-main verification; it is not missing recommended work. | #100 | P2 | rec | Verified incremental answer delivery: Phase 1 shipped; a route-level danger-suppression test and provider-gated Phase 2 remain | REVIEW 2026-09-25 (offline audit of current main; no provider access): Phase 1 is on by default, so 'has no incremental verified delivery' is obsolete. Remaining: (1) one offline route-level test (tests/answer-stream-preview-order.test.ts has no danger-level case; suppression is tested only at unit level in answer-incremental-delivery.test.ts); (2) the provider-gated Phase 2. PRIOR DETAIL: UPDATE 2026-09-02 (offline repo read, a chromium browser run, and a review correction; no provider access). Supersedes the 2026-08-21 note on three points. (1) BOTH flags default ON, not off: src/lib/env.ts:225-228 declares RAG_INCREMENTAL_EVIDENCE_PREVIEW with .default('true'), and src/lib/client-env.ts:18-22 returns value !== 'false', so an unset NEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDER renders the rail. The .env.example:158 line is commented because unset means ON. docs/verified-answer-incremental-delivery-design.md records Phase 1 shipped and enabled by default on 2026-08-27. (2) The browser proof the row asked for already exists and was RUN: tests/answer-progress-ui-smoke.spec.ts:623 'the sources arrive during the wait and hand over to the answer's own rail' and :685 'the arriving sources are paced apart, and are simply present when motion is suppressed', both chromium, result '2 passed (12.4s)'. That spec does not match tests/ui-*.spec.ts, which is why earlier ui-* searches missed it; it is named explicitly in playwright.config.ts productionSpecPattern and testMatch, so it runs in verify:ui and the full release matrix. The open question 'whether the render path is actually exercised by a UI journey' is answered yes. (3) Offline companion coverage exists: tests/answer-evidence-preview.dom.test.tsx:46-53 pins the client gate truth table in both directions. REMAINING SCOPE, both OFFLINE and neither provider-backed: (a) a mocked pipeline/route test asserting the danger-level source-governance suppression at src/lib/answer-preview.ts:40 emits zero preview units through the real route, not only through the unit-level buildEvidencePreviewUnit calls at tests/answer-incremental-delivery.test.ts:187,194 - tests/answer-stream-preview-order.test.ts already drives the /api/answer stream route with @/lib/rag/rag, @/lib/public-api-access and @/lib/supabase/admin vi.mock'd, so no provider is needed; docs/verified-answer-incremental-delivery-design.md places this exact fixture in Phase 0 and states that phase is provider-free. An earlier version of this update called it provider-backed, which was wrong in the direction that matters - it would have parked an offline clinical-safety regression check behind approval and spend (caught in review on PR #2545). (b) No browser assertion of the false rollback, which is inlined at build time per src/lib/client-env.ts:16 and is arguably right to leave at unit level. A stale comment at src/components/clinical-dashboard/answer-status.tsx claiming the preview is 'off by default' was corrected in the same change. Phase 2 acceptance remains unbuilt and provider-gated. | repo read and chromium browser run on main 45a3dcac 2026-09-02; review correction on PR #2545 verified against docs/verified-answer-incremental-delivery-design.md Phase 0 and tests/answer-stream-preview-order.test.ts; tests/answer-progress-ui-smoke.spec.ts:623,685; src/lib/client-env.ts:18-22; src/lib/env.ts:225-228 | 2026-07-30 | | #2AB2NJ | P3 | task | Owner decision: enable RAG_TELEMETRY_EXTENDED (verification_latency_ms projection) in production once a dashboard consumer exists | UPDATE 2026-09-26 (corrects the earlier update): the #GCB0DV timing probe has run (#T9PRB9), but it cannot answer this row. /api/answer's Server-Timing header has no verification stage (src/lib/server-timing.ts answerServerTimingEntries), and verification_latency_ms is recorded only while RAG_TELEMETRY_EXTENDED is on, so repeating the probe will never show whether verification latency matters. The owner decision to leave the flag off stands. Measuring verification needs one of two things: this flag switched on (a Railway production change that needs the owner's approval), or a verification stage added to Server-Timing first. PRIOR DETAIL: OWNER DECISION 2026-09-26 (Josh, 'all as recommended'): leave RAG_TELEMETRY_EXTENDED off. Revisit after the #GCB0DV timing probe shows whether verification latency matters. PRIOR DETAIL: PR #2056 persisted verification_latency_ms behind RAG_TELEMETRY_EXTENDED (typed, default false) with canary-absence tests. Enabling it is a Railway production env change on the Database service (explicit approval; rollback = set false), gated on a dashboard consumer existing. Do not enable speculatively; do not add unproven fields. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #C2D9JF | P3 | issue | Adversarial divergence (S5 harness pin): scope-other-owner-document — abstains in substance but the review fallback still cites in-scope evidence | OWNER DECISION 2026-09-26 (Josh, decision card 'Keep as is'): keep current behaviour; the pinned divergence stays by design. Reason, found offline 2026-09-26: this case runs through the extractiveNeedsReviewFallback branch in src/lib/rag/rag.ts, the same branch that produces the deliberate source-backed review stub (#J8SJQ9). In the adversarial harness 14 of 24 cases share the identical shape (grounded false, confidence unsupported, one review_only citation), and the pipeline cannot tell an irrelevant pointer from a relevant-but-ungenerated one, so stripping citations on unsupported abstentions would also strip the useful pointer from real stubs such as antipsychotic metabolic monitoring. The citation is already labelled review_only, and owner scope is enforced at retrieval, so other-owner content is never read. Only revisit with a relevance test at the fallback (new heuristic on a protected surface; needs a canary pair once the canary is green again). Do not delete the harness pin. | 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 | | #6GW95D | P3 | task | Fleet-wide worktree inventory and safe orphan cleanup remain, but the Dev Drive capacity emergency is resolved | UPDATE 2026-08-23 (inventory evidence retained; cleanup remains open and deferred indefinitely). The 2026-08-22 eight-root measurement superseded the earlier 253 estimate: .claude/worktrees, D:/Worktrees, .codex/worktrees, .gemini/antigravity/worktrees, .copilot/repos/copilot-worktrees, .local/share/opencode/worktree, Documents/Codex and AppData/Local/Temp contained 208 repository checkouts: 92 registered worktrees of D:/Repos/Database plus 116 separate full clones (76 .codex, 26 .copilot, 13 Documents/Codex, 1 Temp), with 54 carrying node_modules. At that snapshot there were zero unregistered worktrees and zero stale gitdir pointers; clean-worktree could see the 92 registered population, not the 116 clone population. Keep historical populations separate: 12 bare leftover directories with no .git or source were removed (11 .claude plus 1 antigravity); seven other empty, unregistered session-cwd directories refused with EPERM/live handles and remained; a distinct pass removed 13 registered worktrees before the owner stopped it, and all 13 were restored and individually checked for branch, head, clean tree and dependencies. Capacity was not an emergency (D: 80 GB total, 53 GB free). UPDATE 2026-08-23: fleet-sweep tooling is now permanently report-only. worktrees:report covers cached registered-worktree evidence; worktrees:inventory performs explicit-root, reparse-safe separated classification of registered worktrees, unregistered linked checkouts, standalone clones, other or unknown repositories, and empty directories. Both report zero mutation counts; remove/apply are unreachable. For worktree tooling, verify:preflight invokes only worktrees:report -- --self-test rather than inspecting the fleet. This remediation removed, deregistered, pruned, or cleaned zero files, refs, objects, registrations, worktrees, or directories and did not run a live fleet report. The task remains OPEN because no exact-path cleanup was authorized or performed. Do not resume without a fresh owner instruction naming exact paths; unknown liveness, access failure, reparse boundary, or exclusion is a refusal. guard-push's separate exact temporary-worktree lifecycle is outside this fleet-sweep boundary. PARKED 2026-09-18: the fleet tooling is permanently report-only by design and the checkouts live on the owner's Windows workstation, which no cloud session can reach. This row's own text already says not to resume without a fresh owner instruction naming exact paths. TO UNBLOCK: the owner runs the inventory locally and names exact paths for removal; nothing else changes this row. | Sessions 2026-08-22 and 2026-08-23; GitHub issue #2270 Part A; report-only fleet tooling remediation | 2026-08-18 | | #VKH7N1 | P3 | rec | eval-canary neuroleptic-side-effect-escalation exceeded its 20 s latency SLO once | REVIEW 2026-09-25 (offline audit of current main; no provider access): No newly approved paid dispatch is needed. The weekly scheduled canary has run at least five times since 2026-08-18, and npm run eval:trend -- --case neuroleptic-side-effect-escalation reads downloaded artifacts offline (retention 30 days, so the original run is gone). Next action: one GitHub read of the retained artifacts (owner go-ahead, no spend); close if there is no repeat. PRIOR DETAIL: Run 32111839806 (canary pair 32100681177 -> 32111839806, otherwise green): strong generation took 20.2 s on neuroleptic-side-effect-escalation, flagged as a non-blocking latency advisory. Answer was still grounded via the source-backed extractive fallback. Watch on subsequent canaries; escalate only if it repeats or worsens. PARKED 2026-09-18: closing this needs a provider-backed eval-canary dispatch (roughly 1-2 US dollars) which is never automatic and needs explicit owner approval, and there is nothing to fix until a second sighting shows it is not a one-off. TO UNBLOCK: approve one canary pair and compare the neuroleptic-side-effect-escalation latency against the 20 s advisory. | docs/rag-improvement/HANDOVER.md packet table row S2, canary pair 32100681177 -> 32111839806 | 2026-08-18 | | #J8SJQ9 | P1 | issue | Antipsychotic metabolic monitoring returns a source-backed stub instead of a written answer, and the eval case must not be relaxed to hide it | UPDATE 2026-10-04 (read-only GitHub Actions log read of eval-canary runs 34773883150, 35528299276, 36218356438, 36264242906, 36339819587; no provider access): the 'failing for about five weeks on clozapine-monitoring, clozapine-monitoring-paraphrase and nocc-requirements' statement is STALE. Those three cases, metabolic-screening and direct-document-lookup-nocc PASSED in the answer-quality subset in every run 2026-09-13..27. The answer-targeting eval that originally graded them is dispatch-only and opt-in (answer_quality_eval=true; calls OpenAI), so the weekly schedule never runs it by design; it is not skipped because the quality step fails. What actually failed for clozapine 2026-09-13..26 was clozapine-fbc-acronym-threshold and clozapine-anc-withhold-threshold: source-backed review fallback (grounded=false, guideline passages shown, no written answer; numeric grounding failures 0 every run), i.e. conservative degradation, not a wrong figure. Cause: evidence-relevance rejected the NMHS clozapine red-range table row; fixed by PR #3134 (b602173fb, 2026-09-27; real code fix, eval cases not relaxed); both passed on run 36339819587. Still individually failing on 2026-09-27 (none unsafe on report data; answer texts unread because the artifact download was blocked): clozapine-missed-dose-table (expected visual evidence missing), assessment-documentation (MHSP.AssessmentDocumentation.pdf not matched; unrelated FSH pressure-injury and radiotherapy citations), admission-discharge-comparison and admission-discharge-coverage-paraphrase (MHSP.AdmissionCommunityPts.pdf missing from top 5). Fixes there touch a protected RAG surface and need an owner-approved canary pair. The metabolic-monitoring stub (quality-antipsychotic-metabolic-monitoring) needs an approved dispatched targeting run to re-measure. | canary run 32589154243; src/lib/rag/rag-eval-cases.ts quality-antipsychotic-metabolic-monitoring; ledger #NPQJKP | 2026-08-22 | @@ -115,48 +114,35 @@ removed after current-main verification; it is not missing recommended work. | #TNYENC | P3 | issue | site_content_registry_baseline on live holds only the 281 frozen baselines, so a record published after 2026-08-24 has no baseline for SQL field merging | LIVE CHECK 2026-10-21 (docs/audit/2026-10-21-database-performance-evidence.md): one release (the freeze) and zero publications since 2026-08-24, so no record lacks a baseline yet. Conditions unchanged: do #81A3YJ first and ship the forward migration only when #HTZPQ8 is about to publish post-freeze records. | Session 2026-09-16 repairing the epoch-zero freeze regression from PR #2814 | 2026-09-16 | | #61GQYY | P2 | task | Formulation: 41 handover sources stay held, each with a named blocker | Publishers resolved for CCI, Phoenix Australia, and Monash in PR #2880; 34 sources held with named blockers. | PR #2880 review | 2026-09-16 | | #BPPRG2 | P3 | rec | Sentry source maps remain unuploaded, so production stack frames stay minified | REVIEW 2026-09-25 (offline audit of current main; no provider access): Still a deliberate parked operator decision (docs/error-tracking.md). Now also holds the source-map and Railway-variables note moved from #YBJVM7, which is unblocked since PR #2871 merged. PRIOR DETAIL: SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT are all absent from the production Database service (confirmed 2026-09-16 via Railway list-variables), so next.config.ts skips withSentryConfig entirely and no maps are uploaded. docs/error-tracking.md already records this as a deliberate operator decision, so this is a standing choice rather than a defect. The fragmentation it caused is now fixed independently: the fingerprint normalises build-volatile chunk filenames and mangled identifiers (tests/error-tracking-fingerprint-stability.test.ts). Supplying the three values would still make frames readable, at the cost of build-time provider coupling; the token needs only project release/sourcemap scope. Revisit if a production fault cannot be diagnosed from route, exception type and the stable frame tail alone. PARKED 2026-09-18: docs/error-tracking.md already records leaving the source maps unuploaded as a deliberate operator decision, and supplying the three values is a provider-backed change to production secrets. The fragmentation this caused was fixed independently by the fingerprint normalisation. TO UNBLOCK: only worth revisiting if a production fault cannot be diagnosed from route, exception type and the stable frame tail; then set SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT on the Database service. | 2026-09-16 Sentry/Railway investigation | 2026-09-16 | -| #TN512M | P1 | issue | Three systems correctly detect production failures and report to nobody: the live monitor, Sentry, and CI on main | UPDATE 2026-09-26: CI ON MAIN CONFIRMED END TO END. The owner confirmed at 10:56Z that main-failure issue #3092 (a real red main, opened 09:45Z) reached his GitHub app Inbox through the owner assignment from PR #3017; #T82ND3 closed on that evidence. The live monitor, eval-canary, live-drift and ingestion-autopilot use the same assign-the-owner path, so the channel is proven, but none of those has yet been seen to fire since #3017. Sentry alert routing is still unaddressed. Close once Sentry routes to the owner (or the owner decides it need not). PRIOR DETAIL: UPDATE 2026-09-25: OWNER DECISION on the channel: phone notifications through the GitHub mobile app. Shipped in PR #3017: live-domain-monitor, CI on main, eval-canary, live-drift and ingestion-autopilot now assign the repository owner (best-effort, the alert still opens if assignment is refused) on open and on update, so every opening and later comment notifies the owner. Close condition unchanged: one real or deliberately triggered failure must be seen to reach the owner's phone. Sentry alert routing is still unaddressed (Sentry MCP was unreachable). PRIOR DETAIL: REVIEW 2026-09-25 (offline audit of current main; no provider access): The close condition now has a negative answer: during the 27-hour production deploy stall on 2026-09-21/22, monitor issue #2973 was opened and updated and nobody acted on it. GitHub-issue routing is proven to fire but not to reach a person. Next action: choose a channel that reaches the owner (phone push, Slack or page). Fact fix: live-monitor routing shipped in #2877 (28dabe0c3), not #2884 (which covered CI on main and eval). The stall's own root cause is tracked separately (inbox add of 2026-09-22); CI on main is #T82ND3. PRIOR DETAIL: TWO OF THE THREE SYSTEMS NOW REPORT, as of 2026-09-18. (1) LIVE MONITOR: live-domain-monitor.yml had no failure handling at all — a grep for issue, notify or any conditional step returned nothing, which is why a real catalogue outage went unreported for about eighteen hours. PR #2884 (merged) gave it the eval-canary failure-issue step. (2) SENTRY: PR #2890 (merged) fixed log delivery across Next's bundle split, so application logs actually reach Sentry rather than being dropped at the boundary. (3) CI ON MAIN is tracked as #T82ND3 and also shipped in #2884. WHAT REMAINS: none of the three has been confirmed against a real production failure — all were verified by workflow tests, not by watching one fire. Dedupe was reviewed (label-based find-or-create, so a flake cannot spawn an issue per run) but likewise not observed under load. Close once a genuine outage has produced a notification someone acted on. | Direct reads of live-domain-monitor run history, Sentry issue list, and ledger #T82ND3; session 01XGpedMgoXWK3U3fn2TWTzR, 2026-09-17. | 2026-09-17 | | #CD63JW | P3 | task | Establish why GET /api/documents costs about a second warm, before assuming the exact count is to blame | OBSERVED 2026-09-17 on live psychiatry.tools: GET /api/documents?limit=10 settled at 1.29-1.52 s warm (5.47 s cold), and ?limit=1 at 0.92-0.99 s, against a ~0.63-0.67 s floor for trivial endpoints (/api/health, /api/local-project-id) measured from the same client. So roughly 0.3-0.9 s is the route's own work, and it does not fall away at limit=1. HYPOTHESIS ONLY, NOT EVIDENCE: src/app/api/documents/route.ts selects with { count: 'exact' }, and the response reports pagination.total 2851, so every request also runs an exact count over the owner-scoped filtered set regardless of limit. That is the obvious suspect and it is exactly the kind of inferred claim this repo has had refuted before (ledger #069 found warm p90 175-243 ms and concluded plans are not the multi-second tail), so it must be measured, not assumed. DO NOT switch to an estimated count on this reasoning alone: pagination.total is user-visible and hasMore depends on it. NEXT ACTION: EXPLAIN ANALYZE the list query with and without the exact count, at limit 1 and 10, against the live owner-scoped shape. GATE: provider-backed, needs explicit owner confirmation per AGENTS.md API and provider confirmation boundary. PARKED 2026-09-18: the next action is EXPLAIN ANALYZE against the live owner-scoped query, which is provider-backed and needs explicit owner confirmation. The exact-count hypothesis must not be acted on without that measurement - this repository has already had one inferred latency claim refuted the same way. TO UNBLOCK: approve one EXPLAIN ANALYZE run of the documents list query, with and without the exact count, at limit 1 and 10. | Live latency review session 2026-09-17 | 2026-09-17 | | #CWWH2E | P3 | issue | One search issues 27-45 database round trips, many of them re-fetching what it already loaded in the same request | REVIEW 2026-09-25 (offline audit of current main; no provider access): No hydration changes since the audit. Lines moved: forceRefresh now rag.ts:1142 and rag-cache.ts:1057; per-request caches rag.ts:1116-1118. The row itself values the saving at a fraction of a second, so P3. PRIOR DETAIL: MEASURED BY CODE AUDIT 2026-09-17, not inferred, against HEAD 8427182d8. For POST /api/search mode=differentials, query 'major depressive disorder', anonymous caller, cold cache: floor approx 27 round trips, typical 34-37, worst approx 45. The four parallel retrieval strategies (lexical, embedding-field, index-unit, hybrid) are deliberate and should NOT be collapsed; the cost is in follow-up hydration. FOUR CONCRETE WASTES, each verified in source: (1) loadChunksForSignalMatches (rag-candidate-sources.ts:1345 -> :1362 -> :1393) is a 3-hop serial chain paid TWICE, where attachDocumentContextPackAdmission in the same file at :275-278 already does the identical job in one embedded-join query; 4 serial hops on the critical path where 2 would do. (2) attachPageVisualEvidence (rag-hydration.ts:253-306) has NO cache and runs 3x per search over heavily overlapping document/page sets. (3) cacheIndexingVersion(...,{forceRefresh:true}) runs twice per search (rag.ts:1088 and rag-cache.ts:1057) and deletes its own 5s TTL entry before reading, so the cache is write-only on the search path; the rag-cache.ts:1057 one is justified as a mid-request staleness guard, the rag.ts:1088 one is not. (4) loadChunksForMemoryCards ignores the request-scoped ChunkLoadCache entirely and runs twice (lexical then vector keys). Also: the typo-correction recursion at rag.ts:1245 threads cacheContext but re-creates memoryCardCache/chunkLoadCache/documentRankingMetadataCache at rag.ts:1062-1064, so an out_of_corpus query pays ~2x the whole search with every hydration cache cold. REFUTED HYPOTHESIS, recorded so it is not re-investigated: the versioned _v2/_v3 retrieval RPCs are NOT missing. All twelve preferred names were cross-checked against supabase/schema.sql and all 248 migration files and every one resolves with matching argument names; drift-allowlist.json has zero functions entries, so a missing one would fail check:drift. Also corrected: callVersionedRetrievalRpc costs 2x not 3x for an anonymous caller (it returns after the legacy call when owner_filter is the public sentinel, rag-candidate-sources.ts:587-594). PRIORITY RATIONALE: P2 not P1 because this is second-order. The dominant cost was read_site_content_public_records at up to 92s; this whole item is worth a fraction of a second and is only worth doing after the catalogue migration lands. NEXT: items 1 and 2 above are the highest value. ALL of these live in src/lib/rag/** which is a RAG-ranking protected surface: flag to owner BEFORE editing, RAG impact line required, owner-merge, and item 1 needs an eval canary because reproducing the three filters (documents.status=indexed, the owner-scope ladder, and the index_generation_id check at :1418) imperfectly would silently drop candidates and change ranking. STOP: do not remove the legacy rungs of callVersionedRetrievalRpc (zero cost while v2 exists, and they are the fail-soft path), and do not skip the coverage-gate block for broad_summary (its results re-enter the candidate pool at rag.ts:1555 and removing it changes ranking). | Code audit by rag-retrieval-reviewer subagent, session 01XGpedMgoXWK3U3fn2TWTzR, 2026-09-17; offline classifier probe confirming single query variant and broad_summary class. | 2026-09-17 | | #B2DC4F | P2 | task | Live browser-side latency (LCP, hydration, long tasks) has never been measured from a real client | GAP, not a defect. The 2026-09-17 latency review measured server timing, payload sizes and offline CPU, but produced NO browser-side numbers: an attempt to drive Chromium at live psychiatry.tools from the cloud session failed because the session proxy re-terminates TLS and Chromium had no NSS store for its CA, and pinning the CA was correctly refused as TLS weakening. So the repo's own docs/performance.md targets (CLS < 0.05, LCP < 2.5 s, INP < 200 ms) are currently unverified against production, and the heaviest pages (/sources/search at 3.2 MB, /differentials/diagnoses at 1.35 MB) have no measured hydration or long-task cost. THIS MATTERS MOST for judging whether the catalogue-payload work is worth doing: without it, any pagination decision is being made on payload size alone. NEXT ACTION: run the measurement from a machine with direct network access (a local Playwright run against https://psychiatry.tools, or the existing Web-Vitals workflow), capturing LCP, CLS, INP, long-task time and transfer per route for at least /, /documents/search, /sources/search and /differentials/diagnoses. STOP: ledger #017 closed with 'do not re-dispatch live Web-Vitals just to re-measure CLS' - this is a payload-driven LCP/hydration question, not that CLS re-measurement, so keep the scope to the heavy pages. | Live latency review session 2026-09-17 | 2026-09-17 | | #PVZB5E | P3 | issue | First request after an idle period costs seconds; production runs a single replica | REVIEW 2026-09-25 (offline audit of current main; no provider access): The catalogue part of cold start is now pre-warmed (closed #WFSMMT), so the /api/search/universal cold figure is stale; /api/documents (5.47 s) and page cold starts are unaffected. The row cites a live healthcheckTimeout of 60, but railway.app.json has declared 300 since c55be8414 (2026-09-14): either the live service ignores the file or the reads disagree. PRIOR DETAIL: MEASURED 2026-09-17 on live psychiatry.tools, read-only. First call to a route was consistently far slower than the warm call that followed: /api/documents?limit=10 took 5.47 s then settled at 1.29-1.52 s; /api/search/universal?q=lithium took 2.35 s then 0.75 s; /sources/search 1.77 s then 1.40 s. So a clinician opening the app between patients, after it has been quiet, can wait several seconds on the first action. CONFIG, read via the Railway MCP on 2026-09-17: production service Database in project Database (5deaad0b-675a-4c13-978e-5ca2b5b877f9) runs multiRegionConfig asia-southeast1-eqsg3a with numReplicas 1, healthcheckPath /api/health/ready, healthcheckTimeout 60. CAUSE NOT ESTABLISHED: a single replica means no warm instance to absorb the first hit, but this could equally be per-route module initialisation in a Node production build (src/data alone is 4.9 MB of JSON, and src/lib/sources/repository-providers.ts imports therapies-source.json at 2.6 MB plus dsm-clinical-content.json at 448 KB), or container sleep. Further production reads in that session were blocked, so nothing below the service config was checked. NEXT ACTION: read the deploy/runtime settings for sleep behaviour and the boot timeline in Railway logs, and separately time a cold Node start of the production build locally to split module init from container start. Only then decide between a second replica, a warmer, or deferring the heavy JSON imports. GATE: any replica or runtime change is a production mutation and needs explicit owner authorisation per AGENTS.md Railway project safety. PARKED 2026-09-18: the cause is still not established, and both halves of the next action are gated - reading Railway deploy settings and boot logs is provider-backed, and any replica or warmer change is a production mutation needing explicit owner authorisation. TO UNBLOCK: approve the Railway runtime read, and separately time a cold Node start of the production build to split module initialisation from container start before choosing between a second replica, a warmer, or deferring the heavy JSON imports. | Live latency review session 2026-09-17 | 2026-09-17 | -| #E6142T | P2 | issue | The PWA update notice may overlap page content on non-answer pages, and the services search mode has no mode-noun stop list | UPDATE 2026-09-25 (PR C, rebuilt on main after PR #3019): Part 1 (PWA update notice overlap) is CLOSED by owner ruling 2026-09-25: leave the notice where it is. Part 2 (services mode nouns in modeSearchWords) REMAINS OPEN and was deliberately not shipped, because on main it has no observable effect: modeSearchWords in src/lib/smart-search-intent.ts is read only by smartSearchContentTerms, which is called only for calculators, factsheets and dictionary (calculator-filters.ts, factsheets-data.ts, dictionary.ts). The services ranker (src/lib/service-ranker.ts) and universal search call smartSearchExpansions, which returns curated rule terms only and never reads modeSearchWords, so adding service/services/pathway(s)/program/referral there changes no services result. It becomes meaningful only if services search starts consuming smartSearchContentTerms (e.g. a required-term filter, which owner decision 18 excluded from PR C). NEXT: close as won't-fix, or keep it parked until such a consumer exists. | PR #2860 working notes; code read of src/app/globals.css:3698-3712 and src/lib/smart-search-intent.ts at origin/main 6f0a3d444; session 01B5auxdz8JsfzSnDezMWz1n, 2026-09-17. | 2026-09-17 | | #YBJVM7 | P2 | task | The Sentry Unhandled server request error groups still have no identified cause; PR #2853 makes them diagnosable but does not name the fault | REVIEW 2026-09-25 (offline audit of current main; no provider access): Unblocked: PR #2871 merged 2026-09-18 (4f1994eb5) and the app:///_next route recovery is on main (error-tracking.ts). 'Waits on #2871' and 'do not set those Railway variables until #2871 lands' are stale; the 24-hour Sentry re-read is now due (provider read). The source-map and variables paragraph now lives in #BPPRG2. PRIOR DETAIL: NEXT ACTION, once PR #2853 has deployed and roughly 24h of events have accumulated: re-read Sentry project clinibase-xz/javascript-nextjs and name the faulting code. Expect the 20 open groups sharing the title Unhandled server request error to collapse to one or two with counts that finally mean something. Use the restored capture mechanism (handled vs onunhandledrejection) to tell a crash from a reported error, and the route recovered into the fingerprint to locate it. WHY IT WAS NOT DIAGNOSABLE BEFORE, measured 2026-09-17: 853 of 857 error events in the preceding 30 days carried no route_path tag, so they took the undefined fingerprint branch in privacySafeErrorEvent and Sentry regrouped them on minified frames that change every build; and the scrubber dropped the exception mechanism, so all 857 events reported error.handled 1 regardless of origin. PR #2853 fixed both. NOT BLOCKING but makes frames readable: source-map upload stays inert until an operator sets SENTRY_AUTH_TOKEN, SENTRY_ORG (clinibase-xz) and SENTRY_PROJECT (javascript-nextjs) on the Railway Database service. PR #2853 declared the matching Dockerfile build ARGs, without which those variables would have been a silent no-op. ALREADY EXCLUDED, do not re-investigate: JAVASCRIPT-NEXTJS-2D (4 events, /differentials/diagnoses/[slug], route_type render) is a reader disconnecting during a streaming page render, stack entirely Next internals, not worth acting on. DO NOT RE-FOLLOW the original supplied analysis, which blamed AbortErrors escaping four API routes: that was checked against the code and is wrong, because jsonError returns a Response so onRequestError never fires. One incidental observation worth a glance: every sampled event reported user.geo SG, Singapore. CORRECTED 2026-09-18: the figures above were first recorded as 849 of 853, which was wrong -- 853 was the untagged count, not the population. Re-read from Sentry as two separate aggregates rather than one derived figure: event.type:error returns 857 and event.type:error !has:route_path returns 853. STATUS CHANGE, also 2026-09-18: PR #2853 was squash-merged at the commit before its final push, so the fixes this row depends on are NOT all on main. Three adversarial reviews found four defects in it, and PR #2871 restores them. Two matter to this row. First, main recovers the route by matching only the /app/.next spelling, so setting the three Sentry build variables would make the SDK DistDirRewriteFrames integration rewrite every frame to app:///_next and collapse the whole application into one unrouted bucket -- worse than the splintering being fixed. DO NOT set those Railway variables until #2871 lands. Second, route-group directories such as (search-app) are kept in the recovered pattern where captureRequestError own tag omits them, so a page fault still splits into two groups. The NEXT ACTION above therefore waits on #2871 deploying, not #2853. | 2026-09-17 Sentry triage session; PR #2853 | 2026-09-17 | | #GCB0DV | P2 | issue | Answer mode re-confirmed slow on the live site by the owner, and still nothing measures it | UPDATE 2026-09-26: the owner-approved timing probe has now run. Do not run it again. The result is recorded in #T9PRB9: for 'What FBC threshold should stop clozapine?', search took 9.2 s of 11.9 s on the server (database lookups 4.2 s plus re-ranking 4.1 s), the rate-limit check took 1.4 s, and generation recorded 0.0 s. So neither branch below applies as written: the first lever is search and re-ranking, not generation (#231/#100) or delivery (#016). Next action is #T9PRB9's: check why generation recorded 0.0 s, then repeat with 3-5 queries before tuning. PRIOR DETAIL: OWNER APPROVED 2026-09-26 (Josh, 'all as recommended'): one run of 'node scripts/probe-answer-timing.mjs --allow-provider' (a few cents of OpenAI credit). It cannot run from a Claude cloud session: the egress proxy refuses psychiatry.tools (CONNECT 403, checked 2026-09-26), so it must run from the owner's computer in Perth, which is also the measurement that matters. If generation dominates, the work is #231 and #100 Phase 2; if first byte dominates, it is delivery and #016. PRIOR DETAIL: owner reported 2026-09-18 15-45 s to something readable on every question. PRs #2849/#2855 fixed only the catalogue read path, not /api/answer. Production is not stale; catalogue latency is fixed. Last figures on file: retrieval ~1 s fast / ~6.7 s hybrid, generation ~19 s (#231); delivery is structurally uncached (layout headers()/cookies(), page connection(), no CDN, sw.js network-only navigations); app declared in Railway Singapore with Supabase in Sydney (145-340 ms round trip), live region unverified. Do not raise answerRouteBudgetMs and do not weaken a clinical gate. | Owner report 2026-09-18; four agent investigations of the answer path, telemetry, wait UI and hosting | 2026-09-18 | | #GQR7DE | P3 | issue | site_content_canonical_json is recursive plpgsql, so release activation will slow the same way the read path did once a release exceeds a couple of thousand records | CURVE RECORDED 2026-10-21 (docs/audit/2026-10-21-database-performance-evidence.md), local PostgreSQL 16, per canonicalisation pass: 843 records 1.3 s, 1,686 5.2 s, 3,372 8.2 s, 6,744 14.7 s; live is roughly 1.5 times slower and activation runs at least two passes. service_role statement timeout is 15 min, so the caller's request timeout is the ceiling (about 20 to 25 s at 3,000 records). Re-measure before a release passes about 2,000 records. Still do not rewrite the function. | docs/audit/2026-09-16-catalogue-read-latency.md; Claude Code session 2026-09-16 (session_01GJHMbC4s2S2n8aChAxVF1D), catalogue read-latency investigation | 2026-09-16 | | #QVVS6W | P2 | issue | Disaster recovery has never been rehearsed at the data layer — only the schema replay has been tested | UPDATE 2026-10-18: a step-by-step, timed, owner-approved drill (restore to a new project, Storage copy, count comparison, cost and stop conditions) is drafted in docs/operator-rehearsal-plan.md step 2; it has not run. PRIOR DETAIL: Run one real restore-to-a-new-project drill and record the wall-clock time and what was lost. Why: docs/disaster-recovery-runbook.md states plainly that only the schema layer was rehearsed (2026-07-07, ~19s local container replay) and that the platform restore plus golden retrieval eval has never been executed — so 'we have backups' is currently an untested claim on the live clinical corpus. Distinct from #1K6T35, which is the accepted ~24h recovery-point decision, not whether a restore works at all. Owner: user + operator (provider-backed). Confidence: high — the runbook says so itself. Depends on: #1K6T35 context. | session 2026-09-20 /ledger sweep — nine-agent repo maturity review | 2026-09-20 | | #HYSWAF | P1 | issue | Railway deploys every main push without waiting for the required checks, so a red commit can be serving psychiatry.tools | OWNER DECISION 2026-09-25: turn Railway 'wait for CI' ON, but only once it cannot freeze deploys. Order: (1) fix or remove from the main-push gate the Firefox/WebKit release-browser-matrix failures (#9Z197J), or confirm Railway can wait on pr-required alone; (2) the owner then enables it on the app and worker services. Until then the essential pre-merge checks remain the safeguard. The owner still has to read the actual setting in the Railway dashboard. PRIOR DETAIL: REVIEW 2026-09-25 (offline audit of current main; no provider access): Kept at P1 deliberately. Still unverified from the repo (the setting is not in railway.app.json); docs/deployment-architecture.md recorded source.checkSuites false on 2026-09-22 for a preview instance, not production. Counter-argument considered: pr-required already gates merges. But #T82ND3 shows CI on main red after merge on six of eight pushes, which is exactly the case this row covers. Trade-off to weigh: Wait-for-CI makes every deploy wait on the full run and flaky jobs, and pairs with the 2026-09-21 deploy stall. PRIOR DETAIL: Configure a Railway deployment gate on the app and worker services so they wait for pr-required to succeed on the main push. Why: the deploy and the post-merge CI run are two independent reactions to the same push, so 'CI passed' and 'what is live is tested' are different claims. Context: repo maturity review 2026-09-19; inferred from docs/deployment-architecture.md §6 (auto-deploy from main, rollback is a manual redeploy after the fact), NOT from a direct read of Railway settings. Owner: user (Railway dashboard, not code). Confidence: medium — the absence of a gate is inferred from docs; verify in the dashboard first. Depends on: nothing. | session 2026-09-20 /ledger sweep — nine-agent repo maturity review | 2026-09-20 | -| #QKW3KN | P2 | task | rag-extractive-answer.ts is now the largest file in the repo at 5268 lines and is not on the monoliths backlog | Add it to docs/maturity-backlog-workorders.md section X3 as a fourth tracked monolith and extract the isSourceBound* predicate cluster first. Why: it grew ~30% in under three weeks (4042 lines at the 2026-09-02 audit) while all three tracked monoliths shrank, so the one file getting worse is the one nothing is watching. It also carries 10 narrowly-scoped isSourceBound* query predicates, a pattern that adds a bespoke function per answer-quality bug rather than generalising. Owner: assistant. Confidence: high - line counts verified 2026-09-20. Depends on: nothing. NOTE CORRECTED 2026-09-20 after a Codex review on PR #2930 caught the original wording overstating the contract. RAG-ranking surface, and the two requirements are NOT the same trigger: the flag-it-first rule applies to EVERY edit here, including a rename or a comment (AGENTS.md 'RAG ranking protection' -> 'Flag it'), but the live eval-canary before/after pair is required only when retrieval, ranking or ordering BEHAVIOUR changes ('Canary for behaviour'). The extraction proposed above is behaviour-preserving, so on its own it needs the flag and not the canary. This distinction is load-bearing rather than pedantic: canary dispatches are provider-backed (~USD 1-2) and need the owner's explicit approval each time, so stating the canary as unconditional would either stall this work behind an approval it does not need or spend money to prove nothing moved. If an extraction does turn out to alter ordering, the canary requirement applies in full and the clamped-score and comparator-key contracts still hold. | session 2026-09-20 /ledger sweep — nine-agent repo maturity review; note corrected after Codex review on PR #2930 | 2026-09-20 | | #PM71Z1 | P2 | task | Three blocked hostnames stop any cloud session running Firefox/WebKit or reading a CI trace, so browser failures can only be reasoned about from logs | Add cdn.playwright.dev, playwright.download.prss.microsoft.com and *.blob.core.windows.net to the Claude Cloud environment's egress allowlist; owner action in the environment settings, no repo change. THE THREE, each verified by a real request, not inferred: the first two are the ONLY mirrors in playwright-core 1.63.0's PLAYWRIGHT_CDN_MIRRORS (the old *.azureedge.net entries were removed in this version, so allowlisting those achieves nothing) and both return 403 request blocked; the third serves GitHub Actions artifacts, and an artifact download redirects there and returns CONNECT tunnel failed 403, which is why a retained Playwright trace cannot be fetched. ALSO CHECKED AND DEAD: ftp/archive/download.mozilla.org, snapcraft, flathub, the mozillateam PPA, codeload, and the npm @playwright/browser-firefox package (a 15KB stub that downloads from the same blocked CDN). A stock apt/tarball Firefox is NOT a substitute at any version - Playwright launches with -juggler-pipe and waits for "Juggler listening to the pipe", which only its own patched build emits - and there is no channel: firefox and no PLAYWRIGHT_FIREFOX_EXECUTABLE_PATH; the repo's PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH is its own invention and Chromium-only. Why: This is the constraint that shaped the whole 2026-09-20 triage. Four Firefox failures were fixed without a single Firefox run, and the dark-mode one was nearly written up as a broken app for every Firefox and Safari user before a cross-check refuted it; the two that remain are stuck precisely because the trace that would settle them is behind the third hostname. Context: Also worth knowing separately - the preinstalled Chromium is 141 (revision 1194) where playwright-core 1.63.0 pins revision 1243 / Chrome 153, so even local Chromium proof is twelve majors behind CI. Owner: Josh - environment settings. Confidence: high; every claim above was checked by running the request or reading node_modules/playwright-core. Depends on: nothing. | session 2026-09-20; agent investigation of browser provisioning; proxy README /root/.ccr/README.md | 2026-09-20 | -| #05WXHX | P1 | issue | Medication and therapy records carry zero source links while their footers tell the clinician to check the linked source | UPDATE 2026-10-10: PR #3398 proposed WA-first sources in src/data/medication-source-links.json: wa-health-clozapine-guideline-2024 for clozapine, and the Australian Prescriber lithium article plus its correction for lithium-carbonate-ir-sr. They render nothing until the owner adopts and signs off those register records. Valproate, other anticonvulsants and QTc-risk drugs still have no proposal. UPDATE 2026-09-25: step 1 shipped in PR #3017. The medication footer no longer promises a linked source (it points to current Australian product information or the local guideline); the therapy footer points to the sources named under Source & review status. OWNER DECISION: default source per medication is the TGA Product Information, plus WA guidelines where they exist; engineering proposes, owner confirms, high-risk medicines first (clozapine, lithium, valproate and other anticonvulsants, QTc/overdose-risk drugs). Real links still need the data-model change described below. PRIOR DETAIL: /medications/[slug] has 0 anchors in
on all four tabs; /therapy-compass/[slug] the same. Footer on every tab: 'verify every dose and interaction against the linked source'. acamprosate states Max 1998 mg/day, a serum creatinine >120 micromol/L contraindication, Half-life 13-28.4 h and an unattributed EFFICACY: MODERATE tile; the only provenance is one prose sentence on tab 4 below the fold. Root cause: medication-records.ts:118-126 derives governance from a free-text src section with no URL or document id. /dictionary and /factsheets do this correctly. Fixing properly is a database migration plus clinical governance. | session 2026-10-10 /ledger sweep, PR #3398 (merged 2026-10-09 as 6f9203d55) | 2026-09-20 | +| #05WXHX | P1 | issue | Medication and therapy records carry zero source links while their footers tell the clinician to check the linked source | UPDATE 2026-10-22: second high-risk batch proposed (PR from thread 'Medication source links'). src/data/medication-source-links.json now maps 74 of 330 medicines (was 26): other anticonvulsants, gabapentinoids, oral antipsychotics, QTc-prolonging antiemetics, TCAs and other overdose-risk antidepressants, benzodiazepines and Z-drugs, buprenorphine, S8 stimulants, ketamine, propranolol and clonidine, each to its TGA PI search link, plus the WA Monitored Medicines Prescribing Code and ScriptCheckWA for stimulants, alprazolam, buprenorphine, ketamine and gabapentinoids. Also captured WA High Risk Medication Management Policy MP 0131/20 v2.0 (candidate, unmapped). Nothing renders until the owner signs. OWNER DECISION 2026-10-22: the live TGA PI search is the PI source, signed once per medicine with no fixed version (docs/decisions/2026-10-22-tga-pi-live-search-source.md), because www.ebs.tga.gov.au robots.txt disallows all automated retrieval. All 71 TGA PI records are now candidates under dateModel live_product_information. Next action: owner signs the records and the mappings (sign-off batch in the project files), then a separate adoption decision. UPDATE 2026-10-10: PR #3398 proposed WA-first sources in src/data/medication-source-links.json: wa-health-clozapine-guideline-2024 for clozapine, and the Australian Prescriber lithium article plus its correction for lithium-carbonate-ir-sr. They render nothing until the owner adopts and signs off those register records. Valproate, other anticonvulsants and QTc-risk drugs still have no proposal. UPDATE 2026-09-25: step 1 shipped in PR #3017. The medication footer no longer promises a linked source (it points to current Australian product information or the local guideline); the therapy footer points to the sources named under Source & review status. OWNER DECISION: default source per medication is the TGA Product Information, plus WA guidelines where they exist; engineering proposes, owner confirms, high-risk medicines first (clozapine, lithium, valproate and other anticonvulsants, QTc/overdose-risk drugs). Real links still need the data-model change described below. PRIOR DETAIL: /medications/[slug] has 0 anchors in
on all four tabs; /therapy-compass/[slug] the same. Footer on every tab: 'verify every dose and interaction against the linked source'. acamprosate states Max 1998 mg/day, a serum creatinine >120 micromol/L contraindication, Half-life 13-28.4 h and an unattributed EFFICACY: MODERATE tile; the only provenance is one prose sentence on tab 4 below the fold. Root cause: medication-records.ts:118-126 derives governance from a free-text src section with no URL or document id. /dictionary and /factsheets do this correctly. Fixing properly is a database migration plus clinical governance. | session 2026-10-10 /ledger sweep, PR #3398 (merged 2026-10-09 as 6f9203d55) | 2026-09-20 | | #ZPHK2F | P1 | issue | Owner design decision: first publication versus adoption for the site catalogue (blocks #HTZPQ8) | OWNER DECISION 2026-09-25: first publication, not adoption. The 222 owner-scoped service rows and 54 forms go public through the administrator first-publication flow in owner-approved batches, each batch clinically signed off (the 17 newest service records need sign-off before they can publish). Do not relax the reconciliation triage to make adoption pass. Next action: design and build the first-publication path; it touches site_content tables, so any migration follows the Supabase merge-is-deploy rule. PRIOR DETAIL: REVIEW 2026-09-25 (offline audit of current main; no provider access): The 'smaller, separate' part is fixed: a27fc99a9 adds a not_comparable verdict with an honest message and seven tests, and docs/site-content-publication-handover.md section 2.5 warns that steps 2-3 cannot complete. What remains is the owner decision between first publication and adoption. PRIOR DETAIL: WHAT HAPPENS. scripts/build-site-content-reconciliation-plan.ts, run against a fresh operator export (843 records, activeReleaseId e4a1dd29, initialized=false, expected=actual=843), reports: owner rows 222, logical groups 222, published groups 843, groups not published 3, TRIAGE SNAPSHOTS 0, needs owner review 222, adoptable 0, identical duplicates 0. It then refuses, telling the operator that 222 groups diverge from the published snapshot and that choosing between them is a clinical judgement. WHY THAT MESSAGE IS MISLEADING. Nothing diverged. buildRegistryReconciliationReport can only mark a group adoptable when canonicalCandidate returns a candidate, and canonicalCandidate delegates to reconcileCanonicalPublicSiteContent, which requires ALL FOUR of publicationState='published', renderedByPublicSite=true, explicitlyReconciled=true and rowOwnerId=null. Measured on live: clinical_registry_records has 222 service rows and 54 form rows, ALL with a non-null owner_id; site_content_publications has 0 rows; site_content_public_records has 0 rows. So no candidate can satisfy those conditions in this state, no triage snapshot is ever built, and every group falls through to divergent_requires_administrator_review by construction. The count 222-of-222 is an artefact of the state, not a measurement of drift. WHY IT MATTERS. The handover (docs/site-content-publication-handover.md) tells the owner the order is export, then reconciliation plan, then the administrator records it. Step 2 cannot produce output, so the owner would follow the documented order and hit a refusal that blames the corpus. Worse, the refusal is the kind that invites someone to 'fix' it by relaxing the triage, which would mark owner-scoped rows canonical for a clinical publication - exactly the judgement the script exists to refuse. WHAT IS ACTUALLY NEEDED, and it is a design decision rather than a bug fix. The reconciliation/adoption path is built for rows that are ALREADY public and whose identity is settled; it adopts them into the control plane. This corpus has never published anything through the control plane at all - the epoch-zero freeze lives only in site_content_release_records. So the question to settle before any more tooling is whether initial adoption is the right mechanism here, or whether these 222 owner-scoped service rows need a first-publication path that makes them public and unowned through the administrator flow. Do NOT resolve it by loosening reconcileCanonicalPublicSiteContent. SMALLER, SEPARATE: the planner should say what it actually found. A refusal that reports 'triage snapshots 0' alongside 'needs owner review 222' should state that the two together mean nothing was comparable, not that 222 things disagreed. | live read 2026-09-21 of clinical_registry_records, site_content_publications and site_content_public_records, plus a run of scripts/build-site-content-reconciliation-plan.ts against the real export | 2026-09-20 | | #WR6FAW | P2 | issue | verify:phone-chrome and verify:ui cannot go green in a cloud sandbox: three failures are the unpinned Chromium, not the code | Established 2026-09-20 by running the three failures against a clean origin/main worktree (aef181f55) with the same environment, and reading the saved failure snapshots. They reproduce identically on main, so they are a property of the sandbox, not of any branch. ROOT CAUSE, found rather than guessed: the only installable browser here is /opt/pw-browsers/chromium = chromium-1194 = Chromium 141.0.7390.37, because cdn.playwright.dev is 403 under the egress policy and the revision Playwright 1.63.0 pins is 1243 / Chromium 153. (1) tests/ui-smoke.spec.ts "document frame stretches the canvas owner at phone and desktop" and "document viewer puts the PDF preview first with pinned evidence after it on mobile" both fail with getByTestId(pdf-canvas-scroll).locator(canvas) "element(s) not found". The error-context snapshot shows the viewer in its error state with the text "this[#re].getOrInsertComputed is not a function" and a Retry preview button. pdfjs-dist@6.3.289 calls Map.prototype.getOrInsertComputed, a V8 addition Chromium 141 does not have, so pdf.js throws during load and no canvas is ever created. The demo PDFs and cover images are all present; nothing is missing from the fixture. (2) tests/ui-pwa.spec.ts "has a browser-valid manifest, installable icons, and a root worker" fails with installability error "in-incognito" — Chromium refusing because every Playwright BrowserContext is off-the-record. Every other assertion in that test (manifest URL, manifest contents, all icon probes, service-worker scope/state/controller) passes first. CONSEQUENCE FOR AGENTS: three failures out of ~798 passing is the FLOOR for a chromium browser gate in this environment, on any branch. Do not read it as a branch signal, and do not "fix" a test to make it pass here. CI runs the pinned browser and the Production UI chromium shards are green on recent main (7936c3f9, cfb5ed90, and shard 3 on aef181f55). NOT ESTABLISHED: per-test CI granularity, because gh run view --log is Forbidden here (results-receiver.actions.githubusercontent.com); only job-level green was read. That Chromium 153 stops reporting in-incognito is an inference from CI being green, not a direct observation. TO UNBLOCK: either allowlist cdn.playwright.dev so the pinned revision installs, or teach the browser gate to recognise this known trio and report them as environment-floor rather than failures. | Claude Code session 2026-09-20 (session_01VE1C4eJidBwMdfHV4nUJgL); reproduced on a clean origin/main worktree with the same runner and environment | 2026-09-20 | -| #MSJT12 | P1 | issue | Production deploys stopped landing for 27 hours on 2026-09-21; root cause unknown and GitHub-issue monitor routing still did not drive action | Second occurrence of the Railway deploy-rollback failure mode first seen 2026-09-11..09-14 (24 consecutive rollbacks, documented in scripts/check-live-deployment-freshness.mjs and docs/deployment-architecture.md 'Readiness: what /api/health/ready may and may not ask'). Measured 2026-09-22 from GitHub deployment statuses: the Database service in the production environment last landed a deploy at 2026-09-21T05:59Z (3a43f808d) and did not land another until 2026-09-22T09:15Z (76bf29ffa, PR #2978). In between, four production deployments were created for ef257fa5c, f44ae5397, 56b123509 and 373046b76 and every one went in_progress -> inactive without ever reaching success. All four built cleanly in the Docker image build workflow, live-drift was green on the 2026-09-21 migrations, and Railway built PR preview environments normally throughout, so the integration, the image and the database are all ruled out. That leaves Railway-side deploy/start/healthcheck rejection, which is the documented mechanism: each healthcheck attempt gets ~10s against /api/health/ready and a container that cannot answer inside the window is discarded and rolled back, leaving the previous deploy serving. Confirming which of the four failed and why needs the Railway deployment logs for the production environment, which no agent session has had access to. Production recovered on its own and no fix was applied, so the trigger is unknown and can recur. Separately confirmed NOT a fault: nine main commits in the same window got a staging deploy but no production deploy at all - all nine touched no path matched by watchPatterns in railway.app.json, which is correct filtering. Alerting clarification (rewrites a false claim in the original draft of this request): live-domain-monitor.yml already has monitor-routing (issues: write + actions/github-script) as of #2884 / ledger #TN512M, and it DID fire during this stall — pinned issue #2973 ('Live domain monitor failing', label live-monitor-failure) was opened 2026-09-21T12:40Z, updated on later red runs including the deployment-freshness failure at 2026-09-22T06:47Z, and closed on the next green run at 2026-09-22T12:41Z. So 'nothing routes a red monitor run' is false. What remains unverified for human delivery: despite #2973 being open and repeatedly commented for ~24 hours of the stall, the gap was still found only because a human inspected GitHub deployment statuses, not because anyone acted on the pinned issue. That matches the #TN512M residual ('Close once a genuine outage has produced a notification someone acted on') and the workflow comment that owner failure emails arrive unread. Durable next actions: (1) pull Railway production deployment logs for the four inactive deploys and record the reject reason; (2) treat this stall as the missing #TN512M real-outage evidence that GitHub-issue routing alone is insufficient delivery, and decide a human-reachable path (page/Slack/owner push) before adding more probes. Pairs with #HYSWAF (Railway deploys every main push without waiting for required checks) and #TN512M. | Claude session 2026-09-22; GitHub deployment statuses for Database/production; live-domain-monitor runs 35639421619/35696377977/35728663173 and issue #2973 routing evidence; Codex review on PR #2982 | 2026-09-22 | +| #MSJT12 | P1 | issue | Production deploys stopped landing for 27 hours on 2026-09-21; likely cause Railway Wait for CI skipping deploys while main CI was red | UPDATE 2026-10-21 (read-only GitHub deployment statuses and Actions run times; no Railway access): LIKELY CAUSE FOUND, and it is not a healthcheck rollback. Each of the four stuck production deploys went from in_progress to inactive within 5 to 6 seconds of that commit's CI workflow run on main concluding failure: ef257fa5c CI failed 10:12:32Z, deploy inactive 10:12:37Z; f44ae5397 10:31:12Z / 10:31:18Z; 56b123509 16:48:48Z / 16:48:54Z; 373046b76 17:36:52Z / 17:36:58Z. That is Railway's documented Wait for CI behaviour (a failed workflow run skips the deploy at once; docs/deployment-architecture.md). 3a43f808d, which triggered no CI run, deployed normally. 76bf29ffa began deploying at 09:08Z on 2026-09-22, three minutes before its own CI run failed at 09:11Z, which fits a manual deploy or Wait for CI being switched off then. So the stall was most likely Wait for CI enabled on the production service while CI on main was red (release-browser-matrix Firefox/WebKit, Lighthouse and PR required failures). This is inferred from timing only and stays provisional until Railway deployment logs or the setting history confirm it. By 2026-09-27 the setting read source.checkSuites false. The same signature recurs on 2026-10-21: 3b4518fdb went inactive at 07:10:45Z, seven seconds after its Docker image build run failed at 07:10:38Z, so Wait for CI appears to be on again and any red workflow run on a main commit skips the production deploy (handed to the Alert root causes work, #3685). Next action, owner: read the Wait for CI setting on the Railway app and worker services and confirm; then decide per #HYSWAF whether it stays on, which requires main CI to stay green. PRIOR DETAIL (its healthcheck-rollback explanation is superseded by the timing evidence above): Second occurrence of the Railway deploy-rollback failure mode first seen 2026-09-11..09-14 (24 consecutive rollbacks, documented in scripts/check-live-deployment-freshness.mjs and docs/deployment-architecture.md 'Readiness: what /api/health/ready may and may not ask'). Measured 2026-09-22 from GitHub deployment statuses: the Database service in the production environment last landed a deploy at 2026-09-21T05:59Z (3a43f808d) and did not land another until 2026-09-22T09:15Z (76bf29ffa, PR #2978). In between, four production deployments were created for ef257fa5c, f44ae5397, 56b123509 and 373046b76 and every one went in_progress -> inactive without ever reaching success. All four built cleanly in the Docker image build workflow, live-drift was green on the 2026-09-21 migrations, and Railway built PR preview environments normally throughout, so the integration, the image and the database are all ruled out. That leaves Railway-side deploy/start/healthcheck rejection, which is the documented mechanism: each healthcheck attempt gets ~10s against /api/health/ready and a container that cannot answer inside the window is discarded and rolled back, leaving the previous deploy serving. Confirming which of the four failed and why needs the Railway deployment logs for the production environment, which no agent session has had access to. Production recovered on its own and no fix was applied, so the trigger is unknown and can recur. Separately confirmed NOT a fault: nine main commits in the same window got a staging deploy but no production deploy at all - all nine touched no path matched by watchPatterns in railway.app.json, which is correct filtering. Alerting clarification (rewrites a false claim in the original draft of this request): live-domain-monitor.yml already has monitor-routing (issues: write + actions/github-script) as of #2884 / ledger #TN512M, and it DID fire during this stall — pinned issue #2973 ('Live domain monitor failing', label live-monitor-failure) was opened 2026-09-21T12:40Z, updated on later red runs including the deployment-freshness failure at 2026-09-22T06:47Z, and closed on the next green run at 2026-09-22T12:41Z. So 'nothing routes a red monitor run' is false. What remains unverified for human delivery: despite #2973 being open and repeatedly commented for ~24 hours of the stall, the gap was still found only because a human inspected GitHub deployment statuses, not because anyone acted on the pinned issue. That matches the #TN512M residual ('Close once a genuine outage has produced a notification someone acted on') and the workflow comment that owner failure emails arrive unread. Durable next actions: (1) pull Railway production deployment logs for the four inactive deploys and record the reject reason; (2) treat this stall as the missing #TN512M real-outage evidence that GitHub-issue routing alone is insufficient delivery, and decide a human-reachable path (page/Slack/owner push) before adding more probes. Pairs with #HYSWAF (Railway deploys every main push without waiting for required checks) and #TN512M. | Claude session 2026-09-22; GitHub deployment statuses for Database/production; live-domain-monitor runs 35639421619/35696377977/35728663173 and issue #2973 routing evidence; Codex review on PR #2982 | 2026-09-22 | | #F9HZEG | P1 | task | CME and On Call have no two-user staging isolation proof; the cross-tenant harness covers documents/search/answer only (audit F17) | UPDATE 2026-10-18 (GitHub Actions run read reported by the coordinating session; no provider access from this branch): the nightly staging-tenancy.yml workflow shows success, but its harness step actually fails, because continue-on-error applies on schedule runs. Run 39059127896 on 2026-10-17 logged 'GET /api/on-call/services returned 503'. So CME and On Call two-user isolation is still unproven on staging, and stays unproven until staging tracks main or is redeployed to the run's SHA (#057). Next action: deploy one exact candidate to staging and dispatch the workflow from that SHA (a dispatched run fails loudly), per docs/operator-rehearsal-plan.md step 3a. PRIOR DETAIL: UPDATE 2026-10-06: Two-user CME/On Call write probe offline test suite tests/cross-tenant-write-probe.test.ts fully passing (9/9 tests). Owner authorized live staging execution via staging-tenancy.yml workflow dispatch. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | -| #ZZ4RAP | P1 | task | Clinical eval battery misses high-risk scenarios: no hepatic, older-adult, interaction or false-premise cases (audit F14 + F15) | OWNER DECISION 2026-09-25: approved. Engineering drafts the 20 cases (question, key facts a correct answer must contain, facts it must not state, expected source); the owner reviews and corrects them before any are added to the harness. A first draft of all 20 was delivered to the owner on 2026-09-25 as a Word document (not committed: clinical content awaiting review). Verified offline by topic count over src/lib/rag/rag-eval-cases.ts (101 cases): hepatic 0, older adult/elderly 0, drug interaction 0, unsafe/false premise 0, Mental Health Act 1, QTc 2, pregnancy 3, paediatric 2. Owner recommendation (2026-09-25): start with ~20 clinician-reviewed cases (3 pregnancy/breastfeeding, 3 renal/hepatic, 2 older adults, 2 QTc, 2 lithium/clozapine monitoring, 2 overdose, 2 interactions, 2 MHA, 2 false-premise where the right answer corrects the premise); engineering drafts expected key facts + source, owner reviews. Adding golden cases touches the eval harness (RAG-protected surface): flag before editing, and live canary dispatches need approval. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | -| #BFCTST | P2 | task | Source-conflict and jurisdiction behaviour has no deliberate tests; owner to confirm the tier rule (audit F16) | OWNER DECISION 2026-09-25: confirmed the existing tier order (WA validated > Australian national > other Australian state > supplementary, within a relevance band) and asked for two additions: a superseded source is never used as evidence, and a clinically material WA-vs-national disagreement is disclosed with both sources shown. Found 2026-09-25: outdated sources are currently KEPT and shown with a danger-severity OUTDATED warning (src/lib/source-governance.ts), and authority conflict in source-authority-registry.ts means publisher-metadata mismatch, not clinical disagreement. Both additions change retrieval/answer behaviour: flag before editing and run a live canary pair (owner approval, about USD 1-2) around the change. A rule already exists: src/lib/australian-source-priority.ts ranks wa_validated < australian_national < australian_state < supplementary WITHIN a relevance band, and tracks authorityConflictCount. Only 3 eval cases touch conflict/superseded sources. Owner recommendation (2026-09-25): confirm that order, add (a) superseded versions never used as evidence and (b) disclose both sources when WA and national disagree on something clinically material. Next action: owner confirms the rule, then add conflict/currentness/attribution cases. Ranking is RAG-protected: flag before editing and require a canary pair for any ordering change. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | +| #ZZ4RAP | P1 | task | Clinical eval battery misses high-risk scenarios: no hepatic, older-adult, interaction or false-premise cases (audit F14 + F15) | UPDATE 2026-10-21 (answer safety hardening thread, verified offline on main 81ba5aefa): 18 of the 20 cases are wired into answerQualityEvalCases as high-risk- on the owner go-ahead of 2026-10-10, with verbatim evidence pinned by tests/high-risk-eval-cases-draft.test.ts. Two stay out as source_needed: breastfeeding-lithium and hepatic-valproate, because no WA passage for either is held in the repository. Draft expected facts for both were sent to the owner for correction on 2026-10-21 (not approved). Next: owner corrects the drafts and approves a free read-only fetch of the KEMH lithium breastfeeding and CG.MHSP.Valproate passages into a fixture, then the two cases are wired in. PRIOR DETAIL: OWNER DECISION 2026-09-25: approved. Engineering drafts the 20 cases (question, key facts a correct answer must contain, facts it must not state, expected source); the owner reviews and corrects them before any are added to the harness. A first draft of all 20 was delivered to the owner on 2026-09-25 as a Word document (not committed: clinical content awaiting review). Verified offline by topic count over src/lib/rag/rag-eval-cases.ts (101 cases): hepatic 0, older adult/elderly 0, drug interaction 0, unsafe/false premise 0, Mental Health Act 1, QTc 2, pregnancy 3, paediatric 2. Owner recommendation (2026-09-25): start with ~20 clinician-reviewed cases (3 pregnancy/breastfeeding, 3 renal/hepatic, 2 older adults, 2 QTc, 2 lithium/clozapine monitoring, 2 overdose, 2 interactions, 2 MHA, 2 false-premise where the right answer corrects the premise); engineering drafts expected key facts + source, owner reviews. Adding golden cases touches the eval harness (RAG-protected surface): flag before editing, and live canary dispatches need approval. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | +| #BFCTST | P2 | task | Source-conflict and jurisdiction behaviour has no deliberate tests; owner to confirm the tier rule (audit F16) | UPDATE 2026-10-21 (answer safety hardening thread, offline): tier-rule tests added to tests/australian-source-priority.test.ts (WA ahead of national ahead of other states ahead of supplementary at equal relevance, relevance always wins across bands, supplementary padding dropped once two Australian documents suffice). Both owner additions remain unbuilt: (a) outdated sources are only penalised in rag-second-stage.ts and warned about in the sealed src/lib/source-governance.ts, so they can still carry a claim; (b) buildSourceConflictSection (src/lib/rag/source-conflict-section.ts) only compares uploaded_local with australian_public, and uploaded_local retrieval is fail-closed (#9V1TJ5), so a WA versus national public disagreement is never disclosed. Both are answer-behaviour changes: RAG notice, canary pair and hazard reseal needed; plan sent to the owner 2026-10-21. PRIOR DETAIL: OWNER DECISION 2026-09-25: confirmed the existing tier order (WA validated > Australian national > other Australian state > supplementary, within a relevance band) and asked for two additions: a superseded source is never used as evidence, and a clinically material WA-vs-national disagreement is disclosed with both sources shown. Found 2026-09-25: outdated sources are currently KEPT and shown with a danger-severity OUTDATED warning (src/lib/source-governance.ts), and authority conflict in source-authority-registry.ts means publisher-metadata mismatch, not clinical disagreement. Both additions change retrieval/answer behaviour: flag before editing and run a live canary pair (owner approval, about USD 1-2) around the change. A rule already exists: src/lib/australian-source-priority.ts ranks wa_validated < australian_national < australian_state < supplementary WITHIN a relevance band, and tracks authorityConflictCount. Only 3 eval cases touch conflict/superseded sources. Owner recommendation (2026-09-25): confirm that order, add (a) superseded versions never used as evidence and (b) disclose both sources when WA and national disagree on something clinically material. Next action: owner confirms the rule, then add conflict/currentness/attribution cases. Ranking is RAG-protected: flag before editing and require a canary pair for any ordering change. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | | #FVF58M | P2 | task | Table parser fixtures are not adversarial enough; add wrapped/merged/multi-column clinically relational tables (audit F20) | Partly done: PR #2810 added worker/python/test_extract_pdf_assets_table_reading_order.py for the clozapine-class line-major interleaving. The historical table-heavy benchmark used easy ruled tables. Next action: add a handful of harder fixtures (merged cells, wrapped multi-line cells, multi-column threshold/action tables) and require semantic non-inferiority for extractor changes. Text-producer surface: RAG-protected. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | | #2F8K1V | P2 | rec | Extractor/parser/OCR/table-strategy/chunker version is not persisted per document, so a parser defect cannot be traced to affected documents (audit F04) | UPDATE 2026-10-21: documents.metadata.extraction_provenance now also records the chunker versions of the committed chunks and the OCR engine (Tesseract) versions and count of OCR'd pages (worker/extraction-provenance.ts), on top of the reader version, PyMuPDF version and table strategy recorded since PR #3632. npm run extraction:provenance (read-only; needs owner confirmation before a live run) lists documents by reader, chunker or OCR version, and npm run reindex:rollback -- --chunker-version already scopes a rollback. No migration needed. Remaining: documents indexed before these keys existed report 'not recorded' until their next index, and re-extraction by version is still an operator step. Close when the owner accepts that. PRIOR DETAIL: Verified offline: only a coarse indexing_version ('rag-deep-memory-v1') is stored; no extractor/OCR/table-strategy/chunker provenance exists in schema or worker. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | | #MT3PZ9 | P2 | task | Owner decisions for the MHA timeline: Form 1A (s 44) entry, a second start input, and how day-based periods are counted | (1) Form 1A 72-hour examination limit is absent because s 44 was not in the pinned Act text when drafted; s 44 may now be pinned. (2) Limits that run from an event other than making the form (3C, 3B, 1B, 4B, 6D, seclusion, restraint, review windows) were dropped rather than counted from the wrong time; adding them needs a second start-time input. (3) The contract rejects unit days until the owner rules whether within N days means same clock time N days later or end of the Nth day (WA Interpretation Act s 61). Owner rules; then a builder implements with verbatim quotes only. | Session 2026-09-25 WA psychiatry build (PR #3019) | 2026-09-25 | | #J9F1ZM | P3 | rec | Represent relational table facts and require semantic non-inferiority for extraction changes (audit F19) | Words/numbers can be extracted correctly while parameter-threshold-action relationships are wrong. Revisit after the #GJHKYC re-index shows whether the reading-order fix was sufficient. First check what worker/table-facts.ts already produces before designing anything new. Structured-evidence producer: RAG-protected. | Ultimate Audit Master Report 2026-09-25 (owner-supplied .docx), reviewed offline against main 955996146 in session claude/review-assessment-4s1w86; no provider access | 2026-09-25 | -| #R2FNTJ | P3 | rec | CME: curated WA learning-opportunity directory with event freshness and bundle/employer-access checks | Review items F23, F38, D21. Separate provider, programme, event and recorded resource; expire past events, flag cancellations, keep historical pages apart; show 'included in your workshop' or 'available through your employer' before suggesting a purchase. Needs ongoing content upkeep and source-register ownership, so decide who maintains it before building. | Master product review 2026-09-26 (thread: Review master review ideas); cross-checked against main 004ab6301 | 2026-09-26 | -| #JYH1FH | P1 | issue | 1,935 documents display Locally reviewed with no recorded reviewer, and nobody knows if a person marked them | MEASURED 2026-09-25 from the live audit-source-governance --json run (operator-run; this session had no credentials). The report carries clinical_validation_status_counts locally_reviewed 1935, unverified 130 across 2065 clinical governance documents. src/lib/document-filter-model.ts renders locally_reviewed to clinicians as 'Locally reviewed' and src/lib/answer-client-payload.ts treats it as an authority level beside approved, so this is a review claim shown to the people using the system. The same report said reviewer_attribution reviewed_record_count 0 over 3907 records with passed true, because isRecordMarkedReviewed read review_status only and required the exact string 'reviewed'. PR #3028 fixed the detector, so the next live run will examine those 1935 documents for the first time. WHAT THIS ROW IS FOR, and it is not the code fix: nobody has established whether those 1935 were marked locally_reviewed by a person or in bulk by an import. If by import, the badge overstates what happened and the honest repair is to the records rather than to any gate; fixing the detector only makes the question visible. NEXT ACTION, owner: run npm run audit:source-governance -- --json on a machine with credentials and read unattributed_reviewed_record_count; then decide person-vs-import, which is a governance judgement and not an agent decision. Offline code path verified; live consequence unmeasured. | Nine-issue packet follow-through session, 2026-09-25; live audit output pasted by the owner | 2026-09-25 | | #T9PRB9 | P2 | issue | Measured 2026-09-26: answer time is dominated by search (database lookups plus re-ranking), not generation, and generation recorded 0.0 s | This is the measurement #GCB0DV asked for, and it lands outside both branches of that row's decision tree (neither generation, i.e. #231/#100, nor page delivery, i.e. #016). One run of scripts/probe-answer-timing.mjs from the owner's PC in Perth (owner-approved, #GCB0DV), query 'What FBC threshold should stop clozapine?', HTTP 200: client total 13.4 s, server total 11.9 s, network/queue 1.5 s. search 9.2 s (77%) = rpc 4.2 s + rerank 4.1 s + embedding <0.1 s; ratelimit 1.4 s; auth and scope <0.1 s each; generation 0.0 s. So #231/#100 (generation) are NOT the first lever for this query; the search RPCs and the rerank step are, plus an unexpectedly slow rate-limit check. UNRESOLVED: generation 0.0 s means either the answer came from a cache/reuse path or the generation Server-Timing metric is not recorded on that path; check src/app/api/answer/route.ts and src/lib/server-timing.ts wiring before trusting the split. One sample only; repeat with 3-5 queries before tuning. Search/rerank is a RAG-protected surface: flag before editing and canary any ordering change. LEDGER NOTE: #GCB0DV already has an unreconciled update queued (PR #3039), so a second update to it would go stale; after that one is reconciled, update #GCB0DV and #231 to point here. | Owner-approved timing probe 2026-09-26 (thread: Clean up task list) | 2026-09-26 | -| #46VNY9 | P1 | task | Repair the 1,935 'Locally reviewed' labels: owner confirmed 2026-09-26 they came from a bulk import, not a reviewer | UPDATE 2026-10-09: the repair migration supabase/migrations/20260926170000_repair_import_stamped_locally_reviewed.sql merged to main in PR #3111 (2026-09-27). Merging to main applies migrations to the live database, so it should already have run, but live application is NOT verified. Next action, provider-backed so it needs owner approval: confirm the post-merge live-drift run for that commit passed both check:drift and check:migration-history, then read the 1,935 documents' validation basis to confirm the relabel landed. Close this and #JYH1FH only after both checks. PRIOR DETAIL: UPDATE 2026-10-06: SQL migration supabase/migrations/20260926170000_repair_import_stamped_locally_reviewed.sql is written, dry-run verified, and tested offline. Awaits live Supabase execution to update the 1,935 rows. Close this and #JYH1FH once applied. | Owner answer in Claude Code session 2026-09-26 (session_018CR3YcCWjJk2fyzTNYmMi4) | 2026-09-26 | | #8CKX6F | P2 | issue | Youth self-harm and suicide services queries rarely show Lifeline, Suicide Call Back Service, 13YARN or Kids Helpline near the top | Lifeline WA boosted in PR #3157; national crisis lines remain unpinned for generic youth queries. Owner ruling 18 Oct 2026 00:10 AWST: do NOT pin national youth crisis lines (Lifeline WA, Suicide Call Back Service, Kids Helpline, 13YARN) for CAMHS crisis searches yet. Pinning waits for owner approval of the exact list; any pinning must exclude services that are closed, planned, superseded or marked temporarily unavailable, and keep CAMHS Crisis Connect and MHERL first. PR #3617 dropped its unapproved pinning attempt and cancelled its done request. | PR #3157 review | 2026-09-25 | | #25PJFR | P3 | issue | On Call demo preview: 'Something went wrong' on activation once, recovered after Try again (unreproduced) | Review section 2.5 browser report: guest activating the device-local 94-entry example preview saw 'Something went wrong', which cleared on retry. No console or network logs were captured. Reproduce with diagnostics before assigning a cause; not yet a confirmed defect. | Master product review 2026-09-26 (thread: Review master review ideas); cross-checked against main 004ab6301 | 2026-09-26 | | #V5C4QJ | P2 | task | Finish the Railway Caring Contacts clean-up that #P00HDB left open: worker service, SUPABASE_CARING_CONTACTS_* and deploy/australia | Split from #P00HDB, which closed on 2026-09-26 on the owner's check that the production Database service has no CARING_CONTACTS_* variables. #P00HDB's re-scoped detail also asked for three more things that were not confirmed: (1) whether any SUPABASE_CARING_CONTACTS_* variables exist on the production Database service, (2) the same two prefixes on the production worker service, and (3) that no Railway service builds from deploy/australia. The Caring Contacts code is gone (PR #3098), so nothing can use these values any more. The risk is leftover credentials: any database address or secret found is a credential to rotate or revoke, not just delete. NEXT ACTION (owner, in the Railway dashboard, project Database, production): look at the Database and worker services' variables for either prefix, and at each service's source settings for deploy/australia. Delete anything found, then rotate or revoke any credential. Record the result here; a clean result closes this row in one line. | Split from #P00HDB after a Codex review of PR #3112, 2026-09-26 | 2026-09-26 | -| #4JTTQ7 | P2 | task | Post-merge eval-canary compare for the dead-stem RAG commit (661ccbb64) | 34 retrieval/chunking/extraction regexes now match real word forms. Baseline: canary run #105 on 67d961107 (already failing on main, see #J8SJQ9), so compare retrieval metrics (doc/content recall 1.0, per-case rr) rather than pass/fail. Regression: revert 661ccbb64 alone. Also glance at answer grouping and document categories in the app (commit d6dd6f0f9). | Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q | 2026-09-27 | | #H69FNZ | P2 | issue | The search 'rerank' timing is mostly database time, so the 4.1 s blamed on re-ranking in #T9PRB9 is really database round trips | src/lib/rag/rag.ts starts rerankStartedAt at line 1453 and adds the elapsed time at 1484 and 1531, and src/lib/rag/rag-hydration.ts:137 does the same. Those windows include metadata hydration, memory-card hydration and visual-evidence hydration, which are Supabase round trips (Singapore to Sydney). The deterministic second-stage rerank itself is in-process arithmetic, and the semantic reranker is off by default (RAG_SEMANTIC_RERANK_ENABLED=false). So in the #T9PRB9 probe (search 9.2 s = rpc 4.2 s + rerank 4.1 s), nearly all search time is database work. Consequence: #CWWH2E (27 to 45 round trips per search, currently P3) is the first latency lever, not reranking. Also note: the 1.4 s rate-limit figure in #T9PRB9 predates 5c1ac4f87 (2026-09-26, one-round-trip anonymous rate limit), which has not been re-measured live. Next action: split rerank_latency_ms so hydration round trips are timed separately from ranking. This is RAG telemetry on a protected surface: flag before editing and write a RAG impact line (no ordering change expected). Then re-run scripts/probe-answer-timing.mjs from Perth (provider-backed, owner approval) to confirm. | Latency, network, Railway and wiring review 2026-09-27 (Claude Code session claude/repo-latency-network-review-zcqd5c), offline code read against main 7f8312f2c; no provider access | 2026-09-27 | -| #K55VBV | P3 | issue | nltk GHSA-8mgp-746c-j5xp (high) has no patched release; transitive via medspacy-quickumls | This one advisory is the 2 high Dependabot alerts (requirements.txt and requirements-cloud.txt). Affected APIs (TransitionParser, AveragedPerceptron, PerceptronTagger save/load) are not called by the worker. Next: bump when nltk ships a fix. | Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q | 2026-09-27 | -| #HD1C6W | P2 | task | Owner clinical re-review: word-form fix withheld from three sealed hazard-control files | Dead stems inside \b...\b never match: answer-verification.ts:1480 escalat; rag-claim-support.ts:267 escalat, :1108 escalat/initiat/recommend; source-text-sanitizer.ts:48 escalat/contraindicat/prescrib, :61 escalat/prescrib. Edits reverted because these paths are sealed in docs/clinical-hazard-controls.json. Next: owner reviews the one-line changes, then re-apply and run npm run governance:seal-hazard-controls. | Claude session 2026-09-27, branch claude/repository-review-bugs-52tq9q | 2026-09-27 | -| #MAAXAX | P3 | rec | Teaching Assessments: tokenized magic-link or external supervisor access flow | Visiting hospital supervisors frequently lack hospital clinical accounts. Build a tokenized magic-link / secure invite flow so supervisors can complete and sign EPA forms without full accounts. | PR #3302 post-merge audit | 2026-10-06 | -| #WVS32F | P3 | rec | Teaching: organisers have no view of who did not attend (attendance-gap views) | Owner product decision needed (raised in the Teaching Mode polish, PR #3200). Organise shows the register and an attendance download, but nothing lists members with no check-in across sessions. Privacy-sensitive: decide who may see it (organiser only?), over what period, and the honest wording ('no check-in recorded', never 'missed'). Next action: owner decides scope and audience; then design on Organise using existing attendance reads, with personal-practice review before build. | Session 2026-10-02, PR #3200 | 2026-10-02 | -| #ZTDZ4Z | P3 | rec | Teaching: no in-app QR scanner; check-in relies on the phone's own camera app | Owner product decision needed (raised in the Teaching Mode polish, PR #3200). Today attendees scan the projector QR with the phone camera or type the 6-digit code; the Today button was renamed 'Check in with code' so it does not promise a scanner. Next action: owner decides whether an in-app scanner (camera permission, BarcodeDetector or a library, fallback to typed code) is worth building; if yes, design it inside the Today hero action, keep typed-code fallback, add no new route without wiring. | Session 2026-10-02, PR #3200 / #3204 | 2026-10-02 | -| #F3B2XC | P2 | task | Check the live Tall Man drug lettering list against the ACSQHC National Tall Man list | src/lib/medications/tall-man.ts is live on medication search and record pages but was never checked against the official list. Doubtful: citaloPRAM/escitaloPRAM and fluPENtixol/zucloPENthixol capitalise the shared stem so they do not separate the pair, CLONazepam differs from ISMP clonazePAM, and VALproate, midazolAM, temazePAM, oxazePAM need checking. Matching is exact-name only. Needs owner verification. | PR 3538 review, 15 Oct 2026 | 2026-10-15 | +| #MAAXAX | P3 | rec | Teaching Assessments: tokenized magic-link or external supervisor access flow | 21 Oct 2026, Teaching and CME PR: durable store public.teaching_epa_magic_links (migration 20261021190000, drafted with owner approval; merge only after the owner's own yes), server routes /api/teaching/assessments/magic-links and the respond route on the durable store, doctor and supervisor screens labelled as feedback to copy into CLA, not an official RANZCP sign-off. Next: owner merges; then confirm live-drift passes, and keep /teaching/assessments/respond/* and its API open to signed-out visitors when the 1 Nov sign-in gate lands. Follow-ups: retire the old PUT registration route and the process-memory store once nothing uses them; consider a retention purge for completed or expired links. | PR #3302 post-merge audit | 2026-10-06 | | #H38M3Y | P3 | issue | The instruction-budget test timed out once under the full unit suite but passed 36 of 36 when run alone; unconfirmed flake (audit M5-1) | Not reproduced. If it recurs, find the slow step and make it robust; never skip or disable the test. Record the run id and timing on the next occurrence. | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #ZWJCK4 | P2 | issue | PDF extractor can turn prose beneath a table into a table row and rebuild the table markdown from it | Rechecked 17 Oct 2026 against main 99507ebca. The original fault is fixed: PR #3571 made worker/python/extract_pdf_assets.py _recover_table_rows_split admit a recovered line only when each piece fits one column, keep top and bottom strips in order, and tests/pdf-table-extraction.test.ts pins full-width prose being rejected. A leftover was fixed on 17 Oct: a short note under a recovered row (for example 'See note') was glued into that row's first cell; a lone line now joins the row above only when that cell actually wrapped (_continues_wrapped_cell), with tests both ways. Still open, low risk: text laid out in the table's own columns directly under a table (an abbreviation key, or a two-column page) becomes an extra row, and only when a drawing below the table extends the crop over it. Geometry alone cannot tell such a key from a real row. Changes reach search only after a re-index. | PsychSift audit review (16 audit reports) checked against main 4382217, 2026-10-13 | 2026-10-13 | -| #SAKCD9 | P2 | task | Ranking-snapshot date gate will fail around 3 Nov 2026 if the automated snapshot-refresh PR is not merged (audit H5-1) | The snapshot was refreshed to 4 Oct, so the automatic checks pass today. .github/workflows/ranking-snapshot-refresh.yml runs after each weekly Eval Canary on main and opens a refresh PR once the snapshot is 14 days old, reusing the canary artifact with no provider calls. Next: watch for that PR (expected from about 18 Oct) and get it reviewed and merged before the 30-day expiry; it touches a RAG ranking fixture, so follow docs/rag-behaviour/ and the canary rules. Only if no refresh PR appears (canary failing or not running) does a new paid eval, with the owner's explicit approval, become necessary. | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #JVQ1HA | P2 | issue | Precompute GIN search_tsv on site_content_release_records for hybrid retrieval | EVIDENCE 2026-10-21 (docs/audit/2026-10-21-database-performance-evidence.md): live active release is the 843-record freeze and 0 records pass the retrieval filter, so no per-row to_tsvector runs today and the change gains nothing yet. Locally, with all 843 eligible, per-row tsvector costs about 1.5 s per search versus about 12 ms with a stored GIN-indexed column (about 0.5 s at the 276 records planned for first publication). NEXT: ship the stored column, GIN index and RPC change before or with the first approved publication batch under #HTZPQ8. Migration yes, RAG impact line and a live eval-canary before and after pair required (protected retrieval RPC change, even though ranking values should be identical). | session 2026-10-14 performance audit follow-up | 2026-10-14 | | #3AVEFG | P3 | task | Small audit leftovers: merge needs zero human approvals and the 'Database / production' GitHub environment is not a real approval gate (L6-F2, L6-F3); reindex reaper has no protected environment (L6-F4); admin has two home pages (L4G-L1); thin browser tests for Compliance, records, Psychiatry and the MHA clock (L4G-L2); clinical-kb name in 47 files (F-L2-04); install prompt may cover password-reset and privacy pages on first paint (L4A-F2) | Settings changes in GitHub are the owner's. Browser-check L4A-F2 before changing anything. HYSWAF already tracks Railway deploying before checks finish (L6-F1). | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #ASA514 | P2 | task | Arrange Aboriginal governance review for the five held cultural formulation records before any is published | Follow-up to #R8HED2 (closed by PR #3412's hold). first-nations-sewb, cultural-explanatory-model, migration-refugee, racism-discrimination and religion-spirituality have release held in src/data/formulation-concepts.json. All carry Indigenous terms, so the clinical sign-off tool refuses them (scripts/lib/indigenous-content.mjs); each needs review under Aboriginal governance. The records also still read clinical_review_required with no reviewer, so governance review alone does not clear them: keep release held until the owner decides how their review status is completed and explicitly approves republishing (then restore each search-index entry). Changing release or review status is a clinical content change. | Review of PR #3521, 2026-10-13 | 2026-10-13 | @@ -165,7 +151,6 @@ removed after current-main verification; it is not missing recommended work. | #K66YES | P3 | rec | On Call has overlapping homes for numbers (Call vs Contacts) and referrals (Refer vs Referrals), and its menu 'Now' goes to /on-call while 'Who to call now' lives at /on-call/now (audit L4D-01 to L4D-03) | Owner decision on one home per job and the naming, then a single navigation change. Also covers /roster/calendar showing On Call dates under a Roster address (L4E-F3). | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #NBJQD8 | P1 | issue | Medication interaction lexicon: the 28 Sept sign-off is out of date because the drug groupings changed since; alerts still fire on an unapproved version (audit L4C-H1) | Owner action: re-approve the current lexicon through the review sheet. The check only warns, so nothing blocks the stale version meanwhile. | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #HMBEQK | P3 | task | Medicines reference list is live but its code comment still says it awaits the owner's check, and Medication Prescribing and Risk and Safety still show 'review due' (audit L4C-M1, L4C-M2) | Owner check of src/lib/medicines-references.ts wording and the two tools, then update the comment and the review-due chips. The comment states a governance fact, so it is not edited without that check. | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | -| #54XJ7D | P2 | task | Shift-swap approval checks the team rules only in the browser, not on the server (audit L4E-F2) | Needs a database migration and an owner decision between blocking the swap and asking the manager to acknowledge. A migration merged to main reaches the live database within seconds, so schedule the merge inside an approved window. | Audit 2026-10-08, rechecked against main 2026-10-13 | 2026-10-13 | | #54N8ZN | P2 | task | Follow-up to PR 3546: CodeRabbit items held out of the merge | PR #3546 landed; tests/xlsx-sheet-dictionary-projection.test.ts (4/4) verifies per-worksheet shared-string and row/column style dictionary projection within provenance budgets, and tests/admin-pilot-client-accessibility.dom.test.tsx (7/7) verifies native form semantics under dark and forced-colors modes, 320px narrow-viewport stacking, and QR enrollment alt/warning copy. Remaining: manual VoiceOver / NVDA screen-reader announcement check on /admin/pilot. | PR 3546 CodeRabbit review 5545295336, owner decision 2026-10-16 | 2026-10-16 | | #7D8WZ2 | P2 | task | Hostile-document ingestion: run the upload-to-answer end-to-end matrix (follow-up to #F3SGCM) | UPDATE 2026-10-21: tests/hostile-document-real-extractor.test.ts now runs generated hostile PDFs (password-protected, truncated, not-a-PDF, blank page, prompt-injected with forged evidence fences and hidden white text) through upload admission, the REAL Python reader, the real chunker, the evidence ranker and the fenced answer source block, offline (runs in the CI coverage job, which installs PyMuPDF). Still open: the live leg (Storage upload, worker ingestion with embeddings, vector retrieval, generated answer) is not run anywhere. Next action: run it on staging once the staging rebuild (#3113) is done and the owner lifts the re-index freeze, with the owner's spend approval for embeddings and answers. PRIOR DETAIL: Seven-class helper coverage exists in tests/hostile-document-ingestion-matrix.test.ts, but it uses an extraction mock and fabricated search results, so no uploaded hostile document is checked against real ingestion, retrieval and answer paths. Close only when each class runs end to end. | PR #3570 review; tests/hostile-document-ingestion-matrix.test.ts | 2026-10-16 | | #9E87MG | P2 | task | Clinical KB: provision PROXY_AUTH dedicated secret on the PsychSift Railway service (follow-up to #789SD7) | Route validation for PROXY_AUTH exists and fails closed with 503, but docs/supabase-remediation-closeout-notes.md still records PROXY_AUTH as not on Railway by name. The owner must authorise and confirm the variable on the correct PsychSift Railway service in a quiet change window; no agent sets production secrets. | PR #3570 review; docs/supabase-remediation-closeout-notes.md; src/lib/supabase/proxy-auth-crypto.ts | 2026-10-16 | @@ -174,7 +159,6 @@ removed after current-main verification; it is not missing recommended work. | #WWTRM5 | P2 | issue | Doc/instruction drift items left open when #WMGPSG was archived: ledger arrow and Caring Contacts decision | #WMGPSG was archived on 17 Oct with an outcome covering items 3 and 6 and the encoding repair in item 1 only. Still open: (1) docs/outstanding-issues.md:15 corrupted arrow (canonical ledger; fix only through reconciliation). (4) docs/decisions/2026-09-26-remove-ward-flow-and-caring-contacts.md says Caring Contacts was removed but src/lib/caring-contacts/clock.ts is live with MHA, First Nations and On Call importers; add a dated superseding decision, do not delete the file. Dropped on 18 Oct after checking the code: item 2 (.claude/cloud-profile/skills/prompt/references/coding-workflow.md:21 describes continuing same-task work in the supplied checkout, not a pre-hardening worktree rule) and item 5 (tests/admin-renewals-page.dom.test.tsx and tests/admin-renewals.test.ts still assert the 'Not checked with issuers' wording; admin-renewed-sheet separately forbids 'checked'). | PR #3609 review (gitar-bot, chatgpt-codex-connector), 17 Oct 2026 | 2026-10-17 | | #C4Q3T7 | P3 | task | Possible dead code: older calculator mockups (audit M5-2), split from #1WAA0Z | #1WAA0Z was archived on 17 Oct after confirming only the On Call Education, Compliance and Logistics screens are live (audit L4D-05). The older calculator mockups under src/app/mockups (calculators-*) from audit M5-2 were not checked. Delete nothing without npm run check:dead-code-candidate (see docs/agents/dead-code-deletion.md). | PR #3609 review (gitar-bot), 17 Oct 2026 | 2026-10-17 | | #SQ2FG9 | P3 | issue | Add a rights and licence field to the source register | Record publisher licence or permission status per source so public display and AI use can be checked. Finding R-07. | Regulatory readiness audit 2026-10-20 (/mnt/project-files/reviews/2026-10-20-regulatory-launch-readiness.md) | 2026-10-20 | -| #TBTNGB | P2 | issue | Lighthouse budget grades and refreshes from a single sample per route, so slow runners fail unrelated PRs | On 21 Oct 2026 a slow-runner window (~15:00Z) failed Lighthouse on #3749 (server-only) and #3752 (CSS-only); all routes' TBT rose together and #3749 passed on rerun (desktop search 956 ms vs 964 ms baseline). The dispatch refresh (run 39625188079, artifact lighthouse-baseline-refresh-39625188079, main 8c03823) is also one sample: desktop-root 1584 ms vs ~935-955 ms typical, so it was not committed. Proposal: take the median of three graded samples per route in scripts/run-lighthouse-budget.mjs for both grading and --update refresh, keeping tolerances unchanged and the two-confirmation rule for breaches. | Main CI and test reliability thread, 21 Oct 2026 | 2026-10-21 | | #PYWRTX | P3 | task | registered-public-answer-options.ts has no test; its planned tests never landed | Audit 2026-10-20 (DOC-18): src/lib/registered-public-answer-options.ts (the registered public answer, no document filter path) landed on main but no file in tests/ imports it. The 15 Oct evidence inventory listed tests/registered-public-answer-no-filter.test.ts, tests/rag-no-filter-published-original-context.test.ts, tests/rag-nhmrc-delivery.test.ts, tests/answer-section-projector.test.ts and the fixture tests/fixtures/nhmrc-response18-consumer.json, but none was ever committed (the originals depended on a private real capture). Next action: write a synthetic-fixture test for registered-public-answer-options.ts. Answer path: check the RAG protection list before editing. | RAG and ingestion audit 2026-10-20, finding DOC-18; docs/audit/ingestion-rag-2026-10-15/rag-evidence-inventory.json repositoryLandingCorrection | 2026-10-20 | | #8P31MT | P1 | task | Owner GitHub settings from the 20 Oct change control audit: delete the repository copy of SUPABASE_SERVICE_ROLE_KEY, and narrow Grok Bot's token | The CI boot smoke no longer reads any secret (audit CC-05), so the repository copy of SUPABASE_SERVICE_ROLE_KEY can be deleted once the copies in production-secrets and Database / production are confirmed. Grok Bot's personal token should lose Workflows, Administration and Actions write (CC-03). Railway wait-for-CI is #HYSWAF. Report: /mnt/project-files/reviews/2026-10-20-change-control-audit.md (project files, not in the repo). | docs/decisions/2026-10-20-database-prs-merge-by-hand.md | 2026-10-20 | | #XJ3N16 | P2 | issue | Privacy page: complaints, access, automated decision statement (APP 1.7-1.9 from 10 Dec 2026) and overseas disclosure | Wording waits for the privacy adviser's answers (question list 6c in the audit report). Findings R-08, R-20. | Regulatory readiness audit 2026-10-20 (/mnt/project-files/reviews/2026-10-20-regulatory-launch-readiness.md) | 2026-10-20 | @@ -186,6 +170,8 @@ removed after current-main verification; it is not missing recommended work. | #AZXEDC | P2 | issue | Uncached searches are slow: index-units search took 9.2 s on first run versus 0.19 s on repeat, with the same plan | Read-only live evidence 2026-10-21 (docs/audit/2026-10-21-database-performance-evidence.md): the first run read 8,413 blocks (about 66 MB) from outside the 256 MB Postgres buffer cache at roughly 1 ms each; the repeat read none. Database 8.8 GB. The term-overlap branch pulled 6,568 units (3,389 kept) for a three-word query, then fetched each embedding and search_tsv. Over 34 days, only 22 to 55 percent of TOAST page requests on the search tables (embeddings and long text) were served from the buffer cache, versus 99.9 percent for documents. NOT YET PROVEN: how often real searches are uncached, or that more memory fixes it (effective_cache_size is only a planner estimate; two back-to-back runs are not a controlled test). NEXT: read the Supabase dashboard memory and cache-hit charts and repeat the capture after a known idle gap. THEN OWNER DECISION: (a) larger compute size, paid, dashboard only; or (b) bound the term-overlap branch before ranking, a RAG behaviour change needing a live canary pair. | Database performance tuning thread, 2026-10-21 | 2026-10-21 | | #NZ4X41 | P2 | task | Therapy catalogue: 22 of 47 unsourced records now carry NICE references and await sign-off, 25 still have none | PS-062 verified against the 2026-10-18 checkout: 179 therapies remain reviewed and 26 were reset to needs_review under the owner ruling recorded in docs/decisions/2026-10-17-agent-recorded-therapy-and-did-sign-offs-reset.md. The previous completion described all 205 as signed; that outcome is superseded. Governed references are present, but the 26 need genuine owner review through therapy:review. Clinical approval, corpus refresh and loaded-client revocation are not established. (Previously archived 2026-10-17: Populated governed guideline and clinical literature references for the remaining 26 Therapy Compass records and completed clinician sign-off across all 205 Therapy Compass profiles.) | PS-062 supplied merged-PR review; canonical therapies-source.json and reset decision, inspected 2026-10-18 | 2026-10-18 | | #WFYDV6 | P1 | issue | Unwired WA MHA Form 6A/6B print component carries unverified statutory text | Owner decision 17 Oct 2026 21:37 AWST: #WFYDV6 must stay open; PR #3609 archived it without the required sign-off. src/components/forms/wa-mha-form-print.tsx (PR #3538) was reworded on 16 Oct (Form 6B now a report to the Chief Psychiatrist; Non-Statutory Study Layout header), but section lists, the 7-day pre-expiry examination and copy recipients remain unverified and no legal or clinical sign-off is recorded. Nothing imports or renders it; it must stay unwired. Delete it once the 30-day dead-code window passes (after 13 Nov 2026) unless legal and clinical sign-off is obtained first. (Previously archived 2026-10-16: Fixed statutory discrepancies and branding in-place in src/components/forms/wa-mha-form-print.tsx: replaced Form 6B Chief Psychiatrist consent wording with statutory post-order Report to the Chief Psychiatrist wording matching form-register.ts, replaced official WA Department of Health branding with an explicit Non-Statutory Study Layout header and warning banner, and updated tests/wa-mha-form-print.dom.test.tsx (retaining the file per the 30-day dead-code policy). \| Note: Reopened 17 Oct 2026 by owner decision (21:37 AWST): archived by PR #3609 without the required legal and clinical sign-off; tracked again as an open P1 row. The form stays unwired until sign-off.) | PR 3538 review, 15 Oct 2026; owner decision on PR #3609, 17 Oct 2026; reopened in place with the ledger reopen action (PR #3627), replacing duplicate row #Z12CBC | 2026-10-17 | +| #J0AY9D | P2 | issue | Guideline-change re-review covers only the 34 medications in the source link map | PR #3746 makes a medication page and its interactions due for review now when a register source they cite has a confirmed change. It reads src/data/medication-source-links.json, which maps 34 of 330 medications. The other records cite their sources (TGA PI, PBS, DACAS) only as free text, and those sources are not in the register, so no change event can reach them. They still get the 12-month date. Next action: register each medicine's sources, then map them with owner confirmation, high-risk medicines first, alongside #05WXHX. | PR #3746 Codex review 2026-10-22 | 2026-10-22 | +| #7B6MMM | P2 | issue | The WA valproate guideline (CG.MHSP.Valproate.pdf) is not in the live corpus, although an answer-quality eval case expects it | Read-only live query 2026-10-21 (owner-approved free read, answer safety hardening thread): no document in public.documents has a title or file name containing 'valpro' other than the registry JSON records. quality-valproate-pregnancy-contraindication in src/lib/rag/rag-eval-cases.ts lists CG.MHSP.Valproate.pdf as an expected file, and the high-risk case hepatic-valproate (#ZZ4RAP) cannot be sourced without it. The only hepatic valproate passage found was BMJ Best Practice 'Bipolar disorder in adults' p130, whose licence is unconfirmed. Next: owner supplies the WA guideline PDF for ingestion (same path as the CAMHS ADHD guideline, #018); no re-index of existing documents is needed. | Answer safety hardening thread, 2026-10-21, read-only Supabase query | 2026-10-21 | ## Resolved / archive @@ -1018,3 +1004,19 @@ Move resolved rows here with the resolution date and a one-line outcome. Keep th | #VHW8K9 | issue | Clinical KB: FK / unused indexes only with evidence (no batch-drop) | Resolved 2026-10-21 with read-only live evidence (docs/audit/2026-10-21-database-performance-evidence.md): 228 never-scanned non-primary indexes over a 34-day stats window, 220 MB total; the large ones are retrieval or search-health indexes and one is unique. No drop justified; candidate list kept in the evidence doc. Revisit trigram indexes only under the RAG gate. | 2026-10-21 | | #GYR7Q3 | task | Ledger tooling: add a reopen action that moves an archived issue back to the open table with its original ID and ULID | The ledger reopen action landed in PR #3627: an archived durable issue moves back to the open table with its original ID and ULID, with identity, fingerprint and prior-outcome checks. It was used to fold duplicate #Z12CBC back into #WFYDV6. | 2026-10-17 | | #MR9VJK | issue | Pinned raster OCR loses inclusive comparators, exponent and decimal in scanned mathematical notation | Resolved the captured default-off ruled-table OCR regression through bounded source-pixel comparison isolation and raised-position normalization, with source-preserving whole-line conditioning for small-font unit fidelity. The original Unicode assertions are unchanged and now ordinary passing tests. Final targeted correction: 21 tests passed, 94.194 seconds, zero skips/expected failures, including serif/Courier values and powers. Independent actual Courier controls retain both baseline 1 and L. The preceding domain run supplied 117 unchanged passing cases; its Courier failure was corrected, not waived. Strict source alignment, original/input/helper hashes, one OCR call, deadlines, caps and fallback cleanup remain. General clinical-corpus accuracy, raised zero/degree and uncovered/noisy layouts are not certified. No live ingestion/reindex or paid inference was performed. | 2026-10-21 | +| #54XJ7D | task | Shift-swap approval checks the team rules only in the browser, not on the server (audit L4E-F2) | Closed 2026-10-21 in the owner's project review (Current issues register thread), which found it already fixed on main. | 2026-10-21 | +| #TN512M | issue | Three systems correctly detect production failures and report to nobody: the live monitor, Sentry, and CI on main | Closed 2026-10-21. All three detectors now report to a person, and on 21 Oct the owner replaced the separate phone alerts with one daily health summary at 7 am Perth (docs/decisions/2026-10-21-one-daily-health-summary.md, .github/workflows/daily-health-summary.yml). | 2026-10-21 | +| #JYH1FH | issue | 1,935 documents display Locally reviewed with no recorded reviewer, and nobody knows if a person marked them | Answered and repaired: the owner confirmed 2026-09-26 the 1,935 labels came from the bulk import, and the repair (#46VNY9, migration 20260926170000) is verified on live 2026-10-21: 1,935 relabelled to unverified with the WA endorsement basis, 0 import-stamped labels left. \| Note: Closed 2026-10-21 as a duplicate of #46VNY9, which tracks the repair of the same 1,935 Locally reviewed labels after the owner confirmed on 2026-09-26 they came from a bulk import (owner asked to close duplicates, 21 Oct 2026). | 2026-10-21 | +| #VXB8XA | issue | Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one | Fixed on main (verified offline 21 Oct 2026, answer safety hardening thread). cite-mismatched-attribution no longer has a KNOWN_DIVERGENCES entry in tests/rag-adversarial-harness.test.ts, and npm run eval:rag:adversarial:offline passes 25 of 25 on main 81ba5aefa, via PR #3628 (62558e5c7, 18 Oct, document attribution fix), so the case now meets its normative fixture expectation (cites only the claim-bearing chunk). The pin was self-expiring by design, so its removal records the behaviour change. | 2026-10-21 | +| #F3B2XC | task | Check the live Tall Man drug lettering list against the ACSQHC National Tall Man list | Done on main (verified 21 Oct 2026, answer safety hardening thread). src/lib/medications/tall-man.ts was rebuilt from the ACSQHC National Mixed-Case Lettering List (April 2024) in PR #3562 (5319dab78, 16 Oct), pinned by tests/tall-man-lettering.test.ts. All 26 lettered names were re-checked against the Commission PDF (safetyandquality.gov.au national_mixed-case_lettering_list.pdf, Tables 1 and 3) on 21 Oct and every one matches. The doubtful forms in this row (citaloPRAM, fluPENtixol, VALproate, midazolAM, temazePAM) are gone. One local exception remains, cloZAPine (not on the ACSQHC list), which the owner confirmed keeping on 21 Oct 2026 ('Go ahead with all recommendations', project chat). Brand names on the list (Largactil, Lamictal, Pristiq and others) are not lettered because only generic record names are formatted. | 2026-10-21 | +| #4JTTQ7 | task | Post-merge eval-canary compare for the dead-stem RAG commit (661ccbb64) | Closed 2026-10-21 in the owner's project review (Current issues register thread), which found it already fixed on main. | 2026-10-21 | +| #SAKCD9 | task | Ranking-snapshot date gate will fail around 3 Nov 2026 if the automated snapshot-refresh PR is not merged (audit H5-1) | Closed 2026-10-21 in the owner's project review (Current issues register thread), which found it already fixed on main. | 2026-10-21 | +| #ZTDZ4Z | rec | Teaching: no in-app QR scanner; check-in relies on the phone's own camera app | The Today check-in sheet (src/components/teaching/teaching-code-sheet.tsx) already offers "Scan in app" (BarcodeDetector) with the typed code as fallback. iPhone Safari has no BarcodeDetector, so the Teaching and CME PR (21 Oct 2026) hides "Scan in app" there and leaves the phone Camera app and 6-digit code wording, instead of adding a decoding library. | 2026-10-21 | +| #R2FNTJ | rec | CME: curated WA learning-opportunity directory with event freshness and bundle/employer-access checks | Directory already live at /cme/learning (src/data/cme/wa-learning-directory.json). The Teaching and CME PR (21 Oct 2026) adds the cancelled flag and the 'Included in your workshop' or 'Available through your employer' note, and a weekly report-only check (.github/workflows/learning-directory-weekly.yml) per the owner's 21 Oct decision; a person still updates the file by PR. | 2026-10-21 | +| #46VNY9 | task | Repair the 1,935 'Locally reviewed' labels: owner confirmed 2026-09-26 they came from a bulk import, not a reviewer | Closed 2026-10-21 on a read-only live check (owner approved read-only reads, 21 Oct 12:01Z): migration 20260926170000 is recorded applied; exactly 1,935 documents carry validation_status_repair_2026_09, all 1,935 still read unverified with basis wa_document_control_endorsement, 0 import-stamped locally_reviewed documents remain, and 786 locally_reviewed documents remain. The check does not split those by source kind; the repair's selector excluded registry records by design, so they are expected to be registry records plus any genuine reviews since, but that breakdown is not verified. All rows were repaired in one transaction at 2026-09-27T02:35:40Z, 44 s after PR #3111 merged. Query: scripts/operator-verify-locally-reviewed-repair.sql. | 2026-10-21 | +| #K55VBV | issue | nltk GHSA-8mgp-746c-j5xp (high) has no patched release; transitive via medspacy-quickumls | Closed 2026-10-21 in the owner's project review (Current issues register thread), which found it already fixed on main. | 2026-10-21 | +| #QKW3KN | task | rag-extractive-answer.ts is now the largest file in the repo at 5268 lines and is not on the monoliths backlog | Closed 2026-10-21 in the owner's project review (Current issues register thread), which found it already fixed on main. | 2026-10-21 | +| #WVS32F | rec | Teaching: organisers have no view of who did not attend (attendance-gap views) | Already built on main 81ba5ae: the Attendance gaps sheet on Teaching Organise (src/components/teaching/organise-sheets.tsx) lists enrolled doctors with 'no check-ins recorded this term', visible to organisers and admins only (export.attendance, migration 20261016134500). Verified 21 Oct 2026 in the Teaching and CME thread. | 2026-10-21 | +| #HD1C6W | task | Owner clinical re-review: word-form fix withheld from three sealed hazard-control files | Done on main (verified 21 Oct 2026, answer safety hardening thread). The word-form fix for all three sealed hazard-control files landed in PR #3571 (e526f8a4d, 16 Oct) with tests in answer-verification, rag-claim-support and source-text-sanitizer; docs/clinical-hazard-controls.json was then resealed with owner approval on 21 Oct (5714539c5, comment 6313455205), and npm run check:clinical-hazard-controls passes on main 81ba5aefa. A fresh grep finds no bare escalat/contraindicat/prescrib/initiat stems left inside word boundaries in those files. | 2026-10-21 | +| #TBTNGB | issue | Lighthouse budget grades and refreshes from a single sample per route, so slow runners fail unrelated PRs | Resolved 2026-10-22 differently from the row's proposal. The flake was not single-sample noise: desktop / streams behind the (search-app) loading skeleton, and whether the skeleton paints first is a race that splits identical code into a fast group (~930-1060 ms LCP) and a slow group (~1190-1590 ms). The gate already grades a breach on a majority of three samples, so a median of three would not have helped. Removing the skeleton was measured and refuted (simulated LCP 1092-1144 ms vs 811-891 ms with it). The owner chose on 22 Oct 2026 to give desktop-root alone a 700 ms LCP floor (STREAMED_HOME_LCP_FLOOR_MS in scripts/check-lighthouse-budget.mjs); see docs/decisions/2026-10-22-desktop-home-lighthouse-floor.md. | 2026-10-22 | +| #E6142T | issue | The PWA update notice may overlap page content on non-answer pages, and the services search mode has no mode-noun stop list | Closed as won't fix by owner decision 2026-10-21 ('Go ahead with all recommendations', project chat, on the answer safety hardening plan). Part 1 was already closed by owner ruling 2026-09-25. Part 2 (services mode nouns in modeSearchWords) has no observable effect on main because the services ranker and universal search never read modeSearchWords; reopen only if services search starts consuming smartSearchContentTerms. | 2026-10-21 | From 84ba8d4f7be41ca79c23b544cb47c074baf6d177 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 22 Oct 2026 07:54:28 +0000 Subject: [PATCH 2/2] Queue ledger corrections for #MAAXAX and #J0AY9D #MAAXAX's migration PR #3759 has merged, and the medication source map now holds 74 medicines, not 34 (Codex review on #3763). Co-Authored-By: Claude Opus 5.5 (1M context) Claude-Session: https://claude.ai/code/session_01Jchk5iTkeUyPRUoCHyWei6 --- .../62ac6cdf-028a-4d9d-a74b-964bcc0746fe.json | 13 +++++++++++++ .../883a3d51-8ceb-46ad-b3bf-daa9ca609720.json | 12 ++++++++++++ 2 files changed, 25 insertions(+) create mode 100644 docs/outstanding-issues-inbox/62ac6cdf-028a-4d9d-a74b-964bcc0746fe.json create mode 100644 docs/outstanding-issues-inbox/883a3d51-8ceb-46ad-b3bf-daa9ca609720.json diff --git a/docs/outstanding-issues-inbox/62ac6cdf-028a-4d9d-a74b-964bcc0746fe.json b/docs/outstanding-issues-inbox/62ac6cdf-028a-4d9d-a74b-964bcc0746fe.json new file mode 100644 index 0000000000..31a9b6b0e8 --- /dev/null +++ b/docs/outstanding-issues-inbox/62ac6cdf-028a-4d9d-a74b-964bcc0746fe.json @@ -0,0 +1,13 @@ +{ + "version": 2, + "id": "62ac6cdf-028a-4d9d-a74b-964bcc0746fe", + "createdOn": "2026-10-22", + "action": "update", + "payload": { + "id": "#J0AY9D", + "summary": "Guideline-change re-review covers only the 74 medications in the source link map", + "detail": "PR #3746 makes a medication page and its interactions due for review now when a register source they cite has a confirmed change. It reads src/data/medication-source-links.json, which maps 74 of 330 medications (counted 22 Oct 2026). The other records cite their sources (TGA PI, PBS, DACAS) only as free text, and those sources are not in the register, so no change event can reach them. They still get the 12-month date. Next action: register each medicine's sources, then map them with owner confirmation, high-risk medicines first, alongside #05WXHX.", + "baseRowFingerprint": "6179865ec40beecdc008bc4d4a2271d7179bc1f3c85f588b54cf5341ab406e2a", + "targetUlid": "01M5GJWYCWJ0AY9D8CTN94SEXK" + } +} diff --git a/docs/outstanding-issues-inbox/883a3d51-8ceb-46ad-b3bf-daa9ca609720.json b/docs/outstanding-issues-inbox/883a3d51-8ceb-46ad-b3bf-daa9ca609720.json new file mode 100644 index 0000000000..70865930a4 --- /dev/null +++ b/docs/outstanding-issues-inbox/883a3d51-8ceb-46ad-b3bf-daa9ca609720.json @@ -0,0 +1,12 @@ +{ + "version": 2, + "id": "883a3d51-8ceb-46ad-b3bf-daa9ca609720", + "createdOn": "2026-10-22", + "action": "update", + "payload": { + "id": "#MAAXAX", + "detail": "21 Oct 2026, Teaching and CME PR: durable store public.teaching_epa_magic_links (migration 20261021190000), server routes /api/teaching/assessments/magic-links and the respond route on the durable store, doctor and supervisor screens labelled as feedback to copy into CLA, not an official RANZCP sign-off. Merged 22 Oct 2026 as PR #3759 (d01496110). Next: confirm the post-merge live-drift run passed, and keep /teaching/assessments/respond/* and its API open to signed-out visitors when the 1 Nov sign-in gate lands. Follow-ups: retire the old PUT registration route and the process-memory store once nothing uses them; consider a retention purge for completed or expired links.", + "baseRowFingerprint": "1303ee492459d61e97cba536888c59a34322dea7e570649301e9eda33673736b", + "targetUlid": "01M484CAW5MAAXAX35108YZ443" + } +}