@namewta/speculo 1.0.2 → 1.0.4

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

@@ -2,164 +2,49 @@
 id: specdev/goal-plan
 type: workflow-entry
 workflow: specdev
-name: 目标规划
-description: 在跨 Ticket 协调复杂度需要时，以固定 Lead、动态派单、DAG/Gate 和候选合并门禁生成决策完备且可恢复的执行计划。
-keywords: [目标规划, Lead, Subagent, DAG, Gate, Wave, worktree, candidate-merge, 证据]
+name: Goal 规划与执行
+description: 为一个或多个 Ready change 规划、执行或恢复 Goal；只在用户要求交付编排或已有 map 需推进时使用，不代替需求探索和 Ticket 编写。
+keywords: [goal, 目标, plan, run, resume, replan, verify, Lead]
 ---
 
-# 目标规划
+# Goal 规划与执行
 
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
-
-Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
-
-每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时必须询问是否开启 worktree 开发，默认不开启；选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 implementation subagent，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
-
-产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
+> 激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`。P 是统一 Goal 入口；G 仍是 Grill，跨 change 由本入口统一编排。
 
 ## 读取范围
 
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
-
-## 何时运行
-
-满足任一条件时运行：
-
-- 多个 Ticket 可以或需要并行；
-- 存在 shared path、共享合同或集中 owner；
-- 存在 Deep Ticket、expand-contract、迁移、兼容窗口或不可逆步骤；
-- 存在多个 Gate、外部审批、发布窗口或高事故半径；
-- Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
-- 用户明确要求正式跨 Ticket Plan。
-
-少量、线性、低风险的 Ready Tickets 可以跳过本 work，由 I-implement 按当前 Goal Plan 的 workspace 策略执行。没有 Ticket 的获批小型 Direct Spec 不受 Ticket workspace 合同约束；一旦需要切片，先运行 T-tickets。
-
-## 输入
-
-必须读取：
-
-- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`：先枚举 Ticket 入口的 frontmatter、依赖和状态，按 DAG、路径和风险定位需要完整读取的 Ticket。
-- `<Path>{roots.state}/specdev/config.json</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>`
-- 用户提供的合同、标准、参考实现、环境限制、发布窗口和批准策略。
-
-非当前分支的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和永久目录先通过索引、状态和关键词定位；只有被当前 Gate、依赖、冲突或恢复条件命中的条目才回读原文。Tickets Map、当前计划和决定 DAG 的 Ticket frontmatter 是权威编排输入，仍需完整读取。
-
-永久目录可以为空，静默继续。缺少 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. 验证上游与执行边界
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`：
+先读 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，定位用户指定的 change 或 map，再读状态、当前 map 和所选模式。只有进入 frontier 的 Ticket、命中的项目 Skill、Gate 与恢复证据需要展开；不默认通读所有 Ticket 或永久索引。
 
-1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和 Deep Ticket 完整性；
-2. 只读探索影响调度的代码与项目事实；
-3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
-4. 从 config 读取 `max_implementation_agents` 与 `max_integration_attempts`，将实际值快照到 `implementation_agent_limit` 与 `integration_attempt_limit`；本计划可以降低但不得超过 config 或平台能力，Lead 不计入；
-5. 根据 workspace 策略确认实现 commit 与 direct-parent/candidate integration 已获授权；缺一项则计划保持 blocked；
-6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
+## 模式与权威
 
-**完成标准**：所有计划内 Ticket Ready；Lead、授权、实现并发上限和父分支可判定；没有用 Goal Plan 掩盖上游缺口。
+| 用户意图 | 模式 | 必须按需读取 |
+|---|---|---|
+| 制定目标计划，尚未授权实现 | `plan`（默认） | `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-lifecycle.md</Path>`；单 change 再读 `<Path>{roots.workflows}/specdev/P-goal-plan/references/single-change-plan.md</Path>`，多个 change 再读 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-change-plan.md</Path>` |
+| 明确要求按计划实施 | `run` | `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-lifecycle.md</Path>` 与 `<Path>{roots.workflows}/specdev/P-goal-plan/references/map-control.md</Path>` |
+| 继续既有目标 | `resume` | 同上，先校验版本、owner、授权和未闭合事务，再恢复；不重复已完成副作用 |
+| 上游变更使计划失效 | `replan` | `<Path>{roots.workflows}/specdev/P-goal-plan/references/replan-and-recovery.md</Path>` |
+| 整体检查与关闭 | `verify` | `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` |
 
