Modos

Modos de trabalho e autonomia

O Big Bang v3 suporta três modos de operação em project.mode (definido no bigbang.toml): normal, flash e autonomous (ADR-0025).

A escolha do modo define o nível de autonomia operacional concedido aos agentes de IA e quais portões de aprovação dependem do dono humano.

1. Princípios universais inegociáveis

Independentemente do modo escolhido, cinco regras de engenharia permanecem estritamente obrigatórias em todos os modos:

1. Testes antes do código: todo código é precedido por testes que falham.
2. Revisão independente: revisões hostis em contexto limpo (quem implementa nunca aprova o próprio PR).
3. Scanners de segurança: Gitleaks, ShellCheck, validação estática e integridade do framework.
4. Documentação viva: atualização de requisitos, arquitetura e inventário no mesmo ciclo de entrega.
5. Rastreabilidade total: vínculo entre decisão, requisito, código, teste e recibo.

---

2. Comparativo de portões e aprovações

Modo	Dinâmica de aprovação	Escalação para o dono
normal	O dono do projeto aprova todos os portões via labels com bb decision.	Nenhuma decisão é delegada para agentes.
flash	O agente pode aprovar etapas de rotina de risco baixo e médio.	O dono retém sempre: seleção de sprint e cancelamento. Refinamento, protótipo, testes e PR escalam ao dono a partir do risco crítico; backlog, QA, publicação e flags escalam ao dono a partir do risco alto. Com qa:human, a homologação é sempre humana.
autonomous	O agente opera de forma autônoma estritamente dentro dos limites definidos no contrato autonomy.toml.	Qualquer ação fora dos limites contratuais bloqueia o fluxo e exige autorização do dono.

---

3. Modo Flash

O modo Flash otimiza a velocidade do ciclo de desenvolvimento sem abrir mão do rigor de qualidade:

• Seleção de testes afetados: tarefas de implementação executam os testes afetados pelo lote de alterações (bb test --base develop), concentrando a execução da suíte completa antes da candidata de release.
• Tratamento de reprovações: agentes corrigem reprovações comuns e só convocam o dono para falhas de alto impacto ou impasses bloqueantes.
• Promoção idempotente: o mesmo artefato auditado na candidata é promovido para produção sem recompilação, reutilizando recibos válidos de auditoria.

---

4. Modo Autonomous e o contrato autonomy.toml

O modo autônomo permite que agentes publiquem e mantenham sistemas com autonomia supervisionada por um contrato estrito, o arquivo autonomy.toml, localizado na raiz do projeto em zona sensível:

version = 1
targets = ["production"]          # Ambientes nos quais o agente pode publicar
risk = ["low", "medium"]          # Classes de risco delegadas
gates = [                         # Portões delegados ao agente
  "backlog", "refinement", "prototype", "tests",
  "pr", "qa", "publish"
]
flags = "owner"                   # Quem altera feature flags: "owner" ou "agent"
wip = 2                           # Limite de épicos simultâneos em andamento
attempts = 3                      # Limite de reprovações consecutivas antes de blocked
max_cost_usd = 20                 # Teto de custo de inferência
publish_window = "12:00-21:00"    # Janela de publicação permitida (UTC)
expires = "2027-03-31"            # Data de expiração da concessão

Regras de governança do contrato

• Leitura confiável: A CI sempre avalia o contrato a partir da branch de destino (develop ou main), garantindo que um PR de um agente não possa expandir sua própria autonomia.
• Contrato vencido ou ausente: Qualquer irregularidade, expiração ou ausência do autonomy.toml causa bloqueio imediato de todos os portões.
• Verificação de controles estruturais (bb autonomy check): O modo recusa funcionar se o repositório não possuir:
  1. Ruleset ativo exigindo o check único obrigatório gate na main e na develop.
  2. Proteção do ambiente production aceitando deploys exclusivamente originados da branch main.
• Identificação do agente: Recibos nunca utilizam a identidade do dono, registrando explicitamente agent:<nome> para garantir rastreabilidade nas auditorias de governança.

Para detalhes sobre os portões e regras de transição, veja Quadro único e Workflows e botões.