@aipper/aiws-spec 0.0.36 → 0.0.39

package/docs/ws-goal-contract.md

@@ -38,10 +38,10 @@ ws-goal 定义为**协议层**（prompt-template + artifact spec），不是运
 |---|---|---|
 | 录入目标 | 按模板写 `.aiws/goals/<id>.md` | 不创建 change/plan |
 | 依赖链预检 | 追溯上游 change 健康度 + target_base_branch 一致性 | 不修改上游工件 |
-| 管道委托 | 预检通过后，将 goal 委托给子 agent 执行完整 pipeline（ws-plan → ws-dev → ws-review → ws-commit → ws-finish → 审计） | ws-goal 自己不执行任何实现步骤 |
+| 管道委托 | 预检通过后，将 goal 拆分为 phase-level 子任务（PLAN → DEV → REVIEW → FINISH），每个 phase 委托给独立轻量子 agent，主 session 编排调度与验证 | ws-goal 自己不执行任何实现步骤 |
 | 完成审计 | Verification 对照 outcome 逐条验证 | 不替代 review 门禁 |
 
-第四步（管道委托）是 ws-goal 的**编排出口**：依赖链预检通过后，ws-goal 构造一个包含 goal 文件完整内容 + 真值文件路径 + 强制 pipeline 步骤的委托 prompt，交由平台支持的子 agent 执行。子 agent 执行完成后，ws-goal 执行最终的完成审计并更新 goal status。
+第四步（管道委托）是 ws-goal 的**编排出口**：依赖链预检通过后，ws-goal 将 goal 拆分为 PLAN → DEV → REVIEW → FINISH 四个 phase，每个 phase 构造独立委托 prompt 交由轻量子 agent 执行。主 session 在每个 phase 完成后验证产出，决定继续/重试/暂停。所有 phase 通过后，ws-goal 执行最终的完成审计并更新 goal status。**设计原则**：每个子 agent 只做一个 phase 的事，上下文小、失败影响范围小、可独立重试。
 
 这样做的好处是：ws-goal 保持轻量协议层，不重复造 runtime，但通过委托机制提供了从 goal 到 complete 的自动化路径。
 
@@ -357,3 +357,235 @@ Dependency chain 验证（2.4）需要：
 - **轻量**（< 3 步，单文件改动）：只做 step 1-2（derive + preserve），跳过完整证据链
 - **标准**（3-10 步，多文件改动）：完整 8 步审计
 - **严格**（跨模块、跨 repo）：8 步审计 + 独立审计者 + ws-review 门禁