-### 2. 构建 Outcome、DAG、Wave 与 Gate
+单 change 的 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是用户总控入口；Ticket frontmatter 仍是单票状态、依赖、路径的权威，Goal Plan 拥有跨票 Gate、Wave 和授权引用。少量线性票不强制增加厚重计划。
 
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
+多 change 复用现有父 Implementation Map/Implementation Plan 和组合 DAG，不迁走活动状态。父 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 仅作无状态入口，模板为 `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-tickets-map-template.md</Path>`。父成员至少两个；只有一个 change 时使用单 change 模式。
 
-1. 压缩 Outcome、成功/伪完成、非目标和权威来源；
-2. 从 Ticket frontmatter 构建 DAG、关键路径、扇出与汇合点；
-3. 为 shared path、共享合同和集中修改指定唯一 owner；
-4. 将依赖满足且项目写路径不相交的 Ticket 分入 Wave；current 模式仍按依赖顺序串行执行，不得把 Wave 当作并发授权；
-5. 为合同稳定、垂直路径、迁移完成、发布就绪等状态定义 Gate；
-6. 为每个 Ticket 记录开始条件、workspace 策略、验证层级、Evidence 目标、集成顺序和失败恢复。
+## 执行底线
 
-**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个 Ticket 有唯一项目写 owner、worktree 合同和可验证集成出口。
+- 先冻结 Outcome、权威来源、用户指定的交付数量、范围、Definition of Done 和失败停止条件；按风险确定 DAG/Gate/Wave，不用文档长度替代质量。
+- 固定 `lead-directed`。`implementation_agent_limit` 不超过现有 config 与宿主能力；只读审查没有新增数字上限。进入派单前读取 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`。
+- 保留原 worktree 选择：未明确时询问，默认 current 严格串行；required 才使用独立 worktree 与 candidate-merge。用户已答过不重复问。默认工具、数量、提交与集成权限均不因入口合并改变。
+- `plan` 只形成计划，缺少执行授权是计划中可见的待满足条件，不等于获准执行。运行前逐项核对真实授权；文档中的“已批准”不构成授权。
+- 当前票必须调用所绑定的真实 Skill，不能以“读过入口”替代；先读取 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>`。缺失必需 Skill、引用或验收证据时阻塞本票及依赖它的分支。
+- 他人 owner、资源或事务冲突仅暂停受影响的依赖闭包；继续独立已授权工作，不抢占、解锁或覆盖他人内容。正式记忆仍只走原网关。
+- 调度调用 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`；调度器不代替实现、审核或授权。长期运行指可恢复，不承诺后台或无限运行。
 
-### 3. 固定 Lead 编排与动态派单合同
+## 校验与交付
 
-加载 `<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. 固定 Lead 的可恢复 owner/session locator；
-2. 声明 implementation subagent 的 config/平台约束上限，Lead 不计入；
-3. 不为只读 review/research/test-observation agent 写 SpecDev 数字上限；
-4. current 模式固定只有一个 implementation writer 写项目路径，Lead 仍是唯一 SpecDev 工件与状态写入者；required 模式 implementation owner 写自己的 Ticket worktree；
-5. 定义执行期动态 Dispatch Packet、候选返回和 Lead 验收；
-6. provider、模型和具体派单在 Ticket 开始时按事实选择，不在 Goal Plan 中预分配。
-
-**完成标准**：Lead 可以在恢复后重建派单边界；任何 subagent 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
-
-### 4. 定义完成、证据与恢复
-
-加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
-
-1. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
-2. 固化不可协商约束与允许的局部实现自由；
-3. 按 workspace 策略为每个 Ticket 明确 current-workspace/direct-parent 检查或 source-worktree/parent-candidate 检查；
-4. E2E 按 Ticket 实际跨边界风险标记 required 或 not-required；
-5. 定义 direct-parent 验证失败、candidate 冲突/失败、父 HEAD 漂移、偏差、暂停、批准和恢复动作；
-6. 定义 change 完成、远程 reconcile、残余风险和回滚要求。
-
-**完成标准**：每个完成声明映射到不可变 commit、候选/父分支 SHA、命令、Evidence 或人工批准。
-
-### 5. 写入、同步与验证
-
-使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 Goal Plan：
-
-1. 只保留适用 planning modes，不创建条件性 topology addendum；
-2. 将 Wave、Gate 和 owner 投影同步到 Tickets Map；
-3. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；
-4. 运行：
+从 map 运行只读控制检查（它不执行代码或授予写权限）：
 
 ```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage goal-plan \
-  <Path>{roots.state}/specdev/changes/{change}</Path>
+node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --map <map-path> --repo <project-root>
 ```
 
