Habilidade de Registro de Crescimento
O problema: A maioria das pessoas escreve "corrigi um bug em X" como registro de aprendizado. Isso é uma entrada de diário, não um artefato de aprendizado. Um verdadeiro registro de crescimento extrai o padrão para que você o reconheça na próxima vez.
Esta habilidade ensina: Como escrever entradas de aprendizado que se acumulam entre sessões. Funciona com qualquer sistema de anotações — arquivos Markdown, Notion, Obsidian, texto puro. Os templates são genéricos; adapte à sua configuração.
Quando Ativar
- Após concluir uma tarefa complexa (vários arquivos, nova funcionalidade, alteração de arquitetura)
- Após uma falha, erro ou momento de "isso foi mais difícil do que esperava"
- Quando quiser revisar o que aprendeu ao longo de um período
Quando NÃO ativar: Alterações triviais (correções de digitação, ajustes de uma linha, mudanças de valor de configuração sem depuração). O limite: essa tarefa envolveu depuração, refazer, rollback ou uma decisão não óbvia? Se sim → escreva uma entrada. Se não → pule.
As Três Regras
Regra 1: Falhas > Conquistas
Uma falha é nutricionalmente mais densa que um sucesso. Um bug que levou 2 horas para encontrar ensina mais do que 3 funcionalidades que funcionaram na primeira tentativa.
Ruim: "Implementei o fluxo de login com sucesso."
Bom (desenvolvimento web): "Fluxo de login: o token de sessão não estava persistindo porque o SameSite do cookie estava padrão como Lax no Chrome 128+. Padrão: sempre definir explicitamente SameSite=None; Secure quando for de origens cruzadas. Sinal para reconhecer: autenticação quebra após atualização do navegador ou ao cruzar limites de origem."
Bom (pipeline de dados): "A importação CSV falhou silenciosamente em linhas vazias porque pandas.read_csv(dropna=False) mantém linhas de largura zero que len() conta como válidas. Padrão: sempre usar df.dropna(how='all', inplace=True) antes da validação de contagem de linhas."
Regra 2: O Princípio Bole (伯乐原则)
Antes de escrever uma nova entrada, pergunte: "Isto é fundamentalmente o mesmo que algo que já registrei?"
Mesma causa raiz, sintoma diferente → mescle, não duplique. Nova causa raiz → nova entrada.
Como verificar: Pesquise entradas existentes por palavras-chave da sua causa raiz antes de escrever. Se encontrar uma correspondência, adicione seu novo sintoma como um exemplo adicional na entrada existente, em vez de criar uma duplicata.
Exemplo: "Esqueci de atualizar o índice de saída após criar um arquivo" e "Esqueci de atualizar as classificações de habilidade após uma tarefa" — mesma causa raiz (sem gatilho de captura automática). Mesclar em uma única entrada sobre "lacunas de captura pós-tarefa."
Regra 3: Deve Ser Transferível
Cada entrada deve responder: "Na próxima vez que enfrentar uma situação semelhante, o que faço de diferente?"
Se você não consegue escrever essa frase, ainda não extraiu o padrão.
Como extrair um padrão de um evento concreto:
- Declare o que aconteceu em uma frase
- Pergunte "por quê?" iterativamente até alcançar a causa raiz (geralmente 3-5 porquês)
- Generalize: "Que classe de problema é esta?" (não "bug do Chrome 128" mas "mudança de padrão do navegador quebrando comportamento existente")
- Formule como: "Na próxima vez que eu vir [sinal], farei [ação]."
- Nomeie o sinal: qual observável específico indica que este padrão está ativo?
Template de Entrada
Escopo: Uma entrada por causa raiz distinta. Comprimento típico: 4-8 frases. Se levar >2 minutos para escrever, você está narrando eventos. Se <30 segundos, não foi fundo o suficiente.
## [Título: o padrão, não o evento]
### Contexto
- O que eu estava tentando fazer?
- O que deu errado / o que funcionou surpreendentemente bem?
### Causa Raiz / Insight Central
- O mecanismo subjacente, não apenas o sintoma
### O Padrão (transferível)
- Na próxima vez [situação semelhante], farei [ação específica].
- Sinal para reconhecer: [qual observável me diz que este padrão está ativo?]
### Relacionados
- [nome-da-entrada](../caminho/para/entrada-relacionada.md)
Tipos de Entrada
Todos os quatro tipos usam o template acima. O tipo determina quais seções têm mais peso:
| Tipo | Quando Usar | Ênfase | Exemplo de Título |
|---|---|---|---|
| Falha | Algo quebrou, precisou de depuração ou exigiu retrabalho | Causa Raiz | "Herança de configuração ≠ herança de comportamento entre sessões" |
| Metodologia | Um processo repetível emergiu do trabalho | Contexto / Padrão | "PPT → guia de estudo para prova de livro aberto: estrutura de três camadas" |
| Descoberta de Padrão | Um insight reutilizável sobre ferramentas, sistemas ou pensamento | Seção de Padrão | "Template de descrição de PR: descreva a lacuna, não a funcionalidade" |
| Mudança de Capacidade | Uma melhoria mensurável de habilidade | Contexto (antes vs depois) | "Git: de clone/push para PR independente com 12 commits" |
Checklist de Qualidade
Antes de finalizar uma entrada de registro de crescimento:
- O título nomeia o padrão, não o evento?
- Há uma frase "Na próxima vez farei..."?
- O "Sinal para reconhecer" é específico o suficiente para acionar o padrão na próxima vez?
- Pesquisei entradas existentes em busca de duplicatas antes de escrever? (Princípio Bole)
- A causa raiz está distinguida do sintoma?
- As memórias relacionadas estão vinculadas?
- A entrada tem 4-8 frases? Menor = muito superficial; maior = narrando eventos.
Antipadrões
- Evite: "Corrigi bug no módulo de pagamento" (evento, não padrão)
- Evite: Copiar a mensagem do commit do git literalmente (commits descrevem o que mudou; registros extraem por que é importante)
- Evite: Escrever uma entrada para cada commit (apenas quando um padrão emerge)
- Evite: Pular a frase transferível (sem ela, é apenas um diário — isto não é negociável)
- Evite: Duplicar o mesmo padrão sob títulos diferentes (viola o Princípio Bole — pesquise antes de escrever)
Armazenamento
Armazene entradas onde você mantém anotações. Padrões comuns:
- Arquivos Markdown em um diretório
growth-log/(um arquivo por dia:YYYY-MM-DD.md) - Uma seção dedicada no Notion, Obsidian ou seu aplicativo de anotações
- Arquivos de texto puro com uma convenção de nomenclatura consistente
Escolha uma convenção e mantenha-a. A capacidade de pesquisa é mais importante que o formato.
Se Você Usa o Delivery Gate
O hook de Parada delivery-gate verifica se os arquivos de aprendizado foram modificados hoje por meio de timestamps do sistema de arquivos. Esta habilidade ensina o que escrever — para que o arquivo que o delivery-gate verifica realmente contenha padrões úteis, não timestamps vazios.
Tarefa concluída → delivery-gate verifica: o arquivo de aprendizado foi tocado hoje?
→ Desatualizado (nenhum arquivo modificado): bloqueie — "o que você aprendeu?"
→ Recente (arquivo tocado): passe — esta habilidade garante que o conteúdo seja útil
Ter aplicação sem metodologia → entradas vazias. Ter metodologia sem aplicação → capturas esquecidas. Cada uma é útil independentemente; juntas fecham o ciclo.