qalisted

# QA ## Core principle Tests verify behavior through public interfaces, not implementation details. Code can be refactored entirely; tests should not break unless behavior changes. If a test breaks when you rename an internal function but the user-facing behavior is unchanged, the test was wrong. When writing test steps or evaluating failures, always ask: "Is this testing what the user experiences, or what the code looks like inside?" ## Step 1: Read the context Read: - `.harness/engineering/features/` — acceptance criteria for every `done` feature - `.harness/product/ux.md` — core user workflows to validate end-to-end - `CLAUDE.md` and `README.md` — how to install and run the project - `package.json` / `pyproject.toml` / `Makefile` / `go.mod` — available test and run commands Determine: - **Project type**: web app, CLI, REST API, library, mobile - **How to start the app**: the exact command(s) - **What testing tools are available**: existing test suite, Playwright MCP, shell ## Step 2: Build a feedback loop Before running any test, identify the fastest, most deterministic signal for each feature. A good feedback loop is: fast (seconds, not minutes), deterministic (same result every run), and sharp (clearly signals pass or fail). Work through this list in order — use the first approach that fits: 1. **Failing test** — does an existing test already cover this criterion? Run it. 2. **curl / HTTP script** — for API features, a one-liner that hits the endpoint and check