类型系统纪律（Type System Discipline）是一项面向静态类型语言的编码与审查准则，核心目标是让编译器承担排除非法状态、混淆原始类型与未处理变体的工作。资料给出的适用时机是：设计类型、审查函数签名，或用任意静态类型语言编写代码时。
主要能力与原则：
-
让非法状态不可表示。变体应建模为和类型（如判别联合、带载荷枚举、密封类），而不是一组可选字段——后者允许矛盾组合通过编译。资料举例：{ completed: boolean; completedAt?: Date } 允许 completed: true 却没有日期；可以改为从 completedAt 派生布尔值，或建模为 { kind: 'open' } | { kind: 'done'; at: Date }。如果一段注释需要解释字段组合何时有效，就应拆成和类型。
-
类型是构造而非限制。应从期望的值出发构造类型，而不是在宽松类型上用检查“雕刻”出来。非空列表是头加尾，合法时间区间是起点加时长；选择无法构造出非法值的形状，并在其上暴露调用方需要的接口。
-
为语义原始类型打品牌。UserId 与 OrderId 底层都是字符串，但不应可互换；各自应有独立类型（如 TypeScript 的品牌交叉类型，或其它语言的 newtype）。在创建时验证一次，下游信任类型。若两个参数共享原始类型但含义不同，应打品牌区分。
-
外部数据在被解析前都是无类型的。RPC 载荷、JSON、IPC 消息、CLI 参数、配置文件、环境变量、数据库行，都应在每个边界设置解析函数，把非结构化输入转为类型化模型。验证放在何处可参考 boundary-discipline 原则技能。
-
不要欺骗类型系统。类型转换、不安全强制转换、绕过编译器的断言函数都是潜在运行时崩溃。编译器无法证明事实时，应去证明（验证、收窄、细化模型），或承认该转换是风险；每个 any、as、assertNotNull 都应追溯到边界并在那里验证。
-
穷尽匹配是编译器的职责。对和类型的匹配在新增变体未处理时必须编译失败，以便编译器提示下一个开发者在哪里补分支。语言惯用法包括：TypeScript 中 never 类型绑定、Rust 中不写通配的 match、Haskell 的 -Wincomplete-patterns、Kotlin 密封类匹配穷尽性。
-
从权威 schema 派生类型。当 protobuf、OpenAPI 规范、GraphQL schema、数据库迁移、设计 token 文件等拥有某个形状时，应从中派生，而不是手写平行类型；可参考 encode-lessons-in-structure 原则技能。
-
只在出现部分性时加强类型。运行时断言、空值检查或“这不应发生”的抛出，标记了类型过弱之处；应把该检查上推到类型中，然后停止。类型系统的职责是跟踪每个使用点必须处理的情况，而非尽可能精确地描述数据。优先全函数：空列表求和为 0，因此接受普通列表；空列表取头无答案，因此要求非空列表；若不会因此 panic，就保留普通类型。
适用场景为静态类型语言中的类型设计、函数签名审查与日常编码。限制方面：资料侧重原则与方法，未提供安装命令、调用方式、工具形态或平台支持信息；TypeScript 具体语法需参阅 typescript-best-practices 技能，边界验证位置需参阅 boundary-discipline 技能。