@namewta/speculo 0.1.21 → 0.2.0

package/template/workflows/dev/R-review/R-review.md

@@ -1,75 +0,0 @@
----
-id: dev/R-review
-category: dev
-name: Review
-description: 从固定比较点开始，按 Spec、Engineering、Standards 三个独立维度审查当前 diff，并给出带严重度的裁决
-keywords: [review, diff, spec, engineering, standards, security, solid, pr, 审查]
----
-
-# Review 工作流执行指引
-
-本工作流是 `dev/R` 入口，用于审查 `HEAD` 与用户提供的固定点之间的 diff。审查以**资深工程师视角**进行，结果必须分成三个**互相独立、互不掩盖**的维度，每条 finding 带严重度，最后给出整体裁决。
-
-> **目录命名：** `<change>` 必须为 `YYYY-MM-DD-<kebab-name>`（例：`2026-06-12-review-auth-module`）。审查产物写入 `speculo/.speculo/dev/<change>/`。
-
-## 何时使用
-
-当用户想审查分支、PR、进行中的变更，或要求 `review since <fixed-point>` 时使用。
-
-## 三个审查维度
-
-| 维度 | 问题 | 关注 |
-|------|------|------|
-| **Spec** | 做对了吗？ | 是否忠实实现来源 issue / PRD / spec |
-| **Engineering** | 做好了吗？ | 工程质量：SOLID、安全、错误处理、性能、边界、死代码 |
-| **Standards** | 合规吗？ | 是否违反仓库已记录的标准 |
-
-详细严重度模型、独立进入流程与来源深度搜索见 `review-setup.md`。
-
-## 阶段
-
-| Phase | id | agent | 规范 | 模板 | 产物 |
-|-------|-----|-------|------|------|------|
-| 1. Review Setup | `review-setup` | — | `review-setup.md` | `../_templates/review-sources-template.md` | `review-sources.md` |
-| 2. Multi-Axis Review | `multi-axis-review` | `agents/spec-review-agent.md`、`agents/engineering-review-agent.md`、`agents/standards-review-agent.md` | `review-axes.md` | `../_templates/review-report-template.md` | `review-report.md` |
-| 3. Verdict & Next Steps | `verdict-next-steps` | — | `review-verdict.md` | `../_templates/review-verdict-template.md` | `review-verdict.md` |
-
-### 1. Review Setup — 固定点、范围与来源收集
-- id：`review-setup`
-- 完成准则：fixed point、diff 命令、来源清单已记录；`review-sources.md` 无残留 `[TODO:]`
-
-### 2. Multi-Axis Review — 三维度审查
-- id：`multi-axis-review`
-- 完成准则：三维度分区独立呈现；每条 finding 带 P0–P3 严重度；`review-report.md` 无残留 `[TODO:]`
-
-### 3. Verdict & Next Steps — 裁决与后续确认
-- id：`verdict-next-steps`
-- 完成准则：整体裁决与 clean-review 声明已给出；未经确认不实施修复；`review-verdict.md` 无残留 `[TODO:]`
-
-## 依赖
-
-- 硬依赖：无；用户提供 fixed point 即可进入
-- 软依赖：同 change 下若有 `prd.md`、`slices.md` 等可继承增强 Spec 维度；缺失时自行采集，不阻塞流程
-
-## 状态扩展字段
-
-- `dev_entry` (string) — 固定为 `dev/R`
-- `review_fixed_point` (string)
-- `review_diff_command` (string)
-- `review_axes` (array) — `spec` | `engineering` | `standards`
-- `standards_sources` (array)
-- `spec_sources` (array)
-- `severity_summary` (object) — `{ "p0": n, "p1": n, "p2": n, "p3": n }`
-- `review_verdict` (approve | request_changes | comment | null)
-- `review_status` (collecting | reviewing | judged | completed | blocked)
-
-## 完成与状态更新
-
-- 进入每个 phase 时更新 `current_phase` 和 `phase_history`。
-- 完成 setup 后写入 fixed point、diff 命令、`review_axes` 和来源清单。
-- 完成报告后更新 `severity_summary`，置 `review_status: judged`。
-- 完成裁决后写入 `review_verdict`，置 `review_status: completed`；不自动完成 change —— 是否进入修复（`../03-tdd/03-tdd.md`）、收尾（`../04-finalize/04-finalize.md`）由用户决定。
-
-### 缺少 change 目录时
-
-若无 active change，执行 `../AGENTS.md` 进入协议步骤 3（原子三步），不得内联自初始化 JSON。

