@namewta/speculo 2.0.1 → 2.0.3

package/template/workflows/specdev/specdev-p-goal-plan/assets/lightweight-goal-plan-template.md

@@ -14,6 +14,8 @@ lead: <actual-session-locator>
 
 ## Integration and Verification
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 <适用集成方式、README AC/verification 导航、实际验证与未验证边界；票或清单全勾不替代整体验收。>
 
 ## Next Steps

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

@@ -2,6 +2,9 @@
 
 ## 1. 整体 Definition of Done
 
+实现型完成必须按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 有覆盖实际最终交付的独立双轴通过证据。多单元组合使用整体审查；单单元固定输入相同可复用，未提交内容使用工作副本快照。非实现学习、复盘及取消沿各自等价验收，不制造代码审查。
+
+
 至少要求：
 
 - Spec 验收合同全部有通过 Evidence 或明确批准的 deferred；

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

@@ -33,7 +33,7 @@ Gate 用可验证状态定义，必须写明：工程/业务状态、开启条
 
 ## 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 自行实现或派 任务执行者 不改变所选策略。
+每个进入 I-implement 的 Ticket 建立唯一记录。current 模式使用 `workspace_ref=current`、`branch=parent_branch`，记录 implementation/source/result SHA 与 direct-parent 验证；required 模式使用唯一 `specdev-worktree/<change>/<ticket-id>`，记录 source/candidate/result SHA 与验证状态。Lead 自行实现或派 任务执行者 不改变所选策略。
 
 required 模式同一 Ticket 在 candidate 验证失败后保留来源 worktree 并继续修正。新的 source commit 替换当前 `source_checkpoint`，旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
 

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

@@ -1,6 +1,6 @@
 # Goal Plan 规划模式与输入门禁
 
-规划模式描述 Goal Plan 需要额外解决的工程问题。Goal Plan 创建时单独询问 Ticket 是否开启 worktree，默认使用当前 workspace；worktree 与 direct-parent/candidate-merge 由该次 Goal Plan 固定。
+规划模式描述 Goal Plan 需要额外解决的工程问题。Goal Plan 按共享执行策略分别记录执行方式与工作区；执行方式默认当前宿主正常执行，工作区默认 current，复用已有选择，current/direct-parent 与 required/candidate-merge 保持配对。
 
 本文件定义单 change 的规划与全局执行门。多 change 父编排创建仍要求成员全员 Ready，遵守 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。
 
@@ -34,7 +34,7 @@
 
 ## 3. Goal Plan 工作区选择
 
-- 创建 Goal Plan 时询问“是否开启 worktree 开发？”，默认 `否`；
+- 创建 Goal Plan 时读取 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path>，复用实际工作区选择；未指定默认 current；
 - 用户选择 `否` 时写入 `ticket_workspace_policy: current` 与 `integration_gate: direct-parent`；
 - 用户选择 `是` 时写入 `ticket_workspace_policy: required` 与 `integration_gate: candidate-merge`；
 - 该选择只作用于当前 Goal Plan，不读取或修改全局配置；

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

@@ -3,7 +3,7 @@
 
 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。
+每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时按 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path> 分别确定执行方式和工作区，复用已有选择；未指定时按当前宿主正常执行，工作区默认 current，选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 实现执行者，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
 
 产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
 
@@ -25,7 +25,7 @@ Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、
 - Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
 - 用户明确要求正式跨 Ticket Plan。
 
-少量、线性、低风险的 Ready Tickets 可以不生成厚重编排正文，但执行前仍要有最小 Goal Plan 记录 workspace、Lead、Gate 和授权引用；不得引用不存在的当前 Goal Plan。没有 Ticket 的获批小型 Direct Spec 不受 Ticket workspace 合同约束；一旦需要切片，先运行 T-tickets。
+少量线性 Ready Tickets 可直接进入 I，不要求最小 Goal Plan；workspace、Lead、验证和原授权引用由 I 写原 Evidence。完整获批 Direct Spec 也可以直接执行并独立选择 worktree；需要独立调度或逐票追踪才运行 T-tickets。高风险要求相应 Gate，不以增加工件数量代替风险控制。
 
 ## 输入
 

