@namewta/speculo 0.7.1 → 0.7.3

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,67 +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。
+Lead 根据当前事实决定自行实现或派单。同时活跃的 implementation subagent 不得超过 Goal Plan 与 config 中较小的上限，且绝不超过三个；Lead 不计入。Wave 是可并发性，不是必须填满的目标。只读 review/research/test-observation agent 不写固定数字上限，但不得写项目或 SpecDev 状态，也不得争用同一可变测试环境。
 
 ## 3. Gate
 
-Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条件。每个 Gate 必须写明业务或工程状态、开启条件、关闭证据、阻塞范围、owner/批准人和失败恢复。
-
-常见 Gate 包括共享合同稳定、首条垂直路径通过、迁移完成、旧调用点归零、发布就绪和观察期结束。名称按项目语义自定义。
+Gate 用可验证状态定义，必须写明：工程/业务状态、开启条件、关闭证据、阻塞范围、Lead/批准人和失败恢复。常见 Gate 包括共享合同稳定、首条垂直路径、迁移完成、旧调用点归零、候选合并通过、发布就绪和观察期结束。
 
-## 4. Shared path 与共享合同
+## 4. Shared path 与合同
 
-规则遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
+遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
 
-1. 由专用 owner Ticket 或计划指定的唯一 owner 修改共享路径；
-2. 形成可验证稳定基线；
-3. 下游消费者在新基线上重新运行 preflight；
-4. 才允许扇出或继续后续 Ticket；
-5. 共享契约需要变化时暂停消费者并修订上游，不通过多个执行者同时修改解决。
+1. 专用 owner Ticket 修改共享路径；
+2. 在其 worktree 形成 commit 与非 E2E 证据；
+3. 通过 Lead candidate-merge 进入父分支；
+4. 下游 Ticket 基于新的父分支 checkpoint 创建或刷新 worktree；
+5. 共享合同变化时暂停消费者并修订上游，不让多个执行者竞争写入。
 
-## 5. Expand-contract
+## 5. 每 Ticket worktree
 
-标准顺序：
+每个进入 I-implement 的 Ticket 建立唯一 `specdev-worktree/<ticket-id>`。记录 workspace/implementation/integration owner、`base_sha`、父分支、branch、portable locator、source checkpoint、candidate/result SHA 与验证状态。Lead 自行实现时仍进入该 worktree；subagent 身份不决定是否隔离。
 
-1. **expand**：新旧形式并存，既有调用者继续工作；
-2. **migrate**：按可独立验证的影响范围分批迁移；
-3. **observe**：扫描旧调用点、旧数据或旧协议使用量；
-4. **contract**：收缩条件有证据后删除旧形式；
-5. **verify**：运行兼容、数据、回归、监控和回滚检查。
+同一 Ticket 在 candidate 验证失败后保留来源 worktree并继续修正。新的 source commit 替换当前 `source_checkpoint`，旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
 
-收缩不得仅以“所有迁移 Ticket 已完成”为依据。
+## 6. 父分支集成队列
 
-## 6. Ticket 执行、Evidence 与集成
+Lead 串行集成 Ready 候选：
 
-每个计划 Ticket 必须写明开始条件、依赖 Evidence、项目路径合同、适用 Gate、必跑验证、Evidence 目标和失败恢复。实际执行仍由 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与 Ticket 拥有，不在 Goal Plan 复制局部施工步骤。
+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 集成由独立委派协议拥有，不写入本文件。
+标准顺序为 expand → migrate → observe → contract → verify。每批迁移独立 commit、candidate 验证和父分支集成；收缩依据旧调用/数据/协议归零证据，不依据 Ticket 数量推断。
 
-**完成标准**：每个执行结果可追溯到代码状态和 Evidence；普通 Goal Plan 可以在不建立角色交付合同的情况下完整恢复和完成。
+**完成标准**：每个 Ticket 从父基线、source commit、candidate 到 result 都可恢复；父分支只包含已通过候选门禁的 Ticket。

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

@@ -1,76 +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 或交付通道无法建立；
-- 用户要求的远程或生产动作没有逐动作授权。
+## 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 治理，不决定是否启用 Lead/subagent。每次运行 P 都向用户提供两个选择：
+存在以下任一情况时 `ready_for_execution: false`：
 
