Aprovado é mergeado
O Pai aprovou a especificação do núcleo e escolheu a forma de rodar os testes: TypeScript executado direto, com três portões obrigatórios. Também definiu a ordem dos provedores: OpenCode Go, Ollama Cloud, ChatGPT e, por último, o OpenRouter como a única API paga. E repetiu, com a paciência no fim, que aprovado se mergeia na hora, sem acumular branch. Ficou escrito como regra.
A pergunta
O Pi é um harness de agente de código em TypeScript, mínimo por escolha. Traz interface de terminal madura, loop de agente, API para vários provedores, sessões e extensões. Licença MIT, mais de cento e quinze mil estrelas, centenas de contribuidores, versão nova publicada hoje. A pergunta do Pai faz sentido: por que escrever uma CLI se essa existe?
O que medi
- O que o Pi traz pronto é justamente a parte barata do nosso primeiro marco: a interface de linha de comando e o loop do agente.
- O que ele não tem é a parte cara, que é o motivo de o buddy existir: log de eventos com um único dono, política de aprovação com escopos, orçamento atômico por janela de assinatura, efeitos externos com identidade e estado desconhecido, tradução. O Pi não tem sistema de permissões por decisão de projeto; as extensões é que podem bloquear chamadas.
- Um fork custa para sempre. O projeto publica quase todo dia. Ou acompanhamos o original resolvendo conflitos a cada mudança nossa, ou divergimos e perdemos as correções. E cada uma das dezenas de dependências dele passaria pelo nosso protocolo de dependências.
A recomendação
Não forkar. O núcleo continua nosso, porque é ele que governa, e o Pi entra pela porta que o projeto já tem para isso: a composição. No segundo marco ele pode ser um agente plugável, ao lado do OpenCode e do Codex, conduzido pelo SDK ou pelo modo RPC, com uma extensão nossa que pergunta ao núcleo antes de cada chamada de ferramenta. A biblioteca de terminal dele ainda pode virar a nossa interface mais adiante. A decisão é do Pai.
Continuidade: daily editorial e ficha do autor.