@namewta/speculo 0.7.2 → 0.7.3

package/template/workflows/specdev/I-init-setup/I-init-setup.md

@@ -42,7 +42,7 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 
 - 项目测试、类型检查、lint 和构建命令；
 - 是否存在多包或多工作区结构；
-- 是否允许并行 worktree；
+- 默认父分支、Git worktree 支持和项目已有分支/提交约定；
 - 共享高冲突路径的类型，例如根依赖清单、锁文件、全局导出、共享 schema、迁移索引和全局路由；
 - 项目中已有的提交、分支和发布约定。
 
@@ -53,8 +53,7 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 仅在上下文未提供时询问：
 
 - 交互语言与持久化工件语言；
-- 是否允许自动提交；
-- 最大并发数；
+- implementation subagent 上限（`1..3`，默认 `3`，Lead 不计入）；
 - Deep Ticket 的迁移、发布和不可逆操作是否必须人工批准；
 
 不询问可由仓库事实回答的文件位置、脚本名或默认分支。
@@ -69,7 +68,7 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 - 验证命令来自仓库事实或显式用户决定；
 - 未确认命令写 `null`，不得虚构；
 - 不写入令牌、凭据、Cookie、个人隐私或敏感环境变量值；
-- 自动提交默认关闭，除非用户明确授权。
+- Ticket 的实现 commit 与本地 candidate integration 仍由具体 Goal Plan/I-implement 取得授权，不存为全局自动副作用开关。
 
 ### 5. 初始化目录与状态
 
@@ -83,7 +82,7 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 - `<Path>{roots.state}/specdev/research/</Path>`
 - `<Path>{roots.state}/specdev/archive/</Path>`
 
-若全局状态已存在，先检查 `schema_version`。版本未知、JSON 不可解析或状态与当前 workflow 契约不一致时，停止当前 Work，并提示用户运行 `speculo init` 建立备份与 pending marker，再运行 `migrate-runtime-state` command 对账修复；不得在 Work 内迁移、兼容或猜测旧状态。只有状态不存在时才从 schema v4 模板创建。
+若全局状态或 config 已存在，先检查各自 `schema_version`。版本未知、JSON 不可解析或状态与当前 workflow 契约不一致时，停止当前 Work，并提示用户运行 `speculo init` 建立备份与 pending marker，再运行 `migrate-runtime-state` command 对账修复；不得在 Work 内迁移、兼容或猜测旧状态。只有状态不存在时才从 schema v4 模板创建。
 
 从模板生成：
 

package/template/workflows/specdev/I-init-setup/change-status-template.json

