chimera-carry-the-failure-forward

Você tem um loop que roda uma tentativa, a julga, e roda outra com feedback: um agente com um verificador, um corretor de código contra uma suíte de testes, um pipeline de gerar-e-conferir. O orçamento é de mais de duas tentativas, e o workspace é revertido entre elas, de modo que cada tentativa começa limpa.

Não se aplica a um retry idempotente sobre um transporte instável — uma chamada de rede que falhou por razões sem relação com o que você enviou. Ali não há nada a aprender com a tentativa 1, e carregá-la adiante é só payload.

1. Guarde as tentativas em uma lista, não em uma variável que você reatribui. Um registro por tentativa: a saída do verificador, o patch que a tentativa de fato escreveu, e qual passo de tool falhou primeiro.
2. Tire o patch do snapshot do workspace, antes da reversão — o diff de verdade, não a descrição que o modelo deu do que mudou. A reversão é o que torna isso necessário: uma vez que a árvore volta atrás, nada em disco registra o caminho errado tampouco, então a próxima tentativa não tem obstáculo nenhum para re-derivar o mesmo caminho.
3. Componha o prompt de retry a partir de todos os registros, do mais antigo para o mais novo, cada um rotulado com o número da tentativa e seu veredito, sob um cabeçalho que diga que essas já foram tentadas e revertidas.
4. Limite cada registro. O Chimera trunca um diff realimentado em 2000 caracteres e marca o corte; um histórico de três tentativas sem limite vai dominar o prompt.
5. Deduplique por assinatura de falha. Se duas tentativas falharam do mesmo jeito, mantenha uma e registre que aquilo se repetiu — a repetição é o sinal, a segunda cópia não é informação nova.
6. Quando a assinatura se repetir, pare de acrescentar e mude algo estrutural: replaneje com as causas acumuladas como contexto do planejador (TaskLedger.context() as renderiza sob "Why earlier attempts failed (do NOT repeat these):"), ou escale para um modelo mais forte. Mais feedback sobre o mesmo beco sem saída não sai do beco sem saída.
7. Emita um evento contável a cada vez que você injeta histórico, para que um braço de benchmark consiga provar que a injeção sequer disparou.

Ancoragem é a contra-hipótese registrada, não uma hipótese vaga: mostrar a um modelo o patch errado pode fixar a atenção dele naquele patch e produzir variações de uma abordagem morta em vez de uma abordagem diferente. É por isso que o comportamento é opt-in e medido no Chimera (--diff-feedback), em vez de ligado por padrão. Trate isso como uma afirmação a testar nas suas próprias tarefas, não como uma melhoria estabelecida.

O segundo custo é o orçamento de contexto. Três diffs, três dumps de verificador e uma revisão do gerente podem empurrar o prompt além do limiar de compactação — e aí um compactador sem restauração vai descartar exatamente o histórico acumulado que você pagou para construir. Limite os registros e conheça o seu orçamento antes de ligar isso, ou os dois mecanismos vão brigar e o sintoma visível não será nenhum dos dois.