@ifrankwang/openspec-agents 0.125.0 → 0.126.0

package/.mcp-server/cli.mjs

@@ -37100,7 +37100,7 @@ async function ensureDefaultUnattended(args, ctx) {
     }
   } catch {}
 }
-var PKG_VERSION = "0.125.0";
+var PKG_VERSION = "0.126.0";
 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

@@ -27,7 +27,7 @@ OpenSpec 把需求、设计、任务拆解成规范文档后，实施阶段仍
 
 `implement → quality_review → done`
 
-面向轻量变更的精简流程：无 analyze 环节（执行边界默认整个 worktree），无 verify_tool / verify_task / verify_cleanup 环节。implement 失败自循环重试；quality_review 由单一审查者合并承担工具检查、任务验证与质量审查（工具改进建议双报机制保留，由开发者实施），失败回 implement 整步重审；开发者提交 implement 成果时强检查工作区干净（不干净拒绝并提示先 commit），收尾为直接合并分支并清理（裸合并，无回归；环境清理由审查者验证完成后自行完成——停止残留服务、清理隔离环境，收尾不单独承担环境清理；合并冲突由开发者解决后直接收尾）。tasks.md 复选框在任务组收尾（opx_orch_complete_task_group）时统一勾选当前任务组，勾选提交落在 worktree 分支、随合并带回主分支；full 与 simple 行为一致，任务完成状态以状态文件为准。
+面向轻量变更的精简流程：无 analyze 环节（执行边界默认整个 worktree），无 verify_tool / verify_task / verify_cleanup 环节。implement 失败自循环重试；quality_review 由单一审查者合并承担工具检查、任务验证与质量审查（工具改进建议双报机制保留，由开发者实施），失败回 implement 整步重审；开发者实施时按已加载接口测试规范即时更新并执行 `.http` 接口测试自证变更有效（含关键数据产出断言）；开发者提交 implement 成果时强检查工作区干净（不干净拒绝并提示先 commit），收尾为直接合并分支并清理（裸合并，无回归；环境清理由审查者验证完成后自行完成——停止残留服务、清理隔离环境，收尾不单独承担环境清理；合并冲突由开发者解决后直接收尾）。tasks.md 复选框在任务组收尾（opx_orch_complete_task_group）时统一勾选当前任务组，勾选提交落在 worktree 分支、随合并带回主分支；full 与 simple 行为一致，任务完成状态以状态文件为准。
 
 ## 身份与角色
 
@@ -43,7 +43,7 @@ OpenSpec 把需求、设计、任务拆解成规范文档后，实施阶段仍
 - **Workflow 驱动**：步骤、角色、门禁在 workflow 中声明，`opx_status` 是下一步调度的唯一事实源。
 - **多 Agent 团队**：主代理编排，2 个物理子代理承载 9 种逻辑身份分工协作，避免单一大模型从头写到尾失控。
 - **强 Review 门禁**：full 模式 tool / task / quality 三层审查 + 收尾验证；simple 模式单一审查者合并审查。问题可回退、可豁免、可检查点决策。确定性质量工具问题以压制手段解决时视为豁免申请，须说明理由并经审查判定合理性。
-- **隔离与安全**：每个 change 使用独立 git worktree、资源隔离命名空间，减少相互干扰。
+- **隔离与安全**：每个 change 使用独立 git worktree、资源隔离命名空间（数据库、mock 服务、消息队列/缓存等中间件、扫描分析平台均按隔离标识隔离），减少相互干扰。
 - **可观测**：内置进度看板，状态/豁免/并发锁持久化到 `openspec/states/`。
 
 ## 优缺点

package/assets/agents/openspec-developer.md

@@ -15,7 +15,7 @@ permission:
 
 提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
 
-自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。
+自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。隔离对象不限于数据库（mock 服务、消息队列/缓存等中间件、扫描分析平台均按隔离标识隔离）。
 
 任务执行与提交约束（Task/Issue 清单处理、环境问题处置、blocker 提交、文档读取范围、工具调用边界）以 opx_status 操作指引与约束区块为准，此处不重复描述。
 
@@ -60,7 +60,7 @@ permission:
 - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
 - 方案复用与平行实现：按 skill 中的方案复用与平行实现约定——同类能力已有既有实现时（如已有手工限流基础框架仍引入新限流框架且不改动原实现）须优先复用或扩展，确需平行引入（新旧并存）时按上文需用户拍板问题的确认机制确认并存期与技术债，无人值守缺省裁决为方案必须包含原技术实现的迁移方案
 - 技术债识别：按 skill 中的技术债识别约定——方案是否引入可识别技术债（过时技术选型、技术迁移中断、平行引入、临时方案固化、契约不一致），引入的债务须在方案中规划偿还或说明可接受理由
-- 架构演进审查：按 skill 中的架构演进审查约定——方案是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口/数据/行为兼容性）、重构方案是否贴合项目历史逻辑并保持既有行为语义；破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排
+- 架构演进审查：按 skill 中的架构演进审查约定——方案是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口/数据/行为兼容性）、重构方案是否贴合项目历史逻辑并保持既有行为语义；破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
 
 ## 执行边界产出（架构师身份）
 

