Consolidate salvaged branches: signal_mesh + MCP↔WS bridge + pomodoro demo, green CI with per-package coverage ratchet

.claude/settings.json

@@ -0,0 +1,4 @@
+{
+  "_agent_pmo": "76596cb",
+  "autoMemoryEnabled": false
+}

.claude/skills/build/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: build
+description: Builds all artifacts for this repo. Use when the user asks to build, compile, or produce artifacts, or when verifying that the project compiles cleanly.
+---
+
+# Build
+
+Build all artifacts for this repo.
+
+## Steps
+
+1. Run `make clean` to remove stale artifacts
+2. Run `make build`
+3. Report what was built and where the artifacts are
+
+## Notes
+
+This is a Dart library monorepo — `make build` verifies that all packages compile cleanly. There are no standalone build artifacts (libraries are consumed via pub.dev).
+
+To build specific components:
+- Backend example: `dart run tools/build/build.dart backend`
+- VS Code extension: see `/build-extension` skill
+
+## Success criteria
+
+- Exit code 0 from `make build`
+- No warnings printed to stderr

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

@@ -0,0 +1,44 @@
+---
+name: ci-prep
+description: Prepares the current branch for CI by running the exact same checks locally, fixing issues at each step. Use before pushing a branch or when the user wants to verify the branch will pass CI.
+---
+
+# CI Prep
+
+Prepare the current state for CI. Ensures the branch will pass CI before pushing.
+
+## Steps
+
+### Step 1 — Analyze the CI workflow
+
+1. Read `.github/workflows/ci.yml`
+2. The CI runs these jobs in order:
+   - **lint**: format check, spell check, dart analyze
+   - **test**: tier 1, tier 2, tier 3 tests with coverage
+   - **build**: `make build`
+   - **website**: website build + Playwright tests (independent)
+
+### Step 2 — Run each CI step locally, in order
+
+1. **Format check**: `make fmt CHECK=1`
+   - If fails: run `make fmt` to fix, then re-check
+2. **Spell check**: `cspell "**/*.md" "**/*.dart" "**/*.ts" --no-progress`
+   - If fails: add words to cspell dictionary or fix typos
+3. **Analyze**: `dart analyze --no-fatal-warnings` on all packages
+   - If fails: fix lint errors in the reported files
+4. **Test Tier 1**: `./tools/test.sh --tier 1`
+5. **Test Tier 2**: `./tools/test.sh --tier 2`
+6. **Test Tier 3**: `./tools/test.sh --tier 3`
+7. **Build**: `make build`
+
+### Step 3 — Report
+
+- List every step that was run and its result (pass/fail/fixed)
+- If any step could not be fixed, report what failed and why
+- Confirm whether the branch is ready to push
+
+## Rules
+
+- Do not push if any step fails
+- Fix issues found in each step before moving to the next
+- Never skip steps or suppress errors

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

@@ -0,0 +1,63 @@
+---
+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.
+---
+
+# Code Dedup
+
+Carefully search for duplicate code, duplicate tests, and dead code across the repo. Merge duplicates and delete dead code — but only when test coverage proves the change is safe.
+
+## Prerequisites — hard gate
+
+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.
+2. `make test` already enforces the coverage threshold from `coverage-thresholds.json`. If it failed on coverage, stop.
+3. This is a Dart repo with static typing via `austerity` — proceed.
+
+## Steps
+
+### Step 1 — Inventory test coverage
+
+1. Run `make test` and note coverage per package from the output
+2. Only packages WITH coverage are candidates for dedup
+
+### Step 2 — Scan for dead code
+
+1. Look for unused exports, functions, classes, variables across all packages
+2. Use `dart analyze` output for unused element warnings
+3. Grep the entire codebase for references before marking as dead
+4. List all dead code found. Do NOT delete yet.
+
+### Step 3 — Scan for duplicate code
+
+1. Look for functions with identical or near-identical logic across packages
+2. Check across package boundaries
+3. List all duplicates found. Do NOT merge yet.
+
+### Step 4 — Scan for duplicate tests
+
+1. Look for tests that verify the same behavior
+2. Look for test helpers duplicated across test files
+3. List all duplicate tests found. Do NOT delete yet.
+
+### Step 5 — Apply changes (one at a time)
+
+For each change: **change -> test -> verify coverage -> continue or revert**.
+
+- After each change: run `./tools/test.sh`
+- If tests fail or coverage drops: **revert immediately**
+
+### Step 6 — Final verification
+
+1. Run `make test` — all tests must still pass
+2. Run `make lint` and `make fmt CHECK=1` — code must be clean
+3. Report: what was removed, what was merged, final coverage vs baseline
+
+## Rules
+
+- **No test coverage = do not touch.**
+- **Coverage must not drop.**
+- **One change at a time.**
+- **When in doubt, leave it.** False dedup is worse than duplication.
+- **Three similar lines is fine.** Only dedup substantial (>10 lines) or 3+ copies.

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

@@ -0,0 +1,67 @@
+---
+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]"
+allowed-tools: Read, Grep, Glob, Edit, Write, Bash
+---
+<!-- agent-pmo:76596cb -->
+
+# 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/fmt/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: fmt
+description: Formats all code in this repo using dart format. Use when the user asks to format code, fix formatting, or before committing changes.
+---
+
+# Format
+
+Format all code in this repo.
+
+## Steps
+
+1. Run `make fmt`
+2. Run `make fmt CHECK=1` to confirm clean
+3. Report which files were modified
+
+## What it does
+
+- `dart format packages/ examples/`
+
+## Success criteria
+
+- `make fmt CHECK=1` exits with code 0 after formatting

.claude/skills/lint/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: lint
+description: Runs all linters and format checks, then fixes any issues found. Use when the user asks to lint, check code quality, or fix linting errors.
+---
+
+# Lint
+
+Run all linters and report issues.
+
+## Steps
+
+1. Run `make lint` (runs format check + cspell + dart analyze on all packages)
+2. Report all issues found (file, line, rule, message)
+3. If issues found, fix them and re-run to confirm clean
+
+## What `make lint` does
+
+1. `dart format --set-exit-if-changed` on packages/, examples/, tools/build
+2. `cspell` spell check on all .md, .dart, .ts files
+3. `dart analyze --no-fatal-warnings` on every package and example
+
+## Rules
+
+- Never suppress a lint warning with an ignore comment
+- Fix the code to satisfy the linter
+- Each package uses the `austerity` lint package — do not bypass its rules
+- If a rule seems wrong for a specific case, document why in code comments
+
+## Success criteria
+
+- `make lint` exits with code 0
+- Zero warnings or errors output