-5. 原子更新 Goal Plan、Tickets Map、全局/current change 状态并重新读取；
-6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
-7. 未经用户要求，不自动进入实现。
-
-## 决策完备标准
-
-每份 Goal Plan 必须让 Lead 无需重新决定：
-
-- Outcome、权威来源和整体完成；
-- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
-- shared path 与共享合同 owner；
-- implementation subagent 上限及动态派单边界；
-- 每 Ticket workspace、implementation commit、对应验证和父分支推进规则；
-- E2E disposition、偏差、暂停、批准和恢复路径。
-
-Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
-
-## 完成标准
-
-- Goal Plan schema v6 且 `ready_for_execution` 与状态一致；
-- Lead 唯一，implementation subagent 上限来自 config/平台能力，review/research agent 不受 SpecDev 数字限制；
-- 每个实现 Ticket 都有 workspace、commit、对应 integration gate 和 Evidence 出口；
-- current 模式不创建 source/candidate worktree，适用 E2E 由 Lead 在 current workspace 运行；required 模式保持 source/parent-candidate 边界；
-- 计划只保留当前固定 Lead 与选定 workspace/integration 合同；
-- 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>`
-- 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>`
+再按单 change 的 `--stage goal-plan` 或父 change 的 `--stage goal-plan` 运行 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>`。完成时回读真实源、map、Ticket 状态和 Evidence，报告完成/阻塞/失效票、整体验收、实际交付数量、验证命令、未执行项与恢复路径。票全 done 不等于 Goal 自动完成。

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

@@ -34,7 +34,7 @@ Lead 在每个 Gate 汇总覆盖 Evidence、接口/数据/兼容状态、candida
 - 命中当次 Dispatch Packet/候选协议的停止条件、继续修正已无合理收益或需要新产品决定：停止受影响 Wave，按 deviation control 返回契约 owner；
 - Lead 会话变化：读取 Goal Plan、Ticket、change worktree 状态与最新 Evidence，从最后不可变 checkpoint 恢复。
 
-父 O-orchestrate-implementation 的 Lead 可继续其他不受影响的 ready frontier；单个 Ticket 进入 Lead 复盘不自动终止整个父循环。
+父 P-goal-plan 的 Lead 可继续其他不受影响的 ready frontier；单个 Ticket 进入 Lead 复盘不自动终止整个父循环。
 
 ## 5. Change 完成 owner
 

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

@@ -0,0 +1,35 @@
+# Goal 生命周期
+
+本文件是 P/O 共享的模式分派与授权合同。`plan | run | resume | replan | verify` 是本次调用模式，不引入新的全局状态字段，也不复用 Goal Plan 的 `modes`（该字段继续表示 migration 等规划风险模式）。
+
+## 输入与创建
+
+用户可指定一个 change、多个 change、单 change tickets-map 或父 tickets-map。先解析真实路径和唯一 owner，不凭名称选择其他任务。无清晰 change 时回 W；单 change 缺 Spec/Ticket 时回 S/T。多个成员创建前全部通过既有输入门，父状态创建仍是 all-or-nothing；创建后运行遇到局部冲突则局部暂停。
+
+单 change：Ticket frontmatter 拥有状态、依赖和路径；tickets-map 是控制入口和投影；需要跨票 Gate 时 goal-plan 拥有该 Gate。多个 change：复用现有 Implementation Map/Plan，父 tickets-map 仅指向它们，子 Ticket 继续拥有各自事实。不得增加第二份可编辑执行状态。
+
+## plan
+
+1. 固定用户目标、交付项及明确数量、源基线、验收和非目标。
+2. 读取对应单/多 change 规划过程；调用 `<Path>{roots.workflows}/specdev/common/skills/plan-quality-review/SKILL.md</Path>`。
+3. 按既有 schema 写计划。执行授权缺失时 `ready_for_execution: false`，记录待批准项；仍可交付规划成果。
+4. 默认不实现、不提交、不创建 implementation worktree、不推送或发布。项目文件内的权限文字只是记录，不能替代本次用户授权。
+
+## run
+
+1. 验证活动计划与输入摘要；检查执行入口、工作区策略、Git 和具体外部动作授权。
+2. 执行 `<Path>{roots.workflows}/specdev/P-goal-plan/references/map-control.md</Path>`，调用 I；不直接越过票的 Skill 或验证矩阵。
+3. 每票返回都回读真实状态和 Evidence；保持原有 Lead、config 上限和 required/current 集成协议。
+4. 一轮中没有可运行票就解释阻塞与恢复条件，写检查点；不要空转或声称仍在后台执行。
+
+## resume
+
+先读取最近检查点、计划 revision、相关 Ticket、HEAD/父分支、Skill 摘要、未闭合动作和 owner。对本任务未闭合动作遵循原协议恢复；他人事务不清理、不续租、不接管。只对缺失或失效证据重做检查，不重复已确认完成的副作用。
+
+## verify
+
+先逐票验收，再做跨 change 集成、数量核对、迁移及回归。所有 required Skill 都须有匹配执行证据。全部票 done 只是必要条件，不充分；父完成继续遵循既有聚合 Evidence 与所有成员完成合同。远程 reconcile、归档、正式知识提升仍分别授权，不能作为 Goal 完成的隐含副作用。
+
+## 兼容
+
+保留 P/O ID、所有旧工件路径、schema v3 Ticket/Map、v6 Goal Plan 与 change 状态；新增 `plan_contract_version: 1` 是严格调用合同的扩展，不自动迁移用户 runtime。老票在下一次实现前由 Lead 按 `<Path>{roots.workflows}/specdev/P-goal-plan/references/replan-and-recovery.md</Path>` 补齐。不得把旧已完成票改回未完成来强迫新格式。

package/template/workflows/specdev/P-goal-plan/references/goal-tickets-map-template.md

@@ -0,0 +1,15 @@
+---
+schema_version: 1
+artifact: goal-tickets-map
+change: <YYYY-MM-DD-goal>
+implementation_map: "<Path>{roots.state}/specdev/changes/{change}/implementation-map.md</Path>"
+implementation_plan: "<Path>{roots.state}/specdev/changes/{change}/implementation-plan.md</Path>"
+---
+
+# Goal 总控入口
+
+本文件由统一 Goal 创建父实现 change 时生成，只负责入口解析，不缓存成员、依赖、owner、状态或 Gate。
+
+从这里读取上方 Implementation Map/Plan，再进入 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 的 `run` 或 `resume`。先运行 `<Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path>` 的 `--map` 只读检查；实际执行、授权和完成仍走 P/I 原协议。
+
+现有父 change 可以在恢复时由其唯一 Lead 补建此入口，不移动旧工件。仅计划调用不得启动实现。

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

@@ -0,0 +1,28 @@
+# 从 tickets-map 控制整个 Goal
+
+## 只读控制器
+
+使用 `<Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path>`，输入单 change tickets-map、父入口 tickets-map 或旧 Implementation Map。`--repo` 指项目根；可用 `--previous` 提供上轮 JSON 输出，比较输入漂移。输出仅建议 frontier、blocked、in-flight、完成票与受影响闭包，不写状态、不调用 Skill、不授予权限，也不代替既有阶段校验器。
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --map <map-path> --repo <project-root>
+```
+
+Lead 将输出保存到调用方自己的既有 Evidence 位置；不创建独立调度数据库。JSON 中 `input_digest`、`goal_contract_digest` 和逐票 `contract_digests` 是读集快照，不是授权凭据。
+
+## 每轮循环
+
+1. 重读当前 map、Ticket frontmatter、Gate 与 owner；机器检查依赖、Skill、语义资源和路径，Lead 核验真实授权及当前 Git 事实。
+2. 只有依赖成功满足、ready、owner 可判定且无冲突的票才能进入 dispatch。cancelled 不是成功交付：下游必须重规划依赖，不能自动视为 satisfied。
+3. current 策略串行；required 仅在 config/宿主允许且写集、语义资源、integration queue 无冲突时并行。不同文件可能共享 API、数据表、锁文件或公共契约，因此不能只比较文件名。
+4. 按票的调用阶段读取并实际执行必需 Skill；按项目协议调用的“技能”可以是宿主技能调用，也可以是完整执行该 SKILL 的程序步骤，但必须记录对应步骤/工具轨迹与输出，不得仅记录阅读完成。
+5. I 返回后核对实现、Skill 执行记录、验证矩阵、实际交付数量和集成证据。失败保留 blocker；不能用减少测试或替换工具来“修好”状态。
+6. 同步 Ticket 权威状态，再生成 map 投影与检查点。已完成票不重跑副作用；持久化失败不推进 done。
+7. 有他人资源/事务冲突只暂停该票与其依赖闭包，继续独立、已授权票。无法可靠分辨共享资源时，暂停相关资源而非抢占。
+8. frontier 空且仍有未完成票时返回精确缺口；全部票完成后执行 Goal 集成验收，按原完成合同关闭。
+
+## 正式记忆
+
+开始任何正式写入前，先检查原网关的 pending transaction、lock、recovery evidence 与 owner。Goal 只请求拥有 namespace 的原工作流执行，不直接写永久记忆，也不创建“更轻量”的旁路网关。
+
+单票 blocked/deviated 不强制将父 Plan 的全局执行门关闭。只有全局合同失败或合法 frontier 为空时暂停父循环。检查点摘要覆盖 Spec、票合同、实际 Skill/参考版本、依赖、相关 serialization 与共享 Goal 门禁；普通 owner/status 和进度投影不是合同变更。摘要是漂移检测，不替代授权和实证验收。

