@namewta/speculo 0.1.21 → 0.2.0

package/template/workflows/dev/H-diagnose/diagnose-loop.md

@@ -1,41 +0,0 @@
-# Diagnose Loop Phase
-
-## 输入
-
-- 用户描述的失败现象、日志、trace、性能症状或失败测试
-- 可运行的测试、脚本、服务、CLI 或浏览器自动化
-- `H-diagnose.md` 中的内置诊断指引（含独立使用协议与自初始化步骤）
-- 同目录 `diagnose-guide.md`（含独立诊断时的信息采集协议）
-
-### 独立进入时的上下文自采集
-
-若无上游工作流产物（PRD、decision-log 等），在进入反馈循环构建前，按 `diagnose-guide.md` 的「独立诊断时的信息采集」执行以下快速自采集，**不要求用户先执行其他工作流**：
-
-1. `git log --oneline -30` + 搜索错误关键符号 → 定位相关代码区域
-2. 读取问题模块及其测试 → 理解预期行为
-3. 检查 `speculo/.speculo/.config/` 下的项目规则与 ADR → 了解约束
-4. 仅在代码库探索穷尽后，使用 `AskUserQuestion` 向用户索取无法从仓库获取的信息（复现环境、日志文件等）
-
-## 产物
-
-- `speculo/.speculo/dev/<change>/diagnosis.md`，由 `../_templates/diagnosis-template.md` 填写
-
-## 填写引导
-
-1. 遵循 `H-diagnose.md` 的内置诊断指引，并按需读取 `diagnose-guide.md`。
-2. 先建立快速、确定、可信的反馈循环。
-3. 没有反馈循环时停止假设阶段，记录已尝试方法和需要用户提供的材料。
-4. 复现后提出 3-5 个排序假设，并把每个假设写成可证伪预测。
-5. 插桩必须映射到具体预测，并使用可清理的唯一调试标记。
-6. 性能回退先建立基线测量，再二分或假设检验；先测量，后修复。
-
-## 边界
-
-- 不在未复现或无可信反馈循环时进入修复。
-- 不把无关日志批量加入代码。
-- 不默认保留一次性调试脚本。
-
-## 完成准则
-
-- `diagnosis.md` 无残留 `[TODO:]`
-- `.status.json` 已记录 `feedback_loop` 和 `hypothesis_status`

package/template/workflows/dev/H-diagnose/scripts/hitl-loop.template.sh

@@ -1,41 +0,0 @@
-#!/usr/bin/env bash
-# 人在环路的复现循环。
-# 复制此文件，编辑下方步骤，然后运行。
-# agent 运行脚本；用户在终端中跟随提示操作。
-#
-# 用法：
-#   bash hitl-loop.template.sh
-#
-# 两个辅助函数：
-#   step "<指令>"          → 显示指令，等待 Enter
-#   capture VAR "<问题>"   → 显示问题，将回答读入 VAR
-#
-# 结束时，捕获的值以 KEY=VALUE 格式打印供 agent 解析。
-
-set -euo pipefail
-
-step() {
-  printf '\n>>> %s\n' "$1"
-  read -r -p "    [完成后按 Enter] " _
-}
-
-capture() {
-  local var="$1" question="$2" answer
-  printf '\n>>> %s\n' "$question"
-  read -r -p "    > " answer
-  printf -v "$var" '%s' "$answer"
-}
-
-# --- edit below ---------------------------------------------------------
-
-step "在浏览器中打开 http://localhost:3000 并登录。"
-
-capture ERRORED "点击「导出」按钮。是否报错了？(y/n)"
-
-capture ERROR_MSG "粘贴错误信息（或输入 'none'）："
-
-# --- edit above ---------------------------------------------------------
-
-printf '\n--- 已捕获 ---\n'
-printf 'ERRORED=%s\n' "$ERRORED"
-printf 'ERROR_MSG=%s\n' "$ERROR_MSG"

package/template/workflows/dev/I-to-issues/I-to-issues.md

