feat(dev): enforce vitest coverage thresholds per TDD domain

[melagiri]

Context

PR #187 established strategic TDD domains with coverage targets:

Level	Domain	Coverage Target
MUST TDD	Parsers (cli/src/providers/)	90%+
MUST TDD	Normalizers (server/src/llm/*-normalize.ts)	85%+
MUST TDD	Pricing (server/src/llm/analysis-pricing.ts)	85%+
MUST TDD	Response parsers (server/src/llm/response-parsers.ts)	85%+
MUST TDD	Migrations (cli/src/db/)	90%+
MUST TDD	Shared utilities	85%+
SHOULD TDD	API routes (server/src/routes/)	70%+

Currently these targets are documented (in docs/QA.md, docs/DEVELOPMENT.md, and agent prompts) but not enforced — there's no vitest config or CI check that fails when coverage drops below the threshold.

What

Configure vitest coverage thresholds so that pnpm test fails if coverage drops below the target for MUST TDD domains.

Acceptance Criteria

• vitest.config.ts in cli/ and server/ configured with coverage.thresholds per-glob pattern
• pnpm test:coverage fails if any MUST TDD domain drops below its target
• Baseline coverage measured and documented (current actual vs target)
• If current coverage is below target for any domain, create a plan to close the gap before enforcing
• Pre-PR hookify gate updated to run pnpm test:coverage (or document why pnpm test alone is sufficient)

Notes

• Raised during triple-layer review of PR feat(dev): implement strategic TDD workflow #187 (Wild Card suggestion S4)
• Coverage enforcement should be additive — don't block pnpm test on coverage, use pnpm test:coverage as a separate check
• Consider whether coverage thresholds should be warnings vs hard failures initially

Size

T-shirt: S (config changes + baseline measurement)

[melagiri]

Baseline measurement + gap plan

PR #304 adds the thresholds config. Floors are set at current actual levels (not targets) so CI passes immediately — the thresholds prevent regression, not enforce targets we haven't reached yet.

Coverage baseline (measured 2026-05-29)

Domain	Target	Stmts	Branch	Floor set
cli/src/providers/**	90%	38%	32%	38% / 32%
cli/src/db/**	90%	81%	69%	81% / 69%
cli/src/utils/**	85%	63%	53%	63% / 53%
server/src/routes/**	70%	81%	68%	81% / 68%
server/src/llm/analysis-pricing.ts	85%	34%	47%	34% / 47%
server/src/llm/response-parsers.ts	85%	0%	0%	⚠️ no floor yet
server/src/llm/*-normalize.ts	85%	0%*	0%*	n/a (re-exports)

*Server normalizer files are thin re-export wrappers pointing to cli/src/analysis/. Actual implementations are 100% covered in the CLI. V8 attributes coverage to the source files, not the re-export wrappers.

Gap plan (to reach targets)

cli/src/providers/ (38% → 90%):

• claude-code.ts at 13% — needs tests for message iteration, tool call classification, session boundary detection
• codex.ts at 37%, cursor.ts at 42% — need tests for event normalization and parsing edge cases

cli/src/db/ (81% → 90%):

• db/client.ts at 17% — needs connection lifecycle and WAL mode tests
• db/write.ts at 76% — transaction rollback paths untested

cli/src/utils/ (63% → 85%):

• ollama-detect.ts at 6% — needs process-detection mocks
• hooks-utils.ts at 50% — needs tests for hook removal edge cases

server/src/llm/analysis-pricing.ts (34% → 85%):

• Cost calculation functions need unit tests (token costs, model pricing lookups)

server/src/llm/response-parsers.ts (0% → 85%):

• No tests exist. Agreed approach: write response-parsers.test.ts before the next change to that file.

Each gap is best addressed as a dedicated test-writing PR per domain when we next touch those files.