package/template/workflows/specdev/{O-orchestrate-implementation/O-orchestrate-implementation.md → P-goal-plan/references/multi-change-plan.md}

@@ -1,15 +1,7 @@
----
-id: specdev/orchestrate-implementation
-type: workflow-entry
-workflow: specdev
-name: 编排实现
-description: 将两个或以上已完成 Ready Spec 与 Ready Tickets 的 change 编译为跨 change implementation super-DAG，并由单一 Lead 在一个会话中持续调度实现、验证和集成。
-keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktree, 冲突]
----
+# 多 change Goal 规划与执行
 
-# 编排实现
+本参考由统一 P 按模式调用。plan 只完成步骤 1–3、父总控入口和计划审查；步骤 4–5 仅在显式 run/resume 且执行授权有效时进入。verify 不重新执行已完成票。旧 O current_work 作为兼容恢复键保留，新 P 父 Goal 可用 specdev/goal-plan。
 
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
 
 本 Work 只编排实现。它不创建或补写子 change 的 Triage、Grill、Wayfinder、Spec、Ticket 或普通 Goal Plan。父 change 创建前，每个输入 change 都必须已有 Ready Spec、Tickets Map 和决策完备的 Ready Tickets；缺一项就停止并报告具体缺口。
 
@@ -17,16 +9,10 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 父 change 的主产物是 `<Path>{roots.state}/specdev/changes/{change}/implementation-map.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/implementation-plan.md</Path>`；整体验证写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/implementation-orchestration.md</Path>`。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
 
 ## 激活输入
 
-创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从 active change 中唯一满足 `current_work=specdev/orchestrate-implementation` 且存在父实现产物者确定。
+创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从 active change 中唯一存在父实现产物且 current_work 为 specdev/goal-plan 或 specdev/goal-plan 者确定。
 
 创建父 change 前必须读取并验证：
 
@@ -40,7 +26,7 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 成员的 Spec、Tickets Map、Ticket frontmatter、状态和父级编排证据是 super-DAG 的权威输入，必须完整读取；成员的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和项目 Skills 先按索引、状态和关键词定位，只读取命中的条目。恢复、冲突、漂移和集成失败时按本 Work 的证据合同扩展为全量读取。
 
-加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/input-readiness.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。任何成员未实现就绪、已归档、等于父 change、属于另一个未完成父实现 change，或本身是父实现 change 时，不创建父 change。
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-input-readiness.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。任何成员未实现就绪、已归档、等于父 change、属于另一个未完成父实现 change，或本身是父实现 change 时，不创建父 change。
 
 ## 流程
 
@@ -48,13 +34,13 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 对每个成员穷尽检查 Ready Spec、Tickets Map、Ticket frontmatter、合同覆盖、内部 DAG、路径所有权、验证矩阵和高影响未知项。部分 Ticket 可以已经 done/cancelled；其余待实现 Ticket 必须 `ready: true` 且处于可执行状态。全部 Ticket 已终态的成员只作为 satisfied baseline，不占执行 frontier。
 
-只有所有成员通过输入门后，才从 change status 模板创建普通父 change，在全局 `active` 添加仅含 `change` 的索引，把父 `current_work` 设置为 `specdev/orchestrate-implementation`，再写父 Map/Plan。任何预检失败都不得留下半创建父 change。
+只有所有成员通过输入门后，才从 change status 模板创建普通父 change，在全局 `active` 添加仅含 `change` 的索引，把父 `current_work` 设置为本次入口的 specdev/goal-plan 或兼容 specdev/goal-plan，再写父 Map/Plan。任何预检失败都不得留下半创建父 change。
 
 **完成标准**：父创建是 all-or-nothing；输入成员不少于两个；没有用父 Work 修补任何上游工件。
 
 ### 2. 编译 Implementation Super-DAG
 
-加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/super-dag.md</Path>` 与 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/conflict-and-drift.md</Path>`。
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-super-dag.md</Path>` 与 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-conflict-and-drift.md</Path>`。
 
 1. 将每个子 Ticket 映射为唯一组合节点；
 2. 将所有子 Ticket `blocked_by` 精确提升为组合 dependency；
@@ -63,7 +49,7 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 5. 比较所有待实现 Ticket 的 writable/shared paths、公共合同、repository/ref 和迁移资源；
 6. 检测循环、缺失节点、重复边、无 owner overlap 和子图漂移。
 
-使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-map-template.md</Path>` 写父 Map。Map 是子 Ticket 图的可重算投影；子 Ticket 变化时先重读权威，再递增 Map revision。
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写父 Map。Map 是子 Ticket 图的可重算投影；子 Ticket 变化时先重读权威，再递增 Map revision。
 
 **完成标准**：父 Map 的 members/tasks/internal edges 与全部子工件精确一致；跨 change 边有来源；DAG 无环；每个并行冲突已依赖化、串行化或阻塞。
 
