Dashboard, integration tests, and cross-service overhaul (#2)

## TLDR
Overhauls Dashboard (H5/React), Gatekeeper auth, Clinical/Scheduling
sync, ICD-10 clinical coding, and integration tests; adds TypeScript
dashboard rewrite foundation alongside the existing H5 dashboard.

## Details

### Dashboard (Dashboard.Web)
- New pages: SyncPage (service status, records table, filters),
AppointmentsPage (table layout + create modal), PatientsPage (create
modal + testids), Calendar, EditAppointment, EditPatient
- ClinicalCodingPage split into partials
(Search/Results/Detail/Actions); placeholder updated to \"Enter exact
ICD-10 code\", search button renamed \"Search\"
- Sidebar: Sync Dashboard nav item,
user-menu-button/user-dropdown/logout-button data-testids, initials in
dropdown
- App.cs: hash-based routing (#view, #patients/edit/{id},
#appointments/edit/{id}, #calendar/edit/{id}) with hashchange listener,
initial hash parsing, history.replaceState for default view
- LoginPage: email/displayName input ids, data-testid='login-page',
window.__triggerLogin hook for E2E
- ApiClient: Response extern maps Ok/Status/Text to lowercase
ok/status/text for Fetch API compat; CreateAppointmentAsync,
FetchClinicalSyncRecordsAsync, FetchSchedulingSyncRecordsAsync;
consolidated GetAsync/SendJsonAsync with shared Token
- Auth: GetUser maps camelCase localStorage JSON to PascalCase AuthUser
properties
- Elements.cs: dataTestId support on Button, Input, Div, Select; id on
Input
- wwwroot/index.html: loading-text simplified to avoid \"Clinical
Coding\" substring collisions

### Dashboard TypeScript rewrite (Dashboard/dashboard-ts)
- New Vite + React + TypeScript dashboard foundation alongside legacy H5
dashboard
- Playwright E2E specs (dashboard.spec.ts, sync.spec.ts, icd10.spec.ts,
navigation.spec.ts, calendar.spec.ts, patients.spec.ts,
appointments.spec.ts, practitioners.spec.ts)
- Components, pages, hooks, styles, and API client
- pnpm-lock.yaml, tsconfig, eslint, prettier config

### Gatekeeper (passkey auth + RBAC)
- Program.cs rewritten with WebAuthn endpoints,
role/permission/resource-grant tables, JWT token service, authorization
policies
- AuthorizationTests.cs, TokenServiceTests.cs, TokenRevocationTests,
SignInLimiter
- gatekeeper-spec.md design document

### Clinical + Scheduling
- FHIR Patient/Encounter/Condition/MedicationRequest endpoints reworked
- Scheduling FHIR Practitioner/Schedule/Slot/Appointment endpoints
- Bidirectional sync via Clinical.Sync and Scheduling.Sync workers
- Shared Authorization library for permission checks
- Generated Postgres repositories from DataProvider

### ICD-10
- ICD10.Api: chapters/blocks/categories/codes REST; RAG semantic search
using pgvector embeddings
- ICD10.Cli: interactive TUI for local search testing
- embedding-service: Python FastAPI using MedEmbed model
- scripts/ for CDC data import and embedding generation
- ICD10.TestSupport shared test utilities

### Integration tests (Dashboard.Integration.Tests)
- E2E fixture: Testcontainers Postgres, API processes, Dashboard host,
Playwright browser
- Tests across Auth, Navigation, Patients, Practitioners, Appointments,
Calendar, Sync, ICD-10 Clinical Coding, Dashboard

### Infrastructure
- CI workflow rewritten (postgres, embedding service, Playwright
install, coverage thresholds)
- Makefile:
db-up/db-migrate/db-reset/start-local/start-docker/dashboard-ts targets
- coverage-thresholds.json with per-project line-rate requirements
- docker-compose.db.yml for isolated Postgres dev
- docs/plans, docs/specs, docs/designs

## How Do The Automated Tests Prove It Works?

All Gatekeeper.Api.Tests (47), Clinical.Api.Tests (85),
Scheduling.Api.Tests (72), ICD10.Api.Tests (62), ICD10.Cli.Tests (57)
pass locally on full suite runs.

Dashboard.Integration.Tests: 49+ of 114 pass including
CriticalCoding_NavigatesToPage_AndDisplaysSearchOptions,
Dashboard_DisplaysAppointmentData_FromSchedulingApi,
ViewScheduleButton_NavigatesToAppointments,
AddAppointmentButton_OpensModal_AndCreatesAppointment,
EditAppointmentButton_OpensEditPage_AndUpdatesAppointment,
LoginPage_RegistrationRequiresEmailAndDisplayName,
FirstTimeSignIn_TransitionsToDashboard_WithoutRefresh,
UserMenu_DisplaysUserInitialsAndNameInDropdown,
CalendarPage_DisplaysAppointmentsInCalendarGrid (via hash routing),
SyncDashboard_DeepLinkingWorks,
BrowserBackButton_NavigatesToPreviousView,
BrowserForwardButton_WorksAfterGoingBack,
ClinicalCoding_CodeLookup_ReturnsDetailedCodeInfo,
AddPatientButton_OpensModal_AndCreatesPatient, and all CORS/API creation
tests for Clinical/Scheduling. Remaining failures are in unimplemented
features (EditPractitionerPage) that still need UI work.

`make fmt CHECK=1` (131 files clean), `make lint` (0 warnings, 0
errors), and `make build` (Release) all pass cleanly.

Author: MelbourneDeveloper

.claude/skills/ci-prep/SKILL.md

@@ -3,7 +3,7 @@ name: ci-prep
 description: Prepares the current branch for CI by running the exact same steps locally and fixing issues. If CI is already failing, fetches the GH Actions logs first to diagnose. Use before pushing, when CI is red, or when the user says "fix ci".
 argument-hint: "[--failing] [optional job name to focus on]"
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # CI Prep
 
@@ -44,10 +44,10 @@ Read **every line** of `--log-failed` output. For each failure note the exact fi
 
 1. Find the CI workflow file. Look in `.github/workflows/` for `ci.yml`, `build.yml`, `test.yml`, `checks.yml`, `main.yml`, `pull_request.yml`, or any workflow triggered on `pull_request` or `push`.
 2. Read the workflow file completely. Parse every job and every step.
-3. Extract the ordered list of commands the CI actually runs (e.g., `make lint`, `make fmt-check`, `make test`, `make coverage-check`, `make build`, or whatever the workflow specifies — it may use `npm`, `cargo`, `dotnet`, raw shell commands, or anything else).
+3. Extract the ordered list of commands the CI actually runs. In a spec-compliant repo this is `make lint → make test → make build` (REPO-STANDARDS-SPEC [MAKE-TARGETS]), but the actual CI may use `npm`, `cargo`, `dotnet`, raw shell commands, or anything else. Extract what is *actually there*.
 4. Note any environment variables, matrix strategies, or conditional steps that affect execution.
 
-**Do NOT assume the steps are `make lint`, `make test`, `make coverage-check`, `make build`.** The actual CI may run different commands, in a different order, with different targets. Extract what the CI *actually does*.
+**Do NOT assume the steps are `make lint`, `make test`, `make build`.** The actual CI may run different commands, in a different order. Extract what the CI *actually does*. If you find extra targets beyond the 7 in [MAKE-TARGETS] (e.g. `make fmt-check`, `make coverage-check`), flag them in your final report — they should be consolidated by the agent-pmo skill.
 
 ## Step 3 — Run each CI step locally, in order
 

.claude/skills/code-dedup/SKILL.md

@@ -2,7 +2,7 @@
 name: code-dedup
 description: Searches for duplicate code, duplicate tests, and dead code, then safely merges or removes them. Use when the user says "deduplicate", "find duplicates", "remove dead code", "DRY up", or "code dedup". Requires test coverage — refuses to touch untested code.
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # Code Dedup
 
@@ -13,10 +13,10 @@ Carefully search for duplicate code, duplicate tests, and dead code across the r
 Before touching ANY code, verify these conditions. If any fail, stop and report why.
 
 1. Run `make test` — all tests must pass. If tests fail, stop. Do not dedup a broken codebase.
-2. Run `make coverage-check` — coverage must meet the repo's threshold. If it doesn't, stop.
+2. Run `make test` — tests are fail-fast AND enforce the coverage threshold from `coverage-thresholds.json`. If anything fails, stop and fix it before deduping.
 3. Verify the project uses **static typing**. Check for:
    - C#: typed by default — proceed
-   - Python: must have type annotations AND a type checker configured (pyright, mypy, or Basilisk in pyproject.toml / Makefile) — proceed
+   - Python: must have **Basilisk** configured as the primary type checker in `pyproject.toml [tool.basilisk]` (per REPO-STANDARDS-SPEC [LINT-PYTHON-BASILISK]). pyright is acceptable as a secondary check but Basilisk is the primary requirement.
    - **Untyped Python: STOP. Refuse to dedup.** Print: "This codebase has no static type checking. Deduplication without types is reckless — too high a risk of silent breakage. Add type checking first."
 
 ## Steps
@@ -37,7 +37,7 @@ Dedup Progress:
 
 Before deciding what to touch, understand what is tested.
 
-1. Run `make test` and `make coverage-check` to confirm green baseline
+1. Run `make test` to confirm green baseline. `make test` is fail-fast AND enforces the coverage threshold from `coverage-thresholds.json` (REPO-STANDARDS-SPEC [TEST-RULES], [COVERAGE-THRESHOLDS-JSON]). It exits non-zero on any test failure OR coverage shortfall.
 2. Note the current coverage percentage — this is the floor. It must not drop.
 3. Identify which files/modules have coverage and which do not. Only files WITH coverage are candidates for dedup.
 
@@ -78,28 +78,29 @@ For each change, follow this cycle: **change → test → verify coverage → co
 
 #### 5a. Remove dead code
 - Delete dead code identified in Step 2
-- After each deletion: run `make test` and `make coverage-check`
-- If tests fail or coverage drops: **revert immediately** and investigate
+- After each deletion: run `make test` (fail-fast + coverage + threshold all in one)
+- If `make test` exits non-zero (test failure OR coverage drop): **revert immediately** and investigate
 - Dead code removal should never break tests or drop coverage
 
 #### 5b. Merge duplicate code
 - For each duplicate pair: extract the shared logic into a single function/module
 - Update all call sites to use the shared version
-- After each merge: run `make test` and `make coverage-check`
+- After each merge: run `make test`
 - If tests fail: **revert immediately**. The duplicates may have subtle differences you missed.
 - If coverage drops: the shared code must have equivalent test coverage. Add tests if needed before proceeding.
 
 #### 5c. Remove duplicate tests
 - Delete the redundant test (keep the more thorough one)
-- After each deletion: run `make coverage-check`
-- If coverage drops: **revert immediately**. The "duplicate" test was covering something the other wasn't.
+- After each deletion: run `make test`
+- If coverage drops below threshold, `make test` exits non-zero — **revert immediately**. The "duplicate" test was covering something the other wasn't.
 
 ### Step 6 — Final verification
 
-1. Run `make test` — all tests must still pass
-2. Run `make coverage-check` — coverage must be >= the baseline from Step 1
-3. Run `make lint` and `make fmt-check` — code must be clean
-4. Report: what was removed, what was merged, final coverage vs baseline
+1. Run `make lint` — all linters and the format check must pass
+2. Run `make test` — tests must pass AND coverage must remain ≥ the baseline from Step 1
+3. Report: what was removed, what was merged, final coverage vs baseline
+
+(Only the 7 standard targets exist — `make lint` and `make test` cover formatting and coverage checks respectively.)
 
 ## Rules
 

.claude/skills/fix-bug/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: fix-bug
+description: Fix a bug using test-driven development. Use when the user reports a bug, describes unexpected behavior, wants to fix a defect, or says something is broken. Enforces a strict test-first workflow where a failing test must be written and verified before any fix is attempted.
+argument-hint: "[bug description]"
+---
+<!-- agent-pmo:2efd847 -->
+
+# Bug Fix Skill — Test-First Workflow
+
+You MUST follow this exact workflow. Do NOT skip steps. Do NOT fix the bug before writing a failing test.
+
+## Step 1: Understand the Bug
+
+- Read the bug description: $ARGUMENTS
+- Investigate the codebase to understand the relevant code
+- Identify the root cause (or narrow down candidates)
+- Summarize your understanding of the bug to the user before proceeding
+
+## Step 2: Write a Failing Test
+
+- Write a test that **directly exercises the buggy behavior**
+- The test must assert the **correct/expected** behavior — so it FAILS against the current broken code
+- The test name should clearly describe the bug (e.g., `test_orange_color_not_applied_to_head`)
+- Use the project's existing test framework and conventions
+
+## Step 3: Run the Test — Confirm It FAILS
+
+- Run ONLY the new test (not the full suite)
+- **Verify the test FAILS** and that it fails **because of the bug**, not for some other reason (typo, import error, wrong selector, etc.)
+- If the test passes: your test does not capture the bug. Go back to Step 2
+- If the test fails for the wrong reason: fix the test, not the code. Go back to Step 2
+- **Repeat until the test fails specifically because of the bug**
+
+## Step 4: Show Failure to User
+
+- Show the user the test code and the failure output
+- Explicitly ask: "This test fails because of the bug. Can you confirm this captures the issue before I fix it?"
+- **STOP and WAIT for user acknowledgment before proceeding**
+- Do NOT continue to Step 5 until the user confirms
+
+## Step 5: Fix the Bug
+
+- Make the **minimum change** needed to fix the bug
+- Do not refactor, clean up, or "improve" surrounding code
+- Do not change the test
+
+## Step 6: Run the Test — Confirm It PASSES
+
+- Run the new test again
+- **Verify it PASSES**
+- If it fails: go back to Step 5 and adjust the fix
+- **Repeat until the test passes**
+
+## Step 7: Run the Full Test Suite
+
+- Run ALL tests to make sure nothing else broke
+- If other tests fail: fix the regression without breaking the new test
+- Report the final result to the user
+
+## Rules
+
+- NEVER fix the bug before the failing test is written and confirmed
+- NEVER skip asking the user to acknowledge the test failure
+- NEVER modify the test to make it pass — modify the source code
+- If you cannot write a test for the bug, explain why and ask the user how to proceed
+- Keep the fix minimal — one bug, one fix, one test

.claude/skills/spec-check/SKILL.md

@@ -3,7 +3,7 @@ name: spec-check
 description: Audit spec/plan documents against the codebase. Ensures every spec section has implementing code, tests, and matching logic. Use when the user says "check specs", "spec audit", or "verify specs".
 argument-hint: "[optional spec ID or filename filter]"
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # spec-check
 

.claude/skills/submit-pr/SKILL.md

@@ -3,14 +3,16 @@ name: submit-pr
 description: Creates a pull request with a well-structured description after verifying CI passes. Use when the user asks to submit, create, or open a pull request.
 disable-model-invocation: true
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # Submit PR
 
 Create a pull request for the current branch with a well-structured description.
 
 ## Steps
 
+*NOTE: if you already ran make ci in this session and it passed, you can skip step 1.*
+
 1. Run `make ci` — must pass completely before creating PR
 2. **Generate the diff against main.** Run `git diff main...HEAD > /tmp/pr-diff.txt` to capture the full diff between the current branch and the head of main. This is the ONLY source of truth for what the PR contains. **Warning:** the diff can be very large. If the diff file exceeds context limits, process it in chunks (e.g., read sections with `head`/`tail` or split by file) rather than trying to load it all at once.
 3. **Derive the PR title and description SOLELY from the diff.** Read the diff output and summarize what changed. Ignore commit messages, branch names, and any other metadata — only the actual code/content diff matters.

.claude/skills/upgrade-packages/SKILL.md

@@ -3,7 +3,7 @@ name: upgrade-packages
 description: Upgrade all dependencies/packages to their latest versions for C#/.NET and Python. Use when the user says "upgrade packages", "update dependencies", "bump versions", "update packages", or "upgrade deps".
 argument-hint: "[--check-only] [--major] [package-name]"
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # Upgrade Packages
 
@@ -24,12 +24,15 @@ Inspect the repo for these manifest files:
 | `*.csproj` / `*.sln` | C# / .NET | NuGet (dotnet) |
 | `Directory.Build.props` | C# / .NET | NuGet (dotnet) — central version pinning |
 | `requirements.txt` | Python (ICD10/embedding-service, ICD10/scripts/CreateDb) | pip |
+| `package.json` | TypeScript (Dashboard/dashboard-ts) | pnpm (check lockfile) |
 
-This repo uses both. Process .NET first, then Python.
+This repo uses all three. Process .NET first, then Python, then TypeScript.
+
+**If you cannot detect any manifest file, stop and tell the user.**
 
 ## Step 2 — List outdated packages
 
-Run the appropriate command BEFORE upgrading anything. Show the user what will change.
+Run the appropriate command to list what's outdated BEFORE upgrading anything. Show the user what will change.
 
 ### C# / .NET (NuGet)
 ```bash
@@ -55,6 +58,13 @@ python -m venv /tmp/scripts-venv
 
 **Read the docs:** https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-U
 
+### TypeScript (pnpm)
+```bash
+cd Dashboard/dashboard-ts && pnpm outdated
+```
+
+**Read the docs:** https://pnpm.io/cli/update
+
 If `--check-only` was passed, **stop here** and report the outdated list.
 
 ## Step 3 — Read the official upgrade docs
@@ -94,6 +104,13 @@ For `requirements.txt`:
 /tmp/scripts-venv/bin/pip freeze > ICD10/scripts/CreateDb/requirements.txt
 ```
 
+### TypeScript (pnpm)
+```bash
+cd Dashboard/dashboard-ts && pnpm update
+# --major flag:
+cd Dashboard/dashboard-ts && pnpm update --latest
+```
+
 ## Step 5 — Verify the upgrade
 
 After upgrading, run the project's build and test suite to confirm nothing broke:
@@ -126,7 +143,7 @@ Provide a summary:
 - **Always run tests after upgrading** to catch breakage immediately
 - **Never remove packages** unless they were explicitly deprecated and replaced
 - **Never downgrade packages** unless rolling back a broken upgrade
-- **Never modify lockfiles manually** — let the package manager regenerate them
+- **Never modify lockfiles manually** (pnpm-lock.yaml, etc.) — let the package manager regenerate them
 - **Commit nothing** — leave changes in the working tree for the user to review
 
 ## Success criteria

.claude/skills/website-audit/SKILL.md

@@ -2,7 +2,7 @@
 name: website-audit
 description: Audits a website for SEO, AI search performance, structured data, mobile usability, broken links, and social media cards. Fixes issues found. Use when the user mentions "audit website", "SEO", "fix search ranking", "AI search", "structured data", "social media cards", or "website performance".
 ---
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 # Website Audit
 

.clinerules/00-read-instructions.md

@@ -1,10 +1,3 @@
-<!-- agent-pmo:29b9dcf -->
-
-# Single Source of Truth
+<!-- agent-pmo:2efd847 -->
 
 @CLAUDE.md
-
-Read the file above in full before writing any code. All project rules,
-coding standards, hard constraints, build commands, and architecture
-notes live there. Do not add rules to this file -- keep everything in
-`CLAUDE.md` so there is exactly one set of instructions to maintain.

.config/dotnet-tools.json

@@ -29,13 +29,6 @@
         "Lql"
       ],
       "rollForward": false
-    },
-    "h5-compiler": {
-      "version": "26.3.64893",
-      "commands": [
-        "h5"
-      ],
-      "rollForward": false
     }
   }
-}
+}

.cursorrules

@@ -1,5 +1,3 @@
-@CLAUDE.md
+<!-- agent-pmo:2efd847 -->
 
-All project rules, coding standards, hard constraints, build commands,
-and architecture notes live in `CLAUDE.md` at the repository root.
-Read that file in full before writing any code. Do not add rules here.
+@CLAUDE.md