package/template/workflows/specdev/specdev-r-retro/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specdev-r-retro
-description: "对指定开发活动、环境或协作流程的已观察摩擦做证据化复盘，形成根因、改进 owner 与可检验提案；代码讲解使用 L-learn-change，Speculo 产品反馈使用 retro 命令。"
+description: "对指定开发活动、环境或协作流程的已观察摩擦做证据化复盘，形成根因、改进 owner 与可检验提案；代码讲解使用 L-learn，Speculo 产品反馈使用 retro 命令。"
 metadata:
   speculo-kind: work-skill
   speculo-id: specdev/retro

package/template/workflows/specdev/specdev-s-spec/SKILL.md

@@ -16,9 +16,9 @@ metadata:
 
 1. **Grounding**：定位用户目标与当前代码、测试、接口、schema、配置和运行事实。按存在情况定位 change 的来源、分诊、诊断、LOG、CONTEXT、ADR 及相关永久领域词汇/决策；只回读命中原文，可选工件缺失静默跳过，不当作已确认事实。按 `<Path>{roots.workflows}/specdev/common/rules/planning-principles.md</Path>` 区分可发现事实、高影响偏好和可逆实现细节；冲突按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 返回权威 owner。
 2. **关闭必要决定**：只确认会改变外部行为、接口、数据、兼容、安全、迁移、发布或验收的高价值问题。广泛取舍未定时返回 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>`；陌生外部依赖或版本行为通过 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>` 查证。不虚构错误码、性能阈值、法规或迁移政策。
-3. **写入合同**：先按下述轻量/完整边界选择唯一负责位置；轻量写 README 等价章节，完整模式以 `<Path>{roots.workflows}/specdev/specdev-s-spec/assets/spec-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`。模板拥有问题/用户/成功、正常/边界/失败/角色/状态行为、IN/REUSE/OUT、保持项、接口数据与 NFR 的完整结构及 `US-### / AC-### / NFR-### / DEC-### / OOS-###` 稳定编号。实现约束仅锁定会影响公共合同、兼容、安全或验收的决定。
+3. **写入合同**：先按下述轻量/完整边界选择唯一负责位置；轻量写 README 等价章节，完整模式以 `<Path>{roots.workflows}/specdev/specdev-s-spec/assets/spec-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`。必需正文为问题与目标、外部行为、验收合同、范围和验证策略；用户故事、接口数据、NFR、约束与风险按需展开。已使用的 `US-### / AC-### / NFR-### / DEC-### / OOS-###` 保持稳定，不为凑数量生成条目。实现约束仅锁定会影响公共合同、兼容、安全或验收的决定。
 4. **绑定验证接缝**：优先复用稳定接缝，通常从用户端到端行为、公共 API/CLI、事件/集成、稳定单元接缝选择；按实际风险与项目先例决定，不机械追求最高测试层级。每个接缝注明入口类型/位置、触发方式、可观察结果、覆盖 AC 和实际测试先例/命令。选择显著改变可测试性、事故半径或范围时聚焦确认；可由已有代码推导时记录依据即可。证据遵守 `<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`。
-5. **Readiness**：对照 <Path>{roots.workflows}/specdev/specdev-s-spec/references/spec-readiness.md</Path>；完整 Spec 再校验 <Path>{roots.workflows}/specdev/common/schemas/spec.schema.json</Path>。高影响未决问题使 `ready_for_tickets: false`；低影响、可逆默认值可作为带验证方式的显式假设。每个 AC 必须可观察、可判定、绑定接缝；不适用影响写明理由。
+5. **Readiness**：对照 <Path>{roots.workflows}/specdev/specdev-s-spec/references/spec-readiness.md</Path>；完整 Spec 再校验 <Path>{roots.workflows}/specdev/common/schemas/spec.schema.json</Path>。高影响未决问题使 `ready_for_tickets: false`；低影响、可逆默认值可作为带验证方式的显式假设。每个 AC 必须可观察、可判定、绑定接缝；只展开实际适用影响；已识别风险若不采取检查，说明依据。
 
 简单单 change 可使用 README 的 scope/acceptance/verification 等价章节承载规格，仍须通过同一行为/AC/Ready 语义；独立 <Path>{roots.state}/specdev/changes/{change}/spec.md</Path> 存在时默认使用它，双权威先裁决。用户明确要求 Spec 或存在复杂设计/Deep/并行/跨 change 时交付完整 Spec。迁出 README 规格改为导航。
 
@@ -34,7 +34,7 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --
 
 回读真实规格与 Ready 结论，返回负责工件完整路径、行为/验收合同、范围、验证接缝、风险、高影响缺口与验证结果；接续写原 README/规格，不维护调用或全局状态镜像。
 
