@namewta/speculo 0.1.9 → 0.1.11

package/template/workflows/dev/00-INDEX.md

@@ -22,9 +22,9 @@ keywords: [dev, 开发, workflow, index, 状态]
 | `dev/02` | `02-prd/02-prd.md` | zoom-out 全景理解与 PRD 综合 |
 | `dev/03` | `03-tdd/03-tdd.md` | 垂直切片 TDD 实现 |
 | `dev/04` | `04-finalize/04-finalize.md` | 完成前验证、状态收尾与归档 |
-| `dev/I` | `I-to-issues/I-to-issues.md` | 垂直切片 issue 分解，可嵌入其他 dev workflow |
-| `dev/H` | `H-diagnose/H-diagnose.md` | hotfix / bug / 性能回退诊断 |
-| `dev/R` | `R-review/R-review.md` | Spec / Engineering / Standards 三维度 diff 审查 |
+| `dev/I` | `I-to-issues/I-to-issues.md` | 垂直切片 issue 分解，可嵌入其他 dev workflow，也可独立进入 |
+| `dev/H` | `H-diagnose/H-diagnose.md` | hotfix / bug / 性能回退诊断，零依赖，可独立进入 |
+| `dev/R` | `R-review/R-review.md` | Spec / Engineering / Standards 三维度 diff 审查，零依赖，可独立进入 |
 | `dev/D` | `D-docs-sync/D-docs-sync.md` | 基于 git diff 同步 README、CHANGELOG、AGENTS 等对外文档 |
 
 ## 进入协议
@@ -42,11 +42,13 @@ keywords: [dev, 开发, workflow, index, 状态]
 - `full`：`dev/01` -> `dev/02` -> `dev/I` -> `dev/03` -> `dev/04`。
 - `planning-only`：`dev/01` -> `dev/02` -> `dev/I`，不进入实现。
 - `implementation-only`：已有 PRD、issue 或明确任务时，从 `dev/03` 开始。
-- `hotfix`：Bug、异常、性能回退时，从 `dev/H` 开始；修复阶段可嵌入 `dev/03` 的 TDD 回归循环。
-- `review`：已有 fixed point 或用户要求审查时，从 `dev/R` 开始。
+- `hotfix`：Bug、异常、性能回退时，从 `dev/H` 开始（零依赖，无需上游工作流产物）；修复阶段可嵌入 `dev/03` 的 TDD 回归循环。
+- `review`：已有 fixed point 或用户要求审查时，从 `dev/R` 开始（零依赖，无需上游工作流产物）。
 - `finalize`：实现完成、需要完成前验证与状态收尾归档时，从 `dev/04` 开始。
 - `docs-sync`：需要基于 git 差异刷新对外文档时，从 `dev/D` 开始。
 
+> **独立入口说明：** `dev/H`、`dev/I`、`dev/R` 三个横向工作流均为零硬依赖设计。用户可直接从任一入口进入，无需预先执行 `dev/01`、`dev/02` 等主线工作流。当同 change 目录下缺少上游产物时，各工作流会自行通过代码库探索（git 考古、grep 搜索、文档扫描）采集所需上下文，仅在代码库无法确定的决策点上询问用户。
+
 ## 状态汇报
 
 输出 dev 状态时至少包含：

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

@@ -39,6 +39,43 @@ keywords: [diagnose, hotfix, bug, debug, performance, 回归]
 
 详细诊断纪律在同目录 `diagnose-guide.md`。必须由人类操作才能复现时，按 `scripts/hitl-loop.template.sh` 建立结构化 HITL 循环。
 
