DOC360

## 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/`