Wiki Status — 監査と差分

Wiki の現在の状態を計算しています。何が取り込まれたか、前回の取り込み以降に何が新しいか、差分がどのように見えるかです。これにより、ユーザーが追加（差分を取り込む）するか再構築（アーカイブしてすべてを再処理する）するかを決定できます。

開始する前に

1. config を解決 — llm-wiki/SKILL.md の Config Resolution Protocol に従う（CWD を上位に向かって検索 .env → ~/.obsidian-wiki/config → プロンプト setup）。これにより OBSIDIAN_VAULT_PATH、OBSIDIAN_SOURCES_DIR、CLAUDE_HISTORY_PATH、CODEX_HISTORY_PATH が得られます。
2. Vault ルートの .manifest.json を読む — これが取り込み追跡台帳です。

マニフェスト

マニフェストは $OBSIDIAN_VAULT_PATH/.manifest.json にあります。取り込まれたソースファイルをすべて追跡します。存在しない場合は、何も取り込まれていない新しい Vault です。

{
  "version": 1,
  "last_updated": "2026-04-06T10:30:00Z",
  "sources": {
    "/absolute/path/to/file.md": {
      "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_path": "~/.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 から）

OBSIDIAN_SOURCES_DIR の各ディレクトリをすべてのテキストファイルで glob
記録: パス、サイズ、変更日時

Claude History（CLAUDE_HISTORY_PATH から）

Glob: ~/.claude/projects/*/          → プロジェクトディレクトリ
Glob: ~/.claude/projects/*/*.jsonl   → 会話ファイル
Glob: ~/.claude/projects/*/memory/*.md → メモリファイル
記録: パス、サイズ、変更日時、親プロジェクト

Codex History（CODEX_HISTORY_PATH から）

Glob: ~/.codex/session_index.jsonl            → セッション在庫インデックス
Glob: ~/.codex/sessions/**/rollout-*.jsonl    → セッションロールアウトトランスクリプト
Glob: ~/.codex/history.jsonl                  → オプションのローカル履歴ログ
Glob: ~/.codex/archived_sessions/**/rollout-*.jsonl → アーカイブされたロールアウト（ユーザーがアーカイブカバレッジを希望する場合）
記録: パス、サイズ、変更日時、利用可能な場合は cwd から推論されたプロジェクト

ユーザーが以前に指定した他のソース

マニフェストで標準ディレクトリ外のソースパスを確認します。

ステップ 2: 差分を計算

現在のソースをマニフェストと比較します。各ソースファイルを分類します。

ステータス	意味	必要なアクション
New	ディスク上に存在するが、マニフェストに含まれていない	取り込む必要があります
Modified	マニフェストに含まれるが、content_hash と異なる	再取り込みが必要
Touched	マニフェストに含まれるが、mtime が新しく、ハッシュは変わらない	スキップ — コンテンツは同じ、再取り込み不要
Unchanged	マニフェストに含まれ、mtime とハッシュが一致	何もしない
Deleted	マニフェストに含まれるが、ファイルがディスクに存在しない	注記 — Wiki ページは古くなっている可能性があります

マニフェストエントリに content_hash がない場合（古いエントリ）は、mtime 比較のみにフォールバックします。

Claude History の場合、特に以下も計算します：

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

Codex History の場合、特に以下も計算します：

• sessions/** の新規ロールアウトファイル
• session_index.jsonl エントリの更新（セッションタイトル/鮮度の変更）
• アーカイブカバレッジをリクエストされた場合のみアーカイブロールアウト差分

ステップ 3: ステータスを報告

可視性集計（レポートを表示する前に）: すべての Vault .md ページの frontmatter を visibility/internal と visibility/pii タグ値で grep。カウント：

• public = visibility/public タグを持つページ または visibility/ タグがすべてのページ
• internal = visibility/internal タグを持つページ
• pii = visibility/pii タグを持つページ

Overview セクションに Page visibility: N public · M internal · K pii として含めます。すべてのページがタグ付けされていない場合（完全にパブリックな Vault）は、この行をスキップします。

明確なサマリーを表示します：

# Wiki Status

## Overview
- **Total wiki pages:** 6 つのカテゴリにまたがる 87 ページ
- **Page visibility:** 72 public · 11 internal · 4 pii
- **Total sources ingested:** 42
- **Projects tracked:** 6
- **Last ingest:** 2026-04-06T11:00:00Z

## Delta (前回の取り込み以降に変わったもの)

### 新規ソース（取り込まれたことがない）: 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 |
| ... | | |

### 修正されたソース（再取り込みが必要）: 3
| Source | Last ingested | Last modified | Delta |
|---|---|---|---|
| ~/notes/architecture.md | 2026-04-01 | 2026-04-05 | 4 日古い |
| ... | | | |

### 新規プロジェクト（まだ Wiki にない）: 2
- **tractorex** (3 会話、2 メモリファイル)
- **papertech** (1 会話、0 メモリファイル)

### 削除されたソース（取り込まれたが消失）: 0

## Summary
- **取り込み準備完了:** 12 新規 + 3 修正 = 15 ソース
- **最新:** 27 ソース変わらず
- **推奨:** 追加（差分は合計に比べて小さい）

ステップ 4: アクションを推奨

差分に基づいて、以下のいずれかを推奨します：

状況	推奨
差分が小さい（合計の <20%）	追加 — 新規/修正ソースのみを取り込む
差分が大きい（合計の >50%）	再構築 — アーカイブしてすべてを再処理
削除されたソースが多い	Lint を先に実行 — 古いページをチェックしてから決定
初回/空の Vault	全取り込み — すべてを処理
ユーザーがステータスを見たいだけ	アクションなし — ただレポート

ユーザーに以下を伝えます：

• 「X 個の新規ソースと Y 個の修正されたソースがあります。[追加/再構築] をお勧めします。」
• 「[差分を取り込む / ゼロから再構築 / 特定のプロジェクトだけを見る] をしたいですか？」

Insights モード

「Wiki インサイト」「Wiki の中心的なのは何か」「ハブを見せて」「ドメイン間ブリッジ」「最も重要なページは何か」「Wiki 構造」などをユーザーが尋ねるときに発動します。このモードは追加的なもので、差分レポートを置き換えません。Wiki 自体の形状を分析します。

差分レポートがユーザーに何が保留中かを知らせる一方、insights モードはユーザーがすでに構築したものと面白い構造がどこにあるかを知らせます。wiki-lint（問題を見つける）を補完して興味深い構造を浮き彫りにします。

計算内容

まず、wikilink グラフを構築します。 すべての .md ページを glob、すべての [[wikilink]] を抽出、構築：

• incoming[page] = このページにリンクする他のページの数
• outgoing[page] = このページがリンクアウトするページの数
• tags[page] = frontmatter からのタグセット
• category[page] = ディレクトリプレフィックス（concepts/、entities/、skills/ など）

以下のすべてのセクションでこのグラフを再利用します。

---

1. アンカーページ（上位ハブ）。 受け取るリンクが最も多いページ — 荷重を担う概念。

   • すべてのページを incoming カウントでランク付けし、上位 10 を取得
   • 各ページについて、受け取るリンクと送り出すリンクの両方を注記：受け取るリンクが多く かつ 送り出すリンクが多いページはコネクタハブ（最も価値がある）
   • 受け取るリンクが多いが送り出すリンクがゼロのページはシンクハブ — クロスリンカー候補としてフラグ

2. ブリッジページ。 他の場合は切り離されたタグクラスタを接続するページ — それらを削除するとグラフが分割されます。これらはしばしば生のハブカウントより構造的に重要です。

   • 各ページ P について、ページのペア (A, B) を見つけます：
     • A が P にリンク、B が P からリンクされ（またはその逆）
     • A と B は互いにタグを共有しない
     • P は 2 ホップ以内で A のタグクラスタと B のタグクラスタを接続する唯一のパス
   • クロスクラスタペアが P が橋渡しする数でランク付け。上位 5 を表示
   • 各ラベル：「P は [tag-cluster-A] ↔ [tag-cluster-B] を橋渡し」

3. タグクラスタ凝集度。 ≥ 5 ページを持つ各タグについて、そのタグ内のページがどの程度密に相互接続されているかをスコア化：

   • n = このタグを共有するページの数
   • actual_links = このタググループ内の任意の 2 つのページ間の wikilink の数
   • cohesion = actual_links / (n × (n−1) / 2) — 実際のリンク数対最大可能数の比率
   • 断片化されたクラスタ（凝集度 < 0.15、n ≥ 5）：これらのページは主題を共有していますが、まとまっていません。クロスリンカーターゲットとして表示します。
   • 凝集度による上位 5 タグ（最も強いクラスタ）と下位 5（最も断片化された）を表示

4. 驚きの接続。 カテゴリ境界を超える非明白な wikilink — 予期しなさの程度でスコア化：

   • カテゴリ境界を超える各 wikilink をスコア化（例：concepts/ → entities/、skills/ → synthesis/）：
     • リンク元ページまたは主張が ^[ambiguous] でマークされている場合 +3（不確かな接続、見直す価値あり）
     • リンク元ページが ^[inferred] でマークされている場合 +2（合成、直接述べられていない）
     • カテゴリが異なる知識層にある場合 +2（例：concepts ↔ entities は concepts ↔ concepts より予期しない）
     • ソースページが ≤ 2 個のリンク（周辺）を持つが、ターゲットが ≥ 8（ハブ）を持つ場合 +2 — エッジから中心への予期しない到達
   • スコア上位 5 の接続を各プレーンな言語の理由とともに表示

5. 孤立に近い提案。 上位 10 ハブからリンクされているが、送り出すリンクがゼロのページ。高トラフィック領域の行き止まり — クロスリンカー候補として最適。

6. 粗いクラスタ。 アンカーページを優勢なタグでグループ化。（単純なタグ交差 — 向き付けのためだけ。）

7. グラフ差分（前回の実行以来）。 現在のリンクグラフを前の _insights.md に保存されたスナップショットと比較：

   • 前の _insights.md の末尾の <!-- GRAPH_SNAPSHOT: ... --> 行を読む（存在する場合） — コンパクト JSON エッジリストを含む
   • 計算：追加されたページ、削除されたページ、作成された新しい wikilink、削除された wikilink
   • フラグ：前回の実行で孤立していたが、今は受け取るリンクを持つページ（「新たに接続：X、Y」）
   • フラグ：前回の実行以降に受け取るリンクを失ったページ（「リンクターゲットは名前が変更された可能性：A、B」）
   • 前のスナップショットが存在しない場合、このセクションをスキップ

8. 推奨質問。 この Wiki 構造が一意の立場にある質問を答えられるか、またはギャップを明らかにする：

   • ^[ambiguous] 主張から：「解決：X と Y の正確な関係は何か？」
   • ブリッジページから：「探索：P が [cluster-A] を [cluster-B] に接続するのはなぜか？」
   • 受け取るリンクがゼロのページから：「リンク：X は受け取るリンクがない — 何がそれを参照すべきか？」
   • 断片化されたクラスタから（凝集度 < 0.15）：「監査：タグ [T] をより焦点を絞ったサブタグに分割すべきか？」
   • AMBIGUOUS を優先し、ブリッジノード、孤立を優先して最大 7 を表示

---

出力

結果を Vault ルートの _insights.md に書き込みます。自由に上書き — 再生成可能です。最後に、次の実行が差分を取ることができるように、コンパクトグラフスナップショットを HTML コメントとして埋め込みます。

# Wiki Insights — <TIMESTAMP>

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

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

## Tag Cluster Cohesion
### 最も結束力がある（よくリンクされている）
- **#ml** — 12 ページ、凝集度 0.41
### 最も断片化（クロスリンカーターゲット）
- **#systems** — 7 ページ、凝集度 0.06 ⚠️ このタグでクロスリンカーを実行

## 驚きの接続 (上位 5)
- [[concepts/scaling-laws]] → [[entities/gordon-moore]] — スコア 5
  - 理由：クロスレイヤー（concepts ↔ entities）、^[inferred] としてマーク
- ...

## 孤立に近い (ハブ近くの行き止まり)
- [[concepts/foo]] — 3 つのハブからリンクされ、0 個のアウトバウンドリンク

## 粗いクラスタ
- **#ml** — transformer-architecture, attention-mechanism, scaling-laws
- **#systems** — distributed-consensus, raft, paxos

## グラフ差分（前回の実行以来）
- +3 個の新規ページ、+11 個の新規 wikilink
- 新たに接続：[[concepts/bar]]、[[entities/baz]]
- リンク喪失：[[references/old-paper]]（ターゲットは名前が変更された可能性）

## 質問する価値がある
1. 解決：`scaling-laws` と `moore's-law` の正確な関係は何か？（^[ambiguous] 主張）
2. 探索：`exponential-growth` が #ml と #economics を橋渡しするのはなぜか？
3. リンク：`references/foo.md` は受け取るリンクがない — 何がそれを参照すべきか？
4. 監査：タグ `#systems` を分割すべきか？（凝集度 0.06、7 ページ）

<!-- GRAPH_SNAPSHOT: {"nodes":["concepts/foo","entities/bar"],"edges":[["concepts/foo","entities/bar"]]} -->

ファイルを書き込んだ後、log.md に追加：

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

スキップする場合

• 20 ページ未満の Vault — グラフ構造が不十分。ユーザーに伝えてスキップ。
• 新しい wiki-rebuild の後 — 少なくとも 1 回の取り込みが発生するまで待つ。

注

• マニフェストが存在しない場合、すべてを「new」として報告し、全取り込みを推奨
• このスキルは読み取りと報告のみ — 何も修正しません（_insights.md を書き込むことを除く、これは再生成可能）
• 実際の取り込み作業は、取り込みスキル（wiki-ingest、claude-history-ingest、codex-history-ingest、data-ingest）で実行
• これらのスキルは完了後にマニフェストを更新する責任があります