# De onde vem o T25

> A origem do projeto, o que o dogfood nos ensinou e os princípios que não negociamos na caminhada de um orquestrador local para uma fábrica de software.

- Por: Djan Magno
- Publicado em: 2026-09-26
- Atualizado em: 2026-09-26
- URL: https://t25.io/blog/de-onde-vem-o-t25/
- Lançamentos · t25 factory, história do projeto, agentes de código, engenharia de software, gates humanos, early evaluators

> **Resumo:** > - O T25 nasceu em agosto de 2026 como um orquestrador local simples: dar a cada tarefa uma worktree isolada e uma máquina de estados que nenhum agente contorna.
> - O dogfood com agentes reais (44 tarefas, até a `TASK-0044`) mostrou onde o desenho quebrava e virou a fila de correções: veredito recalculado, retrabalho por slice, limites de diff.
> - Hoje a fábrica tem control plane durável em Postgres, worker com lease e heartbeat, auditoria e evals de processo. O merge continua humano, por escolha e não por limitação técnica.
> - O próximo capítulo é um programa de early evaluators por convite: rodar na sua máquina, com os CLIs que você já assina.

## O ponto de partida

O repositório começou em 22 de agosto de 2026 com um commit que já diz a ideia inteira: habilitar git worktrees para execução isolada de tarefas. Não era um produto ainda. Era uma convicção de que agente de código, rodando sozinho no checkout principal da sua máquina, não escala, nem em confiança, nem em volume.

A ideia que antecede esse commit é simples: toda empresa pode ter a sua própria fábrica de software. O T25 nasceu da decisão de construir uma. O que os documentos registram é o problema que o projeto passou a atacar desde então: times que já usam agentes de código sem governança. A revisão acontece no improviso de um terminal, o escopo é o que o modelo decidiu tocar, o isolamento é inexistente e o merge é uma decisão que ninguém assumiu de fato. Cada um desses pontos virou uma peça do desenho.

## O que o dogfood ensinou

Nós não escrevemos o T25 para escrever o T25. Desde o início, o repositório do próprio projeto foi a linha de produção: cada fatia de funcionalidade passa pela mesma máquina de estados que qualquer tarefa, spec, plano, gate, worktree, QA, review, pull request.

Em setembro de 2026 o dogfood já tinha 44 tarefas completas, com PR real mergeado (`TASK-0008`), piloto (`TASK-0009`), rodadas de regressão, brownfield, greenfield e uma prova de merge (`TASK-0036`). A tarefa mais importante não foi nenhuma dessas. Foi a `TASK-0044`, que quebrou de um jeito instrutivo: um reprova de QA externo ao escopo da tarefa fazia o pipeline reexecutar o plano inteiro. Com quatro slices, uma única falha de QA custava oito runs de desenvolvimento para consertar nada.

Esse incidente virou rework por slice: findings estruturados com categoria, critérios e arquivos; o retrabalho passou a mirar só as slices atingidas, com um cursor durável que sobrevive a pausa e retomada. No comparativo controlado, a mesma falha caiu de oito runs para quatro, zero retrabalho quando a falha era externa ao escopo. O número importa menos que o hábito que ficou: cada bug real do dogfood fecha uma lacuna determinística, não um prompt mais longo.

