amose

Amọ̀ṣẹ́

在规划、规范、架构、实现和评审过程中，维护项目的领域含义和通用语言。保留有界上下文之间的区别；共享措辞不得掩盖不同的模型。

即使熟悉某些材料规则的表述，也要检查这些规则是否适用。沿用当前已确定的含义；不要将过时记录视为不可更改的意图，也不要为调和冲突而臆造业务规则。

澄清模型

只阅读足以厘清重要含义的证据：当前领域语言来源、具约束力的决策／政策、相关代码／测试／配置／运行时行为，以及能够解决冲突的有限历史记录。实现和运维能证明当前行为，但不能自动证明领域意图。

当含糊、含义过载、同义或相互冲突的术语可能改变范围、所有权、身份、状态、政策或行为时：

1. 指明歧义或矛盾；
2. 用能够区分相互竞争概念的最小具体场景；
3. 将其与当前领域语言和相关证据进行比较；以及
4. 只有在证据或领域权威支持时，才提出规范措辞。

当用户有意确立或更改清晰的领域含义时，只检验确保模型连贯所需的边界。不要为了证明访谈合理而凭空制造歧义。

有用的模型澄清可以确立或区分：

• 规范术语和应避免的同义词；
• 概念身份与生命周期区别；
• 有界上下文及跨上下文含义；
• 关系和所有权；以及
• 语义不变量，或既定含义与当前行为之间的矛盾。

将 yoruba-glossary 用于 Yorùbá／英语技术术语和词汇表维护；Amọ̀ṣẹ́ 负责保留项目特有的领域含义。

直接询问单个已明确理解、影响重大的有限选择。当目的、成功标准、重要权衡或潜在的依赖选择仍未确定，或用户要求访谈时，使用 arojinle。对于尚未解决的结构或重要的技术适用性问题，使用 architect。不要仅仅因为当前实现形态已经存在，就将其转化为领域词汇。

协调规范语言

如果已有领域语言来源，请阅读领域语言，并在解决后的模型发生变化且拥有写入权限时更新该来源。不要另建相互竞争的项目记忆系统或通用文档库。

如果尚未确定持久化领域语言的存放位置，请直接返回模型变更内容；只有当结果需要超出当前工作长期保留时，才指出持久化缺口。让项目或调用方选择合适的项目存放位置，不要自行创建 CONTEXT.md、.learnings、.nongoals、ADR、.qp 记录或其他仓库惯例。

当没有项目惯例时，这一领域澄清边界不妨碍经授权的 ADR 创建请求使用 ADR 后备方案。单独的领域澄清并不授权创建 ADR。

领域模型变更可能导致其他工作流更新规范、架构、文档、测试或政策。这些产物仍由各自对应的工作流负责。Amọ̀ṣẹ́ 维护项目的规范领域记录，并向其他负责人提供澄清后的含义。

维护持久领域记录

当请求涉及项目现有领域记录的内容或生命周期时，维护这些记录：

• .learnings → 阅读经验记录；
• .nongoals → 阅读非目标；或
• ADR 的资格认定或生命周期 → 阅读ADR。

使用记录在项目中现有的存放位置。保留其格式和权威边界。记录变更必须反映已确立的领域含义或经授权的项目决策；不要将任务笔记、临时延期事项或实现历史变成持久领域记录。

返回

返回已解决的术语、身份、关系、所有权、不变量、必要时用于区分的示例，以及任何尚未解决的语义冲突或重大决策，并附上相应依据。

将新发现的需求、事实或技术缺口及其控制依据返回给同一调用方。调用方整合结果，并仅重新开展受影响的工作；领域澄清不会启动另一项计划。

当规范领域语言或持久领域记录更新时，报告其存放位置和验证结果。