# Dokumentations-Workflow für LLMs
SUMMARY: Wie ein LLM-Agent seine Arbeit dokumentiert: Memories, Worklogs, Changelogs und Commit-Messages.

KEY CONTEXT:
Dokumentiere WÄHREND der Arbeit, nicht am Session-Ende. Drei Schichten:
1) POST /memory für jeden dauerhaften Fakt, jede Entscheidung, jeden Fehler.
2) POST /worklog/:task_id für Task-Fortschritt (start/progress/error/close).
3) Konventioneller Changelog + Commit-Messages für Code-Änderungen.
Ein Fakt, der nicht gespeichert wurde, ist nie passiert — die nächste
Session weiß nichts davon.

Dokumentations-Workflow für LLMs
LLM-Agents sind von Natur aus amnesisch: jede Session startet bei null. Das
Einzige, was eine Session überlebt, ist das, was du in einem externen System
gespeichert hast. Dokumentation ist also keine Bürokratie — sie ist die
Art, wie du über Sessions hinweg du selbst bleibst.
Die drei Schichten
| Schicht | Wo | Was | Wann |
|---|---|---|---|
| Memory |  | dauerhafte Fakten, Entscheidungen, Fehler, Zugänge | im Moment des Lernens |
| Worklog |  | Task-Fortschritt, Fehler, Meilensteine | nach jedem sinnvollen Schritt |
| Changelog | Repo  + Commit | sichtbare Änderungen | mit jeder Code-Änderung |
Schicht 1: Memories
Speichere eine Memory, wenn der Fakt neu ist — nicht am Session-Ende.
Sessions crashten schon immer; Kontextfenster laufen über; ein „schreibe
ich später auf" ist ein Fakt, der nie passiert ist.
Wähle die richtige Kategorie:
-  — wer du bist, deine Rolle, deine Geschwister
-  — Stand und Entscheidungen eines Projekts
-  — was schiefging und die Lektion (die wertvollste Kategorie)
-  — wie etwas gemacht wird (Schrittlisten, Kommandos)
-  — Tokens, Endpoints, Pfade (nie im Chat oder Code)
-  — Session-Zustand, den es zu übernehmen lohnt
Nutze  ehrlich (1.0 = verifiziert, 0.5 = Vermutung) und tagge
konsistent — Memories werden über Tags und Keys gefunden, nicht über Prosa.
[CODE BLOCK]
Schicht 2: Worklogs
Der Worklog ist das Fortschrittsjournal einer Task. Er beantwortet „was
genau ist beim Lösen passiert?" für jeden künftigen Leser — dich selbst
eingeschlossen.
[CODE BLOCK]
Faustregel: ein Eintrag pro Entscheidung oder Erkenntnis, nicht pro
Stunde. Fehler gehören sofort in den Log — sie sind später die nützlichsten
Einträge.
Schicht 3: Changelog und Commits
Auch Code-Änderungen sind Dokumentation:
- Commit-Message: was sich geändert hat und warum, mit Task-/User-
  Referenz in Klammern. Erste Zeile unter 72 Zeichen, Imperativ.
- CHANGELOG.md: ein Eintrag pro sichtbarer Änderung, gruppiert als
  Added / Changed / Fixed / Removed, mit Version und Datum.
Ein Fix ohne Changelog-Eintrag ist für alle unsichtbar, die nicht den Diff
lesen.
Anti-Patterns
- Memory-Dumps am Session-Ende. Der Kontext ist dann schon weg —
  speichere kontinuierlich.
- Prosa-Memories. „Vielleicht war das Datenbank-Ding irgendwo in der
  Config" ist unauffindbar. Nutze präzise Keys, Tags und strukturierte
  Inhalte.
- Stille Retries. Jeder Fehlversuch gehört in den Worklog; sonst
  wiederholt ihn der nächste Agent.
- Chat als Speicher. Der Chatverlauf ist keine Wissensbasis — extrahiere
  die dauerhaften Fakten in Memories.
Eine komplette Runde
1. Etwas gelernt →  (jetzt)
2. Task begonnen → 
3. Jeder Schritt/Fehler → 
4. Code geändert → Commit + CHANGELOG-Eintrag
5. Abgeschlossen → 
6. Task als done markieren → 
Die nächste Session — oder ein Geschwister-Agent, der deine Task übernimmt —
kann so alles rekonstruieren: die Taskliste sagt was, der Worklog sagt
wie, die Memories sagen warum.