mcpField
R
resolve-spec-conflict

resolve-spec-conflict

github.com/plainlang开发8043 次安装今天更新
代码仓库

关于 resolve-spec-conflict

用于诊断和解决 `.plain` 功能规格冲突的技能。它区分实现、测试问题与需求矛盾，并提供修改后的验证步骤。

主要功能

  1. 01定位冲突的规格对
  2. 02区分实现、测试与需求问题
  3. 03选择冲突解决策略
  4. 04验证修改后的规格与测试

适用场景

  1. 01调查此前通过的符合性测试失败
  2. 02解决新旧规格之间的矛盾
  3. 03修改需求后更新测试场景

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/plainlang/plain-forge --skill resolve-spec-conflict

安装后在 Claude Code 中输入/resolve-spec-conflict确认已加载。

详细介绍

解决规格冲突

先加载规则。 在读取、编辑或编写任何 .plain 文件之前，先调用 load-plain-reference 技能，并阅读该技能指引的规则文件。只有当本次对话中已经运行过 load-plain-reference 时，才可跳过此步骤。

适用情形

出现以下情况时，说明存在（或疑似存在）冲突：

  • 新规格渲染后，先前通过的功能规格的符合性测试开始失败。
  • 通过 add-functional-spec 或 add-functional-specs 技能添加的新规格似乎与现有规格矛盾。
  • 两个规格对相同的行为、数据或状态提出了不兼容的断言。

工作流

步骤 1：找出冲突的规格对

阅读 .plain 文件，找出存在矛盾的两个规格。如果冲突是通过符合性测试失败发现的，还要阅读失败的测试和 plain_modules/ 中生成的实现，以了解行为发生了什么变化。

步骤 2：诊断根本原因

可能的结果有三种——在进行更改之前，先确定适用的是哪一种：

结果症状修复方法
实现有误生成的代码与规格意图不符。规格本身没有问题。澄清含糊的规格，使渲染器能正确理解。重新渲染。
符合性测试有误测试未能准确验证规格。实际上实现是正确的。调整 ***test reqs***，或通过 add-test-scenarios 技能调整测试 plain 文件中的场景，以便更好地指导测试生成。重新渲染。
需求确实冲突两个规格存在根本矛盾——没有任何实现能同时满足二者。必须修订一个或两个规格。参见步骤 3。

诊断方法：

  1. 仔细阅读两个功能规格。单个实现能否同时满足二者？
  2. 如果可以 → 规格兼容；问题在于歧义（结果 1）或测试不佳（结果 2）。
  3. 如果不可以 → 需求确实冲突（结果 3）。
步骤 3：解决冲突

当需求确实冲突时，选择一种解决策略：

策略 A：补充细节以消除歧义。 规格往往并非相互矛盾，只是含糊到足以让渲染器采用互相冲突的解读。在一个或两个规格中补充明确的上下文即可消除歧义。

修改前（有歧义）：

***functional specs***

# list-resources
All :Resource: items are returned.

# list-active-resources
Only active :Resource: items are returned.

修改后（已消除歧义）：

***functional specs***

# list-resources
All :Resource: items are returned when no filter is specified.

# list-active-resources
When the "active" filter is specified, only active :Resource: items are returned.

策略 B：修订较新的规格。 如果冲突是由新规格引入的，应重写该规格，使其与较早规格确立的行为兼容。

策略 C：修订较旧的规格。 如果旧规格的描述不够充分，而新需求揭示了更好的设计，则更新旧规格。此策略影响更大——该规格及其后所有规格的符合性测试可能都需要重新渲染。

策略 D：合并为一个规格。 如果两个规格描述的行为有所重叠，则将它们合并为一个清晰的规格。删除冗余规格及其测试 plain 文件，并将仍然有效的场景移至保留的功能文件。注意不得超过 200 LOC 的限制。

步骤 4：验证解决方案

编辑后：

  1. 重新阅读完整的 ***functional specs*** 部分，确认没有引入新的冲突。
  2. 检查修订后的规格是否仍符合 200 LOC 限制。
  3. 检查时间顺序是否仍然合理（较早的规格不应依赖较晚的规格）。
  4. 如果通过调整测试来解决冲突，请确认 ***test reqs*** 或测试 plain 文件的修改是恰当的。
  5. 对于每个修订过的功能，调用 add-test-scenarios，使其测试 plain 文件与新文本保持一致。

预防（在使用 add-functional-spec / add-functional-specs 时）

添加新规范前，快速检查是否存在冲突：

  1. 列出所有涉及与新规范相同的 :Concepts: 的现有功能规范。
  2. 对每个规范，询问：“同一个实现能否同时满足这份现有规范和新规范？”
  3. 如果任何答案都不是“显然可以”，就应在插入新规范前添加明确细节，消除歧义。

验证清单

  • 已诊断根本原因（实现 / 测试 / 真正的冲突）
  • 已选择并应用解决策略
  • 修订后的规范与语言无关
  • 已根据 concise-specs.md 精简修订后的规范——新增的消歧内容尽可能简短
  • 修订后的规范各自隐含的代码量不超过 200 行
  • 修复未引入新冲突
  • 保持时间顺序
  • 所有引用的 :Concepts: 仍有定义
  • 通过 add-test-scenarios 添加修订后功能的纯文件测试

评论

支持 Markdown