Lore

Der lebendige Wissensgraph für Ihr Softwareprojekt.

Status: vor 1.0, solo-betreut. Lore ist funktionsfähig und wird in Produktionsprojekten eingesetzt, aber die API, das Schema und die MCP-Oberfläche können sich zwischen Nebenversionen noch ändern. Fehlerberichte sind willkommen; Feature- PRs werden möglicherweise nicht zusammengeführt, während sich das Design stabilisiert. Das Repository wird für eine breitere Zusammenarbeit geöffnet, sobald die API stabil ist (Ziel: 1.0).

Lore erfasst die Geschäftslogik eines Projekts – Module, Fähigkeiten, Abläufe, Ereignisse, Regeln, Formulare, Entitäten und Entscheidungen – als typisierten Graphen auf Basis von SQLite und stellt ihn über MCP bereit, damit KI-Coding-Assistenten (Claude Code, Cursor, Claude Desktop) ihn als Teil der normalen Arbeit abfragen und pflegen können.

Es beantwortet Fragen wie "Wie viele Möglichkeiten gibt es, eine Zahlung zu registrieren?", "Was geht kaputt, wenn ich flow-checkout anfasse?" oder "Welche Regeln schützen diese Entität?" in einem einzigen Tool-Aufruf, mit Herkunftsnachweis, ohne jedes Mal die Codebasis neu durchsuchen zu müssen.

Warum

• Persistentes Gedächtnis über Sitzungen hinweg – der Graph überlebt Kontext-Resets.

• Kein Dokumentationsaufwand – der Assistent schreibt mit, während Konzepte entschieden werden, nicht als separate lästige Pflicht.

• Auditierbar – jeder Knoten trägt source, confidence, source_context. Jeder MCP-Aufruf wird protokolliert.

• Token-effizient – nur Zusammenfassungen, Batch-Operationen, kostengünstige Sub-Agenten für die Exploration, WAL-Modus SQLite.

Related MCP server: kg-memory-mcp

Installation (Claude Code-Plugin – empfohlen)

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

Laden Sie neu und führen Sie dann in dem Projekt, das Sie modellieren möchten, lore init aus (oder /lore:bootstrap für ein geführtes Onboarding, das den Code mit Haiku scannt). "Projekt" kann ein einzelnes Repo oder ein Workspace sein, der mehrere Repos enthält – Lore hat keine Meinung dazu, .lore/lore.db wird relativ zu dem Verzeichnis erstellt, von dem aus Sie Claude Code gestartet haben.

Das Plugin bündelt:

• MCP-Server, der 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 bereitstellt.

• Automatisch aufgerufene Fähigkeit (lore-usage), die Claude anweist, vor dem Handeln zu lesen und bei Entscheidungen zu schreiben, mit Herkunftsregeln und Lebenszykluskonventionen.

• Sub-Agent lore-explorer (Haiku, schreibgeschützt) für eine breite Exploration, ohne teure Token zu verbrauchen.

• Slash-Befehle: /lore:init, /lore:bootstrap, /lore:audit, /lore:show <id>, /lore:recent, /lore:impact <id>, /lore:probe <path> (Audit des Graphen eines anderen Projekts ohne Verzeichniswechsel).

Installation (Standalone-CLI / andere MCP-Hosts)

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

Für Cursor / Claude Desktop:

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

CLI-Referenz

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

Schema

Acht Knotentypen (Stack-agnostisch): module, capability, flow, event, rule, form, entity, decision.

Neun Beziehungen: part_of, implements, depends_on, triggers, validates, enforces, supersedes, references, conflicts_with. Typ-Paare sind eingeschränkt (siehe schema.py).

Status: active | draft | deprecated | superseded | archived. Soft-Delete ist der Standard; lore_delete_node ist für Tippfehler reserviert und warnt vor dem Verlust von Kanten.

Die zentrale Abstraktion ist capability – eine Sache, die das System tun kann, unabhängig davon, wie. Mehrere flow-Knoten können dieselbe Fähigkeit implements (implementieren) und so UX/Logik-Abweichungen aufzeigen.

Modell-Routing

Operationen werden nach Kosten aufgeteilt:

• Lesevorgänge (breite Scans, Traversierungen, Audits): delegiert an Haiku über den lore-explorer Sub-Agenten oder model: haiku Frontmatter bei Slash-Befehlen.

• Schreibvorgänge & Modellierungsentscheidungen: Modell des Aufrufers (Sonnet/Opus). Ein Sub-Agent schlägt JSON vor; der Aufrufer prüft und speichert es dauerhaft.

Überschreiben pro Projekt in .lore/config.json:

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

Herkunft & Historie

Jeder Knoten trägt metadata.{source, confidence, source_context} und, falls relevant, source_ref (path:line), last_verified_at, deprecated_at, deprecated_reason, replaced_by.

lore_update_node(metadata_patch=…) führt Zusammenführungen durch, ohne die Herkunft zu zerstören; metadata existiert weiterhin für seltene vollständige Ersetzungen.

lore_history(id) gibt jedes MCP-Ereignis für einen Knoten zurück (neueste zuerst) aus dem Append-only-Audit-Log. lore_stats aggregiert nach Tool/Op und meldet Eingabe-/Ausgabe-Bytes.

Status

Vor-MVP, Alpha. Schema und MCP-Tool-Oberfläche können sich vor 0.1.0 noch ändern.

Entwicklung

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

Tests befinden sich in tests/. Das Plugin-Layout wird durch test_plugin_structure.py validiert.

Lizenz

MIT.