Tesserae v0.2.0 — Typisiertes Retrieval, Code-Graph, Ontologie-Evolution

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Español · Français

<!-- translations:end -->

Veröffentlicht am 2026-05-21 · PyPI · GitHub-Release · pip install --upgrade tesserae

Tesserae 0.2.0 ist das erste Feature-Release auf Basis der v0.1.0-Linie und liefert sechs additive Funktionen ohne Breaking Changes. Mit diesem Release entwickelt sich die Retrieval-Oberfläche von Tesserae von „BM25 über einem typisierten Graphen" zu einem HippoRAG-2-artigen hybriden Retriever mit Personalized PageRank (personalisiertes PageRank) als Seed-Expansion weiter, legt ein Code-as-Graph-Fundament, das prosaische Erkenntnisse mit Quellcode-Symbolen verknüpft, und ergänzt zwei Ontologie-Evolutionsdurchläufe (Community-Zusammenfassungen und Memory Decay) sowie einen Schema-Drift-Report. Die Funktionen adressieren drei Stellen im Workflow der Nutzerinnen und Nutzer: bessere Recall-Werte zur Query-Zeit (graph_ppr, hybrides search_nodes), reichhaltigere Knoten zur Compile-Zeit (ingest-code, Community-Zusammenfassungen, decay/supersedes) sowie eine schnellere Iterationsschleife auf der Ontologie selbst (schema-drift).

Inhaltsverzeichnis:

1. MD0 — Personalized PageRank über dem typisierten Graphen
2. Hybrides MD0 — BM25 + lexikalisch + Embedding via RRF
3. MD0 — Python-AST → typisierter Code-Graph
4. Community-Zusammenfassungen — Louvain + LLM (opt-in)
5. Decay-Scoring + MD0 + MD1
6. MD0 — EDC-Enum-Vorschläge
7. Upgrade von v0.1.0
8. Strategischer Kontext

1. graph_ppr — Personalized PageRank über dem typisierten Graphen

Was es ist

Ein neues MCP-Tool, das Personalized PageRank (PPR) ausgehend von einer oder mehreren Knoten-IDs ausführt und die Top-k der relevantesten Knoten nach Stationärverteilungsmasse zurückgibt. Der Random Walk ist typenbewusst: Kanten werden nach ihrer Relationsart gewichtet, wobei das Standardprofil die vier Kantentypen höher gewichtet, die in einem Tesserae-Graphen das aussagekräftigste „echte" Signal tragen — derived_from_session, discussed_in, references und supersedes. Dies ist dasselbe Multi-Hop-Seed-Expansion-Primitiv, das auch HippoRAG 2 verwendet, jedoch auf die typisierten Kanten von Tesserae angepasst statt auf einen Ko-Vorkommens-Graphen auf Passagenebene.

Konkret beantwortet graph_ppr die Frage „Wie sieht die Nachbarschaft dieses Knotens aus, gewichtet nach den Relationen, die mich wirklich interessieren?" in einer Weise, wie es einfache BFS- oder BM25-Suchen nicht können. Ein Decision-Seed zieht die Sessions heran, aus denen er entstanden ist, die Fragen, die er beantwortet hat, die Dokumente, die er abgelöst hat, sowie die Konzepte, von denen diese Dokumente handelten — selbst wenn keiner dieser Knoten dieselben Schlüsselwörter erwähnt.

Verwendung

Das Tool wird automatisch registriert, wenn Sie den Tesserae-MCP-Server starten. Aus einem beliebigen MCP-Client heraus:

// Seed an einem einzelnen Knoten, Standard α=0.15, Top-10-Ergebnis
{
  "tool": "graph_ppr",
  "arguments": {
    "seed_node_id": "decision-2026-05-12-switch-to-hybrid-retrieval",
    "top_k": 10
  }
}

