@namewta/speculo 2.0.1 → 2.0.2

package/template/workflows/specdev/specdev-i-implement/assets/evidence-template.md

@@ -1,6 +1,6 @@
 # Evidence: <Ticket ID> — <Ticket title>
 
-本模板按 Goal Plan 的 workspace/integration 策略记录实际验证环境；不适用的环境明确写 `not-applicable`，不伪造 source、candidate 或 result 链。Direct Spec 使用本模板时写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`，以实施前基线和最终 checkpoint 代替 Ticket 集成链。
+本模板按有效计划或当前 I 的 workspace/integration 策略记录实际验证环境；不适用的环境明确写 `not-applicable`，不伪造 source、candidate 或 result 链。Direct Spec 使用本模板时写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`，current 使用实施前基线和最终 checkpoint；required 保存真实 change 工作区集成链，不填 Ticket ID。
 
 - **Change：** `<change>`
 - **Ticket：** `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`
@@ -17,6 +17,7 @@
 
 ## 2. Lead Dispatch And Candidate Return
 
+- **执行选择与来源：** 当前宿主正常执行（mode: lead，App/CLI 等）/ 显式 CLI 交互或调用 / Herdr / 其他已选方式；current / required；实际用户选择或有效计划来源，无 Goal 时默认串行、集成尝试上限 3
 - **Implementation owner：** Lead / `<agent/provider>`
 - **Dispatch Packet/checkpoint：** Lead direct / `<locator + immutable checkpoint>`
 - **允许动作：** worktree changes / implementation commit / ...
@@ -42,11 +43,11 @@
 |---|---|---|---|
 | AC-... | ... | 测试、日志或人工检查摘要 | pass / fail / not-run |
 
-每个 Ticket 验收项恰好落到一行。
+每个 Ticket 验收项或 Direct Spec AC 恰好落到一行。
 
 ## 5. Workspace Verification
 
-按 Goal Plan 记录 current workspace 或 source worktree 检查，并注明运行环境。
+按有效计划或当前 I 执行合同 记录 current workspace 或 source worktree 检查，并注明运行环境。
 
 | 命令或步骤 | 运行环境 | 结果 | 摘要 |
 |---|---|---|---|
@@ -54,7 +55,7 @@
 
 - **失败后修复与重跑：** 无 / ...
 - **未运行检查：** 无 / 原因与风险
-- **E2E：** 按 Goal Plan 的 E2E disposition 记录；未在本环境运行时说明 owner 与原因
+- **E2E：** 按有效计划或当前 I 执行合同 的 E2E disposition 记录；未在本环境运行时说明 owner 与原因
 
 ## 6. 双轴审查
 
@@ -76,7 +77,7 @@
 
 ## 7. Integration Verification
 
-按 Goal Plan 记录 direct-parent 或 parent-candidate 集成；未采用的字段写 `null` 或 `not-applicable`。
+按有效计划或当前 I 执行合同 记录 direct-parent 或 parent-candidate 集成；未采用的字段写 `null` 或 `not-applicable`。
 
 | 项目 | 结果 |
 |---|---|
@@ -146,7 +147,7 @@
 
 ## Workspace Execution Record
 
-仅独立实现 Ticket 真正开始时，在本节保存该票原 workspace 执行字段的唯一 JSON object：base_sha、parent_branch、workspace/implementation/integration owner、workspace_ref、branch、source_checkpoint、status、integration 的 candidate/result/验证/E2E/attempts 等。由实际操作生成，不能预填空对象；current/direct-parent 与 required/source/parent-candidate 仍各按原合同验证。其他表格只说明和导航这些事实，不复制第二套可写状态；Direct Spec 不创建该票记录。
+独立 Ticket 或 required Direct Spec 真正开始时，在本节保存本单元 workspace 执行字段的唯一 JSON object：base_sha、parent_branch、workspace/implementation/integration owner、workspace_ref、branch、source_checkpoint、status、integration 的 candidate/result/验证/E2E/attempts 等。由实际操作生成，不能预填空对象；current/direct-parent 与 required/source/parent-candidate 仍各按原合同验证。其他表格只说明和导航这些事实，不复制第二套可写状态；Direct Spec 使用 purpose=direct-spec、change 和 integration_attempt_limit 代替 ticket_id；required 必须记录，current 可保留原 checkpoint 证据不造集成记录。字段和生成步骤见 <Path>{roots.workflows}/specdev/common/skills/dev-worktree/references/create.md</Path>。无票不创建 Ticket/Map/Goal，历史 current 证据不回填。
 
 ## Acceptance Verification
 

package/template/workflows/specdev/specdev-i-implement/references/execution-preflight.md

