# 规格修改与审阅方法

在[必要前置](../SKILL.md#0-必要前置完成后才编写-spec)核实后，使用从 OpenSpec 已核对的五项做法。沿用本地身份、add/modify/delete 合同和已有制品入口。不引入 OpenSpec 目录结构、CLI、英文标题解析器、归档执行器或第二套工作流引擎。

## 1. 以完整需求及全部相关场景为修改单位

修改一项需求时，逐个相关场景判定：保留、改变、经批准删除，或新增。不能只用局部片段覆盖全部旧要求。

检查问题：
- 本轮声称修改的需求，其全部相关场景是否都有去向？
- 只改其中一个场景时，其他场景是显式保留还是被遗漏？
- 新增场景是否补了对应验收，而不是只改标题？

样例：一项需求有登录成功与登录失败两个场景，方案只改成功路径。必须标出失败路径是保留、同步修改还是经批准删除；不能把“已改成功路径”写成整项需求已覆盖。

## 2. 分别检查删除与重命名

删除与重命名是不同风险，不要用同一种核对。

删除：
- 旧行为现在是否仍可被用户观察到？
- 影响哪些制品、测试和承接位置？
- 删除项的历史去向写在哪里？`delete` 不能只从目录消失。

重命名：
- 旧身份与新身份能否同时定位？
- 变化只是名称，还是行为也改变了？
- 引用方是否仍指向旧身份？

沿用本地 add/modify/delete 与已有制品身份表达这些操作，不新增通用枚举或迁移引擎。

## 3. 按需求展示基线与目标差异

审阅时按需求组织简明对照：相关基线、此次目标、受影响场景。重点找出“名字未变但语义已经相反”的变化。

使用现有 Git 差异与 `artifact-graph query` / `context` / `impact` 定位材料。不新建持久化差异数据库，也不为对照新增 Markdown 解析器。

对照至少能回答：
- 基线要求用户看到什么？
- 本轮目标要求用户看到什么？
- 哪些场景证明这一差值？

## 4. 配置加载时提前诊断

图配置的结构或类型错误，应在加载时按字段路径报告。未知键给出可定位提示并保留兼容，不一律拒绝项目扩展。`extraFields` 仍是可选索引字段。已有配置必须显式写出 `allowedEdges`：缺字段给出路径和补配置方向；`[]`、`null` 或 YAML 空值采用内置默认表；非空清单完全替换默认表，按 from/to/kind 严格白名单校验，清单外报 `DISALLOWED_EDGE`。`forbiddenEdges` 仍优先。没有配置文件时保持未接入。分析关系配置时先读目标类型、关系语义和直接相关制品正文；只读请求只报告缺口并指向 `artifact-chain-bootstrap`，不改配置、不把扫描边一键放行。

表达服务配置由 `artifact-chain-setup` 调用 `scripts/setup-checks.mjs` 检查；缺项只影响表达路径。

SPEC 标记合同、实际安装包定位、必需标记与独立正文审阅，统一按[标记合同与独立正文审阅](../SKILL.md#32-标记合同与独立正文审阅)执行。

## 5. 识别有价值的失败样例

以下情况不能报业务通过：
- **遗漏场景**：只覆盖部分相关场景。
- **同名异义**：标题或 ID 相同，语义已相反或分裂。
- **空材料**：文件存在但没有可观察的要求或证据。
- **勾选无证据**：任务勾选、退出码 0 或模型自报完成，但没有真实行为证据。

文件存在、格式有效、复选框完成、图边成立，都不能代替语义覆盖和真实入口观察。