making-invalid-states-unrepresentablelisted

# Making Invalid States Unrepresentable ## Workflow A: Review Existing Code 1. Identify the scope (module, file, type, or function under review). 2. Read the code and enumerate the types, fields, and state representations. 3. Detect anti-patterns (see checklist below). 4. For each finding, propose a concrete refactoring using the appropriate technique from `references/`. 5. Assess tradeoffs — see `references/advanced-topics.md` § Tradeoffs. 6. Present findings as a prioritized list: high-value (core domain, security, APIs) first. ## Workflow B: Design New Types 1. Collect domain requirements: valid states, invalid states, transitions. 2. Choose modeling techniques — read `references/core-and-parse.md` for foundational approach. 3. Model with types: sum types for alternatives, product types for combinations, phantom/branded types for compile-time tags. 4. Push validation to boundaries: parse external input immediately into precise types. 5. Validate the design: confirm invalid states cannot be constructed. 6. Iterate as domain understanding deepens. ## Anti-Pattern Detection Checklist Flag code that exhibits any of these — see `references/anti-patterns-and-examples.md` for details and fixes: - [ ] **Primitive obsession** — raw strings/ints used for domain concepts (IDs, emails, money) - [ ] **Boolean blindness** — booleans that lose context about what was verified - [ ] **Optional property proliferation** — many optional fields instead of a union type - [ ] **Stringly-t