-- **普通 Goal Plan**：由实现者按核心计划推进，不创建严格角色、交付通道或派单合同；最终产物不记录一个名为 direct 的模式。
-- **委派 Goal Plan**：启用唯一 Lead 与 `native-subagent` 或 `external-web-subagent`，并加载委派协议。
+- 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`。
 
-不得根据 Ticket 数量、并行机会或平台能力静默启用委派。选择普通分支后，AI 自适应决定核心计划的适用细节，不把本次角色选择写入 frontmatter，也不在正文生成空章节或“不适用”说明。
-
-选择委派后才固定：Lead、provider、repository/branch、不可变 `base_sha` 或等价基线、源码交付方式、`max_correction_rounds` 和逐动作授权。认证秘密和机器绝对路径不得进入 Goal Plan。
-
-## 5. 规划摘要
-
-写入前形成核心摘要：
-
-```text
-modes=<mode-list>
-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>
-```
-
-委派分支额外形成 `execution_model`、`lead`、`provider`、`checkpoint`、`source_delivery`、`max_correction_rounds` 和 locator；这些字段只进入委派附录。
-
-**完成标准**：规划 modes 与角色选择互不代替；普通计划没有委派痕迹；委派计划的源码、交付、权限和恢复字段都有可验证值。
+**完成标准**：所有固定字段、适用模式、授权、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>`，角色中立；委派 Goal Plan 才映射为 Lead/Worker
-- 委派 Agent 交付合同 Skill：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，仅用户选择委派 Goal Plan 时调用
+- 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,33 +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 含完整 `## Delegated Execution Addendum`：Lead 在独立验收并关闭最后一个 Gate 后拥有完成转换。
-- Goal Plan 不含委派附录，或无 Goal Plan 的 Ticket/Direct Spec 实现：最后一个计划内 Implement 在最后一项验收通过后拥有完成转换。
-- 非实现型终点：最后一个拥有最终验收工件的 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 都不能自行改写上层合同。

package/template/workflows/specdev/common/rules/evidence-and-verification.md

@@ -1,57 +1,47 @@
 # 证据与验证规范
 
-验证回答“怎样证明行为已经正确发生”，Evidence 回答“实际运行了什么、结果是什么、仍有什么风险”。
+验证回答“怎样证明”，Evidence 记录“实际运行了什么、在哪个状态运行、结果和残余风险是什么”。
 
 ## 1. 验证矩阵
 
-每一行绑定一个行为、合同或风险：
+每行绑定行为、合同或风险，并标记环境：
 
-| 行为或风险 | 验证接缝 | 方法或命令 | 预期结果 | Evidence |
-|---|---|---|---|---|
-| 正常路径 | 公共接口 | 项目定向测试 | 指定外部行为成立 | `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>` |
-| 无效输入 | schema 或公共接口 | 定向失败测试 | 稳定错误行为成立 | `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>` |
-| 回归 | 现有测试套件 | 项目回归命令 | 相关既有行为保持 | `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>` |
+| 行为或风险 | 接缝 | 命令/方法 | 环境 | 预期 | Evidence |
+|---|---|---|---|---|---|
+| 正常/失败路径 | 公共接口或稳定接缝 | 定向测试 | source-worktree | 合同成立 | Ticket Evidence |
+| 跨模块回归 | 集成接缝 | 回归命令 | parent-candidate | 组合状态成立 | Ticket Evidence |
+| E2E required | 真实端到端边界 | 场景步骤 | parent-candidate | 外部行为成立 | Ticket Evidence |
 
-命令引用项目脚本时，项目文件路径使用项目相对 Path 标签，例如 `<Path>package.json</Path>` 或 `<Path>Makefile</Path>`。
+## 2. 两层验证
 
-## 2. 最小充分验证
+### Source-worktree
 
-选择最接近目标行为的稳定接缝：
+implementation owner 运行最接近目标行为的单元/组件测试、静态分析、类型、lint/build 等适用非 E2E 检查。来源实现必须在 clean worktree 形成 commit。任何 source-worktree E2E pass 声明无效。
 
-1. 公共接口或契约集成测试；
-2. 稳定接缝上的单元测试；
-3. 类型检查、静态分析、lint 和构建；
-4. 可重复手动步骤、截图或查询结果；
-5. 代码阅读推断。
+### Parent-candidate
 
