@ifrankwang/openspec-agents 0.147.1 → 0.148.0

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

@@ -8213,18 +8213,24 @@ async function agentSubmitExecute(params, ctx) {
       throw new Error(`worktree 未就绪，当前拒绝提交。
 请编排者先调用 opx_orch_set_worktree 确保 worktree 就绪后再提交。`);
     }
-    if (params.fixed_issue_ids)
-      params.fixed_issue_ids = params.fixed_issue_ids.map(normalizeIssueId);
-    if (params.exempt_issue_ids)
-      params.exempt_issue_ids = params.exempt_issue_ids.map(normalizeIssueId);
-    if (params.exempt_adjudications) {
-      for (const adj of params.exempt_adjudications)
-        adj.issue_id = normalizeIssueId(adj.issue_id);
-    }
-    if (params.recheck_adjudications) {
-      for (const adj of params.recheck_adjudications)
-        adj.issue_id = normalizeIssueId(adj.issue_id);
-    }
+    const normalized = { ...params };
+    if (normalized.fixed_issue_ids)
+      normalized.fixed_issue_ids = normalized.fixed_issue_ids.map(normalizeIssueId);
+    if (normalized.exempt_issue_ids)
+      normalized.exempt_issue_ids = normalized.exempt_issue_ids.map(normalizeIssueId);
+    if (normalized.exempt_adjudications) {
+      normalized.exempt_adjudications = normalized.exempt_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id)
+      }));
+    }
+    if (normalized.recheck_adjudications) {
+      normalized.recheck_adjudications = normalized.recheck_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id)
+      }));
+    }
+    params = normalized;
     const knownChildIds = new Set;
     for (const c of item.children) {
       knownChildIds.add(c.id);
@@ -8984,7 +8990,7 @@ function buildNativeToolExecutes(unattended, processCwd) {
   const wrap = (execute) => async (args, exec) => {
     exec.signal?.throwIfAborted?.();
     const ctx = resolveToolContext(exec, args, { processCwd });
-    const cleanArgs = { ...args };
+    const cleanArgs = structuredClone(args);
     delete cleanArgs[AGENT_ARG];
     if (unattended)
       await ensureDefaultUnattended(cleanArgs, ctx);

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
@@ -29810,18 +29810,24 @@ async function agentSubmitExecute(params, ctx) {
       throw new Error(`worktree 未就绪，当前拒绝提交。
 请编排者先调用 opx_orch_set_worktree 确保 worktree 就绪后再提交。`);
     }
-    if (params.fixed_issue_ids)
-      params.fixed_issue_ids = params.fixed_issue_ids.map(normalizeIssueId);
-    if (params.exempt_issue_ids)
-      params.exempt_issue_ids = params.exempt_issue_ids.map(normalizeIssueId);
-    if (params.exempt_adjudications) {
-      for (const adj of params.exempt_adjudications)
-        adj.issue_id = normalizeIssueId(adj.issue_id);
+    const normalized = { ...params };
+    if (normalized.fixed_issue_ids)
+      normalized.fixed_issue_ids = normalized.fixed_issue_ids.map(normalizeIssueId);
+    if (normalized.exempt_issue_ids)
+      normalized.exempt_issue_ids = normalized.exempt_issue_ids.map(normalizeIssueId);
+    if (normalized.exempt_adjudications) {
+      normalized.exempt_adjudications = normalized.exempt_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id)
+      }));
     }
-    if (params.recheck_adjudications) {
-      for (const adj of params.recheck_adjudications)
-        adj.issue_id = normalizeIssueId(adj.issue_id);
+    if (normalized.recheck_adjudications) {
+      normalized.recheck_adjudications = normalized.recheck_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id)
+      }));
     }
+    params = normalized;
     const knownChildIds = new Set;
     for (const c of item.children) {
       knownChildIds.add(c.id);
@@ -30569,7 +30575,7 @@ async function ensureDefaultUnattended(args, ctx) {
     }
   } catch {}
 }
