Repository configuration, projects, setup, imports/globals, environments, aliases, test placement, and cleanup own the\ntest contract. Inspect them and nearby tests before adding generic patterns. Do not add globals, jsdom, coverage, new\nsetup, or browser mode by default.
\nDefine the behavior or regression, test its observable public result, and mock system boundaries rather than the\nbehavior under test. Follow local fixture and cleanup ownership. In Effect repositories, use established\n@effect/vitest conventions such as it.effect, Layers, and TestClock rather than generic replacements. For a bug fix,\nreproduce the failure before relying on a passing result when practical.
Read patterns for component, async, fixture, snapshot, tag, or browser questions;\nmocking for module, timer, spy, or global boundaries;\nconfiguration for projects, migration, coverage, or reporter selection; and\ntroubleshooting for hangs, discovery, resolution, or flaky state.
\nFor test changes, run the narrowest established command for the changed behavior, then the affected package suite only\nwhen shared setup or contracts changed. Use nlx vitest run only when no project recipe or script exists. Reuse passing\nresults until new edits, failures, or unresolved concerns justify another run.
Completion requires a meaningful passing focused test under repository configuration and concise command/result evidence\nfor test changes. A read-only explanation instead requires supporting configuration or API evidence; do not add or run\ntests merely to satisfy the change workflow. Use ### \uD83E\uDDEA Regression covered when red-before-green evidence exists;\notherwise ### \uD83E\uDDEA Tests verified for executed tests.