@namewta/speculo 0.6.0 → 0.7.0

package/template/workflows/specdev/INDEX.md

@@ -3,8 +3,8 @@ id: specdev
 type: workflow
 workflow: specdev
 name: SpecDev Workflow
-description: 从请求摄入、诊断、设计、规格、决策完备 Ticket、跨 Ticket 编排，到证据驱动实现、架构审查与知识归档的完整研发治理工作流。
-keywords: [specdev, 规格驱动开发, decision-complete, ticket, goal-plan, TDD, 证据, 治理]
+description: 以本地工件为唯一开发权威，从来源冻结、诊断、设计、原型、规格、Ticket、编排和审查推进到证据驱动实现、远程 reconcile 与知识归档。
+keywords: [specdev, local-first, 规格驱动开发, decision-complete, prototype, code-review, TDD, 证据]
 ---
 
 # SpecDev Workflow
@@ -21,9 +21,11 @@ SpecDev 将“理解、决定、规划、执行、验证、沉淀”拆成职责
 ## 工件链
 
 ```text
-外部请求、Issue 或对话
+远程 Issue、指定内容或对话
         ↓
-Triage / Diagnose / Grill / Wayfinder / Architecture Review
+Triage 冻结为本地 Source
+        ↓
+Diagnose / Grill / Wayfinder / Prototype / Code Review / Architecture Review
         ↓
 Spec             外部行为、范围、验收合同与关键约束
         ↓
@@ -37,11 +39,15 @@ Implement        在既定契约内设计、TDD、审查、验证和交接
         ↓
 Evidence         实际修改、命令、结果、偏差和残余风险
         ↓
+Triage           本地完成后按确认回写/关闭支持的远程 Issue
+        ↓
 Archive          归档历史并将经验证知识提升为当前长期知识
 ```
 
 核心状态工件：
 
+- `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
@@ -50,6 +56,9 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 - `<Path>{roots.state}/specdev/changes/{change}/wayfinder-map.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/investigation/</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/evidence/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/reviews/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/prototypes/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/questionnaires/</Path>`
 
 工件职责和冲突裁决位于 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>`。
 
@@ -61,25 +70,24 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 - 活跃 change：`<Path>{roots.state}/specdev/changes/</Path>`
 - 历史归档：`<Path>{roots.state}/specdev/archive/</Path>`
 
-初始化设置 work 首次运行时生成：
+初始化设置 work 首次运行时生成配置并创建空的永久 namespace：
 
 - 全局配置：`<Path>{roots.state}/specdev/config.json</Path>`
 - 追踪规则：`<Path>{roots.state}/specdev/.config/tracking.md</Path>`
 - 领域布局：`<Path>{roots.state}/specdev/.config/domain-layout.md</Path>`
-- 状态标签：`<Path>{roots.state}/specdev/.config/status-labels.md</Path>`
-
-经 change 产物确认后按需创建：
-
 - 永久 ADR：`<Path>{roots.state}/specdev/adr/</Path>`
 - 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
 - 永久研究：`<Path>{roots.state}/specdev/research/</Path>`
 
+初始化只保证永久目录存在，不写知识内容。只有 A-archive-and-consolidate 在 change 完成、实现证据验证、毕业评估和用户确认后，才能创建、合并或改写这些永久 namespace 中的内容；其他 Works 只读。
+
 单个 change 可以包含：
 
 - `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/source-issue.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/diagnostics/</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
@@ -94,6 +102,9 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 - `<Path>{roots.state}/specdev/changes/{change}/architecture-review.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/architecture-review.html</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/evidence/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/reviews/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/prototypes/</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/questionnaires/</Path>`
 
 ## 全局治理原则
 
@@ -106,7 +117,9 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 7. **偏差显式化**：计划与事实冲突时停止、记录、修订，不静默扩大范围或改写契约。
 8. **状态单一来源**：Ticket frontmatter 是单 Ticket 状态权威；Map 和 Goal Plan 是投影与编排。
 9. **知识以当前真相为目标**：归档保留历史，永久知识只保留仍真实且经实现验证的结论。
-10. **恢复依赖权威工件**：跨 Work 或 Agent 边界时同步 `current_work` 与 `work_history`，返回下一 Work 和权威工件的完整路径。
+10. **恢复依赖权威工件**：跨 Work 或 Agent 边界时同步 active change 的 `current_work`，成功完成后去重更新 `works_run`，返回下一 Work 和权威工件的完整路径。
+11. **本地执行权威**：远程 Issue/PR/URL 只作为来源或完成投影；Spec、Ticket、Map、Goal Plan、Evidence 和状态始终以本地工件为准。
+12. **完成与归档分离**：本地完成按 change completion 合同决定；远程 close 失败不回滚完成，但必须 reconcile 或 waive 后才归档。
 
 共享规则：
 
@@ -118,30 +131,33 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 - `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>`
 - `<Path>{roots.workflows}/specdev/common/rules/path-reference-contract.md</Path>`
 - `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`
+- `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`
 
 ## 启动协议
 
 1. 解析 workflow 和 state roots。
 2. 读取 `<Path>{roots.state}/specdev/config.json</Path>`；不存在时运行 `<Path>{roots.workflows}/specdev/I-init-setup/I-init-setup.md</Path>`。
 3. 读取 `<Path>{roots.state}/specdev/status.json</Path>`：用户指定 change 优先；唯一活跃 change 直接使用；无活跃时创建；多个候选时请求消歧。
-4. 在 `<Path>{roots.state}/specdev/status.json</Path>` 写入 work 开始记录，并更新当前 change 的 `current_work`。
+4. 若当前 change 已有非空 `current_work`，先恢复或显式结束该 Work；否则将 `current_work` 设置为本次 work id。
 5. 只加载当前步骤需要的 work 子文件和共享规则。
 6. 完成后写入产物、运行适用校验、更新状态和 `works_run`。
 
+Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`：Goal Plan 含完整委派附录时由 Lead 拥有转换；普通 Goal Plan 或无 Goal Plan 的实现由最后一个 I 拥有；非实现型终点由最终验收工件 owner 拥有。Archive 不补造 completed。
+
 ## 状态字段
 