package/template/workflows/dev/R-review/agents/engineering-review-agent.md

@@ -1,33 +0,0 @@
----
-id: dev/R-review/engineering-review-agent
-type: agent
-name: Engineering Review Agent
-description: 隔离执行 Engineering 维度审查：做好了吗
----
-
-## 使命
-
-独立审查 diff 的 Engineering 维度：SOLID、安全、错误处理、性能、边界、死代码。
-
-## 输入契约
-
-- change 路径：`speculo/.speculo/dev/<change>/`
-- `current_phase` / phase-id：`multi-axis-review`
-- 上游产物：`review-sources.md`
-- 清单：`../solid-checklist.md`、`../security-checklist.md`、`../code-quality-checklist.md`、`../removal-checklist.md`
-
-## 执行规范
-
-- 使用 `review-sources.md` 中的 diff 命令。
-- Engineering 维度始终执行，不依赖外部 spec。
-- 按需读取同目录清单；每条 finding 带 P0–P3 严重度与清单引用。
-- 产出写入 `review-report.md` 的 Engineering 分区。
-
-## 产物与状态
-
-- 产物：`review-report.md`（Engineering 分区）
-- `.status.json`：追加 `review_axes` 含 `engineering`；更新 `severity_summary`
-
-## 边界
-
-- 只写 Engineering 分区；不修改代码；不写 `change_status`；不产出最终 verdict。

package/template/workflows/dev/R-review/agents/spec-review-agent.md

@@ -1,34 +0,0 @@
----
-id: dev/R-review/spec-review-agent
-type: agent
-name: Spec Review Agent
-description: 隔离执行 Spec 维度审查：做对了吗
----
-
-## 使命
-
-独立审查 diff 的 Spec 维度：是否忠实实现来源 issue / PRD / spec。
-
-## 输入契约
-
-- change 路径：`speculo/.speculo/dev/<change>/`
-- `current_phase` / phase-id：`multi-axis-review`
-- 上游产物：`review-sources.md`（fixed point、diff 命令、spec 来源）
-- 规范：`../review-axes.md`（Spec 分区）
-
-## 执行规范
-
-- 使用 `review-sources.md` 中的 diff 命令与 spec 来源。
-- 无 spec 时报告 `no spec available`，不编造需求。
-- 每条 finding 带 P0–P3 严重度、文件/行依据与 spec 引用。
-- 产出写入 `review-report.md` 的 Spec 分区（与 Engineering、Standards 分区独立）。
-
-## 产物与状态
-
-- 产物：`review-report.md`（Spec 分区）
-- `.status.json`：追加 `review_axes` 含 `spec`；更新 `severity_summary`
-
-## 边界
-
-- 只写 Spec 分区；不合并或重排其他维度 findings。
-- 不修改代码；不写 `change_status`；不产出最终 verdict。

package/template/workflows/dev/R-review/agents/standards-review-agent.md

@@ -1,34 +0,0 @@
----
-id: dev/R-review/standards-review-agent
-type: agent
-name: Standards Review Agent
-description: 隔离执行 Standards 维度审查：合规吗
----
-
-## 使命
-
-独立审查 diff 的 Standards 维度：是否违反仓库已记录的标准。
-
-## 输入契约
-
-- change 路径：`speculo/.speculo/dev/<change>/`
-- `current_phase` / phase-id：`multi-axis-review`
-- 上游产物：`review-sources.md`（standards 来源清单）
-- 规范：`../review-axes.md`（Standards 分区）
-
-## 执行规范
-
-- 使用 `review-sources.md` 中的 diff 命令与 standards 来源。
-- 无成文标准时报告覆盖空白，不把缺失当作无问题。
-- 机器已强制的标准（lint / 类型）只记录来源，不重复人工检查。
-- 每条 finding 带 P0–P3 严重度与标准引用。
-- 产出写入 `review-report.md` 的 Standards 分区。
-
-## 产物与状态
-
-- 产物：`review-report.md`（Standards 分区）
-- `.status.json`：追加 `review_axes` 含 `standards`；更新 `severity_summary`
-
-## 边界
-
-- 只写 Standards 分区；不修改代码；不写 `change_status`；不产出最终 verdict。

