用途：这是一条类型系统纪律原则，适用于任何静态类型语言，在涉及类型设计、函数签名审查或编写代码时应用。核心观点是把类型检查器当作证明助手，用它在编译期消除不可能状态、类型不匹配的原始值和未处理的分支；类型允许忽略的情况，最终会变成编译器本可阻止的运行时失败。
主要模式：一、让非法状态不可表示，用和类型建模变体，如 TypeScript 的可辨识联合、Rust/Swift/Kotlin 的带载荷枚举、Scala 的密封类、Haskell/OCaml 的代数数据类型；不要用一堆可选字段建模状态，例如 { completed: boolean; completedAt?: Date } 允许无意义的组合，应改为从单一来源派生或显式建模变体。二、类型是构造而非限制，从想要的值构建类型，如非空列表是头加尾，合法时间范围是起点加时长。三、为语义原始值加品牌，UserId 与 OrderId 底层都是字符串但不可互换，可用 newtype、opaque type、value class、phantom type、branded intersection，创建时校验一次，下游信任类型。四、外部数据在被解析前是无类型的，RPC、JSON、IPC、CLI 参数、配置文件、环境变量、数据库行都应在边界处用解析函数转为类型化模型。五、不要对类型系统撒谎，强制转换、不安全强制和断言函数是潜在运行时崩溃。六、穷尽匹配交给编译器，新增变体未处理时应编译失败。七、从权威 schema 派生类型，如 protobuf、OpenAPI、GraphQL、数据库迁移、设计令牌文件。八、只在出现部分性时加强类型，运行时断言、空检查或“不应发生”的抛出标记了类型过弱之处，应把检查上推到类型中，然后停止。
自检问题：能否写注释解释某字段组合何时有效？两个参数共享原始类型但含义不同？any、as、assertNotNull 从何而来？新增变体编译器会否提示？类型是否重复了其他文件拥有的形状？加强类型是为保持函数全性还是仅为更精确？
限制：资料未提供具体安装命令、收费方式、平台支持或使用步骤；该技能为原则性指导，具体语法需结合如 typescript-best-practices 等技能落地。