@namewta/speculo 1.0.18 → 1.0.19

package/template/workflows/person/M-mao-zedong-cognitive-os/M-mao-zedong-cognitive-os.md

@@ -9,67 +9,25 @@ keywords: [毛泽东, 毛选, 矛盾分析, 战略, 组织, 咨询]
 
 # 毛泽东 · 认知操作系统
 
-本入口把"分析问题—制定战略—组织行动"组织为渐进披露的咨询流程。产物写入当前 `person/changes/<change>/`。
+以特定方法论开展“分析问题—制定战略—组织行动”咨询，产物只写当前 person change。激活时读取 `<Path>{roots.workflows}/person/INDEX.md</Path>` 与 `<Path>{roots.workflows}/person/common/rules/activation-and-memory.md</Path>`；Person 没有 README，不加载其他 phase 或整套书籍。
 
-## 读取范围
+## 按阶段推进
 
-1. 先读取 `<Path>{roots.workflows}/person/INDEX.md</Path>` 与当前 Work 的状态入口；Person 使用整文件 INDEX，不加载不存在的 README。
-2. 再读取 `<Path>{roots.workflows}/person/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
+下表有序且硬依赖：上一阶段产物完成、验证后才进入下一阶段。每个阶段只读取自己的入口，角色、声音、模型和引用纪律由该入口及其参考单点维护。
 
-引用检索固定为：先读取当前 phase 的 framework index，再读取 `references/research/15-quote-bank.md` 定位篇目编号，最后只回读匹配的 `books/src/NNN-*.md`；不扫描整套书籍，无匹配证据时停止引用或结论。
+| 阶段 | 进入时读取 | 产物与可判定完成门 |
+|---|---|---|
+| 1 激活与问诊 | `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/activate.md</Path>` | `<Path>{roots.state}/person/changes/{change}/problem-statement.md</Path>`：首次激活声明；开口三问中至少追问两题且用户回应；问题类型和主框架确定；六段填实 |
+| 2 诊断分析 | `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/diagnose.md</Path>` | `<Path>{roots.state}/person/changes/{change}/analysis.md</Path>`：至少两个 Module A 模型；必过 A1，二手信息过 A3，多方利益过 A6；每个结论含条件/局限，主要矛盾有论证 |
+| 3 战略制定 | `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/strategize.md</Path>` | `<Path>{roots.state}/person/changes/{change}/strategy.md</Path>`：沿定性→定向→站位→时间→投放→运用展开主框架；必要辅助框架；至少两阶段及明确关键战役 |
+| 4 组织行动 | `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/mobilize.md</Path>` | `<Path>{roots.state}/person/changes/{change}/action-plan.md</Path>`：行动、责任人、期限、完成条件、失败处置与反馈机制明确 |
+| 5 综合交付 | `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/deliver.md</Path>` | `<Path>{roots.state}/person/changes/{change}/consultation-output.md</Path>`：按交付模板整合四阶段，教员第一人称、五拍论证、收尾四动作、反模式检查与内在张力标注；全部原文引用有篇目出处 |
 
+每项产物回读后必须无残留 `[TODO:]`；缺少用户回应、阶段证据或原文出处时保留当前阶段，不用后续产物掩盖缺口。
 
-## 流程
+## 引用检索
 
-### 1. 激活与问诊
-
-委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/activate.md</Path>`。输出首次激活声明，通过开口三问摸清用户处境，判定问题类型并匹配主框架。
-
-产物：`<Path>{roots.state}/person/changes/{change}/problem-statement.md</Path>`
-
-**完成标准**：首次激活声明已输出，至少已追问 2 个开口问题且用户已回应，问题类型与主框架已匹配，problem-statement.md 六段均已填写无残留 `[TODO:]`。
-
-### 2. 诊断分析
-
-依赖步骤 1 的 problem-statement.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/diagnose.md</Path>`。从 Module A 八模型中选用至少 2 个进行诊断——所有问题必过 A1（矛盾分析）；信息来自二手必过 A3（调查研究）；涉及多方利益必过 A6（结构分析）。
-
-产物：`<Path>{roots.state}/person/changes/{change}/analysis.md</Path>`
-
-**完成标准**：已应用至少 2 个 Module A 模型，每个模型结论带条件与局限，主要矛盾已明确写出且带论证，analysis.md 无残留 `[TODO:]`。
-
-### 3. 战略制定
-
-依赖步骤 2 的 analysis.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/strategize.md</Path>`。沿元框架流水线（定性→定向→站位→时间→投放→运用）展开主框架，必要时补充辅助框架。
-
-产物：`<Path>{roots.state}/person/changes/{change}/strategy.md</Path>`
-
-**完成标准**：主框架已选定并充分展开，阶段划分清晰（至少分两步），有明确的关键战役判断，strategy.md 无残留 `[TODO:]`。
-
-### 4. 组织行动
-
-依赖步骤 3 的 strategy.md。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/mobilize.md</Path>`。将战略转化为具体行动方案——谁来干、干什么、什么时候干完、干到什么程度算好、干砸了怎么办。
-
-产物：`<Path>{roots.state}/person/changes/{change}/action-plan.md</Path>`
-
-**完成标准**：行动、责任与反馈机制已明确，action-plan.md 无残留 `[TODO:]`。
-
-### 5. 综合交付
-
-依赖前四步全部产物。委托给 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/deliver.md</Path>`。按模板 `../_templates/mao-consultation-output-template.md` 整合为连贯的教员第一人称咨询输出——五拍论证节奏、收尾四动作、引用纪律、反模式检查和内在张力标注。
-
-产物：`<Path>{roots.state}/person/changes/{change}/consultation-output.md</Path>`
-
-**完成标准**：已整合四阶段产物为连贯的教员第一人称咨询输出，五拍论证节奏可辨识，收尾四动作齐全，所有毛泽东原文引用均带篇目出处，反模式检查通过，consultation-output.md 无残留 `[TODO:]`。
-
-## 依赖关系
-
-- 步骤 2「诊断分析」依赖步骤 1「激活与问诊」
-- 步骤 3「战略制定」依赖步骤 2「诊断分析」
-- 步骤 4「组织行动」依赖步骤 3「战略制定」
-- 步骤 5「综合交付」依赖步骤 4「组织行动」
-
-所有步骤为硬依赖——前一产物必须完成并验证后才能进入下一步。
+需要引用时，先读当前 phase 的 framework index，再在 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/references/research/15-quote-bank.md</Path>` 定位篇目编号，最后仅回读匹配的原文。目录映射查询 `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/books/README.md</Path>`；无匹配证据则停止该引用或依赖结论，不扫描整套书籍。
 
 ## 状态追踪
 
@@ -82,16 +40,3 @@ keywords: [毛泽东, 毛选, 矛盾分析, 战略, 组织, 咨询]
 - **`methods_applied`**（数组）—— 组织阶段已应用的 Module C 方法列表
 - **`quotes_cited`**（数组）—— 已引用的毛泽东原话及出处
 - **`consultation_status`**（字符串）—— 当前阶段：`activating` → `diagnosing` → `strategizing` → `mobilizing` → `delivering` → `completed`
-
-## 渐进披露
-
-角色、声音、模型和引用规则继续由各 phase 文件及其相对引用拥有；未进入 phase 时不加载对应材料。
-
-| 文件 | 触发条件 |
-|------|----------|
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/activate.md</Path>` | 步骤 1「激活与问诊」进入时 |
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/diagnose.md</Path>` | 步骤 2「诊断分析」进入时 |
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/strategize.md</Path>` | 步骤 3「战略制定」进入时 |
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/mobilize.md</Path>` | 步骤 4「组织行动」进入时 |
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/deliver.md</Path>` | 步骤 5「综合交付」进入时 |
-| `<Path>{roots.workflows}/person/M-mao-zedong-cognitive-os/books/README.md</Path>` | 需要查原文时——引语库 `references/research/15-quote-bank.md` 映射篇目编号到 books 目录 |

