@namewta/speculo 1.0.24 → 2.0.1

package/template/workflows/specdev/I-implement/references/documentation-procedure.md

@@ -1,21 +0,0 @@
-# 文档维护执行分支
-
-仅在已授权的 Ready documentation Ticket 或满足原条件的 Direct Spec 中使用；当前 Work 仍为 `specdev/implement`，权限、workspace、commit 和验收仍走 I。文档建议或审查请求不授权写入。入口预检和两轴审查不因选择本分支消失。
-
-## 定位事实与修改范围
-
-读取 <Path>{roots.workflows}/specdev/common/rules/documentation-standard.md</Path>，先定位项目的真实源码、当前接口说明、相关 README、生成器和适用写作规范。区分只改说明、修正示例以及改变 prompt/tool/CLI/UI 可见行为。按 Ticket 的获批写集维护项目文档；Evidence 留在原 change 的本票文件或 Direct Spec Evidence，不创建第二份文档状态。
-
-列出每条行为声明的 owner 与验证方法：源码、类型、实际命令、运行场景或人工核对。先修 owner，再同步相应派生物与项目要求的语言侧；禁止手改生成文件。保存行为、条件、否定、例外、失败与所有权，消除仅本会话可理解的叙述。
-
-## 验证与交付
-
-纯说明修改使用相关链接、类型片段、示例、生成一致性和语义核对，不伪造代码 red/green。写入命令实际运行后才记录对应成功结果；缺网络、平台、凭据或权限时保留未验证和责任人，不替换成 mock 后写“真实入口通过”。
-
-可见行为改变时，补充实际输出或目标项目的行为快照/场景证据，并在需要时读取 <Path>{roots.workflows}/specdev/common/rules/agent-experience.md</Path>。默认值、错误、兼容或数据格式变化与代码同改；外部破坏的升级说明在当前改动产生，写清旧新行为、受影响者、迁移验证与真实回退限制。
-
-在原 Evidence 记录 `Engineering Evidence`，kind 为 `documentation`；字段与校验见 <Path>{roots.workflows}/specdev/common/rules/engineering-evidence.md</Path>。每项声明为 verified 或 unverified；总体 partial/blocked 不等于 Ticket done。新分支使用 `--engineering documentation` 校验对应原工件，再完成 I 的适用项目验证、两轴审查、状态回读和交付。
-
-## 失败与恢复
-
-以原 Ticket/Spec、文档 owner、源摘要和已运行证据恢复；输入漂移使相应验证失效，不覆盖旧证据。上层行为合同冲突返回原 owner。required 验证未运行时不能以“只改文档”越过 Gate；不适用须说明原因。结果明确区分修改了什么、实际运行了什么、只核对了什么和仍待验证什么。

package/template/workflows/specdev/I-implement/references/implementation-procedure.md

