@namewta/speculo 0.3.0 → 0.3.2

package/template/canonical/canonical-teach.md

@@ -1,301 +0,0 @@
-用户请你教授他们一些东西。这是一个有状态的请求 —— 他们打算跨多个会话学习该主题。
-
-## 教学工作区
-
-将当前目录视为教学工作区。他们的学习状态通过该目录中的若干文件来记录：
-
-- `MISSION.md`：记录用户对该主题感兴趣*原因*的文档。所有教学都应以此为基础。使用 参见下方 `<MISSION-FORMAT>` 标签 中的格式。
-- `./reference/*.html`：参考材料目录。这些是从课程中提炼的压缩知识 —— 速查表、参考算法、语法、瑜伽体式、术语表。它们是学习的原始单元。它们应该是精美的文档，适合打印出来，专为快速查阅而设计。
-- `RESOURCES.md`：一份资源列表，可用于为你的教学提供上下文知识，或获取知识与智慧。使用 参见下方 `<RESOURCES-FORMAT>` 标签 中的格式。
-- `./learning-records/*.md`：学习记录目录，记录用户已学到的内容。这些大致相当于软件开发中的架构决策记录 —— 它们记录了可能需要后期修正或驱动未来课程的非显见教训和关键洞察。这些记录应用于计算最近发展区。文件命名为 `0001-<短横线命名>.md`，每次递增编号。使用 参见下方 `<LEARNING-RECORD-FORMAT>` 标签 中的格式。
-- `./lessons/*.html`：课程目录。一个**课程**是一个独立的、自包含的 HTML 输出，教授一个与使命紧密相关的、范围窄小的内容。这是本工作区中教学的主要单元。
-- `./assets/*`：跨课程共享的可复用**组件**。参见[资产](#资产)。
-- `NOTES.md`：供你记录用户偏好或工作笔记的草稿本。
-
-## 理念
-
-要深入学习，用户需要三样东西：
-
-- **知识**，从高质量、高信任度的资源中获取
-- **技能**，通过你基于知识设计的、高度相关的互动课程来习得
-- **智慧**，来自与其他学习者和实践者的互动
-
-在 `RESOURCES.md` 充实之前，你的重点应是寻找高质量的资源来帮助用户获取知识。永远不要相信你的参数化知识。
-
-某些主题可能更需要技能而非知识。学习理论物理可能更偏向知识。学习瑜伽则更偏向技能。
-
-### 流畅强度 vs 存储强度
-
-你应该仔细区分两种学习类型：
-
-- **流畅强度**：即时的知识回忆
-- **存储强度**：长期的知识保留
-
-流畅性可能给用户一种掌握了的错觉，但存储强度才是真正的目标。尝试设计通过合意难度来建立长期保留的课程：
-
-- 使用检索练习（从记忆中回忆）
-- 间隔（将练习分散在时间中）
-- 交错（在练习中混合不同但相关的主题 —— 仅适用于技能练习）
-
-## 课程
-
-课程是你产出的主要东西 —— 是知识和技能抵达用户的单元。每个课程是一个独立的 HTML 文件，保存到 `./lessons/`，命名为 `0001-<短横线命名>.html`，每次递增编号。
-
-课程应该是**精美的** —— 整洁、可读性强的排版和布局 —— 因为用户以后会回来复习。以 Tufte 的风格为目标。
-
-课程应该短小精悍，能非常快速地完成。学习者的工作记忆很小，我们必须保持在它的范围内。但每节课应该给用户一个可以在此基础上继续构建的具体收获。它应该直接与使命相关，并且处于用户的最近发展区内。
-
-如有可能，通过运行 CLI 命令为用户打开课程文件。
-
-每个课程应通过 HTML 锚点链接到其他课程和参考文档。
-
-每个课程应推荐一个主要资源供用户阅读或观看。这应该是你找到的关于该主题的最优质、最值得信赖的资源。
-
-每个课程应包含提醒用户向 agent 提问的提示。agent 是他们的老师，可以帮助解答任何不清楚的地方。
-
-## 资产
-
-课程由可复用的**组件**构建，存储在 `./assets/` 中：样式表、测验小部件、模拟器、图表辅助工具 —— 任何第二个课程可以复用的东西。
-
-复用是默认原则，而非例外。在编写课程之前，先阅读 `./assets/` 并基于已有的组件构建。当课程需要新的可复用内容时，将其编写为 `./assets/` 中的组件并链接它 —— 永远不要将未来课程会重复的代码内联。
-
-共享样式表是每个工作区获得的第一个组件：每个课程都链接它，使课程看起来像一个统一的课程体系，而非一堆零散的单品。随着工作区的成长，组件库也应随之成长。
-
-## 使命
-
-每个课程都应与使命相关联 —— 即用户对该主题感兴趣的原因。
-
-如果用户对使命不明确，或 `MISSION.md` 未填写，你的首要任务应该是询问用户为什么想学这个。
-
-未能理解使命将意味着知识获取没有扎根于现实世界目标。课程会感觉过于抽象。你将无法判断用户下一步应该做什么。
-
-随着用户技能和知识的增长，使命可能会改变。这是正常的 —— 务必更新 `MISSION.md` 并添加一条学习记录来记录这一变化。在更改使命前请与用户确认。
-
-## 最近发展区
-
-每节课，用户应始终感觉他们被"恰到好处"地挑战。
-
-用户可能会指定他们想学的确切内容。如果没有，通过以下方式找出他们的最近发展区：
-
-- 阅读他们的 `learning-records`
-- 根据他们的使命找出正确的教授内容
-- 教授处于其最近发展区内的最相关内容
-
-## 知识
-
-课程应围绕用户将学习的技能来设计。课程中的知识应仅限于习得该技能所需的内容。你先教授知识，然后让用户通过互动反馈循环来练习技能。
-
-知识应首先从可信资源中收集。使用 `RESOURCES.md` 来跟踪它们。课程应遍布引用 —— 即支持任何主张的外部资源链接。这增加了课程的可信度。
-
-对知识获取来说，难度是敌人。它会消耗你理解所需的工作记忆。
-
-## 技能
-
-如果说知识的核心是获取，那么技能的核心就是持久性和灵活性。让知识扎根。
-
-对技能获取来说，难度是工具。努力检索才是建立存储强度的方式。技能应通过互动课程来教授。你有以下几种工具可供使用：
-
-- 互动课程，使用测验和轻量级浏览器内任务
-- 引导用户完成一系列现实世界操作步骤的课程（例如，瑜伽体式）
-
-每种方式都应基于**反馈循环**，让用户获得对其表现的反馈。这个反馈循环应尽可能紧密，即时提供反馈 —— 最好是自动化的。
-
-对于测验，每个答案应恰好包含相同数量的单词（如可能，也包含相同数量的字符）。不要通过格式给用户任何关于答案的线索。
-
-## 获取智慧
-
-智慧来自真正的现实世界互动 —— 在学习环境之外检验你的技能。
-
-当用户提出一个看似需要智慧的问题时，你的默认姿态应是尝试回答 —— 但最终要委托给一个**社区**。
-
-社区是用户可以在现实世界中检验其技能的场所（线上或线下）。这可能是一个论坛、一个 subreddit、一个线下课程（预算允许的话）或一个本地兴趣小组。
-
-你应尝试找到用户可加入的高声望社区。如果用户表示不想加入社区，请尊重这一意愿。
-
-## 参考文档
-
-在创建课程的同时，你也应创建参考文档。课程可以引用这些文档 —— 它们有助于跟踪跨课程有用的知识原始单元。
-
-课程很少会被重新翻阅 —— 参考文档才会。它们应该是课程的压缩精华，采用专为快速查阅设计的格式。
-
-某些学习主题天然适合参考：
-
-- 编程的语法和代码片段
-- 流程的算法和流程图
-- 瑜伽的体式和序列
-- 健身的练习和训练计划
-- 任何有自己术语体系的主题的术语表
-
-特别是术语表，是必不可少的参考。一旦创建，每节课都应遵循它。
-
-## `NOTES.md`
-
-用户有时会表达他们希望如何被教授，或你应注意的事项。这是记录这些偏好的地方，以便你在设计课程或与用户协作时可以回头参考。
-
----
-
-## 参考内容
-
-<MISSION-FORMAT>
-
-# MISSION.md 格式
-
-`MISSION.md` 位于工作区根目录。它捕获用户学习该主题的_原因_。每个教学决策 — 接下来教什么、呈现哪些资源、设计哪些练习 — 都应追溯到此文档。
-
-## 模板
-
-```md
-# Mission: {Topic}
-
-## Why
-{1-3 句话。用户正在追求的具体的、真实世界中的目标。当拥有这项技能时，他们的生活或工作中会发生什么改变？避免抽象的表述如"理解 X" — 追问底层的成果。}
-
-## Success looks like
-- {用户将能够做到的一件具体的、可观察的事情}
-- {另一件具体的事情}
-- {……}
-
-## Constraints
-- {时间、预算、既有承诺、学习偏好，任何限制方法的边界条件}
-
-## Out of scope
-- {用户明确不想现在追求的相邻主题 — 保护最近发展区}
-```
-
-## 规则
-
-- **每个工作区一个使命。** 如果用户想学习两个不相关的东西，那就是两个工作区。
-- **具体优于抽象。** "十月份之前跑完半程马拉松"优于"变得更健康"。"给我的团队交付一个 Rust CLI 工具"优于"学习 Rust"。
-- **对模糊性进行追问。** 如果用户无法说清为什么，在写任何东西之前和他们面谈。一个糟糕的使命比没有使命更糟。
-- **当现实改变时修订。** 使命会改变。当用户的目标移动时，更新此文件 — 不要让一个过时的使命引导未来的会话。
-- **保持简短。** 如果 `MISSION.md` 超过一屏，它已经不再是罗盘，而是变成了计划。
-
-</MISSION-FORMAT>
-
-<LEARNING-RECORD-FORMAT>
-
-# 学习记录格式
-
-学习记录存放在 `./learning-records/` 中，使用顺序编号：`0001-slug.md`、`0002-slug.md` 等。延迟创建目录 — 仅在第一条记录被写入时才创建。
-
-它们是教学领域的 ADR：捕获非显而易见的经验、关键洞察以及将会指导未来会话的既有知识声明。它们用于计算最近发展区。
-
-## 模板
-
-```md
-# {对学到或确立的内容的简短标题}
-
-{1-3 句话：学到了什么（或确立了哪些既有知识），以及为什么它对未来会话重要。}
-```
-
-这就是全部格式。一条学习记录可以就是一个段落。其价值在于记录_这个_知识现在已知，以及_为什么_它会改变接下来教什么 — 而不是填满各个部分。
-
-## 可选部分
-
-仅当它们真正增加价值时才包含这些。大多数记录不需要它们。
-
-- **Status** 前置元数据（`active | superseded by LR-NNNN`）— 当早期的理解后来被发现是错误的并被替换时有用。
-- **Evidence** — 用户如何展示了理解（回答了一个问题、完成了一个练习、引用了先前经验）。当声明可能被重新审视时有用。
-- **Implications** — 这为未来会话解锁了什么或排除了什么。当不显而易见时值得记录。
-
-## 编号
-
-扫描 `./learning-records/` 中的最高现有编号，然后加 1。
-
-## 何时编写学习记录
-
-当以下任一为真时编写：
-
-1. **用户展示了对某个非平凡事物的真正理解** — 不仅仅是接触，而是有证据表明他们可以正确使用该概念。这为接下来教什么设定了新底线。
-2. **用户披露了既有知识** — "我已经知道 X。"记录下来，这样未来的会话不会重复教它。同时记录所声称的_深度_。
-3. **一个误解被纠正了** — 用户之前相信了错误的东西，现在明白了为什么。这些是高价值的：它们预测了相关主题未来的绊脚石。
-4. **使命因学习而转变** — 用户发现他们关心的东西与之前想的不同。交叉链接到 [[MISSION.md]] 并更新它。
-
-### 什么不算
-
-- 仅仅覆盖过的材料。覆盖不等于学习。等有证据再说。
-- 任何已简明地作为术语定义捕获在 [[GLOSSARY.md]] 中的内容。不要重复。
-- 逐次会话的活动日志。学习记录不是日志 — 它们是决策级别的洞察。
-
-## 取代
-
-当后来的记录与之前的记录矛盾时（用户的理解深化了或被纠正了），将旧记录标记为 `Status: superseded by LR-NNNN`，而非删除它。理解如何演变的历史本身就是有用的信号。
-
-</LEARNING-RECORD-FORMAT>
-
-<GLOSSARY-FORMAT>
-
-# GLOSSARY.md 格式
-
-`GLOSSARY.md` 是该教学工作区的规范语言。所有讲解、练习和学习记录都应遵守其术语。构建它本身就是学习的一部分：将一个概念压缩成精确的定义，是用户理解它的证据。
-
-## 结构
-
-```md
-# {主题} 术语表
-
-{对该术语表所涵盖主题的一两句话描述。}
-
-## Terms
-
-**Hypertrophy**：
-由反复训练过程中的机械张力和代谢压力驱动的肌肉增长。
-_Avoid_: Bulking, getting big
-
-**Progressive overload**：
-随着时间系统地增加对肌肉的需求 — 通过负荷、训练量或强度。
-_Avoid_: Pushing harder, levelling up
-
-**RPE (Rate of Perceived Exertion)**：
-对一组训练有多吃力的 1–10 分自评，10 表示力竭，8 表示还有两次重复的余力。
-_Avoid_: Effort score, intensity rating
-```
-
-## 规则
-
-- **仅在用户理解术语后添加。** 术语表是压缩知识的记录，不是用户可以阅读来学习的字典。如果用户刚接触一个概念，等到他们能正确使用它再将其提升到此。
-- **要有主见。** 当存在多个表示同一概念的词时，选择最好的那个，将其余列为应避免的别名。这就是语言压缩的方式。
-- **定义保持精炼。** 一到两句话。定义术语是什么，而不是它做什么或如何做。
-- **在定义中使用术语表自身的术语。** 一旦一个术语被收录在术语表中，在任何地方都优先使用它 — 包括在其他定义中。这就是后续理解复杂术语变得更容易的原因。
-- **当自然形成聚类时，用子标题分组**（例如 `## Anatomy`、`## Programming`）。当术语内在一致时，扁平列表也可以。
-- **明确标记歧义。** 如果一个术语在更广泛的领域中被宽松使用，注明本工作区的选择："在本工作区中，'set' 始终表示正式组 — 热身组单独跟踪。"
-- **随着理解深入而修订。** 用户在第一周写的定义到第六周可能是错的。就地更新；不要留下过时的条目。
-
-</GLOSSARY-FORMAT>
-
-<RESOURCES-FORMAT>
-
-# RESOURCES.md 格式
-
-`RESOURCES.md` 是该主题的精选可信来源集合。讲解中的知识应从此处提取，而非从参数化猜测中获取。智慧来自此处列出的社区。
-
-## 结构
-
-```md
-# {主题} 资源
-
-## Knowledge
-
-- [书籍：_The Science and Practice of Strength Training_ — Zatsiorsky & Kraemer](https://example.com)
-  关于编排与适应的基础文本。适用：任何与周期化、恢复、强度区间相关的内容。
-- [文章："How Much Should I Train?" — Greg Nuckols (Stronger By Science)](https://example.com)
-  关于训练量参考点的循证综述。适用：每周每个肌群的组数目标。
-
-## Wisdom (Communities)
-
-- [r/weightroom](https://reddit.com/r/weightroom)
-  高信号 subreddit，严格管控伪科学。适用：训练方案评价、平台期排除。
-- 本地：周二在 {健身房名称} 的力量课程
-  适用：举重的实时指导反馈。
-```
-
-## 规则
-
-- **仅高信任度来源。** 偏好一手来源、公认专家、同行评审工作和具有强管控的社区。如果某个资源是伪装成教育的营销内容，排除它。
-- **为每个条目注释。** 一个裸链接在三个月后毫无用处。添加一行：它涵盖什么以及何时使用它。
-- **按 Knowledge / Wisdom 分组。** 对应 SKILL.md 中的理念。一个资源只出现在一个组中是没问题的。
-- **明确标记缺口。** 如果使命所需的某个领域没有好的资源，写一个 `## Gaps` 部分列出缺失的内容。这将驱动未来的搜索。
-- **无情地修剪。** 一个被证明是错的、肤浅的或偏离使命的资源应该被移除，而不是被埋没。五个精选来源比三十个平庸的要好。
-- **记录社区偏好。** 如果用户选择不加入社区，在此注明，这样未来的会话不会不断建议它们。
-
-</RESOURCES-FORMAT>

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

@@ -1,49 +0,0 @@
-# 归档规则
-
-归档是破坏性目录移动——将已完成变更从 `changes/` 移动到 `archive/`。调用方必须先展示完整计划并取得明确确认，方可执行。
-
-## 共同预检
-
-对每个候选 change 执行以下预检，**任一项失败则整批阻塞**（批量原子性）：
-
-1. **名称格式**：change 名称符合 `^\d{4}-\d{2}-\d{2}-[a-z0-9]+(-[a-z0-9]+)*$`（`YYYY-MM-DD-<kebab-topic>`）。不含日期前缀的遗留 change 标注警告但不阻塞，从文件修改时间推断 YYYY-MM。
-2. **状态可解析**：`.status.json` 可解析，`change_status` 字段存在且值为 `completed`。
-3. **源存在**：源目录 `<Path>{roots.state}/specdev/changes/{change}/</Path>` 真实存在。
-4. **目标不冲突**：目标目录 `<Path>{roots.state}/specdev/archive/<YYYY-MM>/<change>/</Path>` 不存在（YYYY-MM 从 change 名称提取）。
-5. **状态一致**：`<Path>{roots.state}/specdev/status.json</Path>` 的 `active` 数组中存在该 change 的条目（通过 `change` 字段匹配），且 `result` 为 `"completed"`（或不匹配但 change 自身 `.status.json` 状态为 completed——此时记录警告但不阻塞）。
-6. **worktree 已合并**：若使用了 worktree 隔离模式，确认已合并回目标分支并清理；未合并则记录 `blocked`。
-
-## 归档移动步骤
-
-确认执行后，按以下顺序操作：
-
-1. 创建 `<Path>{roots.state}/specdev/archive/<YYYY-MM>/</Path>` 月目录（如不存在）。
-2. 将 `<Path>{roots.state}/specdev/changes/{change}/</Path>` 整个目录原子移动到 `<Path>{roots.state}/specdev/archive/<YYYY-MM>/<change>/</Path>`。使用 mv/rename，不用复制后删除。
-3. 从 `<Path>{roots.state}/specdev/status.json</Path>` 的 `active` 数组中移除该 change 的条目，追加归档记录到 `completed` 数组（`change`、`path`、`archived_at`、`archive_path`）。
-4. 更新已移动的 `.status.json`：
-   - `change_status: "archived"`
-   - `archived: true`
-   - `archive_path`: 指向归档位置的相对路径
-5. 若 `changes/` 目录变空，保留空目录和 `.gitkeep`。
-
-## 冲突处理
-
-| 冲突 | 处理 |
-|------|------|
-| 目标已存在 | `blocked`——永不覆盖归档；需手动解决 |
-| `.status.json` 不可解析或格式错误 | `blocked`——整批阻塞 |
-| change 不在 `status.json#active` 中且自身状态非 completed | `blocked`——状态不一致 |
-| change 名称不含日期前缀（遗留） | 警告但不阻塞；从文件修改时间推断 YYYY-MM |
-| 归档月目录创建失败（权限） | `blocked`——报告具体错误 |
-
-## 重读验证
-
-归档执行后逐项验证：
-
-1. 源路径不存在（移动成功）。
-2. 目标路径完整存在，内容与移动前一致。
-3. `<Path>{roots.state}/specdev/status.json</Path>` 的 `active` 数组已移除该 change 条目，`completed` 数组已追加归档记录。
-4. 归档目录 `.status.json` 字段一致（`change_status: archived`、`archived: true`、`archive_path` 正确）。
-5. 验证失败时报告已完成/未完成清单，不猜测成功。
-
-**完成标准**：源不存在、目标完整、active 索引已移除、归档状态字段一致。

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

@@ -1,80 +0,0 @@
-# 清理规则
-
-知识沉淀完成后，审计三个永久知识库（`adr/`、`context/`、`research/`），识别陈旧、重复、格式违规的内容，生成清理候选清单。默认只分析，不自行修改文件。
-
-## 扫描范围
-
-1. 扫描 `<Path>{roots.state}/specdev/adr/</Path>`——所有 ADR 文件
-2. 扫描 `<Path>{roots.state}/specdev/context/</Path>`——所有术语定义文件
-3. 扫描 `<Path>{roots.state}/specdev/research/</Path>`——`index.md` 及其索引的所有研究文件
-4. 交叉引用：扫描活跃变更（`changes/`）、归档变更（`archive/`）和项目代码中对 ADR 编号、术语名、研究主题的引用
-
-## 五种清理分类
-
-### delete（可删除）
-
-- 已被标记 `Superseded` 超过 30 天且无活跃变更引用的 ADR
-- 空文件或仅含占位符/模板说明的知识文件（保留超过 60 天）
-- 已退役术语/概念——在所有活跃变更、代码中无引用
-- 研究文件结论已被 ADR 充分吸收且无独立参考价值
-- 多处复制的同一内容——保留权威来源，其余删除或替换为指针
-
-### merge（可合并）
-
-- `adr/` 中多条主题相似的 ADR——合并为一条，注明多个来源
-- `context/` 中同一概念在多处有不同表述但实质相同——指定权威版本，其余加指针
-- 被新 ADR 或新研究完全吸收的旧内容——合并到对应条目
-
-### rewrite（可改写）
-
-- 内容正确但格式不符合 G-grill-with-docs 规范的条目
-- 含有相对时间表述（"recently"、"两个月前"、"不久前"）——改为绝对日期
-- "保留作历史"但无真实读者和用途的条目——精简为指针或删除
-
-### needs-confirmation（需确认）
-
-- 术语定义冲突（`context/` 中同一术语有不同定义，无法自动裁决）
-- ADR 内容的实质性改写
-- `research/` 中研究发现矛盾无法自动裁决
-- 任何涉及删除规则或约束的修改
-
-### keep（保留）
-
-- 仍被代码、文档、活跃变更或归档变更引用的内容
-- 距创建不足 30 天的 ADR（即使已被 supersede）
-- 单次出现但满足毕业标准的知识（可能只是新领域，引用尚未积累）
-
-## 交叉验证规则
-
-- **删除前验证**：确认无活跃变更、代码文件或归档文档引用该项
-- **合并前验证**：确认合并结果不丢失任一来源的独特内容
-- **路径包含验证**：确认目标位于 `<Path>{roots.state}/specdev/</Path>` 声明的知识库范围内
-- **引用链检查**：若 ADR A 被 ADR B supersede，ADRB 又被 ADR C supersede——整个链视为一体，只清理末端之前的项
-
-## 反模式扫描
-
-扫描知识库中的以下反模式并标注处理建议：
-
-| 反模式 | 示例 | 处理 |
-|--------|------|------|
-| 历史叙述占位 | ADR 开头"2025 年 3 月，v2 架构上线..." | 历史迁 CHANGELOG/git；当前约束原地保留 |
-| 多版本声称"当前" | 两个 ADR 都声称描述当前认证方案 | 以代码现状裁决；历史版显式标注已废弃 |
-| 已完成 TODO 仍列开放 | "TODO: 迁移到新 API（2025-Q2）"已完成但未更新 | 核实后删除或改为当前约束 |
-| 单次事故长篇常驻 | 30 行的事后分析作为 ADR 常驻 | 提炼可复用教训；详细过程留在归档变更中 |
-| 会话残留 | `_old/`、`_backup/`、一次性调试脚本 | 有效内容并入正式文档；文件列入删除候选 |
-
-## 保护规则
-
-- **路径包含检查**：删除前解析真实路径，确认位于 `<Path>{roots.state}/specdev/</Path>` 下
-- **不跨 workflow**：清理范围限定于 specdev workflow 的知识库
-- **`.gitkeep` 处理**：目录有其他内容时移除 `.gitkeep`；空目录保留 `.gitkeep`
-- **ADR 历史链保护**：被 supersede 的 ADR 即使满足删除条件，若其后继 ADR 距创建不足 30 天则保留
-
-## 完成标准
-
-- 三个知识库均已扫描
-- 每个候选属于恰好一个分类（`delete | merge | rewrite | keep | needs-confirmation`）
-- 每个候选有来源路径、证据、风险说明
-- 删除候选已通过交叉验证确认无活跃引用
-- 反模式已标注
-- 未确认时文件系统未发生变化

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

@@ -1,122 +0,0 @@
-# 知识沉淀规则
-
-基于鉴别结果，向三个永久知识库执行写入操作。所有写入遵循 append/merge 语义——不盲写覆盖已有内容。
-
-## adr/ 写入规则
-
-### 序号分配
-
-扫描 `<Path>{roots.state}/specdev/adr/</Path>` 下所有现有 ADR 文件，提取最大序号。新 ADR 取 N+1，四位零填充（`0001`、`0002`...）。
-
-### 文件命名
-
-`<NNNN>-<kebab-slug>.md`，其中 slug 从决策标题提取。例如：`0005-jwt-refresh-token-mechanism.md`。
-
-### 内容格式
-
-永久库 ADR 与变更内 ADR（`<Path>{roots.workflows}/specdev/G-grill-with-docs/adr-format.md</Path>` 的 `## NNNN: 标题` 段落格式）格式不同——永久库使用独立文件与结构化字段：
-
-```markdown
-# ADR-NNNN: {标题}
-
-- **日期**：{YYYY-MM-DD}
-- **状态**：Accepted
-- **决策上下文**：{为什么需要做这个决策}
-- **决策内容**：{具体决策是什么}
-- **后果**：{这个决策带来的影响，正面和负面}
-```
-
-从变更内 ADR 提升时：标题取 `## NNNN: {标题}` 中的标题文本，正文扩写为上述五字段；来源 change 与原编号写入「决策上下文」。
-
-### Supersede 处理
-
-若新 ADR 取代旧 ADR，在旧 ADR 文件**开头**添加横幅：
-
-```markdown
-> **Superseded by [ADR-NNNN](./NNNN-<slug>.md)** — {简要说明取代原因}
-```
-
-**不删除旧 ADR**——历史决策链完整保留。
-
-### 从 LOG 提升
-
-若变更的 `LOG.md` 中存在 `LOG-XXXX: accepted` 条目，其结论满足 ADR 三条件（难以逆转 + 令人意外 + 真实权衡）但未正式记录为 ADR，则：
-
-1. 创建正式 ADR 文件
-2. 在 Context 中注明"从 `<change-name>` 的 LOG-XXXX 提升"
-3. 在原 LOG 条目添加 `Related: ADR-NNNN` 交叉引用
-
-## context/ 写入规则
-
-### 文件组织
-
-`<Path>{roots.state}/specdev/context/</Path>` 下的术语可以组织在一个或多个 `.md` 文件中。若目录为空，创建首个术语文件（如 `domain-glossary.md`）。
-
-### 条目格式
-
-遵循 `<Path>{roots.workflows}/specdev/G-grill-with-docs/context-format.md</Path>` 定义的格式：
-
-```markdown
-**术语名**：一句话定义（1-2 句，精确、观点明确）。
-
-_Avoid_: 别名1, 别名2（不应使用的同义词或旧称）
-```
-
-### 合并策略
-
-| 场景 | 操作 |
-|------|------|
-| 新术语 | 追加条目到对应分组（如有） |
-| 术语已存在，定义更新 | 替换定义文本；合并 `_Avoid_` 列表（取并集） |
-| 术语更名 | 创建新条目；将旧名加入新条目的 `_Avoid_`；旧条目保留并标注 `> **注意**：此术语已更名为 **新术语名**` |
-| 术语废弃 | 保留条目，标注 `> **已废弃**：{原因}，参见 **替代术语**` |
-
-### 来源溯源
-
-每个新增或更新的术语条目末尾添加来源标注：
-
-```markdown
-_来源：`<change-name>`（{YYYY-MM-DD}）_
-```
-
-## research/ 写入规则
-
-### 文件组织
-
-研究产物写入 `<Path>{roots.state}/specdev/research/<topic>.md</Path>`。维护 `<Path>{roots.state}/specdev/research/index.md</Path>` 索引表。
-
-### index.md 格式
-
-```markdown
-# 研究索引
-
-| 主题 | 来源变更 | 归档日期 | 摘要 |
-|------|---------|---------|------|
-| `<topic>` | `<change-name>` | {YYYY-MM-DD} | 一句话描述研究内容和结论 |
-```
-
-### 合并策略
-
-| 场景 | 操作 |
-|------|------|
-| 新主题 | 复制研究文件到 `_state/research/`；追加条目到 `index.md` |
-| 主题已存在，新发现补充 | 合并新发现到现有文件；更新 `index.md` 中的归档日期和摘要 |
-| 主题已存在，新研究完全取代 | 在旧文件开头标注 `> **Superseded**：更新版本见本文后续内容`；追加新发现；更新 `index.md` |
-| 纯变更特定 | 保留在归档变更的 `research/` 中，不提升 |
-
-## 保护规则
-
-- **不盲写覆盖**：所有写入使用 append/merge 语义；不会不经提示地覆盖已有内容
-- **首次写入自动创建**：`adr/`、`context/` 目录首次写入时若不存在则自动创建
-- **来源溯源**：所有合并内容标注来源变更名称和日期
-- **禁止跨 workflow**：写入范围限定于 `<Path>{roots.state}/specdev/</Path>` 下的 adr/、context/、research/
-- **格式规范**：写入内容遵循 G-grill-with-docs 定义的格式规范（`adr-format.md`、`context-format.md`）
-
-## 完成标准
-
-- 所有计划中的知识项已写入对应知识库
-- 新建 ADR 编号连续且格式正确
-- context/ 术语已合并且冲突已按用户裁决解决
-- research/ 研究文件已添加且 `index.md` 已更新
-- 被取代的旧条目已标注横幅
-- 无未声明的路径被写入

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

@@ -1,96 +0,0 @@
-# 知识鉴别指南
-
-将已完成变更中通过毕业标准的知识，与三个永久知识库（`adr/`、`context/`、`research/`）的现有内容逐项比对，判定处置动作。**核心原则：不盲目追加——每次写入必须经过比对评估。**
-
-## 四步鉴别法
-
-### 第一步：读取现有知识库
-
-对三个知识库建立可检索索引：
-
-- **adr/**：逐文件读取 `<Path>{roots.state}/specdev/adr/</Path>` 下所有 `NNNN-slug.md`，提取标题、决策主题、状态（Accepted/Superseded/Deprecated）、Superseded 链
-- **context/**：逐文件读取 `<Path>{roots.state}/specdev/context/</Path>` 下所有术语定义，提取术语名、定义文本、`_Avoid_` 列表
-- **research/**：读取 `<Path>{roots.state}/specdev/research/index.md</Path>` 索引表及所有研究文件，提取主题、结论摘要、来源变更
-
-### 第二步：逐项比对
-
-将每个知识候选项与对应目标库的现有内容进行比对：
-
-#### adr/ 比对
-
-对每个 ADR 候选项，在现有 `adr/` 中按**决策主题**（非标题字符串）匹配：
-
-| 匹配结果 | 处置动作 | 说明 |
-|---------|---------|------|
-| 主题未找到 | **create** | 创建新 ADR 文件，分配下一个可用序号（四位零填充） |
-| 主题相同，候选项更全面或更新了结论 | **supersede** | 旧 ADR 添加 `Superseded by ADR-NNNN` 横幅；创建新 ADR |
-| 主题相同，候选项补充了新后果或上下文 | **update** | 将新信息合并到现有 ADR 正文，补充 Consequences 或 Context |
-| 主题相同，内容实质一致 | **skip** | 标注"已有"，不重复写入 |
-| 主题相同，结论直接矛盾 | **needs-confirmation** | 展示双方版本及建议，等待用户裁决 |
-| 现有 ADR 已被新变更推翻且 >30 天无引用 | **retire** | 标记废弃，移入清理候选（在清理计划中处理） |
-
-**Supersede 链处理**：若发现链式取代（A 被 B 取代，B 被 C 取代），C 为当前版本，A 和 B 为历史。只对链末端操作。
-
-#### context/ 比对
-
-对每个术语候选项，在现有 `context/` 中按**术语名**和 **`_Avoid_` 别名**精确匹配：
-
-| 匹配结果 | 处置动作 | 说明 |
-|---------|---------|------|
-| 术语名和别名均未找到 | **create** | 添加新术语条目（`**术语**：定义` + `_Avoid_` 列表） |
-| 术语已存在，定义相同 | **skip** | 标注"已有"，不重复 |
-| 术语已存在，定义更精确或范围扩展 | **update** | 合并更新定义；`_Avoid_` 列表取并集 |
-| 术语已存在，定义实质不同 | **needs-confirmation** | 展示双方版本及建议，等待用户裁决 |
-| 术语被重命名（旧名 → 新名） | **rename** | 创建新术语条目，将旧名加入新条目的 `_Avoid_`；旧条目保留并标注指向新条目 |
-| 现有术语在所有活跃变更和代码中均无引用 | **retire** | 弱信号——标记为待用户审核，不自动删除 |
-
-**术语合并规则**：
-- 同一概念的不同表述 → 指定更精确的定义为权威版本
-- 定义相同但 `_Avoid_` 列表有补充 → 合并 `_Avoid_`（取并集）
-- 分组维护：若术语属于已有分组，归入对应分组
-
-#### research/ 比对
-
-对每个研究候选项，在 `<Path>{roots.state}/specdev/research/index.md</Path>` 中按**主题**匹配：
-
-| 匹配结果 | 处置动作 | 说明 |
-|---------|---------|------|
-| 主题未找到 | **create** | 复制研究文件到 `_state/research/`，更新 `index.md` |
-| 主题已存在，新发现补充 | **update** | 合并新发现到现有研究文件，更新日期和来源 |
-| 主题已存在，新研究完全取代 | **supersede** | 标注旧研究为 superseded，新研究成为权威版本 |
-| 主题已存在，发现一致 | **skip** | 标注"已有"，不重复 |
-| 研究发现矛盾 | **needs-confirmation** | 展示双方结论，等待用户裁决 |
-| 纯变更特定（仅对该变更有用） | **skip** | 保留在归档变更中，不提升 |
-
-### 第三步：交叉验证
-
-- 一个变更的知识可能关联多个现有条目——检查是否遗漏关联
-- 新 ADR 可能影响多个现有 context 术语——检查术语是否需要同步更新
-- 研究结论可能支持或削弱现有 ADR——检查是否需要标注关联
-
-### 第四步：标注处置
-
-每个知识项输出以下信息：
-
-```
-- 来源变更：<change-name>
-- 来源文件：ADR.md / CONTEXT.md / LOG.md / research/<topic>.md
-- 知识类型：架构决策 / 领域术语 / 研究产物
-- 目标知识库：adr/ / context/ / research/
-- 处置动作：create / update / merge / supersede / retire / skip / needs-confirmation
-- 毕业标准：稳定机制 / 重复教训 / 接手者必知
-- 内容摘要：1-2 句话
-- 风险等级：低 / 中 / 高
-```
-
-## 处置动作汇总
-
-| 动作 | 含义 | 写入行为 |
-|------|------|---------|
-| **create** | 全新知识，知识库中不存在 | 创建新文件或新条目 |
-| **update** | 已有知识，候选项更精确/全面 | 合并写入现有文件 |
-| **merge** | 实质相同但表述不同 | 保留现有为权威，补充候选项独特内容 |
-| **supersede** | 候选项取代现有知识 | 旧条目加横幅，新条目创建 |
-| **retire** | 现有知识已过时 | 标记废弃，移入清理候选 |
-| **skip** | 完全相同或不符合毕业标准 | 不写入，记录原因 |
-| **needs-confirmation** | 冲突或实质性矛盾 | 展示双方版本，等待用户裁决 |