+### 独立使用
+
+本工作流**零硬依赖**，无需预先执行 dev/01、dev/02 等其他工作流即可独立进入。只需用户描述 Bug/异常/性能症状 + 当前 git 仓库即可启动。
+
+**独立进入流程：**
+
+1. **change 目录**：若用户未指定 `<change>` 目录，按 `YYYY-MM-DD-<kebab-name>` 格式创建（如 `2026-06-17-fix-login-timeout`），初始化 `.status.json` 并更新 `dev-status.json`。
+2. **信息自采集**：若同 change 目录下无上游产物（PRD、decision-log 等），**自行通过代码库探索采集诊断所需上下文**，不要求用户先执行其他工作流：
+   - `git log --oneline -30` 查找近期相关变更
+   - 搜索错误信息/堆栈中的关键符号（`grep -rn` 在项目中定位）
+   - 读取相关模块的代码、测试和配置文件
+   - 检查 `speculo/.speculo/.config/` 下的项目规则与 ADR
+3. **深度搜索**：反馈循环构建受阻时，不轻易放弃——按 `diagnose-guide.md` 的 10 种方法逐项尝试；代码库中找不到线索时，搜索项目文档、issue tracker、CI 日志。
+4. **仅必要时询问**：仅在代码库探索无法确定的关键决策点（如需要访问外部环境、需要用户提供日志文件）使用 `AskUserQuestion`。
+
+### 缺少 change 目录时的自初始化
+
+若当前无对应 change 目录，按以下步骤创建：
+
+1. 从用户报告的 Bug/异常提取 `<kebab-name>`（如 `fix-login-timeout`、`fix-payment-npe`）
+2. 创建 `speculo/.speculo/dev/<YYYY-MM-DD>-<kebab-name>/`
+3. 初始化 `.status.json`：
+   ```json
+   {
+     "dev_entry": "dev/H",
+     "current_phase": "1. Diagnose Loop",
+     "phase_history": [],
+     "change_status": "active",
+     "embedded_guides": ["diagnose"],
+     "feedback_loop": "none",
+     "hypothesis_status": "open",
+     "regression_test": "blocked",
+     "debug_artifacts": []
+   }
+   ```
+4. 在 `speculo/.speculo/dev-status.json` 的 `active` 数组中追加该 change 目录名
+
 ## 阶段
 
 ### 1. Diagnose Loop — 反馈循环与假设
@@ -61,8 +98,8 @@ keywords: [diagnose, hotfix, bug, debug, performance, 回归]
 
 ## 依赖
 
-- 软依赖：无
 - 硬依赖：无
+- 软依赖：无。若同 change 目录下存在其他工作流产物（如 diagnosis.md），可继承其信息加速执行；缺失时自行采集，不阻塞流程。修复阶段可嵌入 `../03-tdd/03-tdd.md` 的 Slice Loop 执行 TDD 修复，此为可选加速而非必须。
 
 ## 状态扩展字段
 

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

@@ -2,7 +2,7 @@
 
 ## 输入
 
-- `diagnosis.md`
+- `diagnosis.md`（本工作流 Phase 1 自产；独立进入时由 diagnose-loop 生成，无需外部提供）
 - 已确认或最高可信假设
 - 原始反馈循环和可用测试接缝
 - `H-diagnose.md` 中的内置诊断指引

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

@@ -4,6 +4,36 @@
 
 一套针对疑难 Bug 的纪律。仅在明确合理时才跳过阶段。
 
+## 独立诊断时的信息采集
+
+当本工作流独立进入（无上游 PRD、decision-log 等产物）时，在构建反馈循环之前先执行以下信息采集。不要求用户先跑其他工作流。
+
+### 1. 快速环境扫描
+
+- `git log --oneline -30` 查看近期变更，关注可能与 Bug 相关的 commit
+- `git log --oneline --all -- <相关文件路径>` 追溯问题模块的变更历史
+- 读取 `speculo/.speculo/.config/RULES.md` 了解项目规则
+- 读取相关模块的 `README.md` 或 `AGENTS.md` 了解架构约定
+
+### 2. 症状定位
+
+- 若有错误信息/堆栈：`grep -rn "<关键符号>"` 在项目中全局搜索，定位所有相关代码路径
+- 若有性能回退：搜索相关模块最近的性能敏感变更（循环、查询、缓存）
+- 若为测试失败：读取失败测试文件及其覆盖的源代码，理解预期行为
+- 搜索项目中是否已有类似的 issue、TODO、FIXME 提及该问题
+
+### 3. 相关模块深度探索
+
+- 读取问题代码路径的所有相关文件（调用链上下游）
+- 阅读现有测试了解模块契约
+- 检查 `speculo/.speculo/.config/adr/` 中与问题模块相关的架构决策
+- 搜索 `speculo/.speculo/doc/` 中已有的领域文档
+
+### 4. 信息仍不足时
+
+- 用 `AskUserQuestion` 向用户索取：复现环境、日志文件、HAR 捕获、核心转储等——但仅在代码库探索穷尽后
+- 不要因缺少上游产物而放弃或要求用户先执行 dev/01、dev/02
+
 探索代码库时，使用项目的领域术语表来建立相关模块的清晰心智模型，并查阅你所触及区域的 ADR。
 
 ## 阶段 1 —— 构建反馈循环

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