-`<Path>{roots.state}/specdev/status.json</Path>` 使用 schema v3：
+`<Path>{roots.state}/specdev/status.json</Path>` 使用全局 schema v4；Spec、Ticket 和 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 等领域工件仍使用各自现有 schema：
 
-- `schema_version`（数字）：状态 schema 版本，固定为 `3`。
+- `schema_version`（数字）：全局状态 schema 版本，固定为 `4`。
 - `workflow`（字符串）：workflow 标识，固定为 `"specdev"`。
 - `active`（对象数组）：当前活跃 change；每项包含：
   - `change`（字符串）：change 目录名，格式 `"YYYY-MM-DD-<kebab-topic>"`。
   - `current_work`（字符串或 null）：当前 work id，如 `"specdev/implement"`；无运行中 work 时为 null。
-  - `works_run`（字符串数组）：已运行的 work id。
-  - `result`（字符串或 null）：整体结果；进行中为 null，结束时记录 `"completed"`、`"blocked"` 或 `"cancelled"`。
+  - `works_run`（去重字符串数组）：已成功完成的 work id；重复运行同一 work 不追加副本。
   - `claimed_investigations`（对象数组，可选）：并行调查领取记录；每项包含 `id`、`owner`、可选 `session` 和 `claimed_at`。
-- `work_history`（对象数组）：work 调用记录；每项包含 `change`、`work_id`、`started_at`、`completed_at` 和 `result`。
-- `completed`（对象数组）：已归档 change；每项包含 `change`、`archived_at` 和 `archive_path`。
+- `archived`（去重字符串数组）：已归档 change 名称。详细归档时间、路径和 promotion 摘要只存在于 `<Path>{roots.state}/specdev/archive/YYYY-MM/{change}/.status.json</Path>`。
+
+`active[].change` 必须唯一，且不得同时出现在 `archived`。开始 Work 时设置 `current_work`；暂停或可恢复阻塞时保留；成功完成时加入 `works_run` 并清空；取消时清空但不加入。逐次时间、结果和审计证据由 change 自有状态、Work 主产物、Evidence 或 LOG 承载，不写入全局索引。
 
 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 的 `worktrees` 保存 Ticket 级 `base_sha`、分支、可迁移 `workspace_ref` 和生命周期状态。
 
@@ -159,27 +175,48 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 1. workflow 运行状态写入 `<Path>{roots.state}/specdev/</Path>`。
 2. change 产物写入 `<Path>{roots.state}/specdev/changes/{change}/</Path>`。
 3. 项目代码、测试和用户要求的项目文档写入项目路径；Evidence 仅保存项目相对指针。
-4. 长期知识先在 change 内形成，经确认后提升到对应永久 namespace。
+4. 长期知识候选先在 change 内形成；只有 A 在完成证据、毕业评估和用户确认全部通过后，才提升到对应永久 namespace。
 
 ## 副作用边界
 
