# Command Dashboard Health Risk Cockpit

Use when an ultra-sensitive Health module in a command dashboard is safe but too passive/technical: the user needs a medically useful operator cockpit without exposing raw Health data.

## Trigger

- Existing Health page primarily shows pipeline/backup/source/contract metadata and users find it practically useless.
- User asks for an "Ampel" / risk cockpit for Health while keeping reports, labs, PDFs, OCR, symptoms, and raw records out of JARVIS.
- A protected specialist Health dashboard may exist and should be opened by link-only handoff, not embedded or parsed.

## Pattern

1. **Keep JARVIS as a command center, not a HealthManager clone**
   - Do not rebuild HealthManager inside JARVIS.
   - Do not iframe the Health dashboard.
   - Do not parse reports, dashboard HTML, PDFs, OCR, DB rows, CSV/JSON raw exports, file names, or Drive links.
   - If a Health dashboard exists, serve/open it only as a protected link-only handoff and report status as `configured_protected`.

2. **Move technical metadata down**
   - Top of `/health`: risk cockpit, not contract/source/backup panels.
   - Put pipeline, backup/data freshness, source health, and contract under a collapsed/secondary "Technischer Datenstatus" section.

3. **Use a fixed risk snapshot contract**
   - Create a strict schema like `health-risk-snapshot.schema.json` with no dynamic keys and no raw objects.
   - Fixed domains, fixed enums, short safe reasons only.
   - Recommended domains:
     - `behcet_activity`
     - `eye_risk`
     - `vascular_thrombosis_risk`
     - `inflammation_lab_trend`
     - `medication_safety`
     - `controls_data_status`
   - Status enum: `green|yellow|red|unknown`.
   - Action enum: `none|watch|contact_doctor|urgent`.
   - Freshness enum: `fresh|stale|missing|unknown`.

4. **Do not invent medical thresholds**
   - Missing safe data => `unknown`.
   - Stale safe data => conservative `yellow`.
   - Synthetic emergency flags may drive test-only `red`.
   - Personal thresholds must be configurable and confirmed by the user/doctor before live interpretation.
   - Document threshold policy separately.

5. **Map Overview to risk, not plumbing**
   - Health overview KPIs should be at most:
     - `Overall Health Risk`
     - `Vascular risk`
     - `Data freshness`
   - Attention items are short labels only, e.g. `Health risk red: eye symptoms`, `Vascular warning signs`, `Lab trend stale`, `Health dashboard unreachable`.
   - Do not show exact lab values or Health filenames on the global overview.

6. **Protected Health dashboard handoff**
   - It is acceptable to check existence of a known dashboard file/server without reading/parsing its contents.
   - If serving a static Health dashboard for local/Tailnet demo, use an ignored runtime process/PID/log area and expose one route only.
   - Never commit dashboard files, `.env`, runtime paths, logs, DBs, PDFs, OCR, raw reports, screenshots, or raw responses.

7. **Verification**
   - Backend tests: fixed domain IDs, strict schema, no forbidden strings/path/file leaks, unknown on missing data, red on synthetic emergency flags, yellow on stale data, max 3 Health KPIs.
   - Frontend tests: six risk cards, technical status secondary/collapsed, Health dashboard button disabled/enabled by config, no iframes, no Health actions.
   - Smoke: `/health` contains the cockpit and all six domains; `/api/overview` uses risk KPIs rather than backup/pipeline main KPIs; forbidden Health strings and path/media/report leaks are absent.

## Pitfalls

- A "safe" Health page can still be useless if it only says everything is locked. The operator needs a small number of meaningful risk categories.
- `locked_by_policy` should not be sold as the primary Health value. Use it only for detail links; the cockpit itself should remain useful.
- Do not treat a protected dashboard link as permission to scrape or summarize its content.
- Avoid wording that implies JARVIS diagnosed the user; use category/status/action language and refer details to HealthManager/clinicians.