Modos - BrunodosSantosVaz/big-bang GitHub Wiki
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.
Independentemente do modo escolhido, cinco regras de engenharia permanecem estritamente obrigatórias em todos os modos:
- Testes antes do código: todo código é precedido por testes que falham.
- Revisão independente: revisões hostis em contexto limpo (quem implementa nunca aprova o próprio PR).
- Scanners de segurança: Gitleaks, ShellCheck, validação estática e integridade do framework.
- Documentação viva: atualização de requisitos, arquitetura e inventário no mesmo ciclo de entrega.
- Rastreabilidade total: vínculo entre decisão, requisito, código, teste e recibo.
| 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. |
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.
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-
Leitura confiável: A CI sempre avalia o contrato a partir da branch de destino (
developoumain), 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.tomlcausa 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:- Ruleset ativo exigindo o check único obrigatório
gatenamaine nadevelop. - Proteção do ambiente
productionaceitando deploys exclusivamente originados da branchmain.
- Ruleset ativo exigindo o check único obrigatório
-
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.