@gong-ym/ai-spec-auto 0.2.15 → 0.2.19

package/.agents/commands/common/spec-continue.md

@@ -61,7 +61,7 @@
 若 `turn.status = blocked` 且存在 `turn.summary.pending_gate`：
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/design/tasks 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/tasks 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-start-review.md

@@ -61,7 +61,7 @@
 
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 `proposal/specs/design/tasks` 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 `proposal/specs/tasks` 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update（协议更新命令）` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-start.md

@@ -48,7 +48,7 @@
 若 `turn.status = blocked` 且存在 `turn.summary.pending_gate`：
 - 明确告诉用户：当前停在该审批门禁，尚未批准，不能继续实现
 - 若存在 `turn.guidance.approval_gate.user_report_contract`，严格按它输出极简摘要：
-  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/design/tasks 或仓库文件路径，不要输出任何“对内说明”
+  只保留“当前状态 / 关键原因 / 下一步”，不要写长篇阶段说明，不要罗列 proposal/specs/tasks 或仓库文件路径，不要输出任何“对内说明”
 - 不要继续执行 `advance`
 - 若用户随后给出明确批准意见，或在归档确认门禁下给出“归档 / 不归档”决定，先执行 `turn.commands.update` 记录说明；若 `protocol-update` 返回 `fast_path.executed = true`，直接结束当前轮次，否则再让用户重新执行 `/spec-continue`
 

package/.agents/commands/common/spec-update.md

@@ -40,7 +40,7 @@
    - `resume-paused-run`：说明已恢复停点，再按返回的下一个 `turn` 继续
 2. 若返回 `turn.mode = update-review`，必须先遵守 `turn.guidance.update_contract`
 3. 只读取 `turn.reads`，只写 `turn.writes`
-4. 若 `change_impact = patch | scope-delta | archive-fix`，默认在同一 `change_id` 内增量更新，不要推倒已有 proposal/specs/design/tasks/checklist/iterations
+4. 若 `change_impact = patch | scope-delta | archive-fix`，默认在同一 `change_id` 内增量更新，不要推倒已有 proposal/specs/tasks/checklist/iterations
 5. 若 `change_impact = re-scope`，不要强行吞进当前 run；按 `reconcile_strategy` 给出“建议新建 change”的最小结论
 6. 若 `change_impact = followup-patch`，这是对已归档变更的补丁修正；继续沿返回的 patch run 推进，不要改旧 archive 目录
 7. 若存在 `turn.finalize_contract`，完成当前轮次后按契约推进，不要自行拼命令
@@ -57,4 +57,4 @@
 - 大段协议日志
 - scratch JSON
 - 内部运行态文件名
-- “整份重写 proposal/tasks/design/specs” 这类误导性说法
+- “整份重写 proposal/tasks/specs” 这类误导性说法

package/.agents/commands/cursor/opsx-apply.md

@@ -28,7 +28,6 @@ description: Cursor 兼容入口：按 tasks.md 执行 OpenSpec 任务实现
    ```
    再读取：
    - `openspec/changes/<change-name>/proposal.md`
-   - `openspec/changes/<change-name>/design.md`（若存在）
    - `openspec/changes/<change-name>/tasks.md`
 
 3. 默认按 `execute-task` 技能执行  

package/.agents/commands/cursor/opsx-propose.md

@@ -43,7 +43,6 @@ description: Cursor 兼容入口：创建 OpenSpec 提案并生成 proposal/spec
 5. 产物位置必须稳定落在：
    - `openspec/changes/<change-name>/proposal.md`
    - `openspec/changes/<change-name>/specs/`
-   - `openspec/changes/<change-name>/design.md`
    - `openspec/changes/<change-name>/tasks.md`
 
 6. 完成后只做简洁收口：

package/.agents/flows/RUN_OUTPUT.md