@@ -4,8 +4,17 @@
 
 - 用户描述的失败现象、日志、trace、性能症状或失败测试
 - 可运行的测试、脚本、服务、CLI 或浏览器自动化
-- `H-diagnose.md` 中的内置诊断指引
-- 同目录 `diagnose-guide.md`
+- `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` 向用户索取无法从仓库获取的信息（复现环境、日志文件等）
 
 ## 产物
 

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

@@ -50,6 +50,48 @@ keywords: [issues, slices, vertical, AFK, HITL, 切片]
 - **复用优先于新造**：能复用就不新建，在切片「复用」字段与 §1 REUSE 列显式记录。
 - **重型小节按需**：风险登记、退役清单、架构上下文是条件段——复杂 change 铺开，单文件小改可省。
 
+### 独立使用
+
+本工作流**零硬依赖**，无需预先执行 dev/01、dev/02 等其他工作流即可独立进入。只需用户描述任务意图 + 当前 git 仓库即可启动。
+
+**独立进入流程：**
+
+1. **change 目录**：若用户未指定 `<change>` 目录，按 `YYYY-MM-DD-<kebab-name>` 格式创建（如 `2026-06-17-refactor-auth`），初始化 `.status.json` 并更新 `dev-status.json`。
+2. **信息自采集**：若同 change 目录下无上游产物（PRD、decision-log、diagnosis 等），**自行通过代码库探索采集切片所需上下文**，不要求用户先执行其他工作流：
+   - 探索项目目录结构，建立模块心智模型（`src/`、`core/`、`tests/` 等）
+   - 读取 `AGENTS.md`、`README.md`、`CONTRIBUTING.md` 了解项目规范与架构约定
+   - `git log --oneline -30` 了解近期变更趋势和相关模块
+   - 搜索相关代码区域的注释、TODO、FIXME 和现有 issue 引用
+   - 读取 `speculo/.speculo/.config/RULES.md` 和 `speculo/.speculo/.config/adr/` 了解项目决策
+3. **深度搜索**：信息仍不足时，执行以下顺序的深度探寻：
+   - 搜索项目中与用户意图关键词匹配的代码、注释和文档
+   - 追溯相关模块的 git history（`git log -p -- <path>`）
+   - 搜索 `speculo/.speculo/doc/` 和 `speculo/.speculo/archive/` 中已有的领域文档
+   - 检查现有测试文件了解模块契约和边界行为
+4. **存疑即问**：仅在代码库探索无法确定的决策分支上，按「存疑时的提问协议」使用 `AskUserQuestion` 一次一问、带推荐、逐步锁定。
+
+### 缺少 change 目录时的自初始化
+
+若当前无对应 change 目录，按以下步骤创建：
+
+1. 从用户意图提取 `<kebab-name>`（如 `refactor-auth`、`add-export-feature`）
+2. 创建 `speculo/.speculo/dev/<YYYY-MM-DD>-<kebab-name>/`
+3. 初始化 `.status.json`：
+   ```json
+   {
+     "dev_entry": "dev/I",
+     "current_phase": "1. Slice Issues",
+     "phase_history": [],
+     "change_status": "active",
+     "embedded_guides": ["to-issues"],
+     "slice_count": 0,
+     "hitl_slice_count": 0,
+     "published_issue_refs": [],
+     "issue_tracker_mode": "local-only"
+   }
+   ```
+4. 在 `speculo/.speculo/dev-status.json` 的 `active` 数组中追加该 change 目录名
+
 ## 阶段
 
 ### 1. Slice Issues — 垂直切片分解
@@ -65,8 +107,8 @@ keywords: [issues, slices, vertical, AFK, HITL, 切片]
 
 ## 依赖
 
-- 软依赖：`../02-prd/02-prd.md`，scope: same-change
-- 硬依赖：无；可从用户计划、issue、诊断结论或 PRD 直接进入
+- 硬依赖：无
+- 软依赖：无。若同 change 目录下存在其他工作流产物（如 prd.md、decision-log.md、diagnosis.md），可继承其信息加速执行；缺失时自行采集，不阻塞流程。完成后通常移交 `../03-tdd/03-tdd.md`，此为推荐后续而非必须。
 
 ## 状态扩展字段
 

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

