thalarch-testlisted

# Thalarch Test Testing exists to falsify the implementation, not to decorate the diff or chase a vanity metric. ## 1. Test selection Prefer the cheapest layer that proves the contract: 1. pure/unit; 2. property/state-machine/model test; 3. component/module; 4. integration with the real boundary; 5. device/browser/end-to-end. Move upward only when the lower layer cannot prove the behavior. Do not substitute a lower layer for an acceptance criterion that fundamentally lives higher in the stack. ## 2. Quality rules A useful test: - asserts user- or contract-visible behavior; - fails for a meaningful broken implementation; - controls unrelated nondeterminism; - covers the actual regression mechanism or invariant; - has a clear reason for its layer; - does not merely mirror private implementation details; - does not pass only because a mock returns the answer configured into it. For bug fixes, prefer red-green proof: 1. reproduce the original failure; 2. prove the test/check fails for the broken behavior when practical; 3. apply the fix; 4. rerun the same proof; 5. run nearby regressions. ## 3. Spec traceability For non-trivial features, map acceptance criteria to tests/checks. Each important criterion should have at least one proof at the layer where the criterion is observable. Do not create a new permanent `specs/` convention unless the repository already uses one or the user requested it. Traceability can live in the task/evidence ledger. ## 4. Boundary matrix