O que faz uma lição atravessar de um projeto para outro é a retratação escrita, não a ferramenta

Cinco sistemas de trading meus rodavam em paralelo havia meses: SignalForge, Equity_Tracker, Daytrading, Solo_Trader e DMR. Cada um com o próprio agente, o próprio arquivo de lições, a própria lista de itens de ação. E cada um cego para o que o vizinho já tinha descoberto pagando caro.

A pergunta que me incomodava era estreita. Uma lição que um sistema aprendeu apanhando: ela precisa ser paga de novo pelo próximo, ou dá para atravessar essa fronteira? O que montei para responder chama-se One_Ring e não tem uma linha de código. Nenhum ponto de entrada, nenhum script, nenhum despachante. Sobrou uma pergunta pior do que a primeira — como um orquestrador sem automação nenhuma produz mudança de código em outro projeto?

Cada sistema aprendia sozinho, e a lição cara morria na pasta de origem

Todo repositório já tinha o essencial: agente próprio, arquivo de lições, itens de ação, documento de passagem de contexto. O que não existia era o papel de ler os cinco e comparar um com o outro. Nenhum agente de projeto abre o repositório do vizinho, nem tem por que fazer isso.

O resultado foi o previsível. Uma descoberta cara feita numa terça dentro de um sistema chegava aos outros só se eu lembrasse dela semanas depois, no meio de outro assunto. A tentação era construir um canal entre os agentes — um barramento, uma integração qualquer. Nunca construí, pelo mesmo motivo que hoje me impede de automatizar.

O orquestrador que resolveu isso não tem uma linha de código

As pastas de código do repositório — src/, app/, tools/, utils/ — estão vazias de propósito. O mecanismo real é outro: abro uma sessão nova do Claude Code, peço ao agente para ser o orquestrador, e ele lê os repositórios dos outros projetos direto pelo sistema de arquivos. Leitura, nunca execução. A saída é sempre um documento em markdown.

Os achados voltam como itens de ação com nome e dono, entregues ao agente do projeto de destino numa sessão separada. Não existe registro de agentes nem configuração de MCP dentro do orquestrador. A única coisa parecida com fiação é uma marcação de domínios no CLAUDE.md, que alimenta a memória entre sessões — injeção passiva, não despacho.

Esse desenho funciona porque cada achado passa por mim antes de virar ação em outro projeto, e é aí que mora o custo. A validação humana que segura a qualidade é a mesma que impede a automação: tirar a pessoa do meio derruba as duas de uma vez.

O que atravessa a fronteira é comparação entre dois sistemas, não conselho geral

O primeiro achado que virou correção saiu de uma leitura lado a lado. A produção de um dos sistemas checava entradas e saídas todo dia, enquanto o backtest já validado daquele mesmo sistema usava rebalanceamento semanal. A configuração diária deixava 1.200 pontos percentuais na mesa. A correção foi um portão semanal na rotina de produção.

O segundo veio de um backtest cruzado entre sistemas: quatro indicadores eram detratores líquidos para um subconjunto de ativos — BDRs — de outro projeto, porque mediam ruído cambial entre real e dólar em vez de fundamento. A correção confirmada foi mapear esse subconjunto para o conjunto de indicadores do mercado original.

O terceiro é o meu favorito porque não era achado técnico. Uma lição de um sistema dizia que premissa de especificação é evidência, não suposição. Ela virou princípio cruzado quando o tempo de execução de uma rotina de outro sistema saltou de 44–53 minutos para 157–172 minutos em três dias, invertendo uma premissa que ninguém tinha reconferido. O mesmo formato de erro apareceu de forma independente num terceiro sistema, com limiares travados antes de os dados existirem. Numa outra passagem, uma revisão comparativa entre dois sistemas rendeu 6 itens de ação para cada um — 12 no total, entregues aos respectivos agentes.

Três recomendações minhas estavam erradas, e a correção ficou no mesmo documento

A primeira: recomendei construir só a versão mínima de uma peça de arquitetura, com o argumento de que a promoção real estava a quatro ou seis meses de distância. Inverti a posição depois que me apontaram que 1.058 operações simuladas e 251 células abaixo do limiar já existiam e podiam exercitar a máquina inteira agora, com dados sintéticos.

A segunda: recomendei apagar um módulo inteiro. Uma verificação de importações mostrou que um arquivo daquele módulo ainda era usado por um componente em produção, um explicador diário. O que ficou foi arquivamento cirúrgico — 5 módulos, 1 script e 4 testes — com o arquivo em uso intocado.

A terceira: critiquei duas camadas de um sistema por serem "descritas como essenciais quando na verdade eram experimentais". Retratei por escrito. O documento de arquitetura já rotulava cada camada por status, e aquelas duas estavam marcadas como aspiracionais, com limiares pré-registrados. O pré-registro, que eu tinha contado como fraqueza, era a força do desenho. Numa quarta situação nem cheguei a recomendar: recusei criar mais uma cerimônia de verificação ao lado de um portão existente, porque isso repetiria o ritual sem rigor que uma lição anterior já descrevia.

Três inversões de posição em cinco dias, entre 2026-05-10 e 2026-05-15. Nenhuma delas foi pega por mim sozinho — todas vieram de alguém do lado que recebia a recomendação, com contexto suficiente para discordar.

Nada disso roda sozinho, e o perfil de cada sistema envelhece rápido

Não existe executor agendado, nem detecção automática de diferença entre projetos. Cada passagem começa comigo abrindo a sessão e escolhendo o que entra na leitura, e só acontece quando eu decido que vai acontecer. O custo em tokens de cada passagem nunca foi medido, e não existe controle de orçamento para essas sessões.

O perfil que o orquestrador mantém de cada sistema é uma foto; os sistemas não são. Um perfil com três dias de idade já tinha derivado de forma relevante, sob projetos que recebiam uma ou duas mudanças substantivas por dia. E o processo já produziu um falso-positivo confirmado: generalizei que um sistema tinha disciplina de paridade embutida, e uma varredura de correção encontrou três bugs de paridade entre críticos e altos no mesmo código.

A regra dos dois projetos é a defesa que adotei contra esse tipo de pressa. Lição de um projeto continua com escopo de projeto, por mais universal que soe, até dois sistemas baterem na mesma parede de forma independente. Isso deixa achado correto parado num limbo de candidato até a segunda observação chegar — e eu prefiro esse limbo ao alternativo, que já me custou três retratações numa semana.

Um achado cruzado só merece confiança depois de duas observações e de uma discordância possível

O que faz esse processo funcionar não é o mecanismo, porque mecanismo não existe. É o hábito de escrever cada retratação com a mesma visibilidade do achado que ela corrige, no mesmo documento, sem nota de rodapé.

O teste prático tem duas condições, e as duas precisam valer: duas observações independentes confirmando o mesmo padrão, e alguém do lado que recebe a recomendação com espaço real para dizer que ela está errada. A condição de falseamento é simples de reconhecer. No dia em que esse processo emendar uma sequência de recomendações que ninguém contesta, o motivo provável não será que elas melhoraram — será que o contexto do outro lado parou de ser lido.