context-and-decisions · diff
git:20261011.d6d08d8 to git:20261012.bd30f6e
4 added, 66 removed. Audit A to A.
---
name: context-and-decisions
- description: >-
- 管理项目或模块的稳定领域上下文与难回退决策：按需建立 CONTEXT.md，复用既有 ADR 或在模块入口内联简短决策。用于领域术语反复解释、同词异义、模块边界、架构或数据库选型、认证/部署/数据模型/API 版本策略、需要记录为什么这样做及如何退出时。English triggers: domain context, context governance, architecture decision record, ADR, database decision, architectural decision.
+ description: 兼容旧 context-and-decisions 调用；领域术语与 ADR 的形成和修改统一转交随插件提供的 domain-modeling。
---
- # 领域上下文与决策
-
- 把“业务里这些词是什么意思”和“为什么选择这个方案”分开管理。没有稳定内容时不要创建空壳。
-
- ## `CONTEXT.md`：只管领域语言
-
- 在术语反复解释、同词异义或模块边界因语言不清而出错时，使用 `templates/context.example.md` 按需维护项目或模块的 `CONTEXT.md`，优先复用现有词汇表。先声明适用上下文；同一上下文同一概念统一名称，不强迫不同上下文的同名词含义相同。跨边界的名称／模型转换由契约或映射代码承载，词汇表只链接。共享术语引用项目主记录，模块只补差异，不复制整表。
-
- 只记录：
-
- - 领域术语及精确定义；
- - 核心概念之间的关系；
- - 已确认的歧义与采用口径；
- - 仍待业务方确认的歧义。
-
- 禁止写入：实现细节、当前状态、任务排期、需求全文、决策理由和历史。对应内容分别回到代码/MAP、STATUS/Issue Tracker、Spec、ADR、LOG。术语必须能和代码、契约或业务证据对照；不能确认就标“待确认”，不要猜。
-
- 与模块 AGENTS 配合时，CONTEXT 解释其中使用的业务概念，AGENTS 链接这些定义并规定操作边界，不重写词义。更名不等于业务含义变化；确实改变含义时，通过 `change-impact` 核对使用该概念的契约、业务行为及消费者。两份文档冲突时展示来源并查已确认决定，不默认以较新的文件覆盖另一份，也不让词汇表中的表述自动扩大 Agent 权限。
-
- ### 主动澄清术语（借鉴 Matt 的 domain-modeling）
-
- 此流程用于形成或改变领域语言；普通开发只读取已有 CONTEXT，不必重新建模。
-
- 1. **找到上下文。** 先读已有 CONTEXT；有 CONTEXT-MAP 时沿它定位，否则复用项目导航。单上下文可用根 CONTEXT，多上下文各自维护；归属不明先询问，不为每个目录建词汇表。
- 2. **指出歧义与冲突。** 对照已定义词义，明确指出“现有定义是 X，本次似乎指 Y”。对“账号”等多义词提出精确候选名称，让业务方确认，不自行把客户、用户和账户合并。
- 3. **用具体场景厘清边界。** 例如“一个客户能否对应多个登录用户？”或“订单允许部分取消吗？”假设场景用于提问，不作为项目事实写入。
- 4. **与代码交叉核对。** 读取相关实现与契约；用户描述和实现不符时呈现两方证据，查已有确认或请求裁决，不默认代码正确。尚无实现时注明，不能捏造核验结果。
- 5. **确认即沉淀。** 第一项术语确定且有文档写入授权时，按需创建或立即更新对应 CONTEXT，不等会话结束批量补记。未确认的问题留“待确认”，不冒充标准词义；只读任务给建议，不写文件。术语变化的下游影响用现有变更流程处理，不顺带改代码。
-
- 格式沿用 `templates/context.example.md`：每个概念选一个标准名，用一两句话定义“它是什么”，用 `_Avoid_` 列出本上下文中不再采用的同义叫法；没有别名写无。只收业务领域词，不收超时、工具函数等通用编程概念。概念多时自然分组，不强制复杂结构。已有表格可以保留并补等价字段，不为格式迁移复制另一份词汇表。共享定义只引用，不要求不同上下文同名词含义相同。
-
- CONTEXT 仍是领域词汇表，不是需求规格、实现方案或决策仓库；决策继续走下方独立流程。本插件仅借鉴 Matt 的术语澄清方法，不依赖用户安装外部 Skill，也不改变既有 ADR 记录规则。
-
- `_Avoid_` 只列同一概念不再采用的叫法；容易混淆但业务含义不同的词应解释区别，不能当作应废弃的别名。没有确认过的同义词就写无，不为填模板发明术语禁用规则。
-
- ## 模块两入口：简短决策可内联
-
- 已采用模块 `AGENTS.md` + `CONTEXT.md` 时，短小且仅影响该模块的决策可放在 AGENTS 的“决策”节，与术语分开。每条有稳定编号（如 `inventory-001`）、确认来源及 Context、Decision、Alternatives、Reason、Consequences、Status、Related、Supersedes；无替代项或前序决策写明无，不虚构。只有负责人已确认才写 `accepted`。
-
- 已有 ADR 沿用原主记录，AGENTS 仅链接；长决策、跨模块决策或历史增长导致入口超过 200 行时，复用项目 ADR 空间存放并留链接，不另造每模块 ADR 目录。替代关系双向链接、旧记录保留，不能用“只留两份文档”为由删除决策历史。内联记录目前由 Agent 核对，不能声称现有 ADR 脚本会解析其完整语义。
-
- ## 独立 ADR：一项决策一个文件
-
- 需要独立记录且没有现成 ADR 布局时，创建：
-
- - `docs/adr/README.md`：薄索引，只列编号、标题、状态和链接；
- - 一项决策一份编号文件（例如 `0001-use-postgresql.md`），套用 `templates/adr.example.md`。
-
- 使用连续四位编号。状态只允许 `proposed`、`accepted`、`deprecated`、`superseded`。ADR 至少包含：Context、Decision、Alternatives、Reason、Consequences、Status、Related、Supersedes。
-
- 以下变化默认检查是否需要 ADR：架构边界、数据库或存储、认证授权、部署拓扑、数据模型、API 版本策略、跨模块技术选型。普通实现细节、易回退的小改动和当天临时实验不要写 ADR。
-
- ## 决策流程
-
- 1. 先读取适用的 `CONTEXT.md`、模块内联决策或既有 ADR 索引和相关记录，避免重复决策。
- 2. 用真实约束写 Context；列出确实讨论过的 Alternatives，不补写虚构方案。
- 3. 在 Decision 与 Reason 中区分“选了什么”和“为什么选”。
- 4. 在 Consequences 中写收益、代价、可逆性、迁移与退出路径；不可逆部分明确标出。
- 5. 用 Related 链接 Spec/Issue、CONTRACT、TEST-ID、提交或代码位置。
- 6. 新决策替代旧决策时，新 ADR 填 Supersedes，旧 ADR 改为 `superseded` 并互相链接；不要删除旧记录。
- 7. 独立 ADR 更新既有索引（默认 `docs/adr/README.md`）；内联记录更新模块入口的决策节。从既有 MAP 导航到模块或 ADR 索引，不再复制决策正文。
- 8. 在 `PROJECT_LOG.md` 追加一条决策事件。
+ # 上下文与决策：兼容入口
- ## 排期与任务边界
+ 读取并执行 [domain-modeling](../domain-modeling/SKILL.md)，包括其[项目适配](../domain-modeling/project-adapter.md)。本入口不再维护术语澄清、格式或 ADR 流程。
- 让 GitHub Issues、Linear 或项目已有 Tracker 成为任务、状态、阻塞和排期的唯一事实源。只有项目没有外部 Tracker 时，才按项目约定使用本地 `.scratch/`；不要把排期塞进 `CONTEXT.md`、ADR、PROJECT_STATUS 或日志数据库。
+ 既有调用与链接继续有效；新路由直接使用 domain-modeling。上游方法、格式及授权随插件提供，用户无需另装外部 Skill。