Um framework para uma pessoa, com uma ou mais IAs, planejar, construir e manter sistemas profissionais: bem arquitetados, seguros, testados e 100% documentados.

• Estado atual
• O que é o Big Bang
• Para quem é (e para quem não é)
• O que você precisa
• Como começar
• Modo padrão ou Flash
• Actions conforme o alvo de deploy
• O que vai acontecer
• Depois da Fundação
• Como a esteira funciona
• Exemplo real: ScreenFakeCam
• Segurança
• Versões e atualização
• Documentação do framework
• Contribuindo
• Licença

A comunidade está em Discussions, com o primeiro anúncio da IA. A Wiki é a fonte oficial pública. A proposta inicial da #208 foi revisada e publicada antes da remoção dos originais. O PR e a release oficial registram separadamente a entrega do código. Confira rastreabilidade.

Estável desde a 1.0.0, validada num sistema real feito do zero até produção só pelo Big Bang: o ScreenFakeCam, um app Android com releases assinadas e homologação registrada em emulador Android 15 (relatório atual). A versão atual está nas Releases.

Esta documentação acompanha o código 2.0.1 (a distribuição oficial é comprovada pelas Releases): inclui modo Flash, catálogo extensível, Actions conforme o alvo e adaptador para o Tsuru existente, além de VPS/Docker e entrega compilada. Na 2.0.1, públicos documentam exclusivamente na Wiki, com inventário, matriz, propostas revisáveis e publicação protegida; privados mantêm arquivos locais. Consulte o processo documental. Tsuru entrega um serviço OCI por aplicação, com TSURU_MIGRACAO=job por padrão ou inicializacao para SQLite em volume persistente. O runbook separa os testes do adaptador da comprovação de uma entrega real no consumidor. AWS, alvo personalizado e formatos de deploy por pacotes ou arquivos continuam reservados no épico #174.

A versão 1.5.1 corrige o registro de revisão em PRs com mais de 300 arquivos: a CLI consulta todos os caminhos pela API paginada, mantém a proteção de renomes e recusa patch de aceite indisponível.

A versão 1.5.2 verifica vulnerabilidades e gera SBOM para cada serviço e plataforma de deploy.plataformas, inclusive ARM64 em runner AMD64. Os SBOMs sbom-<servico>.linux-<arquitetura>.json acompanham a candidata e a produção; sbom-<servico>.json conserva a primeira plataforma configurada. Os digests do índice de imagens e os portões de segurança permanecem iguais. Veja a migração.

A versão 1.5.3 fornece ao workflow Mesclar PR as variáveis públicas dos painéis (PROJETO_OWNER, PROJETO_PLANEJAMENTO e PROJETO_EXECUCAO). Depois de mesclar um PR aprovado, a esteira pode criar a próxima branch e, no último PR do épico, disparar a integração. Revisão, checks do SHA exato e portões continuam exigidos.

A versão 1.5.5 automatiza a faxina após publicação e sincronização do próprio framework, com CI verde nos SHAs exatos e release estável disponível. Nos sistemas, o botão Faxina recupera a limpeza após publicação ou encerramento e diariamente. Encerrar falha se houver sobras: branches com commits exclusivos, PRs abertos e tags continuam protegidos. Atualizar o framework e as Actions pode usar Publicar sem release quando os caminhos do artefato permanecem iguais; a versão e os binários/imagens dos aplicativos não mudam.

O relatório da entrega Flash/Tsuru registra a distribuição, os testes completos no SHA exato e as evidências dos consumidores. A produção do framework é o pacote atestado nas Releases; os consumidores têm seus próprios portões de homologação e produção.

O Big Bang é um repositório-modelo do GitHub que vira o próprio repositório do seu sistema. Você cria um repositório a partir dele, abre qualquer IA para código na pasta e diz "iniciar projeto". A partir daí, os arquivos do framework conduzem a IA por todo o ciclo de vida do sistema, com você decidindo nos pontos de controle. Ele não gera o sistema de uma vez: ele governa a construção, etapa por etapa, e cobra as regras por ferramenta (CI, testes travados, portões), não por promessa.

Escolha na criação com bb init --nome "Meu sistema" --modo flash, ou depois, definindo modo = "flash" em [projeto] do bigbang.toml e rodando bb gerar, com a decisão registrada em ADR. Sem essa escolha, o projeto continua no modo padrão. O modo pertence ao mesmo Big Bang.