-只有用户请求或工作流已显式串联时才进入 `<Path>{roots.workflows}/specdev/specdev-t-tickets/SKILL.md</Path>`；产出 Ready Spec 本身不授权实施。
+完整 Spec 就绪且已有同范围实现授权时，可直接进入 <Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>，执行方式与 current/worktree 独立确定；未指定时按当前宿主正常执行，明确指定 CLI 交互、Herdr 等方式时按选择执行。需要独立调度、依赖图、逐票追踪或用户要求拆票时进入 <Path>{roots.workflows}/specdev/specdev-t-tickets/SKILL.md</Path>；需要跨任务/跨 change 总控才进入 P。产出 Ready Spec 本身不授权实施，只有规格请求时返回可用路由。
 
 ## UI 设计与逻辑原型
 

package/template/workflows/specdev/specdev-s-spec/assets/spec-template.md

@@ -10,90 +10,40 @@ sources:
 
 # Spec: <标题>
 
-- **Spec：** `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
-- **当前 ADR：** `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
-- **当前领域上下文：** `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
+## 问题与目标
 
-## 1. 问题与目标
+<目标用户或调用者、当前问题、预期收益与成功标准。只引用真实存在的来源、CONTEXT 和 ADR。>
 
-### 问题陈述
+## 解决方案与外部行为
 
-### 目标用户与场景
+<从入口到可观察结果描述正常流程、适用的角色/状态、边界与失败行为。需要用户故事时使用 US-###，不为凑数量重复 AC。>
 
-### 成功标准
-
-### 非目标
-
-## 2. 解决方案与外部行为
-
-### 解决方案摘要
-
-### 主要流程
-
-### 边界、失败与稳定错误行为
-
-### 状态转换与不变量
-
-## 3. 用户故事
-
-- **US-001**：作为 <角色>，我希望 <能力>，以便 <收益>。
-
-## 4. 验收合同
+## 验收合同
 
 | ID | 前置条件 | 动作或事件 | 可观察结果 | 验证接缝 |
 |---|---|---|---|---|
 | AC-001 | ... | ... | ... | ... |
 
-## 5. 范围
-
-### IN
-
-### REUSE
+## 范围
 
-### OUT
+- **IN：** <交付的行为>
+- **REUSE：** <沿用的能力和必须保持的行为>
+- **OUT：** <明确不做的内容及原因；需要引用时使用 OOS-###>
 
-- **OOS-001**：<不做什么及原因>。
-
-## 6. 已锁定实现约束
-
-- **DEC-001**：<只写影响公共接口、数据、不变量、兼容、安全或验证的决策>。来源：`ADR-###`。
-
-## 7. 数据、接口与兼容
-
-- **公共接口变化：** 无 / ...
-- **数据模型与持久化：** 无 / ...
-- **兼容要求：** 无 / ...
-- **迁移要求：** 无 / ...
-- **发布或运维影响：** 无 / ...
-
-## 8. 非功能要求
-
-- **NFR-001 安全与隐私：**
-- **NFR-002 性能与容量：**
-- **NFR-003 可用性与可靠性：**
-- **NFR-004 可观测性与运营：**
-
-不适用的维度写“不适用：原因”。
-
-## 9. 验证策略
+## 验证策略
 
 | 接缝 | 层级 | 覆盖合同 | 现有先例或命令 | Evidence 类型 |
 |---|---|---|---|---|
+| ... | ... | AC-001 | ... | ... |
 
-项目测试先例可引用项目相对路径，例如 `<Path>tests/example.test.ts</Path>`。
+优先复用真实测试接缝和项目先例；按风险选择验证层级。项目文件使用项目相对 Path，例如 `<Path>tests/example.test.ts</Path>`。
 
-## 10. 风险、假设与未决问题
+## 约束与风险（适用时）
 
-### 风险
+仅保留影响公共接口、数据、不变量、兼容、安全、迁移或验收的决定；引用原 ADR，必要时以 DEC-###/NFR-### 标识。取消、重复、部分成功、未知结果及恢复限制写入原 AC/NFR，不另抄一套失败合同。无关维度省略，不逐项填“不适用”。
 
-### 已采用的低影响假设
+低影响可逆假设写清适用范围和验证方法；高影响未决问题关闭前保持 `ready_for_tickets: false`。该字段也适用于 Direct Spec 的实现就绪判断。
 
 ### 未决问题
 
 无。
