@namewta/speculo 0.7.2 → 0.7.3

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

@@ -1,11 +1,14 @@
 ---
-schema_version: 3
+schema_version: 5
 artifact: goal-plan
 change: <YYYY-MM-DD-topic>
 status: draft
-modes: [coordination]
-coordination_mode: single-session
-workspace_strategy: current
+modes: []
+orchestration: lead-directed
+lead: <owner-or-session-locator>
+implementation_agent_limit: 3
+ticket_workspace_policy: required
+integration_gate: candidate-merge
 ready_for_execution: false
 ---
 
@@ -30,10 +33,11 @@ ready_for_execution: false
 | 优先级 | 来源 | 负责内容 | 冲突处理 |
 |---|---|---|---|
 | 1 | 用户最新明确决定 | 产品取舍与批准 | 更新真正拥有该决策的工件 |
-| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 当前 change 架构决定 | 通过新决定替代 |
-| 3 | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | 外部行为、范围与验收 | 下游不得改写 |
-| 4 | `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` | 单 Ticket 契约 | Goal Plan 只编排 |
-| 5 | 当前代码事实 | 现状与可行性 | 冲突时触发偏差 |
+| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>` | 当前 change 架构决定与领域语义 | 返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>` 更新真正 owner |
+| 3 | `<Path>{roots.state}/specdev/adr/</Path>` 与 `<Path>{roots.state}/specdev/context/</Path>` | 已毕业的永久决定与领域知识 | 当前 change 替代时在 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 明示 |
+| 4 | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | 外部行为、范围与验收 | 下游不得改写 |
+| 5 | `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>` | 单 Ticket 契约 | Goal Plan 只编排 |
+| 6 | `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>` 与当前代码/运行事实 | 已验证根因、现状与可行性 | 冲突时触发偏差并返回真正 owner |
 
 ## 2. Execution Graph
 
@@ -45,14 +49,14 @@ ready_for_execution: false
 
 ### Waves and Ownership
 
-| Wave | Ticket | 前置条件 | 项目写路径 | Shared owner | 集成点 |
+| Wave | Ticket | 前置条件 | 项目写路径 | Shared owner | Gate/集成序号 |
 |---|---|---|---|---|---|
 
 ### Ticket Quick Reference
 
-| ID | Ticket | 行为产出 | Depth/Risk | Dependencies | Wave/Gate | Owner | Evidence |
-|---|---|---|---|---|---|---|---|
-| T-01 | `<Path>{roots.state}/specdev/changes/{change}/ticket/01-<name>.md</Path>` | ... | standard/medium | — | W0/G0 | `<owner>` | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
+| ID | 可观察产出 | Dependencies | Worktree | Implementation owner | E2E disposition | Evidence |
+|---|---|---|---|---|---|---|
+| T-01 | ... | — | `specdev-worktree/T-01` | Lead / dynamic dispatch | required / not-required: reason | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
 
 ## 3. Gates and Completion Evidence
 
@@ -60,7 +64,7 @@ ready_for_execution: false
 
 ### Gates
 
-| Gate | 开启条件 | 关闭证据 | 阻塞范围 | Owner/批准人 | 失败恢复 |
+| Gate | 开启条件 | 关闭证据 | 阻塞范围 | Lead/批准人 | 失败恢复 |
 |---|---|---|---|---|---|
 
 ### Contract and Reference Coverage
@@ -70,41 +74,44 @@ ready_for_execution: false
 
 ## 4. Execution and Integration Protocol
 
-### Execution Topology
+### Lead Orchestration
 
-| 维度 | 决定 | 事实依据 |
+| 项目 | 决定 | 事实依据 |
 |---|---|---|
-| Coordination | single-session | 未启用严格角色分派；辅助调查只能返回只读结论 |
-| Workspace | current | 没有并行写入或其他隔离触发条件 |
+| Lead | `<owner-or-session-locator>` | 唯一 SpecDev 状态、Evidence 与父分支 owner |
+| Implementation subagents | `<= 3`，Lead 不计入 | config、依赖和平台能力的最小值 |
+| Read-only agents | 无 SpecDev 数字上限 | review/research/test-observation，不写状态 |
+| Dispatch | execution-time dynamic | provider/模型/派单按 Ticket 事实选择 |
 
-### Ticket Execution Order
+### Ticket Workspace and Candidate Integration
 
-| Ticket | 开始条件 | 执行 owner | 必跑验证 | Evidence | 集成条件 |
-|---|---|---|---|---|---|
+| Ticket | Parent/base | Worktree/branch | Source checks | Source commit | Candidate checks/E2E | Parent result |
+|---|---|---|---|---|---|---|
+
+集成按表中顺序串行进行。source worktree 不运行 E2E；Lead 在最新父分支的 candidate 状态运行集成检查和适用 E2E，通过且父 HEAD 未漂移后才推进父分支。
 
 ### Authorization Matrix
 
 | 动作 | 状态 | 目标与条件 |
 |---|---|---|