package/assets/agents/openspec-reviewer.md

@@ -56,8 +56,8 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 | 级别 | task 产出验证 | 服务启动验证 | 测试审查 |
 |------|-------------|-------------|---------|
 | Critical | 核心 task 产出文件缺失 | 服务无法启动（无论是否本次变更引起） | 测试依赖无隔离环境导致 CI 必然失败 |
-| High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为 |
-| Medium | task 产出存在但质量不达标 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试 |
+| High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效）；流程执行正常但关键数据产出缺失/未落库/落错位置（区别于『仅打状态标记未实际生效』：本行=流程与响应正常，产出物缺失或落错位） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为；测试仅验证流程跑通/响应成功，未对 spec 要求的关键数据产出（落位/完整性）断言 |
+| Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
 | Low | 产出文件位置不符合约定 | 启动日志格式不统一 | 测试命名不规范但不影响运行 |
 | Info | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -138,7 +138,7 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
 - 方案复用与平行实现：识别引入与既有实现功能重叠的平行实现（另起一套逻辑）的情况——同类能力已有既有实现仍另建实现且不改动原实现、无迁移方案则报 issue。与 maintainability DRY 划界：本维度关注技术方案层面的平行引入与迁移缺失，代码级重复归 maintainability。具体复用与迁移要求按 skill 约定
 - 技术债识别：按 skill 中的技术债识别约定——识别实现中的存量与新增技术债（过时技术选型、迁移中断残留、平行实现、临时方案固化、契约不一致），按统一严重级别报 issue
-- 架构演进审查：按 skill 中的架构演进审查约定——实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义，破坏兼容或改变既有语义按统一严重级别报 issue
+- 架构演进审查：按 skill 中的架构演进审查约定——实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义，破坏兼容或改变既有语义按统一严重级别报 issue；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
 
 ### 可维护性维度
 
@@ -187,7 +187,7 @@ Info 级别 issue 的 description/suggestion 中禁止出现阶段/时机相关
 ## 职责边界（确定性检查与任务验证）
 
 - **确定性工具检查**：工具维度审查者与 simple 合并审查者被允许运行确定性工具检查（代码格式/架构约束/静态分析/单元测试编译/深度扫描），按已加载质量门 skill 的必做清单执行并将输出映射为统一 issue 结构；检查结果纳入审查结论
-- **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留
+- **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷
 - **工具改进**：可工具化的质量 pattern 双报业务 issue 与工具改进 issue（规则草案由审查者提供），实施工作由开发者完成，审查者不直接改动规则/配置文件以外的实现
 
 ## 压制判定

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

@@ -98,17 +98,18 @@ API 测试脚本运行前需获取有效认证凭证。常见模式：
 ## 执行顺序
 
 ```
-1. **MUST** 启动基础设施（Docker compose 项目名带隔离标识：`docker compose -p <namespace> up -d`，避免与并发 change 的容器冲突）
+1. **MUST** 启动基础设施（Docker compose 项目名带隔离标识：`docker compose -p <namespace> up -d`，避免与并发 change 的容器冲突；隔离对象不限于数据库——mock 服务、消息队列/缓存等中间件、扫描分析平台等一切为本变更启动的资源均须经隔离标识启动，禁止复用宿主既有实例或共享端口）
 2. **MUST** 准备 SQL 前置数据（写入本 change 的隔离容器内 DB）
 3. **MUST** 启动服务（端口用编排会话建议端口：`--server.port=<建议端口>`，避免并发 change 端口冲突）
 4. API 测试脚本（BASE_URL 使用上述端口）
 5. **MUST** 停止服务并清理隔离环境（`docker compose -p <namespace> down`），随后幂等自检：本 change 隔离标识下无残留容器（`docker compose -p <namespace> ps` 为空）、建议端口无进程监听
 ```
 
-以上第 1、2、3、5 条为 MUST：隔离（独立 compose 项目名、隔离 DB、建议端口、down 清理）是并发安全硬约束，不适用本文件开头「项目规范优先」的推荐豁免。
+以上第 1、2、3、5 条为 MUST：隔离（独立 compose 项目名、隔离数据库、隔离 mock 服务/中间件/扫描分析平台、建议端口、down 清理）是并发安全硬约束，不适用本文件开头「项目规范优先」的推荐豁免。
 
 - SQL 在前：先准备数据，再启动应用确保应用启动时读取到完整数据
 - 隔离标识 `<namespace>` 与建议端口来自编排会话上下文
+- 隔离对象不限于数据库：除数据库外，mock 服务、消息队列/缓存等中间件、扫描分析平台等其余为本变更启动的环境资源均须按隔离标识隔离；仅隔离数据库不满足并发安全要求
 - 启动服务：按项目构建文件确定的启动方式（mvn / gradle / npm 等），端口用编排会话建议端口
 - API 脚本：BASE_URL 使用上述建议端口，依赖运行中的服务
 - 停止服务：测试完成后停止服务并清理隔离环境