+
+---
+
+## 6. Pipeline Sequential Dispatch
+
+### 6.1 Motivation
+
+ws-goal step 5（Pipeline Delegation）将 goal 的完整执行委托给单个子 agent。对于包含多个独立交付批次的 goal（如"分四组完成全部页面重构"），单个子 agent 可能在长时间执行中：
+- 因上下文超限而丢失精度
+- 中途失败导致整个 goal 回退
+- 无法体现不同页面组的边界差异
+
+Pipeline Sequential Dispatch 通过**组（group）机制**解决此问题：同一 goal 内的多个执行单元各自委托给独立的子 agent，按依赖顺序逐个执行，ws-goal 负责编排调度。
+
+### 6.2 Core Design
+
+#### 6.2.1 Group 定义
+
+Group 是 goal 内部的一个自包含执行单元：
+
+| 属性 | 类型 | 说明 |
+|---|---|---|
+| **id** | string | 组标识，如 `group-1`, `group-foundation` |
+| **title** | string | 简短标题 |
+| **scope** | string | 范围描述：哪些文件、哪些模块 |
+| **verification** | string[] | 该组的验收标准。组完成时需逐条验证 |
+| **depends_on** | string[] | 依赖的其他 group id。默认 `[]`（无依赖） |
+| **status** | enum | `pending \| in_progress \| complete \| paused \| failed` |
+
+#### 6.2.2 Group Dependencies
+
+Group 之间的依赖构成 DAG（有向无环图）：
+
+- Group B 声明 `depends_on: [A]` → B 仅在 A 完成后启动
+- 无依赖的 group 之间当前必须顺序执行（并行调度暂不实现）
+- 禁止循环依赖
+- 默认（不声明 `depends_on`）按声明顺序执行
+
+#### 6.2.3 State Machine
+
+每个 group 有自己的状态，与整体 goal 状态解耦：
+
+```
+group: pending → in_progress → complete
+                                → paused (下游 block)
+                                → failed (下游 block)
+```
+
+整体 goal 的状态：
+
+```
+active → group 1 executing → group 1 complete → group 2 executing → ... → all groups complete → overall completion audit → complete
+                                                                      → any group paused → paused
+                                                                      → any group failed → paused (with failure recorded)
+```
+
+#### 6.2.4 Delegation Model (Phase-Level)
+
+每个 group 的执行被拆分为 4 个 phase，每个 phase 委托给独立轻量子 agent，主 session 编排调度：
+
+```
+group execution:
+  PHASE 1 - PLAN:   子 agent 只做 proposal + plan + plan-verify
+                      → 主 session 验证 plan 产出
+  PHASE 2 - DEV:    子 agent 只做代码实现 + 本地验证
+                      → 主 session 验证 diagnostics + 改动范围
+  PHASE 3 - REVIEW: 子 agent 只做审计（不修改代码）
+                      → 主 session 验证 review 证据
+  PHASE 4 - FINISH: 子 agent 只做 commit + finish
+                      → 主 session 验证合并完成
+```
+
+每个 phase 的委托 prompt 包含：
+- goal 完整上下文（outcome, verification, constraints, boundaries, target_base_branch）
+- 当前 group 的 scope 与 verification
+- 该 phase 的明确范围（不做什么）
+- 完成条件：仅限该 phase 的产出
+
+phase 间的主 session 验证是门禁：
+- 验证通过 → 进入下一个 phase
+- 验证失败 → 可重试当前 phase（最多 N 次）或暂停 goal
+- 暂停后恢复时，从失败的 phase 重新开始，不重做已通过的 phase
+
+设计原则：
+- **单一职责**：每个子 agent 只做一个 phase。PLAN agent 不做 dev，DEV agent 不做 review
+- **小上下文**：每个 phase 的 prompt 只包含该 phase 需要的信息，不携带无关上下文
+- **失败隔离**：一个 phase 失败不影响其他 phase 的产出；只需重试失败的 phase
+- **可审计**：每个 phase 的产出有明确的验证标准，主 session 逐条核验
+
+### 6.3 Goal File Extension
+
+启用 Pipeline Sequential Dispatch 的 goal，在 `Progress Notes` 字段上方或 `Tasks` 区域添加 groups 定义：
+
+```yaml
+## Groups
+
+### group-1: Foundation Pages
+- scope: index.tsx, category.tsx, search.tsx
+- verification:
+  - "Home page renders product grid"
+  - "Category page renders with filters"
+  - "Search results show 10 items per page"
+- depends_on: []
+- status: pending
+
+### group-2: Purchase Conversion
+- scope: cart.tsx, checkout.tsx, payment-form.tsx
+- verification:
+  - "Add to cart updates badge count"
+  - "Checkout collects shipping address"
+  - "Payment form validates card number"
+- depends_on: [group-1]
+- status: pending
+```
+
+### 6.4 Dispatch Protocol (Phase-Level)
+
+ws-goal 执行 Phase-Level Sequential Dispatch 时遵循以下协议：
+
+```
+1. Parse goal file → extract group list
+2. Validate group DAG (no cycles, deps resolve to known groups)
+3. FOR each group in topological order:
+   a. Update group status → in_progress
+   b. Group PHASE 1 - PLAN:
+      i.   Construct phase delegation prompt:
+           - Goal outcome, verification (group-level), constraints, boundaries
+           - Current group scope and verification
+           - target_base_branch from goal
+           - Dependency chain validation results (step 4)
+           - Workspace state analysis results (step 4.5)
+           - Phase scope: ONLY proposal.md + plan file + plan-verify
+           - Phase constraints: NOT dev, NOT review, NOT commit/finish
+      ii.  Delegate to sub-agent:
+           - `task(category="unspecified-high", prompt="...")`
+           - Wait for completion
+      iii. Main session verify:
+           - proposal.md exists
+           - plan file exists with verification commands
+           - plan-verify passed
+           - Fail max 2x → group paused, blocker recorded, STOP
+   c. Group PHASE 2 - DEV:
+      i.   Construct phase delegation prompt:
+           - Plan content, proposal links
+           - Phase scope: ONLY implement per plan + local verify
+           - Phase constraints: NOT modify proposal/plan, NOT commit
+      ii.  Delegate to sub-agent:
+           - `task(category="deep", prompt="...")`
+           - Wait for completion
+      iii. Main session verify:
+           - Diagnostics clean (lsp_diagnostics on changed files)
+           - Changes match plan scope
+           - Fail → group paused, blocker recorded, STOP
+   d. Group PHASE 3 - REVIEW:
+      i.   Construct phase delegation prompt:
+           - Proposal + plan + changed files
+           - Phase scope: ONLY audit, produce review evidence
+           - Phase constraints: NOT modify code
+      ii.  Delegate to sub-agent:
+           - `task(category="unspecified-high", prompt="...")`
+           - Wait for completion
+      iii. Main session verify:
+           - Review evidence files exist
+           - No HIGH blocker unresolved
+           - Fail → group paused, blocker recorded, STOP
+   e. Group PHASE 4 - FINISH:
+      i.   Construct phase delegation prompt:
+           - Phase scope: ONLY commit + finish
+           - Phase constraints: NOT modify code
+      ii.  Delegate to sub-agent:
+           - `task(category="quick", load_skills=["git-master"], prompt="...")`
+           - Wait for completion
+      iii. Main session verify:
+           - Change branch merged to target_base_branch
+           - Pushed to remote
+   f. Update group status → complete
+   g. Update goal Progress Notes with group result
+4. All groups complete:
+   - Run overall completion audit (all verification + goal-level checks)
+   - Update goal state → complete
+   - Output: "Goal <id> complete (<N> groups executed)"
+```
+
+**Simple Group Escape Hatch**：若 group scope 极小（≤2 文件，配置变更），可合并 PLAN + DEV 为一个 phase，但 REVIEW 和 FINISH 保持独立。
+
+### 6.5 Completion Audit (Phase-Level)
+
+Phase-Level Pipeline Dispatch 的审计分散在各 phase 的门禁验证中，并在全部 group 完成后做总体审计：
+
+**Per-Phase 审计**（每个 phase 完成后由主 session 执行）：
+- PLAN phase: proposal.md 存在、plan 文件存在、plan-verify 通过
+- DEV phase: diagnostics 干净、改动范围匹配 plan
+- REVIEW phase: review 证据文件存在、无 HIGH blocker
+- FINISH phase: change 分支已合并、已推送
+- 任一 phase 审计未通过 → 暂停 goal，记录 blocker，不继续
+
+**Group 级审计**（组内全部 4 个 phase 通过后汇总）：
+- 验证 group 的 scope 是否已实现
+- 验证 group 的 verification 条目（通过各 phase 分散验证自动汇聚）
+- 汇总为 group 的完成状态 → complete / paused
+
+**整体审计**（所有 group 完成后执行）：
+- 验证 goal 级别的 outcome 字段是否满足
+- 验证所有 group 均标记 complete，无 paused/failed
+- 回归检查：全局改动未引入新的 lint/type 错误
+- 验证 dependency chain 在最终合并后仍然健康
+- 输出审计报告：每 group 结果 + 整体结论
+
+### 6.6 Failure Recovery
+
+当 group 中途失败或暂停时：
+
+1. ws-goal 记录当前组停止位置到 Progress Notes
+2. 标记 goal state=paused
+3. 输出恢复命令建议，例如：
+   ```
+   Goal <id> paused at group <group-id>.
+   To resume: fix the reported issue, then restart ws-goal.
+   ws-goal will detect the paused goal and ask whether to:
+     a) Retry group <group-id> (re-delegate)
+     b) Skip group <group-id> (mark complete manually, proceed to next)
+     c) Pause and handoff
+   ```
+4. 下一 session 启动 ws-goal 时（step 0），检测到 paused goal → 输出恢复选项 → 用户选择后继续
+
+### 6.7 Backward Compatibility
+
+| 现有 goal | 兼容性 |
+|---|---|
+| 不含 groups 定义的 goal | 受影响：step 5 从单次 delegation 变为 4-phase 顺序执行。迁移后需按 phase-level 适配 |
+| 含 groups 定义的 goal（新格式） | 进入 Phase-Level Sequential Dispatch 模式，每 group 按 4-phase 执行 |
+| 已有 goal 工件（.md 文件） | 兼容。goal 文件格式不变，仅 delegation 执行方式变更 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aipper/aiws-spec",
-  "version": "0.0.36",
+  "version": "0.0.39",
   "description": "AIWS spec and templates (single source of truth).",
   "type": "module",
   "files": [

package/templates/workspace/.opencode/command/ws-goal.md

@@ -11,11 +11,11 @@ description: 目标协议：设定可审计的 goal 目标；依赖链预检；
 ws-goal 只做三件事，不做更多：
 
 | 做 | 不做 |
-|---|---|
-| 录入目标（写 `.aiws/goals/<id>.md`） | 创建/驱动 change（那是 ws-plan/ws-dev） |
+|---|---|---|
+| 录入目标（写 `.aiws/goals/<id>.md`） | 直接在 main session 创建/驱动 change（通过 pipeline subagent 委托执行） |
 | 依赖链预检（上游死 change → 阻断） | 评估复杂度、路由执行路径 |
 | 完成审计（claim done 时验证 outcome） | git add/commit/push、finish |
-| 记录 target_base_branch 约束 | auto-chain 到下一个 goal |
+| 记录 target_base_branch 约束 | auto-chain 到下一个 goal（但在同一 goal 内支持多组顺序调度 §6） |
 
 超出以上范围的需求，路由到对应 ws-* 技能，ws-goal 不碰。
 
@@ -112,40 +112,155 @@ ws-goal 只做三件事，不做更多：
         - **先清理** → goal status=paused，输出清理建议步骤，结束
      用户未确认前，不得进入 step 5。
 
-5) **Pipeline Delegation**：依赖链预检 + workspace 分析通过后，将 goal 完整执行委托给管道 agent。
-   前置条件：step 4 必须通过（ALL HEALTHY 或 UNHEALTHY 已显式放行）。若 step 4 阻断，则不允许 delegation。
-   a) 读取 goal 文件，评估复杂度：
-      - 简单（配置/doc/规范，≤5 文件，低风险）→ delegate 到 ws-dev-lite
-      - 复杂（代码改动 >5 文件，多模块，架构/迁移风险）→ delegate 到完整 pipeline
-   b) 构造 delegation prompt，包含：
-      - goal 文件完整路径与内容（含 target_base_branch、dependency chain 验证结果）
-      - 真值文件路径（AI_PROJECT.md / REQUIREMENTS.md / AI_WORKSPACE.md）
-      - 强制 pipeline 步骤（见下方 c）
-      - 完成条件：goal 文件的 Verification 字段全部通过
-   c) 强制 pipeline 步骤（子 agent 必须依次执行，不得跳过）：
-      1. 如果 change 不存在：`aiws change start <goal-id> --allow-dirty`，base_branch 必须用 goal 的 target_base_branch
-      2. 写 proposal.md：绑定 goal 的 outcome 到 Req_ID，plan_file 指向即将生成的 plan
-      3. 写 plan 文件：`plan/<timestamp>-<goal-id>.md`，含验证命令与预期
-      4. 运行 plan-verify：`aiws plan-verify <plan-file>` 或等效检查
-      5. 实现代码改动（ws-dev）：按 plan 实施，边改边验证
-      6. review 检查：lint/typecheck/code review 按 ws-review 标准
-      7. 提交：`ws-commit`（或等效 git add + commit）
-      8. 收尾：`ws-finish`（fast-forward 合并 + 推送）
-      9. 更新 goal status=complete：修改 goal 文件中的 state 字段
-      「not applicable」步骤可跳过，但必须说明理由
-   d) 使用 task 委托：
-      - 简单 → `task(category="quick", load_skills=[], ...)`
-      - 复杂 → `task(category="deep", load_skills=[], ...)` 或 `task(subagent_type="general", ...)`
-   e) 委托任务执行完成后：
-      - 收集子 agent 的输出，逐项对照 goal 文件的 Verification 字段做完成审计
-      - 全部通过 → 更新 goal state=complete，输出 "Goal <goal-id> complete"
-      - 有未通过 → 更新 goal state=paused，记录 blocker 到 Audit Trail，输出 "Goal <goal-id> paused: <reason>"
-      - 若子 agent 返回了未完成的 pipeline 状态（只有部分步骤完成），在 goal 文件的 Progress Notes 中记录进展，标记 goal state=paused 并输出当前进度
-    f) 判断平台是否支持 task 委托：
-       - 调用 `task(category="quick", load_skills=[], description="probe", prompt="probe", run_in_background=true)`
-       - 若返回有效的 task_id/session_id → 支持委托，走 e)
-       - 若返回错误或无 session_id → 不支持委托
-       - 不支持时：在本会话中亲自执行 c) 的 pipeline 步骤，全部完成后更新 goal status=complete
+5) **Phase-Level Pipeline Delegation**：依赖链预检 + workspace 分析通过后，将 goal 拆分为 PLAN→DEV→REVIEW→FINISH 四个 phase 顺序执行，每个 phase 委托给独立轻量子 agent，主 session 验证每个 phase 产出后决定继续/重试/暂停。
+    前置条件：step 4 必须通过（ALL HEALTHY 或 UNHEALTHY 已显式放行）。若 step 4 阻断，不允许 delegation。
+    前置条件 2：不存在 status=active 的 change 分支。若有，让用户选择「使用已有 change 继续」或「暂停」。
+
+5a) **Check for Groups**：读取 goal 文件，检查是否定义了 `Groups` 区域。
+    - 若 goal **不含** groups → 走单组 phase-level pipeline（step 5b-5g）
+    - 若 goal **包含** groups → 走 Sequential Group Phase-Level Dispatch（step 5.1）
+
+--- 以下为 phase-level pipeline（无 groups 的 goal） ---
+
+5b) **Phase-Level Sequential Execution**：主 session 按 PLAN→DEV→REVIEW→FINISH 顺序执行 4 个 phase，每个 phase 前检查当前进度（支持断点续跑）。共用一个 change 分支，change id = goal-id。
+
+5c) **PHASE 1 - PLAN**（主 session 执行 change start + 委托子 agent 做 plan）：
+    1. 主 session 执行 `aiws change start <goal-id> --allow-dirty`（若 change 已存在则跳过）
+    2. 委托子 agent 执行 PLAN phase：
+        ```
+        task(
+          category="unspecified-high",
+          description="PLAN phase for goal <goal-id>",
+          prompt="TASK: Write proposal.md + plan file + run plan-verify for goal <goal-id>.
+                  INPUT: goal file at .aiws/goals/<goal-id>.md, truth files at AI_PROJECT.md/REQUIREMENTS.md/AI_WORKSPACE.md.
+                  CONSTRAINTS: Do NOT implement code. Do NOT do review. Do NOT commit.
+                  COMPLETION: proposal.md exists, plan file exists, plan-verify passes."
+        )
+        ```
+    3. 主 session 验证产出：
+        - proposal.md 文件存在
+        - plan 文件存在
+        - plan-verify 通过
+    4. 验证通过 → 进入 PHASE 2
+    5. 验证失败 → 可重试最多 2 次 → 仍失败则 goal state=paused，记录 blocker
+
+5d) **PHASE 2 - DEV**（委托子 agent 做 dev）：
+    1. 委托子 agent 执行 DEV phase：
+        ```
+        task(
+          category="deep",
+          description="DEV phase for goal <goal-id>",
+          prompt="TASK: Implement all code changes per plan for goal <goal-id>.
+                  INPUT: proposal.md at .aiws/changes/<goal-id>/proposal.md, plan file.
+                  CONSTRAINTS: Do NOT modify proposal or plan files. Do NOT commit.
+                  COMPLETION: All changes implemented, lint/typecheck clean."
+        )
+        ```
+    2. 主 session 验证产出：
+        - diagnostics 干净（`lsp_diagnostics` 检查改动文件）
+        - 改动范围与 plan 一致
+    3. 验证通过 → 进入 PHASE 3
+    4. 验证失败 → goal state=paused，记录 blocker
+
+5e) **PHASE 3 - REVIEW**（委托子 agent 做 review）：
+    1. 委托子 agent 执行 REVIEW phase：
+        ```
+        task(
+          category="unspecified-high",
+          load_skills=["review-work"],
+          description="REVIEW phase for goal <goal-id>",
+          prompt="TASK: Audit code changes for goal <goal-id>, produce review evidence.
+                  INPUT: proposal.md, plan file, changed files.
+                  CONSTRAINTS: Do NOT modify code. Do NOT commit.
+                  COMPLETION: Review evidence files exist, no HIGH blockers."
+        )
+        ```
+    2. 主 session 验证产出：
+        - review 证据文件存在
+        - 无未解决的 HIGH blocker
+    3. 验证通过 → 进入 PHASE 4
+    4. 验证失败 → goal state=paused，记录 blocker
+
+5f) **PHASE 4 - FINISH**（委托子 agent 做 commit + finish）：
+    1. 委托子 agent 执行 FINISH phase：
+        ```
+        task(
+          category="quick",
+          load_skills=["git-master"],
+          description="FINISH phase for goal <goal-id>",
+          prompt="TASK: Commit and finish (merge + push) for goal <goal-id> change branch.
+                  CONSTRAINTS: Do NOT modify code. Git operations only.
+                  COMPLETION: Change branch merged to target_base_branch and pushed."
+        )
+        ```
+    2. 主 session 验证产出：
+        - 确认 change 分支已合并到 target_base_branch
+        - 确认已推送
+    3. 验证通过 → goal state=complete，输出 "Goal <goal-id> complete"
+    4. 验证失败 → goal state=paused，记录 blocker
+
+5g) **Simple Goal Escape Hatch**：若 goal 为简单改动（≤3 文件，配置/doc/规范变更，无架构风险）：
+    - 可跳过 PHASE 3（REVIEW），在 PHASE 2 验证后直接进入 PHASE 4
+    - 必须在 goal 文件的 Progress Notes 标注 "skipped review phase (simple goal)"
+
+--- 以下为 Sequential Group Phase-Level Dispatch（含 groups 的 goal） ---
+
+5.1) **Sequential Group Phase-Level Dispatch**：
+     当 goal 文件包含 Groups 定义时，ws-goal 按依赖顺序逐个调度每个 group，每个 group 内按 5c-5f 的 4-phase 流程执行。主 session 负责编排每个 group 的 4 个 phase 并验证每个 phase 的产出。
+
+5.1a) **解析并验证 groups**：
+     - 提取 goal 文件中所有 group 定义（id, scope, verification, depends_on, status）
+     - 验证 DAG：无循环依赖，depends_on 引用正确的已知 group
+     - 将所有 group status 初始化为 `pending`
+     - 若解析失败（格式错误、循环依赖）→ 输出错误，不允许 delegation
+
+5.1b) **计算拓扑顺序**：
+     - 按 depends_on 确定执行顺序。默认：声明顺序
+     - 输出 group 执行计划列表：
+       ```
+       ═══ Group 执行计划 ═══
+       [1] group-1: Foundation Pages（depends_on: none）
+       [2] group-2: Purchase Conversion（depends_on: group-1）
+       [3] group-3: Account & Orders（depends_on: group-1）
+       ═══════════════════════════
+       ```
+     - 展示计划后要求用户确认是否继续。用户确认后才开始调度
+
+5.1c) **按顺序执行每个 group（phase-level）**：
+     FOR each group in 拓扑顺序：
+       1. 更新 group status → `in_progress`，写入 goal 文件 Progress Notes
+       2. **PHASE 1 - PLAN**（同 5c，但 change id = `<goal-id>-<group-id>`）：
+          - 主 session 执行 `aiws change start <goal-id>-<group-id> --allow-dirty`
+          - 委托子 agent 写 proposal.md + plan 文件 + plan-verify
+          - 主 session 验证：proposal/plan 存在，plan-verify 通过
+       3. **PHASE 2 - DEV**（同 5d，scope 限定到当前 group）：
+          - 委托子 agent 按 plan 实现当前 group 的代码改动
+          - 主 session 验证：diagnostics 干净，改动匹配 group scope
+       4. **PHASE 3 - REVIEW**（同 5e，scope 限定到当前 group）：
+          - 委托子 agent 审计当前 group 改动
+          - 主 session 验证：review 证据存在，无 HIGH blocker
+       5. **PHASE 4 - FINISH**（同 5f）：
+          - 委托子 agent 做 commit + finish
+          - 主 session 验证：分支已合并推送
+       6. 任一 phase 失败 → group status = paused/failed，记录 blocker，**STOP**（后续 group 不再调度）
+       7. 全部 phase 通过 → 更新 group status → `complete`，更新 Progress Notes
+          - 若 goal 配置了多组并行：可在 PLANNING 通过且 DAG 无冲突前提下的顺序执行
+
+5.1d) **所有 group 完成后**：
+     - 运行整体完成审计：
+       - goal 级别的 outcome 是否满足
+       - 所有 group 均为 complete（无 paused/failed）
+       - 全局 lint/type 检查无新增错误
+       - 输出每 group 结果 + 整体结论
+     - 全部通过 → 更新 goal state=complete，输出 "Goal <id> complete（<N> groups executed）"
+     - 有未通过 → 更新 goal state=paused
+
+5.1e) **恢复机制**（下一 session 进入 step 0 时触发）：
+     - 检测到 paused goal 且含 groups → 输出恢复选项：
+       - （a）重试失败的 group（从失败的 phase 重新开始）
+       - （b）跳过该 group（标记 complete，继续下游）
+       - （c）暂停并 handoff
+     - 用户选择后执行对应操作
 <!-- AIWS_MANAGED_END:opencode:ws-goal -->
 
 可在下方追加本项目对 OpenCode 的额外说明（托管块外内容会被保留）。