@@ -1,5 +1,7 @@
 # Execution Preflight
 
+先按 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path> 解析有效执行选择；用户选择 Herdr 时先完成其项目 Skill 接入与环境检查。无 Goal 不构成阻塞，不能用另一个 CLI 或工作区替换用户固定选择。
+
 ## Ticket 硬检查
 
 - [ ] Ticket frontmatter 可解析，`ready: true`，`status: ready`。
@@ -22,13 +24,15 @@
 
 ## Direct Spec 硬检查
 
-- [ ] 用户明确批准 Direct Spec；单一行为、局部、低风险、可逆且无需并行/Ticket DAG。
-- [ ] current workspace 只有一个项目与 SpecDev 写入 owner。
+- [ ] 用户已授权按当前规格实现；独立 Spec 已就绪（ready_for_tickets=true），目标、行为、风险门与验收完整；README 替代规格时仍满足轻量边界。不要求单一行为或低风险，确需独立调度/依赖 DAG 才拆票。
+- [ ] current 工作副本只有一个代码 writer（Lead 或获派执行者）；required 以整个 change 为单元，真实 workspace、Lead/实现/integration owner 及路径唯一。SpecDev 正式工件只由 Lead 写入。
 - [ ] 目标、IN/OUT、可写范围、不变量、验证与验收完整。
 - [ ] Direct Spec 涉及 UI 时读取批准 DESIGN 并冻结版本、页面/状态与原型摘要；无 UI 不要求此项。
 - [ ] 实施前 Git checkpoint、dirty 状态和现有用户改动已记录，不覆盖无关改动。
-- [ ] 非 E2E、适用回归与 E2E 验证环境可执行；E2E owner 固定为 Lead。
-- [ ] implementation commit 授权状态明确；未授权时不提交，并在轻量合同与 Evidence 中记录交付状态。
+- [ ] 已读取命中的项目 Skill；非 E2E、适用回归与 E2E 环境可执行，E2E owner 为 Lead。required 的 source 只运行非 E2E，候选检查在 parent-candidate。
+- [ ] implementation commit 授权状态明确；current 未授权时不提交，在原 Evidence 记录交付状态；required 创建前必须有实现 commit 和 local candidate integration/父分支更新授权。
+
+- [ ] required 的 Direct Spec Execution Record 使用 purpose/change 身份、真实 source/candidate locator 和正整数 integration_attempt_limit；恢复时原记录与 Git 一致，不存在未处置 Ticket 执行。
 
 ## 失效分类
 

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

@@ -1,7 +1,7 @@
 # 实现
 
 
-本 work 保留模块设计检查、design-it-twice、TDD 红绿循环、双轴审查和证据治理。Ticket 模式按子 Goal Plan 或父 Implementation Plan 的 `ticket_workspace_policy` 选择 current workspace 串行直接父分支或独立 worktree candidate-merge；Lead 根据实际情况自行实现或动态派单。
+本 work 保留模块设计检查、design-it-twice、TDD 红绿循环、双轴审查和证据治理。Ticket 与 Direct Spec 均按 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path> 独立选择执行方式和工作区；有有效计划时继承其 workspace/Gate，无 Goal 由 I 在原 Evidence 承接。Lead 默认按当前宿主正常执行；明确指定 CLI 交互、Herdr 等方式时按选择执行。
 
 若当前 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，不能放宽或冲突。
 
@@ -10,11 +10,11 @@
 
 ### Ticket 模式（默认）
 
-使用下节规定的输入顺序。父 Implementation Plan 存在时采用其 Lead、workspace/integration 与全局 Gate，即使子 Goal Plan 不存在；两者都有时必须一致。没有父计划沿用子计划；两者都没有时当前主会话作为 Lead，按 Direct Spec 的轻量边界执行，不猜测 worktree 策略。
+使用下节规定的输入顺序。父 Implementation Plan 存在时采用其 Lead、workspace/integration 与全局 Gate，即使子 Goal Plan 不存在；两者都有时必须一致。没有父计划沿用子计划；两者都没有时当前主会话作为 Lead，使用当前票完整合同及共用执行策略，不降级为轻量 Spec，不要求补 Goal。
 
 ### Direct Spec 模式
 