-E2E 仅在变更影响用户界面交互时加入验证矩阵。普通执行由当前实现或集成 owner 运行；委派执行中 Worker 只记录场景、预期结果和待执行状态，由 Lead 在集成阶段运行。API、CLI、后端、库或数据变更默认使用其稳定接缝，不追加 E2E。
+Lead 在最新父分支与 source commit 的 candidate 状态运行受影响集成/回归、项目父状态检查和适用 E2E。E2E 由实际跨边界风险决定，不限于 UI；not-required 必须写理由。required E2E 未运行或失败时不得推进父分支。
 
-低层证据不能替代明确要求的用户行为证据。高风险迁移还需要 dry-run、调用点扫描、数据核对、监控信号或回滚演练。
+### Direct Spec
 
-## 3. 失败分类
+获批 Direct Spec 不创建 Ticket worktree 或 candidate。Lead 在 current workspace 记录实施前基线，运行轻量合同要求的定向检查、适用回归与 E2E，并记录最终 checkpoint、dirty 状态、运行环境、命令、退出状态和未运行原因。E2E 仍只由 Lead 执行；不得为套用两层验证而伪造 Ticket、source/candidate/result 或父分支推进证据。
 
-每个失败必须分类为：
+低层证据不能替代明确要求的外部行为证据。高风险迁移还需要 dry-run、调用点扫描、数据核对、监控或恢复演练。
 
-- 本 Ticket 引入的新失败；
-- 基线已存在的失败；
-- 环境、权限或基础设施失败；
-- 验证本身无效或无法观察目标行为。
+## 3. Agent 声明
 
-不得通过跳过测试、放宽断言、吞错、删除用例或把命令移出验证矩阵来制造绿色。
+subagent 只返回候选命令与结果，不写 Evidence。Lead 重读 workspace/Git、必要时复跑或核对输出后落盘；外部 provider 自报、截图、模拟和推断在此之前标记 `unverified`。review/research/test-observation agent 不拥有 E2E Gate。
 
-## 4. Evidence 最低内容
+## 4. 失败分类与完整性
 
