Maestro, esteira de agentes de código
A issue entra no quadro, um agente implementa, outro revisa e um terceiro valida em staging. Se quebrar, o revert é automático.
Meu papel
Projetei e escrevi tudo. São 122 commits, todos meus, e 110 arquivos de teste.
- 122
- commits, todos meus
- 110
- arquivos de teste
- 11
- campos tipados no contrato de máquina
Problema
Na primeira versão da nossa esteira com agentes, os runtimes caíam 14 vezes por semana, sobravam 125 processos órfãos, o rebase serial levava de 72 a 115 minutos por issue e merges saíam com base em regex sobre comentário.
Solução
Reescrevi o plano de controle como um daemon único em Python só com biblioteca padrão, com estado em SQLite e outbox transacional. Nenhuma transação atravessa I/O de rede ou de git, e a intenção é gravada antes de qualquer efeito irreversível, como merge ou push de revert. Se cair no meio, reconcilia sozinho quando volta.
Destaques
- Fila de merge especulativa. O CI da próxima issue roda numa branch sintética enquanto a atual é validada em staging.
- A validação é feita pelo agente do outro sócio, que confere se o SHA validado é o que está em staging. Regressão gera revert na main e devolve a issue para a fila.
- Contrato de máquina com 11 campos tipados no quadro em vez de regex em comentário.
- Dois bots de Telegram, com um card vivo por issue, caixa de "precisa de você" com botões, resumos diários e canal de incidentes sem duplicata.
- Manutenção noturna que espera os agentes terminarem, atualiza as ferramentas com rollback e retoma a esteira.
Resultado
É a esteira que entrega o Alliomed hoje.