• Situação: aceita
• Data: 2026-10-10
• Dono: Bruno dos Santos Vaz (BrunodosSantosVaz)
• Decisão: #221 (E1); implementação: #232 (E12), tarefa #247; release: #220 (v3.0.0).

O dono pediu três modos de operação e nomeou o terceiro:

pode mudar o nome pra autonomo

No modo autônomo, a IA conduz o trabalho de ponta a ponta sem aprovações repetidas. Isso conflita com a regra de ferro que proíbe publicar em produção sem a ordem do dono na conversa, e uma label nunca pode equivaler a autorização irrestrita.

• Continua valendo do ADR-0017:
  • testes escritos antes do código;
  • execução seletiva dos afetados após o código, com suíte completa em mudança estrutural e major/minor;
  • revisão independente por IA;
  • reuso da CI do mesmo SHA na candidata;
  • revisão humana quando pedida ou crítica.
• Muda na v3 (substitui o ADR-0017 nestes pontos):
  1. a IA trata reprovações comuns no Flash e chama o dono para as críticas;
  2. a suíte completa roda antes da candidata, e a promoção do mesmo artefato para produção reaproveita o recibo válido. Ela deixa de repetir a suíte completa em produção, como o ADR-0017 exigia. Integridade, configuração e saúde continuam sempre conferidas;
  3. o terceiro modo, autonomous, passa a existir.
• O "processo leve" do framework, citado no ADR-0017, é substituído pela esteira própria (ADR-0022).

1. project.mode aceita normal, flash e autonomous. O legado padrao equivale a normal.

2. normal: o dono decide nos portões, e a IA prepara e registra recibos.

3. flash: o ADR-0017 com as mudanças da seção anterior.

4. autonomous só funciona com um contrato versionado autonomy.toml em zona sensível, com revisão humana. O contrato define:

   • alvos;
   • custos;
   • limites de WIP;
   • classes de risco permitidas;
   • janela de publicação;
   • quem liga feature flags.

   O que fica fora do contrato é bloqueado; a IA nunca amplia a própria autorização. A regra de ferro de produção é alterada somente neste modo e somente dentro do contrato.

5. O bootstrap recusa o modo autônomo quando a conta ou o plano não permitem o controle exigido: ambiente protegido, identidade separada para iniciar e aprovar. Nunca há alternativa improvisada.

6. Em todos os modos:

   • rastreabilidade, revisão independente, scanners e documentação continuam obrigatórios;
   • o bot nunca se apresenta como humano;
   • toda aprovação aponta para identidade, SHA e evidência reais.

• O modo fica em configuração protegida; um PR não troca o modo que o julga.
• Uma conta-bot ou organização é opcional e documentada para quem quiser a separação de identidade cobrada pelo GitHub.

• O contrato é lido do autonomy.toml do checkout que roda o bb. Na CI, esse checkout é a branch de destino, então um PR não amplia o contrato que o julga.
• Contrato ausente, inválido ou vencido bloqueia todos os portões no modo autônomo.
• Risco ou portão fora do contrato também bloqueia o agente; só a decisão registrada do dono libera o portão.
• attempts e wip de um contrato válido substituem os limites padrão; o wip limita os épicos em andamento.
• O próprio contrato nunca é delegado: todo PR que muda autonomy.toml (e os demais arquivos do dono) recebe review:human em qualquer modo.
• A publicação no modo autônomo exige três condições:
  • o alvo listado em targets;
  • o portão publish delegado;
  • a hora dentro de publish_window (UTC).
• bb autonomy check e bb board create (no modo autônomo) recusam o repositório sem os controles exigidos:
  • ruleset que exige o check gate na main e na develop;
  • ambiente production que só aceita a main;
  • repositório privado numa conta pessoal Free também é recusado, porque lá rulesets e ambientes protegidos não são aplicados.
• Identidade: todo recibo de transição com portão grava approval com o portão, o risco, o modo e quem aprovou (agent:<nome> ou owner:<login>). Um agente nunca assina como o dono. A conta-bot continua opcional; sem ela, a separação de identidade fica nos recibos.