-只有极小、局部、单一行为、低风险、可逆且无需 Ticket DAG 的工作，才可在用户批准后直接基于 Spec/ADR/CONTEXT 在 current workspace 执行。先确认目标、IN/OUT、唯一写入 owner、可写范围、关键不变量、验证和验收。出现公共 API/schema、迁移、安全、高风险、多个行为或并行需求时返回 T-tickets。
+完整获批 Spec 可以直接实现，包括多个行为或高风险范围；先核对目标、IN/OUT、唯一写入 owner、可写范围、关键不变量、全部 AC、验证及适用批准/恢复门。可以选择 current 或 required，并使用原生能力或 Herdr。独立调度、依赖 DAG、逐票追踪确有需要或用户明确要求时才返回 T-tickets。README 规格替代仍仅适用于轻量任务。
 
 ### Documentation 分支
 
@@ -34,7 +34,7 @@ Ticket 模式必须按以下顺序读取：
 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 模式必须读取用户对轻量执行合同和直接实现的明确批准。
+矩阵是发布时确认的最低必读集合，不是 allowlist。项目 Agent 指令或实际实现范围触发新的项目 Skill 时，先读取该 Skill、停止项目写入，由 Lead 更新 Tickets Map 并重新运行 tickets 校验后恢复。Direct Spec 模式读取同范围直接实现的实际授权、唯一规格与命中的项目 Skill；完整 Spec 的实现不要求补 Ticket/Map/Goal。
 
 按存在情况读取：
 
@@ -45,7 +45,7 @@ Ticket 模式必须按以下顺序读取：
 - 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
 - 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
 
-UI 范围必读 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 和 <Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path> 的批准版本；Ticket design_ref 与所需页面/AC 一致，Direct Spec 在轻量合同中保存等价绑定。无 UI 影响时不要求 DESIGN。
+UI 范围必读 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 和 <Path>{roots.state}/specdev/changes/{change}/DESIGN.md</Path> 的批准版本；Ticket design_ref 与所需页面/AC 一致，Direct Spec 在原规格/Evidence 中保存等价绑定。无 UI 影响时不要求 DESIGN。
 
 永久目录可以为空，静默继续。当前 ADR/CONTEXT 缺失且实施需要对应决定时，返回 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>`；Spec、Ticket 或 Goal Plan 与代码事实冲突时按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 返回真正 owner，不在实现中覆盖。
 
@@ -59,22 +59,22 @@ Git 已处于 merge/rebase 冲突时，先加载 `<Path>{roots.workflows}/specde
 
 预检参考拥有 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 状态。
