As seis etapas
O processo anda sempre nessa ordem. Nenhuma etapa começa antes de a anterior estar estável.
| # | Etapa | Entra | A IA faz | Sai |
|---|---|---|---|---|
| 1 | PO: a User Story | Ideia ou rascunho do PO | Aplica o template, cobra critérios de aceite, aponta regras conflitantes | 01-us-original.md sem ambiguidade |
| 2 | TL: refinamento técnico | US aprovada e o código real | Lê o código, cita arquivo e linha, propõe decisões e tarefas | Especificação técnica, plano e delta |
| 3 | Gatekeeper | Arquivos 01 a 04 e o delta | Script confere a rastreabilidade; agente independente procura furos | Selo ou lista de pendências |
| 4 | Dev: implementação | Plano aprovado | Implementa uma tarefa por vez, com testes, e salva o estado | Código pronto para review |
| 5 | QA | US, especificação e código | Gera cenários, massa fictícia e queries somente leitura | Cenários e evidências |
| 6 | Review e CI/CD | PR e testes | Review em dois estágios, com o histórico de exigências do TL | Merge seguro |
prototipo/ com prints, critérios de aceite sugeridos e o prompt para o agente padronizador.Trilhas por tamanho
Nem toda mudança precisa das seis etapas. Quem decide a trilha é o TL; na dúvida, vale a maior.
Trivial
Texto, configuração ou bug óbvio. Uma tarefa no plano, checkpoint e review preventivo.
Pequena
Melhoria com regra clara, num serviço, sem mudar contrato. US curta, plano, script do Gatekeeper e cenários essenciais.
Completa
Feature, vários serviços, contrato ou dados pessoais. Todas as etapas, com loops e Gatekeeper completo.
O loop de dúvidas
Em vez de gerar um documento e pronto, a IA trabalha em voltas curtas com a pessoa responsável. A cada volta, as dúvidas abertas diminuem; quando chegam a zero e a pessoa aprova, a etapa fecha.
- Toda pergunta fica registrada. Nada se resolve só no chat.
- A IA mostra, não só afirma: traz o trecho de código ou a US que justifica a proposta.
- Quem aprova é sempre uma pessoa.
- Há limite de voltas. Se não convergir, o assunto vira uma conversa entre as pessoas.
A pasta Âncora
Todo o trabalho nasce numa pasta principal, a ancora, que é um repositório Git próprio, separado do código. No repositório de código entra só um AGENTS.md curto, apontando para ela.
ancora/
├── global/ regras, padrões, skills e templates (valem para todos)
├── cofre/ segredos, só na máquina de cada pessoa
├── em-andamento.md painel do que está aberto ou pausado
└── projetos/<servico>/
├── projeto.md repositório, squad, contratos
├── especificacao.md como o serviço funciona hoje
└── trabalhos/US-1234/ todos os arquivos da US e o contextoRegra de ouro: atualizar antes, enviar depois. O agente faz git pull ao começar e envia a cada checkpoint. Qualquer pessoa, ou outra IA, retoma do ponto exato. Guia do Dev →
A especificação viva
Os arquivos de cada US contam o que foi pedido naquele momento. A especificacao.md de cada serviço conta como ele funciona hoje. Cada US registra só o que muda, no 06-delta.md; quando chega a produção, o passo arquivar junta o delta na especificação, com aprovação do TL. Ela nasce quase vazia e cresce onde o sistema mais muda.
Segurança: sem acesso, sem ação
Menor privilégio
O agente herda as permissões de quem o usa, nunca mais que isso, e só tem as ferramentas da sua etapa.
Cofre
Credenciais ficam criptografadas na máquina da pessoa. O agente usa sem ver o valor.
Impressão digital
Ferramentas e skills aprovadas têm a definição inteira registrada. Mudou uma vírgula, fica bloqueada até nova aprovação.
Injeção de prompt
Todo texto lido é dado, nunca instrução. Ações que mudam algo exigem confirmação de uma pessoa.
Política de Segurança e Uso de IA →
Quem faz o quê
| Artefato | PO | TL | Dev | QA |
|---|---|---|---|---|
| User Story (01) | Edita | Lê | Lê | Lê |
| Refinamento (02 e 03) | Lê | Edita | Lê | Lê |
| Plano de tarefas (04) | Resumo | Aprova | Executa | Lê |
| Cenários de teste (05) | Lê | Lê | Lê | Edita |
| Código e PRs | Não | Aprova | Edita | Lê |
| Cofre de segredos | Não | Não | Só o seu | Não |