effect-model-auditlisted

# Effect-model type audit Sweep the **port/domain type surface** for **model-level dishonesty** — types whose *shape* lets a caller construct, or forces a caller to fake, a value the domain does not mean. This is not "did we hand-roll a helper" (that's the sibling) and not "is this line idiomatic" (that's the LSP). It is: **does the type's value space match the domain's, and do all its producers and consumers mean the same thing by it?** Four orthogonal **value-space lenses**, each run against each type-family: - **L1 Illegal-representable** — can the type represent a value that is *invalid* in the domain? A combination of fields, an optional that should be required, a bare primitive admitting an out-of-domain string, a boolean pair whose illegal corner is representable. The general form of "flags-and-optionals for state" and "stringly-typed value", **unbound from any grep costume** — reason about the value space, don't match a token. *Invalid state must be unrepresentable.* - **L2 Under-expressive** — the dual: is there a *legal* domain state the type **cannot** represent, forcing a sentinel, a "transparent placeholder", an impossible branch, or a comment apologising for a field that is "always absent here"? An under-expressive type pushes the missing case into convention or into a lie. - **L3 Role coherence** �� from the producer/consumer **census**: do all construction sites and all read sites mean the *same thing* by this type, or is it two roles