用途：当实现者可能过于贴近设计时，以一名未参与对话的 TypeScript 开发者视角阅读改动，并持续质疑直到生命周期、命名与类型形状变得清晰或收敛为更简单的方案。这是一次结构化质疑，而非普通代码评审。
必要起始动作：若运行环境支持子代理且用户要求全新视角，应生成一个全新上下文的审查者，不要分叉整个对话，除非用户明确要求连续性。给子代理一个有边界的提示，包含要读取的确切文件、要检查的暂存差异或目标分支、硬性不变量、要加载的技能、期望输出形状。若不可用子代理，则在本地模拟同样姿态：先只读取任务指定的文件，仅在问题需要时通过调用方搜索扩大范围。审查前应加载相关本地技能，如 typescript、approachability-audit、refactoring、cohesive-clean-breaks、greenfield-clean-breaks、define-errors 与 error-handling、collapse-pass，以及被审查包对应的领域技能。
姿态：假设代码可能是对的，但解释可能仍然过于昂贵。按顺序提问代码必须成立的一句话是什么、哪些是持久状态、哪些是运行时状态、哪些只是网络观察、各层拥有哪些不变量、新开发者首次阅读会误解什么、满足硬性不变量的最简设计是什么、兼容性压力是否已释放、单调用方辅助函数是否名副其实、类型别名是真正契约还是本地仪式、Result 加 defineErrors 是否比自定义联合更好、测试断言的是公共行为还是实现细节。不要接受“它就是显式的”作为充分答案。
类型形状规则：优先使用现有项目约定；成功或失败用 Result<T, E>；类型化失败模式用 defineErrors；当每个变体都是成功的领域状态或联合建模运行时状态而非操作失败时，使用自定义可辨识联合；不要在 Result 外再包一层成功/错误联合，除非存在明确的第三状态；不要仅为缩短返回注解而创建命名类型别名，除非别名命名了真正的契约。
生命周期质疑：先写出生命周期再审查代码，挑战每个转换：什么启动它、哪些异步工作可能仍在进行、什么对象身份或版本门防止过期工作胜出、哪些状态公开哪些仅内部、持久存储失败会怎样、网络说谎超时或返回过期身份会怎样。若转换无法用一句短话解释，就需要更好的命名、更好的不变量或更少状态。
辅助函数边界质疑：判断前先数调用方。仅当单调用方辅助函数命名生命周期转换、隔离解析或网络边界、防止过期异步工作、保持长方法可读或匹配一组有意操作时才保留；仅重命名简单控制流的应内联。
输出形状：文件读取列表、生命周期、发现（按严重性、文件:行、问题、重要性、修正）、可简化项、可保留项、测试缺口、裁决（保留/修改/阻止，附一个具体理由）。发现必须优先，不要将缺陷埋在叙述之下。
执行编辑时：先添加或调整聚焦测试；在问题真正归属处做修正，仅在兼容性压力明确释放时使用 greenfield-clean-breaks；重读每个被触及文件；运行包类型检查与测试；仅暂存所触及文件；不要将无关清理折入改动。