-| Local changes | allowed / not-authorized | ... |
-| Implementation commit | allowed / not-authorized | ... |
-| Remote repository actions | allowed / not-authorized | ... |
-| Deploy / Migration | allowed / not-authorized | ... |
-| Production configuration / feature / real user data | allowed / not-authorized | ... |
+| Ticket worktree local changes | allowed / not-authorized | 限 writable/shared owner 合同 |
+| Implementation commit | allowed / not-authorized | 每 Ticket 必需；缺失则 Plan blocked |
+| Local candidate integration and parent update | allowed / not-authorized | Lead-only；缺失则 Plan blocked |
+| Push / PR / remote merge | allowed / not-authorized | 不从本计划本地授权继承 |
+| Branch/worktree cleanup | allowed / not-authorized | 成功集成不自动继承 |
+| Deploy / migration / production actions | allowed / not-authorized | 逐动作、目标和条件 |
 
-### Evidence Return and Integration
+### Evidence Return
 
-每个实现者按 I-implement 与对应 Ticket 执行，写入 Evidence 并同步 Ticket/Map/Goal Plan。最后一个计划内 Implement 汇总 Gate、运行适用集成验证，并按完成合同关闭 change。
+subagent 只返回候选事实与 commit；Lead 独立核对并写 Evidence、状态和最终验收。
 
 ## 5. Constraints, Risk and Recovery
 
 ### Non-negotiable Constraints
 
-每条包含来源和违反后果；局部实现自由进入 Guidance。
-
 ### Verification Integrity
 
-记录不可修改的判卷接缝、基线非退化条件、禁止的伪绿色方式，以及仅对静默失败风险执行的受控反向验证。
+记录判卷接缝、基线、禁止的伪绿色方式，以及 source/candidate 两层验证边界。
 
 ### Migration or Release Sequence
 
@@ -118,18 +125,14 @@ ready_for_execution: false
 
 ### Current Status
 
-记录 Wave/Gate、Ticket、最近验证证据和未验证项；不使用主观百分比。
+记录 Wave/Gate、Ticket、source/candidate/result SHA、最近验证和未验证项；不使用主观百分比。
 
 ### Pending Decisions and Blockers
 
-记录失败命令、已通过行为、owner 和恢复条件。
-
 ### Resume Protocol
 
-恢复时读取本 Goal Plan、当前 Ticket、最新 Evidence 和 change 状态，从最后已验证事实继续。
-
-### Reporting Format
+恢复时读取 Goal Plan、当前 Ticket、change worktree 状态和最新 Evidence；从最后通过的父分支 result 或待修正 source checkpoint 继续。
 
 ## Assumptions
 
-仅记录低影响、可逆且有验证方式的假设。高影响假设存在时，`ready_for_execution` 必须为 `false`。
+只记录低影响且可验证的假设。存在高影响假设时 `ready_for_execution` 必须为 `false`。

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

@@ -0,0 +1,34 @@
+# Lead 编排与动态派单协议
+
+## 1. 唯一 Lead
+
+Lead 是主会话中的唯一编排 owner，保留需求解释、DAG/Wave/Gate、路径分配、权限、SpecDev 状态、Evidence、候选验收、父分支集成和最终回复责任。恢复时以 Goal Plan 的 `lead` locator 和权威工件继续；更换会话只转移 Lead 身份，不产生第二写入者。
+
+## 2. 派单类型
+
+- **implementation**：写入单个 Ticket worktree 的授权项目路径，运行非 E2E 检查并返回 source commit；
+- **review**：只读审查固定 checkpoint，返回 findings；
+- **research**：只读收集代码或外部事实，返回来源与结论；
+- **test-observation**：只读运行或观察已授权检查，返回命令与结果，不拥有 E2E Gate。
+
+Lead 在 Ticket 可以独立执行、写路径不冲突、上下文足够且平台支持时派单。派单是执行期决定，不写回 Goal Plan 作为固定拓扑。
+
+## 3. 并发
+
+implementation subagent 同时最多三个，实际值取 Goal Plan、config 与平台能力的最小值；Lead 不计入。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免测试资源冲突、重复工作和上下文失控。
+
+## 4. 写入边界
+
+implementation subagent 只写分配 worktree 中的项目路径和其 Git commit，不写 Ticket、Map、Goal Plan、Evidence、change status 或父分支。其他 subagent 全部只读。Lead 接收返回后独立核对，再写所有 SpecDev 状态。
+
+## 5. 动态 Dispatch Packet
+
+每次派单必须绑定 Ticket、Goal Plan、依赖 Evidence、不可变 `base_sha`、branch/workspace locator、writable/read-only/shared paths、provider、允许动作、非 E2E 验证、停止条件和返回格式。provider 或模型按当次能力与授权选择；外部 provider 需要独立的数据发送授权。
+
+implementation 返回至少包含：Ticket ID、workspace locator、最终 commit、dirty 状态、修改路径、检查命令/结果、未验证项、冲突与阻塞。review/research 返回固定输入、findings、来源和未验证声明。
+
+## 6. Lead 验收
+
+Lead 核对基线、路径、commit、dirty 状态、项目事实与非 E2E 结果；不接受 subagent 自报的 Evidence 或 E2E pass。implementation 候选进入 dev-worktree candidate-merge；read-only 结果由 Lead 复核后写入对应权威工件。失败返回同一 Ticket worktree 修正或标记 blocked。
+
+**完成标准**：每次写入只有一个 Ticket/owner/worktree；所有 SpecDev 状态由 Lead 落盘；派单和返回可从 Evidence 恢复。

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

