@ifrankwang/openspec-agents 0.147.2 → 0.149.0

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

@@ -8282,7 +8282,7 @@ ${content.join(`
 var version = {
   major: 4,
   minor: 6,
-  patch: 6
+  patch: 7
 };
 
 // node_modules/zod/v4/core/schemas.js
@@ -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.147.2";
+var PKG_VERSION = "0.149.0";
 function buildMcpServer(worktree, opts = {}) {
   const mcp = new McpServer({ name: "openspec-agents", version: PKG_VERSION });
   for (const [name, spec] of Object.entries(TOOL_SPECS)) {
@@ -31567,7 +31567,7 @@ var makeCloseHandler = (req, incoming, outgoing, needsBodyCleanup) => () => {
   if (incoming.errored) {
     recordBodyBufferedBeforeDisconnect(incoming);
     req[abortRequest](incoming.errored.toString());
-  } else if (!outgoing.writableFinished) {
+  } else if (!outgoing.writableFinished || incoming instanceof Http2ServerRequest && incoming.aborted) {
     recordBodyBufferedBeforeDisconnect(incoming);
     req[abortRequest]("Client connection prematurely closed.");
   }

package/README.md

@@ -128,14 +128,14 @@ openspec/states/
 
 ## 内置的规范库
 
-插件自带 22 份 skill（含两个流程入口），装了就有，不用自己写提示词；审查的 AI 会按当前任务需要自动挂上对应的一组。
+插件自带 23 份 skill（含两个流程入口），装了就有，不用自己写提示词；审查的 AI 会按当前任务需要自动挂上对应的一组。
 
 **两个入口**
 
 - `orchestrator` —— 编排准则，主代理按它分派子代理、推进流程。
 - `openspec-standard` —— 提案标准初始化。
 
-**9 份通用规范**：DDD 分层与六边形、REST 接口约定、数据库设计约定、安全审查基线、确定性质量门、技术债识别、架构演进审查、API 自动化测试、隔离环境清理。
+**10 份通用规范**：DDD 分层与六边形、REST 接口约定、数据库设计约定、安全审查基线、确定性质量门、测试设计、技术债识别、架构演进审查、API 自动化测试、隔离环境清理。
 
 **11 份 Java 后端配套**：在通用规范之上补齐 Java / Spring 的实现细节 —— Lombok、日志与命名约定、REST 接口的 Java 实现、MyBatisPlus 与 Flyway、DDD 的 Java 实现与 ArchUnit 规则、Maven / Spotless / PMD / SonarQube 质量门、工具规则改进、Java 开发实践、Java 安全实现、Java 性能与可维护性、Java 技术债形态。
 
@@ -151,6 +151,7 @@ OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，
 | 需求澄清 | 澄清不强制，靠 explore 用法自行把握 | 决策树逐轮提问，每题附推荐答案；事实类疑问自己查代码，不抛给你 |
 | 动笔门禁 | 无 | 疑点问完 + 你确认方案，才允许开始写文档；确认必须文字回复，点选项不算 |
 | 改动范围 | proposal 里一句 Impact 描述 | 关联场景清点：把用到这块逻辑的入口、复用链路、数据上下游全列出来，每条附代码位置，逐条跟你确认纳入还是排除；共用逻辑的所有入口必须同一变更里一起改 |
+| 规则边界推演 | 无 | 新增或改动规则、校验、拦截逻辑时，先推演这条规则本身站不站得住：该拦的条件与例外、功能上合法却会被误伤的合法反例（各对应 spec 一条「应当放行」场景）、同一业务意图的等价执行路径与判定挂载点（挂在业务意图层的动作上，不落在被别的流程复用的底层动作上）；变更新增或改了执行路径时，逐条核对既有规则在新路径上是否仍该生效 |
 | 契约变更 | 无专门要求 | 逐条列：建表到列（名/类型/可空/默认值/用途）、接口到字段与方法路径、兼容性影响 |
 | 文档语言 | 要求 spec 避免类名、函数名 | 方案摘要与实施逻辑也必须用人话，禁止类名、方法名这类代码黑话（契约事实与技术设计文档除外） |
 | 任务划分 | 分组 + 每条带验证方式 | 追加：每组必须有真实代码改动（禁止「收尾组」凑数）、测试跟着实现同组、只覆盖本仓库 |

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 | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -81,7 +81,10 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 |------|--------------|--------------------------|
 | Critical | 核心层依赖框架导致循环依赖或编译失败 | design 中的 schema 与实现冲突导致无法建表/编译；tasks 缺失核心步骤导致实施方向错误；实施所需关键信息缺失（如模板路径、字段映射未明），导致无法开始实施；设计架构方案违反 architecture skill 的 MUST 规则 |
 | High | 表示层直接绕过领域层访问基础设施 | spec 需求在 tasks 中无对应任务；基础架构任务错排位置；实施所需信息不完整，部分任务需等待补充信息才能推进；设计方案偏离 architecture skill 推荐做法，存在可通过调整规避的风险；设计方案破坏既有接口/数据/行为契约且无兼容或过渡安排；重构方案改变既有行为语义且未显式声明 |
+| High | 已实现的校验/拦截把功能上合法的场景拦住，或判定挂在被其它业务流程复用的底层动作上致其误触，且无兼容或过渡安排 | 方案新增/修改的规则会误伤功能上合法的场景，或判定挂载点会被复用该动作的其它流程误触，且方案未说明 |
+| High | 本次变更新增或重排的执行路径绕过了既有校验/拦截（该拦未拦），且无兼容或过渡安排 | 方案新增或重排的执行路径会使既有规则/校验/拦截失效（该拦未拦），且方案未说明如何在新路径上保持该判定 |
 | Medium | 依赖注入方式不符合约定（如字段注入）；数据对象可变导致并发风险；应基础设施化的共性能力被分散实现（多处重复、横向共性需求、新增场景易遗漏调用）；引入与既有实现功能重叠的平行实现（另起一套逻辑），同类能力多套方案并存且无迁移方案；引入或延续可识别技术债且无偿还规划（如采用 EOL/弃用技术选型、临时方案长期固化、接口契约不一致）；重构/变更破坏既有契约（接口/数据/行为）或改变既有行为语义且无兼容说明 | tasks 范围模糊；design 技术细节与 tasks 完成标准不一致 |
+| Medium | 已实现的校验/拦截落在被其它业务流程复用的底层动作上，或未覆盖 design.md 列出的例外与等价执行路径，无法确认是否会误伤 | 方案未给出规则边界结论（该拦条件、该放的例外与合法反例、等价执行路径与判定挂载点），无法判断是否会误伤 |
 | Low | 数据对象缺少不可变修饰但当前无并发场景；已有代码中违反分层原则但影响极小的结构性缺陷 | 文档引用路径有冗余前缀；描述用词与 spec 不一致但不影响理解 |
 | Info | 建议拆分为独立服务；建议引入某设计模式（仅当不属于 Low 及以上时） | 建议补充某边缘场景说明；可 `（待补充）` 占位、不阻塞开工的边缘信息缺失 |
 
@@ -145,7 +148,7 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
 - 方案复用与平行实现：识别引入与既有实现功能重叠的平行实现（另起一套逻辑）的情况——同类能力已有既有实现时须优先复用或扩展，另建实现且不改动原实现、无迁移方案则报 issue；方案确需平行引入（新旧并存）时按需用户拍板问题的确认机制确认并存期与技术债，无人值守缺省裁决为方案必须包含原技术实现的迁移方案。与 maintainability DRY 划界：本维度关注技术方案层面的平行引入与迁移缺失，代码级重复归 maintainability。具体复用与迁移要求按 skill 约定
 - 技术债识别：按 skill 中的技术债识别约定——识别存量与新增技术债（过时技术选型、迁移中断残留、平行实现、临时方案固化、契约不一致），按统一严重级别报 issue；方案引入的债务须在方案中规划偿还或说明可接受理由
-- 架构演进审查：按 skill 中的架构演进审查约定——方案/实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义；实施侧破坏兼容或改变既有语义按统一严重级别报 issue，方案侧破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
+- 架构演进审查：按 skill 中的架构演进审查约定——方案/实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义；实施侧破坏兼容或改变既有语义按统一严重级别报 issue，方案侧破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；变更涉及新增/修改业务规则、校验或拦截，或新增/改变任何执行路径时，核对规则边界推演——该拦条件与例外、功能上合法的反例（是否存在不该拦而拦）、既有规则在新执行路径上是否仍成立（是否存在该拦未拦）、同一业务意图的等价执行路径及其判定挂载点（判定须挂在业务意图层的动作上，不得落在被其它业务流程复用的底层动作上）；推演缺失或不完整按统一严重级别报 issue
 
 ### 可维护性维度
 
@@ -194,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/architecture-evolution/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: architecture-evolution
-description: 架构演进审查（架构维度）——方案/变更与项目整体架构脉络的契合度、长期迭代演进支持、拓展性与兼容性、重构对历史逻辑与既有行为语义的贴合。技术栈无关。
+description: 架构演进审查（架构维度）——方案/变更与项目整体架构脉络的契合度、长期迭代演进支持、拓展性与兼容性（新增/修改的规则、校验或拦截误伤功能上合法的既有操作、既有规则在新执行路径上是否仍成立、判定挂载点是否落在被其它业务流程复用的底层动作上）、重构对历史逻辑与既有行为语义的贴合。技术栈无关。
 capabilities: ["architecture"]
 ---
 
@@ -45,10 +45,10 @@ capabilities: ["architecture"]
 
 变更是否破坏既有契约——接口签名、数据格式、行为语义；破坏时是否有兼容或过渡安排；应预留拓展点而未预留。
 
-- 识别信号：修改既有接口签名/响应结构/字段语义且调用方未同步；存量数据/历史行为不兼容；破坏性变更无过渡方案
-- 判据：破坏既有契约且无兼容/过渡安排
-- 处置：破坏既有契约且无兼容/过渡安排 → 至少 Medium 级别 issue
-- 划界：跨接口/模块同一语义表达不一致（枚举 vs 数字码）归契约不一致职责；本类关注变更对既有契约的破坏与兼容安排
+- 识别信号：修改既有接口签名/响应结构/字段语义且调用方未同步；存量数据/历史行为不兼容；破坏性变更无过渡方案；本次新增/变更的规则、校验或拦截把功能上合法的既有操作一并拦住（不该拦而拦）；既有规则、校验或拦截在被本次变更新增或重排的执行路径上失效（该拦未拦）；判定挂在被其它业务流程复用的底层动作上，致那些流程被误触
+- 判据：破坏既有契约且无兼容/过渡安排；既有规则、校验或拦截在本次新增/重排的执行路径上失效（该拦未拦），或本次新增/变更的规则把功能上合法的既有操作一并拦住（不该拦而拦）；或未给出规则边界推演结论（未列出该放行的例外与合法反例、同一业务意图的其它执行路径、判定挂载点）致结论无法核验
+- 处置：破坏既有契约且无兼容/过渡安排 → 至少 Medium 级别 issue；规则误伤功能上合法的场景、或判定挂在被其它业务流程复用的底层动作上致其误触 → 至少 Medium 级别 issue；规则边界推演缺失或无法核验 → 至少 Medium 级别 issue；既有规则在新增/重排的执行路径上失效（该拦未拦）致行为语义变更 → 至少 Medium 级别 issue（无兼容或过渡安排时按架构维度判例表 High 级口径）
+- 划界：跨接口/模块同一语义表达不一致（枚举 vs 数字码）归契约不一致职责；本类关注变更对既有契约的破坏与兼容安排，以及规则在既有合法路径上是否仍成立、判定挂在哪一层；规则类问题的判据措辞用「不该拦而拦 / 该拦未拦」，不按契约破坏口径表述
 
 ### 4. 重构贴合历史逻辑
 

package/assets/skills/openspec-standard/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: openspec-standard
-description: OpenSpec 提案标准初始化与升级——把标准版提案规则（openspec/config.yaml + spec-driven-standard schema 全套）安装到当前项目，统一后续提 change 的质量门槛（关联场景清点、契约变更详列、人话变更清单与实施逻辑、结构化方案摘要、动笔前访谈与用户确认）。当用户要求初始化、升级或标准化 openspec 提案标准/提案规范时使用。
+description: OpenSpec 提案标准初始化与升级——把标准版提案规则（openspec/config.yaml + spec-driven-standard schema 全套）安装到当前项目，统一后续提 change 的质量门槛（关联场景清点、规则边界推演、契约变更详列、人话变更清单与实施逻辑、结构化方案摘要、动笔前访谈与用户确认）。当用户要求初始化、升级或标准化 openspec 提案标准/提案规范时使用。
 capabilities: ["openspec-standard"]
 ---
 
 ## 职责
 
-把本 skill 目录 `templates/` 下的标准文件安装到当前项目的 `openspec/` 目录，使该项目此后用 openspec 提 change 时自动遵循统一标准：关联场景清点（共享处理逻辑的变更须与其全部消费入口同一 change 统一适配，同一数据多条落库路径的校验一致性为访谈必问分支）、契约变更详列、实施逻辑人话分步（proposal 单列实施逻辑小节，禁代码级名词）、结构化方案摘要（访谈穷尽后才给出，一句话做什么、变更内容人话逐条列明并禁代码级名词，以普通消息确认）、动笔前访谈门与用户确认门、任务组实质变更主体、测试随实现同组（禁为测试单开任务组）、单仓变更范围（分仓的前后端默认互不纳入，除非用户明确要求）等。幂等：重跑即把标准升级到插件当前版本，项目自定义内容按下方合并策略保留。
+把本 skill 目录 `templates/` 下的标准文件安装到当前项目的 `openspec/` 目录，使该项目此后用 openspec 提 change 时自动遵循统一标准：关联场景清点（共享处理逻辑的变更须与其全部消费入口同一 change 统一适配，同一数据多条落库路径的校验一致性为访谈必问分支）、规则边界推演（新增/修改规则须推演该拦条件、该放的合法例外与反例、同一业务意图的等价执行路径与判定挂载点）、契约变更详列、实施逻辑人话分步（proposal 单列实施逻辑小节，禁代码级名词）、结构化方案摘要（访谈穷尽后才给出，一句话做什么、变更内容人话逐条列明并禁代码级名词，以普通消息确认）、动笔前访谈门与用户确认门、任务组实质变更主体、测试随实现同组（禁为测试单开任务组）、单仓变更范围（分仓的前后端默认互不纳入，除非用户明确要求）等。幂等：重跑即把标准升级到插件当前版本，项目自定义内容按下方合并策略保留。
 
 ## 前置检查
 

package/assets/skills/openspec-standard/templates/openspec/config.yaml

@@ -1,10 +1,9 @@
 schema: spec-driven-standard
 
 context: |
-  项目技术背景、架构约定与工程规范以项目根目录 AGENTS.md 为准。
-  本文件仅承载 OpenSpec 流程的通用规则；与项目相关的特化约束
-  （技术栈、分层架构、数据库约定、质量门、方法论选择等）一律写入
-  项目 AGENTS.md，生成与复核子代理会被指示读取它。
+  项目特化约束以项目根目录 AGENTS.md 为索引入口（技术栈、目录结构、项目阶段、
+  跨模块复用约定与关键坑位），规则细则以 openspec/specs/ 下的主 spec 为权威锚，
+  操作流程与方法在项目级 skill（.agents/skills/）；生成与复核子代理会被指示读取它。
   explore 模式与 proposal 侧同源同严：凡涉及理清需求，必须按
   spec-driven-standard schema clarify 指令的决策树访谈方法论逐轮穷尽
   疑点；疑点未穷尽不得收束结论、不得捕获任何变更工件
@@ -18,10 +17,14 @@ rules:
     - "实施逻辑与方案摘要结构（强制）：proposal.md 必须单列「实施逻辑（Implementation Outline）」小节，按步骤用业务语言（人话）讲清具体怎么做——数据从哪来、经过什么校验与处理、落到哪、关联场景小节划入的每条链路怎么适配；禁止出现类名/方法名/内部函数名等代码级名词（用户明确要求技术深度时除外；契约变更点小节的表名/列名/端点路径等契约事实不受此限、保持精确）。方案摘要必须按 spec-driven-standard schema clarify 指令 Plan confirmation gate 的要素清单结构化逐项展开——先用一句话说明本次变更做什么，变更内容再用自然语言（人话）逐条列出，每条形如「导出功能新增「状态」字段」并视需要展开必要背景（如该字段的来源、用途），禁止掺杂类名/方法名等代码级名词（限制口径同实施逻辑小节）；摘要含人话分步实施逻辑与关联链路划界结论，两三句话的摘要视为未完成。"
     - "动笔前用户确认门（强制）：proposal/specs/design/tasks 任一文档动笔前，clarify.md 的 Architecture Direction 必须已记录用户对方案摘要的明确确认；确认必须以普通消息直接列出方案摘要要素点（要素清单见 spec-driven-standard schema clarify 指令的 Plan confirmation gate）并停下等待用户直接文字回复，禁止通过提问工具发起确认，提问工具的选项点击不视为确认；未记录时禁止写任何文档——主代理亲自写时先停下向用户补确认，生成子代理则立即终止并向编排方报告，不得以「需求简单」等理由跳过或代用户确认。"
     - "单仓变更范围（强制）：本 change 的变更点只落在本次会话所在的仓库——在独立的前端仓或后端仓会话中，不得把另一端仓库的改动（如后端仓的 change 纳入前端页面代码、前端仓的 change 纳入后端接口实现）写入 proposal/specs/design/tasks 任一工件。关联场景清点发现另一端仓库存在消费方时，按「排除（属另一仓库，另提 change）」记录并附理由，且不得在本 change 内为其排任务。仅当用户明确要求跨仓时才纳入，并在 proposal.md 单列「拆分边界」小节写明哪部分改动归本仓、哪部分归另一仓库、各自如何实施与验证。前后端同处一个仓库时不存在「另一端仓库」，不适用本约束。"
+    - "规则边界推演（强制）：凡变更新增/修改业务规则、校验或拦截逻辑，或新增/改变任何执行路径，proposal.md 必须单列「规则边界（Rule Boundary）」小节，以表格逐条列出每条规则的该拦条件、该放的例外与合法反例（附应有处理）、判定挂载点，并给出同一业务意图的其它执行路径清单及逐条结论；不涉及规则的变更写「不适用」+ 一句理由。缺该小节或仅以「无特殊情况」泛写而无推演结论视为 proposal 未完成。推演方法以 schema clarify 指令的规则边界分支为权威源，本条目只定门禁口径。"
   specs:
     - "数据行为需求（如\"系统 SHALL 持久化 X 含审计字段\"）放 spec；物理 DDL 放 design.md。"
     - "MODIFIED 的需求描述直接给出变更后的终态契约表述（\"系统 SHALL 使用 Y\"），供归档合并时原样落入主 spec；禁止以\"原 X 改为 Y\"的历史对比充当主 spec 内容。"
     - "同一语义只保留一条需求：修改已有需求用 MODIFIED，不得以新标题重复描述同一能力。"
+    - "规则边界三类场景（强制）：新增/修改业务规则、校验或拦截逻辑，或新增/改变任何执行路径的变更，spec 必须按规则边界结论逐条给出三类 Scenario——应当拦截（含判定成立的最小条件）、应当放行（例外与合法反例）、同一业务意图的其它执行路径应当放行（每条路径一个 Scenario）；不适用的写明理由，只有拦截侧场景视为需求未完成。"
+  design:
+    - "判定挂载点（强制）：新增/修改业务规则、校验或拦截逻辑，或新增/改变任何执行路径的变更，design.md 必须写明判定挂在哪个业务动作/哪一层，以及为何不会被同一业务意图的其它执行路径（含复用该底层动作的其它流程）误触；不涉及规则的变更写明「不适用」+ 一句理由。"
   tasks:
     - "每个任务组必须以实质变更为主体（强制）：组内至少一个任务承载真实的代码/配置行为变更（实现 + 测试）；文档/脚本/部署文档同步、验证、回归、质量门只是随行工作，不构成组的实质内容。任务条数不等于实质——排到末位的剩余工作若只剩同步与验证，必须并入前一个功能组，禁止为其新开组（反例：「阶段二收尾：文档、脚本与全量验证」式收尾组）。"
     - "任务组覆盖关联入口（强制）：tasks.md 的任务组划分必须覆盖 proposal.md「关联场景」小节划入本 change 的全部消费入口；任一划入入口缺少对应适配任务视为 tasks 未完成。"

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/README.md

@@ -2,16 +2,24 @@
 
 通用 spec-driven 工作流模板：clarify → proposal → specs → design → tasks，
 增强三点：
-1. **clarify 前置门槛 + 关联场景清点**：每次变更先做需求澄清与关联场景清点
-   （首轮提问前枚举变更触及能力的全部消费方——功能入口 / 共享处理逻辑 /
-   数据流下游，附代码证据；每个清点条目在访谈中经用户划界确认——纳入本
-   change 统一适配或排除附理由；同一数据存在多条落库路径时各路径校验与
-   处理逻辑的一致性为必问分支；共享处理逻辑变更须与其全部消费入口同一
-   change 统一适配）；访谈穷尽后、写任何文档之前，主代理必须先向用户汇报
-   结构化方案摘要（按要素清单逐项编号展开：一句话做什么 + 变更内容人话
+1. **clarify 前置门槛 + 关联场景清点 + 规则边界推演**：每次变更先做需求澄清
+   与关联场景清点（首轮提问前枚举变更触及能力的全部消费方——功能入口 /
+   共享处理逻辑 / 数据流下游，附代码证据；每个清点条目在访谈中经用户划界
+   确认——纳入本 change 统一适配或排除附理由；同一数据存在多条落库路径时
+   各路径校验与处理逻辑的一致性为必问分支；共享处理逻辑变更须与其全部消费
+   入口同一 change 统一适配）；规则边界推演与清点分工：清点管「谁受影响」，
+   规则边界推演管「判定条件本身站不站得住」——凡新增/修改业务规则、校验或
+   拦截逻辑，或新增/改变任何执行路径的变更，须逐条推演该拦的条件与例外、
+   功能上合法却会被误伤的合法反例（各对应 spec 一条「应当放行」场景）、同一
+   业务意图的等价执行路径与判定挂载点（判定挂在业务意图层的动作上，不得落在
+   被其它业务流程复用的底层动作上），并逐条核对新路径下既有规则是否仍该生效；
+   结论落进 proposal 的「规则边界」小节与 spec 的应当拦截 / 应当放行 / 等价
+   执行路径三类场景，其余变更写「不适用」+ 一句理由；访谈穷尽后、写任何
+   文档之前，主代理必须先向用户汇报结构化方案摘要（按要素清单逐项编号展开：
+   一句话做什么 + 变更内容人话
    逐条列明（形如「导出功能新增「状态」字段」，视需要说明字段来源等
    背景）+ 是否动契约 + 选定方案与备选取舍 + 人话分步实施逻辑 +
-   关联链路划界结论 + 影响的能力面）并取得用户明确确认（HARD-GATE：摘要须以普通消息呈现，禁止用提问
+   关联链路划界结论 + 规则边界推演结论 + 影响的能力面）并取得用户明确确认（HARD-GATE：摘要须以普通消息呈现，禁止用提问
    工具发起确认，访谈中的问答不视为确认；访谈未穷尽禁止呈现方案求确认，
    轮次中每题附的推荐答案不视为方案），确认记录落在 clarify.md，后续文档
    不得偏离。proposal.md 单列「实施逻辑」小节，以人话分步讲清怎么做（禁
@@ -74,8 +82,8 @@ openspec/schemas/<schema-name>/
 
 | 位置 | 承载内容 | 例子 |
 |---|---|---|
-| `schema.yaml` instruction | 生成方法论与文档格式要求（官方方法论为底） | 场景标题 4 个 #、SHALL/MUST、ADDED/MODIFIED/REMOVED、任务组格式、每组自带测试与质量门、测试随实现同组、关联场景清点维度与单仓变更范围、实施逻辑小节 |
-| `openspec/config.yaml` rules | **仅** schema 未覆盖的项目补充规则 | MODIFIED 终态契约表述、同语义一条需求、前置 change 标注格式、契约变更详列、访谈门与用户确认门、实施逻辑与方案摘要结构、单仓变更范围与跨仓拆分边界、测试随实现同组 |
+| `schema.yaml` instruction | 生成方法论与文档格式要求（官方方法论为底） | 场景标题 4 个 #、SHALL/MUST、ADDED/MODIFIED/REMOVED、任务组格式、每组自带测试与质量门、测试随实现同组、关联场景清点维度与单仓变更范围、实施逻辑小节、规则边界推演维度与三问 |
+| `openspec/config.yaml` rules | **仅** schema 未覆盖的项目补充规则 | MODIFIED 终态契约表述、同语义一条需求、前置 change 标注格式、契约变更详列、访谈门与用户确认门、方案摘要结构、跨仓拆分边界、规则边界门禁口径（结论必列、三类场景、判定挂载点） |
 | 项目 `AGENTS.md` | 项目特化约束 | 技术栈、分层架构、数据库约定、质量门工具、方法论 |
 
 同一规则只写一处：通用生成方法论以 schema instruction 为准，config.yaml

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/schema.yaml

@@ -73,6 +73,13 @@ artifacts:
            consistency (clarify direction ↔ proposal capabilities ↔ specs
            requirements ↔ design decisions ↔ tasks with [spec:...]
            traceability tags);
+         - for changes that add or alter a rule, validation or blocking check,
+           or introduce/reorder an execution path, check the rule-boundary
+           findings entry by entry: the proposal's Rule Boundary section, the
+           design's mount point, and the spec's blocked / allowed /
+           equivalent-path scenarios must all match the rule-boundary
+           conclusions recorded in clarify.md - use the clarify record as the
+           baseline and do not invent criteria;
          - read openspec/specs/ main specs (read-only) and cross-check:
            proposal capabilities actually exist there, and delta
            requirements/contracts (e.g. error codes, rate-limit semantics,
@@ -141,6 +148,33 @@ artifacts:
         * Data model: which entities/tables/fields are involved? any new tables or columns?
         * Business rules: which are deterministic vs non-deterministic, per the
           project's conventions (see AGENTS.md)?
+        * Rule boundary (规则边界推演): for every business rule, validation or
+          blocking check this change adds or alters - and for every execution
+          path or action sequence the change introduces or reorders - work out
+          and resolve with the user, as branches of the decision tree:
+          1) judgement condition and exception: which cases must be blocked,
+             and which look similar but must be allowed (state the minimal
+             condition under which the block applies);
+          2) legitimate counter-examples: every functionally legal scenario the
+             new rule would wrongly block, and the handling each one should get
+             (each becomes an "allowed" scenario in the spec);
+          3) equivalent paths and the mount point of the check: whether the same
+             business intent has more than one execution path (several screens,
+             several endpoints, an action composed of other actions - e.g.
+             switching a user's role implemented as remove-then-add), and which
+             action or layer the check is mounted on; the check belongs on the
+             business-intent action, never on a lower-level action that other
+             flows reuse.
+          Also ask whether this change introduces or reorders any execution
+          path; if so, go through every EXISTING rule, validation or blocking
+          check and decide whether it should still fire on the new path
+          (blocked when it should not be, not blocked when it should be).
+          Division of labour: the Related-surface survey enumerates WHO is
+          affected; this branch decides whether the judgement itself holds. The
+          multiple-persistence-path consistency branch keeps the judgement
+          semantics consistent across paths (no missed blocking); this branch's
+          mount point keeps the check off shared low-level actions (no wrongful
+          blocking).
         * Integration boundaries: external systems, APIs, ports/adapters?
         * Architecture direction: propose 2-3 approaches with tradeoffs and a recommendation.
       - Round mechanics: each round asks every question whose prerequisites
@@ -195,6 +229,10 @@ artifacts:
         5. the related-surface verdicts: for every surveyed surface,
            adapted in this change or excluded, each with a one-line reason;
         6. the capabilities affected.
+        7. the rule-boundary verdicts: for every rule this change adds or
+           alters, the blocking condition, the exceptions and legitimate
+           counter-examples that must be allowed, and the equivalent execution
+           paths with the mount point of the check - each with its verdict.
         Present it as a
         plain message — do NOT use the question tool for this confirmation
         (the question tool belongs to the interview rounds, not to this
@@ -219,11 +257,20 @@ artifacts:
       - **Architecture Direction**: the crystallized approach, key decisions,
         alternatives considered, and the confirmed plan summary with
         the user's explicit confirmation — the summary structured per the
-        six elements of the plan confirmation gate (including the
+        seven elements of the plan confirmation gate (including the
         itemized plain-language change list, the plain-language
-        implementation outline and the related-surface verdicts),
+        implementation outline, the related-surface verdicts and the
+        rule-boundary verdicts),
         presented as a plain message only after the interview
-        was exhausted. This is the HARD-GATE output.
+        was exhausted. The rule-boundary conclusions must appear here item by
+        item for changes that add or alter a rule, validation or blocking
+        check, or that introduce or reorder an execution path.
+        This is the HARD-GATE output.
+      - **Authoring Tier**: SIMPLE or COMPLEX with a one-line rationale
+        (criteria in the Phase 2 complexity criteria above), recorded before
+        authoring starts; SIMPLE means the orchestrating agent writes the
+        remaining artifacts itself, COMPLEX means one fresh generation
+        subagent writes them.
       - **Initial Capabilities**: preliminary guess of which specs will be touched
         (kebab-case). Finalized in proposal.md.
 
@@ -279,6 +326,15 @@ artifacts:
         method, or internal function names) unless the user explicitly asked
         for technical depth; contract facts (table, column, and endpoint
         names) are exempt and stay precise.
+      - **Rule Boundary (规则边界)**: required when this change adds or alters a
+        business rule, validation or blocking check, or introduces/reorders an
+        execution path; otherwise state 「不适用」 with a one-line reason. One
+        table row per rule - the blocking condition, the exceptions and
+        legitimate counter-examples that must be allowed (with their intended
+        handling), and the mount point of the check - plus one line per
+        equivalent execution path with its verdict. The reasoning method lives
+        in the Rule boundary branch of the clarify instruction; do not restate
+        it here.
       - **Capabilities**: Identify which specs will be created or modified:
         - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<capability-path>/spec.md`. Use kebab-case for path segments you introduce (e.g., `user-auth` or `identity/user-auth`) and follow the project's existing spec organization.
         - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Use the exact existing path under `openspec/specs/`. Leave empty if no requirement changes.
@@ -367,6 +423,13 @@ artifacts:
       - Each scenario: `#### Scenario: <name>` with WHEN/THEN format
       - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
       - Every requirement MUST have at least one scenario.
+      - Rule-type changes (a business rule, validation or blocking check added
+        or altered, or an execution path introduced/reordered) need one Scenario
+        per rule-boundary conclusion, covering three kinds: blocked (with the
+        minimal blocking condition), allowed (exceptions and legitimate
+        counter-examples), and allowed on equivalent execution paths (one
+        Scenario per path). Conclusions that do not apply are stated with a
+        reason. A spec with only blocked-side scenarios is incomplete.
 
       New capabilities only: start the delta spec with a `## Purpose` section -
       one or two sentences (50+ characters, or `openspec validate --strict`
@@ -427,6 +490,11 @@ artifacts:
         (see AGENTS.md / openspec/config.yaml rules). If the change does not
         involve persistence, state that explicitly ("本变更不涉及持久化" or the
         project's equivalent phrasing).
+      - **Rule Boundary Attachment**: MANDATORY when the change adds or alters a
+        business rule, validation or blocking check, or introduces/reorders any
+        execution path. State which action or layer the check is mounted on, and
+        why no other flow reusing that action can trip it. State explicitly when
+        the change involves no rules.
       - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
       - **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
       - **Open Questions**: Unknowns that can safely be answered later without

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/templates/clarify.md

@@ -36,9 +36,10 @@
 <!-- The crystallized approach: chosen direction, key decisions, 2-3 alternatives
      considered with tradeoffs, and the plan summary the user explicitly confirmed
      (interview answers alone do not count as confirmation; the summary must be
-     structured per the six elements of the plan confirmation gate — including
+     structured per the seven elements of the plan confirmation gate — including
      the itemized plain-language change list, the plain-language
-     implementation outline and the related-surface verdicts —
+     implementation outline, the related-surface verdicts and
+     the rule-boundary verdicts —
      presented as a plain message listing the key points, never a question-tool
      prompt, and only AFTER the interview was exhausted: presenting the plan or
      asking for its confirmation mid-interview is forbidden, and the recommended

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/templates/design.md

@@ -22,10 +22,21 @@
      rules: table prefix, primary key strategy, logical delete, audit columns).
      If no persistence, state that explicitly. -->
 
+## Rule Boundary Attachment
+
+<!-- Required when this change adds or alters a business rule, validation or
+     blocking check, or introduces/reorders an execution path; otherwise state
+     「不适用」 with a one-line reason. State which action or layer the check is
+     mounted on, and why no other flow reusing that action can trip it. -->
+
 ## Risks / Trade-offs
 
 <!-- Known risks and trade-offs. Format: [Risk] → Mitigation -->
 
+## Migration Plan
+
+<!-- Steps to deploy, rollback strategy (if applicable). Omit if not applicable. -->
+
 ## Open Questions
 
 <!-- Outstanding decisions or unknowns to resolve -->

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/templates/proposal.md

@@ -25,6 +25,23 @@
      names) unless the user explicitly asked for technical depth; contract facts
      (table/column/endpoint names) are exempt and stay precise. -->
 
+## Rule Boundary
+
+<!-- 规则边界：required when this change adds or alters a business rule,
+     validation or blocking check, or introduces/reorders an execution path;
+     otherwise write 「不适用」 + a one-line reason. One table row per rule, plus
+     the equivalent-path list. The table form is required so each conclusion can
+     be checked item by item. The reasoning method lives in the Rule boundary
+     branch of the clarify instruction in schema.yaml - point there, do not
+     restate it here.
+
+     | 规则 | 该拦的条件 | 该放的例外与合法反例（附应有处理） | 判定挂载点 |
+     |---|---|---|---|
+     | <rule> | <minimal condition that blocks> | <exception / legitimate counter-example + intended handling> | <business-intent action the check sits on> |
+
+     Equivalent execution paths: one line per path - the intent, the path, and
+     whether the check fires correctly on it. -->
+
 ## Capabilities
 
 ### New Capabilities

package/assets/skills/openspec-standard/templates/schemas/spec-driven-standard/templates/spec.md

@@ -1,3 +1,11 @@
+<!-- Rule-type changes (a business rule, validation or blocking check added or
+     altered, or an execution path introduced/reordered): one Scenario per
+     rule-boundary conclusion, covering three kinds - blocked (with the minimal
+     blocking condition), allowed (exceptions and legitimate counter-examples),
+     and allowed on equivalent execution paths (one Scenario per path).
+     Conclusions that do not apply are stated with a reason. Blocked-side
+     scenarios alone count as an incomplete spec. -->
+
 ## ADDED Requirements
 
 ### Requirement: <!-- requirement name -->

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

@@ -39,6 +39,7 @@ phases:
         instructions:
           - "校验 design.md 与 tasks.md、specs/ 下相关 spec.md 的一致性（据 tasks.md 各行 `[spec:xxx]` 溯源定位相关 spec.md 一并复核）"
           - "按评估维度逐项审查 design.md 并给出结论：architecture / api-design / db-design（无问题也需简要确认），不以假设替代确认"
+          - "方案涉及新增/修改业务规则、校验或拦截逻辑，或新增/改变任何执行路径时，按架构维度检查点清单核对规则边界推演结论（对照 proposal.md 的「规则边界」小节、specs 下相关 spec.md 的场景、design.md 的判定挂载点，聚焦当前任务组直接相关的规则变更）；命中检查点定义的缺陷 → 提交 blocker（category: architecture_design），不以假设替代确认"
           - "校验设计文档与任务前提的一致性，评估架构模式合规性"
           - "输出执行边界：allowed_directories（含测试目录）与 allowed_packages 白名单，notes 仅填实施建议（关键坑位/组件复用/边缘场景/框架应用/通用做法），不重复目录与包路径，无补充时留空"
           - "存在缺口时提交 blocker（category: architecture_design / info_gap），不以假设替代确认"
@@ -53,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
@@ -62,6 +63,7 @@ phases:
           - "按 Task 项顺序逐个实现，聚焦当前子任务，不超出执行边界"
           - "实施前识别 spec 描述的一并操作行为组（如状态变更与数据入队这类需同时发生的多个行为）；实施后逐项自证每个行为真实生效，禁止以单一状态字段的实现替代其他行为"
           - "涉及数据模型或流程产出变更（含字段/实体承载位置搬迁、AI 生成等流程产物）时，自证须包含关键数据产出断言：产出字段已持久化到 spec 指定承载位置且值完整非空、搬迁承接与同一输入产出基线一致（按已加载接口测试规范执行）；禁止仅以流程跑通/接口成功替代"
+          - "有代码、接口契约或数据口径变更时，须按已加载的测试设计规范产出行为面清单、用例矩阵与反向探针记录，随提交在 self_check_results 中逐项申报；反向探针结束后必须先还原实现并复跑全量用例确认全绿再提交，禁止带着改坏的实现提交"
           - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；隔离对象不限于数据库——为本变更启动的 mock 服务、消息队列/缓存等中间件、扫描分析平台等一切环境资源均须按隔离标识隔离，禁止复用既有实例或共享端口；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动；残留判定遵循已加载清理规范的归属判别，无法确认归属本变更的进程一律不清"
           - "涉及接口契约或数据口径变更（按已加载的接口测试规范判定）时，实施过程中即时更新/新建与变更接口对应的 `.http` 测试脚本（已有脚本更新为匹配变更后契约，尚无脚本则新建，并同步 SQL 前置数据脚本），按已加载接口测试规范的完整执行顺序（含 SQL 前置数据准备、隔离启动基础设施与服务、执行 `.http` 脚本）执行接口测试，确保变更内容真实有效；执行结果（附执行顺序与覆盖接口清单）经 test_results 参数提交；修复被驳回 issue 后再次提交前同样须执行"
           - "自证完成后停止本次启动的服务/基础设施实例，不留残留"
@@ -122,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 | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -156,7 +156,10 @@
           |------|--------------|--------------------------|
           | Critical | 核心层依赖框架导致循环依赖或编译失败 | design 中的 schema 与实现冲突导致无法建表/编译；tasks 缺失核心步骤导致实施方向错误；实施所需关键信息缺失（如模板路径、字段映射未明），导致无法开始实施；设计架构方案违反 architecture skill 的 MUST 规则 |
           | High | 表示层直接绕过领域层访问基础设施 | spec 需求在 tasks 中无对应任务；基础架构任务错排位置；实施所需信息不完整，部分任务需等待补充信息才能推进；设计方案偏离 architecture skill 推荐做法，存在可通过调整规避的风险；设计方案破坏既有接口/数据/行为契约且无兼容或过渡安排；重构方案改变既有行为语义且未显式声明 |
+          | High | 已实现的校验/拦截把功能上合法的场景拦住，或判定挂在被其它业务流程复用的底层动作上致其误触，且无兼容或过渡安排 | 方案新增/修改的规则会误伤功能上合法的场景，或判定挂载点会被复用该动作的其它流程误触，且方案未说明 |
+          | High | 本次变更新增或重排的执行路径绕过了既有校验/拦截（该拦未拦），且无兼容或过渡安排 | 方案新增或重排的执行路径会使既有规则/校验/拦截失效（该拦未拦），且方案未说明如何在新路径上保持该判定 |
           | Medium | 依赖注入方式不符合约定（如字段注入）；数据对象可变导致并发风险；应基础设施化的共性能力被分散实现（多处重复、横向共性需求、新增场景易遗漏调用）；引入与既有实现功能重叠的平行实现（另起一套逻辑），同类能力多套方案并存且无迁移方案；引入或延续可识别技术债且无偿还规划（如采用 EOL/弃用技术选型、临时方案长期固化、接口契约不一致）；重构/变更破坏既有契约（接口/数据/行为）或改变既有行为语义且无兼容说明 | tasks 范围模糊；design 技术细节与 tasks 完成标准不一致 |
+          | Medium | 已实现的校验/拦截落在被其它业务流程复用的底层动作上，或未覆盖 design.md 列出的例外与等价执行路径，无法确认是否会误伤 | 方案未给出规则边界结论（该拦条件、该放的例外与合法反例、等价执行路径与判定挂载点），无法判断是否会误伤 |
           | Low | 数据对象缺少不可变修饰但当前无并发场景；已有代码中违反分层原则但影响极小的结构性缺陷 | 文档引用路径有冗余前缀；描述用词与 spec 不一致但不影响理解 |
           | Info | 建议拆分为独立服务；建议引入某设计模式（仅当不属于 Low 及以上时） | 建议补充某边缘场景说明；可 `（待补充）` 占位、不阻塞开工的边缘信息缺失 |
 
@@ -220,7 +223,7 @@
           - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
           - 方案复用与平行实现：识别引入与既有实现功能重叠的平行实现（另起一套逻辑）的情况——同类能力已有既有实现时须优先复用或扩展，另建实现且不改动原实现、无迁移方案则报 issue；方案确需平行引入（新旧并存）时按需用户拍板问题的确认机制确认并存期与技术债，无人值守缺省裁决为方案必须包含原技术实现的迁移方案。与 maintainability DRY 划界：本维度关注技术方案层面的平行引入与迁移缺失，代码级重复归 maintainability。具体复用与迁移要求按 skill 约定
           - 技术债识别：按 skill 中的技术债识别约定——识别存量与新增技术债（过时技术选型、迁移中断残留、平行实现、临时方案固化、契约不一致），按统一严重级别报 issue；方案引入的债务须在方案中规划偿还或说明可接受理由
-          - 架构演进审查：按 skill 中的架构演进审查约定——方案/实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义；实施侧破坏兼容或改变既有语义按统一严重级别报 issue，方案侧破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
+          - 架构演进审查：按 skill 中的架构演进审查约定——方案/实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义；实施侧破坏兼容或改变既有语义按统一严重级别报 issue，方案侧破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；变更涉及新增/修改业务规则、校验或拦截，或新增/改变任何执行路径时，核对规则边界推演——该拦条件与例外、功能上合法的反例（是否存在不该拦而拦）、既有规则在新执行路径上是否仍成立（是否存在该拦未拦）、同一业务意图的等价执行路径及其判定挂载点（判定须挂在业务意图层的动作上，不得落在被其它业务流程复用的底层动作上）；推演缺失或不完整按统一严重级别报 issue
 
           ### 可维护性维度
 
@@ -269,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,6 +1,6 @@
 {
   "name": "@ifrankwang/openspec-agents",
-  "version": "0.147.2",
+  "version": "0.149.0",
   "description": "OpenSpec change orchestration plugin for AI coding agents (Claude Code, Codex, ZCode, DeepSeek Harness, OpenCode)",
   "author": "ifrankwang",
   "license": "MIT",

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 不会被受理。`,
       "",
     )
   }