package/template/workflows/dev/R-review/code-quality-checklist.md

@@ -1,118 +0,0 @@
-# 代码质量清单
-
-服务 `R-review.md` 的 **Engineering 维度**。审查 diff 的错误处理、性能与边界条件时读取本文。重点标记会导致**静默失败**或**生产事故**的问题，并按下方"严重度提示"定级。
-
-## 错误处理
-
-### 需要标记的反模式
-
-- **吞掉异常**：空 catch，或只打日志的 catch
-  ```javascript
-  try { ... } catch (e) { }            // 静默失败
-  try { ... } catch (e) { console.log(e) }  // 打了日志就不管
-  ```
-- **过宽的 catch**：捕获 `Exception` / `Error` 基类而非具体类型
-- **错误信息泄露**：把堆栈或内部细节暴露给用户
-- **缺少错误处理**：可失败操作（I/O、网络、解析）周围没有 try-catch
-- **异步错误处理**：未处理的 promise rejection、缺 `.catch()`、无 error boundary
-
-### 应核对的最佳实践
-
-- [ ] 错误在恰当的边界被捕获
-- [ ] 错误信息对用户友好（不暴露内部细节）
-- [ ] 错误带足够上下文记录，便于调试
-- [ ] 异步错误被正确传播或处理
-- [ ] 可恢复错误有定义好的兜底行为
-- [ ] 关键错误触发告警 / 监控
-
-### 追问
-- "这个操作失败时会发生什么？"
-- "调用方会知道出错了吗？"
-- "有足够上下文调试这个错误吗？"
-
-## 性能与缓存
-
-### CPU 密集操作
-- **热路径上的昂贵操作**：循环中编译正则、解析 JSON、做加密
-- **阻塞主线程**：同步 I/O、无 worker / async 的重计算
-- **重复计算**：同一计算被多次执行
-- **缺少记忆化**：相同输入反复调用的纯函数
-
-### 数据库与 I/O
-- **N+1 查询**：循环里每个元素查一次，而非批量
-  ```javascript
-  // 差：N+1
-  for (const id of ids) {
-    const user = await db.query(`SELECT * FROM users WHERE id = ?`, id)
-  }
-  // 好：批量
-  const users = await db.query(`SELECT * FROM users WHERE id IN (?)`, ids)
-  ```
-- **缺索引**：在未建索引的列上查询
-- **过度取数**：只需几列却 SELECT *
-- **无分页**：把整个数据集加载进内存
-
-### 缓存问题
-- **昂贵操作缺缓存**：重复的 API 调用、DB 查询、计算
-- **缓存无 TTL**：脏数据被无限期返回
-- **缓存无失效策略**：数据更新了但缓存没清
-- **缓存键碰撞**：键唯一性不足
-- **把用户私有数据全局缓存**：安全 / 隐私问题
-
-### 内存
-- **无界集合**：不断增长的数组 / map
-- **大对象滞留**：持有引用阻止 GC
-- **循环中字符串拼接**：应改用 StringBuilder / join
-- **整文件加载**：应改用流式
-
-### 追问
-- "这个操作的时间复杂度是多少？"
-- "数据量 10 倍 / 100 倍时行为如何？"
-- "结果可缓存吗？该缓存吗？"
-- "能批量代替逐条吗？"
-
-## 边界条件
-
-### Null / Undefined 处理
-- **缺空值检查**：在可能为 null 的对象上访问属性
-- **truthy / falsy 混淆**：`if (value)` 而 `0` 或 `""` 是合法值
-- **过度可选链**：`a?.b?.c?.d` 掩盖了结构性问题
-- **null 与 undefined 不一致**：混用且无明确约定
-
-### 空集合
-- **未处理空数组**：代码假设数组非空
-- **空对象边界**：在空对象上 `for...in` 或 `Object.keys`
-- **首 / 末元素访问**：`arr[0]` 或 `arr[arr.length-1]` 未先判空
-
-### 数值边界
-- **除零**：除法前缺检查
-- **整数溢出**：超出安全整数范围的大数
-- **浮点比较**：用 `===` 而非 epsilon 比较
-- **负值**：本不该为负的索引或计数
-- **off-by-one**：循环边界、数组切片、分页
-
-### 字符串边界
-- **空字符串**：未作为边界处理
-- **纯空白字符串**：通过 truthy 检查但实际为空
-- **超长字符串**：无长度上限导致内存 / 展示问题
-- **Unicode 边界**：emoji、RTL 文本、组合字符
-
-### 需要标记的危险模式
-```javascript
-const name = user.profile.name   // 危险：无空值检查
-const first = items[0]           // 危险：数组访问未判空
-const avg = total / count        // 危险：除法未判零
-if (value) { ... }               // 危险：truthy 检查排除了 0、""、false
-```
-
-### 追问
-- "如果它是 null / undefined 会怎样？"
-- "如果集合为空会怎样？"
-- "这个数的合法范围是什么？"
-- "边界值（0、-1、MAX_INT）处会怎样？"
-
-## 严重度提示
-
-- 会导致正确性 bug、数据损坏或生产事故的静默失败 → **P0 / P1**
-- 性能回退、可维护性隐患、未覆盖的边界 → **P1 / P2**
-- 局部健壮性改进 → **P3**