-var PKG_VERSION = "0.147.1";
+var PKG_VERSION = "0.148.0";
 function buildMcpServer(worktree, opts = {}) {
   const mcp = new McpServer({ name: "openspec-agents", version: PKG_VERSION });
   for (const [name, spec] of Object.entries(TOOL_SPECS)) {
@@ -31561,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

@@ -151,6 +151,7 @@ OpenSpec 官方默认的流程是 `proposal → specs → design → tasks`，
 | 需求澄清 | 澄清不强制，靠 explore 用法自行把握 | 决策树逐轮提问，每题附推荐答案；事实类疑问自己查代码，不抛给你 |
 | 动笔门禁 | 无 | 疑点问完 + 你确认方案，才允许开始写文档；确认必须文字回复，点选项不算 |
 | 改动范围 | proposal 里一句 Impact 描述 | 关联场景清点：把用到这块逻辑的入口、复用链路、数据上下游全列出来，每条附代码位置，逐条跟你确认纳入还是排除；共用逻辑的所有入口必须同一变更里一起改 |
+| 规则边界推演 | 无 | 新增或改动规则、校验、拦截逻辑时，先推演这条规则本身站不站得住：该拦的条件与例外、功能上合法却会被误伤的合法反例（各对应 spec 一条「应当放行」场景）、同一业务意图的等价执行路径与判定挂载点（挂在业务意图层的动作上，不落在被别的流程复用的底层动作上）；变更新增或改了执行路径时，逐条核对既有规则在新路径上是否仍该生效 |
 | 契约变更 | 无专门要求 | 逐条列：建表到列（名/类型/可空/默认值/用途）、接口到字段与方法路径、兼容性影响 |
 | 文档语言 | 要求 spec 避免类名、函数名 | 方案摘要与实施逻辑也必须用人话，禁止类名、方法名这类代码黑话（契约事实与技术设计文档除外） |
 | 任务划分 | 分组 + 每条带验证方式 | 追加：每组必须有真实代码改动（禁止「收尾组」凑数）、测试跟着实现同组、只覆盖本仓库 |

package/assets/agents/openspec-reviewer.md

@@ -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
 
 ### 可维护性维度
 

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/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），不以假设替代确认"

package/dsh/cordis.patch.yml

@@ -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
 
           ### 可维护性维度
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ifrankwang/openspec-agents",
-  "version": "0.147.1",
+  "version": "0.148.0",
   "description": "OpenSpec change orchestration plugin for AI coding agents (Claude Code, Codex, ZCode, DeepSeek Harness, OpenCode)",
   "author": "ifrankwang",
   "license": "MIT",

package/src/adapters/deepseek-harness/native-tools.ts

@@ -132,7 +132,8 @@ export function buildNativeToolExecutes(
       exec.signal?.throwIfAborted?.()
       const ctx = resolveToolContext(exec, args, { processCwd })
       // 私有身份参数不进入内核参数（内核校验的是纯业务 schema）。
-      const cleanArgs: Record<string, unknown> = { ...args }
+      // DSH 会把入参整份深冻结后原样交给 execute，这里必须交出可写副本（浅拷贝只保护顶层，嵌套仍只读）。
+      const cleanArgs: Record<string, unknown> = structuredClone(args)
       delete cleanArgs[AGENT_ARG]
       if (unattended) await ensureDefaultUnattended(cleanArgs, ctx)
       const result = await execute(cleanArgs, ctx)

package/src/core/tools/submit.ts

@@ -619,15 +619,25 @@ export async function agentSubmitExecute(params: AgentSubmitParams, ctx: ToolCon
       )
     }
 
-    // 参数归一化：issue id 去 # 前缀（fixed/exempt/adjudication/recheck 均接受带 # 的 tg.issue 序号引用）
-    if (params.fixed_issue_ids) params.fixed_issue_ids = params.fixed_issue_ids.map(normalizeIssueId)
-    if (params.exempt_issue_ids) params.exempt_issue_ids = params.exempt_issue_ids.map(normalizeIssueId)
-    if (params.exempt_adjudications) {
-      for (const adj of params.exempt_adjudications) adj.issue_id = normalizeIssueId(adj.issue_id)
+    // 参数归一化：issue id 去 # 前缀（fixed/exempt/adjudication/recheck 均接受带 # 的 tg.issue 序号引用）。
+    // 归一化结果必须回写到 params 绑定：其后的读取点全部依赖归一化后的值。宿主（DSH）可能把入参整份
+    // 冻结为只读，因此只能在可写副本上归一化，不能动传入对象（含嵌套元素）。
+    const normalized: AgentSubmitParams = { ...params }
+    if (normalized.fixed_issue_ids) normalized.fixed_issue_ids = normalized.fixed_issue_ids.map(normalizeIssueId)
+    if (normalized.exempt_issue_ids) normalized.exempt_issue_ids = normalized.exempt_issue_ids.map(normalizeIssueId)
+    if (normalized.exempt_adjudications) {
+      normalized.exempt_adjudications = normalized.exempt_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id),
+      }))
     }
-    if (params.recheck_adjudications) {
-      for (const adj of params.recheck_adjudications) adj.issue_id = normalizeIssueId(adj.issue_id)
+    if (normalized.recheck_adjudications) {
+      normalized.recheck_adjudications = normalized.recheck_adjudications.map((adj) => ({
+        ...adj,
+        issue_id: normalizeIssueId(adj.issue_id),
+      }))
     }
+    params = normalized
 
     // 无效 fixed/exempt id 入口显式拒绝（不静默吞掉修复/豁免声明）：未命中的 id 抛错并列出可用 id 清单。
     // 以 resolveChildByIssueId 做权威判定，与 submitForStep 的 childById 及 collectFixedExemptLayers 消费端解析语义一致。