AIエージェント向けのwikiレイヤーを出荷しました。情報源（唯一の正）としてmarkdown + gitを使い、その上にbleve（BM25）+ SQLiteのインデックスを載せています。まだベクトルDBやグラフDBはありません。
ローカルで ~/.wuphf/wiki/ に動作し、必要ならgit cloneして持ち運べます。
形は、Karpathyがしばらく回り続けているものと同じです。つまり、LLMネイティブな知識の基盤で、エージェントがそこから読み、そこへ書き込む。これにより、毎朝貼り直されるのではなく、セッションをまたいでコンテキストが積み重なります。そのアイデアの多くの実装は、Postgres、pgvector、Neo4j、Kafka、そしてダッシュボードに着地します。
そこで、重いものを何か足す前に、基本に立ち返って markdown + git がどこまで行けるかを確かめたかったのです。
これがやること：
-> 各エージェントは agents/{slug}/notebook/.md にプライベートなノートブックを持ちます。加えて、team/. にある共有チームwikiへのアクセスも持ちます。
-> 下書きからwikiへの昇格フロー。ノートブックのエントリはレビュー（エージェントまたは人）され、バックリンク付きで正規のwikiへ昇格します。小さなステートマシンが、有効期限と自動アーカイブを制御します。
-> エンティティごとの事実ログ：追加専用のJSONLが team/entities/{kind}-{slug}.facts.jsonl にあります。合成（シンセサイズ）ワーカーが、N件の事実ごとにそのエンティティのブリーフを再構築します。コミットは「Pam the Archivist」という別のgitアイデンティティで行われるため、git logで来歴が見えるようになります。
-> [[Wikilinks]]。壊れたリンクの検出は赤で表示されます。
-> 矛盾、古いエントリ、壊れたwikilinksのための毎日 lint クロン。
-> /lookup スラッシュコマンドに加えて、引用付き検索のためのMCPツール。短いルックアップはBM25へ、ナラティブなクエリは引用回答ループへ振り分けるヒューリスティック分類器を使います。
基盤（サブストレート）の選択：
耐久性のためのMarkdown。wikiは実行環境より長生きし、ユーザーはあらゆるバイトをそのまま持ち去れます。BM25のためのBleve。構造化メタデータ（事実、エンティティ、エッジ、リダイレクト、supersedes）のためのSQLite。まだベクトルはありません。現在のベンチマーク（500アーティファクト、50クエリ）は、BM25単体だけでrecall@20が85%を超えます。これは内部の出荷ゲートです。クエリのクラスがそれを下回った場合の、事前コミットされたフォールバックがsqlite-vecです。
正規（カノニカル）IDは最上位の存在です。事実IDは決定的で、文のオフセットを含みます。正規スラッグは一度だけ割り当てられ、リダイレクトのスタブを介してマージされ、決して名前変更されません。再構築は、論理的には同一であっても、バイト単位で同一ではありません。
既知の制限：
-> リコールのチューニングは継続中です。ベンチマークでの85%は、普遍的な保証ではありません。
-> 合成品質は、エージェントの観測品質により上限が決まります。ゴミの事実を入れれば、ゴミのブリーフが出ます。lintパスが助けになります。これは判断エンジンではありません。
-> 今日のスコープは一オフィスのみ。オフィス間のフェデレーションはありません。
デモ。5分のターミナルウォークスルーで、5つの事実を記録し、シンセサイズを起動し、ユーザーのLLM CLIをシェルアウトし、結果をPamのアイデンティティでコミットします：
