@namewta/speculo 1.0.24 → 2.0.1

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

@@ -1,83 +0,0 @@
-# Diagnose Phase — 诊断分析
-
-## 输入
-
-- `speculo/.speculo/person/changes/<change>/problem-statement.md`（Phase 1 产物）
-- Module A 模型清单与展开规则：`references/research/11-analysis-frameworks.md`
-- 引语与篇目映射：`references/research/15-quote-bank.md`（查原文前先读）
-
-## 产物
-
-- `speculo/.speculo/person/changes/<change>/analysis.md`
-
-## 认知主线
-
-**事实 → 矛盾 → 主次 → 定性 → 两面 → 条件 → 本质 → 具体 → 检验。**
-
-Module A 八模型清单、子工具与局限见 `references/research/11-analysis-frameworks.md`；展开某模型时按编号查 `references/research/15-quote-bank.md` 再开 `books/src/NNN-*.md`。
-
-## 填写引导
-
-### 1. 选择适用模型
-
-从 Phase 1 确定的 `problem_type` 出发，从 8 模型中选用至少 2 个：
-
-- 所有问题必过 A1（矛盾分析），这是主算法
-- 信息来自二手而非亲历 → 必过 A3（调查研究）
-- 涉及多方利益 → 必过 A6（结构分析）
-- 判断涉及趋势预测 → 必过 A5（一分为二看转化）+ A7（看本质）
-- 涉及"别人都这么做/标准做法" → 必过 A8（具体分析）
-
-### 2. 逐一应用模型
-
-每个选用的模型产出：
-
-- **诊断结论**（1-2 句，带"不是……而是……"切割）
-- **条件分析**（转化需要什么条件？现在具备哪些？）
-- **局限标注**（这个判断的边界在哪？）
-
-### 3. 综合定性
-
-汇总各模型结论，回答三个问题：
-
-1. **主要矛盾**是什么？为什么它是主要的？
-2. **矛盾的主要方面**在哪一方？这一定性意味着什么？
-3. **转化的关键条件**是什么？现在缺什么？
-
-### 4. 写入 analysis.md
-
-```markdown
-# 诊断分析
-
-## 应用的模型
-[TODO: 列出选用的模型及原因]
-
-## A1 · 矛盾分析
-### 主要矛盾
-[TODO]
-### 矛盾的主要方面
-[TODO]
-### 转化的条件
-[TODO]
-### 局限
-[TODO]
-
-## [其他应用的模型]
-[TODO: 每个模型一小节，含诊断结论、条件分析、局限]
-
-## 综合定性
-[TODO: 汇总三个核心问题的回答]
-```
-
-## 边界
-
-- 不在此阶段给战略建议——先看清，再定打法。
-- 每个判断必须带条件，"只有……才……"。
-- 对无法确定的判断明确标注"待调查"。
-
-## 完成准则
-
-- 已应用至少 2 个 Module A 模型
-- 每个模型结论带条件与局限
-- 主要矛盾已明确写出且带论证
-- `analysis.md` 无残留 `[TODO:]`

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

