happier-testing

# Happier Testing And TDD Use this skill for behavior-changing work in this repository, especially when changes touch shared runtime contracts, CLI/server/UI flows, or any lane that historically accumulates stale fixtures. ## Goal Apply strict RED-GREEN-REFACTOR while following Happier-specific lane, fixture, and rerun rules so changes do not silently drift until a late pipeline sweep. ## Workflow 1. **Inventory first** - Search for existing tests by symbol, route, command, feature id, config key, component name, or error code. - Map the affected lane(s) and any shared/package-local harnesses the change can invalidate before editing code. - Name the observable contract or material risk the test must distinguish before writing it. - For user-visible or environment-dependent work, define the composed live recipe before implementation: exact entry point, provider/account/state, actions, expected outcome, recovery path, and build/bundle/runtime identity that will prove the result. - Update the most relevant existing test first when possible. - Consolidate overlapping tests instead of stacking new ones on top. 2. **Classify failures correctly** - `production bug`: runtime behavior is wrong - `test drift`: assertions/fixtures assume an obsolete contract - `harness drift`: helpers/mocks/testkit no longer match real runtime wiring - `infra/resource issue`: disk, Docker, stale child processes, or similar environment failures 3. **RED** - Write or update the smallest relevant te...