# Agent instructions — CarePath unified

CarePath is one unified medical AI product with two clearly separated user-facing modules:

1. **Ghi chép bệnh án AI**
   Internal/technical term: AI Scribe / scriber
   Backend: `scribe/carepath`, `/api/v1/*`
   Purpose: listen to a consultation and help generate structured clinical notes.

2. **Phiên dịch khám bệnh trực tiếp**
   Internal/technical term: Medical Interpreter / interpreter
   Backend: `interpreter/app`, `/api/*` + `/ws/*`
   Purpose: live two-way interpretation between Vietnamese doctors and English-speaking patients.

The app is served by one FastAPI process plus two Vite frontends:

* `scribe/frontend/` at `/`
* `interpreter/frontend/` at `/phien-dich-y-khoa/` (`/console/` is a legacy redirect)

## Interpreter status

After restructure Phase 7, the Interpreter is on hold. Accept only bug fixes,
safety fixes, and required operational maintenance there; new product work is
focused on the Scribe training track unless the owner explicitly reopens it.

`docs/history/PLAN.md` and `docs/history/DEMO-SITE-PLAN.md` are historical build
plans for the interpreter and demo site. `docs/history/MERGE-PLAN.md` is the
executed unification plan, M.0–M.8 done, and `docs/history/JUDGE.md` is its
review protocol.
`docs/research.md` holds the interpreter safety background.

## Product UX contract

CarePath must be Vietnamese-first.

The target users may include Vietnamese doctors who are not comfortable with English medical software terms. Therefore, the UI must explain workflows by user intent, not by English product names.

### Primary user-facing labels

Use these as primary UI labels:

* `Ghi chép bệnh án AI`
* `Phiên dịch khám bệnh trực tiếp`

Use these as primary CTAs:

* `Bắt đầu ghi chép`
* `Bắt đầu phiên dịch`

Use this homepage framing:

```text
Bạn muốn hỗ trợ việc gì hôm nay?
```

### Secondary/internal labels

The following English terms may appear only as secondary helper text, developer labels, comments, docs, or internal route/component names:

* Scribe
* AI Scribe
* Interpreter
* Medical Interpreter
* Console
* Transcript
* Encounter
* Session

Do not use `Scribe` or `Interpreter` as primary labels on user-facing screens.

### Required distinction between the two modules

The landing page must make it obvious that these are two different workflows:

#### Ghi chép bệnh án AI

Explain as:

```text
AI nghe buổi khám và tạo ghi chú y khoa có cấu trúc.
```

Use when:

```text
Phù hợp khi bác sĩ muốn giảm thời gian nhập liệu sau khám.
```

Clarify that the doctor must review the output before use.

#### Phiên dịch khám bệnh trực tiếp

Explain as:

```text
Dịch hai chiều giữa bác sĩ tiếng Việt và bệnh nhân tiếng Anh trong lúc khám.
```

Use when:

```text
Phù hợp khi bác sĩ và bệnh nhân không cùng ngôn ngữ.
```

Clarify that the system translates only and must not provide medical advice.

### Every user-facing screen must answer

1. Tôi đang dùng chức năng nào?
2. Chức năng này giúp việc gì?
3. Tôi cần bấm gì tiếp theo?
4. Có rủi ro hoặc giới hạn nào bác sĩ cần biết không?

### Vietnamese copy rules

* Vietnamese text must be clear, short, and professional.
* Preserve Vietnamese diacritics.
* Keep text NFC-normalized.
* Avoid unnecessary English.
* Avoid startup/marketing buzzwords on clinical workflow screens.
* Prefer concrete action language over abstract product names.

Good:

```text
Ghi chép bệnh án AI
Phiên dịch khám bệnh trực tiếp
Bắt đầu ghi chép
Bắt đầu phiên dịch
Bác sĩ nói tiếng Việt, bệnh nhân nghe tiếng Anh
```

Avoid as primary UI:

```text
Scribe
Interpreter
Session
Encounter
Transcript
Start session
Launch interpreter
```

## Non-negotiable safety invariants

This file is the current safety contract. `docs/history/PLAN.md §2` preserves
the original MVP source for historical context.

1. Translate-only: never generate medical advice, diagnoses, or drug recommendations.
2. High/critical-risk turns are blocked from patient display and TTS until doctor confirms.
3. Low-confidence output is always visibly flagged, never silently delivered.
4. Raw audio is never persisted. Use memory-only processing. No audio columns, no temp files.
5. No mic capture before recorded consent.
6. On any pipeline or reviewer failure, fail closed: keep the turn blocked, show the doctor raw source and translation, offer escalation. Never fail open to the patient.

## Implementation workflow for agents

For UX or product-flow changes, do not implement immediately.

First produce or update a plan in `docs/ux-redesign-carepath.md` with:

1. Current UX problem
2. Proposed flow
3. Affected routes/pages/components
4. Vietnamese-first copy
5. Implementation stories
6. Dependencies between stories
7. Acceptance criteria
8. Validation commands
9. Risks and fallback behavior

Then implement one story at a time.

### Recommended story order for UX redesign

