15 — Plano de release beta para 15/11/2026 às 08h BRT
AB-NASA-TEAM-IPE · rodada R6 · elaborado em 14/11/2026. Alvo interno: 15 de novembro de 2026, 08h00, America/Sao_Paulo (UTC−03), equivalente a 11h00 UTC. Esse horário organiza a entrega da equipe; não substitui o prazo, o formulário ou as regras do NASA Space Apps.
O objetivo desta rodada é disponibilizar uma beta pública de P&D com entrada clara, jogo funcional, apresentação, mapa de arquitetura e documentação selecionada. O núcleo educacional permanece 0.1.1-rd, catálogo ipe-64-v1. O plano não agenda trabalho futuro nem presume a disponibilidade de pessoas. As etapas abaixo dependem de execução e aceite explícitos, registrados pelos responsáveis.
Resultado esperado no corte
Uma pessoa que recebe a URL consegue identificar o estado BETA, abrir o jogo, acessar a apresentação e consultar a arquitetura/fontes. O site serve os próprios módulos, Worker e dados; o cálculo não depende de API de IA ou de fonte externa. A publicação deve preservar a distinção entre registros NASA históricos, hipóteses didáticas e evidências de teste.
O repositório do projeto é preparado para GitHub privado inicialmente, quando essa capacidade estiver disponível na conta autorizada. A publicação Vercel expõe somente a pasta estática curada. Ter autorização para publicar o projeto não transforma todo arquivo de pesquisa, log ou anexo em material apropriado para exposição pública. A efetiva criação do repositório e o deploy precisam de recibos próprios; este documento não afirma que já ocorreram.
O site e o repositório têm finalidades diferentes. O site é o produto acessível; o repositório preserva trabalho e rastreabilidade para pessoas autorizadas. Um link de código privado deve ser identificado como acesso restrito, sem apresentá-lo ao visitante como documentação pública disponível.
Condições que continuam abertas
O desenvolvimento específico começou antes da abertura local documentada. Elegibilidade temporal e qualificação de uma fonte na lista oficial de Resources continuam sem confirmação. Publicar uma beta, trocar o nome do repositório, declarar IA ou registrar a cronologia não resolve esses pontos. O release pode ser identificado como P&D; uma eventual candidatura exige decisão da organização e conferência do formulário vigente.
O HTML da apresentação tem sete quadros principais em português, notas PT/EN e oito apêndices separados. A copy inglesa dos sete quadros é um documento de preparação, não uma tradução automática da interface nem um deck exportado em inglês. O roteiro de aproximadamente 30 segundos precisa de ensaio; operar o demonstrador completo exige outro tempo.
Não houve qualificação visual de navegador neste ambiente. DOM simulado e HTTP verificam contratos diferentes de foco nativo, leitor de tela, impressão, Worker em navegador, abertura fria offline, persistência e desempenho real. Nenhum resultado de aprendizagem com participantes foi demonstrado.
Responsáveis por função
| Função responsável | Decisão ou entrega | Evidência que deixa |
|---|---|---|
| AB / coordenação de produto | Aceitar o recorte, priorizar bloqueadores e decidir o momento da publicação | Versão aceita, pendências explícitas e endereço/deployment efetivo |
| Coordenação técnica / release | Git privado quando disponível, configuração Vercel, publicação estática e recuperação da versão anterior | Commit e deployment reais, configuração aplicada e recibos HTTP da URL publicada |
| Frente de portal | Entrada, rotas, cópia curada dos artefatos e manifesto de publicação | Build identificado, lista permitida de arquivos e hashes do conteúdo público |
| Frente de arquitetura | Mapa derivado das fontes reais, distinção entre implementado e proposto | Modelo, relações, hashes/linhas de origem e artefatos locais do mapa |
| Frente de QA | Conferência independente de arquivos, links, módulos, dados, textos de estado e exposição acidental | evidence/beta-site-qa.json, com comando, resultado e limites |
| AB / pessoa que apresenta | Ensaio no equipamento, linguagem adequada ao público e mídia final identificada | Registro de navegador, origem, resolução, fluxo e eventuais falhas |
| Responsável pela candidatura | Regras, Resources, formato, idioma, equipe e eventual envio | Fonte/decisão da organização e recibo humano de envio, se houver |
Essas funções não inventam composição de equipe inscrita ou disponibilidade humana. As frentes de IA são assistência de pesquisa/engenharia; não são participantes adicionais da competição.
Sequência até o alvo interno
| Janela planejada, BRT | Prioridade | Saída para avançar | Se a etapa não fechar |
|---|---|---|---|
| 14/11, rodada atual | Montar portal e mapa; curar arquivos; preservar núcleo e apresentação identificados | site/ completo e manifesto sem entradas ausentes ou internas | Continuar em preview e publicar somente módulos realmente prontos |
| 14/11, até 16h | Fechar integridade, links, módulos/Worker/dados e revisão de publicação | QA local do site aprovado e diferenças justificadas frente à base | Corrigir a rota/arquivo; não reabrir ciência ou física para resolver um defeito de empacotamento |
| 14/11, 16h–18h | Publicar a beta autorizada e conferir a URL efetiva | Respostas HTTP e hashes coerentes; cabeçalhos de produção observados | Voltar ao deployment anterior válido ou suspender o módulo que falhou |
| 14/11, 18h–20h | Ensaio em navegador/equipamento real, se houver pessoa e equipamento disponíveis | Jornada observada, dados locais/recibos conferidos e limitações anotadas | Manter BETA e a qualificação pendente; erro fatal observado vira bloqueador |
| 14/11, 20h–22h | Corrigir somente defeitos de acesso, compreensão ou apresentação encontrados | Nova conferência das camadas afetadas e atualização dos recibos | Remover o incremento de risco; preservar a versão demonstrável |
| 15/11, 07h–07h30 | Conferência final da versão candidata | URL, conteúdo, estado BETA, fontes, manifesto, declaração de IA e responsável conferidos | Usar a última versão com evidência válida e listar o que ficou fora |
| 15/11, 07h30–08h | Aceite de release | Referência imutável ao commit/deployment aceito e pendências claras | Publicar o estado real; não converter meta não atendida em tarefa concluída |
Após o primeiro build público íntegro, congelar novas funções do motor. Entre 07h30 e 08h, aceitar somente correções de bloqueadores demonstráveis. A disponibilidade de uma janela não é evidência de que o trabalho ocorreu.
Critérios de aceite do release
| ID | Aceite verificável | Responsável | Evidência mínima | Bloqueio ou limite |
|---|---|---|---|---|
| REL-01 | A pasta publicada contém somente arquivos permitidos; não inclui credenciais, caminhos privados, endpoints internos, dados pessoais de sessão, fontes privadas, logs integrais ou source maps | Portal + QA | Manifesto de publicação e auditoria de conteúdo/caminhos | Vazamento confirmado bloqueia a publicação |
| REL-02 | Entrada, jogo, apresentação, mapa e documentação selecionada abrem por rotas locais válidas; ausência devolve erro real, sem HTML de sucesso no lugar de JS/JSON | Portal + release + QA | HTTP dos arquivos e comparação de MIME/hash | Link principal, módulo, Worker ou dado ausente bloqueia o módulo correspondente |
| REL-03 | BETA/P&D, origem histórica dos dados, hipóteses didáticas e pendências competitivas aparecem de forma consistente | Produto + QA | Inspeção do texto servido e links de referência | Alegação de aprovação, elegibilidade ou resultado humano sem prova deve ser corrigida |
| REL-04 | Runtime do jogo e apresentação preservam as versões declaradas; os dados científicos não são alterados por empacotamento | Release + QA | Hashes dos artefatos e fontes versionadas | Mudança do núcleo exige regressão afetada; mudança apenas de rota pede QA de distribuição |
| REL-05 | Módulos, Worker, CSS e dados usam recursos locais; o portal e o mapa não exigem CDN ou fonte remota | Portal + arquitetura + QA | Grafo de referências e HTTP local/produção | Dependência remota obrigatória não declarada bloqueia o aceite desse contrato |
| REL-06 | Os cabeçalhos configurados permitem a execução necessária e reduzem execução/conteúdo inesperados; produção corresponde à configuração aceita | Release | vercel.json e resposta HTTP da URL real | Teste local não prova aplicação da política pelo provedor; falta de conferência fica explícita |
| REL-07 | O mapa distingue fontes e dependências reais de oportunidades futuras; só revela caminhos relativos ao projeto | Arquitetura + QA | model.json, mapa e fonte de geração | Nó proposto não pode parecer integração executada; caminhos privados bloqueiam publicação |
| REL-08 | A jornada no equipamento não tem falha fatal conhecida; foco, legibilidade e persistência têm estado informado | Pessoa que apresenta | Registro de ensaio real, quando disponível | Ausência de ensaio conserva o rótulo BETA e o gate aberto; não autoriza afirmar compatibilidade/FPS |
| REL-09 | Existe uma referência recuperável à versão aceita e instrução de rollback | Release + AB | Commit/deployment reais e manifesto correspondente | Sem identificação, não chamar a entrega de release reproduzível |
| REL-10 | A candidatura, caso desejada, cumpre decisão de elegibilidade, Resources e formulário/idioma vigentes | Responsável pela candidatura | Autoridade, decisão e conferência do formulário | Gate de competição separado do release público de P&D |
O recibo do novo site deve apresentar sua própria contagem. Não somar reexecuções aos 51 testes Node, nove contagens TAP DOM e oito casos HTTP históricos do jogo, nem aos 25 checks da apresentação R5. Um hash confirma identidade em relação aos bytes esperados; não autentica autoria ou aprovação institucional.
Publicação de documentos e dados
O site pode servir o jogo compilado, a apresentação, o mapa e as fontes científicas arquivadas de acordo com seus termos. Avisos Apache-2.0 e MIT acompanham o material pertinente. Os documentos R4 preservados precisam do rótulo de corte histórico; seu conteúdo não relata trabalho de R6 ou estado de deploy atual.
Recibos públicos devem ser projeções explícitas dos recibos internos quando estes contêm contexto de execução privado. A projeção conserva versão, escopo, resultados e limites úteis, identifica sua origem e não inventa uma nova execução. O log completo e os anexos de ambiente continuam fora da pasta pública. Os três exemplos de replay são dados de demonstração; não devem ser substituídos por diários pessoais de participantes.
A auditoria diferencia informação técnica pública de vazamento: endereços de loopback em instruções locais não são endpoints privados de AB; modelos públicos de hardware citados em limitações não são hostnames; números com pontos só são IPv4 quando todos os octetos são válidos. Assinaturas de credencial precisam de delimitadores e contexto para não confundir palavras ou URLs públicas com segredos.
Ensaio e mídia
No equipamento escolhido, abrir a URL e percorrer previsão, execução, investigação, redesenho, exportação e importação. Conferir a apresentação nos dois modos e o mapa em teclado/zoom. Se for alegar operação local sem WAN, realizar abertura fria do pacote local nesse navegador; uma visita online anterior ou um resultado HTTP não estabelece esse comportamento.
Antes de usar capturas ou vídeo em candidatura, conferir a orientação aplicável sobre identificação de IA e a origem de cada visual. A apresentação identifica sua ilustração; a cena do jogo da base preservada tem legenda conceitual sobre escala/física, sem marca visível de IA. A declaração textual do pacote não certifica individualmente toda captura ou vídeo. Os dados NASA originais não devem receber rótulo de geração sintética.
Rollback e contenção
| Situação observada | Ação de contenção | Evidência para retomar |
|---|---|---|
| Asset, Worker ou JSON 404; MIME errado; erro de execução causado pela distribuição | Retornar ao deployment conhecido como válido ou retirar o link do módulo afetado; preservar os bytes do defeito para diagnóstico | HTTP e fluxo afetado conferidos na nova candidata |
| Documento ou recibo revela informação privada | Retirar o arquivo/rota da publicação e invalidar o deployment exposto; se houver credencial real, o responsável trata sua revogação | Nova allowlist, auditoria e URL sem o conteúdo retirado |
| Cabeçalho de produção impede scripts/Worker necessários | Recuperar a configuração/deployment válido; ajustar a política de forma mínima | Respostas da produção e execução no navegador-alvo, quando disponível |
| Nova edição altera resultado ou muda a semântica do modelo | Reverter o incremento do núcleo e retornar ao artefato identificado anterior | Regressão específica, nova versão e recibos coerentes antes de promover |
| Descoberta de regra ou decisão incompatível com candidatura | Atualizar a narrativa competitiva e conservar a procedência de P&D; não simular autorização | Decisão documentada da organização e conteúdo revisado |
Rollback preserva os recibos existentes; não reescreve a história de uma execução. Reverter o site não recupera ou migra automaticamente IndexedDB/localStorage do visitante. Mudanças de origem podem separar o armazenamento; orientar exportação dos recibos importantes antes de migrar uma instalação usada.
Registro de aceite
No fechamento, registrar: data/fuso, responsável, URL real, referência do commit/deployment, hash do manifesto, resultados de QA, estado do ensaio humano, limitações e versão de rollback. Até esses campos serem observados, o estado é candidata/planejamento, não aceite concluído.
Documento público. Ler o Markdown desta edição. Estado e curadoria no manifesto da publicação.