@@ -4,12 +4,43 @@
 > `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 架构约束
+- 无法从代码库确定的 → `[待确认]` 标记，按提问协议处理
+- 从 `prd-overview.md` 或现有文档继承的风险 → §6 风险与回滚
+
 ## 输入
 
-- `prd.md`、`decision-log.md`、`diagnosis.md`、现有 issue 或用户计划
+- `prd.md`、`decision-log.md`、`diagnosis.md`、现有 issue 或用户计划（均为可选；缺失时按「独立进入时的深度搜索协议」自行采集）
 - 可选 issue tracker 配置和标签词汇表
-- `I-to-issues.md` 中的内置切片指引与「切片计划质量准则」
-- 同级 change 目录下已有的 `context-map.md`、`decision-log.md`、`prd-overview.md`（若存在，用于继承领域术语、已确认决策、风险与 ADR 引用）
+- `I-to-issues.md` 中的内置切片指引、「切片计划质量准则」与「独立使用」协议
+- 同级 change 目录下已有的 `context-map.md`、`decision-log.md`、`prd-overview.md`（若存在，用于继承领域术语、已确认决策、风险与 ADR 引用；不存在则按深度搜索协议自采集）
 
 ## 产物
 
@@ -112,12 +143,12 @@ change 级验证 roll-up，补足每切片「验收切片」的整体闭环（
 
 ## 存疑时的提问协议（决策树）
 
-切分切片或填 §0「已确认决策」时若有未决分支，**不要臆测**——用 `AskUserQuestion` 按决策树逐一锁定；本协议产出的共识即写入 §0：
+切分切片或填 §0「已确认决策」时若有未决分支，**不要臆测**——先用代码库探索尝试确定，无法确定时再用 `AskUserQuestion` 按决策树逐一锁定；本协议产出的共识即写入 §0：
 
 1. **定位关键问题**：识别当前最影响方案正确性的那一个未决问题。
-2. **先查后问**：若答案能用本地代码 / 文档 / 配置确认，先读相关材料；能定则不问。
+2. **先查后问**：若答案能用本地代码 / 文档 / 配置确认，先读相关材料；搜索 `grep -rn`、`git log`、读取测试文件。能从仓库确定则不问。
 3. **一次一问**：每次只问一个问题，不打包问题组。
-4. **带推荐**：每个问题给出推荐答案并说明理由。
+4. **带推荐**：每个问题给出推荐答案并说明理由（基于已探索的代码库上下文）。
 5. **回答后收敛**：用户回答后，更新 §0「已确认决策」与剩余分支。
 6. **遍历至共识**：沿决策树继续，直到核心分支达成共识或用户叫停。
 

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

@@ -60,6 +60,51 @@ keywords: [review, diff, spec, engineering, standards, security, solid, pr, 审
 - `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 — 固定点、范围与来源收集