+通过预检后：`required` 实现以 `purpose=ticket|direct-spec, 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 required 记录真实 change worktree 到原 direct-spec Evidence，不创建 Ticket 状态。
 
 **完成标准**：真实 workspace、基线、唯一 owners 和授权与预检一致；代码使合同失效时停止并返回上游 owner，current Ticket 严格串行。
 
 ### 2. Lead 决定自行实现或动态派单
 
-Ticket 模式下，Lead 根据 Ticket 独立性、路径冲突、上下文、风险和平台能力决定。派单时读取 `<Path>{roots.references}/coordination/task-brief.md</Path>`。`current` 模式仍可派遣一个 实现执行者 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 实现执行者 绑定独立 Ticket worktree。Direct Spec 模式由 Lead 作为 current workspace 唯一写入 owner，不派遣 实现执行者 写入。
+两种输入模式下，Lead 根据独立性、路径冲突、上下文、风险、用户选择和平台能力决定；原生 subagent/team 属于宿主能力。派单时读取 `<Path>{roots.references}/coordination/task-brief.md</Path>`。`current` 模式仍可派遣一个 实现执行者 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 实现执行者 绑定独立 Ticket worktree。Direct Spec 同样可以交接实现：提供获批 Spec、项目 Skill、当前工作区、路径和验收，current 只允许一个代码 writer，required 绑定本 change 的唯一 source worktree。
 
 - 实现执行者 同时取适用子 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 返回；
+- implementation Packet 绑定唯一执行 workspace、checkpoint、路径、非 E2E 检查与已授权 commit 返回；Ticket 提供 Map/项目 Skill/本票，Direct Spec 提供完整规格/项目 Skill/AC，不补造票；
 - 任务执行者 不写 SpecDev 工件、Evidence、父分支或 E2E 结果；
 - Lead 自行实现时仍遵循相同 worktree、commit 与返回事实合同。
 
-**完成标准**：current 模式只有一个 implementation owner 写当前 workspace；required 模式只有一个 owner 写当前 Ticket worktree；Direct Spec 只有 Lead 写 current workspace；所有 SpecDev 写入仍由 Lead 拥有。
+**完成标准**：current 模式只有一个 implementation owner 写当前 workspace；required 模式只有一个 owner 写当前 Ticket worktree；Direct Spec 同样只有一个代码 writer；所有 SpecDev 写入仍由 Lead 拥有。
 
 ### 3. 设计检查
 
@@ -106,7 +106,7 @@ UI 的模板、视觉语言、共享组件及交互规则由批准 DESIGN 锁定
 
 ### 5. 实现检查、commit 与 Lead 接收
 
-Ticket 模式的 implementation owner 按 Goal Plan 策略在当前 workspace 或来源 worktree：
+Ticket 模式的 implementation owner 按有效计划或当前 I 执行合同 策略在当前 workspace 或来源 worktree：
 
 - 运行 Ticket 要求的单元、组件、静态、类型、lint/build 等非 E2E 检查；
 - 审计 writable/shared/read-only 路径和新/既有/环境失败；
@@ -115,13 +115,13 @@ Ticket 模式的 implementation owner 按 Goal Plan 策略在当前 workspace
 
 Ticket 模式中，Lead 读取 `<Path>{roots.references}/coordination/result-and-recovery.md</Path>`，重读 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 状态、实际路径、命令结果、未运行项和恢复条件。
+Direct Spec 的 implementation owner 在所选工作区运行规格要求的非 E2E 检查，审计获批写集，在已授权时创建引用 change 的非空 commit；Lead 按共享返回合同重读候选。required 必须形成 source commit，current 未授权提交则保留真实 checkpoint/dirty 交付事实。无需改动时记录事实并取消直接实现，不创建 empty commit。记录实际路径、命令结果、未运行项和恢复条件。
 
-**完成标准**：required 模式 Ticket worktree clean 且 `source_checkpoint` 精确等于 branch tip；current 模式 workspace clean 且 Ticket `result_sha` 精确等于父分支上的 implementation commit；或 Direct Spec 的 current workspace checkpoint、路径和轻量合同一致。
+**完成标准**：required 模式 Ticket worktree clean 且 `source_checkpoint` 精确等于 branch tip；current 模式 workspace clean 且 Ticket `result_sha` 精确等于父分支上的 implementation commit；或 Direct Spec 的所选 workspace、checkpoint、路径和获批规格一致；required 来源必须 clean 且 source checkpoint 等于 branch tip。
 
 ### 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 为固定点：
+调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`。required Ticket 以 `base_sha` 与 `source_checkpoint` 为固定点；current Ticket 以 Ticket 实施前基线与 implementation commit 为固定点；Direct Spec 以实施前基线与所选 workspace 最终 checkpoint 为固定点：
 
 - 标准轴：正确性、模块设计、错误、安全、性能、并发、资源、测试与可维护性；
 - 规范轴：Spec/Ticket IN/OUT、实现合同、路径所有权、验证矩阵与 Goal Gate；UI 还包括已批准 DESIGN、固定基线和页面/状态规则。
@@ -132,17 +132,17 @@ Direct Spec 模式由 Lead 在 current workspace 运行轻量合同要求的定
 
 ### 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。
+`required` Ticket/Direct Spec 模式中，Lead 以相应 `purpose=ticket|direct-spec, 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 和父分支推进。
+`current` Ticket 模式跳过 source worktree、candidate merge 和 candidate checkout。Lead 在当前 workspace 运行 Ticket 要求的适用集成/回归与 E2E，记录运行环境、命令、退出码和摘要；E2E 不得派给其他 agent。失败时不声明完成，保留 Ticket commit、父 HEAD 和恢复条件。全部通过后重读父 HEAD/tree 并记录 `result_sha`。Direct Spec current 同样跳过 source/candidate 与父分支推进；Direct Spec required 完整执行上方候选集成流程。无 Goal 时采用原 Evidence 记录的尝试上限。
 
 无论失败发生在 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/specdev-i-implement/assets/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 字段。
+Lead 使用 `<Path>{roots.workflows}/specdev/specdev-i-implement/assets/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 使用实施前基线与所选 workspace 最终 checkpoint；required 追加真实 Workspace Execution Record 与 source/candidate/result 链，current 未发生集成不伪造这些字段，两者都不填 Ticket ID。
 
 UI Evidence 必须包含 `## Design Conformance`，列出 design_ref 的准确 digest、pages 与 acceptance ID，逐项连接实现位置、真实浏览器任务、桌面/窄屏截图和状态观察。对照批准原型说明允许的实现差异；未知与未通过项保持未验证，不能仅凭原型证据完成实施。
 
@@ -163,7 +163,7 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 ### 9. 返回
 
