@ifrankwang/openspec-agents 0.142.0 → 0.143.0

package/.mcp-server/cli.mjs

@@ -30459,7 +30459,7 @@ async function ensureDefaultUnattended(args, ctx) {
     }
   } catch {}
 }
-var PKG_VERSION = "0.142.0";
+var PKG_VERSION = "0.143.0";
 function buildMcpServer(worktree, opts = {}) {
   const mcp = new McpServer({ name: "openspec-agents", version: PKG_VERSION });
   for (const [name, spec] of Object.entries(TOOL_SPECS)) {
@@ -30503,20 +30503,17 @@ var defineWebSocketHelper = (handler) => {
     if (typeof args[0] === "function") {
       const [createEvents, options] = args;
       return async function upgradeWebSocket(c, next) {
-        const events = await createEvents(c);
-        const result = await handler(c, events, options);
-        if (result) {
+        const result = await handler(c, await createEvents(c), options);
+        if (result)
           return result;
-        }
         await next();
       };
     } else {
       const [c, events, options] = args;
       return (async () => {
         const upgraded = await handler(c, events, options);
-        if (!upgraded) {
+        if (!upgraded)
           throw new Error("Failed to upgrade WebSocket");
-        }
         return upgraded;
       })();
     }
@@ -31910,6 +31907,50 @@ function isJsonContentType(header) {
   return mediaTypeEssence(header) === "application/json";
 }
 
+// node_modules/@modelcontextprotocol/sdk/dist/esm/server/requestBody.js
+var DEFAULT_MAX_REQUEST_BODY_SIZE = 4 * 1024 * 1024;
+var MAX_BATCH_SIZE = 100;
+function requestBodyTooLargeMessage(maxBytes) {
+  return `Payload Too Large: Request body must not exceed ${maxBytes} bytes`;
+}
+function resolveMaxRequestBodySize(value) {
+  if (value === undefined) {
+    return DEFAULT_MAX_REQUEST_BODY_SIZE;
+  }
+  if (typeof value !== "number" || !Number.isFinite(value) || value <= 0) {
+    throw new RangeError(`maxRequestBodySize must be a positive number of bytes, got ${String(value)}`);
+  }
+  return value;
+}
+async function readRequestBody(request, maxBytes = DEFAULT_MAX_REQUEST_BODY_SIZE) {
+  if (Number(request.headers.get("content-length")) > maxBytes) {
+    return { tooLarge: true };
+  }
+  if (request.body === null) {
+    return { tooLarge: false, text: "" };
+  }
+  const reader = request.body.getReader();
+  const decoder = new TextDecoder;
+  let received = 0;
+  let text = "";
+  try {
+    for (;; ) {
+      const { done, value } = await reader.read();
+      if (done) {
+        break;
+      }
+      received += value.byteLength;
+      if (received > maxBytes) {
+        return { tooLarge: true };
+      }
+      text += decoder.decode(value, { stream: true });
+    }
+  } finally {
+    reader.releaseLock();
+  }
+  return { tooLarge: false, text: text + decoder.decode() };
+}
+
 // node_modules/@modelcontextprotocol/sdk/dist/esm/server/sseKeepAlive.js
 var DEFAULT_SSE_KEEP_ALIVE_MS = 15000;
 var MAX_TIMER_DELAY_MS = 2 ** 31 - 1;
@@ -31945,6 +31986,7 @@ class WebStandardStreamableHTTPServerTransport {
     this._enableDnsRebindingProtection = options.enableDnsRebindingProtection ?? false;
     this._retryInterval = options.retryInterval;
     this._keepAliveMs = options.keepAliveMs ?? DEFAULT_SSE_KEEP_ALIVE_MS;
+    this._maxRequestBodySize = resolveMaxRequestBodySize(options.maxRequestBodySize);
   }
   startKeepAlive(controller, encoder) {
     if (this._closed)
@@ -32261,12 +32303,22 @@ data:
         rawMessage = options.parsedBody;
       } else {
         try {
-          rawMessage = await req.json();
+          const body = await readRequestBody(req, this._maxRequestBodySize);
+          if (body.tooLarge) {
+            const message = requestBodyTooLargeMessage(this._maxRequestBodySize);
+            this.onerror?.(new Error(message));
+            return this.createJsonErrorResponse(413, -32000, message);
+          }
+          rawMessage = JSON.parse(body.text);
         } catch {
           this.onerror?.(new Error("Parse error: Invalid JSON"));
           return this.createJsonErrorResponse(400, -32700, "Parse error: Invalid JSON");
         }
       }
+      if (Array.isArray(rawMessage) && rawMessage.length > MAX_BATCH_SIZE) {
+        this.onerror?.(new Error(`Invalid Request: Batch must not exceed ${MAX_BATCH_SIZE} messages`));
+        return this.createJsonErrorResponse(400, -32600, `Invalid Request: Batch must not exceed ${MAX_BATCH_SIZE} messages`);
+      }
       let messages;
       try {
         if (Array.isArray(rawMessage)) {

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

@@ -15,7 +15,7 @@ rules:
     - "关联场景清点（强制）：proposal 动笔前必须完成「关联场景清点」并以代码检索为证据记入 clarify.md 的「关联场景清点（Related-Surface Survey）」小节：枚举本变更触及能力的全部消费方与关联面——功能入口（API 端点、导入/导出入口、定时任务、消息消费、前端调用等）、共享处理逻辑（被多个入口复用的处理链路）、数据模型与数据流下游（表/字段/事件/导出产物的读写双方），每条附代码位置证据（文件/类/方法）。凡共享处理逻辑发生变更，其全部消费入口必须在同一 change 内统一适配，禁止按入口分别提 change 导致共享逻辑两边割裂维护；确需拆分时必须在 proposal.md 单列「拆分边界」小节论证（每个 change 覆盖哪些入口、共享逻辑变更归属哪个 change、入口间契约），并经用户确认。proposal.md 必须单列「关联场景（Related Surface）」小节逐条列出清点结论与划界结论；泛写「无关联影响」而不附检索证据视为 proposal 未完成。"
     - "契约变更详列（强制）：凡变更涉及 DDL（建表/加列/索引/约束）或接口契约（新增/修改端点、请求响应结构、错误码），proposal.md 必须单列「契约变更点」小节逐条列出——DDL 逐表逐列给全表名、列名、类型、可空性、默认值与用途；API 逐端点给全方法+路径、请求/响应结构变化、新增/修改标记与兼容性影响。泛写「有契约变更」不逐条展开视为 proposal 未完成。"
     - "动笔前访谈门（强制）：proposal/specs/design/tasks 任一文档动笔前，必须已按 spec-driven-standard schema clarify 指令的决策树访谈方法论完成对用户的访谈——把方案建模为决策树逐轮穷尽疑点：每轮将前提已落定、当前可回答的问题一次性编号抛出并逐题附推荐答案，用户答复后重算下一轮前沿，直到决策树所有分支走完、无未决疑点、无静默假设、关联场景清点每个条目均经用户划界确认（纳入/排除+理由）；访谈问答全程记入 clarify.md（Open Questions / User Answers / 关联场景清点）。事实类问题必须自行查代码与 spec 求证，不抛给用户；疑点未穷尽时禁止写任何文档，不得以「需求简单」等理由跳过。访谈未穷尽（含关联场景清点尚有未经用户划界确认的条目）时同样禁止呈现方案或方案摘要请求确认——轮次中每题附的推荐答案不视为方案，不得把方案确认合并进任何一轮提问；用户中途索要方案时说明访谈未完并继续提问，不得提前收口。"
-    - "实施逻辑与方案摘要结构（强制）：proposal.md 必须单列「实施逻辑（Implementation Outline）」小节，按步骤用业务语言（人话）讲清具体怎么做——数据从哪来、经过什么校验与处理、落到哪、关联场景小节划入的每条链路怎么适配；禁止出现类名/方法名/内部函数名等代码级名词（用户明确要求技术深度时除外；契约变更点小节的表名/列名/端点路径等契约事实不受此限、保持精确）。方案摘要必须按 spec-driven-standard schema clarify 指令 Plan confirmation gate 的要素清单结构化逐项展开（含人话分步实施逻辑与关联链路划界结论），两三句话的摘要视为未完成。"
+    - "实施逻辑与方案摘要结构（强制）：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）并停下等待用户直接文字回复，禁止通过提问工具发起确认，提问工具的选项点击不视为确认；未记录时禁止写任何文档——主代理亲自写时先停下向用户补确认，生成子代理则立即终止并向编排方报告，不得以「需求简单」等理由跳过或代用户确认。"
   specs:
     - "数据行为需求（如\"系统 SHALL 持久化 X 含审计字段\"）放 spec；物理 DDL 放 design.md。"

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

@@ -8,9 +8,10 @@
    change 统一适配或排除附理由；同一数据存在多条落库路径时各路径校验与
    处理逻辑的一致性为必问分支；共享处理逻辑变更须与其全部消费入口同一
    change 统一适配）；访谈穷尽后、写任何文档之前，主代理必须先向用户汇报
-   结构化方案摘要（按要素清单逐项编号展开：一句话做什么 + 是否动契约 +
-   选定方案与备选取舍 + 人话分步实施逻辑 + 关联链路划界结论 + 影响的能力
-   面）并取得用户明确确认（HARD-GATE：摘要须以普通消息呈现，禁止用提问
+   结构化方案摘要（按要素清单逐项编号展开：一句话做什么 + 变更内容人话
+   逐条列明（形如「导出功能新增「状态」字段」，视需要说明字段来源等
+   背景）+ 是否动契约 + 选定方案与备选取舍 + 人话分步实施逻辑 +
+   关联链路划界结论 + 影响的能力面）并取得用户明确确认（HARD-GATE：摘要须以普通消息呈现，禁止用提问
    工具发起确认，访谈中的问答不视为确认；访谈未穷尽禁止呈现方案求确认，
    轮次中每题附的推荐答案不视为方案），确认记录落在 clarify.md，后续文档
    不得偏离。proposal.md 单列「实施逻辑」小节，以人话分步讲清怎么做（禁

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

@@ -165,7 +165,14 @@ artifacts:
         number each element below and give it real substance — a
         two-or-three-sentence blob is an invalid summary, expand it before
         presenting. The elements:
-        1. what the change does, in one sentence;
+        1. what the change does, in one sentence, THEN the change
+           contents itemized one item per line in plain business
+           language: each item is a natural-language sentence of the
+           form 「导出功能新增「状态」字段」, expanded as far as it helps
+           the user judge the change (e.g. where the new field comes
+           from, what it gives the user) rather than a bare label. No
+           code-level identifiers — same language rule as element 4
+           below;
         2. whether it touches contracts (API parameters or DDL);
         3. the chosen approach and its key trade-offs versus the
            alternatives;
@@ -204,8 +211,9 @@ artifacts:
         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
-        plain-language implementation outline and the related-surface
-        verdicts), presented as a plain message only after the interview
+        itemized plain-language change list, the plain-language
+        implementation outline and the related-surface verdicts),
+        presented as a plain message only after the interview
         was exhausted. This is the HARD-GATE output.
       - **Initial Capabilities**: preliminary guess of which specs will be touched
         (kebab-case). Finalized in proposal.md.

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

@@ -37,7 +37,8 @@
      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
-     the plain-language implementation outline and the related-surface verdicts —
+     the itemized plain-language change list, the plain-language
+     implementation outline and the related-surface 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/dsh/cordis.patch.yml

@@ -25,6 +25,47 @@
         includeDefaultRoots: false
         customSkillDirs:
           - !!js "process.getBuiltinModule('node:url').fileURLToPath(new URL('./node_modules/@ifrankwang/openspec-agents/assets/skills', baseUrl))"
+    - id: openspec-subagent-developer
+      name: '@deepseek-ai/dsh-tool-subagent'
+      config:
+        provider: spawn
+        toolName: openspec_developer
+        persona: |-
+          ## DSH 工具接入（必读）
+
+          - 本流程的 opx_* 工具在 DSH 中以 `mcp__opx__*` 形式出现，子代理通常只需要：
+            - `mcp__opx__status`
+            - `mcp__opx__agent_submit`
+          - 如果当前工具列表中没有这些工具，请立即调用 `dev_tool_search` 搜索 `opx`，或一次性解锁：
+            ```json
+            {"toolNames": ["mcp__opx__status", "mcp__opx__agent_submit"]}
+            ```
+            如果计划使用 `todo_write` 跟踪任务，也请在同一轮一并解锁。
+          - 严禁使用 `find` / `which` / `grep` 等 shell 命令搜索 `opx`、`openspec`、MCP 配置或安装路径；工具未出现是因为尚未解锁，不是未安装。
+          - 解锁后第一件事是调用 `mcp__opx__status` 获取上下文，不要先探查仓库或读取状态文件。
+
+
+          OpenSpec 编排流程专用 — 开发者（物理 agent，承载开发者逻辑身份）。遵循 TDD 开发新功能，使用 5-Why 分析修复 Bug。仅在 openspec-agents 工作流内由编排者分派使用，不用于通用开发任务。
+
+          ## 角色（开发者身份）
+
+          你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门与接口测试的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
+
+          提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
+
+          自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。隔离对象不限于数据库（mock 服务、消息队列/缓存等中间件、扫描分析平台均按隔离标识隔离）。
+
+          任务执行与提交约束（Task/Issue 清单处理、环境问题处置、blocker 提交、文档读取范围、工具调用边界）以 opx_status 操作指引与约束区块为准，此处不重复描述。
+
+          修复的 issue 进入待复核，终态由提出者（对应 reviewer）裁定；被驳回后按修复未过次数门槛处理。
+
+          收尾阶段承担基准分支同步、合并冲突解决、回归复验与隔离环境清理职责；收尾验证中自报 issue 由自己复核收敛（区别于「修复的 issue 进入待复核，终态由提出者裁定」的常规路径）。
+
+          ## 压制处理（开发者身份）
+
+          确定性质量工具检查出的问题若以压制手段解决（压制注解、注释抑制、规则排除配置、平台状态标注、构建跳过开关等），属豁免申请范畴：必须在压制处代码注释说明清楚理由（commit message 可补充），交由报源审查者判定合理性；不得以压制手段冒充修复。豁免被驳回后，须移除压制并真实修复。
+        enableRunInBackground: false
+        backgroundMode: one-shot
     - id: openspec-subagent-reviewer
       name: '@deepseek-ai/dsh-tool-subagent'
       config:
@@ -241,45 +282,4 @@
           确定性质量工具检查出的问题若以压制手段解决（压制注解、注释抑制、规则排除配置、平台状态标注、构建跳过开关等），一律视为豁免申请，须判定其合理性：可接受情形（无法消除的框架/第三方限制、有证据的误报，且风险可控、理由充分）→ 认可豁免；不可接受情形（真实缺陷被压制规避、仅图省事、无理由或理由不成立）→ 不认可，须要求移除压制并真实修复。判定时核验压制处的理由（代码注释、commit message）；不认可时须给出可见的判定理由（写入问题描述/建议或驳回说明）。此判定适用于承担工具检查的审查身份（工具审查者、simple 合并审查者）。
         enableRunInBackground: false
         backgroundMode: one-shot
-    - id: openspec-subagent-developer
-      name: '@deepseek-ai/dsh-tool-subagent'
-      config:
-        provider: spawn
-        toolName: openspec_developer
-        persona: |-
-          ## DSH 工具接入（必读）
-
-          - 本流程的 opx_* 工具在 DSH 中以 `mcp__opx__*` 形式出现，子代理通常只需要：
-            - `mcp__opx__status`
-            - `mcp__opx__agent_submit`
-          - 如果当前工具列表中没有这些工具，请立即调用 `dev_tool_search` 搜索 `opx`，或一次性解锁：
-            ```json
-            {"toolNames": ["mcp__opx__status", "mcp__opx__agent_submit"]}
-            ```
-            如果计划使用 `todo_write` 跟踪任务，也请在同一轮一并解锁。
-          - 严禁使用 `find` / `which` / `grep` 等 shell 命令搜索 `opx`、`openspec`、MCP 配置或安装路径；工具未出现是因为尚未解锁，不是未安装。
-          - 解锁后第一件事是调用 `mcp__opx__status` 获取上下文，不要先探查仓库或读取状态文件。
-
-
-          OpenSpec 编排流程专用 — 开发者（物理 agent，承载开发者逻辑身份）。遵循 TDD 开发新功能，使用 5-Why 分析修复 Bug。仅在 openspec-agents 工作流内由编排者分派使用，不用于通用开发任务。
-
-          ## 角色（开发者身份）
-
-          你是后端开发工程师，专注于实现 OpenSpec 任务组中的代码开发任务，同时是质量门与接口测试的执行责任人：确定性检查与接口测试由你执行并经自检申报留痕，自检申报是 reviewer 分级复验的事实输入。
-
-          提交前按已加载 skill（含质量维度规范类）完成自检，审查兜底与终局裁定仍由对应 reviewer 承担（自检不替代 reviewer 裁定）。
-
-          自证/验证启动的服务与基础设施一律隔离启动、用后即停，自证完成即清理，不留残留。隔离对象不限于数据库（mock 服务、消息队列/缓存等中间件、扫描分析平台均按隔离标识隔离）。
-
-          任务执行与提交约束（Task/Issue 清单处理、环境问题处置、blocker 提交、文档读取范围、工具调用边界）以 opx_status 操作指引与约束区块为准，此处不重复描述。
-
-          修复的 issue 进入待复核，终态由提出者（对应 reviewer）裁定；被驳回后按修复未过次数门槛处理。
-
-          收尾阶段承担基准分支同步、合并冲突解决、回归复验与隔离环境清理职责；收尾验证中自报 issue 由自己复核收敛（区别于「修复的 issue 进入待复核，终态由提出者裁定」的常规路径）。
-
-          ## 压制处理（开发者身份）
-
-          确定性质量工具检查出的问题若以压制手段解决（压制注解、注释抑制、规则排除配置、平台状态标注、构建跳过开关等），属豁免申请范畴：必须在压制处代码注释说明清楚理由（commit message 可补充），交由报源审查者判定合理性；不得以压制手段冒充修复。豁免被驳回后，须移除压制并真实修复。
-        enableRunInBackground: false
-        backgroundMode: one-shot
 

package/package.json

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