// Seed an mehreren Knoten (ein „Konzept-Cluster"), benutzerdefiniertes α + Kantengewichte
{
  "tool": "graph_ppr",
  "arguments": {
    "seed_node_ids": ["concept-rrf", "concept-bm25", "concept-embedding-fusion"],
    "top_k": 25,
    "alpha": 0.2,
    "edge_type_weights": {
      "derived_from_session": 3.0,
      "discussed_in": 2.0,
      "references": 1.5,
      "supersedes": 1.5
    }
  }
}

Das Tool liefert ein Array aus {node_id, score, kind, title}-Datensätzen, sortiert nach stationärer Masse. Aus einer Claude-Code-Session heraus bitten Sie den Agenten einfach „use graph_ppr seeded at <node> with top-k 15", und der using-tesserae-Skill routet den Aufruf entsprechend.

Wann Sie es einsetzen sollten

Greifen Sie zu graph_ppr, wenn:

• Sie einen gut identifizierten Knoten besitzen (eine Entscheidung, ein Paper, ein Session-Finding) und dessen Nachbarschaft im Sinne von Graph-Distanz benötigen, nicht dessen über Schlüsselworte verwandte Geschwister.
• Sie Multi-Hop-Recall wünschen — z. B. „alles, was zwei oder drei Relationen von diesem Konzept entfernt liegt, mit einem Bias auf session-abgeleitete Findings".
• Das einfache search_nodes zwar den richtigen Knoten zurückgibt, dessen über references verknüpfter Kontext aber zu eng ist.

Für eine Freitext-Query, die von einer Phrase ausgeht, ziehen Sie das hybride search_nodes (Feature 2) vor; um den textuellen Kontext eines bekannten Knotens abzurufen, nutzen Sie node_context.

Wo es lebt

Kernimplementierung: MD0. Tool-Registrierung: tesserae/mcp_server.py.

Einschränkungen

• Das Standard-α=0.15 (Restart-Wahrscheinlichkeit) und die Obergrenze von 50 Iterationen sind auf Graphen im Bereich von 5k–50k Knoten abgestimmt, wie sie für ein Projektgedächtnis typisch sind. Sehr große Graphen (>250k Knoten) benötigen unter Umständen ein niedrigeres α und eine knotengradabhängige Initialisierung; dies ist ein Folge-Thema.
• Kantengewichte werden symmetrisch angewendet; ein asymmetrisches Profil (z. B. eine andere Gewichtung für references gegenüber dessen Inverser) ist noch nicht freigegeben.
• Die Implementierung ist reines Python und bringt keine neuen Laufzeit-Abhängigkeiten mit; falls Sie eine heiße Schleife haben, die graph_ppr tausendfach in einer einzelnen Session aufruft, sollten Sie das Cachen der spaltenstochastischen Matrix zwischen den Aufrufen in Betracht ziehen.

2. Hybrides search_nodes — BM25 + lexikalisch + Embedding via RRF

Was es ist

Das bestehende MCP-Tool search_nodes hat einen mode-Parameter und darunter einen Fusions-Retriever erhalten. Der neue Standard mode="hybrid" führt drei Retriever parallel aus — BM25 (die v0.1.0-Baseline), lexikalisch (Token-Überlappung / Substring) und Embedding (semantische Ähnlichkeit) — und fusioniert sie über Reciprocal Rank Fusion (RRF(d) = Σ 1/(k + rank_i(d)), k=60, die Konstante aus Cormack et al. 2009). Dies ist dasselbe Fusionsrezept, das auch in der Local-Search von Microsoft GraphRAG und im Hybrid-Modus von LightRAG zum Einsatz kommt.

Der Parameter mode akzeptiert:

Das Embedding-Backend wird in folgender Reihenfolge automatisch erkannt: Falls sentence-transformers importierbar ist, wird sentence-transformers/all-MiniLM-L6-v2 geladen (384-dim, ~80 MB, MIT-lizenziert, nach dem ersten Download kein Netzwerkzugriff). Andernfalls fällt das System auf eine deterministische Hash-Bucket-Projektion zurück — nutzbar, abhängigkeitsfrei und reproduzierbar, jedoch mit schwächerem semantischem Recall.

