superior-unit-testslisted

# Superior Unit Tests ## Goal Produce a small, fast, deterministic, valuable test suite that gives high confidence at low cost. Do not maximize test count. ## Non-Negotiable Test Policy All accepted tests must be deterministic. Do not write, preserve, recommend, quarantine, retry, rerun, tolerate, or normalize flaky tests. A flaky test teaches developers to ignore failures, and that is unacceptable. If an existing test is nondeterministic, there are only three acceptable outcomes: 1. Fix it so it is deterministic. 2. Delete it. 3. Replace it with a different deterministic test that provides the desired confidence. A smaller trustworthy suite is better than a larger suite with failures people learn to ignore. ## Test Execution Policy This project uses two test-running scripts: - `./run_tests`: Runs the fast tests. Use this for feedback after small changes, tweaks, refactorings, and incremental feature development. - `./full_test`: First runs `./run_tests`, then runs all additional tests. Use this periodically, before integration, and especially after a fresh `git pull`. Because `./full_test` starts by running `./run_tests`, do not classify any test as "both." A test belongs either in the fast feedback loop or in the additional full-suite layer. ## Fast Feedback Budget The entire `./run_tests` suite must complete within 30 seconds. This is a hard usability constraint. If the fast suite takes longer than 30 seconds, developers will often choose speed of developmen