---
name: mywiki-refactor
description: "重构 myWiki 节点——拆分过载节点、合并重复节点、重路由所有引用。"
---

# myWiki 重构

用户已确认一次结构性变更（通常是 lint 提议的拆分或合并）。这是 wiki 中最具破坏性的操作之一，必须控制变更范围。

## 前提

**没有用户明确确认，绝不执行。** 用户必须已批准具体方案（拆哪个节点、子节点是什么，或合并到哪个节点）。

---

## 拆分流程

### 1. 读取目标节点
解析其 frontmatter、正文、所有入链和出链。

### 2. 设计拆分方案
识别彼此独立的子主题，每个成为一个新节点。如果用户没有具体指定方案，先提出建议并等待确认。

### 3. 创建子节点
对每个子节点：
- 新文件：`<wiki>/nodes/<child-id>.md`
- frontmatter 包含 `derived_from: [<parent-id>]`
- 正文：从原节点中提取相关内容，**重新组织而非机械切割**
- 继承原节点中适用的 relations
- status 设为 `growing`

### 4. 归档父节点
- status 改为 `archived`
- 设置 `splits_into: [<child-id-1>, <child-id-2>, ...]`
- 正文替换为：
```markdown
> 本节点已拆分。

- [[child-id-1]] — 描述
- [[child-id-2]] — 描述
```

### 5. 重路由引用（关键步骤）

找出**所有** `relations[].to` 指向父节点的其他节点。对每个：
- 判断应指向哪个子节点
- 更新该 relation 的 `to` 字段
- 更新正文中的 `[[parent-id]]` wikilink

**这是最关键的一步。** 漏掉一个重路由就会产生断链或把旧结构残留在图里。

验证方式：完成后扫描全量 `nodes/` 目录，搜索 parent-id。除了演化痕迹、归档说明和日志外，不应再有业务正文引用旧节点。

### 6. 更新索引和日志
- 更新 `<wiki>/meta/index.md`：移除父节点条目，添加子节点条目
- 追加 `<wiki>/meta/log.md`：
```markdown
## [YYYY-MM-DD] refactor | split <parent-id> → [child-id-1, child-id-2]
- 重路由 N 条引用
```

### 7. 最小改动检查

- 只改本次重构涉及的节点、索引和日志。
- 不顺手修改无关节点的措辞、状态或关系。
- 如果一个节点在本次重构中没有直接受影响，不要碰它。

### 8. 向用户汇报
- 拆分了什么、为什么
- 新建的节点列表
- 重路由了多少引用
- 有无模糊的重路由（建议用户验证）

---

## 合并流程

偶尔两个节点覆盖相同内容。合并步骤：

1. 选择质量更高的节点作为存活者（survivor）
2. 将被吸收节点的独有内容融入 survivor
3. 被吸收节点：status 设为 `archived`，正文改为 `> 已合并到 [[survivor-id]]`
4. 重路由所有指向被吸收节点的引用 → survivor
5. 日志记录：`refactor | merge <absorbed-id> → <survivor-id>`

合并时也遵守最小改动原则：只吸收差异内容，不借机大改 survivor 的其他部分。

---

## 规则

- ❌ **没有用户确认绝不执行**——只提议，等确认
- ❌ 不丢失内容——父节点正文的每一部分都必须出现在某个子节点中，或经用户同意丢弃
- ❌ 不留悬空引用——完成后全量验证
- ❌ 不大面积重写 survivor 或邻居节点
- ✅ 保持 `derived_from` / `splits_into` 链完整——这是演化历史
- ✅ 重路由后做全量搜索，确认除演化痕迹、归档说明和日志外无旧业务引用残留
