Dashboard, integration tests, and cross-service overhaul

.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

.dockerignore

@@ -0,0 +1,14 @@
+# agent-pmo:2efd847
+
+**/bin/
+**/obj/
+**/node_modules/
+**/dist/
+**/.vite/
+**/coverage/
+**/playwright-report/
+**/test-results/
+TestResults/
+.git/
+.too_many_cooks/
+.DS_Store

.github/copilot-instructions.md

@@ -1,4 +1,4 @@
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 @CLAUDE.md
 

.github/pull_request_template.md

@@ -1,4 +1,4 @@
-<!-- agent-pmo:29b9dcf -->
+<!-- agent-pmo:2efd847 -->
 
 ## TLDR
 <!-- One sentence: what does this PR do? -->

.github/workflows/ci.yml

@@ -1,4 +1,4 @@
-# agent-pmo:29b9dcf
+# agent-pmo:2efd847
 name: CI
 
 on:
@@ -15,6 +15,7 @@ jobs:
   ci:
     name: CI
     runs-on: ubuntu-latest
+    # TIMEOUT EXCEPTION: Postgres startup, DB migration, embedding service model load, and 5 test projects with coverage require ~20 min.
     timeout-minutes: 30
     env:
       DB_PASSWORD: changeme
@@ -27,14 +28,18 @@ jobs:
         with:
           dotnet-version: '10.0.x'
 
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '24'
+
+      - name: Enable pnpm
+        run: |
+          corepack enable
+          corepack prepare pnpm@10.33.0 --activate
+
       - run: dotnet restore
       - run: dotnet tool restore
 
-      # csharpier needs no DB -- run it first so format issues fail
-      # before paying the cost of docker, codegen, or Playwright.
-      - name: Format check
-        run: make fmt-check
-
       - name: Start Postgres (pgvector) via docker compose
         run: make db-up
 
@@ -44,7 +49,10 @@ jobs:
       # `make lint` runs the full Release build, which triggers
       # `dotnet DataProvider postgres` codegen against the live database,
       # so it has to come after db-up + db-migrate. Still kept ahead of
-      # the embedding service / Playwright steps to fail fast on warnings.
+      # the embedding service steps to fail fast on warnings.
+      - name: Format check
+        run: make fmt CHECK=1
+
       - name: Lint
         run: make lint
 
@@ -64,21 +72,9 @@ jobs:
           docker compose logs
           exit 1
 
-      - name: Install Playwright browsers
-        run: |
-          dotnet build Dashboard/Dashboard.Integration.Tests/Dashboard.Integration.Tests.csproj --configuration Release
-          dotnet tool install --global Microsoft.Playwright.CLI || true
-          export PATH="$PATH:$HOME/.dotnet/tools"
-          playwright install --with-deps chromium
-
       - name: Test
         run: make test
 
-      # Per-project thresholds live in coverage-thresholds.json (default 80%).
-      # Bump entries by floor(measured) - 1 whenever real coverage improves.
-      - name: Coverage check
-        run: make coverage-check
-
       - name: Upload coverage
         uses: actions/upload-artifact@v4
         if: always()