domain

领域

两种独立用途：词汇工作将术语、名称或规则边界明确到足以用于验收示例、代码和对话；标准查询则为变更查找语言、数据格式、风险或测试设计标准。两者互不依赖。计划负责统一的发现与恢复；Domain 只解决所需的词汇或规则边界，并将其返回给现有意图。

词汇工作

1. 注明现有词汇负责人。 在调用方的指令、领域文档或契约中找到词汇负责人，并且只阅读相关术语。查阅是只读操作。如果没有负责人，则将每条定义标记为代码中观察到的内容或提案。
2. 在每个有界上下文中保持一种含义。 有界上下文是指术语具有一种约定含义、且有负责人制定其规则的范围。当一个词跨越多个上下文时，应说明每种含义及其在边界处的译法，而不是强行规定一个全局定义。
3. 报告与意图不符的代码。 明确术语指代的参与者、状态、操作和可观察结果，然后将预期含义与调用方、类型和测试进行比较。不匹配之处是需要解决的问题：重命名代码不会补上缺失的行为，而重新定义术语以迁就代码则会掩盖缺陷。
4. 评估共享名称的重命名成本。 导出的名称、序列化字段、存储值和 API 载荷都需要兼容性工作（迁移、版本控制、客户端更新），不能只做表面替换。命名变更须限定在授权范围内。
5. 用示例加以区分。 用具体案例区分相互竞争的含义；用 Given/When/Then 表述分支边界，并在实现和验证中复用。将确定的术语用于场景名称、操作、类型和文档。只有尚未解决的区别会改变行为或归属时才提问；查阅不需要访谈。
6. 更新负责人；默认不新增词汇表。 获准完善时，应在现有负责人处更新含义、上下文和示例。只有当该上下文的新手需要了解某个术语的定义，且它本身是一个概念而非其他条目的属性或通用编程词汇时，才将其纳入。每条词条都应独立完整：用一句话说明含义，仅在确实存在时说明行为规则（生命周期、归属），并定义其所依赖的任何项目术语。记录行为，而非当前值、日期、负责人、状态或链接。将其他上下文中仍有用的别名作为明确译法保留；在仍有效的词条中，将该上下文内已弃用的同义词列为应避免使用的词语。如果没有负责人，应在调用方的意图或对话中返回提案，而不是创建新的词汇表文件。
7. 仅在确有必要时提议决策记录。 当确定边界或重命名构成设计决策时，只有在该决策难以撤销、后续读者若不了解背景便会困惑，且是在有明确理由的情况下从实际备选方案中作出选择，才提议 ADR。三项条件缺一不可；否则更新负责人及其示例即可。如果仓库有决策记录格式，则沿用；否则提议一个简短标题，并用一到三句话说明背景、选择及理由，仅在后续读者确有需要时补充状态、否决的选项或后果。词汇负责人处不应包含实现细节；这类细节应放在决策记录或代码中。

按以下格式返回词汇工作，然后停止，直到下一项变更能够被明确命名并一致评判：

术语	上下文	含义	来源	区分示例	未决问题
<术语>	<有界上下文>	<定义>	<路径:行号、代码中观察到的内容或提案>	<Given/When/Then 或具体案例>	<调用方的决定，或无>

表格之后，列出上下文之间的译法、每一处代码与意图不符的情况、任何拟议重命名的兼容性成本，以及已更新的负责人或拟议文本。参见调用方词汇示例。

偷渡同义词这种失败模式会用改变术语权责的词替换原词：把判定称为结案，会悄然将跟踪器状态转换的责任赋予判定。替代词会转移责任时，应保留原术语。

AgentOps 术语

当 AgentOps 是讨论对象时，其所有者始终是 docs/contracts/ubiquitous-language.md；对于职责和端口，则是 docs/contracts/bounded-contexts.yaml。请返回其中的精确定义和来源路径。不要将 AgentOps 词汇用于无关的调用方领域。 运维层、联邦集成图、语义化工作与证明协议，以及 RPI 遍历在当前契约中各自保留独立含义。 队列、认领、租约、关闭、落地、释放和交付仍属于调用方系统的职责。词汇编辑不会授权这些转换。

标准查阅

仅加载当前变更所需的语言或风险指南，并从通用标准开始。 仓库契约和实际工具链优先。这些参考资料不会形成第二套审批或验证流程。

• 语言：Go、Python、Rust、JavaScript、TypeScript、shell。
• 数据与文本：JSON、YAML、Markdown。
• 相关风险：并发、SQL、LLM 信任。
• 测试设计：测试金字塔；包结构：技能结构。

理念来源：Matt Pocock 的工程技能（领域建模），经调整后用于 AgentOps。