@namewta/speculo 2.0.1 → 2.0.3

package/template/workflows/specdev/common/rules/path-ownership.md

@@ -22,14 +22,14 @@
 
 ## 3. Ticket workspace strategy
 
-Goal Plan 创建时选择 Ticket workspace strategy，默认 `current`。`current` 模式的 Ticket 使用当前分支、当前 workspace 和严格串行执行；允许一个 实现执行者 写入当前 workspace，但前一 Ticket 必须完成 commit、Lead 验收和 direct-parent 验证后才能开始下一个。`required` 模式每个 Ticket 使用唯一来源 worktree `specdev-worktree/<ticket-id>`，并通过 candidate-merge 集成。没有 Ticket 的获批 Direct Spec 继续由 current workspace 唯一 owner 执行；只读调查不创建实现 worktree。
+按 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path> 选择工作区，与当前宿主执行、显式 CLI 交互或 Herdr 等方式正交。默认 current，已有选择直接复用；无 Goal 时 I 在原 Evidence 负责选择与记录。current 严格单代码 writer，前一 Ticket 完成 commit、Lead 验收和 direct-parent 验证后才进入下一票。required 的 Ticket locator 为 `specdev-worktree/<change>/<ticket-id>`，Direct Spec 为 `specdev-worktree/<change>/direct-spec`，两者都走 candidate 集成；只读调查/审查不创建实现 worktree。
 
 workspace/implementation owner 可以是 Lead 或动态 实现执行者；integration owner 固定为 Lead。current 模式 Lead 在父分支直接验收和推进，required 模式 Lead 建立 parent-candidate、运行适用 E2E 并推进父分支。required 生命周期由 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 管理，current 生命周期由 I-implement 的 direct-parent 规则管理。
 
 ## 4. 并发
 
-required 模式 实现执行者 上限取 Goal Plan、config 和平台能力共同约束，Lead 参与实现时计入。current 模式保持单 writer 串行安全不变量，Ticket 严格串行。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
+required 模式 实现执行者 上限取实际存在的 Goal/父计划、项目约定和平台能力共同约束，无计划默认串行，Lead 参与实现时计入。current 模式保持单 writer 串行安全不变量，Ticket 严格串行。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
 
 子 change 属于父 Implementation Map 时，再取父 Implementation Plan 的全局 实现执行者 上限与 workspace 策略；该上限跨全部成员合计。无 dependency 的组合 Ready Tickets 若 writable/shared paths 重叠，也必须在父 Map 建立 serialization。相同 repository/ref 的 parent integration 严格串行；一次父 HEAD 推进会使其他成员旧 candidate 失效。
 
-**完成标准**：每个项目写入映射到唯一 change、Ticket、owner 和来源 worktree；shared 与父分支写入 owner 唯一。
+**完成标准**：每个项目写入映射到唯一 change、已有 Ticket 或 Direct Spec、owner 和来源 worktree；shared 与父分支写入 owner 唯一。

package/template/workflows/specdev/common/rules/path-reference-contract.md

@@ -73,6 +73,8 @@ SpecDev 不假定运行时一定提供项目根变量。Ticket、Evidence、诊
 
 外部 URL 不能伪装成 SpecDev 内部路径；内部文件也不能用 URL 代替完整 Path 标签。
 
+历史会话的只读外部 locator 是限定例外：可记录工具返回的“所属主机＋原生绝对路径/会话标识”，按 <Path>{roots.references}/coordination/session-files.md</Path> 检索。它不使用内部 Path 标签，不是可移植项目路径、静态能力依赖或写入授权；项目内保存的快照仍使用正常工件路径。
+
 ## 5. 工件名称与工件引用
 
 可以在概念层面写“Spec”“Ticket”“Goal Plan”“Evidence”。一旦语句指向具体文件、目录、模板、Schema、工具或状态工件，就必须给出完整 Path 标签。

package/template/workflows/specdev/common/rules/planning-principles.md

@@ -49,7 +49,7 @@ Ticket 告诉执行者：做什么、为什么、不能改变什么、按什么
 ## 7. 分层规划
 
 - Spec 决定外部行为。
-- Ticket 是决策完备的微型执行计划。
+- Ticket 是可独立验收的垂直行为切片；外部合同和必要执行约束完备，局部实现由 I 决定。
 - Tickets Map 决定依赖和覆盖投影。
 - Goal Plan 只在协调复杂度需要时决定跨 Ticket 编排。
 - Implement 在既定契约内完成代码和 Evidence。

package/template/workflows/specdev/common/rules/readiness-and-depth.md

@@ -6,19 +6,19 @@
 
 适用条件通常全部满足：范围局部、行为明确、沿用既有模式、无公共接口或数据迁移、无安全或高事故半径影响、易回滚、无需并行协调。
 
-最低内容：目标、范围、项目路径授权、1–3 条执行路线、验收标准和验证方法。
+最低内容：目标、垂直行为切片、范围、项目路径授权、验收标准和验证方法。局部实现由 I 决定。
 
 ### Standard
 
 适用于大多数跨多个文件或技术层的垂直切片。
 
-额外要求：锁定决策与假设、接口接缝、输入输出、不变量、失败行为、有序执行路线、验证矩阵和路径所有权。
+按适用性补充接口接缝、不变量、失败行为和低影响假设；上游已有合同直接引用。仅在顺序影响安全或正确性时记录执行路线，不要求固定步数。
 
 ### Deep
 
 任一条件触发：公共 API、schema、wire format、数据迁移、认证授权、隐私、资金、不可逆操作、expand-contract、共享核心路径、多个 implementation owner 的跨 Ticket 写入协调、多个实质架构方案或高事故半径。
 
-额外要求：数据流或状态转换、兼容窗口、迁移顺序、可观测性、回滚、风险缓解、收缩条件和人工批准点。
+对触发 Deep 的实际风险补充数据/状态、兼容、迁移、恢复、风险缓解、收缩条件或批准点。无关维度省略；Deep 不要求每票填满所有栏目。
 
 ## 2. Ticket Definition of Ready
 
@@ -34,8 +34,8 @@ Ticket 只有同时满足以下适用条件才可设置 `ready: true`：
 - shared path 有唯一 owner；
 - 验收标准可判定；
 - 验证矩阵覆盖正常、失败和回归风险，或有可信的不适用理由；
-- Standard 或 Deep Ticket 有有序执行路线；
-- Deep Ticket 有迁移、兼容、监控、回滚和批准点，或逐项说明不适用；
+- 迁移或安全操作等不可交换的顺序已明确；普通局部实现不要求预写步骤；
+- Deep Ticket 的实际风险及相应迁移、兼容、恢复或批准要求已闭合；
 - 单个全新上下文可以完成，否则必须拆分。
 
 详细检查位于 `<Path>{roots.workflows}/specdev/specdev-t-tickets/references/ticket-readiness.md</Path>`。

package/template/workflows/specdev/common/rules/workflow-routing.md

