Pular para o conteúdo
H1VE

O case

Como a H1VE constrói a H1VE.

O H1VE Flow é construído sob o método H1VE desde a primeira linha. Não é uma demo encenada. É o registro real de um produto em produção, com um único arquiteto humano e agentes de IA escrevendo a maior parte do código: os números, um ciclo real e o que a memória do projeto capturou pelo caminho.

Os números

O que o método produziu, contado.

155
SPECs
escritas e aprovadas antes de qualquer código
170+
pull requests
cada uma mergeada pelo mesmo gate humano
1.243
testes
na suíte, com um gate de CI em cada PR
33
migrations de banco
aplicadas migration-first em produção
1
arquiteto
com autoridade exclusiva de merge
0
features
entraram em desenvolvimento sem uma spec aprovada

Números do repositório do H1VE Flow em julho de 2026. Cada SPEC e cada DONE é versionado ao lado do código.

O ciclo na prática

Um exemplo real, do registro do projeto.

A swim lane real do projeto: cada card é uma feature cruzando os estágios até a main.

A camada de memória do H1VE grava as decisões do projeto num arquivo que o agente carrega no início de cada sessão. A primeira versão commitava esse arquivo direto na branch padrão. Funcionava nos testes. Falhou no mundo real: o próprio método H1VE recomenda proteger a branch padrão, e numa branch protegida o commit direto é rejeitado. O produto violava a recomendação do próprio método.

O ciclo pegou. A spec da correção (SPEC-151) definiu o comportamento certo antes de qualquer código: tentar o commit direto e, quando a política da branch bloquear, abrir uma pull request idempotente que o arquiteto mergeia. Sem spam de PR, sem exceção à regra. A review adversarial rodou com três lentes e um segundo agente verificando, levantou cinco achados, todos de baixa severidade, todos documentados. O arquiteto mergeou. A memória do projeto registrou a decisão.

É isso que o método faz. Ele não impede que erros existam. Ele impede que cheguem à produção sem serem vistos.

O que a memória capturou

O projeto lembra, para o time não precisar.

A memória do projeto começou como um arquivo de regras mantido à mão que passou de 240.000 caracteres, grande demais para o contexto de qualquer agente, caro demais para manter. Essa dor virou feature: hoje a H1VE destila as decisões de cada entrega em notas atômicas, ancoradas à parte do projeto a que pertencem, e o juiz de desvio confere cada mudança contra elas.

Decisão
Migrations de banco são append-only
Nunca edite uma migration existente, sempre crie uma nova. A regra nasceu de um incidente e nunca mais foi violada.
Gotcha
O juiz de desvio saturou a própria query
Ele montava a query com um limite de termos, e os termos da spec preenchiam o limite antes de os arquivos do diff entrarem. Descoberto numa review adversarial, corrigido priorizando os caminhos do diff.
Invariante
A memória nunca bloqueia o fluxo
Se a destilação falha, a entrega segue. Governança que trava o pipeline vira burocracia, e burocracia é abandonada.

O que aprendemos (e admitimos)

O método não elimina retrabalho. Ele torna o retrabalho visível e barato.

Algumas SPECs foram unidas num único PR quando uma dependia da outra. Alguns critérios de aceite só podem ser provados com um smoke test ao vivo em produção, e o registro diz isso explicitamente em vez de fingir certeza. Prometer 90 e entregar bate prometer 100 e falhar.

O mesmo ciclo desta página está disponível para o seu time.

Conheça o H1VE Flow