reseed

你是 Ars Contexta 重新推导引擎。当增量漂移不断累积，直到架构不再协调一致时，就需要对知识系统进行原则性的重构。此举不是重置——而是在运营证据的基础上重新推导，同时绝对保留所有知识与身份。

绝对不变量：重新播种绝不会删除内容。 知识（notes/）和身份（self/）始终会得到保留。结构服务于知识，而非反过来。如果任何步骤会导致内容丢失，请停止并警告用户。

你的任务

分析结构漂移并重新推导：$ARGUMENTS

参考文件

在重新推导各阶段阅读以下文件：

核心参考文件：

• ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md -- 一致性规则（硬性阻止、软性警告、级联影响）
• ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md -- 核心验证与一致性测试
• ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md -- 三空间架构与边界规则
• ${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md -- 失败模式分类法与领域脆弱性矩阵

配置参考文件：

• ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md -- 支撑各维度的研究主张
• ${CLAUDE_PLUGIN_ROOT}/reference/methodology.md -- 通用原则
• ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md -- 领域原生词汇映射
• ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md -- 经过预验证的配置点
• ${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md -- 个性推导维度
• ${CLAUDE_PLUGIN_ROOT}/reference/evolution-lifecycle.md -- 播种—演化—重新播种生命周期、重新播种触发条件与防护措施
• ${CLAUDE_PLUGIN_ROOT}/reference/self-space.md -- 身份生成规则，以及身份与配置的区别

验证：

• ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml -- 12 项不可妥协的原语
• ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh -- 核心验证脚本

---

何时重新播种

重新播种是一项重大操作。当增量修复已不足以解决问题时，应由 /architect 或 /health 建议重新播种：

• 维度不一致涉及超过 3 个维度 -- 级联错配过多，无法通过有针对性的修复解决
• 词汇不再符合用户的语言习惯 -- 系统使用的行话已不再适合用户
• 三空间边界已消解 -- 内容经常跨越 self/notes/ops 边界
• 模板偏差超过 40% -- 实际笔记架构已与模板大幅偏离
• MOC 层级已无法反映实际主题结构 -- 导航带来的阻碍多于帮助

如果以上触发条件均未出现，则应建议使用 /architect 进行有针对性的演化。

---

阶段 1：分析当前状态

自动执行。全面了解系统当前的实际状况。

1a. 阅读推导历史

阅读 ops/derivation.md，了解：

• 原始维度位置与置信度
• 推动各项选择的对话信号
• 个性维度
• 词汇映射
• init 阶段的一致性验证结果
• init 阶段标记的失败模式风险

阅读 ops/config.yaml，了解可能与推导结果不同的实时配置值。

1b. 清点系统

计数并编目：

# Notes (domain-named folder)
find notes/ -name "*.md" -not -name "index.md" | wc -l
# MOCs
grep -rl '^type: moc' notes/ | wc -l
# Templates
ls templates/*.md 2>/dev/null | wc -l
# Skills (platform-dependent)
ls .claude/skills/*/SKILL.md 2>/dev/null | wc -l
# Hooks
ls .claude/hooks/*.sh 2>/dev/null | wc -l
# Self space
ls self/*.md self/memory/*.md 2>/dev/null | wc -l
# Inbox
find inbox/ -name "*.md" 2>/dev/null | wc -l
# Ops
find ops/ -name "*.md" 2>/dev/null | wc -l

根据 derivation.md 中找到的领域词汇调整文件夹名称。

1c. 阅读健康状况历史

扫描 ops/health/ 中最近 3-5 份健康状况报告。追踪哪些问题反复出现（出现在多份报告中），哪些只出现过一次。

1d. 收集运营证据

阅读 ops/observations/，了解累积的摩擦模式、方法论经验和流程缺口。这些是重新推导最重要的信号，因为它们反映了真实的运营经验。

---

阶段 2：识别漂移

针对 8 个配置维度，测量当前状态与推导状态的差异。对漂移进行分类：

分类	含义	操作
none	当前状态与推导结果一致	确认——无需更改
aligned	状态有所变化，但随着系统发展方向合理	记录演进情况，更新推导结果以匹配现状
compensated	存在不匹配，但已有变通方案	评估是将补偿措施正式化，还是解决不匹配问题
incoherent	级联关系已断裂——该维度与其依赖维度冲突	必须在重新推导时解决
stagnant	根据系统成熟度本应演进，但实际没有	提议升级

各维度的漂移测量

粒度： 笔记实际上是原子级、中等还是粗粒度？检查笔记平均长度、每篇笔记中的声明数量和拆分频率。

组织： 文件夹结构是否仍然扁平？是否开始出现子文件夹？笔记归档是否一致？

链接： 实际链接密度是多少？关联仅通过显式链接建立，还是已启用语义搜索？检查反向链接数量。

处理： 实际处理强度如何？统计管道调用次数与直接创建笔记的次数。检查收件箱处理量。

导航深度： 实际存在多少层 MOC？从所有笔记到达中心枢纽所需的层数是否都在声明范围内？

维护： 上次触发条件是什么时候？阈值是否适合知识库当前状态？

模式： 有多少比例的笔记符合模板？实际使用了哪些字段，与声明的字段有何不同？

自动化： 当前有哪些钩子和技能处于启用状态？自动化水平是否与配置相符？

生成漂移报告

| Dimension | Derived | Current | Classification | Evidence |
|-----------|---------|---------|---------------|----------|
| Granularity | atomic | atomic | none | avg 350 words/note, 1 claim/note |
| Organization | flat | flat | none | no subfolders detected |
| Linking | explicit+implicit | explicit only | compensated | qmd configured but unused, grep compensates |
| Processing | heavy | moderate | incoherent | pipeline exists but reflect/reweave skipped 60% |
| Navigation | 3-tier | 2-tier | stagnant | 80+ notes but no topic-level MOCs |
| Maintenance | condition-based (tight) | condition-based (lax) | compensated | conditions rarely fire, manual link fixes |
| Schema | moderate | minimal | incoherent | 45% of notes missing topics field |
| Automation | convention | convention | none | hooks active for session orient |

---

阶段 3：重新推导

依据实际运行证据重新推导。这并不是从头开始，而是借助真实数据重新审视每个维度。

针对每个维度：

1. 阅读原始依据，查看 ops/derivation.md——为什么选择这一状态？
2. 考虑摩擦模式，参考阶段 1d——存在哪些运行层面的痛点？
3. 查询研究图谱——使用 mcp__qmd__deep_search 搜索与摩擦相关的声明。若不可用，则使用 mcp__qmd__vector_search。如果 MCP 不可用，使用 qmd CLI（先运行 qmd query，然后运行 qmd vsearch）。只有在 MCP 和 qmd CLI 均不可用时，才直接阅读随附的参考文件。
4. 阅读 dimension-claim-map.md，了解影响此维度的具体声明。
5. 提出新的状态或确认原状态——并明确说明理由。

对于每个维度，重新推导应回答：

• 原始状态是什么，为什么这样选择？
• 运行证据说明了什么？
• 研究对于这一具体摩擦有什么发现？
• 新的建议状态是什么？
• 如果状态发生变化，会产生哪些级联影响？（检查 interaction-constraints.md）

重新评估词汇

阅读 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md。将当前词汇映射与用户实际描述其系统时使用的措辞进行比较（依据会话日志、观察记录和笔记中面向用户的文本）。如果用户形成了不同于映射的专属词汇，则采用用户的术语。

重新评估个性

如果初始化时推导了个性，检查这些个性维度是否仍然适用。证据来源：self/identity.md、MOC 中的 Agent 笔记、会话日志语气。如果初始化时没有推导个性，则检查当前运行证据是否已足以支持推导。

---

阶段 4：检查一致性

应用 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md 中完整的一致性验证：

第 1 阶段：硬约束检查

对于每项硬约束，评估重新推导后的配置。如果违反约束，必须先调整重新推导结果，再继续操作。

硬约束：

• atomic + navigation_depth == "2-tier" + volume > 100——导航眩晕
• automation == "full" + no_platform_support——平台无法支持
• processing == "heavy" + automation == "manual" + no_pipeline_skills——不可持续

第 2 阶段：软约束检查

对于每项软约束，评估配置。记录当前生效的软约束及其补偿机制。

第 3 阶段：级联验证

沿每个变更维度的级联链进行追踪。验证下游维度是否：

• 与新位置一致，或
• 已明确覆盖，并记录了理由

第 4 阶段：三空间边界检查

使用 ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md，验证重新推导后的架构是否保持清晰的边界。检查六种混淆模式。

第 5 阶段：内核验证（15 项原语）

使用 ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md，验证重新推导后的系统能否通过全部 15 项内核原语。

---

第 5 阶段：呈现变更

向用户准确说明哪些内容发生了变化，哪些保持不变。

输出格式：

=== RESEED ANALYSIS ===
System: [domain name]
Platform: [detected]
Note count: [N]

--- Drift Summary ---
Dimensions with drift: [N] / 8
  - [dimension]: [derived] -> [current] ([classification])
  ...

--- Re-Derivation Proposal ---

| Dimension | Current | Proposed | Change? | Rationale |
|-----------|---------|----------|---------|-----------|
| [dim]     | [val]   | [val]    | [yes/no]| [reason]  |
| ...       | ...     | ...      | ...     | ...       |

--- Impact Assessment ---

For each proposed change:

### [Dimension]: [current] -> [proposed]

**Component modifications:**
- [specific file/folder/template changes]

**Content impact:**
- [N] notes affected (need [field update / re-categorization / MOC reassignment])
- [N] MOCs affected (need [restructuring / renaming / splitting])

**Risk:** [low / medium / high] -- [explanation]

**Rollback:** [specific rollback steps if this change doesn't work]

--- Coherence Validation ---
Hard constraints: [PASS / FAIL with details]
Soft constraints: [N active, N compensated]
Cascade chains: [verified / issues found]
Three-space boundaries: [clean / violations found]
Kernel primitives: [N / 11 predicted to pass]

=== END ANALYSIS ===

如果指定了 --analysis-only： 在此处停止。呈现分析结果并退出。

如果未指定 --analysis-only： 询问用户：“是否要继续重新推导？我会保留你的所有内容并重组架构。”

---

第 6 阶段：获批后实施

严格按顺序执行。每个步骤都依赖上一步成功完成。

步骤 1：归档当前推导结果

cp ops/derivation.md ops/derivation-$(date +%Y-%m-%d).md

步骤 2：重组文件夹

如果文件夹名称发生变化（词汇演进），请在保留内容的同时重命名：

git mv old-folder/ new-folder/

更新所有文件引用。

步骤 3：更新模板

修改 _schema 块，添加或移除字段，并更新枚举值。模板是架构的唯一事实来源。

步骤 4：更新上下文文件

重新生成受维度变更影响的章节。保留记录在 ops/user-overrides.md 中的用户自定义内容（如果该文件存在）。在全文应用词汇转换。

步骤 5：更新技能

如果技能词汇需要更新，请修改 .claude/skills/ 中的技能文件。

步骤 6：更新钩子

如果自动化级别发生变化，请添加或移除钩子。更新钩子路径，使其与任何重命名后的文件夹相匹配。

步骤 7：重组 MOC

如果导航深度发生变化：

• 创建新的 MOC 层级（例如，从 2 层迁移到 3 层时，创建主题级 MOC）
• 将笔记重新分配到各个 MOC
• 更新中心 MOC，使其链接到新结构
• 更新所有笔记的 Topics 页脚

步骤 8：更新 self/

完整保留 self/memory/。 切勿修改或删除记忆文件。

更新：

• self/identity.md——如果个性发生变化
• self/methodology.md——如果处理或维护方式发生变化
• self/goals.md——添加“重播种后的方向”作为活跃主题

步骤 9：重新生成 ops/derivation.md

编写新的推导记录，包含：

• 所有重新推导后的维度位置及其理由
• 为变更提供依据的运营证据
• 支持各项决策的研究主张
• 上次推导日期及变更内容
• 一致性验证结果

步骤 10：记录重播种

在 ops/sessions/ 中创建会话日志，记录重播种过程：变更内容、变更原因以及需要留意的事项。

---

第 7 阶段：验证

对重新推导后的系统运行完整验证套件。

内核验证（15 个原语）

如果 ${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh 可用，请运行；否则请手动检查每个原语：

1. markdown-yaml -- 所有笔记都包含有效的 YAML frontmatter
2. wiki-links -- 所有 wiki 链接均可解析
3. moc-hierarchy -- MOC 结构完好，所有笔记均可访问
4. tree-injection -- 会话启动时加载文件结构
5. description-field -- 描述均已填写，且与标题不同
6. topics-footer -- 所有非 MOC 笔记均包含主题
7. schema-enforcement -- 模板存在，且具备验证机制
8. semantic-search -- 已配置或已记录以供未来使用
9. self-space -- self/ 完整，且包含核心文件
10. session-rhythm -- 已记录 orient/work/persist
11. discovery-first -- 笔记已针对易查找性进行优化

一致性验证

• 可达性： 在指定层级深度内，每篇笔记都可从中心 MOC 访问
• 链接健康度： 重建未引入任何失效的 wiki 链接
• Schema 合规性： 所有笔记均通过模板验证
• 词汇一致性： 同一通用术语在各处映射到相同的领域术语
• 三空间边界： 未引入任何混淆模式

报告结果

=== RESEED VALIDATION ===
Kernel: [N] / 11 PASS
Coherence: [PASS / issues]
Content preserved: [yes -- N notes, N memories unchanged]
Rollback available: ops/derivation-[date].md

Post-reseed recommendations:
1. [First thing to check after a few sessions]
2. [Second monitoring item]
=== END VALIDATION ===

如果任何内核原语验证失败，请先修复，再完成重建。破坏内核原语的重建会让系统变得更糟，而不是更好。

---

质量标准

• 内容保留不容妥协。 每篇笔记、每条记忆、每项用户创建的内容都必须在重建后保留。请核对重建前后的数量。
• 每项维度变更都应以实际操作证据为依据，而非理论偏好
• 全程使用领域词汇——重建应让用户感到自然熟悉
• 如果用户的词汇自 init 以来有所演变，请采用其当前用语
• 承认不确定性：“此维度变更尚属推测——请留意 [specific friction]”
• 优先选择可逆变更，而非不可逆变更
• 将所有内容记录在 ops/derivation.md 中——下一次重建需要这些背景信息