@@ -1,79 +0,0 @@
----
-id: dev/I-to-issues
-category: dev
-name: To Issues
-description: 将 PRD、计划或诊断结论拆成可独立接手的垂直切片 issue
-keywords: [issues, slices, vertical, AFK, HITL, 切片]
----
-
-# To Issues 工作流执行指引
-
-本工作流是 `dev/I` 入口。它既可独立执行，也可嵌入 `dev/01`、`dev/02`、`dev/03` 或 `dev/H`，用于生成垂直切片。
-
-## 铁律
-
-```
-没有精确到文件路径的改动清单，不算垂直切片
-```
-
-## 内置文档
-
-- `issues-slices.md` — 切片分解规范、深度搜索协议、质量准则与提问协议
-- `../_templates/issues-slices-template.md` — `slices.md` 骨架
-- `../../../vendor/codebase-design/SKILL.md` — 设计词汇单一事实源（模块 / 接口 / 接缝 / 适配器 / 深度 / 杠杆 / 局部性）
-
-## 输入与输出
-
-- **输入**：PRD、计划、诊断结论或当前对话；当前 change 目录 `speculo/.speculo/dev/<change>/`
-- **输出**：`slices.md`（垂直切片清单、依赖、HITL/AFK 标记、验收标准）；可选外部 issue 引用
-
-## 垂直切片规则
-
-- 每个切片交付一条贯穿所有层的窄但完整路径；优先多个薄切片而非少数厚切片
-- 切片标记 `HITL` 或 `AFK`；尽可能优先 AFK
-- 默认只生成本地切片计划；仅 tracker 已配置且用户明确要求时才发布外部 issue
-
-## 独立使用
-
-本工作流**零硬依赖**。只需用户描述任务意图 + 当前 git 仓库即可启动。
-
-1. **change 目录**：若无 active change，执行 `../AGENTS.md` 进入协议步骤 3（原子三步），不得内联自初始化 JSON。
-2. **信息自采集**：无上游产物时，按 `issues-slices.md`「独立进入时的深度搜索协议」自行采集。
-3. **存疑即问**：仅在代码库探索无法确定的决策分支上，按 `issues-slices.md`「存疑时的提问协议」使用 `AskUserQuestion`。
-
-### 缺少 change 目录时
-
-若无 active change，执行 `../AGENTS.md` 进入协议步骤 3（原子三步），不得内联自初始化 JSON。
-
-## 阶段
-
-### 1. Slice Issues — 垂直切片分解
-- id：`slice-issues`
-- 规范：`issues-slices.md`
-- 模板：`../_templates/issues-slices-template.md`
-- 产物：`slices.md`
-- 完成准则：
-  - §0 含已确认决策、当前现状与关键核实结论
-  - 每个切片有文件表、实现要点、验收切片；删除型切片标注保留/不动
-  - 涉及 schema 变更时 §2.5 已填写；§5.5 关键决策已汇总；§8 验证总览存在
-  - `slices.md` 无残留 `[TODO:]`
-
-## 依赖
-
-- 硬依赖：无
-- 软依赖：同 change 下若有 `prd.md`、`diagnosis.md` 等可继承加速；完成后通常移交 `../03-tdd/03-tdd.md`
-
-## 状态扩展字段
-
-- `dev_entry` (string) — 固定为 `dev/I`
-- `embedded_guides` (array) — 包含 `to-issues`
-- `slice_count` (number)
-- `hitl_slice_count` (number)
-- `published_issue_refs` (array)
-- `issue_tracker_mode` (disabled | local-only | publish-requested | published)
-
-## 完成与状态更新
-
-- 默认只生成本地 `slices.md`。
-- 只有 tracker 已配置且用户明确要求时才发布外部 issue。
-- 完成后不自动完成 change；通常移交 `../03-tdd/03-tdd.md`。

package/template/workflows/dev/I-to-issues/issues-slices.md

