atmos-specs-test-planlisted

# Atmos Specs · Test Plan Define observable, executable proof that a feature is done. The audience is the engineer who will later implement the tests (via `atmos-specs-test-run`) and the reviewer checking the feature before merge. ## What this skill owns — and what it does not - **Owns**: `TEST.md` in one spec directory — the scenario-level plan. - **Does not own**: actual test code (Rust `#[cfg(test)]`, `bun test` specs, Playwright specs). That belongs to `atmos-specs-test-run`. - **Does not own**: running `just test` / `cargo test` / `bun test`. Also `atmos-specs-test-run`. - **Does not own**: BRAINSTORM, PRD, TECH. Why: TEST.md is a scenario-level contract, not a test harness. A stable plan lets implementation churn (new helpers, refactored imports, renamed symbols) without invalidating the "what we promise to verify" section. Keeping authoring and execution in separate skills prevents the planner from prematurely committing to brittle assertions tied to today's internals. ## Read these before you write 1. `specs/AGENTS.md`. 2. The spec's `PRD.md` — every Must Have must have at least one scenario that would fail if it regressed. 3. The spec's `TECH.md` — gives you the failure surfaces (new WS messages, new tables, new endpoints, new frontend components). 4. A comparable existing `TEST.md` once the first few land (right now most are templates — that's expected). ## Workflow ### 1. Map PRD Must Haves → scenarios Open PRD.md and list M1, M2, … N1, N2. For each: - Wr