課題
XなどのSNSで「これは便利そう」と思ったリポジトリをブックマークしても、いざ開発を始めると『あれ、あのライブラリ何だったっけ』となって思い出せない — これがLibrAIumの出発点。個人開発者にとって、断片的に集めた「良さそうな道具」の記憶は、必要になった瞬間にこそ取り出せなければ意味がない。単なるブックマーク集では、後から自分の文脈で検索・比較したり、なぜそれを選ぶべきかの根拠にたどり着いたりできない。
アプローチ
解決策は、蔵書をローカルgitリポジトリ上のプレーンなファイル(1リポジトリ = 1 Markdownファイル)として置き、データベースを一切持たないこと。UIはTauri v2 + Rustコア + Svelte 5(runes)のデスクトップアプリで、パース・検索・git・HTTPといった重い処理は型付きのRust側(24のTauri IPCコマンド)に寄せ、システムWebViewを使うことでChromiumを同梱しない小さなネイティブバイナリにしている。最大の設計判断は、同じディスク上の蔵書を2つの独立したコンシューマ — デスクトップアプリと、Claude Code向けのMCPサーバー(Node/stdio) — が共有する点で、MCP経由だからこそエージェントが蔵書を『ツール』として直接呼び出し、依存先を提案できる。名前に反して埋め込みのLLMやモデルキー・埋め込みベクトルは持たず、『AI』はあくまでClaude Codeが叩く検索面(MCP)である。GitHubトークンはOSキーチェーンに置き(keyring)、git操作はlibgit2ではなくgit CLIをラップして既存の認証情報をそのまま使う、といった細部も『秘密情報はファイルに置かない/セットアップ不要』という制約から選ばれている。
エンジニアリング成果
ハイライト
02フロントマター形式(14フィールドのEntryMetaスキーマ)をRustコア(store.rs / frontmatter.rs)とNode(mcp-server/lib/store.js)で意図的に二重実装し、デスクトップアプリとMCPサーバーが互いに依存しないようにした。両者がずれないよう、scripts/conformance.mjs が同じフィクスチャを両パーサに与え、パース結果の一致・不正入力の両側での拒否・バイト単位で同一の再シリアライズ・関数コーパス(slugify等)の一致を要求する。
各エントリには、第三者の評価を出典・日付付きで集約した『## Reception』セクション(不満・採用事例・制約・移行シグナル)を持たせ、これを検索対象そのものにした。8番目のMCPツール find_by_reception は、この散文をシグナル別に走査し、該当した根拠の箇条書きごと返すことで、ストレージ形式を一切変えずに『文書化された落とし穴を持つ棚のリポジトリは?』といった問いに答える。
エントリ本文にはGitHubの説明文やgit同期された外部コンテンツが埋め込まれ、ページのスクリプトはTauriのIPCに到達しうる。そのため src/lib/markdown.js は marked のレンダラを差し替えて生HTMLをテキストへエスケープし、http(s)/mailto/相対のみを許可、さらに制御文字やBOMをコードポイント単位で除去してスキームの区切りを挟み込むタイプのバイパスを潰している。エスケープを一次防御・CSPを二次防御とする多層構成で、tests/markdown.test.mjs で検証している。
検証の入口を scripts/verify-all.sh の1本に集約し、データ検証 → cargo test(33のRust単体テスト)→ フロントビルド+テスト → MCPテスト → Rust↔Node整合 → カタログ差分 → アプリのバイナリビルドまで7段を走らせる。最終段が実際にバイナリを組むのは、素の cargo run が壊れる回帰が前段までを素通りした実体験に基づく。CIはubuntu・macOS・Windowsの3OSで回し、Windowsレグは、macOSで作られた .ico の無いリポジトリがWindowsビルドを壊した後に追加された。
リポジトリ自身が、掲げる前提を自分でドッグフーディングしている。7つのClaudeサブエージェント、10のスラッシュコマンド、エントリ執筆スキル、編集後にデータ検証と rustfmt を走らせるPostToolUseフックを同梱し、integrations/claude/skills/libraium-first/ は他リポジトリでの依存判断の前にこの蔵書を参照させるユーザースコープのスキルになっている。
『langgraph を使え』『llama_index と相性が良い』といった散文だけの示唆を、構造化されたたどれるエッジに変えた。superseded_by / pairs_with フロントマターは片方向にのみ保存し、逆向き(supersedes・対称なペア)は読み取り時に導出することで二方向がずれない設計にし、新しい get_related MCPツールから辿れるようにした — これもRust/Nodeの両実装で一致させている。
開発の転機
03土台一式を単一の大型コミットで一括投下
段階的なスキャフォールドではなく、Tauri v2デスクトップアプリ・Rustコア・Svelte GUI・MCPサーバー・シードデータが、設計書に続いて1つのコミットで着地。以後すべての作業が整合を保ち続けねばならない、Rust/Node二重実装のデータ設計がここで確定した。
エージェント監査によるPDCAを開発手法として採用
4エージェントの敵対的監査で洗い出した指摘を明示的なバックログとして積み、反復ごとに潰していく。fix / chore / test が往復するこのループがコミット量の大半を生み、以降の全フェーズで再利用される『監査 → 修正 → 収束』のリズムを定めた。
『Reception』への軸足移動 — 一次メモから出典付きの第三者評価へ
蔵書の差別化点を、キュレーター自身のメモから、出典と日付を伴う『## Reception』層へ作り直し、全43エントリに展開。ストレージ・MCP読み取り経路・新しいスキャナに通したこの層が、後に find_by_reception で問い合わせ対象になる『堀』となる。
Windowsとの初接触がクロスプラットフォームの穴を露呈
開発機がmacOSからWindowsへ移った際、macOS前提のアイコン生成がネイティブWindowsビルドを壊した。手作りの icon.ico、再発防止の専用Windows CIレグ、カタログリンクのスラッシュ統一、Windows限定のテストスキップで対処した。
ナレッジグラフ化 — 散文のシグナルを構造化された辺へ
自由記述に埋もれていた移行・継承・ペアリングのヒントを、superseded_by / pairs_with という一級のフロントマター辺に昇格。get_related MCPツールと authored-first なランキングを備え、『各エントリは孤島』をたどれるグラフに置き換えた。
手法の転換 — main直押しからレビュー付きPRへ、収束監査で締める
後半のロードマップは、読み取り専用のレビューエージェントを通した個別PRとして出荷される。最後に defect-hunter・drift-auditor・completeness-critic による3レンズの収束監査を行い、重大な指摘ゼロで締めた。ソロの速度から、自己点検を組み込んだプロセスへと移行した局面。