package/template/workflows/dev/R-review/removal-checklist.md

@@ -1,53 +0,0 @@
-# 删除候选与迭代计划清单
-
-服务 `R-review.md` 的 **Engineering 维度**。审查 diff 引入或暴露的死代码、冗余、关停特性时读取本文。区分**现在可安全删除**与**需计划后再删**，审查阶段只给出候选与计划，**不在审查中直接删除代码**。
-
-## 优先级
-
-- [ ] **P0**：需立即删除（安全风险、显著成本、阻塞其他工作）
-- [ ] **P1**：本迭代删除
-- [ ] **P2**：进 backlog / 下个迭代
-
-## 现在可安全删除
-
-### 候选项：[名称 / 描述]
-
-| 字段 | 内容 |
-|------|------|
-| **位置** | `path/to/file.ts:line` |
-| **理由** | 为什么应该删除 |
-| **证据** | 无引用、死特性开关、已废弃 API |
-| **影响** | 无 / 低 —— 无活跃消费者 |
-| **删除步骤** | 1. 删代码 2. 删测试 3. 删配置 |
-| **验证** | 跑测试、确认无运行时错误、观察日志 |
-
-## 推迟删除（需计划）
-
-### 候选项：[名称 / 描述]
-
-| 字段 | 内容 |
-|------|------|
-| **位置** | `path/to/file.ts:line` |
-| **为何推迟** | 有活跃消费者、需迁移、需干系人签字 |
-| **前置条件** | 特性开关关闭 2 周、遥测显示 0 使用 |
-| **破坏性变更** | 列出 API / 契约变更 |
-| **迁移计划** | 消费者迁移步骤 |
-| **时间线** | 目标日期或迭代 |
-| **负责人** | 责任人 / 团队 |
-| **验证** | 确认可安全删除的指标（错误率、使用计数） |
-| **回滚计划** | 出问题时如何恢复 |
-
-## 删除前核对
-
-- [ ] 全代码库搜索过所有引用（`rg`、`grep`）
-- [ ] 检查过动态 / 反射式调用
-- [ ] 确认无外部消费者（API、SDK、文档）
-- [ ] 复核过特性开关遥测（如适用）
-- [ ] 测试已更新 / 删除
-- [ ] 文档已更新
-- [ ] 已通知团队（如为共享代码）
-
-## 严重度提示
-
-- 引入的死代码 / 冗余本身一般是 **P3**；但当它**掩盖了正确性或安全风险**，或带来显著维护 / 成本负担时升级到 **P2 / P1**。
-- 审查只产出删除候选与计划；实际删除交由后续 `../03-tdd/03-tdd.md` 或专门的清理任务执行。

