# Documentatieworkflow voor LLM's
SUMMARY: Hoe een LLM-agent zijn werk moet documenteren: herinneringen, worklogs, changelogs en commit-berichten.

KEY CONTEXT:
Documenteer TIJDENS het werken, niet aan het einde van de sessie. Drie lagen:
1) POST /memory voor elke duurzame feite, beslissing, fout of credential.
2) POST /worklog/:task_id voor voortgang per taak (start/progress/error/close).
3) Conventionele changelog + commit-berichten voor codewijzigingen.
Een feit dat niet is opgeslagen is nooit gebeurd — de volgende sessie weet het niet.

Documentatieworkflow voor LLM's
LLM-agenten zijn van nature amnesie-drachtig: elke sessie begint op nul. Het enige dat een sessiegrens overleeft is wat je in een extern systeem hebt opgeslagen. Documentatie is dus geen bureaucratie — het is hoe je jezelf blijft tussen sessies.
De drie lagen
| Laag | Waar | Wat | Wanneer |
|---|---|---|---|
| Memory |  | duurzame feiten, beslissingen, fouten, credentials | op het moment dat je het leert |
| Worklog |  | taakvoortgang, fouten, mijlpalen | na elke betekenisvolle stap |
| Changelog | repo  + commit | voor gebruiker zichtbare wijzigingen | bij elke codewijziging |
Laag 1: Herinneringen
Sla een herinnering op als het feit nieuw is, niet aan het einde van de sessie. Sessies crashen; contextvensters lopen over; een "ik schrijf het later op" is een feit dat nooit gebeurd is.
Kies de juiste categorie:
-  — wie je bent, je rol, je broers en zussen
-  — status en beslissingen van een project
-  — wat er misging en de les (de meest waardevolle categorie)
-  — hoe iets gedaan wordt (steplijsten, commando's)
-  — tokens, endpoints, paden (nooit in chat of code)
-  — sessiestatus die het waard is mee te nemen
Gebruik  eerlijk (1.0 = geverifieerd, 0.5 = aanname) en tag consistent — herinneringen worden gevonden op tag en key, niet op proza.
[CODE BLOCK]
Laag 2: Worklogs
Het worklog is het voortgangsjournaal van één taak. Het beantwoordt "wat is er precies gebeurd tijdens het oplossen?" voor elke toekomstige lezer — inclusief toekomstig jij.
[CODE BLOCK]
Vuistregel: één invoer per beslissing of ontdekking, niet per uur. Fouten horen direct in het logboek — het zijn later de meest nuttige invoer.
Laag 3: Changelog en commits
Codewijzigingen zijn ook documentatie:
- Commit-bericht: wat er veranderde en waarom, met de taak/gebruikersverwijzing tussen haakjes. Eerste regel onder 72 tekens, gebiedende wijs.
- CHANGELOG.md: één invoer per voor gebruiker zichtbare wijziging, gegroepeerd als Added / Changed / Fixed / Removed, met versie en datum.
Een fix zonder changelog-invoer is onzichtbaar voor iedereen die de diff niet heeft gelezen.
Anti-patronen
- Geheugendumps aan het einde van de sessie. De context is er dan al — sla continu op.
- Proza-herinneringen. "Misschien stond het database-ding ergens in de config" is onvindbaar. Gebruik precieze keys, tags en contentstructuur.
- Stille retries. Elke mislukte poging hoort in het worklog; anders herhaalt de volgende agent hem.
- Chat als opslag. Chatgeschiedenis is geen kennisbank — extraheer de duurzame feiten naar herinneringen.
Een complete lus
1. Leer iets →  (nu)
2. Start een taak → 
3. Elke stap/fout → 
4. Verander code → commit + CHANGELOG-invoer
5. Rond af → 
6. Markeer de taak als klaar → 
De volgende sessie — of een broer/zussen-agent die je taak overneemt — kan dan alles reconstrueren: de takenlijst zegt wat, het worklog zegt hoe, de herinneringen zeggen waarom.