@@ -1,71 +1,56 @@
 # Goal Plan 核心编排协议
 
-本文件定义所有 Goal Plan 都需要的 DAG、Wave、Gate、路径所有权、Evidence 返回和集成规则。它不建立 Lead/subagent 角色或 Agent 交付合同。
+本文件定义 DAG、Wave、Gate、路径所有权、Ticket worktree、Evidence 返回和父分支集成队列。
 
 ## 1. DAG 与关键路径
 
-- 依赖权威来自 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` frontmatter 的 `blocked_by`；
-- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是投影，不是第二套依赖真相；
+- 依赖权威来自 Ticket frontmatter 的 `blocked_by`；Tickets Map 是投影；
 - 计算根节点、扇出、汇合点、关键路径、共享合同 owner 和最终收缩点；
-- 依赖只表示真实开始条件，不表示偏好、人员交接或“最好先做”；
-- 无法独立保持可验证状态的迁移批次必须有隔离集成策略和最终集成 Gate。
+- 依赖只表示真实开始条件，不表达偏好、Agent 交接或“最好先做”；
+- 无法独立保持可验证状态的迁移批次必须有明确 Gate 和恢复策略。
 
-## 2. Wave
+## 2. Wave 与实现并发
 
-Wave 内 Ticket 必须同时满足：
+Wave 内 Ticket 必须 Ready、依赖 Evidence 完整、项目写路径不相交、shared owner 已稳定、适用 Gate 已打开且基线一致。
 
-- `ready: true`；
-- 所有依赖已完成并有 Evidence；
-- 项目写路径不相交；
-- shared path 已由 owner 稳定；
-- 适用 Gate 已打开；
-- 源码基线和外部合同版本一致。
-
-最大并发从 `<Path>{roots.state}/specdev/config.json</Path>` 读取。并发上限是资源约束，不是必须填满的目标；Wave 也不意味着必须使用多个 Agent。
-
-Wave、Agent Team 和 worktree 是三个不同概念。Wave 只表达依赖上可并发；是否委派由 coordination mode 决定，是否隔离写入由 workspace strategy 决定。只读并行不需要 worktree；同一 current workspace 只能有一个项目与状态写入 owner。
+Lead 根据当前事实决定自行实现或派单。同时活跃的 implementation subagent 不得超过 Goal Plan 与 config 中较小的上限，且绝不超过三个；Lead 不计入。Wave 是可并发性，不是必须填满的目标。只读 review/research/test-observation agent 不写固定数字上限，但不得写项目或 SpecDev 状态，也不得争用同一可变测试环境。
 
 ## 3. Gate
 
-Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条件。每个 Gate 必须写明业务或工程状态、开启条件、关闭证据、阻塞范围、owner/批准人和失败恢复。
-
-常见 Gate 包括共享合同稳定、首条垂直路径通过、迁移完成、旧调用点归零、发布就绪和观察期结束。名称按项目语义自定义。
-
-## 4. Shared path 与共享合同
+Gate 用可验证状态定义，必须写明：工程/业务状态、开启条件、关闭证据、阻塞范围、Lead/批准人和失败恢复。常见 Gate 包括共享合同稳定、首条垂直路径、迁移完成、旧调用点归零、候选合并通过、发布就绪和观察期结束。
 
-规则遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
+## 4. Shared path 与合同
 
-1. 由专用 owner Ticket 或计划指定的唯一 owner 修改共享路径；
-2. 形成可验证稳定基线；
-3. 下游消费者在新基线上重新运行 preflight；
-4. 才允许扇出或继续后续 Ticket；
-5. 共享契约需要变化时暂停消费者并修订上游，不通过多个执行者同时修改解决。
+遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
 
-## 5. Expand-contract
+1. 专用 owner Ticket 修改共享路径；
+2. 在其 worktree 形成 commit 与非 E2E 证据；
+3. 通过 Lead candidate-merge 进入父分支；
+4. 下游 Ticket 基于新的父分支 checkpoint 创建或刷新 worktree；
+5. 共享合同变化时暂停消费者并修订上游，不让多个执行者竞争写入。
 
-标准顺序：
+## 5. 每 Ticket worktree
 
-1. **expand**：新旧形式并存，既有调用者继续工作；
-2. **migrate**：按可独立验证的影响范围分批迁移；
-3. **observe**：扫描旧调用点、旧数据或旧协议使用量；
-4. **contract**：收缩条件有证据后删除旧形式；
-5. **verify**：运行兼容、数据、回归、监控和回滚检查。
+每个进入 I-implement 的 Ticket 建立唯一 `specdev-worktree/<ticket-id>`。记录 workspace/implementation/integration owner、`base_sha`、父分支、branch、portable locator、source checkpoint、candidate/result SHA 与验证状态。Lead 自行实现时仍进入该 worktree；subagent 身份不决定是否隔离。
 
-收缩不得仅以“所有迁移 Ticket 已完成”为依据。
+同一 Ticket 在 candidate 验证失败后保留来源 worktree并继续修正。新的 source commit 替换当前 `source_checkpoint`，旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
 
-## 6. Ticket 执行、Evidence 与集成
+## 6. 父分支集成队列
 
-每个计划 Ticket 必须写明开始条件、依赖 Evidence、项目路径合同、workspace 分配、适用 Gate、必跑验证、Evidence 目标和失败恢复。实际执行仍由 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与 Ticket 拥有，不在 Goal Plan 复制局部施工步骤。
+Lead 串行集成 Ready 候选：
 
-Current workspace Ticket 由该 workspace 的唯一写入 owner 顺序执行。隔离 Ticket 的创建、恢复和本地集成由 workspace addendum 与 dev-worktree Skill 管理；integration owner 是核心编排角色，不预设为 Lead。`single-session` 时通常映射为主会话，`lead-team` 时通常映射为 Lead。
+1. 冻结最新 `parent_before_sha`；
+2. 在 Lead-owned parent integration checkout 组合父分支与 `source_checkpoint`；
+3. 生成可定位的 `candidate_sha`；
+4. 在 candidate 状态运行集成检查和适用 E2E；
+5. 重读父 HEAD；若变化，将候选标记 `stale` 并重建；
+6. 检查通过且父 HEAD 未变时，父分支 fast-forward 到 candidate；
+7. 重读父 HEAD/tree，写入 `result_sha` 后才允许 Ticket Done。
 
-每个实现者完成或阻塞时：
+父分支是 source checkpoint 的祖先时 candidate/result 可等于 source SHA，方法为 `fast-forward`；否则 candidate 必须是独立 merge commit。候选失败时父分支保持不变，Ticket 回到 `in_progress` 或 `blocked`。
 
-1. 写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`；
-2. 同步 Ticket、Tickets Map、Goal Plan 和 change 状态；
-3. 检查依赖、路径所有权、合同覆盖和适用 Gate；
-4. 返回 Ticket 状态、Evidence 路径、代码引用、未验证项和恢复条件。
+## 7. Expand-contract
 
