Lore

あなたのソフトウェアプロジェクトのためのライブ知識グラフ。

ステータス: 1.0未満、個人メンテナンス。 Loreは機能しており、本番プロジェクトでも使用されていますが、API、スキーマ、MCPインターフェースはマイナーバージョン間で変更される可能性があります。バグ報告は歓迎しますが、設計が安定するまで機能追加のPRはマージされない可能性があります。APIが安定（目標: 1.0）した段階で、より広範なコラボレーションに向けてリポジトリを公開する予定です。

Loreは、プロジェクトのビジネスロジック（モジュール、機能、フロー、イベント、ルール、フォーム、エンティティ、決定事項）をSQLiteでバックアップされた型付きグラフとしてキャプチャします。これをMCP経由で公開することで、AIコーディングアシスタント（Claude Code、Cursor、Claude Desktop）が通常の作業の一環としてクエリやメンテナンスを行えるようにします。

「支払い登録の方法は何通りあるか？」「flow-checkoutを触ると何が壊れるか？」「このエンティティを保護しているルールはどれか？」といった質問に対し、毎回コードベースを再探索することなく、根拠（provenance）付きで単一のツール呼び出しで回答します。

なぜLoreなのか

• セッションをまたぐ永続的なメモリ — グラフはコンテキストのリセット後も存続します。

• ドキュメント作成のオーバーヘッドゼロ — アシスタントが概念を決定するたびに書き込むため、別途作業を行う必要はありません。

• 監査可能 — すべてのノードはsource、confidence、source_contextを保持します。すべてのMCP呼び出しはログに記録されます。

• トークン効率的 — 要約のみのリスト表示、バッチ操作、探索用の安価なサブエージェント、WALモードのSQLiteを採用しています。

Related MCP server: kg-memory-mcp

インストール（Claude Codeプラグイン — 推奨）

/plugin marketplace add YACB2/lore
/plugin install lore@lore

リロード後、モデル化したいプロジェクトからlore initを実行します（または、Haikuでコードをスキャンするガイド付きオンボーディングのために/lore:bootstrapを実行します）。「プロジェクト」は単一のリポジトリでも、複数のリポジトリを含むワークスペースでも構いません。Loreは特定の構成を強制せず、Claude Codeを起動したディレクトリを基準に.lore/lore.dbが作成されます。

プラグインには以下が含まれます：

• MCPサーバー: lore_add_node、lore_add_nodes、lore_update_node、lore_delete_node、lore_get_node、lore_add_edge、lore_add_edges、lore_remove_edge、lore_query、lore_traverse、lore_list、lore_find_variants、lore_audit、lore_history、lore_stats、lore_export_markdownを公開。

• 自動呼び出しスキル (lore-usage): Claudeに対し、行動前に読み取り、決定時に書き込むよう指示し、根拠ルールとライフサイクル規則を適用します。

• サブエージェント lore-explorer (Haiku、読み取り専用): 高価なトークンを消費せずに広範な探索を行うためのエージェント。

• スラッシュコマンド: /lore:init、/lore:bootstrap、/lore:audit、/lore:show <id>、/lore:recent、/lore:impact <id>、/lore:probe <path>（ディレクトリを切り替えずに別のプロジェクトのグラフを監査）。

インストール（スタンドアロンCLI / その他のMCPホスト）

pipx install projectlore   # or: uv tool install projectlore
lore init

Cursor / Claude Desktopの場合：

{
  "mcpServers": {
    "lore": {
      "command": "lore",
      "args": ["mcp", "--db", ".lore/lore.db"]
    }
  }
}

CLIリファレンス

lore init                      # create .lore/lore.db
lore list [--type flow]        # summary listing (id, type, title, status)
lore show <id>                 # full detail + edges
lore query "payment"           # exact id → title substring → tag fallback
lore variants <capability-id>  # flows implementing a capability
lore audit                     # orphans, cycles, id hygiene
lore stats [--since ISO]       # token/usage analytics from the audit log
lore export --out .lore/export # one markdown file per node

スキーマ

8つのノードタイプ (スタック非依存): module、capability、flow、event、rule、form、entity、decision。

9つの関係: part_of、implements、depends_on、triggers、validates、enforces、supersedes、references、conflicts_with。型ペアは制限されています（schema.pyを参照）。

ステータス: active | draft | deprecated | superseded | archived。デフォルトはソフトデリートです。lore_delete_nodeは誤字脱字のために予約されており、エッジの損失について警告します。

中心となる抽象化は**capability**です。これは、その方法に関係なく、システムが「何ができるか」を示すものです。複数のflowノードが同じcapabilityをimplements（実装）でき、UXやロジックの乖離を浮き彫りにします。

モデルルーティング

操作はコストに応じて分割されます：

• 読み取り (広範なスキャン、トラバーサル、監査): lore-explorerサブエージェント経由でHaikuに委任、またはスラッシュコマンドのフロントマターでmodel: haikuを指定。

• 書き込みおよびモデリングの決定: 呼び出し元のモデル（Sonnet/Opus）。サブエージェントがJSONを提案し、呼び出し元がレビューして永続化します。

プロジェクトごとに.lore/config.jsonでオーバーライド可能です：

{
  "language": "es",
  "app_name": "my-app",
  "models": { "exploration": "haiku", "write": "sonnet" }
}

根拠と履歴

すべてのノードはmetadata.{source, confidence, source_context}を保持し、関連する場合はsource_ref (path:line)、last_verified_at、deprecated_at、deprecated_reason、replaced_byを保持します。

lore_update_node(metadata_patch=…)は根拠を破壊せずにマージします。まれな完全置換のためにmetadataはそのまま存在します。

lore_history(id)は、追記専用の監査ログからノードのすべてのMCPイベントを（最新のものから順に）返します。lore_statsはツール/操作ごとに集計し、入出力バイト数を報告します。

ステータス

プレMVP、アルファ版。スキーマとMCPツールのインターフェースは0.1.0までに変更される可能性があります。

開発

uv sync --all-groups
uv run pytest -q
uv run ruff check src tests

テストはtests/にあります。プラグインのレイアウトはtest_plugin_structure.pyによって検証されます。

ライセンス

MIT。