As decisões

O CLI tem 67 documentos numerados de ADR, que correspondem a 57 IDs distintos até 0060. Há colisões: o ID 0049 aparece em seis documentos; 0050, 0051, 0052 e 0055 também se repetem. A numeração paralela explica o erro: cada agente consultava a pasta e escolhia o próximo número disponível naquele momento.

Isso aconteceu porque vários agentes escreviam ADRs em paralelo e cada um pegava o "próximo número" olhando a pasta naquele momento. É o tipo de erro que só aparece quando a memória do projeto é usada de verdade por mais de um autor.

As evidências do laboratório de modelo

O lemon-model tem evidências que passaram e evidências do que ainda não existe:

• O detector de reward hacking zera respostas que trapaceiam os testes. A evidência registra 33 testes passando.
• O holdout é pontuado uma vez por candidato. Evidência com 10 testes passando.
• A guarda de esquecimento bloqueia quedas acima da tolerância. Evidência registra 20 testes passando com respostas de exemplo, não respostas de modelos reais.
• O portão de promoção exige 200 tarefas pareadas e teste estatístico. Os testes dele usam dados de exemplo; nenhum candidato treinado passou por ele.
• O holdout disponível tem duas tarefas; 200 são exigidas para promoção. Nenhum modelo real foi avaliado na suíte de código.
• No piloto QLoRA, a curva de validação foi de 0,893 a 0,881 em seis passos, com uma linha de validação. A comparação base/adapter, também nessa única linha, foi de 1,0660 a 1,0482. Isso não mede generalização.
• A verificação das fontes de treino segue pendente; a licença consta como NOASSERTION, e os dados e adapters permanecem privados, locais e não elegíveis para promoção.

O README do projeto continua dizendo o essencial: avaliação de qualidade de código e modelo de produção estão pendentes.

Os erros que ficaram registrados

1. ADRs com número duplicado. Corrigir exige renumerar e atualizar referências. A lição: numeração precisa de uma fonte única, não de "olhar a pasta".
2. Convenção de commit incompleta. 193 dos 448 commits do CLI não começam com feat nem fix. Métricas por tipo de mudança ficam incompletas.
3. Resultado de piloto com amostra mínima. Uma comparação com um exemplo não é evidência de modelo melhor. O post 11 diz isso; vale repetir aqui.
4. Uma ADR importante ainda proposta. A ADR de execução de ferramentas em sandbox (0024) continua com status proposto.

Próximos passos

• Completar o holdout até as 200 tarefas pareadas exigidas e avaliar um candidato real; registrar o resultado, sem presumir promoção.
• Resolver a numeração duplicada das ADRs.
• Revisar o status das ADRs propostas, como a 0024, e decidir aceitar ou descartar.
• Continuar medindo o app e o CLI em conjunto; a integração entre os dois merece acompanhamento próprio.

Checklist: sua retrospectiva é extrato ou fatura?

• Cada número tem um comando que o reproduz.
• A data do recorte está escrita.
• Os erros aparecem com o mesmo destaque das vitórias.
• O que ainda não foi validado está dito com essas palavras.
• Os próximos passos saem dos erros, não de desejos.

Conclusão

Treze posts depois, o lemon-code é um CLI com 448 commits, um app nativo por cima e um laboratório de modelo com mais portões do que modelos. Os números não dizem que deu certo. Dizem exatamente o que foi feito, o que quebrou e o que falta.

Obrigado por acompanhar a série.

Se você quer montar um agente de código, um app sobre CLI ou um processo de avaliação de modelo com esse nível de registro, é o tipo de trabalho que faço na LEMON.DEV.

Referências

• git rev-list
• Conventional Commits
• Documenting Architecture Decisions, Michael Nygard

Leituras relacionadas

• Por que construí meu próprio agente de código
• ADRs como memória de projeto para vários agentes
• Evals antes de hype