-最后一个计划内 Implement 按 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>` 汇总核心计划的 Gate 和 Evidence。Lead Team 的候选交付验收由独立委派协议拥有；worktree 的 Git 集成由角色中立的 workspace 协议拥有。
+标准顺序为 expand → migrate → observe → contract → verify。每批迁移独立 commit、candidate 验证和父分支集成；收缩依据旧调用/数据/协议归零证据，不依据 Ticket 数量推断。
 
-**完成标准**：每个执行结果可追溯到代码状态和 Evidence；single-session Goal Plan 可以在不建立角色交付合同的情况下完整恢复和完成。
+**完成标准**：每个 Ticket 从父基线、source commit、candidate 到 result 都可恢复；父分支只包含已通过候选门禁的 Ticket。

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

@@ -1,91 +1,57 @@
 # Goal Plan 规划模式与输入门禁
 
-本文件由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 在上游验证和角色分支确认时加载。
+规划模式描述 Goal Plan 需要额外解决的工程问题，不再表示 Agent 或 workspace topology。Lead-directed、每 Ticket worktree 和 candidate-merge 是所有新 Goal Plan 的固定合同。
 
-## 1. 必需输入门禁
+## 1. 输入门禁
 
-- [ ] `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` 设置 `ready_for_tickets: true`，或存在用户明确批准的等价权威目标。
-- [ ] `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 与全部 Ticket 一致。
-- [ ] 所有计划执行的 Ticket 设置 `ready: true`。
-- [ ] Ticket ID、具体 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` 和 Map 行一致。
-- [ ] `blocked_by` 引用存在，DAG 无环。
-- [ ] Spec 验收合同全部 covered，或 deferred 项有批准、原因和后续归属。
-- [ ] 可能并行的 Ticket 项目写路径不相交，或已有 shared owner 与排序方案。
-- [ ] Deep Ticket 具备迁移、兼容、监控、回滚、收缩条件和批准点。
-- [ ] Ticket 与 Spec、ADR、代码事实不存在未处理冲突。
-- [ ] 项目声明的验证命令真实存在且能观察目标行为；不可运行项有替代证据或明确 blocker。
-- [ ] 当前源码基线、工作区状态和外部合同版本已实测，而非使用浮动的“最新”描述。
+开始规划前穷尽检查：
 
-## 2. 硬停止
+- Spec `ready_for_tickets: true`，或上游工件已等价覆盖范围、合同与验收；
+- Tickets Map 与全部 Ticket 存在、Ready、DAG 无环；
+- 每个验收合同被 Ticket 覆盖；
+- writable/shared path 有唯一 owner，Wave 候选无写冲突；
+- config schema v4，`max_implementation_agents` 为 `1..3`；
+- 父分支可定位，implementation commit 与本地 integration 已获授权；
+- Deep Ticket 的迁移、兼容、监控、恢复和不可逆批准点完整。
+- Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`、`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>` 和当前代码事实不存在未处理冲突；
+- 项目声明的验证命令真实存在，并能观察目标行为；不可运行项有替代证据或明确 blocker；
+- 当前源码基线、父分支、工作区状态和现有用户改动已经实测；
+- 外部合同、标准、参考实现或依赖版本已经固定，不使用浮动的“最新”描述。
 
-出现以下任一情况时停止：
+缺失上游事实返回其 owner；非 v4 Goal Plan 必须按当前合同重新规划，不能只修改版本号。
 
