principle-boundary-discipline

Input validation belongs at system boundaries: CLI argument parsing, config file loading, network handlers, and external API clients. Once data is parsed into domain types at the boundary, internal code should trust those types without re-validating.

Extract business logic into pure functions with no framework dependencies, such as parse functions transforming raw bytes to typed state or scoring functions mapping state to results. The framework shell then just calls these functions, so tests need no framework setup.

No. If the boundary already validated the data, redundant nil checks deep in call chains add noise and a false sense of safety. Trust the types once data has crossed into the system.

Do not re-export transport, storage, framework, or wire types through your public API surface. Expose domain concepts instead, keeping general-purpose mechanism inside and special-purpose policy at the edge.

Ask whether the data is crossing a system boundary right now. If not, validation is redundant. Also ask whether the logic can be a pure function the shell just calls; if yes, extract it from the framework wiring.