test-strategylisted

# Test Strategy + Scaffolding Goal: protect against regressions cheaply. Test pure logic and cross-service contracts — that's where silent bugs live (record detection, object-store-key drift, data-class split, type coercion). Skip trivial getters. ## Test-first (RED → GREEN → REFACTOR) Write the test **before** the production code, not after — the bug/feature's test should exist and **fail (RED)** first, then the implementer makes it pass **(GREEN)**, then refactor under green. The test list is **derived from the Design Spec's ACCEPTANCE criteria** (one criterion → one named test), not invented at validation time. The implementer may not weaken a RED test to pass; a wrong test goes back to feature-architect. (Validation that lands *after* code is test-after — a weaker guard. See `.claude/context/AGENT-CONTRACTS.md`.) ## What to test (priority) 1. **The exact bug being fixed** — a test that fails before the fix, passes after. 2. **Cross-service contracts** — drift = silent wedge (object-store key shape, record fields, routing keys). 3. **Security/segregation** — restricted vs non-restricted data routing, fail-safe defaults. 4. **Edge cases** — empty/missing, wrong type, boundary (padding, blank + coerced value). Avoid tests needing live queue/DB/object-store (those are integration — keep a separate fixture for them). ## Scaffolding conventions Mirror the repo's existing test layout and pinned tooling versions. Common stacks: - **.NET** → a `<Service>.Tests` project referen