package/templates/workspace/.opencode/skills/ws-goal/SKILL.md

@@ -9,13 +9,13 @@ description: 目标协议：设定可审计的 goal 目标；依赖链预检；
 目标：
 - 将用户需求转化为可审计的 goal 目标，按 ws-goal-contract.md 的目标模板写入目标文件。
 - 依赖链预检：阻断"死 change 阻塞下游"这类 chain 问题。
-- 管道委托：预检通过后将完整 pipeline 委托给子 agent（从 ws-plan 一路走到 ws-finish）。
+- 管道委托：预检通过后将 goal 拆分为 phase-level 子任务（PLAN→DEV→REVIEW→FINISH），每个 phase 委托给独立轻量子 agent，主 session 编排调度与验证。
 - 完成审计：claim done 时验证 outcome 真伪。
 
 ws-goal 不做的事：
-- 不直接创建 change、不直接写 code
+- 不直接在 main session 操作 change 或写代码（通过 pipeline subagent 委托执行）
 - 不替换 review/commit/finish 门禁
-- 不 auto-chain 到下一个 goal
+- 不 auto-chain 到下一个 goal（但在同一 goal 内支持多组顺序调度 §6）
 
 前置条件：
 1) 先运行 `/ws-preflight`（对齐 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`）。
@@ -29,4 +29,4 @@ ws-goal 不做的事：
 3) 按 ws-goal-contract.md 的目标模板生成目标文件，写入 `.aiws/goals/<goal-id>.md`。
 4) 输出 completion audit checklist，列出每个 goal 的完成标准与验证方式。
 5) **Workspace State Analysis**：分析 dirty/submodule/change artifacts/git 状态，输出影响等级报告，用户确认后才能继续。参考 `/ws-goal` command 的 step 4.5 完整流程。
-6) **Pipeline Delegation**：预检 + 分析通过后，将 goal 完整执行委托给管道 agent。参考 `/ws-goal` command 的 step 5 完整流程。
+6) **Phase-Level Pipeline Delegation**：预检 + 分析通过后，将 goal 拆分为 PLAN→DEV→REVIEW→FINISH 四个 phase 顺序执行，每个 phase 委托给独立轻量子 agent，主 session 验证每个 phase 产出后决定继续/重试/暂停。参考 `/ws-goal` command 的 step 5 完整流程。