@namewta/speculo 1.0.24 → 2.0.1

package/template/workflows/specdev/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/specdev-p-goal-plan/references/map-control.md</Path>`，调用 I；不直接越过票的 Skill 或验证矩阵。
+3. 每票返回都回读原 Ticket 状态和 Evidence；按原计划的 Execution Policy Source、实际存在的 config 与宿主能力核对上限，保持原 Lead 和 required/current 集成协议。
+4. 一轮中没有可运行票就解释阻塞与恢复条件，写检查点；不要空转或声称仍在后台执行。
+
+## resume
+
+先读取最近检查点、计划 revision、相关 Ticket、HEAD/父分支、Skill 摘要、未闭合动作和 owner。对本任务未闭合动作遵循原协议恢复；他人事务不清理、不续租、不接管。只对缺失或失效证据重做检查，不重复已确认完成的副作用。
+
+## verify
+
+先逐票验收，再做跨 change 集成、数量核对、迁移及回归。所有 required Skill 都须有匹配执行证据。全部票 done 只是必要条件，不充分；父完成继续遵循既有聚合 Evidence 与所有成员完成合同。远程 reconcile、归档、正式知识提升仍分别授权，不能作为 Goal 完成的隐含副作用。
+
+## 兼容
+
+P 保留原业务 ID；Ticket/Map 使用 schema v3 与 plan_contract_version: 1，Goal Plan 使用 v7；整体结论使用 README Outcome。只接受当前合同；无效或旧格式停止受影响分支，保留原始文件与证据，不提供迁移或兼容读取。

package/template/workflows/specdev/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/specdev-p-goal-plan/SKILL.md</Path>` 的 `run` 或 `resume`。先运行 `<Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path>` 的 `--map` 只读检查；实际执行、授权和完成仍走 P/I 原协议。
+
+现有父 change 可以在恢复时由其唯一 Lead 补建此入口，不移动旧工件。仅计划调用不得启动实现。

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

@@ -0,0 +1,44 @@
+> 通用编排方法唯一权威：<Path>{roots.references}/coordination/coordination-contract.md</Path>。本文件仅补充 SpecDev Goal 的既有 DAG、工作区、集成和状态职责。
+
+# Lead 编排与动态派单协议
+
+## 1. 唯一 Lead
+
+Lead 是主会话中的唯一编排 owner，保留需求解释、DAG/Wave/Gate、路径分配、权限、SpecDev 状态、Evidence、候选验收、父分支集成和最终回复责任。恢复时以 Goal Plan 的 `lead` locator 和权威工件继续；更换会话只转移 Lead 身份，不产生第二写入者。
+
+## 2. 派单类型
+
+- **implementation**：写入 Goal Plan 选择的 current workspace 或 Ticket worktree 的授权项目路径，运行非 E2E 检查并返回 implementation/source commit；
+- **review**：只读审查固定 checkpoint，返回 findings；
+- **research**：只读收集代码或外部事实，返回来源与结论；
+- **test-observation**：只读运行或观察已授权检查，返回命令与结果，不拥有 E2E Gate。
+
+Lead 在 Ticket 可以独立执行、写路径不冲突、上下文足够且平台支持时派单。派单是执行期决定，不写回 Goal Plan 作为固定拓扑。
+
+## 3. 并发
+
+required 模式 实现执行者 上限取 Goal Plan、实际存在的 config 与平台能力的最小值；current 模式保持单 writer 串行安全不变量；Lead 参与实现时计入。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免测试资源冲突、重复工作和上下文失控。
+
+## 4. 写入边界
+
+实现执行者 只写分配的 current workspace 或 worktree 中的项目路径和其 Git commit，不写 Ticket、Map、Goal Plan、Evidence、README Outcome 或父分支。current 模式 commit 直接落在 parent branch；required 模式 commit 落在 source branch。其他 任务执行者 全部只读。Lead 接收返回后独立核对，再写本次负责工件的独有事实。
+
+## 5. 动态 Dispatch Packet
+
+每次派单必须绑定 Ticket、Goal Plan、依赖 Evidence、不可变 `base_sha`、branch/workspace locator、workspace strategy、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 结果；不接受 任务执行者 自报的 Evidence 或 E2E pass。required implementation 候选进入 dev-worktree candidate-merge；current implementation 由 Lead 在同一 parent branch/current workspace 做 direct-parent 验证。read-only 结果由 Lead 复核后写入对应权威工件。首次失败可返回同一 workspace/worktree 修正或标记 blocked。
+
+同一 Ticket 在 implementation/review 反复返回相同 blocker、下一轮没有产生新证据，或 integration attempts 达到有效 Plan 的 `integration_attempt_limit` 时，停止把相同请求直接退回原 implementation owner。Lead 保留 workspace、commit/candidate 与失败事实，在现有 Ticket Evidence 中回答四项：共同失败模式、最可能原因、下一轮具体改变、下一 owner/路由。Lead 可改写指导、调整 Ticket 内实现路径、更换 implementation owner 或自行实现；若发现 Ticket、Goal、父 Plan、Spec/ADR 已失效，则返回对应 owner。
+
+只有 Lead 的复盘决定已写入 Evidence，才可将当前 Ticket 的 `attempts` 重置为 `0` 并发出新 Dispatch Packet；新 Packet 必须引用该 Evidence 并明确相较上一轮改变了什么。没有实质变化时不得重新派发同一请求。上限因此是 Lead 复盘触发点，不是 Ticket 的永久失败终态。
+
+**完成标准**：每次写入只有一个 Ticket/owner/worktree；所有 SpecDev 状态由 Lead 落盘；派单、返回与重复失败后的 Lead 决定可从 Evidence 恢复。
+
+## 可解释的再派发
+
+重复 blocker 且没有新证据时保持原停滞停止。新的 Dispatch 明确改变输入、方法、范围、环境或处置的哪一项；仅更换 Agent、重置 attempts、让用户再答相同问题不构成恢复。旧历史保留，按原 owner 和依赖闭包处理。

