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.