health

ランタイム設定（ステップ 0 — 処理を開始する前）

ドメイン固有の動作を設定するため、以下のファイルを読み込みます。

1. ops/derivation-manifest.md — 用語のマッピング、フォルダー名、プラットフォームに関するヒント

   • ノートフォルダー名には vocabulary.notes を使用します
   • インボックスフォルダー名には vocabulary.inbox を使用します
   • 出力するノートの種類名には vocabulary.note を使用します
   • MOC／トピックマップの参照には vocabulary.topic_map を使用します
   • 複数形には vocabulary.topic_maps を使用します

2. ops/config.yaml — 処理の深さ、しきい値

3. 3空間のリファレンス — 境界ルールについては ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md（full モードと three-space モードでのみ読み込みます）

4. テンプレート — 検証に必要なスキーマフィールドを把握するため、テンプレートファイルを読み込みます

これらのファイルが存在しない場合（初期化前の実行または単独での使用）は、共通のデフォルト値を使用します。

• ノートフォルダー：notes/
• インボックスフォルダー：inbox/
• トピックマップ：notes/ 内のトピックマップ

---

今すぐ実行

対象：$ARGUMENTS

呼び出しモードをすぐに判定します。

入力	モード	実行するカテゴリ
空または quick	Quick	1（スキーマ）、2（孤立ファイル）、3（リンク）
full	Full	8カテゴリすべて
three-space	Three-Space	5（3空間の境界）のみ

以下の手順を実行します。

1. 引数からモードを判定します
2. ボルトをスキャンします — すべてのノートファイル、{vocabulary.topic_map} ファイル、インボックス項目、ops ファイルを一覧化します
3. 該当する診断カテゴリを順番に実行します（1～8）
4. 以下のしきい値に基づいて、各結果を PASS、WARN、FAIL に分類します
5. 条件に基づくメンテナンスシグナルを提示します（しきい値テーブルと照合します）
6. 具体的なファイルパス、件数、推奨アクションを含むヘルスレポートを生成します
7. レポートを ops/health/YYYY-MM-DD-report.md に書き込みます

今すぐ開始してください。 各診断カテゴリの詳細は以下を参照してください。

プラットフォームへの適応

チェックは、プラットフォームがサポートする機能に合わせて調整されます。

• セマンティック検索（qmd）が設定されていない場合、セマンティック検索に依存するチェックはスキップし、その旨を記録します
• フックが利用できない場合、検証は規約のみに基づき、自動的な適用は行われないことを記録します
• self/ ディレクトリが存在しない場合（設定で無効化されている場合）、self-space のチェックはスキップします。ただし、self-space の内容が ops/ に正しく取り込まれていることを確認します

プラットフォームにない機能ではなく、確認できる内容を報告してください。

---

8つの診断カテゴリ

カテゴリ 1：スキーマ準拠（quick、full）

チェック内容： {vocabulary.notes}/ および self/ が有効な場合は self/memory/ 内のすべての {vocabulary.note} に、必須フィールドを備えた有効な YAML フロントマターがあることを確認します。

確認方法：

# 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 フィールドに少なくとも1つの Wiki リンクが含まれていること

${CLAUDE_PLUGIN_ROOT}/reference/ に validate-kernel.sh が存在する場合は、実行して結果を含めます。

しきい値：

条件	レベル
YAML フロントマターのないノートが1つでもある	FAIL
description フィールドのないノートが1つでもある	WARN
topics フィールドのないノートが1つでもある	WARN
無効な列挙型の値が1つでもある	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：孤立ファイルの検出（quick、full）

チェック内容： すべての {vocabulary.note} に、別のファイルからの Wiki リンクが少なくとも1つあることを確認します。

確認方法：

# 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（想定どおり — 振り返りフェーズ待ち）
作成から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：リンクの健全性（quick、full）

チェック内容： すべてのファイル内のすべての 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