Nos dois modos, testes são escritos antes do código. O Flash reutiliza autorizações já dadas, usa revisão independente por IA e concentra a execução após concluir as alterações: bb testes --base origin/develop roda o seletor de testes afetados da stack. Mudança estrutural, primeira entrega, release major/minor e produção exigem suíte completa. Sem seletor ou base confiável, também roda tudo. A candidata reutiliza a CI verde do mesmo commit. Lint, tipos, scanners, testes congelados, documentação e aprovação humana de produção permanecem obrigatórios.

Veja a tabela de diferenças e configuração do Flash.

flowchart LR
  F[Fundação<br/>produto, stack, design,<br/>GitHub, esteira] --> B[Backlog<br/>épicos refinados]
  B --> S[Sprint<br/>testes, tarefas,<br/>documentação]
  S --> E[Entrega<br/>candidata, homologação,<br/>produção]
  E --> M[Manutenção<br/>bugs, segurança,<br/>atualização]
  M --> B

É para quem constrói sistemas sozinho com IAs e quer o resultado de uma equipe disciplinada: decisões registradas, testes que a IA não pode enfraquecer, segurança verificada, documentação e README sempre em dia, e um painel que mostra o que espera por você.

Não é para quem quer só um gerador de código, nem para equipes grandes com processo próprio: o Big Bang assume um dono que decide e IAs que executam, com o GitHub como fonte da verdade.

• Git
• GitHub CLI (gh) autenticado (gh auth login)
• Python 3.11 ou superior, disponível também como comando python (no Ubuntu/Debian: sudo apt install python-is-python3)
• Uma IA para código, como Claude Code, Codex ou Cursor
• Uma conta no GitHub

Em repositórios públicos, habilite Wiki e crie Home antes de F0 ou de migrar documentação. Os nomes PRODUTO.md, STACK.md e DESIGN.md abaixo são identificadores lógicos, consultados com bb documentacao ler <nome>; os conteúdos ficam na Wiki. Arquivos privados permanecem locais. Ao atualizar um projeto existente, siga migração e publicação, preservando originais até confirmação.

1. No GitHub, clique em Use this template → Create a new repository. O repositório novo nasce limpo, sem o histórico do framework, e pode ser privado.
2. Clone o repositório novo: gh repo clone <seu-usuario>/<seu-sistema>.
3. Abra sua IA na pasta do repositório.
4. Diga: "iniciar projeto".

A Fundação tem seis etapas. Cada uma vira uma issue e um PR, para ficar no histórico.

O dia a dia é conversa. Você diz a intenção com as suas palavras; a IA reconhece o pedido, faz e termina dizendo o próximo passo e o que depende de você.

Tudo também pode ser feito pelos botões das GitHub Actions (Run workflow), sempre com simular=true por padrão.

• Três camadas: o framework (.bigbang/, conferido por hash), a camada gerada (.github/, skills, hooks) e o seu projeto, que uma atualização do framework nunca toca.
• Branches: main só recebe releases; a develop espelha o que está em produção; cada épico e cada tarefa têm a sua branch, sempre por PR.
• Testes de aceite primeiro e travados: escritos antes do código, com o ID da regra de negócio; a IA que programa não pode mudá-los, só retirar a marca de pendente da própria tarefa.
• Dois perfis de entrega: compilado (binários, APK; a produção publica os mesmos bytes homologados) e deploy (imagem por digest, staging, migração antes da troca, Voltar versão).
• Catálogo de deploy: bb alvos lista destinos e formatos implementados e reservados, sem acessar servidor. O gerador valida os contratos antes de escrever arquivos. vps-docker e tsuru estão implementados com imagem OCI; Tsuru aceita um serviço por app, com job manual preparado ou migração na inicialização. Veja o runbook. Personalizado e outros formatos continuam no backlog do épico #174. Veja o contrato de extensão.
• Várias IAs ao mesmo tempo: cada uma assume a tarefa (bb assumir) e trabalha na própria pasta.
• Repositório completo: todo sistema nasce com README, licença, código de conduta, guia de contribuição, política de segurança e um ícone global aprovado no protótipo (DOC-15 a DOC-17, cobrados pela CI).
• Nada fica para trás: a faxina apaga as branches mescladas e lista issues, PRs e posses soltas; a CI reprova um README desatualizado depois da primeira release.