@@ -17,7 +17,7 @@
 | 单个已拆票 change 或多个 Ready change 的 Goal 规划、持续实现与恢复 | P-goal-plan | I / verify / completed / blocked |
 | 旧 O 调用或恢复键 | P-goal-plan | 统一 P 多 change 模式 |
 | Ready 执行 | I-implement | Triage / A / blocked / deviation |
-| 开发完成后需要理解当前 change 或追问实现 | L-learn-change | 返回用户 / 继续提问 / Triage / A |
+| 学习需求参考、本项目代码、已有 change 或外部项目与文章 | L-learn | 返回用户 / 继续提问；另有开发请求再选 G / W / S |
 | 架构健康扫描 | R-review-architecture | G / T |
 
 同 change 下一阶段需要当前一手推理且上下文健康时继续；切换 repo/person/harness 或旁路时使用 `<Path>{roots.commands}/handoff/COMMAND.md</Path>`；严格限定且可独立派单时使用 Dispatch Packet；其他长上下文以权威工件路径恢复。平台不支持 clear/compact 时不虚构操作。
@@ -27,7 +27,7 @@
 
 ## 复盘与交付路由
 
-开发环境/流程复盘 → <Path>{roots.workflows}/specdev/specdev-r-retro/SKILL.md</Path>。代码讲解仍为 L；Speculo 产品反馈仍为 retro command。CI/安全/PR/包发布 → <Path>{roots.workflows}/specdev/specdev-t-triage/SKILL.md</Path> 的对应模式；确定性修复回到 D/I，不由 T 接管代码。
+开发环境/流程复盘 → <Path>{roots.workflows}/specdev/specdev-r-retro/SKILL.md</Path>。代码与参考资料学习 → <Path>{roots.workflows}/specdev/specdev-l-learn/SKILL.md</Path>；可在实现前直接进入，用户未指定 change 时由 L 新建学习载体。Speculo 产品反馈仍为 retro command。CI/安全/PR/包发布 → <Path>{roots.workflows}/specdev/specdev-t-triage/SKILL.md</Path> 的对应模式；确定性修复回到 D/I，不由 T 接管代码。
 
 长任务在阶段边界按产物与待决问题选择继续、压缩上下文或 handoff；交接只携带准确 owner、SHA、输入和未闭合动作，不硬编码特定模型的上下文阈值，不自动启动其他会话。
 
@@ -40,6 +40,6 @@
 | 一次性事件暂时无法重现 | D / evidence-triage | 不标记 root-cause-confirmed，不创建 Ready 修复 |
 | 已批准的文档维护 | I-implement / documentation | 不新建文档 workflow，不伪造 TDD |
 | 只审查文档或某个 commit | C-code-review | 不写项目、不把单 commit 扩大到 HEAD |
-| 理解已实现 change | L-learn-change | 不改 Learning workflow，不永久晋升 |
+| 理解功能、实现思路、运行机制或文章观点 | L-learn | 不自动规划/实现，不改 Learning workflow，不永久晋升 |
 
 只读调查或审查不是后续修改授权。清晰的小请求继续走原适用阶段，不因增加专业分支强制进入 W/G/Triage；无差异、无候选和证据不足均可诚实返回，不制造工作量。

package/template/workflows/specdev/common/rules/workflow-state-and-lifecycle.md

@@ -14,6 +14,8 @@ change 的稳定身份是同一项目、领域内的 `YYYY-MM-DD-topic[-NN]` 目
 
 归档实际位置和原回执表示封存；不在 README 增加 archived、archive_path 或全局 active/archived 列表。新 archive 不嵌套月份。旧历史移动须另有明确计划，验证所有 locator 和 DESIGN 摘要；不可变正文不做路径替换。
 
+实际外部派遣的输入、报告和按需历史快照按 <Path>{roots.references}/coordination/session-files.md</Path> 保存在 <Path>{roots.state}/specdev/changes/{change}/sessions/</Path>，随 change 整体归档并进入原完整性清单；归档前仍核对 writer 已停止，不因 REPORT 显示 completed 就移动活动工作区。session 只是交接材料分组，不成为整体 Outcome 或执行状态的第二权威。引用按稳定 change 与对象内 locator 解析，历史原件不回填或清理。
+
 ## 唯一整体结论
 
 每个新 change README 正文恰有一行：

package/template/workflows/specdev/common/skills/code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-review
-description: 对固定的本地文件快照或不可变 Git diff 执行隔离的标准轴与规范轴审查，供独立 C Work 和 I Work 最终审查共同调用。
+description: 对固定的本地文件快照或不可变 Git diff 由未参与实现的 Agent 执行标准轴与规范轴审查，供独立 C Work 和 I Work 最终审查共同调用。
 compatibility: Requires the owning Speculo workflow resources and explicit project roots.
 metadata: {"speculo-source-id": "specdev-code-review"}
 ---
@@ -9,9 +9,11 @@ metadata: {"speculo-source-id": "specdev-code-review"}
 
 本 Skill 返回审查结果，不创建 runtime namespace。调用方分别负责 C review 工件或 I Evidence。
 
+采用调用方按 <Path>{roots.references}/coordination/coordination-contract.md</Path> 确定的 review 阶段方式。默认派遣一位未参与当前范围实现的原生 subagent，分别完成两轴；实际需要可拆成两位。已选择 Herdr/Orca/CLI 的任务沿该方式派遣，明确 review 阶段选择优先。能力不足或独立身份不明时阻塞完成，不能由实现者自审替代。task 上下文仅执行已分配轴，不递归派遣。
+
 ## 输入
 
-默认 diff 模式使用下列 fixed_point/head/diff/log。C 显式本地文件分支使用 `review_mode: source-files` 与 `source_snapshot`（路径/原始字节 SHA256）；不提供虚假的 Git 字段。两种模式均须提供相同的规范、标准、范围与隔离输入，I 最终审查保留 diff 模式。
+默认 diff 模式使用下列 fixed_point/head/diff/log。C 显式本地文件分支使用 `review_mode: source-files` 与 `source_snapshot`（路径/原始字节 SHA256）；不提供虚假的 Git 字段。各模式均提供规范、标准、范围和独立身份。I 未提交 Direct Spec 使用 `review_mode: working-tree`，按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/working-tree-review.md</Path> 固定完整交付快照。
 
 - `fixed_point`：已解析的 commit SHA；
 - `head`：已解析的 HEAD/checkpoint SHA；
@@ -20,17 +22,19 @@ metadata: {"speculo-source-id": "specdev-code-review"}
 - `spec_sources`：零个或多个本地权威来源；
 - `standards_sources`：仓库编码标准来源；
 - `review_context`：路径范围、调用 Work 和适用授权；
