类型系统纪律：让编译器拒绝不可能的状态、错配的原始值与未处理的分支变体。与其不断增加处理分支，不如从源头把错误和特例定义为不存在。若需 TypeScript 语法示例，可调用 /pstack-typescript-best-practices。
用途 本技能面向静态类型语言中的类型设计与代码评审，目标是借助类型系统把非法状态排除在表达范围之外，减少运行期校验与分支处理。
主要能力
- 为语义原始值打品牌：UserId 与 OrderId 底层都是字符串，但不应可互换。应各自拥有独立类型，例如 TypeScript 中的 branded intersection，或其他语言中的 newtype。在创建时校验一次，下游信任该类型。若两个参数共享同一原始类型却含义不同，就为它们打品牌。
- 外部数据在被解析前都是无类型的：RPC 载荷、JSON、IPC 消息、CLI 参数、配置文件、环境变量、数据库行皆如此。每个边界都应有解析函数，把非结构化输入转为类型化模型。至于校验放在何处，参见 /pstack-principle-boundary-discipline。
- 从权威 schema 派生类型：当 protocol buffer、OpenAPI 规范、GraphQL schema、数据库迁移、design-token 文件等拥有某个形状时，应从其派生类型，而不是手写一份平行类型。参见 /pstack-principle-encode-lessons-in-structure。
- 只在出现部分性时加强类型：运行期断言、空值检查或“这不应发生”的抛错，标记了类型过弱之处。把该检查上推到类型层，然后停止。类型系统的职责是跟踪每个使用点必须处理的情形，而非尽可能精确地描述数据。优先使用全函数：空列表求和为 0，因此接受普通列表；空列表取首元素无答案，因此要求非空列表。若本不会发生 panic，就保留普通类型。
使用方式 在设计类型、评审函数签名或编写任何静态类型语言代码时应用上述原则；TypeScript 语法示例可调用指定技能获取。
适用场景 类型建模、API 与函数签名设计、边界数据解析、类型评审。
限制 资料未提供具体安装方式、依赖要求、支持语言清单及许可信息，暂未提供。