Big Bang v3.1.0

Os mesmos bytes de v3.1.0-rc.2. SHA-256: 080cbcd6a14237a0248c30774963aa409035ae94c34e9bee89f44b7a609e3185.

[3.1.0] - 2026-10-12

O que muda

Deploy multiplataforma (épico #174) e correções de operação:

• Alvo de deploy personalizado: o projeto pode publicar com scripts próprios. Os scripts rodam com ambiente mínimo e
  nunca recebem o token da publicação.
• Pacotes e arquivos estáticos: novos formatos de artefato com manifesto imutável por hash SHA-256; a promoção
  reutiliza o mesmo artefato e a validação recusa corrupção e caminhos fora do pacote.
• Adaptador AWS (S3 + CloudFront) em BETA: autenticação por OIDC (sem chaves fixas) e política de menor privilégio.
  Não foi testado em conta AWS real: use com atenção e envie o relato pelo template de issue gerado.
• Publicação e corte de release repetíveis: o botão de publicar aceita PR já mesclado e lê as notas depois do merge; o
  botão de corte configura a identidade do git antes de gravar a versão.
• Checagem de comunidade aceita o quadro único (paineis.quadro), além do formato de três painéis.

O que o projeto precisa fazer

Nada.

Big Bang v3.1.0-rc.2

[3.1.0] - 2026-10-12

O que muda

Deploy multiplataforma (épico #174) e correções de operação:

• Alvo de deploy personalizado: o projeto pode publicar com scripts próprios. Os scripts rodam com ambiente mínimo e
  nunca recebem o token da publicação.
• Pacotes e arquivos estáticos: novos formatos de artefato com manifesto imutável por hash SHA-256; a promoção
  reutiliza o mesmo artefato e a validação recusa corrupção e caminhos fora do pacote.
• Adaptador AWS (S3 + CloudFront) em BETA: autenticação por OIDC (sem chaves fixas) e política de menor privilégio.
  Não foi testado em conta AWS real: use com atenção e envie o relato pelo template de issue gerado.
• Publicação e corte de release repetíveis: o botão de publicar aceita PR já mesclado e lê as notas depois do merge; o
  botão de corte configura a identidade do git antes de gravar a versão.
• Checagem de comunidade aceita o quadro único (paineis.quadro), além do formato de três painéis.

O que o projeto precisa fazer

Nada.

Big Bang v3.1.0-rc.1

[3.1.0] - 2026-10-12

O que muda

Deploy multiplataforma (épico #174) e correções de operação:

• Alvo de deploy personalizado: o projeto pode publicar com scripts próprios. Os scripts rodam com ambiente mínimo e
  nunca recebem o token da publicação.
• Pacotes e arquivos estáticos: novos formatos de artefato com manifesto imutável por hash SHA-256; a promoção
  reutiliza o mesmo artefato e a validação recusa corrupção e caminhos fora do pacote.
• Adaptador AWS (S3 + CloudFront) em BETA: autenticação por OIDC (sem chaves fixas) e política de menor privilégio.
  Não foi testado em conta AWS real: use com atenção e envie o relato pelo template de issue gerado.
• Publicação e corte de release repetíveis: o botão de publicar aceita PR já mesclado e lê as notas depois do merge; o
  botão de corte configura a identidade do git antes de gravar a versão.
• Checagem de comunidade aceita o quadro único (paineis.quadro), além do formato de três painéis.

O que o projeto precisa fazer

Nada.

Big Bang v3.0.1

Os mesmos bytes de v3.0.1-rc.2. SHA-256: 352abf1e70bc2820d2172efb93821da5b8d0f863b01405b92cb325982a9c853d.

[3.0.1] - 2026-10-11

O que muda

Correções da v3.0.0, sem mudar o fluxo:

• A atualização do framework deixa de invalidar os hashes de .bigbang-docs.json em projetos públicos: o carimbo
  de versão dos arquivos gerados é normalizado, então bb atualizar não exige mais renovar a documentação só por
  causa da versão.
• bb migrate config remove a citação herdada do framework no AGENTS.md por inteiro, não só a primeira linha.
• bb migrate board confere as automações embutidas do Project antes de adicionar cartões, aplica o Status
  calculado, relê todos os valores e repara divergências antes de trocar a configuração; a coleta de evidências de
  PRs passou a ser feita uma vez por execução, e não por cartão.
• bb init remove o autonomy.toml herdado do framework, para que um sistema novo nunca receba a delegação do
  Big Bang.

O que o projeto precisa fazer

Nada.

Big Bang v3.0.1-rc.2

[3.0.1] - 2026-10-11

O que muda

Correções da v3.0.0, sem mudar o fluxo:

• A atualização do framework deixa de invalidar os hashes de .bigbang-docs.json em projetos públicos: o carimbo
  de versão dos arquivos gerados é normalizado, então bb atualizar não exige mais renovar a documentação só por
  causa da versão.
• bb migrate config remove a citação herdada do framework no AGENTS.md por inteiro, não só a primeira linha.
• bb migrate board confere as automações embutidas do Project antes de adicionar cartões, aplica o Status
  calculado, relê todos os valores e repara divergências antes de trocar a configuração; a coleta de evidências de
  PRs passou a ser feita uma vez por execução, e não por cartão.
• bb init remove o autonomy.toml herdado do framework, para que um sistema novo nunca receba a delegação do
  Big Bang.

O que o projeto precisa fazer

Nada.

Big Bang v3.0.1-rc.1

[3.0.1] - 2026-10-11

O que muda

Correções da v3.0.0, sem mudar o fluxo:

• A atualização do framework deixa de invalidar os hashes de .bigbang-docs.json em projetos públicos: o carimbo
  de versão dos arquivos gerados é normalizado, então bb atualizar não exige mais renovar a documentação só por
  causa da versão.
• bb migrate config remove a citação herdada do framework no AGENTS.md por inteiro, não só a primeira linha.
• bb migrate board confere as automações embutidas do Project antes de adicionar cartões, aplica o Status
  calculado, relê todos os valores e repara divergências antes de trocar a configuração; a coleta de evidências de
  PRs passou a ser feita uma vez por execução, e não por cartão.
• bb init remove o autonomy.toml herdado do framework, para que um sistema novo nunca receba a delegação do
  Big Bang.

O que o projeto precisa fazer

Nada.

Big Bang v3.0.0

Os mesmos bytes de v3.0.0-rc.2. SHA-256: b7f38506a5c6dce799d18d03cf401d61a57d5cf70697e64d1e66ec854f79e8fc.

[3.0.0]

O que muda

A v3 usa identificadores e CLI em inglês, com os nomes em português preservados como aliases. O quadro passa
para um Project único com 15 estados, incluindo Rejected e Cancelled; o estado é registrado por recibos e a
posse usa travas atômicas. O fluxo agrupador reúne tarefas de um épico: as tarefas fecham no merge na develop e
uma release é cortada dessa branch. Feature flags participam do fluxo e o check obrigatório é o gate.

Além dos modos normal e flash, o modo autonomous exige um contrato autonomy.toml, limites explícitos e os
controles do GitHub conferidos. Testes continuam escritos antes do código, a revisão é independente e os
scanners permanecem obrigatórios. bb init funda sistemas novos já na v3; --fluxo epic-branch preserva o
fluxo anterior quando escolhido. Sistemas existentes continuam com seu comportamento após bb update.

O que o projeto precisa fazer

Nada.

Adoção opcional da v3

1. Para continuar como está, atualize normalmente: bb update não muda o fluxo, os painéis nem as labels do
   projeto. Ler esta seção não autoriza migração ou mudança de controles no GitHub.
2. Para adotar a v3 por completo, use a skill bb-migrate: pré-checagem, simulação, snapshots protegidos e um
   PR revisado por parte, na ordem config → board → workflow → labels. Cada parte tem --dry-run,
   --snapshot <arquivo> e --rollback; escritas no GitHub exigem confirmação explícita --yes.
3. Faça os passos do dono no GitHub só depois da virada: check obrigatório gate, ambiente production
   com os mesmos revisores/proteções, segredo PROJECT_TOKEN e variáveis PROJECT_OWNER/PROJECT_NUMBER.
   A skill fornece os comandos exatos. Os painéis anteriores só são arquivados pelo dono após um ciclo sem
   divergência; nada do histórico é apagado.

Sistemas fundados antes do PR #236 herdaram do AGENTS.md a seção Modo do próprio framework.
bb migrate config remove esse trecho: ele pertence ao Big Bang, não ao sistema cliente.

Big Bang v3.0.0-rc.2

[3.0.0]

O que muda

A v3 usa identificadores e CLI em inglês, com os nomes em português preservados como aliases. O quadro passa
para um Project único com 15 estados, incluindo Rejected e Cancelled; o estado é registrado por recibos e a
posse usa travas atômicas. O fluxo agrupador reúne tarefas de um épico: as tarefas fecham no merge na develop e
uma release é cortada dessa branch. Feature flags participam do fluxo e o check obrigatório é o gate.

Além dos modos normal e flash, o modo autonomous exige um contrato autonomy.toml, limites explícitos e os
controles do GitHub conferidos. Testes continuam escritos antes do código, a revisão é independente e os
scanners permanecem obrigatórios. bb init funda sistemas novos já na v3; --fluxo epic-branch preserva o
fluxo anterior quando escolhido. Sistemas existentes continuam com seu comportamento após bb update.

O que o projeto precisa fazer

Nada.

Adoção opcional da v3

1. Para continuar como está, atualize normalmente: bb update não muda o fluxo, os painéis nem as labels do
   projeto. Ler esta seção não autoriza migração ou mudança de controles no GitHub.
2. Para adotar a v3 por completo, use a skill bb-migrate: pré-checagem, simulação, snapshots protegidos e um
   PR revisado por parte, na ordem config → board → workflow → labels. Cada parte tem --dry-run,
   --snapshot <arquivo> e --rollback; escritas no GitHub exigem confirmação explícita --yes.
3. Faça os passos do dono no GitHub só depois da virada: check obrigatório gate, ambiente production
   com os mesmos revisores/proteções, segredo PROJECT_TOKEN e variáveis PROJECT_OWNER/PROJECT_NUMBER.
   A skill fornece os comandos exatos. Os painéis anteriores só são arquivados pelo dono após um ciclo sem
   divergência; nada do histórico é apagado.

Sistemas fundados antes do PR #236 herdaram do AGENTS.md a seção Modo do próprio framework.
bb migrate config remove esse trecho: ele pertence ao Big Bang, não ao sistema cliente.

Big Bang v3.0.0-rc.1

[3.0.0]

O que muda

A v3 usa identificadores e CLI em inglês, com os nomes em português preservados como aliases. O quadro passa
para um Project único com 15 estados, incluindo Rejected e Cancelled; o estado é registrado por recibos e a
posse usa travas atômicas. O fluxo agrupador reúne tarefas de um épico: as tarefas fecham no merge na develop e
uma release é cortada dessa branch. Feature flags participam do fluxo e o check obrigatório é o gate.

Além dos modos normal e flash, o modo autonomous exige um contrato autonomy.toml, limites explícitos e os
controles do GitHub conferidos. Testes continuam escritos antes do código, a revisão é independente e os
scanners permanecem obrigatórios. bb init funda sistemas novos já na v3; --fluxo epic-branch preserva o
fluxo anterior quando escolhido. Sistemas existentes continuam com seu comportamento após bb update.

O que o projeto precisa fazer

Nada.

Adoção opcional da v3

1. Para continuar como está, atualize normalmente: bb update não muda o fluxo, os painéis nem as labels do
   projeto. Ler esta seção não autoriza migração ou mudança de controles no GitHub.
2. Para adotar a v3 por completo, use a skill bb-migrate: pré-checagem, simulação, snapshots protegidos e um
   PR revisado por parte, na ordem config → board → workflow → labels. Cada parte tem --dry-run,
   --snapshot <arquivo> e --rollback; escritas no GitHub exigem confirmação explícita --yes.
3. Faça os passos do dono no GitHub só depois da virada: check obrigatório gate, ambiente production
   com os mesmos revisores/proteções, segredo PROJECT_TOKEN e variáveis PROJECT_OWNER/PROJECT_NUMBER.
   A skill fornece os comandos exatos. Os painéis anteriores só são arquivados pelo dono após um ciclo sem
   divergência; nada do histórico é apagado.

Sistemas fundados antes do PR #236 herdaram do AGENTS.md a seção Modo do próprio framework.
bb migrate config remove esse trecho: ele pertence ao Big Bang, não ao sistema cliente.

Big Bang v2.0.1

[2.0.1] - 2026-10-09

O que muda

O validador da Wiki confere também o destino externo dos badges Markdown aninhados, além da imagem.
Página ou âncora ausente bloqueia entrega; badges válidos e validação da imagem são preservados.
Não adiciona dependências, não executa prosa e não altera os procedimentos privados.

O que o projeto precisa fazer

Nada.

Compatibilidade com a migração anterior

Projetos já migrados atualizam pelo pacote oficial e geram os arquivos conforme o procedimento habitual.
Se está migrando de antes da 2.0.0, o validador confiado da branch de destino pode ainda ler STACK.md e RNs
locais. Preserve somente esses contratos efetivamente consumidos, classifique a exceção transitória no manifesto,
atualize a branch confiada e então retire os contratos por outro PR com CI e revisão. Não desligue portões,
não altere aceites e não declare migração concluída enquanto a ponte existir. A Wiki é a fonte documental oficial.