@@ -1,164 +0,0 @@
-# 实现
-
-
-本 work 保留模块设计检查、design-it-twice、TDD 红绿循环、双轴审查和证据治理。Ticket 模式按子 Goal Plan 或父 Implementation Plan 的 `ticket_workspace_policy` 选择 current workspace 串行直接父分支或独立 worktree candidate-merge；Lead 根据实际情况自行实现或动态派单。
-
-若当前 change 是未完成父 Implementation Map 的成员，必须读取 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`、父 Map 与父 Plan。父 Plan 提供跨 change dependency/serialization、全局 workspace 策略、组合派单标识、implementation agent cap 和 integration queue；子 Goal Plan 只能增加子内 Gate，不能放宽或冲突。
-
-
-## 执行模式
-
-### Ticket 模式（默认）
-
-使用下节规定的输入顺序。父 Implementation Plan 存在时采用其 Lead、workspace/integration 与全局 Gate，即使子 Goal Plan 不存在；两者都有时必须一致。没有父计划沿用子计划；两者都没有时当前主会话作为 Lead，按 Direct Spec 的轻量边界执行，不猜测 worktree 策略。
-
-### Direct Spec 模式
-
-只有极小、局部、单一行为、低风险、可逆且无需 Ticket DAG 的工作，才可在用户批准后直接基于 Spec/ADR/CONTEXT 在 current workspace 执行。先确认目标、IN/OUT、唯一写入 owner、可写范围、关键不变量、验证和验收。出现公共 API/schema、迁移、安全、高风险、多个行为或并行需求时返回 T-tickets。
-
-### Documentation 分支
-
-Ready documentation Ticket 或获批 Direct Spec 需要维护项目文档时读取 <Path>{roots.workflows}/specdev/I-implement/references/documentation-procedure.md</Path>。继续执行下方全部适用预检、workspace、commit、双轴审查、Evidence 和完成步骤；仅纯说明变更的代码红绿循环由可运行示例/类型/链接/生成与事实验证替代。prompt/tool/CLI/UI 文案属于可见行为，不能按纯说明豁免。
-
-## 输入
-
-两种模式都必须读取：
-
-- 当前 Spec：`<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- 项目配置：`<Path>{roots.state}/specdev/config.json</Path>`
-
-Ticket 模式必须按以下顺序读取：
-
-1. `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 的总体实施背景和完整项目 Skill 读取矩阵；
-2. 矩阵中适用于 `ALL` 或当前 Ticket ID 的全部项目 Skill；
-3. 当前 Ticket `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`；
-4. 存在的 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`，以及父 Implementation Map 声明当前 change 时的父 Map/Plan。
-
-矩阵是发布时确认的最低必读集合，不是 allowlist。项目 Agent 指令或实际实现范围触发新的项目 Skill 时，先读取该 Skill、停止项目写入，由 Lead 更新 Tickets Map 并重新运行 tickets 校验后恢复。Direct Spec 模式必须读取用户对轻量执行合同和直接实现的明确批准。
-
-按存在情况读取：
-
-- 当前 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 缺失且实施需要对应决定时，返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`；Spec、Ticket 或 Goal Plan 与代码事实冲突时按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 返回真正 owner，不在实现中覆盖。
-
-Git 已处于 merge/rebase 冲突时，先加载 `<Path>{roots.workflows}/specdev/I-implement/merge-conflict-protocol.md</Path>`；不把冲突伪装成普通 TDD。
-
-## 流程
-
-### 1. 执行前预检与 workspace
-
-加载 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`。
-
-预检参考拥有 Ready、依赖证据、真实 Skill、计划版本、owner、权限、Git 状态与 workspace 的完整检查，不在此复写。
-
-通过预检后：`required` Ticket 以 `purpose=ticket, operation=create|restore` 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；`current` Ticket 确认当前 branch/HEAD/dirty 状态和单 writer。Lead 设置 Ticket 为 `in_progress` 并按策略登记 active worktree 或 current workspace 记录。Direct Spec 不创建虚假 Ticket/worktree 状态。
-
-**完成标准**：真实 workspace、基线、唯一 owners 和授权与预检一致；代码使合同失效时停止并返回上游 owner，current Ticket 严格串行。
-
-### 2. Lead 决定自行实现或动态派单
-
-Ticket 模式下，Lead 根据 Ticket 独立性、路径冲突、上下文、风险和平台能力决定。派单时以 `operation=dispatch` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`。`current` 模式仍可派遣一个 implementation subagent 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 implementation subagent 绑定独立 Ticket worktree。Direct Spec 模式由 Lead 作为 current workspace 唯一写入 owner，不派遣 implementation subagent 写入。
-
-- implementation subagent 同时取适用子 Goal Plan、父 Implementation Plan、config 和平台能力的共同上限；current 模式保持单 writer 串行安全不变量；Lead 不计入；
-- 父实现编排存在时，派单与返回都使用 `<member-change>::<ticket-id>`，并占用父 Plan 的 task/serialization/integration slot；
-- review/research/test-observation agent 不设置 SpecDev 数字上限，但保持只读；
-- implementation Packet 按策略绑定唯一 Ticket workspace 或 current workspace、checkpoint、Tickets Map、当前 Ticket 的项目 Skill 最低必读集合、路径、非 E2E 检查与 commit 返回；
-- subagent 不写 SpecDev 工件、Evidence、父分支或 E2E 结果；
-- Lead 自行实现时仍遵循相同 worktree、commit 与返回事实合同。
-
-**完成标准**：current 模式只有一个 implementation owner 写当前 workspace；required 模式只有一个 owner 写当前 Ticket worktree；Direct Spec 只有 Lead 写 current workspace；所有 SpecDev 写入仍由 Lead 拥有。
-
-### 3. 设计检查
-
-加载 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`，检查模块、接口、类型、不变量、顺序/错误/性能语义、接缝、适配器、依赖分类、测试观察点和既有公共合同。
-
-存在多个不改变上层契约的局部设计时，可运行 `<Path>{roots.workflows}/specdev/common/rules/design-it-twice.md</Path>`。超出 Ticket 或改变产品/公共合同/数据/兼容/安全时，返回架构审查、Grill、Spec 或 Ticket owner。陌生外部依赖使用 research Skill。
-
-**完成标准**：局部设计与上层契约一致，稳定接缝和依赖策略明确。
-
-### 4. TDD 红→绿垂直循环
-
-加载 `<Path>{roots.workflows}/specdev/I-implement/tdd-rules.md</Path>`、`<Path>{roots.workflows}/specdev/I-implement/tdd-test-design.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`。纯说明文档按上方 documentation 分支验证；其余对每个验收行为或关键风险：
-
-1. 选择公共接口或稳定接缝；
-2. 编写因目标行为缺失而失败的测试/验证并确认失败原因；
-3. 只写足以通过当前测试的实现；
-4. 运行定向非 E2E 验证；
-5. 保存 red/green 事实并进入下一条窄切片。
-
-涉及外部依赖、隔离策略或已有 Mock 时，先读取 `<Path>{roots.workflows}/specdev/I-implement/tdd-mocking.md</Path>`，再决定是否复用真实接缝或替身。
-
-不得删除测试、放宽断言、吞错、永久跳过或只验证 Mock 调用次数来制造绿色。
-
-新增或修改代码注释时，先判断信息能否由命名、类型或结构表达，并同步维护受行为变化影响的既有注释。
-
-涉及错误、取消、并发或资源释放时，按 <Path>{roots.workflows}/specdev/common/rules/error-handling.md</Path> 和 <Path>{roots.workflows}/specdev/common/rules/test-reliability.md</Path> 验证实际状态与清理完成。注册、Worker、CLI、配置和发布路径要覆盖真正入口；删除旧测试前核对全部风险承接，不因为新接口测试存在就删除。
-
-### 5. 实现检查、commit 与 Lead 接收
-
-Ticket 模式的 implementation owner 按 Goal Plan 策略在当前 workspace 或来源 worktree：
-
-- 运行 Ticket 要求的单元、组件、静态、类型、lint/build 等非 E2E 检查；
-- 审计 writable/shared/read-only 路径和新/既有/环境失败；
-- 在已授权时创建引用 Ticket ID 的实现 commit；current 模式 commit 直接落在父分支，required 模式落在 Ticket branch；
-- 返回 commit、dirty 状态、实际路径、命令/结果、未运行项和恢复条件。
-
-Ticket 模式中，Lead 以 `operation=accept` 调用 subagent-delivery，重读 Git 状态、branch tip、commit、diff 和命令事实。无改动时将 Ticket 改为 `cancelled` 并记录原因；不得 empty commit 或 Evidence-only Done。required 模式来源 worktree 不运行 E2E；current 模式适用 E2E 留给 Lead 的 direct-parent 验证。
-
-Direct Spec 模式由 Lead 在 current workspace 运行轻量合同要求的定向非 E2E 检查，审计获批可写范围，并在获得 implementation commit 授权后创建引用 change 的非空 commit；无需改动时记录事实并取消直接实现，不创建 empty commit。记录实施前基线、最终 checkpoint、dirty 状态、实际路径、命令结果、未运行项和恢复条件。
-
-**完成标准**：required 模式 Ticket worktree clean 且 `source_checkpoint` 精确等于 branch tip；current 模式 workspace clean 且 Ticket `result_sha` 精确等于父分支上的 implementation commit；或 Direct Spec 的 current workspace checkpoint、路径和轻量合同一致。
-
-### 6. 双轴审查
-
-调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`。required Ticket 以 `base_sha` 与 `source_checkpoint` 为固定点；current Ticket 以 Ticket 实施前基线与 implementation commit 为固定点；Direct Spec 以实施前基线与 current workspace 最终 checkpoint 为固定点：
-
-- 标准轴：正确性、模块设计、错误、安全、性能、并发、资源、测试与可维护性；
-- 规范轴：Spec/Ticket IN/OUT、实现合同、路径所有权、验证矩阵与 Goal Gate。
-
-标准轴同时复核 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`：公共 API 契约完整，内部注释只保留非显然的 Why、Invariant 和 Risk，且相关注释与当前行为一致。
-
-两个轴隔离并按标准轴、规范轴顺序返回 Lead。局部 finding 在当前模式的实现 workspace 修正、创建新 checkpoint 并重跑；改变上层契约则登记 deviation。Ticket 进入 `review` 或 Direct Spec 进入最终验证前，两轴必须通过。
-
-### 7. 最终集成与适用 E2E
-
-`required` Ticket 模式中，Lead 以 `purpose=ticket, operation=finalize` 调用 dev-worktree，并读取 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/references/finalize.md</Path>`。该参考唯一维护最新父分支 candidate 的组合、检查、失败/漂移、重建、fast-forward、回读与尝试上限过程。验证失败或父 HEAD 漂移，父分支不推进；不能凭来源检查通过标记 Done。
-
-E2E 是否需要由 Ticket/Goal Plan 的实际跨边界风险决定，不限于 UI；不适用必须记录原因。
-
-`current` Ticket 模式跳过 source worktree、candidate merge 和 candidate checkout。Lead 在当前 workspace 运行 Ticket 要求的适用集成/回归与 E2E，记录运行环境、命令、退出码和摘要；E2E 不得派给其他 agent。失败时不声明完成，保留 Ticket commit、父 HEAD 和恢复条件。全部通过后重读父 HEAD/tree 并记录 `result_sha`。Direct Spec 模式同样跳过 source worktree、candidate merge 和父分支推进。
-
-无论失败发生在 implementation、review、direct-parent 还是 parent-candidate，同一 Ticket 反复返回相同 blocker、下一轮没有产生新证据，或 integration attempts 达到有效 Plan 上限时，都停止自动退回原 implementation owner。Lead 保留当前 workspace/worktree、implementation/source commit、旧 candidate 和失败命令，在 Ticket Evidence 记录失败历史，并将 Ticket/worktree 标为 `blocked`。当前 change 属于父实现时返回父 O Lead；否则返回 Goal Plan Lead，或无 Goal Plan 时的当前 I Lead。Lead 按 lead-orchestration 完成最小复盘并形成有实质变化的新 Dispatch Packet 后，才可重置 attempts 和重新派发；契约已失效则返回真正 owner。
-
-### 8. Evidence、状态与完成
-
-Lead 使用 `<Path>{roots.workflows}/specdev/I-implement/evidence-template.md</Path>` 写入 Ticket Evidence；Direct Spec 按该模板的 Direct Spec 适配说明写 `<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`。Ticket Evidence 按策略记录 implementation/source、适用 candidate/result SHA、派单/返回、两层验证、双轴审查、E2E disposition、路径审计、失败历史与适用 Lead 复盘、偏差和残余风险；Direct Spec Evidence 使用实施前基线与 current workspace 最终 checkpoint，不伪造 Ticket/worktree/candidate 字段。
-
-Ticket 正常状态：`ready → in_progress → review → done`。`required` 的 `done` 要求 change worktree 已完成集成（`integrated` 或 `removed`）、父 HEAD=result SHA 且包含 source commit；`current` 的 `done` 要求 current workspace clean、direct-parent 验证通过且父 HEAD=result SHA。阻塞使用 `blocked`，契约偏差使用 `deviated`，无需改动使用 `cancelled`。Direct Spec 由当前 I-implement owner 按 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` 关闭 change。
-
-按存在和当前模式同步 Ticket、Tickets Map、Goal Plan、`<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 和全局状态；Direct Spec 不创建缺失的 Ticket/Map/Goal Plan。最后一个计划内 Ticket 完成后，Goal Plan 的 Lead 按 change completion 关闭；无 Goal Plan 的当前 I owner 承担同一门禁。需要远程 reconcile 或把已完成 Ticket 投影为 GitHub Issue 时返回 T-triage，否则进入 Archive。
-
-当前 change 属于未完成父实现 change 时，单个组合 Ticket 完成、阻塞或触发 Lead 复盘，且子状态与 Evidence 已写入后，必须自动返回 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>`，由父 Lead 重读全部成员并决定重新派发、返回上游或继续下一 frontier；不得要求用户逐个重新激活，不得直接归档子 change，也不得从本 Work 实现另一个成员。
-
-运行：
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage implement \
-  --repo <project-root> \
-  <Path>{roots.state}/specdev/changes/{change}</Path>
-```
-
-### 9. 返回
-
-Ticket 模式返回 Ticket/change 状态、Evidence 完整路径、workspace locator、implementation/source、适用 candidate/result SHA、父分支、E2E disposition、适用 Lead 复盘决定、未验证项和下一路由。Direct Spec 返回 change 状态、`<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`、current workspace、实施前/最终 checkpoint、适用 E2E 和下一路由。push、PR、remote merge、deploy、migration、生产动作及来源 branch/worktree cleanup 只在独立授权时执行。
-
-## 计划型票扩展
-
-实施前按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 执行绑定；恢复或上游变化按 `<Path>{roots.workflows}/specdev/P-goal-plan/references/replan-and-recovery.md</Path>` 核验。不以读取替代调用，不因他人任务冲突暂停独立已授权工作。

package/template/workflows/specdev/I-implement/tdd-rules.md

@@ -1,25 +0,0 @@
-# TDD 红绿规则
-
-1. 从 Ready Ticket/Spec 选择下一条最小可观察行为，并写下已确认 seam。
-2. 只为该行为编写一个会因目标能力缺失而失败的测试或验证。
-3. 运行并观察红灯；失败原因必须是目标行为缺失，而不是语法、夹具或环境错误。
-4. 只写使当前测试通过的最小生产代码，不预测后续切片。
-5. 运行定向测试并观察绿灯，记录命令与结果。
-6. 进入下一条窄垂直切片；周期性运行受影响回归。
-
-重构不属于红绿循环。全部目标行为完成并经过双轴 review 后，才进入独立修正/重构阶段，并重跑受影响 review 轴与验证。
-
-## 完成门
-
-- 每个切片有对应 red 和 green 证据；
-- 一个循环只有一个 seam、一个测试和一个最小实现；
-- 测试没有通过删除、跳过、吞错或放宽断言制造绿色；
-- review 前没有以“顺手重构”扩大切片。
-
-## 强制变异验证
-
-使用强制变异时，先保存基线 hash/diff，修改后核对实际执行文件的 diff 与测试选择。只有预期行为断言 red 才有效；编译错误、错测或变异未落地均不计。恢复原内容、复跑基线并核对 diff，把全过程记入 Evidence。诊断协议见 <Path>{roots.workflows}/specdev/D-diagnose-bugs/D-diagnose-bugs.md</Path>。
-
-## 纯说明与测试承接
-
-纯文档按 <Path>{roots.workflows}/specdev/I-implement/references/documentation-procedure.md</Path> 执行适用验证，不伪造代码红绿；prompt/tool/output 改动仍属行为。旧测试删除必须覆盖其行为、错误、兼容和回归义务，具体按 <Path>{roots.workflows}/specdev/common/rules/test-reliability.md</Path>。

package/template/workflows/specdev/I-init-setup/I-init-setup.md

@@ -1,45 +0,0 @@
----
-id: specdev/init-setup
-type: workflow-entry
-workflow: specdev
-name: 初始化设置
-description: 初始化 SpecDev 的语言、配置、全局状态、本地 change 追踪、领域知识布局、验证命令和并发治理。
-keywords: [初始化, 配置, status, tracking, 验证命令]
----
-
-# 初始化设置
-
-激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`、`<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/path-reference-contract.md</Path>`。本 Work 只配置 SpecDev，不修改业务代码或迁移旧状态。
-
-## 定位与探测
-
-创建任何目录前，从 cwd 向上定位并打开 `<Path>{roots.state}/workspace.json</Path>`，验证 `path_base` 与 roots。只写声明的 `<Path>{roots.state}/specdev/</Path>`；不得把状态根默认展开成项目根 `.speculo`，嵌套安装的项目根 `.speculo/specdev` 非法。根目录未解析或未获授权时停止写入；持久化引用使用根变量，不把机器绝对路径写回模板。
-
-只读探测包管理、多工作区、构建/测试/类型/lint/CI、默认父分支、worktree、项目 Agent 指令及分支/提交/发布先例；记录根依赖清单、锁文件、共享 schema、迁移索引、全局导出/路由等高冲突资源。能从仓库发现的事实不重复问用户。
-
-确认项目根 `.gitignore` 已含 `specdev-worktree/` 或 `/specdev-worktree/`；该条目由 `speculo init` 唯一维护，缺失时停止并提示重新运行当前版本 CLI，不由 Work 补写。
-
-## 能力探测的结果
-
-把每项能力区分为可用、未安装、未配置、未授权或当前不适用，并保留仓库依据；未知验证命令仍为 null。先定位真实项目 Skill 和构建/测试/发布入口，不把 DSH 命令或覆盖率搬进配置。探测不自动安装依赖、不运行发布，不创建虚假 change；再次初始化只补缺失骨架，不覆盖原历史。
-
-## 选择初始化分支
-
-| 当前事实 | 执行 |
-|---|---|
-| 配置或状态不存在 | 读取 `<Path>{roots.workflows}/specdev/I-init-setup/references/first-setup.md</Path>`，仅在首次创建对应文件时读取 `<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>`、`<Path>{roots.workflows}/specdev/I-init-setup/tracking-template.md</Path>`、`<Path>{roots.workflows}/specdev/I-init-setup/domain-layout-template.md</Path>`；只创建缺失骨架；语言、并发、UI 数量与人工批准偏好仅补问尚未知项 |
-| 已有有效配置和状态 | 对照 `<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>`、`<Path>{roots.workflows}/specdev/common/schemas/status.schema.json</Path>` 验证并复用；保留 active、历史、永久知识和用户配置 |
-| 用户要求修改既有配置 | 先验证并展示差异，再按授权更新；不存全局自动提交/集成开关 |
-| JSON 无效、版本未知或契约冲突 | 保留原文件并报告 blocker；迁移只由 `speculo init` 使用 `<Path>{roots.workflows}/specdev/runtime-contract.json</Path>` 中登记的显式 migrator 完成 |
-
-## 验收与返回
-
-配置/全局状态必须可解析且满足 schema；状态、changes、永久 ADR/context/research、archive 与配置目录齐全，tracking/domain-layout 两份配置文档有效。验证命令必须有仓库或用户来源，未知值保留 `null`，不保存秘密。
-
-创建 change 前，对照 `<Path>{roots.workflows}/specdev/I-init-setup/change-status-template.json</Path>` 与 `<Path>{roots.workflows}/specdev/common/schemas/change-status.schema.json</Path>`，真实创建时替换占位符后校验；纯初始化不创建虚假的 change。
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --self-check
-```
-
-回读实际配置、状态、目录和忽略项后返回状态根、语言、验证命令、并发/批准策略、未确认配置与检查结果。若由 active change 调用，按原启动/交接合同登记 `current_work`，成功后去重更新 `works_run` 并清空；纯初始化不改已有 active 索引。时间和验证证据留在回复或调用 change 的 Evidence/LOG，不写进全局索引。

package/template/workflows/specdev/I-init-setup/change-status-template.json

@@ -1,28 +0,0 @@
-{
-  "schema_version": 6,
-  "artifact": "change-status",
-  "change": "<YYYY-MM-DD-topic>",
-  "change_status": "active",
-  "current_work": null,
-  "works_run": [],
-  "claimed_investigations": [],
-  "execution_authorization": {
-    "implementation_commit": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Ticket implementation commits"},
-    "local_candidate_integration": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Lead-owned local direct-parent or candidate integration and parent update"},
-    "source_cleanup": {"status": "not-authorized", "source": null, "granted_at": null, "scope": "Source worktree and branch cleanup"}
-  },
-  "leadership": {
-    "current": "<owner-or-session-locator>",
-    "epoch": 1,
-    "assigned_at": "<ISO-8601>",
-    "history": []
-  },
-  "created_at": "<ISO-8601>",
-  "updated_at": "<ISO-8601>",
-  "completed_at": null,
-  "archived": false,
-  "archive_path": null,
-  "blockers": [],
-  "deviations": [],
-  "worktrees": []
-}

package/template/workflows/specdev/I-init-setup/config-template.json

@@ -1,31 +0,0 @@
-{
-  "schema_version": 6,
-  "interaction_language": "zh-CN",
-  "artifact_language": "zh-CN",
-  "git": {
-    "default_branch": null
-  },
-  "execution": {
-    "max_implementation_agents": 3,
-    "max_integration_attempts": 3,
-    "deep_ticket_human_approval": true,
-    "shared_path_owner": "explicit"
-  },
-  "verification": {
-    "test": null,
-    "typecheck": null,
-    "lint": null,
-    "build": null
-  },
-  "planning": {
-    "default_depth": "standard",
-    "require_ready_gate": true,
-    "require_evidence": true,
-    "ui_design_default_candidates": 3,
-    "ui_design_max_candidates": 4
-  },
-  "github": {
-    "include_external_prs": false,
-    "labels": {}
-  }
-}

package/template/workflows/specdev/I-init-setup/domain-layout-template.md

@@ -1,23 +0,0 @@
-# 领域文档布局
-
-## 读取顺序
-
-1. 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
-2. 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
-3. 当前领域上下文：`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
-4. 当前架构决策：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-5. 当前 Spec：`<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-6. 当前 Ticket 目录：`<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`
-7. 当前 Goal Plan：`<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`
-8. 当前设计日志：`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
-
-## 职责
-
-- `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`：当前 bounded context 的项目规范术语和 `_Avoid_` 同义词；不保存代码导航或 change 历史。
-- `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`：当前 change 已接受、被替代或废弃的架构决策。
-- `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`：设计讨论轨迹，不作为当前架构的最终权威。
-- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`：用户问题、外部行为、范围与验收合同。
-- `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`：单个垂直切片的执行契约。
-- `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`：跨 Ticket 的门禁、调度和治理。
-
-change 完成后，只有仍真实、跨 change 有用且有实现证据的规范术语或符合三项准入条件的 ADR 才能提升到永久目录。

package/template/workflows/specdev/I-init-setup/references/first-setup.md

@@ -1,46 +0,0 @@
-# 首次配置与缺失骨架
-
-只在配置或状态尚不存在时读取；已有文件先按入口验证，不重新初始化。
-
-### 3. 询问不可发现偏好
-
-仅在上下文未提供时询问：
-
-- 交互语言与持久化工件语言；
-- implementation subagent、集成尝试次数和 UI 设计候选上限（初始化时写入 config，Lead 不计入）；
-- Deep Ticket 的迁移、发布和不可逆操作是否必须人工批准；
-
-不询问可由仓库事实回答的文件位置、脚本名或默认分支。
-
-### 4. 写入配置
-
-以 `<Path>{roots.workflows}/specdev/I-init-setup/config-template.json</Path>` 为模板写入 `<Path>{roots.state}/specdev/config.json</Path>`。
-
-要求：
-
-- 字段满足 `<Path>{roots.workflows}/specdev/common/schemas/config.schema.json</Path>`；
-- 验证命令来自仓库事实或显式用户决定；
-- 未确认命令写 `null`，不得虚构；
-- 不写入令牌、凭据、Cookie、个人隐私或敏感环境变量值；
-- Ticket 的实现 commit 与本地 candidate integration 仍由具体 Goal Plan/I-implement 取得授权，不存为全局自动副作用开关。
-
-### 5. 初始化目录与状态
-
-创建或确认以下目录和文件：
-
-- 以 `<Path>{roots.workflows}/specdev/I-init-setup/status-template.json</Path>` 生成 `<Path>{roots.state}/specdev/status.json</Path>`
-- `<Path>{roots.state}/specdev/.config/</Path>`
-- `<Path>{roots.state}/specdev/changes/</Path>`
-- `<Path>{roots.state}/specdev/adr/</Path>`
-- `<Path>{roots.state}/specdev/context/</Path>`
-- `<Path>{roots.state}/specdev/research/</Path>`
-- `<Path>{roots.state}/specdev/archive/</Path>`
-
-若全局状态或 config 已存在，先检查各自 `schema_version`。版本未知、JSON 不可解析或状态与当前 workflow 契约不一致时，停止当前 Work；不得在 Work 内迁移、兼容或猜测旧状态。`speculo init` 只会对 `<Path>{roots.workflows}/specdev/runtime-contract.json</Path>` 已登记且存在显式 migrator 的旧版本升级，其他冲突会保留当前安装并报告具体 blocker。只有状态不存在时才从当前 schema 模板创建。
-
-从模板生成：
-
-- `<Path>{roots.workflows}/specdev/I-init-setup/tracking-template.md</Path>` → `<Path>{roots.state}/specdev/.config/tracking.md</Path>`
-- `<Path>{roots.workflows}/specdev/I-init-setup/domain-layout-template.md</Path>` → `<Path>{roots.state}/specdev/.config/domain-layout.md</Path>`
-
-已有永久知识不得被初始化过程清空。已有配置应先验证和展示差异，再按用户授权更新。

package/template/workflows/specdev/I-init-setup/status-template.json

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

package/template/workflows/specdev/I-init-setup/tracking-template.md

@@ -1,13 +0,0 @@
-# 变更追踪约定
-
-SpecDev 只使用本地 Markdown/JSON 工件跟踪开发。远程 Issue、URL 或指定内容必须先由 Triage 冻结为 `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`；远程状态、label、assignee 和 dependency 不替代本地 change、Ticket、Map、Goal Plan 或 Evidence。
-
-- change 根：`<Path>{roots.state}/specdev/changes/</Path>`。
-- 单个 change：`<Path>{roots.state}/specdev/changes/{change}/</Path>`，其中 `{change}` 使用 `<YYYY-MM-DD>-<kebab-topic>`。
-- 一个 change 表示一个可独立说明、实现、验证和归档的目标。
-- `<Path>{roots.state}/specdev/status.json</Path>` 维护全局活动索引；`<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 维护单个 change 生命周期。
-- Ticket 文件是 Ticket 状态权威；`<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是同步投影。
-- 工件状态应在同一次操作中同步，避免入口状态、Ticket 状态与 Map 状态漂移。
-- 完成条件：全部必需 Ticket 为 `done` 或有批准的 `cancelled`，证据齐全，无未批准 deviation，change 级验证通过。
-- 归档后的 `<Path>{roots.state}/specdev/archive/YYYY-MM/{change}/</Path>` 默认只读；后续纠正通过新 change 和 supersedes 链完成。
-- 可关闭的远程来源在本地完成后由 Triage reconcile；`closed`、显式 `waived` 或 `not-applicable` 后才归档。完成后若要把 Ticket 记到 GitHub，由 T-triage publish 写入 `<Path>{roots.state}/specdev/changes/{change}/publish.md</Path>`；`pending`/`publish-failed` 不可归档。尚未成 Change 的记事项由 T-triage capture 写入 `<Path>{roots.state}/specdev/capture.md</Path>`（缺失合法），Issue 保持 open，不创建 change。发布计数与 inbox 计数都以对应本地账本为准，标签词表见 T-triage classification-map。远程 Issue 仍不是开发权威。

package/template/workflows/specdev/INDEX.md

@@ -1,30 +0,0 @@
----
-id: specdev
-type: workflow
-workflow: specdev
-name: SpecDev Workflow
-description: 以本地工件为开发权威，覆盖来源分诊、诊断、设计、逻辑/UI 原型、规格、Ticket、编排、实现、审查、复盘、GitHub/PR/包发布交付与知识归档。
-keywords: [specdev, local-first, 规格驱动开发, decision-complete, prototype, code-review, TDD, retro, PR, release, 证据]
----
-
-# SpecDev Index
-
-本索引用于发现 SpecDev，并让未激活 SpecDev 的会话按需取得项目已经沉淀的长期知识。
-
-激活后读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`：先定位相关 entry，再回读少量原文与 provenance；正式写入前检查 owner/gateway、pending transaction、lock 和 recovery evidence。
-
-## 永久知识
-
-读取本索引时，只把与当前请求相关且已经存在的内容作为只读背景；不存在的路径静默跳过：
-
-- 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
-- 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
-- 永久研究：`<Path>{roots.state}/specdev/research/</Path>`
-
-## Work 激活
-
-用户明确激活 SpecDev 或其中某个 Work 后，读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 取得 Work 条目、启动、恢复、状态、所有权和副作用合同，再进入目标 Work。仅发现本索引或读取永久知识不加载该合同。
-
-## 专业能力定位
-
-用户明确激活对应 Work 后再加载其分支：性能测量用 R-review-architecture；获批文档维护用 I-implement；无法复现事件的证据收集用 D-diagnose-bugs。保留原入口，不新增 Work ID 或另一套技能目录；只想了解当前 change 的实现仍用 L-learn-change。