-Ticket 模式返回 Ticket 状态与 README Outcome、Evidence 完整路径、workspace locator、implementation/source、适用 candidate/result SHA、父分支、E2E disposition、适用 Lead 复盘决定、未验证项和下一路由。Direct Spec 返回 README Outcome、`<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`、current workspace、实施前/最终 checkpoint、适用 E2E 和下一路由。push、PR、remote merge、deploy、migration、生产动作及来源 branch/worktree cleanup 只在独立授权时执行。
+Ticket 模式返回 Ticket 状态与 README Outcome、Evidence 完整路径、workspace locator、implementation/source、适用 candidate/result SHA、父分支、E2E disposition、适用 Lead 复盘决定、未验证项和下一路由。Direct Spec 返回 README Outcome、`<Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>`、实际 workspace、实施前/最终 checkpoint、适用 E2E 和下一路由。push、PR、remote merge、deploy、migration、生产动作及来源 branch/worktree cleanup 只在独立授权时执行。
 
 ## 计划型票扩展
 

package/template/workflows/specdev/specdev-i-init-setup/SKILL.md

@@ -28,4 +28,4 @@ metadata:
 
 ## 可选项目编排选择
 
-只有用户要求持久化编排偏好时，依据 <Path>{roots.references}/coordination/project-facts.schema.json</Path> 写入 <Path>{roots.state}/coordination/project.json</Path>，先读 <Path>{roots.references}/coordination/coordination-contract.md</Path>。配置缺失默认 Lead；不探测、安装或要求外部工具，选择不是授权凭证。只读调用不生成配置。
+只有用户要求持久化编排偏好时，依据 <Path>{roots.references}/coordination/project-facts.schema.json</Path> 写入 <Path>{roots.state}/coordination/project.json</Path>，先读 <Path>{roots.references}/coordination/coordination-contract.md</Path>。未明确指定时按当前宿主正常执行（mode: lead），App、CLI 等均可；不探测、安装或要求外部工具，选择不是授权凭证。只读调用不生成配置。

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