@@ -57,7 +57,6 @@
     "artifacts": [
       "openspec/changes/<change-id>/proposal.md",
       "openspec/changes/<change-id>/specs/",
-      "openspec/changes/<change-id>/design.md",
       "openspec/changes/<change-id>/tasks.md",
       "code",
       "openspec/changes/<change-id>/checklist.md",
@@ -129,7 +128,6 @@
   "artifacts": [
     "openspec/changes/add-user-center/proposal.md",
     "openspec/changes/add-user-center/specs/",
-    "openspec/changes/add-user-center/design.md",
     "openspec/changes/add-user-center/tasks.md",
     "openspec/changes/add-user-center/checklist.md",
     "openspec/changes/add-user-center/iterations.md"

package/.agents/flows/common/prd-to-delivery.md

@@ -25,7 +25,6 @@ approval_gates: []
 artifacts:
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
   - code
   - openspec/changes/<change-id>/checklist.md
@@ -119,7 +118,6 @@ domains:
 
 - `openspec/changes/<change-id>/proposal.md`
 - `openspec/changes/<change-id>/specs/`
-- `openspec/changes/<change-id>/design.md`
 - `openspec/changes/<change-id>/tasks.md`
 - 与本次变更相关的代码实现
 - `openspec/changes/<change-id>/checklist.md`
@@ -131,7 +129,6 @@ domains:
 
 - 需求边界已被收敛为 `proposal.md`
 - 增量规范已落在 `specs/`，且允许按 domain 拆分多份 spec
-- 技术方案已沉淀为 `design.md`
 - 实施任务已被拆解为 `tasks.md`
 - 代码实现与任务范围一致
 - 交付前检查已完成并形成 `checklist.md`

package/.agents/flows/common/requirement-to-observability.md

@@ -20,7 +20,6 @@ optional_roles:
 approval_gates: []
 artifacts:
   - openspec/changes/<change-id>/proposal.md
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
   - event-plan
   - tracking-schema-notes
@@ -78,7 +77,6 @@ domains:
 至少要沉淀以下内容：
 
 - `proposal.md`
-- `design.md`
 - `tasks.md`
 - `event-plan`
 - `tracking-schema-notes`

package/.agents/orchestration/runtime-state-handoff-spec.md

@@ -237,7 +237,99 @@ frontend-implementer（前端实现专家）
 - 追加一条 `run-cancelled` 事件
 - 记录 `timestamps.finished_at`
 
-## 7. 当前阶段边界
+## 7. 上下文传递优化（Context Pass-through）
+
+### 7.1 问题背景
+
+当前每个专家都需要独立加载以下上下文：
+
+- `context/PROJECT.md`
+- `.agents/rules/` 下的项目规则
+- `openspec/changes/<change-id>/` 下的变更文档
+- 前序专家的分析产物
+
+这导致：
+
+- 重复读取相同文件
+- 每个专家都要重新解析项目规则
+- 上下文信息在多轮对话中逐渐稀释
+
+### 7.2 上下文传递机制
+
+当发生专家交接时，handoff payload 应携带 `context_payload`：
+
+```json
+{
+  "context_payload": {
+    "project_facts": {
+      "tech_stack": "Vue 3 + TypeScript + Vite",
+      "directory_structure": "src/views/, src/components/",
+      "api_pattern": "@/utils/request",
+      "style_pattern": "主题变量 + Tailwind"
+    },
+    "current_change": {
+      "change_id": "add-product-delete",
+      "proposal_path": "openspec/changes/add-product-delete/proposal.md",
+      "tasks_path": "openspec/changes/add-product-delete/tasks.md",
+      "specs_dir": "openspec/changes/add-product-delete/specs/"
+    },
+    "previous_analysis": {
+      "requirement_summary": "给商品卡片加删除按钮，点击后调用 DELETE API",
+      "key_decisions": ["沿用项目 Button 组件", "删除前弹确认框"],
+      "open_questions": []
+    },
+    "rules_snapshot": {
+      "loaded_rules": ["01-项目概述.md", "03-项目结构.md", "05-API规范.md", "09-样式规范.md"],
+      "key_constraints": ["API 必须使用 @/utils/request 封装", "样式必须使用主题变量"]
+    }
+  }
+}
+```
+
+### 7.3 下游专家行为
+
+当收到 `context_payload` 时，下游专家应：
+
+1. **优先使用传递的上下文**：不再重复读取已包含的文件
+2. **按需补充读取**：只读取 `context_payload` 中未覆盖的规则
+3. **继承前序分析**：直接引用 `previous_analysis` 中的结论，不重新分析
+
+### 7.4 简单需求直接交接
+
+当 `delivery_profile = micro` 且 `complexity = low` 时，允许：
+
+- `requirement-analyst` 完成后直接产出 `frontend-implementer` 的执行载荷
+- `task-orchestrator` 只做状态记录，不做额外干预
+- 实现专家直接读取 `context_payload` 进入编码
+
+## 8. 并行分析阶段（可选）
+
+### 8.1 适用场景
+
+当复杂需求同时触发多个可选专家时：
+
+- `requirement-analyst` 完成基础分析
+- `design-collaborator` 分析设计约束
+- `api-contract-specialist` 分析接口契约
+
+### 8.2 并行执行模式
+
+```
+requirement-analyst（完成基础分析）
+    ↓
+    ├─ design-collaborator（并行分析）
+    └─ api-contract-specialist（并行分析）
+    ↓
+frontend-implementer（合并分析结果后进入实现）
+```
+
+### 8.3 实现约束
+
+- 并行专家必须基于同一份 `context_payload`
+- 各专家产出独立文档，不互相依赖
+- `task-orchestrator` 在所有并行专家完成后合并结果
+
+## 9. 当前阶段边界
 
 当前最小实现只解决：
 

package/.agents/orchestration/task-orchestrator-run-plan-template.md

@@ -211,7 +211,34 @@ description: 定义 task-orchestrator 在首次识别任务时必须输出的最
   - 多状态联动、真实接口、复杂业务规则、核心模块改造
   - 使用完整产物与完整门禁
 
-### 5.6 micro 的产物规格
+### 5.6 简单需求快速通道
+
+当 `delivery_profile = micro` 且 `complexity = low` 时，启用快速通道：
+
+**简单需求判断标准**（满足全部）：
+- 单文件或 2-3 个文件的修改
+- 任务明确（如"加个按钮"、"改个样式"、"加个校验"）
+- 不涉及新模块、新路由、新接口
+- 无需设计稿或复杂交互
+- 项目规则中已有明确实现模式
+
+**快速通道行为**：
+1. `requirement-analyst` 跳过 `design-analysis` 调用
+2. `proposal.md` 使用极简版（目标、范围、假设，各 1-2 行）
+3. `specs/` 使用极简版（只写变更点，不写完整场景）
+4. `tasks.md` 使用极简版（3-5 条直接可执行任务）
+5. 快速进入实现，不做详细澄清
+
+**复杂需求**（命中任一）：
+- 涉及多个模块或系统级变更
+- 需要新接口、新状态管理、新路由设计
+- 有设计稿或复杂交互需求
+- 存在技术选型或架构决策
+- 规则不明确，需要大量澄清
+
+复杂需求按完整流程执行，不做快速通道优化。
+
+### 5.7 micro 的产物规格
 
 当 `delivery_profile = micro` 时：
 
@@ -219,7 +246,8 @@ description: 定义 task-orchestrator 在首次识别任务时必须输出的最
 - `tasks.md` 使用短版：3-5 条可执行任务
 - `checklist.md` 使用短版：关键检查项、阻断项、是否建议通过
 - `iterations.md` 使用短版：问题、修正动作、残留风险
-- 不允许因为是 `micro` 而跳过专家或跳过 OpenSpec 落盘
+- 对于简单需求（见 5.6），`requirement-analyst` 可采用快速通道行为
+- 不允许因为 `micro` 而跳过 OpenSpec 落盘
 
 ### 5.7 page-development 任务的缺口分类
 
@@ -236,8 +264,8 @@ description: 定义 task-orchestrator 在首次识别任务时必须输出的最
 对于 `prd-to-delivery（需求到交付）`：
 
 - 首轮 `run-plan（运行计划）` 必须确定稳定 `change_id（变更 ID）`
-- 首轮 `run-plan（运行计划）` 必须显式带出 `proposal/specs/design/tasks/checklist/iterations` 的目标路径
-- 未存在 `proposal.md`、`specs/`、`design.md` 与 `tasks.md` 时，不得交给 `frontend-implementer（前端实现专家）`
+- 首轮 `run-plan（运行计划）` 必须显式带出 `proposal/specs/tasks/checklist/iterations` 的目标路径
+- 未存在 `proposal.md`、`specs/` 与 `tasks.md` 时，不得交给 `frontend-implementer（前端实现专家）`
 - 未存在 `checklist.md` 与 `iterations.md` 时，不得进入 `complete（完成）`
 
 ## 6. 示例
@@ -289,6 +317,59 @@ description: 定义 task-orchestrator 在首次识别任务时必须输出的最
 - 先按默认假设进入 requirement-analyst（需求解析专家）；若需求收敛阶段发现高风险冲突，再转 suggest 或 manual
 ```
 
+### 简单需求示例（快速通道）
+
+#### 输入
+
+```text
+@task-orchestrator（任务主代理） 给商品卡片加个删除按钮
+```
+
+#### 输出
+
+```md
+## 任务识别
+- 类型：组件增强
+- 当前输入：给商品卡片加个删除按钮
+- 风险级别：low
+- 复杂度：low（单文件修改，任务明确）
+
+## 推荐流程模板
+- `selected_flow（选中的流程模板）`：prd-to-delivery
+- 原因：简单增强任务，适合快速通道
+
+## 运行模式
+- `mode（运行模式）`：auto
+
+## 交付档位
+- `delivery_profile（交付档位）`：micro
+- `artifact_profile（产物规格）`：compact
+- `complexity（复杂度）`：low
+
+## 快速通道
+- 已识别为简单需求，启用快速通道
+- requirement-analyst 跳过 design-analysis
+- 文档采用极简版
+
+## 推荐专家
+- 必选：frontend-implementer（前端实现专家）、code-guardian（规范守护者）
+- 可选：requirement-analyst（需求解析专家）
+- 第一跳：requirement-analyst（需求解析专家）
+
+## 默认假设
+- 沿用项目现有组件结构和样式规范
+- 删除按钮样式沿用项目 Button 组件
+
+## 缺失输入
+- 无
+
+## 审批点
+- 暂无
+
+## 下一步
+- 直接进入快速通道，requirement-analyst 生成极简文档后快速进入实现
+```
+
 ## 7. 一句话约束
 
 > `task-orchestrator（任务主代理）` 的首轮输出必须先形成结构化 `run-plan（运行计划）`；在 `auto（自动）` 模式下，应先做仓库推断并记录 `assumptions（默认假设）`，不默认回问用户，只有高风险关键分歧才转 `suggest（建议）` 或 `manual（手动）`。

package/.agents/registry/flows.json

@@ -21,10 +21,10 @@
         "frontend-implementer->code-guardian": "silent",
         "code-guardian->archive-change": "silent"
       },
-      "core_artifacts": ["proposal", "specs", "design", "tasks", "checklist", "iterations"],
-      "required_artifacts": ["proposal.md", "specs", "design.md", "tasks.md", "checklist.md", "iterations.md"],
+      "core_artifacts": ["proposal", "specs", "tasks", "checklist", "iterations"],
+      "required_artifacts": ["proposal.md", "specs", "tasks.md", "checklist.md", "iterations.md"],
       "handoff_policy": "task-orchestrator -> requirement-analyst -> frontend-implementer -> code-guardian -> archive-change(可选) -> terminal",
-      "completion_policy": "proposal.md、specs/、design.md、tasks.md、checklist.md、iterations.md 缺一不可；默认自动进入 archive-change，如需人工审核可切换到 main-flow-blocking"
+      "completion_policy": "proposal.md、specs/、tasks.md、checklist.md、iterations.md 缺一不可；默认自动进入 archive-change，如需人工审核可切换到 main-flow-blocking"
     },
     "bugfix-to-verification": {
       "name": "缺陷修复到验证",
@@ -101,8 +101,8 @@
       "optional_roles": ["error-tracker", "rum-analyst", "code-guardian"],
       "first_handoff": "requirement-analyst",
       "approval_gates": [],
-      "core_artifacts": ["proposal", "design", "tasks", "event-plan", "tracking-schema-notes"],
-      "required_artifacts": ["proposal.md", "design.md", "tasks.md", "event-plan"],
+      "core_artifacts": ["proposal", "tasks", "event-plan", "tracking-schema-notes"],
+      "required_artifacts": ["proposal.md", "tasks.md", "event-plan"],
       "handoff_policy": "task-orchestrator -> requirement-analyst -> event-instrumentation-specialist -> error-tracker/rum-analyst(可选) -> code-guardian(可选) -> terminal",
       "completion_policy": "观测目标、事件口径与追踪建议已收口；若启用附加专家，则需补齐错误或 RUM 观察结论"
     },

package/.agents/registry/roles.json

@@ -149,7 +149,7 @@
       "rule_contract_profiles": {
         "default": {
           "must_follow": [
-            "先把项目定位、目录落点、规范约定吸收到 proposal/specs/design/tasks，不要把规范已明确的信息重复写成 missing_inputs。",
+            "先把项目定位、目录落点、规范约定吸收到 proposal/specs/tasks，不要把规范已明确的信息重复写成 missing_inputs。",
             "需求收敛必须落到当前仓库可实施的具体落点，而不是抽象方案。"
           ],
           "blocked_when": [
@@ -184,13 +184,11 @@
       "openspec_rule_sections": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -248,11 +246,11 @@
         "default": {
           "must_follow": [
             "优先复用现有目录、路由、请求封装、状态管理和样式变量约定。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "vue": {
@@ -270,13 +268,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -312,11 +308,11 @@
         "default": {
           "must_follow": [
             "优先复用现有 Service、Repository 和工具类，不重复建设。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "springboot": {
@@ -333,13 +329,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -375,11 +369,11 @@
         "default": {
           "must_follow": [
             "优先复用现有工具函数、Contract 定义和模块导出，不重复建设。",
-            "实现前先对齐 proposal/specs/design/tasks 的范围与落点，不要自行扩 scope。",
+            "实现前先对齐 proposal/specs/tasks 的范围与落点，不要自行扩 scope。",
             "若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构。"
           ],
           "blocked_when": [
-            "proposal/specs/design/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
+            "proposal/specs/tasks 未落盘或仍处于 before-implementation 审批门禁时，禁止改业务代码。"
           ]
         },
         "node-tooling": {
@@ -396,13 +390,11 @@
       ],
       "openspec_rule_sections": [
         "specs",
-        "tasks",
-        "design"
+        "tasks"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "runtime_transition": {
@@ -500,7 +492,7 @@
       "rule_contract_profiles": {
         "default": {
           "must_follow": [
-            "以 proposal/specs/design/tasks 和项目规则为准检查实现，而不是只做泛化 lint。",
+            "以 proposal/specs/tasks 和项目规则为准检查实现，而不是只做泛化 lint。",
             "必须给出阻断项、非阻断项和交付建议，不能写成模糊建议列表。",
             "若实现阶段经历过 auto-fix 仍未通过 verification，必须按阻断项处理，不能以后续再看放行。"
           ],
@@ -513,7 +505,7 @@
             "核查页面是否落在 src/views、路由是否落在 src/router/modules，并保持动态导入。",
             "核查 API 是否通过 src/api 封装、类型是否放在 src/api/types，页面中未直接调 request。",
             "核查样式是否使用主题变量、scoped 或 CSS Modules，而不是硬编码全局样式。",
-            "核查 Pinia/store、mock 与 proposal/specs/design/tasks 的边界是否一致，避免演示页写成生产页。"
+            "核查 Pinia/store、mock 与 proposal/specs/tasks 的边界是否一致，避免演示页写成生产页。"
           ]
         },
         "springboot": {
@@ -539,14 +531,12 @@
       "openspec_rule_sections": [
         "tasks",
         "specs",
-        "design",
         "checklist",
         "iterations"
       ],
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": [
@@ -586,7 +576,7 @@
             "归档目录必须落在 openspec/changes/archive/YYYY-MM-DD-<change-id>/，不能改到其它位置。"
           ],
           "blocked_when": [
-            "缺少 proposal/specs/design/tasks/checklist/iterations 任一关键产物时，不得执行归档。"
+            "缺少 proposal/specs/tasks/checklist/iterations 任一关键产物时，不得执行归档。"
           ]
         }
       },
@@ -601,7 +591,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks",
         "checklist",
         "iterations"
@@ -831,7 +820,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []
@@ -973,7 +961,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []
@@ -1107,7 +1094,6 @@
       "required_inputs": [
         "proposal",
         "specs",
-        "design",
         "tasks"
       ],
       "required_outputs": []

package/.agents/roles/common/backend-implementer.md

@@ -16,7 +16,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - code
@@ -35,13 +34,13 @@ handoff_to:
 
 ## 工作原则
 
-- 先读 `proposal.md`、`specs/`、`design.md` 和 `tasks.md`，再动代码
+- 先读 `proposal.md`、`specs/` 和 `tasks.md`，再动代码
 - 若当前 flow 是 `bugfix-to-verification`，优先读 `bugfix.md`、用户原始输入和仓库规则，再做最小修复
 - 先按分层规范（Controller → Service → Repository）判断实现落点，再选技能
 - 项目规则高于 skill 示例；如果 skill 样例与当前项目约定冲突，以规则为准
 - 优先复用现有服务、Repository 和工具类，不重复建设
 - 修改范围尽量贴近本次变更，不顺手大改无关代码
-- 若 `proposal.md`、`specs/`、`design.md` 或 `tasks.md` 缺失，必须退回要求补齐
+- 若 `proposal.md`、`specs/` 或 `tasks.md` 缺失，必须退回要求补齐
 
 ## 必做步骤
 
@@ -64,7 +63,7 @@ handoff_to:
 
 ### OpenSpec 模式
 
-- 输入以 `proposal.md / specs/ / design.md / tasks.md` 为准
+- 输入以 `proposal.md / specs/ / tasks.md` 为准
 - 输出以 `code + implementation-notes` 为准
 - 不得跳过需求收敛产物直接写实现
 

package/.agents/roles/common/code-guardian.md

@@ -18,7 +18,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - openspec/changes/<change-id>/checklist.md
@@ -37,7 +36,7 @@ handoff_to: []
 
 ## 工作原则
 
-- 以规则、specs/design、任务目标和验收标准为准
+- 以规则、specs、任务目标和验收标准为准
 - 若当前 flow 是 `bugfix-to-verification`，必须同时把 quick-fix 边界核查写进结论
 - 先建立需求完成度清单，再做规则与质量审查
 - 先发现问题，再判断严重程度和是否阻断交付
@@ -83,7 +82,7 @@ handoff_to: []
 
 ### OpenSpec 模式
 
-- 以 `proposal/specs/design/tasks` 和当前实现为主输入
+- 以 `proposal/specs/tasks` 和当前实现为主输入
 - 输出 `openspec/changes/<change-id>/checklist.md` 与 `iterations.md`
 - 继续承担归档前放行门禁
 

package/.agents/roles/common/frontend-implementer.md

@@ -22,7 +22,6 @@ reads:
   - .agents/rules/
   - openspec/changes/<change-id>/proposal.md
   - openspec/changes/<change-id>/specs/
-  - openspec/changes/<change-id>/design.md
   - openspec/changes/<change-id>/tasks.md
 writes:
   - code
@@ -41,7 +40,7 @@ handoff_to:
 
 ## 工作原则
 
-- 先读 `proposal.md`、`specs/`、`design.md` 和 `tasks.md`，再动代码
+- 先读 `proposal.md`、`specs/` 和 `tasks.md`，再动代码
 - 若当前 flow 是 `bugfix-to-verification`，优先读 `bugfix.md`、用户原始输入和仓库规则，再做最小修复
 - 先按 `rules` 和 `repo_conventions` 判断目录、路由、API、状态、样式落点，再选 skill
 - 项目规则高于 skill 示例；如果 skill 样例与当前项目约定冲突，以规则为准
@@ -49,7 +48,7 @@ handoff_to:
 - 按技术栈选择对应 profile skill，不混用无关框架做法
 - 修改范围尽量贴近本次变更，不顺手大改无关代码
 - 若 verification 失败触发 auto-fix，只修失败步骤对应的问题，不新增功能、不顺手重构
-- 若 `proposal.md`、`specs/`、`design.md` 或 `tasks.md` 缺失，必须退回要求补齐，不能跳过需求阶段直接实现
+- 若 `proposal.md`、`specs/` 或 `tasks.md` 缺失，必须退回要求补齐，不能跳过需求阶段直接实现
 - 优先执行协议下发的 `project_context / repo_conventions / implementation_contract`
 - 实现方式必须由 `role_skill_contract` 和 `role_rule_contract` 共同约束，而不是自由发挥
 
@@ -77,7 +76,7 @@ handoff_to:
 
 ### OpenSpec 模式
 
-- 输入以 `proposal.md / specs/ / design.md / tasks.md` 为准
+- 输入以 `proposal.md / specs/ / tasks.md` 为准
 - 输出以 `code + implementation-notes` 为准
 - 不得跳过需求收敛产物直接写实现