package/template/workflows/specdev/L-learn-change/L-learn-change.md

@@ -1,32 +0,0 @@
----
-id: specdev/learn-change
-type: workflow-entry
-workflow: specdev
-name: Change 学习
-description: 在开发完成后围绕当前 SpecDev change 回答问题，并用面向零专业背景读者的 Markdown 与 ASCII 图解持续记录理解。
-keywords: [learn-change, change 学习, 开发后提问, 零基础, 大一新生, Markdown, ASCII]
----
-
-# Change 学习：给零基础新生的图解
-
-激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`。只解释当前 change 已验证的实现与测试事实，不作产品/架构决定或授予实现权限。
-
-## 执行
-
-1. **选择现有 change**：使用用户指定或唯一未归档 change；没有时返回缺失输入，不创建空 change。只读归档不追加学习材料。按原交接规则登记 `current_work=specdev/learn-change`，不把 `change_status=completed` 重新打开为开发中。
-2. **确定主题**：使用 `$ARGUMENTS` 调用参数或用户最新问题；缺少时只询问主题。读者是刚入大学、零专业背景的新生，先确定“它是什么、为什么需要、怎样流动或被调用”三个答案。
-3. **定位事实**：按主题读取 Source、Spec、Ticket、Evidence、review、实际代码/测试与可靠来源。区分已验证事实、类比与未知；旧计划和实现冲突时明确差异，以当前代码、测试、Evidence 为实现事实，不让类比代替证据。
-4. **生成与保存**：读取 `<Path>{roots.workflows}/specdev/L-learn-change/references/lesson-format.md</Path>` 的完整格式和命名合同。先画 ASCII 全图，再按实际关系画短小结构/数据/调用/状态图；用短句解释箭头，术语先日常解释再给专业名字。验证零背景读者能复述三个答案；不能时拆图或换词，不灌长文。
-5. **追加而非覆盖**：从 `<Path>{roots.state}/specdev/changes/{change}/learning/index.md</Path>` 及同目录真实图解的最大编号取下一号；先原子创建 `<Path>{roots.state}/specdev/changes/{change}/learning/{number}_{topic}.md</Path>` 新图解，再更新索引并回读。重讲同主题仍新增编号，保留旧文件、原顺序和全部历史行。产物仅为纯 Markdown/ASCII，不生成 HTML、CSS、SVG、图片或浏览器依赖，不写 `<Path>{roots.state}/learning/</Path>`、生产代码、永久知识或远程系统。
-
-## 事实、理由与解释
-
-图解中明确已验证实现事实、可定位设计理由、教学类比与未知。讲解失败或恢复时引用实际契约与证据，不编造事故；旧计划与现状不同要指出差异，不把提案当事实。重新讲同主题仍追加新编号，不覆盖历史，不改 Learning workflow，也不把理解总结直接晋升永久知识。
-
-## 验收与恢复
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --stage learn-change <Path>{roots.state}/specdev/changes/{change}</Path>
-```
-
-图解符合格式参考的四节、至少一个 ASCII 图和连续编号；索引指向真实新文件且主题/简介一致，箭头方向与事实相符。验证通过才去重更新 `works_run`、清空 `current_work`，返回新图解和索引完整路径。失败保留恢复位置与原因，不改变 change 原有开发完成状态。

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