-
-存在高影响未决问题时，`ready_for_tickets` 必须为 `false`。
-
-## 失败与兼容补充（适用时）
-
-在原 AC/NFR 编号下记录取消/重复/乱序、未开始/部分提交/已提交/未知结果、可安全重试前提、状态 owner、可观察错误和旧数据迁移/恢复限制。这里只补充适用合同，不新增另一套验收编号或实现计划。

package/template/workflows/specdev/specdev-t-tickets/SKILL.md

@@ -36,7 +36,7 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --
 node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --map <Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path> --repo <project-root>
 ```
 
-需要正式 Goal、多 change、迁移或跨票 Gate 时交给 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/SKILL.md</Path>`；少量线性票可从 map 按已授权范围调用 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`。不得以“精简”为理由静默更换默认工具或少交付。
+需要正式 Goal、多 change、迁移或跨票 Gate 时交给 `<Path>{roots.workflows}/specdev/specdev-p-goal-plan/SKILL.md</Path>`；少量线性票无需额外 Goal，可从 map 按已授权范围调用 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`。不得以“精简”为理由静默更换默认工具或少交付。
 
 ## 工程义务与证据失效
 

package/template/workflows/specdev/specdev-t-tickets/assets/ticket-template.md

@@ -28,130 +28,46 @@ shared_path_owners: []
 
 # Ticket T-01: <标题>
 
-- **Ticket 文件：** `<Path>{roots.state}/specdev/changes/{change}/ticket/01-<ticket-name>.md</Path>`
 - **总体 Map：** `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
 - **上游 Spec：** `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
 - **完成 Evidence：** `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`
+- **执行入口：** 获得实现授权后读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`；按 Map → 适用项目 Skill → 当前 Ticket 读取输入。项目 Skill 调用不能替代 I 的实现、独立双轴审查及完成流程。
 
-实现本 Ticket 时，Lead 与 实现执行者 必须按顺序完整读取总体 Map，读取项目 Skill 的 frontmatter 与入口并只展开适用于 `ALL`/`T-01` 的匹配项，再读取本 Ticket 与相关上游工件。Map 中的 Skill 是最低必读集合；新的匹配项先由 Lead 同步到 Map 并重新校验。
+## 目标与来源
 
-## 1. 战略与来源
+<本票交付的可观察产出、为何需要，以及上游 AC/用户决定/诊断来源；只补充相关现状与差距。>
 
-- **目标：** 做什么、为什么、基于什么现有能力。
-- **可观察产出：** 完成后用户、调用者或系统外部可以观察到什么。
-- **来源：** `US-###`、`AC-###`、`ADR-###`、`USER-DECISION`、`CODE`、`RESEARCH` 或 `DIAG-###`。
-- **当前事实：** 相关现状与目标差距；项目文件使用项目相对 Path 标签，例如 `<Path>src/example.ts</Path>`。
-- **Planning Depth 原因：** 说明为什么是 Lite、Standard 或 Deep。
+## 行为与范围
 
-## 2. 决策状态
+<描述入口、动作、结果与适用失败行为组成的完整垂直切片。引用 Spec，明确本票 IN/REUSE/OUT 和必要差异，不复制上游合同。>
 
-### 已锁定决策
+## 验收标准
 
-- ...
+- [ ] `AC-001`：<本票可独立验证的结果>。
 
-### 已采用的低影响假设
-
-- 无。
-
-### 未决问题
-
-无。
-
-存在会改变行为、接口、数据、兼容、安全、范围、迁移或验收的问题时，frontmatter 中 `ready` 必须为 `false`。
-
-## 3. 范围边界
-
-| IN（本 Ticket 构建） | REUSE（复用且不改变契约） | OUT（明确不做） |
-|---|---|---|
-| ... | ... | ... |
-
-## 4. 要构建什么
-
-从用户或调用者视角描述一条完整行为路径：入口、动作、可观察结果、失败行为和边界。不要按数据库、后端、前端、测试等技术层分段罗列。
-
-## 5. 实现契约
-
-<!-- Lite 可压缩为适用条目；Standard 和 Deep 必填。 -->
-
-- **入口或接缝：**
-- **输入与输出：**
-- **公共接口变化：** 无 / ...
-- **不变量：**
-- **状态或数据流：**
-- **错误与失败行为：**
-- **兼容要求：**
-- **安全与隐私要求：** 不适用：原因 / ...
-
-## 6. 执行路线
-
-<!-- Lite 通常 1–3 步；Standard 和 Deep 通常 3–7 步。描述行为顺序、安全落点和验证时机，不写逐行代码。 -->
-
-1. 建立或确认验证接缝，使目标行为或关键风险按预期失败。
-2. ...
-3. 形成保持仓库可验证的安全落点。
-4. 运行定向验证和适用回归。
-
-## 7. 路径访问契约
-
-- **预计修改点：** 与 `expected_changes` 对齐，仅作导航。
-- **可写范围：** 与 `writable_paths` 对齐；越界前必须停止。
-- **只读上下文：** 与 `read_only_paths` 对齐。
-- **共享路径：** 与 `shared_paths` 对齐；每项在 `shared_path_owners` 指定唯一 owner。
-- **保留或不动：** 无 / ...
-
-项目路径必须写成项目相对 Path 标签。SpecDev 工件必须使用完整根变量 Path 标签。
-
-## 8. 验证矩阵
+## 验证方法
 
 | 行为或风险 | 验证接缝 | 命令或步骤 | 预期结果 | Evidence |
 |---|---|---|---|---|