-- `parallel_reviewers`：平台支持时为 true，否则使用两个独立上下文包顺序执行。
+- 实现者真实身份、所选 review 方式与实际派遣凭据；默认一位独立 reviewer，需要时分别派遣两轴。
 
 ## 流程
 
 1. diff 模式重验 fixed point/head、实际 diff 语义和摘要；无效引用不启动 reviewer。合法空 diff 由调用方返回 no-diff，不伪造 approved 或复用非空报告。显式范围不得回退为默认三点比较。source-files 模式重验固定路径与原字节，不推断历史 diff 或 commit。
 2. 加载 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/source-discovery.md</Path>`，穷尽规范和标准来源。
-3. 发现已有审查并拟复用时，先读取 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/result-reuse.md</Path>`，完整核对输入、两轴隔离与原始证据；能证明相同的轴保留原结果，其余轴按下列步骤运行；未能证明相同就正常重审两轴。
+3. 发现已有审查并拟复用时，先读取 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/result-reuse.md</Path>`，完整核对输入、审查者独立性与原始证据；能证明相同的轴保留原结果，其余轴按下列步骤运行；未能证明相同就正常重审两轴。
 4. 加载 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/fowler-smells.md</Path>` 作为标准轴最低启发式；仓库明确标准优先。
 5. 用户要求全面审查或触及安全、数据迁移、公共契约、并发和恢复时，先加载 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/risk-review.md</Path>`，覆盖全部适用风险，不限制 finding 数量。
-6. 加载 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/reviewer-contracts.md</Path>`，用互不共享发现的上下文分别运行两个轴。
-7. 原顺序返回 `standards` 和 `specification` 两份结果。规范来源不存在时只跳过规范轴并解释，标准轴继续。
+6. 加载 `<Path>{roots.workflows}/specdev/common/skills/code-review/references/reviewer-contracts.md</Path>`，实际派遣未参与实现的 Agent，分别运行两个轴。
+7. 原顺序返回 `standards` 和 `specification` 两份结果。C 规范来源确实不存在时只跳过规范轴并解释，标准轴继续；I 缺少权威规范则阻塞，不允许跳过后完成。
+
+8. 按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 返回固定输入、原始报告、真实 reviewer 身份和工具凭据，由 Lead 核验并写入原 owning 工件。
 
 ## 输出
 
@@ -41,6 +45,7 @@ source-files 结果以 `review_mode` 和 `source_snapshot` 代替下例 Git 字
   fixed_point, head, diff_command, commit_log,
   standards: { result, findings, sources },
   specification: { result, findings, sources },
+  reviewers, implementers, dispatch_receipts,
   skipped_axes,
   summary_counts
 }
@@ -52,7 +57,7 @@ Finding 必须包含 severity、项目相对 Path/代码块、具体风险、依
 
 - diff 的 fixed point、head、diff、commits 或 source-files 的原字节快照固定且可重复；
 - 仓库标准优先于 Fowler 启发式；
-- 两个 reviewer 上下文没有相互发现污染；
+- 每个 reviewer 均未参与本范围实现；两轴分别判断并返回，有真实派遣与原始结果证据；
 - 每个发现可定位且说明行为风险；
 - 两轴按固定顺序返回，缺失规范没有掩盖标准审查。
 

package/template/workflows/specdev/common/skills/code-review/references/result-reuse.md

@@ -4,12 +4,12 @@
 
 | 必须相同并可回读 | 核对证据 |
 |---|---|
-| review_mode、实际比较或文件范围 | diff 模式的 fixed_point/head、不可变 SHA、diff 摘要与 commit 范围（legacy 默认三点）；source-files 的路径与原字节摘要；不可跨模式复用 |
+| review_mode、实际比较或文件范围 | diff 模式的 fixed_point/head、不可变 SHA、diff 摘要与 commit 范围（legacy 默认三点）；source-files 的路径与原字节摘要；working-tree 的基线、完整范围与实际工作副本快照；不可跨模式复用 |
 | 规范、标准、ADR 和适用项目指令 | 稳定来源路径、原始字节摘要与明确范围 |
 | review Skill 与当前触发的全部参考 | ID、入口/参考字节摘要、风险分支与跳过理由 |
 | 与结论相关的工具、测试环境、配置 | 实际版本/配置摘要与观察证据；未记录不能宣称相同 |
-| 两轴隔离及执行结果 | 原 reviewer 输入、独立 findings、原验证输出及其 locator |
+| 审查独立性及执行结果 | 实际实现者/reviewer 身份、派遣/返回与 Lead 核验、原输入、两轴 findings 和原验证输出 locator |
 
-Lead 必须回读真实原报告和证据；相同文件名、报告“通过”文字、相同 HEAD 或结构校验均不足。任一输入变化、缺失、不可解析或来源不明，重跑受影响轴；无法证明两轴输入独立时重跑两轴。新风险范围必须完整审查，不因复用缩减 finding 数量。
+Lead 必须回读真实原报告和证据；相同文件名、报告“通过”文字、相同 HEAD 或结构校验均不足。任一输入变化、缺失、不可解析或来源不明，重跑受影响轴；无法证明 reviewer 未参与实现时重跑两轴。新风险范围必须完整审查，不因复用缩减 finding 数量。
 
 复用保持原结果与来源，不能把 request-changes、skipped:no-spec 或未测结果改成 passed。有 change 的正式 C 仍创建自己的新 CR 报告并引用原证据；会话文件审查只返回本次结果；I 仍由 Lead 写入本票 Evidence，旧报告/旧完成证据不覆盖。复用报告不跳过当前 workspace/集成/E2E/授权检查，不新增全局缓存、状态树或完成捷径。

package/template/workflows/specdev/common/skills/code-review/references/review-evidence.md

