health

运行时配置（步骤 0 — 开始处理前）

读取以下文件以配置特定领域的行为：

1. ops/derivation-manifest.md — 词汇映射、文件夹名称、平台提示

   • 使用 vocabulary.notes 作为 notes 文件夹名称
   • 使用 vocabulary.inbox 作为 inbox 文件夹名称
   • 使用 vocabulary.note 作为输出中的笔记类型名称
   • 使用 vocabulary.topic_map 指代 MOC／主题映射
   • 使用 vocabulary.topic_maps 作为复数形式

2. ops/config.yaml — 处理深度、阈值

3. 三空间参考 — ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md，用于边界规则（仅在 full 和 three-space 模式下加载）

4. 模板 — 阅读模板文件，了解验证所需的架构字段

如果这些文件不存在（初始化前调用或独立使用），请采用通用默认值：

• notes 文件夹：notes/
• inbox 文件夹：inbox/
• 主题映射：notes/ 中的主题映射

---

立即执行

目标：$ARGUMENTS

立即解析调用模式：

输入	模式	执行类别
空或 quick	快速	1（架构）、2（孤立项）、3（链接）
full	完整	全部 8 个类别
three-space	三空间	仅 5（三空间边界）

执行以下步骤：

1. 检测模式：根据参数判断
2. 扫描知识库 — 清点所有笔记文件、{vocabulary.topic_map} 文件、inbox 项目和 ops 文件
3. 按顺序运行所有适用的诊断类别（1-8）
4. 使用下方阈值对每项结果分类为 PASS、WARN 或 FAIL
5. 显示基于条件的维护信号（对照阈值表检查）
6. 生成健康报告，列出具体文件路径、数量和建议操作
7. 将报告写入 ops/health/YYYY-MM-DD-report.md

现在开始。 下文详细说明了各诊断类别。

平台适配

检查会根据平台支持的功能进行调整：

• 如果未配置语义搜索（qmd），则跳过依赖语义搜索的检查，并注明该功能不可用
• 如果没有可用的钩子，则注明验证仅依赖约定（无自动强制执行）
• 如果 self/ 目录不存在（由配置禁用），则跳过 self-space 检查，但要确认 ops/ 正确吸收 self-space 内容

报告可检查的内容，而非平台缺少的功能。

---

8 个诊断类别

类别 1：架构合规性（快速、完整）

检查内容： {vocabulary.notes}/ 和 self/memory/（如果启用了 self/）中的每个 {vocabulary.note} 都具有包含必需字段的有效 YAML frontmatter。

检查方法：