@@ -1,9 +1,22 @@
 {
-  "schema_version": 3,
+  "schema_version": 5,
   "artifact": "change-status",
   "change": "<YYYY-MM-DD-topic>",
   "change_status": "active",
   "current_work": null,
+  "works_run": [],
+  "claimed_investigations": [],
+  "execution_authorization": {
+    "implementation_commit": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Ticket source commits"},
+    "local_candidate_integration": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Lead-owned local parent candidate integration and parent update"},
+    "source_cleanup": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Source worktree and branch cleanup"}
+  },
+  "leadership": {
+    "current": "<owner-or-session-locator>",
+    "epoch": 1,
+    "assigned_at": "<ISO-8601>",
+    "history": []
+  },
   "created_at": "<ISO-8601>",
   "updated_at": "<ISO-8601>",
   "completed_at": null,

package/template/workflows/specdev/I-init-setup/config-template.json

@@ -1,14 +1,12 @@
 {
-  "schema_version": 3,
+  "schema_version": 4,
   "interaction_language": "zh-CN",
   "artifact_language": "zh-CN",
   "git": {
-    "auto_commit": false,
-    "default_branch": null,
-    "worktree_for_parallel": true
+    "default_branch": null
   },
   "execution": {
-    "max_parallel": 3,
+    "max_implementation_agents": 3,
     "deep_ticket_human_approval": true,
     "shared_path_owner": "explicit"
   },

package/template/workflows/specdev/I-init-setup/status-template.json

@@ -1,5 +1,5 @@
 {
-  "schema_version": 4,
+  "schema_version": 5,
   "workflow": "specdev",
   "active": [],
   "archived": []

package/template/workflows/specdev/INDEX.md

@@ -70,7 +70,7 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 - 活跃 change：`<Path>{roots.state}/specdev/changes/</Path>`
 - 历史归档：`<Path>{roots.state}/specdev/archive/</Path>`
 
-刷新时 CLI 在 `<Path>{roots.state}/back/</Path>` 保留最近一次旧配置与完整 runtime state，并对 v0.7+ 状态执行兼容迁移。若 `<Path>{roots.state}/migration.json</Path>` 存在且为 pending，所有 SpecDev Works 必须在读取 workflow state 前停止；只有 `<Path>{roots.commands}/migrate-runtime-state.md</Path>` 可以读取备份并在用户确认后修复。`back/`、`install.json` 与 `migration.json` 均不属于 SpecDev 写入 namespace。
+刷新时 CLI 在 `<Path>{roots.state}/back/</Path>` 保留最近一次旧配置与完整 runtime state，并对 v0.7+ 状态执行兼容迁移。若 `<Path>{roots.state}/migration.json</Path>` 存在且为 pending，所有 SpecDev Works 必须在读取 workflow state 前停止；只有 `<Path>{roots.commands}/migrate-runtime-state.md</Path>` 可以读取备份并在用户确认后修复。`<Path>{roots.state}/back/</Path>`、`<Path>{roots.state}/install.json</Path>` 与 `<Path>{roots.state}/migration.json</Path>` 均不属于 SpecDev 写入 namespace。
 
 初始化设置 work 首次运行时生成配置并创建空的永久 namespace：
 
@@ -122,7 +122,8 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 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 后才归档。
-13. **协作与工作区正交**：是否使用 Lead Team 只决定角色与交付合同；是否使用 worktree 只由 change 的隔离事实决定。只读辅助 Agent 不成为第二写入者。
+13. **Lead 与隔离正交**：Lead 固定拥有 SpecDev 状态、Evidence 与父分支；是否派遣 subagent 由 Lead 动态决定。每个实现 Ticket 都使用独立 worktree，Agent 身份不决定是否隔离。
+14. **候选先验收**：source worktree 只产生实现 commit 与非 E2E 证据；Lead 在 parent-candidate 状态运行集成检查和适用 E2E，通过后才推进父分支。
 
 共享规则：
 
@@ -146,11 +147,11 @@ Archive          归档历史并将经验证知识提升为当前长期知识
 6. 只加载当前步骤需要的 work 子文件和共享规则。
 7. 完成后写入产物、运行适用校验、更新状态和 `works_run`。
 
-Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`：`coordination_mode: lead-team` 时由 Lead 拥有转换；`single-session` 或无 Goal Plan 的实现由最后一个 I 拥有；旧 Goal Plan 按完整委派附录兼容推导。非实现型终点由最终验收工件 owner 拥有，Archive 不补造 completed。
+Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`：有 Goal Plan 时由其中唯一 Lead 拥有转换；无 Goal Plan 的 Ticket/Direct Spec 由当前 I owner 拥有；非实现型终点由最终验收工件 owner 拥有。Archive 不补造 completed。
 
 ## 状态字段
 
-`<Path>{roots.state}/specdev/status.json</Path>` 使用全局 schema v4；Spec、Ticket 和 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 等领域工件仍使用各自现有 schema：
+`<Path>{roots.state}/specdev/status.json</Path>` 使用全局 schema v4；Spec/Ticket/Tickets Map 继续使用各自 schema v3，config、Goal Plan 和 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 使用 schema v4：
 
 - `schema_version`（数字）：全局状态 schema 版本，固定为 `4`。
 - `workflow`（字符串）：workflow 标识，固定为 `"specdev"`。
@@ -163,7 +164,9 @@ Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/sp
 
 `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`、父分支、owners、可迁移 `workspace_ref`、结束动作、来源/结果 checkpoint、验证与生命周期状态。旧 v3 记录保持可读；出现 `terminal_action` 时启用完整集成合同。本版本新增的 `integrating` 不属于 legacy 状态，必须始终携带完整合同。
+`<Path>{roots.state}/specdev/config.json</Path>` 的 `execution.max_implementation_agents` 为 `1..3`，默认 `3`，仅限制 implementation subagent 且不含 Lead；只读 review/research/test-observation agent 不设 SpecDev 数字上限。
+
+`<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 的 `worktrees` 保存 Ticket 级 `base_sha`、父分支、workspace/implementation/integration owner、portable source workspace、source checkpoint、parent-candidate branch/workspace、candidate/result SHA、验证、E2E disposition 与生命周期状态。每个实现 Ticket 都有一条记录；父分支只有在 candidate passed 后推进。`removed` 是 `integrated` 后来源 branch/worktree 完成清理的终态，必须保留全部集成与 E2E 证据。
 
 领域状态枚举：
 
@@ -183,7 +186,7 @@ Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/sp
 
 ## 副作用边界
 
-未经用户明确授权不得提交、推送、合并、删除分支或 worktree、部署、发布、移动归档、写入/关闭远程 Issue 或执行不可逆迁移。Worktree 记录中的 `terminal_action=integrate` 是对应 Ticket 的持久本地集成授权，包含必要的集成专用 merge commit，但不授权普通实现提交或任何远端/清理动作。只读探索、生成 change 工件和已授权验证可以进行。远程开发投影仅由 Triage reconcile 执行；Retro command 的 Speculo 反馈 Issue 是独立 command 边界。敏感值不得写入 `<Path>{roots.state}/specdev/</Path>`。
+未经用户明确授权不得提交、推送、合并、删除来源 branch/worktree、部署、发布、移动归档、写入/关闭远程 Issue 或执行不可逆迁移。Ready Goal Plan/Ticket 执行必须明确取得 implementation commit 与 local candidate integration/父分支更新授权；该授权包含 transient candidate checkout/branch 生命周期，不扩展到来源 cleanup、远端或生产动作。只读探索、change 工件生成和已授权验证可以进行。远程开发投影仅由 Triage reconcile 执行；Retro command 的 Speculo 反馈 Issue 是独立 command 边界。敏感值不得写入 `<Path>{roots.state}/specdev/</Path>`。
 
 ## 场景路由
 
@@ -213,9 +216,9 @@ Change 从 active/blocked 转为 completed 时加载 `<Path>{roots.workflows}/sp
 - **D-diagnose-bugs** — 诊断 Bug：先建立会在精确症状上变红的紧凑反馈回路，再通过最小化、排名假设和单变量探针确认根因，输出修复契约而不实施生产修复。
 - **E-engineering-cognitive-mentor** — 工程认知导师：面向 Bug、项目源码、需求技术方案、架构设计与陌生技术领域的非执行型认知指导 Work；以证据、因果 Why、候选方案对比和逐轮澄清帮助用户形成可复述理解，并将完整问答轨迹持续持久化到当前 change。
 - **G-grill-with-docs** — 设计访谈（带文档）：以完整 frontier 逐轮推进设计树，直到每个决策分支都已关闭并获得用户共识，同时持续维护当前 change 的设计树、日志、领域上下文和架构决策。
-- **I-implement** — 实现：基于 Ready Ticket 或获批的小型 Spec 执行设计检查、TDD 红绿循环、持续验证、双轴审查、证据回写和提交。
+- **I-implement** — 实现：基于 Ready Ticket 或获批小型 Spec 执行设计检查、TDD、动态派单、双轴审查、Ticket worktree commit、候选合并验证和 Lead Evidence 回写。
 - **I-init-setup** — 初始化设置：初始化 SpecDev 的语言、配置、全局状态、本地 change 追踪、领域知识布局、验证命令和并发治理。
-- **P-goal-plan** — 目标规划：在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 计划，并仅在用户选择时加入严格角色委派。
+- **P-goal-plan** — 目标规划：在跨 Ticket 协调复杂度需要时，以固定 Lead、动态派单、DAG/Gate 和候选合并门禁生成决策完备且可恢复的执行计划。
 - **P-prototype** — 原型：在获授权的临时 branch/worktree 中构建一次性 Logic 或 UI 原型，回答一个明确设计问题并持久化答案、资产定位和清理状态。
 - **R-review-architecture** — 架构审查：从用户指定范围或 Git 热点扫描代码库的深化机会，以持久化可视化 HTML 呈现候选，并对用户选择的一个方案运行设计树访谈。
 - **S-spec** — 编写 Spec：综合已知事实、设计决定、诊断与代码现状，产出以外部行为和验收合同为权威的 Ready Spec。

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

@@ -3,15 +3,15 @@ id: specdev/goal-plan
 type: workflow-entry
 workflow: specdev
 name: 目标规划
-description: 在协调复杂度需要时，将 Ready Spec、Tickets、架构决策与外部约束综合为决策完备的跨 Ticket 计划，并仅在用户选择时加入严格角色委派。
-keywords: [目标规划, 编排, DAG, Gate, Wave, Lead, Subagent, checkpoint, 派单, 迁移, 证据]
+description: 在跨 Ticket 协调复杂度需要时，以固定 Lead、动态派单、DAG/Gate 和候选合并门禁生成决策完备且可恢复的执行计划。
+keywords: [目标规划, Lead, Subagent, DAG, Gate, Wave, worktree, candidate-merge, 证据]
 ---
 
 # 目标规划
 
-Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序、并发、共享所有权、里程碑 Gate、集成验证、迁移与发布顺序、偏差升级和恢复。它不是 Ticket 的放大版，也不按固定章节数量衡量质量。
+Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
 
-协作拓扑与工作区拓扑是两个正交决定。`coordination_mode: single-session` 是默认值：主会话拥有全部项目与状态写入，只读探索可以使用辅助 Agent；只有用户明确选择时才进入 `lead-team` 并建立 Lead/Worker 交付合同。`workspace_strategy` 则根据 change/Ticket 的实际隔离需求独立确定，Agent Team 本身既不要求也不禁止 worktree。
+每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、候选验收、父分支集成和最终回复。Lead 可以根据实际依赖与平台能力动态派遣 subagent，不需要用户预选协作模式。Agent 编排与 worktree 隔离是正交关系；每个进入 I-implement 的 Ticket 都必须拥有独立 worktree，无论由 Lead 还是 implementation subagent 实现。
 
 产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
 
@@ -21,12 +21,12 @@ Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序
 
 - 多个 Ticket 可以或需要并行；
 - 存在 shared path、共享合同或集中 owner；
-- 存在 Deep Ticket、expand-contract、数据迁移、兼容窗口或不可逆步骤；
-- 存在多个里程碑、外部审批、发布窗口、参考符合性或高事故半径；
-- Ticket DAG 虽不大，但关键路径、汇合点或恢复策略不能仅由 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 安全表达；
+- 存在 Deep Ticket、expand-contract、迁移、兼容窗口或不可逆步骤；
+- 存在多个 Gate、外部审批、发布窗口或高事故半径；
+- Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
 - 用户明确要求正式跨 Ticket Plan。
 
-少量、线性、低风险且路径不冲突的 Ready Tickets 可以跳过本 work，直接由 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 按 Tickets Map 执行。
+少量、线性、低风险的 Ready Tickets 可以跳过本 work，由 I-implement 逐 Ticket 建立 worktree 并执行。没有 Ticket 的获批小型 Direct Spec 不受 Ticket worktree 合同约束；一旦需要切片，先运行 T-tickets。
 
 ## 输入
 
@@ -39,97 +39,78 @@ Goal Plan 只解决单个 Ticket 无法独立决定的事情：跨 Ticket 顺序
 
 按存在情况读取：
 
-- `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
-- `<Path>{roots.state}/specdev/adr/</Path>`
-- `<Path>{roots.state}/specdev/context/</Path>`
-- 用户提供的合同、标准、参考实现、环境限制、发布窗口与批准策略。
+- 当前 change 架构决策：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
+- 当前 change 领域上下文：`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
+- 当前 change 设计日志：`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
+- 当前 change 诊断：`<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
+- 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
+- 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
+- 用户提供的合同、标准、参考实现、环境限制、发布窗口和批准策略。
 
-Spec 或 Tickets Map 不存在时，返回 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>` 或 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`，不得在 Goal Plan 中临时补造上游工件。
+永久目录可以为空，静默继续。缺少 Spec 或 Tickets Map 时返回 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>` 或 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`；当前 ADR/CONTEXT 缺失且规划依赖对应决定时返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`，不在 Goal Plan 中补造上游权威。
 
 ## 流程
 
-### 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. 未获得用户对 Lead Team 的明确选择时固定 `coordination_mode: single-session`；只读探索 Agent 不改变该值；
-5. 用户明确选择 Lead Team 时固定 `coordination_mode: lead-team`，再选择 `native-subagent` 或 `external-web-subagent`；
-6. 按每个 Ticket 的可观察事实选择 current 或 worktree，并汇总为 `workspace_strategy: current | worktree | mixed`；
-7. 只对无法发现且会改变 Gate、Wave、owner、迁移、批准点或隔离策略的问题继续提问；
-8. 不熟悉的外部标准或依赖使用 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`。
+1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和 Deep Ticket 完整性；
+2. 只读探索影响调度的代码与项目事实；
+3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
+4. 从 config 读取 `max_implementation_agents`，将实际上限写入 `implementation_agent_limit`；本计划可以降低但不得超过 `3`，Lead 不计入；
+5. 确认实现 commit 与本地候选集成已获授权；缺一项则计划保持 blocked；
+6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
 
-任何硬停止问题都必须退回拥有该决策的上游工件，不得用 Goal Plan 覆盖。
+**完成标准**：所有计划内 Ticket Ready；Lead、授权、实现并发上限和父分支可判定；没有用 Goal Plan 掩盖上游缺口。
 
-### 2. 构建跨 Ticket 核心计划
+### 2. 构建 Outcome、DAG、Wave 与 Gate
 
 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
 
-1. 从 Ticket frontmatter 构建 DAG 和关键路径；
-2. 将 Ready 且项目写路径不相交的 Ticket 分配到 Wave；
-3. 为 shared path、共享合同和集中变更指定唯一 owner；
-4. 为行为闭环、合同稳定、迁移完成、发布就绪等关键状态定义 Gate；
-5. 明确 expand → migrate → contract、Evidence 返回和集成规则；
-6. 定义每个 Ticket 的开始条件、执行顺序、workspace 分配、验证、Evidence 目标和失败恢复，不复制 Ticket 全文；
-7. 只有存在允许的隔离触发条件时才规划 worktree，并固定 workspace owner、integration owner、父分支和结束动作。
+1. 压缩 Outcome、成功/伪完成、非目标和权威来源；
+2. 从 Ticket frontmatter 构建 DAG、关键路径、扇出与汇合点；
+3. 为 shared path、共享合同和集中修改指定唯一 owner；
+4. 将依赖满足且项目写路径不相交的 Ticket 分入 Wave；
+5. 为合同稳定、垂直路径、迁移完成、发布就绪等状态定义 Gate；
+6. 为每个 Ticket 记录开始条件、worktree、验证层级、Evidence 目标、集成顺序和失败恢复。
 
-**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个计划 Ticket 都有唯一 owner、可验证开始条件、Evidence 目标和恢复路径。
+**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个 Ticket 有唯一项目写 owner、worktree 合同和可验证集成出口。
 
-### 3. 按两个维度加载条件分支
+### 3. 固定 Lead 编排与动态派单合同
 
-当 `workspace_strategy` 为 `worktree` 或 `mixed` 时：
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`，并以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`：
 
-1. 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/workspace-execution-template.md</Path>`；
-2. 为每个隔离 Ticket 记录合法触发事实、固定基线、父分支、implementation owner、integration owner、可迁移 locator 和 `integrate | retain`；
-3. 按需以规划输入调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`，不在规划阶段创建工作区。
+1. 固定 Lead 的可恢复 owner/session locator；
+2. 声明 implementation subagent 最多同时三个，Lead 不计入；
+3. 不为只读 review/research/test-observation agent 写 SpecDev 数字上限；
+4. 固定只有 Lead 写 SpecDev 工件与状态；
+5. 定义执行期动态 Dispatch Packet、候选返回和 Lead 验收；
+6. provider、模型和具体派单在 Ticket 开始时按事实选择，不在 Goal Plan 中预分配。
 
-只有 `coordination_mode: lead-team` 时：
+**完成标准**：Lead 可以在恢复后重建派单边界；任何 subagent 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
 
-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. 为每个派单标记 `lead-write | worker-write | read-only`；`worker-write` 必须引用隔离 workspace 分配。
-
-`single-session` 跳过委派能力，但仍可加载独立 workspace 附录；`lead-team` 在没有隔离触发条件时也不得制造 worktree。
-
-### 4. 定义整体完成、证据与恢复
+### 4. 定义完成、证据与恢复
 
 加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
 
-1. 将整体目标、非目标和权威来源压缩为一个可审查摘要；
-2. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
-3. 固化跨 Ticket 不可协商约束；
-4. 区分不可违反约束与可由实现者调整的建议；
-5. 定义实测基线、反向验证、防伪完成、偏差等级、暂停范围、批准人和恢复动作；
-6. 定义进度回报、Evidence 汇总、残余风险和回滚要求。
-
-**完成标准**：所有完成声明能映射到实际命令、代码状态、Evidence 或人工批准；没有自报即通过的门禁。
-
-### 5. 写入自适应 Goal Plan
+1. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
+2. 固化不可协商约束与允许的局部实现自由；
+3. 为每个 Ticket 明确 source-worktree 检查与 parent-candidate 检查；
+4. E2E 按 Ticket 实际跨边界风险标记 required 或 not-required；
+5. 定义候选失败、父 HEAD 漂移、偏差、暂停、批准和恢复动作；
+6. 定义 change 完成、远程 reconcile、残余风险和回滚要求。
 
-使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
+**完成标准**：每个完成声明映射到不可变 commit、候选/父分支 SHA、命令、Evidence 或人工批准。
 
-核心模板包含六个职责区，但只保留适用内容：
+### 5. 写入、同步与验证
 
-1. Outcome and Authority；
-2. Execution Graph；
-3. Gates and Completion Evidence；
-4. Execution and Integration Protocol；
-5. Constraints, Risk and Recovery；
-6. Progress and Decisions。
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 Goal Plan：
 
-当 workspace strategy 需要隔离时加入 `<Path>{roots.workflows}/specdev/P-goal-plan/workspace-execution-template.md</Path>`；当 coordination mode 为 Lead Team 时加入 `<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution-template.md</Path>`。两个附录互不蕴含，可单独或同时出现。Ticket 较多时在 Execution Graph 内增加速查表，不创建独立的第二套状态来源。
-
-### 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>`，确认 coordination 与 workspace 两个字段成对存在且组合有效；
-3. 运行：
+1. 只保留适用 planning modes，不创建条件性 topology addendum；
+2. 将 Wave、Gate 和 owner 投影同步到 Tickets Map；
+3. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；
+4. 运行：
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
@@ -137,44 +118,37 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
   <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 和同步投影后重新读取，确认核心 DAG/Wave/Gate/owner、两个执行维度和授权一致；存在 workspace 附录时核对触发条件与集成字段，存在委派附录时核对 Lead、checkpoint、locator、Delivery Contract 与 Dispatch Packet；
-6. 向用户汇报规划模式、协作方式、workspace 分配、关键路径、Wave、Gate、shared owner、迁移策略、主要风险和 Ready 状态；Lead Team 再汇报交付通道与 Lead；
+5. 原子更新 Goal Plan、Tickets Map、全局/current change 状态并重新读取；
+6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
 7. 未经用户要求，不自动进入实现。
 
 ## 决策完备标准
 
-每份 Goal Plan 必须让实现者无需重新决定：
-
-- 跨 Ticket 先后、并发 Wave 和关键汇合点；
-- shared path 与共享合同的 owner；
-- Gate 开启、关闭和证据；
-- 迁移、兼容、收缩、发布和回滚顺序；
-- Evidence 返回、集成、偏差、暂停和批准路径。
+每份 Goal Plan 必须让 Lead 无需重新决定：
 
-每份新 Goal Plan 必须锁定 coordination mode 与 workspace strategy。Lead Team 还必须锁定 Agent 派单上下文、execution model、Lead、checkpoint、locator、修正上限和逐动作授权；single-session 不包含这些角色内容。Worktree/mixed 还必须锁定逐 Ticket 隔离触发、父分支、integration owner 与结束动作；current 不包含隔离占位。
+- Outcome、权威来源和整体完成；
+- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
+- shared path 与共享合同 owner；
+- implementation subagent 上限及动态派单边界；
+- 每 Ticket worktree、source commit、候选验证和父分支推进规则；
+- E2E disposition、偏差、暂停、批准和恢复路径。
 
-Goal Plan 不应重复 Ticket 的局部执行路线、全部文件预测、局部验收 checklist 或 Spec 的完整用户故事。
+Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
 
 ## 完成标准
 
-- `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` 已写入且只包含适用内容；
-- 所有计划内 Ticket Ready，DAG 无环，合同覆盖明确；
-- Wave、Gate、owner、集成、偏差和恢复可执行；
-- `single-session` 没有委派角色、交付合同或空占位，`lead-team` 的 Delivery Contract 与每个 Dispatch Packet 完整可恢复；
-- current strategy 没有 worktree、Ticket branch 或逐 Ticket merge 安排；worktree/mixed 的每条分配都有实际触发事实和可恢复集成合同；
-- Tickets Map 投影已同步；
-- 无未批准高影响假设或硬停止问题；
-- `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 无 error；
-- 用户收到摘要和下一步选择。
+- Goal Plan schema v4 且 `ready_for_execution` 与状态一致；
+- Lead 唯一，最多三个 implementation subagent，review/research agent 不受 SpecDev 数字限制；
+- 每个实现 Ticket 都有 worktree、commit、candidate-merge 和 Evidence 出口；
+- source worktree 不承担 E2E，适用 E2E 只由 Lead 在 parent-candidate 状态运行；
+- 计划只保留当前固定 Lead 与 candidate-merge 合同，不携带条件性编排附录；
+- validator 无 error，Tickets Map 投影同步，用户收到下一步选择。
 
 ## 子文件引用
 
 - 规划模式与输入门禁：`<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.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>`
-- 隔离 workspace 附录模板：`<Path>{roots.workflows}/specdev/P-goal-plan/workspace-execution-template.md</Path>`，仅 worktree/mixed 时加载
-- 委派附录模板：`<Path>{roots.workflows}/specdev/P-goal-plan/delegated-execution-template.md</Path>`，仅用户选择委派时加载
-- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，仅用户选择委派时调用
+- DAG、Wave、Gate 与集成队列：`<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`
+- Lead 与动态派单：`<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.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>`
+- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`

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

@@ -1,58 +1,40 @@
-# Goal Plan 完成、证据与恢复控制
+# Goal Plan 完成、证据与恢复
 
-## 1. Outcome and Authority
+## 1. 整体 Definition of Done
 
-Goal Plan 用紧凑摘要表达业务目标、受众、所有 Ticket 完成后的可观察终态、关键约束、非目标、权威来源、冲突规则和伪完成判据，不复制 Spec 的完整用户故事。
+至少要求：
 
-## 2. 整体 Definition of Done
+- Spec 验收合同全部有通过 Evidence 或明确批准的 deferred；
+- 所有非 cancelled Ticket 都有 source commit、通过的 candidate 和父分支 result SHA；
+- shared path、接口、数据、兼容、迁移、调用点与回滚合同闭合；
+- 项目定向检查、受影响回归、类型检查、lint/build 和适用 E2E 无未经批准退化；
+- change 状态、Ticket、Map、Goal Plan、Evidence 与实际 Git 状态一致；
+- 没有未集成 source checkpoint、活动 integration candidate 或未决高影响偏差。
 
-整体完成至少覆盖：
+无需改动的 Ticket 必须转为 `cancelled` 并记录来源事实；不得用 Evidence-only Done 或 empty commit 关闭。
 
-- 所有计划内 Ticket 完成，cancelled 或 deferred 项有批准；
-- 所有 Spec 验收合同和外部符合性要求有 Evidence；
-- 项目类型检查、静态检查、测试、lint、构建、适用 CI 和受影响 E2E 完成，基线没有未经批准的退化；
-- 可静默失效的关键门禁完成受控反向验证并恢复绿色；
-- 迁移、兼容、调用点清零、监控、回滚和不可逆批准完成；
-- 无未批准偏差、未处置高风险残余问题或伪装成通过的 `unverified` 声明；
-- Ticket、Map、Goal Plan、Evidence、代码事实和状态一致。
+## 2. 两层验证
 
-## 3. Gate 关闭与 change 完成
+- `source-worktree`：implementation owner 运行 Ticket 要求的单元、组件、静态、类型、lint/build 等非 E2E 检查；
+- `parent-candidate`：Lead 运行受影响集成/回归和 Ticket 标记 required 的 E2E。
 
-每个 Gate 关闭时汇总覆盖 Evidence，检查合同、共享接口、数据、兼容、迁移和调用点，运行里程碑验证和适用 E2E，执行必要反向验证，审查偏差/风险/恢复能力，获取适用人工批准，并同步 Goal Plan、Map 和状态。
+Evidence 必须记录命令运行环境。任何在 source worktree 声称的 E2E pass 都无效；subagent 返回的测试结果在 Lead 核对前保持候选状态。
 
-最后一个 Gate 关闭后加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`：
+## 3. Gate 关闭
 
-- `coordination_mode: single-session` 时，由最后一个计划内 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 汇总并完成 change；
-- `coordination_mode: lead-team` 时，由 Lead 在独立验收后完成 change；旧 Goal Plan 缺少该字段时，继续按完整 Delegated Execution Addendum 是否存在推导。
+Lead 在每个 Gate 汇总覆盖 Evidence、接口/数据/兼容状态、candidate/result SHA、适用 E2E、反向验证、偏差、风险和批准。Gate 不以“完成若干 Ticket”作为唯一关闭条件。
 
-若 triage 的 `external_action` 为 `pending-close` 或 `close-failed`，下一 Work 为 `<Path>{roots.workflows}/specdev/T-triage/T-triage.md</Path>`，否则进入 Archive。远程动作不参与本地 Gate 判断。
+## 4. 失败与恢复
 
-## 4. 不可协商约束
+- source 检查失败：保留 worktree，继续当前 Ticket；
+- candidate 冲突或检查失败：父分支不动，integration 记 `failed`，Ticket 回到 `in_progress`/`blocked`；
+- 父 HEAD 漂移：integration 记 `stale`，从最新父分支重建并重跑；
+- E2E required 失败：父分支不动，保留失败命令、candidate SHA 和恢复条件；
+- 命中当次 Dispatch Packet/候选协议的停止条件、继续修正已无合理收益或需要新产品决定：停止受影响 Wave，按 deviation control 返回契约 owner；
+- Lead 会话变化：读取 Goal Plan、Ticket、change worktree 状态与最新 Evidence，从最后不可变 checkpoint 恢复。
 
-只记录跨多个 Ticket 且不可由实现者改变的规则，例如数据完整性、wire format 兼容、旧协议收缩条件、shared owner、安全要求、发布窗口、回滚演练和批准点。每条约束说明来源和违反后果；可由实现者沿惯例选择的事项写入 Guidance。
+## 5. Change 完成 owner
 
-## 5. 偏差与暂停
+Lead 是 Goal Plan change 的唯一完成 owner。没有 Goal Plan 的单 Ticket/Direct Spec 由当前 I-implement owner 按 change completion 规则完成。Archive 不补造完成证据。
 
-偏差遵循 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>`。跨 Ticket 偏差还要说明暂停哪些 Wave/Ticket、重新打开哪个 Gate、哪些执行者需要新基线、哪些 Evidence 失效和恢复条件。
-
-## 6. 风险与恢复
-
-每个高风险项写明触发信号、事故半径、预防、检测、恢复、owner 和批准点。迁移或发布计划必须给出回滚不可行时的前向恢复方案。
-
-恢复时依次读取 Goal Plan、当前 Ticket、最新 Evidence 和 change 状态，从最后已验证事实继续，不重复询问已确认事项，也不创建额外进度或阻塞文件。委派专属的 checkpoint、locator 和修正轮次由委派附录管理。
-
-## 7. 进度与决策回报
-
-使用可核验状态，不使用主观百分比：
-
-```text
-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>
-BLOCKER id=<id> owner=<owner> needed=<decision-or-input> impact=<scope>
-DECISION id=<id> owner=<owner> status=pending|approved|rejected impact=<scope>
-```
-
-Lead Team 的交付状态格式由委派协议提供，不加入 single-session Goal Plan。
-
-**完成标准**：进度可由权威工件恢复；普通计划由最后一个 Implement 完成，委派计划由 Lead 完成；所有通过、阻塞和未验证声明均能定位到具体 Evidence 与代码事实。
+**完成标准**：所有通过、阻塞、取消和未验证声明均定位到权威工件、命令与 Git checkpoint；失败不会推进父分支或 Done。