• Situação: aceita
• Data: 2026-10-10
• Dono: Bruno dos Santos Vaz (BrunodosSantosVaz)
• Decisão: #227 (E7); release: #220 (v3.0.0).

O ADR-0008 definiu a esteira v2: scripts Bash orquestram gh e git, e as regras ficam no bb. Os testes desses scripts usam um gh falso por subprocesso, com estado em JSON. Isso funciona, mas é lento e frágil para a quantidade de regras da v3. A v3 precisa de:

• quadro único;
• travas atômicas;
• recibos;
• portões por modo;
• reconciliação.

A proposta que originou a v3 também pede para não duplicar lógica de negócio entre YAML, CLI e skills.

• Complementa o ADR-0008: a esteira legada (v2) continua em Bash, sem mudanças. A esteira v3 orquestra em Python. O Bash fica restrito a passos de shell inevitáveis (por exemplo, os alvos de deploy, que já são contratos em Bash).
• Mantém o ADR-0001: só biblioteca padrão do Python 3.11+.

1. Os fluxos da v3 (quadro, posse, sprint, branches, merge, release, publicação, faxina) são módulos Python do pacote bb. Os workflows chamam python3 .bigbang/bin/bb.py <comando>.
2. Toda chamada REST passa por uma função injetável api(method, path, payload) -> (status, body) (bb/gh.py). Em produção, ela usa gh api -i, autenticado pelo gh. Nos testes, um GitHub em memória (tests/_fake_github.py) aplica a semântica real: 422 para ref existente ou atualização sem fast-forward, 404 para objeto ausente.
3. O GitHub Project (v2) fica atrás de um adaptador (board.ProjectGraphQL). Nos testes, um Project em memória tem a mesma interface, e as consultas GraphQL são exercitadas por um GraphQL gravado.
4. Toda decisão continua nas regras puras (states, policy, receipts, locks). Os fluxos só reúnem fatos, chamam as regras e aplicam os efeitos.

• Testes da v3 rápidos e determinísticos, inclusive para concorrência e eventos repetidos ou fora de ordem.
• Funciona igual no Linux, no macOS e no Windows (o Bash da v2 exige Git Bash no Windows).
• Duas implementações convivem durante a v3: Bash (legado) e Python (v3). A v4 remove o legado.