-未经用户明确授权不得提交、推送、合并、删除分支或 worktree、部署、发布、移动归档或执行不可逆迁移。只读探索、生成 change 工件和已授权验证可以进行。敏感值不得写入 `<Path>{roots.state}/specdev/</Path>`。
+未经用户明确授权不得提交、推送、合并、删除分支或 worktree、部署、发布、移动归档、写入/关闭远程 Issue 或执行不可逆迁移。只读探索、生成 change 工件和已授权验证可以进行。远程开发投影仅由 Triage reconcile 执行；Retro command 的 Speculo 反馈 Issue 是独立 command 边界。敏感值不得写入 `<Path>{roots.state}/specdev/</Path>`。
+
+## 场景路由
+
+| 场景 | 入口 | 正常出口 |
+|---|---|---|
+| 远程 Issue、URL、文件或对话摄入 | T-triage intake | D / G / W / P / S / C / T |
+| 本地 change 完成且来源可关闭 | T-triage reconcile | A |
+| 疑难 bug 或性能回归 | D-diagnose-bugs | S / T / I / R / W |
+| 模糊但可通过决策访谈收敛 | G-grill-with-docs | P / S / T / W |
+| 路径超出单次上下文 | W-wayfinder | G / P / D / S / T |
+| 需要用代码回答逻辑/UI 问题 | P-prototype | G / S / T / I |
+| 固定点 diff、branch 或 PR review | C-code-review | completed / T / S / G |
+| 外部行为已清楚 | S-spec | T-tickets |
+| Ready Spec 需要垂直切片 | T-tickets | P-goal-plan / I |
+| 多 Ticket 协调 | P-goal-plan | I / Triage / A |
+| Ready 执行 | I-implement | Triage / A / blocked / deviation |
+| 架构健康扫描 | R-review-architecture | G / T |
+
+同 change 下一阶段需要当前一手推理且上下文健康时继续；切换 repo/person/harness 或旁路时使用 `<Path>{roots.commands}/handoff.md</Path>`；严格限定且可独立派单时使用 Dispatch Packet；其他长上下文以权威工件路径恢复。平台不支持 clear/compact 时不虚构操作。
 
 ## Work 条目
 
 <!-- AUTO-INDEX-START -->
 
-- **A-archive-and-consolidate** — 归档与沉淀：双模式沉淀 Work——归档已验证完成的 change 并提升其知识，或在没有可归档 change 时以当前代码为基本事实深度访谈用户，把经验证的架构决策与领域术语提升为永久知识。
-- **D-diagnose-bugs** — 诊断 Bug：通过复现、反馈回路、可证伪假设与最小插桩定位根因，输出修复契约而不是猜测性补丁。
+- **A-archive-and-consolidate** — 归档与沉淀：校验本地完成与远程 reconcile 门，复用全局归档能力移动 completed change 并提升当前知识，或从代码访谈形成可归档知识 change。
+- **C-code-review** — 代码审查：将 commit、branch、tag、merge-base 或 PR 解析为本地不可变固定点，执行隔离的标准轴与规范轴审查并持久化可恢复报告。
+- **D-diagnose-bugs** — 诊断 Bug：先建立会在精确症状上变红的紧凑反馈回路，再通过最小化、排名假设和单变量探针确认根因，输出修复契约而不实施生产修复。
 - **E-engineering-cognitive-mentor** — 工程认知导师：面向 Bug、项目源码、需求技术方案、架构设计与陌生技术领域的非执行型认知指导 Work；以证据、因果 Why、候选方案对比和逐轮澄清帮助用户形成可复述理解，并将完整问答轨迹持续持久化到当前 change。
-- **G-grill-with-docs** — 设计访谈（带文档）：以完整 frontier 逐轮推进设计树，直到每个决策分支都已关闭并获得用户共识，同时持续维护设计树、日志、领域上下文和架构决策。
+- **G-grill-with-docs** — 设计访谈（带文档）：以完整 frontier 逐轮推进设计树，直到每个决策分支都已关闭并获得用户共识，同时持续维护当前 change 的设计树、日志、领域上下文和架构决策。
 - **I-implement** — 实现：基于 Ready Ticket 或获批的小型 Spec 执行设计检查、TDD 红绿循环、持续验证、双轴审查、证据回写和提交。
-- **I-init-setup** — 初始化设置：初始化 SpecDev 的语言、配置、全局状态、追踪约定、领域知识布局、验证命令和并发治理。
-- **P-goal-plan** — 目标规划：在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 编排计划。
+- **I-init-setup** — 初始化设置：初始化 SpecDev 的语言、配置、全局状态、本地 change 追踪、领域知识布局、验证命令和并发治理。
+- **P-goal-plan** — 目标规划：在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 计划，并仅在用户选择时加入严格角色委派。
+- **P-prototype** — 原型：在获授权的临时 branch/worktree 中构建一次性 Logic 或 UI 原型，回答一个明确设计问题并持久化答案、资产定位和清理状态。
 - **R-review-architecture** — 架构审查：从用户指定范围或 Git 热点扫描代码库的深化机会，以持久化可视化 HTML 呈现候选，并对用户选择的一个方案运行设计树访谈。
 - **S-spec** — 编写 Spec：综合已知事实、设计决定、诊断与代码现状，产出以外部行为和验收合同为权威的 Ready Spec。
 - **T-tickets** — 拆分 Tickets：将 Spec、计划或已确认对话拆成曳光弹式垂直切片；每个 Ticket 决策完备、可独立验证、适配单一上下文，并建立阻塞 DAG、路径所有权和执行就绪门禁。
-- **T-triage** — 请求分诊：完整摄入外部请求，判断问题类型、影响、风险、缺失信息和下一 work，不在分诊阶段过早设计或实现。
+- **T-triage** — 请求分诊：把远程 Issue、URL、文件或对话冻结为本地来源工件，完成风险分诊与路由，并在本地 change 完成后受控回写和关闭支持的远程 Issue。
 - **W-wayfinder** — 寻路：为超出单次会话且路径尚不可见的工作建立本地共享地图，逐个解决 research、prototype、grilling 或 task Ticket，直到目的地路线决策完备。
 
 <!-- AUTO-INDEX-END -->
