wiki-status

Wiki 状态 — 审计与增量

你正在计算 Wiki 的当前状态：已摄取哪些内容、上次摄取后有哪些新增内容，以及增量的具体情况。这有助于用户决定是追加（摄取增量）还是重建（归档并重新处理全部内容）。

开始之前

写作规范： 起草或改写自然语言 Markdown 之前，请阅读并遵循 llm-wiki/SKILL.md 中的 Writing Profile Resolution 部分。框架架构、来源溯源、安全和针对具体操作的要求优先级更高。 WRITING.md 中的偏好仅适用于生成的 _insights.md 文本；分析器快照须保持原样。

1. 解析配置 — 按照 llm-wiki/SKILL.md 中的 Config Resolution Protocol 操作（内联 @name 覆盖 → 从 CWD 向上查找 .env → 全局配置 → 提示设置）。由此获取 OBSIDIAN_VAULT_PATH、OBSIDIAN_SOURCES_DIR、CLAUDE_HISTORY_PATH 和 CODEX_HISTORY_PATH。
2. 读取 Vault 根目录中的 .manifest.json — 这是摄取跟踪台账

清单

清单位于 $OBSIDIAN_VAULT_PATH/.manifest.json。它会跟踪已摄取的每个源文件。如果文件不存在，则这是一个尚未摄取任何内容的全新 Vault。

来源键可移植 — 绝不能使用裸绝对路径。 规范键为：Vault 内来源使用相对于 Vault 的路径（Raw/database/x.pdf）；$HOME 下的来源使用相对于 ~ 的路径（~/.claude/projects/.../abc.jsonl）；没有可移植路径形式的来源使用伪键（repo:/url:/agent:）。绝不要混用形式 — 同一文件会被跟踪两次并重复摄取。请参阅 llm-wiki/SKILL.md → .manifest.json（Source key contract v2）。使用 scripts/manifest.py migrate <vault> 转换旧版绝对路径键清单。

{
  "version": 1,
  "last_updated": "2026-04-06T10:30:00Z",
  "sources": {
    "Raw/papers/attention.pdf": {
      "ingested_at": "2026-04-06T10:30:00Z",
      "size_bytes": 4523,
      "modified_at": "2026-04-05T08:00:00Z",
      "source_type": "document",
      "project": null,
      "pages_created": ["concepts/transformers.md"],
      "pages_updated": ["entities/vaswani.md"]
    },
    "~/.claude/projects/-Users-name-my-app/abc123.jsonl": {
      "ingested_at": "2026-04-06T11:00:00Z",
      "size_bytes": 128000,
      "modified_at": "2026-04-06T09:00:00Z",
      "source_type": "claude_conversation",
      "project": "my-app",
      "pages_created": ["entities/my-app.md"],
      "pages_updated": ["skills/react-debugging.md"]
    }
  },
  "projects": {
    "my-app": {
      "source_repo": "github.com/owner/my-app",
      "source_cwd_hint": "~/.claude/projects/-Users-name-my-app",
      "vault_path": "projects/my-app",
      "last_ingested": "2026-04-06T11:00:00Z",
      "conversations_ingested": 5,
      "conversations_total": 8,
      "memory_files_ingested": 3
    }
  },
  "stats": {
    "total_sources_ingested": 42,
    "total_pages": 87,
    "total_projects": 6,
    "last_full_rebuild": null
  }
}

步骤 1：扫描当前来源

建立当前所有可供摄取内容的清单：

文档（来自 OBSIDIAN_SOURCES_DIR）

Glob each directory in OBSIDIAN_SOURCES_DIR for all text files
Record: path, size, modification time

Claude 历史记录（来自 CLAUDE_HISTORY_PATH）

Glob: ~/.claude/projects/*/          → project directories
Glob: ~/.claude/projects/*/*.jsonl   → conversation files
Glob: ~/.claude/projects/*/memory/*.md → memory files
Record: path, size, modification time, parent project

Codex 历史记录（来自 CODEX_HISTORY_PATH）

Glob: ~/.codex/session_index.jsonl            → session inventory index
Glob: ~/.codex/sessions/**/rollout-*.jsonl    → session rollout transcripts
Glob: ~/.codex/history.jsonl                  → optional local history log
Glob: ~/.codex/archived_sessions/**/rollout-*.jsonl → archived rollouts (if user wants archive coverage)
Record: path, size, modification time, inferred project from cwd when available