-| 正常路径 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
-| 失败路径 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
-| 回归 | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
+| ... | ... | ... | ... | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
 
-不适用的关键风险类别必须写“不适用：原因”。
-
-- **Workspace checks：** 按 Goal Plan 在 current workspace 或 source worktree 运行单元、组件、静态、类型、lint/build 等适用非 E2E 检查。
 - **E2E disposition：** required / not-required：原因。
-- **E2E owner/environment：** Lead / current-workspace 或 parent-candidate；required 时写明场景、接缝与预期。
-- **Integration evidence：** implementation/source commit、parent before、适用 candidate/result SHA 和父分支包含关系。
-
-E2E 由实际跨边界行为与风险决定，不限于 UI；required 模式不得在 Ticket source worktree 运行或声明通过。
-
-## 9. 发布、迁移与恢复
+- **运行环境：** 按有效执行合同选择 current-workspace 或 source-worktree；required E2E 由 Lead 在 current-workspace 或 parent-candidate 执行。
 
-<!-- Deep 必填；其他深度仅在适用时保留。 -->
+覆盖真实正常、失败和回归风险；不为无关风险制造测试或重复验收条目。
 
-- **迁移顺序：** 不适用：原因 / ...
-- **兼容窗口：** 不适用：原因 / ...
-- **监控信号：** 不适用：原因 / ...
-- **回滚或前向恢复：**
-- **不可逆操作与批准点：** 无 / ...
-- **收缩条件：** 不适用：原因 / 旧调用点、旧数据或旧协议使用量为零并有 Evidence。
+## 执行约束
 
-## 10. 验收标准
+依赖、深度及理由、路径所有权、资源声明和 Skill 调用绑定以 frontmatter 为准；`expected_changes` 仅作导航，实现前核对实际代码。必需项目 Skill 按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 实际调用并保留证据。
 