@@ -0,0 +1,35 @@
+---
+name: specdev-l-learn
+description: "围绕需求参考、本项目代码、已有 change 或外部项目与文章开展学习，讲清功能、实现思路和运行机制，并用面向零专业背景读者的 Markdown 与 ASCII 图解记录理解。"
+metadata:
+  speculo-kind: work-skill
+  speculo-id: specdev/learn
+  speculo-domain: specdev
+  speculo-contract-version: "2"
+---
+
+# 学习与图解
+
+激活后读取 `<Path>{roots.workflows}/specdev/common/rules/domain-runtime.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`。从用户想理解的对象和问题开始；学习可以发生在需求实现前、开发中或实现后。
+
+## 执行
+
+1. **确定学习问题**：使用 `$ARGUMENTS` 或用户最新请求，明确想学的对象、本轮问题及已有背景；缺少对象或问题时只补问缺失项。默认读者是刚入大学、零专业背景的新生。带着需求来时，先讲参考对象解决什么问题、具有什么功能、为什么这样实现。
+2. **定位依据**：按问题读取本项目代码、测试、文档，或外部项目源码、官方说明、文章与论文；关联 change 时才读取相关 Source、Spec、Ticket、Evidence 和 review。需求明确但未指定参考时，围绕问题检索可靠的一手资料。记录来源文件/章节/URL 及适用版本；资料无法访问或关键事实缺失时说明缺口，停止依赖它的结论，继续有依据的部分。
+3. **确定保存位置**：问题与必要资料明确后，读取 `<Path>{roots.workflows}/specdev/specdev-l-learn/references/learning-change.md</Path>`。用户指定未归档 change 就使用其 learning 目录；同轮续学复用已选对象；未指定则新建承载本轮学习的轻量 change，不自动选择其他现有 change。指定对象不存在或身份冲突时先消歧，不静默另建。
+4. **讲解与保存**：读取 `<Path>{roots.workflows}/specdev/specdev-l-learn/references/lesson-format.md</Path>`。先画 ASCII 全图，再按实际关系画短小结构、数据、调用或状态图；短句解释箭头，术语先日常解释再给专业名字。覆盖“它是什么、为什么需要、怎样流动或被调用”，按追问继续拆解；有当前需求时说明可借鉴之处和适用条件，不把参考思路写成已批准的实现方案。
+5. **追加与交付**：按格式合同原子创建 `<Path>{roots.state}/specdev/changes/{change}/learning/{number}_{topic}.md</Path>`，再更新 `<Path>{roots.state}/specdev/changes/{change}/learning/index.md</Path>` 并回读。重讲同主题仍新增编号，保留旧文件、原顺序和全部历史行；部分失败先恢复已有结果。产物仅为纯 Markdown/ASCII，不写 `<Path>{roots.state}/learning/</Path>`、生产代码、永久知识或远程系统。
+
+## 事实、理由与解释
+
+区分源码事实、文章作者的观点、实际测试验证、可定位设计理由、教学类比、推断与未知。未运行测试就不宣称运行验证；旧计划、文章和实际实现冲突时明确各自版本与差异。类比帮助理解，不能代替证据；参考的可借鉴点不代表已经决定在本项目采用。
+
+## 验收与恢复
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --stage learn <Path>{roots.state}/specdev/changes/{change}</Path>
+```
+
+图解覆盖约定问题、引用可追溯，符合四节、至少一个 ASCII 图和连续编号；索引指向真实文件且主题/简介一致，箭头方向与依据相符。验证通过后按保存位置合同完成本轮学习专用 change，或仅追加已有 change 的导航；学习交付不证明用户已经掌握，也不改变已有开发 change 的完成状态。
+
+返回新图解、索引和 README 完整路径、验证结果及未解问题；失败保留恢复位置与原因。默认返回用户继续提问。用户另行提出开发需求时，需求澄清交 `<Path>{roots.workflows}/specdev/specdev-g-grill-with-docs/SKILL.md</Path>`，多 change 探索交 `<Path>{roots.workflows}/specdev/specdev-w-wayfinder/SKILL.md</Path>`，外部行为明确时交 `<Path>{roots.workflows}/specdev/specdev-s-spec/SKILL.md</Path>`，由下一 Work 核对范围与授权；不自动启动实现。系统课程、作业和周期复习由 Learning workflow 负责，本 Work 不改其状态。

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

@@ -0,0 +1,23 @@
+# 学习载体与完成
+
+确定保存位置、恢复续学或交付时读取。学习对象可以是代码、需求参考、文章或 change；change 承载学习记录，不要求先有开发产物。
+
+## 选择与恢复
+
+- 用户指定未归档 change：核对身份和原 README，写入其 learning 目录。即使它已 completed/cancelled，也只追加学习材料和必要导航，不改变原 Outcome、范围、验收、owner 或开发进度。
+- 同轮继续追问：从原 README 导航与学习索引恢复已选 change；不因每条消息未重复名称就另建，也不因学习完成而重新打开状态。
+- 独立请求未指定 change：问题与必要资料明确后，按 `<Path>{roots.workflows}/specdev/common/rules/workflow-state-and-lifecycle.md</Path>` 新建 `YYYY-MM-DD-topic[-NN]`，检查活动与历史重名；不自动接入唯一活动 change。指定对象不存在、身份冲突、旧活动协议或未知 schema 时保留诊断，停止相关写入。
+- 指定已归档对象：只读原件，在新的学习 change 中引用原 locator，不向封存对象追加文件；旧历史沿原只读定位协议访问。
+
+新建时采用 `<Path>{roots.workflows}/specdev/specdev-i-init-setup/assets/change-readme-template.md</Path>` 的轻量结构，原子创建 `<Path>{roots.state}/specdev/changes/{change}/README.md</Path>`，初始为 `Outcome: active`。scope 只记录学习对象、来源、本轮问题及获准的学习写集；acceptance 覆盖约定问题、来源与事实区分、图解和索引有效性；verification 在实际验证后填写。只创建真实需要的 README 和 learning 产物，无需 Spec、Ticket、Goal 或实现 Evidence。
+
+已有 change 的写集限于 `<Path>{roots.state}/specdev/changes/{change}/learning/</Path>` 与 README 中必要的学习导航；新建学习 change 的 L 同时负责其轻量验收与结束。写前核对原 owner、相关 pending transaction、lock 和 recovery evidence。冲突只阻塞重叠写入，不把资料阅读当作接管开发 owner 的依据。
+
+## 本轮交付与结束
+
+1. 完成图解、索引和事实回读，执行 `node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --stage learn <Path>{roots.state}/specdev/changes/{change}</Path>`；缺资料影响约定问题、图解缺失或索引不一致时，不标记本轮交付完成。
+2. 本 Work 为本轮新建的学习 change，或明确恢复的尚未完成学习专用 change：确认其 scope 仍仅为学习，没有新增开发任务，再读取 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` 和 `<Path>{roots.workflows}/specdev/specdev-i-init-setup/references/change-record-examples.md</Path>`。L 是本轮非实现验收 owner，记录真实会话依据、逐 AC 的 Method/Source/Observed/Result，以及校验命令和实际退出码；证据指向独立观察段或真实图解，不以 Outcome 自证。
+3. 全部学习验收满足后，核对 README 原字节并由原 owner 原子更新唯一 `Outcome: completed`，再运行 `node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --stage complete <Path>{roots.state}/specdev/changes/{change}</Path>` 并回读。完成仅表示本轮材料交付；不等待掌握测验，不宣称用户已理解，不自动归档。失败保留证据与原恢复位置，由原 owner 修正不满足完成门的结论，不能报告成功。
+4. 指定的开发 change 或已经 completed/cancelled 的对象，只验证新增学习产物与必要导航，不修改原范围、验收或 Outcome。学习产物不能代替开发验收；已经完成的学习 change 续问也沿用此追加分支。
+
+需要保存接续时只使用原 README/索引，不新增学习 status 镜像。学习后产生的新开发请求由被激活的下一 Work 重新确认范围和载体；本 Work 不把学习目标自动改成实现目标。

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

