@namewta/speculo 2.0.1 → 2.0.3

package/template/workflows/specdev/manifest.json

@@ -82,11 +82,9 @@
     },
     {
       "id": "learn",
-      "after": [
-        "verify"
-      ],
+      "after": [],
       "inputs": [
-        "verification"
+        "learning-request"
       ],
       "outputs": [
         "learning"
@@ -103,7 +101,7 @@
     "specdev-g-grill-with-docs/SKILL.md",
     "specdev-i-implement/SKILL.md",
     "specdev-i-init-setup/SKILL.md",
-    "specdev-l-learn-change/SKILL.md",
+    "specdev-l-learn/SKILL.md",
     "specdev-p-goal-plan/SKILL.md",
     "specdev-p-prototype/SKILL.md",
     "specdev-r-retro/SKILL.md",
@@ -134,7 +132,7 @@
     "specdev-d-diagnose-bugs/SKILL.md": [],
     "specdev-g-grill-with-docs/SKILL.md": [],
     "specdev-i-init-setup/SKILL.md": [],
-    "specdev-l-learn-change/SKILL.md": [],
+    "specdev-l-learn/SKILL.md": [],
     "specdev-p-prototype/SKILL.md": [],
     "specdev-r-retro/SKILL.md": [],
     "specdev-r-review-architecture/SKILL.md": [],

package/template/workflows/specdev/specdev-c-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specdev-c-code-review
-description: "按用户指定文件或 PR、单 commit、区间、基线冻结真实审查范围，执行隔离的标准轴与规范轴审查；有效空差异诚实返回，不实施修复或发布。"
+description: "按用户指定文件或 PR、单 commit、区间、基线冻结真实审查范围，派遣未参与实现的 Agent 执行标准轴与规范轴审查；有效空差异诚实返回，不实施修复或发布。"
 metadata:
   speculo-kind: work-skill
   speculo-id: specdev/code-review
@@ -31,7 +31,7 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 1. **解析固定点**：先选择 baseline（共同祖先到 head）、range（两个指定端点）、commit（指定提交与其父）或 pr（远程 PR diff）。PR 先通过 <Path>{roots.workflows}/specdev/specdev-t-triage/references/remote-operations.md</Path> 的 pr-read 获得完整 base/head SHA。调用 <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> 的 `--review-scope --repo <project-root> --mode <mode>`；端点模式传 --base/--head，commit 传 --commit，多父提交明确 --parent。此只读工具冻结本地对象，不抓取、不写状态；根提交没有现有 CR 的 committed baseline 时明确报告限制，不编造父提交。
 2. **冻结输入**：保存工具返回的实际 diff argv、fixed_point/head、diff_sha256、路径与 commit log，不把单 commit 扩大到当前 HEAD。引用无效则失败；有效空 diff 返回 no-diff，不启动 reviewer、不造 CR、不声称 approved；正常结束本次 Work 并报告固定输入，change 完成仍按原终点规则判断。有差异才继续。
 3. **发现来源**：调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`；规范来源缺失时经确认跳过规范轴，标准轴继续。
-4. **隔离审查**：仅按公共 Skill 的完整输入复用门接受既有结果；需要执行的轴在平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
+4. **独立审查**：按公共 Skill 的完整输入与独立身份门复用已有结果；否则默认派遣一位未参与实现的 Agent 分别审两轴，需要并行时使用两位。保存真实工具凭据和原始输出，Lead 核验后记录 Independent Review；能力不足保持 blocked。
 5. **持久化（有 change 时）**：选择下一个未占用 `CR-###`，使用 `<Path>{roots.workflows}/specdev/specdev-c-code-review/assets/code-review-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
 6. **验证与路由**：无 change 时核对实际报告与固定范围直接返回；有 change 时使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage review` 校验当前 change。无阻塞 finding 时返回完成或 I；局部修复生成/修订 Ticket；规范冲突返回 S/G；无法确定的 blocker 保持 C 可恢复状态。
 
@@ -39,7 +39,7 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 
 - 有差异分支的 fixed point/head 是本地不可变 SHA，diff 语义与用户选择一致；no-diff 独立返回，不运行要求 CR 的 review stage；
 - 规范和标准来源发现顺序有记录；
-- 两轴隔离、固定顺序、未合并排名；
+- 审查者与实现者不同、两轴分别判断、固定顺序、未合并排名；
 - 每个 finding 有路径、风险、依据和满足条件；
 - 报告、状态、验证结果和下一 Work 路径一致；
 - C 未修改项目代码或远程状态。
@@ -48,8 +48,8 @@ UI diff 按 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Pat
 
 ## 编排与执行上下文
 
-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 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

package/template/workflows/specdev/specdev-c-code-review/assets/code-review-template.md

@@ -46,8 +46,12 @@ created_at: <ISO-8601>
 
 ## 审查证据复用（仅实际发生时填写）
 
-记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、审查者独立身份与派遣/返回核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
 
 ## 比较语义与证据有效期
 
 记录 baseline/range/commit/pr、实际 diff argv/digest、原 base/head 与 fixed point、消费者和相关配置/规范版本。合法 no-diff 不创建本 CR；非法引用和根提交无 committed baseline 明确报告。head 或相关输入变更后，核对受影响审查与验证，不沿用旧通过。
+
+## 独立审查记录的填写
+
+按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 在本文实际生成 `Independent Review`、固定输入、原始 reviewer 输出和 Lead 核验段。完成前必须有真实独立身份与两轴结果；不要预填通过或用模板段落替代证据。

package/template/workflows/specdev/specdev-c-code-review/references/source-files-review.md

@@ -3,8 +3,8 @@
 仅用于明确指定文件的只读请求，不替代用户要求的 PR、commit、range 或 baseline 比较，也不冒充 I 的最终 diff 审查。
 
 1. 用下列只读调用固定 projectRoot、用户指定路径和实际原始字节摘要，多个文件重复 `--file`。它不调用 Git、不创建状态，拒绝空范围、重复文件/别名、非文件及越界路径；内部符号链接保留所选路径和实际目标。读取必要直接调用方、测试与适用标准，并把扩展范围及理由列入输入。若文件在审查中变化，重验受影响结论，不沿用原快照结果。无 Git 时如实说明没有 commit/log，不能借外层仓库或伪造 SHA。
-2. 将 `review_mode: source-files`、`source_snapshot`（项目相对路径及 SHA256）、规范/标准来源、review_context 和实际可用隔离方式交给 <Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>。来源发现将 commit 引用步骤记为 not-applicable；其余来源与两轴隔离要求照常。
-3. 规范缺失只阻塞依赖规范的判断，标准轴独立进行；按原规则确认规范缺失后才标记 skipped:no-spec。工具或独立 reviewer 缺失如实报告，不用一次自审宣称两个隔离轴已完成。
+2. 将 `review_mode: source-files`、`source_snapshot`（项目相对路径及 SHA256）、规范/标准来源、review_context 和真实独立 reviewer 身份与派遣方式交给 <Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>。来源发现将 commit 引用步骤记为 not-applicable；其余来源与独立审查要求照常。
+3. 规范缺失只阻塞依赖规范的判断，标准轴独立进行；按原规则确认规范缺失后才标记 skipped:no-spec。工具或独立 reviewer 缺失如实报告，不得用实现者自审宣称双轴已完成。
 4. 返回固定文件/摘要、两轴结果、实际验证、限制和下一步。会话结果不创建 change、CR、配置或状态文件，不改源文件、永久知识或远程系统。若后来要求正式 diff 审查，转回 C 的真实固定点分支。
 
 本分支的文件摘要只证明输入未变，不证明语义审查质量、用户授权或整个 change 完成。

package/template/workflows/specdev/specdev-i-implement/SKILL.md

@@ -16,17 +16,17 @@ metadata:
 
 先读 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`；从 README/原 Goal 或当前 tickets-map/父 map 定位所需范围、本票、上游约束、项目 Skill 与执行策略。仅展开当前 Ticket 的正文、直接依赖、适用 Skill 和必要恢复证据，不整读知识库。
 
-轻量实现可读取 README 的唯一 scope/acceptance/verification 规格章节，等价于获批低风险 Direct Spec；保留明确范围、可判定 AC、真实验证及停止条件。存在独立 <Path>{roots.state}/specdev/changes/{change}/spec.md</Path> 时优先读取并拒绝双权威。无需独立票时不造 Ticket/Map；UI 的 DESIGN、批准和真实浏览器门保持。
+轻量实现可读取 README 的唯一 scope/acceptance/verification 规格章节，等价于获批轻量 Direct Spec；独立完整 Spec 可按其全部风险门直接实施；保留明确范围、可判定 AC、真实验证及停止条件。存在独立 <Path>{roots.state}/specdev/changes/{change}/spec.md</Path> 时优先读取并拒绝双权威。无需独立票时不造 Ticket/Map；UI 的 DESIGN、批准和真实浏览器门保持。
 
 ## 当前票的执行入口
 
-执行必须读取 `<Path>{roots.workflows}/specdev/specdev-i-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/specdev-i-implement/references/execution-preflight.md</Path>`；执行过程按当前阶段路由设计、TDD、双轴审查和 Evidence；预检单独拥有 Git、workspace、Ready 与授权检查。两者必读，分支参考只在对应 workspace/风险/阶段进入时加载。
+执行先读取 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path>，确定 Spec/Ticket、执行方式与工作区三个独立选择；完整获批 Spec 不因范围较大而强制拆票，已有 Ready Ticket 不强制补 Goal。执行必须读取 `<Path>{roots.workflows}/specdev/specdev-i-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/specdev-i-implement/references/execution-preflight.md</Path>`；执行过程按当前阶段路由设计、TDD、双轴审查和 Evidence；预检单独拥有 Git、workspace、Ready 与授权检查。两者必读，分支参考只在对应 workspace/风险/阶段进入时加载。
 
 UI Ticket 或 Direct Spec 必须读取 <Path>{roots.workflows}/specdev/common/rules/design-contract.md</Path> 与当前批准 DESIGN，核验 design_ref（revision/digest/pages/acceptance）、原型和基线。页面任务按已批准规则实现，不重新选择模板；实际实现证据写入 `Design Conformance`，原型截图不替代生产页面验证。
 
 1. 核验 Ready、授权、owner、真实源与 map 基线；新增计划型票按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 实际调用绑定能力并记录证据。票缺调用契约时先由 Lead 补齐，不猜测。
 2. 保持 codebase-design、design-it-twice 和 TDD 的适用门禁；进入对应实现步骤再读其 reference。派单时调用 共享编排方法；Lead 是唯一 SpecDev 状态写入者。
-3. current 模式串行使用当前 workspace；required 模式使用独立 worktree，E2E 由 Lead 在 parent-candidate 完成。实现 commit、父分支推进和集成均需真实授权。
+3. Ticket 和 Direct Spec 均可在 current 模式串行使用当前 workspace，或在 required 模式使用独立 worktree，E2E 由 Lead 在 current 或 required 的 parent-candidate 完成。实现 commit、父分支推进和集成均需真实授权。
 4. 安全、并发、公共接口、数据迁移或用户要求全面审查时展开 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/risk-review.md</Path>`；不为省上下文删减必要检查或限制发现数量。
 5. 写 Evidence、运行适用校验并回读后才推进状态；必需 Skill 失败、验收失败、越界或归属冲突暂停本票及依赖它的分支。无关工作仍由总控继续，不接管他人事务。
 
@@ -42,8 +42,8 @@ UI Ticket 或 Direct Spec 必须读取 <Path>{roots.workflows}/specdev/common/ru
 
 ## 编排与执行上下文
 
-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 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

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,14 +17,16 @@
 
 ## 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>`
+- **文件交接（实际外部派遣时）：** `<Path>{roots.state}/specdev/changes/{change}/sessions/{session}/{task}/TASK.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/sessions/{session}/{task}/REPORT.md</Path>`；绑定稳定 change 身份与 change 根相对 locator，修正交付引用新任务及旧报告；Lead direct 不创建空目录
 - **允许动作：** worktree changes / implementation commit / ...
 - **返回：** commit、dirty 状态、修改路径、非 E2E 命令、未验证项与恢复条件
 - **Lead 独立核对：** pass / fail；实际读取与命令摘要
 - **只读 Agent findings：** 无 / 固定输入、来源、结论、Lead 核对
 
-任务执行者 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和返回事实整理。
+任务执行者 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和返回事实整理。有文件交接时依 <Path>{roots.references}/coordination/session-files.md</Path> 只保存输入/报告指针和 Lead 独立核验，不复制正文；REPORT 的 completed 不是本 Evidence 的 done。先读报告聚焦交接，细节不足再检索其历史入口。突然中断无报告时记录未知事实与原工具查询结果，不补造成功回报。
 
 ## 3. 修改范围与路径所有权
 
@@ -42,11 +44,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 +56,7 @@
 
 - **失败后修复与重跑：** 无 / ...
 - **未运行检查：** 无 / 原因与风险
-- **E2E：** 按 Goal Plan 的 E2E disposition 记录；未在本环境运行时说明 owner 与原因
+- **E2E：** 按有效计划或当前 I 执行合同 的 E2E disposition 记录；未在本环境运行时说明 owner 与原因
 
 ## 6. 双轴审查
 
@@ -69,14 +71,14 @@
 ### 规范轴
 
 - **固定输入与来源：** Spec / Ticket / Goal Plan / source
-- **结果：** pass / request-changes / skipped:no-spec
+- **结果：** pass / request-changes / blocked:missing-spec
 - **Findings 与修正：** 无 / ...
 
-两个轴隔离并按上述顺序记录。
+两个轴分别判断并按上述顺序记录；默认同一位未参与实现的 reviewer 完成两轴。
 
 ## 7. Integration Verification
 
-按 Goal Plan 记录 direct-parent 或 parent-candidate 集成；未采用的字段写 `null` 或 `not-applicable`。
+按有效计划或当前 I 执行合同 记录 direct-parent 或 parent-candidate 集成；未采用的字段写 `null` 或 `not-applicable`。
 
 | 项目 | 结果 |
 |---|---|
@@ -134,7 +136,7 @@
 
 ## 审查证据复用（仅实际发生时填写）
 
-记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、审查者独立身份与派遣/返回核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
 
 ## OPS 交付（仅用户请求时）
 
@@ -146,8 +148,12 @@
 
 ## 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
 
 仅独立 Spec 的无票 Direct Spec 完成时填写本节 JSON array，每个 Spec AC 恰一项。字段为 `id`（AC-N）、`result: passed`、`method`、`source`、`observed`；实际执行命令时增加 `command` 与 `exit: 0`。引用外部 `evidence` 文件时须提供真实匹配的 `sha256`；原 Evidence 内联实际观察不另造文件。没有执行的项不伪造 passed。普通 README 轻量模式仍用 README verification 表，二者不重复维护。
+
+## 独立审查记录的填写
+
+按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 在本文实际生成 `Independent Review`、固定输入、原始 reviewer 输出和 Lead 核验段。完成前必须有真实独立身份与两轴结果；不要预填通过或用模板段落替代证据。

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>`；外部 CLI/Herdr/Orca 派遣按 `<Path>{roots.references}/coordination/session-files.md</Path>` 保存 TASK、交回 REPORT，原 Evidence 只导航与验收。`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,34 +115,38 @@ 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、固定基线和页面/状态规则。
 
 标准轴同时复核 `<Path>{roots.workflows}/specdev/common/rules/code-commenting-rule.md</Path>`：公共 API 契约完整，内部注释只保留非显然的 Why、Invariant 和 Risk，且相关注释与当前行为一致。
 
-两个轴隔离并按标准轴、规范轴顺序返回 Lead。局部 finding 在当前模式的实现 workspace 修正、创建新 checkpoint 并重跑；改变上层契约则登记 deviation。Ticket 进入 `review` 或 Direct Spec 进入最终验证前，两轴必须通过。
+默认派遣一位未参与本范围实现的原生 subagent，分别判断标准轴、规范轴并按顺序返回 Lead；明确选择 Herdr/Orca/CLI 时沿该方式派遣。保存真实身份、原始报告和 Lead 工具核验，禁止实现者自审。局部 finding 在当前模式的实现 workspace 修正、创建新 checkpoint 并重跑；改变上层契约则登记 deviation。Ticket 进入 `review` 或 Direct Spec 进入最终验证前，两轴必须通过。
+
+Direct Spec current 未提交时按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/working-tree-review.md</Path> 固定实际交付快照；HEAD 不能代表未提交内容，也不因审查而自动取得 commit 授权。
 
 ### 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。
 
+最终候选与来源审查不同、发生冲突修正或多个单元组合时，Lead 按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 对最终交付范围补充独立审查；原输入完全相同才复用。候选未获两轴通过不能推进父分支或声明完成。
+
 ### 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 +167,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 自审替代。
+P 在已授权 run/resume 中完成当前实现、审查、验证和同范围修复后继续下一 Ready 任务，不逐票询问“继续”。只读分析或 plan 不执行。双轴审查必须由未参与本范围实现的 Agent 执行，默认派遣一位原生 subagent；已有编排选择沿用于 review，不能由实现者或参与实现的 Lead 自审替代。

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

@@ -77,8 +77,12 @@ ready_for_execution: false
 
 ## 4. Execution and Integration Protocol
 
+**执行入口：** 获得实现授权后，Lead 与实现执行者读取并执行 `<Path>{roots.workflows}/specdev/specdev-i-implement/SKILL.md</Path>`，再按当前输入实际调用适用项目 Skill。I 负责实现、独立双轴审查、验证与 Evidence；计划本身不授予实现或 Git 操作权限。
+
 ### Lead Orchestration
 
+执行方式独立于下方工作区策略：默认按当前宿主正常执行（mode: lead），App、CLI 等均可，subagent/team 属于宿主能力；明确指定 CLI 交互、Herdr 等方式才按共享编排合同接入。记录本次选择与来源，不逐任务重新询问。
+
 | 项目 | 决定 | 事实依据 |
 |---|---|---|
 | Lead | `<owner-or-session-locator>` | 唯一 SpecDev 状态、Evidence 与父分支 owner |