-- [ ] `AC-001`：<可判定结果>。
-- [ ] 实现开始前已完整读取 Tickets Map，已读取项目 Skill 入口并完整展开其中适用于 `ALL`/`T-01` 的匹配项；新发现的匹配 Skill 已由 Lead 同步回 Map。
-- [ ] 验证矩阵全部执行并记录到 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`。
-- [ ] 实际项目修改未超出 `writable_paths`，shared path 由指定 owner 修改。
-- [ ] Ticket 已按 Goal Plan 策略形成非空 implementation/source commit，direct-parent 或 candidate 验证通过且父分支 result 已记录。
-- [ ] E2E disposition 已执行；required 模式 E2E 在 parent-candidate、current 模式在 current workspace 由 Lead 完成。
-- [ ] 未发生未批准的范围、契约或发布偏差。
-- [ ] Ticket 状态有本票 Evidence 支撑；Tickets Map 的导航、依赖和合同覆盖仍有效，不复制本票进度。
+仅补充绑定字段未表达的本票约束：公共接口差异、不可交换的迁移/安全顺序、用户明确交付数量与必要批准点。局部实现由 I 决定，不要求固定步数。通用停止、检查点、集成和完成合同由执行入口负责。
 
-## 11. SKILL 调用计划
+## 未决事项与风险
 
-依据 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 填写 frontmatter 绑定；正文解释每项调用为什么属于本票、具体何时调用、输入定位、输出如何用于下一步。不是仅给出技能名称或阅读列表。没有适用项目 Skill 时写明真实扫描证据；不要保留 unreviewed。
+<仅写适用风险、低影响假设及其验证方式；迁移、兼容、恢复、收缩条件和批准按实际风险展开。没有额外风险时写“无”。>
 
-## 12. 停止、检查点与交付
+存在改变行为、接口、数据、安全、兼容、范围或验收的高影响问题时保持 `ready: false`；记录解除条件与上游 owner。
 
-- **用户交付要求与数量：** 与 Map 的 requested_deliverables 对齐；不为压缩而减少。
-- **必需 Skill/引用/测试不可用：** 阻塞本票，报告缺口，不静默替换默认工具。
-- **归属与资源冲突：** 暂停本票和受影响下游，不接管他人状态；独立票由 map 继续。
-- **检查点：** 记录源版本、绑定摘要、已完成步骤、Evidence 和未闭合动作；恢复前回读。
-- **完成出口：** 全部适用验收及实际 Skill 证据通过，再将结果交回 Goal；未完成项明确列出。
-
-## 工程验收补充（适用时）
+### 未决问题
 
-列明真实消费者/入口、文档和升级说明、错误后的状态保证、恢复责任、旧测试的风险承接，以及代码/输入/配置/Skill 变化时需重验的证据。性能票引用用户操作与基线；documentation 票区分纯说明与模型/用户可见变化。无关项写不适用及理由，不逐项另造 Ticket。
+无。

package/template/workflows/specdev/specdev-t-tickets/assets/tickets-map-template.md

@@ -19,6 +19,8 @@ status: draft
 
 ## 1. 目标与拆分策略
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 引用主要用户故事、验收合同和架构决策，说明所有 Ticket 共同交付的目标、切片原则、prefactor 和 expand-contract 选择。不要复制整个 Spec。
 
 ### 总体实施背景
@@ -68,7 +70,7 @@ T-01
 - review/research/test-observation agent 不设 SpecDev 数字上限，但保持只读。
 - shared owner 为专用 Ticket；Lead 是 SpecDev 状态与父分支 integration owner。
 - 项目路径契约以 Ticket frontmatter 为准。
-- 每个实现 Ticket 的 workspace 由 Goal Plan 选择；current 模式串行使用当前 workspace，required 模式使用独立 worktree；只读调查不进入 I-implement Ticket。
+- 每个实现 Ticket 的 workspace 由有效 Goal/父计划或无 Goal 时当前 I 的原 Evidence 选择；current 模式串行使用当前 workspace，required 模式使用独立 worktree；只读调查不进入 I-implement Ticket。
 
 | Ticket A | Ticket B | Writable 交集 | 真实依赖 | 处理 |
 |---|---|---|---|---|

package/template/workflows/specdev/specdev-t-tickets/references/planning-procedure.md

@@ -1,7 +1,7 @@
 # 拆分 Tickets
 
 
-Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、范围、公共契约、关键顺序和验收上的关键决策，但不展开逐行代码、局部变量或可从现有惯例自然推导的实现细节。
+Ticket 是**可独立验收的垂直行为切片**：它消除执行者在目标、范围、公共契约、关键顺序和验收上的关键决策，但不展开逐行代码、局部变量或可从现有惯例自然推导的实现细节。
 
 本 work 保留原有能力：代码库探索、prefactor 识别、曳光弹垂直切片、真实阻塞边、用户粒度核对、宽重构的 expand-contract 排序、Ticket 独立文件和总体 Tickets Map。
 
@@ -102,27 +102,13 @@ UI 范围同时读取 <Path>{roots.workflows}/specdev/common/rules/design-contra
 
 规划深度不是优先级，也不是 Gate。每个 Ticket 必须记录触发该深度的原因。
 
-### 5. 写成决策完备 Ticket
+### 5. 写成可交接的垂直切片 Ticket
 
 必须按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 填写本票真实调用绑定；Map 中的读取路由不能代替调用。
 
-使用 `<Path>{roots.workflows}/specdev/specdev-t-tickets/assets/ticket-template.md</Path>` 填写：
-
-- 战略目标、可观察产出与来源追踪；
-- 当前代码事实和需求差距；
-- 已锁定决策、低影响假设和未决问题；
-- IN / REUSE / OUT；
-- 用户或调用者视角的端到端行为；
-- Standard/Deep 的接口、输入输出、不变量、数据流、失败与兼容契约；
-- 有序执行路线和安全落点；
-- expected、writable、read-only、shared 路径；
-- 正常、失败和回归验证矩阵；
-- 每个 Ticket 按 Goal Plan 的 workspace 策略定义 current-workspace/direct-parent 或 source-worktree/parent-candidate 检查，以及按实际跨边界风险判定的 E2E disposition；
-- 每个实现 Ticket 的 implementation commit 与对应父分支完成条件；仅 required 模式创建独立 worktree；
-- Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点；
-- 可判定验收标准。
-
-路径所有权必须遵守 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`，证据设计必须遵守 `<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`。
+使用 `<Path>{roots.workflows}/specdev/specdev-t-tickets/assets/ticket-template.md</Path>`：正文只写目标与来源、垂直行为与范围、验收和验证、本票执行约束及适用风险。依赖、路径、资源和项目 Skill 调用以原 frontmatter 为准；不在正文维护镜像。
+
+引用上游 AC/ADR，只补充本票差异。公共合同、关键安全顺序和验收必须确定；局部实现选择交给 I。Lite/Standard/Deep 决定需要展开的实际风险，不规定执行步数，也不要求无关栏目逐项填“不适用”。通用实现、独立审查、集成、停止与恢复沿 I 入口执行。
 
 ### 6. 构建依赖 DAG、合同覆盖与并发检查
 