@@ -122,11 +123,18 @@ API 测试脚本必须覆盖所有新增/变更接口：
 | 正常路径 | 按 spec 请求结构传入合法值，验证响应状态码(2xx) 和响应结构 |
 | 关键边界 | 缺必填字段 → 4xx；非法值(空串/超长/类型错误) → 4xx；极值 → 正确响应或合理错误 |
 | 业务闭环 | spec 含列表/详情/状态流转/删除接口时，测试须端到端闭环：创建后用返回标识在列表/详情检索成功、状态变更后可见性反映、删除/停用后不可见 |
+| 关键数据产出 | 涉及数据产出/落位/搬迁的变更，测试须断言关键产出字段已持久化到 spec 指定承载位置且值完整非空；产出为异步/延迟时须等待产出完成后断言；仅凭响应 2xx 与流程跑通不构成验收 |
 
 spec 描述为多个行为一并发生的（如状态变更与数据入队），每个行为都须有断言证据；断言范围不限于响应状态码与响应结构，须覆盖变更引发的真实行为（状态落库、消息入队、下游可消费等连带效果）。
 
 「业务闭环」与「一并操作行为组」划界：行为组=同一请求内多个行为同时发生的断言；闭环=跨请求链路的可见性验证（创建 → 检索 → 变更 → 删除），二者互补，均须覆盖。
 
+「数据产出落位」≠业务闭环（闭环=跨请求可见性：创建→检索→变更→删除；数据产出=产出字段在 spec 指定承载位置的持久化与完整性，含不暴露于响应、须异步等待的字段）；也≠一并操作行为组（行为组=同一请求内多个行为同时发生）。三者互补，均须覆盖；数据产出断言不得以「详情接口能查到」替代「字段已持久化到 spec 指定承载位置」。
+
+## 数据模型搬迁与数据产出回归
+
+字段/实体承载位置变更（如字段从子实体搬到实体根）时，测试须验证：新位置读写正常、旧位置无遗漏依赖/无残留写入、存量数据迁移后可读、关键产出字段非空完整、产出字段新旧承载位置映射正确；回归场景以同一输入比对关键数据产出与变更前基线一致（持久化存储快照/导出/读回结果对比）。
+
 ## 测试数据
 
 http 请求体与 SQL 前置数据均按 spec 业务语义构造：使用真实字段值与业务含义明确的数据（如按 spec 字段语义构造的订单号、状态名、业务名称），禁止无意义占位值（如「测试数据」「aaa」「test1」）。列表/详情检索断言须基于真实业务标识（创建接口返回的 id/编码），使检索结果可预期、可追溯。
@@ -138,6 +146,7 @@ http 请求体与 SQL 前置数据均按 spec 业务语义构造：使用真实
 以下情况不属于 API 变更，可豁免本章约束：
 - 纯配置文件（非接口契约配置）、构建脚本、GitHub Actions、Docker 文件
 - 仅 SQL init 文件改动且无 API 契约影响
+- 涉及数据模型搬迁/存量数据迁移的 SQL 改动不适用「仅 SQL init 文件改动且无 API 契约影响」豁免
 - 纯格式、注释、import 排序等无逻辑变更
 - 仅测试代码变更（无生产代码、接口契约、构建与测试配置改动）
 - 纯文档变更
@@ -146,7 +155,8 @@ http 请求体与 SQL 前置数据均按 spec 业务语义构造：使用真实
 
 MUST 遵守以下约束，不得以编译通过或单元测试通过替代 API 测试：
 
-- MUST 不得以接口返回成功与状态字段正确作为唯一验收；spec 含一并操作行为组时，须提供每个行为真实发生的断言证据。
+- MUST 不得以接口返回成功、状态字段正确或流程执行顺畅作为唯一验收；spec 含一并操作行为组时，须提供每个行为真实发生的断言证据。
+- MUST 数据产出类变更须提供关键产出字段落位与完整性的断言证据（产出为异步/延迟时须等待产出完成后断言）。
 
 ### 脚本准备
 

package/assets/skills/architecture-evolution/SKILL.md

@@ -20,7 +20,7 @@ capabilities: ["architecture"]
 | 术语/命名与通用语言漂移 | 命名与通用语言约定 |
 | 分层规则合规、依赖方向违规（绕过分层直连） | 架构分层约定 |
 | 方案设计时未复用既有能力/平行引入新实现 | 方案复用与平行实现约定 |
-| 本 skill 四类检查与上述职责的相邻边界见各类检查中的划界说明 | 本 skill |
+| 本 skill 五类检查与上述职责的相邻边界见各类检查中的划界说明 | 本 skill |
 
 ## 检查类别
 
@@ -58,3 +58,7 @@ capabilities: ["architecture"]
 - 判据：重构改变既有行为语义且未显式声明
 - 处置：重构改变既有行为语义且未显式声明 → 至少 Medium 级别 issue
 - 划界：重构场景下破坏契约归本类；非重构场景的新契约破坏归第 3 类。平行引入新实现（另起一套）归方案复用与平行实现约定