@@ -198,6 +235,7 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage <triage|diagnosis|grill|spec|tickets|goal-plan|implement|review|prototype|wayfinder|complete> \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 

package/template/workflows/specdev/P-goal-plan/P-goal-plan.md

@@ -3,13 +3,15 @@ id: specdev/goal-plan
 type: workflow-entry
 workflow: specdev
 name: 目标规划
-description: 在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 编排计划。
+description: 在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 计划，并仅在用户选择时加入严格角色委派。
 keywords: [目标规划, 编排, DAG, Gate, Wave, Lead, Subagent, checkpoint, 派单, 迁移, 证据]
 ---
 
 # 目标规划
 
-Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序、并发、共享所有权、里程碑 Gate、Agent 交付、集成验证、迁移与发布顺序、偏差升级和恢复。它不是 Ticket 的放大版，也不按固定章节数量衡量质量；每个 Ticket 的独立 Dispatch Packet 是 Goal Plan 的执行入口，不是第二份 Ticket。
+Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序、并发、共享所有权、里程碑 Gate、集成验证、迁移与发布顺序、偏差升级和恢复。它不是 Ticket 的放大版，也不按固定章节数量衡量质量。
+
+Lead/subagent 是可选的委派分支，不是 Goal Plan 的固有角色。每次运行都先由用户选择普通 Goal Plan 或委派 Goal Plan；普通计划不写 execution model、Lead、Provider、Delivery Contract、Dispatch Packet、Worker、会话 locator 或修正轮次，也不写“未启用”或“不适用”占位。
 
 产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
 
@@ -18,7 +20,7 @@ Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序
 满足任一条件时运行：
 
 - 多个 Ticket 可以或需要并行；
-- 存在 shared path、共享合同、集中 owner 或 Lead/Subagent；
+- 存在 shared path、共享合同或集中 owner；
 - 存在 Deep Ticket、expand-contract、数据迁移、兼容窗口或不可逆步骤；
 - 存在多个里程碑、外部审批、发布窗口、参考符合性或高事故半径；
 - Ticket DAG 虽不大，但关键路径、汇合点或恢复策略不能仅由 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 安全表达；
@@ -48,20 +50,21 @@ Spec 或 Tickets Map 不存在时，返回 `<Path>{roots.workflows}/specdev/S-sp
 
 ## 流程
 
-### 1. 验证上游与选择规划模式
+### 1. 验证上游并确认角色分支
 
 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`：
 
 1. 验证 Spec Ready、Ticket Ready、合同覆盖、DAG、路径所有权和 Deep Ticket 完整性；
 2. 只读探索会影响调度的代码事实和项目约束；
 3. 识别 coordination、migration、high-assurance、reference-conformance 等可组合规划模式；
-4. 在 `direct`、`native-subagent`、`external-web-subagent` 中选择唯一 execution model，并固定 Lead、源码 checkpoint、上下文交付和逐动作授权；
-5. 只对无法发现且会改变 Gate、Wave、owner、执行模型、迁移或批准点的问题向用户提问；
-6. 不熟悉的外部标准或依赖使用 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`。
+4. 每次向用户询问选择普通 Goal Plan 或委派 Goal Plan，不按复杂度静默启用角色委派；
+5. 用户选择委派时，再在 `native-subagent` 与 `external-web-subagent` 中选择实际交付通道；普通分支不形成或持久化执行模式；
+6. 只对无法发现且会改变 Gate、Wave、owner、迁移或批准点的问题继续提问；
+7. 不熟悉的外部标准或依赖使用 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`。
 
 任何硬停止问题都必须退回拥有该决策的上游工件，不得用 Goal Plan 覆盖。
 
-### 2. 构建跨 Ticket 执行模型
+### 2. 构建跨 Ticket 核心计划
 
 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
 
@@ -69,13 +72,24 @@ Spec 或 Tickets Map 不存在时，返回 `<Path>{roots.workflows}/specdev/S-sp
 2. 将 Ready 且项目写路径不相交的 Ticket 分配到 Wave；
 3. 为 shared path、共享合同和集中变更指定唯一 owner；
 4. 为行为闭环、合同稳定、迁移完成、发布就绪等关键状态定义 Gate；
-5. 明确 expand → migrate → contract、Evidence 返回和集成规则；并行写代码时使用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；
-6. 以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，生成里程碑 Delivery Contract 和每个 Ticket 可独立投递的 Dispatch Packet；
-7. 派单块只携带实现所需的权威引用、边界、基线、验证、恢复和返回字段，不复制完整历史对话或 Ticket 全文。
+5. 明确 expand → migrate → contract、Evidence 返回和集成规则；
+6. 定义每个 Ticket 的开始条件、执行顺序、验证、Evidence 目标和失败恢复，不复制 Ticket 全文。
+
+**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个计划 Ticket 都有唯一 owner、可验证开始条件、Evidence 目标和恢复路径。
+
+### 3. 按确认加载委派分支
 
-**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个计划 Ticket 都有唯一 owner、基线和可恢复派单块。
+只有用户在本次运行选择委派 Goal Plan 时：
 
-### 3. 定义整体完成、证据与恢复
+1. 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution.md</Path>`；
+2. 以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`；
+3. 固定唯一 Lead、native/external provider、不可变 checkpoint、可恢复 locator、逐动作授权和修正上限；
+4. 生成里程碑 Delivery Contract 与每个 Ticket 的独立 Dispatch Packet；
+5. 并行写代码时按需调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`。
+
+普通 Goal Plan 跳过本步骤，不加载上述委派能力，也不在最终产物中留下该分支的标题、字段或占位。
+
+### 4. 定义整体完成、证据与恢复
 
 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
 