package/template/workflows/specdev/specdev-t-tickets/references/ticket-readiness.md

@@ -20,22 +20,22 @@
 - [ ] 每个 shared path 在 `shared_path_owners` 中有唯一 owner。
 - [ ] 正常、失败和回归至少各有一条验证，或有可信的不适用原因。
 - [ ] 明确 `E2E disposition: required | not-required: reason`；required 场景、预期和接缝可执行。
-- [ ] 按 Goal Plan 策略定义 current-workspace 或 source-worktree 的非 E2E 检查；E2E owner 固定为 Lead，运行环境分别为 current-workspace 或 parent-candidate。
-- [ ] Ticket 完成合同包含 implementation commit、direct-parent 或 candidate-merge、父分支 result SHA 和 Lead Evidence；仅 required 模式需要独立 worktree。
+- [ ] 按有效计划或当前 I 执行合同 策略定义 current-workspace 或 source-worktree 的非 E2E 检查；E2E owner 固定为 Lead，运行环境分别为 current-workspace 或 parent-candidate。
+- [ ] Ticket 已明确进入 I-implement，由该入口负责 implementation commit、direct-parent 或 candidate-merge、独立双轴审查、父分支 result SHA 和 Lead Evidence；正文不重复通用清单。
 - [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
 - [ ] 单个全新上下文能够完成；否则已拆分。
 - [ ] 所有内部文件与目录引用使用完整根变量 Path 标签。
 
 ## Standard 门禁
 
-- [ ] 实现契约包含入口、输入输出、不变量、状态或数据流、失败行为和兼容。
-- [ ] 有 3–7 步有序执行路线。
+- [ ] 适用的接口、不变量、失败与兼容合同可由 Spec 和本票差异定位。
+- [ ] 影响安全或正确性的关键顺序已明确；不要求固定数量的执行步骤。
 - [ ] 路径所有权足以支持并发判断。
 - [ ] 验证矩阵可以证明外部行为，而非只检查内部调用。
 
 ## Deep 门禁
 
-- [ ] 迁移顺序、兼容窗口、监控、回滚或前向恢复、收缩条件和批准点完整。
+- [ ] 实际涉及的迁移、兼容、监控、恢复、收缩条件和批准点完整；无关项省略。
 - [ ] 安全、隐私、资金或数据完整性风险有缓解与验证。
 - [ ] 跨 implementation owner 的路径所有权和所选 direct-parent/parent-candidate 集成 Gate 明确。
 - [ ] expand-contract 的收缩条件可通过扫描、指标、查询或测试证明。

package/template/workflows/specdev/specdev-l-learn-change/SKILL.md

@@ -1,33 +0,0 @@
----
-name: specdev-l-learn-change
-description: "在开发完成后围绕当前 SpecDev change 回答问题，并用面向零专业背景读者的 Markdown 与 ASCII 图解持续记录理解。"
-metadata:
-  speculo-kind: work-skill
-  speculo-id: specdev/learn-change
-  speculo-domain: specdev
-  speculo-contract-version: "2"
----
-
-# Change 学习：给零基础新生的图解
-
-激活后读取 `<Path>{roots.workflows}/specdev/common/rules/domain-runtime.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`。只解释当前 change 已验证的实现与测试事实，不作产品/架构决定或授予实现权限。
-
-## 执行
-
-1. **选择现有 change**：使用用户指定或唯一未归档 change；没有时返回缺失输入，不创建空 change。只读归档不追加学习材料。恢复依据留原学习索引与当前 README 导航；不把 completed/cancelled 重新打开为开发中。
-2. **确定主题**：使用 `$ARGUMENTS` 调用参数或用户最新问题；缺少时只询问主题。读者是刚入大学、零专业背景的新生，先确定“它是什么、为什么需要、怎样流动或被调用”三个答案。
-3. **定位事实**：按主题读取 Source、Spec、Ticket、Evidence、review、实际代码/测试与可靠来源。区分已验证事实、类比与未知；旧计划和实现冲突时明确差异，以当前代码、测试、Evidence 为实现事实，不让类比代替证据。
-4. **生成与保存**：读取 `<Path>{roots.workflows}/specdev/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 图和连续编号；索引指向真实新文件且主题/简介一致，箭头方向与事实相符。验证通过后回读并返回新图解和索引完整路径，必要接续留原学习载体。失败保留恢复位置与原因，不改变 change 原有开发完成状态。

package/template/workflows/specdev/specdev-l-learn-change/references/lesson-format.md

@@ -1,51 +0,0 @@
-# Change 学习图解格式
-
-写图解与分配编号时读取；这是产物格式权威，不是另一套学习状态。
-
-## 输出格式
-
-在当前 change 的 `<Path>{roots.state}/specdev/changes/{change}/learning/</Path>` 内原子写入一份新的 `<Path>{roots.state}/specdev/changes/{change}/learning/{number}_{topic}.md</Path>`，并原子更新索引 `<Path>{roots.state}/specdev/changes/{change}/learning/index.md</Path>`。这些产物属于 SpecDev change，不写入 `<Path>{roots.state}/learning/</Path>`。文档必须是纯 Markdown，不生成 HTML、CSS、SVG、图片链接或浏览器专属交互。
-
-`<number>` 是两位起始、持续递增的序号：先读取索引和同目录已有的图解文件，取最大序号加一，因此第一次为 `01`，下一次为 `02`；不为旧文件重编号。`<topic>` 是主题的简短、可作文件名的标签，可使用中文、字母、数字、`-` 或 `_`，但不能含空格、`/`、`\\` 或 `..`。同主题再次解释也创建新编号文件。
-
-索引是唯一目录，使用下列 Markdown 表格；每新增一份图解就在表末追加一行，并保留既有行。文件列只写同目录的文件名：
-
-```markdown
-# Change 学习图解索引
-
-| 编号 | 文件 | 主题 | 简介 |
-| --- | --- | --- | --- |
-| 01 | 01_<topic>.md | <主题> | <一句话说明它解释什么> |
-```
-
-按主题选择最贴切的图，但优先用多个短小 ASCII 图代替长文字：
-
-```text
-结构图：
-[系统]
-  |
-  +-- [部件 A]
-  +-- [部件 B]
-
-数据流图：
-[输入] -> [处理] -> [结果]
-
-调用流图：
-[用户动作] -> [入口] -> [服务] -> [回应]
-
-状态变化图：
-[等待] -> [进行中] -> [完成]
-```
-
-每份图解至少包含以下四节：
-
-1. `## 先看全图`：一个能说清“谁和谁有关”的 ASCII 图。
-2. `## 一步一步看`：按箭头顺序解释。流程、数据或调用会移动时，再给对应的 ASCII 图。
-3. `## 术语小词典`：只保留读图必需的词。每个词先用日常语言解释，再给它的专业名字。例如：`临时便签（缓存）`，意思是“把常用结果先放在手边，下一次不用重新找”。
-4. `## 你现在能复述什么`：用短句归纳“它是什么、为什么需要它、它怎样流动或被调用”。
-
-图中的方框名称使用普通名词和动词，不用缩写；箭头必须有方向。一个图只讲一个问题。确有边界、失败或例外时，单独画一张小图说明，不把它塞进主图。
-
-## 解释依据
-
-在原四节中区分已验证事实、可定位理由、教学类比与未知；需要时用原 ASCII 图展示失败和恢复方向。旧 Spec 与实现不一致时说明差异；新理解追加编号，不改旧文件，不增加其他格式产物。