@@ -93,8 +138,8 @@ keywords: [review, diff, spec, engineering, standards, security, solid, pr, 审
 
 ## 依赖
 
-- 软依赖：`../02-prd/02-prd.md` 或 `../I-to-issues/I-to-issues.md`，scope: same-change
 - 硬依赖：无；用户提供 fixed point 即可进入
+- 软依赖：无。若同 change 目录下存在其他工作流产物（如 prd.md、slices.md、decision-log.md），可继承其信息增强 Spec 维度审查；缺失时自行采集（commit message、代码注释、项目文档），不阻塞流程。审查完成后是否进入修复（`../03-tdd/03-tdd.md`）或归档（`../04-finalize/04-finalize.md`）由用户决定。
 
 ## 状态扩展字段
 

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

@@ -18,9 +18,13 @@
 
 ### Spec 维度（做对了吗）
 
-1. 先读 spec，再读 diff。
+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 原文。缺少 spec 时整区写 `no spec available`。
+3. 每条引用 spec 原文（若有）或推断来源（commit message/测试/注释）。
 
 ### Engineering 维度（做好了吗）
 

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

@@ -6,6 +6,28 @@
 - 当前 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` 填写
@@ -19,17 +41,21 @@
    - **大 diff（> 500 行）**：先按文件 / 模块汇总，再按模块或功能分批审查。
    - **混合关注点**：按逻辑功能分组，不只按文件顺序。
 4. 标识关键路径：auth / 授权、支付 / 金额、数据写入、网络 / 外部调用、并发 —— 这些区域在 Engineering 维度需重点审查。
-5. 寻找 spec 来源，顺序为：
-   - commit message 中的 issue / PR 引用
+5. 寻找 spec 来源，按「独立进入时的来源深度搜索」中的 Spec 扩展发现顺序执行：
+   - commit message 中的 issue / PR 引用 → commit message 全文搜索
    - 用户作为参数传入的路径
-   - `speculo/.speculo/dev/<change>/prd.md`、`slices.md`、`decision-log.md`
+   - 代码注释/TODO/FIXME 中的需求线索
    - 仓库中与分支名或功能匹配的规格文档
-6. 寻找 standards 来源，常见路径包括：
+   - `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`
+   - `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`。
 

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

@@ -25,6 +25,9 @@
    2. 仅修复 P0 / P1
    3. 修复指定项（由用户点名）
    4. 不改动，审查到此为止
+   - 若选择修复且仓库支持，移交 `../03-tdd/03-tdd.md` 的红绿重构循环
+   - 若选择不改动且 change 已完成其使命，可移交 `../04-finalize/04-finalize.md` 归档
+   - 独立进入时（无上下游工作流），以上移交均为可选推荐，由用户决定后续路径
 5. 用户选择修复时，移交 `../03-tdd/03-tdd.md` 的红绿重构循环执行，并在该 change 内继续维护状态。
 
 ## 边界

package/template/workflows/doc/00-INDEX.md

@@ -18,7 +18,6 @@ keywords: [doc, writing, article, fragments, edit, 文档, 写作]
 
 | 别名 | 入口 | 用途 |
 |------|------|------|
-| `doc/M` | `M-mao-zedong-cognitive-os/M-mao-zedong-cognitive-os.md` | 以毛泽东方法论为底座的认知咨询：分析问题→制定战略→组织行动 |
 | `doc/T` | `T-teach/T-teach.md` | 设计交互式课程：使命→资源→课程→参考→记录 |
 | `doc/F` | `F-writing-fragments/F-writing-fragments.md` | 追问式访谈，沉淀异质 fragment 素材 |
 | `doc/B` | `B-writing-beats/B-writing-beats.md` | 逐个 beat 推进文章旅程 |
@@ -36,7 +35,6 @@ keywords: [doc, writing, article, fragments, edit, 文档, 写作]
 
 ## 执行模式
 
-- `mao`：以毛泽东方法论进行结构化认知咨询——分析问题、制定战略、组织行动，进入 `doc/M`。
 - `teach`：想学某个主题，需要设计交互式课程体验，进入 `doc/T`。
 - `fragments`：从主题和对话中采集素材，进入 `doc/F`。
 - `beats`：已有素材，想逐个转向推进叙事，进入 `doc/B`。

package/template/workflows/person/00-INDEX.md

@@ -0,0 +1,51 @@
+---
+id: person/index
+category: person
+name: Person Workflow Index
+description: 以人物方法论为底座的工作流导航入口
+keywords: [person, methodology, 人物, 方法论, cognitive, 认知]
+---
+
+# Person Workflow Index
+
+> ⚠️ **持久化铁律：本文件及所有 person workflow 的全部产物，必须且只能写入 `speculo/.speculo/person/<change>/`。绝对禁止写入项目根目录的 `.speculo/`、`temp/` 或其他任何非规范位置。**
+
+本文件是 person 分类的导航入口。进入时先读取 `speculo/.speculo/person-status.json`，再按其中 active change 读取 `speculo/.speculo/person/<change>/.status.json`，根据用户意图推荐横向 workflow。
+
+> **命名铁律：** 所有 change 目录必须为 `YYYY-MM-DD-<kebab-name>`（例：`2026-06-12-mao-strategy-consult`）。不符合此格式的目录视为 `malformed`，仅汇报不自动操作。
+
+## 入口别名
+
+| 别名 | 入口 | 用途 |
+|------|------|------|
+| `person/M` | `M-mao-zedong-cognitive-os/M-mao-zedong-cognitive-os.md` | 以毛泽东方法论为底座的认知咨询：分析问题→制定战略→组织行动 |
+
+## 进入协议
+
+1. 若用户未指定 change，扫描 `speculo/.speculo/person-status.json` 和 `speculo/.speculo/person/*/.status.json`，列出 active changes。
+   - **命名校验**：扫描时仅处理符合 `YYYY-MM-DD-<kebab-name>` 格式的目录。不符合的目录标记为 `malformed`，单独列出路径并提示用户修复或手动清理，不自动删除或重命名。
+2. 若只有一个 active change，默认继续该 change；若有多个 active change，要求用户选择。
+3. 若没有 active change，按用户意图创建新的 change 目录，**目录名必须为 `YYYY-MM-DD-<kebab-name>`**（使用当前日期，`<kebab-name>` 从用户意图提取），并初始化 `.status.json` 与 `speculo/.speculo/person-status.json`。
+4. 推荐入口时优先使用用户显式别名；没有别名时按用户意图推荐一个横向 workflow。
+5. 执行任何 workflow 前，读取该 workflow 入口文件、阶段文件和模板。
+
+## 执行模式
+
+- `mao`：以毛泽东方法论进行结构化认知咨询——分析问题、制定战略、组织行动，进入 `person/M`。
+
+## 状态汇报
+
+输出 person 状态时至少包含：
+
+- active change 数量与每个 change 的 `current_phase`
+- malformed 目录清单（不符合 `YYYY-MM-DD-<kebab-name>` 格式的目录）
+- 每个 change 的当前文档路径、素材路径和最近写入时间
+- `phase_history` 最后一项为 `blocked` 或 `updated_at` 超过 14 天未变化的 change
+- 推荐下一步入口和原因
+
+## 完成与状态更新
+
+- 所有 person workflow 必须维护同一 change 的 `.status.json`。
+- 进入 phase 时更新 `current_phase`，并在 `phase_history` 追加 `in-progress` 记录。
+- phase 完成时写入 `completed_at` 和 `status: completed`。
+- 用户确认咨询输出或分析边界完成后，才把 `change_status` 置为 `completed`。

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/M-mao-zedong-cognitive-os.md

@@ -1,6 +1,6 @@
 ---
-id: doc/M-mao-zedong-cognitive-os
-category: doc
+id: person/M-mao-zedong-cognitive-os
+category: person
 name: 毛泽东认知操作系统
 description: 以毛泽东方法论为底座的问题诊断、战略制定与行动规划咨询工作流；当用户需要以矛盾分析、持久战思维、群众路线等方法论拆解复杂问题、制定对策、组织落地时使用
 keywords: [毛泽东, 毛选, 教员, 矛盾分析, 战略, 组织, 认知模型, 咨询, 持久战, 群众路线]
@@ -20,7 +20,7 @@ keywords: [毛泽东, 毛选, 教员, 矛盾分析, 战略, 组织, 认知模型
 
 **局限**：聚焦思维方法论的迁移，不评判政治立场；涉及 1949 年后争议历史只取思维方法论侧面并标注边界。
 
-> **目录命名：** `<change>` 必须为 `YYYY-MM-DD-<kebab-name>`（例：`2026-06-12-mao-strategy-consult`）。产物写入 `speculo/.speculo/doc/<change>/`。
+> **目录命名：** `<change>` 必须为 `YYYY-MM-DD-<kebab-name>`（例：`2026-06-12-mao-strategy-consult`）。产物写入 `speculo/.speculo/person/<change>/`。
 
 ## 内置指引
 
@@ -99,7 +99,7 @@ keywords: [毛泽东, 毛选, 教员, 矛盾分析, 战略, 组织, 认知模型
 
 ## 阶段
 
-> **产物目录：** 本工作流所有产物写入 `speculo/.speculo/doc/<change>/`。下文产物路径均相对该 change 目录。**`<change>` 必须为 `YYYY-MM-DD-<kebab-name>`**（例：`2026-06-12-mao-strategy-consult`）。
+> **产物目录：** 本工作流所有产物写入 `speculo/.speculo/person/<change>/`。下文产物路径均相对该 change 目录。**`<change>` 必须为 `YYYY-MM-DD-<kebab-name>`**（例：`2026-06-12-mao-strategy-consult`）。
 
 ### 1. 激活与问诊 — Activate
 - 规范：`activate.md`
@@ -158,7 +158,7 @@ keywords: [毛泽东, 毛选, 教员, 矛盾分析, 战略, 组织, 认知模型
 
 本工作流需在同 change 的 `.status.json` 追加：
 
-- `doc_entry` (string) — 固定为 `doc/M`
+- `doc_entry` (string) — 固定为 `person/M`
 - `problem_type` (string) — 问题类型（战略方向/强敌竞争/实力悬殊/起步弱小/资源分配/团队组织/决策方法/路线两难）
 - `primary_framework` (string) — 主框架（如 `B1-持久战`、`A1-矛盾分析`）
 - `models_applied` (array) — 已应用的 Module A 模型列表

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/activate.md

@@ -3,11 +3,11 @@
 ## 输入
 
 - 用户描述的困境、问题或咨询主题
-- 当前 doc change 目录：`speculo/.speculo/doc/<change>/`
+- 当前 doc change 目录：`speculo/.speculo/person/<change>/`
 
 ## 产物
 
-- `speculo/.speculo/doc/<change>/problem-statement.md`
+- `speculo/.speculo/person/<change>/problem-statement.md`
 
 ## 填写引导
 

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/deliver.md

@@ -2,14 +2,14 @@
 
 ## 输入
 
-- `speculo/.speculo/doc/<change>/problem-statement.md`（Phase 1 产物）
-- `speculo/.speculo/doc/<change>/analysis.md`（Phase 2 产物）
-- `speculo/.speculo/doc/<change>/strategy.md`（Phase 3 产物）
-- `speculo/.speculo/doc/<change>/action-plan.md`（Phase 4 产物）
+- `speculo/.speculo/person/<change>/problem-statement.md`（Phase 1 产物）
+- `speculo/.speculo/person/<change>/analysis.md`（Phase 2 产物）
+- `speculo/.speculo/person/<change>/strategy.md`（Phase 3 产物）
+- `speculo/.speculo/person/<change>/action-plan.md`（Phase 4 产物）
 
 ## 产物
 
-- `speculo/.speculo/doc/<change>/consultation-output.md`（由模板 `../_templates/mao-consultation-output-template.md` 填写）
+- `speculo/.speculo/person/<change>/consultation-output.md`（由模板 `../_templates/mao-consultation-output-template.md` 填写）
 
 ## 填写引导
 

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/diagnose.md

@@ -2,12 +2,12 @@
 
 ## 输入
 
-- `speculo/.speculo/doc/<change>/problem-statement.md`（Phase 1 产物）
+- `speculo/.speculo/person/<change>/problem-statement.md`（Phase 1 产物）
 - Module A 的 8 大分析模型（见下方）
 
 ## 产物
 
-- `speculo/.speculo/doc/<change>/analysis.md`
+- `speculo/.speculo/person/<change>/analysis.md`
 
 ## 认知主线
 

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/mobilize.md

@@ -2,13 +2,13 @@
 
 ## 输入
 
-- `speculo/.speculo/doc/<change>/problem-statement.md`（Phase 1 产物）
-- `speculo/.speculo/doc/<change>/analysis.md`（Phase 2 产物）
-- `speculo/.speculo/doc/<change>/strategy.md`（Phase 3 产物）
+- `speculo/.speculo/person/<change>/problem-statement.md`（Phase 1 产物）
+- `speculo/.speculo/person/<change>/analysis.md`（Phase 2 产物）
+- `speculo/.speculo/person/<change>/strategy.md`（Phase 3 产物）
 
 ## 产物
 
-- `speculo/.speculo/doc/<change>/action-plan.md`
+- `speculo/.speculo/person/<change>/action-plan.md`
 
 ## 核心命题
 

package/template/workflows/{doc → person}/M-mao-zedong-cognitive-os/strategize.md

@@ -2,12 +2,12 @@
 
 ## 输入
 
-- `speculo/.speculo/doc/<change>/problem-statement.md`（Phase 1 产物）
-- `speculo/.speculo/doc/<change>/analysis.md`（Phase 2 产物）
+- `speculo/.speculo/person/<change>/problem-statement.md`（Phase 1 产物）
+- `speculo/.speculo/person/<change>/analysis.md`（Phase 2 产物）
 
 ## 产物
 
-- `speculo/.speculo/doc/<change>/strategy.md`
+- `speculo/.speculo/person/<change>/strategy.md`
 
 ## 元框架（战略流水线）