O método · papéis
Cinco papéis. Um time.
Cada papel é uma responsabilidade humana — a IA assiste todos, detém nenhum. Veja o que cada um faz, no dia a dia, e como operá-lo na plataforma de referência.
O founder define a direção e é a raiz de confiança. Decide o que é construído e em que ordem, funda o projeto e mantém o sistema saudável. O primeiro usuário, com visibilidade total.
Uma vez — fundar o projeto
- 1
Desenhar o projeto no canvas
Qualquer interfacePreencha o H1VE Canvas com o arquiteto e depois expanda nos quatro documentos de fundação.
- 2
Montar o time
PainelConvide os membros e atribua um papel a cada um.
- 3
Conectar a fonte
PainelVincule o repositório do GitHub e o webhook para o quadro refletir a realidade.
Todo dia — 5 minutos
- 1
Conferir a caixa de entrada e as notificações
PainelO painel mostra o que espera por você e o que está travado.
- 2
Aprovar specs pendentes
PainelNenhuma feature entra em desenvolvimento sem a sua aprovação (ou a do arquiteto).
- 3
Acompanhar blockers e a fila do arquiteto
PainelIdentifique gargalos antes que cresçam.
Toda semana
- 1
Registrar métricas de saúde técnica
PainelInforme os sinais de saúde da semana — taxa de aprovação de CI, tempo de ciclo.
- 2
Decidir as próximas features
PainelPriorize a partir do roadmap e defina o apetite de cada feature.
Pode
Criar e priorizar features · aprovar specs · atribuir papéis · ver tudo.
Não pode
Pular os gates. A autoridade do founder é direção, não um atalho.
O arquiteto traduz a visão em realidade técnica. Lidera a spec técnica, aprova specs pelo ângulo técnico, revisa pull requests e detém a autoridade exclusiva de fazer merge na main — o gate humano final.
Uma vez — fundar o lado técnico
- 1
Liderar a spec técnica (SDD)
Qualquer interfaceDefina stack, modelo de dados, APIs e as decisões-chave, com a IA como parceira de redação.
- 2
Adaptar o arquivo de memória do projeto
Qualquer interfaceFixe as regras inegociáveis, os arquivos críticos e o estado atual no CLAUDE.md.
Quando uma spec chega
- 1
Revisar com foco técnico
PainelConfira schema, ownership e critérios de aceite.
- 2
Aprovar a spec
PainelSó então o dev começa a codar.
Quando um PR chega
- 1
Verificar as pré-condições
PainelCI verde, QA e Data com sign-off, o DONE presente.
- 2
Revisar os arquivos críticos
PainelFoque onde a AI declaration sinaliza código gerado.
- 3
Fazer o merge
PainelO squash merge na main — sua autoridade exclusiva. Resolva conflitos manualmente, nunca via IA.
Pode
Aprovar specs · revisar e fazer merge de PRs · resolver conflitos · definir a arquitetura.
Não pode
Fazer merge de trabalho sem CI, sem sign-off de QA ou de Data. A autoridade de merge é responsabilidade, não atalho.
O dev escreve o código, em par com um agente de IA, trabalhando apenas dentro de uma spec aprovada e só nos arquivos atribuídos. Declara o que a IA gerou e o quanto foi revisado.
Antes de codar
- 1
Confirmar a spec aprovada
Qualquer interfaceLeia o contexto do projeto e a spec da sua feature.
- 2
Gerar um token pessoal
PainelCrie seu token para usar a CLI e a integração de IA sob a sua própria identidade.
- 3
Iniciar a feature
CLI
nf startmostra as features atribuídas a você e cria a branch automaticamente — sem nomear na mão.
Durante o trabalho
- 1
Construir com a IA, dentro da spec
MCPO agente gera; você permanece no escopo de arquivos da spec.
- 2
Ver o status sem sair do terminal
CLI
nf statusmostra a feature atual, o estágio e os blockers. - 3
Registrar um blocker se travar
CLI
nf blocker "..."— ou peça à sua IA para registrá-lo via MCP.
Ao terminar
- 1
Submeter a AI declaration
CLI
nf doneregistra o que a IA gerou e move a feature para PR. O agente pode fazer isso via MCP. - 2
Abrir o pull request
Qualquer interfaceAbrir o PR move a feature automaticamente; a CI roda.
Pode
Implementar uma spec aprovada · abrir PRs · registrar blockers · submeter a AI declaration.
Não pode
Escrever código sem spec aprovada · tocar em arquivos fora do escopo · fazer merge na main.
QA verifica a funcionalidade contra os critérios de aceite da spec. Um gate independente — QA não escreveu o código. O foco é o comportamento, não o estilo do código ou o schema.
Quando uma feature chega
- 1
Ver na caixa de entrada
PainelO painel avisa: uma feature aguarda o seu sign-off.
- 2
Ler a spec e o DONE
PainelA spec dá os critérios de aceite; o DONE diz como testar.
- 3
Rodar os testes funcionais
Qualquer interfaceVerifique o comportamento que a spec prometeu.
A decisão
- 1
Conferir cada critério
PainelAtende à spec, ou não?
- 2
Dar sign-off — ou rejeitar com motivo
PainelFeedback específico e reproduzível se falhar.
- 3
O gate duplo se completa
PainelQuando o Data também dá sign-off, a feature avança automaticamente.
Pode
Dar sign-off ou rejeitar por critérios funcionais, com feedback específico.
Não pode
Ser quem escreveu o código · substituir o gate do Data.
Data verifica schema, migrations, constraints e tipos. Pega o jeito específico com que a IA falha com dados — inventar campos, renomear colunas sem migration, quebrar constraints em silêncio — erros que passam num teste funcional mas corrompem o banco.
Quando uma feature chega
- 1
Ver na caixa de entrada
PainelO painel avisa: uma feature aguarda o seu sign-off.
- 2
Ler as mudanças de dados da spec
PainelFoque nas seções de schema e migration.
- 3
Inspecionar a migration linha a linha
Qualquer interfaceConfira contra o schema existente.
A decisão
- 1
Verificar a integridade
PainelCompatibilidade retroativa, constraints, tipos, índices.
- 2
Dar sign-off — ou rejeitar com a linha
PainelAponte a linha exata do problema se falhar.
- 3
O gate duplo se completa
PainelQuando o QA também dá sign-off, a feature avança automaticamente.
Pode
Dar sign-off ou rejeitar por integridade de dados, com a linha exata.
Não pode
Substituir o gate do QA. Dois riscos, dois gates independentes.