-每个完成 Ticket 在 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>` 记录：
+失败分类为本 Ticket 新失败、基线既有失败、环境/权限/基础设施失败、无效验证或 candidate stale。不得通过跳过、放宽断言、吞错、删除用例或迁移验证位置制造绿色。
 
-- 基线、分支或 worktree；
-- 实际修改的项目路径；
-- 每条命令、退出状态和结果摘要；
-- 每条验收合同的证据映射；
-- 未运行项与原因；
-- 新失败、既有失败和环境失败；
-- 偏差及批准；
-- 残余风险；
-- worktree、提交或 PR 引用；
-- 最终结论。
+受控反向验证只用于可能静默通过的关键门禁：证明检查能在目标风险出现时失败，再恢复并重跑。普通测试不为形式执行破坏性操作。
 
-无法运行关键验证、存在未批准偏差或 Evidence 不完整时，Ticket 不得标为 `done`。
+## 5. Evidence 最低内容
+
+每个 Ticket Evidence 至少包含：Lead、Dispatch/返回（若有）、base/source/candidate/result SHA、来源 worktree、实际路径、每条命令/环境/退出状态、合同映射、双轴审查、E2E disposition、未运行项、失败分类、偏差、残余风险和父分支重读结果。
+
+Ticket Done 必须有 source commit、通过 candidate、父分支 result 与 Lead Evidence。无法运行 required 验证、存在未批准偏差、父分支未包含 source commit 或 Evidence 不完整时不得 Done。
+
+Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施前/最终 checkpoint、实际路径、定向/回归/E2E 命令及环境、验收映射、未运行项、偏差、残余风险和提交授权状态。

package/template/workflows/specdev/common/rules/path-ownership.md

@@ -1,35 +1,33 @@
 # 路径所有权与并发规则
 
-路径所有权是并行执行的硬边界，不是文件预测清单。
+路径所有权是逻辑写入边界；worktree 是物理隔离边界，两者不能互相替代。
 
 ## 1. 四类路径
 
-- `expected_changes`：预计修改的项目路径，仅用于导航；每项写成项目相对 Path 标签。
-- `writable_paths`：实现者获准修改的项目路径或 glob，是硬约束。
-- `read_only_paths`：建立上下文但不得修改的项目路径。
-- `shared_paths`：多个 Ticket 可能需要修改的项目路径，必须指定唯一 owner。
+- `expected_changes`：导航预测；
+- `writable_paths`：当前 Ticket implementation owner 可写的硬边界；
+- `read_only_paths`：只读上下文；
+- `shared_paths`：多个 Ticket 可能触达且必须有唯一 owner 的项目路径。
 
-示例：
-
-```yaml
-expected_changes: ["<Path>src/auth/session.ts</Path>"]
-writable_paths: ["<Path>src/auth/**</Path>"]
-read_only_paths: ["<Path>src/users/**</Path>"]
-shared_paths: ["<Path>package.json</Path>"]
-```
+所有项目路径使用项目相对 Path 标签。根依赖清单、锁文件、根导出、共享 schema、迁移索引、全局路由和跨 Ticket 合同默认视为 shared。
 
 ## 2. 所有权规则
 
-1. 可能并行的 Ticket，其 `writable_paths` 不得相交。
-2. glob 与具体路径按覆盖关系判断，不得只比较字符串。
-3. 根依赖清单、锁文件、根导出、共享 schema、迁移索引、全局路由和跨 Ticket 合同文件默认视为 shared。
-4. shared path 只能由专用 owner Ticket 或 Goal Plan 明确指定的唯一集成 owner 修改；消费者 Ticket 只读。委派 Goal Plan 可以把该 owner 指定为 Lead，但普通计划不预设角色。
-5. 需要越界时先停止，按 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>` 提出 ownership change；不得先改后报。
-6. 前置 Ticket 改变目录结构后，后续 Ticket 开始前重新解析项目路径；若授权范围语义未改变，可只更新导航路径。
-7. 不得把“最后解决合并冲突”当作所有权方案。
+1. 可能并行的 Ticket，其 writable paths 不得相交；glob 按覆盖关系判断。
+2. shared path 只由专用 owner Ticket 修改；消费者 Ticket 只读。Lead 负责集成，不以冲突解决替代 shared owner。
+3. implementation subagent 只写其 Packet 与 Ticket 授权路径；Lead 自行实现也受同一边界约束。
+4. review/research/test-observation agent 只读项目与 SpecDev 工件。
+5. 越界前停止并按 deviation control 提出 ownership change；不得先改后报。
+6. 上游 Ticket 改变目录/合同后，下游基于已集成父分支重新解析路径和 preflight。
+
+## 3. Ticket worktree
+
+每个进入 I-implement 的 Ticket 都使用唯一来源 worktree `specdev-worktree/<ticket-id>`，无论是否并行、是否派遣 subagent。Ticket 切片是隔离依据；Agent Team 不是 worktree 触发器。没有 Ticket 的获批 Direct Spec 可由 current workspace 唯一 owner 执行；只读调查不创建实现 worktree。
+
+workspace/implementation owner 可以是 Lead 或动态 implementation subagent；integration owner 固定为 Lead。只有 Lead 写 SpecDev 状态、建立 parent-candidate、运行适用 E2E 并推进父分支。生命周期由 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 管理。
 
-## 3. Worktree 与分支
+## 4. 并发
 
-需要并行或临时隔离项目写入时使用独立 worktree；只读调查和顺序执行默认共用当前工作区。Worktree 防止工作区污染，路径所有权防止逻辑冲突，两者不能互相替代。
+implementation subagent 同时最多三个，Lead 不计入；实际上限取 Goal Plan、config 和平台能力最小值。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
 
-生命周期由调用方明确的 workspace owner 按 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 管理。普通 Goal Plan 由当前执行或集成 owner 负责；委派 Goal Plan 才把 workspace owner 映射为 Lead。编排规则位于 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`。
+**完成标准**：每个项目写入映射到唯一 Ticket、owner 和来源 worktree；shared 与父分支写入 owner 唯一。

package/template/workflows/specdev/common/rules/readiness-and-depth.md

@@ -16,7 +16,7 @@
 
 ### Deep
 
-任一条件触发：公共 API、schema、wire format、数据迁移、认证授权、隐私、资金、不可逆操作、expand-contract、共享核心路径、多 Agent 复杂协作、多个实质架构方案或高事故半径。
+任一条件触发：公共 API、schema、wire format、数据迁移、认证授权、隐私、资金、不可逆操作、expand-contract、共享核心路径、多个 implementation owner 的跨 Ticket 写入协调、多个实质架构方案或高事故半径。
 
 额外要求：数据流或状态转换、兼容窗口、迁移顺序、可观测性、回滚、风险缓解、收缩条件和人工批准点。