package/template/workflows/specdev/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。单 change 的未来 draft 票只阻塞自身及依赖闭包；上游 done 后仍需 Lead 按真实产物重审 DoR，不自动提升 Ready。cancelled 不是成功交付：下游必须重规划依赖，不能自动视为 satisfied。
+3. current 策略严格单 writer；required 使用原计划 `Execution Policy Source` 确定的并发与尝试上限，核对实际存在的 config/宿主限制，Lead 实际参与实现时计入。写集、语义资源、integration queue 无冲突才并行。不同文件可能共享 API、数据表、锁文件或公共契约，因此不能只比较文件名。
+4. 按票的调用阶段读取并实际执行必需 Skill；按项目协议调用的“技能”可以是宿主技能调用，也可以是完整执行该 SKILL 的程序步骤，但必须记录对应步骤/工具轨迹与输出，不得仅记录阅读完成。
+5. I 返回后核对实现、Skill 执行记录、验证矩阵、实际交付数量和集成证据。失败保留 blocker；不能用减少测试或替换工具来“修好”状态。
+6. 核验后只更新原 Ticket 的权威状态和本票 Evidence；跨票 Gate 的独有结果留原 Goal。仅当导航、依赖或合同覆盖发生变化时修订 Map，不为票级进度生成持久投影。恢复回读这些原工件与实际 Git，已完成票不重跑副作用；证据持久化失败不推进 done。
+7. 有他人资源/事务冲突只暂停该票与其依赖闭包，继续独立、已授权票。无法可靠分辨共享资源时，暂停相关资源而非抢占。
+8. frontier 空且仍有未完成票时返回精确缺口；全部票完成后执行 Goal 集成验收，按原完成合同关闭。
+
+## 正式记忆
+
+开始任何正式写入前，先检查原网关的 pending transaction、lock、recovery evidence 与 owner。Goal 只请求拥有 namespace 的原工作流执行，不直接写永久记忆，也不创建“更轻量”的旁路网关。
+
+单票 blocked/deviated 不强制将父 Plan 的全局执行门关闭。只有全局合同失败或合法 frontier 为空时暂停父循环。检查点摘要覆盖 Spec、票合同、实际 Skill/参考版本、依赖、相关 serialization 与共享 Goal 门禁；原 Ticket 的普通 owner/status 变化不是合同变更。摘要是漂移检测，不替代授权和实证验收。

package/template/workflows/specdev/specdev-p-goal-plan/references/multi-change-plan.md

