test-scope-routinglisted

# Test Scope Routing Choose validation from the changed surface and risk. Keep the local feedback loop small, while reserving complete regression and release gates for merge, release, and high-risk boundaries. For compact routing examples, read [references/usage-examples.md](references/usage-examples.md) when needed. ## Establish the project contract Before selecting commands: 1. Read the applicable `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING.md`, and test-scope documentation. 2. Inspect `package.json`, Makefiles, task runners, test configuration, CI workflows, and release workflows. 3. Identify the repository, branch, worktrees, submodules, and uncommitted changes. Preserve changes that are outside the request. 4. Use project-defined commands and prerequisites. Do not invent a global command name or assume that `verify`, `fast`, or `full` has a standard meaning. 5. Check whether a command starts a database, browser, production connection, deployment, or other external state before running it. Treat project documentation as the authority for exact commands and boundaries. This skill supplies the routing method, not project-specific command names. ## Write a small spec first For behavior changes, record before implementation: - in-scope behavior and explicit non-goals; - user-observable acceptance conditions; - affected code, UI, data, permission, offline, conflict, error, and compatibility boundaries; - the smallest validation tier and any additional tiers; - checks inte