package/template/workflows/dev/R-review/review-axes.md

@@ -1,61 +0,0 @@
-# Multi-Axis Review Phase
-
-## 输入
-
-- `speculo/.speculo/dev/<change>/review-sources.md`
-- `git diff <fixed-point>...HEAD`
-- spec 来源文件或 `no spec available`
-- standards 来源文件或覆盖空白说明
-- Engineering 深度清单：同目录 `solid-checklist.md`、`security-checklist.md`、`code-quality-checklist.md`、`removal-checklist.md`
-
-## 产物
-
-- `speculo/.speculo/dev/<change>/review-report.md`，由 `../_templates/review-report-template.md` 填写
-
-## 填写引导
-
-三个维度各自独立成区，每条 finding 都要带**严重度（P0–P3）**、**文件/行或 hunk 依据**、**引用来源**，并尽量给出**可执行的修复建议**。
-
-### Spec 维度（做对了吗）
-
-1. 先读 spec（若有），再读 diff；若无 spec 且 `review-setup.md` 记录为 `no spec available`，则从以下自推断来源检查一致性：
-   - **commit message 推断**：commit message 中描述的需求是否在 diff 中完整实现
-   - **测试推断**：新增/修改的测试所描述的预期行为是否在 diff 中正确实现
-   - **代码注释推断**：diff 中 TODO/FIXME/HACK 标记的意图是否被正确落实
-   - **自推断仍不足时**：整区写 `no spec available — unable to verify spec compliance`
-2. 报告：缺失需求、范围蔓延（spec 外的实现）、看似实现但有问题的需求。
-3. 每条引用 spec 原文（若有）或推断来源（commit message/测试/注释）。
-
-### Engineering 维度（做好了吗）
-
-按需读取四份清单，逐项扫描 diff：
-
-1. **SOLID 与架构**（`solid-checklist.md`）：SRP/OCP/LSP/ISP/DIP 违背、代码异味；提重构时说明为何改善内聚 / 降低耦合，非平凡重构给增量计划。
-2. **安全与可靠性**（`security-checklist.md`）：注入 / XSS / SSRF / 路径穿越、认证授权、密钥泄露、竞态（TOCTOU、共享状态、DB 并发）、密码学、运行时风险；每条说明可利用性与影响。
-3. **代码质量**（`code-quality-checklist.md`）：错误处理（吞异常、异步错误）、性能（N+1、热路径昂贵操作、缓存）、边界条件（null、空集合、数值 / 字符串边界、off-by-one）。
-4. **删除候选**（`removal-checklist.md`）：死代码、冗余、关停特性；区分可安全删除与需计划，只产出候选与计划，不在审查中删代码。
-
-### Standards 维度（合规吗）
-
-1. 先读已记录标准（RULES、ADR、CONTRIBUTING、配置），再读 diff。
-2. 报告违反**已成文**标准的位置，引用标准来源。
-3. 工具已机器强制的项不重复人工检查；无成文标准时说明覆盖空白。
-
-### 并行与隔离
-
-- 如果可用，使用三个并行子代理分别审查 Spec、Engineering、Standards。
-- 如果没有子代理，分三个独立小节顺序执行，不让任一维度的结论影响另一维度。
-- 最终报告在 `## Spec`、`## Engineering`、`## Standards` 下并排呈现，可轻微清理措辞，但不要合并或重排 findings。
-
-## 边界
-
-- 不修复代码（review-first）。
-- 不把三个维度混成一个优先级列表。
-- 缺少 spec 时跳过 Spec 维度并明确写 `no spec available`；Engineering 维度始终执行。
-- 严重度按各清单的"严重度提示"判定，不凭印象拔高或压低。
-
-## 完成准则
-
-- `review-report.md` 已按 Spec / Engineering / Standards 三区呈现
-- 每条 finding 有严重度、明确依据和来源引用
-- `.status.json` 写入 `severity_summary`，`review_status: judged`

