reviewing-functional-designlisted

# Reviewing Functional Design ## Overview This is the audit pass for everything else in this pack. It turns the principles into a checklist that can be run against a diff, a module, or a proposed design, and produces findings ranked by cost rather than a list of opinions. The value of a red flag is that it is cheap to spot and reliably points at a real problem. You do not need to understand a system to notice that a function's body is one call, that two modules share a string literal, or that a name could apply to anything. ## When to use - Reviewing a pull request or a design document - Before merging any non-trivial change - Assessing an unfamiliar codebase - Deciding what to fix first in code that everyone dislikes - Checking your own work before calling it done Not for: finding bugs, which is a different activity with different methods. ## The pass Run in this order. Stop and record findings; do not fix as you go, or you will lose the overview. 1. **Types.** Can any type hold a state the business forbids? Are domain values primitives? Does a record have correlated optional fields? 2. **Signatures.** Is every function total? Are failures in the return type? Are effects visible? Would two parameters be transposable? 3. **Interfaces.** Is each module's interface much smaller than what it hides? Is anything exported that no caller outside uses? 4. **Dependencies.** Does the domain import infrastructure? Does any function take a whole service to use one op