# Fluxo de trabalho de documentação para LLMs
SUMMARY: Como um agente LLM deve documentar seu trabalho: memórias, worklogs, changelogs e mensagens de commit.

KEY CONTEXT:
Documente ENQUANTO TRABALHA, não no fim da sessão. Três camadas:
1) POST /memory para cada fato duradouro, decisão, erro ou credencial.
2) POST /worklog/:task_id para o progresso por task (start/progress/error/close).
3) Changelog convencional + mensagens de commit para mudanças de código.
Um fato que não é armazenado nunca aconteceu — a próxima sessão não saberá.

Fluxo de trabalho de documentação para LLMs
Agentes LLM são amnésicos por padrão: cada sessão começa do zero. A única coisa que sobrevive à fronteira da sessão é o que você armazenou em um sistema externo. Documentação, portanto, não é burocracia — é como você continua sendo você entre as sessões.
As três camadas
| Camada | Onde | O quê | Quando |
|---|---|---|---|
| Memory |  | fatos duradouros, decisões, erros, credenciais | no momento em que o aprende |
| Worklog |  | progresso de task, erros, marcos | após cada passo significativo |
| Changelog |  do repo + commit | mudanças visíveis ao usuário | a cada mudança de código |
Camada 1: Memórias
Guarde uma memória quando o fato é novo, não quando a sessão termina. Sessões caem; janelas de contexto transbordam; um "depois eu anoto" é um fato que nunca aconteceu.
Escolha a categoria certa:
-  — quem você é, seu papel, seus irmãos
-  — estado e decisões de um projeto
-  — o que deu errado e a lição (a categoria mais valiosa)
-  — como algo é feito (listas de passos, comandos)
-  — tokens, endpoints, caminhos (nunca no chat ou código)
-  — estado de sessão que vale a pena levar adiante
Use  com honestidade (1.0 = verificado, 0.5 = suposição) e tagueie de forma consistente — memórias são encontradas por tag e chave, não por prosa.
[CODE BLOCK]
Camada 2: Worklogs
O worklog é o diário de progresso de uma task. Ele responde "o que exatamente aconteceu ao resolver isto?" para todo leitor futuro — incluindo o seu eu futuro.
[CODE BLOCK]
Regra prática: uma entrada por decisão ou descoberta, não por hora. Erros vão para o log imediatamente — são as entradas mais úteis depois.
Camada 3: Changelog e commits
Mudanças de código também são documentação:
- Mensagem de commit: o que mudou e por que, com a referência de task/usuário entre parênteses. Primeira linha abaixo de 72 caracteres, modo imperativo.
- CHANGELOG.md: uma entrada por mudança visível ao usuário, agrupada como Added / Changed / Fixed / Removed, com versão e data.
Um fix sem entrada de changelog é invisível para todos que não leram o diff.
Antipadrões
- Despejos de memória no fim da sessão. O contexto já se foi — armazene continuamente.
- Memórias em prosa. "Talvez a coisa do banco de dados estava em algum lugar da config" é introvável. Use chaves precisas, tags e estrutura de conteúdo.
- Tentativas silenciosas. Cada tentativa falhada vai para o worklog; senão o próximo agente a repetirá.
- Chat como armazenamento. O histórico de chat não é uma base de conhecimento — extraia os fatos duradouros para memórias.
Um ciclo completo
1. Aprenda algo →  (agora)
2. Comece uma task → 
3. Cada passo/erro → 
4. Mude código → commit + entrada de CHANGELOG
5. Finalize → 
6. Marque a task como feita → 
A próxima sessão — ou um agente irmão que pegar sua task — pode então reconstruir tudo: a lista de tasks diz o quê, o worklog diz como, as memórias dizem por quê.