adversarial-ddd

对抗式 DDD 门禁

适用于任何代码库的领域驱动设计和通用语言门禁——通过/失败门禁：由单个盲审子 Agent 按照此门禁的规则，以对抗式审查要求评判工作；只有每条规则都为 PASS 或 N/A 时，工作才算通过。此技能只给出评判结果，绝不修复工作。

门禁的核心是术语表生命周期：只要目标包含领域概念，就必须有记录在案的通用语言（术语表）；若缺失，则判定为 FAIL，修复清单会指出要创建的确切文件及其中必须定义的术语。在任何项目上运行门禁，第一次评判就会促使词汇表得以建立；之后每次运行都会依据它检查代码、测试、文档和面向客户的文案，并确保术语表规模适当。这正是一个技能能在多个项目中建立共同且易于理解的词汇表的方式，也完全符合 DDD 的规定。

适用场景

• 领域代码即将合并，需要针对通用语言和领域模型质量获得客观的 PASS/FAIL 结果，而非建议性反馈。
• 项目刚刚启动或被采用，你希望强制建立共享词汇表——首次运行的修复清单就是术语表的初始内容。
• Agent（Claude、Codex）编写了代码，你希望独立检查其常见默认做法：*Manager/*Helper 类型、setStatus() 状态转换、贫血实体，以及被吸收到模型中的供应商类型。
• 正在引入 DSL、流式构建器或声明式规范格式，需要评判其表层设计是否体现了领域词汇。
• 定期审计时，代码库、文档和面向利益相关方的界面已经出现偏差，你希望指出具体位置和差异。

不要将其用于不包含领域概念的目标，例如纯基础设施、构建工具或通用库（审查提示词的前置条件会中止并返回“GATE NOT APPLICABLE”）。如果用户需要的是解释或重构，而非评判结果，也不要使用。若规则所需的前置结构不存在（没有可识别的上下文、没有 DSL，或符合性规则尚无术语表），则标记为 N/A，而非 FAIL——但两条缺失规则（gloss-language-recorded、dsl-deterministic-validator-exists）除外：缺少相应产物本身就意味着 FAIL。

审查流程

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

1. 确定目标。 精确确定审查对象（差异、模块／限界上下文或 DSL 表面），并记录引用版本／路径，使审查针对明确且固定的目标运行。始终包含仓库根目录——gloss-* 规则会在仓库中搜索术语表和术语用法，而 ctx-* 规则需要看到差异之外的同级上下文。若文档和面向用户的文案存在，也请注明其位置。
2. 加载规则。 阅读 references/_sections.md 以及 references/ 中的每个规则文件（所有 gloss-*.md、lang-*.md、model-*.md、ctx-*.md、dsl-*.md 文件）。
3. 编写审查提示词。 将规则和目标填入 references/reviewer-prompt.md。组合后的提示词必须完全自包含——审查者看不到对话历史，因此不得引用提示词以外的上下文。
4. 派发一名盲审查者。 启动一个 Task 子代理，其全部输入仅为组合后的提示词——不得附带对话上下文或评论。
5. 采用失败关闭策略。 审查者的结构化输出就是裁定结果——不进行合并步骤。只有每条规则均为 PASS 或 N/A 时，总体裁定才是 PASS；任何一条 FAIL 都会导致门禁失败。绝不取平均、权衡严重性或豁免规则——即使是“轻微”的 FAIL 也仍是 FAIL。如果审查者返回“GATE NOT APPLICABLE”（目标中没有领域概念），则停止并报告这一结果，不要给出裁定。
6. 呈现裁定结果。 填写 assets/templates/verdict.md。若结果为 FAIL，将审查者提供的“达到 PASS 所需的修改建议”汇总到修复清单中，每项注明位置，并按类别重要性排序——先列术语表修改，因为记录或修正语言是检查其余规则的基础。如果某条规则的结果为 FAIL，则必须在修复清单中列出，并提供可直接照做的具体修改；如果审查者的建议只是重述违规内容，则在呈现结果前，依据规则中的 Correct 示例推导出修复方案。

如果同一目标未经修改却在重新审查时出现同一规则裁定反复变化，或者人工阅读证据后推翻裁定，则说明该规则存在可判定性缺陷——请在 gotchas.md 中记录并完善规则；不要推翻门禁。

裁定格式

审查者对每条规则返回以下内容：PASS | FAIL | N/A、证据（file:line、引文或术语表条目；PASS 和 FAIL 均必须提供），以及每条 FAIL 对应的修复方案——应用后即可使该规则通过 PASS 的修改，须注明修改内容及位置，不能只重述违规内容。审查者还须报告找到的术语表（或说明未找到术语表及搜索位置）。最终报告遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	涵盖内容
1	术语表生命周期	gloss-	存在已记录的通用语言（缺失即 FAIL）；代码符合该语言；每个条目均保持有效；定义包含业务含义
2	语言一致性	lang-	每个概念使用一个名称，每个名称表达一种含义；领域规则不得使用没有语义的名称；转换须命名为操作；代码／测试／文档／UI 使用统一词汇
3	领域模型完整性	model-	规则与模型共置；构造时保证有效；使用领域类型而非裸基本类型；使用具名状态，而非堆叠布尔标志
4	边界与上下文完整性	ctx-	上下文之间具有公开接口；供应商边界处设有防腐层；领域不依赖基础设施；每个存储模型仅有一个写入方
5	语义模型与 DSL 表面	dsl-	语义模型与承载语法分离；非法语句无法构造或会快速失败；外部 DSL 具备确定性验证器

相关 Skills

• domain-architect（实验性）——以教学方式提供领域建模指导；当目标是设计模型而非对其进行门控时使用。
• adversarial-ts-patterns（实验性）——TypeScript/React 的模式使用门控；对 TypeScript 目标运行此门控时，应同时运行该项以实现全面覆盖（它负责代码习惯用法层面的状态机和过度抽象规则）。
• feature-arch-gate（实验性）——文件夹/功能架构门控；在项目结构层面与之互补。

参考文件

文件	描述
references/reviewer-prompt.md	供每位盲审员使用的独立提示词模板
assets/templates/verdict.md	评审结论报告模板
references/_sections.md	类别定义与排序
metadata.json	版本和源引用