BigSimmo · BigSimmo · Aug 18, 2026
@@ -0,0 +1,99 @@
+# Caring contacts — accessibility and responsive acceptance
+
+**Status:** local synthetic-prototype evidence, 15 August 2026 
+**Boundary:** Chromium evidence and source review; not physical-device or production acceptance
+
+## 1. Evidence classification
+
+| Area | Status | Evidence and limit |
+| --------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 320px / 400% reflow proxy | Actual local Chromium evidence | 320px viewport is the repository proxy for 400% zoom on 1280px. Core, boundary and delivery journeys have no horizontal page overflow or obscured action. This is a proxy, not a browser-zoom measurement. |
+| 390px | Actual local Chromium evidence | Compact shell, four-item dock, activation sheets, all overlays, offline/protected actions and final screenshots. |
+| 430px | Actual local Chromium evidence | Compact continuity retained at the upper compact boundary; no horizontal overflow. |
+| 768px | Actual local Chromium evidence | Collapsed desktop navigation/rail state, not enlarged phone; contextual delivery rail remains in bounds. |
+| 1024px | Actual local Chromium evidence | Split-capable continuity; no clipped panes or horizontal page overflow. |
+| 1440px | Actual local Chromium evidence | Wide navigation, workflow preview, dialogs/drawers and final screenshots. |
+| Keyboard and focus | Actual DOM and Chromium evidence | Keyboard activation, workflow-heading focus, Escape dismissal, trigger focus restoration, session-gate containment, offline focusability and protected-decision denial. |
+| Names, roles and states | Actual DOM and Chromium evidence plus source review | One page `h1`; named navigation, lists, dialogs, status banner, schedule and controls; expanded/current/unavailable states exposed. |
+| Word/non-colour status | Actual DOM/source evidence | Every operational status has visible text and a dot/icon/structure. Tests retain wording in forced colours. |
+| Text sizing and long values | Source plus responsive rendered evidence | Semantic type tokens; full values wrap; no truncated page/dialog title; 320px overflow proof. Dedicated browser text-resize beyond the 320px proxy is unrun. |
+| Dock and safe area | Actual local Chromium evidence | Compact actions are scrolled clear of the fixed dock in routine journeys. During evidence capture only, the fixed phone dock is hidden and each required region is asserted not to intersect a painted/interactive fixed overlay before pixels are written. |
+| Dark mode | Rendered specimen plus source review | Dark specimen uses repository theme roles. A whole-suite dark-theme screenshot journey is not part of this focused proof. |
+| Forced colours | Actual local Chromium media evidence | Forced-colour media activates; status words remain; system-colour continuity and specimens are present. |
+| Reduced motion | Actual local Chromium media evidence | Reduced-motion media activates; continuity and status meaning remain; motion classes stop/avoid animation. |
+| Physical iPhone Safari | **Unrun — required later** | Chromium responsive emulation cannot close Safari viewport, safe-area, keyboard or focus behaviour. |
+| Installed PWA | **Unrun — required later** | Requires an authorised production-like build on a managed physical device, including install/launch and offline boundary checks. |
+
+## 2. Final rendered-evidence manifest
+
+The ignored local directory
+`.local/caring-contact-design-evidence/2026-08-15` contains exactly the following 26 synthetic PNGs.
+Routine browser runs do not write or remove evidence; only
+`CARING_CONTACT_CAPTURE_EVIDENCE=1` enables the deterministic reset and capture. Delivery and
+component/state dialogs use named internal-scroll slices so the real viewport, header/footer and
+every required section are represented without expanding the production Sheet.
+
+| File | Dimensions |
+| ------------------------------------------------------- | ---------- |
+| `foundation-phone-390.png` | 390×1410 |
+| `foundation-desktop-1440.png` | 1440×698 |
+| `today-phone-390.png` | 390×1142 |
+| `today-desktop-1440.png` | 1440×606 |
+| `activation-review-phone-390.png` | 390×2777 |
+| `activation-review-desktop-1440.png` | 1440×2401 |
+| `patient-overview-phone-390.png` | 390×2626 |
+| `patient-overview-desktop-1440.png` | 1440×2193 |
+| `schedule-phone-390.png` | 390×2644 |
+| `schedule-desktop-1440.png` | 1440×2202 |
+| `delivery-exception-transport-phone-390.png` | 390×844 |
+| `delivery-exception-transport-desktop-1440.png` | 512×1000 |
+| `delivery-exception-operational-task-phone-390.png` | 390×844 |
+| `delivery-exception-operational-task-desktop-1440.png` | 512×1000 |
+| `delivery-exception-clinical-boundary-phone-390.png` | 390×844 |
+| `delivery-exception-clinical-boundary-desktop-1440.png` | 512×1000 |
+| `delivery-exception-audit-phone-390.png` | 390×844 |
+| `delivery-exception-audit-desktop-1440.png` | 512×1000 |
+| `component-state-interaction-phone-390.png` | 390×844 |
+| `component-state-interaction-desktop-1440.png` | 1392×952 |
+| `component-state-content-phone-390.png` | 390×844 |
+| `component-state-content-desktop-1440.png` | 1392×952 |
+| `component-state-modes-phone-390.png` | 390×844 |
+| `component-state-modes-desktop-1440.png` | 1392×952 |
+| `component-state-system-phone-390.png` | 390×844 |
+| `component-state-system-desktop-1440.png` | 1392×952 |
+
+Every file was visually inspected after the final capture. The phone dock is absent from capture
+pixels; required content remains visible across the named slices; the desktop Version conflict tile
+is fully visible in `component-state-system-desktop-1440.png`.
+
+## 3. Keyboard and focus acceptance
+
+- Destination buttons, More sheet, workflow stages and every enabled decision are keyboard
+ reachable and have an object-specific accessible name.
+- Moving between activation stages focuses the new stage heading and announces the stage.
+- Escape closes dismissible sheets/dialogs and returns focus to the invoking control.
+- The session-expiry gate uses the shared Sheet stack, keeps the background inert, locks body scroll,
+ traps focus and resists Escape/backdrop dismissal until `Sign in again`.
+- Persistent offline status is non-modal; focus can leave it. Mutation controls remain focusable with
+ `aria-disabled`, a visible reason and no state change. Read-only inspection remains available.
+- Phone full-screen protected stages and desktop dialogs retain a visible decision, close path where
+ permitted and unobscured validation/action region.
+
+## 4. Responsive continuity
+
+The frozen shell mapping is 320–430 compact, 768 rail, 1024 split-or-safe-fallback and 1440 wide.
+The same information and action sequence is retained; content is not removed to make a width pass.
+Today remains action-first, patient identity stays in the activation flow, Schedule retains its
+seven-day strip and day detail, and the continuity ordered list remains the semantic source of truth.
+
+At compact widths the four-item dock owns the bottom edge. In-flow screens retain enough final
+clearance; full-screen Sheets own their safe-area action region. At desktop widths the delivery
+exception is a constrained right contextual rail and confirmation decisions remain bounded.
+
+## 5. Known acceptance gaps
+
+Before production, run real 400% browser zoom with text-only enlargement, Windows High Contrast with
+representative assistive technology, VoiceOver on physical iPhone Safari, keyboard appearance and
+rotation, and installed-PWA launch/offline/focus journeys. Those checks must use an approved
+production implementation and synthetic or authorised test data. The current prototype evidence
+does not establish WCAG conformance, clinical accessibility approval or device support.
@@ -0,0 +1,137 @@
+# Caring contacts — clinical and content boundaries
+
+**Status:** binding language contract for synthetic design, 15 August 2026 
+**Limit:** records settled product language; it is not clinical approval.
+
+## 1. Core boundary
+
+A caring contact is a brief, governed, one-way message supplemental to usual care and active
+person-to-person follow-up. It is not monitoring, crisis response, triage, a safety check, clinical
+advice, treatment or evidence that clinical follow-up occurred. The workspace does not assess,
+predict or represent suicide risk, urgency, wellbeing, engagement or response.
+
+## 2. Exact distinctions
+
+### Transport is not patient state
+
+`Scheduled`, `Processing`, `Sent`, `Delivered`, `Not delivered`, `Number invalid`, `Contact changed`,
+`Status unavailable` and `Missed` describe systems and events only. Delivered does not prove that a
+patient saw, read or understood a message and never implies safety, wellbeing, engagement or benefit.
+A failure does not imply deterioration or increased risk. It creates named operational work only.
+
+Never relabel transport as `Reached`, `Engaged`, `Responded`, `Safe`, `Concern` or `Clinical
+follow-up`. A permanent failure pauses future contacts and creates a same-day operational task; it
+does not automatically trigger patient contact or clinical review.
+
+### Pending referral is not accepted ownership
+
+Until explicit acceptance, the referring team retains responsibility. `Received`, `Awaiting review`
+and `Clarification requested` show `Awaiting handover` and the referring team, not an aftercare owner.
+After acceptance, coordinator claim/assignment identifies coordination; it does not erase the
+handover history or independently transfer duty of care.
+
+### Objective eligibility is not inferred risk
+
+Eligibility uses adult status, qualifying discharge/referral, pilot-service scope,
+patient-controlled/suitable-for-SMS evidence and `Agreement confirmed: Yes`. Diagnosis,
+presentation, risk assessments, notes, delivery or non-response never drive automated eligibility or
+priority. Order referrals by discharge and first eligible window. Do not use `high risk`, `risk
+score`, `priority patient`, `best match` or unqualified `needs attention`; name the exact condition,
+remedy and owner.
+
+### Imported evidence is not overstated verification
+
+The label is `Agreement confirmed: Yes/No`, not legal or treatment consent. Callback imports the
+current hospital-record mobile without a test SMS, read-back or separate attestation, so do not label
+it as separately destination-verified. Activation separately requires the source flag that the destination is
+patient-controlled and suitable for discreet SMS; family, carer and shared destinations are
+ineligible.
+
+## 3. Sender, one-way and support rules
+
+- Keep contact roles distinct: the Rowan patient mobile, staffed programme line and crisis-support
+ contact are separate fictional numbers. A patient mobile is never displayed as the programme or
+ crisis contact.
+- Use a non-receiving sender with a discreet, recognisable, neutral team identity; do not expose
+ suicide, crisis or mental-health treatment on a lock screen.
+- Sign every message with the named coordinator under governed substitution rules.
+- Do not receive, store, analyse or display replies. No inbox, conversation, urgency detection or
+ triage route exists.
+- Enrolment and the first SMS state the no-reply boundary, programme phone and staffed hours,
+ emergency direction and one locally approved crisis-support contact.
+- Later messages retain the short no-reply boundary and programme contact.
+- Patients request timing changes, pause or withdrawal through the programme phone, staffed seven
+ days during every sending window; any authorised team member may act immediately.
+
+The design fixes these required meanings, not final sentences. Exact sender label, phone, hours,
+emergency wording, crisis contact and message text require a versioned locally approved set with
+clinical programme lead and lived-experience/content approval. Synthetic prototypes demonstrate
+structure using clearly fictional details. Never invite a reply with wording such as `Reply if`,
+`Text us`, `Tell us`, `Let us know` or `We monitor this number`.
+
+## 4. Governed message rules
+
+Every message is warm, brief, non-demanding and discreet. It may substitute preferred name, neutral
+team identity, coordinator signature and an approved variant only. There is no unrestricted free
+text, generative authoring or dynamic translation; translated pathways need professional translation
+and cultural approval.
+
+Every message:
+
+- makes no claim about current patient state or clinical effect;
+- requests no task, appointment response or disclosure by reply;
+- includes its required one-way/support content;
+- shows the exact fully substituted patient-visible text before activation; and
+- is limited to two concatenated SMS segments including notices and signature, with encoding and
+ exact count shown; overflow blocks activation.
+
+The first message includes discreet team identity, bounded caring-contact purpose, coordinator
+signature, no-reply statement, programme phone/hours, emergency direction and one approved crisis
+support contact. Later messages retain the short no-reply statement and programme contact. Final
+activation shows the exact first message, not a generic summary.
+
+## 5. Clinical/operational action terms
+
+- **Pause:** reversible; preserves the original calendar; contacts within the pause are skipped;
+ resumption begins with the next future contact.
+- **Withdrawal:** patient preference; immediately cancels unsent contacts; no approval; reason
+ optional; terminal with immutable history.
+- **Cancellation:** distinct authorised operational action with a reason.
+- **Readmission:** source event that pauses future contacts; later discharge needs a new referral.
+- **Recorded death:** source event that irreversibly cancels unsent contacts; a correction is an
+ incident and any future plan needs a new referral.
+- **Mobile change:** source event that pauses future contacts for coordinator review; never silently
+ switch destination.
+
+None is inferred from transport, reply or engagement data.
+
+## 6. Claims and reporting
+
+The illustrative twelve-month cadence is locally governed, not a universal prescription. Until
+approved, label it `Illustrative locally governed pathway`, never `Recommended`, `Best practice` or
+`Proven`. The pilot tests operational safety, reliability, clinician usability and separately
+consented patient acceptability; it is not a clinical-effectiveness study.
+
+Each plan has one selected sending preference. All 10 planned contacts derive the same service
+window; only different patients may contribute to different window aggregates on Schedule. A
+one-contact exception is explicit, reasoned and audited and does not silently replace the plan
+preference.
+
+Reporting may cover operational counts, completeness, due/dispatched/delayed contacts, exact
+transport exceptions, resolution time, pauses/withdrawals/cancellations, duplicates, schedule drift
+and versions. Approved demographics require small-cell suppression. Never rank clinicians or infer
+patient safety, suicide risk, wellbeing, engagement, therapeutic response or effectiveness.
+
+## 7. Review reject list
+
+Reject any copy or visual that implies delivered means safe/read/helped; failure means deterioration;
+pending means accepted ownership; coordinator assignment transfers duty of care; imported mobile is
+independently verified; agreement is legal/treatment consent; the cadence is universally effective;
+or that replies are received or monitored. Reject real patient information or PHI in
+URLs/toasts/logs/analytics/page titles/screenshots, free/generated message text, and any
+reply/inbox/conversation surface. Prototype and test screenshots are still required to contain
+clearly fictional synthetic identities and details so boundary states can be reviewed without using
+real data.
+
+Final patient-facing content and the complete prototype require separate lived-experience and
+clinical-language approvals; either may block progression.