Ein neues begleitendes MCP-Tool, embedding_status, meldet, welches Backend aktiv ist, sodass Sie nachvollziehen können, ob Ihre Hybrid-Scores von echten Embeddings profitieren oder auf dem Hash-Bucket-Fallback laufen.

Verwendung

// Neuer Standard — fusioniert, gibt die Top 10 zurück
{
  "tool": "search_nodes",
  "arguments": { "query": "RRF fusion constant choice", "top_k": 10 }
}

// Einen einzelnen Retriever für Ablations-Tests erzwingen
{ "tool": "search_nodes", "arguments": { "query": "RRF fusion", "mode": "bm25" } }

// Bitgenau auf das v0.1.0-Verhalten zurücksetzen
{ "tool": "search_nodes", "arguments": { "query": "RRF fusion", "mode": "legacy" } }

// Prüfen, welches Embedding-Backend aktiv ist
{ "tool": "embedding_status", "arguments": {} }

Um statt des Hash-Bucket-Fallbacks das echte sentence-transformers-Backend zu erhalten:

pip install 'sentence-transformers>=2.7'
# Der erste Aufruf lädt die MiniLM-Gewichte (~80 MB) in den HF-Cache; nachfolgende Aufrufe sind offline.

Wann welcher Modus

• hybrid standardmäßig für alles. RRF ist robust, wenn ein Retriever Müll liefert, da die rangreziproke Dämpfung den Beitrag eines einzelnen Retrievers begrenzt.
• bm25, wenn die Query im Wesentlichen ein Tag oder ein struktureller Slug ist (concept-rrf, decision-2026-05-12-…) — die exakte Übereinstimmung dominiert, und Embeddings fügen Rauschen hinzu.
• embedding, wenn die Query eine Paraphrase oder Frage ist und die passenden Knoten ein deutlich abweichendes Vokabular verwenden.
• legacy für Ablationen gegen eine v0.1.0-Baseline oder als Notausgang, falls eine einzelne Regression auftauchen sollte.

Wo es lebt

Kernimplementierung: MD0.

Einschränkungen

• Der Hash-Bucket-Fallback ist reproduzierbar, hat aber bei Paraphrasen einen begrenzten semantischen Recall — embedding_status macht die getroffene Wahl sichtbar.
• Die aktuelle RRF-Konstante ist auf 60 fixiert; sie pro Aufruf konfigurierbar zu machen, ist ein kleines Folge-Thema, falls Sie andere Werte testen möchten.
• Embedding-Caching erfolgt pro Prozess; ein persistierter Embedding-Store (Lance/SQLite-vec) ist ein Kandidat für ein künftiges v0.3.

3. tesserae project ingest-code — Python-AST → typisierter Code-Graph

Was es ist

Ein neuer CLI-Unterbefehl, der ein Python-Repository mit dem ast-Modul der Standardbibliothek durchläuft und fünf typisierte Knotenarten sowie fünf Kantenarten prägt:

Das Ergebnis wird in .tesserae/code-graph.json persistiert und vom nächsten tesserae project compile eingelesen, sodass Code-Symbole zu vollwertigen Graphknoten werden, die Sie aus Prosa heraus verlinken, über search_nodes suchen, über graph_ppr expandieren und gemeinsam mit Konzepten und Papern visualisieren können. Damit wird das Fundament gelegt, um Entscheidungen mit den Symbolen zu verknüpfen, die sie umgesetzt haben — eine Nische, die bislang kein anderes PKM-AI-Tool besetzt.

Verwendung

# Aus einem aktivierten Tesserae-Projekt heraus
tesserae project ingest-code

# Oder gegen einen beliebigen Root
tesserae project ingest-code --root ./my-package

# Anschließend nimmt ein normales Compile die neue code-graph.json auf
tesserae project compile

Nach dem nächsten Compile werden Code-Knoten durchsuchbar:

tesserae ask "Where is the RRF fusion implemented?"