@@ -1,85 +0,0 @@
-# Mobilize Phase — 行动组织
-
-## 输入
-
-- `speculo/.speculo/person/changes/<change>/problem-statement.md`（Phase 1 产物）
-- `speculo/.speculo/person/changes/<change>/analysis.md`（Phase 2 产物）
-- `speculo/.speculo/person/changes/<change>/strategy.md`（Phase 3 产物）
-- Module C 方法清单与操作手册：`references/research/13-organization-action.md`
-- 引语与篇目映射：`references/research/15-quote-bank.md`
-
-## 产物
-
-- `speculo/.speculo/person/changes/<change>/action-plan.md`
-
-## 核心命题
-
-> "正确的路线确定之后，干部就是决定的因素。"
-
-Module C 八方法清单与党委会 12 条见 `references/research/13-organization-action.md`。
-
-## 填写引导
-
-### 1. 选定组织方法
-
-从 Phase 3 的战略方案出发，从 C1-C8 中选用 2-3 个适用的方法：
-
-- 涉及动员/协同多人 → 必过 C1（群众路线）
-- 涉及团队管理/领导 → 必过 C5（党委12条）
-- 任务大而模糊 → 必过 C7（桥与船）
-- 涉及用人与分工 → 必过 C6（用人与带队伍）
-- 涉及复盘/持续改进 → 必过 C2（批评与自我批评）
-
-### 2. 为每个任务配方法
-
-每个战略阶段的关键战役，逐一回答：
-
-- **谁来执行**？（C6：谁是最合适的骨干？）
-- **怎么执行**？（C7：桥和船是什么？）
-- **如何检验**？（C1：怎么回到群众/实践中检验？）
-- **什么纪律**？（C8：不可逾越的底线是什么？）
-
-### 3. 应用党委会 12 条
-
-从 C5 的 12 条中选出 3-5 条当前最需要的，写入行动纪律。
-
-### 4. 写入 action-plan.md
-
-```markdown
-# 行动方案
-
-## 组织方法
-[TODO: 列出选用的 C1-C8 方法及原因]
-
-## 阶段一：[阶段名]
-### 任务
-[TODO]
-### 执行者与骨干
-[TODO]
-### 方法（桥与船）
-[TODO]
-### 检验方式
-[TODO]
-
-## 阶段二：[阶段名]
-[TODO: 同上结构]
-
-## 行动纪律（党委会精选）
-[TODO: 从12条中选3-5条，写具体怎么执行]
-
-## 底线与停止条件
-[TODO: 什么情况下必须停下来重新判断？]
-```
-
-## 边界
-
-- 不在此阶段重新讨论战略——战略已定，现在是执行。
-- 每个任务必须配有具体方法，不给桥和船就是空话。
-- 不替用户决定人事安排（可建议选人标准，不指定具体人）。
-
-## 完成准则
-
-- 已选用至少 2 个 Module C 方法
-- 每个战略阶段的任务已配方法（桥与船）
-- 已从党委会 12 条中选出至少 3 条行动纪律
-- `action-plan.md` 无残留 `[TODO:]`

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

@@ -1,76 +0,0 @@
-# Strategize Phase — 战略制定
-
-## 输入
-
-- `speculo/.speculo/person/changes/<change>/problem-statement.md`（Phase 1 产物）
-- `speculo/.speculo/person/changes/<change>/analysis.md`（Phase 2 产物）
-- Module B 框架清单与决策树：`references/research/12-strategy-frameworks.md`
-- 引语与篇目映射：`references/research/15-quote-bank.md`
-
-## 产物
-
-- `speculo/.speculo/person/changes/<change>/strategy.md`
-
-## 元框架（战略流水线）
-
-**定性（敌我力量本质）→ 定向（主要矛盾）→ 站位（敌我友）→ 时间（阶段/节奏）→ 投放（集中一点）→ 运用（保持主动）。**
-
-Module B 八框架清单、情境选择表与适用条件见 `references/research/12-strategy-frameworks.md`。
-
-## 填写引导
-
-### 1. 确认主框架
-
-对照 Phase 1 确定的 `primary_framework` 和上方的战略快速选择表，确认匹配正确。
-若诊断结果改变了问题性质，修正主框架。
-
-### 2. 展开主框架
-
-对选定的主框架详细展开：
-
-- **阶段划分**：当前处于什么阶段？分几步走？
-- **关键战役**：哪一仗必须先打赢？为什么？
-- **资源配置**：力量往哪投？在哪集中？
-- **风险预案**：最坏情况是什么？底线在哪？
-
-### 3. 补充框架
-
-若需要，从 B1-B8 中选取辅助框架（最多 2 个），说明组合方式。
-
-### 4. 写入 strategy.md
-
-```markdown
-# 战略方案
-
-## 战略判断
-[TODO: 一句话方向判断——"我们的方针是……"]
-
-## 主框架：[框架名]
-### 阶段划分
-[TODO: 分几个阶段？当前在哪一阶段？]
-### 关键战役
-[TODO: 必须先打赢哪一仗？]
-### 资源配置
-[TODO: 力量集中在哪里？]
-### 风险与底线
-[TODO]
-
-## 辅助框架
-[TODO: 如有，说明组合方式]
-
-## 战略箴言
-[TODO: 1-2 句毛泽东原话点题，带篇目编号]
-```
-
-## 边界
-
-- 不在此阶段讨论执行细节——那是 Phase 4 的事。
-- 战略判断必须给确定性，不能用"可能/也许"回避判断。
-- 每一步战略都标注前置条件。
-
-## 完成准则
-
-- 主框架已选定并充分展开
-- 阶段划分清晰（至少分两步）
-- 有明确的关键战役判断
-- `strategy.md` 无残留 `[TODO:]`

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