-- 任一计划内 Ticket 未 Ready；
-- DAG 有环、缺失引用或依赖仅代表偏好；
-- 合同 uncovered 且未批准 deferred；
-- 并行候选写路径相交且无 owner 或顺序；
-- Ticket 改写了 Spec 的外部行为、范围或验收；
-- Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 的已接受决定冲突；
-- Deep Ticket 缺少关键迁移或恢复信息；
-- 当前代码事实使 Ticket 的核心行为、接口或验证不可执行；
-- 必需外部合同或参考权威不可获得；
-- 已选择委派，但 Lead、checkpoint、可恢复 locator 或交付通道无法建立；
-- workspace strategy 为 worktree/mixed，但任一隔离 Ticket 缺少允许的 trigger、父分支、integration owner、可恢复 locator 或结束动作；
-- `lead-team + current` 中存在 `worker-write`，或 current workspace 出现多个项目/状态写入 owner；
-- 用户要求的远程或生产动作没有逐动作授权。
+## 2. 可组合模式
 
-按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>` 返回真正拥有该决策的工件。
+- `migration`：存在 expand-contract、数据/协议迁移、兼容窗口或收缩条件；
+- `high-assurance`：涉及安全、隐私、资金、数据完整性、法规、关键基础设施、不可逆操作或高事故半径；
+- `reference-conformance`：必须逐项符合外部标准、协议、设计或参考实现；
+- `release-coordination`：存在发布窗口、跨团队依赖、外部批准、阶段部署、观察期、运营交接或远程 reconcile。
 
-## 3. 可组合规划模式
+没有适用模式时 `modes: []`。模式只增加对应 Gate、证据和恢复，不改变 Lead、worktree 或集成基本合同。
 
-- **coordination**：多 Wave、扇出/汇合或 shared path；重点是 DAG、owner、Evidence 返回、集成和状态同步。
-- **migration**：expand-contract、数据或协议迁移；重点是扩展、分批迁移、收缩条件、数据核对、监控和回滚。
-- **high-assurance**：安全、隐私、资金、数据完整性、法规或不可逆操作；重点是独立审查、人工批准、Evidence 完整性和失败恢复。
-- **reference-conformance**：外部合同、标准、官方实现或指定兼容行为；重点是来源版本、符合性矩阵和冲突裁决。
-- **release-coordination**：发布窗口、跨团队依赖、部署顺序或运营交接；重点是环境前置条件、Gate、观察期和回退。
+## 3. 固定执行拓扑
 
-模式可以组合。仅有线性低风险 Ticket 时不应为了形式生成重型 Goal Plan。
+- `orchestration: lead-directed`；
+- `ticket_workspace_policy: required`；
+- `integration_gate: candidate-merge`；
+- `implementation_agent_limit` 不大于 config，也不大于 `3`；
+- Lead 不计入 implementation subagent 数量；
+- review/research/test-observation agent 无 SpecDev 固定数字上限，但必须保持只读且不竞争同一可变环境；
+- provider 与派单在执行期决定，不成为 Goal Plan 的静态枚举。
 
-## 4. 锁定正交执行维度
+## 4. Ready 停止条件
 
-规划模式描述为什么需要跨 Ticket 治理，不决定协作或工作区方式。每份新 Goal Plan 都必须分别记录：
+存在以下任一情况时 `ready_for_execution: false`：
 
-- `coordination_mode: single-session | lead-team`；
-- `workspace_strategy: current | worktree | mixed`。
+- Lead locator 无法恢复；
+- 本地 commit 或 candidate integration 未授权；
+- Ticket 无法建立独立 worktree 或父分支不明确；
+- shared path 没有唯一 owner；
+- E2E 是否需要会改变验收结论但尚未确定；
+- 项目验证命令不能执行或无法观察目标行为，且没有批准的替代证据；
+- 当前源码/工作区基线未实测，或外部合同版本仍然浮动；
+- Ticket 与 Spec、ADR、`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>` 或代码事实存在未处理冲突；
+- 迁移、发布、不可逆动作或恢复存在高影响未知项；
+- 实现 agent 上限超过 `3`。
 
-`single-session` 是默认协作方式：主会话拥有全部项目和 SpecDev 状态写入，只读探索、日志分析、测试观察和审查 Agent 可以返回结论，但不得成为第二写入者。只有用户明确要求或确认严格角色分派时才能使用 `lead-team`；不得根据 Ticket 数量、并行机会或平台能力静默启用。
-
-Workspace 按 Ticket 判断，允许触发只有：`parallel-write`、`protect-local-state`、`disposable-experiment`、`background-resume`、`provider-requirement`、`user-requested`。每个触发必须引用实测事实；Agent Team、Ticket 数量、只读并行、顺序写入或泛化的“更安全”都不是触发条件。全部 Ticket 使用当前工作区时为 `current`；全部项目写入位于隔离 workspace 时为 `worktree`；两者并存时为 `mixed`。
-
-四种组合均合法，但约束不同：
-
-| Coordination | Workspace | 写入约束 |
-|---|---|---|
-| single-session | current | 主会话唯一写入 |
-| single-session | worktree/mixed | 主会话管理并集成隔离写入 |
-| lead-team | current | Lead 唯一写入，Worker 只读 |
-| lead-team | worktree/mixed | `worker-write` 每项绑定独立 workspace，Lead 默认承担 integration owner |
-
-选择 Lead Team 后固定 Lead、provider、repository、不可变 `base_sha` 或等价基线、源码交付方式、`max_correction_rounds` 和逐动作授权。选择 worktree/mixed 后固定每项的 trigger、workspace owner、integration owner、父分支、locator、来源 checkpoint 策略和结束动作。认证秘密和机器绝对路径不得进入 Goal Plan。
-
-## 5. 规划摘要
-
-写入前形成核心摘要：
-
-```text
-modes=<mode-list>
-coordination_mode=single-session|lead-team
-workspace_strategy=current|worktree|mixed
-tickets=<count>
-critical_path=<ticket-list>
-parallel_capacity=<n>
-shared_owners=<owner-map>
-gates=<gate-list>
-authorization=<action-summary>
-hard_stops=<none-or-list>
-adopted_assumptions=<low-impact-only>
-```
-
-Lead Team 额外形成 `execution_model`、`lead`、`provider`、`checkpoint`、`source_delivery`、`max_correction_rounds` 和 locator；worktree/mixed 额外形成逐 Ticket workspace allocation。两类字段分别只进入各自附录。
-
-**完成标准**：规划 modes、coordination mode 与 workspace strategy 互不代替；single-session 没有委派痕迹；current 没有隔离安排；所有条件分支的源码、交付、权限和恢复字段都有可验证值。
+**完成标准**：所有固定字段、适用模式、授权、Lead、父分支和阻塞均可验证；没有替代编排模型或空占位。

package/template/workflows/specdev/T-tickets/T-tickets.md

@@ -94,7 +94,7 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 
 - `lite`：局部、可逆、沿用既有模式、无公共契约或迁移影响；
 - `standard`：大多数多文件或跨层垂直切片；
-- `deep`：公共 API/schema、数据迁移、安全/隐私/资金、不可逆操作、expand-contract、共享核心路径、多 Agent 或高事故半径。
+- `deep`：公共 API/schema、数据迁移、安全/隐私/资金、不可逆操作、expand-contract、共享核心路径、多个 implementation owner 的跨 Ticket 写入协调或高事故半径。
 
 规划深度不是优先级，也不是 Gate。每个 Ticket 必须记录触发该深度的原因。
 
@@ -111,7 +111,8 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 - 有序执行路线和安全落点；
 - expected、writable、read-only、shared 路径；
 - 正常、失败和回归验证矩阵；
-- 用户界面交互受影响时的 E2E Gate 与执行 owner；后续委派 Goal Plan 可以显式把该 Gate 转交 Lead；
+- 每个 Ticket 的 source-worktree 非 E2E 检查、父分支 candidate 集成出口，以及按实际跨边界风险判定的 E2E disposition；
+- 每个实现 Ticket 的独立 worktree、implementation commit 与父分支合并完成条件；
 - Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点；
 - 可判定验收标准。
 
@@ -139,6 +140,8 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 - 依赖缺失或 DAG 有环；
 - 可写路径不明确或并行所有权冲突；
 - 验证方法不能执行且没有批准的替代证据；
+- Ticket 未声明 E2E required/not-required 及理由，或把 E2E 安排到 source worktree；
+- 无法形成实现 commit 与 candidate-merge 父分支出口；
 - 单个新上下文无法完成；
 - Standard/Deep 缺少有序执行路线；
 - Deep 缺少迁移、兼容、监控、回滚或批准点。
@@ -219,4 +222,4 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 ## 下一步
 
-满足任一情况时建议运行 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>`：Ticket 数量达到或超过 10、存在多 Agent 并行、Deep Ticket、迁移、共享契约、多个 Gate 或高风险发布。少量线性 Ready Ticket 可直接进入 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。
+满足任一情况时建议运行 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>`：Ticket 数量达到或超过 10、存在多个 implementation owner 的并行写入协调、Deep Ticket、迁移、共享契约、多个 Gate 或高风险发布。只读 review/research 并行本身不触发 Goal Plan；少量线性 Ready Ticket 可直接进入 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。

package/template/workflows/specdev/T-tickets/ticket-readiness.md

@@ -11,10 +11,12 @@
 - [ ] 高影响未决问题为零。
 - [ ] `blocked_by` 指向存在的 Ticket，DAG 无环。
 - [ ] `expected_changes`、`writable_paths`、`read_only_paths` 和 `shared_paths` 中的项目路径都使用项目相对 Path 标签。
-- [ ] `writable_paths` 非空，或明确为仅文档、调查或无代码变更。
+- [ ] `writable_paths` 非空；纯 review/research 不伪装成 I-implement Ticket。
 - [ ] 每个 shared path 在 `shared_path_owners` 中有唯一 owner。
 - [ ] 正常、失败和回归至少各有一条验证，或有可信的不适用原因。
-- [ ] 仅当用户界面交互受影响时定义 E2E 与当前执行 owner；Ticket 不预设 Lead/Worker，委派 Goal Plan 可以显式改由 Lead 集成。
+- [ ] 明确 `E2E disposition: required | not-required: reason`；required 场景、预期和接缝可执行。
+- [ ] Source-worktree 验证只包含单元、组件、静态、类型、lint/build 等非 E2E 检查；E2E owner 固定为 Lead，运行环境固定为 parent-candidate。
+- [ ] Ticket 完成合同包含独立 worktree、implementation commit、candidate-merge、父分支 result SHA 和 Lead Evidence。
 - [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
 - [ ] 单个全新上下文能够完成；否则已拆分。
 - [ ] 所有内部文件与目录引用使用完整根变量 Path 标签。
@@ -30,7 +32,7 @@
 
 - [ ] 迁移顺序、兼容窗口、监控、回滚或前向恢复、收缩条件和批准点完整。
 - [ ] 安全、隐私、资金或数据完整性风险有缓解与验证。
-- [ ] 跨 Agent 路径所有权和集成 Gate 明确。
+- [ ] 跨 implementation owner 的路径所有权和 parent-candidate 集成 Gate 明确。
 - [ ] expand-contract 的收缩条件可通过扫描、指标、查询或测试证明。
 
 ## Ready 状态

package/template/workflows/specdev/T-tickets/ticket-template.md

@@ -102,7 +102,12 @@ shared_path_owners: []
 
 不适用的关键风险类别必须写“不适用：原因”。
 
-仅当用户界面交互受影响时增加 E2E 行并指定当前执行 owner。若后续 Goal Plan 含委派附录，再由该计划显式转交 Lead；Ticket 不预设 Lead/Worker 角色。
+- **Source-worktree checks：** 单元、组件、静态、类型、lint/build 等适用非 E2E 检查。
+- **E2E disposition：** required / not-required：原因。
+- **E2E owner/environment：** Lead / parent-candidate；required 时写明场景、接缝与预期。
+- **Integration evidence：** source commit、parent before、candidate/result SHA 和父分支包含关系。
+
+E2E 由实际跨边界行为与风险决定，不限于 UI；不得在 Ticket source worktree 运行或声明通过。
 
 ## 9. 发布、迁移与恢复
 
@@ -120,5 +125,7 @@ shared_path_owners: []
 - [ ] `AC-001`：<可判定结果>。
 - [ ] 验证矩阵全部执行并记录到 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`。
 - [ ] 实际项目修改未超出 `writable_paths`，shared path 由指定 owner 修改。
