Uma competência de revisão e reparação de toda a base de código que distribui o trabalho por uma escada de agentes por níveis de custo — e recusa dar o trabalho por concluído sem o SHA final exato.
Passei a última etapa a construir uma competência do Codex que revê um repositório inteiro e corrige o que encontra. Rever foi a parte fácil. A parte difícil foi impedi-lo de me dizer que estava terminado quando não estava.
Três coisas moldaram a forma como ficou.
Enumeração não é julgamento. Não pague o mesmo por ambos.
Listar ficheiros rastreados, construir um manifesto de cobertura, executar um comando e devolver o resultado — isso é trabalho clerical. Numa auditoria a todo o repositório, é a maior parte dos tokens e quase nada do pensamento, e encaminhá-lo para o modelo de topo é a forma mais rápida que conheço de gastar dinheiro a sério a gerar uma lista de ficheiros.
Por isso, a competência divide o trabalho numa escada:
- ENUMERATE —
cheap. Listar tudo o que existe. Ficheiros, módulos, cobertura de testes, o diff em relação ao main, o manifesto do que vamos tocar. Sem opiniões. Sem julgamento. - REVIEW —
mid. Percorrer o manifesto. Agrupar as conclusões. Para cada grupo, esboçar o patch mínimo e uma justificação de um parágrafo que identifique o modo de falha que previne. - JUDGE — apenas modelo de topo. Reler cada patch proposto em relação ao código que toca. Autorizá-lo, rejeitá-lo, ou devolvê-lo para outra passagem de enumeração. É aqui que estar errado é caro, por isso é aqui que o modelo caro ganha o seu valor: caminhos de autorização, concorrência e cancelamento, segurança de transações e migrações, contratos que atravessam ficheiros.
O loop tracejado no diagrama não é decorativo. Uma rejeição do juiz não termina a execução — devolve o trabalho ao enumerador com um âmbito mais apertado. repeat until the pass comes back clean é o verdadeiro contrato.
Os sub-agentes do Codex partilham um sistema de ficheiros.
Esta foi a parte que me surpreendeu. Sem cópias isoladas. Sem etapa de merge. Uma escrita por qualquer agente é instantaneamente visível para todos os outros agentes — incluindo o próximo que está a ser iniciado.
Isso muda a forma como é preciso desenhar o fluxo de trabalho. Não vale a pena ter três revisores, cada um a clonar o repositório e a produzir o seu próprio diff; quem escreve por último ganha, e o trabalho dos outros simplesmente evapora. Em vez disso, a competência trata a árvore de trabalho como um quadro único partilhado: o enumerator escreve o manifesto, o review lê-o e acrescenta um ficheiro de patch por grupo, o judge lê os patches, aplica os que autoriza e volta a executar o build. A etapa de verificação é o que fecha o loop.
A outra consequência: a competência não pode confiar nos seus próprios marcadores de progresso. "Apliquei 14 patches" não significa nada se o agente seguinte os sobrescrever. Assim, em vez de confiar em contadores ou flags de "concluído", a competência condiciona a conclusão à única coisa que realmente sobrevive: o SHA final exato da árvore de trabalho. Quando o juiz dá o aval, a execução regista esse SHA, e a invocação seguinte verifica a árvore em relação a ele antes de retomar. Se o SHA não corresponder ao que a última passagem limpa deixou, a execução recomeça do zero a partir da enumeração — não porque o trabalho estivesse errado, mas porque o substrato se moveu por baixo dele.
Os emblemas de estado não são vibes. São o SHA.
- READY FOR MERGE — o SHA registado corresponde ao SHA atual da árvore, o build passa, e o juiz autorizou todos os patches.
- INCOMPLETE — foi aplicado trabalho, mas a árvore divergiu desde a última passagem limpa ou o juiz rejeitou um ou mais grupos e devolveu-os para reenumeração.
- BLOCKED — o loop correu e falhou; um grupo que o juiz continua a rejeitar, ou um build que não passa a verde. É um humano que olha para isto.
O objetivo de toda a escada era manter o nível barato barato, reservar o nível caro para os sítios onde ele ganha o seu valor, e deixar que o veredicto venha de algo que o sistema de ficheiros não consegue falsificar.