@@ -0,0 +1,126 @@
+# 多 change Goal 规划与执行
+
+本参考由统一 P 按模式调用。plan 只完成步骤 1–3、父总控入口和计划审查；步骤 4–5 仅在显式 run/resume 且执行授权有效时进入。verify 不重新执行已完成票。恢复由原 Implementation Map/Plan 和 README 接续点定位。
+
+
+本 Work 只编排实现。它不创建或补写子 change 的 Triage、Grill、Wayfinder、Spec、Ticket 或普通 Goal Plan。父 change 创建前，每个输入 change 都必须已有 Ready Spec、Tickets Map 和决策完备的 Ready Tickets；缺一项就停止并报告具体缺口。
+
+父 change 将所有子 Ticket 投影为 `<member-change>::<ticket-id>` 组合节点，以跨 change implementation super-DAG、全局 workspace 策略、serialization、agent 配额和 integration queue 持续驱动 I-implement。子 Spec/Ticket/Evidence/Git 继续是行为与实现权威，父工件只拥有跨 change 实现编排。
+
+父 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>`。
+
+
+## 激活输入
+
+创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从实际 changes 目录中唯一存在合法父实现产物与 active Outcome 的对象确定。
+
+创建父 change 前必须读取并验证：
+
+- 明确根与实际执行策略来源；已有真实 config 时核对相关上限；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/README.md</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/spec.md</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/tickets-map.md</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/ticket/</Path>`：先枚举所有 Ticket frontmatter、依赖、状态和可写路径，再按 super-DAG、冲突和当前 frontier 回读相关正文；
+- 存在时读取子 Goal Plan、ADR、CONTEXT、LOG、Diagnosis 与 Evidence；
+- 当前 repository、branch、HEAD、dirty 状态、项目 Agent 指令与可用验证命令。
+
+成员的 Spec、Tickets Map、Ticket frontmatter、状态和父级编排证据是 super-DAG 的权威输入，必须完整读取；成员的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和项目 Skills 先按索引、状态和关键词定位，只读取命中的条目。恢复、冲突、漂移和集成失败时按本 Work 的证据合同扩展为全量读取。
+
+加载 `<Path>{roots.workflows}/specdev/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。
+
+## 流程
+
+### 1. 先验证全部子 Change，再创建父 Change
+
+对每个成员穷尽检查 Ready Spec、Tickets Map、Ticket frontmatter、合同覆盖、内部 DAG、路径所有权、验证矩阵和高影响未知项。部分 Ticket 可以已经 done/cancelled；其余待实现 Ticket 必须 `ready: true` 且处于可执行状态。全部 Ticket 已终态且 change 已 completed 的成员只作为已结束基线，不占执行 frontier；下游成功依赖仍须由 done 票的有效产物满足，cancelled 票的相关依赖由原 Lead 按真实依据重规划。
+
+只有所有成员通过输入门后，才创建普通父 README 的 Outcome active 与目标导航，再写父 Map/Plan；身份来自稳定目录名，不注册全局状态。任何预检失败都不得留下半创建父 change。
+
+**完成标准**：父创建是 all-or-nothing；输入成员不少于两个；没有用父 Work 修补任何上游工件。
+
+### 2. 编译 Implementation Super-DAG
+
+加载 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-super-dag.md</Path>` 与 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-conflict-and-drift.md</Path>`。
+
+1. 将每个子 Ticket 映射为唯一组合节点；
+2. 将所有子 Ticket `blocked_by` 精确提升为组合 dependency；
+3. 只为真实合同/产物前置关系增加跨 change dependency；
+4. 为无语义依赖但不能并发的 Ticket 增加无方向 serialization pair；
+5. 比较所有待实现 Ticket 的 writable/shared paths、公共合同、repository/ref 和迁移资源；
+6. 检测循环、缺失节点、重复边、无 owner overlap 和子图漂移。
+
+使用 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>` 写父 Map。Map 是子 Ticket 图的可重算投影；子 Ticket 变化时先重读权威，再递增 Map revision。
+
+**完成标准**：父 Map 的 members/tasks/internal edges 与全部子工件精确一致；跨 change 边有来源；DAG 无环；每个并行冲突已依赖化、串行化或阻塞。
+
+### 3. 一次决定全局执行策略
+
+只询问一次是否开启 Ticket worktree，默认不开启，并把选择写入父 Plan：
+
+- `current/direct-parent`：全部成员的待实现 Ticket 全局严格串行，只允许一个 current workspace implementation writer；
+- `required/candidate-merge`：依赖满足且无 serialization/path/resource 冲突的 Tickets 可跨 change 并行，每个 Ticket 使用自己的 source worktree。
+
+在父 Plan 的 Execution Policy Source 记录实际 implementation agent 与 integration attempt 上限来源；已有 config 的有效上限不可提高，缺 config 使用明确项目/本次约定和宿主能力，默认 current 单写入者。Lead 参与实现时计入实现 agent 数；review/research/test-observation agents 只读且不受该数字限制。同一 repository/ref 的 integration 永远串行。
+
+使用 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>` 写父 Plan。已有子 Goal Plan 只提供子 change 内的额外 Gate/约束；其 workspace 策略与父 Plan 冲突时阻塞，不能覆盖父级全局选择。
+
+Implementation Plan 固定使用 `orchestration: lead-directed`，并显式持久化 `concurrent_implementation_limit`、`integration_attempt_limit`、workspace/integration 策略和唯一 Lead；恢复时不得从会话记忆重建这些值。
+
+**完成标准**：Lead、workspace/integration 策略、全局 agent 上限、frontier、Wave、serialization owner 和 integration queue 可从父 Plan 恢复。
+
+随后用 `<Path>{roots.workflows}/specdev/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/specdev-p-goal-plan/references/multi-execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
+
+1. 重读父 Map/Plan、所有子 Ticket/README/Evidence 和 Git；
+2. 计算依赖满足、lock 可用且配额允许的 ready frontier；
+3. current 模式选择一个 Ticket，required 模式选择一组互不冲突的 Tickets；
+4. 由父 Plan 记录实际 Dispatch 与 owner，按组合 ID 调用 I-implement；
+5. implementation agent 仅写授权 workspace，Lead 验收 commit/diff/验证/Evidence；
+6. 按 repository/ref queue 串行完成 direct-parent 或 candidate integration；
+7. 先写回子 Ticket/Evidence 的负责事实，再更新父 Plan 导航/集成 Gate；
+8. 父 HEAD、Map revision 或子合同变化后使旧 dispatch/candidate stale，并重新 preflight；
+9. 仍有 frontier 时立即进入下一轮，否则完成或持久化 blocker。
+
+I-implement 是实际实现 owner；父 Work 不复制 TDD、代码审查、Evidence 或 worktree 逻辑。用户只在合同冲突、高影响偏差、缺失授权、不可逆动作或无合法 frontier 时被打断。
+
+**完成标准**：单次父激活可以连续完成多个子 Ticket；没有第二个 SpecDev 状态 writer、超限 agent、并发 parent integration 或绕过子 I-implement 完成门。
+
+### 5. 关闭子 Changes 与父 Change
+
+一个成员的全部计划内 Ticket 已 done，或因权威事实无需改动而有依据地 cancelled，且相关依赖已处置、Goal/Evidence/Git 门通过时，父 Lead 按 change completion 关闭该子 change；不等待其他成员才关闭，也不自动归档。单票取消不是依赖交付，也不等于整个 change 被取消；整体取消仍由原 owner 核对真实用户决定与处置证据。
+
+全部成员 completed 后，Lead 运行跨 change aggregate test/typecheck/lint/build 与适用 E2E，核对跨 change 合同、依赖顺序、共享路径、迁移/恢复和最终 Git checkpoint，并使用 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>` 写整体验证。
+
+只有父 Map/Plan completed、全部成员 completed、无 blocker/deviation/active dispatch/candidate/lock 且整体验证通过时，才由原父 Lead 更新 README 的唯一 Outcome completed 并链接 aggregate Evidence。归档、push、PR、remote merge、deploy 和生产迁移保持独立授权。
+
+运行：
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage goal-plan \
+  <Path>{roots.state}/specdev/changes/{change}</Path>
+```
+
+## 完成标准
+
+- 父 change 只接受 Spec/Tickets 已 Ready 的成员；
+- Implementation Map/Plan 可恢复完整组合 DAG、全局策略、frontier 和 integration queue；
+- 子工件保持权威，父投影与子 Ticket 精确一致；
+- current 全局串行，required 只并行无冲突 Ticket，全部实现受父级 agent cap 约束；
+- I-implement 自动回到父循环，全部子 change 和父 change completed；
+- aggregate Evidence 与 validator 通过；
+- 无未经授权的归档、远程 Git、部署或生产副作用。
+
+## 子文件引用
+
+- 输入就绪门：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-input-readiness.md</Path>`
+- Super-DAG：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-super-dag.md</Path>`
+- 执行循环：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-execution-loop.md</Path>`
+- 冲突与漂移：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/multi-conflict-and-drift.md</Path>`
+- Map 模板：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>`
+- Plan 模板：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>`
+- Evidence 模板：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>`
+- 共享规则：`<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`

package/template/workflows/specdev/specdev-p-goal-plan/references/multi-execution-loop.md

@@ -0,0 +1,31 @@
+# Continuous Implementation Loop
+
+## 每轮固定顺序
+
+1. 重读父 status、Map、Plan、成员 status/Tickets 和 repository；
+2. 校验 Map revision、Plan source revision、当前 Lead 身份、授权、active dispatch、workspace 与 integration queue；
+3. 重建 super-DAG 并计算 ready frontier；
+4. 根据 current/required 策略选择本轮节点；
+5. 为每个节点形成不可变 Dispatch Packet，task ID 使用组合身份；
+6. 调用 I-implement 完成设计检查、TDD、commit、双轴审查、验证和 Evidence；
+7. Lead 独立验收返回事实并按 repository/ref 串行集成；
+8. 先写子 Ticket/Evidence 的实际结果，再写 Map 导航与父 Plan 集成/Gate；
+9. 重读实际 Git 和全部受影响工件，运行 validator；
+10. 有 frontier 则继续，无 frontier 则完成或持久化 blocker。
+
+## 唯一写入者
+
+父 Lead 是全部 SpecDev 工件、E2E、integration queue 和父分支推进的唯一 owner。Implementation agent 在 current 模式写唯一当前 workspace，或在 required 模式写绑定 Ticket 的 source worktree；不得写父/子状态、Evidence、其他成员或父分支。
+
+## 自动继续边界
+
+子 Ticket 正常完成、candidate stale 后可机械重建、已批准且产生新证据的局部实现修正和下一 frontier 选择不再次询问用户。同一 Ticket 反复返回相同 blocker、没有新证据或达到 integration attempt 上限时，停止该 Ticket 的自动重复并回到父 Lead 决策点；父 Lead 重读其全部 Evidence，记录共同失败模式、最可能原因、下一轮改变和下一 owner/路由，再决定改写指导、换 owner、自行实现或返回上游契约 owner。只有形成有实质变化的新 Dispatch Packet 后，才可重置该 Ticket attempts 并重新派发。
+
+这个回转不自动终止整个父循环；父 Lead 可以继续其他不受影响的 ready frontier。以下情况才停止并等待用户或上游新决定：
+
+- 高影响合同、范围、架构、数据、安全、迁移或验收需要新决定；
+- implementation commit、integration 或不可逆动作缺少授权；
+- dependency/serialization/path owner 无法由权威事实裁决；
+- 无合法 frontier 但仍有非终态 Ticket。
+
+停止时父 Plan 保存最后 accepted 节点、active/stale dispatch、Git checkpoint、blocker、owner、下一合法动作和恢复重读清单。

package/template/workflows/specdev/specdev-p-goal-plan/references/multi-input-readiness.md

@@ -0,0 +1,25 @@
+# Implementation Input Readiness
+
+## 创建前硬门
+
+对每个用户指定成员穷尽检查：
+
+1. change 位于 active namespace，状态不是 archived，且没有另一个未完成父实现 owner；
+2. Ready Spec 使用当前 schema，`status: ready` 且 `ready_for_tickets: true`；
+3. Tickets Map 使用当前 schema，状态为 ready、in_progress 或 completed；
+4. Ticket 目录非空，Ticket ID/文件名唯一，全部内部 dependency 可解析且无环；
+5. 每个非终态 Ticket 决策完备、`ready: true`、路径/验证/验收完整，状态为 ready；
+6. done Ticket 有 Evidence 与完成 workspace 记录，cancelled Ticket 有权威理由；
+7. Spec 合同全部 covered 或有用户批准的 deferred；
+8. 没有未裁决的行为、接口、数据、兼容、安全、范围、迁移或验收问题；
+9. 当前代码与 Ticket 的入口、路径和验证接缝没有已知漂移。
+
+任一成员失败时，返回按 change 分组的缺口和真正 owning Work，不创建父目录、全局 active entry、Map 或 Plan。父 Work 不调用这些 owning Works。
+
+## 恢复状态
+
+父 change 创建后，Ticket 可以进入 in_progress、review、done、cancelled，或因执行事实进入 blocked/deviated。单票 blocked/deviated 在原 Ticket/Evidence 记录原因与恢复 owner，只阻塞本票及其依赖闭包；父 Plan 可保留有效全局执行门，继续独立且已授权的 frontier。共享全局门失败、计划整体失效或没有合法 frontier 时才暂停父运行；创建前的全员 Ready 门不变。
+
+## 已完成成员
+
+全部 Ticket 已 done/cancelled 且 change 已 completed 的成员可以作为已结束基线，不进入 frontier 或占用实现配额。dependency 仍逐票核验：done 且证据有效才表示成功交付；cancelled 不提供依赖产物，原 Lead 须依据真实交付或获批调整重规划相关边。用户只选择已完成成员且没有待实现 Ticket 时停止，因为不存在实现编排目标。

package/template/workflows/specdev/specdev-p-goal-plan/references/multi-super-dag.md

@@ -0,0 +1,27 @@
+# Implementation Super-DAG
+
+## 组合身份
+
+每个节点使用 `<member-change>::<ticket-id>`。父 Map 的 `tasks` 必须与所有成员 Ticket 一一对应，包括已经 done/cancelled 的节点；不得用标题、文件名或局部 Ticket ID 代替组合身份。
+
+## Dependency
+
+- 子 change 内部 dependency 从 Ticket `blocked_by` 精确提升，不得遗漏或改序；
+- 跨 change dependency 只表达后置 Ticket 实际消费前置 Ticket 的合同、代码、迁移或产物；
+- 格式为 `dependent <- prerequisite`；端点必须存在；自依赖、重复边和循环阻塞 Ready。
+
+## Serialization
+
+serialization 格式为 `task-a <> task-b`，只表示两个无语义依赖的 Ticket 因 writable/shared path、repository/ref、环境、迁移窗口或唯一资源不能同时执行。无方向重复 pair 非法。
+
+依赖与串行不能互相冒充。Map 正文必须记录跨 change 边或 serialization 的事实来源、owner、开始 Gate 和解除证据。
+
+## Frontier 与 Wave
+
+节点只有在所有 prerequisite 为 done 且真实依赖产物与证据有效、子 Ticket Ready、无 blocker/deviation、serialization lock 可用、workspace/授权有效且实现配额可用时进入 frontier。cancelled 是终态但不是成功交付；相关下游保持阻塞，由原 Lead 按真实产物或获批范围调整重规划依赖，不能自动把取消当作 satisfied。取消单票也不改变 README 的整体 Outcome。
+
+current 策略每个 Wave 只能含一个节点。required 策略可以放入多个节点，但任意两节点必须不存在传递依赖、serialization、writable/shared overlap 或同一不可并发资源。
+
+## 漂移
+
+每轮从子 Ticket 重新构建预期 task set 和内部 edges。与父 Map 不一致时停止派单、递增 revision、更新 Map 与 Plan，再重新计算；不能用旧投影覆盖子权威。

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

@@ -0,0 +1,58 @@
+> 通用编排方法唯一权威：<Path>{roots.references}/coordination/coordination-contract.md</Path>。本文件仅补充 SpecDev Goal 的既有 DAG、工作区、集成和状态职责。
+
+# Goal Plan 核心编排协议
+
+本文件定义 DAG、Wave、Gate、路径所有权、Ticket workspace 策略、Evidence 返回和父分支集成队列。
+
+## 1. DAG 与关键路径
+
+- 依赖权威来自 Ticket frontmatter 的 `blocked_by`；Tickets Map 是投影；
+- 计算根节点、扇出、汇合点、关键路径、共享合同 owner 和最终收缩点；
+- 依赖只表示真实开始条件，不表达偏好、Agent 交接或“最好先做”；
+- 无法独立保持可验证状态的迁移批次必须有明确 Gate 和恢复策略。
+
+## 2. Wave 与实现并发
+
+required 模式的 Wave 内 Ticket 必须 Ready、依赖 Evidence 完整、项目写路径不相交、shared owner 已稳定、适用 Gate 已打开且基线一致。current 模式即使 DAG 存在可并行节点，也强制一次只执行一个 Ticket。
+
+Lead 根据当前事实决定自行实现或派单。required 模式同时活跃的 实现执行者 不得超过 Goal Plan、实际存在的 config 与平台能力的共同上限；current 模式保持单 writer 串行安全不变量。Lead 参与实现时计入。Wave 是可并发性，不是必须填满的目标。只读 review/research/test-observation agent 不写固定数字上限，但不得写项目或 SpecDev 状态，也不得争用同一可变测试环境。
+
+## 3. Gate
+
+Gate 用可验证状态定义，必须写明：工程/业务状态、开启条件、关闭证据、阻塞范围、Lead/批准人和失败恢复。常见 Gate 包括共享合同稳定、首条垂直路径、迁移完成、旧调用点归零、候选合并通过、发布就绪和观察期结束。
+
+## 4. Shared path 与合同
+
+遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
+
+1. 专用 owner Ticket 修改共享路径；
+2. required 模式在其 source worktree 形成 commit 与非 E2E 证据；current 模式在当前 workspace 形成 commit 与证据；
+3. required 模式通过 Lead candidate-merge 进入父分支；current 模式由 Lead 在父分支 direct-parent 验证并推进；
+4. required 模式下游 Ticket 基于新的父分支 checkpoint 创建或刷新 worktree；current 模式仅在前一 Ticket 完成后开始下一个；
+5. 共享合同变化时暂停消费者并修订上游，不让多个执行者竞争写入。
+
+## 5. 每 Ticket workspace 记录
+
+每个进入 I-implement 的 Ticket 建立唯一记录。current 模式使用 `workspace_ref=current`、`branch=parent_branch`，记录 implementation/source/result SHA 与 direct-parent 验证；required 模式使用唯一 `specdev-worktree/<ticket-id>`，记录 source/candidate/result SHA 与验证状态。Lead 自行实现或派 任务执行者 不改变所选策略。
+
+required 模式同一 Ticket 在 candidate 验证失败后保留来源 worktree 并继续修正。新的 source commit 替换当前 `source_checkpoint`，旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
+
+## 6. 父分支集成队列
+
+required 模式 Lead 串行集成 Ready 候选：
+
+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`。current 模式跳过候选 checkout，Lead 在 current workspace 核对 implementation commit、运行集成检查并记录 `method=direct-parent`；失败时父 HEAD 不推进。
+
+## 7. Expand-contract
+
+标准顺序为 expand → migrate → observe → contract → verify。每批迁移独立 commit、按所选策略验证和父分支集成；收缩依据旧调用/数据/协议归零证据，不依据 Ticket 数量推断。
+
+**完成标准**：每个 Ticket 从父基线、implementation/source commit、对应 integration 到 result 都可恢复；父分支只包含已通过所选门禁的 Ticket。

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