+- [ ] Ticket 来源 worktree 已形成非空实现 commit，candidate 验证通过且父分支 result 包含 source commit。
+- [ ] E2E disposition 已执行；required E2E 在 parent-candidate 由 Lead 完成。
 - [ ] 未发生未批准的范围、契约或发布偏差。
 - [ ] Ticket、Tickets Map 和 Evidence 状态一致。

package/template/workflows/specdev/T-tickets/tickets-map-template.md

@@ -46,10 +46,11 @@ T-01 [READY]
 
 ## 5. 并行与路径所有权
 
-- 最大并发来自 `<Path>{roots.state}/specdev/config.json</Path>`。
-- shared owner 为专用 Ticket 或明确的集成 owner；只有委派 Goal Plan 才使用 Lead 角色。
+- implementation subagent 上限来自 `<Path>{roots.state}/specdev/config.json</Path>`，不得超过三个且不含 Lead。
+- review/research/test-observation agent 不设 SpecDev 数字上限，但保持只读。
+- shared owner 为专用 Ticket；Lead 是 SpecDev 状态与父分支 integration owner。
 - 项目路径契约以 Ticket frontmatter 为准。
-- 并行写代码的 Ticket 使用独立 worktree；只读调查不需要。
+- 每个实现 Ticket 使用独立 worktree，不以是否派遣 Agent 或是否并行为条件；只读调查不进入 I-implement Ticket。
 
 | Ticket A | Ticket B | Writable 交集 | 真实依赖 | 处理 |
 |---|---|---|---|---|