@@ -1,58 +0,0 @@
----
-id: specdev/goal-plan
-type: workflow-entry
-workflow: specdev
-name: Goal 规划与执行
-description: 为单个已拆票 change 或多个 Ready change 规划、执行或恢复 Goal；只在用户要求交付编排或已有 map 需推进时使用，不代替需求探索和 Ticket 编写。
-keywords: [goal, 目标, plan, run, resume, replan, verify, Lead]
----
-
-# Goal 规划与执行
-
-> 激活后读取 `<Path>{roots.workflows}/specdev/README.md</Path>`。P 是统一 Goal 入口；G 仍是 Grill，跨 change 由本入口统一编排。
-
-## 读取范围
-
-先读 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，定位用户指定的 change 或 map，再读状态、当前 map 和所选模式。每次只展开实际进入 frontier 的 Ticket、直接依赖 Evidence、命中的项目 Skill、当前 Gate 与恢复证据；不默认通读所有 Ticket 或永久索引。
-
-## 按意图选择模式与权威
-
-| 用户意图 | 模式 | 必须按需读取 |
-|---|---|---|
-| 制定目标计划，尚未授权实现 | `plan`（默认） | `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-lifecycle.md</Path>`；单 change 再读 `<Path>{roots.workflows}/specdev/P-goal-plan/references/single-change-plan.md</Path>`，多个 change 再读 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-change-plan.md</Path>` |
-| 明确要求按计划实施 | `run` | `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-lifecycle.md</Path>` 与 `<Path>{roots.workflows}/specdev/P-goal-plan/references/map-control.md</Path>` |
-| 继续既有目标 | `resume` | 同上，先校验版本、owner、授权和未闭合事务，再恢复；不重复已完成副作用 |
-| 上游变更使计划失效 | `replan` | `<Path>{roots.workflows}/specdev/P-goal-plan/references/replan-and-recovery.md</Path>` |
-| 整体检查与关闭 | `verify` | `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` |
-
-单 change 的 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是用户总控入口；Ticket frontmatter 仍是单票状态、依赖、路径的权威，Goal Plan 拥有跨票 Gate、Wave 和授权引用。少量线性票不强制增加厚重计划。
-
-单 change 的 Map 结构就绪、Goal 全局执行门与逐票 DoR 分开判断。等待上游真实产物的未来票可保持 draft，并记录缺口和重审条件；独立 Ready 票仍可进入 frontier。具体门禁读取 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`。
-
-多 change 复用现有父 Implementation Map/Implementation Plan 和组合 DAG，不迁走活动状态。父 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 仅作无状态入口，模板为 `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-tickets-map-template.md</Path>`。父成员至少两个；只有一个 change 时使用单 change 模式。
-
-## 执行底线
-
-- 先冻结 Outcome、权威来源、用户指定的交付数量、范围、Definition of Done 和失败停止条件；按风险确定 DAG/Gate/Wave，不用文档长度替代质量。
-- 固定 `lead-directed`。`implementation_agent_limit` 不超过现有 config 与宿主能力；只读审查没有新增数字上限。进入派单前读取 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`。
-- 保留原 worktree 选择：未明确时询问，默认 current 严格串行；required 才使用独立 worktree 与 candidate-merge。用户已答过不重复问。默认工具、数量、提交与集成权限均不因入口合并改变。
-- `plan` 只形成计划，缺少执行授权是计划中可见的待满足条件，不等于获准执行。运行前逐项核对真实授权；文档中的“已批准”不构成授权。
-- 当前票必须调用所绑定的真实 Skill，不能以“读过入口”替代；先读取 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>`。缺失必需 Skill、引用或验收证据时阻塞本票及依赖它的分支。
-- 他人 owner、资源或事务冲突仅暂停受影响的依赖闭包；继续独立已授权工作，不抢占、解锁或覆盖他人内容。正式记忆仍只走原网关。
-- 调度调用 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`；调度器不代替实现、审核或授权。长期运行指可恢复，不承诺后台或无限运行。
-
-## 证据复用与停滞恢复
-
-验证复用按 <Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path> 核对代码、配置、输入、Skill、环境和原输出；只使受影响证据失效。升级兼容、迁移、用户可见行为或性能测量仅在风险相关时成为 Goal Gate，不增加普遍必跑流程。
-
-保留原无进展停止：同一 blocker 没有新证据时不重复派发。新 Dispatch 必须说明输入、方法、范围、环境或责任处置的实质变化；换 Agent 或清空 attempts 不是变化。恢复仍核对原授权、owner、Lead epoch 和未决副作用，不接管他人资源。
-
-## 校验与交付
-
-从 map 运行只读控制检查（它不执行代码或授予写权限）：
-
-```bash
-node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --map <map-path> --repo <project-root>
-```
-
-再以 `--stage goal-plan` 运行 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>`：单 change 要求自己的 Goal Plan，合法 draft 可通过结构校验；存在任一父 Map、Plan 或父入口时校验完整父编排，残缺父工件不得回退单 change。校验通过不授予执行权限。完成时回读真实源、map、Ticket 状态和 Evidence，报告完成/阻塞/失效票、整体验收、实际交付数量、验证命令、未执行项与恢复路径。票全 done 不等于 Goal 自动完成。

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

