qol-apps-testinglisted

# qol-apps-testing ## When to use Use this skill when the user asks to: - add tests - improve or expand test coverage - review whether tests are meaningful - convert weak example tests into stronger property or parameterized tests - design tests for a bug fix or regression guard ## Defaults - When the task changes code or tests, run the relevant tests by default unless the user explicitly says not to. - Prefer repo-native validation commands first when the project defines them. - Prefer testing pure helpers, reducers, validators, parsers, and planners over UI shells or thin wrappers. - For bug fixes, write the test for the expected behavior before changing implementation when practical. - A test must fail on a plausible regression. If it would keep passing after the bug comes back, it is not good enough. ## Before claiming a seam is missing Verdicts like "this isn't testable without a refactor", "we'd need to inject the path", "the seam doesn't exist" must be backed by `path:line` evidence from a survey of the relevant modules. Without that, the verdict is a guess. qol-tools modules already carry test seams that are not obvious from the function signature, so the guess is wrong often enough that you cannot trust it. **Mandatory grep before declaring a seam absent:** ``` grep -rn "test_path_root\|TestPathRootGuard\|push_test_path_root\|TEST_.*ENV\|cfg(test)" src/ grep -rn "QOL_.*TEST\|_TEST_PATH" src/ ``` Also: read `paths/mod.rs` (or whatever owns config/data path re