…und der Agent kann von einem prosaischen Decision-Knoten über die Kanten references / declared_in zur CODE_FUNCTION wandern, die ihn implementiert.

Wann Sie es einsetzen sollten

• Sie möchten, dass Entscheidungen und Findings auf die tatsächlich diskutierten Symbole verlinken, nicht nur auf das README, das diese Symbole erwähnt.
• Sie möchten code-bewusstes Retrieval, ohne einen separaten Code-Suchindex aufzusetzen — dieselben Tools search_nodes + graph_ppr decken nun Prosa und Code gleichermaßen ab.
• Sie nutzen die Understand-Anything-Integration, möchten aber einen leichteren, abhängigkeitsfreien Code-Graphen, der im Haupt-Graphen von Tesserae lebt statt in einer separaten JSON-Datei.

Wo es lebt

Kernimplementierung: MD0.

Einschränkungen

• Nur Python in v0.2.0. Der Extraktor ist so strukturiert, dass später sprachspezifische Walker hinzugefügt werden können; TypeScript / Rust / Go stehen auf der v0.3-Roadmap.
• calls-Kanten werden per Namensauflösung innerhalb des Scopes desselben Moduls aufgelöst; modulübergreifende Call-Auflösung nutzt Import-Aliase, leistet aber keine vollständige Typinferenz. Bei stark überladenen Namen ist mit einer moderaten False-Positive-Rate zu rechnen — für Retrieval in Ordnung, für Refactoring nicht.
• Decorators werden in den Attributen des dekorierten Knotens festgehalten, prägen aber (noch) keine eigene Kantenart.

4. Community-Zusammenfassungen — Louvain + LLM (opt-in)

Was es ist

Ein opt-in Post-Compile-Durchlauf, der Louvain-Community-Detection über den typisierten Graphen ausführt und das LLM anschließend bittet, für jede Community der Größe ≥ 4 eine einabsatzige Zusammenfassung zu erstellen. Jede Zusammenfassung wird als COMMUNITY_SUMMARY-Knoten materialisiert, über summarizes-Kanten mit ihren Mitgliedern verknüpft und über den SHA der Liste der Mitglieds-IDs gecached, sodass ein erneutes Compile nur jene Communities neu zusammenfasst, deren Mitgliedschaft sich tatsächlich geändert hat. Das ist dasselbe Muster, mit dem Microsoft GraphRAG zur Query-Zeit beantwortet, „worum es in diesem Cluster geht".

Ein neues MCP-Tool, list_communities(min_size, limit), liefert die Community-Summary-Knoten sortiert nach Mitgliederzahl, sodass Sie die Makrostruktur des Graphen erkunden können, ohne ihn zu laden.

Verwendung

Opt-in über eine Umgebungsvariable, danach kompilieren:

export TESSERAE_COMMUNITY_SUMMARIES=true
tesserae project compile

Anschließend die erzeugten Zusammenfassungen abfragen:

{ "tool": "list_communities", "arguments": { "min_size": 5, "limit": 20 } }

Oder folgen Sie den summarizes-Kanten eines Community-Summary-Knotens über node_context zurück zu seinen Mitgliedern.

Wann Sie es aktivieren sollten

• Sie haben einen mittelgroßen bis großen Graphen (>500 Knoten als Faustregel) und wünschen sich ein Inhaltsverzeichnis auf Cluster-Ebene.
• Sie möchten LLM-geschriebene Cluster-Bezeichnungen, die sich an die Farbgruppen der Graph-Ansicht im statischen Site anhängen.
• Sie erstellen periodische Digests (wöchentlich / monatlich) und wünschen sich einen Abschnitt zur „Makrostruktur", der sich nur aktualisiert, wenn sich die Mitgliedschaft tatsächlich verschoben hat.

Falls Ihr Graph klein ist (das README eines einzelnen Projekts plus eine Handvoll Dokumente), decken die strukturellen Synthesis-Knoten dies bereits ab — Community-Zusammenfassungen liefern dann Rauschen, kein Signal.

