ubiquitous-language

通用语言：通过决策演进，绝不漂移

语言的变化就是模型的变化（Evans）。每个限界上下文使用一种通用语言——试图让整个企业都使用同一种语言，终将失败（Vernon）。此技能将仓库声明的术语表作为命名权威。语言理应演进，但只能通过明确记录的决策来演进。

此技能要消除的已记录 Agent 失效模式：术语漂移——processUserData 与 processUserInfo 这样的近似重复项，或某个功能开发到一半时，“booking”悄然变成“reservation”。提示词级术语表只能引导；确定性门禁才能强制执行。

资源	在以下情况加载……
resources/language-protocol.md	遇到缺失、别扭或重复的术语——执行五个步骤并记录会改变模型的决策
resources/glossary-format.md	创建或编辑术语表——了解仓库架构、可选的 Contextive 示例、上下文范围、别名和初始化路径

---

语言所在之处

1. 声明的术语表是其限界上下文的命名权威。凡是提及某个概念，其规范拼写和大小写都很重要。使用仓库选定的文件位置和架构；不要强行采用其他术语表格式。
2. 领域代码和可执行示例使用并实践该语言。标识符、品牌类型、DSL 动词和测试标题都应使用规范术语。
3. 维护中的系统其余部分会将已批准的术语传递到架构、API、文档、图表、夹具和生成的客户端中。即使内部名称已重命名，对外的线协议词汇也可能需要经过审慎的版本管理。
4. 口头表达、计划、研究、注释、历史文档和现有代码可展现候选词汇和可能的漂移。这些是提案的依据，而不是可以默默确立术语的权威。

术语表中没有的词表示尚未达成共识，并不自动意味着该词已获批准或被禁止。

临时名称必须明确标注为暂定名称，并说明将如何批准或替换它。不要让占位名称像已批准的语言一样传播。

语言协议（核心内容）

禁止默默演进。每个新增、变更或存疑的领域术语都必须经过五个步骤——完整指南见 resources/language-protocol.md：

1. 检测——你需要一个术语表中没有的术语；发现同义词或近似重复项（一个概念对应一个词；两个短语必须表示两个概念）；某个术语在对话中显得别扭；或针对性标识符 lint 标记了一个未知领域词。缺失的术语尚未达成共识。
2. 提议——绝不直接采用。 停下并向人类提出：术语、拟议定义、限界上下文、例句以及考虑过的备选项。可用时使用宿主提供的结构化提问机制；否则，用纯文本提出一个简洁问题并给出建议。Agent 绝不能默默创造领域术语。
3. 决策——由人类批准、改名或拒绝。一次只处理一个术语，并附上建议，因此成本很低。
4. 记录——在同一个可审查的变更中添加或更新术语表条目；被拒绝或替换的别名应指向所属的限界上下文和规范术语。若重命名改变了模型而不只是标签，则使用仓库的决策记录机制；常规新增只需提交术语表差异。
5. 重命名——按此顺序执行：先做决策，然后在同一个可审查的变更中一并重构代码、测试和术语表。边界规则：可在限界上下文内部自由重命名；上下文边界处发布的语言——API、事件、架构——必须谨慎进行版本管理，绝不可随意重命名。

机械化强制执行

如果已安装机械化强制执行层（根据词汇表生成的 lint 规则），它会在 Agent 的循环中运行，并限定在特定领域路径内，强制执行以下规则：