@@ -57,7 +58,7 @@ T-01 [READY]
 
 ## 6. Gate、Wave 与集成点
 
-T-tickets 可以标注候选 Wave 和行为里程碑。需要正式跨 Ticket 编排时，由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 完成 Gate、Wave、owner、发布与恢复，并把结果投影回本 Map。
+T-tickets 可以标注候选 Wave、E2E disposition 和行为里程碑。需要正式跨 Ticket 编排时，由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 完成 Gate、Wave、Lead、动态派单边界、candidate 集成顺序、发布与恢复，并把结果投影回本 Map。
 
 ## 7. 横切契约与风险
 

package/template/workflows/specdev/_state/status.json

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

package/template/workflows/specdev/common/README.md

@@ -44,8 +44,8 @@
 - 包与 change 校验器：`<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>`
 - 校验器说明：`<Path>{roots.workflows}/specdev/common/tools/README.md</Path>`
 - 外部技术研究 Skill：`<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`
-- 隔离 Ticket/原型 worktree Skill：`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`，角色中立；由 change 的隔离事实触发，Agent Team 只影响 owner 映射
-- 委派 Agent 交付合同 Skill：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，仅用户明确选择 lead-team 时调用
+- Ticket/原型 worktree Skill：`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；Ticket 固定使用 source → parent-candidate → parent 状态机，原型保持临时生命周期
+- 动态 Agent 交付合同 Skill：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`；P-goal-plan 建立 Lead 合同，I-implement 在执行期派单与验收
 - 双轴代码审查 Skill：`<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`
 
 ## 加载原则