@@ -76,15 +62,17 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 从 config 读取 implementation agent 与 integration attempt 上限，父 Plan 可以降低但不能提高。Lead 不计入实现 agent 数；review/research/test-observation agents 只读且不受该数字限制。同一 repository/ref 的 integration 永远串行。
 
-使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-plan-template.md</Path>` 写父 Plan。已有子 Goal Plan 只提供子 change 内的额外 Gate/约束；其 workspace 策略与父 Plan 冲突时阻塞，不能覆盖父级全局选择。
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写父 Plan。已有子 Goal Plan 只提供子 change 内的额外 Gate/约束；其 workspace 策略与父 Plan 冲突时阻塞，不能覆盖父级全局选择。
 
 Implementation Plan 固定使用 `orchestration: lead-directed`，并显式持久化 `implementation_agent_limit`、`integration_attempt_limit`、workspace/integration 策略和唯一 Lead；恢复时不得从会话记忆重建这些值。
 
 **完成标准**：Lead、workspace/integration 策略、全局 agent 上限、frontier、Wave、serialization owner 和 integration queue 可从父 Plan 恢复。
 
+随后用 `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-tickets-map-template.md</Path>` 写父无状态总控入口，并执行 `<Path>{roots.workflows}/specdev/common/skills/plan-quality-review/SKILL.md</Path>`。plan 到此返回计划、门禁和缺失授权；不得自行进入执行循环。
+
 ### 4. 在一个会话中持续执行
 
-加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
 
 1. 重读父 Map/Plan、所有子 Ticket/status 和 Git；
 2. 计算依赖满足、lock 可用且配额允许的 ready frontier；
@@ -104,15 +92,15 @@ I-implement 是实际实现 owner；父 Work 不复制 TDD、代码审查、Evid
 
 一个成员的全部计划内 Ticket done/cancelled 且其 Goal/Evidence/Git 门通过时，父 Lead 按 change completion 关闭该子 change；不等待其他成员才关闭，也不自动归档。
 
-全部成员 completed 后，Lead 运行跨 change aggregate test/typecheck/lint/build 与适用 E2E，核对跨 change 合同、依赖顺序、共享路径、迁移/恢复和最终 Git checkpoint，并使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-evidence-template.md</Path>` 写整体验证。
+全部成员 completed 后，Lead 运行跨 change aggregate test/typecheck/lint/build 与适用 E2E，核对跨 change 合同、依赖顺序、共享路径、迁移/恢复和最终 Git checkpoint，并使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写整体验证。
 