@@ -1,211 +0,0 @@
-# Slice Issues Phase
-
-> 本阶段将 PRD、计划或诊断结论拆为**可独立验证的垂直切片**（tracing bullet），产出一份可被下游直接接手的**切片计划** `slices.md`。
-> `slices.md` 借鉴高质量 plan 的纪律——以厚 Context（已确认决策 + 关键核实结论）开篇，按依赖排序的切片展开，
-> 每切片标注保留/不动，并以分层验证收口；同时保留 HITL/AFK 标记、用户确认与 issue 发布流程。
-
-## 独立进入时的深度搜索协议
-
-当本工作流独立进入（无上游 PRD、decision-log、diagnosis 等产物）时，在执行切片分解前先按以下步骤自行采集上下文。**不要求用户先执行 dev/01、dev/02 或其他工作流。**
-
-### 第一轮：项目全景扫描
-
-1. **目录结构探索**：遍历项目顶层目录（`src/`、`core/`、`tests/`、`docs/` 等），建立模块边界心智模型
-2. **项目规范读取**：读取 `AGENTS.md`、`README.md`、`CONTRIBUTING.md`，提取架构约定、命名规范、测试策略
-3. **配置与依赖**：读取 `package.json`（或等效构建文件），了解技术栈、依赖和脚本入口
-4. **Speculo 状态读取**：读取 `speculo/.speculo/.config/RULES.md`、`speculo/.speculo/.config/adr/`、`speculo/.speculo/dev-status.json`，了解项目决策与当前活跃 change
-5. **近期变更趋势**：`git log --oneline -30` 了解近期工作方向
-
-### 第二轮：领域上下文采集
-
-6. **搜索相关代码**：按用户意图关键词在项目中 `grep -rn`，定位所有相关代码路径、注释、TODO
-7. **文档检索**：搜索 `speculo/.speculo/doc/` 和 `speculo/.speculo/archive/` 中已有的领域分析、设计文档
-8. **测试即规格**：阅读相关模块的现有测试文件——测试描述了系统契约和边界行为
-9. **git 考古**：对关键路径执行 `git log -p -- <path>` 理解模块的演进动机
-
-### 第三轮：锁定未决分支
-
-10. **已确认决策的底线**：从以上探索中能确定的事实写入 §0「已确认决策」；无法从代码/文档确定的分支标记为 `[待确认]`
-11. **提问收敛**：对标记 `[待确认]` 的决策分支，按「存疑时的提问协议」逐一锁定——但仅在代码库探索穷尽后
-
-### 采集成果写入
-
-- 探索确认的事实 → §0「关键核实结论」（注明行号近似）
-- 从代码/文档提取的约束 → §1 IN/REUSE/OUT、§2 架构约束
-- 无法从代码库确定的 → `[待确认]` 标记，按提问协议处理
-- 从 `overview.md` 或现有文档继承的风险 → §6 风险与回滚
-
-## 输入
-
-- `prd.md`、`decision-log.md`、`diagnosis.md`、现有 issue 或用户计划（均为可选；缺失时按「独立进入时的深度搜索协议」自行采集）
-- 可选 issue tracker 配置和标签词汇表
-- `I-to-issues.md` 中的内置切片指引、「切片计划质量准则」与「独立使用」协议
-- 同级 change 目录下已有的 `context-map.md`、`decision-log.md`、`overview.md`（若存在，用于继承领域术语、已确认决策、风险与 ADR 引用；不存在则按深度搜索协议自采集）
-
-## 产物
-
-- `speculo/.speculo/dev/<change>/slices.md`，由 `../_templates/issues-slices-template.md` 填写
-
-## `slices.md` 结构规范
-
-`issues-slices-template.md` 提供模板骨架；AI 填写时按下述结构展开。`[必填]` 段每份都要，`[条件]` 段有则填、单文件小改可省。
-> 最小形态（单文件小改）：§0(简) + §1 + §3(单切片) + §5 + §8。复杂 change：全段铺开（含 §2.5 数据库表、§5.5 关键决策、切片内文件表和实现要点）。
-
-### 0. 战略与背景（Context）—— [必填]
-
-本段是整份切片计划的决策锚点，含五块：
-
-- **一句话战略**：单句概括「做什么 + 为什么 + 怎么做到（以现有系统为基底 / 新建 / 复用）」。
-- **已确认决策**：逐条列出与用户拍板的范围/取舍决策，防止下游重新扯皮。**有 `decision-log.md` 则继承其「已确认决策」段；独立进入（无上游）时在此自采集**。
-- **当前现状**：逐条列出与需求不符的现有实现、缺失的能力或待修复的问题。每条含：`文件路径:行号范围` + 当前值/行为 + 为什么不满足需求。独立进入时从代码库探索采集；有上游 PRD 或 diagnosis 则继承其发现。格式示例：`RegexConstants.PASSWORD` 为正则 `^(?=.*[a-z])...`（要求四类全含）——与需求「至少三类」不符。
-- **关键核实结论**：探索阶段确认的事实（依赖关系、唯一调用点、可删/须留边界等）。**必须显式写明「行号为近似、实施时以现场代码为准」**，避免下游照搬过期行号。
-- **预期产出**：1–2 句描述本 change 完成后的可观察结果。
-
-### 1. 范围边界（IN / REUSE / OUT）—— [必填]
-
-三列表格，逐条列出：
-- **IN** —— 本次必造的新能力（每项可对应后续一个或多个切片）
-- **REUSE** —— 复用现有系统的能力（不改动，只收编进新地基）
-- **OUT** —— 本期不做、留给后续迭代的内容（吸收「明确不做」边界）
-
-表格来源优先从 PRD 或用户指令提取；若来源未明确，用 `[待确认]` 标记并提请用户补充。
-
-### 2. 架构上下文 —— [条件]
-
-若 change 涉及多模块或改动既有架构，本节记录：
-- 涉及的 `core/` / `src/` / `src-tauri/`（或本项目对应分层）模块及其职责分工
-- 新增模块的定位（一句话职责 + 落点目录）
-- 不可逾越约束（来自 `AGENTS.md` 或 PRD 的硬性规则）
-- 可选 ASCII 分层图，标出依赖方向（如 `src → core → src-tauri`）
-
-> **设计词汇**：描述模块、接口与接缝时统一使用 `../../../vendor/codebase-design/SKILL.md` 的词汇（模块 / 接口 / 接缝 / 适配器 / 深度），不要散用「组件 / 服务 / 边界」。某切片是否值得切出新接缝，按「一个适配器 = 假设接缝，两个适配器 = 真实接缝」判定。
-
-单文件修复或热点 patch 可省略本节。
-
-### 2.5. 涉及的数据库表 —— [条件]
-
-若 change 涉及数据库 schema 变更（新建表、新增字段、字段语义调整），用三列表格记录：
-
-| 表 | 变更 |
-|----|------|
-
-变更描述规则：
-- **新建**表：列出全部字段名 + 类型 + PRIMARY KEY + UNIQUE KEY + INDEX，注明建表 DDL 追加到哪个 sql 文件末尾
-- **新增**字段：`字段名 类型 DEFAULT 默认值 COMMENT '注释'`，注明 ALTER TABLE 追加到哪个 sql 文件末尾
-- **字段语义调整**：`旧字段名 → 新语义`（不变更数据库结构，仅改代码层注释/映射）
-- **无结构变更**：纯逻辑变更（如增加唯一性校验）不产生 DDL，在此注明即可
-
-> SQL 追加原则：所有 DDL 变更追加到对应 sql 文件末尾，遵循只追加不修改原则。
-
-### 3. 切片（slices）—— [必填]
-
-每个切片是**一个从数据到 UI 的端到端闭环**（窄而完整）。切片按依赖顺序排列；每个切片包含：
-
-```markdown
-### 切片 N · 切片名称
-<phase id="<phase-id>" status="未开始"><!-- 未开始 → 已实现(dev/03) → 已验证(dev/04) --></phase>
-
-- **类型：** `AFK` | `HITL`
-- **阻塞于：** 切片 M（或「无」）
-- **覆盖：** PRD 章节 / US 编号 / 用户故事简述
-- **需阅读的文件：** 实现本切片前需理解的现有代码（| 文件 | 目的 | 表）；单文件小改可省略
-- **交付物：** 该切片产出的具体文件/模块/功能清单
-- **需修改的文件：** 本切片要改动的文件（| 文件 | 改动内容 | 表）；新增文件标 **新增**，重度重构标 **重度重构**
-- **保留/不动：** 本切片**不能碰**的代码/契约/数据（如冻结常量、共享依赖、邻近功能）；无则写「无」
-- **复用：** 复用哪些现有能力（模块/文件/命令）
-- **实现要点：** 关键技术决策、算法细节、并发控制、兜底策略（编号列表）；单文件小改可省略
-- **验收切片：** 一个可独立执行的验证命令或手动检查步骤，证明本切片完成；**删除型切片须含残留扫描**（如 `grep -rn "<符号>" <范围>` 应 0 命中）
-- **对齐：** PRD FR-xxx 或 issue 引用
-- **ADR 引用：** （可选）关联的工程层 ADR 编号
-```
-
-- `<phase id="...">` 是稳定的阶段标识（如 `phase0-node-base`、`phase1-templates`），供 `dev/03` TDD 工作流引用。单阶段 change 用 `phase0-<slug>`。
-- `status` 枚举：`未开始`（切片创建时） → `已实现`（TDD finish 置入） → `已验证`（finalize 置入）。状态只前进不回退。
-- **需阅读/需修改的文件表**：借鉴高质量 plan 的双表模式——读文件表让执行者知道上下文边界，改文件表让执行者知道改动面和操作类型（新增/修改/重构）。单文件小改的切片可省略读文件表。
-- **实现要点**：每个切片列出 3-7 条关键技术点，让执行者拿到切片就知道怎么下手。包含算法细节、并发控制、兼容/兜底策略等。
-
-### 4. 横切关注点与铁律（贯穿所有切片）—— [必填]
-
-列出跨切片一致的规则、约束与不可违反的铁律，如：
-- **数据安全铁律**：必须冻结的常量 / wire-format / 密文格式（改了即用户数据损坏）——显式列出，标「不动」。
-- **契约先行**：磁盘契约先改 zod + fixtures 再改解析。
-- **删缓存可重建**铁律。
-- 范围隔离规则（不 import 旧子系统等）、命名消歧规则。
-- **行号现场核对纪律**：本计划内所有行号为近似，实施时以现场代码为准。
-
-### 5. 依赖顺序速查 —— [必填]
-
-ASCII 依赖链，展示切片先后顺序：
-
-```
-P0  切片0  名称    ← 不可回退,最先
-P1  切片1  名称
-P2  切片2  名称    依赖 P0+P1
-...
-```
-
-### 6. 风险与回滚 —— [条件]
-
-本期涉及删除、数据迁移、外部副作用或高耦合改动时填写；纯增量的单文件小改可省。逐条列出风险、触发条件、缓解与回滚手段（表格形式）。**有 `overview.md` 的「风险与未知点」则继承并细化**。
-
-### 7. 退役清单 —— [条件]
-
-仅当本 change **删除既有能力**时填写：用「项 / 处置 / 验证」表逐条记录被删/被迁的内容及其去向，作为兜底核对。
-
-### 8. 验证总览 —— [必填（轻）]
-
-change 级验证 roll-up，补足每切片「验收切片」的整体闭环（按适用项填，不适用标「N/A」）：
-- **静态检查**：构建 / 类型 / lint。
-- **测试**：单测 / 契约校验。
-- **残留扫描**：对删除项 grep，应 0 命中。
-- **E2E 冒烟**：真实运行应用走查关键路径。
-- **迁移测试**：若涉及持久化 / 格式 / 键名迁移，预置旧数据验证向后兼容。
-
-> **判据：** 每个切片的「验收切片」全部通过即该切片完成；§8 验证总览整体通过 = change 可进入 `dev/04` 收尾。
-
-## 存疑时的提问协议（决策树）
-
-切分切片或填 §0「已确认决策」时若有未决分支，**不要臆测**——先用代码库探索尝试确定，无法确定时再用 `AskUserQuestion` 按决策树逐一锁定；本协议产出的共识即写入 §0：
-
-1. **定位关键问题**：识别当前最影响方案正确性的那一个未决问题。
-2. **先查后问**：若答案能用本地代码 / 文档 / 配置确认，先读相关材料；搜索 `grep -rn`、`git log`、读取测试文件。能从仓库确定则不问。
-3. **一次一问**：每次只问一个问题，不打包问题组。
-4. **带推荐**：每个问题给出推荐答案并说明理由（基于已探索的代码库上下文）。
-5. **回答后收敛**：用户回答后，更新 §0「已确认决策」与剩余分支。
-6. **遍历至共识**：沿决策树继续，直到核心分支达成共识或用户叫停。
-
-## 填写引导
-
-1. 遵循 `I-to-issues.md` 的内置切片指引与「切片计划质量准则」，以及本文件的结构规范。
-2. **写 Context（§0）**：提炼一句话战略；**采集或继承已确认决策**（有 `decision-log.md` 则继承）；**梳理当前现状**（逐条记录与需求不符的现有实现，精确到文件路径+行号）；**记录关键核实结论**（写明行号为近似、现场核对）；点明预期产出。未决分支按「存疑时的提问协议」逐一锁定。
-3. **采集范围**：从 PRD / decision-log / diagnosis / 用户指令中提取 IN/REUSE/OUT 三列、架构上下文和 ADR 引用；不确定的标记 `[待确认]`。
-4. **记录数据库变更（§2.5）**：涉及 schema 变更时，用「涉及的数据库表」表记录每张表的变更（新建/新增字段/语义调整），DDL 注明 sql 文件和追加位置。
-5. **切分垂直切片（§3）**：优先窄而完整、优先 AFK；每个切片必须写明**需阅读的文件**（\| 文件 \| 目的 \|）、**需修改的文件**（\| 文件 \| 改动内容 \|，新增标 **新增**，重构标 **重度重构**）、**实现要点**（编号列表）、用户可独立验证的「验收切片」，并标注**保留/不动**；删除型切片在验收里配残留扫描。
-6. **标注 phase id**：为每个切片生成稳定的 `<phase id="...">` 标识（kebab-case），供 TDD 阶段直接引用。
-7. **填条件段**：涉及删除 / 迁移 / 外部副作用时补 §6 风险与回滚、§7 退役清单；多模块时补 §2 架构上下文。
-8. **汇总关键决策（§5.5）**：将跨切片的技术选型与取舍写入「关键决策」段（方案选择、字段复用/新建决策、SQL 追加规则等），防止下游反复争论。
-9. **收口验证（§8）**：列出静态 / 测试 / 残留扫描 / E2E / 迁移的整体验证项。
-10. 用编号列表向用户确认粒度、依赖、HITL/AFK 标记、phase id 和是否需要发布外部 issue。
-11. 按依赖顺序记录切片；发布外部 issue 时也按依赖顺序发布。
-12. 迭代直到用户批准分解；未批准前不发布外部 issue。
-
-## 边界
-
-- 不关闭或修改父级 issue。
-- 不默认发布到外部 tracker。
-- 不写实现代码。
-- 不编造来源；PRD/ADR/issue 引用必须真实存在。
-- 不照搬过期行号：所有行号为近似，实施期以现场代码为准。
-
-## 完成准则
-
-- `slices.md` 无残留 `[TODO:]`
-- §0 战略与背景含已确认决策、**当前现状**与关键核实结论（独立进入时自采集，有上游则继承）
-- 存疑点已按「存疑时的提问协议」逐一与用户锁定，或显式标记 `[待确认]`
-- 每个切片都有 `<phase id="...">` 标识、类型、依赖、覆盖来源、**需阅读/需修改文件表**、**实现要点**、验收切片；删除型切片标注保留/不动且验收含残留扫描
-- IN/REUSE/OUT 表格完整（无法确定时标 `[待确认]` 并已获用户补充）
-- 涉及 schema 变更时 §2.5 数据库表已填写（表名、变更类型、DDL 位置）
-- §5.5 关键决策已汇总跨切片技术选型与取舍
-- §8 验证总览存在（静态 / 残留扫描 / 冒烟按适用项填）
-- 适用时已填条件段（§2 架构 / §2.5 数据库表 / §5.5 关键决策 / §6 风险 / §7 退役）
-- `.status.json` 已记录 `slice_count`、`hitl_slice_count` 和 `issue_tracker_mode`

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