@@ -1,47 +0,0 @@
-# Goal Plan 完成、证据与恢复
-
-## 1. 整体 Definition of Done
-
-至少要求：
-
-- Spec 验收合同全部有通过 Evidence 或明确批准的 deferred；
-- current 模式的非 cancelled Ticket 都有 implementation commit、通过的 direct-parent 验证和父分支 result SHA；required 模式都有 source commit、通过的 candidate 和父分支 result SHA；
-- shared path、接口、数据、兼容、迁移、调用点与回滚合同闭合；
-- 项目定向检查、受影响回归、类型检查、lint/build 和适用 E2E 无未经批准退化；
-- change 状态、Ticket、Map、Goal Plan、Evidence 与实际 Git 状态一致；
-- 没有未集成 implementation/source checkpoint、活动 integration candidate 或未决高影响偏差。
-
-无需改动的 Ticket 必须转为 `cancelled` 并记录来源事实；不得用 Evidence-only Done 或 empty commit 关闭。
-
-## 2. 两层验证
-
-- `current-workspace`：current 模式 implementation owner 运行 Ticket 要求的检查，Lead 在同一 workspace 运行受影响集成/回归和适用 E2E；
-- `source-worktree`/`parent-candidate`：required 模式由 implementation owner 和 Lead 分别运行非 E2E 与集成/E2E 检查。
-
-Evidence 必须记录命令运行环境。required 模式任何在 source worktree 声称的 E2E pass 都无效；subagent 返回的测试结果在 Lead 核对前保持候选状态。
-
-## 3. Gate 关闭
-
-Lead 在每个 Gate 汇总覆盖 Evidence、接口/数据/兼容状态、candidate/result SHA、适用 E2E、反向验证、偏差、风险和批准。Gate 不以“完成若干 Ticket”作为唯一关闭条件。
-
-## 4. 失败与恢复
-
-- current/source 检查失败：保留当前 workspace 或 source worktree，继续当前 Ticket；
-- direct-parent/candidate 冲突或检查失败：父分支不动，integration 记 `failed`，Ticket 回到 `in_progress`/`blocked`；
-- 父 HEAD 漂移：integration 记 `stale`，从最新父分支重建并重跑；
-- E2E required 失败：父分支不动，保留失败命令、适用 checkpoint 和恢复条件；
-- 同一 blocker 反复出现、下一轮没有新证据，或 integration attempts 达到有效上限：停止自动重复，保留 workspace、checkpoint/candidate 和全部失败事实，将受影响 Ticket 标为 `blocked` 并返回有效 Lead；Lead 按 lead-orchestration 在 Evidence 写复盘决定后，才可重置该 Ticket 的 `attempts` 并以有实质变化的新 Packet 重新派发；
-- 命中当次 Dispatch Packet/候选协议的停止条件、继续修正已无合理收益或需要新产品决定：停止受影响 Wave，按 deviation control 返回契约 owner；
-- Lead 会话变化：读取 Goal Plan、Ticket、change worktree 状态与最新 Evidence，从最后不可变 checkpoint 恢复。
-
-父 P-goal-plan 的 Lead 可继续其他不受影响的 ready frontier；单个 Ticket 进入 Lead 复盘不自动终止整个父循环。
-
-## 5. Change 完成 owner
-
-Lead 是 Goal Plan change 的唯一完成 owner。没有 Goal Plan 的单 Ticket/Direct Spec 由当前 I-implement owner 按 change completion 规则完成。Archive 不补造完成证据。
-
-**完成标准**：所有通过、阻塞、取消和未验证声明均定位到权威工件、命令与 Git checkpoint；失败不会推进父分支或 Done。
-
-## 完成声明的版本
-
-关闭前核对最终实际代码/配置/构件与证据版本，说明未运行项、行为差异和残余风险。性能微基准、原型或 mock 不替代明确要求的真实路径。PR/Issue/发布分别回读原账本，远程 pending 不伪装已交付。