@@ -0,0 +1,44 @@
+# 独立审查证据
+
+供 C、I 和最终集成审查使用。只在原 CR、I Evidence、轻量 README 或原整体 Evidence 中记录，不创建 Agent 注册表、状态镜像或完整聊天副本。外部派遣复用已有 TASK/REPORT；原生工具可把必要原始输出及 Lead 核验摘录保存在同一 Markdown 的独立锚点。工具提供的真实身份统一写成 `provider:agent-or-session-id`，如原生工具句柄；不得使用任意角色名或 session 目录名代替。
+
+## 冻结输入
+
+在报告中建立独立的 `review-input` 锚点，用一个 JSON 对象保存 `scope`（review-scope 的完整原始返回值）、`sources` 和适用的 `exclusions`。sources 每项为 `kind: standards|specification|instructions`、项目根相对 `locator` 和实际 UTF-8 原文字节的 `sha256`。locator 可带显式锚点；轻量 README 只摘要其 scope/acceptance 等合同段，不能摘要包含审查记录的整份 README。来源必须覆盖本轮实际规范、标准及适用指令。
+
+`Input-SHA256` 为该对象经 JSON.parse 后再 JSON.stringify 的 UTF-8 SHA256，由工具计算，不手写猜测。将同一对象及摘要交给 reviewer。摘要证明输入一致，不证明审查真的发生。
+
+未提交的 Direct Spec 先读取 <Path>{roots.workflows}/specdev/common/skills/code-review/references/working-tree-review.md</Path>。Git diff 使用实际工具返回的不可变端点；规范/标准和相关指令变化也会使受影响结论失效。
+
+## 最小记录
+
+下列字段和表头置于原 owning 工件；locator 相对当前 change。无 change 时返回相同信息和真实工具输出，沿调用方原报告位置保存，不为审查制造 change。
+
+```markdown
+## Independent Review
+
+Input: evidence/T-01.md#review-input
+Implementers: provider:actual-implementation-session
+Mode: native
+Verified-By: provider:actual-lead-session
+Verification: evidence/T-01.md#review-receipt
+
+| Axis | Reviewer | Result | Report |
+|---|---|---|---|
+| standards | provider:actual-review-session | pass | evidence/T-01.md#standards-output |
+| specification | provider:actual-review-session | pass | evidence/T-01.md#specification-output |
+```
+
+Mode 为 native/herdr/orca/cli。Implementers 包含本范围全部实现及修复者；Lead 参与实现也列入。每轴 Report 指向 reviewer 实际输出的独立段，含 `Reviewer`、`Axis`、`Result`、`Input-SHA256`、`Observed` 字段及具体 findings/依据。不能指回汇总表自证。请求修正或未验证不得改写为 pass；原报告不覆盖。
+
+Verification 指向 Lead 回读真实派遣和返回事实后的独立核验段，含 `Verified-By`、`Mode`、`Reviewers`（逗号分隔真实身份）、`Input-SHA256`、`Result: verified`、`Observed`。Observed 说明工具返回的实际身份、派遣/返回定位、只读范围和核验事实；工具不提供的事实保持未验证。需要深查时沿原历史会话 locator 检索，不以 JSONL 文件存在代替审查。
+
+## 完成与复用
+
+完成前回读输入、原报告和工具核验。实现范围内的 reviewer 不独立；一轴失败或 I 缺规范都阻塞完成。改变角色名或重新开启同一实现者的上下文不能绕过。
+
+单票结果以本票实际 checkpoint 为准。多个实现单元组合或冲突修正后，Lead 对实际最终整体范围调用同一独立审查能力，在 <Path>{roots.state}/specdev/changes/{change}/evidence/final-review.md</Path> 记录；跨 change 父编排使用原 <Path>{roots.state}/specdev/changes/{change}/evidence/implementation-orchestration.md</Path>。单 Direct Spec/单票最终输入完全相同可沿用原 Evidence；候选变化先补审再推进父分支或宣布完成。整体输入以最初实施基线为起点，覆盖所有成员实际交付，不只审最后一票。
+
+C 可以只审明确的不可变 commit；I 完成时还必须确认实际工作副本与该交付一致。存在未提交代码时转入 working-tree 审查，不能沿用旧 commit 的通过结论。原 change 的 Markdown 执行记录可在审查后更新；规范与标准段仍需摘要一致。父编排的输入包含原 Implementation Plan/Map 和各成员 Spec，并纳入成员实际实现/冲突修复者及共同起始基线。纯学习或 triage 调查依据原 Ownership/Work 和非实现产物判定，附加 learning 索引不能豁免实现审查。
+
+旧报告可只读展示；作为本轮完成或复用依据时，缺少独立性与固定输入证据就重新审查。静态校验仅验证记录、原文匹配和版本一致性，真实执行仍由 Lead 核对工具事实；工具不可用不能从格式通过推导完成。

package/template/workflows/specdev/common/skills/code-review/references/reviewer-contracts.md

@@ -1,13 +1,25 @@
-# Isolated Reviewer Contracts
+# 独立双轴审查
+
+## 派遣与身份
+
+默认派遣一位未参与当前审查范围实现的原生 subagent，分别给出标准轴和规范轴结果。实际需要并行时可派遣两位。沿调用方确定的 review 阶段方式执行：明确选择 Herdr/Orca/CLI 时用该工具派遣，并保存真实工具返回的 Agent/会话标识；编排方式与工作区独立。
+
+实现者包括当前范围的代码、配置、模型可见指令及修复/冲突解决的所有 Agent。实现者运行测试和自查是实现活动，不能作为独立审查。改名、切换角色或重置上下文不改变参与过实现这一事实。Reviewer 只读审查对象，返回 findings；参与修复后必须另派独立 reviewer。
+
+无法获得独立 Agent、身份无法核实或指定工具不可用时，报告 blocked/unverified，保持完成门关闭。不得用当前实现者顺序扮演两个角色替代派遣。task 上下文只执行分配的一个或两个轴，不递归编排；Lead 核对工具事实并维护正式 Evidence。
 
 ## 标准轴
 
-输入仅包含固定 diff/log（source-files 为固定文件快照）、标准来源和 Fowler baseline。报告仓库规则违规和判断性 smell，引用来源与代码块，区分 hard violation 与 heuristic，并跳过工具链已强制执行的纯格式项。
+依据固定 diff/log 或完整工作副本/文件快照、仓库标准和 Fowler baseline，检查正确性、可维护性及适用风险。引用来源与代码块，区分 hard violation 和 heuristic，跳过工具链已强制执行的纯格式项。
 
 ## 规范轴
 
-输入仅包含固定 diff/log（source-files 为固定文件快照）与规范来源。报告缺失或不完整需求、超出范围行为和语义/失败/边界错误，并引用具体规范来源。
+依据同一固定代码输入和实际规范，检查缺失或不完整需求、超范围行为、失败与边界语义；引用具体 AC、合同或决定。
+
+## 结果
+
+同一 reviewer 可以读取两轴依据，但必须分别判断并按 standards、specification 顺序返回，不用一轴结论替代另一轴。两位 reviewer 时分别派发所属轴，汇总前不共享 findings。汇总者只整理格式，不删除或跨轴合并、重排发现，不设置任意字数或 finding 上限。
 
-## 隔离与结果
+每轴返回 `pass | request-changes | skipped`。标准轴不可跳过；C 经来源发现确认没有规范时可 `skipped:no-spec`，不能宣称完整双轴通过。I 始终有 Spec/Ticket 或轻量 README 合同，两轴必须 pass。
 
-平台支持独立 reviewer 时可并行；否则创建两个不共享发现的完整输入包并顺序执行。汇总者只整理格式，不删除、合并或跨轴重排 finding。每轴独立返回 `pass | request-changes | skipped`；一轴通过不抵消另一轴失败。
+执行与复用都按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 保存独立性和固定输入证据。

package/template/workflows/specdev/common/skills/code-review/references/working-tree-review.md

