@ifrankwang/openspec-agents 0.141.0 → 0.143.0

package/.mcp-server/cli.mjs

@@ -30459,7 +30459,7 @@ async function ensureDefaultUnattended(args, ctx) {
     }
   } catch {}
 }
-var PKG_VERSION = "0.141.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 统一适配）、契约变更详列、动笔前访谈门与用户确认门、任务组实质变更主体等。幂等：重跑即把标准升级到插件当前版本，项目自定义内容按下方合并策略保留。
+把本 skill 目录 `templates/` 下的标准文件安装到当前项目的 `openspec/` 目录，使该项目此后用 openspec 提 change 时自动遵循统一标准：关联场景清点（共享处理逻辑的变更须与其全部消费入口同一 change 统一适配，同一数据多条落库路径的校验一致性为访谈必问分支）、契约变更详列、实施逻辑人话分步（proposal 单列实施逻辑小节，禁代码级名词）、结构化方案摘要（访谈穷尽后才给出，一句话做什么、变更内容人话逐条列明并禁代码级名词，以普通消息确认）、动笔前访谈门与用户确认门、任务组实质变更主体等。幂等：重跑即把标准升级到插件当前版本，项目自定义内容按下方合并策略保留。
 
 ## 前置检查
 

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

@@ -14,7 +14,8 @@ rules:
   proposal:
     - "关联场景清点（强制）：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/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/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

@@ -3,12 +3,19 @@
 通用 spec-driven 工作流模板：clarify → proposal → specs → design → tasks，
 增强三点：
 1. **clarify 前置门槛 + 关联场景清点**：每次变更先做需求澄清与关联场景清点
-   （枚举变更触及能力的全部消费方——功能入口 / 共享处理逻辑 / 数据流下游，
-   附代码证据；共享处理逻辑变更须与其全部消费入口同一 change 统一适配）；
-   访谈结束后、写任何文档之前，主代理必须先向用户简单直接汇报方案（一句话
-   讲清做什么 + 是否动契约 + 取舍 + 影响面）并取得用户明确确认（HARD-GATE：
-   汇报须以普通消息直接列出要素点，禁止用提问工具发起确认，访谈中的问答
-   不视为确认），确认记录落在 clarify.md，后续文档不得偏离。
+   （首轮提问前枚举变更触及能力的全部消费方——功能入口 / 共享处理逻辑 /
+   数据流下游，附代码证据；每个清点条目在访谈中经用户划界确认——纳入本
+   change 统一适配或排除附理由；同一数据存在多条落库路径时各路径校验与
+   处理逻辑的一致性为必问分支；共享处理逻辑变更须与其全部消费入口同一
+   change 统一适配）；访谈穷尽后、写任何文档之前，主代理必须先向用户汇报
+   结构化方案摘要（按要素清单逐项编号展开：一句话做什么 + 变更内容人话
+   逐条列明（形如「导出功能新增「状态」字段」，视需要说明字段来源等
+   背景）+ 是否动契约 + 选定方案与备选取舍 + 人话分步实施逻辑 +
+   关联链路划界结论 + 影响的能力面）并取得用户明确确认（HARD-GATE：摘要须以普通消息呈现，禁止用提问
+   工具发起确认，访谈中的问答不视为确认；访谈未穷尽禁止呈现方案求确认，
+   轮次中每题附的推荐答案不视为方案），确认记录落在 clarify.md，后续文档
+   不得偏离。proposal.md 单列「实施逻辑」小节，以人话分步讲清怎么做（禁
+   代码级名词，契约事实除外），代码级细节归 design.md。
 2. **主代理访谈直录 + 分级撰写 + 独立复核循环**：主代理亲自访谈，问答
    直接记入 clarify.md（访谈阶段唯一落笔的文档，不设独立访谈文件）；
    架构方向经用户确认后，按复杂度分级产出其余文档（proposal → specs →
