@ifrankwang/openspec-agents 0.133.1 → 0.133.2

package/assets/skills/orchestrator/SKILL.md

@@ -29,6 +29,7 @@ capabilities: ["orchestrator"]
   2. 若未初始化，调用初始化工具（如 `mcp__opx__orch_init`）传入 `change_id` / `task_group_id`；
   3. 若 worktree 未就绪，调用 `mcp__opx__orch_set_worktree`（或列表中对应工具）；
   4. 再次调用状态查询工具获取权威「下一步」并严格按返回执行。
+- 用户仅给出 change 名（未指定任务组）时的约定语义：表示以简单模式串行实施该 change 的全部任务组。先读取 `openspec/changes/<change 名>/tasks.md` 获取任务组清单与顺序（该文件是编排规划清单，非被编排项目的业务源码，也是初始化前唯一允许读取的项目文件）：未初始化时从清单第一个任务组开始，以显式 `mode="simple"` 调用初始化工具；当前任务组收尾完成后初始化顺序中的下一个任务组，直至全部任务组完成后编排结束。用户明确指定任务组或要求 full 模式时按用户指定执行，不适用本约定。
 - 子代理工具命名随 harness 不同：
   - DSH 形态：`openspec_developer` / `openspec_reviewer` 两个物理子代理（`openspec_<role>`，物理 agent 已收敛，9 种逻辑身份经 `_agent` 参数承载），分派时直接调用这些专用工具，不要使用通用 `subagent` 代替；
   - 其他 harness 按各自原生子代理机制分派（Claude Code / Codex / ZCode 插件已注入对应子代理）。
@@ -51,7 +52,7 @@ capabilities: ["orchestrator"]
 - 断点续传：子代理因步骤限制中断后重新分派即可继续，无需保存已完成子任务列表
 - 工具列出多个子代理时并排分派（单条消息中同时发送），不串行等待
 - 分派前校验分派 prompt：按「禁止事项」中禁止转述的动态内容清单逐项检查，校验通过后再分派
-- 先解锁、后 status、再探索；禁止在首次 status 前手动探查项目文件/状态文件
+- 先解锁、后 status、再探索；禁止在首次 status 前手动探查项目文件/状态文件（唯一例外：用户未指定任务组时，按启动编排约定语义读取 tasks.md 确定任务组清单与顺序）
 
 ## 禁止事项
 

package/dsh/cordis.patch.yml

@@ -25,47 +25,6 @@
         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:
@@ -282,4 +241,45 @@
           确定性质量工具检查出的问题若以压制手段解决（压制注解、注释抑制、规则排除配置、平台状态标注、构建跳过开关等），一律视为豁免申请，须判定其合理性：可接受情形（无法消除的框架/第三方限制、有证据的误报，且风险可控、理由充分）→ 认可豁免；不可接受情形（真实缺陷被压制规避、仅图省事、无理由或理由不成立）→ 不认可，须要求移除压制并真实修复。判定时核验压制处的理由（代码注释、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.133.1",
+  "version": "0.133.2",
   "description": "OpenSpec change orchestration plugin for AI coding agents (Claude Code, Codex, ZCode, DeepSeek Harness, OpenCode)",
   "author": "ifrankwang",
   "license": "MIT",