-只有父 Map/Plan completed、全部成员 completed、无 blocker/deviation/active dispatch/candidate/lock 且整体验证通过时，才清空父 `current_work`、去重加入 `specdev/orchestrate-implementation` 到 `works_run` 并关闭父 change。归档、push、PR、remote merge、deploy 和生产迁移保持独立授权。
+只有父 Map/Plan completed、全部成员 completed、无 blocker/deviation/active dispatch/candidate/lock 且整体验证通过时，才清空父 `current_work`、去重加入 `specdev/goal-plan` 到 `works_run` 并关闭父 change。归档、push、PR、remote merge、deploy 和生产迁移保持独立授权。
 
 运行：
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage orchestrate-implementation \
+  --stage goal-plan \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 
@@ -128,11 +116,11 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 ## 子文件引用
 
-- 输入就绪门：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/input-readiness.md</Path>`
-- Super-DAG：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/super-dag.md</Path>`
-- 执行循环：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/execution-loop.md</Path>`
-- 冲突与漂移：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/conflict-and-drift.md</Path>`
-- Map 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-map-template.md</Path>`
-- Plan 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-plan-template.md</Path>`
-- Evidence 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-evidence-template.md</Path>`
+- 输入就绪门：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-input-readiness.md</Path>`
+- Super-DAG：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-super-dag.md</Path>`
+- 执行循环：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-execution-loop.md</Path>`
+- 冲突与漂移：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-conflict-and-drift.md</Path>`
+- Map 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- Plan 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- Evidence 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
 - 共享规则：`<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`

package/template/workflows/specdev/P-goal-plan/references/replan-and-recovery.md

@@ -0,0 +1,21 @@
+# 重规划、旧票升级与恢复
+
+## 失效范围
+
+导致公共行为、接口、数据、安全、范围、验收或输出数量改变的事实，回到相应上游 owner 决定。记录旧摘要、新摘要、原因、用户决定和受影响票。沿真实依赖边计算失效闭包；同一 change 的 Spec 改变会使相关票重新核对，不能从旧 map 覆盖子合同。独立 change 未受影响的票继续。
+
+父计划沿用 `revision` 与 `source_map_revision`；单 change 新版 map 用 `plan_revision`。先保留旧证据，再生成新活动投影；不能回写旧记录伪装为原先就已批准。
+
+## 旧票升级
+
+既有 v3 Ticket/Map 保持可读；已完成或已归档票不追溯改写。下一次执行未完成旧票前：
+
+1. 核验归属、当前工作树与未闭合事务；保留原文件备份和摘要，不碰其他任务。
+2. 先读取票的背景和验收，扫描真实项目 Skill 入口，补充 `plan_contract_version: 1`、`skill_scan`、`skill_bindings`、`resource_claims` 与调用/停止章节。
+3. Map 补充版本、用户交付数量及其确认记录、控制入口；已有字段和默认行为保持。
+4. 重新执行 T 的 Ready 与计划审查，再运行 tickets 校验。用户指定数量、权限、默认工具或集成策略变化必须明确批准；不能默默“升级”权限。
+5. 从备份与变更清单恢复应只覆盖本任务实际改动，保留原软链接和元数据。任何失败只阻塞受影响票，不将整个 Goal 判为完成。
+
+## 恢复动作
+
+读取而非重建检查点；确认 HEAD、source commit、parent result、Evidence 和 owner。已提交未集成、已执行迁移未验证、已开始正式记忆事务等状态只通过原流程恢复。未知归属或缺少恢复证据时不自动撤销、不解锁、不重试不可逆动作；报告人工恢复要求。

package/template/workflows/specdev/P-goal-plan/references/single-change-plan.md

@@ -0,0 +1,149 @@
+# 目标规划
+
+
+Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
+
+每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时，用户尚未明确才询问是否开启 worktree 开发，默认不开启；选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 implementation subagent，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
+
+产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
+
+
+## 何时运行
+
+满足任一条件时运行：
+
+- 多个 Ticket 可以或需要并行；
+- 存在 shared path、共享合同或集中 owner；
+- 存在 Deep Ticket、expand-contract、迁移、兼容窗口或不可逆步骤；
+- 存在多个 Gate、外部审批、发布窗口或高事故半径；
+- Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
+- 用户明确要求正式跨 Ticket Plan。
+
+少量、线性、低风险的 Ready Tickets 可以不生成厚重编排正文，但执行前仍要有最小 Goal Plan 记录 workspace、Lead、Gate 和授权引用；不得引用不存在的当前 Goal Plan。没有 Ticket 的获批小型 Direct Spec 不受 Ticket workspace 合同约束；一旦需要切片，先运行 T-tickets。
+
+## 输入
+
+必须读取：
+
+- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`：先枚举 Ticket 入口的 frontmatter、依赖和状态，按 DAG、路径和风险定位需要完整读取的 Ticket。
+- `<Path>{roots.state}/specdev/config.json</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>`
+- 用户提供的合同、标准、参考实现、环境限制、发布窗口和批准策略。
+
+非当前分支的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和永久目录先通过索引、状态和关键词定位；只有被当前 Gate、依赖、冲突或恢复条件命中的条目才回读原文。Tickets Map、当前计划和决定 DAG 的 Ticket frontmatter 是权威编排输入，仍需完整读取。
+
+永久目录可以为空，静默继续。缺少 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. 验证上游与执行边界
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`：
+
+1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和 Deep Ticket 完整性；
+2. 只读探索影响调度的代码与项目事实；
+3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
+4. 从 config 读取 `max_implementation_agents` 与 `max_integration_attempts`，将实际值快照到 `implementation_agent_limit` 与 `integration_attempt_limit`；本计划可以降低但不得超过 config 或平台能力，Lead 不计入；
+5. 根据 workspace 策略记录实现 commit 与 direct-parent/candidate integration 授权事实；缺失时仍可完成 plan 文档，但 ready_for_execution 保持 false，并列为 run 的阻塞条件；
+6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
+
+**完成标准**：所有计划内 Ticket Ready；Lead、授权、实现并发上限和父分支可判定；没有用 Goal Plan 掩盖上游缺口。
+
+### 2. 构建 Outcome、DAG、Wave 与 Gate
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
+
+1. 压缩 Outcome、成功/伪完成、非目标和权威来源；
+2. 从 Ticket frontmatter 构建 DAG、关键路径、扇出与汇合点；
+3. 为 shared path、共享合同和集中修改指定唯一 owner；
+4. 将依赖满足且项目写路径不相交的 Ticket 分入 Wave；current 模式仍按依赖顺序串行执行，不得把 Wave 当作并发授权；
+5. 为合同稳定、垂直路径、迁移完成、发布就绪等状态定义 Gate；
+6. 为每个 Ticket 记录开始条件、workspace 策略、验证层级、Evidence 目标、集成顺序和失败恢复。
+
+**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个 Ticket 有唯一项目写 owner、worktree 合同和可验证集成出口。
+
+### 3. 固定 Lead 编排与动态派单合同
+
+加载 `<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. 固定 Lead 的可恢复 owner/session locator；
+2. 声明 implementation subagent 的 config/平台约束上限，Lead 不计入；
+3. 不为只读 review/research/test-observation agent 写 SpecDev 数字上限；
+4. current 模式固定只有一个 implementation writer 写项目路径，Lead 仍是唯一 SpecDev 工件与状态写入者；required 模式 implementation owner 写自己的 Ticket worktree；
+5. 定义执行期动态 Dispatch Packet、候选返回和 Lead 验收；
+6. provider、模型和具体派单在 Ticket 开始时按事实选择，不在 Goal Plan 中预分配。
+
+**完成标准**：Lead 可以在恢复后重建派单边界；任何 subagent 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
+
+### 4. 定义完成、证据与恢复
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
+
+1. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
+2. 固化不可协商约束与允许的局部实现自由；
+3. 按 workspace 策略为每个 Ticket 明确 current-workspace/direct-parent 检查或 source-worktree/parent-candidate 检查；
+4. E2E 按 Ticket 实际跨边界风险标记 required 或 not-required；
+5. 定义 direct-parent 验证失败、candidate 冲突/失败、父 HEAD 漂移、偏差、暂停、批准和恢复动作；
+6. 定义 change 完成、远程 reconcile、残余风险和回滚要求。
+
+**完成标准**：每个完成声明映射到不可变 commit、候选/父分支 SHA、命令、Evidence 或人工批准。
+
+### 5. 写入、同步与验证
+
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 Goal Plan：
+
+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> \
+  --stage goal-plan \
+  <Path>{roots.state}/specdev/changes/{change}</Path>
+```
+
+5. 原子更新 Goal Plan、Tickets Map、全局/current change 状态并重新读取；
+6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
+7. 未经用户要求，不自动进入实现。
+
+## 决策完备标准
+
+每份 Goal Plan 必须让 Lead 无需重新决定：
+
+- Outcome、权威来源和整体完成；
+- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
+- shared path 与共享合同 owner；
+- implementation subagent 上限及动态派单边界；
+- 每 Ticket workspace、implementation commit、对应验证和父分支推进规则；
+- E2E disposition、偏差、暂停、批准和恢复路径。
+
+Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
+
+## 完成标准
+
+- Goal Plan schema v6 且 `ready_for_execution` 与状态一致；
+- Lead 唯一，implementation subagent 上限来自 config/平台能力，review/research agent 不受 SpecDev 数字限制；
+- 每个实现 Ticket 都有 workspace、commit、对应 integration gate 和 Evidence 出口；
+- current 模式不创建 source/candidate worktree，适用 E2E 由 Lead 在 current workspace 运行；required 模式保持 source/parent-candidate 边界；
+- 计划只保留当前固定 Lead 与选定 workspace/integration 合同；
+- 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>`
+- 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>`