O ScreenFakeCam foi feito do zero só pelo Big Bang: Fundação com entrevista, pesquisa de stack (Kotlin + Jetpack Compose), design kit e protótipo; três sprints; uma reprovação na homologação corrigida pela tarefa de correção; APKs em produção com assinatura, hash e atestação de origem. O relatório histórico descreve as três versões do piloto; o relatório atual registra a auditoria e as entregas posteriores. Referências históricas a aparelho físico não substituem os ensaios desta entrega em emulador.

• Cinco regras de ferro valem em todo sistema e não podem ser desligadas pelo bigbang.toml (AGENTS.md).
• Varredura em todo PR: segredos (Gitleaks), análise estática, dependências (OSV) e CodeQL; o check regras julga cada PR com as regras da branch de destino, que o próprio PR não consegue mudar.
• Produção só com a sua aprovação no ambiente producao; tokens e segredos são sempre criados por você.
• Texto de terceiros (issues, PRs, páginas) é tratado como dado, nunca como instrução para a IA.

Encontrou uma falha de segurança no framework? Siga a política de segurança: relato privado, nunca numa issue pública.

O Big Bang segue SemVer. Cada versão é uma Release com o pacote bigbang-vX.Y.Z.tar.gz, o SHA-256 e a atestação de origem. Num sistema, diga "atualizar o Big Bang" (bb atualizar): a IA baixa e confere o pacote, mostra o MIGRACAO.md e abre um PR que troca só o framework.

A série 1.5 mantém VPS/Docker, runner público e modo padrão para configurações existentes. Adoção de Flash ou Tsuru fica numa decisão própria por ADR e bb gerar, após a atualização oficial. Consulte o changelog e os passos opcionais da migração antes de mudar a entrega do sistema.

• Especificação completa: .bigbang/docs/especificacao.md
• Processo, passo a passo: .bigbang/processo/
• Padrões obrigatórios: .bigbang/padroes/
• Decisões do framework (ADRs): .bigbang/docs/decisoes/
• O que muda em cada versão e como atualizar: .bigbang/MIGRACAO.md
• Piloto que validou a 1.0.0: .bigbang/docs/piloto-screenfakecam.md

Pedidos, ideias e problemas do framework entram pelas issues. Num sistema feito com o Big Bang, a skill bb-retrospectiva abre a issue com a evidência quando encontra um problema do framework. Toda mudança chega por PR, com os testes do framework (python -m unittest discover -s .bigbang/tests) e o bb verificar verdes; o passo a passo está em CONTRIBUTING.md. Ao participar, você concorda com o código de conduta.

O framework Big Bang (tudo que está em .bigbang/ e os arquivos gerados a partir dele) é distribuído sob a licença MIT.

O sistema que você criar a partir do Big Bang é seu: o código pertence a você, que escolhe a licença dele, inclusive fechada. A única obrigação é manter o aviso de copyright do framework, que na Fundação vai para .bigbang/LICENSE.

bb gerar injeta somente os nomes de variáveis e segredos do contrato escolhido em staging, produção e rollback. O contrato de artefato define os scripts da construção e da candidata. A construção permanece no runner público; [deploy] runner = ["self-hosted", "rede-deploy"] seleciona o runner das publicações (inclusive rede privada). preparar_rede = "bash deploy/rede.sh" executa a preparação aprovada antes do alvo, somente no deploy real. Valores de segredo ficam nos ambientes do GitHub; nunca no TOML. Produção e rollback mantêm aprovação humana.

O alvo Tsuru aceita TSURU_MIGRACAO=inicializacao: a aplicação migra o arquivo de seu volume persistente antes de começar a atender. O modo de job manual continua como padrão para bancos externos. Configure uma réplica, readiness que consulta o banco e backup; veja o runbook. A pré-checagem registra migration=pending; a imagem migra antes de abrir a porta, e só saúde/readiness e testes posteriores comprovam a entrega. O rollout pode sobrepor temporariamente duas unidades no mesmo volume, exigindo migrações transacionais e compatíveis. A instalação da plataforma Node.js é uma preparação separada do servidor: o alvo desta versão importa imagem OCI por digest, com seu inicializador, sem upload de fontes.