adversarial-ts-patterns

对抗式 TypeScript 模式门禁

用于 TypeScript 和 React 应用代码的设计模式使用门禁——一种通过／不通过门禁：由单个盲审子 Agent 按照本门禁规则，以对抗性审查要求评判代码；只有每条规则均为 PASS 或 N/A 时，代码才通过。此技能只给出裁定，绝不会修复代码。

门禁会从两个方向进行评判。过度抽象——将适用于 Java/C# 的四人帮模式和企业级机制照搬过来，而惯用的 TypeScript 通常会采用函数、模块或带标签的联合类型。建模不足——隐式状态机让不可能的状态也能通过编译：使用布尔标志管理生命周期、由 effect 串联的状态更新、手动同步的派生状态，以及不会发出提示的 default 分支。

何时应用

• TypeScript/React 代码差异或功能即将合并，需要对模式使用情况进行客观的 PASS/FAIL 判定，而非建议性反馈。
• 代码由 Agent（Claude、Codex）编写，而你想要独立检查它是否在复现 Java/C# 训练数据中的惯用写法——Singleton 类、工厂层级、repository 封装、JavaBean 访问器。
• 从其他技术栈（Java、C#、Angular 风格的 DI）迁移并宣称已完成，需要审查移植后的架构中哪些层在 TypeScript 中已失去存在的理由。
• 组件或 store 状态逐渐累积，你想在发布前捕获隐式状态机的失效模式（相互矛盾的布尔值、effect 链、非穷尽匹配）。

不要将其用于非 TypeScript 代码库（审查提示词的前置条件会以 “GATE NOT APPLICABLE” 中止），也不要在用户需要解释和重构而非裁定时使用——这属于经过筛选的 implementation-design-patterns 和 implementation-functional-patterns 技能的职责。非 React TypeScript 项目中的 React 特定规则标记为 N/A；其余门禁规则适用于任何 TypeScript 应用。

审查协议

严格遵循以下步骤——门禁的价值在于确保每次审查都以相同方式运行。

1. 确定目标。 准确确定审查对象（差异、一组文件或 PR），并记录引用和路径，确保审查针对明确且固定的目标运行。在目标描述中包含仓库根目录——layer-no-single-impl-interface 和 layer-no-di-container-in-app 规则要求在差异之外搜索其他实现和注册项。
2. 加载规则。 阅读 references/_sections.md 以及 references/ 中的每个规则文件（所有 state-*.md、create-*.md、behave-*.md、layer-*.md、react-*.md、oo-*.md 文件）。
3. 编写审查者提示词。 将规则和目标填入 references/reviewer-prompt.md。编写后的提示词必须完全自包含——审查者看不到任何对话历史，因此不得引用提示词之外的上下文。
4. 派发一名盲审查者。 启动一个 Task 子 Agent，其全部输入只能是编写好的提示词——不得附带对话上下文或评论。
5. 按失败即关闭原则给出结果。 审查者的结构化输出就是最终判定——不进行合并。只有每条规则均为 PASS 或 N/A 时，总体判定才是 PASS；任何一条 FAIL 都会导致门禁失败。绝不取平均、权衡严重程度或豁免规则——“轻微”的 FAIL 仍然是 FAIL。如果审查者返回“GATE NOT APPLICABLE”（目标不是 TypeScript），则停止并报告此结果，而不是给出判定。
6. 呈现判定。 填写 assets/templates/verdict.md。若结果为 FAIL，将审查者提出的“通过所需的修改”汇总到修复清单中，并为每项标注位置，按类别重要性排序。每条最终结果为 FAIL 的规则都必须出现在修复清单中，并给出可直接照此执行的具体修改——如果审查者的建议只是重述违规内容，则在呈现结果前，根据规则的 Correct 示例推导修复方案。

如果同一规则在针对未变更目标的多次重新审查中判定反复变化，或人工查看证据后推翻判定，这说明规则存在可判定性缺陷——应将其记录在 gotchas.md 并完善规则；不得推翻门禁结果。

判定格式

审查者必须逐条返回规则结果：PASS | FAIL | N/A、证据（file:line 或引文——PASS 和 FAIL 均必须提供证据）；对于每条 FAIL，还必须提供应用后可使该规则通过的修复方案——包含具体修改及其位置，不能只是重述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	涵盖内容
1	状态建模与状态机	state-	使用区分联合而非布尔标志、不使用效果链、不存储派生状态、使用 never 穷尽匹配
2	创建型接口	create-	不使用 getInstance() 单例、不使用工厂类层级、不为选项对象构建构建器
3	行为型接口	behave-	使用函数而非单方法类、使用联合而非 State/Visitor 层级、不在 React 树内使用事件总线
4	企业级分层	layer-	不使用直通式仓储、不使用仅有单一实现的 DI 容器、不使用仅有单一实现的接口
5	React 组合	react-	不使用组件继承、逻辑专用 HOC 使用钩子替代、使用 props 而非命令式句柄
6	面向对象仪式性样板	oo-	不使用仅含静态成员的容器类、不使用无实质作用的访问器对

相关技能

• implementation-design-patterns（精选）——介绍何时适合采用 GoF 类形式的教学式参考；当目标是提供指导或进行重构，而非作出判定时使用。
• implementation-functional-patterns（精选）——从 GoF 到函数式模式的映射；本门禁的 create-/behave- 规则会强制执行其中可审查的子集。
• adversarial-tanstack / adversarial-zod ——针对框架和库层面的 TanStack Start 应用门禁；若要全面审查 Start 差异，请与本门禁一并运行。

参考文件

文件	描述
references/reviewer-prompt.md	供盲审查者使用的独立提示词模板
assets/templates/verdict.md	判定报告模板
references/_sections.md	类别定义和排序
metadata.json	版本和来源引用