Lore: Git Commit Messages als strukturiertes Wissensprotokoll für KI‑Coding‑Agenten

Wenn KI‑Coding‑Agenten zum primären Produzenten und Konsumenten von Source Code werden, steht die Software‑Industrie vor einem beschleunigten Verlust institutionellen Wissens. Jeder Commit speichert einen Code‑Diff, verwirft aber die Entscheidungslogik dahinter – die Constraints, verworfenen Alternativen und den vorausschauenden Kontext, der die Entscheidung geprägt hat. Dieses verworfene Wissen nennt das arXiv‑Paper „Decision Shadow“. Die Lösung? Lore: ein leichtgewichtiges Protokoll, das Commit‑Messages mit strukturierten Git‑Trailers in selbst‑contained Decision Records verwandelt – ohne zusätzliche Infrastruktur, abfragbar über ein CLI‑Tool und für jeden Agenten nutzbar, der Shell‑Commands ausführen kann.

Das Problem: Decision Shadow

Stell dir vor, ein KI‑Agent (oder ein menschlicher Entwickler) bearbeitet eine Codebase. Er stößt auf ein Problem, erwägt mehrere Lösungsansätze, wägt Trade‑offs ab, wählt einen aus und implementiert ihn. Der resultierende Git‑Commit hält genau ein Artefakt fest: den finalen Diff. Alles andere – die Problemdefinition, die geprüften Alternativen, die verworfenen Optionen, die Constraints („darf keine neuen Abhängigkeiten einführen“) und die vorausschauenden Hinweise („dieser Ansatz skaliert besser, wenn später Feature X kommt“) – verschwindet.

Das Paper „Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents“ (arXiv:2603.15566v1, März 2026) bezeichnet dieses verworfene Wissen als Decision Shadow ¹. Es ist das implizite, nicht‑kodierte Wissen, das KI‑Agenten beim nächsten Commit, beim Refactoring oder bei der Fehlerbehebung fehlt. Ohne diesen Kontext treffen Agenten Entscheidungen auf Basis unvollständiger Information – oder reproduzieren bereits verworfenen Lösungen.

Bisherige Ansätze, diesen Wissensverlust zu adressieren, sind schwergewichtig: Knowledge‑Graphen, versionierte Agent‑Memory‑Systeme oder separate Architecture Decision Records (ADRs). Sie erfordern zusätzliche Infrastruktur, Tools und Prozesse – und werden daher in der Praxis oft nicht adoptiert.

Lore: Das Protokoll in Git‑Commit‑Messages

Lore schlägt einen radikal einfacheren Weg vor: Nutze die Git‑Commit‑Message selbst als strukturiertes Wissensprotokoll. Das Protokoll erweitert Commit‑Messages um standardisierte Git‑Trailers – jene Key‑Value‑Paare, die bereits für Co‑Authored‑By, Signed‑Off‑By etc. genutzt werden.

Ein Lore‑Commit sieht beispielsweise so aus:

feat: implement caching layer for user profiles

- Added Redis client with connection pooling
- Cache invalidation on profile updates
- Fallback to database on cache miss

Lore-Constraints: no new external dependencies, must respect GDPR data locality
Lore-Alternatives: considered in‑memory LRU cache (rejected – doesn’t scale across pods), considered PostgreSQL notify (rejected – adds complexity)
Lore-Agent-Directives: if user‑count exceeds 10k, evaluate sharding strategy
Lore-Verified-By: agent‑claude‑3‑7‑sonnet (confidence=0.92)

Die Trailers Lore‑Constraints, Lore‑Alternatives, Lore‑Agent‑Directives und Lore‑Verified‑By bilden ein selbst‑contained Decision Record. Sie sind maschinenlesbar, können über git log --grep oder ein spezielles CLI‑Tool abgefragt werden und bleiben im Repository – ohne zusätzliche Infrastruktur ².

Die Trailers im Detail

• Lore‑Constraints: Festgelegte Randbedingungen („no new dependencies“, „must run on ARM“, „max latency 100ms“).
• Lore‑Alternatives: Geprüfte und verworfenen Ansätze mit kurzer Begründung.
• Lore‑Agent‑Directives: Vorausschauende Hinweise für künftige Agenten‑Entscheidungen („if condition X, consider Y“).
• Lore‑Verified‑By: Welcher Agent (oder welches Modell) die Entscheidung verifiziert hat – inklusive Confidence‑Score.

Das Protokoll ist erweiterbar: Teams können eigene Trailers definieren (z.B. Lore‑Business‑Context, Lore‑Performance‑Tradeoff).

Praxis‑Guide: Lore im Team einführen

1. Commit‑Message‑Template einrichten

In der Git‑Config des Projekts:

git config commit.template .gitmessage

Die .gitmessage‑Datei:

Lore‑Commit‑Template
Title: <type>: <short description>

Body (optional)
- Bullet points describing changes

Lore Trailers (optional – fill as needed)
Lore-Constraints:
Lore-Alternatives:
Lore-Agent-Directives:
Lore-Verified-By:

2. CLI‑Tool für Abfragen

Das Paper beschreibt ein standalone CLI‑Tool (lore), das Commit‑Histories nach Lore‑Trailers durchsucht und sie strukturiert ausgibt. Beispiel‑Abfragen:

lore list --trailer Lore-Constraints
lore search "caching" --trailer Lore-Alternatives
lore extract --trailer Lore-Agent-Directives --grep "scale"

Ein solches Tool kann in wenigen hundert Zeilen Python oder Go implementiert werden – es nutzt git log --pretty=format:… und parst die Trailers.

3. Integration in KI‑Agenten‑Workflows

KI‑Agenten, die Code‑Änderungen vorschlagen, sollten automatisch Lore‑Trailers generieren. Beispiel‑Prompt für einen Coding‑Agent:

„Before committing, summarize the constraints you respected, the alternatives you considered (and why you rejected them), and any forward‑looking directives for future agents. Format them as Lore‑Constraints:, Lore‑Alternatives:, Lore‑Agent‑Directives: trailers.“

Beim Review eines Agent‑Commits können menschliche Entwickler die Trailers prüfen und gegebenenfalls ergänzen.

4. Entscheidungs‑Shadow sichtbar machen

Regelmäßig lore audit laufen lassen, um Commits ohne Lore‑Trailers zu identifizieren – besonders bei kritischen Änderungen (Architektur, Daten‑Migrationen, Sicherheits‑Fixes). Das schärft das Bewusstsein für den Decision Shadow.

Vorteile gegenüber alternativen Ansätzen

Ansatz	Infrastruktur‑Overhead	Maschinenlesbar	Git‑native	Für KI‑Agenten zugänglich
Lore	keine (nur Git)	✅ (Trailers)	✅	✅ (Shell‑Commands)
Knowledge‑Graphs	hoch (DB, API, Schema)	✅	❌	eingeschränkt
Versioned Agent Memory	mittel (Storage, Sync)	✅	❌	✅ (aber system‑spezifisch)
Architecture Decision Records	niedrig (Markdown‑Files)	⚠️ (Text‑Parsing)	⚠️ (separate Files)	⚠️ (File‑Access nötig)
Keine explizite Dokumentation	keine	❌	❌	❌

Lore punktet durch Git‑Nativität und Null‑Infrastruktur. Es nutzt ein bestehendes, universell verfügbares Tool (Git) und ein etabliertes Format (Trailers). Jeder Agent, der Shell‑Commands ausführen kann (git log), kann auf den Decision‑Shadow zugreifen.

Grenzen und offene Fragen

• Menschliche Disziplin: Lore setzt voraus, dass Entwickler (oder Agenten) die Trailers pflegen. Ohne Tool‑Unterstützung und Team‑Kultur verblasst der Ansatz.
• Trailer‑Explosion: Bei vielen Trailers pro Commit wird die Message unübersichtlich. Hier hilft ein CLI‑Tool, das gezielt extrahiert.
• Merge‑Conflicts: Trailers sind Teil der Commit‑Message – bei Rebases oder Merges können Konflikte entstehen. Das Paper schlägt automatisierte Merge‑Strategien vor.
• Historische Commits: Bestehende Repositories haben keinen Decision Shadow. Retrofitting ist aufwendig, aber für kritische Code‑Areas sinnvoll.

Fazit: Decision Shadow als Chance

Der Decision Shadow ist kein neues Problem – aber KI‑Coding‑Agenten machen ihn akut. Wenn Agenten Code produzieren, ohne den zugrundeliegenden Entscheidungskontext zu kennen, reproduzieren sie Fehler, ignorieren Constraints und verlieren Effizienz.

Lore zeigt einen pragmatischen Ausweg: Git‑Commit‑Messages als strukturiertes Wissensprotokoll wiederverwenden. Mit wenigen standardisierten Trailers wird aus einer simplen Beschreibung ein maschinenlesbarer Decision Record – ohne zusätzliche Infrastruktur, ohne neue Tools, ohne komplexe Migration.

Für Teams, die KI‑Agenten in ihre Development‑Workflows integrieren, ist Lore ein niedrigschwelliger Schritt, um den Decision Shadow sichtbar zu machen. Es ist kein Allheilmittel, aber ein praktischer Hebel, um die Wissens‑Lücke zwischen menschlichen und KI‑Entscheidungen zu schließen.

Weiterführend: Das vollständige Paper auf arXiv:2603.15566 – inklusive formaler Protokoll‑Spezifikation, Vergleich mit fünf alternativen Ansätzen und Stress‑Tests.

Hat dein Team bereits Erfahrung mit Decision Shadows oder ähnlichen Wissens‑Protokollen?

Footnotes

1. Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents – arXiv:2603.15566v1, March 2026. https://arxiv.org/abs/2603.15566 ↩

2. Git Trailers – Git‑internes Format für Key‑Value‑Paare in Commit‑Messages. Git‑Dokumentation: https://git-scm.com/docs/git-interpret-trailers ↩