• 项目声明的词汇问题 — 仓库可以选择在指定领域路径中标记含义模糊的后缀，例如 Manager、Helper 或 Impl。应将这些标记视为审查提示，而非普遍禁令：规范词汇表术语优先于通用问题清单。
• 词汇表驱动的标识符检查（TypeScript 中首创的旗舰规则）— 将标识符拆分为单词，使用词元类别根据上下文的词汇表检查领域词汇：词汇表术语 / 已弃用别名（标记时附上替代项）/ 路径范围内的技术停用词 / 豁免的框架标识符。
• 测试标题检查 — 根据词汇表检查标题；拒绝已弃用的别名时，指出其规范替代项。
• DSL 词汇检查 — 新增的验收 DSL 动词必须已收录在词汇表中，否则触发协议流程。
• 上下文范围内的别名和形式 — 在别名所属的上下文内进行检查；当词汇表对此有规定时，强制使用规范大小写、复数形式、标识符形式和公开线路名称。
• 仅限语言范围 — 将架构和依赖关系的强制执行交由 domain-driven-design、hexagonal-architecture 和 structure-codebase 负责；不要把结构策略塞进词汇 lint 中。

每条规则都应起到指导作用：使用三部分消息——指出触发了什么、解释规则存在的原因、说明应如何处理，并附上技能指引。没有退出途径的门禁会诱发绕过，因此应保留有记录的例外处理流程（在 PR 中说明理由并记录）。

强制执行状态：在项目中安装生成式 lint 层或等效门禁之前，这里的所有内容都只是约定——应明确说明；绝不可暗示存在实际上并未提供的保护。即使命令通过，也要报告其配置的路径和词元类别：针对特定范围逐步收紧规则，并不能证明每段文本和每个标识符都正确使用了通用语言。

每项语言检查都需要正向控制：使用一个 fixture 或专门的测试引入已知禁用词汇，并证明检查会因所属上下文和规范替代项而失败。扫描当前代码树且未发现问题，只能证明扫描器已完成运行。

采用路径

• 绿地项目 — 从词汇表和最精简、实用的正向控制检查开始；仅在发现确实存在漂移风险时才添加强制执行。
• 棕地项目 — 受保护核心的逐步收紧。 如果规则在第一天就触发数千次，就会被绕过。从一项能力或一个限界上下文开始，强制执行其领域 / 应用边界，并在工作触及相邻行为时逐步扩展。已有违规可以冻结在基线中，且基线计数只能减少。词汇表可以先以警告模式和仅检查差异的方式推出，并明确说明其有限范围。
• Spike — 将词汇视为暂定内容，并在将其推广到维护中的代码之前，按协议流程处理。遵循仓库现有的 Spike 或实验性代码策略，而不是自行发明全局标记。

边界

情况	技能
值对象、实体、聚合、限界上下文	domain-driven-design
端口 / 适配器结构及其强制执行的架构规则	hexagonal-architecture
外层循环中的 DSL 和测试标题词汇	项目的验收 / 规格说明技能
记录会改变模型的重命名	仓库的决策记录机制
探索过程中的命名问题	宿主提供的提问机制

验证清单

• 每个有界上下文都有一个由仓库声明的词汇表权威来源
• 保留仓库声明的词汇表格式和位置
• 命名已声明概念时，使用规范拼写和大小写
• 缺失的术语视为尚未达成一致
• 未经五步流程，不得创造领域术语——只能提出提案，绝不可静默采纳
• 词汇表差异与引入相关词汇的代码变更一同提交审查
• 被替代的术语记录为已弃用别名，并注明替代术语
• 被拒绝的别名指向所属有界上下文和规范术语
• 会改变模型的重命名使用仓库的决策记录机制
• 上下文边界处发布的语言须进行版本管理，绝不可随意重命名
• 在适用范围内，将已批准的术语贯穿应用于代码、类型、架构、API、测试、文档、图表、固定数据和生成的客户端
• 临时名称须明确标示为暂定名称，并提供批准或替换路径
• 别名和词形检查限定在其所属有界上下文内
• Lint 规则包含三部分的说明信息
• 将 Lint 通过结果报告为有针对性的渐进改进，而非证明整个仓库的语言使用均符合要求
• 使用正向控制验证是否能检测到禁用词汇
• Brownfield 执行范围明确，其基线不得在无提示的情况下扩大，并报告其限制
• 临时 Spike 词汇在推广前须经批准或替换