@@ -1,74 +0,0 @@
-# ADR 格式
-
-本文是项目架构决策记录（ADR）格式与判据的**单一事实源**，由 `dev/M-domain-modeling` 拥有，`dev/01`、`dev/04`、`dev/A` 等工作流按需引用。
-
-默认产物写入调用方工作流的会话产物（如 `decision-log.md`、`domain-model-log.md`）；只有用户明确确认时，才按本格式创建项目 ADR。
-
-ADR 存放在 `speculo/.speculo/.config/adr/` 目录下，使用顺序编号：`0001-slug.md`、`0002-slug.md`，以此类推。`speculo/.speculo/.config/adr/` 目录由 Speculo 初始化提供；如果目标项目缺失该目录，按需创建。
-
-## 模板
-
-```md
-# {决策的简短标题}
-
-{1-3 句话：背景是什么、我们决定了什么、为什么这样决定。}
-```
-
-就这些。一个 ADR 可以只是一段话。价值在于记录「做出了某个决策」以及「为什么」——而不是填满各个章节。
-
-## 生命周期元数据
-
-默认 ADR 不需要元数据。只有当决策需要生命周期联动时，在标题下方放极简字段：
-
-```md
-# {决策的简短标题}
-
-Status: accepted
-superseded_by: null
-
-{1-3 句话：背景是什么、我们决定了什么、为什么这样决定。}
-```
-
-允许值：
-
-- `Status: proposed | accepted | deprecated | superseded`
-- `superseded_by: ADR-NNNN | null`
-
-当新 ADR 取代旧 ADR 时：
-
-- 新 ADR 正文说明取代了哪个 ADR 以及原因。
-- 旧 ADR 顶部更新为 `Status: superseded` 和 `superseded_by: ADR-NNNN`。
-- 若项目有 ADR 索引或 README，同步状态和取代链。
-- 任何 CONTEXT、AGENTS、README 或 docs 中的旧 ADR 引用都必须改为新 ADR、删除，或标记为待确认。
-
-## 可选章节
-
-只有确实能增加价值时才包含以下章节。大多数 ADR 不需要它们。
-
-- **Status** 前置元数据（见「生命周期元数据」）—— 当决策被重新审视时很有用
-- **Considered Options** —— 只有被拒绝的替代方案值得记住时才写
-- **Consequences** —— 只有非显而易见的下游影响需要指出时才写
-
-## 编号
-
-扫描 `speculo/.speculo/.config/adr/` 找到已有的最大编号，然后加一。
-
-## 何时提议创建 ADR
-
-以下三个条件必须同时满足：
-
-1. **难以逆转** —— 日后改变主意的代价不可忽略
-2. **缺少上下文会令人意外** —— 未来的读者看到代码会疑惑「他们到底为什么要这样做？」
-3. **真实权衡的结果** —— 确实存在替代方案，而你基于特定原因选择了其中一个
-
-如果一个决策很容易逆转，就跳过它——你反正会逆转它。如果它不令人意外，没人会疑惑为什么。如果没有真正的替代方案，除了「我们做了显而易见的事」之外没有什么可记录的。
-
-### 哪些情况应该写 ADR
-
-- **架构形态。** 「我们使用 monorepo。」「写模型采用事件溯源，读模型投射到 Postgres。」
-- **上下文之间的集成模式。** 「Ordering 和 Billing 通过领域事件通信，而非同步 HTTP。」
-- **带有锁定效应的技术选型。** 数据库、消息总线、认证提供商、部署目标。不是每个库——只是那些换掉需要花一个季度的。
-- **边界和范围决策。** 「客户数据由 Customer 上下文拥有，其他上下文只通过 ID 引用。」明确的「不做」和「要做」同样有价值。
-- **刻意偏离显而易见的路径。** 「我们用原生 SQL 而非 ORM，因为 X。」任何理性读者会假设相反做法的地方。这能防止下一个工程师去「修复」某个刻意为之的设计。
-- **代码中看不见的约束。** 「因为合规要求，我们不能用 AWS。」「因为合作方 API 合约，响应时间必须在 200 ms 以内。」
-- **拒绝理由不明显的替代方案。** 如果你考虑过 GraphQL 但因为某些微妙原因选了 REST，记录下来——否则六个月后会有人再次提议 GraphQL。

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,102 +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 目录时
-
-若无 active change，执行 `../AGENTS.md` 进入协议步骤 3（原子三步），不得内联自初始化 JSON。
-
-## 阶段
-
-> **惰性创建文件**——只在需要写入时才创建。`.config/context/CONTEXT.md` 与 `.config/adr/` 由 Speculo 初始化提供；若目标项目缺失，在第一个术语 / ADR 解决时按需创建。
-
-### 1. Model Session — 词汇与决策沉淀
-- id：`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；嵌入其他工作流时随宿主流程推进。