@@ -83,16 +97,16 @@ Spec 或 Tickets Map 不存在时，返回 `<Path>{roots.workflows}/specdev/S-sp
 2. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
 3. 固化跨 Ticket 不可协商约束；
 4. 区分不可违反约束与可由实现者调整的建议；
-5. 定义实测基线、反向验证、防伪完成、偏差等级、修正上限、暂停范围、批准人和恢复动作；
+5. 定义实测基线、反向验证、防伪完成、偏差等级、暂停范围、批准人和恢复动作；
 6. 定义进度回报、Evidence 汇总、残余风险和回滚要求。
 
-**完成标准**：所有完成声明能映射到实际命令、代码状态、Evidence 或人工批准；没有 provider 自报即通过的门禁。
+**完成标准**：所有完成声明能映射到实际命令、代码状态、Evidence 或人工批准；没有自报即通过的门禁。
 
-### 4. 写入自适应 Goal Plan
+### 5. 写入自适应 Goal Plan
 
 使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
 
-模板包含六个职责区，但只保留适用内容：
+核心模板包含六个职责区，但只保留适用内容：
 
 1. Outcome and Authority；
 2. Execution Graph；
@@ -101,51 +115,46 @@ Spec 或 Tickets Map 不存在时，返回 `<Path>{roots.workflows}/specdev/S-sp
 5. Constraints, Risk and Recovery；
 6. Progress and Decisions。
 
-Ticket 较多时在 Execution Graph 内增加速查表；不创建独立的第二套状态来源。
-
-Goal Plan 不受单次 `/goal` 字符上限约束。需要粘贴到外部 Agent 时，只投递对应 Ticket 的 Dispatch Packet 及其指向的权威材料。
+用户选择委派时，在第 4 节加入 `<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution-template.md</Path>` 的完整内容；没有选择时不加入任何委派痕迹。Ticket 较多时在 Execution Graph 内增加速查表，不创建独立的第二套状态来源。
 
-### 5. 同步与验证
+### 6. 同步与验证
 
 1. 将 Wave、Gate 和 owner 投影同步到 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`；
-2. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；
+2. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；schema 不记录角色分支；
 3. 运行：
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage goal-plan \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 
 4. 更新 `<Path>{roots.state}/specdev/status.json</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>`；
-5. 原子写入 Goal Plan 和同步投影后重新读取，确认 execution model、Lead、checkpoint、授权、Wave/Gate 与派单块一致；
-6. 向用户汇报规划模式、execution model、关键路径、Wave、Gate、shared owner、checkpoint、迁移策略、主要风险和 Ready 状态；
+5. 原子写入 Goal Plan 和同步投影后重新读取，确认核心 DAG/Wave/Gate/owner/授权一致；存在委派附录时额外确认 Lead、checkpoint、locator、Delivery Contract 与 Dispatch Packet 完整一致；
+6. 向用户汇报规划模式、关键路径、Wave、Gate、shared owner、迁移策略、主要风险和 Ready 状态；选择委派时再汇报交付通道与 Lead；
 7. 未经用户要求，不自动进入实现。
 
 ## 决策完备标准
 
-Goal Plan 必须让执行 Lead 或实现者无需重新决定：
+每份 Goal Plan 必须让实现者无需重新决定：
 
 - 跨 Ticket 先后、并发 Wave 和关键汇合点；
 - shared path 与共享合同的 owner；
 - Gate 开启、关闭和证据；
 - 迁移、兼容、收缩、发布和回滚顺序；
-- Agent 派单上下文、Evidence 返回和集成规则；
-- execution model、Lead、checkpoint、上下文交付、修正上限和逐动作授权；
-- 偏差等级、暂停范围和批准路径。
+- Evidence 返回、集成、偏差、暂停和批准路径。
 
-Goal Plan 不应重复：
+委派 Goal Plan 还必须锁定 Agent 派单上下文、execution model、Lead、checkpoint、locator、修正上限和逐动作授权。普通 Goal Plan 不包含这些内容。
 
-- Ticket 的完整局部执行路线；
-- 每个 Ticket 的全部文件预测；
-- 每条局部验收 checklist；
-- Spec 中的完整用户故事和产品背景。
+Goal Plan 不应重复 Ticket 的局部执行路线、全部文件预测、局部验收 checklist 或 Spec 的完整用户故事。
 
 ## 完成标准
 
 - `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` 已写入且只包含适用内容；
 - 所有计划内 Ticket Ready，DAG 无环，合同覆盖明确；
 - Wave、Gate、owner、集成、偏差和恢复可执行；
-- 每个计划 Ticket 的 Dispatch Packet 可独立定位权威输入、路径合同、验证和恢复点；
+- 普通计划没有委派角色、交付合同或空占位；
+- 委派计划的 Delivery Contract 与每个 Dispatch Packet 完整可恢复；
 - Tickets Map 投影已同步；
 - 无未批准高影响假设或硬停止问题；
 - `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 无 error；