Wo es lebt

Kernimplementierung: MD0.

Einschränkungen

• Standardmäßig deaktiviert — Louvain + LLM-Zusammenfassung kostet Wandzeit, und die LLM-Kosten sind bei Graphen mit vielen Communities nicht trivial. Der Cache amortisiert dies über mehrere Re-Compiles hinweg.
• Die Community-Mitgliedschaft ist nicht-deterministisch zwischen verschiedenen Louvain-Seeds; der Durchlauf fixiert den Seed für die Reproduzierbarkeit innerhalb eines Projekts, projektübergreifende Vergleiche von Community-IDs sind jedoch nicht aussagekräftig.
• Der Zusammenfassungs-Prompt ist generisch; domänenspezifische Prompt-Overrides sind ein geplantes Folge-Thema.

5. Decay-Scoring + supersedes + fresh_insights

Was es ist

Zwei komplementäre Primitive, beide inspiriert vom Ebbinghaus-basierten Decay-Memory-Modell von A-MEM:

Decay-Scoring weist jedem Session-Finding-Knoten (Insight / Decision / Question / TODO / Hypothesis / Takeaway) einen kontinuierlichen decay_score ∈ (0, 1] über die klassische Vergessenskurve zu:

decay_score = exp(-ln(2) · age_days / half_life)

Die Standard-Halbwertszeit beträgt 14 Tage, und ein Anstieg von access_count (jedes Mal, wenn der Knoten von ask oder fresh_insights hervorgeholt wird) verlangsamt den Zerfall zusätzlich. Zeitstempel struktureller Entscheidungen werden aus der übergeordneten Session abgeleitet, sodass nachgetragene Findings ein sinnvolles Alter erhalten.

Der supersedes-Durchlauf ist ein opt-in Post-Compile-Schritt, der nahezu duplizierte Session-Findings über Jaccard-Ähnlichkeit auf Title- und Content-Shingles findet und das LLM anschließend beurteilen lässt, ob der neuere wirklich den älteren ablöst. Ein bestätigtes Paar erhält eine supersedes-Kante, und der effektive decay_score des älteren Knotens wird unterdrückt.

Ein neues MCP-Tool, fresh_insights(limit, kind), liefert die Top-Findings nach aktuellem decay_score, unter Ausschluss abgelöster Knoten. Dies ist die kanonische Query für „Worauf sollte der Agent aus vergangenen Sessions priorisiert eingehen?".

Verwendung

Das Decay-Scoring läuft bei jedem Compile automatisch. Um den supersedes-Durchlauf zu aktivieren:

export TESSERAE_SUPERSEDE_PASS=true
tesserae project compile

Dann die frischesten, nicht abgelösten Findings abfragen:

{
  "tool": "fresh_insights",
  "arguments": { "limit": 15, "kind": "Decision" }
}

Oder kind weglassen, um einen gemischten Feed über alle Session-Finding-Arten zu erhalten.

Wann Sie den supersedes-Durchlauf aktivieren sollten

• Sie sammeln wöchentlich Sessions an, und Ihre Decision- / Hypothesis-Queries beginnen, widersprüchliche, veraltete Einträge zurückzugeben.
• Sie möchten, dass der Recall-Fluss des Agenten via using-tesserae einen Bias in Richtung „das ist der aktuelle Stand zu X" hat statt „alles, was wir je zu X dachten".
• Die Kosten sind akzeptabel: Jedes Compile zahlt einen Jaccard-Durchlauf (günstig) plus N LLM-Judge-Aufrufe für Kandidatenpaare oberhalb der Jaccard-Schwelle (gecached per Content-Hash).

Wenn Sie nur ein paar Wochen Sessions haben, reicht Decay allein meist aus — die supersedes-Kante ist eine Optimierung für ältere, dichter besiedelte Graphen.

Wo es lebt

• Decay-Scoring: MD0
• supersedes-Durchlauf: MD0