@@ -67,8 +74,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` | 项目特化约束 | 技术栈、分层架构、数据库约定、质量门工具、方法论 |
 
 同一规则只写一处：config.yaml rules 不重复 schema instruction 已有内容；

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

@@ -108,16 +108,27 @@ artifacts:
         branches into the decisions that hang off it):
         * Problem & intent: what problem is being solved? what is the success criteria?
         * Scope: what is in/out of bounds? is the change decomposable into sub-changes?
-        * Related-surface survey (关联场景清点): enumerate every consumer of the
+        * Related-surface survey (关联场景清点): complete the survey BEFORE the
+          first interview round and treat it as input to the decision tree, not
+          just a documentation step. Enumerate every consumer of the
           capability being changed, grounded in real code — functional entry points
           (API endpoints, import/export entries, scheduled jobs, message consumers,
           frontend calls), shared processing logic reused by multiple entry points,
           and downstream data consumers (readers/writers of the tables, fields,
           events, or export artifacts involved). Record each finding with code
           evidence (file/class/method) in clarify.md's Related-Surface Survey
-          section. When shared processing logic changes, every consuming entry
-          point must be adapted within the SAME change; splitting into separate
-          changes requires an explicit boundary rationale confirmed by the user.
+          section. Every surveyed surface becomes a decision-tree branch that
+          MUST be resolved IN the interview: for each, ask the user whether it
+          is adapted in this change or excluded with a reason, and record the
+          verdict. Consistency branches are mandatory: when the same data has
+          multiple persistence paths (e.g. import, save, and update all writing
+          the same table), whether and how their validation and processing
+          logic stay shared and consistent must be asked and decided by the
+          user — touching only the requested path while skipping the related
+          paths means the interview is NOT exhausted. When shared processing
+          logic changes, every consuming entry point must be adapted within
+          the SAME change; splitting into separate changes requires an
+          explicit boundary rationale confirmed by the user.
         * 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)?
@@ -125,22 +136,57 @@ artifacts:
         * Architecture direction: propose 2-3 approaches with tradeoffs and a recommendation.
       - Round mechanics: each round asks every question whose prerequisites
         are already settled (the whole frontier at once) via the question
-        tool, numbered, each with your recommended answer; then wait for
-        the user's answers before the next round. A question whose answer
+        tool, numbered, each with your recommended answer; then wait for the
+        user's answers before the next round. A question whose answer
         depends on one still open in this round belongs to a later round.
         Facts are yours to find (codebase, specs, tools) - never ask the
         user for anything you can look up yourself; the decisions are the
         user's. Rounds continue until the frontier is empty: every branch
-        visited, no doubt left unresolved, nothing silently assumed.
+        visited, no doubt left unresolved, nothing silently assumed, and
+        every related-surface survey entry carries a user-confirmed scoping
+        verdict.
+      - Sequencing prohibition: while the interview is still open (the
+        frontier is not empty, or any related-surface survey entry lacks a
+        user-confirmed verdict), do NOT present the plan or a plan summary
+        and ask the user to confirm it. The recommended answer attached to
+        each question is not the plan and must never be presented as one;
+        do not fold plan confirmation into any interview round. If the user
+        asks for the plan mid-interview, say the interview is not finished
+        yet, you may recap what has already been settled, and keep asking
+        until the frontier is empty — only then use the plan confirmation
+        gate.
       - Challenge assumptions (yours and the user's). Reframe the problem when needed.
       - Plan confirmation gate (HARD-GATE): once the interview rounds have
-        exhausted every open doubt (frontier empty) and before starting
+        exhausted every open doubt (frontier empty — see the sequencing
+        prohibition above) and before starting
         Phase 2 (authoring — whether by you or
-        by a generation subagent), present a simple, direct plan summary to
-        the user and stop for confirmation. The summary must state: what the
-        change does in one sentence; whether it touches contracts (API
-        parameters or DDL); the chosen approach and its key trade-offs
-        versus the alternatives; the capabilities affected. Present it as a
+        by a generation subagent), present a direct plan summary to
+        the user and stop for confirmation. The summary MUST be structured:
+        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, 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;
+        4. the implementation logic, step by step, in plain business
+           language (人话) — where the data comes from, what validation and
+           processing it goes through, where it lands, and how each related
+           path is adapted. Do NOT use code-level identifiers (class,
+           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;
+        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.
+        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
         confirmation) — and stop for the user's free-text reply. Interview
@@ -157,12 +203,18 @@ artifacts:
       - **User Answers**: the user's responses, captured verbatim or summarized.
       - **Related-Surface Survey**: the related-surface survey output (关联场景清点) —
         every consuming entry point / shared processing logic / downstream
-        consumer with code evidence, and the scoping verdict for each. Shared
+        consumer with code evidence, and the scoping verdict for each —
+        every verdict confirmed by the user during the interview. Shared
         processing logic changes must be covered together with all their
         consuming entry points in the same change.
       - **Architecture Direction**: the crystallized approach, key decisions,
         alternatives considered, and the confirmed plan summary with
-        the user's explicit confirmation. This is the HARD-GATE output.
+        the user's explicit confirmation — the summary structured per the
+        six elements of the plan confirmation gate (including the
+        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.
 
@@ -196,11 +248,23 @@ artifacts:
       - **Related Surface (关联场景)**: the survey conclusions from clarify.md —
         every consuming entry point / shared processing logic / downstream
         consumer with code evidence and its scoping verdict (adapted in this
-        change, or explicitly justified out). When shared processing logic
+        change, or explicitly justified out). The verdicts recorded here must
+        match the user-confirmed verdicts from the clarify.md interview.
+        When shared processing logic
         changes, every consuming entry point must be adapted in THIS change;
         splitting into separate changes requires a boundary rationale section
         confirmed by the user. A bare "no related impact" without search
         evidence counts as an incomplete proposal.
+      - **Implementation Outline (实施逻辑)**: how the change plays out, step by
+        step, in plain business language (人话) — where the data comes from,
+        what validation and processing it goes through, where it lands, and
+        how each related path scoped into this change (per the Related
+        Surface section above) is adapted. What Changes lists WHAT changes;
+        this section walks through HOW it plays out, as numbered steps. Same
+        language rule as the plan summary: no code-level identifiers (class,
+        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.
       - **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.
@@ -218,8 +282,10 @@ artifacts:
       behavior, so if behavior does not change, no spec should change either.
       Do not invent a requirement just to satisfy validation.
 
-      Keep it concise (1-2 pages). Focus on the "why" not the "how" -
-      implementation details belong in design.md. Stay consistent with
+      Keep it concise (1-2 pages). The proposal covers the why and the
+      plain-language how (the Implementation Outline); code-level details
+      (class/method structure, DDL design, technology-choice argumentation)
+      belong in design.md. Stay consistent with
       clarify.md's architecture direction; if the proposal drifts from clarify,
       update clarify first and get user confirmation.
 

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

@@ -22,7 +22,10 @@
      import/export entries, scheduled jobs, message consumers, frontend calls),
      shared processing logic reused by multiple entry points, and downstream
      data consumers (readers/writers of the tables, fields, events, or export
-     artifacts involved). When shared processing logic changes, every consuming
+     artifacts involved). Every entry carries a scoping verdict (adapted in
+     this change, or excluded with a reason) confirmed by the user during the
+     interview — the frontier is not empty until every entry has one. When
+     shared processing logic changes, every consuming
      entry point must be adapted in the SAME change; splitting into separate
      changes requires an explicit boundary rationale confirmed by the user. -->
 
@@ -32,8 +35,14 @@
 
 <!-- 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 a
-     plain message listing the key points — never a question-tool prompt). This is
+     (interview answers alone do not count as confirmation; the summary must be
+     structured per the six elements of the plan confirmation gate — including
+     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
+     answer attached to a question is not the plan). This is
      the HARD-GATE output — proposal, specs, design, and tasks must stay consistent
      with what is recorded here. -->
 

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

@@ -11,10 +11,20 @@
 <!-- 关联场景：survey conclusions from clarify.md — each entry point / shared
      processing logic / downstream consumer with code evidence and its scoping
      verdict (adapted in this change, or explicitly justified out with a boundary
-     rationale confirmed by the user). Shared processing logic changes must cover
-     all consuming entry points in this change. A bare "no related impact"
+     rationale confirmed by the user). Verdicts must match the user-confirmed
+     verdicts from the clarify.md interview. Shared processing logic changes must
+     cover all consuming entry points in this change. A bare "no related impact"
      without search evidence counts as an incomplete proposal. -->
 
+## Implementation Outline
+
+<!-- 实施逻辑：how the change plays out, step by step, in plain business
+     language (人话) — where the data comes from, what validation and processing
+     it goes through, where it lands, and how each related path scoped in above
+     is adapted. Numbered steps. No code-level identifiers (class/method/function
+     names) unless the user explicitly asked for technical depth; contract facts
+     (table/column/endpoint names) are exempt and stay precise. -->
+
 ## Capabilities
 
 ### New Capabilities

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.141.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",