Relatorio de testes 2 0 1 - BrunodosSantosVaz/big-bang GitHub Wiki

Relatório de testes e entrega — Big Bang 2.0.1

Verificação em 09/10/2026. Distribuição oficial v2.0.1; código documentado 9c73feb3e357a1216011eaf64bf4b5d944827087, tag/pacote em 4e18a53c168ec4daa00fcde4a9b9c09ac4fa863e. Alterações posteriores de identificação e deste relatório modificam somente documentação e manifesto, preservando o pacote byte a byte.

Suíte do framework

Verificação Resultado Evidência
Python 3.11 562 casos contabilizados: 561 aprovados e um reservado ao job Docker CI da fonte 2.0.1
Python 3.13 Mesmos 562 casos: 561 aprovados e o mesmo ciclo reservado CI da fonte acima
Alvo VPS/Docker 15 aprovados: 14 cenários de protocolo/SSH simulado e um ciclo Docker/SSH real em contêiner Job dedicado, BB_TESTE_DOCKER=1, na mesma CI
ShellCheck, Gitleaks e bb verificar Aprovados; nenhuma desativação de scanner, teste ou proteção Mesma CI
Integração e sincronização documental Todos os cinco jobs aprovados nos commits respectivos main 5c63ad8 e develop b128ad4
Distribuição Pacote, SHA-256 e atestação publicados Workflow oficial

O caso reservado nas matrizes Python foi executado no job dedicado. No ciclo em contêiner, a leitura da release pelo gh é simulada; o ensaio externo abaixo usa releases e SSH reais. Flash reutiliza CI adequada ao SHA, sem repetir suítes manuais completas por hábito. As regressões de links de badges foram escritas antes da correção, e a documentação bloqueia entregas incompletas também em Flash.

SHA-256 do pacote: 74a6d009c437d8dc3aee7a384be4d491be34302067e55a6969d9496e93a63b27.

Ensaio de campo E9 em servidor externo

A tarefa #99, do épico #91, foi exercitada com o script oficial e inalterado alvos/vps-docker/scripts/alvo.sh, num servidor ARM64 real do dono com Docker Compose 2.40.2. O host foi conferido pela chave SSH previamente conhecida, com StrictHostKeyChecking=yes.

Foram usados dois projetos Compose temporários, correspondentes aos ambientes lógicos staging e producao, com portas restritas a loopback e acesso por túnel SSH. Isso testa o adaptador no VPS externo; não significa que o jogo servido pelo Tsuru foi revertido ou que houve uma nova release do aplicativo. Não foi criada aplicação/repositório novo nem alterada a configuração dos sistemas existentes.

Passo, executado em ambos os ambientes Resultado
Migrar e publicar imagem anterior; conferir prontidão HTTP 200, imagem exata e banco funcional
Gravar placar de teste válido POST 201; BBE, 140 pontos, apenas no banco temporário
Migrar com a imagem nova antes da troca Contêiner anterior continuou atendendo; migração aprovada
Publicar a nova imagem por digest Contêiner mudou para o digest esperado; HTTP 200
Conferir persistência Mesmo volume SQLite e placar preservados
Executar voltar buscando imagem.txt pelo gh release download real Retorno ao digest da release anterior; HTTP 200
Conferir banco após retorno Placar e registros de migração preservados; rollback não desfaz migrações
Isolamento e limpeza Volumes distintos nos dois ambientes; contêineres existentes com mesmos IDs antes/depois; contêineres, redes, volumes e diretório temporários removidos

Imagens usadas, publicadas no repositório Snake 3310:

  • Release anterior v0.1.0-rc.1: ghcr.io/brunodossantosvaz/snake-3310@sha256:39b2dd1fdd667f1f1e3972d722879fc5ca9b1c4bc56ea8e2d8a351ff1210d206.
  • Release atual v0.1.0: ghcr.io/brunodossantosvaz/snake-3310@sha256:12fb06c1c51f72772358d7cf6dfd2a7b4468af13c5f4917946d290477b2acac1.

A anterior é uma release candidata pública, e a atual é a release estável. Nenhuma tag foi criada, movida ou removida pelo ensaio. A configuração e os dados de teste não continham segredos; chaves foram passadas ao processo local sem publicação. Uma fixture inicial com 120 pontos recebeu 400 por violar a regra de múltiplos de sete; corrigiu-se o dado do ensaio para 140, preservando a validação do aplicativo.

Os logs e recibos da execução ficam no ambiente autorizado de manutenção; não são publicados com endereços administrativos ou credenciais. A evidência documental é revisada independentemente antes da integração. O relatório de 07/10 permanece como registro histórico; sua pendência do ensaio externo foi resolvida por esta execução.

Migração e cobertura documental

Projeto Framework instalado Funcionalidades reais rastreadas Fontes inventariadas Evidência de entrega
Big Bang 2.0.1 48/48 212 PR 211, 214, 216
Snake 3310 2.0.1 12/12 87 PR 80, 84, produção sem release
ScreenFakeCam 2.0.1 10/10 68 PR 95, 97, produção sem release

As matrizes de cada Wiki relacionam funcionalidade → requisito/regra → página → teste/cenário real → commit/hashes das fontes. Cobertura de 100% refere-se a esse inventário revisado, não à quantidade de páginas. Os onze assuntos documentais, fluxos, erros, permissões e limitações foram conferidos, e todos os inputs documentais transitórios foram retirados após publicação. Arquivos funcionais e comunitários permanecem. Privados conservam documentação local.

A cobrinha mantém a imagem 0.1.0 em produção e homologação. O ScreenFakeCam mantém o APK 0.3.2, SHA-256 29d89a99d2839185138259dafc688ee85fbcb087a6a788a8ebc8612dd3a43fca. Os scanners e CIs dos commits entregues passaram; ambos os projetos estavam sem alertas CodeQL abertos nesta conferência.

Comunidade e limites da entrega

Os nove painéis têm leitura anônima e edição restrita a pessoas/automações autorizadas. Os três posts originais de Discussions foram atualizados à versão do framework 2.0.1 sem duplicação; READMEs e Wikis apresentam seus links.

As imagens de Social preview em 1280×640 estão publicadas nas três Wikis, nas respectivas páginas Design. O upload da imagem personalizada no GitHub permanece pendente, pois a API consultada não fornece esse upload e não há sessão de interface autenticada disponível; não se declara que foi realizado.

AWS, entrega de pacotes e adaptadores personalizados continuam no roadmap próprio; este ensaio fecha o critério de campo VPS/Docker e não registra esses destinos futuros como implementados. A manutenção Tsuru verificada preserva hom/produção e os controles já publicados, incluindo os limites documentados de recuperação contra perda total do host.