在维护 Obsidian wiki…

当需要定期检查或清理 Obsidian 知识库、找出并修复结构性问题、或让 wiki 自愈时使用。

适用场景

解决思路

1. 扫描前遵循 `llm-wiki/SKILL.md` 的 Retrieval Primitives 表，优先使用 frontmatter-scoped greps 和 section-anchored reads，避免整页读取。
2. 在起草或改写自然语言 Markdown 前，阅读并应用 `llm-wiki/SKILL.md` 的 `Writing Profile Resolution`；框架 schema、provenance、安全、操作要求优先，`WRITING.md` 偏好只用于生成的 consolidation reports；确定性发现和修复保持原格式。
3. 解析配置：按 `llm-wiki/SKILL.md` 的 Config Resolution Protocol（inline `@name` override → 从 CWD 向上查找 `.env` → global config → prompt setup），获取 `OBSIDIAN_VAULT_PATH` 以及 `OBSIDIAN_ALLOWED_LIFECYCLES`、`OBSIDIAN_ALLOWED_RELATIONSHIP_TYPES`、`OBSIDIAN_REQUIRED_TRUST_FIELDS`、`OBSIDIAN_SCHEMA_SOURCE`。
4. 读取 owner rules：若 `$OBSIDIAN_VAULT_PATH/AGENTS.md` 存在，在解释任何 schema 前读取；owner rules 覆盖 framework defaults。
5. 形成 effective schema：记录 schema source locator、有效必需/可选 frontmatter、lifecycle 值、relationship types、provenance markers；framework 值是默认值；保留 owner extensions 和放宽的 requiredness；绝不把 owner type 强制转成 framework type。
6. 读取 `index.md` 获取完整页面清单。
7. 读取 `log.md` 获取最近活动上下文。
8. 显式把 effective schema 传给 deterministic checks：用 `--allow-lifecycle` / `--allow-relationship-type` 添加 owner extensions，用可重复的 `--required-trust-field` 替换 trust requiredness，用 `--schema-source "$OBSIDIAN_VAULT_PATH/AGENTS.md"` 标识 authority；JSON report 的 `schema` 块必须匹配已形成的 schema。
9. Schema 优先级：CLI flags > resolved environment/config values > framework defaults；lifecycle 和 relationship extensions 保持 additive；使用前去除所有 override；显式配置为空或仅空白、空逗号分隔列表项要 fail closed；不要当作有效 lifecycle、relationship type、required field 或 authority locator；要默认值就移除变量。
10. 所有检查跳过 `_archives/`、`_raw/`、`_readouts/` 和 `.obsidian/`；这些是冻结快照、未处理 staging drafts、派生 readouts，不是知识图谱页面。
11. 按顺序运行检查并边运行边报告发现。
12. 检查 1 Orphaned Pages：Glob vault 中所有 `.md` 文件；对每个页面 grep 其余 vault 中的 `[[page-name]]` 引用；除 `index.md` 和 `log.md` 外零入链页面为 orphan；修复时确定哪些现有页面应链接到 orphan，并在合适章节添加 wikilinks。
13. 检查 2 Broken Wikilinks：grep 所有页面的 `\[\[.*?\]\]`；提取 target 时丢弃第一个 `|` 后的别名或 `#` 后的 heading/block anchor，去掉表格内转义 `\|` 留下的尾部反斜杠；若 target 扩展名是附件类型（`.png`, `.jpg`, `.gif`, `.svg`, `.webp`, `.pdf`, `.canvas`, `.base`, 音频和视频）则跳过，视为 embed 而非 page link；不要把所有点视为扩展名，`[[Node.js]]`、`[[Next.js]]`、`[[v1.2 release notes]]` 是页面链接；去掉显式 `.md` 后缀后检查对应 `.md` 文件是否存在；修复：目标重命名则更新链接，目标应存在则创建，链接错误则删除或纠正。
14. 检查 3 Missing Frontmatter：每个页面应有 title, category, tags, sources, created, updated；用 grep 定位文件头 `^---` 的 frontmatter 块，不要整页读取；标记缺失必需字段；修复时用合理默认值添加缺失字段。
15. 检查 3a Missing Summary（软警告）：每个页面应有 `summary:` frontmatter，1-2 句、≤200 字符；grep `^summary:`；缺失标记为软警告而非错误；摘要超过 200 字符也标记；修复：重新 ingest 页面，或手动写 1-2 句摘要。
16. 检查 4 Stale Content：比较页面 `updated` 时间戳与来源文件修改时间；来源在页面最后更新之后被修改则标记。
17. 检查 5 Contradictions：读取相关页面并比较 claims，聚焦共享 tags 或大量交叉引用页面；查找 "however"、"in contrast"、"despite" 等短语以区分已承认与未承认矛盾；修复：添加 "Open Questions" 章节记录矛盾，引用双方来源和 claims。
18. 检查 6 Index Consistency：比较 `index.md` 中列出的页面与磁盘实际文件；检查 `index.md` 摘要仍匹配页面内容。
19. 检查 7 Provenance Drift：对每个有 `provenance:` 块或 `^[inferred]`/`^[ambiguous]` 标记的页面，统计句子/bullet 总数及以各标记结尾的数量；计算 extracted/inferred/ambiguous 粗略比例；阈值：AMBIGUOUS > 15% 标记 "speculation-heavy"；INFERRED > 40% 且 frontmatter 无 `sources:` 标记 "unsourced synthesis"；入链数 top 10 hub pages 且 INFERRED > 20% 标记 "high-traffic page with questionable provenance"；若有 `provenance:` frontmatter，任一字段与重算值差超过 0.20 标记 drift；无 `provenance:` 且无标记的页面跳过，按约定视为 fully extracted；修复：ambiguous-heavy 重新从来源 ingest、解决不确定 claims 或拆分 speculative content 到 `synthesis/`；unsourced synthesis 添加 `sources:` 或明确标为 synthesis；hub pages INFERRED >20% 优先重新 ingest；drift 更新 `provenance:` frontmatter 匹配重算值。
20. 检查 8 Fragmented Tag Clusters：对出现于 ≥5 页的每个 tag，令 `n`=该 tag 页面数，`actual_links`=该 tag 组内任意两页之间双向 wikilinks 数，`cohesion = actual_links / (n × (n−1) / 2)`；标记 cohesion < 0.15 且 n ≥ 5 的 tag group；修复：运行 `cross-linker` 技能针对碎片 tag 暴露并插入缺失链接；若 tag group 大（n > 15）且仍碎片化，考虑拆成更具体 sub-tags。
21. 检查 9 Visibility Tag Consistency：未标记 PII patterns：grep 页面正文中常见敏感模式（`password`, `api_key`, `secret`, `token`, `ssn`, `email:`, `phone:` 后接实际值而非字段描述）；若匹配且缺少 `visibility/pii` 或 `visibility/internal`，标记可能误分类；`visibility/pii` 无 `sources:`：标记任何缺 `sources:` 的 `visibility/pii` 页面，因为无 provenance 无法验证分类；taxonomy 中的 visibility tags：`visibility/` 标签是系统标签，不得出现在 `_meta/taxonomy.md`，若出现标记为 misconfigured；修复：对未标记 PII patterns 在 frontmatter tags 添加 `visibility/pii`（或团队上下文用 `visibility/internal`）；缺 `sources:` 则添加 provenance 或上报用户，不要自动填充；taxonomy 污染则从 `_meta/taxonomy.md` 删除 `visibility/` 条目。
22. 检查 10 Misc Promotion Candidates：Glob `$OBSIDIAN_VAULT_PATH/misc/*.md`；对每个页面读取 `affinity` frontmatter；标记任何单个 project 分数 ≥3 的页面；修复：若 affinity scores 看起来过期（例如有很多 wikilinks 的页面 `affinity: {}`），先运行 `cross-linker`；提升时把页面移动到 `projects/<project-name>/references/`（或其他合适 category），更新 `category` frontmatter，移除 `promotion_status`，grep vault 反向链接并更新。
23. 检查 12 Confidence and Lifecycle Schema：两种模式 `--check`（默认只读，报告 errors 和 warnings）和 `--consolidate`（可应用单独批准的结构维护，但绝不重写 `base_confidence`）；confidence 是语义判断，确定性工具不能仅从 source strings 推断 independent evidence lineages 或 whole-page claim coverage；confidence automation 只验证明确批准的手工 trust ledger，绝不用 URL 计数替代 review。
24. 规则 12a lifecycle enum validation：grep frontmatter `^lifecycle:`；标记超出 effective lifecycle set 的值（framework 默认 `{draft, reviewed, verified, disputed, archived}`）；修复 n/a，只有人类应设置 lifecycle state。
25. 规则 12b base_confidence range：grep frontmatter `^base_confidence:`；标记存在值超出 `[0.0, 1.0]`；仅当 effective owner schema 要求该字段时标记缺失；修复 n/a，错误值需人工纠正。
26. 规则 12c Stale page report（computed overlay）：staleness 从不存储，读取时计算 `is_stale = (today − updated) > 90 days`；对每个页面读 `updated:` 计算 `is_stale`；若 stale 再检查 `lifecycle:`；报告：stale 且 `lifecycle: verified` 用更响亮注释（最危险，高信任页面可能错误），其他 stale 页面标准警告；修复：`--fix` 不重写 `lifecycle`；重新 ingest 提升 `updated` 后 staleness 自动清除。
27. 规则 12c-2 Illegal lifecycle transitions：lifecycle enum 是状态机；`obsidian-wiki lint` 通过比较当前 `lifecycle` 与 `_meta/trust-ledger.json` 中上次 review 记录的值来报告 `illegal_lifecycle_transitions`；标记任何回退到 `draft`（只有 ingest 设置 draft）和任何退出 `archived`（终态，恢复需人类刻意删除再重建）；不标记 `draft → verified`，因为 ledger snapshots 稀疏，中间可能有合法 `reviewed`；默认 warn，`--strict-trust` 下 fail；ledger entry 早于 `lifecycle` 字段的页面无 baseline，静默跳过；修复 n/a，上报人类解决。
28. 规则 12d Supersession integrity：对每个有 `superseded_by: "[[target]]"` 的页面：验证 target 页面存在；验证 target 页面不是 archived（无循环或链式 supersession）；验证无 cycles（A supersedes B，B supersedes A）；若 `lifecycle != archived` 而设置 `superseded_by` 则 warn 状态不一致；修复 n/a，标记人工解决。
29. 规则 12e Confidence review integrity：先运行确定性 ledger validator `obsidian-wiki trust-check "$OBSIDIAN_VAULT_PATH" --strict --json --pretty`；CI 和 scheduled gates 用 `--strict`，stale、unreviewed 或 missing-page warnings 返回非零；无 `--strict` 时 `trust-check` 是只读报告，仅硬 ledger 错误或 score mismatches 返回非零；批准的 ledger 位于 `_meta/trust-ledger.json`，每项记录人工 review 分数加材料页面内容和证据元数据的 SHA-256 指纹；指纹排除易变 bookkeeping（`updated`、`base_confidence`、lifecycle transition fields），所以仅时间戳编辑不会重开 review；解释结果：`reviewed` 当前材料指纹和存储分数都匹配批准 review，不要从 source strings 重算；`stale` 正文、summary、sources、provenance、tags 或 relationships 变了，需新人工 lineage + claim-coverage review；`unreviewed` 无批准 ledger entry，需人工 review；`score_mismatches` 材料内容仍匹配但存储 `base_confidence` 与批准值不同，lint 失败；`errors` ledger 数据格式错误/缺失，lint 失败。
30. 对单独批准的 full-vault review 记录接受状态：运行 `obsidian-wiki trust-record "$OBSIDIAN_VAULT_PATH" --all --reviewed-at "<ISO-8601 timestamp>" --approved --json --pretty`；对仅特定 stale/unreviewed 页面的单独批准 review，只更新那些条目：`obsidian-wiki trust-record "$OBSIDIAN_VAULT_PATH" --page "concepts/example.md" --page "skills/example.md" --reviewed-at "<ISO-8601 timestamp>" --approved --json --pretty`；`--approved` 表示人类批准每个记录的分数，是工作流断言不是加密签名；把 `_meta/trust-ledger.json` 置于版本控制并要求人工 diff review 后合并；`--all` 仅在 full-vault review 后有效，部分 review 用可重复 `--page`，让无关 stale 页面保持 open；绝不为了消除警告运行 `trust-record`。
31. 对 stale/unreviewed 页面的人工重算协议：1) 把页面分解为 material claims 并将每个 claim 映射到 evidence；2) 把 dependent evidence 折叠为 independent lineages：同一 repository 的 files/commits、同一 task chain 的 retries、snapshots 加其 captured source、duplicate memories、parent/child tasks 各算一次；3) 按 `llm-wiki` buckets 给每个 independent lineage 分配 reviewed quality；4) 计算 raw base score，再评估 whole-page claim coverage，公式是起点不是自动目标；5) 将结果分类为 `raise`、`keep`、`lower` 或 `repair first`；改变 `base_confidence` 或刷新 ledger 前要求批准。
32. Confidence review 修复：没有自动 confidence 修复；只应用明确批准的确切 patch，验证其范围，然后只刷新已 review 的 ledger state；`--consolidate` 绝不重写 `base_confidence`。
33. Current enforcement：framework 默认下每个非保留内容页必须含 `[0.0, 1.0]` 内的有限 `base_confidence` 和有文档的 lifecycle 值；owner schema 可放宽任一字段，出现值仍被验证；缺失/格式错误 trust fields、格式错误 ledger 数据、缺少必需 ledger 是 hard errors；有新页面有有效 trust fields 但无批准 ledger entry 是 `unreviewed`；已批准页面材料变更后是 `stale`。
34. 在 Wiki Health Report 中添加 `### Confidence/Lifecycle Issues (N found)`，列出缺失 `lifecycle`、无效 enum、`base_confidence` 超出范围、STALE 且 lifecycle=verified 高优先级、STALE 且 lifecycle=draft、`superseded_by` 但 lifecycle 不符、confidence review stale、confidence mismatch 等问题；追加 `LINT` log：`- [TIMESTAMP] LINT ... lifecycle_issues=N`。
35. 检查 13 Typed Relationships Validity：跳过无 `relationships:` block 的页面；framework 默认 types：`extends`, `implements`, `contradicts`, `derived_from`, `uses`, `replaces`, `related_to`；应用 owner extensions 后对 effective set 验证；grep frontmatter `^relationships:`；对每个有 block 的页面只读 frontmatter；对每个 entry：类型验证，标记 `type:` 不在允许集合；broken target：从 `target:` 去掉 `[[`/`]]`，正常化（lowercase、spaces→hyphens、strip `.md`），检查 vault 中是否存在该路径 `.md`，标记未解析 target；正常化前丢弃第一个 `|` 或 `#` 后内容，因为别名或 heading anchor 不应仅因字面 bracket 内容不匹配文件名而 broken；self-reference：解析 target 等于页面自身 node id 则标记；修复：无效类型报告值和 effective schema source，仅当框架默认和 owner extensions 都缺失时纠正，绝不用 `related_to` 替换有效 owner type；broken target 更新或移除 entry，若 target 应存在先创建；self-reference 移除 entry。
36. 添加 `### Typed Relationship Issues (N found)` 输出，例如 `concepts/foo.md — relationships[1]: type "contradication" is not an allowed type (did you mean "contradicts"?)`；追加 log `relationship_issues=N`。
37. 检查 14 Event-Time Validity：验证 `valid_from` / `valid_until` / `superseded_by`；三者可选，若都无则跳过；`created`/`updated` 是 ingestion time，这三个是 event time，claim 本身为真时；`valid_until` 已过表示 historical 而非错误，页面仍留在 vault 和图谱，只从默认 retrieval 消失；grep frontmatter `^valid_from:`、`^valid_until:`、`^superseded_by:`；对每个有任一字段的页面：日期可解析性，值必须是 `YYYY-MM-DD` 或完整 ISO 8601 timestamp，否则标记；窗口顺序，`valid_until` 在 `valid_from` 前标记；dangling successor：从 `superseded_by` 去 `[[`/`]]`，丢弃第一个 `|` 或 `#` 后内容，strip `.md`，正常化，检查页面存在，标记未解析 target 和 self-references；`obsidian-wiki lint` 将 date/window 报告为 `temporal_errors`，successor 报告为 `superseded_dangling`；带括号的 dangling successor 也会出现在 `broken_links`；日期失败而非警告，因为 retrieval 把无法解析窗口视为 current，未报告 typo 会让 stale claim 作为事实回答；修复：无法解析日期改写为 `YYYY-MM-DD`，真实日期未知则移除字段而非猜测；倒置窗口与来源确认哪个日期错，绝不静默交换；dangling successor 创建 replacement 页面、纠正指针或若没有替代则移除；绝不通过把 historical 页面改写为 current 来“修复”，那会破坏 window 要保留的记录。
38. 添加 `### Event-Time Issues (N found)` 输出，例如 `references/gateway-nginx.md — valid_until (2026-04-01) precedes valid_from (2026-05-01)`；追加 log `temporal_issues=N`。
39. 检查 11 Synthesis Gaps：列出 `synthesis/` 所有页面，收集每个已覆盖的 concept pairs（来自其 `[[wikilinks]]` 或 title）；从 `concepts/` 和 `entities/` 选 10-15 个频繁链接概念；对每对运行快速 grep 统计链接到两者的页面数，命令：`rg -l --glob '*.md' "\[\[ConceptA\]\]" "$OBSIDIAN_VAULT_PATH" > /tmp/a.txt`，`rg -l --glob '*.md' "\[\[ConceptB\]\]" "$OBSIDIAN_VAULT_PATH" > /tmp/b.txt`，`comm -12 <(sort /tmp/a.txt) <(sort /tmp/b.txt) | wc -l`；标记 co-occurrence ≥3 且无现有 synthesis page 的 pair；修复：运行 `/wiki-synthesize` 自动发现并填充 top gaps。
40. 输出 Wiki Health Report 结构化列表，包含各章节：Orphaned Pages、Broken Wikilinks、Missing Frontmatter、Stale Content、Contradictions、Index Issues、Missing Summary (soft)、Provenance Issues、Fragmented Tag Clusters、Visibility Issues、Misc Promotion Candidates、Typed Relationship Issues、Synthesis Gaps 等。
41. Lint 后追加 `log.md`：`- [TIMESTAMP] LINT issues_found=N orphans=X broken_links=Y stale=Z contradictions=W prov_issues=P missing_summary=S fragmented_clusters=F visibility_issues=V promotion_candidates=C synthesis_gaps=G relationship_issues=R`；提供自动修复或让用户选择要处理的问题。
42. Consolidate 模式 `wiki-lint --consolidate`：从 report-only 切换到 act-and-report，即定期运行的 "dream cycle"，让 wiki 自愈。
43. Consolidate 安全协议：先干跑；写任何东西前运行所有 12 个 lint checks（上面 Step 1–12）；打印计划 consolidation actions 的结构化列表；询问用户 `"Apply these N changes? [yes / no / select]"`；仅在明确确认后写入；若用户选择单个 action，只应用那些；绝不合并页面，合并用 `wiki-dedup`；只链接、提升、降级和标记。
44. Consolidate actions 按顺序，在确认后：Pre-write snapshot——第一次文件写入前，检查 vault 本身是否为 Git repository root；仅作为更大 repository 的子目录不算，因为 `git add -A` 可能捕获无关文件；若 vault 不是独立 Git repository，静默跳过，不 nagging，不建议 `git init`。命令：`VAULT_REAL_PATH=$(cd "$OBSIDIAN_VAULT_PATH" && pwd -P)`；`VAULT_GIT_ROOT=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse --show-toplevel 2>/dev/null || true)`；`SNAPSHOT_SHA=""`；若 `[ -n "$VAULT_GIT_ROOT" ] && [ "$VAULT_GIT_ROOT" = "$VAULT_REAL_PATH" ]`，若 `git -C "$OBSIDIAN_VAULT_PATH" diff --quiet` 且 `git -C "$OBSIDIAN_VAULT_PATH" diff --cached --quiet` 且 `[ -z "$(git -C "$OBSIDIAN_VAULT_PATH" ls-files --others --exclude-standard)" ]`，则 `SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD)`；否则 `git -C "$OBSIDIAN_VAULT_PATH" add -A`，失败则输出错误并 exit 1 不写 vault 文件；`git -C "$OBSIDIAN_VAULT_PATH" commit -m "pre-wiki-lint snapshot" --quiet`，失败同样 abort；`SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD)`；clean-repository 分支避免调用 `git commit`，所以 "nothing to commit" 不是错误；若 `git add` 或 `git commit` 失败，编辑 vault 前停止；绝不在没有承诺 snapshot 时继续；若 `SNAPSHOT_SHA` 非空且技能写文件，最终报告包含 SHA；要丢弃整个 run，确认无后续要保留变更后运行 `git -C "$OBSIDIAN_VAULT_PATH" reset --hard "$SNAPSHOT_SHA"` 和 `git -C "$OBSIDIAN_VAULT_PATH" clean -fd`。
45. Action 1 Fix broken wikilinks：对 Check 2 每个 broken `[[Target]]`，在 vault 中搜索标题或文件名最接近的 fuzzy match（用 `Grep` 扫 `index.md` titles）；若唯一最佳匹配存在（edit distance ≤2 字符或同词根），重写链接，记录 `[[Oringal]] → [[corrected-page]]`；若无匹配或歧义，转为纯文本（`~~[[Target]]~~` → `Target`）并添加注释 `<!-- broken link: no match found -->`；绝不为满足 broken link 创建新页面。
46. Action 2 Add missing cross-references for orphans：对 Check 1 每个 orphan（零入链），grep vault 正文中页面 title 或 aliases 的提及（不区分大小写）；对另一个页面中每个提及，添加 `[[wikilink]]` 替换纯文本提及；每个 orphan 最多 3 次插入，不要淹没页面；仅限 orphans，区别于 `cross-linker` 的广泛运行。
47. Action 3 Correct lifecycle states：自动应用规则：Promote `draft` → `reviewed`：页面满足 `lifecycle: draft` 且 `created` > 30 天前且 `base_confidence > 0.7`，设 `lifecycle: reviewed`、`lifecycle_changed: <today>`、`lifecycle_reason: "auto-promoted by wiki-lint --consolidate: age>30d, confidence>0.7"`；Demote `verified` → `stale`：不是状态转换——`stale` 是 computed overlay 不是 lifecycle 值；改为对 verified 页面 `is_stale = (today − updated) > 180 days`，在页面正文顶部添加 callout `> ⚠️ **Stale**: This page was last updated <date>. Verify before relying on it.`，仅在 callout 不存在时添加；不要改变 `reviewed` → `verified` 或任何其他转换，那些是 human-only。
48. Action 4 Tier demotion：对 `tier: supporting`（或未设置）且 0 入链且 90+ 天未更新的页面，设 `tier: peripheral`；输出 demotions 列表供用户 review；不要自动降级 `tier: core` 页面，那些是手工设置的。
49. Action 5 Tag normalization：读取 `_meta/taxonomy.md` 的 alias mapping（例如 `ml → machine-learning`）；对每个页面，在 `tags:` frontmatter 字段中把已知 alias tags 替换为 canonical form；这是 `tag-taxonomy` 工作的子集——只修 alias，不做完整审计。
50. Action 6 Contradiction callouts：对每对标记互相矛盾的页面（通过 frontmatter `relationships: contradicts` 或 Check 5 标记），检查相关 claim 附近是否已有 `> ⚠️ Contradiction flagged with [[Other Page]]` callout；若没有，在 "Key Ideas" 章节末尾（若无 "Key Ideas" 则在 "Open Questions" 之前）添加，保持简洁一行；不要解决矛盾，只视觉标记。
51. Action 7 Write consolidation report：所有 actions 后写报告到 `synthesis/consolidation-<YYYY-MM-DD>.md`，frontmatter 包含 `title`、`category: synthesis`、`tags: [maintenance, consolidation]`、`sources: []`、`summary`、`lifecycle: draft`、`lifecycle_changed`、`tier: peripheral`、`created`、`updated`；正文包含 Summary（Broken links fixed、Cross-references added、Lifecycle states updated、Tier demotions、Tags normalized、Contradiction callouts added）及各节 Broken Link Fixes、Cross-References Added、Lifecycle Updates、Tier Demotions、Tag Normalizations、Contradiction Callouts。
52. Dry-Run Output 在写前显示：`wiki-lint --consolidate — Dry Run`；`Planned actions (N total):`；编号列出计划动作，例如 `[1] Fix broken link: concepts/foo.md:12 [[OldTarget]] → [[correct-target]]`，`[2] Add cross-ref: concepts/baz.md ← [[concepts/alpha]] (orphan rescue)`，`[3] Lifecycle: concepts/old-draft.md → reviewed (age 45d, confidence 0.74)`，`[4] Tier demotion: concepts/unused.md → peripheral (0 links, 112 days stale)`，`[5] Tag alias: entities/some-tool.md: ml → machine-learning`，`[6] Contradiction callout: concepts/scaling.md ↔ [[synthesis/efficiency]]`；询问 `Apply these 6 changes? [yes / no / select by number]`。
53. Consolidate log entry：`- [TIMESTAMP] LINT_CONSOLIDATE links_fixed=N orphans_rescued=M lifecycle_updates=K tier_demotions=D tag_fixes=T contradiction_callouts=C report=synthesis/consolidation-YYYY-MM-DD.md`。
54. QMD Refresh After Vault Writes：QMD 是搜索索引不是事实源；若 `$QMD_WIKI_COLLECTION` 为空或未设置，跳过；只在本技能写入或重写 vault markdown 后运行；若 QMD refresh 失败，不要 rollback vault 变更，单独报告 QMD 状态；使用 `$QMD_CLI`（若设置）否则 `qmd`；运行 `${QMD_CLI:-qmd} update`；若输出说需要 vectors 或 embeddings 可能 stale，运行 `${QMD_CLI:-qmd} embed`；用 `${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"` 或已知页面路径时 `${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5` 验证 collection；记录之一：`QMD refreshed: update + embed + verified`、`QMD refreshed: update only + verified`、`QMD skipped: QMD_WIKI_COLLECTION unset`、`QMD skipped: qmd CLI unavailable`、`QMD failed: <short error summary>`。

适用边界 · 注意事项

• 没有 Obsidian wiki 或未配置 `OBSIDIAN_VAULT_PATH`、`llm-wiki` 框架与相关 schema 时不要使用。
• 不要用本技能合并页面；合并应使用 `wiki-dedup`。
• 在无法提供干跑预览和用户明确确认写操作时，不要运行 `--consolidate` 写模式。