package/template/workflows/dev/R-review/review-setup.md

@@ -1,111 +0,0 @@
-# Review Setup Phase
-
-## 输入
-
-- 用户提供的 fixed point；如果缺失，先询问
-- 当前 git 仓库
-- 当前 change 目录：`speculo/.speculo/dev/<change>/`
-
-## 严重度模型
-
-每条 finding 必须标注严重度：
-
-| 级别 | 名称 | 含义 | 动作 |
-|------|------|------|------|
-| **P0** | Critical | 安全漏洞、数据丢失风险、正确性 bug | 必须阻断合并 |
-| **P1** | High | 逻辑错误、显著 SOLID 违背、性能回退、关键需求缺失 | 合并前应修复 |
-| **P2** | Medium | 代码异味、可维护性隐患、轻微 SOLID 违背、范围蔓延 | 本 PR 修或建后续项 |
-| **P3** | Low | 风格、命名、小建议 | 可选改进 |
-
-## 执行原则
-
-- 用户说的任何东西都是固定点。若用户没有指定固定点，先询问；拿到前不要继续。
-- 比较命令使用三点语法：`git diff <fixed-point>...HEAD`，同时记录 `git log <fixed-point>..HEAD --oneline`。
-- **Worktree 模式**：若当前 change 为 worktree 隔离模式（`.status.json` 的 `worktree_enabled` 为真），fixed point 默认取 `base_branch`，且审查必须完整覆盖 change 分支树 `base_branch..change_branch` 的**每一个 commit**。此时读取 `../../../skills/worktree-isolation/SKILL.md` 的 `references/audit-branch-tree.md`。
-- **Review-first**：本工作流默认只产出审查结论，**不修改代码**；除非用户在看到 findings 后明确授权修复。
-- **诚实优先**：无法覆盖的区域要显式声明（见 `review-verdict.md` 的 clean-review 要求）。
-- 机器已强制的标准（lint / 类型 / 格式）只记录来源，不重复人工检查。
-- 如果环境支持并行子代理，三个维度应并行执行；否则按三个独立上下文顺序执行。
-
-## 独立进入流程
-
-本工作流**零硬依赖**。只需用户提供 fixed point + 当前 git 仓库即可启动。
-
-1. **fixed point**：若用户未指定，先询问；worktree 模式下默认取 `base_branch`。
-2. **change 目录**：若无 active change，执行 `../AGENTS.md` 进入协议步骤 3（原子三步），不得内联自初始化 JSON。
-3. **信息自采集**：若同 change 下无上游产物，按下方「来源深度搜索」自行采集审查上下文。
-4. **深度搜索**：Spec 和 Standards 来源仍不足时，对关键路径执行额外考古；检查测试文件推断预期行为。
-5. **诚实优先**：找不到 spec 时记录 `no spec available`；找不到成文标准时记录覆盖空白。Engineering 维度始终执行。
-
-## 独立进入时的来源深度搜索
-
-当本工作流独立进入（无上游 PRD、slices、decision-log 等产物）时，在收集 spec 和 standards 来源时执行以下扩展搜索。**不要求用户先执行 dev/01、dev/02 或其他工作流。**
-
-### Spec 来源的扩展发现（按优先级）
-
-1. **commit message 提取**：`git log <fixed-point>..HEAD --oneline` + `git log <fixed-point>..HEAD --format="%B"` 提取全部 commit message 正文，搜索 issue/PR 引用（`#\d+`、`fixes #`、`closes #`、JIRA key 模式）
-2. **commit message 全文搜索**：`git log <fixed-point>..HEAD --grep="<关键词>"` 搜索与变更主题相关的 commit
-3. **代码注释/TODO 提取**：在 diff 涉及的文件中搜索注释、TODO、FIXME 和 HACK 标记——这些常包含需求意图
-4. **本地 spec 文档搜索**：搜索仓库中与分支名、变更模块名匹配的 `.md` 文档、`docs/` 目录、`spec/` 目录
-5. **Speculo 文档搜索**：搜索 `speculo/.speculo/doc/`、`speculo/.speculo/archive/` 中与变更模块相关的领域文档
-6. **测试文件读取**：读取 diff 中测试文件的变更——新增测试描述了预期行为
-7. **上游产物继承**（若存在）：`speculo/.speculo/dev/<change>/prd.md`、`slices.md`、`decision-log.md`
-8. **以上均无时**：记录 `no spec available`——Spec 维度跳过，不编造来源
-
-### Standards 来源的扩展发现
-
-1. **Speculo 配置搜索**：`speculo/.speculo/.config/RULES.md`、`speculo/.speculo/.config/adr/`、`speculo/.speculo/.config/context/`
-2. **项目根文档搜索**：`AGENTS.md`、`CONTRIBUTING.md`、`CLAUDE.md`、`README.md`
-3. **工具配置搜索**：`.editorconfig`、`eslint.config.*`、`biome.json`、`prettier.config.*`、`tsconfig.json`、`pyproject.toml`
-4. **全部缺失时**：记录覆盖空白说明（如"仓库无 RULES.md、无 ADR、无 CONTRIBUTING.md——Standards 维度仅检查通用工程实践"），不把缺失当作"无问题"
-
-## 产物
-
-- `speculo/.speculo/dev/<change>/review-sources.md`，由 `../_templates/review-sources-template.md` 填写
-
-## 填写引导
-
-1. 沿用用户提供的 fixed point，不自行替换为其他分支。**Worktree 模式**（`.status.json` 的 `worktree_enabled` 为真）下，若用户未另行指定，fixed point 默认取 `base_branch`，并按 `../../../skills/worktree-isolation/SKILL.md` 的 `references/audit-branch-tree.md` 用 `git log <base_branch>..<change_branch> --oneline` 记录 change 分支树**全部 commit**、`git diff <base_branch>...<change_branch>` 取全量 diff，确保审查覆盖每个 commit。
-2. 记录 `git diff <fixed-point>...HEAD` 和 `git log <fixed-point>..HEAD --oneline`。
-3. 用 `git diff <fixed-point>...HEAD --stat` 评估 diff 规模并定分批策略：
-   - **无变更**：`git diff` 为空时，告知用户并询问是否改审 staged 变更或某个 commit 区间，拿到前不继续。
-   - **大 diff（> 500 行）**：先按文件 / 模块汇总，再按模块或功能分批审查。
-   - **混合关注点**：按逻辑功能分组，不只按文件顺序。
-4. 标识关键路径：auth / 授权、支付 / 金额、数据写入、网络 / 外部调用、并发 —— 这些区域在 Engineering 维度需重点审查。
-5. 寻找 spec 来源，按「独立进入时的来源深度搜索」中的 Spec 扩展发现顺序执行：
-   - commit message 中的 issue / PR 引用 → commit message 全文搜索
-   - 用户作为参数传入的路径
-   - 代码注释/TODO/FIXME 中的需求线索
-   - 仓库中与分支名或功能匹配的规格文档
-   - `speculo/.speculo/dev/<change>/prd.md`、`slices.md`、`decision-log.md`（若存在）
-   - `speculo/.speculo/doc/` 和 `speculo/.speculo/archive/` 中的领域文档
-   - 以上均无时记录 `no spec available`
-6. 寻找 standards 来源，按「独立进入时的来源深度搜索」中的 Standards 扩展发现顺序执行：
-   - `speculo/.speculo/.config/RULES.md`
-   - `speculo/.speculo/.config/context/`
-   - `speculo/.speculo/.config/adr/`
-   - `AGENTS.md`、`CONTRIBUTING.md`、`CLAUDE.md`
-   - `.editorconfig`、`eslint.config.*`、`biome.json`、`prettier.config.*`、`tsconfig.json`
-   - 全部缺失时记录覆盖空白说明
-7. 机器强制的标准只记录来源，不重复检查工具已覆盖的内容。
-8. Engineering 维度不需要外部来源，但记录将依据同目录的 `solid-checklist.md`、`security-checklist.md`、`code-quality-checklist.md`、`removal-checklist.md`（进入 Engineering 审查时按需读取）。
-
-## 渐进披露（Engineering 维度深度清单）
-
-- `solid-checklist.md`：SOLID 违背与架构异味
-- `security-checklist.md`：安全漏洞、竞态、密钥、密码学
-- `code-quality-checklist.md`：错误处理、性能、边界条件
-- `removal-checklist.md`：死代码与删除候选
-
-## 边界
-
-- 不开始主观审查，先完成来源与范围收集。
-- 找不到 spec 时不要编造；记录 `no spec available`。
-- 找不到成文标准时记录覆盖空白，不把缺失当作"无问题"。
-
-## 完成准则
-
-- fixed point、diff 命令、commit 列表、diff 规模与分批策略已记录
-- worktree 模式下已记录 change 分支树 `base_branch..change_branch` 的全部 commit
-- standards 来源、spec 来源、关键路径已记录
-- `.status.json` 写入 `review_fixed_point`、`review_diff_command`、`review_axes`、`standards_sources`、`spec_sources`，`review_status: collecting`