@@ -0,0 +1,78 @@
+# Goal Plan 规划模式与输入门禁
+
+规划模式描述 Goal Plan 需要额外解决的工程问题。Goal Plan 创建时单独询问 Ticket 是否开启 worktree，默认使用当前 workspace；worktree 与 direct-parent/candidate-merge 由该次 Goal Plan 固定。
+
+本文件定义单 change 的规划与全局执行门。多 change 父编排创建仍要求成员全员 Ready，遵守 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。
+
+## 1. 输入门禁
+
+开始规划前穷尽检查：
+
+- Spec `ready_for_tickets: true`，或上游工件已等价覆盖范围、合同与验收；
+- Tickets Map 与全部计划内 Ticket 存在，范围、合同覆盖、DAG 和所有权完整，DAG 无环；Map Ready 表示结构就绪，不要求所有未来 Ticket 同时 Ready；
+- 等待真实上游产物的未来 Ticket 保持 `status: draft`、`ready: false`，在未决问题中记录缺口、生产者 Ticket、所需证据和 DoR 重审条件；不编造版本、路径或验证入口；
+- 每个验收合同被 Ticket 覆盖；
+- writable/shared path 有唯一 owner，Wave 候选无写冲突；
+- 原计划的 `Execution Policy Source` 指向项目/本次约定，确定正整数并发与集成尝试上限；实际存在 config 时验证 schema v7 及对应限制，不为规划补建配置；UI 设计候选只在相关分支读取实际 planning 配置；
+- 父分支可定位，implementation commit 与本地 integration 的授权状态已记录；`plan` 可以列出待批准项并保持 `ready_for_execution: false`；
+- 待执行 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；
+- 当前源码基线、父分支、工作区状态和现有用户改动已经实测；
+- 外部合同、标准、参考实现或依赖版本已经固定，不使用浮动的“最新”描述。
+
+影响整体范围、DAG、合同覆盖或所有权的上游事实缺失时返回其 owner。已定位到未来 Ticket 的局部缺口只阻塞该票及其依赖闭包，不阻塞独立 Ready 生产者。非 v7 Goal Plan 必须按当前合同重新规划，不能只修改版本号。
+
+## 2. 可组合模式
+
+- `migration`：存在 expand-contract、数据/协议迁移、兼容窗口或收缩条件；
+- `high-assurance`：涉及安全、隐私、资金、数据完整性、法规、关键基础设施、不可逆操作或高事故半径；
+- `reference-conformance`：必须逐项符合外部标准、协议、设计或参考实现；
+- `release-coordination`：存在发布窗口、跨团队依赖、外部批准、阶段部署、观察期、运营交接或远程 reconcile。
+
+没有适用模式时 `modes: []`。模式只增加对应 Gate、证据和恢复，不改变 Lead、worktree 或集成基本合同。
+
+## 3. Goal Plan 工作区选择
+
+- 创建 Goal Plan 时询问“是否开启 worktree 开发？”，默认 `否`；
+- 用户选择 `否` 时写入 `ticket_workspace_policy: current` 与 `integration_gate: direct-parent`；
+- 用户选择 `是` 时写入 `ticket_workspace_policy: required` 与 `integration_gate: candidate-merge`；
+- 该选择只作用于当前 Goal Plan，不读取或修改全局配置；
+- `current` 模式下所有 Ticket 必须串行，并持有唯一 implementation writer 锁；
+- `required` 模式继续使用每 Ticket source worktree 和 Lead-owned candidate integration；
+- `orchestration` 固定为 `lead-directed`；实现与集成尝试上限来自 `Execution Policy Source`，实际存在 config 时不得超过其限制。未选 worktree 时缺省 current/direct-parent、单 writer；Lead 实际参与实现也计入实现上限。
+
+## 4. Ready 停止条件
+
+Goal 全局执行门与 Ticket DoR 分开判断。以下任一全局条件未满足时 `ready_for_execution: false`；局部 Ticket 的缺口、资源冲突或未通过 DoR 由逐票检查阻塞对应依赖闭包，不升级成全员停止：
+
+- Goal Plan 工作区选择未记录；
+- `current` 模式下 Ticket 无法串行排序或当前 workspace 不是唯一项目写入 owner；
+- `required` 模式下 Ticket 无法建立独立 worktree 或父分支不明确；
+- 当前模式所需的 implementation commit 或 direct-parent/candidate integration 授权缺失；
+- shared path 没有唯一 owner；
+- E2E 是否需要会改变验收结论但尚未确定；
+- 整体目标的验证命令不能执行或无法观察目标行为，且没有批准的替代证据；
+- 当前源码/工作区基线未实测，或外部合同版本仍然浮动；
+- 影响整体目标的 Ticket 与 Spec、ADR、`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>` 或代码事实冲突未处理；
+- 整体迁移、发布、不可逆动作或恢复存在高影响未知项；
+- 实现或 integration attempt 上限无真实来源，或超过实际存在的 config 或平台能力。
+
+全局门通过后仍只调度自身 Ready、依赖成功完成、owner 明确且资源/并发条件满足的 Ticket。上游 done 不自动修改消费者 Ready；Lead 回读真实产物，按 `<Path>{roots.workflows}/specdev/specdev-t-tickets/references/ticket-readiness.md</Path>` 重审后才能更新该票。frontier 为空且仍有未完成票时报告精确缺口与重审条件。
+
+## 5. 固定执行拓扑
+
+- `orchestration: lead-directed`；
+- `ticket_workspace_policy: current | required`；
+- `integration_gate: direct-parent | candidate-merge`；
+- `current` 与 `direct-parent` 必须成对；`required` 与 `candidate-merge` 必须成对；
+- `concurrent_implementation_limit` 与 `integration_attempt_limit` 由 `Execution Policy Source` 说明，实际存在 config 时不超过其限制，实际实现并发不超过宿主能力；current 模式保持单 writer 串行安全不变量；
+- Lead 参与实现时计入 实现执行者 数量；
+- review/research/test-observation agent 无 SpecDev 固定数字上限，但必须保持只读且不竞争同一可变环境；
+- provider 与派单在执行期决定，不成为 Goal Plan 的静态枚举。
+
+**完成标准**：所有固定字段、适用模式、授权、Lead、父分支和阻塞均可验证；没有替代编排模型或空占位。
+
+## 按风险选择 Gate
+
+兼容、迁移、恢复、性能和用户/模型可见行为仅按真实影响设置 Gate。Gate 说明不可替代的证据、执行环境与失效条件；不要要求所有未来票同时 Ready，也不让局部字段通过替代全局执行授权。

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

@@ -0,0 +1,15 @@
+# 重规划与恢复
+
+## 失效范围
+
+导致公共行为、接口、数据、安全、范围、验收或输出数量改变的事实，回到相应上游 owner 决定。记录旧摘要、新摘要、原因、用户决定和受影响票。沿真实依赖边计算失效闭包；同一 change 的 Spec 改变会使相关票重新核对，不能从旧 map 覆盖子合同。独立 change 未受影响的票继续。
+
+父计划沿用 `revision` 与 `source_map_revision`；单 change 新版 map 用 `plan_revision`。先保留旧证据，再生成新活动投影；不能回写旧记录伪装为原先就已批准。
+
+## 格式门
+
+活动工件必须满足当前 schema、Plan 调用合同和 Ready 门。发现旧版本或未知字段时停止受影响分支，保留原件与证据；不补写旧票、不自动迁移，也不重写已完成历史。
+
+## 恢复动作
+
+读取而非重建检查点；确认 HEAD、source commit、parent result、Evidence 和 owner。已提交未集成、已执行迁移未验证、已开始正式记忆事务等状态只通过原流程恢复。未知归属或缺少恢复证据时不自动撤销、不解锁、不重试不可逆动作；报告人工恢复要求。