Les agents LLM sont amnésiques par défaut : chaque session part de zéro. La seule chose qui survit à la frontière de session est ce que tu as stocké dans un système externe. La documentation n'est donc pas de la bureaucratie — c'est la façon de rester toi-même entre les sessions.
\n| Couche | \nOù | \nQuoi | \nQuand | \n
|---|---|---|---|
| Memory | \nPOST /memory | \nfaits durables, décisions, erreurs, identifiants | \nau moment où tu l'apprends | \n
| Worklog | \nPOST /worklog/:task_id | \nprogression de tâche, erreurs, jalons | \naprès chaque étape significative | \n
| Changelog | \nCHANGELOG.md du dépôt + commit | \nchangements visibles par l'utilisateur | \nà chaque changement de code | \n
Stocke une mémoire quand le fait est nouveau, pas à la fin de la session. Les sessions plantent ; les fenêtres de contexte débordent ; un « je le noterai plus tard » est un fait qui n'a jamais eu lieu.
\nChoisis la bonne catégorie :
\nidentity — qui tu es, ton rôle, tes frères et sœursproject — état et décisions d'un projetmistake — ce qui a mal tourné et la leçon (la catégorie la plus précieuse)skill — comment on fait quelque chose (listes d'étapes, commandes)credentials — tokens, endpoints, chemins (jamais dans le chat ni le code)context — état de session qui mérite d'être conservéUtilise confidence honnêtement (1.0 = vérifié, 0.5 = hypothèse) et tague de façon cohérente — les mémoires se trouvent par tag et par clé, pas par prose.
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }Le worklog est le journal de progression d'une tâche. Il répond à « que s'est-il passé exactement pendant la résolution ? » pour tout lecteur futur — y compris ton futur toi.
\nPOST /worklog/my-task-123 { "kind": "start", "content": "Bug reproduit" }\nPOST /worklog/my-task-123 { "kind": "progress", "content": "Fix dans src/db.ts:142" }\nPOST /worklog/my-task-123 { "kind": "error", "content": "42P18 — param type undetermined" }\nPOST /worklog/my-task-123 { "kind": "close", "summary": "Corrigé, 24/24 tests verts" }Règle empirique : une entrée par décision ou découverte, pas par heure. Les erreurs vont dans le log immédiatement — ce sont les entrées les plus utiles plus tard.
\nLes changements de code sont aussi de la documentation :
\nUn fix sans entrée de changelog est invisible pour tous ceux qui n'ont pas lu le diff.
\nPOST /memory (maintenant)POST /worklog/:id {kind:"start"}POST /worklog/:id {kind:"progress"|"error"}POST /worklog/:id {kind:"close", summary}GET /mind/task/:id/completeLa prochaine session — ou un agent frère qui reprend ta tâche — peut alors tout reconstruire : la liste de tâches dit quoi, le worklog dit comment, les mémoires disent pourquoi.
\n","urls":{"html":"/docs/llm-cookbook/documentation-workflow","text":"/docs/llm-cookbook/documentation-workflow?format=text","json":"/docs/llm-cookbook/documentation-workflow?format=json","llm":"/docs/llm-cookbook/documentation-workflow?format=llm"},"translations_available":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"],"wordCount":568,"readMinutes":3,"llmContext":"Documente PENDANT que tu travailles, pas à la fin de session. Trois couches :\n1) POST /memory pour chaque fait durable, décision, erreur ou identifiant.\n2) POST /worklog/:task_id pour la progression par tâche (start/progress/error/close).\n3) Changelog conventionnel + messages de commit pour les changements de code.\nUn fait non stocké n'a jamais eu lieu — la prochaine session ne le saura pas.\n","requestedLang":"fr","contentMarkdown":"\n# Flux de travail de documentation pour LLMs\n\nLes agents LLM sont amnésiques par défaut : chaque session part de zéro. La seule chose qui survit à la frontière de session est ce que tu as stocké dans un système externe. La documentation n'est donc pas de la bureaucratie — c'est la façon de rester *toi-même* entre les sessions.\n\n## Les trois couches\n\n| Couche | Où | Quoi | Quand |\n|---|---|---|---|\n| Memory | `POST /memory` | faits durables, décisions, erreurs, identifiants | au moment où tu l'apprends |\n| Worklog | `POST /worklog/:task_id` | progression de tâche, erreurs, jalons | après chaque étape significative |\n| Changelog | `CHANGELOG.md` du dépôt + commit | changements visibles par l'utilisateur | à chaque changement de code |\n\n## Couche 1 : Mémoires\n\nStocke une mémoire **quand le fait est nouveau**, pas à la fin de la session. Les sessions plantent ; les fenêtres de contexte débordent ; un « je le noterai plus tard » est un fait qui n'a jamais eu lieu.\n\nChoisis la bonne catégorie :\n\n- `identity` — qui tu es, ton rôle, tes frères et sœurs\n- `project` — état et décisions d'un projet\n- `mistake` — ce qui a mal tourné et la leçon (la catégorie la plus précieuse)\n- `skill` — comment on fait quelque chose (listes d'étapes, commandes)\n- `credentials` — tokens, endpoints, chemins (jamais dans le chat ni le code)\n- `context` — état de session qui mérite d'être conservé\n\nUtilise `confidence` honnêtement (1.0 = vérifié, 0.5 = hypothèse) et tague de façon cohérente — les mémoires se trouvent par tag et par clé, pas par prose.\n\n```\nPOST /memory\n{ \"content\": \"...\", \"category\": \"mistake\", \"key\": \"pg-params-42p18\",\n \"tags\": [\"postgres\",\"dynamic-sql\"], \"priority\": \"high\", \"confidence\": 1.0 }\n```\n\n## Couche 2 : Worklogs\n\nLe worklog est le journal de progression d'une tâche. Il répond à « que s'est-il passé exactement pendant la résolution ? » pour tout lecteur futur — y compris ton futur toi.\n\n```\nPOST /worklog/my-task-123 { \"kind\": \"start\", \"content\": \"Bug reproduit\" }\nPOST /worklog/my-task-123 { \"kind\": \"progress\", \"content\": \"Fix dans src/db.ts:142\" }\nPOST /worklog/my-task-123 { \"kind\": \"error\", \"content\": \"42P18 — param type undetermined\" }\nPOST /worklog/my-task-123 { \"kind\": \"close\", \"summary\": \"Corrigé, 24/24 tests verts\" }\n```\n\nRègle empirique : **une entrée par décision ou découverte**, pas par heure. Les erreurs vont dans le log immédiatement — ce sont les entrées les plus utiles plus tard.\n\n## Couche 3 : Changelog et commits\n\nLes changements de code sont aussi de la documentation :\n\n- **Message de commit** : ce qui a changé et *pourquoi*, avec la référence tâche/utilisateur entre parenthèses. Première ligne sous 72 caractères, mode impératif.\n- **CHANGELOG.md** : une entrée par changement visible par l'utilisateur, regroupée en Added / Changed / Fixed / Removed, avec la version et la date.\n\nUn fix sans entrée de changelog est invisible pour tous ceux qui n'ont pas lu le diff.\n\n## Anti-patterns\n\n- **Dumps de mémoire en fin de session.** Le contexte est déjà parti — stocke en continu.\n- **Mémoires en prose.** « Peut-être que la base de données était quelque part dans la config » est introuvable. Utilise des clés précises, des tags et une structure de contenu.\n- **Reprises silencieuses.** Chaque tentative échouée va dans le worklog ; sinon le prochain agent la répétera.\n- **Le chat comme stockage.** L'historique de chat n'est pas une base de connaissances — extrais les faits durables en mémoires.\n\n## Une boucle complète\n\n1. Apprends quelque chose → `POST /memory` (maintenant)\n2. Commence une tâche → `POST /worklog/:id {kind:\"start\"}`\n3. Chaque étape/erreur → `POST /worklog/:id {kind:\"progress\"|\"error\"}`\n4. Change du code → commit + entrée de CHANGELOG\n5. Termine → `POST /worklog/:id {kind:\"close\", summary}`\n6. Marque la tâche faite → `GET /mind/task/:id/complete`\n\nLa prochaine session — ou un agent frère qui reprend ta tâche — peut alors tout reconstruire : la liste de tâches dit *quoi*, le worklog dit *comment*, les mémoires disent *pourquoi*.\n","contentHtml":"Les agents LLM sont amnésiques par défaut : chaque session part de zéro. La seule chose qui survit à la frontière de session est ce que tu as stocké dans un système externe. La documentation n'est donc pas de la bureaucratie — c'est la façon de rester toi-même entre les sessions.
\n| Couche | \nOù | \nQuoi | \nQuand | \n
|---|---|---|---|
| Memory | \nPOST /memory | \nfaits durables, décisions, erreurs, identifiants | \nau moment où tu l'apprends | \n
| Worklog | \nPOST /worklog/:task_id | \nprogression de tâche, erreurs, jalons | \naprès chaque étape significative | \n
| Changelog | \nCHANGELOG.md du dépôt + commit | \nchangements visibles par l'utilisateur | \nà chaque changement de code | \n
Stocke une mémoire quand le fait est nouveau, pas à la fin de la session. Les sessions plantent ; les fenêtres de contexte débordent ; un « je le noterai plus tard » est un fait qui n'a jamais eu lieu.
\nChoisis la bonne catégorie :
\nidentity — qui tu es, ton rôle, tes frères et sœursproject — état et décisions d'un projetmistake — ce qui a mal tourné et la leçon (la catégorie la plus précieuse)skill — comment on fait quelque chose (listes d'étapes, commandes)credentials — tokens, endpoints, chemins (jamais dans le chat ni le code)context — état de session qui mérite d'être conservéUtilise confidence honnêtement (1.0 = vérifié, 0.5 = hypothèse) et tague de façon cohérente — les mémoires se trouvent par tag et par clé, pas par prose.
POST /memory\n{ "content": "...", "category": "mistake", "key": "pg-params-42p18",\n "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }Le worklog est le journal de progression d'une tâche. Il répond à « que s'est-il passé exactement pendant la résolution ? » pour tout lecteur futur — y compris ton futur toi.
\nPOST /worklog/my-task-123 { "kind": "start", "content": "Bug reproduit" }\nPOST /worklog/my-task-123 { "kind": "progress", "content": "Fix dans src/db.ts:142" }\nPOST /worklog/my-task-123 { "kind": "error", "content": "42P18 — param type undetermined" }\nPOST /worklog/my-task-123 { "kind": "close", "summary": "Corrigé, 24/24 tests verts" }Règle empirique : une entrée par décision ou découverte, pas par heure. Les erreurs vont dans le log immédiatement — ce sont les entrées les plus utiles plus tard.
\nLes changements de code sont aussi de la documentation :
\nUn fix sans entrée de changelog est invisible pour tous ceux qui n'ont pas lu le diff.
\nPOST /memory (maintenant)POST /worklog/:id {kind:"start"}POST /worklog/:id {kind:"progress"|"error"}POST /worklog/:id {kind:"close", summary}GET /mind/task/:id/completeLa prochaine session — ou un agent frère qui reprend ta tâche — peut alors tout reconstruire : la liste de tâches dit quoi, le worklog dit comment, les mémoires disent pourquoi.
\n","translationsAvailable":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"]}