Documentation source
DOC360
Clinical wellness intelligence — productized from the DOC'S design-partner pilot
## Overview
DOC360 is the clinical wellness vertical built on the Sprinter Platform. It is productized from the **DOC'S** design-partner pilot — a recovery and wellness clinic in Wall, NJ owned by Dr. Jim Louro ("Doc") and operated by Nolan Genovese.
The product solves a gap that generic EMR/EHR and scheduling tools leave open: **clinical protocol intelligence**. DOC'S already runs commerce and appointment booking in Acuity Scheduling. What Acuity does not do — and what DOC360 must — is the clinical layer: multi-modality dosing, per-patient protocol progression, visit-level response tracking, screening disposition routing, and protocol optimization over time.
**What makes it different from EMR/EHR:**
- No billing or insurance model — DOC'S is a cash-pay wellness clinic
- Protocol is structured and agent-generated, not free-text notes
- The AI agents run protocol synthesis and evidence lookup, not just dictation
- Acuity stays the source of truth for commerce; DOC360 is the source of truth for clinical
**Pilot tenant:** DOC'S (`tenant_id: 6013155f-1f8a-4c35-941a-2b5e4ae23199`, slug: `docs`)
**Who uses it:**
- **Nolan** — floor operator, runs intakes, sets up modalities, logs visits. See [`docs-operator-nolan.mdx`](/docs/personas/docs-operator-nolan).
- **Doc (Dr. Jim Louro)** — clinic owner and clinical authority, reviews flagged patients and approves protocol library changes.
- Patients — via the public intake embed.
---
## Clinical Entity Graph
The DOC'S tenant module (`features/custom/tenants/docs/`) ships custom UI for all 14 entity types. As of PR #1419, every type has a branded card component; 9 of 14 types have a custom detail page.
### Core entity types
Four core entity types are seeded by `scripts/seed-docs-clinical-entity-types.ts`. Each carries a structured JSON Schema, field layout, status maps, and card accent config.
| Entity type | Slug | Key fields | Status lifecycle | Custom card | Custom detail |
| -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ----------- | ------------- |
| **Patient** | `patient` | `name`, `protocol_lane`, `lane_tone`, `screening_disposition`, `plan_status`, `risk_flags`, `response_score`, `membership_recommendation_status` | `plan_status`: awaiting_review → active → reassessment_due / safety_hold → completed | yes | yes |
| **Visit** | `visit` | `patient_id`, `scheduled_for`, `modality_id`, `modality_label`, `protocol_lane`, `visit_number`, `response_score`, `adverse_events` | `status`: scheduled → in_progress → completed / no_show / cancelled | yes | yes |
| **Feedback** | `feedback` | `patient_id`, `visit_id`, `concern_level`, `overall_rating`, `relief_score`, `energy_score`, `sleep_score`, `flagged_concerns` | `status`: pending → submitted → reviewed | yes | yes (PR #1419) |
| **Membership** | `membership` | `patient_id`, `plan_name`, `tier`, `visits_per_month_limit`, `protocol_week`, `monthly_amount_cents` | `status`: active → paused / lapsed / cancelled | yes | yes |
### Protocol and research entity types
| Entity type | Slug | Source | Custom card | Custom detail |
| ----------------- | ----------------- | -------------------------------------- | ----------- | -------------- |
| **Protocol** | `protocol` | `seed-docs-research-entity-types.ts` | yes | yes |
| **Modality** | `modality` | `seed-docs-modalities.ts` | yes | yes |
| **Intake** | `intake` | `seed-docs-research-entity-types.ts` | — | yes |
| **Therapy Plan** | `therapy-plan` | `seed-docs-research-entity-types.ts` | yes | yes (PR #1419) |
| **Screening Rule**| `screening-rule` | `seed-docs-research-entity-types.ts` | yes | yes (PR #1419) |
| **Evidence Claim**| `evidence-claim` | `seed-docs-research-entity-types.ts` | yes | yes (PR #1419) |
| **Source Item** | `source-item` | `seed-docs-research-entity-types.ts` | — | — |
### Clinical-knowledge entity types (PR #1419)
Five types added to the tenant module's declarative `entityTypes` block with branded cards. They were previously seeded in the DB but rendered the platform's generic fallback.
| Entity type | Slug | Key fields | Custom card | Custom detail |
| ------------------ | ------------------ | ------------------------------------------ | ----------- | ------------- |
| **Medication** | `medication` | `generic_name`, `dosage`, `notes` | yes | — |
| **Condition** | `condition` | `category`, `icd10`, `notes` | yes | — |
| **Pain Area** | `pain-area` | `body_region`, `laterality`, `notes` | yes | — |
| **Screening Flag** | `screening-flag` | `severity`, `category`, `notes` | yes | — |
| **Contraindication**| `contraindication`| `modality_scope`, `severity`, `notes` | yes | — |
`screening-flag` uses an `AlertOctagon` icon companion for the `critical` level so severity is distinguishable without relying on color alone (WCAG 1.4.1). `contraindication` maps `relative` → warning and `absolute` → error tokens.
Source: `features/custom/tenants/docs/components/docs-clinical-knowledge-cards.tsx`.
### Entity relations
```
Patient ──has-membership──► Membership
Patient ──had-visit────────► Visit
Visit ──got-feedback─────► Feedback
```
Round 1 relations (onboarding form chip flips — `intake`, `patient`, `visit`, `feedback`, `modality`) were seeded via migrations `20260509100100` / `20260510200000`.
Round 2 (PR #1419, migration `20260514130000_relations_kg_flip_doc_fields_round2.sql`) thickens the clinical knowledge graph with 25 new per-field relation edges across `condition`, `medication`, `pain-area`, `screening-flag`, `contraindication`, `screening-rule`, `feedback`, `therapy-plan`, and `evidence-claim`. All edges use the canonical `config.fields[<key>].relation` shape from `features/entities/types.ts`. The deprecated `config.relations[]` array is left untouched on types that already have one; the resolver merges both.
Relations are also seeded by `scripts/seed-docs-clinical-relations.ts` and `scripts/seed-docs-clinical-fixtures.ts`.
### Additional entity types (from `dial-in-docs-demo.js`)
Two additional types support the full demo story:
| Entity type | Slug | Purpose |
| ------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Condition** | `condition` | Condition/use-case library grounded in TheraLight source pages. Fields: `category`, `recommended_protocol_family`, `starting_conservatism`, `demand_signal`, `screening_watchouts`, `operator_language`. 12 conditions seeded across pain, recovery, inflammation, sleep, mood, skin, circulation, performance, first-responder. |
| **Follow-Up** | `follow-up` | After-visit care touchpoints. Fields: `touchpoint_type`, `channel`, `adherence_signal`, `relief_score`, `sleep_score`, `operator_action`. Status: drafted → scheduled → sent → awaiting_response → closed. |
A broader set of entity types supports the research and protocol-building layers — see `scripts/seed-docs-research-entity-types.ts` for `source-item`, `evidence-claim`, `modality`, `protocol`, `intake`, `therapy-plan`, `session-log`.
### Protocol lanes
Patients are routed into a `protocol_lane` string at intake. The lane drives which modality set, dose, and cadence the protocol builder generates. Lane tone (`fire` / `ice` / `sage`) encodes conservatism:
| Lane | Tone | Population |
| --------------------------------------------- | ---- | ------------------------------------------------- |
| Recovery + Inflammation | fire | Athletes, CrossFit, post-workout |
| Performance | sage | Endurance, training optimization |
| General Wellness | sage | Maintenance, mobility, stress |
| Pain Management — General Musculoskeletal | ice | Chronic pain, arthritis, neuropathy |
| Law Enforcement — Officer Recovery & Wellness | fire | First responders, shift fatigue, TBI/PTSD support |
| Pending review | — | Safety-hold cases awaiting medical clearance |
---
## Modality Catalog
Six modalities are seeded by `scripts/seed-docs-modalities.ts`. Each modality entity carries dosing semantics (`session_duration_range`, `typical_frequency`), primary indications, a contraindications summary, and DOC'S-specific notes.
| Modality | Slug | Duration | Frequency | Notes |
| --------------------------------- | ---------------- | ----------------- | -------------------------------------- | ---------------------------------------------------------------------- |
| **Full-Body Cryotherapy** | `full-body-cryo` | 2–3 min | 1–5× / week | Primary recovery modality for athletes and LE clients |
| **Localized Cryotherapy** | `localized-cryo` | 5–12 min / region | As-needed | Often stacked with Full-Body Cryo or Normatec |
| **Hyperbaric Oxygen (HBOT)** | `hbot` | 60–90 min | 5×/wk intensive or 1–3×/wk maintenance | Flagship modality. Wall PD program uses HBOT for TBI/PTSD |
| **Normatec Compression** | `normatec` | 20–45 min | 2–5× / week | Common add-on; used heavily by athletes and marathoners |
| **Full-Body PBM / Red Light Bed** | `pbm-bed` | 12–20 min | 2–4× / week | Anchor modality. All existing protocols target the Theralight 360+ bed |
| **Infrared Sauna** | `infrared-sauna` | 20–45 min | 2–4× / week | Complement modality; often sequenced post-workout |
### Dosing semantics
Each modality has a `contraindications_summary` field surfaced by the screening agent before any session is approved. The protocol builder always names the specific contraindication — never a generic hedge. Key contraindications by modality:
- **Full-Body Cryo:** pregnancy, uncontrolled hypertension, pacemakers, severe cardiovascular disease, Raynaud's
- **HBOT:** untreated pneumothorax, severe COPD with CO2 retention, uncontrolled seizures, bleomycin history
- **PBM Bed:** active photosensitizing medications (tetracyclines, retinoids, St. John's wort), pregnancy (caution), active malignancy at treatment field
- **Infrared Sauna:** pregnancy, severe cardiovascular disease, hemophilia, recent surgery, fever, medications affecting heat regulation
A `frankness preamble` is prepended to all DOC360 agent system prompts (see `seed-docs-consolidated-agents.ts`). It suppresses reflex medical disclaimers for on-staff use while preserving named contraindication gates for real safety calls.
---
## Agent Set
Four agents are exposed in the DOC'S chat picker via the `chat_agent_visibility` tenant setting. Other agents (delegation, heartbeats) exist but are filtered from the operator UI. Seeded and configured by `scripts/seed-docs-consolidated-agents.ts`.
### DocBot (`docbot`)
**Role:** Front-line Q&A for operators and patients on the floor.
**Autonomy:** Chat (supervised). Runs when an operator or patient types a question.
**Use for:** Patient questions, modality info, contraindication checks, anything that comes up during a visit. "Can Mia run Cryo today given she mentioned anticoagulants?"
**Tool groups:** entity (reads patient + protocol records), web (evidence lookup if needed)
**Triggering:** Operator-initiated in chat or patient-facing intake embed Q&A.
---
### Protocol Builder (`docs-protocol-builder`)
**Role:** Synthesizes a patient's multi-modality therapy plan from their intake record.
**Autonomy:** Chat (supervised) with structured output. Produces a `therapy-plan` entity the operator can review and confirm before any session starts.
**Use for:** New patient intake → protocol generation. Produces: intake summary, screening result, protocol lane rationale, progression plan (sessions 1–N with dose/frequency), operator-safe language check, recommended parameters.
**Tool groups:** entity (reads intake, writes therapy-plan), entity create
**Triggering:** Operator selects the patient intake record and asks Protocol Builder to generate a plan. Also triggered from the Intake & Protocol workspace Plan Builder view.
**Seeded action:** `docs-protocol-recommendation` appears on patient detail when required intake fields (`name`, `primary_goals`, `intent`, `screening_disposition`, `intake_notes`) and the patient `symptoms` relation are complete. It creates or updates one `therapy-plan` and links it back to the patient with `has-plan`. Missing intake or symptoms keeps the action blocked in the entity-pipes chip surface.
---
### Research (`research-agent`)
**Role:** Peer-reviewed evidence lookup on modalities, dosing, and target populations.
**Autonomy:** Chat (supervised) + autonomous heartbeat for evidence library refresh.
**Use for:** Evidence questions ("What does the literature say about PBM for neuropathy?"), grading sources, pulling new studies into the `source-item` / `evidence-claim` graph.
**Tool groups:** entity (reads/writes research graph), web (Exa search)
**Triggering:** Operator-initiated in Research workspace. Autonomous heartbeat scans for new claims to grade.
---
### Operations (`workspace-architect`)
**Role:** Scheduling, follow-up planning, workflow improvements, and system tuning.
**Autonomy:** Chat (supervised). Used by Nolan for end-of-day coordination and by Doc for strategic workflow changes.
**Use for:** Scheduling follow-up calls, reviewing the visit queue, improving nav/views/agent context, operational questions. "Which patients need a follow-up call this week?"
**Tool groups:** entity (reads/writes follow-up and visit records), admin-read (views, nav, tenant settings)
**Triggering:** Operator-initiated in Operations workspace or admin context.
---
## Wall PD Officer Recovery Program
The flagship cohort driving the DOC360 protocol library is the **Wall Police Department officer recovery program**.
**Context:** Officers face occupational load + shift-fatigue patterns — chronic low-back tightness from gear/belt, interrupted sleep from rotating shifts, stress-load recovery, and TBI/PTSD recovery needs (primarily addressed via HBOT). The program formalizes what DOC'S already does informally: structured protocol lanes built for first responders.
**Why it leads the protocol library:**
- Commercially grounded: DOC'S Wall NJ has a documented relationship with Wall PD and real clients in this lane
- Clinically distinct: the first-responder lane uses HBOT as the primary modality (TBI/PTSD recovery) whereas the general athletic recovery lanes center on PBM + Cryo
- Demo value: makes the protocol builder feel commercially real rather than hypothetical when shown to prospects
- Condition library anchor: "Law Enforcement Shift Fatigue" is the highest-demand-signal condition in the conditions library (`demand_signal: "high"`)
**Protocol slug:** `law-enforcement-officer-recovery`
**Modalities:** HBOT (primary) + Full-Body PBM (secondary) + Normatec (recovery add-on)
**Grant context:** TBD — a $50K grant has been referenced in project context but specific details are not confirmed in source scripts. Do not assert specifics until confirmed with Doc/Nolan.
**Demo patient:** Mia Torres (`mia-torres-intake`) — patrol officer, rotating shifts, low-back tightness, sleep disruption. Three sessions logged with a strong positive feedback trend. See `scripts/seed-docs-clinical-fixtures.ts`.
---
## Six Workspaces
DOC360 uses six workspaces scoped to the DOC'S tenant. Three are seeded by `scripts/seed-docs-workspaces.ts`; the operator and owner "home" workspaces are implicit from the tenant-level nav.
| Workspace | Slug | JTBD |
| ----------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **DOC'S Operator** | _(tenant default — Operations)_ | Nolan's daily floor workspace: today's visits, patient queue, quick visit log, modality setup, daily clinical close-out. Pinned record: Patient. Nav: Wellness OS, Command Center, Today's Visits, Schedule, Active Patients, Pending/Concerning Feedback, Modality Utilization. |
| **DOC'S Owner** | _(tenant default — strategic)_ | Doc's strategic workspace: cohort trends (Wall PD, athletic recovery, chronic pain), flagged patient review, protocol library approval, agent context tuning. |
| **Recovery & Wellness** | _(via Operations workspace)_ | Live patient visit tracking, feedback inbox, real-time modality utilization. Nolan's second most-used surface after the patient record. |
| **Research** | `research` | Modality evidence library, claims queue, evidence gaps, modality dossier. Used by the clinical reviewer and the Research agent. Nav: Modalities, Sources, Claims Queue, Evidence Gaps, Modality Dossier, Library. |
| **Intake & Protocol** | `intake-protocol` | New patient intake forms, therapy plans, plan builder, protocol library, screening rules. Pinned record: Patient. Nav: New Patient Intake, Therapy Plans, Plan Builder, Active Patient, Protocol Library. |
| **Operations** | `operations` | Today's visits, scheduling, modality utilization, patient feedback inbox. Operator daily command center. Pinned record: Patient. |
> The three workspace seeds (`research`, `operations`, `intake-protocol`) are created by `seed-docs-workspaces.ts`. The DOC'S Operator and Owner contexts are tenant-level nav configurations, not separate workspace rows.
---
## For Agents
When operating inside the DOC'S tenant, agents should:
1. **Use clinical vocabulary** — "visit", "modality", "dose", "feeling", "protocol", "protocol lane". Never expose "entity", "response", "task", "criteria-set", "session ID" in operator-facing text.
2. **Respect the frankness preamble** — suppresses reflex "consult a doctor" hedges for on-staff use. When a real contraindication applies, name it specifically. See `FRANKNESS_PREAMBLE` in `seed-docs-consolidated-agents.ts`.
3. **Acuity is the source of truth for commerce** — appointment, payment, pack balance, membership status. DOC360 is the source of truth for clinical — protocol, dose, visit log, feeling trend, flags. Never rebuild commerce in amble.
4. **Screening disposition gates protocol start** — a patient with `screening_disposition: "defer"` or `plan_status: "safety_hold"` must not receive a protocol recommendation without explicit operator override. Name the specific risk flag.
5. **Available tools via the four visible agents:**
- `createEntity` / `updateEntity` — create/update patient, visit, feedback, membership, therapy-plan, follow-up records
- `searchEntities` — find patients by name, filter visits by status, find open follow-ups
- `getEntityDetail` — read a patient's full protocol, visit history, feedback trend
- `webSearch` — evidence lookup via Exa (Research agent)
- `submitResponse` — score protocol response, grade evidence claims
6. **Workspace scoping** — Research workspace routes to evidence graph; Operations workspace routes to visit + feedback management; Intake & Protocol workspace routes to therapy plans. When asking "what workspace is this?", read `getActiveWorkspace()` from the URL context.
---
## Patient Progress Loop
The DOC'S patient detail view now carries the post-intake management loop directly on the patient record. It is tenant-local code under `features/custom/tenants/docs/details/` and does not add a platform route or new scheduling primitive.
The progress loop has four operator-facing sections:
- **Cross-protocol timeline** — combines linked visits and feedback into a dated modality/protocol arc.
- **Membership adherence** — prefers `membership-protocol-adherence`-like dimension data on the active membership, then falls back to completed visits versus the active therapy plan target.
- **Refine plan** — opens the active therapy plan when a surface action is available, or links to the therapy-plan route from the current DOC'S workspace.
- **Scheduling** — shows upcoming scheduled visits as read-only Acuity/DOC360 context. Acuity remains the appointment and commerce source of truth.
The adapter intentionally reads existing related entities only: visits, feedback, memberships, therapy plans, and protocols. Future relation-scored form work can write richer adherence dimensions without changing the patient-detail renderer.
---
## Protocol Session Edge Model (PR #2428 + PR #2465)
The DOC'S protocol model is edges-first. Every session is recorded as a `did-protocol` relation edge from a `visit` to a `protocol` (family preset or composite). There is no separate `treatment` entity type.
### Core shapes
| Concept | Where it lives |
| --- | --- |
| Protocol definition | `protocol` entity — either a single-modality **preset** (family member) or a **composite** (base `protocol` + ordered `includes-protocol` edges to per-modality presets) |
| Planned protocol for a visit | `visit.content.planned_visit_sequence[n].protocols[]` — snapshot refs to protocol entity ids, written at plan-build time |
| Per-visit session record | `did-protocol` edge from `visit` → `protocol` with `metadata.settings_override` (operator adjustments) and `metadata.scores` (response dimensions) |
| Visit-level overrides | `visit.content.protocol_overrides` — keyed by protocol entity id; merged at read time with the preset defaults |
| Composite components | `includes-protocol` edges from the composite `protocol` entity to its per-modality preset entities, ordered by `metadata.order` |
### Protocol entity discriminator
A `protocol` entity is a **composite** when it has one or more `includes-protocol` outbound edges. Single-modality presets have none. The legacy `protocol_scope: "composite"` field is a transitional fallback only (removed at promotion via `pnpm tenant:push`).
### Modality catalog
`parameter_schema` and `presets` are derived from the protocol-family entity type's `json_schema` and the seeded family preset entities — they are no longer stored as `modality.content` fields. The modality entity now carries dosing semantics and contraindication profile only.
### Deprecated keys (removed in PR #2465)
The following schema keys no longer exist on any entity type and are absent from all write payloads. They remain readable on pre-migration rows until the promotion runbook scrubs them:
| Key | Was on | Replaced by |
| --- | --- | --- |
| `planned_modality_variables` | `visit`, `therapy-plan` | `planned_visit_sequence[].protocols[]` refs |
| `actual_modality_variables` | `visit` | `did-protocol` edge `metadata.settings_override` |
| `template_modality_variables` | `protocol` | protocol-family preset entity content |
| `protocol_scope` | `protocol` | `includes-protocol` edges (edges-first discriminator) |
| `treatment_detail_type_slug` | `modality` | removed — no treatment subtypes |
| `composite_components` | `modality` | `includes-protocol` edges |
| `parameter_schema` | `modality` | protocol-family entity type json_schema |
| `presets` | `modality` | seeded protocol-family preset entities |
### Retired entity types
`treatment`, `treatment-detail`, and the six `*-treatment-detail` subtypes are retired. The `package` entity type (billing/credits) was split out from the treatment declarations and survives. The four treatment-scoped criteria sets (`protocol-service-fit`, `treatment-response`, `progression-readiness`, `protocol-adherence`) are replaced by the `visit-protocol-response` edge-scoring set introduced in PR #2428.
### Promotion runbook
Destructive data ops (scrub of deprecated content keys, deletion of 697 treatment rows, schema key removals via `pnpm tenant:push`, type-row retirement) run post dev→main promotion. See `documents/work/2026-06-12-docs-protocol-unification/runbook-pr2-promotion.md` for the exact ordered commands and verification queries.
---
## Design Decisions
### Why `modality_label` is denormalized on Visit
`modality_id` (FK to modality entity) is canonical for joins. `modality_label` is a denormalized human-readable string populated at session-log time. This lets every card, table, timeline, and session-history surface render the modality name without chasing a UUID through a second query. A missing label is surfaced explicitly as "Modality missing — update session log." — making data gaps visible to staff rather than silently omitting them.
### Why protocol lanes are a string, not an enum
Protocol lanes evolve as DOC'S expands to new populations (e.g., a Skin Health lane, a Post-Surgical lane). An open `string` field lets operators and agents name new lanes without a schema migration. The current lane set is defined by convention in `seed-docs-modalities.ts` and the conditions library, not by a database constraint.
### Why the frankness preamble uses a versioned sentinel
The preamble is injected into agent system prompts at seed time, not at request time. Versioned HTML-comment sentinels (`<!-- docs-frankness-preamble-v2 -->`) let the seed script detect and replace stale preambles on re-run without double-prepending. This avoids bloating prompts across repeated seed passes.
### Acuity as the commerce boundary
DOC360 deliberately does not replicate Acuity appointment booking, payment, or pack management. This is a single-source-of-truth decision: Acuity already has Nolan's trust for commerce. Rebuilding it in amble creates drift. The integration contract is: Acuity appointment → amble Visit (inbound sync); Acuity checkout → amble Visit status update. Commerce data in the patient header is a read-only mirror with a one-click deep-link to Acuity for any edit.
---
## Where to Look Next
| Resource | Purpose |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `scripts/seed-docs-clinical-entity-types.ts` | Source of truth for patient, visit, feedback, membership schemas |
| `scripts/seed-docs-modalities.ts` | Source of truth for the 6 modalities and research relation map |
| `scripts/dial-in-docs-demo.js` | Condition library (12 conditions), richer patient journeys (Mia Torres, Linda Carver), demo views |
| `scripts/seed-docs-consolidated-agents.ts` | Agent roster, frankness preamble, visibility allowlist |
| `scripts/seed-docs-workspaces.ts` | Workspace seeds (research, operations, intake-protocol) |
| `scripts/seed-docs-workspace-nav.ts` | Nav overlay per workspace (view slugs → nav rail items) |
| `content/docs/personas/docs-operator-nolan.mdx` | Nolan persona — JTBD, surface map, Acuity integration contract, demo bar |
| `features/custom/` | Patient and protocol custom detail views (PR #1298), operator wellness page (PR #1303) |
| `content/docs/features/workspaces.mdx` | Workspace mechanics (scope resolver, URL routing, nav overlay) |
| `content/docs/features/agent-system.mdx` | Agent registry, heartbeat, delegation, tool groups |
**PR references:**
- **PR #1298** — patient and protocol custom detail views
- **PR #1303** — operator wellness page (the `DOCS_WELLNESS_PAGE_SLUG` surface linked from the Operations workspace nav as "Wellness OS")
- **PR #1419** — 5 clinical-knowledge cards + 4 new detail pages + 25 relations graph edges (Round 2). Work folder: `documents/work/2026-05-14-docs-tenant-ui-gaps/`
- **PR #2428** — protocol unification PR1: protocol-family presets, unified log flow, stop minting treatment rows
- **PR #2465** — protocol unification PR2: treatment layer deleted, migration scripts, blocks off treatment graph, UX perfection pass. Work folder: `documents/work/2026-06-12-docs-protocol-unification/`