test-roadmaplisted

# test-roadmap skill ## Purpose Synthesize. Take the three phase artifacts and produce the single document that drives execution. ## When invoked By the `/test-roadmap` command. Requires: - `docs/test-readiness/test-inventory.md` - `docs/test-readiness/test-system.md` - `docs/test-readiness/test-migration.md` ## Output structure `docs/test-readiness/test-readiness-plan.md` opens with a `## Coverage Gate` block — the headline machine-checkable verdict (`feature_coverage_pct`, `feature_coverage_source`, `line_coverage_pct`, `line_coverage_source`, `verdict`, `targets`), computed by `scripts/check-coverage-gate.ts` and rendered verbatim (see Process step 8) — followed by six sections: ### 1. Where we are now Distilled from Phase 3: - Layer coverage map (counts: how many tests at each layer, how many ought to be there) - Local-runnable status: % of tests that run locally with no network - Canary status: size of current canary suite vs. target (from Phase 2 critical-path roster) - Speed status: Tier 1 aggregate wall-clock vs. budget; per-layer p95 only if Tier 2 was triggered - "Rebuild" debt: count by layer and effort - "Delete (redundant)" count and what it implies about false-confidence coverage ### 2. Where we want to be Distilled from Phase 2: - Framework matrix per layer - Local-substitute map - Coverage targets per tier - Canary suite definition (critical-path roster) - Speed budgets per layer ### 3. The gap The concrete diff between sections 1 and 2: - Missing