package/template/workflows/dev/R-review/review-verdict.md

@@ -1,43 +0,0 @@
-# Verdict & Next Steps Phase
-
-## 输入
-
-- `speculo/.speculo/dev/<change>/review-report.md`（三维度 findings）
-- `.status.json` 的 `severity_summary`
-
-## 产物
-
-- `speculo/.speculo/dev/<change>/review-verdict.md`，由 `../_templates/review-verdict-template.md` 填写
-
-## 填写引导
-
-1. **严重度汇总**：统计三维度合计的 P0 / P1 / P2 / P3 计数。
-2. **整体裁决**，依据汇总给出其一：
-   - `REQUEST_CHANGES`：存在任何 P0，或存在合并前应修复的 P1
-   - `COMMENT`：无 P0/P1，但有值得跟进的 P2/P3
-   - `APPROVE`：无阻断项，至多少量 P3
-3. **Clean-review 诚实声明**（无论是否发现问题都必须写）：
-   - **检查了什么**：覆盖到的文件 / 模块 / 维度（worktree 模式下须确认已覆盖 `base_branch..change_branch` 的每个 commit）
-   - **未覆盖什么**：未审的区域及原因（如 "未验证数据库迁移"、"大 diff 仅抽样审查了 X 模块"）
-   - **残留风险**：建议补充的测试或后续验证
-4. **后续选项**：向用户给出明确选项并等待选择，未经确认不实施修复：
-   1. 修复全部
-   2. 仅修复 P0 / P1
-   3. 修复指定项（由用户点名）
-   4. 不改动，审查到此为止
-   - 若选择修复且仓库支持，移交 `../03-tdd/03-tdd.md` 的红绿重构循环
-   - 若选择不改动且 change 已完成其使命，可移交 `../04-finalize/04-finalize.md` 归档
-   - 独立进入时（无上下游工作流），以上移交均为可选推荐，由用户决定后续路径
-5. 用户选择修复时，移交 `../03-tdd/03-tdd.md` 的红绿重构循环执行，并在该 change 内继续维护状态。
-
-## 边界
-
-- 不修复代码；本阶段只裁决与确认。
-- 不夸大或弱化裁决；裁决必须与 `severity_summary` 一致。
-- 不把"未覆盖"伪装成"无问题"。
-
-## 完成准则
-
-- `review-verdict.md` 含整体裁决、严重度汇总、clean-review 三项声明、后续选项
-- `review-verdict.md` 无残留 `[TODO:]`
-- `.status.json` 写入 `review_verdict`，`review_status: completed`