@namewta/speculo 0.1.20 → 0.2.0

package/template/workflows/dev/M-domain-modeling/CONTEXT-FORMAT.md

@@ -1,67 +0,0 @@
-# CONTEXT.md 格式
-
-本文是项目术语表（通用语言）写法的**单一事实源**，由 `dev/M-domain-modeling` 拥有，`dev/01`、`dev/02`、`dev/04`、`dev/D`、`dev/A` 等工作流按需引用。
-
-只有用户明确确认时，才按本格式创建或更新 `speculo/.speculo/.config/context/CONTEXT.md` / `speculo/.speculo/.config/context/CONTEXT-MAP.md`；未确认的术语只记录到调用方工作流的会话产物（如 `decision-log.md`、`domain-model-log.md`）。
-
-## 结构
-
-```md
-# {上下文名称}
-
-{一到两句话描述这个上下文是什么、为什么存在。}
-
-## 术语
-
-**订单（Order）**：
-{一到两句话描述该术语}
-_避免使用_：Purchase、transaction
-
-**发票（Invoice）**：
-交付后向客户发送的付款请求。
-_避免使用_：Bill、payment request
-
-**客户（Customer）**：
-下单的个人或组织。
-_避免使用_：Client、buyer、account
-```
-
-## 规则
-
-- **要有主见。** 当同一个概念有多个词汇时，选择最好的一个，将其他词列为「避免使用」的别名。
-- **显式标记冲突。** 如果某个术语被合混地使用，在「已标记的合混」中明确指出并给出解决方案。
-- **保持定义简洁。** 最多一到两句话。定义它「是什么」，而不是「做什么」。
-- **展示关系。** 使用粗体术语名称，在明显的地方表达基数关系。
-- **只包含本项目的上下文特有的术语。** 通用编程概念（超时、错误类型、工具模式）即使项目大量使用也不应该包含。添加术语前问自己：这是本项目上下文特有的概念，还是通用编程概念？只有前者才应该包含。
-- **当自然分组出现时，用子标题分组术语。** 如果所有术语属于一个紧密相关的领域，平铺列表即可。
-- **写一段示例对话。** 一段开发者与领域专家之间的对话，展示术语如何自然交互，并澄清相关概念之间的边界。
-
-## 单上下文与多上下文仓库
-
-**单上下文（大多数仓库）：** `speculo/.speculo/.config/context/CONTEXT.md` 记录项目级术语表。
-
-**多上下文：** `speculo/.speculo/.config/context/CONTEXT-MAP.md` 列出所有上下文、它们的位置以及它们之间的关系：
-
-```md
-# 上下文映射
-
-## 上下文
-
-- [Ordering](./ordering.md) —— 接收并跟踪客户订单
-- [Billing](./billing.md) —— 生成发票并处理付款
-- [Fulfillment](./fulfillment.md) —— 管理仓库拣货和发货
-
-## 关系
-
-- **Ordering → Fulfillment**：Ordering 发出 `OrderPlaced` 事件；Fulfillment 消费这些事件开始拣货
-- **Fulfillment → Billing**：Fulfillment 发出 `ShipmentDispatched` 事件；Billing 消费这些事件生成发票
-- **Ordering ↔ Billing**：共享 `CustomerId` 和 `Money` 类型
-```
-
-本工作流自动推断适用哪种结构：
-
-- 如果 `speculo/.speculo/.config/context/CONTEXT-MAP.md` 存在，读取它以查找上下文
-- 如果只有 `speculo/.speculo/.config/context/CONTEXT.md`，则为单上下文
-- 如果都不存在，在第一个术语确定时按需创建 `speculo/.speculo/.config/context/CONTEXT.md`
-
-当存在多个上下文时，推断当前主题与哪个上下文相关。如果不确定，就问。

package/template/workflows/dev/M-domain-modeling/M-domain-modeling.md

