@namewta/speculo 1.0.22 → 2.0.1

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。已提交未集成、已执行迁移未验证、已开始正式记忆事务等状态只通过原流程恢复。未知归属或缺少恢复证据时不自动撤销、不解锁、不重试不可逆动作；报告人工恢复要求。

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

@@ -0,0 +1,157 @@
+# 目标规划
+
+
+Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
+
+每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时，用户尚未明确才询问是否开启 worktree 开发，默认不开启；选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 实现执行者，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
+
+产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
+
+
+## 简单无票 Goal
+
+用户要求 Goal，但范围只含一个非 Deep、无真实并行/复杂设计依赖的轻量 change 时，使用 <Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/lightweight-goal-plan-template.md</Path>：frontmatter 为 `artifact: lightweight-goal-plan`、`change`、`lead`，正文 `## Tasks`、`## Integration and Verification`、`## Next Steps`。README 保留 scope/acceptance/verification 的规格/验收，任务进度唯一在 Goal 清单。此分支不创建 Ticket/Map/Implementation，也不调用 analyzeMap；完整 Goal 不能因字段缺失自动降级。实际工作和完成仍走原 I/完成门。
+
+下面的 Ticket 输入与完整 schema 只适用于有票的完整模式。
+
+## 何时运行
+
+满足任一条件时运行：
+
+- 多个 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。
+- 实际执行策略来源；存在真实 config 时只读相关限制
+
+按存在情况读取：
+
+- 当前 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/specdev-s-spec/SKILL.md</Path>` 或 `<Path>{roots.workflows}/specdev/specdev-t-tickets/SKILL.md</Path>`；当前 ADR/CONTEXT 缺失且规划依赖对应决定时返回 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>`，不在 Goal Plan 中补造上游权威。
+
+## 流程
+
+### 1. 验证上游与执行边界
+
+加载 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/planning-modes.md</Path>`：
+
+1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和待执行 Deep Ticket 完整性；未来 draft 票按规划输入门记录局部缺口；
+2. 只读探索影响调度的代码与项目事实；
+3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
+4. 从项目/本次约定读取实际并发与尝试上限，在 `Execution Policy Source` 记录来源并填写既有 `concurrent_implementation_limit` 与 `integration_attempt_limit`；存在 config 时不得超过其有效上限或平台能力，Lead 参与实现时计入；
+5. 根据 workspace 策略记录实现 commit 与 direct-parent/candidate integration 授权事实；缺失时仍可完成 plan 文档，但 ready_for_execution 保持 false，并列为 run 的阻塞条件；
+6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
+
+**完成标准**：计划内 Ticket、范围、覆盖、DAG 与所有权完整；未来 draft 票已记录真实缺口、生产者证据和 DoR 重审条件；Lead、授权状态、实现并发上限和父分支可判定。缺执行授权时可交付规划，但 `ready_for_execution` 保持 `false`。
+
+### 2. 构建 Outcome、DAG、Wave 与 Gate
+
+加载 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/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/specdev-p-goal-plan/references/lead-orchestration.md</Path>`，并按规划阶段读取 `<Path>{roots.references}/coordination/task-brief.md</Path>`：
+
+1. 固定 Lead 的可恢复 owner/session locator；
+2. 按 `Execution Policy Source` 声明实现与集成尝试上限，核对实际存在的 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 可以在恢复后重建派单边界；任何 任务执行者 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
+
+### 4. 定义完成、证据与恢复
+
+加载 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/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/specdev-p-goal-plan/assets/goal-plan-template.md</Path>` 写入 Goal Plan：
+
+1. 只保留适用 planning modes，不创建条件性 topology addendum；
+2. Tickets Map 只增加原 Goal 的 Wave/Gate 导航，执行 owner 与进度仍从 Ticket/Evidence 回读；
+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 的 Gate/执行事实与 Map 导航，README 只保留目标/接续并重新读取；
+6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
+7. 未经用户要求，不自动进入实现。
+
+## 决策完备标准
+
+每份 Goal Plan 必须让 Lead 无需重新决定：
+
+- Outcome、权威来源和整体完成；
+- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
+- shared path 与共享合同 owner；
+- 实现执行者 上限及动态派单边界；
+- 每 Ticket workspace、implementation commit、对应验证和父分支推进规则；
+- E2E disposition、偏差、暂停、批准和恢复路径。
+
+Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
+
+## 完成标准
+
+- Goal Plan schema v7 且 `ready_for_execution` 与状态一致；
+- 规划完成与执行就绪分别报告；允许交付 `draft / ready_for_execution: false`，单 change 不创建父 Implementation Map/Plan；
+- 等待上游产物的未来票保持 draft，局部缺口只阻塞依赖闭包；进入执行的票必须重新通过 DoR，上游完成不自动提升 Ready；
+- Lead 唯一，Execution Policy Source 可回读，实际存在的 config/平台限制已核对，Lead 实际参与实现时计入；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/specdev-p-goal-plan/references/planning-modes.md</Path>`
+- DAG、Wave、Gate 与集成队列：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/orchestration-protocol.md</Path>`
+- Lead 与动态派单：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/lead-orchestration.md</Path>`
+- 完成、证据与恢复：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/references/completion-control.md</Path>`
+- Goal Plan 模板：`<Path>{roots.workflows}/specdev/specdev-p-goal-plan/assets/goal-plan-template.md</Path>`
+- Agent 交付合同：`<Path>{roots.references}/coordination/task-brief.md</Path>`

package/template/workflows/specdev/specdev-p-prototype/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: specdev-p-prototype
+description: "按需验证离线逻辑模型，或继承项目设计基线、按任务自动组合模板生成 HTML，经集中确认后形成 change DESIGN 并通过归档网关沉淀永久设计。"
+metadata:
+  speculo-kind: work-skill
+  speculo-id: specdev/prototype
+  speculo-domain: specdev
+  speculo-contract-version: "2"
+---
+
+# 逻辑与 UI 原型
+
+> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/common/rules/domain-runtime.md</Path>`，再执行本入口。
+
+本 Work 的主导词是**设计定向**：先定位项目设计与代码事实，再按用户任务组合设计模板，生成可操作 HTML 后集中确认，形成当前 change 的 DESIGN 合同。P 不修改生产 UI；S、Tickets、I 与审查必须读取已批准设计。
+
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
+
+## 分支选择
+
+逻辑/状态/规则验证读取 <Path>{roots.workflows}/specdev/specdev-p-prototype/references/logic-protocol.md</Path>，跳过下方 UI 专属步骤。UI 默认离线持久化，候选缺省 3 个、配置上限 4 个；用户显式数量覆盖缺省与上限并记录来源。只有用户明确要求项目内预览时读取 <Path>{roots.workflows}/specdev/specdev-p-prototype/references/project-preview-protocol.md</Path>；其临时写集与清理由该分支管理。
+
+UI 分支必读 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path>，用于区分永久基线、change DESIGN、原型源码、批准及其失效条件。
+
+## 交互和逻辑状态
+
+按项目风险验证正常、空、加载、失败、取消、重试、权限不足和恢复状态。复用既有 token/组件；主题、窗口边缘、响应式、键盘、focus、遮挡与可访问性均由真实项目需求决定，不搬 DSH 视觉常量。失败反馈遵守 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path>，提示与有效数据有明确生命周期。原型只证明原型路径，不冒充生产或真实 API 验收。
+
+## 输入与所有权
+
+- 必需输入：目标项目或新产品设想、核心用户任务，以及当前 SpecDev change。
+- 可选输入：现有代码、页面、截图、设计 token、品牌约束、ADR、Spec、调查和用户明确给出的参考产品。
+- 项目事实权威：依赖清单、样式源码、组件实现、路由、真实页面、测试和可复现截图；仅凭依赖名称不得断言实际风格。
+- 用户决定权威：明确的产品/设计约束、最终 HTML 和交互、设计合同及永久知识发布范围。可由代码或所选模板推导的视觉细节先作有依据的组合，不逐项询问。
+
+P 拥有 `<Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/</Path>`，`design-id` 使用当前 change 内最小未占用的 `UI-NNN`。保留文件名 design-system.md，但它只拥有源码与证据；设计规则唯一保存在 change DESIGN。永久 <Path>{roots.state}/specdev/design/DESIGN.md</Path> 只可经 <Path>{roots.workflows}/specdev/specdev-a-archive-and-consolidate/references/design-knowledge-gateway.md</Path> 由 A 发布，嵌入调用保持 P 原 owner。P 不直接写任何永久知识，不创建 branch/worktree，不提交生产代码。
+
+## 流程
+
+1. **创建或恢复设计包**：读取 change，定位项目基线的相关规则，再读取 `<Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path>` 和当前包。使用 <Path>{roots.workflows}/specdev/specdev-p-prototype/assets/change-design-template.md</Path> 与 <Path>{roots.workflows}/specdev/specdev-p-prototype/assets/design-system-template.md</Path> 创建缺失草案；没有项目基线时另用 <Path>{roots.workflows}/specdev/specdev-p-prototype/assets/project-design-template.md</Path> 在当前包中准备候选，不写永久目录。恢复先核对批准摘要和 owner。
+2. **检测现有风格**：加载 `<Path>{roots.workflows}/specdev/specdev-p-prototype/references/detect-existing-style.md</Path>`，穷尽技术栈、布局、视觉 token、组件状态、响应式与可访问性证据。新项目明确记录 `project_kind: new`，不伪造检测结果。
+3. **组合设计模板**：读取 `<Path>{roots.workflows}/specdev/specdev-p-prototype/design-library/INDEX.md</Path>` 和 `<Path>{roots.workflows}/specdev/specdev-p-prototype/references/style-selection-protocol.md</Path>`，按任务、平台、密度和已有基线选择主模板及有明确职责的辅模板。用户已指定或允许组合时直接采用；未指定时推荐组合并记录理由，不阻塞于逐层选择。实际候选数尊重用户要求。
+4. **先生成 HTML**：加载 `<Path>{roots.workflows}/specdev/specdev-p-prototype/references/generate-design-package.md</Path>`。以相同任务和内容生成候选 HTML、comparison 及推荐 final；将最终 HTML/CSS/JS 具名源码块物化。设计规则写入 change DESIGN 草案，源码包只链接规则。完成真实浏览器检查并通过设计包 --check-preview 后才提出集中确认。
+5. **集中确认与首次基线**：展示同一批准包中的项目基线候选/当前版本、本 change 设计差异、HTML 及交互证据。用户可直接接受、选择其他候选或组合修改；修改后重新验证受影响内容。一次初始确认同时明确 HTML、change DESIGN 与首次永久基线发布范围；已有基线不在此流程自动提升 delta。批准前预绑定候选基线的确定 revision/digest；A 网关发布成功后回读并确认与批准包一致，再登记同一批准记录；缺少批准保持草案或 blocked。
+6. **验证并封板**：运行 `<Path>{roots.workflows}/specdev/specdev-p-prototype/scripts/materialize-prototype.mjs</Path> --check` 与 `<Path>{roots.workflows}/specdev/specdev-p-prototype/scripts/validate-design-package.mjs</Path> --check-ready`。对照 `<Path>{roots.workflows}/specdev/specdev-p-prototype/assets/design-package.schema.json</Path>`，设计绑定、批准、浏览器证据与源码全门通过后才设置 ready；再运行 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --stage prototype --prototype-id UI-NNN` 并回读，成功后将有效包与下一步导航写回原 README。失败恢复 blocked 并保留当前包与恢复位置。
+7. **返回路由**：返回设计包、comparison 和 final 的完整路径、验证命令与结果、未决问题和下一 Work。需要补足产品决定时返回 G；需要写外部行为合同返回 S；需要拆实施工作返回 Tickets；已有 Ready Ticket 才返回 I。Wayfinder 调用时只把设计包与 comparison locator 写入对应 solution comment。
+
+## 完成标准
+
+- 现有项目的检测结论逐项有项目相对证据；新项目明确没有既有风格。
+- 候选由功能、平台和密度推导，数量满足用户要求或有依据的配置；用户已看到候选和最终可操作 HTML。
+- 项目基线、change DESIGN 与源码包职责分离，批准绑定真实内容；首次基线只经 A 网关发布，后续 delta 等归档评估。
+- comparison 导航覆盖实际候选，final HTML 可离线运行；真实桌面与窄屏观察没有未解决的空白、遮挡或无意横向溢出。
+- 字体、间距、圆角、色彩、层级、控件状态、异步反馈、响应式、键盘、focus 和 reduced motion 均有明确合同。
+- Markdown 代码块与 `final/` 文件逐字一致；S/T/I/C/W 有明确 DESIGN/版本/规则/原型引用；schema、局部校验和指定原型 stage 全部通过。
+- 设计包不包含机器绝对路径、敏感值、生产数据写入、发布动作或未授权的生产实现。

package/template/workflows/specdev/specdev-p-prototype/assets/change-design-template.md

@@ -0,0 +1,68 @@
+---
+schema_version: 1
+artifact: change-design
+change: <YYYY-MM-DD-topic>
+revision: 1
+status: draft
+scope: [<app-or-surface-scope>]
+baseline: null
+prototype_ref:
+  id: UI-001
+  digest: <computed-prototype-sha256>
+selection:
+  candidate_id: candidate-a
+tokens:
+  <semantic-token>: <resolved-value>
+pages:
+  - id: PAGE-001
+    route: <project-relative-route-or-screen>
+    task: <primary-user-task>
+    states: [default, loading, empty, error]
+    acceptance: [<observable-acceptance>]
+overrides: []
+confirmation: null
+updated_at: <ISO-8601>
+---
+
+# Change Design: <功能名称>
+
+本文件是当前 change 的视觉与交互合同，由 P 拥有。使用 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 与 <Path>{roots.workflows}/specdev/common/schemas/change-design.schema.json</Path>。替换占位符并计算摘要；draft 不等于批准，模板也不产生授权。
+
+## Scope and Baseline
+
+- **用户、任务与成功条件：**
+- **页面模式：** 操作 / 阅读 / 转化 / 体验；按 surface 决定。
+- **基线：** 永久设计的 revision/digest 与实际使用的 rule IDs。
+- **明确保持项、排除项和用户约束：**
+- **产品/架构来源：** 当前 CONTEXT、ADR、Spec 的适用 locator。
+
+无基线时先形成 baseline-draft，并在首次集中确认包中明确其内容。确认前用待发布候选的确定 revision/designDigest 填入 `baseline: {revision, digest}` 并在原型包中记录 pending publication；不得猜测版本。A 发布后核验同一 snapshot，再登记已取得的确认并设 approved；发布失败保持 draft/blocked。
+
+## Selected Direction
+
+主模板及辅助维度、任务适配理由、首屏结构、主要路径、内容层级和关键交互。候选来源引用原型包的结构化清单，不复制上游全文。
+
+## Tokens and Components
+
+frontmatter tokens 是本次解析后的精确值，正文说明用途。列出继承的共享组件、允许新增的变体和复用边界；CSS 是可运行投影，不能另建相互冲突规则。
+
+## Pages and Interaction
+
+逐页说明入口、主要操作、完整状态、反馈、取消/重试/撤销、权限与离开/返回行为，关联 PAGE/AC ID。页面清单与 frontmatter 保持一致，写明不适用状态原因。
+
+## Responsive and Accessibility
+
+桌面/窄屏布局、必要断点、密度变化、键盘/focus、语义、对比度、缩放、长中文/本地化、触屏与 reduced motion。每条重要要求给出实际验证方式。
+
+## Baseline Overrides
+
+frontmatter overrides 记录 `rule_id`、`reason`、`scope`；正文解释替代影响和当前 change 边界。无偏离写 none。更改外部行为返回 Spec owner，架构冲突返回 ADR owner，不能用 DESIGN 擅自裁决。
+
+## Confirmation and Handoff
+
+展示 HTML 和交互后记录真实用户确认：`confirmation: {by: user, at, record, record_digest, digest}`。digest 使用 design-artifacts 的 designDigest，排除 confirmation/status/updated_at；prototype_ref.digest 使用当前候选组成与运行文件摘要。record 为当前 change 内固定确认快照的相对 locator；record_digest 为其完整字节 SHA-256，快照正文必须包含当前 designDigest、prototype_ref.digest 和 baseline.digest，并记录真实用户决定及范围。LOG 只追加快照定位，不能把后续持续追加的文件当作固定确认快照。变更内容或基线使原确认失效，重新验证受影响范围。
+
+- **原型源码与检测证据：** <Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/design-system.md</Path>
+- **实际浏览器证据：** <Path>{roots.state}/specdev/changes/{change}/prototypes/{design-id}/evidence/browser.json</Path>
+- **Spec AC / Ticket / implementation evidence 绑定：**
+- **归档候选：** 可跨 change 复用的规则与实际采用证据；未验证或一次性内容不提升。