# Find all note files (exclude topic maps)
for f in {vocabulary.notes}/*.md; do
  [[ -f "$f" ]] || continue
  # Check: YAML frontmatter exists
  head -1 "$f" | grep -q '^---$' || echo "FAIL: $f — no YAML frontmatter"
  # Check: description field present
  rg -q '^description:' "$f" || echo "WARN: $f — missing description field"
  # Check: topics field present and links to at least one topic map
  rg -q '^topics:' "$f" || echo "WARN: $f — missing topics field"
done

其他检查：

• 领域专属枚举字段的值有效（如果存在模板，则对照模板中的 _schema 块检查）
• description 字段非空（不只是存在）
• topics 字段至少包含一个 wiki 链接

如果 ${CLAUDE_PLUGIN_ROOT}/reference/ 中存在 validate-kernel.sh，则运行该脚本并附上结果。

阈值：

条件	级别
任意笔记缺少 YAML frontmatter	FAIL
任意笔记缺少 description 字段	WARN
任意笔记缺少 topics 字段	WARN
任意枚举值无效	WARN
所有笔记均通过全部检查	PASS

输出格式：

[1] Schema Compliance ............ WARN
    2 notes missing description:
      - notes/example-note.md
      - notes/another-note.md
    1 note missing topics:
      - notes/orphaned-claim.md
    12/15 notes fully compliant

类别 2：孤立项检测（快速、完整）

检查内容： 每个 {vocabulary.note} 至少有一个来自其他文件的传入 wiki 链接。

检查方法：

# For each note file, check if ANY other file links to it
for f in {vocabulary.notes}/*.md; do
  [[ -f "$f" ]] || continue
  basename=$(basename "$f" .md)
  # Search for [[basename]] in all other files
  count=$(rg -l "\[\[$basename\]\]" --glob '*.md' | grep -v "$f" | wc -l | tr -d ' ')
  if [[ "$count" -eq 0 ]]; then
    echo "WARN: $f — no incoming links (orphan)"
  fi
done

注意： 孤立项不一定代表失败。今天创建、尚未经过 /{vocabulary.cmd_reflect} 的笔记，暂时处于孤立状态是预期情况。请检查文件时间：

条件	级别
孤立笔记创建时间 < 24 小时	INFO（符合预期 — 等待 reflect 阶段）
孤立笔记创建时间为 1-7 天	WARN
孤立笔记创建时间超过 7 天	FAIL（持续孤立，需要处理）
未检测到孤立项	PASS

输出格式：

[2] Orphan Detection ............. WARN
    3 orphan notes detected:
      - notes/new-claim.md (created 2h ago — awaiting reflect) [INFO]
      - notes/old-observation.md (created 5d ago) [WARN]
      - notes/forgotten-insight.md (created 14d ago) [FAIL]
    Recommendation: run /reflect on forgotten-insight.md and old-observation.md

类别 3：链接健康度（快速、完整）

检查内容： 每个文件中的每个 wiki 链接 [[target]] 是否都指向现有文件。

检查方法：

# Extract all wiki links from all markdown files
# For each unique link target, verify a file with that name exists
rg -oN '\[\[([^\]]+)\]\]' --glob '*.md' -r '$1' | sort -u | while read target; do
  # Search for file matching this name
  found=$(find . -name "$target.md" -not -path "./.git/*" 2>/dev/null | head -1)
  if [[ -z "$found" ]]; then
    echo "FAIL: dangling link [[${target}]] — no file found"
    # Show which files contain this dangling link
    rg -l "\[\[$target\]\]" --glob '*.md'
  fi
done

阈值：

条件	级别
存在任何悬空链接（目标不存在）	FAIL
所有链接均可解析	PASS

为什么是 FAIL 而不是 WARN： 悬空链接是无法兑现的承诺。读者跟随每个 [[link]] 却无功而返，都会削弱他们对知识图谱的信任。请立即修复。

输出格式：

[3] Link Health .................. FAIL
    2 dangling links found:
      - [[nonexistent-note]] referenced in:
        - notes/some-claim.md (line 14)
        - notes/another-claim.md (line 8)
      - [[removed-topic]] referenced in:
        - notes/old-note.md (line 22)
    Recommendation: create missing notes or remove broken links

类别 4：描述质量（仅完整检查）

检查内容： 每个 {vocabulary.note} 的描述都提供了超出标题的真实信息，而非只是重述标题。

检查方法：

对于每个 {vocabulary.note}：

1. 阅读标题（不带扩展名的文件名）
2. 阅读 YAML frontmatter 中的 description 字段
3. 评估：描述是否补充了标题未涵盖的范围、机制或含义？

质量启发式规则：

检查项	阈值
描述长度	理想长度为 50-200 个字符。少于 30 个字符 = 过于简短。多于 250 个字符 = 过于冗长
重述检测	如果描述与标题使用了超过 70% 的相同词语 = 重述
补充的信息	描述应提及标题未包含的机制、范围或含义

阈值：

条件	级别
描述明显是在重述标题	WARN
描述少于 30 个字符	WARN
完全缺少描述	WARN（类别 1 也会检查）
描述补充了真实的新信息	PASS

此项检查需要判断。 请运用语义理解，而不只是匹配字符串。即使描述使用了不同的词语，只要表达的内容与标题相同，仍然属于重述。

输出格式：

[4] Description Quality .......... WARN
    2 descriptions are restatements:
      - notes/quality-matters.md
        Title: "quality matters more than quantity"
        Description: "quality is more important than quantity in knowledge work"
        Issue: restates title without adding mechanism or implication
      - notes/structure-helps.md
        Title: "structure without processing provides no value"
        Description: "having structure without processing it is not valuable"
        Issue: exact restatement
    Recommendation: rewrite descriptions to add scope, mechanism, or implication

类别 5：三空间边界检查（完整、三空间）

检查内容： 内容遵守 self/、{vocabulary.notes}/ 和 ops/ 之间的边界。每个空间都有自己的用途——混淆这些空间会降低搜索质量、导航体验和信任度。

运行此项检查前： 阅读 ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md，了解完整的边界规范。

需要检测的六种混淆模式：

5a. 运维内容进入笔记（基础设施蔓延）

队列状态、健康指标、任务文件或处理产物出现在 {vocabulary.notes}/ 目录中。

检测方法：

# Check for ops-pattern YAML fields in notes
rg '^(current_phase|completed_phases|batch|source_task|queue_id):' {vocabulary.notes}/ --glob '*.md'
# Check for task file patterns in notes
rg '## (Create|Reflect|Reweave|Verify|Enrich)$' {vocabulary.notes}/ --glob '*.md'

检查结果	级别
{vocabulary.notes}/ 中存在任何运维模式内容	WARN

5b. 自我内容进入笔记（身份污染）

Agent 身份或方法论内容混入用户的知识图谱。Agent 的运维观察出现在用户的 {vocabulary.notes}/ 空间中。

检测方法：

# Check for agent-reflection patterns in notes (methodology observations, workflow assessments)
rg -i '(my methodology|I observed that|agent reflection|session learning|I learned)' {vocabulary.notes}/ --glob '*.md'

检查结果	级别
{vocabulary.notes}/ 中存在任何 Agent 反思内容	WARN

5c. 笔记内容进入运维（知识受困）

真正的见解受困于会话日志、观察记录或运维文件中，而这些内容本应提升至 {vocabulary.notes}/。

检测方法：

# Check for claim-like content in ops that could be notes
# Look for files with description fields in ops/observations/ or ops/methodology/
rg '^description:' ops/observations/*.md ops/methodology/*.md 2>/dev/null

检查结果	级别
ops/ 中的内容采用笔记式架构（description + topics）	INFO（可能是有意为之，请标记以供审核）

5d. 自我内容进入运维 / 运维内容进入自我

时间状态存储在 self/ 中（本应位于 ops/），或身份内容存储在 ops/ 中（本应位于 self/）。

检测方法：

# Check for temporal/queue content in self/
rg '^(current_phase|status|queue):' self/ --glob '*.md' 2>/dev/null
# Check for identity content in ops/
rg -i '(my identity|I am|who I am|my personality)' ops/ --glob '*.md' 2>/dev/null

5e. 笔记内容进入自我

领域知识存储在 self/ 中，而不是 {vocabulary.notes}/。

检测方法：

# Check self/memory/ for notes that have topics linking to notes-space topic maps
rg '^topics:.*\[\[' self/memory/*.md 2>/dev/null | grep -v 'identity\|methodology\|goals\|relationships'

5f. 自我空间缺失的影响（停用 self/ 时）

停用 self/ 时，请确认 ops/ 正确承接自我空间内容。检查目标和交接内容是否位于 ops/ 中，而不是散落在 {vocabulary.notes}/ 中。

检测方法：

# If self/ doesn't exist, check that goals/handoffs are in ops/
if [[ ! -d "self/" ]]; then
  # Check for goals or handoff content in notes/
  rg -i '(my goals|current goals|handoff|session handoff)' {vocabulary.notes}/ --glob '*.md'
fi

阈值：

条件	级别
存在任何边界违规（5a、5b、5d、5e）	WARN
知识受困于 ops 中（5c）	INFO
自我空间缺失的影响（5f）	WARN
所有边界均完好	PASS

输出格式：

[5] Three-Space Boundaries ....... WARN
    1 boundary violation detected:
      Ops into Notes (infrastructure creep):
        - notes/task-tracking.md contains queue state fields (current_phase, batch)
        - Should be in ops/queue/ not notes/
    1 potential trapped knowledge:
      - ops/observations/interesting-pattern.md has note-like schema
        Consider promoting to notes/ via /reduce or direct creation
    Recommendation: move task-tracking.md to ops/queue/

类别 6：处理吞吐量（仅完整模式）

检查内容： 收件箱与知识库的比例。比例较高表明存在收集者谬误——收集多于处理。

检查方法：

# Count items in each space
INBOX_COUNT=$(find {vocabulary.inbox}/ -name '*.md' -not -path '*/archive/*' 2>/dev/null | wc -l | tr -d ' ')
NOTES_COUNT=$(find {vocabulary.notes}/ -name '*.md' 2>/dev/null | wc -l | tr -d ' ')
QUEUE_COUNT=$(find ops/queue/ -name '*.md' -not -path '*/archive/*' 2>/dev/null | wc -l | tr -d ' ')

# Calculate ratio
if [[ $((INBOX_COUNT + NOTES_COUNT)) -gt 0 ]]; then
  RATIO=$((INBOX_COUNT * 100 / (INBOX_COUNT + NOTES_COUNT)))
else
  RATIO=0
fi

echo "Inbox: $INBOX_COUNT | Notes: $NOTES_COUNT | In-progress: $QUEUE_COUNT | Ratio: ${RATIO}%"

阈值：

条件	级别
收件箱与总量之比 > 75%（收件箱与笔记为 3:1）	FAIL
收件箱与总量之比 > 50%	WARN
收件箱项目 > 20	WARN（无论比例如何）
收件箱与总量之比 <= 50% 且收件箱 <= 20	PASS

输出格式：

[6] Processing Throughput ........ WARN
    inbox: 12 | notes: 8 | in-progress: 3 | ratio: 60%
    Inbox items outnumber processed notes — collector's fallacy risk
    Recommendation: run /reduce on oldest inbox items or /pipeline for end-to-end processing

类别 7：过时笔记检测（仅完整模式）

检查内容： 最近未修改且链接密度较低的笔记。过时状态基于条件（链接密度低 + 自新增 N 条笔记后没有活动），而非单纯依据日历时间。

检查方法：

对于每个 {vocabulary.note}：

1. 检查最后修改日期（stat 或 git log）
2. 统计传入链接（与孤立笔记检测相同，但统计数量而非布尔值）
3. 标记符合以下条件的笔记：修改时间距今 > 30 天，且传入链接 < 2 条

for f in {vocabulary.notes}/*.md; do
  [[ -f "$f" ]] || continue
  basename=$(basename "$f" .md)

  # Last modified (days ago)
  mod_days=$(( ($(date +%s) - $(stat -f %m "$f" 2>/dev/null || stat -c %Y "$f" 2>/dev/null)) / 86400 ))

  # Incoming link count
  incoming=$(rg -l "\[\[$basename\]\]" --glob '*.md' | grep -v "$f" | wc -l | tr -d ' ')

  if [[ $mod_days -gt 30 ]] && [[ $incoming -lt 2 ]]; then
    echo "STALE: $f — $mod_days days old, $incoming incoming links"
  fi
done

阈值：

条件	级别
任意笔记距今 > 30 天且传入链接 < 2 条	WARN
任意笔记距今 > 90 天且传入链接为 0 条	FAIL
所有笔记要么较新，要么连接良好	PASS

优先级排序： 按以下顺序排列过时笔记：

1. 时间（最久远的排在最前）
2. 链接密度（连接最少的排在最前）
3. 主题相关性（活跃主题领域中的笔记优先级更高）

输出格式：

[7] Stale Notes .................. WARN
    4 stale notes detected (>30d old, <2 incoming links):
      - notes/old-observation.md (92d, 0 links) [FAIL — consider archiving or reweaving]
      - notes/early-claim.md (45d, 1 link) [WARN]
      - notes/setupial-thought.md (38d, 1 link) [WARN]
      - notes/first-draft.md (31d, 0 links) [WARN]
    Recommendation: run /reweave on these notes to find connections, or archive if no longer relevant

类别 8：{vocabulary.topic_map} 连贯性（仅完整模式）

检查内容： 每个 {vocabulary.topic_map} 都链接了适量的笔记，且同一主题领域中的笔记彼此确实有链接。

检查方法：

对于每个 {vocabulary.topic_map} 文件：

1. 统计链接到此 {vocabulary.topic_map} 的笔记（在 topics 页脚/字段中包含此主题映射的笔记）
2. 检查同一主题领域中是否存在未链接到此 {vocabulary.topic_map} 的笔记（覆盖缺口）
3. 确认 Core Ideas 链接中包含上下文短语（而非裸链接）

# For each topic map
for moc in {vocabulary.notes}/*.md; do
  [[ -f "$moc" ]] || continue
  # Check if this is a topic map (has type: moc in frontmatter)
  rg -q '^type: moc' "$moc" || continue

  moc_name=$(basename "$moc" .md)

  # Count notes linking to this topic map
  note_count=$(rg -l "\[\[$moc_name\]\]" {vocabulary.notes}/ --glob '*.md' | grep -v "$moc" | wc -l | tr -d ' ')

  echo "$moc_name: $note_count notes"
done

阈值：

条件	级别
包含 < 5 条笔记的 {vocabulary.topic_map}	WARN（尚未充分发展——考虑合并到上级主题映射）
包含 > 50 条笔记的 {vocabulary.topic_map}	WARN（规模过大——考虑拆分为子级 {vocabulary.topic_maps}）
包含 > 40 条笔记的 {vocabulary.topic_map}	INFO（接近阈值）
主题领域中存在未链接到 {vocabulary.topic_map} 的笔记	WARN（覆盖缺口）
所有 {vocabulary.topic_maps} 都在 5-50 条笔记范围内且覆盖良好	PASS

上下文短语检查：

# Check for bare links in topic map Core Ideas (links without context phrases)
for moc in {vocabulary.notes}/*.md; do
  rg -q '^type: moc' "$moc" || continue
  # Look for "- [[note]]" without " — " context
  rg '^\s*- \[\[' "$moc" | grep -v ' — ' | grep -v '^\s*- \[\[.*\]\].*—'
done

没有上下文短语的裸链接只是通讯录条目，而非导航。{vocabulary.topic_map} 中的每个链接都应说明为什么要访问它。

输出格式：

[8] MOC Coherence ................ WARN
    3 topic maps checked:
      - knowledge-work: 28 notes [PASS]
      - graph-structure: 52 notes [WARN — oversized, consider splitting]
        3 bare links without context phrases
      - agent-cognition: 3 notes [WARN — underdeveloped, consider merging]
    Recommendation: split graph-structure into sub-topic-maps; add context phrases to bare links

---

基于条件的维护信号

运行完所有适用的诊断类别后，检查这些基于条件的触发项。它们不是上面的 8 个类别，而是可触发特定技能的跨领域信号。

条件	阈值	建议
待处理观察	ops/observations/ 中 >= 10 个文件	考虑运行 /rethink
未解决的张力	ops/tensions/ 中 >= 5 个文件	考虑运行 /rethink
收件箱项目	>= 3 个项目	考虑运行 /reduce 或 /pipeline
未处理的会话	ops/sessions/ 中 >= 5 个文件	考虑运行 /remember --mine-sessions
孤立笔记	任意持久存在（> 7d）	对孤立笔记运行 /reflect
悬空链接	任意	立即修复失效引用
过时笔记	链接少 + 时间久	考虑运行 /reweave
{vocabulary.topic_map} 过大	> 40 个笔记	考虑拆分
队列停滞	任务待处理超过 2 个会话且没有进展	标记为受阻
触发器覆盖缺口	已知维护条件没有配置的触发器	标记缺口本身

如何检查条件计数：

# Pending observations
OBS_COUNT=$(find ops/observations/ -name '*.md' 2>/dev/null | wc -l | tr -d ' ')

# Open tensions
TENSION_COUNT=$(find ops/tensions/ -name '*.md' 2>/dev/null | wc -l | tr -d ' ')

# Inbox items
INBOX_COUNT=$(find {vocabulary.inbox}/ -name '*.md' -not -path '*/archive/*' 2>/dev/null | wc -l | tr -d ' ')

# Unprocessed sessions
SESSION_COUNT=$(find ops/sessions/ -name '*.md' 2>/dev/null | wc -l | tr -d ' ')

# Queue stalled
PENDING_TASKS=$(jq '[.tasks[] | select(.status=="pending")] | length' ops/queue/queue.json 2>/dev/null || echo 0)

元触发器： 纳入“触发器覆盖”检查。将已知维护条件与实际检查的内容进行比较。如果某项维护条件没有对应的检查或已配置的触发器，那么这个缺口本身就是一项发现。这可以防止维护债务不断累积却未被察觉。

---

输出格式

完整的健康报告采用以下结构。无论采用哪种模式，每份报告都使用此格式。

=== HEALTH REPORT ===
Mode: [quick | full | three-space]
Date: YYYY-MM-DD
Notes scanned: N | Topic maps: N | Inbox items: N

Summary: N FAIL, N WARN, N PASS

FAIL:
- [Category N]: [brief description of failure]
  [specific files and details]

WARN:
- [Category N]: [brief description of warning]
  [specific files and details]

PASS:
- [Category N]: [confirmation]

---

[1] Schema Compliance ............ PASS | WARN | FAIL
    [details — specific files, specific issues]

[2] Orphan Detection ............. PASS | WARN | FAIL
    [details — specific files, age, link count]

[3] Link Health .................. PASS | WARN | FAIL
    [details — specific dangling links, where referenced]

[4] Description Quality .......... PASS | WARN | FAIL  (full mode only)
    [details — specific files, title vs description comparison]

[5] Three-Space Boundaries ....... PASS | WARN | FAIL  (full/three-space mode)
    [details — specific boundary violations by type]

[6] Processing Throughput ........ PASS | WARN | FAIL  (full mode only)
    inbox: N | notes: N | in-progress: N | ratio: N%

[7] Stale Notes .................. PASS | WARN | FAIL  (full mode only)
    [N notes older than 30d with <2 incoming links, sorted by priority]

[8] MOC Coherence ................ PASS | WARN | FAIL  (full mode only)
    [details — note count per topic map, coverage gaps, bare links]

---

Maintenance Signals:
    [condition-based triggers from table above, if any thresholds met]
    - observations: N pending (threshold: 10) [TRIGGERED | OK]
    - tensions: N pending (threshold: 5) [TRIGGERED | OK]
    - inbox: N items (threshold: 3) [TRIGGERED | OK]
    - sessions: N unprocessed (threshold: 5) [TRIGGERED | OK]

---

Recommended Actions (top 3, ranked by impact):
1. [Most impactful action — specific command + specific file]
2. [Second priority — specific command + specific file]
3. [Third priority — specific command + specific file]
=== END REPORT ===

报告存储

将每份健康报告写入 ops/health/YYYY-MM-DD-report.md。如果同一天运行多份报告，则在文件名后追加计数器：YYYY-MM-DD-report-2.md。

这样会形成健康历史，供 /architect 在提出演进方案时参考。跨报告的趋势可以揭示单份报告无法发现的系统性模式。

---

质量标准

具体明确

每项发现都必须列出涉及的具体文件。

不佳：“有些笔记缺少描述” 良好：“notes/example-note.md 和 notes/another-note.md 缺少 description 字段”

不佳：“存在悬空链接” 良好：“[[nonexistent-claim]] 在 notes/old-note.md（第 14 行）和 notes/related.md（第 22 行）中被引用，但不存在同名文件”

按影响排序

问题的严重程度各不相同。建议操作部分会按影响排序：

影响等级	示例	原因
最高	悬空链接、持久存在的孤立笔记	图谱中的承诺已失效，读者会陷入死胡同
高	架构违规、边界违规	结构完整性问题，会累积成更大的问题
中	描述质量、过时笔记	检索质量下降，但系统并未损坏
低	{vocabulary.topic_map} 大小警告、吞吐率	维护债务，在规模扩大时才会显现影响

避免信息过载

• 在建议操作中重点关注最重要的 5-10 个问题
• 将相关问题归为一组（3 个笔记缺少描述 = 1 项发现，而不是 3 项）
• 对于大型知识库，每个类别最多列出 10 个具体文件，之后进行汇总：“……以及另外 15 个”

区分 FAIL 和 WARN

级别	含义	所需操作
FAIL	结构性问题——某处已损坏	在问题进一步恶化前修复
WARN	改进机会——某处不够理想	方便时处理
PASS	类别状态良好	无需操作
INFO	值得注意，但无需采取行动	提供背景信息

仅在以下情况使用 FAIL： 悬空链接（图谱损坏）、持久存在的孤立笔记（> 7 天）、严重的架构违规（完全缺少 frontmatter）、关键边界违规。

其他所有不够理想但尚未损坏的情况均使用 WARN。

---

特定模式的行为

快速模式（默认）

仅运行类别 1-3：Schema、孤立项、链接。

适用于：

• 会话开始时的健康检查
• 快速检查知识库完整性
• 批量创建笔记后

运行时间： 对于最多 200 条笔记的知识库，应在 30 秒内完成。

完整模式

运行全部 8 个类别以及维护信号。

适用于：

• 定期进行全面健康检查
• 知识库发生重大变化后（批量处理、大规模重组）
• 感觉知识库“有些不对劲”时
• 开始 /architect 或 /reseed 会话前

运行时间： 对于较大的知识库，可能需要 1-3 分钟，因为需要分析描述质量并检查 {vocabulary.topic_map} 的一致性。

三空间模式

仅运行类别 5：边界违规检查。

适用于：

• 执行 /reseed 后，确认边界完好无损
• 搜索结果似乎受到污染时（知识查询中出现 ops 内容）
• 启用或禁用 self/ 时
• 调试“为什么我的搜索会返回奇怪的结果？”

运行时间： 应在 30 秒内完成。

---

边缘情况

空知识库

有 0 条笔记的知识库并非不健康，而是全新的。报告：

Notes scanned: 0 | Topic maps: 0 | Inbox items: N
All categories PASS (no notes to check)
Maintenance Signal: inbox has N items — consider /reduce to start building knowledge

禁用 Self 空间

当 self/ 不存在时：

• 跳过 self 空间边界检查（5b、5d、5e 入站）
• 但要检查 ops/ 是否正确吸收 self 空间内容（5f）
• 在报告中注明：“self/ 已禁用 — 已相应调整边界检查”

无语义搜索

当 qmd/MCP 工具不可用时：

• 跳过所有依赖语义搜索的检查
• 在报告中注明：“语义搜索不可用 — 已跳过部分检查”
• 仍会运行所有基于文件的检查（Schema、孤立项、链接、边界）

大型知识库（500+ 条笔记）

• 每个类别的文件列表最多显示 10 项，然后汇总
• 如果性能下降，可考虑分批运行检查
• 将建议操作集中在影响最大的项目上

---

与其他技能的集成

健康报告中的发现会提供给其他技能：

发现	提供给	方式
孤立笔记	/reflect	运行 reflect，为孤立笔记查找关联
过时笔记	/reweave	运行 reweave，为旧笔记补充新的关联
描述质量问题	/verify 或手动重写	修正描述以改善检索效果
Schema 违规	/validate	运行验证以修复特定的 Schema 问题
边界违规	手动重组	将文件移至正确的空间
处理吞吐量	/reduce 或 /pipeline	处理收件箱条目以提高比例
{vocabulary.topic_map} 过大	手动拆分或 /architect	将过大的 {vocabulary.topic_maps} 拆分为子级 {vocabulary.topic_maps}
累积的观察	/rethink	审查并分类观察结果
累积的张力	/rethink	解决或消除张力

健康检查到行动的闭环：

/health (diagnose) -> specific findings -> specific skill invocation -> /health (verify fix)

健康检查仅用于诊断——它衡量状态，但不规定变更。/architect 会读取健康报告，并基于研究提出变更方案。这种职责分离很重要：健康检查告诉你哪里出了问题，architect 告诉你为什么出问题以及如何修复。