WARN ではなく FAIL にする理由： リンク切れは、読者への約束を破るものです。読者がたどった [[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：説明の品質（full のみ）

チェック内容： すべての {vocabulary.note} の説明に、タイトルの言い換えではない、実質的な情報が含まれていることを確認します。

確認方法：

各 {vocabulary.note} について：

1. タイトルを読む（拡張子を除いたファイル名）
2. YAML フロントマターの 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：3 つのスペースの境界チェック（full、three-space）

チェック内容： コンテンツが self/、{vocabulary.notes}/、ops/ の境界を守っていることを確認します。それぞれのスペースには目的があり、混同すると検索品質、ナビゲーション、信頼性が損なわれます。

このチェックを実行する前に： ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md を読み、境界の仕様を確認してください。

検出する 6 つの混同パターン：

5a. Notes への Ops 混入（インフラの侵入）

キューの状態、健全性メトリクス、タスクファイル、処理成果物が {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}/ 内に ops パターンのコンテンツがある	WARN

5b. Notes への Self 混入（アイデンティティの汚染）

エージェントのアイデンティティや方法論が、ユーザーのナレッジグラフに混在している状態です。エージェントの運用上の所見が、ユーザーの {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}/ 内にエージェントの内省に関するコンテンツがある	WARN

5c. Ops への Notes 混入（閉じ込められた知識）

セッションログ、観察記録、または ops ファイル内に閉じ込められている、本来は {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/ にある	INFO（意図的な場合もありますが、レビュー対象としてフラグを立ててください）

5d. Ops への Self 混入／Self への Ops 混入

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 への Notes 混入

ドメイン知識が {vocabulary.notes}/ ではなく self/ に保存されている状態です。

検出方法：

# 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/ が無効な場合）

self/ が無効な場合、ops/ が self スペースのコンテンツを適切に受け入れていることを確認します。目標と引き継ぎ情報が {vocabulary.notes}/ に浮いたままではなく、ops/ に保存されていることを確認してください。

検出方法：

# 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
Self が存在しない場合の影響（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: 処理スループット (full のみ)

チェック内容: インボックスとナレッジの比率。高い比率はコレクターの誤謬 (collector's fallacy) を示します。つまり、処理する以上の量を収集している状態です。

チェック方法:

# 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: 古いノートの検出 (full のみ)

チェック内容: 最近変更されておらず、かつリンク密度が低いノート。古さは (低いリンク密度 + N 件の新しいノートが追加されて以降の活動がないこと) に基づく条件で判定され、純粋にカレンダーに基づくものではありません。

チェック方法:

各 {vocabulary.note} について:

1. 最終変更日を確認する (stat または git log)
2. 被リンク数を数える (孤立検出と同じですが、boolean ではなくカウント)
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} の一貫性 (full のみ)

チェック内容: 各 {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）が1つでもある	孤立したメモに対して /reflect を実行
リンク切れ	1つでもある	壊れた参照を直ちに修正
古いメモ	リンクが少なく、古い	/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つある場合は、3件ではなく1件の指摘とします）
• 大規模な保管庫では、カテゴリごとの詳細を具体的なファイル10件までに制限し、その後は「...その他15件」のように要約します

FAIL と WARN を区別する

レベル	意味	必要な対応
FAIL	構造上の問題 — 何かが壊れている	問題が拡大する前に修正する
WARN	改善の機会 — 最適ではない状態	都合のよいときに対応する
PASS	カテゴリは健全	対応不要
INFO	注目すべきだが、対応は不要	状況を理解するための情報

FAIL の対象： リンク切れ（グラフの破損）、永続化した孤立メモ（> 7 days）、重大なスキーマ違反（frontmatter が完全に欠落）、重大な境界違反。

それ以外の最適ではない状態はすべて WARN とします。

---

モード固有の動作

クイックモード（デフォルト）

カテゴリ 1〜3 のみを実行します: スキーマ、孤立、リンク。

使用する場合:

• セッション開始時のヘルスチェック
• ボールトの整合性の簡単な確認
• ノート作成をまとめて行った後

実行時間: ノート数 200 までのボールトでは 30 秒以内に完了するはずです。

フルモード

8 つのカテゴリすべてに加えてメンテナンスシグナルを実行します。

使用する場合:

• 定期的な包括的ヘルスレビュー
• ボールトに大きな変更を加えた後（大量のバッチ処理、再構築）
• ボールトについて「何かおかしい」と感じたとき
• /architect または /reseed セッションの前

実行時間: 説明品質の分析と {vocabulary.topic_map} の一貫性チェックのため、大きなボールトでは 1〜3 分かかることがあります。

スリースペースモード

カテゴリ 5 のみを実行します: 境界違反チェック。

使用する場合:

• /reseed の後に境界が保たれていることを確認するとき
• 検索結果が汚染されているように見えるとき（ナレッジのクエリに運用コンテンツが混ざる）
• 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 ツールが利用できない場合:

• セマンティック検索に依存するチェックはスキップします
• レポートに記載します: 「セマンティック検索が利用できません — 一部のチェックをスキップしました」
• ファイルベースのチェック（スキーマ、孤立、リンク、境界）はすべて引き続き実行されます

大きなボールト（ノート 500 件以上）

• カテゴリごとのファイル一覧は 10 件までに制限し、その後は要約します
• パフォーマンスが低下する場合は、チェックをバッチで実行することを検討します
• 推奨アクションは影響の大きい項目に絞ります

---

他のスキルとの統合

ヘルスレポートの検出事項は他のスキルに引き継がれます:

検出事項	引き継ぎ先	方法
孤立ノート	/reflect	reflect を実行して孤立ノートのつながりを見つけます
古いノート	/reweave	reweave を実行して古いノートを新しいつながりで更新します
説明品質の問題	/verify または手動での書き直し	説明を修正して検索精度を改善します
スキーマ違反	/validate	バリデーションを実行して特定のスキーマ問題を修正します
境界違反	手動での再構築	ファイルを正しいスペースに移動します
処理スループット	/reduce または /pipeline	インボックス項目を処理して比率を改善します
{vocabulary.topic_map} が大きすぎる	手動での分割または /architect	大きすぎる {vocabulary.topic_map} をサブ {vocabulary.topic_map} に分割します
蓄積された観察	/rethink	観察をレビューしてトリアージします
蓄積された緊張	/rethink	緊張を解決または解消します

ヘルスからアクションへのループ:

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

ヘルスは診断のみです — 状態を測定するもので、変更を指示するものではありません。/architect はヘルスレポートを読み、調査に基づいて変更を提案します。この分離は重要です: ヘルスは何が問題かを伝え、architect はなぜ、どのように修正するかを伝えます。