name: refactor description: 计划从配置更改中重构保险库。比较config.yaml与derivation.md，识别维度变化，展示重构计划，经批准后执行。触发于"/refactor"，“restructure vault”。 version: “1.0” generated_from: “arscontexta-v1.6” user-invocable: true context: fork allowed-tools: Read, Write, Edit, Grep, Glob, Bash, argument-hint: “[dimension|–dry-run] — 专注于特定维度或预览而不经批准提示”
运行时配置（步骤0 — 在任何处理之前）
读取这些文件以配置特定领域的操作：
-
ops/derivation-manifest.md— 词汇映射，维度位置，平台提示- 使用
vocabulary.notes作为笔记文件夹名称 - 使用
vocabulary.note/vocabulary.note_plural作为笔记类型引用 - 使用
vocabulary.topic_map/vocabulary.topic_map_plural作为MOC引用 - 使用
vocabulary.inbox作为收件箱文件夹名称
- 使用
-
ops/config.yaml— 当前实时配置（“之后”状态） -
ops/derivation.md— 原始派生记录（“之前”状态）
如果这些文件不存在，报告错误：“无法在没有ops/config.yaml和ops/derivation.md的情况下重构。这些文件建立了基线和当前配置。”
立即执行
不变式：/refactor从未未经批准执行。 计划总是首先显示。
目标：$ARGUMENTS
立即解析：
- 如果目标为空：检测所有配置更改并计划重构
- 如果目标指定特定维度（例如，“granularity”，“organization”）：仅关注该维度
- 如果目标是
--dry-run：显示计划而不请求批准
执行这些阶段：
- 检测config.yaml和derivation.md之间的更改
- 为每个变化的维度计划重构
- 显示带有受影响工件和风险评估的计划
- 经批准后执行（除非–dry-run）
- 验证重构后
现在开始。 以下参考定义了工作流程。
哲学
配置更改级联。
更改维度不仅仅是在config.yaml中编辑一个值。每个维度影响多个工件 — 技能，模板，上下文文件部分，钩子，MOC结构。将组织从“flat”更改为“hierarchical”意味着重构笔记目录，更新MOC模板，调整上下文文件中的导航引用，并重新生成引用文件夹结构的技能。
/refactor使这些级联可见并管理它们。没有它，维度更改会造成漂移：配置说一件事，工件说另一件事。有了它，每个更改都是计划的，批准的和验证的。
与/architect的关系： /architect推荐更改。/refactor实施它们。/architect分析健康和摩擦以提出维度变化。当这些建议被批准时，/refactor确保每个受影响的工件都一致更新。
阶段1：检测变化
比较ops/config.yaml中的每个维度与ops/derivation.md中相同维度：
步骤1：读取两个文件
完全读取ops/config.yaml和ops/derivation.md。从两者中提取每个8个维度的位置。
步骤2：构建比较表
| 维度 | 派生值 | 配置值 | 变化？ | 漂移类型 |
|---|---|---|---|---|
| granularity | [val] | [val] | [yes/no] | [aligned/misaligned] |
| organization | [val] | [val] | [yes/no] | [aligned/misaligned] |
| linking | [val] | [val] | [yes/no] | [aligned/misaligned] |
| processing | [val] | [val] | [yes/no] | [aligned/misaligned] |
| navigation | [val] | [val] | [yes/no] | [aligned/misaligned] |
| maintenance | [val] | [val] | [yes/no] | [aligned/misaligned] |
| schema | [val] | [val] | [yes/no] | [aligned/misaligned] |
| automation | [val] | [val] | [yes/no] | [aligned/misaligned] |
步骤3：检查特性标志
还在派生和配置之间比较特性标志：
| 功能 | 派生 | 配置 | 变化？ |
|---|---|---|---|
| semantic_search | [on/off] | [on/off] | [yes/no] |
| processing_pipeline | [on/off] | [on/off] | [yes/no] |
| self_space | [on/off] | [on/off] | [yes/no] |
| session_capture | [on/off] | [on/off] | [yes/no] |
| parallel_workers | [on/off] | [on/off] | [yes/no] |
步骤4：如果没有变化则提前退出
如果没有检测到变化：
--=={ refactor }==--
未检测到config.yaml和derivation.md之间的配置漂移。
所有维度和功能与原始派生匹配。
如果你想探索更改，运行/architect以获得建议
或直接编辑ops/config.yaml，然后再次运行/refactor。
阶段2：计划重构
对于每个变化的维度，确定所有受影响的工件。这是级联分析。
维度到工件映射
| 变化 | 受影响工件 | 变化内容 |
|---|---|---|
| 粒度变化 | 笔记模板，/reduce中的提取深度，处理技能，上下文文件"笔记设计"部分 | 模板正文长度指导，提取粒度设置，可组合性测试阈值 |
…（此处省略部分内容以保持简洁）