Einschränkungen

• Die 14-Tage-Halbwertszeit ist ein sinnvoller Standard für aktive Forschungsprojekte; langfristige Archiv-Graphen benötigen unter Umständen 60–90 Tage. Eine Tabelle für kindspezifische Halbwertszeiten ist ein geplantes Feature für v0.3.
• Die Jaccard-Kandidatengenerierung verwendet eine feste Shingle-Größe von 5; sehr kurze Findings (einsatzige Takeaways) werden möglicherweise zu wenig gruppiert.
• Der supersedes-LLM-Judge ist bewusst konservativ — False-Negatives (übersehene Duplikate) überwiegen gegenüber False-Positives (fälschlich gesetzte supersedes-Kanten).

6. tesserae project schema-drift — EDC-Enum-Vorschläge

Was es ist

Ein neuer CLI-Unterbefehl, der dabei hilft, die Ontologie gemeinsam mit dem Korpus weiterzuentwickeln. Er implementiert das EDC-Muster (Extract-Define-Canonicalize, EMNLP'24): Für jede stark vertretene Knotenart clustert er die Mitglieder per Jaccard auf Basis von Title- und Content-Shingles und bittet das LLM anschließend, Sub-Typen in PascalCase mit einer kurzen Begründung und drei repräsentativen Mitglieder-Vorschauen pro Cluster vorzuschlagen. Die Ausgabe wird unter .tesserae/schema-drift.md als Checkliste mit kopier-und-einfügbaren Enum-Ergänzungen für die Ontologie-Dateien in ontology/ abgelegt.

LLM-Vorschläge werden atomar (write-temp-then-rename) gecached und über den SHA der Mitglieds-IDs des Clusters geschlüsselt, sodass ein erneuter Durchlauf günstig ist und bei unverändertem Korpus zu denselben Vorschlägen konvergiert.

Verwendung

tesserae project schema-drift
# → schreibt .tesserae/schema-drift.md

Öffnen Sie anschließend den Report, prüfen Sie die vorgeschlagenen Enums (jeder Block ist ein kopier-und-einfügbares Python-Literal) und fügen Sie die akzeptierten Vorschläge in die jeweilige Datei unter ontology/ ein. Der nächste tesserae project compile validiert dann gegen das aktualisierte Schema.

Wann Sie es einsetzen sollten

• Nach einem größeren Batch neuer Dokumente / Sessions, bevor Sie einen neuen Knotenart-Wert in ein vollwertiges Enum überführen.
• Periodisch (monatlich) bei langlaufenden Projekten, um Ontologie-Drift sichtbar zu machen — der Report ist schnell und nur lesend.
• Als Übergabe-Artefakt: Das Markdown ist in sich geschlossen, sodass Sie es einem Reviewer (oder einem anderen Agenten) übergeben können, ohne die vollständige Tesserae-CLI aufzusetzen.

Wo es lebt

Kernimplementierung: MD0.

Einschränkungen

• Die Vorschläge sind Empfehlungen — der Mensch (oder ein nachgelagerter Agent) entscheidet weiterhin, welche Cluster zu echten Enum-Werten werden. Der Durchlauf modifiziert ontology/ bewusst nicht selbsttätig.
• Das Jaccard-Clustering teilt die Shingle-Größen-Annahme mit dem supersedes-Durchlauf; sehr kurze Mitglieder gruppieren möglicherweise weniger trennscharf.
• Der Durchlauf konzentriert sich auf stark vertretene Arten; seltene Arten (≤ 3 Mitglieder) werden übersprungen, um spekulative Enums zu vermeiden.

Upgrade von v0.1.0

pip install --upgrade tesserae

Das ist das gesamte Upgrade — v0.2.0 ist additiv ohne Breaking Changes. Einige optionale Stellschrauben sind dennoch wissenswert:

Umgebungsvariablen für die opt-in-Durchläufe:

# Den Post-Compile-Community-Summary-Durchlauf aktivieren (Feature 4)
export TESSERAE_COMMUNITY_SUMMARIES=true

# Den supersedes-Near-Duplicate-Durchlauf aktivieren (Feature 5)
export TESSERAE_SUPERSEDE_PASS=true

Die eine Änderung an der MCP-Oberfläche, die Sie kennen sollten: search_nodes arbeitet nun standardmäßig mit mode="hybrid". Falls Sie Automatisierungen besitzen, die vom exakten v0.1.0-Ranking abhingen, übergeben Sie mode="legacy" — der Legacy-Pfad bleibt bitgenau erhalten.

Neue, optionale Python-Abhängigkeit für das echte Embedding-Backend:

pip install 'sentence-transformers>=2.7'

Wenn Sie diesen Schritt überspringen, funktioniert search_nodes mode="hybrid" weiterhin (Hash-Bucket-Fallback); embedding_status meldet dann hash-bucket statt minilm-l6-v2, sodass die Wahl beobachtbar bleibt.

Neue CLI-Unterbefehle, die Sie sich einprägen sollten:

tesserae project ingest-code      # Code-Knoten prägen (Feature 3)
tesserae project schema-drift     # Ontologie-Enums vorschlagen (Feature 6)

Neue MCP-Tools, die dem Agenten nun zur Verfügung stehen:

• graph_ppr (Feature 1)
• embedding_status (Feature 2)
• list_communities (Feature 4)
• fresh_insights (Feature 5)

Alles andere — Slash-Commands, Hooks, ask, die Wiki- / Obsidian-Projektion — bleibt unverändert.

Strategischer Kontext

v0.2.0 bringt Tesserae strukturell auf eine Linie mit dem GraphRAG- / Agent-Memory-State-of-the-Art von 2026:

• Hybrides Retrieval (BM25 + lexikalisch + Embedding via RRF) entspricht demselben Fusionsrezept, das die Local-Search von Microsoft GraphRAG und der Hybrid-Modus von LightRAG verwenden.
• Personalized PageRank als Seed-Expansion ist das Multi-Hop-Primitiv im Zentrum von HippoRAG 2, hier auf typisierte Kanten statt auf Passagen-Ko-Vorkommen adaptiert.
• Community-Zusammenfassungen spiegeln die Cluster-Summary-Ebene von Microsoft GraphRAG wider — jene Schicht, die Anfragen nach „worum geht es in diesem Korpus grob?" eine schnelle, strukturelle Antwort liefert.
• Decay-Scoring + supersedes ist das Ebbinghaus-Modell aus A-MEM, angewandt auf das Projektgedächtnis; der supersedes-Durchlauf ist im Geiste näher an den „ADD / UPDATE / DELETE"-Memory-Operationen aus Mem0, wird hier jedoch als reine Kante statt als In-Place-Rewrite ausgedrückt.
• Schema-Drift via EDC ist dieselbe Extract-Define-Canonicalize-Idee von der EMNLP'24, angewandt auf Ontologie-Evolution statt auf Relations-Extraktion.

Tesserae-spezifisch und als verteidigbarer Wedge verbleibt: durchgängig typisierte Kanten, Session-Findings als vollwertige Graphknoten und (nun) Code-Symbole innerhalb desselben Graphen. Die meisten Wettbewerber in der 2026er-Landschaft besitzen schlicht keine typisierten Kanten; unter denen, die welche haben, verknüpft keiner prosaische Entscheidungen mit Code-Symbolen — das in v0.2.0 gelegte feat/code-graph-Fundament ist der Punkt, an dem dieser Wedge zu zinsen beginnt.

Siehe auch:

• Architektur-Übersicht — Modul-Karte und Pipeline
• Feature-Map — vollständige Feature-Status-Tabelle mit Quell-Links
• Sessions-Integration — das Session-Graph-Feature, auf dem decay und supersedes operieren
• MCP-Integration — vollständige Liste der MCP-Tools (die vier neuen Tools werden im nächsten Docs-Durchlauf hier eingepflegt)