@ifrankwang/openspec-agents 0.148.0 → 0.149.1

package/.dsh-plugin/opx-tools.mjs

@@ -5830,7 +5830,7 @@ function renderCheckpoint(rec, workflow, item) {
   const entry = rec.stepId ? workflow.stepMap.get(rec.stepId) : undefined;
   const stepCaps = Array.from(new Set((entry?.step.agents ?? []).flatMap((a) => a.capability_tags)));
   if (resolveMustDoForCaps(stepCaps).length > 0) {
-    lines.push(`质量门类 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`, "");
+    lines.push(`含必做清单的 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`, "");
   }
   return lines.join(`
 `);
@@ -8149,8 +8149,8 @@ function handleReviewParams(item, params, newChildren, stepId, opts) {
   if (params.verdict === "passed" && !opts.skipMustDoGate) {
     const uncovered = uncoveredMustDo(opts.capabilityTags, params.validation_steps);
     if (uncovered.length > 0) {
-      throw new Error(`提交的验证步骤未覆盖质量门 skill 必做清单，缺少以下必做项：${uncovered.join("、")}。
-` + `请按已加载质量门类 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` + `确实无法执行的必做项须以结构化 skip_reason 申报降级理由` + `（格式：${SKIP_REASON_FORMAT}）。` + `低成本必做项必须实跑后申报；核验申报仅限 workflow 指令白名单限定的高成本必做项。`);
+      throw new Error(`提交的验证步骤未覆盖已加载 skill 的必做清单，缺少以下必做项：${uncovered.join("、")}。
+` + `请按已加载 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` + `确实无法执行的必做项须以结构化 skip_reason 申报降级理由` + `（格式：${SKIP_REASON_FORMAT}）。` + `低成本必做项必须实跑后申报；核验申报仅限 workflow 指令白名单限定的高成本必做项。`);
     }
   }
   const isTaskVerifyStep = stepId === "verify_task" || stepId === "quality_review";
@@ -8433,7 +8433,7 @@ async function applyCheckpointDecision(params, item, workflow, ctx, state) {
       }
       const missing = uncovered.filter((m) => !provided.has(m));
       if (missing.length > 0) {
-        throw new Error(`giveup 无法应用：当前 step 的质量门必做清单存在未覆盖项，须逐项提供结构化降级理由。
+        throw new Error(`giveup 无法应用：当前 step 的已加载 skill 必做清单存在未覆盖项，须逐项提供结构化降级理由。
 ` + `缺少降级理由的必做项：${missing.join("、")}
 ` + `请通过 checkpoint_skip_reasons 逐项提供（giveup 未覆盖项不可跳过申报）：
 ` + `[${SKIP_REASON_FORMAT}]`);
@@ -8671,7 +8671,7 @@ var checkpointSkipReasonItem = {
   type: "object",
   description: "giveup 决策的必做项结构化降级理由",
   properties: {
-    item: { type: "string", minLength: 1, description: "对应的必做项（质量门 skill 的 must_do 清单项）" },
+    item: { type: "string", minLength: 1, description: "对应的必做项（已加载 skill 的 must_do 清单项）" },
     category: { type: "string", minLength: 1, description: "降级类别，如环境不可用 / 用户裁定豁免 / 无人值守自动降级" },
     adjudication: {
       type: "string",
@@ -8852,7 +8852,7 @@ var agentSubmitSchema = {
     },
     checkpoint_skip_reasons: {
       type: "array",
-      description: "giveup 决策配套：对当前 step 质量门必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
+      description: "giveup 决策配套：对当前 step 已加载 skill 必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
       items: checkpointSkipReasonItem
     },
     new_children: {

package/.mcp-server/cli.mjs

@@ -27427,7 +27427,7 @@ function renderCheckpoint(rec, workflow, item) {
   const entry = rec.stepId ? workflow.stepMap.get(rec.stepId) : undefined;
   const stepCaps = Array.from(new Set((entry?.step.agents ?? []).flatMap((a) => a.capability_tags)));
   if (resolveMustDoForCaps(stepCaps).length > 0) {
-    lines.push(`质量门类 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`, "");
+    lines.push(`含必做清单的 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`, "");
   }
   return lines.join(`
 `);
@@ -29746,8 +29746,8 @@ function handleReviewParams(item, params, newChildren, stepId, opts) {
   if (params.verdict === "passed" && !opts.skipMustDoGate) {
     const uncovered = uncoveredMustDo(opts.capabilityTags, params.validation_steps);
     if (uncovered.length > 0) {
-      throw new Error(`提交的验证步骤未覆盖质量门 skill 必做清单，缺少以下必做项：${uncovered.join("、")}。
-` + `请按已加载质量门类 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` + `确实无法执行的必做项须以结构化 skip_reason 申报降级理由` + `（格式：${SKIP_REASON_FORMAT}）。` + `低成本必做项必须实跑后申报；核验申报仅限 workflow 指令白名单限定的高成本必做项。`);
+      throw new Error(`提交的验证步骤未覆盖已加载 skill 的必做清单，缺少以下必做项：${uncovered.join("、")}。
+` + `请按已加载 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` + `确实无法执行的必做项须以结构化 skip_reason 申报降级理由` + `（格式：${SKIP_REASON_FORMAT}）。` + `低成本必做项必须实跑后申报；核验申报仅限 workflow 指令白名单限定的高成本必做项。`);
     }
   }
   const isTaskVerifyStep = stepId === "verify_task" || stepId === "quality_review";
@@ -30030,7 +30030,7 @@ async function applyCheckpointDecision(params, item, workflow, ctx, state) {
       }
       const missing = uncovered.filter((m) => !provided.has(m));
       if (missing.length > 0) {
-        throw new Error(`giveup 无法应用：当前 step 的质量门必做清单存在未覆盖项，须逐项提供结构化降级理由。
+        throw new Error(`giveup 无法应用：当前 step 的已加载 skill 必做清单存在未覆盖项，须逐项提供结构化降级理由。
 ` + `缺少降级理由的必做项：${missing.join("、")}
 ` + `请通过 checkpoint_skip_reasons 逐项提供（giveup 未覆盖项不可跳过申报）：
 ` + `[${SKIP_REASON_FORMAT}]`);
@@ -30255,7 +30255,7 @@ var checkpointSkipReasonItem = {
   type: "object",
   description: "giveup 决策的必做项结构化降级理由",
   properties: {
-    item: { type: "string", minLength: 1, description: "对应的必做项（质量门 skill 的 must_do 清单项）" },
+    item: { type: "string", minLength: 1, description: "对应的必做项（已加载 skill 的 must_do 清单项）" },
     category: { type: "string", minLength: 1, description: "降级类别，如环境不可用 / 用户裁定豁免 / 无人值守自动降级" },
     adjudication: {
       type: "string",
@@ -30436,7 +30436,7 @@ var agentSubmitSchema = {
     },
     checkpoint_skip_reasons: {
       type: "array",
-      description: "giveup 决策配套：对当前 step 质量门必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
+      description: "giveup 决策配套：对当前 step 已加载 skill 必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
       items: checkpointSkipReasonItem
     },
     new_children: {
@@ -30575,7 +30575,7 @@ async function ensureDefaultUnattended(args, ctx) {
     }
   } catch {}
 }
-var PKG_VERSION = "0.148.0";
+var PKG_VERSION = "0.149.1";
 function buildMcpServer(worktree, opts = {}) {
   const mcp = new McpServer({ name: "openspec-agents", version: PKG_VERSION });
   for (const [name, spec] of Object.entries(TOOL_SPECS)) {

package/README.md

@@ -3,34 +3,49 @@
 ![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)
 ![Built for OpenSpec](https://img.shields.io/badge/built%20for-OpenSpec-6b46c1.svg)
 
-> AI 写代码很快，但没有东西替你把关。
+`openspec-agents` 是 [OpenSpec](https://openspec.sh) 的配套插件，兼容 Claude Code / Codex / ZCode / DeepSeek Harness / OpenCode：提案阶段把标准钉得更死（澄清在前、改动范围与契约变更逐条确认），实施阶段由多 Agent 分工——写、查、验收、质量审查各由不同 Agent 担任，按生产级标准把控到收口。
 
-`openspec-agents` 是一组面向主流 AI 编码工具的插件，给 AI 写代码补上「可以交付」这道关卡：一个变更从「实现 → 检查 → 验收 → 收口」逐步推进，每一步都要通过校验才能往下走，通不过就退回去修；过程留痕，中断能接上。
+前提：项目正在使用 OpenSpec 管理需求。
 
-它补的是 [OpenSpec](https://openspec.sh) 变更从「规范写好了」到「代码真的没问题」之间的实施与把关环节。前提是你的项目在用 OpenSpec 管需求。
+| | |
+|---|---|
+| 适合 | 变更需要真正落进代码库、有验收标准、需通过检查、过程可追溯的团队与项目 |
+| 不适合 | 希望快速产出 demo、不走检查与验收的场景 |
+| 代价 | 比单个 AI 直接修改更慢，Token 消耗更高 |
+| 模型选型 | 实施用 flash 类模型，提案用旗舰模型 |
 
-## 你可能正遇到这些
+## 常见痛点
 
-- AI 一次改一大片，改完说「完成了」，但没人验证过它到底改对没有。
-- 一个共用逻辑被改动了，另一个入口还在用老写法，谁也没发现。
-- 出了问题想复盘，只翻得到一堆对话流水，看不出当时谁按什么标准放行的。
+- AI 一次改一大片，改完声称「完成了」——能编译、测试也通过，但其中夹带的空实现与伪成功未被发现。
+- 共用逻辑被改动后，其他调用入口仍在使用旧写法，无人察觉。
+- 出了问题想复盘，只能翻到大量对话记录，看不出当时按什么标准放行。
 
-## 它和你现在用的有什么不同
+## 与工具自带工作流的区别
 
-Claude Code 和 DeepSeek Harness 自带的工作流能力擅长**一次把很多活并行干完**。这个插件管的是另一件事，两者可以叠着用。
+Claude Code 和 DeepSeek Harness 自带的工作流能力擅长**并行完成大量独立任务**。这个插件解决的是另一件事，两者可以叠加使用。
 
 | | 工具自带的工作流 | 本插件 |
 |---|---|---|
-| 擅长 | 一次并行干完大量独立任务 | 一个变更按阶段推进，每步把关 |
-| 怎么放行 | 脚本里的判断 | 流程规则由程序强制：检查没做完、问题没闭环就不许提交通过 |
-| 换工具 | 各家私有 | 一套流程跨工具通用 |
-| 中断之后 | 进度绑在对话或某次运行上 | 进度记在仓库里，换会话、换工具都能接上 |
+| 擅长 | 并行完成大量独立任务 | 单个变更按阶段推进，逐层把关 |
+| 如何放行 | 由脚本中的判断决定 | 由程序强制：检查未完成、问题未闭环时无法以「通过」提交 |
+| 跨工具 | 各家私有 | 同一套流程跨工具通用 |
+| 中断之后 | 进度依附于对话或单次运行 | 进度记录在仓库中，换会话、换工具均可继续 |
+
+一句话：原生工作流负责把任务做完，这个插件负责判定产出是否达到生产级。
+
+## 局限
+
+使用前请先确认以下三条边界。
+
+**存量项目需要一次收敛成本。** 判据按理想状态定义（方法不超过 50 行、类职责单一、核心域不依赖框架、构建产物需忽略、覆盖率需达标），且工具检查覆盖全量代码——存量违规同样按原级别上报并阻塞。存量项目首次运行会暴露大量存量问题，只能逐个修复，或逐个走豁免裁定；裁定通过的会沉淀进项目级清单，后续变更不再重复阻塞。
+
+**Java 之外只有通用规范。** 23 份 skill 中 10 份技术栈无关、11 份为 Java 后端配套（含具体构建与检查命令、ArchUnit 规则、Spotless / PMD / SonarQube 配置）。非 Java 项目审查照常执行，但编译、格式、静态分析、覆盖率这几项确定性检查没有现成命令，需自行补充一份技术栈 skill，否则只能按降级申报跳过。
 
-一句话：原生工作流管「把活干完」，这个插件管「这次变更算不算通过」。
+**架构规范只有 DDD 一套。** 包组织有两种等价的合法风格——四层分层（domain / application / infrastructure / interfaces）与六边形（内核 + 入站 / 出站适配器），采用哪种由项目声明，未声明时按四层认定。不按 DDD 组织的项目（例如 MVC + Service + DAO 直写）没有对应规范，会被判定为偏离规范并报出问题；项目已有自己的架构规范时以项目规范为准，但该规范需自行写入。
 
-## 从零跑起来
+## 快速开始
 
-**前提**：项目已经在用 OpenSpec。没有的话先装上并初始化：
+项目还没用 OpenSpec 的话，先装上并初始化：
 
 ```bash
 npm install -g @fission-ai/openspec
@@ -91,22 +106,23 @@ npm install -D @ifrankwang/openspec-agents
 
 首次加载时，插件会在项目 `.opencode/agents/` 下生成三个代理定义文件。这些文件带生成标记，插件**每次加载**都按当前版本重写；要自己改，先删掉文件里的生成标记。
 
-### 第二步：确认装上了
+### 第二步：确认安装成功
 
 重启后查看可用 skill 列表：`openspec-standard`、`orchestrator` 是插件自带的两个入口，它们和一批规范类 skill 一起出现在列表里，就说明插件已经生效。这些 skill 可以像命令一样唤起（DSH 里输入 `/` 即可看到并调用）。
 
-### 第三步：开始
+### 第三步：开始使用
 
 - 项目里还没提变更时，调用 `/openspec-standard`，把提案标准装进项目。
-- 用 OpenSpec 提一个变更（按 OpenSpec 的用法，在你的 AI 工具里把要做的事说清楚，生成 `openspec/changes/<变更名>/` 下的文档），然后调用 `/orchestrator {change-id}` 开始编排。`{change-id}` 就是那个目录名，`openspec list` 能看到当前有哪些变更。
+- 提变更用 OpenSpec 官方命令：`/openspec-propose {具体需求描述}`，生成 `openspec/changes/<变更名>/` 下的文档；装过提案标准后，这些文档会按更严的标准产出。
+- 然后调用 `/orchestrator {change-id}` 开始编排。`{change-id}` 就是那个目录名，`openspec list` 能看到当前有哪些变更。
 
 > 不同工具里 skill 的呈现形式可能不同，以各工具实际显示为准。
 
-### 默认由 AI 自行拍板
+### 默认无人值守
 
 各安装方式**默认都开启无人值守**：流程里需要人拍板的环节（方案怎么选、无法自动验证的部分）由编排 AI 自行决断，不会停下来问你——**审查和门禁照常跑，变的只是「要不要来问你」**。希望它在这些地方先问你，让它关掉无人值守模式即可。
 
-### 顺手加两行进 `.gitignore`
+### 将以下两行加入 `.gitignore`
 
 ```
 .worktree/
@@ -115,32 +131,6 @@ openspec/states/
 
 两者都不该进版本库：前者是变更（以及独立审查）的独立工作副本，后者是流程进度。
 
-## 它替你守住什么
-
-- **分工协作**：不再是单个 AI 从头写到尾、写完自己说没问题。完整模式下，实现、检查、验收、质量审查是彼此分开的角色；精简模式把确定性检查交给开发者执行，再由一个审查者合并复核。
-- **每一步都要过校验**：完整模式下，实现完先过工具检查，再走独立验收，最后过多个维度的质量审查，结论不通过就退回修复。流程规则由程序强制——检查没做完、问题没闭环，就不可能以「通过」提交；至于质量判断本身，仍由承担该环节的审查角色给出。
-- **问题跟到底**：变更编排里，审查发现的问题会一直挂在变更上，要么修好，要么走豁免流程由报出该问题的审查者裁定通过，否则不允许继续推进。
-- **写隔离**：变更在独立分支和独立工作副本里做，收口前你的基准分支上看不到这些改动。
-- **中断能接上**：进度记在仓库里，问一句「现在跑到哪了」就能看到；关掉工具、隔一天、换个工具，都能从上次的位置继续。
-- **规范驱动**：直接消费 OpenSpec 的提案、规格、设计、任务清单，流程与规范一一对应。
-
-初始化编排时选流程模式，**默认是精简模式**：精简模式把确定性检查交给开发者执行、审查者分级复验，小改动不必走全套；完整模式开头多一道方案预检，验收也拆得更细。
-
-## 内置的规范库
-
-插件自带 22 份 skill（含两个流程入口），装了就有，不用自己写提示词；审查的 AI 会按当前任务需要自动挂上对应的一组。
-
-**两个入口**
-
-- `orchestrator` —— 编排准则，主代理按它分派子代理、推进流程。
-- `openspec-standard` —— 提案标准初始化。
-
-**9 份通用规范**：DDD 分层与六边形、REST 接口约定、数据库设计约定、安全审查基线、确定性质量门、技术债识别、架构演进审查、API 自动化测试、隔离环境清理。
-
-**11 份 Java 后端配套**：在通用规范之上补齐 Java / Spring 的实现细节 —— Lombok、日志与命名约定、REST 接口的 Java 实现、MyBatisPlus 与 Flyway、DDD 的 Java 实现与 ArchUnit 规则、Maven / Spotless / PMD / SonarQube 质量门、工具规则改进、Java 开发实践、Java 安全实现、Java 性能与可维护性、Java 技术债形态。
-
-Java 后端项目会自动带上配套那套；其它语言目前只有通用规范生效，具体的构建与检查命令由你项目的规范补充。
-
 ## 提案标准化
 
 OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，给出文档骨架与写作要求。这套标准在它前面加一道澄清与确认关，并把改动范围、契约变更、文档语言钉得更死。
@@ -157,10 +147,60 @@ OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，
 | 任务划分 | 分组 + 每条带验证方式 | 追加：每组必须有真实代码改动（禁止「收尾组」凑数）、测试跟着实现同组、只覆盖本仓库 |
 | 归档 | 官方归档命令本身会同步主规格 | 追加写作纪律：主规格只写终态，不留「原 X 改为 Y」；废弃项显式删除并补 REMOVED；同语义合并去重 |
 
-用法：在目标项目的普通会话里调用 `/openspec-standard`（不要在被编排流程占用的会话里调用，那种会话不能改文件）。它会先检查项目有没有 `openspec/` 目录，再把标准写进去。
+**用法**：在目标项目的普通会话里调用 `/openspec-standard`（不要在被编排流程占用的会话里调用，那种会话不能改文件）。它会往项目写入 `openspec/config.yaml`（指定 `spec-driven-standard` schema）与 `openspec/schemas/spec-driven-standard/`。
+
+装好之后提变更不必换命令，仍走 OpenSpec 官方用法：调用 `/openspec-propose {具体需求描述}`，生成的 proposal / specs / design / tasks 就会按这套标准产出，再由 `/orchestrator {change-id}` 接手实施与把关。
 
 已经装过标准的项目重跑就是升级：标准更新到插件当前版本，你自己加的规则条目和项目背景会保留。
 
+## 质量把关机制
+
+「生产级」不是靠提示词要求的，而是逐层校验出来的。
+
+**审查分工**
+
+```
+完整模式  方案预检 → 实现 → 工具检查 → 独立验收 → 五维质量审查 → 收口
+精简模式  实现 → 合并审查 → 收口
+```
+
+最终判定不由实现者自己作出。完整模式下，检查、验收、质量审查由彼此独立的角色承担；精简模式由开发者执行确定性检查，再由一名审查者独立复核。
+
+**工具与 AI 的分工**
+
+确定性检查全部交给工具执行：编译、代码格式、架构约束、静态分析、单元测试与覆盖率、深度扫描，以及质量工具配置有没有被弱化。AI 审查只负责工具覆盖不到的部分——业务行为是否真实生效、关键数据是否真的落库、测试断言有没有放水、设计与规则边界是否站得住，并把其中可工具化的发现反过来沉淀成规则。判据锚在 skill 上，不是让模型现场发挥，所以非旗舰模型（flash 类）的产出下限同样有保障。
+
+**通过标准**
+
+- **五级定级**：Critical / High / Medium / Low / Info，各级判例锚定规范 skill；Info 仅为建议，Low 及以上未修复不得推进。
+- **问题闭环**：审查报出的问题挂在变更上，修复后由报出该问题的审查者复核通过方为终结；确实无法修复的提交豁免申请，由同一审查者裁定，被驳回则退回重修。
+- **程序强制**：检查未完成、问题未闭环时，无法以「通过」提交——由工具拦截，而非依赖提示词约束。
+- **禁止规避**：压制注解、关闭规则、修改扫描平台状态一律视为豁免申请，须写明理由并接受裁定；同一问题修复未过两次，须先完成根因分析再修改。
+- **规则沉淀**：可由工具检出的问题，要求同时提交业务问题与规则草案，将本次判定口径沉淀为后续的自动拦截规则。
+
+**其他特性**
+
+- **变更隔离**：变更在独立分支与独立工作副本中进行，收口前基准分支上看不到这些改动。
+- **可续跑**：进度记录在仓库中，查询当前状态即可恢复；关闭工具、跨天、更换工具都能从上次位置继续。
+- **规范驱动**：直接消费 OpenSpec 的提案、规格、设计与任务清单，流程与规范一一对应。
+
+初始化编排时选择流程模式，**默认为精简模式**：精简模式下小改动不必走全套流程；完整模式在开头增加一道方案预检，验收也拆得更细。
+
+## 内置的规范库
+
+插件自带 23 份 skill（含两个流程入口），安装后即可使用，无需自行编写提示词；审查 AI 会按当前任务自动加载对应的一组，作为判据的**最低基准**——审查者还需结合自身领域知识扩展覆盖，不限于清单所列条目。
+
+**两个入口**
+
+- `orchestrator` —— 编排准则，主代理按它分派子代理、推进流程。
+- `openspec-standard` —— 提案标准初始化。
+
+**10 份通用规范**：DDD 分层与六边形、REST 接口约定、数据库设计约定、安全审查基线、确定性质量门、测试设计、技术债识别、架构演进审查、API 自动化测试、隔离环境清理。
+
+**11 份 Java 后端配套**：在通用规范之上补齐 Java / Spring 的实现细节 —— Lombok、日志与命名约定、REST 接口的 Java 实现、MyBatisPlus 与 Flyway、DDD 的 Java 实现与 ArchUnit 规则、Maven / Spotless / PMD / SonarQube 质量门、工具规则改进、Java 开发实践、Java 安全实现、Java 性能与可维护性、Java 技术债形态。
+
+Java 后端项目会自动带上配套那套；其它语言目前只有通用规范生效，具体的构建与检查命令由你项目的规范补充。
+
 ## 独立审查会话
 
 除了绑定变更的编排，插件也支持不绑定任何变更的独立代码审查：对一个 PR 的改动区间、或整个代码库做一次完整审查。
@@ -173,7 +213,7 @@ OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，
 
 审查在独立工作副本里进行。`fix` 模式全部通过后把工作分支合并回目标分支并清理环境；`none` 模式不合并，直接销毁工作环境并按严重级别、维度、文件位置归并给出审查结果。
 
-## 它会往你仓库里写什么
+## 对仓库的写入范围
 
 编排流程只碰这几处，全在你的仓库内：
 
@@ -185,16 +225,7 @@ OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，
 
 变更的全部任务组完成后，才会把这条分支合并回基准分支，随后自动删掉工作副本和分支。合并前如果基准分支已经往前走了，插件先比对两边改动：只有文档、规划文件或版本号这类无害变化时直接合并；有实质冲突时退回做一次收尾回归，通过后才合并。
 
-**中途想放弃**：删掉工作副本和 `change/<变更号>` 分支即可，基准分支上不会留下这个变更的任何代码。
-
-## 适用场景与代价
-
-| | |
-|---|---|
-| 适合 | 一个变更要真正落进代码库、有验收标准、要过几道检查、过程要能审计，可能跨天甚至跨工具的团队与项目 |
-| 代价 | 比单个 AI 直接改更慢，Token 消耗更高 |
-
-如果你愿意用一点成本换取稳定、可复现、可审计的实施过程，这个项目就是为你准备的。
+**中途放弃**：删除工作副本与 `change/<变更号>` 分支即可，基准分支不会留下该变更的任何代码。
 
 ## 开发
 

package/assets/agents/openspec-developer.md

@@ -11,7 +11,7 @@ permission:
 
 ## 角色（开发者身份）
 
-你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门与接口测试的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
+你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门、接口测试与测试设计的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
 
 提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
 

package/assets/agents/openspec-reviewer.md

@@ -65,7 +65,7 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 |------|-------------|-------------|---------|
 | Critical | 核心 task 产出文件缺失 | 服务无法启动（无论是否本次变更引起） | 测试依赖无隔离环境导致 CI 必然失败 |
 | High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效）；流程执行正常但关键数据产出缺失/未落库/落错位置（区别于『仅打状态标记未实际生效』：本行=流程与响应正常，产出物缺失或落错位） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为；测试仅验证流程跑通/响应成功，未对 spec 要求的关键数据产出（落位/完整性）断言 |
-| Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
+| Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试或未提交测试设计物证据（行为面清单/用例矩阵/反向探针记录）；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
 | Low | 产出文件位置不符合约定 | 启动日志格式不统一 | 测试命名不规范但不影响运行 |
 | Info | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -197,7 +197,7 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 ## 职责边界（确定性检查与任务验证）
 
 - **确定性工具检查**：工具维度审查者与 simple 合并审查者被允许运行确定性工具检查（代码格式/架构约束/静态分析/单元测试编译/深度扫描），按已加载质量门 skill 的必做清单执行并将输出映射为统一 issue 结构；检查结果纳入审查结论
-- **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷
+- **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷；测试设计核验——对照 spec 与独立推导的行为面核验测试设计物（行为面清单、用例矩阵、反向探针记录），识别漏面、漏格、断言放水与探针缺失
 - **维度审查锚点**：以 spec 验收标准、行为组与数据产出要求为主锚做对照审查，skill 检查点清单与 dev 自检申报对照兜底（抽查申报遗漏项）
 - **工具改进**：可工具化的质量 pattern 双报业务 issue 与工具改进 issue（规则草案由审查者提供），实施工作由开发者完成，审查者不直接改动规则/配置文件以外的实现
 

package/assets/skills/test-design/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: test-design
+description: 测试设计规范（技术栈无关）——从 spec 与契约独立推导行为面与用例矩阵，定义覆盖类别、断言强度、用例与实现解耦、反向探针与证据形态。
+capabilities: ["test-design"]
+# 机器可读检查项清单：与下方「证据形态」表格逐项对应。
+must_do: ["behavior_surface", "case_matrix", "negative_probe"]
+---
+
+> **项目规范优先**：本 skill 所列约定为推荐标准。若项目已有明确规范且与本 skill 不一致，以项目规范为准。
+
+## 行为面推导
+
+从 spec 与接口/数据契约推导本次变更牵动的行为面，作为覆盖的完整边界；禁止把验收标准的条目直接当成行为面清单：
+
+- 状态与流程：新增/变更的状态、状态流转路径、初始态与终止态
+- 数据承载：新增/变更字段、字段的产出与读写位置、可空性、默认值
+- 枚举与取值域：有限取值集合、类别标记、字典项
+- 权限与可见性：谁能调用、越权访问的拒绝路径
+- 外部依赖：第三方与下游调用、超时与失败路径
+- 可选路径：可选字段、可选分支、可跳过的步骤
+- 异步产出：延迟落库、消息入队、下游消费
+
+行为面条目多于验收标准条目属正常：一条验收标准常牵动多条行为面。
+
+## 用例矩阵
+
+每条行为面至少覆盖三类，缺一类即覆盖不全：
+
+| 类别 | 取值与场景 |
+|------|-----------|
+| 正常 | 按契约传入合法值，断言响应结构与关键产出 |
+| 边界 | 空值/空集合/零、极值、超长、边界长度、类型非法、精度与舍入、日期与时间边界 |
+| 异常 | 非法状态跳转、重复提交与幂等、并发、事务回滚、部分失败、依赖不可用与超时、越权访问 |
+
+组合与状态迁移：多个可选字段或条件并存时按判定表收敛组合；状态机逐条迁移覆盖合法边与非法边，非法迁移须断言被拒绝。
+
+## 断言强度
+
+- 每条行为至少一条「实现写错就红」的断言：断具体值、状态流转结果、副作用是否发生，而不是「没报错」
+- 仅断言响应成功、字段非空、流程跑通，不构成断言
+- 同一请求内一并发生的多个行为逐个断言，禁止以其中一个行为的断言替代其余
+- 断言范围包括连带效果：状态落库、消息入队、下游可消费、产出字段落位与完整性
+
+## 用例与实现解耦
+
+- 预期值来自 spec 与契约，不得先运行实现再把实际结果抄成期望
+- 禁止 mock 被测对象本身；替身只用于外部依赖
+- 用例只依赖契约与可观察行为，不依赖实现内部结构（私有方法名、内部字段）
+
+## 反向探针
+
+取至少一条关键用例做对抗校验，证明用例真能发现问题：
+
+1. 把实现改坏（拔掉被测行为、翻转判定条件、让产出落错位置）
+2. 确认该用例失败
+3. 还原实现，确认该用例恢复通过
+
+记录探针的改坏点、变红的用例、还原确认结果。反向探针未通过的用例视为无对抗力，须重写。
+
+## 证据形态
+
+| 检查项 | 交付物 |
+|--------|--------|
+| behavior_surface | 行为面清单（按上节维度列出，标注对应验收标准） |
+| case_matrix | 用例矩阵：行为面 × 类别 → 用例名/脚本名，每格注明断什么 |
+| negative_probe | 探针记录：改坏点、变红用例、还原确认结果 |
+
+## 适用范围
+
+有代码、接口契约或数据口径变更时必须执行；纯文档、纯格式与注释变更不适用。

package/assets/workflows/review-simple.yaml

@@ -34,7 +34,7 @@ phases:
       - id: implement
         agents:
           - id: openspec-developer
-            capability_tags: [efficiency, api-testing, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
+            capability_tags: [efficiency, api-testing, test-design, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
         transitions:
           on_pass: quality_review
           on_fail: implement
@@ -43,6 +43,7 @@ phases:
           - "执行边界缺省整个 worktree（独立审查无分析环节，不生成边界白名单）；issue 的 file 字段指向的文件即修复边界，修复这些文件（含回归引入问题）不算越界；可按 issue 的 suggestion 直接执行修复；reviewer 的 boundary_expansion 已并入边界"
           - "对修复未过次数≥2 的 issue 须先完成 5-Why 根因分析再动手，不得跳过分析直接改代码"
           - "修复完成后先 git commit 再提交；提交前按已加载的质量门类 skill 完成本地构建验证，并按维度规范类 skill（style/architecture/performance/security/maintainability 能力类别）对本次修复文件逐项自检，自检结论与工具检查结果一并汇总进 self_check_results"
+          - "有代码、接口契约或数据口径变更时，须按已加载的测试设计规范产出行为面清单、用例矩阵与反向探针记录，随提交在 self_check_results 中逐项申报；反向探针结束后必须先还原实现并复跑全量用例确认全绿再提交，禁止带着改坏的实现提交"
           - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；验证完成后停止本次启动的实例，不留残留，残留判定遵循已加载清理规范的归属判别，无法确认归属本变更的进程一律不清；禁止为腾出端口或资源而停止、复用或干扰非本会话启动的进程"
           - "确定性质量工具检查出的问题不得以压制手段（压制注解/注释抑制/规则排除配置/平台状态标注/构建跳过开关等）静默规避：确需压制时，必须在压制处代码注释说明清楚理由，并经 exempt_issue_ids 申请豁免由报源 reviewer 裁定；不得以 fixed_issue_ids 冒充修复"
           - "提交 opx_agent_submit：必传 verdict；修复完成的 issue 经 fixed_issue_ids 上报、不可修 issue 经 exempt_issue_ids 申请豁免"
@@ -56,7 +57,7 @@ phases:
       - id: quality_review
         agents:
           - id: openspec-reviewer
-            capability_tags: [quality-gate, api-testing, dev-practices, efficiency, style, architecture, performance, security, maintainability, tool-improvement, cleanup]
+            capability_tags: [quality-gate, api-testing, test-design, dev-practices, efficiency, style, architecture, performance, security, maintainability, tool-improvement, cleanup]
         transitions:
           on_pass: done
           on_fail: implement
@@ -65,6 +66,7 @@ phases:
           - "审查锚点按视图「审查范围」：PR 区间形态为 base..head 区间（首轮）或检查点增量（修复轮）；全量形态为整个代码库——全量形态下的工具违规无论是否本轮引入一律映射为 issue，不得以不在变更清单为由丢弃"
           - "「有变更」分支先审查上方「本次变更证据」区块的变更文件清单与区间 diff 内容后自行判断：若确认本次变更仅为注释/文档性且无逻辑影响，可自行决定跳过全量工具检查直接提交 passed（validation_steps 以 step=no_change 申报整体豁免必做清单）；无法确认或含逻辑/结构变更，必须顺序运行全部确定性工具检查；裁量仅免除全量工具扫描，不免除复核/裁定——本层 blocking issue 仍须处理至终态后提交"
           - "回归验证（独立审查场景，无 spec 验收标准——以既有测试与行为基线为锚）：①构建通过；②既有测试全量执行不引入新失败——首轮跑出的存量失败按 issue 上报进入处置通道（审并修模式进修复闭环或豁免，只审模式进报告），修复轮出现「上轮未登记的新失败」即回归、verdict=failed 并报 issue（说明失败用例与归因）；③可启动服务时按已加载技术栈 skill 的隔离启动规范隔离启动做冒烟与既有 API 测试脚本执行（存在时），验证后按已加载的清理规范幂等清理（含 verdict=failed 轮次）；无法启动服务或无脚本时 ③ 置 completed=false 并以结构化 skip_reason 申报"
+          - "核验测试设计物（独立审查无 spec：行为面从变更 diff 与既有实现推导）：核验既有与新增测试的行为面清单、用例矩阵与反向探针记录（检查点按已加载测试设计规范与任务维度判例执行）；证据缺失或不足时据实上报，不得跳过核验直接提交通过；无测试对象（无代码、接口契约与数据口径变更）时以 completed=false + 结构化 skip_reason 申报"
           - "加载匹配维度 skill 做五维度合并审查（style/architecture/performance/security/maintainability），结合领域知识做拓展审查（skill 仅为最低基准）；顺带发现的其他缺陷按对应维度严重级别标准报 issue，禁止静默丢弃"
           - "审查新 issue 前先查看视图「待复核」区块中的既有 issue（仅本审查者报源），避免语义重复"
           - "报 issue 时必须显式声明归因维度 dimension（style/architecture/performance/security/maintainability）：本 reviewer 不归属任一质量维度，dimension 即该 issue 归属的目标质量维度"

package/assets/workflows/review.yaml

@@ -33,7 +33,7 @@ phases:
       - id: implement
         agents:
           - id: openspec-developer
-            capability_tags: [efficiency, api-testing, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
+            capability_tags: [efficiency, api-testing, test-design, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
         transitions:
           on_pass: verify_tool
           on_fail: implement
@@ -42,6 +42,7 @@ phases:
           - "执行边界缺省整个 worktree（独立审查无分析环节，不生成边界白名单）；issue 的 file 字段指向的文件即修复边界，修复这些文件（含回归引入问题）不算越界；可按 issue 的 suggestion 直接执行修复；reviewer 的 boundary_expansion 已并入边界"
           - "对修复未过次数≥2 的 issue 须先完成 5-Why 根因分析再动手，不得跳过分析直接改代码"
           - "修复完成后先 git commit 再提交；提交前按已加载的质量门类 skill 完成本地构建验证，并按维度规范类 skill（style/architecture/performance/security/maintainability 能力类别）对本次修复文件逐项自检，自检结论与工具检查结果一并汇总进 self_check_results"
+          - "有代码、接口契约或数据口径变更时，须按已加载的测试设计规范产出行为面清单、用例矩阵与反向探针记录，随提交在 self_check_results 中逐项申报；反向探针结束后必须先还原实现并复跑全量用例确认全绿再提交，禁止带着改坏的实现提交"
           - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；验证完成后停止本次启动的实例，不留残留，残留判定遵循已加载清理规范的归属判别，无法确认归属本变更的进程一律不清；禁止为腾出端口或资源而停止、复用或干扰非本会话启动的进程"
           - "确定性质量工具检查出的问题不得以压制手段（压制注解/注释抑制/规则排除配置/平台状态标注/构建跳过开关等）静默规避：确需压制时，必须在压制处代码注释说明清楚理由，并经 exempt_issue_ids 申请豁免由报源 reviewer 裁定；不得以 fixed_issue_ids 冒充修复"
           - "提交 opx_agent_submit：必传 verdict；修复完成的 issue 经 fixed_issue_ids 上报、不可修 issue 经 exempt_issue_ids 申请豁免"
@@ -79,12 +80,13 @@ phases:
       - id: verify_task
         agents:
           - id: openspec-reviewer-task
-            capability_tags: [api-testing, efficiency, dev-practices, cleanup]
+            capability_tags: [api-testing, test-design, efficiency, dev-practices, cleanup]
         transitions:
           on_pass: verify_quality
           on_fail: implement
         instructions:
           - "回归验证层（独立审查场景，无 spec 验收标准——以既有测试与行为基线为锚）逐项验证：①构建通过；②既有测试全量执行不引入新失败——首轮跑出的存量失败按 issue 上报进入处置通道（审并修模式进修复闭环或豁免，只审模式进报告），修复轮出现「上轮未登记的新失败」即回归、verdict=failed 并报 issue（说明失败用例与归因）；③可启动服务时按已加载技术栈 skill 的隔离启动规范隔离启动做冒烟与既有 API 测试脚本执行（存在时），验证后幂等清理"
+          - "核验测试设计物（独立审查无 spec：行为面从变更 diff 与既有实现推导）：核验既有与新增测试的行为面清单、用例矩阵与反向探针记录（检查点按已加载测试设计规范与任务维度判例执行）；证据缺失或不足时据实上报，不得跳过核验直接提交通过；无测试对象（无代码、接口契约与数据口径变更）时以 completed=false + 结构化 skip_reason 申报"
           - "验证完成后（含 verdict=failed 轮次）按已加载的清理规范执行幂等清理：停止残留的服务实例、清理本会话的隔离环境、删除残留的隔离扫描项目；无残留即通过，清理结果纳入 validation_steps 申报"
           - "无法启动服务或不存在 API 测试脚本时，③置 completed=false 并以结构化 skip_reason 申报（格式：{\"item\":\"<对应验证项>\",\"category\":\"<降级类别>\",\"adjudication\":\"user_response|unattended_auto|env_unavailable\",\"note\":\"<说明>\"}），注明判定依据"
           - "报 issue 时必须显式声明归因维度 dimension（style/architecture/performance/security/maintainability）：本 reviewer 不归属任一质量维度，dimension 即该 issue 归属的目标质量维度"

package/assets/workflows/task-simple.yaml

@@ -23,7 +23,7 @@ phases:
       - id: implement
         agents:
           - id: openspec-developer
-            capability_tags: [efficiency, api-testing, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
+            capability_tags: [efficiency, api-testing, test-design, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
         transitions:
           on_pass: quality_review
           on_fail: implement
@@ -32,6 +32,7 @@ phases:
           - "按 Task 项顺序逐个实现，聚焦当前子任务，不超出执行边界"
           - "实施前识别 spec 描述的一并操作行为组（如状态变更与数据入队这类需同时发生的多个行为）；实施后逐项自证每个行为真实生效，禁止以单一状态字段的实现替代其他行为"
           - "涉及数据模型或流程产出变更（含字段/实体承载位置搬迁、AI 生成等流程产物）时，自证须包含关键数据产出断言：产出字段已持久化到 spec 指定承载位置且值完整非空、搬迁承接与同一输入产出基线一致（按已加载接口测试规范执行）；禁止仅以流程跑通/接口成功替代"
+          - "有代码、接口契约或数据口径变更时，须按已加载的测试设计规范产出行为面清单、用例矩阵与反向探针记录，随提交在 self_check_results 中逐项申报；反向探针结束后必须先还原实现并复跑全量用例确认全绿再提交，禁止带着改坏的实现提交"
           - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；隔离对象不限于数据库——为本变更启动的 mock 服务、消息队列/缓存等中间件、扫描分析平台等一切环境资源均须按隔离标识隔离，禁止复用既有实例或共享端口；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动；残留判定遵循已加载清理规范的归属判别，无法确认归属本变更的进程一律不清"
           - "涉及接口契约或数据口径变更（按已加载的接口测试规范判定）时，实施过程中即时更新/新建与变更接口对应的 `.http` 测试脚本（已有脚本更新为匹配变更后契约，尚无脚本则新建，并同步 SQL 前置数据脚本），按已加载接口测试规范的完整执行顺序（含 SQL 前置数据准备、隔离启动基础设施与服务、执行 `.http` 脚本）执行接口测试，确保变更内容真实有效；执行结果（附执行顺序与覆盖接口清单）经 test_results 参数提交，作为审查者分级复验的事实输入；修复被驳回 issue 后再次提交前同样须执行"
           - "自证完成后停止本次启动的服务/基础设施实例，不留残留"
@@ -64,7 +65,7 @@ phases:
       - id: quality_review
         agents:
           - id: openspec-reviewer
-            capability_tags: [quality-gate, api-testing, dev-practices, efficiency, style, architecture, performance, security, maintainability, tool-improvement, cleanup]
+            capability_tags: [quality-gate, api-testing, test-design, dev-practices, efficiency, style, architecture, performance, security, maintainability, tool-improvement, cleanup]
         transitions:
           on_pass: done
           on_fail: implement
@@ -73,6 +74,7 @@ phases:
           - "「有变更」分支先审查上方「本次变更证据」区块的变更文件清单与区间 diff 内容后自行判断：若确认本次变更仅为注释/文档性且无逻辑影响（非注释掉代码、非结构性/格式化变更、非文件重命名），可自行决定跳过全量工具检查直接提交 passed（validation_steps 以 step=no_change 申报整体豁免必做清单）；无法确认或含逻辑/结构变更，必须按分级复验口径执行确定性检查；裁量仅免除全量工具扫描，不免除复核/裁定——本层 blocking issue 仍须处理至终态后提交"
           - "分级复验：低成本必做项（分钟级）全量实跑 + 逐项申报（completed=true 附执行结果）；deep_scan 核验上方「开发者自检申报」区块的 dev 申报（证据完整性、命中项与 diff 的合理性）并抽验命中项（如本地复跑单规则静态分析验证命中真实存在），不重扫全量，申报形态为 step 名首段 deep_scan、completed=true、描述注明核验方式与抽验样本；白名单口径：仅高成本必做项（deep_scan）允许核验申报形态，低成本必做项必须实跑后申报；升级回退全量重跑触发条件（统一四处）：dev 申报缺证据或不完整 / 抽验失败 / 发现断言放水类 issue / 本轮为修复轮且修复波及接口契约或数据口径——命中任一即本轮高成本项改为实跑全量"
           - "对抗性判断（独立视角，不重走 dev 路径）：①task 产出完整性 ②③按 spec 验收标准选样的核心链路抽样重放（1-2 条端到端，覆盖创建-检索-变更-删除闭环中 spec 声明的关键行为；服务健康并入抽样重放——能重放即健康）并审查 `.http` 脚本质量（对照 spec 核断言覆盖/放水/Mock 过度——防作弊主力；含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值）④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷 ⑥关键数据产出核验：对照 spec 数据产出要求，核验实现与测试是否覆盖产出数据落位（spec 指定承载位置）、完整非空、搬迁承接与同一输入基线一致，识别『流程正常但数据缺失/落错位置』类缺陷；轮次口径：首轮按上述分级复验与对抗判断全项执行；复核轮（二轮起）聚焦被修复 issue 相关面 + 本轮修复 diff 波及面 + dev 再自检申报（「开发者自检申报」区块），首轮已通过且无波及的维度与低成本工具结论不重审，但低成本工具实跑保留（防修复引入回归）"
+          - "核验测试设计物：对照 spec 与独立推导的行为面，核验 dev 提交的行为面清单、用例矩阵与反向探针记录（检查点按已加载测试设计规范与任务维度判例执行）；证据缺失或不足时据实上报，不得跳过核验直接提交通过；无测试对象（无代码、接口契约与数据口径变更）时以 completed=false + 结构化 skip_reason 申报"
           - "验证完成后（含 verdict=failed 报 issue 回退 implement 的轮次）按已加载的清理规范执行幂等清理：停止残留的服务实例（含抽样重放启动的服务）、清理本 change 的隔离环境、删除残留的隔离扫描项目；无残留即通过，不因重复执行报错；清理结果纳入 validation_steps 申报（未执行须以 completed=false + 结构化 skip_reason 说明）"
           - "本次变更仅含测试代码（判定：视图「变更范围」文件清单全部命中已加载技术栈 skill 定义的测试代码路径，且无生产代码、接口契约、构建与测试配置等非测试文件）时，豁免②③核心链路抽样重放，仅验证①④；豁免时 validation_steps 中②③置 completed=false，并以结构化 skip_reason 申报（格式：{\"item\":\"<对应验证项>\",\"category\":\"<降级类别>\",\"adjudication\":\"user_response|unattended_auto|env_unavailable\",\"note\":\"<说明>\"}），note 注明「本次变更仅含测试代码，豁免抽样重放」及判定依据；⑤⑥的实现核验在纯测试代码变更场景无对象，其断言证据核验并入④测试代码质量"
           - "读取 design.md 的 API 定义（请求/响应结构、数据模型）与 specs/ 下相关 spec.md（需求细节、验收标准与数据产出要求），用于准备测试数据与对照 API 合约、选样核心链路"

package/assets/workflows/task.yaml

@@ -54,7 +54,7 @@ phases:
       - id: implement
         agents:
           - id: openspec-developer
-            capability_tags: [efficiency, api-testing, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
+            capability_tags: [efficiency, api-testing, test-design, quality-gate, dev-practices, db-design, style, architecture, performance, security, maintainability, cleanup]
         transitions:
           on_pass: verify_tool
           on_fail: analyze
@@ -63,6 +63,7 @@ phases:
           - "按 Task 项顺序逐个实现，聚焦当前子任务，不超出执行边界"
           - "实施前识别 spec 描述的一并操作行为组（如状态变更与数据入队这类需同时发生的多个行为）；实施后逐项自证每个行为真实生效，禁止以单一状态字段的实现替代其他行为"
           - "涉及数据模型或流程产出变更（含字段/实体承载位置搬迁、AI 生成等流程产物）时，自证须包含关键数据产出断言：产出字段已持久化到 spec 指定承载位置且值完整非空、搬迁承接与同一输入产出基线一致（按已加载接口测试规范执行）；禁止仅以流程跑通/接口成功替代"
+          - "有代码、接口契约或数据口径变更时，须按已加载的测试设计规范产出行为面清单、用例矩阵与反向探针记录，随提交在 self_check_results 中逐项申报；反向探针结束后必须先还原实现并复跑全量用例确认全绿再提交，禁止带着改坏的实现提交"
           - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；隔离对象不限于数据库——为本变更启动的 mock 服务、消息队列/缓存等中间件、扫描分析平台等一切环境资源均须按隔离标识隔离，禁止复用既有实例或共享端口；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动；残留判定遵循已加载清理规范的归属判别，无法确认归属本变更的进程一律不清"
           - "涉及接口契约或数据口径变更（按已加载的接口测试规范判定）时，实施过程中即时更新/新建与变更接口对应的 `.http` 测试脚本（已有脚本更新为匹配变更后契约，尚无脚本则新建，并同步 SQL 前置数据脚本），按已加载接口测试规范的完整执行顺序（含 SQL 前置数据准备、隔离启动基础设施与服务、执行 `.http` 脚本）执行接口测试，确保变更内容真实有效；执行结果（附执行顺序与覆盖接口清单）经 test_results 参数提交；修复被驳回 issue 后再次提交前同样须执行"
           - "自证完成后停止本次启动的服务/基础设施实例，不留残留"
@@ -123,12 +124,14 @@ phases:
       - id: verify_task
         agents:
           - id: openspec-reviewer-task
-            capability_tags: [api-testing, efficiency, dev-practices, cleanup]
+            capability_tags: [api-testing, test-design, efficiency, dev-practices, cleanup]
         transitions:
           on_pass: verify_quality
           on_fail: implement
         instructions:
           - "逐项验证：①task 产出完整性 ②启动服务并检查健康 ③独立执行全量 API 测试并审查质量（含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值） ④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷 ⑥关键数据产出核验：对照 spec 数据产出要求，核验实现与测试是否覆盖产出数据落位（spec 指定承载位置）、完整非空、搬迁承接与同一输入基线一致，识别『流程正常但数据缺失/落错位置』类缺陷"
+          # 全模式 verify_task 视图不渲染开发者自检申报，故证据源取变更 diff 与 worktree 测试代码；simple 模式该 step 可核验 dev 申报
+          - "核验测试设计物：对照 spec 与独立推导的行为面，核验测试对行为面的覆盖、用例矩阵（正常/边界/异常与断言强度）与反向探针证据（以本次变更 diff 与 worktree 测试代码为准）；无测试对象（无代码、接口契约与数据口径变更）时以 completed=false + 结构化 skip_reason 申报；不得跳过核验直接提交通过"
           - "验证完成后（含 verdict=failed 轮次）按已加载的清理规范执行幂等清理：停止残留的服务实例、清理本 change 的隔离环境、删除残留的隔离扫描项目；无残留即通过，清理结果纳入 validation_steps 申报"
           - "本次变更仅含测试代码（判定：视图「变更范围」文件清单全部命中已加载技术栈 skill 定义的测试代码路径，且无生产代码、接口契约、构建与测试配置等非测试文件）时，豁免②启动服务并检查健康与③独立执行全量 API 测试，仅验证①④；豁免时 validation_steps 中②③置 completed=false，并以结构化 skip_reason 申报（格式：{\"item\":\"<对应验证项>\",\"category\":\"<降级类别>\",\"adjudication\":\"user_response|unattended_auto|env_unavailable\",\"note\":\"<说明>\"}），note 注明「本次变更仅含测试代码，豁免启动服务与 API 测试」及判定依据；⑤⑥的实现核验在纯测试代码变更场景无对象，其断言证据核验并入④测试代码质量"
           - "读取 design.md 的 API 定义（请求/响应结构、数据模型）与 specs/ 下相关 spec.md（需求细节、验收标准与数据产出要求），用于准备测试数据与对照 API 合约"

package/dsh/cordis.patch.yml

@@ -44,7 +44,7 @@
 
           ## 角色（开发者身份）
 
-          你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门与接口测试的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
+          你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门、接口测试与测试设计的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
 
           提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
 
@@ -140,7 +140,7 @@
           |------|-------------|-------------|---------|
           | Critical | 核心 task 产出文件缺失 | 服务无法启动（无论是否本次变更引起） | 测试依赖无隔离环境导致 CI 必然失败 |
           | High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效）；流程执行正常但关键数据产出缺失/未落库/落错位置（区别于『仅打状态标记未实际生效』：本行=流程与响应正常，产出物缺失或落错位） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为；测试仅验证流程跑通/响应成功，未对 spec 要求的关键数据产出（落位/完整性）断言 |
-          | Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
+          | Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试或未提交测试设计物证据（行为面清单/用例矩阵/反向探针记录）；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
           | Low | 产出文件位置不符合约定 | 启动日志格式不统一 | 测试命名不规范但不影响运行 |
           | Info | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -272,7 +272,7 @@
           ## 职责边界（确定性检查与任务验证）
 
           - **确定性工具检查**：工具维度审查者与 simple 合并审查者被允许运行确定性工具检查（代码格式/架构约束/静态分析/单元测试编译/深度扫描），按已加载质量门 skill 的必做清单执行并将输出映射为统一 issue 结构；检查结果纳入审查结论
-          - **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷
+          - **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷；测试设计核验——对照 spec 与独立推导的行为面核验测试设计物（行为面清单、用例矩阵、反向探针记录），识别漏面、漏格、断言放水与探针缺失
           - **维度审查锚点**：以 spec 验收标准、行为组与数据产出要求为主锚做对照审查，skill 检查点清单与 dev 自检申报对照兜底（抽查申报遗漏项）
           - **工具改进**：可工具化的质量 pattern 双报业务 issue 与工具改进 issue（规则草案由审查者提供），实施工作由开发者完成，审查者不直接改动规则/配置文件以外的实现
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@ifrankwang/openspec-agents",
-  "version": "0.148.0",
-  "description": "OpenSpec change orchestration plugin for AI coding agents (Claude Code, Codex, ZCode, DeepSeek Harness, OpenCode)",
+  "version": "0.149.1",
+  "description": "OpenSpec companion plugin for AI coding agents (Claude Code, Codex, ZCode, DeepSeek Harness, OpenCode): a stricter proposal standard plus multi-agent implementation and review, gated to production-grade standards",
   "author": "ifrankwang",
   "license": "MIT",
   "homepage": "https://github.com/ifrankwang/openspec-agents#readme",

package/src/adapters/codex/index.ts

@@ -118,12 +118,12 @@ export function buildCodexPlugin(outDir: string = CODEX_PLUGIN_DIR): PluginPacka
         mcpServers: "./.mcp.json",
         interface: {
           displayName: "OpenSpec Agents",
-          shortDescription: "OpenSpec change orchestration for Codex",
+          shortDescription: "Production-grade OpenSpec proposals, implementation and review for Codex",
           longDescription: PLUGIN_DESCRIPTION,
           developerName: "ifrankwang",
           category: "Developer Tools",
           capabilities: ["Read", "Write"],
-          defaultPrompt: ["Run the OpenSpec change orchestration workflow."],
+          defaultPrompt: ["Run the OpenSpec proposal, implementation and review workflow."],
         },
       },
       null,

package/src/adapters/plugin-common/index.ts

@@ -18,7 +18,7 @@ import { parseAgentMd, resolve, EXCLUDED_AGENTS } from "../agent-md.ts"
 
 export const PLUGIN_NAME = "openspec-agents"
 export const PLUGIN_DESCRIPTION =
-  "OpenSpec change orchestration for AI coding agents: turn OpenSpec change specs into reviewed, high-quality code."
+  "OpenSpec companion plugin for AI coding agents: a stricter proposal standard plus multi-agent implementation and review, gated to production-grade standards."
 /** plugin.json author（各插件包统一署名项目作者）。 */
 export const PLUGIN_AUTHOR = "ifrankwang"
 

package/src/core/tools/gate.ts

@@ -1,9 +1,10 @@
 /**
- * 质量门必做清单（must_do）覆盖度门禁与降级理由（skip_reason）结构化解析。
+ * skill 必做清单（must_do）覆盖度门禁与降级理由（skip_reason）结构化解析。
  *
  * 语义：skill 在 frontmatter 声明机器可读的 must_do 必做清单后，review 提交（verify_tool）的
  * validation_steps 必须逐项覆盖（completed=true，或 completed=false 且 skip_reason 为合法结构化
- * JSON）。未声明 must_do 的 skill 与解析不到质量门 skill 的 step 优雅跳过（不误伤非质量门 step）。
+ * JSON）。门禁按各 skill 声明的 must_do 通用生效，不限质量门类；未声明 must_do 的 skill 与解析不到
+ * 声明 must_do 的 skill 的 step 优雅跳过（不误伤无必做清单的 step）。
  * giveup 决策复用同一套未覆盖项推导，要求对未覆盖必做项补充结构化降级理由（checkpoint_skip_reasons），
  * 杜绝「放弃审查 → 直接推进收尾」的无痕绕过通道。
  *
@@ -45,7 +46,7 @@ export interface SkipReasonData {
 
 /**
  * 测试注入：覆盖门禁使用的 skill 索引。
- * 存量测试基建（tests/helpers.ts setupWorkspace）默认注入空索引以豁免门禁（解析不到质量门 skill），
+ * 存量测试基建（tests/helpers.ts setupWorkspace）默认注入空索引以豁免门禁（解析不到声明 must_do 的 skill），
  * 新增门禁用例显式注入构造索引或真实索引（scanSkillTags()）验证。null=无注入，走真实文件扫描。
  */
 let overrideIndex: SkillTagIndex | null = null

package/src/core/tools/schemas.ts

@@ -134,7 +134,7 @@ export const checkpointSkipReasonItem: JSONSchema = {
   type: "object",
   description: "giveup 决策的必做项结构化降级理由",
   properties: {
-    item: { type: "string", minLength: 1, description: "对应的必做项（质量门 skill 的 must_do 清单项）" },
+    item: { type: "string", minLength: 1, description: "对应的必做项（已加载 skill 的 must_do 清单项）" },
     category: { type: "string", minLength: 1, description: "降级类别，如环境不可用 / 用户裁定豁免 / 无人值守自动降级" },
     adjudication: {
       type: "string",
@@ -330,7 +330,7 @@ export const agentSubmitSchema: JSONSchema = {
     },
     checkpoint_skip_reasons: {
       type: "array",
-      description: "giveup 决策配套：对当前 step 质量门必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
+      description: "giveup 决策配套：对当前 step 已加载 skill 必做清单未覆盖项的结构化降级理由（未覆盖项缺理由则拒绝 giveup）",
       items: checkpointSkipReasonItem,
     },
     new_children: {

package/src/core/tools/submit.ts

@@ -511,8 +511,9 @@ function handleReviewParams(
   }
 
   // 必做清单覆盖度门禁：verdict=passed 且非补交豁免（仅裁定参数）时，validation_steps 须逐项覆盖
-  // 当前 agent 能力集解析出的质量门 skill 必做清单（must_do）。遗漏必做项且无有效降级证据 → 拒绝提交。
-  // 未声明 must_do 的 skill / 解析不到质量门 skill 的 step 自动跳过（不误伤 verify_task/verify_quality）。
+  // 当前 agent 能力集解析出的已加载 skill 必做清单（must_do）。遗漏必做项且无有效降级证据 → 拒绝提交。
+  // 门禁按各 skill 声明的 must_do 通用生效，不限质量门类；未声明 must_do 的 skill / 解析不到声明
+  // must_do 的 skill 的 step 自动跳过（不误伤无必做清单的 step）。
   // 覆盖口径：核验申报（completed=true + 描述注明核验方式与抽验样本，step 名首段 token 命中必做项）是
   // 高成本必做项的合法覆盖形态，仅限 workflow 指令白名单限定的高成本必做项（deep_scan）；低成本必做项
   // 必须实跑后申报（机制层只认 token 命中不区分形态，白名单口径在错误提示中明示）。
@@ -520,8 +521,8 @@ function handleReviewParams(
     const uncovered = uncoveredMustDo(opts.capabilityTags, params.validation_steps)
     if (uncovered.length > 0) {
       throw new Error(
-        `提交的验证步骤未覆盖质量门 skill 必做清单，缺少以下必做项：${uncovered.join("、")}。\n` +
-        `请按已加载质量门类 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` +
+        `提交的验证步骤未覆盖已加载 skill 的必做清单，缺少以下必做项：${uncovered.join("、")}。\n` +
+        `请按已加载 skill 的必做清单逐项执行并逐项申报结果（completed=true）；` +
         `确实无法执行的必做项须以结构化 skip_reason 申报降级理由` +
         `（格式：${SKIP_REASON_FORMAT}）。` +
         `低成本必做项必须实跑后申报；核验申报仅限 workflow 指令白名单限定的高成本必做项。`
@@ -791,8 +792,9 @@ export async function agentSubmitExecute(params: AgentSubmitParams, ctx: ToolCon
     const newChildren = (params.new_children ?? []).map((nc) => buildIssueChild(nc, ctx.agent))
 
     if (stepPhase === "review") {
-      // 必做清单覆盖度门禁取「当前提交 agent 的能力集」：verify_quality 多 agent 各自 capability 解析
-      // 不出质量门 skill（自动跳过），verify_tool 的 reviewer 按 quality-gate 能力集校验。
+      // 必做清单覆盖度门禁取「当前提交 agent 的能力集」：各 agent 只按自身 capability_tags 解析 skill。
+      // verify_quality 多 agent 各自解析不出声明 must_do 的 skill（自动跳过），verify_tool 按 quality-gate
+      // 能力集、verify_task 按 test-design 能力集分别校验各自的必做清单。
       const stepCfg = workflow.stepMap.get(params.step_id)!.step
       const agentCfg = stepCfg.agents.find((a) => a.id === ctx.agent)
       handleReviewParams(item, params, newChildren, params.step_id, {
@@ -957,10 +959,10 @@ async function applyCheckpointDecision(
   if (decision === "continue") {
     applyCheckpointContinue(item, step)
   } else {
-    // giveup 必做清单核对（堵 giveup 侧门）：当前 step 若含质量门 skill 必做清单（must_do），
+    // giveup 必做清单核对（堵 giveup 侧门）：当前 step 若解析出已加载 skill 必做清单（must_do），
     // 未覆盖项必须有结构化降级理由（checkpoint_skip_reasons），否则拒绝 giveup——
-    // 杜绝「放弃审查 → 自动推进 → 收尾合码」的无痕绕过通道。非质量门 step 或未声明 must_do
-    // 的 skill 环境下 uncovered 为空，giveup 行为不受影响（与「编排改动须评估全流程连锁影响」一致）。
+    // 杜绝「放弃审查 → 自动推进 → 收尾合码」的无痕绕过通道。未声明 must_do 的 skill 环境下
+    // uncovered 为空，giveup 行为不受影响（与「编排改动须评估全流程连锁影响」一致）。
     const stepCaps = Array.from(new Set(step.agents.flatMap((a) => a.capability_tags)))
     const prevSteps = (item.metadata["validation_steps"] as Array<{ step: string; completed: boolean }> | undefined)
     const uncovered = uncoveredMustDo(stepCaps, prevSteps)
@@ -972,7 +974,7 @@ async function applyCheckpointDecision(
       const missing = uncovered.filter((m) => !provided.has(m))
       if (missing.length > 0) {
         throw new Error(
-          `giveup 无法应用：当前 step 的质量门必做清单存在未覆盖项，须逐项提供结构化降级理由。\n` +
+          `giveup 无法应用：当前 step 的已加载 skill 必做清单存在未覆盖项，须逐项提供结构化降级理由。\n` +
           `缺少降级理由的必做项：${missing.join("、")}\n` +
           `请通过 checkpoint_skip_reasons 逐项提供（giveup 未覆盖项不可跳过申报）：\n` +
           `[${SKIP_REASON_FORMAT}]`

package/src/core/tools/types.ts

@@ -77,7 +77,7 @@ export interface AgentSubmitParams {
     reject_reason?: string
   }>
   checkpoint_decision?: "continue" | "giveup"
-  /** giveup 决策配套：对当前 step 质量门必做清单（must_do）未覆盖项逐项提供的结构化降级理由
+  /** giveup 决策配套：对当前 step 已加载 skill 必做清单（must_do）未覆盖项逐项提供的结构化降级理由
    * （giveup 未覆盖项缺理由则拒绝 giveup）。adjudication 取值 user_response / unattended_auto / env_unavailable。 */
   checkpoint_skip_reasons?: Array<{
     item: string

package/src/core/workflow/status.ts

@@ -131,13 +131,13 @@ function renderCheckpoint(rec: EngineRecommendation, workflow: LoadedWorkflow, i
     `唯一动作：调用 \`opx_agent_submit({ step_id: "${step}", checkpoint_decision: "continue" })\`（continue / giveup 二选一）推进。`,
     "",
   ]
-  // 质量门类 step（当前 step 能力集解析出质量门必做清单）giveup 时，未覆盖必做项须经
+  // 解析出必做清单的 step（各 skill 声明 must_do 即生效，不限质量门类）giveup 时，未覆盖必做项须经
   // checkpoint_skip_reasons 逐项申报结构化降级理由（操作指引层面，不解释门禁内部实现）。
   const entry = rec.stepId ? workflow.stepMap.get(rec.stepId) : undefined
   const stepCaps = Array.from(new Set((entry?.step.agents ?? []).flatMap((a) => a.capability_tags)))
   if (resolveMustDoForCaps(stepCaps).length > 0) {
     lines.push(
-      `质量门类 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`,
+      `含必做清单的 step 的 giveup 决策：未覆盖必做项须经 \`checkpoint_skip_reasons\` 逐项申报结构化降级理由（格式：\`${SKIP_REASON_FORMAT}\`），缺理由 giveup 不会被受理。`,
       "",
     )
   }