@@ -0,0 +1,61 @@
+# 学习图解格式
+
+写图解与分配编号时读取；这是产物格式权威，不是另一套学习状态。
+
+## 输出格式
+
+在选定或本轮新建 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、图片链接或浏览器专属交互；文字来源链接可以使用普通 Markdown 链接。
+
+`<number>` 是两位起始、持续递增的序号：先核对索引与同目录真实图解，恢复未闭合的追加，再取两者最大序号加一，因此第一次为 `01`，下一次为 `02`，超过 `99` 继续 `100`；不为旧文件重编号。`<topic>` 是主题的简短、可作文件名的标签，可使用中文、字母、数字、`-` 或 `_`，但不能含空格、`/`、`\\` 或 `..`。同主题再次解释也创建新编号文件，同一编号不能分配给多个文件。
+
+索引是唯一目录，使用下列 Markdown 表格；每新增一份图解就在表末追加一行，并保留既有行。文件列只写同目录的文件名：
+
+```markdown
+# 学习图解索引
+
+| 编号 | 文件 | 主题 | 简介 |
+| --- | --- | --- | --- |
+| 01 | 01_<topic>.md | <主题> | <一句话说明它解释什么> |
+```
+
+已有 `# Change 学习图解索引` 属于历史产物格式，保持原题头和历史行，仍可追加；新索引使用上面的标题。
+
+## 追加与部分失败恢复
+
+图解文件使用无覆盖的原子创建，索引用写前原字节检查和原子替换；两次写入不是整体事务。先保存图解，后追加索引，再回读两者。目标已存在或索引已被其他 writer 改动时停止重叠写入，保留已落地文件，不覆盖、不删历史、不抢占编号。
+
+恢复先核对原会话和真实文件：本轮完整图解已创建但未登记时，验证正文后补入原编号行；索引已经登记则直接验证，不重复追加或重新生成。出现缺文件、断号、重复编号、不完整正文或未知 owner 的孤立文件时，报告冲突与恢复位置，由原 writer 处理后再分配下一号。不能靠重新编号或跳过旧记录掩盖失败。
+
+按主题选择最贴切的图，但优先用多个短小 ASCII 图代替长文字：
+
+```text
+结构图：
+[系统]
+  |
+  +-- [部件 A]
+  +-- [部件 B]
+
+数据流图：
+[输入] -> [处理] -> [结果]
+
+调用流图：
+[用户动作] -> [入口] -> [服务] -> [回应]
+
+状态变化图：
+[等待] -> [进行中] -> [完成]
+```
+
+每份图解至少包含以下四节：
+
+1. `## 先看全图`：一个能说清“谁和谁有关”的 ASCII 图。
+2. `## 一步一步看`：按箭头顺序解释。流程、数据或调用会移动时，再给对应的 ASCII 图。
+3. `## 术语小词典`：只保留读图必需的词。每个词先用日常语言解释，再给它的专业名字。例如：`临时便签（缓存）`，意思是“把常用结果先放在手边，下一次不用重新找”。
+4. `## 你现在能复述什么`：用短句归纳“它是什么、为什么需要它、它怎样流动或被调用”，列出仍未讲清的问题；这是复述提示，不是用户已经掌握的判定。
+
+图中的方框名称使用普通名词和动词，不用缩写；箭头必须有方向。一个图只讲一个问题。确有边界、失败或例外时，单独画一张小图说明，不把它塞进主图。
+
+## 解释依据
+
+在原四节中就近引用文件、章节或 URL，记录适用版本/修订；区分源码事实、作者观点、实际测试验证、可定位理由、类比、推断与未知。没有运行测试不写“已通过”，外部文章的说法不自动成为本项目事实。旧 Spec、文章与实现不一致时说明差异；需要时用小图展示真实失败与恢复方向，不编造事故。
+
+带着需求学习时，在“一步一步看”中说明参考思路解决的问题、可借鉴部分和适用条件；把本项目尚未决定的取舍留作问题，不生成实施计划或授权结论。新理解追加编号，不改旧文件，不增加其他格式产物。