@@ -1,118 +0,0 @@
----
-id: dev/M-domain-modeling
-category: dev
-name: Domain Modeling
-description: 主动构建与精炼项目领域模型——挑战术语、压测边界，并在决策结晶当下沉淀通用语言（CONTEXT）与架构决策（ADR）
-keywords: [domain-modeling, context, adr, ubiquitous-language, 领域建模, 术语, 通用语言]
----
-
-# Domain Modeling 工作流执行指引
-
-本工作流是 `dev/M` 入口，也是 dev 分类**领域模型的横向纪律与格式单一事实源**：在设计与讨论中*主动*构建、精炼项目领域模型，并在术语和决策结晶的当下立即沉淀。它既可独立进入（`dev/M`），也被 `dev/01`、`dev/02`、`dev/04`、`dev/D` 与 `dev/A` 在各自阶段中引用。
-
-> **主动 vs 消费**：仅仅*读取* CONTEXT 取词汇**不是**本工作流——那是任何工作流都该有的一行习惯。本工作流用于你正在*改变*模型，而不仅是消费它时。
-
-## 内置指引
-
-### 何时使用
-
-当 dev 工作流需要*改变*领域模型时使用——挑战或锐化术语、消解一词多义、记录难以逆转的架构决策、维护通用语言。典型触发：
-
-- 用户用词与现有 CONTEXT 冲突，或同一概念出现多个词
-- 讨论领域关系，需要用具体场景压测边界
-- 出现「难以逆转 + 缺上下文会令人意外 + 真实权衡」的决策，值得记成 ADR
-- 实现 / 重构 / PRD 中引入了 CONTEXT 里尚不存在的概念
-
-### 输入
-
-- 用户的计划、设计或当前讨论
-- `speculo/.speculo/.config/context/CONTEXT.md`、`speculo/.speculo/.config/context/CONTEXT-MAP.md`、`speculo/.speculo/.config/adr/` 与相关代码
-- 当前 change 目录：`speculo/.speculo/dev/<change>/`（`<change>` 必须为 `YYYY-MM-DD-<kebab-name>`，例：`2026-06-12-model-ordering`）
-
-### 输出
-
-- 会话沉淀记录：`speculo/.speculo/dev/<change>/domain-model-log.md`
-- 经用户确认后更新 `speculo/.speculo/.config/context/CONTEXT.md`（或 `CONTEXT-MAP.md`）
-- 经用户确认后在 `speculo/.speculo/.config/adr/` 新建 ADR
-- 需要用户决策的术语 / 边界问题，每次只问一个
-
-（`<change>` 格式：`YYYY-MM-DD-<kebab-name>`）
-
-### 会话期间（主动纪律）
-
-在讨论进行中持续执行，**不要批量**——在发生的当下捕获：
-
-- **对照词汇表挑战**：用户用词与 CONTEXT 现有语言冲突时立即指出。「你的词汇表把『取消』定义为 X，但你似乎指 Y——到底是哪个？」
-- **锐化模糊语言**：用户用含混或一词多义术语时，提出一个精确的规范术语。「你说『账户』——是指 Customer 还是 User？它们是不同的东西。」
-- **用具体场景压测**：讨论领域关系时，发明探测边界的场景，迫使精确界定概念之间的边界。
-- **与代码交叉引用**：用户陈述某事如何运作时，核对代码是否一致；矛盾即指出。「你的代码取消整个 Order，但你刚说支持部分取消——哪个对？」
-- **内联沉淀**：术语一旦解决，立即按 `CONTEXT-FORMAT.md` 更新（用户确认后写 `.config/context/`）；未确认的只记到 `domain-model-log.md`。
-- **有节制地提供 ADR**：仅当「难以逆转 + 缺上下文会令人意外 + 真实权衡的结果」三条全部满足时，才按 `ADR-FORMAT.md` 提议创建 ADR；任一不满足则跳过。
-
-> `CONTEXT.md` 必须完全不含实现细节——它是词汇表，不是 spec、草稿本或实现决策仓库。
-
-### 渐进披露
-
-- `CONTEXT-FORMAT.md`：撰写或更新项目术语表（CONTEXT / CONTEXT-MAP）时读取——**通用语言格式的单一事实源**。
-- `ADR-FORMAT.md`：判断是否该写 ADR、以何种格式写时读取——**ADR 格式与判据的单一事实源**。
-
-### 独立使用
-
-本工作流**零硬依赖**，无需预先执行其他工作流即可独立进入（`dev/M`）。只需用户的领域讨论 + 当前 git 仓库即可启动；缺 change 目录时按下「自初始化」创建。
-
-### 缺少 change 目录时的自初始化
-
-若当前无对应 change 目录：
-
-1. 从用户意图提取 `<kebab-name>`（如 `model-ordering-terms`）
-2. 创建 `speculo/.speculo/dev/<YYYY-MM-DD>-<kebab-name>/`
-3. 初始化 `.status.json`：
-   ```json
-   {
-     "dev_entry": "dev/M",
-     "current_phase": "1. Model Session",
-     "phase_history": [],
-     "change_status": "active",
-     "embedded_guides": ["domain-modeling"],
-     "terms_resolved": [],
-     "adr_candidates": [],
-     "context_write_status": "none"
-   }
-   ```
-4. 在 `speculo/.speculo/dev-status.json` 的 `active` 数组追加该 change 目录名
-
-## 阶段
-
-> **惰性创建文件**——只在需要写入时才创建。`.config/context/CONTEXT.md` 与 `.config/adr/` 由 Speculo 初始化提供；若目标项目缺失，在第一个术语 / ADR 解决时按需创建。
-
-### 1. Model Session — 词汇与决策沉淀
-- 规范：本入口「会话期间（主动纪律）」+ 同目录 `CONTEXT-FORMAT.md`、`ADR-FORMAT.md`
-- 模板：`../_templates/domain-model-log-template.md`
-- 产物：`domain-model-log.md`；经用户确认后更新 `.config/context/` 与 `.config/adr/`
-- 完成准则：
-  - 每个被挑战 / 锐化的术语都有结论（已写入 CONTEXT 或记为 `[待确认]`）
-  - 每个 ADR 候选都已按三条判据裁决（提议创建，或显式跳过并记原因）
-  - 写入 `.config/context/` 或 `.config/adr/` 的内容均经用户确认
-  - `domain-model-log.md` 无残留 `[TODO:]`
-
-## 依赖
-
-- 硬依赖：无
-- 软依赖：无。可独立进入；也被 `../01-grill-with-docs/01-grill-with-docs.md`、`../02-prd/02-prd.md`、`../04-finalize/04-finalize.md`、`../D-docs-sync/D-docs-sync.md`、`../A-improve-architecture/A-improve-architecture.md` 在其阶段中引用。
-
-## 状态扩展字段
-
-本工作流需在同 change 的 `.status.json` 追加：
-
-- `dev_entry` (string) — 固定为 `dev/M`
-- `embedded_guides` (array) — 包含 `domain-modeling`
-- `terms_resolved` (array) — 本会话解决的术语及结论
-- `adr_candidates` (array) — ADR 候选及裁决（`created` | `skipped` + 原因）
-- `context_write_status` (none | logged | context-updated | adr-created) — 领域模型沉淀状态
-
-## 完成与状态更新
-
-- 进入 phase 时更新 `current_phase` 和 `phase_history`。
-- 术语 / 决策沉淀后更新 `terms_resolved`、`adr_candidates`、`context_write_status`。
-- 写 `.config/context/` 或 `.config/adr/` **前必须经用户确认**（持久化写入责任表中，这两处 AI 仅在用户确认后写入）。
-- 本工作流不自动完成 change；嵌入其他工作流时随宿主流程推进。

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

