Caring Contacts Phase 2B foundation: approved copy changes, shared empty state, overlay commit contract by BigSimmo · Pull Request #2350 · BigSimmo/Database

BigSimmo · 2026-08-24T14:41:09Z

Summary

Caring Contacts Phase 2B, foundation only. Three complete, independently reviewed units. The
clinician screens themselves are not in this PR — they continue on
claude/browser-test-gate-handoff-d5c1db.

The owner's six approved copy and message-policy changes (Task C). Approved 2026-08-24; each
change cites its item number and carries its own covering test. The automated reply to a patient who
texts back drops an unverifiable storage claim and now says who is not reading and that the reply is
automatic; a fictional-contact check refuses an unacknowledged reserved number; a closing message
with no authored body refuses loudly instead of sending nothing; the lead prohibition stops
flagging job titles; and the prohibited-vocabulary scan is extended to interface strings.
ListEmptyState (Task 1). One shared empty state for the four Phase 2B list screens, which
makes "nothing exists yet" and "your filter hid everything" structurally impossible to confuse — a
caseload that looks empty when it is not is the defect it exists to prevent. Not yet consumed by any
screen; the first consumer is the Patients directory on the follow-on branch.
The overlay trigger and its commit contract (Task 3). The 24 overlays are decision surfaces and
none was reachable from a control. The trigger makes them reachable and requires a commit
handler at the type level, so a screen cannot open an overlay it has not wired. No screen renders a
trigger yet, so no new control ships here.

Behaviour change worth reading before merging

WorkspaceOverlays previously closed an overlay and recorded nothing. A deep-linked overlay whose row
records a decision now refuses its action with a stated reason instead. This applies to the 16 rows
with mutatesState: true only — the 8 non-mutating rows keep a fully usable control, because their
actions are exits ("Sign in again", "Back to the plan"), not confirmations. Restricting it to
recording rows was a review finding: the first version refused all 24 and left session-expiry and
offline-banner — both recovery-only, where Escape and the backdrop are deliberately inert — with
no usable control at all.

No database migration. No route added. No change to definitions.ts or the frozen interaction matrix.

Verification

npm run test — Tests 2 failed | 9823 passed | 74 skipped (9899). The two failures are
tests/gate-receipts.test.ts "gate receipts — file modes", both failing inside
chmodSync(..., 0o755). They are environmental: this workstation is a Windows ReFS Dev Drive
with core.fileMode=false and cannot represent a Unix file mode. Verified pre-existing by
running that file alone (Tests 2 failed | 32 passed (34)) and by confirming the diff touches
nothing filesystem-related.
npm run typecheck — clean.
npm run lint — clean.
npm run test:e2e -- tests/ui-caring-contacts-workspace.spec.ts --project=chromium —
32 passed (51.2s), exit 0, zero failures, run against this tip's source state. An earlier
green taken before the review fixes was deliberately discarded and re-taken, because the fixes
changed both which rows render the refusal and what renders at commit time.
npm run verify:pr-local — not run locally; CI's required aggregate covers it.
Every change mutation-proven: the implementation was deliberately broken and the covering test
confirmed red, with the mutation proved present in the tree before the result was believed.

Review

Each of the three units went through an independent review and a scoped re-review. The reviews found
real defects, all fixed: an allowlist that silently permitted commercial phrasing it was meant to
refuse; a fictional-number check matching only the label and not the number; a false test-coverage
attribution in docs/design-system/adoption-manifest.json caused by a component-name collision
(fixed by renaming to ListEmptyState); a missing role="group" on the empty state; the overlay
refusal being applied to rows it should never have reached; a refusal that briefly flashed on confirm;
and a staged commit that was never cleared on Back.

Clinical Governance Preflight

Source-backed claims still require linked source verification before clinical use
No patient-identifiable document workflow was introduced or expanded without explicit governance approval
Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
Service-role keys and private document access remain server-only
Demo/synthetic content remains clearly separated from real clinical sources
Source metadata, review status, and outdated/unknown-source behavior remain conservative
Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

Evidence for the above

Patient-visible wording is PROVISIONAL and not clinically approved. That has been the standing
position of this workspace since Phase 1 and it is unchanged here. The owner approved these six
specific changes on 2026-08-24 as improvements to accuracy; that is not clinical sign-off, and lived
experience and clinical approval remain required before any real use.

No message is sent to any number, real or test. There is no SMS provider, no provider account and
no adapter. validateGovernedMessage has zero production callers — the checks in this PR are the
mechanism a future sender must pass through, not a live guard, and that distinction is recorded rather
than glossed.

Every patient, number and message is synthetic. The reserved fictional numbers are non-connecting.
The new fictional-contact check exists precisely to make replacing them a deliberate act: a caller must
pass an explicit syntheticFictionalContactsAcknowledged flag or the message is refused, so a real
send path cannot inherit a fictional crisis number silently.

One approved item is deliberately NOT implemented. The owner approved adding Lifeline 13 11 14,
conditional on a real crisis number existing — the message sits about nine characters from its
two-segment maximum, so nothing can be added until something is removed. No real number exists, so
implementing it would mean an implementer choosing which sentence to a distressed patient to delete.
Recorded as approved-in-principle and blocked.