@@ -154,8 +163,9 @@ Goal Plan 不应重复：
 ## 子文件引用
 
 - 规划模式与输入门禁：`<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`
-- DAG、Wave、Gate 与 Lead 编排：`<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`
+- DAG、Wave、Gate 与核心集成：`<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`
+- 委派执行协议：`<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution.md</Path>`，仅用户选择委派时加载
 - 完成、证据、偏差与恢复：`<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`
-- Goal Plan 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
-- 并行 Ticket worktree：`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`
-- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`
+- Goal Plan 核心模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- 委派附录模板：`<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution-template.md</Path>`，仅用户选择委派时加载
+- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，仅用户选择委派时调用

package/template/workflows/specdev/P-goal-plan/completion-control.md

@@ -2,17 +2,7 @@
 
 ## 1. Outcome and Authority
 
-Goal Plan 用紧凑摘要表达：
-
-- 业务或用户目标；
-- 目标受众或运营角色；
-- 所有计划 Ticket 完成后的可观察终态；
-- 关键约束；
-- 明确非目标；
-- 权威来源和冲突规则；
-- 看似有主路径但违反边界、数据、兼容或证据要求的伪完成判据。
-
-不复制 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` 的完整用户故事。
+Goal Plan 用紧凑摘要表达业务目标、受众、所有 Ticket 完成后的可观察终态、关键约束、非目标、权威来源、冲突规则和伪完成判据，不复制 Spec 的完整用户故事。
 
 ## 2. 整体 Definition of Done
 
@@ -20,59 +10,36 @@ Goal Plan 用紧凑摘要表达：
 
 - 所有计划内 Ticket 完成，cancelled 或 deferred 项有批准；
 - 所有 Spec 验收合同和外部符合性要求有 Evidence；
-- 项目类型检查、静态检查、测试、lint、构建和适用 CI 完成，测试数量、skip/todo、覆盖率或等价基线没有未经批准的退化；仅 UI 交互受影响时由 Lead 完成 E2E；
-- 可静默失效的关键门禁完成受控反向验证并恢复绿色；普通门禁有明确不适用结论，不为形式破坏环境；
+- 项目类型检查、静态检查、测试、lint、构建、适用 CI 和受影响 E2E 完成，基线没有未经批准的退化；
+- 可静默失效的关键门禁完成受控反向验证并恢复绿色；
 - 迁移、兼容、调用点清零、监控、回滚和不可逆批准完成；
-- 无未批准偏差和未处置高风险残余问题；
-- Ticket、Map、Goal Plan、Evidence、源码 checkpoint 和状态一致；
-- provider 或 Worker 自报结果均已由 Lead 核对，未核对项保持 `unverified`。
+- 无未批准偏差、未处置高风险残余问题或伪装成通过的 `unverified` 声明；
+- Ticket、Map、Goal Plan、Evidence、代码事实和状态一致。
 
-## 3. Gate 关闭仪式
+## 3. Gate 关闭与 change 完成
 
-每个 Gate 关闭时：
+每个 Gate 关闭时汇总覆盖 Evidence，检查合同、共享接口、数据、兼容、迁移和调用点，运行里程碑验证和适用 E2E，执行必要反向验证，审查偏差/风险/恢复能力，获取适用人工批准，并同步 Goal Plan、Map 和状态。
 
-1. 汇总覆盖的 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`；
-2. 检查对应合同和参考符合性；
-3. 检查共享接口、数据、兼容、迁移和调用点；
-4. 运行里程碑级验证；仅 UI 交互受影响时由 Lead 运行最小 E2E；
-5. 对会出现“坏了但仍绿色”的关键门禁运行受控反向验证，记录失败信号和恢复后的通过证据；
-6. 审查基线退化、失败分类、偏差、残余风险和恢复能力；
-7. 获取适用人工批准；
-8. 同步 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 和状态工件。
-
-## 4. 不可协商约束
+最后一个 Gate 关闭后加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`：
 
-只记录跨多个 Ticket 且不可由实现者改变的规则，例如数据完整性、wire format 兼容、旧协议收缩条件、shared owner、安全要求、发布窗口、回滚演练和批准点。
+- Goal Plan 不含 `## Delegated Execution Addendum` 时，由最后一个计划内 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 汇总并完成 change；
+- Goal Plan 含完整委派附录时，由 Lead 在独立验收后完成 change。
 