package/template/workflows/specdev/common/rules/change-completion.md

@@ -1,34 +1,31 @@
 # Change Completion
 
-本规则是 change 从 active/blocked 转为 completed 的唯一合同，并由 Implement、Goal Plan、Triage、Status 与 Archive 共同读取。
+本规则是 change 从 active/blocked 转为 completed 的唯一合同。
 
 ## 完成门
 
-一个 change 只有同时满足以下条件才能设置 `change_status: completed`：
+一个 change 只有同时满足以下条件才能 completed：
 
-1. 所有计划内 Ticket 为 `done`，或有明确批准理由的 `cancelled`；无 Ticket 的 Direct Spec/非实现流程有等价的验收清单。
-2. 每个完成行为有 Evidence，全部 Spec 验收合同和适用 Goal Gate 可定位。
-3. 项目级验证通过；既有或环境失败已分类、接受并记录风险。
-4. 迁移、发布、监控、回滚和不可逆批准已完成或明确不适用。
-5. 没有未批准 deviation、未处置 blocker 或伪装成通过的 `unverified` 声明。
-6. Ticket、Map、Goal Plan、Evidence、源码 checkpoint 和 change 状态一致。
+1. 所有计划内 Ticket 为 done，或因权威事实无需改动而记录为 cancelled；Direct Spec/非实现流程有等价验收。
+2. 每个 done Ticket 有 source commit、passed candidate、父分支 result SHA，且父分支包含 source commit；worktree 生命周期为 `integrated` 或完成来源清理后的 `removed`。
+3. 每个行为有 Lead Evidence，全部 Spec 合同与 Goal Gate 可定位。
+4. source-worktree 非 E2E 检查、parent-candidate 集成/回归和 required E2E 已通过；not-required 有理由。
+5. 迁移、发布、监控、恢复和不可逆批准已完成或明确不适用。
+6. 没有未批准 deviation、blocker、unverified、活动 candidate 或未集成 source checkpoint。
+7. Ticket、Map、Goal Plan、Evidence、change status 与实际 Git 一致。
+
+Evidence-only Done 和 empty commit 不满足完成门。
 
 ## 转换 Owner
 
-- Goal Plan 为 `coordination_mode: lead-team`：Lead 在独立验收并关闭最后一个 Gate 后拥有完成转换。
-- Goal Plan 为 `coordination_mode: single-session`，或无 Goal Plan 的 Ticket/Direct Spec 实现：最后一个计划内 Implement 在最后一项验收通过后拥有完成转换。
-- 旧 Goal Plan 缺少 coordination 字段时，根据完整 `## Delegated Execution Addendum` 是否存在兼容推导，不要求 runtime schema 迁移。
-- 非实现型终点：最后一个拥有最终验收工件的 Work 使用本规则完成转换。
+- 有 Goal Plan：其唯一 Lead 在关闭最后 Gate 后拥有转换；
+- 无 Goal Plan 的 Ticket/Direct Spec：当前 I-implement 主会话 owner 拥有转换；
+- 非实现型终点：最终验收工件 owner 使用本规则。
 
-Owner 原子更新 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 的 `change_status`、`completed_at`、`updated_at` 和 `current_work`，然后重读验证。全局 `<Path>{roots.state}/specdev/status.json</Path>` 继续只保存 active 索引，不复制完成详情。
+Owner 原子更新 `<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 的 `change_status`、`completed_at`、`updated_at` 和 `current_work`，然后重读。全局 status 只维护 active/archived 索引。
 
 ## 远程来源与归档
 
-远程动作不参与本地完成判定。完成后若 `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>` 的 `external_action` 为 `pending-close` 或 `close-failed`，下一路线是 Triage reconcile；`closed`、`waived` 或 `not-applicable` 才允许 Archive 移动 change。归档后工件只读，不在归档目录补写远程结果。
-
-## 完成标准
+远程动作不参与本地完成判定。Triage 为 `pending-close`/`close-failed` 时先 reconcile；`closed`、`waived` 或 `not-applicable` 才允许 Archive。归档后工件只读。
 
-- 完成声明可以从本地工件和实际验证重建；
-- 当前 change 只有一个条件命中的转换 owner；
-- 远程失败不会把 completed 改回 active；
-- Archive 不接收尚未 reconcile 或 waive 的远程来源。
+**完成标准**：完成声明可由本地工件、Git 与验证重建；只有一个 owner 命中；失败 candidate 不污染父分支。

package/template/workflows/specdev/common/rules/deviation-control.md

@@ -40,4 +40,4 @@
 
 - 未批准的 ticket、spec、architecture 或 release 偏差不得继续实现。
 - 不得通过扩大 `writable_paths`、删除测试、降低断言或把风险改写成“已知限制”来绕过停止。
-- 偏差影响普通并行执行时，当前集成 owner 必须暂停受影响 Wave，重新计算路径所有权、依赖和 Gate；委派执行由 Lead 承担同一责任。
+- 偏差影响并行执行、source checkpoint 或 candidate 集成时，Lead 必须暂停受影响 Wave，重新计算路径所有权、依赖、Gate 与父分支顺序；任何 subagent 都不能自行改写上层合同。