@@ -1,113 +0,0 @@
----
-id: person/steelman-deliberation
-type: workflow-entry
-workflow: person
-name: 双向钢人论证
-description: 将尚未厘清的复杂问题经真实问题重述、正反双向钢人化与关键变量识别，在一次关键追问后推进为明确判断和可执行行动
-keywords: [双向钢人, steelman, 决策, 反谄媚, 关键变量, 明确判断]
----
-
-# 双向钢人论证
-
-重述用户真正的问题，分别形成支持与反对当前倾向的最强可信论证，找出分歧和关键变量，只关闭一个最高价值的不确定性，再给出明确判断与可验证行动。不以虚假平衡、迎合立场或通用建议替代判断。
-
-激活时读取 `<Path>{roots.workflows}/person/INDEX.md</Path>` 与 `<Path>{roots.workflows}/person/common/rules/activation-and-memory.md</Path>`；Person 不使用不存在的 README。
-
-## 输入与权威
-
-必需一个需要选择、判断、排序或策略的具体问题；缺失或只是无需权衡的事实查询时返回 `blocked-input`，不制造争论。按已知情况采用用户倾向、候选/反对意见、时间/预算/资源、不可逆约束、事实来源、价值目标和调用方 change；缺失的可选内容静默跳过，已明确信息不重复问。
-
-### 权威顺序
-
-1. 用户明确陈述的目标、价值偏好和不可外部发现的约束；
-2. 已验证的代码、测试、配置、schema、材料和当前外部事实；
-3. `<Path>{roots.state}/person/changes/{change}/steelman-dossier.md</Path>` 中冻结的回答前分析；
-4. 合理推断；
-5. 未验证假设。
-
-低优先级内容不得覆盖高优先级内容。用户的确信程度不是事实证据；模型表达得有说服力也不是事实证据。
-
-### 职责边界
-
-本 work 拥有：
-
-- `<Path>{roots.state}/person/changes/{change}/steelman-dossier.md</Path>`；
-- `<Path>{roots.state}/person/changes/{change}/decision.md</Path>`；
-- `<Path>{roots.state}/person/changes/{change}/.status.json</Path>` 中 `work_id: person/steelman-deliberation` 的生命周期；
-- `<Path>{roots.state}/person/status.json</Path>` 的 `active` 数组中属于本 work 的条目。
-
-它不修改其他 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
-
-先读取 `<Path>{roots.state}/workspace.json</Path>` 解析公共 roots，再读取 `<Path>{roots.state}/person/status.json</Path>`。选择 change 的顺序固定为：
-
-1. 调用方提供 `{change}`：验证名称不含路径穿越，使用该 change；
-2. 未提供时，筛选 `active` 中 `work_id === "person/steelman-deliberation"` 的条目；
-3. 只有一个候选：恢复它；
-4. 多个候选：返回 `blocked-change-selection`，列出 change 名称，不自行猜测；
-5. 没有候选：创建 `YYYY-MM-DD-steelman-<topic-slug>`；同名已存在时追加最小未占用的 `-01`、`-02`。
-
-新建 change 时创建 `<Path>{roots.state}/person/changes/{change}/</Path>` 和 change `.status.json`。恢复时先读 `.status.json`、已有 dossier 和 decision，禁止重新询问或重写已经确认的内容。
-
-**完成标准**：恰有一个合法 change 被选定；新建与恢复可区分；没有覆盖其他 change 或其他 work 的状态。
-
-### 2. 判断当前阶段
-
-根据 change `.status.json` 和权威工件恢复：
-
-- 无 dossier：进入 `deliberating`；
-- dossier 存在、`phase === "awaiting-answer"`：恢复 dossier，仅处理同一个关键问题；
-- `phase === "judging"`：从冻结 dossier 和已记录用户回答继续裁决；
-- decision 存在且验证通过：返回 `completed`，不重复生成；
-- 状态与工件矛盾：返回 `validation-failed`，列出冲突路径，不推进状态。
-
-**完成标准**：当前阶段由持久化证据决定，而不是根据对话印象猜测。
-
-### 3. 回答前的双向钢人化
-
-仅在无有效 dossier 时读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/deliberate.md</Path>`，完整重述问题、分层证据、正反钢人、分歧与关键变量，形成唯一关键问题。变化事实、专业事实、冲突材料、代码或高风险领域还须读 `<Path>{roots.workflows}/person/S-steelman-deliberation/evidence-gate.md</Path>`；可发现的事实先探索，不拿来问用户。
-
-按状态与发布合同的“回答前”分支创建、校验并发布 dossier；其中没有最终判断或行动建议，退出码必须为 0。该 dossier 随后冻结。
-
-### 4. 只关闭一个最高价值的不确定性
-
-若 dossier 中的关键问题尚未被回答：
-
-1. 将 change phase 更新为 `awaiting-answer`；
-2. 在 workflow `status.json.active` 中 upsert 本 work 的条目，保留未知字段和其他 work 条目；
-3. 展示 dossier 的必要内容；
-4. 原样提出 dossier 中的唯一关键问题；
-5. 返回 `awaiting-user-answer`。
-
-此阶段禁止给出方案排序、倾向性结论、最终建议或下一步行动。
-
-若用户原始输入已经清楚回答了该问题，将问题和对应回答原文记录到 `.status.json`，设置 `key_question_asked: false` 与 `question_disposition: already-answered`，不重复追问，也不新增 workflow active 等待项，直接进入步骤 5。
-
-恢复后若用户没有实质回答，原样重复同一个问题；不得提出第二个问题。若用户回答改变了原始问题、候选集合、决策目标或成功标准，返回 `reframe-required`，保留旧 dossier，并建议创建新 change；不得把新问题偷偷塞回冻结分析。
-
-**完成标准**：最多向用户提出一个问题；该问题关闭一个可能改变结论的用户特异变量；回答与问题可从持久化状态恢复。
-
-### 5. 明确裁决并形成行动
-
-得到有效回答后原样保存，设置 `phase: judging`，再读取 `<Path>{roots.workflows}/person/S-steelman-deliberation/judge.md</Path>`。以冻结 dossier 和真实回答裁决，不重做迎合回答的新分析。
-
-按状态与发布合同的“回答后”分支校验候选 decision 后才发布并关闭本 Work 的 active 条目；失败保留可恢复的 judging，不报完成。decision 必须包含明确判断、决定性理由、最强反方回应、具体行动、反转条件与置信度，且能追溯到关键变量和回答。
-
-## 返回合同
-
-每次返回都给出：
-
-- `result`：`awaiting-user-answer | completed | blocked-input | blocked-change-selection | blocked-evidence | reframe-required | validation-failed`；
-- `change`；
-- 权威工件完整 `<Path>…</Path>` 路径；
-- 已运行验证命令、退出码和关键结果；
-- 尚未解决的高影响问题；
-- `decision_type`（完成时）：`recommend | reject | conditional | defer-for-evidence`；
-- 下一路由：等待回答时返回 `<Path>{roots.workflows}/person/S-steelman-deliberation/S-steelman-deliberation.md</Path>` 并携带同一 change；问题已重构时创建新 change；否则明确完成。
-
-只有 `completed` 才能声明已经形成最终判断。`awaiting-user-answer` 的下一路由始终是带着同一 change 回到本入口。

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

@@ -1,86 +0,0 @@
-# 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

@@ -1,56 +0,0 @@
----
-id: specdev/archive-and-consolidate
-type: workflow-entry
-workflow: specdev
-name: 归档与沉淀
-description: 校验本地完成、源 Issue reconcile 门和票级 publish_action 门，复用全局归档能力移动 completed change 并提升当前知识，或从代码访谈形成可归档知识 change。
-keywords: [归档, consolidation, ADR, context, research, knowledge, 代码库访谈]
----
-
-# 归档与沉淀
-
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
-
-A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和代码访谈；机械扫描、dry-run、知识毕业、合并、清理、移动与重读由 `<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>` 单一维护。
-
-激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
-
-## 模式
-
-- **archive**：处理用户指定或唯一的 completed change。
-- **consolidate-from-code**：用户明确要求从当前代码沉淀知识，或没有可归档 change；本次访谈本身创建一个 change，形成、验证、完成后再归档。
-
-多个候选或模式冲突时请求消歧，不猜测。
-
-## Archive 模式
-
-1. 读取全局/change 状态、Ticket、Map、Goal Plan、Evidence、ADR、CONTEXT、LOG、triage 和项目验证事实。
-2. 加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`，确认 `change_status: completed`、完成 owner 已写入时间和证据、无 blocker/deviation；若该 change 是未完成父实现 change 的成员则停止，若其自身是父实现 change 则还需所有成员与 aggregate Evidence 完成。
-3. 检查 `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>` 的 `external_action`：`pending-close` 或 `close-failed` 返回 `<Path>{roots.workflows}/specdev/T-triage/T-triage.md</Path>`；只有 `closed | waived | not-applicable` 继续。再检查 `publish_action`：`pending` 或 `publish-failed` 同样返回 T-triage publish；只有 `not-requested | published | waived`（缺省视为 `not-requested`）继续。
-4. 调用 `<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>` 的 `archive-single + dry-run`，传入已解析 workflow/state/changes/archive/knowledge roots。展示完整移动、提升和清理计划。
-5. 只有用户明确批准该计划后调用 `confirmed`。移动、知识写入和清理均使用计划内路径；计划后出现 drift 时停止。
-6. 重读源、归档目标、全局索引、归档 `<Path>{roots.state}/specdev/archive/YYYY-MM/{change}/.status.json</Path>` 和永久知识；运行 `--stage complete` 及包级校验，报告每个提升/跳过结论。
-
-## Consolidate-from-code 模式
-
-读取 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/consolidation-interview.md</Path>`，由本 Work 创建知识 change、按代码证据访谈并验证后关闭，再回到 Archive 模式。LOG/CONTEXT/ADR 先在该 change 内形成；未验证结论留在 LOG，不直接提升永久知识。
-
-## 晋升前的语义筛选
-
-检查当前性、跨 change 决策价值、实际实现证据、适用范围、真实备选和后果；已接受但尚未实现的计划不能写成当前产品事实。按未来决策价值毕业，不按年龄、字数或数量配额。机械局部修改可以不晋升，但原 change 与必要历史仍保留。
-
-同主题先判断复用、局部取代或完整取代，合并前保留独有理由、负向保证、验证义务与恢复条件。未毕业解释留在原 change；不复制 DSH 的 Notes 树、冻结清单或双语三件套。干预范围仍由原全局归档网关的 dry-run/confirmed 和漂移检查决定。
-
-## 副作用
-
-Dry-run 不修改文件。归档移动、知识 merge/rewrite/delete、Git 动作均在计划展示后单独确认。归档目录完成后只读；后续纠正通过新 change 和 supersedes 链完成。
-
-## 完成标准
-
-- 模式与唯一 change 已确定；
-- 本地完成、external reconcile 门和 publish_action 门通过；
-- 机械归档与知识规则只有全局 skill 一个事实源；
-- dry-run 与 confirmed 执行严格分离；
-- 源不存在、目标完整、active/archived 无重叠、归档状态正确；
-- 永久知识只包含当前、跨 change 有用且有实现证据的结论；
-- 无未批准移动、删除、改写或 Git 副作用。

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

@@ -1,67 +0,0 @@
-# 代码库沉淀访谈协议
-
-本协议由 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md</Path>` 的 consolidate-from-code 模式使用，遵循 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/planning-principles.md</Path>`。
-
-目标不是设计新功能，而是**以当前代码库为基本事实**，把散落在代码里的领域语义与架构决策访谈出来、固化为永久知识。区别于 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`（实现前打磨方案），本协议描述的是**系统当前已经如此**的真相。
-
-## 1. 基本事实优先
-
-- 一切结论以当前代码、配置、接口、schema、测试和经验证文档为准。
-- 提问前先只读探索相关实现，能从代码回答的事实不得转交用户；只有语义命名、边界取舍、不变量意图、历史缘由这类代码无法自证的事项才升级为访谈问题。
-- 涉及不熟悉的外部技术、第三方 API、标准或版本行为时，调用 `<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`，把来源与置信度写入当前 change 的 LOG。
-- 若无相关 change 参考，直接以代码为事实开始访谈，不因缺少历史 change 而阻塞。
-
-## 2. 决策树
-
-按“哪些永久知识当前缺失或过时”驱动，不机械提问：
-
-1. 领域边界与限界上下文：系统由哪些领域构成，各自职责与边界；
-2. 规范术语与语义：代码中的类型/模块名对应什么业务概念，别名与禁用词；
-3. Context Map：多个 bounded context 之间需要明确的关系；
-4. 已固化的架构决策：现有代码体现了哪些难逆转、令人意外且来自真实权衡的决定；
-5. 历史缘由：为什么当前这样，哪些是有意决策、哪些只是可从代码即时发现的实现事实。
-
-## 3. 每轮只关闭一个关键结论
-
-每轮格式：
-
-1. **代码事实：** 简述从代码/测试读到的证据，带 `CODE:<Path>project/relative/path</Path>` 指针；
-2. **唯一问题：** 不使用复合问题；
-3. **可行解读：** 只列实质不同的语义/决策解读；
-4. **权衡：** 不同解读对术语一致性、架构约束、下游影响的差异；
-5. **推荐：** 给出基于代码最可能的默认解读及理由；
-6. **用户结论：** confirmed / deferred / rejected；
-7. **落盘：** 立即更新当前 change 的 LOG，并按需更新 CONTEXT 或 ADR。
-
-## 4. 记录与格式
-
-change 内三份文档复用 grill 的既有格式，避免重复发明：
-
-- 设计日志：`<Path>{roots.workflows}/specdev/G-grill-with-docs/log-format.md</Path>`；
-- 领域上下文：`<Path>{roots.workflows}/specdev/common/rules/context-format.md</Path>`；
-- 架构决策：`<Path>{roots.workflows}/specdev/common/rules/adr-format.md</Path>`；
-- 领域建模规则：`<Path>{roots.workflows}/specdev/common/rules/domain-modeling.md</Path>`。
-
-同步顺序固定：先 LOG，再 CONTEXT，最后 ADR。CONTEXT 只描述当前真相，历史轨迹留在 LOG；未确认的解读不得写成已接受 ADR；与现有永久 ADR 冲突时建立 supersedes 链，不重写历史。高影响条目带来源标识（`USER-DECISION`、`CODE:`、`RESEARCH:`、`ADR-###`）。
-
-## 5. 停止条件
-
-- 目标主题的规范术语、Context Map 与符合准入条件的架构决策已覆盖，足以提升为永久知识；或
-- 用户明确延后，且该延后不伪装成已确认真相；或
-- 缺少必要外部信息或权限，change 标 blocked；或
-- 继续提问只会产生低影响或纯实现细节，交给对应实现阶段决定。
-
-停止后返回 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/确认流程。
-
-## 未来价值与取代关系
-
-逐条核对当前实现、跨 change 用途、真实备选/代价、负向保证和恢复义务；不编造设计理由，不把未落地计划晋升为事实。同主题合并保留独有理由，局部替代保留剩余有效部分。未晋升内容随原 change 保留，永久写入仍走既有 A 网关。

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