@@ -0,0 +1,15 @@
+# 未提交工作副本审查
+
+I 的 Direct Spec current 未获提交授权时使用本分支。它覆盖实际交付差异，不以 HEAD 代替未提交内容；C 的 source-files 仍只承诺指定文件阅读。
+
+1. 停止相关 writer，回读实施前 Git 基线、原有 dirty 改动、当前授权写集与实际变更。确认项目 Git 根；无已存在的基线、冲突 index、不可读取文件或不支持的子模块时保持未验证，不伪造提交。
+2. 调用以下只读工具。`--file` 可重复，使用已核对的完整交付文件清单，包含删除路径；不传时覆盖相对基线的全部实际变化和非忽略未跟踪文件。只读冻结不创建 commit、不暂存、不修改 index。
+3. 保存完整返回值，审查 `working_snapshot` 的新增/修改/删除/类型及权限变化。`tracked_diff_command` 只展示 Git 已跟踪部分；新增文件读取快照对应实际字节，删除读取基线对象，二进制和符号链接分别检查实际格式/链接语义。不得因为 diff 为空忽略未跟踪新增。
+4. 使用显式范围时回读 `excluded_paths`，在输入 exclusions 中说明原有用户改动、报告等排除依据；实现范围不能排除。审查输入、原报告和 Evidence 本身放在范围外，避免自引用。原有改动不自动成为本轮可写内容。
+5. 交给未参与实现的 reviewer，结束及完成声明前重跑相同选择并核对全部范围内字节、模式、基线和 index。显式范围外新增的报告不使代码审查失效，但 Lead 仍须核实没有遗漏实现。发生范围内漂移、规范/标准/指令变化或新实现文件，重建输入并补审。
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> --review-scope --repo <project-root> --mode working-tree --base <implementation-baseline-sha> --file <project-relative-file>
+```
+
+输出的 observed_head 只记录观察到的 Git HEAD，working_snapshot/input_sha256 才标识未提交内容。无法验证的二进制、生成物或外部环境如实报告，不宣称两轴或整个 change 已完成。

package/template/workflows/specdev/common/skills/dev-worktree/SKILL.md

@@ -1,32 +1,32 @@
 ---
 name: dev-worktree
-description: 管理 SpecDev required Ticket 的 Git worktree；创建隔离来源 workspace、固定实现 commit，并由 Lead 在 parent-candidate checkout 验证后推进父分支。
+description: 管理 SpecDev required Ticket 或 Direct Spec change 的 Git worktree；创建隔离来源 workspace、固定实现 commit，并由 Lead 在 parent-candidate checkout 验证后推进父分支。
 compatibility: Requires the owning Speculo workflow and its workspace path resolver.
 ---
 
 # Dev Worktree
 
-本 Skill 由 T-tickets、P-goal-plan 和 I-implement 复用。仅在 Goal Plan 选择 `required` 时使用完整 source → candidate → parent 状态机；`current` Ticket 不调用本 Skill。
+本 Skill 由 T-tickets、P-goal-plan 和 I-implement 复用。按 <Path>{roots.workflows}/specdev/common/rules/execution-policy.md</Path> 选择 `required` 时使用 source → candidate → parent 状态机，无需先建 Goal；`current` 不调用本 Skill。原生执行与 Herdr 使用同一工作区合同。
 
 ## 输入
 
 - `operation=create | restore | finalize | remove`；
-- `purpose=ticket`；
+- `purpose=ticket | direct-spec`；
 - repository、父分支、`base_sha`、branch、portable workspace locator；
 - workspace、implementation 和 integration owner；
 - 允许动作、路径合同、验证合同、调用方状态记录位置。
 
-required Ticket 还必须提供 Ready Ticket、Goal Plan（若存在）、Evidence 路径、implementation commit 与本地 candidate integration/父分支更新授权。缺失时返回 blocked；current Ticket 应按 I-implement 的 direct-parent 规则执行。
+required Ticket 提供 Ready Ticket；Direct Spec 提供获批完整规格及验证合同。两者都提供实际存在的 Goal/父计划、原 Evidence 路径、Lead、尝试上限来源、implementation commit 与 local candidate integration/父分支更新授权。缺失时返回 blocked；不为这些输入补造 Ticket/Goal。
 
 ## 1. 创建或恢复
 
-`operation=create` 时加载 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/references/create.md</Path>`。Ticket 使用 `specdev-worktree/<ticket-id>`；同一 Ticket 只存在一个来源 worktree。`operation=restore` 时重读实际 Git worktree/branch/tip/dirty 状态并与调用方记录核对，漂移时停止。
+`operation=create` 时加载 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/references/create.md</Path>`。Ticket 使用 `specdev-worktree/<change>/<ticket-id>`；Direct Spec 使用 `specdev-worktree/<change>/direct-spec`。每个实现单元只有一个来源 worktree。`operation=restore` 时重读实际 Git worktree/branch/tip/dirty 状态并与调用方记录核对，漂移时停止。
 
 **完成标准**：来源基线、branch、locator、owners 和实际 Git 状态一致；现有用户改动未被覆盖。
 
 ## 2. 来源实现门
 
-implementation owner 只在来源 worktree 修改授权项目路径，运行 Ticket 要求的单元、组件、静态、类型、lint/build 等非 E2E 检查。进入 `review` 前，worktree 必须 clean，branch tip 必须是已授权的 `source_checkpoint` commit，实际 diff 必须符合路径合同。
+implementation owner 只在来源 worktree 修改授权项目路径，运行规格或 Ticket 要求的单元、组件、静态、类型、lint/build 等非 E2E 检查。进入 `review` 前，worktree 必须 clean，branch tip 必须是已授权的 `source_checkpoint` commit，实际 diff 必须符合路径合同。
 
 **完成标准**：source checkpoint 不可变且可达；来源 worktree 没有 E2E pass 声明。
 
@@ -36,18 +36,18 @@ implementation owner 只在来源 worktree 修改授权项目路径，运行 Tic
 
 本地 candidate checkout/branch 的创建、重建和回收属于已授权 local candidate integration；来源 branch/worktree 的删除仍需要独立 cleanup 授权。push、PR、remote merge、deploy、migration 和生产动作不从本 Skill 继承。
 
-**完成标准**：Ticket `integrated` 时父 HEAD 精确等于记录的 result SHA，并包含 source checkpoint；失败或 stale 时父分支未变化。后续 `removed` 只表示来源 branch/worktree 已清理，不撤销该集成事实。
+**完成标准**：执行单元 `integrated` 时父 HEAD 精确等于记录的 result SHA，并包含 source checkpoint；失败或 stale 时父分支未变化。后续 `removed` 只表示来源 branch/worktree 已清理，不撤销该集成事实。
 
 ## 4. 移除
 
-`operation=remove` 先验证 Ticket 已 `integrated`、目标 worktree clean、checkpoint 可恢复且删除目标精确。只有明确 cleanup 授权时删除来源 branch/worktree；强制删除需要单独确认。删除后重读 `git worktree list` 与 refs，并只把调用方生命周期状态更新为 `removed`；`base_sha`、source checkpoint、candidate/result、验证、E2E 与 Evidence 字段必须原样保留。
+`operation=remove` 先验证执行单元已 `integrated`、目标 worktree clean、checkpoint 可恢复且删除目标精确。只有明确 cleanup 授权时删除来源 branch/worktree；强制删除需要单独确认。删除后重读 `git worktree list` 与 refs，并只把调用方生命周期状态更新为 `removed`；`base_sha`、source checkpoint、candidate/result、验证、E2E 与 Evidence 字段必须原样保留。
 
 **完成标准**：只删除精确授权目标；失败保留现场与恢复命令。
 
 ## 固定规则
 
-- Agent Team 不决定 worktree；Ticket 切片本身决定来源 worktree；
-- Ticket E2E 只在 Lead-owned parent-candidate checkout 运行；
-- 每个 Done Ticket 必须有 source commit 与父分支 result，worktree 状态为 `integrated` 或其清理后终态 `removed`；
+- 执行方式与工作区正交；获批策略决定是否使用 worktree，Ticket 或 Direct Spec change 决定工作单元；
+- required E2E 只在 Lead-owned parent-candidate checkout 运行；
+- 每个 required 实现单元完成前必须有 source commit 与父分支 result，worktree 状态为 `integrated` 或其清理后终态 `removed`；
 - candidate 失败保留来源 worktree 修正，父分支不动；
 - 成功集成不自动清理来源 branch/worktree。

package/template/workflows/specdev/common/skills/dev-worktree/references/create.md

@@ -1,22 +1,24 @@
 # Create Or Restore Worktree
 
-## Ticket 前置条件
+## 前置条件
 
-- Ticket Ready，项目根是有效 Git repository，父分支和 `base_sha` 可解析；
+- Ticket Ready 或完整 Direct Spec 已获批且规格就绪，项目根是有效 Git repository，父分支和 `base_sha` 可解析；
 - implementation commit 与 local candidate integration/父分支更新已授权；
 - workspace、implementation、integration owner 唯一；integration owner 必须为 Lead；
-- `specdev-worktree/` 已由 Speculo init 加入项目 `.gitignore`；
+- 检查 `specdev-worktree/` 已被 Git ignore；未初始化项目由当前 I 在授权写集内补充该忽略规则并记录，不能强制运行 init；
 - 目标 branch/worktree 不覆盖现有用户 workspace，路径合同无冲突。
 
-## 创建 Ticket 来源 worktree
+## 创建来源 worktree
+
+先确定 `unit-id`：Ticket 使用真实 ID（如 T-01），Direct Spec 固定为 `direct-spec`；change 使用已解析的 change 名。下列路径由两者共同限定。
 
 1. 重读父分支 HEAD、工作树、现有 worktrees 与 refs；父 HEAD 与计划基线不一致时由 Lead决定更新 `base_sha` 或阻塞；
-2. 固定 branch `speculo/<change>/<ticket-id>` 与 locator `specdev-worktree/<ticket-id>`；
-3. 确认目标 branch/path 不存在，或其实际记录精确匹配当前 Ticket；
-4. 从 `base_sha` 创建 Git worktree，不复用其他 Ticket 目录；
+2. 固定 branch `speculo/<change>/<unit-id>` 与 locator `specdev-worktree/<change>/<unit-id>`；
+3. 确认目标 branch/path 不存在，或其实际记录精确匹配当前实现单元；
+4. 从 `base_sha` 创建 Git worktree，不复用其他实现单元目录；
 5. 在来源 worktree 读取项目 Agent 指令、依赖、构建与路径合同；
 6. 安装实际需要的依赖，运行最小非 E2E 基线；
-7. Lead 将实际 workspace、owner、checkpoint 和 `status: active` 记录在该票 Evidence 的 `## Workspace Execution Record` 唯一 JSON object 中，保留原执行字段；不创建全局 worktree 镜像。
+7. Lead 将实际 workspace、owner、checkpoint 和 `status: active` 记录在本单元原 Evidence 的 `## Workspace Execution Record` 唯一 JSON object 中，保留原执行字段；不创建全局 worktree 镜像。
 
 初始记录：
 