-每条约束同时说明违反后果。可由实现者沿现有惯例选择、且不改变行为或风险的事项写入 Guidance，不伪装成硬约束。
+若 triage 的 `external_action` 为 `pending-close` 或 `close-failed`，下一 Work 为 `<Path>{roots.workflows}/specdev/T-triage/T-triage.md</Path>`，否则进入 Archive。远程动作不参与本地 Gate 判断。
 
-来源必须指向：
+## 4. 不可协商约束
 
-- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`；
-- `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`；
-- 具体 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`；
-- 外部 Url 标签；
-- `<Path>{roots.state}/specdev/config.json</Path>`。
+只记录跨多个 Ticket 且不可由实现者改变的规则，例如数据完整性、wire format 兼容、旧协议收缩条件、shared owner、安全要求、发布窗口、回滚演练和批准点。每条约束说明来源和违反后果；可由实现者沿惯例选择的事项写入 Guidance。
 
 ## 5. 偏差与暂停
 
-偏差等级和处理遵循 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>`。
-
-跨 Ticket 偏差还必须明确：
-
-- 暂停哪些 Wave 或 Ticket；
-- 哪个 Gate 重新打开；
-- 哪些 Agent 需要重新基线；
-- 哪些 Evidence 失效；
-- 重新开始的条件。
-
-## 6. 风险、修正与恢复
+偏差遵循 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>`。跨 Ticket 偏差还要说明暂停哪些 Wave/Ticket、重新打开哪个 Gate、哪些执行者需要新基线、哪些 Evidence 失效和恢复条件。
 
-每个高风险项写明：触发信号、事故半径、预防措施、检测方式、恢复动作、owner 和批准点。迁移或发布计划必须给出回滚不可行时的前向恢复方案。
+## 6. 风险与恢复
 
-每个 Dispatch Packet 记录 checkpoint、workspace/session locator、最近已验证 Evidence 和 `max_correction_rounds`。默认同一验收项最多修正 3 轮；达到上限后暂停当前 Ticket 和受影响 Wave，保留已通过行为，形成包含失败命令、最小错误、责任方和恢复条件的 blocker。
+每个高风险项写明触发信号、事故半径、预防、检测、恢复、owner 和批准点。迁移或发布计划必须给出回滚不可行时的前向恢复方案。
 
-恢复时依次读取 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`、当前 Ticket、最新 Evidence 和 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>`。从最后已验证 checkpoint 继续，不重复询问已确认事实，也不创建额外进度或阻塞文件。
+恢复时依次读取 Goal Plan、当前 Ticket、最新 Evidence 和 change 状态，从最后已验证事实继续，不重复询问已确认事项，也不创建额外进度或阻塞文件。委派专属的 checkpoint、locator 和修正轮次由委派附录管理。
 
 ## 7. 进度与决策回报
 
@@ -82,11 +49,10 @@ Goal Plan 用紧凑摘要表达：
 WAVE_STATUS wave=<n> ready=<ids> active=<ids> done=<ids> blocked=<ids>
 GATE_STATUS gate=<name> state=open|closed evidence=<paths> risks=<summary>
 TICKET_STATUS id=<id> state=<state> evidence=<path> deviation=<none|id>
-DELIVERY_STATUS id=<id> model=<model> checkpoint=<sha> locator=<ref> corrections=<n> unverified=<items|none>
 BLOCKER id=<id> owner=<owner> needed=<decision-or-input> impact=<scope>
 DECISION id=<id> owner=<owner> status=pending|approved|rejected impact=<scope>
 ```
 
-具体路径必须以完整 Path 标签 形式填写。
+委派 Goal Plan 的交付状态格式由委派协议提供，不加入普通 Goal Plan。
 
-**完成标准**：进度可由权威工件恢复；所有通过、阻塞和未验证声明均能定位到具体 Evidence 与源码 checkpoint。
+**完成标准**：进度可由权威工件恢复；普通计划由最后一个 Implement 完成，委派计划由 Lead 完成；所有通过、阻塞和未验证声明均能定位到具体 Evidence 与代码事实。

package/template/workflows/specdev/P-goal-plan/delegated-execution-template.md

@@ -0,0 +1,33 @@
+## Delegated Execution Addendum
+
+### Delivery Contract
+
+| 字段 | 值 |
+|---|---|
+| Execution model | native-subagent / external-web-subagent |
+| Lead / Provider | `<owner>` / `<provider>` |
+| Repository / Branch | `<repository-or-local>` / `<branch>` |
+| Checkpoint policy | immutable SHA / equivalent fixed baseline |
+| Source delivery | repository-url / source-package / combination |
+| Max concurrency / corrections | `<n>` / `3` |
+| Review | standards + spec + Lead verification + conditional E2E |
+
+### Per-Ticket Dispatch Packets
+
+#### Dispatch: T-01
+
+- **Goal / observable result：**
+- **Priority on conflict：** correctness > contract completeness > speed，或当前项目裁决
+- **Implement / Ticket：** `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`；`<Path>{roots.state}/specdev/changes/{change}/ticket/01-<name>.md</Path>`
+- **Authority / dependencies：** 相关合同、ADR/CONTEXT、已完成依赖 Evidence
+- **Wave / Gate / hard constraints：**
+- **Writable / read-only / shared owner：**
+- **Baseline / branch / workspace or session locator / package hash：**
+- **Preflight receipt：** 在 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` 记录目标、顺序、最大风险和基线差异，不超过 10 行
+- **Verification / baseline / reverse check：**
+- **Authorization / deviation / correction limit：**
+- **Return：** 状态、Evidence、locator、最终 checkpoint、commit/PR、未验证项、待 Lead E2E
+
+### Candidate Delivery Return and Lead Integration
+
+Worker 将 Ticket 推进到 `review` 并返回候选交付；Lead 负责独立验证、适用 E2E、集成、Gate 关闭和 worktree 收尾。达到修正上限时保留最后可信 checkpoint、失败命令、已通过行为和恢复条件。