1. Update Vietnamese-first product naming and copy.
2. Redesign the landing page into two clear workflow cards.
3. Add or clarify separate entry routes for the two modules.
4. Add pre-start onboarding/explanation screens.
5. Improve empty/loading/error states in Vietnamese.
6. Run QA for mobile, accessibility, safety copy, and route regressions.

Do not combine homepage redesign, routing changes, and audio/backend logic changes in one large patch.

### Agent behavior

* Keep changes small and focused.
* Preserve existing working functionality.
* Do not rewrite backend, audio, risk, or websocket logic unless the current story explicitly requires it.
* Do not introduce new dependencies without documenting why.
* Prefer existing components and styling patterns.
* When changing user-facing Vietnamese text, check diacritics and consistency.
* When changing risk-engine behavior, update fixtures and evals.
* When changing product copy only, avoid touching medical logic.

## Commands

### Combined service

```bash
uvicorn carepath.main:app --app-dir scribe --reload
```

Requires:

```bash
pip install -e ".[dev]" -e "./shared" -e "./interpreter[dev]"
```

### Scriber and combined tests

```bash
pytest
python scripts/smoke_backend.py
python scripts/build_term_artifacts.py --check
```

### Interpreter backend alone

```bash
cd interpreter && uvicorn app.main:app --reload
pytest
```

### Console

```bash
cd interpreter/frontend && npm run dev
npm test
npx playwright test
```

### Demo site

```bash
cd scribe/frontend && npm run dev
npm test
npm run build
npm run e2e
```

`npm run build` is also the diacritics gate.

### Full mock-mode run

Set this in `.env`:

```bash
PROVIDER_MODE=mock
```

Mock mode must work with no API keys.

### Eval regression

```bash
python interpreter/eval/run_eval.py --set interpreter/eval/fixtures/eval_starter.tsv --providers mock
```

## Conventions

* Python 3.12.
* Python code must be ruff-formatted and type-hinted.
* Use pure functions for normalization and risk rules.
* TypeScript must be strict.
* Components should be small.
* Keep state minimal: context/zustand is allowed, Redux is not.
* `shared/carepath_shared/terms/medical_terms.json` is the canonical medical
  term source. Regenerate `data/medical_lexicon.json` and
  `interpreter/app/glossary/data/seed_glossary.csv` with
  `python scripts/build_term_artifacts.py`; do not hand-edit generated artifacts.
* Risk lexicons under `interpreter/app/risk/lexicons/` remain separate
  interpreter safety data. Clinicians edit data, not code.
* Every risk-engine behavior change updates `interpreter/eval/fixtures/risk_cases.jsonl`.
* The fixture run is the test.
* Zero misses on critical fixtures is a hard gate.
* Secrets only via env.
* `.env` is gitignored.
* `.env.example` must stay current.
* No new dependencies without noting why in the PR.
* Vietnamese text is data, not decoration: always NFC-normalized, diacritics preserved.
* Tests must include diacritic-stripped variants where matching allows it.

## Acceptance criteria for UX clarity changes

A UX clarity change is not done un  less all of the following are true:

1. A Vietnamese doctor can understand the two workflows without knowing the words `Scribe` or `Interpreter`.
2. The landing page clearly separates:

   * `Ghi chép bệnh án AI`
   * `Phiên dịch khám bệnh trực tiếp`
3. Each workflow has a distinct CTA.
4. Each workflow explains when to use it.
5. English terms appear only as secondary helper text, not primary labels.
6. Mobile layout remains clear.
7. Existing core functionality still works.
8. Safety invariants remain unchanged.
9. Build and relevant tests pass.

<!-- HARNESS:START -->
## Harness workflow

This repository uses Repository Harness for durable task intake, proof, and
decision records. This block adds to the CarePath instructions above; it does
not replace them.

Priority, highest first:

1. The current user request and the safety and product rules in this file.
2. Current product contracts in `docs/product/`.
3. Selected story packets in `docs/stories/` and accepted decisions in
   `docs/decisions/`.
4. Executable tests and the Harness proof matrix.
5. `docs/history/` as context only.

Before any task, read `README.md`, `docs/HARNESS.md`, and
`docs/FEATURE_INTAKE.md`; then run
`.\scripts\bin\harness-cli.exe query matrix` on Windows. Classify and record
the task as `tiny`, `normal`, or `high-risk` before changing code.

- Tiny work records an intake and runs the relevant quick proof.
- Normal work also updates one story packet and its proof record.
- High-risk work uses `docs/templates/high-risk-story/`, records a decision
  when it changes architecture, data, safety, APIs, or validation, and waits
  for human direction if its scope is ambiguous.
- A UX or product-flow task still must first update
  `docs/ux-redesign-carepath.md`, then follow the Harness lane requirements.
- Before a step that could use an external tool, query the available provider:
  `.\scripts\bin\harness-cli.exe query tools --capability <capability> --status present`.
  A missing provider is a clean skip, never a reason to invent a dependency.
- Finish normal and high-risk work with a Harness trace that records the real
  validation outcome and any friction. Do not claim proof that was not run.
<!-- HARNESS:END -->