package/template/workflows/person/S-steelman-deliberation/S-steelman-deliberation.md

@@ -9,39 +9,13 @@ keywords: [双向钢人, steelman, 决策, 反谄媚, 关键变量, 明确判断
 
 # 双向钢人论证
 
-本 work 的主导词是**钢人化**。它不负责替用户把既有立场说得更顺耳，也不以“正反都说一点”制造表面平衡；它负责在结论形成前，把用户真正要解决的问题、支持当前倾向的最强可信论证、反对当前倾向的最强可信论证和决定结论的变量同时推进到可检验状态，再只关闭一个最高价值的不确定性，最后承担判断责任。
+重述用户真正的问题，分别形成支持与反对当前倾向的最强可信论证，找出分歧和关键变量，只关闭一个最高价值的不确定性，再给出明确判断与可验证行动。不以虚假平衡、迎合立场或通用建议替代判断。
 
-核心动作保持为：
+激活时读取 `<Path>{roots.workflows}/person/INDEX.md</Path>` 与 `<Path>{roots.workflows}/person/common/rules/activation-and-memory.md</Path>`；Person 不使用不存在的 README。
 
-1. 用最完整、最有力的方式，重述用户真正想解决的问题；
-2. 使用钢人论证法，分别给出支持当前想法与反对它的最强论证；
-3. 找出双方真正的分歧，以及最可能改变结论的关键变量；
-4. 只问用户一个最关键的问题；等用户回答后，再给出明确判断、理由和下一步行动。
+## 输入与权威
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/person/INDEX.md</Path>` 与当前 Work 的状态入口；Person 使用整文件 INDEX，不加载不存在的 README。
-2. 再读取 `<Path>{roots.workflows}/person/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
-
-## 输入、权威与边界
-
-### 必需输入
-
-- 一个需要选择、判断、取舍、排序或制定策略的具体问题。
-
-缺失可识别问题，或输入只是无需权衡的事实查询时，返回 `blocked-input`，说明缺少什么，不制造虚假争论。
-
-### 可选输入
-
-- 用户当前倾向、候选方案与反对意见；
-- 时间窗口、预算、资源、风险和不可逆约束；
-- 已知事实、项目材料、证据或外部来源；
-- 用户已经明确的目标、价值排序和成功标准；
-- 调用方显式提供的 `{change}`。
-
-不存在的可选输入静默跳过；已经明确的信息不得重复询问。
+必需一个需要选择、判断、排序或策略的具体问题；缺失或只是无需权衡的事实查询时返回 `blocked-input`，不制造争论。按已知情况采用用户倾向、候选/反对意见、时间/预算/资源、不可逆约束、事实来源、价值目标和调用方 change；缺失的可选内容静默跳过，已明确信息不重复问。
 
 ### 权威顺序
 
@@ -64,7 +38,9 @@ keywords: [双向钢人, steelman, 决策, 反谄媚, 关键变量, 明确判断
 
 它不修改其他 person work 的产物或 active 条目，不把运行时状态写回 `{roots.workflows}/person/_state/`，也不提交、推送、发布、部署或执行不可逆操作。
 
-## 流程
+## 按持久化阶段执行
+
+新建、恢复或状态写入前读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/references/state-and-publication.md</Path>`，遵守 v1 字段、候选校验、原子替换顺序和未知字段保留；不得覆盖其他 Work。
 
 ### 1. 解析 roots，选择或恢复 change
 
@@ -94,23 +70,9 @@ keywords: [双向钢人, steelman, 决策, 反谄媚, 关键变量, 明确判断
 
 ### 3. 回答前的双向钢人化
 
-仅在没有有效 dossier 时读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/deliberate.md</Path>`，按其顺序完成真实问题重述、证据分层、双向钢人、分歧与关键变量识别，并形成唯一关键问题。
-
-若问题依赖会变化的公开事实、专业事实、冲突材料、代码/测试/配置，或属于医疗、法律、财务、安全等高风险领域，再读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/evidence-gate.md</Path>`；可发现的事实先探索，不拿来问用户。
-
-使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/steelman-dossier-template.md</Path>` 在 change 目录下的唯一临时子目录中写入候选 dossier 与候选 `.status.json`，重读后运行：
+仅在无有效 dossier 时读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/deliberate.md</Path>`，完整重述问题、分层证据、正反钢人、分歧与关键变量，形成唯一关键问题。变化事实、专业事实、冲突材料、代码或高风险领域还须读 `<Path>{roots.workflows}/person/S-steelman-deliberation/evidence-gate.md</Path>`；可发现的事实先探索，不拿来问用户。
 
-```bash
-node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
-  --phase awaiting-answer \
-  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
-  --dossier-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/steelman-dossier.md</Path> \
-  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
-```
-
-临时目录名在并发时追加唯一后缀。校验通过后，先原子替换正式 dossier，再原子替换 change `.status.json`；workflow active 只在步骤 4 确认需要等待用户时更新。校验失败时删除临时目录并保持正式工件和旧状态不变。
-
-**完成标准**：dossier 是回答前的冻结快照；正反最强可信论证、真正分歧、关键变量和唯一问题均存在；没有最终判断或行动建议；校验退出码为 0。
+按状态与发布合同的“回答前”分支创建、校验并发布 dossier；其中没有最终判断或行动建议，退出码必须为 0。该 dossier 随后冻结。
 
 ### 4. 只关闭一个最高价值的不确定性
 
@@ -132,73 +94,9 @@ node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steel
 
 ### 5. 明确裁决并形成行动
 
-关键问题得到有效回答后，将回答原文写入 change `.status.json`，设置 `phase: judging`，再读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/judge.md</Path>`。必须基于冻结 dossier 和用户回答裁决，不重做一份迎合回答的新钢人分析。
-
-使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/decision-template.md</Path>` 在唯一临时目录中写入候选 decision 与候选完成态 `.status.json`，随后运行：
+得到有效回答后原样保存，设置 `phase: judging`，再读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/judge.md</Path>`。以冻结 dossier 和真实回答裁决，不重做迎合回答的新分析。
 
-```bash
-node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
-  --phase completed \
-  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
-  --decision-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/decision.md</Path> \
-  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
-```
-
-校验通过后才原子替换正式 decision 和 change 状态，并只从 workflow `status.json.active` 删除匹配当前 `change` 且属于本 work 的条目。校验失败时删除临时目录、返回 `validation-failed`，保留可恢复的 `judging` 状态。
-
-**完成标准**：decision 给出明确判断、决定性理由、对最强反方的回应、具体行动、反转条件及置信度；状态与工件一致；校验退出码为 0。
-
-## 状态合同
-
-### Workflow 状态
-
-`<Path>{roots.state}/person/status.json</Path>` 保持 `schema_version: 1`，本 work 只管理 `active` 数组中的如下条目：
-
-```json
-{
-  "change": "2026-08-18-steelman-company-anniversary",
-  "work_id": "person/steelman-deliberation",
-  "phase": "awaiting-answer",
-  "updated_at": "2026-08-18T00:00:00.000Z"
-}
-```
-
-读取—合并—写入时保留未知顶层字段、未知 entry 字段和其他 work 的全部条目。写临时文件、重读 JSON、再原子替换。
-
-### Change 状态
-
-`<Path>{roots.state}/person/changes/{change}/.status.json</Path>` 至少包含：
-
-```json
-{
-  "schema_version": 1,
-  "artifact": "person-work-status",
-  "workflow": "person",
-  "change": "2026-08-18-steelman-company-anniversary",
-  "work_id": "person/steelman-deliberation",
-  "status": "active",
-  "phase": "awaiting-answer",
-  "key_question": "[唯一关键问题]",
-  "key_question_asked": true,
-  "question_disposition": "asked",
-  "answer_received": false,
-  "user_answer": null,
-  "created_at": "2026-08-18T00:00:00.000Z",
-  "updated_at": "2026-08-18T00:00:00.000Z",
-  "completed_at": null,
-  "blockers": []
-}
-```
-
-允许转换：
-
-```text
-intake → deliberating → awaiting-answer → judging → completed
-任一活动阶段 → blocked
-awaiting-answer → reframe-required
-```
-
-`question_disposition` 只能是 `asked | already-answered`；前者要求 `key_question_asked: true`，后者要求 `key_question_asked: false`。工件先验证，change 状态后更新，workflow active 最后更新。状态只是工件的索引，不替代工件本身。
+按状态与发布合同的“回答后”分支校验候选 decision 后才发布并关闭本 Work 的 active 条目；失败保留可恢复的 judging，不报完成。decision 必须包含明确判断、决定性理由、最强反方回应、具体行动、反转条件与置信度，且能追溯到关键变量和回答。
 
 ## 返回合同
 
@@ -213,13 +111,3 @@ awaiting-answer → reframe-required
 - 下一路由：等待回答时返回 `<Path>{roots.workflows}/person/S-steelman-deliberation/S-steelman-deliberation.md</Path>` 并携带同一 change；问题已重构时创建新 change；否则明确完成。
 
 只有 `completed` 才能声明已经形成最终判断。`awaiting-user-answer` 的下一路由始终是带着同一 change 回到本入口。
-
-## 全局完成标准
-
-- 用户真正要解决的问题与表层问法已区分；
-- 当前倾向和最强反方都经过可信、可识别的钢人化；
-- 没有编造证据、虚假平衡或因用户立场降低证据标准；
-- 只关闭了一个最高价值的不确定性，且没有重复追问已知信息；
-- 回答前 dossier 保持冻结，回答后 decision 可追溯到关键变量和用户回答；
-- 最终答案不是任何人都能套用的通用建议，而是明确判断与可验证行动；
-- owned 工件、change 状态与 workflow active 一致，验证证据已返回。

package/template/workflows/person/S-steelman-deliberation/references/state-and-publication.md

@@ -0,0 +1,86 @@
+# Steelman 状态与候选发布合同
+
+新建、恢复或写入状态前读取状态合同；发布 dossier 时只读取回答前分支，发布 decision 时只读取回答后分支。所有路径、schema 和字段沿用原版，禁止另建状态源。
+
+## 状态合同
+
+### Workflow 状态
+
+`<Path>{roots.state}/person/status.json</Path>` 保持 `schema_version: 1`，本 work 只管理 `active` 数组中的如下条目：
+
+```json
+{
+  "change": "2026-08-18-steelman-company-anniversary",
+  "work_id": "person/steelman-deliberation",
+  "phase": "awaiting-answer",
+  "updated_at": "2026-08-18T00:00:00.000Z"
+}
+```
+
+读取—合并—写入时保留未知顶层字段、未知 entry 字段和其他 work 的全部条目。写临时文件、重读 JSON、再原子替换。
+
+### Change 状态
+
+`<Path>{roots.state}/person/changes/{change}/.status.json</Path>` 至少包含：
+
+```json
+{
+  "schema_version": 1,
+  "artifact": "person-work-status",
+  "workflow": "person",
+  "change": "2026-08-18-steelman-company-anniversary",
+  "work_id": "person/steelman-deliberation",
+  "status": "active",
+  "phase": "awaiting-answer",
+  "key_question": "[唯一关键问题]",
+  "key_question_asked": true,
+  "question_disposition": "asked",
+  "answer_received": false,
+  "user_answer": null,
+  "created_at": "2026-08-18T00:00:00.000Z",
+  "updated_at": "2026-08-18T00:00:00.000Z",
+  "completed_at": null,
+  "blockers": []
+}
+```
+
+允许转换：
+
+```text
+intake → deliberating → awaiting-answer → judging → completed
+任一活动阶段 → blocked
+awaiting-answer → reframe-required
+```
+
+`question_disposition` 只能是 `asked | already-answered`；前者要求 `key_question_asked: true`，后者要求 `key_question_asked: false`。工件先验证，change 状态后更新，workflow active 最后更新。状态只是工件的索引，不替代工件本身。
+
+
+## 回答前：发布 dossier
+
+使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/steelman-dossier-template.md</Path>` 在 change 目录下的唯一临时子目录中写入候选 dossier 与候选 `.status.json`，重读后运行：
+
+```bash
+node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
+  --phase awaiting-answer \
+  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
+  --dossier-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/steelman-dossier.md</Path> \
+  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
+```
+
+临时目录名在并发时追加唯一后缀。校验通过后，先原子替换正式 dossier，再原子替换 change `.status.json`；workflow active 只在入口的等待回答阶段 确认需要等待用户时更新。校验失败时删除临时目录并保持正式工件和旧状态不变。
+
+
+## 回答后：发布 decision
+
+使用 `<Path>{roots.workflows}/person/S-steelman-deliberation/_templates/decision-template.md</Path>` 在唯一临时目录中写入候选 decision 与候选完成态 `.status.json`，随后运行：
+
+```bash
+node <Path>{roots.workflows}/person/S-steelman-deliberation/tools/validate-steelman-change.mjs</Path> \
+  --phase completed \
+  --change-dir <Path>{roots.state}/person/changes/{change}</Path> \
+  --decision-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/decision.md</Path> \
+  --status-file <Path>{roots.state}/person/changes/{change}/.steelman-stage/.status.json</Path>
+```
+
+校验通过后才原子替换正式 decision 和 change 状态，并只从 workflow `status.json.active` 删除匹配当前 `change` 且属于本 work 的条目。校验失败时删除临时目录、返回 `validation-failed`，保留可恢复的 `judging` 状态。
+

package/template/workflows/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md

@@ -13,12 +13,7 @@ keywords: [归档, consolidation, ADR, context, research, knowledge, 代码库
 
 A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和代码访谈；机械扫描、dry-run、知识毕业、合并、清理、移动与重读由 `<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>` 单一维护。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 模式
 
@@ -38,11 +33,7 @@ A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和
 
 ## Consolidate-from-code 模式
 
-1. 创建 `<Path>{roots.state}/specdev/changes/{change}/</Path>`、change 状态、LOG、CONTEXT 和 ADR，并登记 `current_work`。
-2. 加载 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`，每轮先探索代码/配置/测试并陈述证据，再一次只问一个真正影响长期理解的问题。
-3. 按 LOG → CONTEXT → ADR 顺序写入：CONTEXT 只保存项目规范术语；ADR 只有同时满足难逆转、令人意外和真实权衡时才创建。
-4. 用户结论必须由当前代码或实际行为验证；未验证内容留在 LOG，不提升。
-5. 按 change completion 规则由本 Work 关闭该非实现型 change，再进入 Archive 模式的 dry-run/确认流程。
+读取 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`，由本 Work 创建知识 change、按代码证据访谈并验证后关闭，再回到 Archive 模式。LOG/CONTEXT/ADR 先在该 change 内形成；未验证结论留在 LOG，不直接提升永久知识。
 
 ## 副作用
 
@@ -57,9 +48,3 @@ Dry-run 不修改文件。归档移动、知识 merge/rewrite/delete、Git 动
 - 源不存在、目标完整、active/archived 无重叠、归档状态正确；
 - 永久知识只包含当前、跨 change 有用且有实现证据的结论；
 - 无未批准移动、删除、改写或 Git 副作用。
-
-## 子文件引用
-
-- 全局归档 Skill：`<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>`
-- Change 完成：`<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`
-- 代码访谈：`<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`

package/template/workflows/specdev/A-archive-and-consolidate/consolidation-interview.md

@@ -51,4 +51,13 @@ change 内三份文档复用 grill 的既有格式，避免重复发明：
 - 缺少必要外部信息或权限，change 标 blocked；或
 - 继续提问只会产生低影响或纯实现细节，交给对应实现阶段决定。
 
-停止后交回入口 §3，进入知识提升评估。未获代码或实际行为验证的结论一律不提升，只留在 change 内。
+停止后返回 A 的 Archive 模式，进入知识提升评估。未获代码或实际行为验证的结论一律不提升，只留在 change 内。
+
+
+## Consolidate-from-code 模式
+
+1. 创建 `<Path>{roots.state}/specdev/changes/{change}/</Path>`、change 状态、LOG、CONTEXT 和 ADR，并登记 `current_work`。
+2. 按上述访谈过程，每轮先探索代码/配置/测试并陈述证据，再一次只问一个真正影响长期理解的问题。
+3. 按 LOG → CONTEXT → ADR 顺序写入：CONTEXT 只保存项目规范术语；ADR 只有同时满足难逆转、令人意外和真实权衡时才创建。
+4. 用户结论必须由当前代码或实际行为验证；未验证内容留在 LOG，不提升。
+5. 按 change completion 规则由本 Work 关闭该非实现型 change，再进入 Archive 模式的 dry-run/确认流程。

package/template/workflows/specdev/C-code-review/C-code-review.md

@@ -13,12 +13,7 @@ keywords: [code-review, review, diff, fixed-point, PR, 标准, 规范]
 
 C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/specdev/changes/{change}/reviews/</Path>`；I 的最终审查由 I 写入 Evidence，不写本目录。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 输入
 
@@ -31,8 +26,8 @@ C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/spe
 1. **解析固定点**：使用 `git rev-parse` 把固定点和 HEAD 固定为 SHA；PR 先通过 `<Path>{roots.skills}/github-npm-ops/SKILL.md</Path>` 的 `pr-read` 获得 base/head SHA，并确保对应对象可在本地解析。
 2. **冻结输入**：记录 `git diff <fixed>...<head>` 和 `git log <fixed>..<head> --oneline`。引用无效或 diff 为空时失败，不创建报告。
 3. **发现来源**：调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`；规范来源缺失时经确认跳过规范轴，标准轴继续。
-4. **隔离审查**：平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
-5. **持久化**：选择下一个未占用 `CR-###`，使用模板写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
+4. **隔离审查**：仅按公共 Skill 的完整输入复用门接受既有结果；需要执行的轴在平台支持时并行 reviewer，否则用两个独立完整输入包顺序执行。两轴不得读取对方 finding。
+5. **持久化**：选择下一个未占用 `CR-###`，使用 `<Path>{roots.workflows}/specdev/C-code-review/code-review-template.md</Path>` 写入 `<Path>{roots.state}/specdev/changes/{change}/reviews/CR-###.md</Path>`，原子重读。
 6. **验证与路由**：使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage review` 校验当前 change。无阻塞 finding 时返回完成或 I；局部修复生成/修订 Ticket；规范冲突返回 S/G；无法确定的 blocker 保持 C 可恢复状态。
 
 ## 完成标准
@@ -43,9 +38,3 @@ C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/spe
 - 每个 finding 有路径、风险、依据和满足条件；
 - 报告、状态、验证结果和下一 Work 路径一致；
 - C 未修改项目代码或远程状态。
-
-## 子文件引用
-
-- 公共审查 Skill：`<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`
-- 报告模板：`<Path>{roots.workflows}/specdev/C-code-review/code-review-template.md</Path>`
-- 报告 Schema：`<Path>{roots.workflows}/specdev/common/schemas/code-review.schema.json</Path>`

package/template/workflows/specdev/C-code-review/code-review-template.md

@@ -40,3 +40,7 @@ created_at: <ISO-8601>
 - **Most severe standards finding:** none / ...
 - **Most severe specification finding:** none / ...
 - **Next Work:** completed / `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>` / `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>`
+
+## 审查证据复用（仅实际发生时填写）
+
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。

package/template/workflows/specdev/D-diagnose-bugs/D-diagnose-bugs.md

@@ -13,12 +13,7 @@ keywords: [bug, 诊断, 红灯, tight-loop, 根因, 复现, 假设]
 
 D 的主导词是**红灯**：没有一条已执行且能在此 bug 上变红的紧凑命令，就没有可进入的假设阶段。D 默认只读项目代码，可以创建 change 诊断工件和经授权的临时可撤销探针；生产修复由 Implement 拥有。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
 
 ## 输入与所有权
 
@@ -74,20 +69,3 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 ```
 
 根因确认后将本 Work 加入 `works_run` 并清空 `current_work`，返回 diagnosis 和下一 Work：局部修复进入 Tickets/I，公共行为或高风险进入 S/Tickets，缺 seam 进入 R，仍无根因则保持 blocked 或进入 W。
-
-## 完成标准
-
-- 红灯回路硬门有已执行证据；
-- 最小复现的剩余元素都有负载作用；
-- 假设有排名、预测和反证；
-- 根因解释触发、机制、漏检和影响；
-- 修复契约决策完备但未夹带生产修复；
-- debug 插桩已清理或有明确 owner；
-- diagnosis、状态、验证证据和下一 Work 路径一致。
-
-## 子文件引用
-
-- 反馈回路：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/feedback-loop.md</Path>`
-- 假设与插桩：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/hypothesis-and-instrumentation.md</Path>`
-- 诊断模板：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/diagnosis-template.md</Path>`
-- HITL 模板：`<Path>{roots.workflows}/specdev/D-diagnose-bugs/scripts/hitl-loop.template.sh</Path>`

package/template/workflows/specdev/G-grill-with-docs/G-grill-with-docs.md

@@ -15,9 +15,9 @@ keywords: [grill, 设计树, 领域, 决策, 共识]
 
 读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`；定位当前 change 的 `<Path>{roots.state}/specdev/changes/{change}/design-tree.json</Path>`、`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 和相关 initiative 决策。先找到相关条目再回读必要原文，不默认整读永久 ADR 或索引。
 
-## 过程与边界
+## 当前 change 的访谈与共识
 
-进入访谈必须读取 `<Path>{roots.workflows}/specdev/G-grill-with-docs/references/interview-procedure.md</Path>`，再按触发分支读取 grilling、领域建模、日志格式或 stakeholder questionnaire。保留完整 frontier、推荐答案和逐轮共识检查，但不替用户回答高影响取舍。
+进入访谈必须读取 `<Path>{roots.workflows}/specdev/G-grill-with-docs/references/interview-procedure.md</Path>`，由该过程在出现设计取舍、术语变化、日志写入或外部 stakeholder 缺口时分别读取 grilling、领域建模、日志格式或 questionnaire；不默认加载所有参考。保留完整 frontier、推荐答案和逐轮共识检查，但不替用户回答高影响取舍。
 
 - 先查仓库可发现事实，只询问会改变行为、架构、风险、范围、迁移或验收的决定。
 - W 的每个 materialized change 在自己的目录拥有设计树和文档；共享答案以来源指针引用，不能共用一棵可写设计树。

package/template/workflows/specdev/I-implement/I-implement.md

@@ -15,9 +15,9 @@ keywords: [implement, Ticket, TDD, Evidence, integration]
 
 先读 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`；从当前 tickets-map 或父 map 定位本票、上游约束、项目 Skill 与执行策略。仅展开当前 Ticket 的正文、直接依赖、适用 Skill 和必要恢复证据，不整读知识库。
 
-## 执行入口
+## 当前票的执行入口
 
-执行必须读取 `<Path>{roots.workflows}/specdev/I-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`；这两份合同持有原有 Direct Spec/Ticket、TDD、双轴审查、Git、workspace 与 Evidence 全流程，不得跳过。
+执行必须读取 `<Path>{roots.workflows}/specdev/I-implement/references/implementation-procedure.md</Path>` 和 `<Path>{roots.workflows}/specdev/I-implement/execution-preflight.md</Path>`；执行过程按当前阶段路由设计、TDD、双轴审查和 Evidence；预检单独拥有 Git、workspace、Ready 与授权检查。两者必读，分支参考只在对应 workspace/风险/阶段进入时加载。
 
 1. 核验 Ready、授权、owner、真实源与 map 基线；新增计划型票按 `<Path>{roots.workflows}/specdev/common/rules/skill-invocation.md</Path>` 实际调用绑定能力并记录证据。旧票缺调用契约时先由 Lead 补齐，不猜测。
 2. 保持 codebase-design、design-it-twice 和 TDD 的适用门禁；进入对应实现步骤再读其 reference。派单时调用 subagent-delivery；Lead 是唯一 SpecDev 状态写入者。

package/template/workflows/specdev/I-implement/evidence-template.md

@@ -131,3 +131,11 @@ subagent 不写本 Evidence；以上内容由 Lead 从实际 workspace、Git 和
 ## 用户交付与源回读
 
 记录用户要求的实际数量、交付位置、源/链接/必要元数据回读、行为差异、备份和未完成项。Goal 有显式数量时在 `<Path>{roots.state}/specdev/changes/{change}/evidence/goal-delivery.md</Path>` 写 Delivery Records，与 map 合同逐项核对。字符统计包含移动后的参考文件，不等同于 Token 或套餐用量。
+
+## 审查证据复用（仅实际发生时填写）
+
+记录原 CR/Evidence locator、fixed/head/diff、规范/标准/指令与 Skill/reference 摘要、工具/环境相关证据、两轴隔离核对、复用或重跑的轴与原因。未发生时写“不适用”；本节不是通过声明，也不改变原始审查结果。
+
+## OPS 交付（仅用户请求时）
+
+交付前读取 `<Path>{roots.workflows}/specdev/common/rules/deployment-handoff.md</Path>`，记录当前 change/Ticket、代码 revision、实际构件 digest、AC/Evidence、目标与部署约束；回传时只追加经核对的 Run/Release/receipt 指针。未请求写“不适用”，不为填表创建 OPS 任务。