+
+### 5. 数据模型搬迁与数据承接
+
+涉及字段/实体承载位置搬迁时，须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失或遗漏产出字段承载点按契约破坏/重构贴合判例处理。

package/assets/skills/environment-cleanup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: environment-cleanup
-description: 隔离环境清理通用规范——停止残留服务、清理隔离容器/数据库、删除隔离扫描分析项目。技术栈无关。
+description: 隔离环境清理通用规范——停止残留服务、清理隔离容器/数据库/mock 服务/中间件、删除隔离扫描分析项目。技术栈无关。
 capabilities: ["cleanup"]
 ---
 
@@ -22,8 +22,9 @@ capabilities: ["cleanup"]
 
 - 隔离容器：按隔离标识确认存在性后停止并移除（无残留容器即通过，不因重复清理报错）
 - 隔离数据库：确认无残留的隔离数据库实例/数据卷后清理；无残留即通过
+- 隔离 mock 服务/中间件：按隔离标识停止并移除对应容器/实例；无残留即通过
 
-幂等判据：隔离标识下无残留容器、无残留隔离数据库即为清理完成，重复执行不产生副作用。
+幂等判据：隔离标识下无残留容器、无残留隔离数据库、无残留隔离 mock 服务/中间件即为清理完成，重复执行不产生副作用。
 
 ## 删除隔离扫描分析项目
 
@@ -41,4 +42,5 @@ capabilities: ["cleanup"]
 
 - 无残留的服务进程（本次启动的进程已停止，端口监听已释放）
 - 无残留的隔离容器（隔离标识下 compose ps 为空）
+- 无残留的隔离 mock 服务/中间件（按隔离标识查询不存在或容器已移除）
 - 无残留的隔离扫描分析项目（按隔离标识查询不存在）

package/assets/skills/java-quality-gate/SKILL.md