package/template/workflows/specdev/specdev-p-goal-plan/SKILL.md

@@ -64,8 +64,8 @@ node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --ma
 
 ## 编排与执行上下文
 
-Lead 自行执行或当前阶段需要交接任务时，读取 <Path>{roots.references}/coordination/coordination-contract.md</Path>，按用户指定的 Lead、Orca、Herdr 或无头 CLI 方式操作。只读取所选工具的当前指南；不固定编程工具或模型。
+进入实现或审查时读取 <Path>{roots.references}/coordination/coordination-contract.md</Path>；未明确指定时按当前宿主正常执行，App、CLI 等均可，subagent/agent team 属于宿主能力。明确指定 CLI 交互、Herdr 等方式时按选择执行并展开对应参考；编排与 current/worktree 独立，已有授权和选择直接复用。只读取所选工具的当前指南，不固定工具或模型。
 
-`lead` 上下文维护原业务状态和 Evidence；`task` 上下文只处理 Lead 指定目标和阶段，执行同一方法并返回候选、findings、检查和未验证项，不修改正式 Ticket、Map、Goal、Evidence，不递归启动 Goal 或交接其他任务。未曝光到宿主列表不影响读取真实入口。
+`lead` 上下文维护原业务状态和 Evidence；`task` 上下文只处理 Lead 指定目标和阶段，执行同一方法并返回候选、findings、检查和未验证项，不修改正式 Ticket、Map、Goal、Evidence，不递归启动 Goal 或擅自跨 CLI 派单；宿主原生协作遵守原写集和单 writer 约束。未曝光到宿主列表不影响读取真实入口。
 
 P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。独立审查 required 时不能以 Lead 自审替代。

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

@@ -79,6 +79,8 @@ ready_for_execution: false
 
 ### Lead Orchestration
 
+执行方式独立于下方工作区策略：默认按当前宿主正常执行（mode: lead），App、CLI 等均可，subagent/team 属于宿主能力；明确指定 CLI 交互、Herdr 等方式才按共享编排合同接入。记录本次选择与来源，不逐任务重新询问。
+
 | 项目 | 决定 | 事实依据 |
 |---|---|---|
 | Lead | `<owner-or-session-locator>` | 唯一 SpecDev 状态、Evidence 与父分支 owner |

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

@@ -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-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

@@ -111,7 +111,7 @@ shared_path_owners: []
 
 不适用的关键风险类别必须写“不适用：原因”。
 
-- **Workspace checks：** 按 Goal Plan 在 current workspace 或 source worktree 运行单元、组件、静态、类型、lint/build 等适用非 E2E 检查。
+- **Workspace checks：** 按有效计划或当前 I 执行合同 在 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 和父分支包含关系。
@@ -135,7 +135,7 @@ E2E 由实际跨边界行为与风险决定，不限于 UI；required 模式不
 - [ ] 实现开始前已完整读取 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 已记录。
+- [ ] Ticket 已按有效计划或当前 I 执行合同 策略形成非空 implementation/source commit，direct-parent 或 candidate 验证通过且父分支 result 已记录。
 - [ ] E2E disposition 已执行；required 模式 E2E 在 parent-candidate、current 模式在 current workspace 由 Lead 完成。
 - [ ] 未发生未批准的范围、契约或发布偏差。
 - [ ] Ticket 状态有本票 Evidence 支撑；Tickets Map 的导航、依赖和合同覆盖仍有效，不复制本票进度。

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

@@ -68,7 +68,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

@@ -117,7 +117,7 @@ UI 范围同时读取 <Path>{roots.workflows}/specdev/common/rules/design-contra
 - 有序执行路线和安全落点；
 - expected、writable、read-only、shared 路径；
 - 正常、失败和回归验证矩阵；
-- 每个 Ticket 按 Goal Plan 的 workspace 策略定义 current-workspace/direct-parent 或 source-worktree/parent-candidate 检查，以及按实际跨边界风险判定的 E2E disposition；
+- 每个 Ticket 按有效计划或当前 I 执行合同 的 workspace 策略定义 current-workspace/direct-parent 或 source-worktree/parent-candidate 检查，以及按实际跨边界风险判定的 E2E disposition；
 - 每个实现 Ticket 的 implementation commit 与对应父分支完成条件；仅 required 模式创建独立 worktree；
 - Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点；
 - 可判定验收标准。

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

@@ -20,7 +20,7 @@
 - [ ] 每个 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。
+- [ ] 按有效计划或当前 I 执行合同 策略定义 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。
 - [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
 - [ ] 单个全新上下文能够完成；否则已拆分。

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 原有开发完成状态。