package/template/workflows/specdev/P-goal-plan/delegated-execution.md

@@ -0,0 +1,53 @@
+# Goal Plan 委派执行协议
+
+只有用户在本次 P-goal-plan 运行中选择委派 Goal Plan 时加载。该分支同时启用唯一 Lead 与 native/external subagent；不支持 Lead-only，也不把本协议用于普通 Goal Plan。
+
+## 1. Lead 与 Delivery Contract
+
+Lead 负责源码基线、DAG、Wave、shared owner、Gate、权限、Evidence 汇总和集成；已派发 Ticket 的实现由对应执行者负责，Lead 不制造双重 owner。
+
+委派分支选择唯一 execution model：`native-subagent` 或 `external-web-subagent`。Lead 以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>` 生成里程碑 Delivery Contract；Implement 阶段以 `operation=execute` 调用同一 Skill 做恢复和验收。
+
+Delivery Contract 必须固定：
+
+- execution model、Lead、provider 和可恢复 workspace/session locator；
+- repository、branch、不可变 checkpoint 与源码交付方式；
+- 最大并发和默认 3 轮的 `max_correction_rounds`；
+- 标准轴、规范轴、Lead 独立验证和条件性 E2E；
+- local changes、commit、push、PR、merge、deploy、migration 和生产动作的逐项授权；
+- 完成、阻塞、偏差、恢复和返回协议。
+
+并行写代码且配置允许时，Lead 为每个 Ticket 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`。所有并行 Ticket 固定同一 `base_sha`，每个 Ticket 使用独立分支和 `workspace_ref`；Lead 创建、恢复、集成和清理，Worker 只推进到 `review`。
+
+## 2. Dispatch Packet
+
+每个计划 Ticket 都生成一个可独立投递的 Dispatch Packet，至少包含：
+
+1. Ticket ID、目标、可观察完成结果和优先级冲突裁决；
+2. `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与具体 Ticket；
+3. 相关 Spec 合同、ADR/CONTEXT 条目、Wave、Gate 和不可协商约束；
+4. 已完成依赖及其 Evidence；
+5. 项目 writable/read-only/shared 路径与唯一 shared owner；
+6. `base_sha`、branch、workspace/session locator 和 source package hash；
+7. 必跑验证、基线、反向验证和明确不适用项；
+8. 当前授权、偏差升级、修正上限、Evidence 路径和返回字段。
+
+派单块将不可违反项写为 Hard Constraints，将低影响实现自由写为 Guidance。执行者先核对 checkpoint、项目指令、路径和验证命令，再在 Ticket Evidence 写入不超过 10 行的开工回执。事实不一致时停止受影响路径并升级。
+
+## 3. 候选交付、Evidence 与 Lead 集成
+
+Worker 完成或阻塞时写入 Ticket Evidence，同步状态，并向 Lead 返回 Ticket ID、Evidence、workspace/session locator、最终 checkpoint、commit/PR、未验证项和条件性 Lead E2E。
+
+Lead 接收候选交付时：
+
+1. 读取 Dispatch Packet、Ticket、Evidence、Goal Plan 和代码引用；
+2. 检查 checkpoint、附件 hash、路径授权、依赖和敏感信息边界；
+3. 在隔离基线上应用交付并复跑定向验证和受影响回归；
+4. 仅当 UI 交互受影响时运行最小 E2E；
+5. provider 声明、模拟结果和静态推断在独立证据前保持 `unverified`；
+6. 验证通过后集成，并按 dev-worktree Skill 更新或清理 worktree；
+7. 同步 Ticket、Map、Evidence 和 Goal Plan，检查 Gate 是否可关闭。
+
+同一验收项达到修正上限时标记 blocker，记录最后 checkpoint、错误、已通过行为、责任方和恢复条件。
+
+**完成标准**：完整委派附录包含唯一 Lead、完整 Delivery Contract、每 Ticket Dispatch Packet 和候选交付验收协议；任何一部分缺失都不得视为 Ready。