用户此前指定的其他来源

检查清单中是否包含标准目录之外的来源路径。

步骤 2：计算增量

将当前来源与清单进行比较。对每个源文件分类：

状态	含义	所需操作
新增	文件存在于磁盘上，但不在清单中	需要摄取
已修改	文件在清单中，但哈希与 content_hash 不同	需要重新摄取
已触及	文件在清单中，修改时间更新但哈希未变	跳过 — 内容相同，无需重新摄取
未更改	文件在清单中，修改时间和哈希均匹配	无需处理
已删除	清单中的 Vault 本地来源，但文件已不在磁盘上	记录 — Wiki 页面可能已过时
不可用	机器本地来源（相对于 home 的路径或绝对路径键）在当前机器上不存在 — 例如从另一台主机同步而来的条目	跳过 — 不要报告为已删除，也不要清理；该来源可能存在于摄取它的机器上

如果清单条目没有 content_hash（旧条目），则仅使用修改时间进行比较。

对于 Claude 历史记录，还要计算：

• 新项目（~/.claude/projects/ 中不在清单里的目录）
• 现有项目中的新对话
• 已更新的记忆文件

对于 Codex 历史记录，还要计算：

• sessions/** 下新增的 rollout 文件
• 已更新的 session_index.jsonl 条目（会话标题／新旧程度变化）
• 仅在请求涵盖归档时，计算已归档 rollout 的增量

第 3 步：报告状态

可见性统计（生成报告前）： 使用 Grep 检查知识库中所有 .md 页面里的 frontmatter，查找 visibility/internal 和 visibility/pii 标签值。统计：

• public = 带有 visibility/public 标签的页面，或完全没有 visibility/ 标签的页面
• internal = 带有 visibility/internal 标签的页面
• pii = 带有 visibility/pii 标签的页面

在 Overview 部分加入 Page visibility: N public · M internal · K pii。如果所有页面都没有标签（知识库完全公开），则省略此行。

提供清晰的摘要：

# Wiki Status

## Overview
- **Total wiki pages:** 87 across 6 categories
- **Page visibility:** 72 public · 11 internal · 4 pii
- **Total sources ingested:** 42
- **Projects tracked:** 6
- **Last ingest:** 2026-04-06T11:00:00Z
- **Staged writes pending:** 4 pages · 2 patches (oldest: 3 days ago)  ← only when WIKI_STAGED_WRITES=true

## Delta (what's changed since last ingest)

### New sources (never ingested): 12
| Source | Type | Size |
|---|---|---|
| ~/Documents/research/new-paper.pdf | document | 2.1 MB |
| ~/.claude/projects/-Users-.../session-xyz.jsonl | claude_conversation | 340 KB |
| ~/.codex/sessions/2026/04/12/rollout-...jsonl | codex_rollout | 220 KB |
| ... | | |

### Modified sources (need re-ingesting): 3
| Source | Last ingested | Last modified | Delta |
|---|---|---|---|
| ~/notes/architecture.md | 2026-04-01 | 2026-04-05 | 4 days newer |
| ... | | | |

### New projects (not yet in wiki): 2
- **tractorex** (3 conversations, 2 memory files)
- **papertech** (1 conversation, 0 memory files)

### Deleted sources (ingested but gone): 0

## Summary
- **Ready to ingest:** 12 new + 3 modified = 15 sources
- **Up to date:** 27 sources unchanged
- **Recommendation:** Append (delta is small relative to total)

## Token Footprint (estimated)

| Scope | Pages | ~Tokens |
|---|---|---|
| core tier | 12 | 18,400 |
| supporting tier | 87 | 94,200 |
| peripheral tier | 43 | 31,600 |
| **Full wiki (all)** | **142** | **144,200** |

Index-only pass (frontmatter + summaries): ~8,900 tokens
Typical query (index + 5 full pages):      ~14,200 tokens

⚠️  Full wiki exceeds 100K tokens. Consider:
  - Demoting peripheral pages (promote tier suggestions from wiki-status insights mode)
  - Running /wiki-lint --consolidate to merge near-duplicates
  - Using wiki-query fast mode for most queries

第 3b 步：计算 Token 占用量

生成状态摘要后，计算 Token 占用量估算：

1. 按层级统计页面大小 — 遍历所有 .md 页面。读取每个页面 frontmatter 中的 tier: 字段（使用廉价的 grep）。按层级值分组页面（core、supporting、peripheral；未设置时 → supporting）。

2. 估算 Token 数 — 将每个页面的 Token 数估算为 file_size_bytes / 4（按 4 个字符/token 的启发式估算，无需实际 Tokenizer）。按层级和总体求和。

3. 仅索引估算 — 估算仅索引扫描的成本：对每个页面，将 frontmatter 中的 len(title) + len(summary) + len(tags) 求和（平均每页约 100 个字符），再除以 4。

4. 典型查询估算 — 仅索引估算 + 平均完整读取 5 个页面的成本（total_chars / total_pages * 5 / 4）。

5. 阈值检查 — 从配置中读取 WIKI_TOKEN_WARN_THRESHOLD（默认值：100000）。如果为 0，则跳过警告。如果全知识库 Token 估算值超过阈值，则输出 ⚠️ 警告，并附上上方模板中的三条补救建议。

6. 包含在每次标准状态运行中 — 普通模式和洞察模式均需包含。方法说明（4 chars/token heuristic）作为脚注放在表格下方。

第 4 步：接下来要做什么

将旧的单行 Recommendation 替换为按优先级排列的 接下来要做什么 部分。生成内容前，先收集以下信号：

4a：收集信号

0. 待处理的暂存写入（仅当 WIKI_STAGED_WRITES=true 时）— 遍历 $OBSIDIAN_VAULT_PATH/_staging/**/*.md 和 **/*.patch.md。分别统计新页面和补丁。报告最早文件的存放时长（mtime）。如果存在任何暂存文件，始终将其列在第一位——它的意图信号最强（LLM 已完成工作；人类只需审核）。

1. _raw/ 文件 — 列出 $OBSIDIAN_VAULT_PATH/_raw/ 顶层的每个文件，但不包括 .gitkeep，并排除 _archived/ 子目录（其中保存的是已提升的草稿，用于保留来源记录，并非待处理工作）。统计数量并列出名称。

2. 过时的核心页面 — 扫描知识库中的所有 .md 文件。如果某页面的 updated frontmatter 字段比今天早 ≥90 天，且有 ≥5 个入站 wikilink（即该页面属于“核心”页面，其他页面依赖它），则该页面为“过时”页面。按名称和最后更新时间列出。

3. 孤立页面 — 入站 wikilink 数为零的页面。计算方法：遍历所有 .md 页面，提取每个 [[wikilink]]，统计对每个页面的引用次数，并收集 incoming == 0 的页面。最多显示 5 个名称；报告总数。

4. 综合整理机会 — 检查 hot.md 是否有近期 /wiki-synthesize 运行摘要。如果最近一次综合整理报告了 N 个机会，则显示该数量。如果最近 14 天内没有运行综合整理（hot.md 或 log.md 中均无记录），则标记为“综合整理扫描已逾期”。

5. 来源变化 — 使用第 2 步的结果：统计准备摄取的新来源和已修改来源数量。

6. Lint 问题 — 检查 log.md 中近期的 /wiki-lint 运行记录（30 天内）。如果近期运行记录了损坏的链接或缺失的 frontmatter，则显示数量。如果日志中没有 Lint 运行记录，则标记为“近期未运行 Lint”。

4b：排名并呈现

为每个类别评分并输出排名列表，最多 6 项。始终按以下优先级排序（如果某类别的数量为 0 或无内容可报告，则跳过）：

优先级	类别	触发条件
0	有待处理的暂存写入	_staging/ 中有任何 .md/.patch.md（仅当 WIKI_STAGED_WRITES=true 时）
1	_raw/ 中有待处理文件	_raw/ 中存在任何文件
2	过时的核心页面	任意页面：更新时间 ≥90 天前，且有 ≥5 个入链
3	孤立页面	入链为零的任意页面
4	综合整理机会	上次综合整理运行中有 N 个机会，或扫描已逾期
5	新增/修改的来源	第 2 步中的增量数量
6	Lint 问题	上次 Lint 运行中已知的问题，或 Lint 已逾期

呈现为：

## What to Do Next

0. 📋  6 staged pages waiting for review (oldest: 3 days ago)
   → 4 new pages + 2 patches in _staging/
   run: /wiki-stage-commit

1. 📥  Ingest 3 files waiting in _raw/
   → architecture-notes.md, meeting-2026-05-10.md, paper-draft.pdf
   run: /wiki-ingest

2. 🔄  Refresh 2 stale core pages (not updated in 90+ days)
   → [[System Architecture]] (last updated 2026-02-10), [[API Design]] (2026-01-15)
   run: open these pages and re-run /wiki-update

3. 🔗  Link 7 orphan pages  →  run: /cross-linker
   Disconnected: [[Redis Caching]], [[JWT Tokens]], +5 more

4. 🧩  2 synthesis opportunities identified  →  run: /wiki-synthesize
   [[Redis Caching]] × [[Session Management]] (co-occur in 8 pages)

5. ✅  4 sources modified since last ingest  →  run: /wiki-ingest (append mode)

6. 🩺  Lint not run in 30+ days — run: /wiki-lint

**空状态：**如果所有类别都没有内容可报告（没有暂存文件、_raw/ 文件、孤立页面、过时页面、综合整理机会、新来源或 Lint 问题），则改为输出：

## What to Do Next

✅  Wiki is healthy — nothing urgent.
    All sources up to date · no orphans · no stale core pages · no _raw/ files pending · no staged writes

**溢出：**如果显示的项目超过 6 项，则添加一行页脚：_(N more items available — run /wiki-status --full to see all)_。--full 标志尚未实现；这段前瞻性文案用于让用户了解预期。

洞察模式

当用户提出类似“wiki insights”“我的 wiki 中什么最核心”“展示枢纽”“跨领域桥接”“哪些页面最重要”或“wiki 结构”的请求时触发。此模式是附加的——它不会取代增量报告，而是分析 wiki 本身的结构形态。

增量报告会告诉用户有哪些待处理事项；洞察模式则会告诉用户他们已经构建了什么，以及有趣的结构分布在哪里。它与 wiki-lint（用于发现问题）互为补充，通过呈现有趣的结构来提供洞察。

要计算的内容

**首先，运行图分析器。**它取代了手动解析 wikilink 的工作——一条命令即可生成所需的所有原始数据：

obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --pretty --snapshot \
  --diff-against "$OBSIDIAN_VAULT_PATH/_insights.md"   # omit if no previous _insights.md

分析器使用与 graphify 应用于代码图相同的一类算法，并以纯 Python 实现：度数排名、社区检测（安装了 obsidian-wiki[graph] 时使用 Leiden，否则使用标签传播）、社区凝聚度、Brandes 介数中心性、跨社区意外连接评分，以及快照差异比较。Vault 管理文件（index、log、hot、_insights、_meta/、_readouts/）会被排除，以免它们在每项排名中都占据主导。

下文使用的输出字段：

• god_nodes — 按总度数（入度 + 出度）排名的页面，并带有 in_degree/out_degree。用于查找锚点页面并分类枢纽。
• bridges — 按介数中心性（经过该页面的最短路径占比）排名的页面，并带有 community 以及其 connects 的其他社区列表。直接用于“桥接页面”部分——无需手动搜索标签组合。
• communities — 按链接密度划分的页面集群，每个集群带有 label、size、pages 和 cohesion（集群内边密度，0–1）。用于集群命名和凝聚度部分。
• surprising_connections — 按意外程度排名的跨社区边；在任何社区对重复出现之前，每对社区只列出一条，并带有 note 字段，注明这两个社区。直接用于“意外连接”部分。
• suggested_questions — 根据桥接页面、汇入型枢纽、孤立页面和低凝聚度集群生成的 {type, question, why}。用这些内容为“问题”部分提供初始内容。
• dead_ends — 出链为零的页面。用于提供与孤立页面相关的建议，以及建议添加跨链接。
• isolated — 任一方向的链接数都为零的页面。用于报告存根/孤立页面。
• stats — 页面总数、边数、社区数、图的 density。
• diff（仅与 --diff-against 一起使用）— added_pages、removed_pages、added_edges、removed_edges、newly_connected、lost_incoming、summary。用于“图变化”部分。
• snapshot（仅与 --snapshot 一起使用）— 将此 JSON 原样写入 _insights.md 末尾的 `` 注释中。 查询模式（适用于用户提出后续问题时）：--path A B 返回两个页面之间最短的链接链；--around PAGE --depth N [--direction in|out|both] 返回 N 跳范围内的邻域（--direction in = 如果重命名或删除 PAGE，可能造成的影响范围）。

回退方案（如果未安装 obsidian-wiki）：对所有 .md 页面使用 glob，提取每个 [[wikilink]]，手动构建 incoming、outgoing 和 tags 映射，然后手动近似生成以下各节。

你将在以下各节中重复使用这些数据。

---

1. 锚点页面（顶级枢纽）。 入链最多的页面——承载核心概念的页面。

   • 按 incoming 数量对所有页面排序，取前 10 个
   • 记录每个页面的入链和出链数量：入链和出链都高的页面是连接枢纽（最有价值）
   • 入链高但出链为零的页面是汇聚枢纽——将其标记为潜在的交叉链接对象

2. 桥接页面。 连接原本互不相连的集群的页面——移除它们会将图拆分。这些页面在结构上的重要性往往超过单纯的枢纽数量所显示的程度。

   • 取 bridges 中排名前 5 的页面（已按介数中心性排序）
   • 使用社区标签为每个页面标注：“P 连接 [社区标签] ↔ [所连接的标签]”。如果 connects 列表为空，则说明它是集群内部的关键节点——标注为“[标签] 的内部枢纽”
   • 显示介数分数，以便比较不同时间的运行结果

3. 集群紧密度。 每个社区的页面相互链接的紧密程度——直接读取 communities[].cohesion（actual_links / (n × (n−1) / 2)）。

   • 碎片化集群（紧密度 < 0.15，规模 ≥ 5）：这些页面主题相同，但彼此之间缺少关联。将它们列为交叉链接目标。
   • 显示紧密度排名前 5（最紧密的集群）和后 5（最碎片化的集群）的社区，并列出各自的标签和规模
   • 如果用户关注标签级紧密度，可按标签（页面数 ≥ 5）重复使用相同公式

4. 意外关联。 不明显的跨社区 wikilink。

   • 从 surprising_connections 开始（结构分数 = 1/√(cross-degree(A)·cross-degree(B))；每对社区之间先取一条边，再取重复的社区对，因此单个枢纽无法占满列表）
   • 使用分析器无法识别的内容信号重新排列候选项：
     • +3：如果链接页面或声明标记为 ^[ambiguous]（关联不确定，值得复查）
     • +2：如果链接页面标记为 ^[inferred]（经过综合推断，并非直接陈述）
     • +2：如果类别属于不同的知识层（例如，concepts ↔ entities 比 concepts ↔ concepts 更令人意外）
   • 显示前 5 个，并用通俗易懂的语言说明原因（使用 note——“连接 [标签 A] → [标签 B]”——以及任何内容加分）

5. 孤立相邻页面建议。 由排名前 10 的枢纽链接、但自身没有出链的页面。它们是高流量区域的死胡同，是优先考虑的交叉链接对象。

6. 粗略集群。 按主导标签对锚点页面分组。（简单取标签交集，仅供参考。）

7. 与上次运行相比的图变化。 直接读取 diff 字段（由上一个 _insights.md 上的 --diff-against 生成，分析器会从其 `` 注释中读取）：

   • summary → “+N 个页面，+M 个 wikilink”；列出 added_pages / removed_pages
   • newly_connected → “新建立连接：X、Y”（上次运行时没有入链的页面）
   • lost_incoming → “链接目标可能已重命名：A、B”
   • 如果没有之前的快照（没有 diff 字段），则跳过此节

8. 层级分配建议。 计算完枢纽和桥接节点后，建议调整 tier:。绝不要将 tier: 写入页面——只给出建议，由人来决定。

   • 提升为 core： 入链数 ≥5，或桥接节点排名前 5，且当前 tier: supporting 或没有 tier: 字段的页面
   • 降级为 peripheral： 入链数 ≤1，且 90 天以上未更新，并且当前 tier: supporting 或 tier: core 的页面
   • 最多显示 10 条建议（先显示提升，再显示降级），格式如下：

     Tier Suggestions:
     ↑ core    [[concepts/attention-mechanism]] — 14 incoming links, currently tier=supporting
     ↑ core    [[entities/andrej-karpathy]]     — bridge (3 cluster pairs), currently unset
     ↓ peripheral [[concepts/old-concept]]       — 0 incoming, 120 days stale
     

   • 如果所有高入链页面都已是 tier: core，且所有低入链页面都已是 tier: peripheral，则输出：“层级分配状态良好——无需提出更改建议。”

9. 建议问题。 这类问题只有凭借此 Wiki 结构才能解答，或能揭示其中的缺口：

   • 来自 ^[ambiguous] 声明（内容扫描——分析器看不到这些）：“澄清：X 和 Y 之间的确切关系是什么？”
   • 来自 suggested_questions——已为你生成：bridge_node → “探索：……”，sink_hub → “链接：……”，isolated_nodes → “链接：……”，low_cohesion → “审查：……”。将每个问题改写为对应的前缀格式
   • 最多显示 7 个，优先级依次为：歧义项、桥接节点、汇聚枢纽／孤立节点、内聚度审查

---

输出

将结果写入 Vault 根目录下的 _insights.md。可直接覆盖——该文件可重新生成。在文件末尾，以 HTML 注释原样嵌入分析器的 snapshot 字段，以便下次运行时可使用 --diff-against 与之比较。

# Wiki Insights — <TIMESTAMP>

## Anchor Pages (top 10 hubs)
| Page | Incoming | Outgoing | Note |
|---|---|---|---|
| [[concepts/transformer-architecture]] | 23 | 8 | connector hub |
| [[entities/andrej-karpathy]] | 17 | 0 | sink hub — cross-linker candidate |

## Bridge Pages (top 5)
| Page | Bridges | Cross-cluster pairs |
|---|---|---|
| [[concepts/exponential-growth]] | #ml ↔ #economics | 4 pairs |

## Tag Cluster Cohesion
### Most cohesive (well-linked)
- **#ml** — 12 pages, cohesion 0.41
### Most fragmented (cross-linker targets)
- **#systems** — 7 pages, cohesion 0.06 ⚠️ run cross-linker on this tag

## Surprising Connections (top 5)
- [[concepts/scaling-laws]] → [[entities/gordon-moore]] — score 5
  - Reason: cross-layer (concepts ↔ entities), marked ^[inferred]
- ...

## Orphan-Adjacent (dead-ends near hubs)
- [[concepts/foo]] — linked from 3 hubs, 0 outbound links

## Rough Clusters
- **#ml** — transformer-architecture, attention-mechanism, scaling-laws
- **#systems** — distributed-consensus, raft, paxos

## Graph Delta Since Last Run
- +3 new pages, +11 new wikilinks
- Newly connected: [[concepts/bar]], [[entities/baz]]
- Lost incoming links: [[references/old-paper]] (target may have been renamed)

## Tier Suggestions
↑ core    [[concepts/attention-mechanism]] — 14 incoming links, currently tier=supporting
↑ core    [[entities/andrej-karpathy]]     — top bridge (4 cluster pairs), currently unset
↓ peripheral [[concepts/old-concept]]       — 0 incoming, 132 days stale

## Questions Worth Asking
1. Resolve: What is the exact relationship between `scaling-laws` and `moore's-law`? (^[ambiguous] claim)
2. Explore: Why does `exponential-growth` bridge #ml and #economics?
3. Link: `references/foo.md` has no incoming links — what should reference it?
4. Audit: Should tag `#systems` be split? (cohesion 0.06, 7 pages)

写入文件后，追加到 log.md：

- [TIMESTAMP] STATUS_INSIGHTS anchors=10 bridges=N cohesion_checked=T surprising=5 questions=7 delta="+N pages +M links" tier_suggestions=N

何时跳过

• 页面少于 20 个的 Vault——图结构不足。告知用户并跳过。
• 刚执行完 wiki-rebuild——等待至少完成一次摄取后再运行。

均衡模式

当用户询问“我的 Vault 是否达到均衡”“Wiki 均衡”“Vault 是否已收敛”“维护是否完成”“这些技能是否在相互冲突”或“所有维护技能还有哪些待办事项”时触发。

维护技能是同一个共享 Vault 中的一场博弈的参与者。每个技能都有一组可执行操作（修复 lint 问题、合并重复项、新增链接、规范化标签），并根据自身目标评估 Vault。当没有任何参与者可以通过单方面改变操作获得收益时，即每轮审计都不建议做任何更改，Vault 就达到了均衡。这才是“维护已完成”的真正信号，而且比任何单个技能报告状态正常都更有力，因为技能之间可能相互撤销对方的更改。

此模式对参与者只读：以仅报告的形式运行每项审计，绝不让任何技能应用更改。除 _insights.md 中的快照行外，不写入任何内容。

参与者

参与者	仅审计调用	计为一次操作
wiki-lint	obsidian-wiki lint "$OBSIDIAN_VAULT_PATH" --json	findings 中的每个问题（对 stats.findings 的计数求和）
wiki-dedup	审计模式（不使用 --merge 或 --auto）	每对高或中优先级重复项
cross-linker	仅执行审计——报告建议链接，不插入链接	每个本可添加链接的未链接提及
tag-taxonomy	仅执行步骤 1 的审计——报告偏差，不进行规范化	每个将重命名或删除的标签

只有 wiki-lint 的结果是确定的；其余三个由大模型执行，因此计数是根据各自报告得出的估算值。请在输出中说明这一点，不要暗示结果精确无误。

报告内容

# Vault Equilibrium — <TIMESTAMP>

equilibrium: no

| Player | Pending moves | Top proposed move |
|---|---|---|
| wiki-lint | 4 | fix broken link [[concepts/old-name]] in synthesis/foo.md |
| wiki-dedup | 1 | merge entities/gpt-4.md ← entities/gpt4.md (0.91) |
| cross-linker | 12 | link "attention mechanism" in concepts/transformers.md |
| tag-taxonomy | 0 | — |

Deviating players: wiki-lint, wiki-dedup, cross-linker
Converged players: tag-taxonomy

当所有计数均为零时，报告 equilibrium: yes，并明确说明此时运行任何维护技能都不会产生更改。

振荡检测

如果某个参与方的计数在降至零后又不断恢复，说明有两个参与方在冲突——典型情况是 tag-taxonomy 对标签进行规范化，而某个摄取技能的默认值又不断将其重新添加，导致知识库无限循环，始终无法收敛。

在 _insights.md 中现有的 GRAPH_SNAPSHOT 旁边追加一条快照：

读取之前的 EQUILIBRIUM_SNAPSHOT 行（保留最近 5 条；删除更早的行）并进行比较：

• 某个参与方的计数在多次运行中呈现 0 → N → 0 → N，则表示其处于振荡状态——按名称标记，并指出可能的对手（重新引入这些移动的技能）。
• 某个参与方的计数只增不减，则表示其正在失势——没有人在运行它。
• 如果没有之前的快照，则报告“首次运行，尚无基线”，并跳过比较。

振荡检测只用于报告，不用于修复。如何解决应由人决定哪个参与方的目标优先——通常需要修改 _meta/taxonomy.md 或所有者的 AGENTS.md 中的规则，而不是再次运行维护任务。

来源记录

待处理移动在不同来源间的分布并不均匀。请追溯其来源：对于某个参与方的发现中出现的每个页面，查询哪个清单来源创建了该页面（.manifest.json → pages_created / pages_produced）。

如果某个来源对应 ≥3 个问题，或占某个参与方待处理移动的 ≥50%，则添加一行：

Source track record:
- ~/exports/slack-dump/ — 7 of 12 cross-linker moves, 3 of 4 lint findings.
  Its pages consistently need repair; consider reviewing its source_quality bucket.

这体现了重复博弈的视角：如果某个来源持续生成需要修复的页面，就应降低其 source_quality。仅报告——绝不自动调整 source_quality 或信任账本。所有者应通过现有的信任流程（obsidian-wiki trust-record）自行决定，与其他任何置信度变更的处理方式相同。

跳过条件

• 页面少于 20 个的知识库——在这种规模下，审计结果只是噪声。
• 如果无法以纯报告形式干净地运行任何参与方的审计，请省略该行，并说明缺少哪个参与方，而不要猜测计数。

备注

• 如果清单不存在，则将所有内容报告为“新”，并建议执行完整摄取
• 此技能只读取并报告——不会修改任何内容（insights 模式下写入 _insights.md 除外；该文件可重新生成）
• 实际的摄取工作由摄取技能（wiki-ingest、claude-history-ingest、codex-history-ingest）完成
• 这些技能负责在完成后更新清单

知识库写入后的 QMD 刷新

QMD 是搜索索引，并非事实来源。如果 $QMD_WIKI_COLLECTION 为空或未设置，则跳过此步骤。仅当此技能已写入或重写知识库 Markdown 文件后才运行。如果 QMD 刷新失败，不要回滚知识库更改；应单独报告 QMD 状态。

如果已设置 $QMD_CLI，则使用它；否则使用 qmd。

${QMD_CLI:-qmd} update

如果输出表示需要向量，或嵌入可能已过期，则运行：

${QMD_CLI:-qmd} embed

通过以下任一方式验证集合：

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

或者，已知具体页面路径时：

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

记录以下其中一项：

• 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>