No change to Supabase, service-role handling, or document access. No migration, no new
environment variable, no new provider call. The diff touches the sealed src/lib/caring-contacts/
domain, the workspace components and their tests only.

Deployment classification: unchanged. This is a synthetic, non-clinical prototype behind a demo
role switcher; it is not clinical decision support and makes no clinical recommendation.

Notes

Full reasoning lives in the repository, not this description. Every decision taken on the
owner's behalf is numbered and recorded with what it costs if wrong, in
docs/caring-contacts/phase-2b-build-record.md (Rulings 68–90), continuing Phase 2A's numbering.
The plan is docs/superpowers/plans/2026-08-24-caring-contact-phase-2b-screens.md.
Deferred findings are recorded at the end of each task's section in the build record and are
pointed at the final whole-branch review rather than silently dropped.
Two Phase 2A findings surfaced during this work and are queued in
docs/outstanding-issues-inbox/: validateGovernedMessage has no production callers, and the
closing-message refusal is a guard nothing is obliged to call.

Note

Low Risk
Documentation-only: ledgers, handoffs, copy recommendations, and SDD archives. No application, auth, or data-path code in this diff.

Overview
Records that Phase 2A is merged to main (e4cbe8d3a, PR #2279) and retires claude/suicide-contact-mockup-b5aaa0. Handoffs and the continuation prompt now tell sessions to work from origin/main.

Closes Phase 2A verification: browser gate 32 passed on 2026-08-24, condensed-bar pin and dark-colour mutation proofs both discriminate, and deferred findings are queued in docs/outstanding-issues-inbox/. Adds copy-decisions-recommended.md: owner approved 13 copy items (A9 blocked on a real crisis number; A4 wording deferred).

Starts Phase 2B with a build record (Rulings 67–90), a plan pre-flight, and SDD briefs/reports for Task C (approved copy/policy), Task 1 (ListEmptyState), Task 3 (overlay trigger + commit contract), and Task 5 (patients directory). Group 0 is recorded complete; Task 2 cut, Task 4 merged into Task 5.

^{Reviewed by Cursor Bugbot for commit bb03d00. Configure here.}

…browser gate, capture the deferred findings Phase 2A was squash-merged to main as e4cbe8d (#2279) on 2026-08-23, but the handoff, the ledger and the continuation prompt all still named the feature branch as the source of truth and told the next session to build a worktree from it. Corrected in place rather than deleted, because the reasoning about durability and about measuring a moving tree still holds -- and holds harder on main, which far more sessions touch. - Browser gate re-run on main: 32 passed, exit 0, no ECONNRESET. The test that failed on 2026-08-23 (the 1440px condensed-bar pin) ran and passed, so the residual failure was load, not a defect. Also records that :822 was the test's declaration line, never the failing statement -- the dropped connection was in the setup POST at line 672, before any pin assertion ran. - Seven deferred findings captured as immutable issues-inbox requests, so they no longer survive only in the build record. - copy-decisions-recommended.md is new: the copy recommendations existed only in a previous session's conversation and did not survive it. Also corrects the count -- the records said seven items need the owner, the copy review actually raises thirteen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…cord the mutation proofs The entry-point handoff said on line 7 that the branch had never been pushed and in section 4 that it was pushed to origin. Both were true when written and neither was updated when the other changed; both are now superseded by the merge. Records mutation proof A for the condensed bar: top-full -> top-0 turns 32/0 into 13 failed / 19 passed, and the 1440px failure is the pin assertion itself at line 877 (barBox.top 64 -> 0) with the two preceding assertions passing first, so the assertion is reached and discriminating rather than merely present. Also records the trap that nearly produced a false proof: the first mutation-B anchor matched two elements, a uniqueness assertion refused the edit, and the script ran the full gate anyway on an unmutated tree -- reporting 32 passed, exit 0. Read without the abort line that is a real, green, strongest-looking gate run supporting exactly the wrong conclusion. A mutation proof therefore has two results, not one: prove the mutation is in the tree before believing the gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Mutation B (dark-mode colour): 1 failed / 31 passed. The single failure is the scheme-comparison at line 931 and names the injected literal, so it is attributable by value and not merely by timing; the display guard before it passed, so the assertion is reached. A blast radius matching the mutation's intent is itself evidence the assertion measures what it claims. With mutation A already proven, both closing proofs the final review recorded as UNRUN are discharged and the condensed bar's fix round is closed. Adds the Phase 2B implementation plan. It follows the owner's stated order and is grounded in a measured reading of what Phase 2A actually left: one real route, thirteen stub destinations, zero of twenty-four overlays wired to a trigger, no empty-state component, and no read API for patients, schedule or team. Two gaps the plan surfaces rather than hides: message templates have a full governance lifecycle but only ONE hard-coded message, so a template library cannot show per-version content that does not exist; and 'workload and coverage' has an approved design only at roster-table depth, which is the single most likely place the plan under-delivers against what the owner means. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…py decisions The owner answered 'go ahead with your recommendations' to all thirteen items on 2026-08-24. Recorded as the decision of record, with two qualifications that approval alone does not settle: A9 (add Lifeline 13 11 14) is approved in principle but BLOCKED. The recommendation was conditional -- add Lifeline and drop the Fictional Support Line once a real crisis number is chosen -- because the message sits about nine characters from its two-segment maximum, so nothing can be added until something comes out. No real number exists, and the owner was explicitly asked to name what goes. An implementer must not pick the removal itself. A4 (the closing message) is approved as a deferral, not as text: the refusal path is buildable now, the wording waits for a lived-experience representative. Patient-visible copy is no longer frozen, but every change must cite its item number and still live only in the sealed domain's message-copy module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…tradicts The approval banner lifted the copy freeze, but the line directly beneath it still said wording stays frozen until the owner answers. That is the same self-contradiction this session just criticised in phase-2a-handoff.md, created the same way -- a true sentence left in place when the thing it described changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…can, add Task C The pre-flight scan found one real defect in the plan before any dispatch: the design-corrections table routed correction #2 to 'Group 3, Task 11', but Task 11 is Group 1's overlay wiring and Group 3 is Tasks 15-16. An implementer would have received a requirement it had no surface for. Fixed as Ruling 73. Adds Task C -- the owner's six approved copy changes, batched into one dispatch per the method's rule about small same-shape work. A9 (add Lifeline) is deliberately excluded: it is approved in principle but conditional on a real crisis number existing, and dispatching it would force an implementer to choose which patient-facing sentence to delete. Rulings 73-78 recorded, each with what it costs if wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…s forced Ruling 79: the owner's approved 'refuse any message containing Fictional' cannot be implemented as a prohibited term, because both approved patient messages contain 'Fictional Support Line' -- every existing message would be invalid and the check would have to be disabled to ship. Implemented instead as a validator issue plus an explicit synthetic-acknowledgement flag on each call site, so a real send path has to opt in deliberately rather than fail silently. Ruling 80: A3's 'something automatic comes back' fits only in the reply message. Message A is 252 septets against a two-segment ceiling. Measured with the repo's own calculateGsm7 rather than estimated -- the proposed reply is 210 septets. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Carries Ruling 81: EmptyState is its own component and does not render AutomatedState internally. The two have different triggers -- AutomatedState is for the system acting on its own, an empty list is usually the user's own filter or simply nothing existing yet -- and AutomatedState's alert icon and state-name aria-label are both wrong for 'no patients yet'. The filtered variant reuses its why/what-changes-it wording shape so a clinician learns one pattern. The brief models the two emptinesses as a discriminated union rather than optional strings, because an optional reason is a reason that will be omitted, and a filtered-empty list that says only 'nothing to show' is indistinguishable from an empty caseload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…tomated reply (A2 + A3) Owner-approved 2026-08-24. The reply's first sentence claimed replies "had not been seen by anyone and had not been kept" -- a firm storage claim about a system with no telephony provider yet, so nobody could currently know if it was true (A2). It also left a patient who had just been told "no one reads this" unable to tell a reply was automatic rather than human (A3). Replaces the sentence with wording that states only what the system can actually know and names the reply as automatic. Verified 210 septets / 2 segments / GSM-7 valid (was 218). EXACT_PATIENT_VISIBLE_MESSAGE is untouched -- it has no segment headroom left, so the "reply is automatic" fact lives only here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ail (A1 / Ruling 79) Both approved patient-visible messages name the reserved fictional crisis number on purpose, so a bare prohibition on the word "Fictional" would make every existing message invalid and the check would have to be disabled to ship -- worse than no check. Instead validateGovernedMessage now always reports fictional-contact-detail-present when a message contains the marker (derived from message-rules.ts's crisisSupportContact, not hard-coded a second time), unless the caller passes the new, explicit syntheticFictionalContactsAcknowledged: true. Existing tests that build compliant first/closing messages from the crisis contact are updated to pass the acknowledgement, since they were never testing this rule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…thored body (A4) No closing message has ever been written -- that wording is a clinical decision deferred to a lived-experience representative, not an implementation gap. resolveClosingContactMessageBody is the refusal only: it never returns an empty string, never falls back to another message's text, and never silently drops the contact when no authored body exists. No closing-message wording is drafted here. No existing seam resolved a contact's message body anywhere in this domain (checked schedule.ts, simulation.ts, repository.ts, model.ts): PlannedContact carries a messageType but no body content, and nothing supplies one yet. This function is the mechanism a future sender will call once that seam exists; it is deliberately not wired into schedule.ts/simulation.ts here, since doing so would require inventing where an authored closing body comes from -- exactly the decision this task defers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

lowerText.includes("lead") also matched the ordinary English "the incident lead" and "the clinical programme lead" -- job titles that appear in the service-stop wording -- so a message using the word correctly would be rejected. Word-boundary matching alone would not have fixed this (both job titles contain "lead" as a whole word too), so "lead" is narrowed to a commercial-specific form instead: a marketing-word modifier ("sales lead", "a new lead") or companion ("lead generation", "lead conversion"). The narrowing lives as a per-term pattern override in message-rules.ts (prohibitedTermPatternOverrides), keeping message-policy.ts's mechanism generic. Every other prohibited term keeps its exact substring behaviour -- one covering test per term proves it, since narrowing one term is precisely the change most likely to quietly widen what the rest of the list allows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…vocabulary (B3) Until now the prohibited-word ban ran only against outgoing messages (message-policy.ts) and the 24 frozen overlay definition rows (caring-contacts-overlay-definitions.test.ts) -- nothing checked the words on a screen, so it was policy held by people rather than software. This scans every string/template literal under src/components/caring-contacts/ workspace/** and src/app/caring-contacts/** against the existing wider CARING_CONTACTS_PROHIBITED_LANGUAGE vocabulary. src/components/caring-contacts/mockups/** is out of scope by construction (not one of the two scan roots) -- it is frozen design scratch that 404s in production and knowingly contains one prohibited phrase the owner ruled (B4) to leave alone. Extraction uses a small character-by-character scan rather than a regex over the raw source: a naive quote-matching regex treats JSDoc inline-code backticks (`` `useSearchParams` ``) as template-literal delimiters, and an odd count across a comment pairs unrelated spans into one giant fake literal spanning most of the file. className attribute values are excluded before extraction -- narrowing which literals reach the scan, not adding a file to an ignore list -- because they carry CSS custom-property names (var(--safe-area-bottom)) that contain "safe" as a substring unrelated to interface prose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

npm run test's repo-wide test-runner-safety.test.ts requires every recursive rmSync in a test fixture to pass maxRetries/retryDelay, guarding against Windows file-lock flakiness on cleanup. The B3 fixture cleanup added in the previous commit was missing them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…tion-proven Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Verified the two full-suite failures myself rather than accepting the report: both are gate-receipts file-mode tests failing in chmodSync, on a Windows drive that cannot represent file modes. Environmental, and a third known local failure. Records the consequential finding: validateGovernedMessage has zero production callers. The brief assumed callers to update and there are none. The checks are real but guard a send path that does not exist yet, so 'the validator refuses this' must not be read as 'the system refuses this'. Captured as a P2 issue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Spec passed. Three Important findings, four Minor. Two lessons recorded that generalise beyond this task: An allowlist cannot close an open-ended set. B2 narrowed the 'lead' prohibition by enumerating commercial phrasings, so everything unenumerated is now permitted -- 'lead magnet', 'qualify this lead' and others all pass and all previously failed. Enumerate the safe set, never the dangerous one. A guard on a chokepoint fires; a guard beside one does not. A1 and A4 both look 'unwired' and have opposite futures: A1 sits inside validateGovernedMessage which any sender must pass, while A4 is a standalone function nothing obliges anyone to call. Ruling 83 therefore refuses to record A4 as closed. Ruling 82 promotes the A1 marker finding from Minor: it matches the label 'Fictional Support Line', not the reserved number, and the number is the artefact that would actually reach a patient. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…3, comment) Fix round 1 against Task C, six of seven fixable findings (the seventh, A4's standalone resolveClosingContactMessageBody, was recorded and reported to the owner instead of changed -- it rides no chokepoint yet, and inventing one is out of this task's scope). Important 1+2 (B2): the first "lead" override was an ALLOWLIST of nine commercial modifiers/companions, and commercial vocabulary is open-ended, so anything not enumerated passed silently -- verified newly permitted "lead nurturing", "lead magnet", "lead source", "leads database", "lead gen", "qualify this lead", "convert the lead", "this lead is hot", "your lead". Inverted: COMMERCIAL_LEAD_PATTERN now refuses "lead"/"leads" as a whole word BY DEFAULT via a negative lookbehind, exempting only the closed set of job titles this domain's own wording uses -- incident lead, programme lead, clinical lead, team lead, service lead. The "scoring?" typo (matched "lead scoring" but not "lead score") disappears with the allowlist it lived in; confirmed via a dedicated "lead score" test. Promoted Important (A1): the marker was `crisisSupportContact.split(":") [0]`, i.e. the LABEL "Fictional Support Line" only -- a message carrying the bare reserved NUMBER with no label raised nothing, which is the shape that would actually reach a sender. fictionalContactMarkerPattern is now `/Fictional/i` plus every reserved number in synthetic-contacts.ts (escaped), so relabelling, reordering, or dropping the label entirely are all still caught. One pre-existing rule-6 test (contains-patient-mobile) used +61 491 570 006 -- itself one of the four reserved numbers -- as its example patient mobile; its expectation is updated (not loosened) to the now-correct two-issue result. Minor 5: pins prohibitedTermPatternOverrides to exactly {"lead"} so a future override for another term cannot land unnoticed by this regression suite. Important 3 (B3): the interface-vocabulary scan only saw quoted/template strings, missing the plain-JSX-text form this tree actually writes copy in (shell.tsx, loading.tsx). Added a second raw-prose pass (comments and className values stripped, everything else scanned as-is) and a fixture test proving it catches a word planted as bare JSX text between tags, not just inside quotes. Minor 7 (B3): the real-tree scan now asserts filesScanned > 0, closing the vacuous-pass hole a root with no matching files would otherwise leave open. Minor 6: reworded the AUTOMATED_REPLY_RESPONSE comment claiming content "is discarded... nothing is stored" as a design INTENT/contract rather than settled fact, so it no longer contradicts the very next paragraph explaining that no telephony provider exists yet to make that claim true or false. Every fixable finding mutation-proven: B2 mutated back to the old allowlist (the CRM test goes red) and to a bare `\bleads?\b` with no exemption (the job-title test goes red); A1 mutated to drop the number half of the pattern (the bare-number and four-numbers tests go red); B3's raw-prose pass and floor assertion each mutated out and confirmed red. All mutations confirmed present in the tree via direct file inspection before trusting the red result. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…rified independently Executed the new negative-lookbehind pattern against 18 cases rather than accepting the report. All ten previously-leaking commercial phrasings are now refused -- including 'lead score', the case the scoring? typo let through, so that finding is genuinely moot rather than relocated. All eight job-title and ordinary-English cases still pass. Records the rule the inversion confirms: when a check must separate a safe set from a dangerous one, enumerate whichever set is CLOSED. Five job titles are closed; commercial vocabulary is not. That test now applies to every allowlist, ignore list and exemption the rest of this plan adds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Re-review re-derived every claim by execution rather than reading assertions. Two mechanism-level checks worth keeping: the A1/patient-mobile double report is benign because the patient-mobile check is independent of the acknowledgement flag, so acknowledging silences the noisy code and keeps the safety-critical one; and the global-regex handling is correct, with the non-global copy used for .test() and the global copy only with matchAll. B2's mutation proof is two-directional as requested -- reverting to the allowlist reddens the refusal test, widening to a bare pattern reddens the exemption test. Those bracket the behaviour rather than being two views of one assertion. Six minors deferred to the final whole-branch review, including a new one: the job-title exemption needs whitespace adjacency but this domain writes 'team-lead'. Inert today -- outside the scan roots, absent from both messages, and the validator has no production callers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ed two Went to write Task 2's brief, read the code it was meant to extract a pattern from, and found the pattern already there. Two more premises fell the same way. Ruling 84 cuts Task 2: readHandler already is the list-read pattern, used by eight routes, four of them sharing the collection objectId convention. One requirement survives into the first list route -- a contract test pinning that an empty list is 200 with an empty array, never a 404, since auditedRead maps a null release to denied and an empty array is neither. Ruling 85: Task 5 builds no API. GET /api/caring-contacts/plans already lists team plans. The patientDirectory object type is not an unwired gap -- the referrals route already uses it, for patients who may not yet have a plan. Ruling 86: design correction 1 is already in the domain. schedule.ts takes and validates firstContactDate and the plans schema accepts it; only the screen control is missing. All three came from recon reports that were factually correct and whose implications I carried too far. Before a brief says build this, open the file. The cost of skipping that is not a wasted task, it is a second implementation of something that already works, sitting beside the first, both maintained. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…Task 1) Adds src/components/caring-contacts/workspace/empty-state.tsx, exporting EmptyState -- the one shared empty-list surface the four Phase 2B list screens (patients, schedule, templates, team) will use, so each does not invent its own. Modelled as a discriminated union on `kind`: "no-data" (nothing exists yet) and "filtered" (a filter/search is hiding existing records) cannot be confused with each other, because "filtered" requires its `because` and `changedBy` at the type level -- there is no shared optional field a caller could omit. The "filtered" branch reuses AutomatedState's "Why: .../What changes it: ..." wording shape without rendering AutomatedState itself (Ruling 81): the two have different triggers, and AutomatedState's CircleAlert icon and state-name aria-label are wrong for "no patients yet". A Server Component with no hooks (Ruling 13): the optional `action` slot takes an already-built ReactNode (a <Link>, a form-submit button, or an UnavailableDestination) rather than raw onClick/href props, the same way ServiceStateBanner hosts UnavailableDestination as a child without becoming a Client Component itself. The icon started as lucide-react's Inbox and had to change to FolderOpen: tests/caring-contacts-interface-vocabulary.test.ts's raw-prose scan caught the bare identifier "Inbox" as the prohibited reply-monitoring/marketing term "inbox" (CARING_CONTACTS_PROHIBITED_LANGUAGE), even though it was never in a string literal -- a real catch by that guard, not a false positive. tests/caring-contacts-empty-state.dom.test.tsx: 9 tests covering both kinds' required copy, the absence of the other kind's wording, the optional action (rendered vs. omitted, and genuinely actionable), a type-level compile check that "filtered" cannot omit because/changedBy, a 320px-container render, and the forced-colors override class. Mutation-tested: forcing the "filtered" branch to always render the "no-data" JSX (dropping the reason and remedy) reddened exactly the two tests that read that content; reverted and confirmed green again. docs/design-system/adoption-manifest.json regenerated via `npm run design-system:adoption:update` -- the only change is the new test file being recorded against ui-primitives.tsx's testFiles array. Not wired into any screen (later tasks' job). Does not modify automated-state.tsx, shell.tsx, or any route. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…out the commit contract Verified in code before writing the brief. openWorkspaceOverlay already exists, is exported and is DOM-tested, so Task 3 was never going to build an opening mechanism. Reading it exposed the thing that matters instead. WorkspaceOverlays' commit callback closes the overlay and records nothing, with an honest comment noting this is safe because nothing in the workspace opens an overlay yet, so no control advertises an action it does not perform. Task 3 is precisely what would break that clause: the moment a screen can open an overlay, its confirm button becomes a control that advertises an action the system does not perform, which is what the button-wiring gate forbids. So the trigger and the commit contract ship together, and the trigger requires a commit handler rather than defaulting to a no-op. A screen must be unable to open an overlay it has not wired, and the compiler is what finds the omissions rather than a later sweep. The general shape, worth keeping: a mechanism that is safe only because nothing reaches it is not safe, it is unreached. Before making something reachable, check what its arrival makes true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Carries Ruling 87 into the brief, and tells the implementer plainly that the overlay opening mechanism already exists so it does not rebuild one. The task is the small client control plus the type-level requirement that a screen cannot open an overlay it has not wired. Leaves one genuinely open design question to the implementer with instructions to choose deliberately and record what it rejected: WorkspaceOverlays is rendered once by the shell rather than per screen, so a screen's commit handler has to reach it somehow, and the obvious answers each carry costs. If the honest answer is that it needs a decision above its level, it is told to say so rather than pick silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Records the build of src/components/caring-contacts/workspace/empty-state.tsx, the TDD red/green proof, the mutation proof, the interface-vocabulary catch (Inbox -> FolderOpen), and the full verification chain (vitest, full test suite, typecheck, lint -- including the two bounded lock-contention retries before typecheck acquired the repo's heavy-run lease). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…rected the briefs The implementer paused mid-task on the heavy-run lease with its work uncommitted, on a machine that has destroyed four working directories mid-session. Resumed with an explicit ordering -- commit first, then retry the gate, bounded -- which is now standing for every remaining brief. Machine health was measured rather than assumed: node --version in 0.083s, so ordinary lease contention. Records that Task C's interface-vocabulary scan caught a defect in Task 1 one task after being built: a lucide Inbox icon, rejected because inbox is banned as reply-monitoring language. It fired on a bare identifier rather than prose, which is exactly the deferred concern Task C's re-review raised -- so that concern is real and will recur. Whether it was a false positive is put to the reviewer rather than settled here, with the note not to narrow the scan merely because it was inconvenient once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…nent, and my brief caused the collision The reviewer re-ran both mutations rather than reading the report, and found the described mutation does not produce the reported numbers: mutating the filtered branch gives 1 failed, not 2, because with the guard hardcoded true that branch is dead code. The evidence is real, the account of which branch was mutated is not. Second time on this programme that re-deriving a self-reported mutation changed the answer. Ruling 88 renames to ListEmptyState. ui-primitives.tsx already exports an EmptyState and the adoption-manifest generator matches tests to components by a bare name regex with no import awareness, so the caring-contacts test now falsely counts as coverage for a shared primitive it never imports. False evidence about test coverage in a governance artifact. My brief mandated the colliding name. Also settles two open questions: action: ReactNode is correct because an onClick prop cannot cross a Server-to-Client boundary; and the vocabulary scan will not be narrowed after firing on an identifier, closing Task C deferred item 2 as decided rather than deferred. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ble group, mutation-proof correction Three review findings addressed: 1. Renamed EmptyState -> ListEmptyState (file, exports, test imports/usages). src/components/ui-primitives.tsx already exports a registered design-system primitive called EmptyState, used across 43 files. scripts/generate-design-system-adoption.mjs credits test coverage by matching \bName\b against raw test-file text with no import-path awareness, so the bare name in this component's test file was crediting tests/caring-contacts-empty-state.dom.test.tsx as coverage for the unrelated ui-primitives EmptyState in the generated adoption manifest -- false evidence in a governance artifact. ListEmptyState does not match \bEmptyState\b, so it cannot recreate the collision. Manifest regenerated; the false testFiles line is confirmed gone from the ui-primitives EmptyState entry (see report for the diff). 2. Wrapped the whole component in role="group" aria-label={props.heading}, reusing automated-state.tsx's accessible grouping (Ruling 81 forbade rendering AutomatedState, not reusing its structure): a screen reader that reaches the state enters a named group and finds "Why:"/"What changes it:" without hunting elsewhere. Applied to both kinds, not only "filtered", for one consistent grouping pattern. Uses the same aria-label (not aria-labelledby) technique automated-state.tsx already proves hook-free. Two new tests assert the group and its name for each kind. 3. Re-ran the brief's named mutation correctly. The prior report described mutating the "filtered" branch but had actually hardcoded the ternary's guard to `true` AND replaced the no-data branch's real content with a placeholder string -- coarser than specified, and it broke both kinds equally rather than leaving no-data's real output intact. This round's mutation touches only the guard (hardcoded true) plus a necessary type-safe cast, reusing the actual no-data code path rather than a placeholder: for a genuine no-data instance the cast is a no-op (identical output); for a genuine filtered instance, reading a field that does not exist on it renders nothing. Result: exactly 2 of 11 tests reddened, both in the "filtered" describe block; all "no-data" tests stayed green throughout. Reverted and confirmed 11 passed again. Report rewritten to describe this accurately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Task 4 would have created the patients page rendering the empty state before Task 5 gave it data -- a caseload screen saying 'No patients yet' whether or not patients exist. That is precisely the defect Task 1's component was built to prevent, and the orphan-route gate would have forced an inbound link at the same moment, making the false state reachable rather than merely present. Its real deliverables travel with the screen that has real data: the href, the sitemap update, the codebase-index entry and the reachability assertion. Same shape as Ruling 87: before making something reachable, ask what its arrival makes true. There it was confirm buttons that do nothing; here a caseload screen that says empty when it is not. Both invisible while unreachable. Also records what already exists: caring-contacts-routes.ts declares all fifteen destinations plus typed helpers for every dynamic route, and shell.tsx's own comment says lighting one up is exactly adding an href. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…heck and lint clean Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… 1 and is owed a re-take The coordinator's 32-passed result in 9cc7fa5 ran against the pre-fix head. Ruling 90 changed which rows render the refusal and the confirm-sequence fix changed what renders at commit time, so that evidence does not name this head. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ould not fail Records two corrections the implementer made to my framing. My suggested remedy for the flashing refusal -- close before clearing -- would not have worked, since both are synchronous while the URL change is not. A controller's suggested remedy is a hypothesis like any other, and this one was falsified by someone reading the code more carefully than I did. The valuable part is a gate it caught not running: grep -c chained with && before the test, where the mutation had stripped the very classes being counted, so grep exited non-zero on a legitimate no-match and the test never ran. No summary line, and it reads as 'confirm the mutation landed, then test it'. Fifth member of a family this repo keeps meeting. The tell that unites them: ask what the check prints when it fails, and confirm you have seen that output once. Four of the five produce no output at all in the failing case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1306c0b The earlier green was correctly declared stale: Ruling 90 changed which rows render the refusal paragraph and the confirm-sequence fix changed what renders at commit time, so neither the input nor the output of the assertion that mattered was the same thing twice. Both greens read 32 passed, which is why the rule matters rather than why it does not. Identical numbers across two different trees are two separate measurements that happen to agree, and only one describes the code that now exists. Had the fix broken the viewport assertion, the stale green would have said 32 passed about a tree nobody was shipping. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

All five findings addressed. The re-reviewer checked Ruling 90 against definitions.ts itself: exactly 8 non-mutating rows, the withholding reads the frozen flag, and definitions.ts is untouched across the task range, so the flag was consulted rather than edited. It corrected one of my claims. I described the fix as a one-shot token; it is two mechanisms -- the token and a reconciliation effect -- and neither alone closes the set. A mechanism described as one thing that is actually two is a description under which a later maintainer can delete half and still believe the comment. The generated manifest line is a different problem from Ruling 88 despite the same weak generator: there the attribution was false, here it is true. Same mechanism, opposite verdicts, which is why 'we saw this before' is not itself an answer. Group 0 done: Task 2 cut, Task 4 merged forward, leaving ListEmptyState and the overlay trigger with its commit contract. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

supabase · 2026-08-24T14:41:17Z

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-24T14:41:18Z

Warning

Review limit reached

Next included review available in 34 minutes.

View limit details

Limit details: You’ve used the included review currently available. Your 101 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 887e1591-30b1-4050-9faf-16fbf1dd6bf1

📥 Commits

Reviewing files that changed from the base of the PR and between f3cd66c and b77fcc5.

⛔ Files ignored due to path filters (24)

docs/caring-contacts/PROGRESS-LEDGER.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/copy-decisions-recommended.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2a-build-record.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2a-continuation-prompt.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2a-handoff.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-build-record.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-1-brief.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-1-report.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-3-brief.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-3-report.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-c-brief.md is excluded by !docs/**, !**/*.md
docs/caring-contacts/phase-2b-sdd-archive/task-c-report.md is excluded by !docs/**, !**/*.md
docs/design-system/adoption-manifest.json is excluded by !docs/**
docs/outstanding-issues-inbox/1838b99a-9323-4e3b-84a5-8e52535ecec8.json is excluded by !docs/**
docs/outstanding-issues-inbox/18b32d38-540f-4d7c-af35-3f4f067e4998.json is excluded by !docs/**
docs/outstanding-issues-inbox/854ca9ba-ba3b-442b-be6d-6f5873ed60ed.json is excluded by !docs/**
docs/outstanding-issues-inbox/9da200a8-0ae0-451b-bef8-d1636b9e3cff.json is excluded by !docs/**
docs/outstanding-issues-inbox/a0548b2c-2c80-44f9-9440-5b983e169a13.json is excluded by !docs/**
docs/outstanding-issues-inbox/a4b0610d-ef92-4d1b-bcc8-3da0eb646d5a.json is excluded by !docs/**
docs/outstanding-issues-inbox/ba655ad0-9934-4885-a959-5efd375a9bf1.json is excluded by !docs/**
docs/outstanding-issues-inbox/cd97d402-7af1-473e-a2eb-dbac597cd03d.json is excluded by !docs/**
docs/outstanding-issues-inbox/d7725691-5968-48f1-9912-bca3a5942731.json is excluded by !docs/**
docs/outstanding-issues-inbox/fa126adf-ade8-4027-a029-d59b4bef8967.json is excluded by !docs/**
docs/superpowers/plans/2026-08-24-caring-contact-phase-2b-screens.md is excluded by !docs/**, !**/*.md

📒 Files selected for processing (17)

data/outstanding-issues-snapshot.json
src/components/caring-contacts/workspace/list-empty-state.tsx
src/components/caring-contacts/workspace/overlays/overlay-commits.ts
src/components/caring-contacts/workspace/overlays/overlay-host.tsx
src/components/caring-contacts/workspace/overlays/overlay-trigger.tsx
src/components/caring-contacts/workspace/overlays/workspace-overlays.tsx
src/lib/caring-contacts/message-copy.ts
src/lib/caring-contacts/message-policy.ts
src/lib/caring-contacts/message-rules.ts
tests/caring-contact-mockups.dom.test.tsx
tests/caring-contacts-empty-state.dom.test.tsx
tests/caring-contacts-explained-automation.dom.test.tsx
tests/caring-contacts-interface-vocabulary.test.ts
tests/caring-contacts-message-copy.test.ts
tests/caring-contacts-message-policy.test.ts
tests/caring-contacts-overlay-host.dom.test.tsx
tests/caring-contacts-overlay-trigger.dom.test.tsx

_{Comment @coderabbitai help to get the list of available commands.}

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and this PR changes clinical caring-contacts message policy, rules, and copy, so human review is needed. No reviewers were assigned because the only code owner is the PR author.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and this PR changes clinical caring-contacts message policy and overlay commit behavior, so human review is needed. No reviewers were assigned.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:bb03d00b51

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

BigSimmo · 2026-08-24T14:49:57Z

@codex resolve actionable Codex review findings for this pull request and current head using the repository instructions. This is the pull request's single automatic repair pass: do not perform a fresh review, create new standalone findings, or request another review. Work only the existing unresolved Codex threads on the current head. The only repository destination is BigSimmo/Database, and the only branch destination is the pull request head branch claude/caring-contacts-foundation at starting commit 409d4b0; never publish fixes to a detached or synthetic work branch and never create a stacked pull request. Use the authenticated GitHub connector to commit each approved fix to BigSimmo/Database:claude/caring-contacts-foundation, then verify that the pull request head contains the published commit before reporting success. Always fix P0 and P1 findings. For P2 and lower findings, fix only clear, scoped, low-risk issues; otherwise disposition them with a concise reason. For a fixed thread, reply with as the first line and as the second line. For a no-code disposition, use followed by . These result markers authorize the workflow to close that exact thread only after it verifies a fixed commit is the pull request head; a local-only commit is not a fix. If publication or verification fails, do not use either result marker, do not claim success, and leave the thread open with the blocker. If human input or new authorization is required, do the same. Finish only after every actionable thread is fixed or dispositioned and closed, or explicitly left open for a human decision. Do not update the branch from main, address unrelated reviews, broaden scope, or create more than one scoped fix commit. Do not use external APIs, paid services, credentials, dependency changes, or broad refactors unless explicitly authorized. Add targeted tests where behavior changes and run the narrowest relevant validation.

chatgpt-codex-connector · 2026-08-24T14:51:48Z

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit:409d4b0f6e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

github-actions · 2026-08-24T14:57:03Z

CI triage

CI failed on this PR. Automated classification of the 2 failed job(s):

Static PR checks — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.
PR required — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.

Compared with main CI run #13693 (success).

Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger.

CI's 'Outstanding-issues ledger integrity' step failed because this branch queues ten new inbox request files -- the deferred Phase 2A findings and the two Task C review findings -- taking pending from 103 to 113, while the committed snapshot still described 103. The snapshot is generated from the ledger, so this is a regeneration rather than an edit: node scripts/generate-outstanding-issues-snapshot.mjs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and two unresolved Codex P1 findings remain on the overlay commit path, so human review is needed. No reviewers were assigned.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

The docs link check failed on five references across four files. All five were real, and none was the checker being wrong. Two are stale paths from Ruling 88's rename: task-1's brief and report both named empty-state.tsx / EmptyState, which fix round 1 renamed to list-empty-state.tsx / ListEmptyState. Corrected, with a note in the brief recording that the naming instruction was mine and the collision was my defect -- the brief is a historical record and should say so rather than read as though it always said this. One is a quoted tsc diagnostic in task-3's report. The compiler prints path(line,col), which glues the location to the path so the checker reads one malformed reference. Reworded so the location is prose; the file itself exists. Two are task-5-brief.md referencing the Patients page and its report -- files that exist only on the working branch. A brief describing work this PR does not contain does not belong in it, so the file is removed here; it stays on claude/browser-test-gate-handoff-d5c1db with the work it describes. Local: docs link check passed, 3297 repo path references resolve. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and two unresolved Codex P1 findings remain on the overlay commit path, so human review is needed. No reviewers were assigned.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and two unresolved Codex P1 findings remain on the overlay commit path, so human review is needed. No reviewers were assigned.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

cursor

Stale comment

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and two unresolved Codex P1 findings remain on the overlay commit path, so human review is needed. No reviewers were assigned.
_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

cursor

Left a non-blocking comment (not approved). Cursor Bugbot was not present after the first check poll, and two unresolved Codex P1 findings remain on the overlay commit path, so human review is needed. No reviewers were assigned.

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

BigSimmoand others added 30 commits August 24, 2026 15:32

docs(caring-contacts): Task C report -- six copy/policy changes, muta…
9a4cf05
…tion-proven Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs(caring-contacts): Task C fix-round-1 report
a865d6a
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

BigSimmoand others added 5 commits August 24, 2026 20:24

docs(caring-contacts): Task 3 fix round 1 gates -- 9823 passed, typec…
b452084
…heck and lint clean Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merge branch 'main' into claude/caring-contacts-foundation
409d4b0

BigSimmo changed the title ~~Claude/caring contacts foundation~~Caring Contacts Phase 2B foundation: approved copy changes, shared empty state, overlay commit contractAug 24, 2026