Do mesmo período vem a lição que virou post próprio: o veredito que um agente reviewer escreve é um sinal de entrada, não uma decisão. O `APPROVE` do modelo continua registrado; quem decide é a política, recalculada a partir dos findings. Está em [O APPROVE do modelo não é o merge](https://t25.io/blog/o-approve-do-modelo-nao-e-o-merge/).

## De orquestrador local a fábrica

A primeira versão era um processo local com estado em disco. Funcionava, até querer restartar o worker no meio de uma tarefa, ou responder de onde veio uma transição, ou recuperar uma fila após queda. Em setembro de 2026, três decisões arquiteturais formalizaram a evolução:

1. **Control plane em Postgres.** Tarefas, runs, leases e eventos passam a viver num banco durável com trilha de auditoria, em vez de JSON na pasta de estado. Restart do processo deixa de ser evento.
2. **Protocolo de worker.** Um worker remoto assina leases com credencial própria, envia heartbeat e reconhece conclusão. A fila deixa de ser local por acidente e vira contrato.
3. **Armazenamento de artefatos endereçado por hash.** Specs, planos e relatórios viram conteúdo endereçável, o que permite revisitar exatamente o que o pipeline leu quando decidiu.

Em paralelo, o projeto ganhou evals de processo, gates determinísticos que reproduzem cenários adversariais (projeto vazio, comando quebrado, checkout stale, objetivo ambíguo) e separam falha de infraestrutura de falha de produto, e a supervisão de progresso, que pausa uma tarefa quando o mesmo erro se repete ou o mesmo critério fica sem prova, em vez de deixar o agente gastar orçamento em loop.

Em setembro veio o rename: a superfície pública passou a se chamar T25. O nome é uma referência ao T-25 Universal, avião usado no aprendizado de voo militar da Força Aérea Brasileira. O nome ficou como referência ao ponto de partida de quem aprende a voar com procedimento antes de ganhar autonomia: checklist antes de cada voo, alguém ao lado e autonomia liberada aos poucos. É a postura que queremos de um agente de código. O pacote e os identificadores internos mantêm o nome antigo por compatibilidade, e a frase que resume o produto sobreviveu a todas as versões: uma ordem entra, um pull request sai, e o merge continua sendo seu.

## Os princípios que não negociamos

Depois de um mês de dogfood, os princípios pararam de ser intenção e viram teste de regressão:

- **Isolamento por tarefa.** Nenhum agente roda no checkout principal. Cada ordem ganha uma worktree e uma branch próprias, com validação de caminho e limpeza que nunca apaga mudança não commitada. Detalhes em [Uma ordem, um worktree](https://t25.io/blog/uma-ordem-um-worktree-isolando-agentes-de-codigo/).
- **O modelo não decide o próprio veredito.** Saída estruturada entra; veredito sai de uma função determinística. Saída que não parseia falha fechado.
- **Gate humano proporcional ao risco.** Spec sempre passa por pessoa; plano depende do risco; merge, sempre. A política decide o que chega até você.
- **Custo e credencial com o usuário.** O T25 roda local e chama os CLIs de agente que você já assina. Não há chave de API nova para vazar.
- **Toda decisão deixa rastro.** Eventos sequenciais, artefatos com hash e auditoria append-only respondem "quem, quando e o quê" sem depender da memória de ninguém.

## O que vem agora

O T25 está em early access, com distribuição privada: um pacote instalado por tarball verificado por checksum, um `t25 doctor --evaluation` que valida o ambiente antes da primeira ordem e um programa de early evaluators por convite, gratuito durante os 30 dias de avaliação, rodando na sua máquina. O T25 não coleta seu código, prompts, logs nem credenciais; os CLIs de agente que você usa seguem enviando aos provedores deles, na sua conta.

A próxima prova não é mais interna: é uma coorte externa de avaliação self-hosted, medida por primeiro pull request, segunda execução e entrevista, nunca apenas por instalação. Se quiser acompanhar a fundo o desenho antes de pedir o convite, a [documentação](https://t25.io/docs/) cobre a máquina de estados, a configuração e o contrato do worker.

## Perguntas frequentes

### O código do T25 é aberto (open source)?

Não. O código não é público. Avaliadores recebem um pacote privado sob os Termos de Avaliação, que proíbem redistribuição, engenharia reversa e uso comercial sem contrato.

### Por que o merge continua humano?

Porque o merge é a decisão com maior blast radius do pipeline, e porque quem responde pela main precisa poder responder de fato. A fábrica trabalha para que o que chegue até esse botão já tenha passado por spec aprovada, QA, review com veredito recalculado e limites de diff. O botão, porém, é seu.

### O que significa T25?

É uma referência ao T-25 Universal, avião usado no aprendizado de voo militar da Força Aérea Brasileira. Como um avião de instrução, o T25 trabalha com procedimento, supervisão e autonomia liberada aos poucos.

### Como entro no programa de early evaluators?

Por convite: o link pessoal de download chega por e-mail, o instalador verifica o checksum do pacote e o `t25 doctor --evaluation` valida o ambiente. As inscrições abrem em breve pela página de convite.