@@ -1,163 +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** | 合规吗？ | 是否违反仓库**已记录**的标准：RULES、ADR、CONTRIBUTING、lint / 格式 / 类型配置 |
-
-若缺少 spec，Spec 维度跳过并报告 `no spec available`；若仓库无成文标准，Standards 维度报告检查范围并说明覆盖空白。Engineering 维度始终执行。
-
-### 严重度模型
-
-每条 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`；非 worktree 模式不读取该 skill。
-- **Review-first**：本工作流默认只产出审查结论，**不修改代码**；除非用户在看到 findings 后明确授权修复。
-- **诚实优先**：无法覆盖的区域要显式声明（见 `review-verdict.md` 的 clean-review 要求），不得用"看起来没问题"代替实际检查。
-- 机器已强制的标准（lint / 类型 / 格式）只记录来源，不重复人工检查工具已覆盖的内容。
-- 如果环境支持并行子代理，三个维度应并行执行；如果不支持，按三个独立上下文顺序执行，并在报告中保持分离。
-
-### 渐进披露（Engineering 维度深度清单）
-
-进入 Engineering 维度审查时，按需读取同目录清单：
-
-- `solid-checklist.md`：检查 SOLID 违背与架构异味、给重构启发式时读取。
-- `security-checklist.md`：检查安全漏洞、竞态、密钥、密码学与运行时风险时读取。
-- `code-quality-checklist.md`：检查错误处理、性能 / 缓存、边界条件时读取。
-- `removal-checklist.md`：识别死代码与删除候选、产出删除 / 推迟计划时读取。
-
-### 独立使用
-
-本工作流**零硬依赖**，无需预先执行 dev/01、dev/02、dev/I 等其他工作流即可独立进入。只需用户提供 fixed point（分支/commit/tag）+ 当前 git 仓库即可启动。
-
-**独立进入流程：**
-
-1. **fixed point**：若用户未指定，先询问；拿到前不继续。在 worktree 模式下默认取 `base_branch`。
-2. **change 目录**：若用户未指定 `<change>` 目录，按 `YYYY-MM-DD-<kebab-name>` 格式创建（如 `2026-06-17-review-auth-refactor`），初始化 `.status.json` 并更新 `dev-status.json`。
-3. **信息自采集**：若同 change 目录下无上游产物（PRD、slices、decision-log 等），**自行通过代码库探索采集审查所需上下文**，不要求用户先执行其他工作流：
-   - `git log <fixed-point>..HEAD --oneline` 提取 commit message 中的 issue/PR 引用
-   - 搜索仓库中与变更模块匹配的 spec 文档、README、设计文档
-   - 从代码注释、TODO/FIXME 和 commit message 正文推断需求意图
-   - 搜索 `speculo/.speculo/.config/RULES.md`、`speculo/.speculo/.config/adr/`、`AGENTS.md`、`CONTRIBUTING.md` 获取标准来源
-   - 搜索 `.editorconfig`、`eslint.config.*`、`biome.json`、`prettier.config.*`、`tsconfig.json` 获取机器强制标准
-4. **深度搜索**：Spec 和 Standards 来源仍不足时：
-   - 对关键路径（auth/支付/数据写入/网络）执行额外的代码库考古（`git log -p -- <path>`）
-   - 搜索 `speculo/.speculo/doc/` 和 `speculo/.speculo/archive/` 中的领域文档
-   - 检查变更模块的现有测试文件以推断预期行为
-5. **诚实优先**：找不到 spec 时明确记录 `no spec available`，不编造；找不到成文标准时记录覆盖空白，不把缺失当作"无问题"。Engineering 维度始终执行，不依赖任何外部产物。
-
-### 缺少 change 目录时的自初始化
-
-若当前无对应 change 目录，按以下步骤创建：
-
-1. 从审查意图提取 `<kebab-name>`（如 `review-auth-refactor`、`review-api-changes`）
-2. 创建 `speculo/.speculo/dev/<YYYY-MM-DD>-<kebab-name>/`
-3. 初始化 `.status.json`：
-   ```json
-   {
-     "dev_entry": "dev/R",
-     "current_phase": "1. Review Setup",
-     "phase_history": [],
-     "change_status": "active",
-     "review_fixed_point": null,
-     "review_diff_command": null,
-     "review_axes": ["spec", "engineering", "standards"],
-     "standards_sources": [],
-     "spec_sources": [],
-     "severity_summary": { "p0": 0, "p1": 0, "p2": 0, "p3": 0 },
-     "review_verdict": null,
-     "review_status": "collecting"
-   }
-   ```
-4. 在 `speculo/.speculo/dev-status.json` 的 `active` 数组中追加该 change 目录名
-
-## 阶段
-
-### 1. Review Setup — 固定点、范围与来源收集
-- 规范：`review-setup.md`
-- 模板：`../_templates/review-sources-template.md`
-- 产物：`review-sources.md`
-- 完成准则：
-  - 已记录 fixed point、diff 命令、commit 列表、diff 规模与分批策略
-  - 已列出 standards 来源与 spec 来源，或记录各自缺失
-  - 已标识关键路径（auth / 支付 / 数据写入 / 网络）
-  - `review-sources.md` 无残留 `[TODO:]`
-
-### 2. Multi-Axis Review — 三维度审查
-- 规范：`review-axes.md`
-- 模板：`../_templates/review-report-template.md`
-- 产物：`review-report.md`
-- 完成准则：
-  - Spec / Engineering / Standards 分区独立呈现，不合并、不重排
-  - 每条 finding 带严重度（P0–P3）、文件/行或 hunk 依据，以及对应 spec / 清单 / 标准引用
-  - `review-report.md` 无残留 `[TODO:]`
-
-### 3. Verdict & Next Steps — 裁决与后续确认
-- 规范：`review-verdict.md`
-- 模板：`../_templates/review-verdict-template.md`
-- 产物：`review-verdict.md`
-- 完成准则：
-  - 给出整体裁决（APPROVE / REQUEST_CHANGES / COMMENT）与严重度汇总
-  - 完成 clean-review 声明：检查了什么、未覆盖什么、残留风险
-  - 已向用户给出后续选项，未经确认不实施修复
-  - `review-verdict.md` 无残留 `[TODO:]`
-
-## 依赖
-
-- 硬依赖：无；用户提供 fixed point 即可进入
-- 软依赖：无。若同 change 目录下存在其他工作流产物（如 prd.md、slices.md、decision-log.md），可继承其信息增强 Spec 维度审查；缺失时自行采集（commit message、代码注释、项目文档），不阻塞流程。审查完成后是否进入修复（`../03-tdd/03-tdd.md`）或归档（`../04-finalize/04-finalize.md`）由用户决定。
-
-## 状态扩展字段
-
-本工作流需在同 change 的 `.status.json` 追加：
-
-- `dev_entry` (string) — 固定为 `dev/R`
-- `review_fixed_point` (string) — 用户提供的比较点
-- `review_diff_command` (string) — 实际使用的 diff 命令
-- `review_axes` (array) — 实际执行的维度，取值自 `spec` | `engineering` | `standards`
-- `standards_sources` (array) — Standards 审查读取的规则来源
-- `spec_sources` (array) — Spec 审查读取的规格来源
-- `severity_summary` (object) — 各严重度 finding 计数：`{ "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`）或其他动作由用户决定。

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,73 +0,0 @@
-# Review Setup Phase
-
-## 输入
-
-- 用户提供的 fixed point；如果缺失，先询问
-- 当前 git 仓库
-- 当前 change 目录：`speculo/.speculo/dev/<change>/`
-
-## 独立进入时的来源深度搜索
-
-当本工作流独立进入（无上游 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`。
-
-## 边界
-
-- 不开始主观审查，先完成来源与范围收集。
-- 找不到 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`