@@ -29,7 +29,7 @@ must_do: ["env", "compile", "format", "architecture", "static_analysis", "unit_t
 
 在执行工具检查前，先确保工具运行环境就绪。环境检查失败时先按自愈性步骤尝试恢复；不可自愈或自愈失败后，用 `question` 提请用户处理或裁定。用户裁定降级跳过时，在报告中注明降级理由，不阻塞其他检查。
 
-使用编排会话提供的隔离标识 `<namespace>`（来自编排会话上下文）为 SonarQube 容器指定独立的 docker compose 项目名，避免多个并发 change 的容器互相冲突。
+使用编排会话提供的隔离标识 `<namespace>`（来自编排会话上下文）为 SonarQube 容器指定独立的 docker compose 项目名，避免多个并发 change 的容器互相冲突。环境隔离对象不限于数据库：SonarQube 实例与扫描项目均须按隔离标识隔离（独立 compose 项目名 + 项目 key 后缀，见第 6 节），禁止复用宿主既有实例/项目。
 
 ```bash
 docker info

package/assets/workflows/task-simple.yaml

@@ -30,7 +30,9 @@ phases:
           - "tasks.md 当前任务组任务项 + `[spec:xxx]` 溯源 specs/ 下相关 spec.md（需求细节与验收标准）；存在时读取 clarify.md（架构方向结论）"
           - "按 Task 项顺序逐个实现，聚焦当前子任务，不超出执行边界"
           - "实施前识别 spec 描述的一并操作行为组（如状态变更与数据入队这类需同时发生的多个行为）；实施后逐项自证每个行为真实生效，禁止以单一状态字段的实现替代其他行为"
-          - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动"
+          - "涉及数据模型或流程产出变更（含字段/实体承载位置搬迁、AI 生成等流程产物）时，自证须包含关键数据产出断言：产出字段已持久化到 spec 指定承载位置且值完整非空、搬迁承接与同一输入产出基线一致（按已加载接口测试规范执行）；禁止仅以流程跑通/接口成功替代"
+          - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；隔离对象不限于数据库——为本变更启动的 mock 服务、消息队列/缓存等中间件、扫描分析平台等一切环境资源均须按隔离标识隔离，禁止复用既有实例或共享端口；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动"
+          - "涉及接口契约或数据口径变更（按已加载的接口测试规范判定）时，实施过程中即时更新/新建与变更接口对应的 `.http` 测试脚本（已有脚本更新为匹配变更后契约，尚无脚本则新建，并同步 SQL 前置数据脚本），按已加载接口测试规范的完整执行顺序（含 SQL 前置数据准备、隔离启动基础设施与服务、执行 `.http` 脚本）执行接口测试，确保变更内容真实有效；执行结果纳入自证与 self_check_results；修复被驳回 issue 后再次提交前同样须执行"
           - "自证完成后停止本次启动的服务/基础设施实例，不留残留"
           - "环境/基础设施问题（schema 缺失、DDL 未执行、依赖未安装）应通过 migration/初始化脚本等代码层面解决；仅生产级凭据、真实第三方资源、人工运维才走 blocker/豁免"
           - "issue 指向文件的目录已并入执行边界，修复这些文件（含回归引入问题）不算越界；issue 的 file 字段指向 openspec/changes/ 下文档时，按该 issue 要求修复对应文档同样不算越界（仅限该 issue 指定文件，不得扩大范围）；可按 issue 的 suggestion 直接执行修复；reviewer 的 boundary_expansion 已并入边界"
@@ -53,7 +55,7 @@ phases:
           - "需以 verdict=failed + blocker 上报的条件：需求模糊 / design 问题 / 技术阻塞 / 超出执行边界"
           - "禁止以 SonarQube 平台状态修改（SAFE/WONTFIX/False Positive/Confirmed 等）作为豁免手段：平台状态仅作用于当前 SonarQube 项目实例，每次 change 使用独立项目 key，不跨 change 生效；存量问题跨 change 豁免必须经 exempt_issue_ids 申请 → 报源 reviewer 裁定 dismissed 的流程"
           - "禁止以压制手段静默规避确定性质量工具问题：压制必须附明确理由并经豁免申请流程裁定，不得以工具不再报错为由跳过申报"
-          - "禁止为腾出端口或资源而停止、复用或干扰非本变更启动的进程（含用户或其他会话运行的服务实例）；验证一律走隔离启动"
+          - "禁止为腾出端口或资源而停止、复用或干扰非本变更启动的进程（含用户或其他会话运行的服务实例）；验证所需环境（数据库、mock 服务、消息队列/缓存等中间件、扫描分析平台等）一律按隔离标识隔离启动，禁止共享或占用宿主既有实例"
   - name: review
     steps:
       - id: quality_review
@@ -66,10 +68,10 @@ phases:
         instructions:
           - "依据 opx_status 提供的变更检测结果分流：无代码/配置变更且本层无待复核/待裁定项 → 直接提交 passed，不运行全量工具检查，并以一条 step 名首段为 no_change 的 validation_steps 声明本轮整体豁免必做清单（completed=false + 结构化 skip_reason 注明判定依据）；无变更但有本层待复核/待裁定项 → 仅复核/裁定待处理项后提交，不跑全量工具扫描；有变更 → 加载质量门类 skill 获取工具清单与映射规则，按已加载质量门 skill 必做清单逐项执行全部确定性工具检查（代码格式/架构约束/静态分析/单元测试编译/深度扫描——按必做清单中的对应项逐项执行并逐项申报），将工具输出映射为统一 issue 结构后提交"
           - "「有变更」分支先审查上方「本次变更证据」区块的变更文件清单与区间 diff 内容后自行判断：若确认本次变更仅为注释/文档性且无逻辑影响（非注释掉代码、非结构性/格式化变更、非文件重命名），可自行决定跳过全量工具检查直接提交 passed（validation_steps 以 step=no_change 申报整体豁免必做清单）；无法确认或含逻辑/结构变更，必须顺序运行全部确定性工具检查；裁量仅免除全量工具扫描，不免除复核/裁定——本层 blocking issue 仍须处理至终态后提交"
-          - "逐项验证：①task 产出完整性 ②启动服务并检查健康 ③独立执行全量 API 测试并审查质量（含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值） ④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷"
+          - "逐项验证：①task 产出完整性 ②启动服务并检查健康 ③独立执行全量 API 测试并审查质量（含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值） ④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷 ⑥关键数据产出核验：对照 spec 数据产出要求，核验实现与测试是否覆盖产出数据落位（spec 指定承载位置）、完整非空、搬迁承接与同一输入基线一致，识别『流程正常但数据缺失/落错位置』类缺陷"
           - "验证完成后（含 verdict=failed 报 issue 回退 implement 的轮次）按已加载的清理规范执行幂等清理：停止残留的服务实例、清理本 change 的隔离环境、删除残留的隔离扫描项目；无残留即通过，不因重复执行报错；清理结果纳入 validation_steps 申报（未执行须以 completed=false + 结构化 skip_reason 说明）"
-          - "本次变更仅含测试代码（判定：视图「变更范围」文件清单全部命中已加载技术栈 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 合约"
+          - "本次变更仅含测试代码（判定：视图「变更范围」文件清单全部命中已加载技术栈 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 合约"
           - "加载匹配维度 skill，以本轮 diff/变更文件为锚点结合 skill 规范与领域知识做拓展审查（skill 仅为最低基准）；顺带发现的非本轮缺陷按对应维度严重级别标准报 issue，禁止静默丢弃"
           - "审查新 issue 前先查看视图「待复核」区块中的既有 issue（仅本审查者报源），避免语义重复"
           - "报 issue 时必须显式声明归因维度 dimension（style/architecture/performance/security/maintainability）：本 reviewer 不归属任一质量维度，dimension 即该 issue 归属的目标质量维度"

package/assets/workflows/task.yaml

@@ -61,7 +61,9 @@ phases:
           - "tasks.md 当前任务组任务项 + `[spec:xxx]` 溯源 specs/ 下相关 spec.md（需求细节与验收标准）；存在时读取 clarify.md（架构方向结论）"
           - "按 Task 项顺序逐个实现，聚焦当前子任务，不超出执行边界"
           - "实施前识别 spec 描述的一并操作行为组（如状态变更与数据入队这类需同时发生的多个行为）；实施后逐项自证每个行为真实生效，禁止以单一状态字段的实现替代其他行为"
-          - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动"
+          - "涉及数据模型或流程产出变更（含字段/实体承载位置搬迁、AI 生成等流程产物）时，自证须包含关键数据产出断言：产出字段已持久化到 spec 指定承载位置且值完整非空、搬迁承接与同一输入产出基线一致（按已加载接口测试规范执行）；禁止仅以流程跑通/接口成功替代"
+          - "自证/验证需启动服务或基础设施时，一律按已加载技术栈 skill 的隔离启动规范以隔离方式启动，隔离标识与建议端口以视图 Worktree 区块为准；隔离对象不限于数据库——为本变更启动的 mock 服务、消息队列/缓存等中间件、扫描分析平台等一切环境资源均须按隔离标识隔离，禁止复用既有实例或共享端口；启动前发现隔离环境有残留时，先按已加载的清理规范幂等清空再启动"
+          - "涉及接口契约或数据口径变更（按已加载的接口测试规范判定）时，实施过程中即时更新/新建与变更接口对应的 `.http` 测试脚本（已有脚本更新为匹配变更后契约，尚无脚本则新建，并同步 SQL 前置数据脚本），按已加载接口测试规范的完整执行顺序（含 SQL 前置数据准备、隔离启动基础设施与服务、执行 `.http` 脚本）执行接口测试，确保变更内容真实有效；执行结果纳入自证与 self_check_results；修复被驳回 issue 后再次提交前同样须执行"
           - "自证完成后停止本次启动的服务/基础设施实例，不留残留"
           - "环境/基础设施问题（schema 缺失、DDL 未执行、依赖未安装）应通过 migration/初始化脚本等代码层面解决；仅生产级凭据、真实第三方资源、人工运维才走 blocker/豁免"
           - "issue 指向文件的目录已并入执行边界，修复这些文件（含回归引入问题）不算越界；issue 的 file 字段指向 openspec/changes/ 下文档时，按该 issue 要求修复对应文档同样不算越界（仅限该 issue 指定文件，不得扩大范围）；可按 issue 的 suggestion 直接执行修复；reviewer 的 boundary_expansion 已并入边界"
@@ -72,7 +74,7 @@ phases:
           - "提交前完成自检并经 self_check_results 汇总"
           - "提交前按已加载的维度规范类 skill（style/architecture/performance/security/maintainability 能力类别）对本次变更文件逐项自检（聚焦本轮变更文件，不扩散全量代码），自检结论与工具检查结果一并汇总进 self_check_results；修复被驳回 issue 后再次提交前同样须按维度规范类 skill 对变更文件自检后再提交"
           - "自检须覆盖已加载的维度规范类 skill 的全部检查点，self_check_results 按维度逐项列结论（通过/遗留及理由），禁止仅汇总工具检查结果"
-          - "修复完成的 issue 经 fixed_issue_ids 上报后进入待复核（review）状态，终态由对应 reviewer 复核裁定；不可修 issue 经 exempt_issue_ids 申请豁免（申请后进入待裁定（review）状态，由报源 reviewer 在后续审查轮次裁定，被驳回的 issue 回待修复）；Info 级 issue 不阻塞提交，无需申请豁免；全部 blocking issue 均已上报修复或申请豁免后才可 passed 提交推进"
+          - "修复完成的 issue 经 fixed_issue_ids 上报后进入待复核（review）状态，终态由报源 reviewer 复核裁定；不可修 issue 经 exempt_issue_ids 申请豁免（申请后进入待裁定（review）状态，由报源 reviewer 在后续审查轮次裁定，被驳回的 issue 回待修复）；Info 级 issue 不阻塞提交，无需申请豁免；全部 blocking issue 均已上报修复或申请豁免后才可 passed 提交推进"
           - "确定性质量工具检查出的问题不得以压制手段（压制注解/注释抑制/规则排除配置/平台状态标注/构建跳过开关等）静默规避：确需压制时，必须在压制处代码注释说明清楚理由（commit message 可补充），并经 exempt_issue_ids 申请豁免由报源 reviewer 裁定；不得以 fixed_issue_ids 冒充修复；被驳回后须移除压制并真实修复"
           - "遇外部依赖、凭证、真实输入或必须 stub/降级/跳过验收才能继续时，以 verdict=failed 提交 blocker（含 source_role、task_id、category、description、evidence、attempted_actions、options）"
           - "提交 opx_agent_submit：passed 时存在未完成或被驳回（open/rejected）的子任务必须全部列入 completed_task_ids（数字 id 如 1、2，或任务编号如 1.1），全部子任务已验证时可省略；不可修 issue 申请豁免（exempt_issue_ids）"
@@ -86,7 +88,7 @@ phases:
           - "需以 verdict=failed + blocker 上报的条件：需求模糊 / design 问题 / 技术阻塞 / 超出执行边界"
           - "禁止以 SonarQube 平台状态修改（SAFE/WONTFIX/False Positive/Confirmed 等）作为豁免手段：平台状态仅作用于当前 SonarQube 项目实例，每次 change 使用独立项目 key，不跨 change 生效；存量问题跨 change 豁免必须经 exempt_issue_ids 申请 → 报源 reviewer 裁定 dismissed 的流程"
           - "禁止以压制手段静默规避确定性质量工具问题：压制必须附明确理由并经豁免申请流程裁定，不得以工具不再报错为由跳过申报"
-          - "禁止为腾出端口或资源而停止、复用或干扰非本变更启动的进程（含用户或其他会话运行的服务实例）；验证一律走隔离启动"
+          - "禁止为腾出端口或资源而停止、复用或干扰非本变更启动的进程（含用户或其他会话运行的服务实例）；验证所需环境（数据库、mock 服务、消息队列/缓存等中间件、扫描分析平台等）一律按隔离标识隔离启动，禁止共享或占用宿主既有实例"
   - name: review
     steps:
       - id: verify_tool
@@ -123,10 +125,10 @@ phases:
           on_pass: verify_quality
           on_fail: implement
         instructions:
-          - "逐项验证：①task 产出完整性 ②启动服务并检查健康 ③独立执行全量 API 测试并审查质量（含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值） ④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷"
+          - "逐项验证：①task 产出完整性 ②启动服务并检查健康 ③独立执行全量 API 测试并审查质量（含 API 测试自闭环链路：创建后可检索、状态变更后可见、删除后不可见；测试数据贴近业务语义，禁止无意义占位值） ④审查测试代码质量（断言放水/Mock 过度/覆盖不足）⑤业务行为真实性：对照 spec 逐项核验每个业务行为的实现与断言证据（含一并操作的行为组、连带效果、下游消费），识别『仅打状态标记未实际生效』类缺陷 ⑥关键数据产出核验：对照 spec 数据产出要求，核验实现与测试是否覆盖产出数据落位（spec 指定承载位置）、完整非空、搬迁承接与同一输入基线一致，识别『流程正常但数据缺失/落错位置』类缺陷"
           - "验证完成后（含 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 合约"
+          - "本次变更仅含测试代码（判定：视图「变更范围」文件清单全部命中已加载技术栈 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 合约"
           - "有 task 未通过时必须 verdict=failed 并经 failed_tasks 上报（task_id + reason）；passed 时不允许提供 failed_tasks"
           - "当发现修复需要调整 openspec/changes/ 下文档时，所报 issue 的 file 字段必须指向目标文档"
           - "报 issue 时必须显式声明归因维度 dimension（style/architecture/performance/security/maintainability）：本 reviewer 不归属任一质量维度，dimension 即该 issue 归属的目标质量维度"
@@ -173,7 +175,7 @@ phases:
           on_fail: verify_cleanup
         instructions:
           - "将基准分支（{{base_branch}}）最新代码合并进当前工作分支（git merge 基准分支），解决合并冲突；修复范围仅限合并冲突涉及文件与回归失败定位文件（改动仅用于解决合并引入的问题，可超出现有执行边界，禁止借机扩大范围）"
-          - "合并后回归复验：按已加载的开发实践规范执行构建验证；按已加载的接口测试规范启动服务并执行接口测试；全部通过才算通过，不分失败来源（含基准分支新代码引入的失败）"
+          - "合并后回归复验：按已加载的开发实践规范执行构建验证；按已加载的接口测试规范启动服务并执行接口测试（含关键数据产出/搬迁回归断言）；全部通过才算通过，不分失败来源（含基准分支新代码引入的失败）"
           - "按已加载的清理规范执行幂等清理：停止残留的服务实例、清理本 change 的隔离环境、删除残留的扫描分析项目；无对应 skill 规范时跳过并在申报中注明"
           - "清理后确认工作分支 git status 干净（含未跟踪文件）"
           - "逐项申报 validation_steps（completed + 证据；未执行项以 completed=false + 结构化 skip_reason 申报：{\"item\":\"<必做项>\",\"category\":\"<降级类别>\",\"adjudication\":\"user_response|unattended_auto|env_unavailable\",\"note\":\"<说明>\"}）"

package/dsh/cordis.patch.yml

@@ -53,7 +53,7 @@
 
           提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
 
-          自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。
+          自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。隔离对象不限于数据库（mock 服务、消息队列/缓存等中间件、扫描分析平台均按隔离标识隔离）。
 
           任务执行与提交约束（Task/Issue 清单处理、环境问题处置、blocker 提交、文档读取范围、工具调用边界）以 opx_status 操作指引与约束区块为准，此处不重复描述。
 
@@ -98,7 +98,7 @@
           - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
           - 方案复用与平行实现：按 skill 中的方案复用与平行实现约定——同类能力已有既有实现时（如已有手工限流基础框架仍引入新限流框架且不改动原实现）须优先复用或扩展，确需平行引入（新旧并存）时按上文需用户拍板问题的确认机制确认并存期与技术债，无人值守缺省裁决为方案必须包含原技术实现的迁移方案
           - 技术债识别：按 skill 中的技术债识别约定——方案是否引入可识别技术债（过时技术选型、技术迁移中断、平行引入、临时方案固化、契约不一致），引入的债务须在方案中规划偿还或说明可接受理由
-          - 架构演进审查：按 skill 中的架构演进审查约定——方案是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口/数据/行为兼容性）、重构方案是否贴合项目历史逻辑并保持既有行为语义；破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排
+          - 架构演进审查：按 skill 中的架构演进审查约定——方案是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口/数据/行为兼容性）、重构方案是否贴合项目历史逻辑并保持既有行为语义；破坏兼容或偏离架构脉络须在方案中说明理由与过渡安排；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
 
           ## 执行边界产出（架构师身份）
 
@@ -185,8 +185,8 @@
           | 级别 | task 产出验证 | 服务启动验证 | 测试审查 |
           |------|-------------|-------------|---------|
           | Critical | 核心 task 产出文件缺失 | 服务无法启动（无论是否本次变更引起） | 测试依赖无隔离环境导致 CI 必然失败 |
-          | High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为 |
-          | Medium | task 产出存在但质量不达标 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试 |
+          | High | 关键 task 产出不完整；行为无实现（仅状态标记未实际生效）；流程执行正常但关键数据产出缺失/未落库/落错位置（区别于『仅打状态标记未实际生效』：本行=流程与响应正常，产出物缺失或落错位） | 健康检查不通过；关键外部依赖不可用；新增接口无法调通（不论原因） | 核心业务逻辑无测试覆盖；Mock 了被测对象本身；测试仅断言可见状态/响应而 spec 要求的一并操作行为（入队/落库/下游消费等）无断言，将缺陷固化为期望行为；测试仅验证流程跑通/响应成功，未对 spec 要求的关键数据产出（落位/完整性）断言 |
+          | Medium | task 产出存在但质量不达标；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 | 启动有 WARN 但服务可用 | 断言过于宽松；缺少边界值测试；关键数据产出部分缺失、值不完整或与 spec 指定承载位置不一致 |
           | Low | 产出文件位置不符合约定 | 启动日志格式不统一 | 测试命名不规范但不影响运行 |
           | Info | 建议补充额外产出物 | 建议增加启动度量指标 | 建议补充边缘用例 |
 
@@ -267,7 +267,7 @@
           - 命名合理性：按 skill 中的通用语言与命名规范——命名体现意图、不与其他场景混淆、与术语表一致防漂移
           - 方案复用与平行实现：识别引入与既有实现功能重叠的平行实现（另起一套逻辑）的情况——同类能力已有既有实现仍另建实现且不改动原实现、无迁移方案则报 issue。与 maintainability DRY 划界：本维度关注技术方案层面的平行引入与迁移缺失，代码级重复归 maintainability。具体复用与迁移要求按 skill 约定
           - 技术债识别：按 skill 中的技术债识别约定——识别实现中的存量与新增技术债（过时技术选型、迁移中断残留、平行实现、临时方案固化、契约不一致），按统一严重级别报 issue
-          - 架构演进审查：按 skill 中的架构演进审查约定——实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义，破坏兼容或改变既有语义按统一严重级别报 issue
+          - 架构演进审查：按 skill 中的架构演进审查约定——实现是否延续项目整体架构方向、是否支持长期迭代演进、是否破坏既有契约（接口签名/数据格式/行为语义兼容性）、重构是否贴合项目历史逻辑并保持既有行为语义，破坏兼容或改变既有语义按统一严重级别报 issue；涉及字段/实体承载位置搬迁时，方案须明确数据承接与迁移设计：新承载位置、产出字段写入目标、存量数据迁移、旧位置兼容与清理；缺失按既有契约破坏/重构贴合判例报 issue
 
           ### 可维护性维度
 
@@ -316,7 +316,7 @@
           ## 职责边界（确定性检查与任务验证）
 
           - **确定性工具检查**：工具维度审查者与 simple 合并审查者被允许运行确定性工具检查（代码格式/架构约束/静态分析/单元测试编译/深度扫描），按已加载质量门 skill 的必做清单执行并将输出映射为统一 issue 结构；检查结果纳入审查结论
-          - **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留
+          - **任务验证**：任务维度审查者与 simple 合并审查者承担任务验证职责，验证 task 产出完整性、服务健康与 API 测试质量；未通过的 task 经 failed_tasks 上报；验证完成后按清理规范做幂等清理，不留环境残留；数据产出核验——对照 spec 数据产出要求核验关键数据产出落位/完整性/搬迁承接/基线对比，识别『流程正常但数据缺失/落错位置』类缺陷
           - **工具改进**：可工具化的质量 pattern 双报业务 issue 与工具改进 issue（规则草案由审查者提供），实施工作由开发者完成，审查者不直接改动规则/配置文件以外的实现
 
           ## 压制判定

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ifrankwang/openspec-agents",
-  "version": "0.125.0",
+  "version": "0.126.0",
   "type": "module",
   "main": "./src/core/index.ts",
   "exports": {