@@ -30,29 +32,35 @@
   "base_sha": "<immutable-sha>",
   "parent_branch": "<parent-branch>",
   "branch": "speculo/<change>/T-01",
-  "workspace_ref": "specdev-worktree/T-01",
+  "workspace_ref": "specdev-worktree/<change>/T-01",
   "source_checkpoint": null,
   "integration": {
     "status": "pending",
+    "parent_ref": "<parent-branch>",
     "parent_before_sha": null,
     "source_sha": null,
     "candidate_sha": null,
+    "candidate_tree_sha": null,
     "candidate_branch": null,
     "candidate_workspace_ref": null,
     "result_sha": null,
     "method": null,
     "conflict_paths": [],
     "verification": "pending",
-    "e2e": {"required": false, "status": "not-required", "evidence": null},
+    "full_suite": {"required": true, "status": "pending", "reason": null, "evidence": null},
+    "e2e": {"required": false, "status": "not-required", "reason": "实际范围无端到端风险时填写依据", "evidence": null},
     "evidence": "<Path>{roots.state}/specdev/changes/<change>/evidence/T-01.md</Path>",
-    "attempts": 0
+    "attempts": 0,
+    "promotion_status": "pending"
   },
   "status": "active",
   "updated_at": "<ISO-8601>"
 }
 ```
 
-`e2e.required` 与 Ticket/Goal Plan disposition 一致；required 时初始 status 为 `pending`。
+Direct Spec 将 `ticket_id` 替换为 `purpose: "direct-spec"`、`change: "<change>"`、`integration_attempt_limit: <实际正整数上限>`；branch 与 workspace 的单元部分替换为 direct-spec，integration.evidence 指向 <Path>{roots.state}/specdev/changes/{change}/evidence/direct-spec.md</Path>。不额外创建 Ticket。
+
+`full_suite` 与 `e2e` 的 required/reason 依据 Spec/Ticket/有效计划的实际验证合同；required 初始为 pending，not-required 必须给真实理由。未发生操作不预填通过。
 
 ## 恢复
 

package/template/workflows/specdev/common/skills/dev-worktree/references/finalize.md

@@ -1,27 +1,27 @@
 # Candidate Merge And Parent Integration
 
-仅由 Lead/integration owner 对状态为 `review` 的 Ticket 调用。
+仅由 Lead/integration owner 对处于 review 的 Ticket 或 Direct Spec 执行单元调用。Ticket 状态来自原票；Direct Spec 状态来自原 Evidence 的 Workspace Execution Record。unit-id 为真实 Ticket ID 或 direct-spec。
 
 ## 1. 接收 source checkpoint
 
-1. 核对 Ticket、Goal Plan、Evidence 目标、owner 与本地 integration 授权；
+1. 核对获批 Spec/Ready Ticket、实际存在的计划、Evidence 目标、owner 与本地 integration 授权；
 2. 验证来源 worktree clean，branch tip 精确等于 `source_checkpoint`，commit 从 `base_sha` 可达；
 3. 审计实际 diff 未越过 writable/shared owner 合同；
 4. 确认 source-worktree 必跑非 E2E 检查已执行，且没有把 E2E 自报为通过；
 5. 重读父分支 checkout clean、HEAD 与 remote/本地约定，记录 `parent_before_sha`。
 
-建立新 candidate 前先比较 Ticket `attempts` 与有效 Plan 的 `integration_attempt_limit`。若前一轮尚未通过且当前 attempts 已达到上限，不创建或重建 candidate、不增加 attempts；保留 source workspace、旧 candidate 与失败记录，将 Ticket/worktree 标为 `blocked`，向有效 Lead 返回 `integration-attempt-limit`。
+建立新 candidate 前先比较原记录 `attempts` 与有效 Plan 或无 Goal 执行合同的 `integration_attempt_limit`。若前一轮尚未通过且当前 attempts 已达到上限，不创建或重建 candidate、不增加 attempts；保留 source workspace、旧 candidate 与失败记录，将执行记录及已有 Ticket 标为 `blocked`，向有效 Lead 返回 `integration-attempt-limit`。
 
 其他预检失败时保持 `review`/`blocked`，不开始候选合并。
 
 ## 2. 建立 parent-candidate checkout
 
-1. 使用 branch `speculo/integration/<change>/<ticket-id>` 和 locator `specdev-worktree/.integration/<ticket-id>`，从最新 `parent_before_sha` 建立 Lead-owned integration worktree；
+1. 使用 branch `speculo/integration/<change>/<unit-id>` 和 locator `specdev-worktree/.integration/<change>/<unit-id>`，从最新 `parent_before_sha` 建立 Lead-owned integration worktree；
 2. 如果父 SHA 是 source checkpoint 的祖先，在 candidate checkout 执行 `git merge --ff-only <source_checkpoint>`，`method=fast-forward`；
 3. 否则执行 `git merge --no-ff --no-commit <source_checkpoint>`；
 4. 冲突按 `<Path>{roots.workflows}/specdev/specdev-i-implement/references/merge-conflict-protocol.md</Path>` 处理。需要新产品决定时执行 `git merge --abort`，记录 blocker 并返回来源 worktree；
 5. 对分叉结果创建一次 Lead-owned candidate merge commit，`method=merge-commit`；
-6. 记录 candidate branch/locator、`candidate_sha`、`source_sha`、冲突路径与 attempts，worktree 状态改为 `integrating`、integration 状态改为 `candidate`。
+6. 记录 candidate branch/locator、`candidate_sha`、实际 Git tree SHA `candidate_tree_sha`、`source_sha`、冲突路径与 attempts，worktree 状态改为 `integrating`、integration 状态改为 `candidate`。
 
 重试前从最新父分支重建 candidate branch/worktree；旧 candidate SHA 保存在 Evidence。候选生命周期的重建/回收包含在 local candidate integration 授权中。
 
@@ -29,11 +29,13 @@
 
 在 candidate checkout 运行：
 
-- Ticket 受影响集成与回归；
+- 当前实现单元受影响集成与回归；
 - 项目要求的 typecheck/lint/build 或其他父状态检查；
-- 仅当 Ticket/Goal Plan `e2e.required=true` 时运行对应 E2E。
+- 仅当 Spec/Ticket/有效执行合同 `e2e.required=true` 时运行对应 E2E。
 
-每条命令记录运行环境 `parent-candidate`、退出码与摘要。E2E required 未运行或失败时 integration `verification=failed`、`status=failed`；父分支保持 `parent_before_sha`。当本轮失败使 attempts 达到 Goal Plan 快照的 `integration_attempt_limit` 时，保存本轮失败并返回 Lead 复盘；不得继续机械修正、放宽断言、删除检查或发明行为。上限是 Lead 复盘触发点，不是永久禁止恢复。
+每条命令记录运行环境 `parent-candidate`、退出码与摘要。E2E required 未运行或失败时 integration `verification=failed`、`status=failed`；父分支保持 `parent_before_sha`。当本轮失败使 attempts 达到有效执行合同的 `integration_attempt_limit` 时，保存本轮失败并返回 Lead 复盘；不得继续机械修正、放宽断言、删除检查或发明行为。上限是 Lead 复盘触发点，不是永久禁止恢复。
+
+候选的代码、规范或相关配置与已审输入不同，尤其发生合并或冲突修正时，按 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path> 在此实际 candidate 上完成独立双轴审查。修正合并冲突的 Lead/Agent 也属于实现者；两轴通过前不得推进。完全相同的输入沿原证据复用门核对，不以 source 检查代替 candidate 审查。
 
 ## 4. 推进父分支
 
@@ -42,13 +44,13 @@
 1. 重读父分支 HEAD；不等于 `parent_before_sha` 时将 candidate 标记 `stale`，不推进父分支并从步骤 2 重建；
 2. 在父分支 checkout 执行 `git merge --ff-only <candidate_sha>`；候选 merge commit 本身已以父 SHA 为第一祖先，因此不再创建第二个 merge commit；
 3. 重读父 HEAD、tree 与 ancestor 关系，确认 HEAD 精确等于 candidate SHA 且包含 source checkpoint；
-4. 写入 `result_sha=candidate_sha`、`verification=passed`、E2E 最终状态和 Evidence；
-5. integration/status 改为 `passed`/`integrated`，再由 Lead 标记 Ticket Done。
+4. 写入 `result_sha=candidate_sha`、`verification=passed`、full_suite/E2E 最终状态、`promotion_status=applied` 和 Evidence；
+5. integration/status 改为 `passed`/`integrated`，再由 Lead 标记 Ticket Done 或在 Direct Spec 全部 AC 通过后完成 change。
 
 ## 5. 失败、清理与恢复
 
-- candidate 检查失败：父分支不动，Ticket 回 `in_progress` 或 `blocked`，来源 worktree 保留；
-- 达到 integration attempt 上限：保留全部 source/candidate checkpoint 与失败记录，等待 Lead 在 Ticket Evidence 写明共同失败模式、最可能原因、下一轮改变和下一 owner/路由；只有形成有实质变化的新 Dispatch Packet 后，Lead 才可将当前 Ticket `attempts` 重置为 `0` 并重新进入 finalize；
+- candidate 检查失败：父分支不动，已有 Ticket 回 `in_progress` 或 `blocked`，来源 worktree 保留；
+- 达到 integration attempt 上限：保留全部 source/candidate checkpoint 与失败记录，等待 Lead 在原 Evidence 写明共同失败模式、最可能原因、下一轮改变和下一 owner/路由；只有形成有实质变化的新 Dispatch Packet 后，Lead 才可将当前执行记录 `attempts` 重置为 `0` 并重新进入 finalize；
 - 父 HEAD 漂移：旧 candidate 记 `stale`，完整重建并重跑；
 - 成功后可按 candidate integration 授权回收 transient integration worktree/branch；来源 branch/worktree 不自动清理。获得独立 cleanup 授权并清理后，只将生命周期状态改为 `removed`，完整保留已经通过的集成与 E2E 证据；
 - push、PR、remote merge、deploy、migration 和生产动作仍需各自授权。

package/template/workflows/specdev/common/tools/README.md

@@ -4,7 +4,7 @@
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage <triage|diagnosis|grill|spec|tickets|goal-plan|implement|learn-change|retro|pr-delivery|review|prototype|wayfinder|complete|archive-ready|archived> \
+  --stage <triage|diagnosis|grill|spec|tickets|goal-plan|implement|learn|retro|pr-delivery|review|prototype|wayfinder|complete|archive-ready|archived> \
   --repo <project-root> \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
@@ -46,6 +46,8 @@ node <Path>{roots.workflows}/specdev/common/tools/ticket-control.mjs</Path> --ma
 
 `<Path>{roots.workflows}/specdev/common/tools/plan-contract.mjs</Path>` 是两个工具共用的只读校验库：新 Ticket 的真实 Skill 名称/摘要、必需调用证据、Map 数量合同、父入口与 W 候选图。普通 --repo 仍支持原 Git 事实验证；存在未完成票的真实项目 Skill 绑定时必须提供项目根。Ticket/Map 必须满足当前 Plan 合同；已完成历史证据不要求当前 Skill 包仍与历史版本相同。
 
+`--stage complete` 与移动前的 `--stage archive-ready` 对实现型终点校验独立审查：实际实现者与 reviewer 身份、两轴原报告、Lead 工具核验、固定范围及权威规格来源必须一致。轻量完成预检只核对 AC/owner，代码交付仍进入完整门；学习、复盘和取消使用各自终点。已归档材料按历史读取，不以当前代码重做旧审查。格式校验不能证明真实 Agent 调用。
+
 ## 专业分支与审查固定点
 
 原 change 校验支持 `--engineering performance|documentation|incident`，要求对应原 owner 工件中的标记证据；不传时仍检查已经存在的标记。字段见 <Path>{roots.workflows}/specdev/common/rules/engineering-evidence.md</Path>。历史无标记工件不强制回填，所有路径只读。
@@ -69,3 +71,9 @@ UI 原型阶段用 --stage prototype --prototype-id UI-NNN；逻辑原型可指
 本地完成使用 `--stage complete`；移动前使用 `--stage archive-ready`，额外核验本次实际请求的外部交付。A 完成现役维护后最后无覆盖移动，再以 `--stage archived` 核验唯一目标与原回执；`moved` 结果明确尚未封存，原 A8 回执完成后用 `--stage archived --sealed` 验证。回执导航与完整移动清单依 <Path>{roots.workflows}/specdev/specdev-a-archive-and-consolidate/references/archive-receipt-contract.md</Path>，不能创建第二份报告。
 
 历史已完成/已归档包不自动重写；旧 v6 归档只读解析原完整 schema、身份和位置，不凭 archived 枚举批准新的 implemented 晋升。旧活动 UI 包应保留为证据，按 v3 新建 UI 编号、生成新 HTML/浏览器证据并重新确认。不能只把旧 schema 数字或 ready 标记改成新版。
+
+## 未提交交付的只读审查范围
+
+`--review-scope --repo <project-root> --mode working-tree --base <baseline-sha> [--file <relative-path> ...]` 固定真实 Git 根的工作副本。无 file 参数覆盖全部相对基线的变化和非忽略新增；显式 file 包含删除路径，排除项返回供 Lead 核对。输出保留已暂存/未暂存状态、实际内容摘要、类型、模式、链接、基线和观察到的 HEAD，不写项目文件、commit 或 index。
+
+新增文件必须按 working_snapshot 阅读，不能只看 tracked_diff_command。子模块、冲突 index、越界或目录链接保持未验证。停止 writer 后固定输入，结束与完成前重验；显式范围外新增报告不使代码摘要自引用，遗漏实现仍由 Lead 的完整范围审计阻塞。详见 <Path>{roots.workflows}/specdev/common/skills/code-review/references/working-tree-review.md</Path> 与 <Path>{roots.workflows}/specdev/common/skills/code-review/references/review-evidence.md</Path>。

package/template/workflows/specdev/common/tools/change-artifacts.mjs

@@ -2,6 +2,7 @@
 import { existsSync, readdirSync } from 'node:fs';
 import { createHash } from 'node:crypto';
 import { basename, join } from 'node:path';
+import { readChangeExecution } from './plan-contract.mjs';
 import {
   readChangeFactsSync, readArtifactSectionSync, readUtf8ArtifactSync,
   safeWorkPathSync, markdownBodyLines, parseFrontmatter,
@@ -105,16 +106,9 @@ function validateCancellation(facts, owner, errors) {
     }
   }
   for (const key of ['Dependencies','Checkpoints','External']) if (!/^(?:none|resolved|transferred|waived): \S/.test(data[key] ?? '')) errors.push(`closure-evidence-missing: ${facts.readmePath}: unresolved ${key}`);
-  const tickets = safeWorkPathSync(root, 'evidence', { type: 'directory' });
-  if (existsSync(tickets)) for (const file of readdirSync(tickets).filter(n => /^T-\d+\.md$/.test(n))) {
-    const path = safeWorkPathSync(tickets, file, { type: 'file', mustExist: true }), text = readUtf8ArtifactSync(path);
-    const blocks = [...text.matchAll(/^## Workspace Execution Record\r?\n([\s\S]*?)(?=^## |$(?![\s\S]))/gm)];
-    for (const block of blocks) {
-      const json = /```json\s*\n([\s\S]*?)\n```/.exec(block[1]);
-      if (!json) error('closure-evidence-missing', path, 'invalid workspace execution record');
-      const record = JSON.parse(json[1]);
-      if (['active','review','integrating','blocked'].includes(record.status)) errors.push(`writer-active: ${path}: cancellation does not end an execution owner or candidate`);
-    }
+  for (const record of readChangeExecution(root)) {
+    if (record.purpose === "direct-spec" && record.status === "cancelled" && !/^stopped: \S/.test(data.Writers ?? "")) errors.push(`writer-active: ${root}: cancelled Direct Spec execution requires observed stopped writer evidence`);
+    if (['active','review','integrating','blocked'].includes(record.status)) errors.push(`writer-active: ${root}: ${record.ticket_id ?? 'direct-spec'} cancellation does not end an execution owner or candidate`);
   }
 }
 export function validateArchiveDelivery(changeRoot) {
@@ -152,8 +146,11 @@ export function validateChangeClosure({context, change, forArchive = false}) {
       const goalPath = safeWorkPathSync(root, 'goal-plan.md', {type:'file'});
       const lightweightGoal = existsSync(goalPath) && parseFrontmatter(readUtf8ArtifactSync(goalPath)).fields.artifact === 'lightweight-goal-plan';
       const independent = ['spec.md','ticket','tickets-map.md','implementation-plan.md','implementation-map.md','retro',...(!lightweightGoal ? ['goal-plan.md'] : [])].some(name => existsSync(join(root, name)));
-      const complex = independent || ['DESIGN.md','prototypes'].some(name => existsSync(join(root,name)));
+      const complex = independent || readChangeExecution(root).length > 0 || ['DESIGN.md','prototypes'].some(name => existsSync(join(root,name)));
       scope = complex ? 'complex-preflight' : 'lightweight';
+      // AC checks are preflight only. The full validator distinguishes actual
+      // implementation from learning/triage using original Work ownership.
+      scope = 'complex-preflight';
       if (!independent && facts.outcome === 'completed') {
         validateLightweightCompletion(root, errors);
         if (lightweightGoal) {