m05-type-driven

Compile-time state validation through type encoding, eliminating invalid states at the type level. Layer 1: Language Mechanics How can the type system prevent invalid states? Before reaching for runtime checks: Before adding runtime validation: Can the type encode the constraint? When is validation possible? Who needs to know the invariant? When type design is unclear: From design to implementation: - Covers six core patterns: newtype for type-safe primitives, type state for state machines, PhantomData for variance tracking, marker traits for capability flags, builders for gradual construction, and sealed traits for closed impl sets - Emphasizes asking "can the compiler catch this?" before adding runtime validation, with decision guides mapping common needs to appropriate patterns - Includes anti-patterns section contrasting runtime approaches (boolean flags, string semantics, public fields) with type-driven alternatives - Provides trace-up and trace-down navigation to related skills for domain modeling, trait design, and error handling - Can the compiler catch this error? - Can invalid states be unrepresentable? - Can the type encode the invariant?