@@ -1,42 +0,0 @@
----
-id: specdev/code-review
-type: workflow-entry
-workflow: specdev
-name: 代码审查
-description: 按用户指定的 PR、单 commit、区间或基线冻结真实比较范围，执行隔离的标准轴与规范轴审查；有效空差异诚实返回，不实施修复或发布。
-keywords: [code-review, review, diff, fixed-point, PR, 标准, 规范, no-diff, commit, range]
----
-
-# 代码审查
-
-> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
-
-C 是独立 review 入口，不实施修复。它拥有 `<Path>{roots.state}/specdev/changes/{change}/reviews/</Path>`；I 的最终审查由 I 写入 Evidence，不写本目录。
-
-激活时读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前步骤定位输入和证据。
-
-## 输入
-
-- 用户提供的 commit、branch、tag、merge-base 或 PR locator；缺失时只询问固定点。
-- 可选 source、Spec、Ticket、ADR 和 Goal Plan。
-- 当前仓库代码、commit log 和编码标准。
-
-## 流程
-
-1. **解析固定点**：先选择 baseline（共同祖先到 head）、range（两个指定端点）、commit（指定提交与其父）或 pr（远程 PR diff）。PR 先通过 <Path>{roots.workflows}/specdev/T-triage/remote-operations.md</Path> 的 pr-read 获得完整 base/head SHA。调用 <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> 的 `--review-scope --repo <project-root> --mode <mode>`；端点模式传 --base/--head，commit 传 --commit，多父提交明确 --parent。此只读工具冻结本地对象，不抓取、不写状态；根提交没有现有 CR 的 committed baseline 时明确报告限制，不编造父提交。
-2. **冻结输入**：保存工具返回的实际 diff argv、fixed_point/head、diff_sha256、路径与 commit log，不把单 commit 扩大到当前 HEAD。引用无效则失败；有效空 diff 返回 no-diff，不启动 reviewer、不造 CR、不声称 approved；正常结束本次 Work 并报告固定输入，change 完成仍按原终点规则判断。有差异才继续。
-3. **发现来源**：调用 `<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.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 可恢复状态。
-
-## 完成标准
-
-- 有差异分支的 fixed point/head 是本地不可变 SHA，diff 语义与用户选择一致；no-diff 独立返回，不运行要求 CR 的 review stage；
-- 规范和标准来源发现顺序有记录；
-- 两轴隔离、固定顺序、未合并排名；
-- 每个 finding 有路径、风险、依据和满足条件；
-- 报告、状态、验证结果和下一 Work 路径一致；
-- C 未修改项目代码或远程状态。
-
-审查接口双方、生命周期、取消/重试、资源释放、真实执行入口与可绕过路径；项目文档和模型可见内容变化分别按 <Path>{roots.workflows}/specdev/common/rules/documentation-standard.md</Path> 与 <Path>{roots.workflows}/specdev/common/rules/agent-experience.md</Path> 核对。base/head、配置或规范输入变化后重新评估受影响结论，不沿用旧 head 的通过。