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 と異なる	再取り込みが必要
更新のみ	ファイルがマニフェストにあり、mtime は新しいがハッシュは変わっていない	スキップ — 内容は同一のため、再取り込みは不要
変更なし	ファイルがマニフェストにあり、mtime とハッシュの両方が一致する	対応不要
削除済み	Vault 内のソースがマニフェストにあるが、ファイルがディスク上に存在しない	記録する — Wiki ページが古くなっている可能性がある
利用不可	マシンローカルのソース（ホーム相対キーまたは絶対パスキー）がこのマシンにない — たとえば、別のホストから同期されたエントリ	スキップ — 削除済みとして報告したり、クリーンアップしたりしないでください。取り込みを実行したマシンには存在する可能性があります

マニフェストのエントリに content_hash がない場合（古いエントリ）は、mtime の比較のみを使用します。

Claude の履歴については、次の項目も計算します。

• 新しいプロジェクト（~/.claude/projects/ 内にある、マニフェストに記録されていないディレクトリ）
• 既存のプロジェクト内の新しい会話
• 更新されたメモリファイル

Codex の履歴については、次の項目も計算します。

• sessions/** 配下の新しいロールアウトファイル
• 更新された session_index.jsonl のエントリ（セッションのタイトル／鮮度の変更）
• アーカイブ対象範囲が指定されている場合に限り、アーカイブ済みロールアウトの差分

ステップ 3：ステータスを報告する

可視性の集計（レポートの生成前）： vault 内のすべての .md ページのフロントマターを visibility/internal と visibility/pii のタグ値で Grep します。次のように数えます。

• public = visibility/public タグがあるページ、または visibility/ タグが一切ないページ
• internal = visibility/internal タグがあるページ
• pii = visibility/pii タグがあるページ

Overview セクションに Page visibility: N public · M internal · K pii を含めます。すべてのページにタグがない場合（完全に public な vault）は、この行を省略します。

明確な要約を提示します。

# 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：トークン使用量を算出する

ステータスの要約を作成した後、トークン使用量の推定値を算出します。

1. ティアごとのページサイズ — すべての .md ページを Glob します。各ページの tier: フロントマターフィールドを読み取ります（低コストの grep）。ページをティアの値（core、supporting、peripheral。未設定の場合は supporting）ごとにグループ化します。

2. トークン数の推定 — 各ページのトークン数を file_size_bytes / 4（4 文字を 1 トークンとするヒューリスティック。実際のトークナイザーは不要）で推定します。ティアごと、および合計のトークン数を算出します。

3. インデックスのみの推定値 — インデックスのみを処理する場合のコストを推定します。各ページのフロントマターについて len(title) + len(summary) + len(tags) の合計（平均で各約 100 文字）を 4 で割ります。

4. 一般的なクエリの推定値 — インデックスのみの推定値 + 全ページの平均全文読み取りコスト 5 ページ分（total_chars / total_pages * 5 / 4）。

5. しきい値の確認 — 設定から WIKI_TOKEN_WARN_THRESHOLD を読み取ります（デフォルト：100000）。値が 0 の場合、警告を省略します。wiki 全体のトークン推定値がしきい値を超える場合は、上記のテンプレートにある 3 つの改善案とともに ⚠️ 警告を出します。

6. 標準ステータス実行ごとに含める — 通常モードとインサイトモードの両方に含めます。手法に関する注記（4 chars/token heuristic）は表の下に脚注として記載します。

ステップ 4：次に行うこと

以前の 1 行だけの Recommendation を、優先順位を付けた 次に行うこと セクションに置き換えます。表示する前に、次のシグナルを集めます。

4a：シグナルを集める

0. ステージング済みの書き込みが保留中（WIKI_STAGED_WRITES=true の場合のみ）— $OBSIDIAN_VAULT_PATH/_staging/**/*.md および **/*.patch.md を Glob します。新規ページとパッチを別々に数えます。最も古いファイルの経過時間（mtime）を報告します。ステージングされたファイルが 1 つでもある場合は、意図を示す最も強いシグナルであるため、常に最初に記載します（LLM はすでに作業を済ませており、人間が確認するだけです）。

1. _raw/ ファイル — $OBSIDIAN_VAULT_PATH/_raw/ のトップレベルにあるファイルのうち、.gitkeep ではないものをすべて列挙します。_archived/ サブディレクトリは除外します（出所の確認用に保管されている、すでに昇格済みの下書きであり、保留中の作業ではありません）。件数とファイル名を報告します。

2. 古くなったコアページ — vault 内のすべての .md ファイルを確認します。updated フロントマターフィールドの日付が今日より 90 日以上前で、かつ被リンクが 5 件以上あるページを「古くなった」と見なします（つまり「コア」ページであり、他のページが依存しています）。名前と最終更新日を列挙します。

3. 孤立ページ — 被リンクが 0 件のページです。計算方法：すべての .md ページを Glob し、すべての [[wikilink]] を抽出して、各ページへの参照数を数え、incoming == 0 のページを集めます。最大 5 件の名前を表示し、合計件数を報告します。

4. 統合の機会 — hot.md を確認し、最近の /wiki-synthesize 実行の要約があるか調べます。最後の統合実行で N 件の機会が報告されていた場合は、その件数を表示します。最近の統合実行がない場合（過去 14 日以内の hot.md または log.md に記録がない場合）は、「統合スキャンの実施期限超過」として示します。

5. ソースの差分 — ステップ 2 から、取り込み可能な新規ソースと変更済みソースの件数を取得します。

6. Lint の問題 — log.md を確認し、最近（過去 30 日以内）の /wiki-lint 実行があるか調べます。最近の実行でリンク切れまたはフロントマター不足が記録されていた場合は、その件数を表示します。ログに Lint の実行記録がない場合は、「最近 Lint が実行されていません」として示します。

4b: ランク付けして表示

各カテゴリを評価し、ランク付けしたリストを最大6項目まで出力します。常に次の優先順位でランク付けしてください（件数が0、または報告する内容がないカテゴリはスキップします）。

優先度	カテゴリ	条件
0	ステージ済みの書き込み待ち	_staging/ に .md／.patch.md がある場合（WIKI_STAGED_WRITES=true の場合のみ）
1	_raw/ の未処理ファイル	_raw/ にファイルがある場合
2	古くなったコアページ	更新から90日以上経過し、かつ被リンクが5件以上あるページ
3	孤立ページ	ウィキリンクの被リンクがないページ
4	統合の機会	前回の統合実行からの機会数、またはスキャンの期限超過
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」「what's central in my wiki」「show me the hubs」「cross-domain bridges」「what pages are most important」「wiki structure」などを尋ねた場合に起動します。このモードは追加機能です。差分レポートを置き換えるのではなく、ウィキ自体の構造を分析します。

差分レポートがユーザーに保留中の項目を伝えるのに対し、インサイトモードは、すでに構築したものや、興味深い構造が存在する場所を伝えます。問題を見つける wiki-lint を補完し、興味深い構造を明らかにします。

計算する項目

まず、グラフアナライザーを実行します。 手動でのウィキリンク解析の代わりに、1つのコマンドですべての元データを取得できます。

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 — 意外性の高さでランク付けされたコミュニティ間のエッジ。コミュニティのペアが繰り返される前に、ペアごとに1件が示され、それぞれに2つのコミュニティ名を記した 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 は 2 つのページ間の最短リンクチェーンを返します。--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))。ペアが繰り返される前にコミュニティペアごとに 1 つのエッジであるため、単一のハブがリストを埋め尽くすことはできません）
   • アナライザーには見えないコンテンツシグナルで候補を再ランク付けします：
     • リンク元のページまたは主張に ^[ambiguous] が付いている場合は +3（不確実なつながりで、見直す価値があります）
     • リンク元のページに ^[inferred] が付いている場合は +2（直接述べられておらず、合成されたものです）
     • カテゴリが異なるナレッジレイヤーにある場合は +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: の変更を提案します。ページに tier: を書き込んではいけません。候補を提示するだけにして、判断は人間に委ねます。

   • core への昇格： 被リンクが5件以上あるページ、またはブリッジの上位5位に入るページのうち、現在 tier: supporting であるか、tier: フィールドがないもの
   • peripheral への降格： 被リンクが1件以下で、90日以上更新されていないページのうち、現在 tier: supporting または tier: core であるもの
   • 候補は最大10件（昇格を先に、次に降格）まで、次の形式で表示します。

     Tier の候補：
     ↑ core    [[concepts/attention-mechanism]] — 被リンク14件、現在はtier=supporting
     ↑ core    [[entities/andrej-karpathy]]     — ブリッジ（クラスターのペア3組）、現在は未設定
     ↓ peripheral [[concepts/old-concept]]       — 被リンク0件、120日間更新なし
     

   • 被リンクの多いページがすべて tier: core で、被リンクの少ないページがすべて tier: peripheral である場合は、「Tier の割り当ては適切です — 変更候補はありません。」と出力します。

9. 質問候補。 この Wiki の構造だからこそ回答できる質問、または不足を明らかにする質問です。

   • ^[ambiguous] の主張から（コンテンツスキャンによるもの。analyser はこれを認識しません）： 「解決：X と Y の正確な関係は何ですか？」
   • suggested_questions から（すでに生成されています）：bridge_node → 「探索：…」、sink_hub → 「リンク：…」、isolated_nodes → 「リンク：…」、low_cohesion → 「監査：…」。それぞれ対応する接頭辞の形式に書き換えます。
   • 最大7件まで表示し、AMBIGUOUS を最優先に、次にブリッジノード、シンクハブ／孤立ノード、結合度の監査の順に優先します。

---

出力

結果を Vault のルートにある _insights.md に書き込みます。自由に上書きできます。再生成可能なファイルです。最後に、analyser の snapshot フィールドを HTML コメントとしてそのまま埋め込みます。これにより、次回の実行で --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 の直後 — 少なくとも1回の取り込みが行われるまで待ちます。

均衡モード

ユーザーが「Vault は均衡状態ですか」「Wiki の均衡状態」「Vault は収束していますか」「メンテナンスは完了しましたか」「スキル同士が競合していますか」「すべてのメンテナンススキルで残っている作業は何ですか」と尋ねた場合に起動します。

メンテナンススキルは、1つの共有 Vault を対象とするゲームのプレイヤーです。それぞれに手（lint の修正、重複の統合、新しいリンク、タグの正規化）があり、それぞれ独自の目的に基づいて Vault を評価します。どのプレイヤーにも有利な逸脱がなく、すべての監査パスで変更が提案されないとき、Vault は均衡状態にあります。これが「メンテナンス完了」を示す真のシグナルです。スキル同士が互いの変更を取り消すことがあるため、単一のスキルが問題なしと報告するよりも確かな指標です。

このモードでは、プレイヤーに対して読み取り専用で実行します。すべての監査をレポートのみの形式で実行し、変更を適用させてはいけません。_insights.md のスナップショット行以外には何も書き込みません。

プレイヤー

プレイヤー	監査のみの実行方法	手として数えるもの
wiki-lint	obsidian-wiki lint "$OBSIDIAN_VAULT_PATH" --json	findings 内の各指摘（stats.findings の件数を合計）
wiki-dedup	監査モード（--merge と --auto を指定しない）	HIGH または MEDIUM の重複ペア各1件
cross-linker	監査のみ実行 — 提案リンクを報告し、挿入はしない	リンクを追加する対象となる、未リンクの各言及
tag-taxonomy	Step 1 の監査のみ — ずれを報告し、正規化はしない	名前変更または削除の対象となるタグ各1件

決定論的なのは wiki-lint だけです。他の3つは LLM による処理のため、その件数は各レポートから得られる推定値です。正確な値であるかのように示すのではなく、その旨を出力に記載してください。

報告内容

# 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 と報告し、今メンテナンススキルを実行しても何も変更されないことを明確に伝えます。

振動の検出

カウントをゼロにした後も値が戻り続けるプレイヤーがいる場合、2 つのプレイヤーが競合しています。典型的なケースは、tag-taxonomy がタグを正規化する一方で、取り込みスキルのデフォルト設定がそのタグを再追加し続けるため、Vault がいつまでも循環し、収束しない状況です。

既存の GRAPH_SNAPSHOT の隣に、_insights.md のスナップショットを追記します。

以前の EQUILIBRIUM_SNAPSHOT の行を読み取ります（最後の 5 件を保持し、それより古いものは削除します）。次のように比較します。

• 実行をまたいでプレイヤーの値が 0 → N → 0 → N と変化している場合は振動中です。プレイヤー名と、該当する変更を再導入する可能性が高い対抗プレイヤー（書き込みを行うスキル）の名前を示します。
• カウントが増加し続けるだけのプレイヤーは遅れています。誰もそのプレイヤーを実行していません。
• 以前のスナップショットがない場合は「初回実行、比較基準はまだありません」と報告し、比較を省略します。

振動は報告するものであり、修正するものではありません。どちらのプレイヤーの目標を優先するかは、人が判断して解決します。通常は、別のメンテナンス実行ではなく、_meta/taxonomy.md または所有者の AGENTS.md のルール変更で対応します。

ソースの履歴

保留中の変更は、ソースごとに均等に分布しているわけではありません。各プレイヤーの調査結果に含まれるページについて、どのマニフェストソースが作成したかを調べます（.manifest.json → pages_created / pages_produced）。

1 つのソースが 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 未満の Vault では、監査結果はノイズになるためスキップします。
• いずれかのプレイヤーの監査をレポート専用形式で正常に実行できない場合は、その行を省略し、カウントを推測せずに、どのプレイヤーが欠けているかを明記します。

注意事項

• マニフェストが存在しない場合は、すべてを「新規」として報告し、完全な取り込みを推奨します。
• このスキルは読み取りと報告のみを行い、何も変更しません（インサイトモードで _insights.md を書き込む場合を除きます。これは再生成可能です）。
• 実際の取り込み処理は、取り込みスキル（wiki-ingest、claude-history-ingest、codex-history-ingest）が行います。
• それらのスキルは、処理の完了後にマニフェストを更新する責任を負います。

Vault 書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる情報源ではありません。$QMD_WIKI_COLLECTION が空、または設定されていない場合は、この手順をスキップします。このスキルが Vault の Markdown を書き込んだ、または書き換えた後にのみ実行します。QMD の更新に失敗しても、Vault の変更をロールバックしないでください。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>