Um projeto aberto.
Todas as decisões.

PROJETO-IPÊ — verificação do beta 0.5

Data: 14/11/2026, referência de apresentação America/Sao_Paulo. Este registro separa teste automático, validação de contratos, observação visual e publicação.

Domínio e integridade

npm test passou com 120 testes, zero falhas, zero ignorados em Node 24.22.1. O relatório está em evidence/domain-test.tap. Os 19 testes novos de campanha complementam os 101 testes anteriores sem alterar o motor 0.1.1-rd, o catálogo ipe-64-v1 ou os arquivos científicos.

A cobertura inclui conservação de bits e energia, limites de massa/orçamento/potência, qualidade científica, identidade byte a byte das fontes, recálculo de replay, persistência, modelos físicos independentes e requisitos dos quatro capítulos. A busca contextual avalia 64 configurações por capítulo, com 17 / 6 / 1 / 2 soluções elegíveis e nenhum caso indeterminado.

Jornada React

npm run test:ui passou com 14 testes, zero falhas. Recibos: ui-dom-test.tap e ui-dom-test.json.

O fluxo integrado confirma:

1. Previsão e justificativa antes da execução.
2. Nível 1 concluído por tentativa própria; níveis posteriores bloqueados antes disso.
3. Nível 2 com perda de lotes na configuração inicial, ajuda que preserva 512 Mbit e redesign 6/6.
4. Nível 3 com contato curto, busca que preserva BANDAS e solução 6/6.
5. Nível 4 com missão operacional 6/6 a 84 créditos sem concluir o capítulo; conclusão após redesign elegível até 78.
6. Restauração da campanha concluída; replay importado não concede progresso.
7. Resultados existentes preservados diante de importação inválida e falha de armazenamento.

O ambiente é jsdom com fake-indexeddb. Esses testes usam o motor real, mas não medem GPU, renderização, foco modal nativo, leitor de tela, Worker real ou durabilidade do armazenamento do navegador.

Contratos técnicos

O schema com 12 modelos passou por prisma format e prisma validate, usando Prisma 7.10.1. SHA-256 do schema:

94febcdc03d58830da102d1af5a3f270e2b5120b9c64338b815094509302c521

Os seis diagramas passaram por mermaid.parse em Mermaid 11.14.0. Os seis blocos de FLOWCHARTS.md foram comparados com os .mmd e são idênticos. A validação não conecta banco nem aplica migração. A arquitetura cloud permanece proposta.

Build e documentação pública

npm run build executa o gerador de pesquisa, o recibo público de versão, TypeScript estrito e Vite. O documento /release.json identifica versão, ambiente e, quando fornecido pela Vercel, o commit do build. Builds locais não afirmam um SHA de publicação.

O bundle de cena 3D permanece separado e gera aviso de tamanho superior a 500 kB. O motor também é usado por replay e progressão, portanto os avisos de importação dinâmica sem separação efetiva são conhecidos. Isso não foi convertido em alegação de desempenho; medição em dispositivos continua pendente.

Observação visual

A inspeção local desta rodada foi interrompida pela política de URL do navegador de QA após a prévia deixar de estar acessível. O erro bloqueou o acesso ao frame; não houve tentativa de contornar a restrição. As capturas históricas R9–R10 permanecem identificadas como anteriores, em evidence/ui/.

A revisão de contraste dos novos painéis usou os valores CSS efetivos navy/lime: texto secundário sobre navy 7,52:1 e sobre o fundo de sucesso 6,47:1. Esse cálculo cobre essas combinações, sem estabelecer conformidade WCAG para toda a aplicação.

Publicação e inspeção pública

A campanha foi publicada em /campanha/index.html, preservando o R14 em /lab/index.html. A implantação dpl_DHsVtWQurf2w9do6bhcnXdD84aJT ficou READY no commit f30ca994098262b75a86b25784b78657c34c0db5; o recibo público de versão confirmou esse SHA.

Na URL pública, o primeiro nível executou com 6/6 registros válidos e liberou o nível 2. O mapa carregou estilos e scripts, navegou até o capítulo de níveis e selecionou o nível 4. A documentação exibiu 21 documentos e 160 referências. O PowerPoint baixado pelo mapa é idêntico ao arquivo local validado, SHA-256 01580db767d9bc8d4002cc75d179ea71886930c8211e3a1fa6978e9d3954af11.

O ambiente apresentou a alternativa 2D. Esta inspeção pública não comprova 3D, todos os dispositivos ou a jornada completa fora do teste DOM. O problema observado de normalização de barra nas URLs de diretório foi corrigido com redirecionamentos explícitos para index.html. A checagem estática das rotas verificou 430 referências, sem erros. Recibo completo e capturas.

Limites de evidência

Não houve estudo com participantes, teste de transferência de aprendizagem, validação de voo, auditoria WCAG completa, medição de 60 FPS ou teste de recarga offline a frio. A conclusão de um capítulo é uma evidência de atendimento das regras do modelo, não uma medida automática de compreensão do jogador.

PROJETO-IPÊ — PRD do beta

Versão editorial 1.0 · 14/11/2026 · referência de data: America/Sao_Paulo. Direção de produto: AB / Alexandre Belo. Pesquisa, organização e redação com assistência de IA. Documento de produto; a evidência de implementação, testes e publicação deve acompanhar o handoff da versão.

1. Produto e problema

PROJETO-IPÊ — Ciência que chega é um jogo educativo de projeto de missão espacial. A pessoa configura um CubeSat fictício para entregar seis registros científicos históricos do Cerrado. Precisa relacionar processamento, memória, energia, potência e comunicação para cumprir o objetivo dentro do envelope do projeto.

A dificuldade de aprendizagem que o beta pretende investigar é a distância entre escolher um componente e entender sua consequência no sistema. Capacidade de bateria não é potência de descarga; produzir um lote não significa entregá-lo; um índice calculado não permite qualquer conclusão ambiental. Uma montagem visualmente convincente também não demonstra que a missão funciona. Essas dificuldades são hipóteses de produto, ainda sem estudo próprio com participantes.

A proposta de valor é permitir prever → executar → investigar → redesenhar com consequências reproduzíveis. O motor apresenta recursos, eventos e dados efetivamente recebidos; o jogador pode explicar o que mudou usando evidência da própria execução. O cenário científico próximo a Rio Verde dá contexto à decisão sem sugerir que os três pontos representam todo o Cerrado.

2. Público e hipóteses

As personas abaixo são hipóteses de trabalho, não resultados de entrevistas nem pessoas reais da narrativa. O público inicial proposto reúne estudantes dos anos finais da educação básica, ensino médio e pessoas adultas iniciantes em engenharia espacial. A adequação de linguagem e mediação precisa ser observada antes de fixar faixa etária de uso autônomo.

Nenhuma dessas hipóteses está demonstrada pela existência do software, pela aprovação de testes ou por uma execução 6/6.

3. Contrato científico e operacional

O beta reutiliza o motor 0.1.1-rd, o catálogo ipe-64-v1 e os contratos em src/core/. São seis decisões binárias — bateria, painel, processamento, rádio, memória e política de transmissão — formando 64 configurações. Há dois cenários: long-contact, com duas janelas de 600 s, e short-contact, com duas janelas de 240 s.

O sucesso operacional exige 6/6 registros completos e válidos, nenhuma violação, massa ≤ 3,6 kg, custo ≤ 86 créditos e atendimento às demais regras do motor até 180 minutos simulados. A decisão final vem de MissionResult.outcome; a interface não converte um 6/6 inválido em sucesso. Capacidade, potência, reservas, agendas e créditos são parâmetros didáticos.

Os registros são Terra/MODIS MOD13Q1 Collection 061, preservados com procedência e metadados. São dois períodos históricos de 2024 em três pontos próximos a Rio Verde. Os 180 minutos pertencem à simulação de processamento e transporte. Não são o período de aquisição dos dados históricos. As bandas e o índice oferecem a mesma pergunta científica do catálogo atual; um rádio ou componente diferente não melhora a qualidade original da observação. O guia oficial do produto sustenta a leitura de composição temporal, bandas, escala e qualidade [F-07].

O objetivo científico narrativo é descrever diferenças de NDVI entre os períodos recebidos. Só há comparação temporal quando os dois registros do ponto chegaram completos e válidos. Diferença de NDVI, isoladamente, não identifica a causa da mudança, e o beta não diagnostica seca, incêndio, desmatamento ou produtividade agrícola.

4. Campanha de quatro níveis

As condições abaixo são objetivos pedagógicos adicionais da campanha. Não modificam os limites globais, os parâmetros, o conjunto de dados ou o resultado do motor. Uma operação pode ter sucesso e ainda deixar a condição específica do nível pendente. A interface deve comunicar ambos os estados.

A dificuldade cresce pela interdependência de decisões, pelo tipo de evidência a interpretar e pela autonomia. O número mínimo de trocas não cresce em todos os níveis: a missão final começa com uma configuração que já cumpre a operação por 84 créditos e pede otimização. A descrição de dificuldade não deve prometer mais falhas ou um espaço maior de hardware no quarto nível.

Personagens, incidentes, configurações iniciais, soluções de referência, feedback e transições estão em STORYTELLING-4-NIVEIS.md. A reflexão é uma oportunidade de explicação; texto livre não recebe nota automática nem comprova aprendizagem.

5. Escopo do beta e fronteira do roadmap

Um schema Prisma é um artefato de preparação para uma possível camada conectada. Sua presença não significa banco criado, migração executada, autenticação ativa ou coleta remota. O jogo visitante não depende desses serviços. Publicação no GitHub ou Vercel precisa de URL e evidência próprias; este PRD não é recibo de deploy.

A partida usa o pacote científico incluído, sem consultar uma API de dados durante a simulação. Recarga offline a frio não está estabelecida pela evidência anterior e não é promessa do beta. Preparar e verificar um cache offline seria um trabalho específico.

6. Jornada

1. A pessoa lê a finalidade científica, reconhece que os dados são históricos e seleciona o próximo nível no mapa.
2. O briefing apresenta personagem, incidente, meta 6/6, condição particular e recursos disponíveis.
3. No hangar, revisa escolhas, limites e condições necessárias; registra sua previsão antes de executar.
4. A execução determinística produz um resultado imutável. A animação é uma apresentação desse resultado.
5. O relatório separa operação, condição do nível e ciência disponível. Um evento ou requisito fornece a evidência para a investigação.
6. A pessoa pode refletir, comparar, solicitar ajuda e redesenhar. Ajuda não reduz reconhecimento de conclusão.
7. Uma nova execução que satisfaça o contrato do nível registra a conclusão; o mapa apresenta a próxima etapa e permite revisitar as anteriores.

O tempo simulado de 180 minutos não é contagem regressiva para a pessoa. Pausa, inspeção, ajuda, teclado e movimento reduzido não mudam os resultados nem penalizam progresso.

7. Requisitos e aceite

P0 identifica o contrato de liberação do beta; P1 identifica evolução posterior. O aceite é prescritivo e precisa ser confrontado com a evidência final de QA.

8. Acessibilidade e qualidade de uso

WCAG 2.2 é a referência para planejar e verificar acessibilidade, com foco nos critérios de texto alternativo, teclado, foco, contraste, reflow, movimentos de arraste e mensagens de estado [F-05]. Isso não constitui declaração de conformidade do beta.

Não impor prazo de resposta, punição por pedir ajuda, ranking público, recompensa por tempo de tela ou ação motora que seja desnecessária à decisão. Qualidade de navegação e compreensão serão avaliadas separadamente de velocidade de conclusão.

9. Dados e analytics propostos

O beta já dispõe de diário local de previsões, tentativas, reflexões, ajuda e redesign. Isso é um recurso do dispositivo, não uma plataforma de analytics institucional. Os eventos abaixo formam uma proposta de instrumentação mínima para estudo futuro, sem autorização implícita para enviar dados a servidor.

Evitar nome completo, e-mail, data de nascimento, localização da pessoa, gravação de tela, áudio ou perfil público no núcleo visitante. Coordenadas do pacote MODIS descrevem os dados, não a localização do jogador. Texto livre pode conter identificação espontânea; sua eventual exportação exige orientação e revisão. Não chamar armazenamento local de anonimato garantido.

As métricas propostas são: conclusão por nível e critério; tentativas até uma solução; incidentes de usabilidade; uso de apoio; capacidade de explicar uma relação com evidência; e desempenho em uma tarefa distinta de transferência. Informar denominadores, faltantes, contexto, versão e apoio recebido. Percentual de conclusão mede o fluxo; aprendizagem exige instrumento próprio. Não há resultados de campo neste documento.

10. Validação e decisão de liberação

Há três camadas de evidência: software/modelo, usabilidade/acessibilidade e valor educativo. A primeira verifica contratos; a segunda observa a interação; a terceira investiga compreensão e transferência. Nenhuma substitui as demais.

Antes da liberação, o integrador deve confrontar os requisitos P0 com testes do domínio e da campanha, fluxo UI, build e inspeção de navegador. A documentação de QA deve informar ambiente, comandos, resultado, achados corrigidos e limites. Não marcar leitor de tela, durabilidade de armazenamento, Worker real, GPU ou recarga offline como verificados por um teste jsdom.

Para uma rodada formativa posterior, propõe-se começar com um grupo pequeno e diverso de iniciantes e educadores, com sessões observadas e consentimento adequado ao contexto. O objetivo inicial é encontrar problemas de compreensão e interação, não estimar um efeito causal ou anunciar uma porcentagem de aprendizagem. A quantidade e o recrutamento serão definidos no protocolo real.

Perguntas prioritárias:

1. O jogador explica a diferença entre dado histórico, processamento simulado e ciência recebida?
2. Diferencia W de Wh ao investigar a limitação de pico?
3. Explica por que a memória precisa suportar o acúmulo antes do primeiro contato?
4. Percebe por que a solução com índice deixa de atender o pedido do nível 3?
5. Identifica que 6/6 por 84 créditos cumpre a operação, mas não a condição de 78 créditos do nível 4?
6. Consegue propor um redesign com base em uma evidência, sem copiar a solução da ajuda?
7. Entende que um delta de NDVI não estabelece uma causa ambiental?
8. Consegue completar a jornada com os recursos de acessibilidade que utiliza?

11. Riscos e respostas de produto

12. Origem, referências e decisões

O projeto preserva a origem em oalexandrebelo/AB-NASA-TEAM-IPE, commit 73162276b46227e8965eed2b91a7dc8edae70b96, e os avisos de autoria/licença existentes. O nome PROJETO-IPÊ identifica a evolução solicitada; não apaga a história da Missão Ipê. Não há endosso NASA, PhET ou W3C.

Os anexos SmartCity fornecidos por AB foram usados como referência de estrutura: separar evidência de intenção, ligar mecânica a feedback, preservar autoria e manter serviços futuros distintos do núcleo visitante. A campanha continua espacial. Faixas etárias, legislação de trânsito, 12 missões, Prisma de 23 modelos e promessas de offline daquele material não foram transferidos para este produto.

Fontes consultadas em 14/11/2026, America/Sao_Paulo. As aplicações ao PROJETO-IPÊ são decisões autorais de produto.

Continuam válidas as fontes e limitações documentadas em PESQUISA-E-DECISOES-R9.md, REFINAMENTO-NASA-R10.md e research/round10/. A nova pesquisa e as oportunidades estão em INSIGHTS-E-OPORTUNIDADES.md.

PRT — Plano de Requisitos Técnicos do PROJETO IPÊ

Este PRT transforma o escopo de produto em contratos verificáveis para o beta educacional. A meta científica permanece 6/6 registros completos e válidos, respeitando todas as restrições do motor. Os quatro níveis acrescentam objetivos de engenharia; nenhum deles reduz a qualidade científica exigida.

Referência: 14/11/2026, base de implementação R9–R10. Fontes de autoridade: PRD, contratos TypeScript, catálogo, contrato de implementação e refinamento NASA. A arquitetura e os fluxos estão em ARQUITETURA e FLOWCHARTS.

1. Escopo de entrega

O nível didático é um contrato de conteúdo, não um novo ScenarioId. Lançador, órbita e agenda base continuam fixos. O laboratório físico é uma experiência independente.

2. Contrato dos quatro níveis

Todos os níveis usam até 3,6 kg, até 86 créditos, 10.800 segundos simulados e o mesmo pacote de seis registros. A conclusão exige uma execução própria concluída no nível, com a configuração registrada no resultado e o gate correspondente. Importação, mudança de componente depois da execução ou aplicação de uma sugestão não contam como nova execução.

O gate usa exclusivamente o resultado executado e sua configuração. Um motor com sucesso e gate pendente precisa de feedback específico, preservando o significado do sucesso científico. A regra do nível não pode mudar result.outcome, requiredRecords ou o catálogo.

As testemunhas abaixo foram recalculadas com o motor real em Node 24.22.1 em 14/11/2026. Todas produziram outcome = "success", 6/6 e aprovação no gate do nível. A base é DEFAULT_CONFIG: bateria pequena, painel padrão, BANDAS, rádio econômico, memória grande e todos os contatos; a tabela declara cada alteração.

A busca contextual foi também executada: 64/64 configurações em cada nível, nenhuma indeterminação e, respectivamente, 17, 6, 1 e 2 soluções elegíveis. As distâncias mínimas a partir do projeto inicial de cada nível foram 0, 2, 3 e 1. Essa contagem descreve o catálogo fechado; não é probabilidade de sucesso nem prova de aprendizagem.

3. Requisitos funcionais e critérios de aceite

4. Requisitos numéricos e científicos

5. Requisitos não funcionais

Não se fixa uma meta de FPS ou latência sem perfil de dispositivo e medição. O gate do beta exige fluxo utilizável e sem bloqueio indevido; metas quantitativas de desempenho devem vir de benchmark registrado, com navegador, hardware e condições.

6. Contratos de dados e segurança

A entrada científica aceita somente as seis chaves de MissionConfig, valores do catálogo e um dos dois cenários conhecidos. O resultado v1 preserva observações, eventos, trace, violações, balanço energético e contadores de bits como strings decimais. Datas reais do pacote nunca são derivadas do relógio simulado.

O armazenamento local preserva snapshots; o rascunho permanece editável e revisionado. Importação é uma fronteira de confiança: deve rejeitar estrutura inválida antes de aplicar estado, conferir identidade e recalcular. Hashes não servem como assinatura de autoria ou credencial.

O schema Prisma propõe versões de campanha/nível/projeto, identidade pseudônima, sessões, execuções, previsões, decisões, reflexões, proveniência e progresso. A existência do schema não significa que esses dados sejam enviados para um servidor. Os tipos, índices, exclusão, retenção e protocolo de sync estão descritos no README Prisma.

Para ativar a proposta cloud serão obrigatórios: autenticação do contexto, owner resolvido no servidor, autorização por sessão, chaves de idempotência, comparação de conteúdo em retries, validação de cada DTO, reexecução, proteção contra alteração de evidências e testes de exclusão. RLS requer migração SQL e testes específicos. Credenciais ficam no servidor; nenhum dado de conexão entra no bundle ou em VITE_*.

Textos de previsão e reflexão continuam locais por padrão. O piloto cloud proposto usa campos opcionais para texto, expiração explícita e expurgo; essas medidas ainda precisam de implementação. Não se infere anonimização a partir de um pseudônimo nem se acrescenta coleta de dados infantis para habilitar a campanha.

7. Estratégia de verificação e gates de entrega

O registro R10 documenta 101 testes de domínio/física/proveniência e 9 testes UI da base. A integração dos quatro níveis deve acrescentar seu próprio recibo, sem reutilizar essa contagem como se cobrisse mudanças posteriores. A coordenação deve atualizar a evidência final após executar a suíte da entrega.

8. Riscos técnicos e respostas

9. Handoff técnico

O próximo responsável deve partir de package-lock.json, contratos e testes existentes. Mudança que altera a física, dataset ou formato de replay exige nova identidade de versão e revisão dos resultados de referência. Mudança puramente didática pode criar revisão da trilha sem tocar no motor, desde que preserve o significado de outcome e as evidências de cada tentativa.

O pacote inclui arquitetura, fontes Mermaid, schema Prisma e instruções de validação do schema. O recibo final deve distinguir implementado, executado em teste, observado no navegador, publicado e proposto. Autoria de código assistida por IA, arquivos NASA e sucesso na simulação não estabelecem certificação, endosso institucional, validação de voo ou elegibilidade competitiva.

MISSÃO IPÊ — narrativa científica de quatro níveis

Versão editorial 1.1 · atualização R17 em 15/11/2026 · America/Sao_Paulo. Direção de produto: AB / Alexandre Belo; conteúdo e verificação do contrato com assistência de IA. Documento vigente da campanha. Os dados científicos são reais e históricos; as configurações, os contatos, os limites e os créditos pertencem ao exercício didático.

1. Arco da campanha

O instrumento MODIS, a bordo do satélite Terra da NASA, observa a vegetação terrestre. O produto MOD13Q1 V6.1 reúne índices de vegetação em períodos compostos de 16 dias e resolução de 250 m. A campanha usa um recorte de seis registros históricos de 2024: dois períodos em três pontos próximos a Rio Verde. O participante investiga como os valores de NDVI variam e quais decisões permitem que os dados necessários à comparação cheguem completos ao solo.

Os registros já existem no arquivo científico. O CubeSat é um modelo didático de processamento e transporte desses arquivos. A experiência progride de uma primeira entrega orientada para decisões de armazenamento, comunicação e uso de recursos; ela não recria a aquisição de dados pela missão Terra.

A história avança quando surge uma necessidade nova: compreender o caminho do dado; trabalhar com memória compacta; preservar bandas sob contatos curtos; e produzir a mesma entrega com folga de créditos. As necessidades são conhecidas antes da execução. Nenhum incidente exige uma falha aleatória, um desastre ambiental inventado ou uma recuperação que o motor não oferece.

Pergunta científica: como os valores de NDVI dos três pontos diferem entre os dois períodos efetivamente recebidos? Meta operacional: entregar 6/6 registros válidos e completos com todas as restrições satisfeitas. Convite educativo: explicar como uma escolha alterou o caminho dos dados até o solo.

As condições particulares dos níveis são escolhas pedagógicas da campanha. O envelope do motor permanece em 3,6 kg, 86 créditos e 180 minutos simulados. O nível 4 acrescenta uma meta de custo de 78 créditos; isso não altera retroativamente o teto de 86 créditos do motor.

2. Funções científicas e linguagem

Cada função é uma perspectiva de trabalho que o participante assume. Os briefings são instruções pedagógicas da MISSÃO IPÊ, sem falas atribuídas a pessoas ou equipes da NASA. O símbolo da árvore pertence à identidade da equipe; a progressão da campanha se fundamenta nas perguntas científicas e nos compromissos de engenharia.

O feedback deve seguir ocorrência observada → consequência → oportunidade de investigação. Evitar “você errou tudo”, “missão segura”, “risco zero” ou “aprovado pela NASA”. Uma tentativa incompleta continua disponível para estudo; nunca é necessário falhar deliberadamente para obter a conquista.

3. Regras comuns de progressão

O identificador do nível, seu briefing e sua condição acompanham a tentativa. A conclusão é avaliada sobre a configuração realmente executada. Alterar o projeto depois do relatório não reaproveita o resultado anterior como evidência de uma nova solução.

Em todos os níveis, a primeira condição é result.outcome === 'success', com 6/6 registros exigidos e nenhuma violação. As condições adicionais vêm da tabela a seguir. Nenhuma resposta de texto, escolha de câmera, velocidade de animação ou pontuação visual substitui esse contrato.

O apoio muda de orientação inicial para perguntas de investigação e, por fim, síntese autônoma. Recursos de ajuda permanecem disponíveis e não anulam conclusão. A reflexão pode ser sugerida e salva, mas sua qualidade depende de interpretação humana; não é corrigida por contagem de palavras ou palavras-chave.

4. Nível 1 — Primeiro sinal

Função: planejamento de missão. Intenção pedagógica: reconhecer que o valor científico depende de chegar ao solo com integridade e qualidade.

Situação de aprendizagem: examine o pacote histórico e o projeto inicial que já atende à operação simulada. A primeira tarefa é acompanhar o fluxo completo e entender por que ele funciona. A comparação entre dois períodos só fica disponível quando ambos os registros de um ponto chegam completos e válidos.

Orientação ao participante:

Examine seis registros históricos Terra/MODIS de três pontos próximos a Rio Verde. Antes de interpretar a variação de NDVI, faça os pares chegarem completos. Acompanhe o caminho de cada lote até o solo.

Objetivo mensurável: entregar os seis registros válidos no cenário de contatos longos, sem violação do motor. O jogador pode manter ou alterar o projeto inicial; a configuração vencedora não precisa ser única.

Escolha significativa: decidir quando transmitir e conferir se as capacidades escolhidas atendem o volume. A política de todos os contatos ajuda a perceber por que duas oportunidades importam. O jogador pode usar a revisão prévia, mas deve distinguir uma conta necessária de uma execução concluída.

Interação: examinar a meta, observar um subsistema, registrar uma previsão e executar. No relatório, acompanhar ao menos um registro do fim de processamento à entrega; essa inspeção é uma orientação de aprendizagem, não um clique obrigatório que simula compreensão.

Feedback contextual:

• Em sucesso: “Os seis registros chegaram completos e válidos. Agora os três pontos têm os dois períodos necessários à comparação.”
• Se um lote estiver parcial: “Parte deste lote chegou, mas o registro ainda não conta como entregue.”
• Se a configuração falhar: apresentar o evento real e permitir redesenhar; não insistir em uma fala de sucesso do roteiro.

Critério de conclusão: sucesso operacional 6/6 no cenário longo, atribuído a este nível. A configuração inicial já o satisfaz quando executada.

Evidência de referência: DEFAULT_CONFIG entrega 6/6 com 3,05 kg e 71 créditos. Produz e transmite 1.080 Mbit; não perde dados e termina sem fila. Esses números vêm do motor, não de uma recompensa narrativa.

Pergunta de debrief: “Qual é a diferença entre produzir um lote e disponibilizar sua ciência no solo?”

Transição: o segundo exercício exige manter uma memória menor. Leve o raciocínio sobre volume e agenda para esse novo limite do modelo.

Conceitos: cadeia de dados; lote completo; tempo de contato; projeto versus operação; dados históricos versus simulação; primeira leitura de evidência.

5. Nível 2 — Memória em disputa

Função: engenharia de dados. Intenção pedagógica: investigar armazenamento antes do contato e perceber que reduzir volume exige uma decisão de processamento e potência.

Situação de aprendizagem: o novo exercício fixa a memória compacta de 512 Mbit. Mantidos os demais componentes iniciais, seis lotes de bandas não cabem antes do primeiro contato. Não é uma pane de fabricação: é uma incompatibilidade entre a agenda e o projeto.

Orientação ao participante:

Neste exercício, a memória disponível é de 512 Mbit. Os trabalhos terminam antes do primeiro contato com o solo. Investigue como entregar todos os registros mantendo essa capacidade.

Objetivo mensurável: sucesso 6/6 no cenário longo mantendo buffer: compact. Uma execução bem-sucedida com memória grande cumpre a operação, mas deixa este pedido pendente.

Escolha significativa: manter bandas maiores e investigar por que não cabem, ou processar o índice a bordo e sustentar sua demanda de potência. A qualidade científica da pergunta permanece igual no catálogo; a mudança não cria precisão adicional.

Interação: comparar capacidade e volume antes do primeiro contato, prever o gargalo, executar e localizar uma perda de lote quando houver. Redesenhar o processamento e a alimentação; executar outra vez para verificar a hipótese.

Feedback contextual:

• No preset: “O terceiro lote completo não coube. A transmissão ainda não havia começado, e o lote novo foi perdido.”
• Ao escolher índice com bateria pequena e observar pico: “O volume diminuiu, mas a demanda instantânea excedeu a descarga permitida. Investigue W e Wh separadamente.”
• Se trocar apenas para memória grande: “A missão entregou 6/6. Para concluir este nível, a entrega também precisa funcionar com 512 Mbit.”
• Em sucesso com memória compacta: “O projeto acomodou os seis lotes e entregou os registros mantendo a memória prevista.”

As frases só aparecem quando a evidência da execução corresponder. O motor emite BUFFER_OVERFLOW no primeiro descarte aos 1.860 s do preset, depois do terceiro trabalho; não existe animação de restauração dos arquivos perdidos nessa tentativa.

Critério de conclusão: sucesso operacional e memória compacta na configuração executada. Não exigir um número arbitrário de tentativas, uma falha prévia ou uma solução específica entre as viáveis.

Evidência de referência: o preset entrega 2/6, perde 720 Mbit e termina sem fila porque os lotes rejeitados não foram armazenados. Trocar processamento para índice e bateria para grande, mantendo painel padrão, rádio econômico, memória compacta e todos os contatos, entrega 6/6 com 3,40 kg e 81 créditos. Existem seis configurações que atendem este nível no catálogo atual.

Pergunta de debrief: “Que escolha reduziu o volume, e que outro requisito precisou ser atendido para ela funcionar?”

Transição: o próximo exercício exige receber as bandas para calcular NDVI no solo, com contatos menores. A solução aprendida continua válida para o exercício anterior; agora o requisito de representação mudou.

Conceitos: acúmulo antes do contato; perda de lote novo; processamento a bordo; representação de dados; potência instantânea versus energia; solução que depende do objetivo.

6. Nível 3 — Janela estreita

Função: operação de solo. Intenção pedagógica: coordenar comunicação, potência e envelope quando o pedido científico restringe uma alternativa.

Situação de aprendizagem: neste exercício, os contatos duram quatro minutos cada e a representação precisa permanecer em bandas. As janelas menores são uma condição do cenário anunciada no briefing, não uma estação que falha ao acaso.

Orientação ao participante:

Preserve as bandas vermelha e infravermelha próxima para calcular o NDVI no solo. O cenário oferece dois contatos de quatro minutos. Revise o projeto para entregar os seis registros nesse tempo.

O pedido de bandas é uma restrição pedagógica de representação. O motor mantém a mesma pergunta NDVI; não simula automaticamente uma nova análise científica apenas por preservar as bandas.

Objetivo mensurável: sucesso 6/6 em short-contact com processing: bands. Usar índice pode resolver a operação em outras configurações, mas não atende a condição deste nível.

Escolha significativa: aumentar a taxa de transmissão requer suportar a potência do rádio; acomodar rádio e bateria maiores também exige manter massa e créditos dentro do envelope. O projeto não pode simplesmente maximizar todas as peças.

Interação: comparar volume total com a capacidade útil das janelas; executar a hipótese; inspecionar fila e registros completos; redesenhar rádio, alimentação e painel conforme necessário; verificar novamente e comparar.

Feedback contextual:

• No preset: “Nenhum lote foi perdido na memória. A janela terminou com dados ainda a bordo.”
• Ao trocar somente para rádio rápido e observar pico: “O rádio oferece maior taxa, mas esta execução parou no limite de descarga. Confira a demanda na bateria.”
• Ao ultrapassar o envelope: “O projeto não atende ao limite indicado. A entrega, sozinha, não conclui a missão.”
• Em sucesso com bandas: “As bandas dos seis registros chegaram. O cálculo no solo pôde ser concluído dentro das regras deste exercício.”

Critério de conclusão: sucesso operacional, cenário curto e bandas na configuração executada. Uma solução por índice deve mostrar “pedido de bandas pendente” sem renomear o sucesso do motor como falha física.

Evidência de referência: o preset entrega 2/6, transmite 460,8 Mbit e mantém 619,2 Mbit na fila, sem perda de memória. Há uma configuração que atende a este nível no catálogo: bateria grande, painel compacto, bandas, rádio rápido, memória grande e todos os contatos. Ela entrega 6/6 com 3,40 kg e 79 créditos.

Pergunta de debrief: “Por que aumentar a taxa de rádio exigiu rever a alimentação e outra escolha do projeto?”

Transição: o exercício final permite receber o índice para responder à mesma pergunta sobre NDVI e exige oito créditos de folga. Escolha a representação conforme os requisitos e justifique a decisão usando o resultado da execução.

Conceitos: taxa e duração; recepção parcial; capacidade útil de contato; potência do rádio; compromissos de massa e orçamento; representação solicitada; comparação com múltiplas mudanças.

7. Nível 4 — Ciência que chega

Função: revisão de projeto e ciência. Intenção pedagógica: otimizar sob uma necessidade explícita, defender uma alternativa e reconhecer o limite do que os dados permitem afirmar.

Situação de aprendizagem: o projeto de partida já entrega 6/6 nos contatos curtos por 84 créditos. O novo pedido é reservar ao menos oito dos 86 créditos totais. A missão funciona; a pergunta agora é como atingir a mesma entrega usando no máximo 78 créditos.

Orientação ao participante:

O projeto inicial já entrega todos os registros. Encontre uma configuração de até 78 créditos e mostre, no relatório, o que sustenta sua decisão. Descreva a diferença de NDVI dos pares recebidos e indique o limite dessa conclusão.

Objetivo mensurável: sucesso 6/6 em contatos curtos com custo ≤ 78 créditos. A explicação acompanha a reflexão e não vira uma condição de aprovação automática de texto.

Escolha significativa: escolher quais folgas preservar. Um projeto de 78 créditos mantém a memória grande; um de 75 usa memória compacta. Ambos cumprem a missão sob as condições fixas do motor. O menor custo não representa, por si só, maior confiabilidade ou uma decisão universalmente melhor.

Interação: revisar o briefing com menos orientação passo a passo; escolher, prever e executar; consultar requisitos e folgas; comparar ao projeto de partida; abrir os pares recebidos e elaborar uma afirmação descritiva com limite.

Feedback contextual:

• No preset: “Operação concluída: 6/6. A condição deste nível ainda pede reduzir o projeto de 84 para até 78 créditos.”
• Em sucesso: “Os seis registros chegaram e o projeto preservou pelo menos oito créditos. Veja quais folgas sua escolha mantém.”
• Na ciência: “A diferença entre dois valores descreve o par recebido. Ela não revela, sozinha, a causa da mudança.”

Critério de conclusão: sucesso operacional e custo de até 78 créditos no resultado executado. Contador, etapa do mapa e mensagem de conclusão devem corresponder a essa avaliação.

Evidência de referência: há duas configurações elegíveis no catálogo curto: bateria grande, painel compacto, índice, rádio econômico e todos os contatos; a memória pode ser grande, totalizando 3,20 kg/78 créditos, ou compacta, totalizando 3,10 kg/75 créditos. Ambas entregam 6/6. O preset tem bateria grande, painel padrão, índice, rádio econômico e memória grande, somando 3,50 kg/84 créditos.

Debrief final sugerido:

1. “Qual escolha você defende e que valor ou evento sustenta sua explicação?”
2. “Que folga mudou em relação ao projeto anterior?”
3. “Qual diferença de NDVI pode ser descrita com os pares recebidos e o que ainda não pode ser concluído?”

Essas perguntas podem ser respondidas por texto, fala em atividade mediada ou discussão fora da aplicação. O beta não presume gravar áudio nem interpretar automaticamente a resposta. Concluir a campanha demonstra cumprimento dos desafios; aprendizagem continua sendo uma questão de pesquisa.

Encerramento: o participante examina os três pares recebidos, consulta as fontes e compara outra solução ou explora o laboratório. O resultado reúne decisões verificadas dentro do modelo e uma leitura descritiva dos dados. A conclusão da campanha não equivale a certificação de engenharia de voo ou classificação NASA.

Conceitos: objetivos e restrições; folga de recursos; comparação de alternativas; evidência e raciocínio; dado versus inferência; limite do modelo; autonomia com possibilidade de ajuda.

8. Configurações e resultados para integração

small/large, compact/standard, bands/index, economy/fast, compact/large e every-contact/last-contact são os valores dos seis campos do contrato. A tabela escreve as opções por extenso para revisão humana.

As contagens de soluções foram verificadas por enumeração das 64 configurações em 14/11/2026: 17 satisfazem a operação longa, seis também atendem à memória compacta do nível 2; nove satisfazem a operação curta, uma também preserva bandas no nível 3 e duas atendem ao teto de 78 créditos do nível 4. Esses conjuntos não são probabilidades de sucesso em voo.

9. Aceite narrativo e pedagógico

10. Referências e alcance

A base científica é o produto MOD13Q1 V6.1, NASA Earthdata. A página MODIS — missão Terra explica o instrumento e suas observações da vegetação. Os seis registros usados no jogo, suas bandas, qualidade, coordenadas de consulta e hashes estão em public/data/mod13q1-research-pack.json; o contrato executável conserva esses dados em src/data/science-data.ts. O MOD13 User Guide V6.1 detalha produto e indicadores de qualidade.

O Appendix S do NASA Systems Engineering Handbook inspira a ligação entre necessidade, usuários e operação. My NASA Data — Building Claims from Evidence informa a separação entre afirmação, evidência e raciocínio. As funções, instruções e condições pedagógicas da campanha são uma adaptação autoral, sem endosso das instituições.

Referências pedagógicas consultadas em 14/11/2026; produto MOD13Q1 e instrumento Terra/MODIS reconferidos em 15/11/2026, America/Sao_Paulo. O código do catálogo e do motor fornece a evidência dos números do jogo. O roteiro propõe uma experiência educativa; revisão humana, clareza com o público e transferência de aprendizagem permanecem pendentes de pesquisa. O PRD define o produto e INSIGHTS-E-OPORTUNIDADES registra hipóteses de evolução.

PROJETO-IPÊ — insights e oportunidades

Pesquisa e decisões de produto · 14/11/2026 · referência de data: America/Sao_Paulo. Direção: AB / Alexandre Belo. Investigação e redação com assistência de IA. Este documento distingue evidência externa, observação do código e hipótese autoral.

1. Decisão principal

A evolução de maior valor para este beta é transformar o motor existente em quatro pedidos de missão diferentes e explicáveis. O projeto já consegue conservar recursos, distinguir entrega parcial e total, verificar qualidade e comparar alternativas. A campanha dá motivo a essas decisões sem acrescentar física não modelada.

A pesquisa adicional favorece três oportunidades: apoio à exploração que não revele a solução; uma explicação final apoiada em evidência; e alfabetização de dados que inclua procedência e limites. As fontes orientam hipóteses de design. Elas não validam a eficácia do PROJETO-IPÊ.

2. O que foi consultado

Foram revisados README, pesquisa R9, refinamento R10 e os três pareceres de research/round10/, além dos contratos, catálogo, motor, busca, pacote de registros e diário local. Os anexos de SmartCity enviados por AB foram consultados como referência contextual de estrutura e avaliação; não redefinem o tema da missão espacial.

Foram abertas fontes primárias de NASA, My NASA Data, University of Colorado/PhET e W3C. A consulta ao catálogo LP DAAC retornou 403; o guia oficial MOD13 Collection 6.1 permaneceu acessível. Um artigo da RSC foi localizado por busca, mas sua abertura também retornou 403; ele não é usado como base de uma afirmação sobre resultados no projeto. A investigação sobre orientação em simulações usa o estudo disponível no domínio do PhET [S-05].

Não foram realizados entrevistas, aplicação com estudantes, revisão pedagógica por especialista humano, experimento controlado ou coleta de resultados de campo. Esta frente não publicou serviços, criou banco ou modificou a física do jogo.

3. Evidência externa e interpretação de produto

4. Oportunidades incorporadas ao contrato do beta

O-01 — Quatro pedidos, uma engenharia coerente

Os níveis usam os mesmos seis registros e 64 projetos, mas mudam o pedido: entrega inicial, memória compacta, bandas sob contatos curtos e economia com oito créditos de folga. As condições surgem no briefing e são avaliadas depois. Essa distinção dá significado à necessidade do usuário da missão: uma configuração bem-sucedida pode não atender à representação ou ao custo pedido no nível.

Entrega prevista: quatro níveis no mapa com cenário, preset, personagem, intenção e critério próprios. Evidência de aceite: concluir com os resultados elegíveis; rejeitar progresso quando apenas o motor, mas não o pedido particular, foi satisfeito. Risco de UX: chamar as duas avaliações de “falha” indistintamente. Resposta: apresentar “operação concluída” e “condição do nível pendente” quando for o caso.

O-02 — Ajuda que protege o objetivo do exercício

A busca existente enumera o catálogo para sucesso da missão. No nível 2, a solução mínima genérica seria ampliar memória, o que viola o pedido de manter 512 Mbit. No nível 3, uma solução com índice também poderia violar o pedido de bandas. Portanto, uma ajuda de campanha precisa considerar o critério do nível ou dizer claramente que está respondendo apenas à operação.

Entrega prevista: ajuda contextual após tentativa própria, mantendo explicação de mudanças e oportunidade de prever novamente. Aceite: nenhuma alternativa anunciada como solução do nível falha em sua condição adicional. Hipótese a investigar: a ajuda orienta o raciocínio ou induz a copiar opções sem compreensão?

O-03 — Explicação final com evidência, sem nota automática

O diário e os eventos existentes permitem uma reflexão curta: escolha defendida, valor/evento observado, consequência e limite. Isso pode apoiar a discussão com um facilitador sem inserir um avaliador generativo ou uma regra frágil de palavras-chave.

Entrega prevista: perguntas de reflexão integradas ao arco narrativo e acesso às evidências do resultado. Aceite: conclusão depende de condições computáveis da missão; texto livre não recebe um selo de aprendizagem. Pesquisa posterior: revisão humana de explicações e de uma tarefa distinta de transferência.

O-04 — Mapa como orientação de campanha

O mapa deve mostrar propósito, estado e próxima ação dos quatro níveis. Ele representa a progressão educativa; não é uma órbita operacional nem precisa pedir localização do jogador. Uma lista de ações no DOM deve oferecer a mesma informação e acesso.

Entrega prevista: seleção de nível, progresso real e retorno ao briefing. Aceite: teclado e alternativa textual permitem acessar cada etapa; visitar um nó não concede conclusão. Pesquisa posterior: observar se mapa e lista produzem diferenças de orientação, sem presumir que uma decoração espacial melhora compreensão.

5. Novas oportunidades para o próximo ciclo

P1 é o próximo ciclo de investigação e P2 é expansão dependente de nova engenharia. Essas oportunidades não são funcionalidades já implementadas. O beta mantém o laboratório independente e não conecta seus controles à campanha sem um contrato novo.

6. Decisões que evitam conclusões indevidas

Dificuldade não será uma contagem oculta de falhas. O nível 4 pode ser resolvido com uma troca de painel a partir do preset; seu desafio está em otimizar com autonomia e explicar o compromisso. Se participantes o perceberem como mais simples que o nível 3, a observação deve orientar a próxima revisão. Não inventar um indicador de dificuldade para defender a ordem.

“Processar índice” não significa compressão genérica sem perdas. O catálogo representa duas formas de responder à mesma pergunta NDVI, com volumes e cargas diferentes. A documentação deve falar em processamento ou redução de volume. Novos usos científicos que dependam das bandas precisam de objetivo próprio e não são simulados por uma frase da narrativa.

Folga não é confiabilidade. A diferença entre limite e uso é informativa, mas não mede probabilidade de pane. As contagens de configurações elegíveis tampouco representam chance de sucesso de um satélite real.

Conhecimento científico continua separado da história. A equipe é fictícia; o pacote MODIS e sua procedência são reais; recursos e operação da nave são didáticos. A ciência só aparece conforme recepção e qualidade. Um quadro com delta positivo ou negativo não autoriza identificar uma causa ambiental.

O domínio SmartCity fornece estrutura, não regras deste produto. Aproveitam-se a preocupação com evidência, acessibilidade, separação de serviços e critérios por mecânica. Não se importam afirmações sobre legislação, público infantil, licenças de repositórios ou resultados de oficinas. O dossiê também não é tratado como validação de dados que não vieram acompanhados de evidência.

7. Verificação numérica realizada nesta frente

Foi executada leitura direta de simulateMission e enumeração de enumerateConfigurations em Node com --experimental-strip-types, usando os contratos atuais. Os resultados abaixo são observações do motor local em 14/11/2026. Não substituem a suíte integrada nem uma inspeção do novo mapa no navegador.

Critérios usados na enumeração: resultado success e, conforme o nível, config.buffer === 'compact', config.processing === 'bands' ou result.credits <= 78. O cenário faz parte de cada comparação. Configurações, soluções e consequências estão detalhadas em STORYTELLING-4-NIVEIS.md.

8. Perguntas para uma pesquisa futura

1. O jogador entende por que os pedidos dos níveis 2 e 3 exigem representações diferentes, ou interpreta isso como contradição do jogo?
2. O preset bem-sucedido do nível 4 ajuda a separar operação e objetivo de projeto, ou precisa de uma apresentação mais clara?
3. O jogador identifica o primeiro evento relevante e formula uma mudança, ou a quantidade de informação do relatório atrapalha?
4. A pessoa diferencia “perdido por memória” de “ainda em fila por contato curto” quando ambos mostram 2/6?
5. O mapa permite retomar contexto e próximo passo sem obrigar a ler novamente toda a narrativa?
6. A ajuda de catálogo mantém espaço para prever e explicar, ou encerra a investigação cedo demais?
7. O retorno científico comunica ausência de dados e limites da inferência sem parecer um erro da interface?
8. Quais diferenças aparecem com teclado, leitor de tela, zoom, movimento reduzido e aparelhos de menor capacidade?

O protocolo deve distinguir comportamento observado, fala do participante e interpretação do pesquisador. Registrar versão do software, tarefa, apoio recebido, incidentes e dados ausentes. Não usar duração de sessão, cliques ou número de tentativas como medida isolada de aprendizagem.

9. Registro de fontes primárias

Todas as fontes abaixo foram consultadas em 14/11/2026, America/Sao_Paulo. Datas editoriais ou de versão são preservadas quando identificadas; não se usa a data de acesso como revisão técnica do documento.

As referências R9/R10 continuam preservadas, inclusive a distinção entre orientações NASA e obrigações institucionais. O PROJETO-IPÊ mantém a autoria e a licença de sua base, declara assistência de IA e não apresenta endosso, certificação, parceria ou aprendizagem demonstrada que não tenha evidência própria.

Arquitetura — PROJETO IPÊ

A execução científica do beta acontece no navegador, com um motor determinístico independente da interface. A trilha de quatro níveis acrescenta objetivos didáticos sobre os dois cenários existentes; não substitui o contrato científico. A persistência cloud descrita ao final é uma proposta opcional e isolada.

Data de referência: 14/11/2026. Base inspecionada: motor 0.1.1-rd, catálogo ipe-64-v1, trilha ipe-campaign-v1, resultado/replay v1, canonicalização ipe-json-v1, pacote científico 6f49100126a82e1783281083e2c268bcf7b4661b500280de4dc96123036b2a1e. As versões do frontend estão fixadas no package.json e lockfile.

1. Limite de cada camada

2. Stack e compatibilidade

Prisma 7 documenta suporte a Node ^24.0.0 e TypeScript 5.4+. Isso permite escolher Node 24 para a proposta, mas não comprova que um serviço futuro com o client gerado já foi compilado/testado com TypeScript 7.0.2. Esse teste integra o gate de ativação cloud. O frontend atual não importa Prisma. Ver requisitos oficiais e decisão do modelo de dados.

3. Contratos de execução

src/core/contracts.ts é a autoridade de tipos do motor; o contrato de implementação preserva suas invariantes.

O resultado distingue success, failure e invalid. A condição científica é 6/6 registros completos e válidos, com todas as restrições respeitadas. Massa de até 3,6 kg, até 86 créditos, horizonte de 10.800 s e as condições de energia, potência, memória, transmissão e qualidade permanecem válidos nos quatro níveis.

Trilha didática e cenários

Os níveis selecionam os mesmos seis componentes do catálogo. O motor mantém dois cenários: duas janelas de 600 s ou duas de 240 s. Um relatório pode informar “missão científica concluída; requisito deste nível pendente” quando o motor tem sucesso mas a restrição pedagógica não foi cumprida. Essa distinção evita esconder um resultado científico correto ou completar o nível por uma regra diferente da declarada.

A busca geral responde sobre viabilidade científica no catálogo. searchCampaignCatalog aplica também os critérios do nível, recalcula a distância mínima entre soluções elegíveis e separa missionSuccessful de rejectedByLevel. As contagens da ajuda contextual devem somar elegíveis, rejeitados pelo nível, falhas e inválidos; não usar a regra de contagem da busca científica sem incluir essa nova categoria. Os níveis são liberados em ordem e podem ser revisitados depois de concluídos.

4. Cálculo, recursos e proveniência

O motor progride por eventos e fronteiras de tempo. Potência instantânea e energia armazenada são grandezas distintas. Os contadores de dados preservam bits e registram estados como produzido, em fila, parcialmente transmitido, entregue ou perdido. Somente recepção completa com qualidade válida conta como registro científico entregue.

Os seis registros históricos são Terra/MODIS MOD13Q1, Collection 061, em três locais próximos a Rio Verde, com compostos iniciados em 28/08/2024 e 13/09/2024. Cada observação preserva sua própria data, separada do início do composto e do relógio simulado. A cadeia de proveniência relaciona respostas ORNL DAAC, recibos de recuperação, metadados CMR e pacote compilado. O refinamento NASA registra a auditoria científica e as referências da rodada.

O retorno científico só compara um ponto quando os dois registros do par chegaram e foram validados. Variação de NDVI entre datas é descritiva; não determina causa ambiental, nem três pontos representam o Cerrado inteiro. As massas, potências, créditos e agendas do catálogo são parâmetros didáticos.

5. Concorrência e falhas locais

A ponte de Worker preserva entrada e ID do pedido, valida o tipo de resposta e ignora respostas obsoletas. Cancelamento termina o trabalho correspondente; o fallback local utiliza o mesmo motor quando Worker não está disponível. Isso mantém equivalência de regras, sem prometer equivalência de responsividade entre execução fora e dentro da thread principal.

App mantém tokens para execução, importação e histórico. Trocar projeto ou cenário invalida a relação com o resultado anterior; aplicar uma alternativa cria um projeto ainda não executado. Pausar o relatório apenas percorre um trace já calculado. O tempo visual da cena não é o tempo de integração do motor.

O rascunho do IndexedDB usa comparação de revisão dentro de transação readwrite, inclusive entre abas. Divergência gera conflito e exige recarregar/conciliar; não sobrescreve silenciosamente o trabalho mais recente. Para salvar execução, snapshot e hashes são preparados antes de abrir a transação. O retorno ao chamador acontece após transaction.complete.

O diário pedagógico em localStorage é independente dos snapshots do IndexedDB. Não há transação atômica entre os dois mecanismos. Portanto, o diário não é usado como um registro antifraude ou comprovante institucional; uma falha em um deles deve ser comunicada sem descartar o resultado da missão.

O progresso da trilha usa mission-ipe:campaign:v1 em localStorage, com a versão da campanha, motor e catálogo. Ao restaurar, valida estrutura, ordem de conclusões, configuração e critério de cada nível por recálculo. Na sessão ativa, um token mantido em WeakMap impede que importação ou histórico sejam tratados como o lançamento próprio atual. Isso protege o fluxo da aplicação; não transforma armazenamento controlado pelo usuário em prova antifraude. Reflexão é uma atividade pedagógica disponível, não uma exigência do gate numérico de conclusão.

6. Importação como fronteira de confiança

O replay v1 tem uma gramática JSON deliberadamente limitada: tamanho máximo de 1 MiB, profundidade máxima de 20, limitação de nós/strings/arrays e rejeição de chaves duplicadas, propriedades perigosas, números inválidos e versões incompatíveis. URLs, scripts e instruções presentes em arquivo importado não são executados nem consultados.

Depois do parser, a importação confere a entrada, o resultado alegado e seus hashes; então roda novamente o motor. matchesClaim informa se o resultado recalculado corresponde à alegação. A UI deve manter essa distinção e nunca usar um trace importado como substituto do cálculo. Uma importação inválida não deve apagar um resultado anterior ainda válido.

SHA-256 canônico garante identidade do conteúdo dentro do formato; não atesta autoria, aquisição NASA, avaliação humana ou verdade de um modelo de voo. O contrato versionado limita a reexecução ao motor e pacote compatíveis. Não se promete determinismo binário entre versões diferentes de motores.

7. Modelo cloud proposto

O schema completo tem 12 modelos e mantém três grupos:

• Conteúdo científico versionado: Campaign, Level, Dataset, Evidence.
• Atividade pseudônima e suas evidências: Player, Session, Project, Run, Prediction, Decision, Reflection.
• Projeção derivada: LearningProgress.

Uma revisão de Project é um snapshot imutável da configuração. Run mantém entrada, resultado e replay canônicos, mais versões e hashes. O campo contentId conserva a identidade numérica atual; clientRunKey distingue tentativas e torna retries idempotentes. Os valores SQL em Decimal/BigInt servem para consulta; o texto canônico mantém a autoridade do replay. Ver mapeamento e invariantes.

O futuro serviço resolveria owner pelo contexto autenticado e sempre filtraria Project → Session → Player. UUIDs e hashes não são credenciais. RLS é uma camada adicional a implementar em SQL e testar; não é criada automaticamente pelo Prisma. O frontend jamais recebe URL de banco ou uma chave privilegiada.

Os registros de jogador não possuem nome civil, e-mail, idade, escola, IP ou localização. Texto livre continua local por padrão. A proposta técnica de retenção é explícita, com expiração e expurgo a implementar. Não há serviço de analytics ou coleta infantil adicional necessário para executar o beta.

8. Decisões arquiteturais

9. Publicação e gates de evolução

O caminho de distribuição é repositório → verificações → build estático → hospedagem HTTP(S). A Vercel é um destino de publicação previsto para dist/; o endereço, commit implantado e estado do deploy pertencem ao recibo de entrega da coordenação. O build também gera a documentação pública de pesquisa. GitHub guarda a origem versionada; as URLs só devem ser anunciadas como publicadas depois de confirmação real.

Antes de declarar beta distribuível, passar testes de domínio, fluxo e build, verificar os quatro níveis com resultados do motor real, conferir fontes no artefato e executar QA de navegador do fluxo principal. Evidência jsdom não valida WebGL, foco real, leitor de tela, persistência durável ou recarga offline. Esses itens devem ter estado próprio no handoff.

Antes de ativar cloud, exigir: client gerado e compilado, migração revisada em banco descartável, autenticação/ownership, idempotência e conflitos, validação/reexecução de entradas, exclusão por retenção e teste de restauro. Nenhum desses gates é satisfeito apenas pela presença ou validação sintática do schema.

Os diagramas fonte e renderizáveis estão em FLOWCHARTS. Os requisitos verificáveis estão no PRT, e o PRD descreve os resultados de produto esperados.

Flowcharts e modelos — PROJETO IPÊ

Diagramas Mermaid de referência para o beta e sua evolução. As fontes .mmd em diagrams/ são editáveis e correspondem aos blocos abaixo. Layout vertical, labels curtas e diagramas separados mantêm a leitura compacta.

Implementado/local e proposto/cloud são contextos diferentes. A ciência continua exigindo 6/6 registros válidos e todas as restrições; os níveis acrescentam gates sem modificar o motor.

1. Jornada do jogador

O ciclo principal é prever, executar, investigar e redesenhar. O resultado científico e o critério adicional do nível recebem avaliações separadas. Os quatro níveis e seus critérios estão no PRT.

Fonte: 01-user-flow.mmd.

flowchart TD
  Start["Abrir Missão Ipê"] --> Levels["Escolher nível disponível"]
  Levels --> Brief["Ler objetivo e limites"]
  Brief --> Design["Configurar seis subsistemas"]
  Design --> Predict["Registrar previsão e justificativa"]
  Predict --> Run["Executar projeto congelado"]
  Run --> Report["Investigar resultado e eventos"]
  Report --> Science{"Motor indica sucesso?"}
  Science -->|"Falha ou inválido"| Explain["Explicar causa e redesenhar"]
  Explain --> Design
  Science -->|"Sim, com 6/6"| Gate{"Critério do nível atendido?"}
  Gate -->|"Não"| Explain
  Gate -->|"Sim"| Reflect["Registrar reflexão opcional"]
  Reflect --> Next{"Há outro nível?"}
  Next -->|"Sim"| Levels
  Next -->|"Não"| Finish["Revisar a campanha"]
  Report --> Export["Exportar replay ou comparar"]
  Start --> Lab["Explorar laboratório independente"]

2. Estados de uma tentativa

Este é o contrato conceitual da coordenação. As labels descrevem estados de produto; não afirmam existir um reducer ou enum com esses nomes no código. Falha do motor, invalidade do projeto e objetivo pedagógico pendente permanecem distintos.

Fonte: 02-game-state.mmd.

stateDiagram-v2
  direction TB
  [*] --> Briefing
  Briefing --> Editing: entrar no hangar
  Editing --> Ready: previsão e justificativa válidas
  Ready --> Editing: alterar projeto ou cenário
  Ready --> Running: congelar entrada e executar
  Running --> Editing: cancelar e descartar resposta pendente
  Running --> Error: erro de execução
  Error --> Editing: revisar ou tentar novamente
  Running --> Result: receber e validar resultado
  Result --> Failed: outcome failure
  Result --> Invalid: outcome invalid
  Result --> Successful: outcome success
  Failed --> Editing: redesenhar
  Invalid --> Editing: corrigir envelope
  Successful --> LevelPending: critério adicional não atendido
  Successful --> LevelComplete: tentativa própria e critério atendido
  LevelPending --> Editing: revisar projeto
  LevelComplete --> Editing: próximo nível ou nova tentativa
  LevelComplete --> [*]

  state "Projeto editável" as Editing
  state "Pronto para executar" as Ready
  state "Execução em andamento" as Running
  state "Resultado imutável" as Result
  state "Falha científica" as Failed
  state "Projeto inválido" as Invalid
  state "Sucesso científico" as Successful
  state "Objetivo do nível pendente" as LevelPending
  state "Nível concluído" as LevelComplete
  state "Erro recuperável" as Error

3. Dados, simulação e replay

A entrada original e a importada convergem no mesmo motor. O parser e a checagem de identidade antecedem o recálculo. Comparar a alegação importada nunca substitui o resultado recalculado. A figura resume dados científicos e snapshots; o diário pedagógico separado continua em armazenamento local.

Fonte: 03-data-flow.mmd.

flowchart TD
  subgraph Scientific["Arquivo científico histórico"]
    Sources["Respostas, recibos e metadados"] --> Pack["Seis registros e hash do pacote"]
  end
  subgraph Browser["Execução local no navegador"]
    Choices["Configuração e cenário"] --> Frozen["Entrada congelada e validada"]
    Frozen --> Engine["Motor determinístico"]
    Engine --> Result["Resultado completo e validado"]
    Result --> Report["Relatório e gate do nível"]
    Result --> Canonical["JSON canônico e hashes"]
    Canonical --> Store["IndexedDB: snapshot imutável"]
    Canonical --> Export["Replay exportado"]
    Imported["Replay importado"] --> Parser["Parser estrito e limites"]
    Parser --> Identity["Conferir versões e hashes"]
    Identity --> Engine
    Result --> Compare["Comparar com alegação importada"]
    Identity --> Compare
  end
  Pack --> Engine

4. Distribuição e evolução opcional

O bloco superior mostra o caminho técnico da entrega estática para GitHub/Vercel. Ele não é recibo de publicação: URL e commit implantado devem ser conferidos no handoff. O bloco inferior é proposto e ainda não implementado; o beta não envia dados a essa API nem se conecta a PostgreSQL.

Fonte: 04-deployment.mmd.

flowchart TD
  subgraph Delivery["Distribuição do beta estático"]
    Repo["Repositório GitHub"] --> Checks["Testes de domínio e UI"]
    Checks --> Build["TypeScript e Vite build"]
    Assets["Dados e documentação pública"] --> Build
    Build --> Dist["dist com assets preservados"]
    Dist --> Host["Hospedagem estática Vercel"]
    Host --> Browser["Navegador: UI, Worker e motor"]
    Browser --> Local["IndexedDB, diário e progresso local"]
  end
  subgraph Future["Proposta futura: cloud opcional"]
    Api["API com autenticação e owner"] --> Validate["Validar, recalcular e deduplicar"]
    Validate --> Prisma["Prisma 7.10.1 no servidor"]
    Prisma --> Db["PostgreSQL com políticas testadas"]
    Retention["Expurgo por retenção"] --> Db
  end
  Browser -.->|"Sync opcional ainda não implementado"| Api

5. Modelo de conteúdo e proveniência

Modelo cloud proposto. Cada nível fixa uma revisão de campanha e um dataset. Dataset referencia evidências com URL, datas e identidade dos arquivos preservados. Os campos mostrados são um recorte; o schema Prisma contém tipos e constraints completos.

Fonte: 05-er-content.mmd.

erDiagram
  direction TB
  Campaign ||--o{ Level : contains
  Dataset ||--o{ Level : pins
  Dataset ||--o{ Evidence : documents

  Campaign {
    uuid id PK
    string slug
    int version
    string contentHash
  }
  Level {
    uuid id PK
    uuid campaignId FK
    uuid datasetId FK
    string key
    int version
    string scenarioId
    json criterionSnapshot
  }
  Dataset {
    uuid id PK
    string key
    int version
    string packHash UK
    json manifest
  }
  Evidence {
    uuid id PK
    uuid datasetId FK
    string sourceUrl
    string contentHash
    datetime retrievedAt
  }

6. Modelo de atividade pseudônima

Modelo cloud proposto. O proprietário é derivado de Project → Session → Player. Run também referencia Dataset; Session referencia Campaign e Project/LearningProgress referenciam Level, mostrados no diagrama anterior. As relações opcionais não dispensam autorização e validação semântica no servidor.

Fonte: 06-er-player.mmd.

erDiagram
  direction TB
  Player ||--o{ Session : owns
  Session ||--o{ Project : freezes
  Project ||--o{ Prediction : records
  Project ||--o{ Run : executes
  Project ||--o{ Decision : logs
  Prediction o|--o| Run : precedes
  Run o|--o{ Decision : supports
  Run ||--o{ Reflection : inspires
  Player ||--o{ LearningProgress : has
  Run o|--o{ LearningProgress : supports

  Player {
    uuid id PK
    string pseudonym
    datetime expiresAt
  }
  Session {
    uuid id PK
    uuid playerId FK
    uuid campaignId FK
  }
  Project {
    uuid id PK
    uuid sessionId FK
    uuid levelId FK
    int version
    json configSnapshot
  }
  Run {
    uuid id PK
    uuid projectId FK
    string contentId
    string inputHash
    string resultHash
    string replayHash
  }
  Prediction {
    uuid id PK
    uuid projectId FK
    string target
  }
  Decision {
    uuid id PK
    uuid projectId FK
    uuid runId FK
    string kind
  }
  Reflection {
    uuid id PK
    uuid runId FK
    string eventId
  }
  LearningProgress {
    uuid id PK
    uuid playerId FK
    uuid levelId FK
    uuid supportingRunId FK
    string status
  }

Como manter os diagramas

Ao mudar um contrato, editar a fonte .mmd correspondente e atualizar o bloco deste documento com o mesmo conteúdo. A sintaxe pode ser verificada com um parser Mermaid; renderizar também é necessário para conferir legibilidade. Uma figura não substitui os testes dos fluxos representados.

Verificação executada em 14/11/2026: os seis arquivos passaram por mermaid.parse com Mermaid 11.14.0; os seis blocos deste documento foram comparados com suas fontes e são idênticos. A tentativa de QA visual via Chromium local foi bloqueada pelo ambiente antes de abrir o navegador (socket: Operation not permitted). Portanto, esta verificação comprova sintaxe aceita pelo parser, sem alegar inspeção visual dos gráficos renderizados. A sintaxe segue as referências oficiais de uso da API e relações entre entidades.

A distinção entre snapshot, tentativa e progresso, a idempotência e os controles ainda pendentes estão no README Prisma. As decisões de implementação estão em ARQUITETURA e os critérios de aceite em PRT.

Persistência cloud opcional — Missão Ipê

O schema Prisma descreve uma evolução possível de armazenamento. O beta usa IndexedDB e localStorage; não usa Prisma, PostgreSQL, autenticação, API de sincronização ou RLS. Nenhum banco foi provisionado, nenhuma migração foi aplicada e este diretório não é importado pelo frontend.

Referência técnica: Prisma ORM 7.10.1, PostgreSQL e Node.js 24. Consulta oficial em 14/11/2026. A documentação já distingue Prisma 8 RC de Prisma 7; por isso os comandos fixam a versão e não usam @latest. A escolha mantém esta proposta no formato de schema estável da linha 7, sem migrar a aplicação para outro runtime.

Validar sem banco

Na raiz do projeto, com Node 24 e acesso ao registro npm:

npm exec --yes --package=prisma@7.10.1 -- prisma validate --schema ./prisma/schema.prisma

Esse comando valida a linguagem e as relações do schema; não cria tabelas nem testa autorização, migração, exclusão, desempenho ou compatibilidade de um cliente gerado com TypeScript 7. O ambiente de verificação pode instalar o CLI em uma pasta temporária para manter o package.json do beta intacto. Não é necessário fornecer uma conexão para essa validação.

Verificação executada em 14/11/2026: prisma format e prisma validate, usando CLI 7.10.1 isolado e Node 24.22.1, terminaram com código 0; o validador confirmou o schema como válido. Os 12 modelos foram conferidos. Nenhum comando de conexão ou migração foi executado.

O gerador usa provider = "prisma-client", saída explícita em server/generated/prisma e ESM. No Prisma 7, a URL de conexão pertence à configuração do CLI, fora do schema. O client gerado e seu driver adapter pertencem exclusivamente a um serviço de servidor futuro.

Doze modelos e suas responsabilidades

Project → Session → Player define o proprietário. As relações compostas entre Project, Session e Level impedem ligar uma sessão a um nível de outra revisão de campanha. As relações compostas de Run/Prediction e Decision/Run impedem ligar esses registros a projetos diferentes. A pertença de LearningProgress.supportingRun ao mesmo jogador e nível ainda deve ser validada pelo serviço: um simples FK não expressa essa regra transitiva.

O manifesto em Campaign.content deve fixar a lista ordenada de IDs/versões dos níveis. A execução consulta esse manifesto; não escolhe a revisão mais recente implicitamente. Publicar a campanha também congela esse conjunto. Alterar um nível publicado exige nova revisão de conteúdo e campanha, sem mudar o significado de tentativas já registradas.

Relação com o beta local

O armazenamento local atual deduplica snapshots iguais por identidade de entrada e resultado. O modelo cloud distingue conteúdo de ocorrência: dois Run podem ter o mesmo contentId quando representam tentativas diferentes. projectId + clientRunKey torna o retry da mesma tentativa idempotente. A migração de um snapshot local deve usar LOCAL_ARCHIVE; não deve inventar quantas tentativas o produziram.

Identidade, replay e imutabilidade

O contrato existente é preservado:

• inputHash: SHA-256 de { kind: "mission-ipe-input-v1", ...IDENTITY_VERSIONS, input } usando ipe-json-v1.
• resultHash: SHA-256 de { kind: "mission-ipe-result-v1", ...IDENTITY_VERSIONS, result } pela mesma canonicalização.
• contentId: run- seguido do SHA-256 canônico de { kind: "mission-ipe-run-v1", inputHash, resultHash }.
• replayHash: campo novo da proposta cloud; SHA-256 dos bytes UTF-8 do replay canônico completo, sem acrescentar um hash autorreferente ao envelope v1.
• configHash: campo novo de Project; SHA-256 canônico de { kind: "mission-ipe-project-config-v1", scenarioId, config }. A configuração continua validada contra a versão de catálogo fixada no nível.

O hash detecta alteração de conteúdo; não prova identidade do jogador, autoria, sequência de pensamento ou autenticidade institucional. recordedAt é o horário informado pelo cliente. receivedAt/verifiedAt são horários do servidor proposto. Uma importação offline não recebe retrospectivamente uma garantia de previsão registrada antes da tentativa.

O schema fornece tipos, chaves e relações. Ele não impõe imutabilidade sozinho. Antes de usar o modelo em produção, o serviço deve permitir apenas inserção em Project, Run, Prediction, Decision e Reflection; uma migração revisada deve acrescentar proteção contra UPDATE nesses dados e nas revisões publicadas de conteúdo. Exclusão por retenção ou pelo titular permanece possível por um caminho específico. LearningProgress é a exceção mutável: projeção reconstruível com controle de revisão, sem alterar as evidências originais.

Unidades e precisão

resultCanonical permanece a autoridade numérica do replay. As projeções SQL não devem ser serializadas de volta para reconstruir o hash. Para o motor 0.1.1-rd, a ingestão mantém o limite de inteiro seguro dos contratos existentes, mesmo que PostgreSQL aceite um BigInt maior. Toda conversão parte de strings decimais validadas.

Invariantes que ainda exigem implementação

Antes de autorizar qualquer escrita cloud:

1. Validar UUIDs, hashes hexadecimais de 64 posições, números não negativos, versões positivas e payloads fechados. Char(64) sozinho não verifica um hash.
2. Conferir scenarioId, as seis escolhas e as versões de motor, catálogo, schema, canonicalização e dataset. Conferir igualdade entre a configuração do projeto, a entrada e o resultado recalculado.
3. Validar o replay com limite de 1 MiB, profundidade 20, rejeição de chaves duplicadas e proibidas, números não finitos e campos desconhecidos; nenhuma URL importada é buscada ou executada.
4. Reexecutar o motor compatível. Somente o resultado recalculado é canônico. Divergência da alegação produz diagnóstico explícito, sem salvar a alegação como verificada.
5. Exigir previsão anterior para OWN_EXECUTION; REPLAY_IMPORT e LOCAL_ARCHIVE não completam critérios que exigem tentativa própria. O vínculo não prova participação humana nem aprendizagem.
6. Conferir conservação de bits e demais invariantes do motor. SUCCESS exige outcome === "success", seis registros completos e válidos e todas as restrições; o banco não redefine essa lógica.
7. Conferir se Reflection.eventId existe no resultado referido e se a evidência usada em LearningProgress pertence ao mesmo jogador, nível e revisão de regra.
8. Acrescentar CHECKs SQL para intervalos, não negatividade e condição PRESERVED → assetPath/contentHash/byteLength; testar a exclusão em cascata de toda a árvore de um jogador.

Protocolo de sincronização proposto

Não há endpoint implementado. O fluxo de uma API futura é:

1. Autenticar o contexto da sessão e resolver playerId no servidor. Não confiar em um owner enviado no JSON.
2. Validar o lote fora da transação, limitar tamanho/tempo e recalcular resultados com as versões permitidas.
3. Em uma transação, resolver a sessão e o projeto versionado; inserir os registros por suas chaves client*Key.
4. Se a chave já existir, comparar o conteúdo canônico: igual retorna o mesmo recibo; diferente retorna conflito. Não usar upsert para sobrescrever um replay imutável.
5. Recalcular LearningProgress sem contar novamente o retry; aplicar comparação de revision para concorrência.
6. Confirmar somente após commit. Falha de rede mantém os dados locais e o estado pendente; a campanha permanece executável.

O conjunto de chaves resolve repetição, não autorização. A consulta e a mutação sempre devem carregar a condição de owner em Session.playerId. RLS seria defesa adicional, com SQL próprio, políticas testadas e identidade de sessão transacional; não é criada por este schema. Um client Prisma conectado com função privilegiada não fornece isolamento por jogador automaticamente. Credenciais de banco ficam exclusivamente no servidor, nunca em variáveis VITE_* ou no bundle.

Minimização e retenção

O beta não pede nome, e-mail, idade, escola ou localização do jogador. Seu texto de previsão/reflexão fica no navegador. Um pseudônimo e UUID aleatórios ainda podem constituir dados vinculáveis; não são chamados de anonimização.

Na proposta cloud, textos livres são opcionais e omitidos na sincronização padrão. Eles podem conter dados pessoais espontaneamente digitados; o contrato não presume que estejam anonimizados. payload de decisão deve aceitar somente escolhas, IDs de regras/eventos e medidas previstas no DTO, sem cópia de texto livre, IP ou user agent.

Política técnica proposta para um piloto: 30 dias desde a criação da identidade, com Player.expiresAt explícito; sessões e progresso expiram no máximo nessa data. Um job de expurgo ainda precisa ser implementado e testado; expiresAt não é TTL automático. A exclusão do jogador elimina sessões, projetos, tentativas e escritos associados; pacotes científicos e conteúdo editorial compartilhado permanecem. Não há coleta infantil adicional para viabilizar o beta. Qualquer pesquisa educacional com contas ou grupos requer protocolo próprio antes de ativar essa camada.

No beta local, não há expurgo agendado: a disponibilidade depende do navegador e de limpeza/exclusão local. Não transportar essa característica silenciosamente para a futura retenção cloud.

Configuração futura, fora do build do beta

Somente quando a API for implementada em um pacote/branch de servidor, ela precisará do CLI, @prisma/client@7.10.1, adapter PostgreSQL compatível e driver pg, com lockfile próprio. A configuração abaixo é uma referência, não um arquivo ativo deste repositório:

// prisma.config.ts — criar apenas no pacote de servidor futuro.
import { defineConfig } from 'prisma/config';

export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations' },
  datasource: { url: process.env.DATABASE_URL },
});

O ambiente deve fornecer DATABASE_URL; Prisma 7 não carrega .env implicitamente. O serviço usará PrismaPg e new PrismaClient({ adapter }). Antes de integrar: gerar o client, compilar com TypeScript 7.0.2/Node 24, revisar a migração em banco descartável, testar ownership, concorrência, idempotência e expurgo. A compatibilidade mínima documentada de TypeScript não substitui esse teste concreto do client gerado.

Referências oficiais

Consultadas em 14/11/2026:

• Release Prisma ORM 7.10.1: versão fixada e correções da linha 7.
• Prisma 7: caminhos de instalação: distinção da linha estável em relação ao Prisma 8 RC.
• Geradores Prisma 7: prisma-client, saída explícita e ESM.
• Referência de configuração: conexão fora do schema e carregamento de variáveis.
• Introdução ao client: adapter de banco obrigatório na linha 7.
• Requisitos de sistema: Node ^24.0.0 e TypeScript 5.4+.
• Modelos e relações: tipos e restrições do schema.

Arquitetura, requisitos e diagramas estão em ARQUITETURA, PRT e FLOWCHARTS.

PROJETO-IPÊ — handoff do beta

Referência da entrega: 14/11/2026, beta 0.5.0-beta.1. Direção de produto: AB / Alexandre Belo. Desenvolvimento, pesquisa e documentação com assistência de IA. Este documento permite retomar a implementação, demonstrar o produto e preparar o próximo ciclo sem confundir o beta funcional com o roadmap.

1. O que está sendo entregue

O PROJETO-IPÊ é um jogo educativo de projeto de missão. A pessoa escolhe seis subsistemas de um CubeSat fictício, registra uma previsão, executa o modelo e investiga a entrega de seis registros científicos históricos. Uma campanha de quatro níveis acrescenta pedidos de engenharia sobre o motor existente.

Fronteira do beta: execução e persistência no navegador, sem conta obrigatória, sem API NASA durante a partida e sem LLM calculando os resultados. Testes automatizados verificam contratos de software. Ainda não existe evidência própria de aprendizagem, estudo com participantes, endosso NASA/NN/g ou validação de engenharia de voo.

2. Início em uma máquina nova

Requisitos: Git, Node.js 24 ou superior, npm e acesso ao registro de pacotes ou cache completo. Usar as versões fixadas pelo lockfile. Não substituir por npm update durante uma reprodução da entrega.

git clone https://github.com/oalexandrebelo/PROJETO-IPE.git
cd PROJETO-IPE
npm ci
npm run verify
npm run dev

O Vite informa a URL de desenvolvimento. Para testar o artefato de distribuição, executar:

npm run build
npm run preview

A aplicação visitante não requer variáveis de ambiente. Prisma pertence ao planejamento de um serviço futuro. Uma credencial nunca deve entrar em VITE_*, no HTML público ou em um replay.

3. Estrutura para manutenção

4. Contratos que precisam sobreviver ao próximo ciclo

Campanha e referência de demonstração

Todas as conclusões exigem uma tentativa própria vinculada ao nível. A reflexão é opcional e não recebe nota automática.

N2 e N3 começam em 2/6 por razões diferentes. No N2, lotes novos não cabem antes do contato e são perdidos. No N3, dados permanecem na fila porque as janelas terminam. Esse contraste é a principal demonstração de raciocínio causal. No N4, a operação já funciona e a necessidade muda para otimização. A sequência não promete aumento monotônico de dificuldade ou de número de trocas.

Progresso e ajuda

beginCampaignAttempt emite um token em memória após conferir nível disponível, cenário, configuração, previsão e justificativa. completeCampaignAttempt consome o token, confere o snapshot e recalcula o resultado antes de avaliar o nível. O token não pode ser reconstruído a partir de JSON, histórico ou replay. Editar um componente depois da execução não altera sua evidência.

O progresso restaurado valida versão, sequência, identificadores e configuração de cada conclusão, recalculando as testemunhas. Isso protege consistência local, mas não constitui um sistema antifraude ou uma avaliação institucional. Quem controla o dispositivo controla seu armazenamento.

searchCampaignCatalog avalia as 64 tuplas com o critério do nível. Uma opção que resolve apenas a operação, como ampliar a memória no N2, não pode ser anunciada como solução desse nível. Aplicar uma sugestão inicia um novo projeto e exige nova previsão e execução.

5. Persistência e recuperação

Não há transação única entre IndexedDB, diário e campanha. A disponibilidade e a durabilidade dependem do navegador. Armazenamento local também não equivale a anonimato garantido, sobretudo quando texto livre contém identificação.

Para investigar um problema, registrar versão/commit, navegador, origem, nível, configuração, cenário, mensagem e passos reproduzíveis. Compartilhar texto livre somente após revisar seu conteúdo. Limpeza total do armazenamento é uma ação destrutiva e não é o primeiro procedimento de suporte.

6. Runbook de demonstração

1. Abrir o beta e o mapa de apresentação em abas separadas. Conferir que o objetivo do N1, o contador de progresso e a URL estão visíveis.
2. Apresentar o pacote como histórico e o CubeSat como fictício. Distinguir os 180 minutos simulados da duração da sessão e das datas MODIS.
3. No N1, manter o preset, registrar uma previsão própria e executar. Mostrar 6/6, resultado operacional e conclusão do nível.
4. No N2, executar o preset compacto. Inspecionar perda de lote e o instante de 1.860 s. Comparar capacidade com volume antes do contato. Executar a solução de referência apenas depois de explicar sua hipótese.
5. No N3, observar que 2/6 corresponde a fila remanescente. Revisar taxa, potência e envelope antes da execução com bandas.
6. No N4, mostrar o preset 6/6 a 84 cr com condição pendente. Reduzir o custo a 78 ou 75, executar e explicar a folga conservada.
7. Abrir retorno científico e discutir um par recebido. Finalizar com uma afirmação descritiva e uma limitação da inferência.
8. Fechar no convite à pilotagem. Se houver falha de demonstração, o mapa e a galeria preservam explicação e evidência histórica, identificadas como tal.

Uma demonstração curta pode usar somente N1 e o contraste N2/N3 no mapa. Não chamar replay, screenshot ou solução aplicada de nova conquista. Testar o roteiro antes do encontro e não limpar o progresso de outra pessoa para encenar a primeira sessão.

7. Verificação e publicação

O beta integrado passou 120 testes de domínio e 14 testes UI, sem falhas. Os 120 incluem os 19 testes da campanha e os 101 testes anteriores. Os 14 UI incluem o percurso dos quatro níveis e a restauração. O schema de 12 modelos passou em Prisma 7.10.1 e os seis diagramas passaram no parser Mermaid 11.14.0. Os detalhes estão no QA do beta 0.5, no README e em evidence/. Uma publicação posterior precisa preservar a associação entre esses recibos e o commit entregue.

A inspeção local de navegador desta rodada foi bloqueada pela política de URL do ambiente de QA. As capturas R9/R10 são históricas e não comprovam a nova campanha. Testes DOM, validação de schema e parsing de Mermaid têm alcances próprios. A observação da URL publicada deve ser registrada separadamente quando realizada.

A aplicação isolada gera um site Vite com npm run build e saída dist/, sob Node 24. A aplicação depende de HTTP(S) e caminhos de assets preservados. Conferir /, /apresentacao/, /research/, /research/galeria.html, /kit/schema.prisma e as fontes Mermaid expostas em /kit/diagrams/. Na distribuição pública, o código está em experiments/four-level-campaign/ e esses caminhos recebem o prefixo /campanha. O build raiz preserva o R14 e copia o dist/ da campanha para site/campanha/. O recibo de publicação registra o commit e o estado remoto verificado.

Em regressão de publicação, preservar a evidência, identificar o último commit e deployment estáveis e usar a reversão da hospedagem para essa revisão. Depois reproduzir o defeito localmente e publicar correção verificada. Uma troca de URL pode mudar o armazenamento local percebido pelo jogador. Não prometer migração automática entre origens.

8. Decisões consolidadas

• A autoridade do resultado permanece no motor puro. Interface, roteiro, 3D e campanha não ajustam o resultado para favorecer a narrativa.
• A progressão usa necessidades diferentes sobre um catálogo fechado. O mesmo projeto pode funcionar fisicamente e não atender ao pedido atual.
• Dados reais possuem procedência e limites. Operação da nave, agenda, massas e créditos são didáticos.
• A busca revela alternativas elegíveis e explicita o domínio avaliado. Ajuda não penaliza a pessoa.
• O laboratório físico permanece separado. Transformar seus controles em parâmetros de missão exige outro contrato e revisão numérica.
• O beta visitante funciona sem conta. PostgreSQL/Prisma é uma possibilidade de evolução, sem coleta remota ativa.
• Acessibilidade orienta o DOM, o mapa e o fallback. Conformidade WCAG completa requer auditoria própria.
• Previsão e reflexão apoiam a atividade. A conclusão de quatro níveis demonstra cumprimento dos desafios, sem certificar aprendizagem.

9. Próximos trabalhos e decisão de aceite

Não há prazo, adoção, parceiro institucional ou ganho de aprendizagem confirmado a registrar. O próximo compromisso proposto é uma pilotagem observada que permita decidir o que ajustar antes de expandir a complexidade.

10. Fontes e direitos

A origem do código e as licenças permanecem em LICENSE, NOTICE e licenses/. A marca do projeto não usa logotipos NASA ou NN/g como selo. Os personagens são fictícios. As fontes científicas e de design orientam decisões autorais e não estabelecem parceria.

Para a rastreabilidade de produto e ciência, consultar insights, R10 e PITCH. Para alterar o modelo, começar pelo contrato de implementação, não pela narrativa ou pelo material de apresentação.

PROJETO-IPÊ — pitch e roteiro de estudo

Referência: 14/11/2026. Direção: AB / Alexandre Belo. Pesquisa, redação e construção com assistência de IA. Público desta apresentação: avaliadores de produto, educadores e colaboradores técnicos. O convite é testar um beta educativo e organizar uma pilotagem futura.

Abra o mapa interativo para apresentar ou baixe o deck de dez slides editáveis, com notas de orador e fontes. O handoff concentra instalação, contratos e operação. As falas abaixo são textos autorais para ensaio. Os tempos são aproximados e devem ser ajustados à velocidade do apresentador.

1. A frase que organiza a conversa

O PROJETO-IPÊ permite projetar uma missão fictícia e explicar, com evidências, por que a ciência chegou ao solo.

O nome da marca é PROJETO-IPÊ. “Ciência que chega” descreve o objetivo. NASA Space Mission Design é o contexto temático e de referências consultadas. Não é uma afiliação, um selo de aprovação ou uma afirmação de elegibilidade em edital.

2. Pitch de 30 segundos

O PROJETO-IPÊ é um jogo educativo de projeto de missão espacial. Em quatro níveis, a pessoa monta um CubeSat fictício e tenta entregar seis registros históricos do Cerrado. Cada escolha muda memória, potência, transmissão ou custo. Ela prevê, executa e usa os eventos para redesenhar. O beta já permite experimentar essas relações no navegador. O próximo passo é observar estudantes e educadores usando o jogo e investigar o que conseguem explicar e transferir para um novo desafio.

Ênfase no ensaio: dar uma pausa após “seis registros”. Terminar no convite à observação, sem transformar a existência do software em uma promessa de eficácia.

3. Pitch de 90 segundos

O PROJETO-IPÊ começa com uma pergunta: de que adianta produzir ciência se os dados não chegam a quem precisa deles?

É um jogo educativo de projeto de missão espacial. A pessoa configura seis sistemas de um CubeSat fictício para entregar seis registros históricos Terra/MODIS, de três pontos próximos a Rio Verde. Antes de executar, registra uma previsão. Depois, o relatório mostra o que aconteceu com energia, potência, memória e comunicação.

A campanha tem quatro pedidos. Primeiro, acompanhar uma entrega completa. Depois, manter uma memória menor. No terceiro, preservar as bandas em contatos curtos. No último, entregar tudo por até 78 créditos. Uma missão pode funcionar e ainda não atender ao pedido do nível. Essa diferença torna visível o trabalho de engenharia.

O motor é determinístico e mantém 64 configurações verificáveis. O 3D apresenta a nave, enquanto as decisões e resultados ficam acessíveis pela interface. Dados e fontes estão preservados. A persistência do beta é local, sem exigir conta.

Temos um produto que pode ser experimentado. Ainda precisamos avaliar compreensão e usabilidade com pessoas. O convite é organizar uma pilotagem com educadores e iniciantes, observar suas explicações e usar essa evidência para decidir o próximo ciclo.

4. Pitch de três minutos

Imagine que uma equipe precisa comparar dois períodos de vegetação em três pontos do Cerrado. Os registros científicos já existem, mas neste exercício você precisa projetar como eles chegam ao solo. Uma bateria maior resolve tudo? Um rádio mais rápido basta? E uma entrega de seis registros sempre cumpre o pedido?

Essas perguntas organizam o PROJETO-IPÊ, um jogo educativo de projeto de missão espacial. A pessoa escolhe bateria, painel, processamento, rádio, memória e política de transmissão de um CubeSat fictício. Registra uma previsão, executa o modelo e examina os eventos antes de redesenhar.

A campanha tem quatro níveis. O primeiro acompanha uma entrega que já funciona. O segundo mantém a memória em 512 Mbit. Nesse preset, parte dos lotes se perde antes do contato. Reduzir o volume por processamento ajuda, mas exige suportar a potência dessa operação. O terceiro também começa com dois de seis registros, por outra razão: as janelas curtas terminam com dados na fila. Como o pedido exige bandas, o jogador precisa rever comunicação, alimentação e envelope. O quarto começa entregando tudo por 84 créditos. A meta passa a ser entregar por até 78. A operação está concluída, mas o objetivo de projeto continua pendente.

Esse contraste é o centro da proposta: interpretar uma consequência e defender a próxima escolha. O motor é determinístico, com 64 projetos e regras explícitas. Um resultado 6/6 só vale como sucesso quando todas as restrições são atendidas. A cena 3D é conceitual. A informação essencial permanece na interface e existe alternativa 2D.

O contexto científico usa seis registros históricos Terra/MODIS, com procedência, qualidade e datas preservadas. Só comparamos NDVI quando os dois registros de um ponto chegam completos e válidos. Uma diferença não autoriza diagnosticar sua causa ambiental. Essa limitação também faz parte da atividade.

Referências da NASA ajudam a relacionar necessidade, operação e evidência. Princípios de usabilidade orientam feedback e recuperação. São bases para nossas decisões, sem transferir validação institucional ao projeto.

O beta pode ser experimentado no navegador. Tem documentação de produto, requisitos técnicos, diagramas e um desenho de dados para evolução. Hoje o progresso fica no dispositivo. Ainda não realizamos um estudo de aprendizagem com participantes.

Por isso, o próximo passo é uma pilotagem observada com educadores e iniciantes. Queremos saber se a pessoa diferencia perda de memória de fila de transmissão, se usa evidência para justificar uma mudança e se aplica o raciocínio em uma situação nova. O convite é colaborar nessa investigação e melhorar o produto a partir do que as pessoas realmente fizerem.

5. Roteiro de dez slides

O roteiro completo comporta uma conversa de aproximadamente seis a oito minutos, com tempo separado para demonstração e perguntas. O mapa agrupa os slides em sete capítulos para facilitar estudo e navegação. As notas orientam a fala e não precisam ser lidas integralmente.

Slide 1 — PROJETO-IPÊ

Na tela: “Ciência que chega” e “Um jogo educativo de projeto de missão espacial”. Captura do produto, identificada como versão de referência quando anterior à campanha atual.

Fala: “O objetivo é entender como uma escolha de projeto muda a entrega científica. A nave é fictícia e os seis registros são históricos. O jogo permite experimentar essa relação e examinar o resultado.”

Nota de orador: apresentar autoria de AB e assistência de IA no crédito. Evitar começar pela lista de tecnologias. A pergunta de abertura pode ser “O que precisa acontecer entre produzir um dado e conseguir usá-lo?”.

Evidência: PRD, galeria. Mapa: Pesquisa.

Slide 2 — A necessidade de compreensão

Na tela: “Escolher uma peça exige entender sua consequência.” Uma pergunta de projeto e o ciclo prever, executar, investigar e redesenhar.

Fala: “Nossa hipótese é que observar energia, fila e entrega ajuda iniciantes a conectar escolhas ao sistema. Não fizemos entrevistas ou testes pedagógicos próprios para afirmar a frequência desse problema. O beta torna essa hipótese investigável.”

Nota de orador: explicar W versus Wh com um exemplo verbal breve se a audiência pedir. Deixar a física detalhada para a demonstração. O problema proposto é a compreensão das relações, não falta de um satélite visualmente atraente.

Evidência: PRD, hipóteses H-01 a H-05. Mapa: Problema.

Slide 3 — Pesquisa que orienta escolhas

Na tela: necessidade e operação; afirmação e evidência; estado e recuperação. Três relações específicas com suas fontes, sem logotipos de endosso.

Fala: “O ConOps da NASA orienta começar pela necessidade e pela operação. My NASA Data articula afirmações, evidências e raciocínio. As heurísticas de Nielsen ajudam a revisar visibilidade de estado, linguagem e recuperação. Nós traduzimos essas referências em decisões do produto.”

Nota de orador: citar brevemente as fontes [S1–S3]. Distinguir a recomendação externa da hipótese autoral. Referência não é prova de que o jogo funciona para seu público.

Evidência: registro de fontes ao final. Mapa: Pesquisa.

Slide 4 — Quatro pedidos de missão

Na tela: 1 Primeiro sinal; 2 Memória em disputa; 3 Janela estreita; 4 Ciência que chega. Condição mensurável de cada nível.

Fala: “Todos exigem seis registros completos e válidos. O pedido muda: compreender o fluxo, manter 512 Mbit, preservar bandas em contatos curtos e reduzir o custo a 78 créditos. Os personagens são fictícios e cada briefing explica o que está sendo solicitado.”

Nota de orador: não descrever progressão como “cada vez mais trocas”. O N4 pode ser resolvido com uma troca de painel a partir do preset. A dificuldade proposta vem da decisão autônoma e da explicação, ainda a investigar com público.

Evidência: storytelling. Mapa: Quatro níveis.

Slide 5 — Dois resultados iguais, causas diferentes

Na tela: N2: 2/6, 720 Mbit perdidos. N3: 2/6, 619,2 Mbit na fila. Cenário e condição distintos aparecem junto dos valores.

Fala: “Olhar somente o placar esconde o problema. No N2, lotes novos não cabem antes do primeiro contato. No N3, os lotes cabem, mas o tempo de comunicação termina. O relatório precisa permitir localizar a evidência que explica a diferença.”

Nota de orador: revelar soluções apenas se isso ajudar a audiência. O processamento para índice usado no N2 não atende ao pedido de bandas do N3. O conhecimento que deve ser transportado é a forma de investigar, não uma configuração universal.

Evidência: presets executados no motor e tests/campaign.test.mts. Mapa: seletor N2/N3 em Quatro níveis.

Slide 6 — Motor e ciência

Na tela: 64 configurações; 6/6 com restrições; dois cenários. Dados históricos e tempo simulado identificados separadamente.

Fala: “O motor calcula os recursos e entrega um resultado reproduzível. A animação apresenta esse resultado. O retorno científico usa apenas os registros completos e válidos recebidos. O pacote contém dois períodos em três pontos. A diferença de NDVI descreve esses pares, sem determinar uma causa ambiental.”

Nota de orador: “determinístico” significa que a mesma entrada e versão produzem o resultado previsto pelo código. Não significa exatidão de um satélite real. O catálogo utiliza valores didáticos e não propaga uma órbita operacional.

Evidência: contrato, guia MOD13 [S4]. Mapa: Motor.

Slide 7 — Arquitetura do beta

Na tela: React/TypeScript; motor puro; Worker; IndexedDB/localStorage. Prisma/PostgreSQL em uma área explicitamente chamada “proposta futura”.

Fala: “O núcleo funciona no navegador. O 3D está separado da regra do jogo e há alternativa 2D. A persistência é local. Importações passam por validação e recálculo. O desenho Prisma documenta uma possível evolução, mas não há banco, conta ou sincronização de produção.”

Nota de orador: se a audiência for técnica, explicar snapshot, token de tentativa própria e recálculo. Se for pedagógica, resumir como preservação da relação entre a escolha feita e a evidência que a pessoa examina.

Evidência: arquitetura, Prisma. Mapa: Stack.

Slide 8 — Evidência disponível

Na tela: software, interação e aprendizagem como camadas distintas. Link para o recibo da versão publicada.

Fala: “Temos contratos testáveis e resultados de referência. Os testes automatizados cobrem regras e jornadas DOM. A inspeção de navegador tem seu próprio registro. Ainda não há estudo com participantes ou efeito de aprendizagem demonstrado. Essa distinção define o que podemos afirmar hoje.”

Nota de orador: o recibo integrado do beta 0.5 registra 120 testes de domínio e 14 UI. Os 120 já incluem os 19 da campanha. Conferir o README da revisão demonstrada antes de apresentar. A inspeção local do novo beta foi bloqueada pela política de URL do ambiente, e capturas R9/R10 continuam identificadas como históricas.

Evidência: PRT, handoff, README. Mapa: Evidência.

Slide 9 — Próximo ciclo de pesquisa

Na tela: compreender a causa; justificar uma mudança; transferir o raciocínio. Proposta de observação, sem resultados inventados.

Fala: “Queremos observar onde a pessoa se confunde, que evidência consulta e como explica o redesign. Uma tarefa nova ajudará a investigar transferência. Também precisamos testar linguagem, teclado, leitor de tela, zoom e aparelhos de menor capacidade.”

Nota de orador: número de participantes, escola, faixa etária e agenda ainda devem ser acordados. A primeira rodada é formativa e não sustenta estimativa ampla de efeito. Separar incidentes de interface, dúvidas conceituais e apoio do facilitador.

Evidência: insights, PRD. Mapa: Oportunidades.

Slide 10 — Convite à pilotagem

Na tela: “Vamos observar como as pessoas explicam suas decisões.” Link para beta e código.

Fala: “Buscamos educadores e colaboradores para revisar a atividade e organizar uma pilotagem. A decisão seguinte será baseada no que observarmos: ajustar instruções, evidências e apoio antes de ampliar o modelo. Podemos começar pelo beta, pelo protocolo e por uma conversa sobre o contexto de uso.”

Nota de orador: pedir uma ação concreta apropriada ao encontro: experimentar o N1, revisar o roteiro ou combinar uma sessão de planejamento. Não apresentar parceria como fechada, nem prometer resultado educacional antes do estudo.

Evidência: beta, GitHub. Mapa: Oportunidades.

6. Demonstração em até três minutos

O tempo depende da fluência da demonstração. Não correr com a interface nem pular a previsão fingindo uma tentativa própria. Para aprofundar o jogo completo, reservar outra sessão. Capturas e resultados de referência ajudam a explicar, mas devem ser identificados como registros.

7. Perguntas difíceis e respostas honestas

8. Plano de ensaio para AB

1. Memorizar a relação central: escolha, consequência, evidência e redesign. Explicar com palavras próprias em 30 segundos.
2. Ensaiar o contraste N2/N3 sem consultar números. Depois conferir os valores exatos no roteiro: 720 Mbit perdidos versus 619,2 Mbit em fila.
3. Explicar N4 em uma frase: “Já entrega seis registros por 84 créditos e agora precisa custar até 78”.
4. Praticar as distinções: W e Wh; produzido e entregue; operação e condição do nível; dado histórico e tempo simulado; conclusão e aprendizagem.
5. Fazer uma rodada de perguntas usando a tabela acima. Responder primeiro com o estado atual, depois com a próxima evidência necessária.
6. Abrir os links e demonstrar o N1 no navegador do encontro. Separar três minutos para a fala e três para a demonstração quando houver seis minutos totais.
7. Encerrar com uma ação concreta: experimentar, revisar a mediação ou combinar a preparação de uma pilotagem. Não fechar com promessa de resultado.

9. Fontes para estudar e citar

Fontes primárias abertas em 14/11/2026. As descrições abaixo são paráfrases. As decisões do PROJETO-IPÊ são interpretações autorais, não recomendações específicas dessas instituições para este produto.

Para números do jogo, usar o código, as testemunhas de teste e os documentos desta versão. Para estados de publicação, usar o recibo do deploy. Para resultados humanos, aguardar pesquisa efetivamente realizada.

Refinamento do jogo a partir das referências NASA

Rodada 10 · 14 de novembro de 2026 · Missão Ipê / Space Mission Design Game.

Nota editorial R17 · 15/11/2026: a orientação atual usa funções científicas assumidas pelo participante e registros reais Terra/MODIS, sem personagens ou equipes inventadas. O roteiro vigente está em Narrativa científica de quatro níveis. Essa atualização de apresentação preserva o contrato do motor e as evidências técnicas da Rodada 10; contatos, capacidades, créditos e duração continuam sendo parâmetros didáticos.

1. A oportunidade principal

As referências enviadas por AB reforçam um caminho de produto: cada escolha de engenharia precisa responder a uma necessidade da missão e produzir uma consequência verificável. Isso orienta a evolução do beta: explicitar para quem os dados servem, antecipar limites, verificar requisitos e mostrar o retorno científico realmente disponível.

Nossa interpretação de design é que essa cadeia ensina mais do que acrescentar componentes sem finalidade ou uma sequência longa de aprovações formais. A interface mantém a entrada rápida no jogo, com detalhes técnicos acessíveis quando ajudam a decidir. O contrato da campanha continua sendo entregar 6/6 registros completos e válidos, respeitando todas as demais restrições.

O Appendix S do Systems Engineering Handbook organiza objetivos, usuários, operadores, interfaces, modos e cenários nominais e fora do nominal. O currículo NTRS 20210021839 conecta conceito de operações, requisitos, alternativas, realização e verificação. Essas estruturas foram adaptadas ao tamanho de um jogo educacional; não representam uma revisão formal de projeto NASA.

2. Auditoria das referências e suas revisões

Consulta documental em 14/11/2026. Os links originais foram abertos e suas indicações de revisão foram conferidas.

As NPRs possuem escopo institucional próprio. A NPR 8705.4B, Preface aplica-se a programas/projetos robóticos geridos sob 7120.5 e exclui, de sua aplicação direta, os geridos sob 7120.8, embora estes possam adotar objetivos de garantia em sua documentação. O jogo usa essas referências como base de estudo e adaptação pedagógica.

3. Refinamentos de produto desta rodada

Plano da missão: começar pela necessidade

Na orientação vigente R17, o participante assume as funções de planejamento, engenharia de dados, operação de solo e revisão científica. A pergunta é comparar o NDVI entre dois períodos em três pontos do pacote real Terra/MODIS. O jogador projeta o processamento e a entrega desses arquivos históricos em um modelo didático de CubeSat.

A ficha de missão apresenta a cadeia de operações: preparar o projeto, processar os arquivos, armazenar entre contatos, transmitir e verificar o que chegou ao solo. O limite de 180 minutos pertence ao relógio da simulação; as datas dos dados pertencem ao arquivo histórico.

Essa ficha aplica o raciocínio do ConOps em linguagem de jogo. A informação necessária para compreender a missão aparece antes das opções de subsistema. A estrutura detalhada fica no caderno de pesquisa.

Revisão prévia: contas necessárias, com alcance declarado

Antes da execução, a pessoa pode abrir uma revisão do plano operacional. Ela compara o volume dos lotes com o teto de transmissão permitido pela política escolhida, o acúmulo antes do primeiro contato com a capacidade de memória e a potência requerida com a descarga máxima da bateria.

Uma conta favorável nessa revisão não garante a entrega. Por exemplo, o teto de comunicação supõe serviço útil durante o tempo disponível; a operação ainda depende de energia, memória, produção dos lotes e continuidade. A integração temporal da energia fica explicitamente para a execução.

A memória é analisada em relação à agenda. Neste catálogo, os trabalhos terminam antes do primeiro contato. Essa propriedade permite explicar o acúmulo prévio, mas não cria uma regra geral de que toda missão precise guardar todos os dados ao mesmo tempo.

O exemplo de armazenamento no currículo NASA, página impressa 12, trata justamente da necessidade de guardar dados entre contatos de um satélite LEO e dos compromissos com massa, potência, tamanho e custo. Essa é a ligação mais direta entre as novas referências e o mecanismo do jogo.

Requisitos: mostrar o que foi demonstrado

O relatório acrescenta uma matriz com requisito, valor observado, limite e evidência. Massa e créditos são verificações da configuração executada. Reserva, potência e memória dependem da operação. A qualidade dos dados de origem e a entrega completam a análise. A primeira é a pré-validação do arquivo histórico usado pelos lotes produzidos; ela não comprova o cálculo de NDVI no solo nem a recepção completa. Somente registros efetivamente entregues e válidos alimentam a comparação científica.

Os estados distinguem atendido, não atendido e não concluído. Se a missão termina antes do horizonte, a ausência de um alerta não demonstra que aquele requisito seria satisfeito até o fim. Uma falha já registrada continua sendo falha; o encerramento precoce não apaga a evidência.

O relatório também separa os limites do projeto, a conclusão da operação e a meta científica. Uma configuração pode entregar seis registros e ainda ser inválida por massa ou custo. O resultado geral continua vindo do motor, sem ser redefinido pela interface.

A NPR 7123.1D, Appendix A distingue verificação dos requisitos e validação do propósito em relação às expectativas e ao conceito de operações. No produto, verificamos as regras da simulação; a utilidade educacional ainda exige avaliação com o público.

Retorno científico: usar apenas o que chegou

Os resultados agora permitem comparar os dois registros de cada ponto quando ambos foram recebidos integralmente e passaram pela verificação científica. Uma recepção parcial não habilita o valor ausente. A variação só aparece com o par completo.

Os valores vêm do resultado executado. Isso respeita a diferença de representação entre transmitir bandas para calcular o NDVI no solo e transmitir o índice processado a bordo. As datas de observação são identificadas separadamente do início do composto MOD13Q1.

No cenário curto inicial, o par A chega completo, enquanto os pares B e C permanecem incompletos. Portanto, uma comparação temporal fica disponível e duas aguardam dados. Isso dá significado ao retorno científico: a engenharia determina quais perguntas podem ser examinadas com a informação efetivamente recebida.

A variação de NDVI entre duas observações é descritiva. Não estabelece, sozinha, causa de mudança, seca, incêndio ou desmatamento, e três pontos não representam todo o bioma. O MOD13 User Guide V6.1 continua sendo a referência de produto e qualidade.

Operação prevista e folgas

Eclipse, término de contato e espera entre janelas são condições previstas pela agenda. Uma violação de potência, energia ou memória é um resultado distinto que exige investigação. A interface passa a nomear essa diferença. O estado de encerramento do motor não é apresentado como um modo seguro com capacidade de recuperação que não foi modelada.

A comparação entre missões acrescenta folga de massa, créditos restantes e energia mínima acima da reserva. Esses números ajudam a discutir o custo de uma solução. Eles são diferenças dentro do modelo e não probabilidades de sucesso em voo.

4. Risco: como incorporar sem fabricar certeza

As classes A–D de 8705.4B expressam tolerância a risco e expectativas de garantia. O Appendix C orienta considerar conjuntamente prioridade, duração, complexidade e custo. Nenhum fator isolado determina automaticamente a classe.

Por isso, esta rodada não transforma classe A–D em fácil/difícil ou em percentuais arbitrários de falha. Também não transforma 9 configurações viáveis entre 64 em chance de sucesso de 14,1%. A enumeração descreve um catálogo finito sob hipóteses fixas; probabilidade exigiria um modelo de incerteza justificado.

A adaptação atual trabalha com condições conhecidas, restrições calculadas, evidências disponíveis e aspectos que ainda precisam de investigação. Isso permite raciocinar sobre risco sem prometer uma avaliação de garantia de missão real.

5. Oportunidades priorizadas para evolução

O critério para priorizar uma nova mecânica é ela criar uma decisão explicável e observável. Uma nova variável deve ter significado, unidade, fonte, hipótese e forma de verificação.

6. Como conduzir a demonstração

1. Ler o plano da missão e formular a pergunta científica.
2. Projetar a configuração inicial e abrir a revisão prévia.
3. Registrar hipótese; executar o cenário longo e observar seis registros recebidos.
4. Executar o mesmo projeto com contatos curtos; verificar o limite de transmissão, os registros na fila e as comparações científicas possíveis.
5. Relacionar o resultado a um requisito e a um evento, antes de consultar alternativas.
6. Aplicar o redesign mínimo, registrar nova previsão e executar.
7. Comparar a entrega, as folgas e os pares de NDVI disponíveis; explicar o compromisso entre processamento a bordo e potência da bateria.

Esse roteiro propõe uma atividade. Concluir a missão ou selecionar uma combinação vencedora, isoladamente, não comprova aprendizagem.

7. Procedência e limites

Os três pareceres integrais desta rodada estão em research/round10/refinamento-conops.md, refinamento-requisitos.md e refinamento-risco-ux.md. O caderno também mantém a pesquisa anterior para tornar as decisões rastreáveis.

O motor 0.1.1-rd, o catálogo ipe-64-v1, os seis registros históricos, o objetivo 6/6 e os dois cenários foram preservados. Os refinamentos acrescentam apresentação, análise dos resultados e explicações. O laboratório de física permanece separado da campanha.

Esta experiência foi desenvolvida com assistência de IA. Não há validação de voo, certificação NASA, endosso NN/g ou estudo de aprendizagem concluído. As verificações automatizadas e visuais têm alcance descrito nos respectivos registros de QA.

Refinamento ConOps — Missão Ipê 6/6

Pesquisa de 14/11/2026. Escopo: oportunidades de refinamento baseadas em fontes primárias NASA, sem editar o site durante o empacotamento. Continuidade: Missão Ipê, campanha LEO/Cerrado, seis escolhas binárias e seis resultados históricos MOD13Q1. O direcionamento desta rodada fixa a meta 6/6; a hipótese de calibração 4/6 da pesquisa inicial não deve ser aplicada a esta versão.

Decisão recomendada

O maior ganho imediato é explicitar a lógica que já existe: para quem a missão trabalha, o que deve entregar, em quais condições opera e como cada escolha contribuiu para o resultado. Isso pode ser feito com texto contextual, estados derivados e relatório, mantendo catálogo, dados e motor determinístico.

As referências estudadas orientam este desenho. Elas não representam aprovação, certificação nem demonstração de conformidade do jogo com processos da NASA.

Top 3 melhorias rápidas

1. Abertura: dar significado ao 6/6

Texto proposto, para ajustar aos nomes e critérios reais do motor:

Você lidera uma missão de observação do Cerrado. Projete o satélite para que seis resultados cheguem à equipe que estuda a vegetação de Rio Verde. Equilibre os recursos da nave e acompanhe o caminho dos dados até o solo.

Complemento de precisão:

A campanha usa referências históricas Terra/MODIS. As escolhas simulam a capacidade da missão de entregar os resultados; não alteram as medições originais.

Uma linha responde à pergunta científica: “Como a vegetação varia entre os períodos históricos apresentados?”. Essa é uma pergunta de exploração, não uma conclusão causal sobre seca, incêndio ou desmatamento.

Aplicação proposta: uma ficha com quatro campos curtos — Quem usa, Pergunta, Entrega: 6/6, Limites. Os limites devem vir do modelo atual. Evitar valores ou obrigações novas criadas apenas para preencher a interface.

Base documental: Appendix S §§1.1.1, 3.1 e 3.2; SEH §4.1. A adaptação da NASA para uma ficha curta é nossa decisão de UX.

2. Operação: deixar o gargalo compreensível

O currículo NASA oferece um exemplo particularmente próximo: um satélite LEO precisa armazenar dados porque não mantém contato contínuo com estações; o armazenamento disputa recursos da nave. Essa relação pode aparecer no replay com uma frase por evento, sempre derivada do motor.

Exemplos de microcopy proposta, usar somente onde o estado real corresponder:

• Sem contato previsto: “Os dados permanecem a bordo até a próxima janela de transmissão.”
• Memória insuficiente: “Esta coleta não foi armazenada porque a memória disponível era menor que o volume necessário.”
• Enlace limitado: “A janela terminou antes de transmitir todos os dados armazenados.”
• Eclipse previsto: “A nave está sem iluminação solar e depende da energia armazenada.”
• Modo de proteção, se implementado: “A coleta foi suspensa para preservar a operação da nave.”

Formato de cada evento: o que aconteceu → qual recurso mudou → qual resultado foi afetado. Uma ação “Ver decisão relacionada” pode levar ao componente ou escolha que realmente causou o efeito.

Não atribuir uma causa só porque ela parece plausível. Se o motor calcula apenas um balanço agregado, dizer “capacidade estimada insuficiente nesta simulação”, sem inventar instante de pane, sequência de comandos ou recuperação física.

Base documental: currículo NTRS 20210021839, §2.4, página impressa 12; Appendix S §§3.4, 6.1 e 6.2. A classificação de cada evento da Missão Ipê depende do comportamento implementado, não da presença de um ícone de alerta.

3. Resultado: três perguntas, três estados

Uma operação concluída com 4/6 entregas pode ter projeto viável e meta não atingida. A interface deve explicar isso sem trocar o nome da meta nem tratar tudo como “missão explodiu”. A nave pode sobreviver e ainda assim deixar de cumprir o objetivo.

O relatório deve destacar primeiro o resultado principal, depois a causa dominante e a escolha relacionada. Comparar com outra configuração usando o mesmo cenário permite examinar causalidade. Não prometer que uma mudança isolada resolverá o problema sem recalcular a alternativa.

Base documental: SEH §5.3 distingue conformidade com requisitos; §5.4 trata adequação ao uso. No jogo, esses conceitos inspiram a separação dos resultados; não equivalem a uma validação de missão espacial real.

Evidência primária: versão, localização e alcance

NASA Systems Engineering Handbook

Página: https://www.nasa.gov/reference/systems-engineering-handbook/

PDF: https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf

Versão documental: NASA/SP-2016-6105 Rev2, substitui Rev1 de 2007. A data de atualização de uma página web não deve ser usada como uma nova revisão técnica. O prefácio informa que o handbook é orientação de boas práticas, não diretiva.

Trechos consultados para esta proposta:

URLs dos capítulos:

• https://www.nasa.gov/reference/4-0-system-design-processes/
• https://www.nasa.gov/reference/5-0-product-realization/
• https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/

Appendix S: Concept of Operations Annotated Outline

Página: https://www.nasa.gov/reference/appendix-s-concept-of-operations-annotated-outline/

Versão: integra o Handbook Rev2. Páginas impressas 251–253, correspondentes às páginas 261–263 do PDF contado a partir de 1. A página impressa 254 inicia Appendix T. A extração HTML desta sessão ficou parcial; o conteúdo restante foi conferido no PDF oficial.

Resumo dos trechos, mantido curto: o roteiro admite adaptação ao tipo, porte e complexidade do projeto. §§1.1 e 1.2 cobrem motivação, premissas e escopo; §§3.1–3.4 conectam expectativas, elementos, pessoas, interfaces e modos; §§4–5 tratam ambiente e suporte; §6 pede cenários rastreáveis; §§6.1–6.2 distinguem funcionamento esperado de falhas, baixo desempenho, condições inesperadas ou erro humano; §7.3 relaciona sucesso a perguntas científicas e lacunas de conhecimento.

Trecho curto decisivo: “cover both nominal and off-nominal conditions”. Ele sustenta tratar falhas e degradação de modo explícito, não exigir aleatoriedade ou complexidade extra.

Currículo NASA — NTRS 20210021839

Registro: https://ntrs.nasa.gov/citations/20210021839

PDF: https://ntrs.nasa.gov/api/citations/20210021839/downloads/SE-Curriculum-Intro.2021-09-20.pdf

Metadados: autores Kenneth Freeman e Gilena A. Monroe, Ames Research Center; publicação em 11/10/2021; arquivo identificado por 20/09/2021; 27 páginas; material curricular para estudantes. O registro exibe o título “System Engineering Curriculum Into”, enquanto o PDF abre com “Systems Engineering Curriculum”.

O currículo foi adaptado do Handbook e desenvolve um exemplo de satélite/instrumento para detecção de incêndios. §§2.3 e 3 mostram a passagem de operação imaginada a requisitos, projeto, integração, testes e uso. A página impressa 12 apresenta o trade-off de armazenar dados entre contatos, sob limites de massa, potência, tamanho e custo. As atividades pedem aos estudantes formular poucos requisitos e explorar alternativas. As páginas 15–19 aproximam necessidades de stakeholders, conceito e requisitos derivados.

Limite: o exemplo é de detecção térmica de incêndio. Não importar sua operação noturna ou seu instrumento como se fossem propriedades do NDVI/MOD13Q1 da campanha. A oportunidade é adaptar o raciocínio de engenharia, preservando a diferença científica.

NASA Science Activation / Learn

Portal: https://science.nasa.gov/learn/

Dados: https://science.nasa.gov/learn/entry-points-to-nasa-data/

Aprendizagem digital: https://science.nasa.gov/learn/digital/

São páginas de programa/catálogo, sem revisão técnica numerada indicada. SciAct oferece recursos para diferentes públicos, participação em ciência e conteúdo educativo revisado. O catálogo de dados organiza ferramentas também por nível de habilidade. Para Terra, lista entradas como My NASA Data, NEO, Eyes on Earth e Worldview.

Aplicação proposta: oferecer aprofundamento opcional depois da partida — origem do dado, explicação do indicador e uma ferramenta para explorar outros períodos. A existência dessas páginas não demonstra eficácia pedagógica da Missão Ipê e não autoriza afirmar parceria com o programa.

ConOps leve proposto para o projeto

Este texto é uma definição proposta do produto, não uma reprodução do documento NASA.

Necessidade: aprender como decisões de engenharia tornam possível entregar dados científicos, com referência local ao Cerrado.

Objetivo científico da história: explorar variações de vegetação entre os períodos históricos de Rio Verde representados na campanha.

Objetivo jogável: configurar uma missão que entregue os seis resultados exigidos pelo cenário, respeitando as regras do catálogo atual.

Objetivo educativo: ao final, a pessoa consegue explicar uma cadeia causal entre escolha, recurso e entrega científica; distingue observação histórica de simulação.

Sistema: jogador/equipe, nave didática, instrumentos e recursos abstratos, sequência de operação, estação/recepção e destinatário científico. A interface apresenta o funcionamento; o catálogo define as escolhas e o motor determina resultados.

Premissas: cenário histórico fixado; mesmos inputs produzem os mesmos outputs; parâmetros didáticos identificados; duração da partida não equivale à duração física dos compostos de 16 dias; a animação orbital não deve sugerir fidelidade superior à do modelo.

Limites: este refinamento não muda valores históricos, parâmetros, catálogo ou condição de vitória. Operação de missão espacial real, licenciamento e engenharia de lançamento real ficam fora do escopo pedagógico.

Início e término: começa na compreensão do pedido científico e termina na avaliação do resultado, proveniência e possibilidade de comparar outra configuração. A decolagem é uma etapa.

Stakeholders sem criar parceiros fictícios

Não usar nome ou logotipo de organização como destinatária real sem vínculo existente. O jogador pode operar sozinho; papéis diferentes podem orientar cooperação na mesma tela, sem alegar multiplayer.

Cenários que o ConOps deve distinguir

Não é necessário introduzir eventos aleatórios para representar cenários anormais. Um modo de treino separado pode usar um evento reproduzível e identificado. Não alterar o cenário principal para fabricar drama durante o empacotamento.

Cadeia missão → requisito → verificação

Matriz proposta para uso interno. Os identificadores são nossos e não pertencem à NASA.

Essas verificações avaliam o software/modelo segundo seu contrato. A validação educativa é separada: observar usuários compreendendo a meta, identificando um gargalo e escolhendo uma alteração justificável. Uma suíte técnica aprovada não demonstra, sozinha, que o jogo ensina.

Oportunidades futuras, depois do pacote atual

1. Comparação orientada. Guardar duas configurações no mesmo cenário e perguntar qual atende a meta com menor uso de um recurso. Mostrar alternativas viáveis sem impor uma única solução universal.
2. Treino de recuperação. Campanha curta com perda de uma janela ou capacidade reduzida. A pessoa identifica impacto e escolhe uma resposta dentro de regras documentadas. Começar com um único evento reproduzível.
3. Debrief para educadores. Três perguntas: o que você previu, o que aconteceu, que evidência sustenta sua próxima escolha. Proposta nossa, a validar com usuários; não atribuir o método como requisito NASA.
4. Exploração científica. Ao concluir, abrir origem da observação e recurso de aprendizagem adequado ao nível. Comparar períodos preservando contexto e QA, sem converter diferença de NDVI em diagnóstico automático.
5. Fim de missão. Introduzir descarte/encerramento e arquivo de resultados em uma campanha futura. Sem inventar uma manobra real se o modelo só simula operação simplificada.

Pontos a conferir antes de aplicar

• No retorno científico, comparar somente os registros recebidos, ordenar por período e manter localização/unidade comparáveis. Com menos de dois registros, apresentar o dado disponível sem calcular variação temporal. Ausências devem permanecer visíveis; não completar a série com dados não entregues nem concluir causa da variação. Ao comparar partidas, identificar quando os subconjuntos de datas recebidas diferem.
• Confirmar se 6/6 significa apenas entregues ou entregues e aprovados cientificamente; não alterar a definição por texto.
• Conferir se os seis registros já têm QA auditada. Se não têm, não declarar qualidade científica validada.
• Ler estados e causas efetivamente emitidos pelo motor antes de gerar narrativa de operação.
• Manter as escolhas e todos os resultados atuais reproduzíveis; mudanças de regras exigem versão própria.
• Apresentar Handbook e currículo como referências utilizadas no desenho educativo. Não usar “NASA compliant”, “NASA approved” ou equivalentes.

Nenhum arquivo do site foi alterado nesta frente.

Refinamento por requisitos — Missão Ipê

Pesquisa de fontes primárias realizada em 14/11/2026. Escopo: propostas de interface, avaliação e rastreabilidade sobre o core determinístico existente, sem alterar catálogo, 64 combinações, agenda, fórmulas, pontuação ou comportamento operacional. Nenhum arquivo do site foi editado.

As três melhorias de maior retorno

1. Mostrar um contrato de missão mensurável

Antes da simulação, apresentar objetivo, critérios de sucesso e restrições já existentes, em linguagem de jogo. Depois, preencher as mesmas linhas com o resultado e a evidência. Exemplo de estrutura, reutilizando os limites atuais:

Cada requisito recebe identificador curto, finalidade, regra de avaliação, unidade e estado: ainda não avaliado, atendido, não atendido ou não concluído. Encerramento precoce deve preservar falhas já demonstradas e deixar não concluídos apenas os critérios cuja evidência necessária não foi produzida; não transformar a ausência de medição em aprovação ou falha automática. “Ver evidência” leva ao evento/resultado correspondente; não precisa acrescentar um formulário para o jogador.

Base documental: NPR 7123.1D §3.2.3.2 pede requisitos quantitativos, mensuráveis, verificáveis e rastreáveis; §3.2.12 trata gestão e rastreabilidade. É a inspiração metodológica, não uma obrigação institucional da Missão Ipê [R05].

Aceitação de produto proposta: todos os critérios exibidos usam exatamente os limites e resultados atuais; nenhuma linha recebe “atendido” antes da avaliação; a configuração e o mesmo cenário produzem os mesmos resultados antes e depois desta camada.

2. Transformar o debrief em evidência + interpretação

Organizar o pós-missão em duas perguntas distintas, sem chamar ambas de “validação NASA”:

• O projeto cumpriu os critérios? Resultado calculado para cada requisito, com a causa dos limites: orçamento, massa, energia, armazenamento ou comunicação, conforme as saídas já disponíveis.
• O resultado atende ao objetivo desta missão? Explicação do que efetivamente chegou à Terra e do que faltou. Expor a diferença entre coletar e entregar, destacando um gargalo e uma mudança possível.

No texto auxiliar, explicar que verificação confronta requisitos, enquanto validação confronta finalidade e uso pretendido. A NPR 7123.1D distingue esses processos e também distingue validação do produto de validação dos próprios requisitos [R06].

Duas camadas que não podem ser confundidas: os testes determinísticos verificam o software e os critérios simulados; para validar o jogo como produto educacional, é necessário observar jogadores realizando a tarefa. Testes passando não demonstram que as pessoas aprenderam. Uma rodada de pesquisa pode avaliar se o participante consegue explicar um compromisso entre ciência, comunicação e energia, sem ajuda. Essa validação continua “planejada” até haver evidência.

Aceitação proposta: o debrief apresenta evidência numérica e interpretação sem inventar telemetria; um resultado que coletou dados mas não os entregou não recebe texto de sucesso científico; a interface não afirma validação educacional já realizada.

3. Comparar alternativas com folgas e motivo da escolha

Permitir fixar duas configurações existentes e comparar os resultados sob o mesmo cenário. Mostrar ciência entregue, custo, massa e indicadores operacionais já produzidos. Acrescentar uma explicação factual do ganho e da perda: “esta opção entrega mais ciência e usa mais créditos”, com números reais.

Folga de orçamento = limite − total; folga de massa = limite − massa. Para energia, preferir a diferença entre mínimo observado e limite operacional, se esses campos existem, em vez de inventar uma média. Percentuais precisam declarar denominador. Não introduzir taxa de falha probabilística ou ranking “NASA” sem modelo.

O processo de análise de decisões da NPR 7123.1D considera critérios, alternativas, análise, seleção e incertezas [R05]. O Apêndice G considera margens e recursos de massa, potência e memória nas revisões, sem prescrever nessas passagens uma porcentagem única [R08]. A NPR 7120.8A diferencia meta desejada e limiar mínimo para seus parâmetros de desempenho [R09].

Aceitação proposta: comparar sob o mesmo cenário; evitar premiar uma alternativa por uma restrição que a outra não recebeu; preservar o score existente; “melhor” deve sempre apontar o critério considerado. Um projeto dominado pode ser identificado por critérios explícitos, sem substituir o objetivo do jogador por um peso oculto.

Auditoria das versões e dos três links solicitados

Todos os endereços fornecidos foram abertos diretamente pela web.

Correção importante sobre a diretiva provisória: a capa do PDF NID 7120.148 mostra vigência a partir de 09/12/2024 e expiração original em 09/12/2025. O catálogo oficial NODIS informa que a expiração foi prorrogada para 01/08/2027. Portanto, não diagnosticar a NID como vencida com base só na capa. Citar o catálogo juntamente com o PDF [R07, R13].

As páginas informam que as diretivas não vinculam o público salvo autorização legal ou incorporação contratual. Os prefácios delimitam NASA, centros e situações contratuais. A 7123.1D prevê adaptação proporcional ao tipo, porte e complexidade; isso não cria processo formal de aprovação NASA para o jogo [R04]. A 7120.8A rege atividades de pesquisa e tecnologia da NASA e possui critérios próprios para casos geridos pela 7120.5; não é uma norma universal para todo protótipo [R11].

Texto editorial recomendado: “Práticas de engenharia de sistemas adaptadas para esta simulação educacional.” Na área de referências, identificar documento, revisão, mudança e data de consulta. Não usar “certificado”, “aprovado para voo”, “NASA compliant” ou o fato de os testes passarem como equivalentes a uma revisão institucional.

Ciclo de vida: o que os documentos apoiam

A figura 2-5 da NID 7120.148 foi inspecionada visualmente. Para projetos de voo, apresenta Pre-Phase A, seguida de fases A a F: conceito, definição preliminar, projeto/fabricação, integração/testes/lançamento, operações e encerramento. “Fase 0” não é o rótulo dessa figura. KDP 0 aparece em ciclos de programas, e não deve ser confundido com uma fase inicial universal de qualquer projeto [R07, R14].

A NPR 7123.1D §5.1.5 vincula revisões à maturidade das evidências e aos critérios de entrada, não simplesmente à passagem do calendário. O mesmo capítulo explica que o ciclo depende da natureza do programa/projeto [R15].

Adaptação recomendada para o jogo, sem acrescentar bloqueios burocráticos:

Esses quatro momentos são uma síntese didática nossa, não uma reprodução das fases NASA nem uma revisão formal MCR/SRR/PDR/CDR/FRR. Se for desejado usar “Fase 0” como nome de onboarding, explicitar que é nomenclatura do jogo. Para reduzir jargão, a interface principal pode ficar com verbos e manter a correspondência conceitual na área “Como foi pensado”.

Risco, margens e decisões sem alterar o motor

Separar três situações:

1. Resultado conhecido: a execução ultrapassou um limite; mostrar evento e consequência.
2. Folga pequena: há pouca distância entre resultado e limite no cenário calculado; mostrar a quantidade sem convertê-la em probabilidade.
3. Incerteza fora do modelo: condições físicas e operacionais reais não representadas; tratar na explicação metodológica, não sortear falhas para aparentar realismo.

Uma reserva escolhida pelo jogo é didática e deve ser identificada assim. “10% de folga” não significa “90% de confiabilidade”. Não copiar valores de margens ou regras de autorização institucional para o score.

As comparações podem reutilizar os 64 resultados determinísticos já verificáveis. Um histórico pequeno pode guardar ID da configuração, cenário, versão do conjunto de regras, métricas e explicação do jogador. Isso permite repetir e comparar sem criar um novo simulador.

Limites de implementação para a próxima frente

• Adicionar apenas leitura, apresentação, rastreabilidade e comparação sobre as saídas existentes.
• Conservar o mesmo catálogo, agenda, 64 combinações e semântica de ciência entregue.
• Não recalibrar pontuação silenciosamente para fazer novas telas parecerem úteis.
• Não exibir uma métrica que o core não calcula como se fosse medida. Se falta um campo, restringir a primeira entrega ao que já existe.
• Fazer uma verificação de regressão dos resultados antes/depois; os testes e o oracle já existentes são a referência. Testes novos devem cobrir a camada de critérios/comparação quando ela adicionar lógica.
• Não abrir uma nova frente de física, compliance de voo ou aprovação formal. Nenhuma dessas três melhorias precisa disso.

Fontes consultadas

As referências R01–R03 são precisamente os links solicitados. As demais resolvem versão, contexto e trechos específicos. As URLs permitem conferir a versão e o contexto de cada documento.

Refinamento de risco, garantia e UX — Missão Ipê

Pesquisa primária e revisão pontual de componentes em 14/11/2026. Este parecer propõe evolução didática da interface; não altera o checkout, o motor, o catálogo de 64 combinações ou o requisito de 6/6 registros válidos com todas as restrições atendidas. Não constitui classificação oficial de missão, conformidade com diretivas NASA ou homologação de voo.

Prioridade imediata de implementação: revisão prévia determinística de contato, memória e potência, apresentada como condições necessárias. Um teto de transmissão pode usar a duração das janelas permitidas pela política multiplicada pela taxa útil do catálogo: se for insuficiente para o volume necessário, há um impedimento; se for suficiente, energia, disponibilidade dos lotes e sequência ainda precisam ser simuladas. Para memória, capacidade menor que um lote é impeditiva, mas não é necessário guardar todos os dados da missão simultaneamente se há contatos intermediários. Para potência, comparar a demanda das operações relevantes com a descarga disponível sob as condições declaradas. Passar nesses filtros não garante 6/6 nem estima probabilidade de sucesso. Não criar um selo NASA nem substituir a execução do motor por esses filtros.

1. Achados prioritários

1. NPR 8705.4B é a revisão publicada atualmente identificada no NODIS, efetiva em 01/11/2024, com expiração indicada em 31/10/2032. Ela substituiu a revisão A. A comunicação da OSMA sobre planos para uma futura revisão C não equivale à publicação dessa revisão. [R01, R02, R14, R15]
2. Classe de risco não é probabilidade de falha. A classificação declara a tolerância dos responsáveis ao risco e orienta o nível de escrutínio e atividades de garantia. Um resultado do jogo também não estima confiabilidade de hardware. [R04]
3. Classe D não significa ausência de segurança. A diretiva diferencia expectativas de garantia, mas mantém requisitos institucionais que não variam com a classe. A abordagem é proporcional à missão, não uma autorização geral para desconsiderar segurança. [R06]
4. A aplicabilidade precisa ser preservada. A NPR 8705.4B se aplica a programas/projetos robóticos NASA geridos sob NPR 7120.5, inclusive cargas robóticas em veículos humanos. Não se aplica automaticamente a veículos humanos, sistemas de lançamento ou projetos sob NPR 7120.8. Estes últimos podem adotar objetivos do apêndice D. [R02]
5. Há uma atualização importante em 7120.5: a página da NPR 7120.5F, Change 4, orienta usar NID 7120.148. O PDF ainda mostra expiração em 09/12/2025, mas o catálogo oficial registra extensão até 01/08/2027. Capa e catálogo devem ser citados juntos; não concluir que a NID expirou pela capa isolada. [R08–R10]
6. Aprendizado e missão cumprida são resultados diferentes. O jogo pode reconhecer uma investigação bem sustentada sem transformar 2/6 ou 4/6 em sucesso da campanha. A NPR 7120.8A oferece um paralelo útil: em pesquisa, demonstrar que uma hipótese não é viável pode ser um resultado válido, conforme o objetivo declarado. Isso não redefine os objetivos de uma missão operacional. [R13]

2. Versões e escopo confirmados

Fontes: [R01, R08–R11, R15].

NPR 7120.8 não é uma versão simplificada livremente escolhida de 7120.5. Seu prefácio descreve circunstâncias nas quais atividades de pesquisa e tecnologia são geridas sob 7120.5, incluindo dependência direta de um programa de voo e outras condições. A decisão depende de governança e aplicabilidade; não decorre apenas de ser pequeno, educacional ou um CubeSat. [R12]

Para o beta independente, apresentar essas fontes como referências de engenharia e ensino. Não etiquetar a Missão Ipê como “NASA Classe D” por ser um CubeSat, ter custo didático baixo ou possuir poucas escolhas.

3. O que as classes A–D significam

O enquadramento é designado e documentado pela Mission Directorate, com justificativa, até o marco KDP B; não é calculado a partir de uma única característica. [R03]

O apêndice C trata prioridade, duração, complexidade e custo de ciclo de vida de forma conjunta. Seus exemplos mostram que duração curta não determina classe D e duração longa não determina classe A. Uma régua automática “massa/preço → classe NASA” ensinaria uma regra que a própria fonte rejeita. [R05]

A definição de risco combina cenário que pode prejudicar um objetivo, sua possibilidade de ocorrência e suas consequências, com consideração das incertezas. A possibilidade pode ser expressa qualitativa ou quantitativamente; a classificação A–D não fornece um percentual universal. [R04]

Consequências para a interface, por inferência de produto:

• Não mostrar “Classe D = 40% de chance de falha”, “Classe A = 99% de sucesso” ou “baixo risco” calculado somente por margem de bateria.
• A quantidade de configurações bem-sucedidas entre as 64 é uma contagem de alternativas discretas sob uma condição fixa, não uma distribuição de falhas físicas. Não convertê-la em “chance de sucesso da nave”.
• Margem de massa, saldo de créditos e energia acima da reserva são folgas calculadas; não são estimativas de confiabilidade, segurança ou robustez probabilística.
• Um limite violado no motor é um resultado da simulação sob suas hipóteses. Uma incerteza não modelada não deve receber verde por ausência de erro.

4. Garantia, evidência e revisão de prontidão

A revisão B organiza objetivos de garantia e admite abordagens apropriadas à missão. O apêndice D contempla confiabilidade, tolerância a falhas, verificação ambiental, cobertura de telemetria e gestão de riscos. A consideração de contingências e a análise de alternativas fazem parte desse contexto. Alguns objetivos institucionais, como proteção planetária, detritos orbitais e segurança nuclear, não são reduzidos por escolher uma classe de maior tolerância. [R06]

A Assurance Implementation Matrix — AIM — documenta objetivos, implementação planejada e abordagens alternativas, apoiando acordo inicial entre responsáveis. Ela não é apenas uma lista de caixas marcadas depois de construir o sistema. [R07] O capítulo 3 inclui operação e atividades pré-voo no planejamento de garantia e prevê apresentação das diferenças em relação ao plano nos marcos de revisão. [R03]

Na NID 7120.148, a revisão de prontidão para lançamento avalia sistemas de solo, hardware e software. A SMSR prepara gestores para decisões de prosseguir ou não em atividades significativas. [R09] Aplicação didática proposta: a revisão no hangar deve reunir objetivo, limites, evidências e pendências antes do ensaio; não emitir um certificado de prontidão real.

Uma decisão pedagógica pode ter quatro campos: “objetivo ameaçado”, “evidência observada”, “mudança proposta” e “como conferir”. O primeiro remete ao contrato da campanha; o segundo, a um evento ou resultado; os demais, ao próximo experimento. Isso torna o raciocínio revisável sem imitar toda a burocracia de um programa espacial.

5. Três melhorias mínimas para os componentes atuais

As propostas abaixo são incrementais. A leitura local confirmou que a UI já possui hipótese prévia, avisos de potência, eventos com critério/valor/limite, diário, comparação e mensagens contra atribuição causal indevida. Não é necessário reconstruir esses mecanismos.

1 — Revisão pré-voo didática com estado da evidência

Onde: src/ui/Workbench.tsx, no painel project-dossier existente.

Mudança: organizar a revisão em três grupos curtos e sempre identificados por texto:

O aviso atual peakRisk representa uma comparação de demanda com limite; apresentar “Demanda prevista acima do limite de descarga”, com demandW e maxDischargeW, é mais preciso do que sugerir uma probabilidade. Não produzir um estado global “apto ao voo” só porque massa e créditos cabem.

Esforço mínimo: apresentação, rótulos e estados derivados de getConfigTotals, cenário e catálogo existentes. Não antecipar uma execução silenciosa para revelar a solução antes da previsão do jogador. Não acrescentar caixas obrigatórias de “aceito o risco”. Uma troca de componente atualiza imediatamente os dados; execução antiga não é evidência válida para o projeto alterado.

Critério de aceite: uma configuração dentro do envelope ainda mostra pendências; uma fora do envelope mantém o caminho de verificação já existente e explica a restrição; nenhuma mudança de visual ou texto altera o resultado do motor.

2 — Distinguir operação nominal de ocorrência que exige investigação

Onde: src/ui/MissionControl.tsx, em TRACE_MODES, painel de eventos e evidência selecionada.

Mudança: acrescentar uma classificação descritiva dos eventos, sem modificar severidade ou lógica do motor:

Acrescentar abaixo da evidência: “Qual ação você testaria na próxima tentativa?”. O botão já existente de localizar na linha do tempo e a reflexão vinculada a eventId continuam sendo o caminho de investigação.

Limite fundamental: o motor atual tem idle, processing, transmitting, terminated e complete; não há um modo operacional de contingência/autorreparo demonstrado. Não renomear terminated para “modo seguro”, não animar recuperação inexistente e não chamar o cenário de contato curto de falha aleatória. No beta, a resposta a uma ocorrência é a investigação e o redesign de uma nova tentativa.

Esforço mínimo: mapa estático de descrições por código e microtexto. Preservar mensagens, valores, regras e cores já vinculadas à severidade.

Critério de aceite: o jogador distingue um eclipse previsto de energia esgotada e sabe se está inspecionando uma execução encerrada ou preparando outra. Pausa/reprodução continuam sem alterar ciência ou energia.

3 — Comparar folgas e evidências, sem um “índice de risco” inventado

Onde: src/ui/CompareDialog.tsx e os textos de busca/reflexão em src/ui/MissionControl.tsx.

Mudança: acrescentar à tabela existente três leituras simples: margem de massa limite − massa, saldo orçamento − créditos e energia mínima acima da reserva minEnergyWh − reserveWh. Rotular valores negativos como limite excedido, não como porcentagem de risco. Usar os valores exatos existentes para decidir o estado; arredondamento é só apresentação.

Expor engineVersion e catalogVersion nas duas execuções e sinalizar diferenças antes de sugerir comparação direta. Manter o aviso atual quando cenários diferem ou múltiplas escolhas mudaram. No resumo da busca finita, acrescentar: “A contagem descreve o catálogo neste cenário; não estima a probabilidade de uma falha real.”

Na reflexão existente, o prompt pode ser mais específico: “Eu testaria __ para proteger __. O evento __ mostra __. Vou comparar __.” Não é necessário mudar o esquema persistido: o campo de texto e o eventId já existem.

Esforço mínimo: linhas de tabela, operações de diferença de grandezas já calculadas e textos. Nenhum ajuste em procura de alternativas, estado outcome ou critério de mínimo.

Critério de aceite: duas execuções 6/6 podem revelar folgas diferentes; seis registros com envelope violado continuam mostrando projeto inválido; a UI não promove uma alternativa a “mais segura” sem declarar o que comparou.

6. Três melhorias futuras

1 — Laboratório de contingências com contrato próprio

Criar um cenário separado, com máquina de modos explícita: operação nominal, detecção, proteção, recuperação e retomada quando permitida. Definir gatilhos, cargas desligadas, preservação de dados, prioridade de comunicação, condições de saída e consequências temporais. Começar com injeção determinística de uma ocorrência identificada, por exemplo perda de uma oportunidade de contato; documentar o instante e permitir comparar o mesmo ensaio com duas respostas.

Adicionar semente somente quando houver aleatoriedade de fato. O painel deve mostrar “evento injetado para o exercício”, evitando atribuir uma frequência NASA inventada. Não inserir esse comportamento retrospectivamente no contrato ipe-64-v1.

2 — Plano didático de garantia e revisão por evidências

Introduzir uma atividade inspirada na AIM: para cada objetivo, registrar evidência planejada, resultado do teste, limitação conhecida e ação. Perfis fictícios de tolerância ajudam a discutir quanto investir em análise, ensaio e contingência, com custos/tempo de jogo declarados. Uma biblioteca explica A–D por exemplos e consideração conjunta de contexto; não classifica automaticamente a missão do jogador.

Na revisão, diferenciar “teste planejado”, “teste executado” e “evidência insuficiente”. Um controle visual marcado não substitui um resultado. A consequência educativa pode ser a qualidade da justificativa, separada do cumprimento da campanha e sem selo de conformidade NASA.

3 — Análise de incerteza com hipóteses verificáveis

Somente depois de definir distribuições, dependências, limites e justificativas, criar conjuntos de execuções para estudar dispersão e sensibilidade. Mostrar tamanho da amostra, sementes, modelo e intervalo de incerteza da estimativa. Separar incerteza sobre parâmetros de eventos aleatórios e evitar tratar componentes como independentes sem justificativa.

Permitir comparar decisões sob as mesmas realizações do cenário. A probabilidade resultante será condicional ao modelo e às hipóteses, não uma propriedade universal de uma classe NASA. Antes dessa modelagem, manter a apresentação determinística atual, com folgas e limites explícitos.

7. Linguagem recomendada

Estas são recomendações autorais de UX derivadas da leitura das fontes e dos componentes, não prescrições de interface feitas pela NASA.

8. Fontes primárias

Material local lido para propostas de integração: src/ui/Workbench.tsx, src/ui/MissionControl.tsx, src/ui/CompareDialog.tsx, src/ui/learning.ts e src/core/contracts.ts. Leitura de código não equivale a ensaio de navegador. Nenhuma nova suíte ou navegador foi executado nesta pesquisa.

Missão Ipê — jogo de projeto de missão espacial

Pesquisa e decisões da rodada 9 · 14 de novembro de 2026 · português do Brasil.

1. Decisão de produto

O tema escolhido por AB é Space Mission Design Game, do NASA Space Apps Challenge 2026. A campanha inicial será Missão Ipê — Ciência que chega: projetar um CubeSat educacional que precisa entregar seis registros científicos válidos ao solo, dentro de limites de massa, orçamento, energia, potência, memória e tempo de contato.

O jogador não ganha por selecionar o componente mais caro ou por assistir ao lançamento. Precisa fazer sistemas interdependentes funcionarem juntos. A pergunta de produto é: como tornar visível a consequência de uma escolha de engenharia, para que a pessoa possa prever, executar, investigar e redesenhar?

A campanha principal foi preservada depois de inspecionar o repositório existente oalexandrebelo/AB-NASA-TEAM-IPE, no commit 73162276b46227e8965eed2b91a7dc8edae70b96. O contrato ipe-64-v1 e o motor 0.1.1-rd já ofereciam dois cenários e conservação auditável de recursos. Recomeçar esse motor não era necessário para produzir a nova interface. A rodada evolui a experiência e acrescenta modelos de física separados.

Critério de sucesso preservado: 6/6 registros válidos entregues e nenhuma restrição de missão violada. A hipótese de aceitar 4/6 mencionada no parecer A1 não foi adotada. Um contador 6/6 não basta quando massa, orçamento ou outra restrição tornam a configuração inválida.

2. O que o desafio oficial sustenta

A URL da aba Resources fornecida pelo usuário retornou erros de recuperação nesta rodada. O resumo institucional do desafio foi confirmado no bloco About the Challenge de uma página oficial de equipe, separando-o da descrição autoral da equipe: https://www.spaceappschallenge.org/2026/find-a-team/missionforge/ . Ele sustenta projeto, gestão e simulação de uma missão completa, com decisões de engenharia, recursos limitados e consequências sobre o resultado.

O texto integral reproduzido no evento HackAthlone ajudou a localizar referências, mas não substitui a autoridade do original: https://hackathlone.com/challenges/space-mission-design-game . A associação exata dos nove recursos dessa reprodução à aba oficial permanece pendente. Não foram inventados requisitos obrigatórios de multiplayer, realidade virtual ou uso de IA. O desafio de VR de 2023 é uma referência histórica distinta.

O beta cobre o percurso objetivo → configuração → revisão → operação simulada → ciência recebida → explicação → novo projeto. A seleção livre de lançador, instrumento e órbita permanece para evolução: no catálogo atual, esses elementos são fixos. Isso deve ser apresentado como recorte explícito, não como cobertura integral de todos os exemplos do enunciado.

3. Por que Cerrado / LEO primeiro

O Cerrado aproxima a missão da equipe e do público de Rio Verde. A tarefa tem finalidade científica reconhecível: obter índices de vegetação válidos. A órbita terrestre permite estudar energia, eclipses, armazenamento e contatos sem introduzir simultaneamente captura planetária, múltiplos estágios e propulsão de baixo empuxo.

O recorte torna a consequência verificável: dois cenários mudam o tempo de contato mantendo os arquivos científicos e as opções. A configuração inicial entrega 6/6 no contato longo e apenas 2/6 no curto. O jogador pode investigar o limite de comunicação, perceber que processar a bordo reduz os dados e descobrir que esse processamento exige mais potência da bateria.

A campanha não afirma que o CubeSat fictício adquiriu os dados históricos. Os seis registros Terra/MODIS já existem. O motor usa representações didáticas de processamento e transporte para ensinar o caminho entre informação produzida e resultado disponível na Terra.

4. Fontes NASA aplicadas

MOD13Q1 V061 é um produto de composição temporal de 16 dias, com resolução nominal de 250 m. O pacote preserva datas dos registros, bandas vermelha e infravermelha próxima, índice de referência e QA. Ele não é uma sequência de imagens instantâneas produzidas pelo satélite do jogo.

Os JSON de origem, recibos e pacote estão em public/data. A restauração local foi comparada com os hashes de blobs do repositório. A revisão A6 identificou e permitiu corrigir um LF excedente introduzido pelo transporte dos arquivos. Os recibos e hashes de origem foram preservados; não foram modificados para aceitar arquivos divergentes.

5. Correções das premissas do briefing

Delta-v e lançamento

Tsiolkovsky usa Δv = Isp × g0 × ln(m0/mf), com logaritmo natural e g0 = 9,80665 m/s². Esse g0 é uma referência de definição do impulso específico; não muda para a gravidade local da Lua. Deve-se separar o serviço de lançamento das manobras realizadas pela própria nave. Valores de uma tabela Terra/LEO/Marte não são requisitos universais sem definir origem, destino, captura, janela, perdas e veículo.

Alto Isp não significa alto empuxo. A equação ideal não produz automaticamente duração de manobra ou trajetória de uma propulsão elétrica. O laboratório mostra a capacidade ideal de Δv e declara essas limitações.

Energia solar e bateria

Há duas entradas diferentes: irradiância incidente em W/m² ou potência elétrica nominal de um painel. Para a primeira, aplicar área, eficiência e orientação. Para a segunda, não multiplicar novamente pela eficiência já incorporada ao nominal.

O laboratório usa P = 1361 × A × η × cos(θ) / R², com R em UA, incidência medida em relação à normal e conversão aplicada uma vez. A campanha usa potências elétricas nominais de 12 e 18 W e fatores operacionais declarados. Energia em Wh é a integral da potência com o tempo em horas; potência máxima de descarga e capacidade energética são limites distintos.

Comunicação

Friis descreve potência recebida no modelo ideal, não uma taxa de dados automaticamente. Com ganhos em dBi mantidos fixos, aumentar frequência aumenta a perda em espaço livre. Se a abertura física das antenas for mantida fixa, seus ganhos variam com frequência; é outra comparação. Taxa exige considerar ruído, modulação, codificação, Eb/N0, perdas e margem.

O laboratório mantém ganhos fixos, calcula perda, potência recebida e latência de luz e informa que não calcula bitrate. No jogo, taxas úteis de serviço são parâmetros didáticos de 960 kbit/s ou 2,4 Mbit/s.

Custos, margens, massa e MMRTG

Preços de lançamento, capacidades máximas e contratos não são intercambiáveis. Não foi construída uma tabela de preços atuais com os números do briefing. O beta usa créditos claramente identificados como economia de jogo.

Faixas de distribuição de massa e margem não são regras universais. Uma margem precisa especificar sua base: percentual da estimativa ou da alocação. A revisão não converteu 20–25% em uma suposta obrigação NASA aplicável a toda missão.

O MMRTG tem referências NASA/JPL para aproximadamente 110 W elétricos iniciais e 45 kg, mas degradação total e custo não são constantes universais de catálogo. O MMRTG não foi inserido como opção plausível dentro do CubeSat de 3,6 kg.

6. O jogo que está sendo entregue

Campanha

As seis decisões são bateria, painel solar, processamento, rádio, memória e plano de transmissão. Cada decisão tem duas opções; são 64 configurações. Há dois cenários com duas janelas cada: 600 s por janela ou 240 s. A missão didática tem horizonte de 10.800 s, envelope de 3,6 kg e 86 créditos.

O resultado considera conservação dos bits, fila FIFO, lotes completos, transmissão parcial, saturação da memória, geração solar, perdas de conversão, carga limitada, potência de descarga, reserva e energia mínima. Os seis registros precisam chegar completos e passar pela validação científica. A busca exaustiva conta configurações inválidas e não atribui certificado de mínimo a uma execução incompleta.

O relógio do motor é independente do frame de renderização. Pausar a imagem ou percorrer os estados do relatório não muda a missão já calculada. Isso é essencial para permitir comparação justa entre tentativas.

Interface e aprendizado

O briefing apresenta objetivo e limites. O hangar mostra a montagem 3D e as opções de um subsistema por vez. Os outros sistemas permanecem reconhecíveis na navegação, com a escolha ativa. Massa, orçamento e capacidades são atualizados pelo projeto selecionado.

Antes de executar, a pessoa registra uma hipótese e uma justificativa. Alterar um componente invalida a seleção da hipótese, preservando a justificativa para revisão. O relatório mostra estado geral, dados completos, curva de energia e eventos. A comparação de duas execuções evidencia mudanças de configuração e alerta quando os cenários diferem.

A ajuda de catálogo aparece após a própria tentativa e explica o mínimo de escolhas alteradas dentro das 64 opções. Ela não se apresenta como inteligência artificial nem como diagnóstico causal universal. A proposta educativa é investigar relações de sistema, não memorizar uma combinação vencedora.

Laboratório de física

Quatro experiências independentes permitem variar: altitude LEO; área, eficiência, incidência e distância solar; massa seca, propelente e Isp; potência, frequência e distância do enlace. Resultados e diagramas mudam imediatamente. Cada modelo tem unidades, hipóteses e fontes.

O laboratório não configura a campanha. Ele serve para aprofundamento didático e prepara a expansão futura. Dados reais de efemérides, janelas de lançamento, órbitas perturbadas ou captura lunar não foram implicitamente acrescentados ao motor por existir um globo 3D.

7. UX orientada por NN/g

Foram consultadas as dez heurísticas, divulgação progressiva, reconhecimento e lembrança e heurísticas em aplicações complexas.

As decisões de interface são aplicações nossas desses princípios: estado e limites visíveis, controle do ritmo, linguagem comum, escolhas nativas fora do canvas, fonte disponível junto do dado, recuperação por novo projeto e comparação de resultados. Não há endosso NN/g nem estudo de usabilidade com participantes concluído.

O modo 2D preserva os controles e resultados. O 3D é complementar, com detecção de indisponibilidade, movimento reduzido e controles de visualização. A verificação por teclado e em larguras menores complementa os testes de DOM; não constitui certificação de conformidade WCAG.

8. Stack e repositórios

Vite, React 19, TypeScript strict, Three.js, R3F 9 e Drei formam a implementação. O motor continua isolado e pode rodar em Worker. IndexedDB guarda execuções e rascunhos; replay importado é validado e recalculado. CSS local com tokens preserva a identidade da experiência. Não foi necessário adicionar um backend, autenticação ou LLM para resolver números de engenharia.

Astronomy Engine é apropriado a posições e eventos astronômicos, não a calcular sozinho um plano completo de Δv. Satellite.js atende propagação SGP4/SDP4 com elementos apropriados a satélites terrestres; não é substituto para trajetórias interplanetárias. MuSCAT é MATLAB; CML é C++/Trick/JEOD. Eles são referências arquiteturais futuras.

O parecer A3 separa licenças de código e assets. Planetarium não apresentou licença na raiz consultada. Earth-moon-solar declara MIT para código, CC BY 4.0 em texturas e CC BY-SA 4.0 em dados HYG. CML usa NOSA 1.3; MuSCAT usa Apache-2.0. Esta rodada criou geometrias próprias; não copiou esses projetos ou sua coleção de assets.

9. Evolução priorizada

1. Fechar a revisão humana do desafio integral e a associação de uma fonte da aba Resources ao uso demonstrado; preservar autoria, datas e declaração de IA.
2. Realizar sessões com jogadores do público: entender a meta, identificar restrição, explicar mudança, transferir a estratégia ao cenário curto. Medir compreensão antes/depois com tarefas distintas e registrar erros; não confundir conclusão com aprendizado.
3. Integrar escolha de órbita, lançador e instrumento em contrato versionado, com compatibilidades e agendas completas. Comparar resultados com referências independentes antes de mudar o catálogo.
4. Adicionar campanha lunar com transferência, captura, comunicação, eclipse e ciência própria. Separar modelos impulsivos de baixo empuxo.
5. Expandir para Marte com efemérides e solucionador de trajetórias apropriado, latência e plano de operações. Cada camada deve trazer decisão útil, hipótese explícita e verificação.
6. Só depois acrescentar cenários estocásticos com semente registrada, colaboração de equipe, missões autorais e progressão persistente.

10. Evidência e leitura completa

As pesquisas integrais estão em research/round9/a1-desafio.md, a2-fisica.md e a3-ux-tecnologia.md. O guia de demonstração e a revisão independente estão em docs/GUIA-DIDATICO-R9.md e docs/QA-R9.md. Os recibos de execução ficam em evidence/.

Preservar a diferença entre revisão documental, teste numérico, DOM simulado, inspeção visual no navegador e uso real por participantes. Nenhuma dessas evidências substitui todas as outras. Desenvolvimento assistido por IA; nenhuma afiliação ou validação institucional da NASA ou da NN/g é inferida.

A1 — Desafio oficial, referências NASA e escopo didático

Pesquisa realizada em 14 de novembro de 2026. Contexto recebido do agente coordenador: existe uma base real no repositório privado AB-NASA-TEAM-IPE, versão 0.3.0-beta.1, denominada Missão Ipê. Ela utiliza seis resultados históricos MOD13Q1 de Rio Verde, um catálogo de seis escolhas binárias ipe-64-v1 e simulação determinística. Não inspecionei o código nem os seis registros; estas informações sobre a implementação vieram do coordenador.

1. Conclusão para decisão de produto

Recomendo preservar a Missão Ipê / Cerrado como campanha inicial. O tema de observação terrestre permite demonstrar, em uma partida curta, os quatro segmentos de uma missão científica: lançamento, nave, solo e pessoas que usam os resultados. A nova interface pode tornar visível o percurso objetivo → configuração → revisão → operação → ciência entregue → comparação de decisões. A Lua é uma expansão coerente, depois de o ciclo terrestre ser demonstrável.

O núcleo verificado do desafio 2026 é criar um jogo interativo para projetar, gerir e simular uma missão espacial completa, tornando perceptíveis escolhas de engenharia, recursos limitados e suas consequências. Isso favorece uma missão pequena e completa. Uma montagem de nave sem operação e sem avaliação de resultados deixaria de demonstrar parte desse núcleo.

2. O que foi efetivamente verificado sobre 2026

URL solicitada: https://www.spaceappschallenge.org/2026/challenges/space-mission-design-game/?tab=resources

Nesta pesquisa, a ferramenta web não conseguiu abrir a página específica: houve DisabledError, timeout e URL inacessível, inclusive ao testar a URL canônica, a variante sem www e a aba details. Isso não prova que a página inexista. Sua existência temática em 2026 é corroborada por páginas oficiais do Space Apps de equipes que exibem a seção institucional About the Challenge e nomeiam Space Mission Design Game.

Fontes oficiais com o resumo:

• https://www.spaceappschallenge.org/2026/find-a-team/project_morazan/
• https://www.spaceappschallenge.org/2026/find-a-team/missionforge/
• https://www.spaceappschallenge.org/2026/find-a-team/los-marcianos/

É importante distinguir a descrição escrita pelas equipes do bloco institucional do desafio. A confirmação acima usa o segundo. Um trecho curto desse bloco: “design, manage, and simulate a complete space mission”. O resumo menciona objetivos, desenho da nave, instrumentos, lançadores, orçamento, potência, massa, comunicações e restrições orbitais.

O calendário de 2026 também é confirmado diretamente por NASA e Space Apps: evento em 14–15/11/2026, tema The Next Frontier; o cronograma oficial informa divulgação dos enunciados em 28/10/2026.

• NASA: https://science.nasa.gov/universe/nasa-welcomes-all-ages-experience-levels-for-space-apps-challenge/
• PDF oficial: https://assets.spaceappschallenge.org/media/documents/2026_NASA_Space_Apps_Registration_Recruitment.pdf

Limite desta auditoria: não atribuir a mim a leitura integral da aba oficial de recursos. O coordenador informou que o projeto já tinha um gate Resources aberto; uma evidência anterior válida pode completar esta lacuna, mas não foi reproduzida por esta frente.

3. Obrigação, sugestão e decisão nossa

Uma reprodução extensa foi localizada no evento local HackAthlone: https://hackathlone.com/challenges/space-mission-design-game . Ela indica nove recursos e apresenta colaboração e outras funcionalidades em linguagem opcional. Usei essa página para localizar os destinos primários abaixo, não como autoridade técnica nem substituto da página oficial. A obrigatoriedade detalhada continua sujeita ao original.

4. Recursos localizados e acesso aos destinos primários

A associação destes nove itens à aba do desafio vem da reprodução local. O conteúdo técnico dos destinos NASA/JPL/CSA foi verificado separadamente, salvo indicação explícita.

Fonte oficial que distingue os anos: https://www.spaceappschallenge.org/2023/ registra o evento de 7–8/10/2023 e seu tema Explore Open Science Together. A lista https://www.spaceappschallenge.org/2023/locations/shah-alam/ inclui o desafio de VR. Não foi encontrado motivo para transportar VR para uma obrigação de 2026.

5. NASA Systems Engineering Handbook: aplicação didática

Fonte central: https://www.nasa.gov/reference/systems-engineering-handbook/

PDF oficial: https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf

O documento é NASA/SP-2016-6105 Rev2. O próprio prefácio o caracteriza como orientação de boas práticas, sem transformá-lo em diretiva. Não apresentar o jogo como execução integral ou certificação desse handbook.

Capítulos primários consultados:

• Ciclo de vida: https://www.nasa.gov/reference/3-0-nasa-program-project-life-cycle/ . A fase de operação envolve realização dos objetivos, obtenção e análise dos dados, resolução de anomalias e relatórios. O encerramento contempla destinação do sistema e arquivamento.
• Design: https://www.nasa.gov/reference/4-0-system-design-processes/ . ConOps deve considerar o uso do sistema, decisões, interfaces e situações relevantes, inclusive degradadas, desde cedo.
• Realização: https://www.nasa.gov/reference/5-0-product-realization/ . A distinção entre verificação de requisitos e validação de expectativas é importante. A NASA inclui seres humanos e interfaces na validação; também trata limitações dos modelos como possível origem de resultados inadequados.

Aplicação proposta, não prescrição NASA: traduzir esses conceitos em linguagem comum, com “Objetivo”, “Projeto”, “Revisão”, “Operação” e “Resultados”. Siglas como PDR, CDR e CML podem ficar no conteúdo opcional de aprofundamento.

6. Basics of Space Flight: o que aproveitar e o que atualizar

Portal atual: https://science.nasa.gov/learn/basics-of-space-flight/

O material originou-se no JPL e hoje está hospedado em NASA Science. Sua apresentação diz que é amplo e introdutório, voltado a compreender como as áreas de uma missão se relacionam. Serve à alfabetização científica do jogo, não a validar sozinho um simulador de engenharia.

Fontes e uso:

• Missão e fases: https://science.nasa.gov/learn/basics-of-space-flight/chapter7-1/ . Apoia o percurso de uma ideia até projeto e desenvolvimento.
• Telecom: https://science.nasa.gov/learn/basics-of-space-flight/chapter10-1/ . Explica comunicação, taxas e multiplexação. Aplicação: dado gerado não equivale a dado recebido; parte da capacidade serve a funções de engenharia.
• Sistemas a bordo: https://science.nasa.gov/learn/basics-of-space-flight/chapter11-1/ . Relaciona estrutura, controle, processamento e proteção da nave. Aplicação: modo seguro preserva a missão com impacto temporário na ciência.
• Energia: https://science.nasa.gov/learn/basics-of-space-flight/chapter11-3/ . A relação geração, consumo, armazenamento e eclipse é útil. Não importar como valores de CubeSat seus exemplos de naves interplanetárias.
• Instrumentos: https://science.nasa.gov/learn/basics-of-space-flight/chapter12-1/ . Fonte para explicar por que instrumentos diferentes respondem a perguntas científicas diferentes.

Achado de qualidade: o tutorial contém exemplos e afirmações tecnológicas antigas. O capítulo de energia ainda usa números históricos e um trecho que limita a praticabilidade solar para além de Marte. Juno demonstra energia solar em Júpiter, como descreve https://science.nasa.gov/mission/juno/ . Portanto, reutilizar princípios e revisar afirmações quantitativas ou de tecnologia.

Fonte adicional atualizada, muito útil ao catálogo: https://www.nasa.gov/smallsat-institute/sst-soa/ . A edição disponível é a de 2026; o resumo diz cobrir tecnologias públicas até abril de 2026. O capítulo de energia está em https://www.nasa.gov/smallsat-institute/sst-soa/power-subsystems/ . É uma revisão tecnológica, com informações agregadas; valores específicos de hardware ainda devem ser rastreados às condições e à fonte original. Para o jogo, separar dados de referência de parâmetros didáticos calibrados.

7. Dados abertos adequados à Missão Ipê

Base preferida: manter MOD13Q1 histórico

Earthdata Search: https://search.earthdata.nasa.gov/search?q=MOD13Q1

Catálogo USGS/LP DAAC: https://lpdaac.usgs.gov/products/mod13q1v061/ — a abertura direta retornou 403 nesta sessão, portanto os fatos abaixo foram confirmados nas entradas Earthdata/CMR.

Registro CMR de distribuição INPE: https://cmr.earthdata.nasa.gov/search/concepts/C3560374404-INPE.html . Atenção: essa distribuição tem sua própria extensão temporal; não usar a última data dela como prova de encerramento do produto global.

MOD13Q1 V061 é um produto Terra/MODIS nível 3, em grade, com resolução nominal de 250 m e composição de 16 dias. Inclui NDVI e EVI, camadas de qualidade e informações auxiliares. A composição seleciona observações segundo critérios de qualidade; não é uma única imagem instantânea. A série MOD13 é Terra, enquanto MYD13 corresponde a Aqua.

Implicações de produto e de fidelidade:

1. Mostrar “Referência histórica Terra/MODIS”, período do composto, localização, produto e versão.
2. Não dizer que o CubeSat Ipê real mediu esses seis resultados. A nave é parte da simulação educativa; os dados vieram da missão NASA.
3. A escolha do jogador muda a entrega, o armazenamento e a disponibilidade dos resultados simulados; não muda os valores históricos de NDVI.
4. Não representar seis compostos como seis fotos tiradas em seis órbitas reais. A duração de uma rodada pode ser pedagógica, identificada dessa forma.
5. Não atribuir automaticamente uma queda de NDVI a desmatamento, fogo ou seca. O indicador necessita contexto, série temporal, qualidade e análise para uma interpretação causal.
6. Preservar valores ausentes e baixa qualidade; não transformá-los silenciosamente em zero ou “vegetação ruim”.

Fundamento do indicador: https://science.nasa.gov/earth/earth-observatory/measuring-vegetation-ndvi-evi/ e https://science.nasa.gov/earth/earth-observatory/global-vegetation-8622/ . NDVI usa a diferença normalizada entre infravermelho próximo e vermelho. Na explicação ao jogador: instrumentos precisam captar as faixas adequadas; uma câmera RGB simples não entrega automaticamente essa capacidade.

Limite físico importante: https://science.nasa.gov/mission/aqua/modis/ descreve MODIS como instrumento de 36 bandas, com massa de 229 kg. Usar seus produtos como referência científica não significa que o instrumento caiba em um CubeSat. “Inspirado em observação multiespectral” é mais fiel que “réplica de MODIS”.

Acesso programático e proveniência

Documentação oficial ORNL DAAC/TESViS:

• https://modis.ornl.gov/data.html
• https://modis.ornl.gov/data/modis_webservice.html
• https://modis.ornl.gov/rst/globalsubset_ui/

O serviço documenta consultas de produtos, bandas, datas e subconjuntos por localização. O endpoint /rst/api/v1/MOD13Q1/subset aceita latitude, longitude, intervalo e área; os exemplos mostram JSON e CSV. A documentação apresenta limite de dez datas por pedido síncrono, suficiente para um pacote de seis resultados se as datas estiverem cobertas. Não executei a extração dos seis registros existentes.

Para cada resultado empacotado, recomenda-se registrar: produto, coleção/versão, bandas, coordenadas e área, datas do composto e da obtenção, valor bruto, fator de escala, valor final, regra de QA, método de agregação e URL da consulta. Os exemplos ORNL documentam fator 0,0001 para EVI; conferir o metadado efetivamente retornado de cada banda antes de converter. Guias antigos V5/V6 não devem ser apresentados como se fossem a especificação completa V061.

O jogo pode operar com um pacote histórico fixado e auditável, sem depender de API ao vivo durante a demonstração. Um link “Ver origem deste dado” leva à proveniência. Isso é uma decisão de robustez e clareza do projeto, não uma exigência formal da NASA.

8. MVP concreto recomendado

Nome de campanha: Missão Ipê — Ciência que chega.

Papel: equipe que configura uma pequena missão de observação do Cerrado e precisa entregar resultados úteis a quem estuda a vegetação de Rio Verde.

Missão curta: selecionar uma configuração, passar pela revisão, acompanhar uma simulação determinística de seis oportunidades didáticas e entregar a meta científica sem violar as restrições essenciais. Tempo de experiência proposto: 8–12 minutos na primeira partida, 2–4 minutos para revisar uma decisão e repetir.

Contrato de compatibilidade: manter o catálogo ipe-64-v1 e os resultados conhecidos até auditar o motor existente. Não renomear parâmetros científicos nem modificar limiares apenas para acomodar um layout. Se a nova interface fizer escolhas diferentes, tratá-las como nova versão de catálogo ou campanha.

Loop proposto:

1. Entender a missão. Uma pergunta científica, destinatário, seis referências históricas e uma meta visível. Explicar o que conta como resultado útil.
2. Projetar. Apresentar as seis escolhas existentes progressivamente, com delta imediato de recursos e uma frase causal por opção. Mostrar limites e unidade de cada recurso.
3. Revisar. Separar impedimentos de lançamento de margens apertadas. Explicar o problema e levar diretamente à escolha responsável. Uma configuração inviável é oportunidade de revisão, não tela terminal.
4. Operar. Executar a mesma sequência para a mesma configuração. Permitir pausar e avançar etapas. Mostrar energia, memória, coleta e comunicação; explicar por que cada resultado foi ou não entregue.
5. Avaliar. Exibir ciência capturada, ciência transmitida e ciência útil. Justificar sucesso ou falha por requisitos concretos. Relacionar cada consequência a uma decisão.
6. Experimentar. Duplicar a configuração, alterar uma decisão e comparar o antes/depois sob o mesmo cenário. Isso ensina causalidade e trade-offs.

Condição de vitória proposta para calibrar: entregar pelo menos quatro dos seis resultados úteis, manter orçamento e compatibilidade de lançamento e concluir a operação sem falha terminal de energia. Esse número é uma decisão inicial de design, não requisito do desafio nem descrição verificada do motor atual. Antes de adotá-lo, avaliar todas as 64 configurações: deve haver mais de um caminho viável, trocas reais e pelo menos uma falha instrutiva explicável.

Condições de insucesso: chegar ao final abaixo da meta; perder a capacidade operacional crítica; ou não entregar observações por insuficiência de comunicação/armazenamento. Falha deve terminar com causa, efeito e uma sugestão ligada à configuração. Evitar explosão aleatória como justificativa sem vínculo com o modelo.

Regras de modelagem propostas:

• Separar potência instantânea (W) e energia armazenada (Wh).
• Energia varia por geração menos consumo ao longo de um intervalo; dados armazenados variam por coleta menos transmissão.
• Capacidade de lançamento e orçamento são restrições explícitas; não se resolvem com “pontos de ciência”.
• Pontuação é secundária à entrega da meta. Evitar um único score opaco que permita compensar nave inviável com bônus.
• Valores de componentes, janelas e custos devem estar identificados como reais documentados ou didáticos. Não nomear preços fictícios como cotações de fornecedores.
• Se a órbita for só uma animação, dizer que é representação didática; não chamá-la de propagação orbital validada.

Cooperação de escopo contido: dois a quatro participantes podem debater a mesma missão na mesma tela, distribuindo papéis de ciência, nave, comunicação e recursos. Isso preserva colaboração sem alegar multiplayer online. Realtime, salas e contas só entram quando houver necessidade demonstrada.

9. Mapa de aderência e evidência de demonstração

10. Lacunas e próximos passos objetivos

1. Recuperar/arquivar a página oficial integral de 2026 ou a evidência anterior do gate Resources para resolver a obrigatoriedade fina e a associação exata dos nove recursos.
2. Auditar os seis resultados reais de Rio Verde: fonte, datas, QA, escala, agregação e rótulos da UI. Não foram lidos nesta frente.
3. Ler as seis decisões e as condições atuais do motor ipe-64-v1 antes de implementar a proposta de apresentação.
4. Validar os 64 resultados existentes e os motivos de falha; não introduzir um threshold novo sem recalibrar e versionar.
5. Separar simulação pedagógica de dados observados em todos os pontos que possam causar confusão.
6. Usar Handbook, Basics e CubeSat 101 para conceitos; recorrer ao estado da arte 2026 e a fontes originais para valores contemporâneos.

Nenhum código de aplicação foi modificado por esta frente.

A2 — Auditoria de física e dados: Missão Ipê / Space Mission Design

Pesquisa: 14/11/2026. Entrega de pesquisa e especificação; nenhum motor de voo foi implementado.

Decisão após localizar o projeto existente: preservar a campanha Missão Ipê, CubeSat LEO de observação do Cerrado, seu catálogo e sua agenda didática. A evolução física pode existir em um laboratório separado, com experiências de Kepler, Tsiolkovsky, energia e telecomunicações. Missão lunar polar é a segunda campanha; Marte é extensão posterior. Os números abaixo são referências para verificações e explicações, não previsões da agenda operacional atual.

1. Correções que realmente importam

A NASA recomenda adequar a fidelidade do modelo à decisão de projeto e evitar complexidade excessiva na fase conceitual [F16]. Isso apoia um laboratório explicativo separado, sem substituir uma agenda didática coerente por uma promessa de previsão orbital.

2. Natureza dos números e rastreabilidade

Usar três classes em qualquer painel de dados:

• Referência física: constante ou especificação publicada, com fonte, unidade, versão e contexto.
• Derivado: resultado calculado de referências e hipóteses declaradas; mostrar equação e condições.
• Didático: escolha de cenário, balanceamento, custo, qualidade de ciência, reserva, taxa de falha ou hardware fictício.

Cada parâmetro deve carregar valor, unidade, classe, fonte, data de acesso, contexto e transformação aplicada. Uma eficiência retirada de ficha de célula não é automaticamente a eficiência do conjunto painel + cabos + regulador. Preservar valores originais de dados científicos; separar claramente campos reais de pesos de pontuação inventados.

Recomendação de unidades internas: m, s, kg, rad, W, Wh, bit/s e byte. Evitar alternar km e m silenciosamente. O g₀ de Isp continua terrestre mesmo em manobras na Lua.

3. Kepler e a referência LEO a 500 km

Para órbita circular de raio r = R + h:

v_c=\sqrt{\mu/r},\qquad n=\sqrt{\mu/r^3},\qquad T=2\pi\sqrt{r^3/\mu}.

Para elipse:

v^2=\mu(2/r-1/a),\qquad M(t)=M_0+n(t-t_0),\qquad E-e\sin E=M.

Essas equações são de dois corpos; não incluir implicitamente arrasto, J₂, manobras ou perturbações lunares. Uma órbita polar tem i = 90°; isso não a torna automaticamente heliossíncrona [F06].

Resultados calculados independentemente para uma Terra esférica, h = 500 km, e = 0:

β é o ângulo entre a direção do Sol e o plano orbital. Não é inclinação, latitude ou estação do ano. Para Sol distante e sombra cilíndrica:

f_\mathrm{eclipse}=\frac{1}{\pi}\arccos\left(\frac{\sqrt{r^2-R^2}}{r\cos\beta}\right)

quando |β| < arcsin(R/r); fora dessa condição, o eclipse é zero. Em β = 0, a expressão reduz a arcsin(R/r)/π. A NASA descreve a dependência de eclipse com β e altitude [F07].

No passo de simulação, é mais útil testar geometria: com posição relativa r e direção unitária para o Sol s, há sombra cilíndrica quando r·s < 0 e a distância ao eixo de sombra, ||r − (r·s)s||, é menor que R. Usar um teste por corpo ocultador quando relevante.

Não transportar esses horários para a agenda original. Eles são casos verificáveis do laboratório. Para prever passagens por Rio Verde seria necessário definir época, inclinação, nó ascendente, fase, estação e referencial. “Uma passagem de 8 minutos a cada órbita” não é uma propriedade geral de uma estação terrestre.

4. Energia por tempo: W, Wh, sombra e bateria

Duas formas corretas, mutuamente exclusivas, de representar o painel:

P_\mathrm{solar}=S_0(1\mathrm{au}/d_\odot)^2 A_\mathrm{ativa}\eta_\mathrm{célula}
\max(0,\hat n\cdot\hat s)\,k_\mathrm{demais}\,I_\mathrm{sol}

ou, se a entrada já é potência elétrica nominal:

P_\mathrm{solar}=P_{\mathrm{el,ref}}(d_\mathrm{ref}/d_\odot)^2
\max(0,\hat n\cdot\hat s)\,k_\mathrm{relativo}\,I_\mathrm{sol}.

Não aplicar η da célula na segunda forma. Registrar quais efeitos estão incluídos na ficha nominal para não repetir temperatura, radiação, regulador ou fator de preenchimento. A NASA apresenta células espaciais próximas de 30% e destaca ausência de geração em eclipse e degradação durante a missão [F08].

Se Pnet = Pgeração − Pcarga, com Δt em segundos:

E_{k+1}=E_k+\left[\eta_c\max(P_\mathrm{net},0)
-\frac{\max(-P_\mathrm{net},0)}{\eta_d}\right]\Delta t/3600.

Também limitar potência de carga/descarga, capacidade e SOC operacional. Se faltar energia durante um passo, calcular o instante da falta e desligar cargas conforme a política; simplesmente limitar E a zero depois de executar ciência cria energia fictícia. Excesso após bateria cheia é energia descartada, não capacidade adicional.

O rádio consome potência elétrica DC; a potência irradiada RF é só uma parte dela. Se o catálogo informa consumo elétrico total do transmissor, não somar novamente seus watts de RF. Cargas incrementais devem ser distinguidas de modos que já incluem o consumo do barramento.

Caso didático de verificação, sem representar produto comercial:

No caso LEO acima: potência solar = 16,332 W; geração bruta por órbita = 16,022 Wh; consumo desse perfil = 10,051 Wh. Eclipse só com barramento requer 3,136 Wh retirados da bateria; se contiver os seis minutos de rádio, 4,189 Wh. A bateria tem 16 Wh na faixa utilizável. Esses totais são verificações de escala; a integração temporal ainda decide SOC, recarga e limites de pico.

Reduzir a área a 0,025 m² fornece somente 8,011 Wh brutos por órbita nesse mesmo caso: há déficit antes mesmo das perdas de recarga. Aumentar a bateria posterga a falha, mas não resolve um déficit energético recorrente.

Os cinco minutos de instrumento e seis de rádio são um perfil de teste. A campanha só deve executar observações e downlinks permitidos por sua agenda ou geometria; não prometer sobrevoo do Cerrado a cada órbita.

5. Contatos, Friis e taxa de dados

Separar três condições: visada geométrica; serviço de estação disponível; link RF suficiente. Estar acima do horizonte não garante estação agendada, compatibilidade de rádio ou taxa máxima.

Em uma esfera de raio R, satélite de raio r, elevação mínima ε:

\rho=\sqrt{r^2-R^2\cos^2\epsilon}-R\sin\epsilon.

Em LEO a 500 km, a distância inclinada varia de 500 km no zênite a 1695,09 km em elevação de 10°. Uma passagem exatamente sobre uma estação fixa, desprezando rotação terrestre, dura aproximadamente 7,383 min acima de 10°. Isso é um caso geométrico ideal, não duração universal de contato.

Para computar a elevação, colocar estação e espaçonave no mesmo referencial: com u sendo a direção local vertical da estação e l a direção unitária estação→espaçonave, ε = arcsin(u·l). Na Lua, também testar a interseção do segmento de rádio com o corpo lunar. Estação na Terra ainda precisa satisfazer seu próprio horizonte.

Friis, com ganhos lineares e perda multiplicativa L ≥ 1:

P_r=P_t G_tG_r\left(\frac{c}{4\pi df}\right)^2/L.

Em decibéis:

L_\mathrm{FS}=20\log_{10}(4\pi df/c),

P_r[\mathrm{dBW}]=P_t[\mathrm{dBW}]+G_t[\mathrm{dBi}]+G_r[\mathrm{dBi}]-L_\mathrm{FS}-L_\mathrm{outros}.

N_0=10\log_{10}(k_BT_\mathrm{sys})\ [\mathrm{dBW/Hz}],

C/N_0=P_r-N_0,\qquad E_b/N_0=C/N_0-10\log_{10}(R_b).

O relatório JPL 90-27 explicita a relação de C/N₀ com EIRP, perda de espaço livre, G/T e constante de Boltzmann [F09]. A NASA detalha os compromissos de frequência, abertura, atmosfera e apontamento [F10–F11].

Para uma abertura circular idealizada:

G=\eta_\mathrm{ap}\left(\pi D/\lambda\right)^2.

Logo: frequência maior aumenta a perda com ganhos fixos, mas também aumenta ganho para uma abertura física fixa. Esse é o motivo pelo qual “frequência mais alta perde mais” e “antena de mesmo tamanho ganha mais” podem ser verdadeiros ao mesmo tempo. Antena de maior ganho também exige melhor apontamento.

Taxa permitida = menor entre capacidade do equipamento, limite da largura de banda/modulação e limite do orçamento de Eb/N₀. Não usar Shannon como taxa automaticamente alcançável; não usar o mesmo Eb/N₀ mínimo para todas as modulações/códigos como se fosse um fato.

Caso didático LEO para validar cálculos: f = 2,2 GHz; Pt RF = 2 W; Gt = 2 dBi; Gr = 30 dBi; perdas agregadas = 3 dB; Tsys = 300 K; d = 1695,09 km. Resultado: FSPL = 163,880 dB; Pr = −131,870 dBW; C/N₀ = 71,958 dBHz. A 1 Mbit/s, Eb/N₀ = 11,958 dB. Se o código fictício exige 4 dB, a margem é 7,958 dB. Os 4 dB são parâmetro do exemplo, não requisito universal.

Uma taxa bruta de 1 Mbit/s com eficiência de protocolo de 0,8 por 6 min transporta 36 MB decimais. Definir se a taxa já é líquida antes de aplicar overhead; não descontar codificação duas vezes. Bytes, bits, MB e MiB devem aparecer consistentemente.

6. Latência, memória e ciência entregue

t_\mathrm{prop}=d/c.

Em LEO de 500 km, o tempo de propagação unidirecional no exemplo varia de 1,668 a 5,654 ms. A 384400 km, é 1,282 s. O número usual de 1,3 s lunar refere-se à propagação, não ao ciclo completo de operação; processamento, fila e disponibilidade de estação acrescentam tempo. NASA informa aproximadamente 3–22 min para comandos Terra–Marte conforme a geometria [F12].

Contrato recomendado de pacote: ID único, origem, instante de aquisição, tamanho, bytes transmitidos, qualidade, valor de ciência, instante final de recepção. Estados distintos: coletado → armazenado → em transmissão → em propagação → recebido. Só conceder ciência na recepção completa; retransmissões não pontuam outra vez.

Preservar memória finita, transferências parciais, interrupção de contato, política de descarte e tempo de emissão do último bit. O último bit chega após a duração da transmissão mais a propagação. Uma atividade enviada da Terra também só pode começar após chegada do comando, quando esse nível de detalhe estiver habilitado.

Invariantes: bytes únicos entregues ≤ adquiridos; ciência entregue não diminui nem cresce por repetição do mesmo pacote; não transmitir sem contato/potência; memória nunca negativa nem acima da capacidade; só executar uma coleta quando suas condições são válidas.

Para os seis registros MODIS existentes, conservar dados e procedência. Tratar uso em missão CubeSat como cenário educacional. Os limites do instrumento fictício e seu tamanho de arquivo não devem ser apresentados como características reais de MODIS. Visível/refletido depende de iluminação; sensores térmicos de emissão podem observar à noite. Não impor “somente de dia” a todo payload.

7. Delta-v, propelente e extensão lunar

Para um estágio com Isp constante e queima impulsiva ideal:

\Delta v_\mathrm{cap}=I_{sp}g_0\ln(m_0/m_f),

m_\mathrm{após}=m_\mathrm{antes}\exp[-\Delta v/(I_{sp}g_0)].

A NASA apresenta essa relação e suas hipóteses [F13]. Usar logaritmo natural e massas do mesmo veículo/estágio; massa final inclui tudo que permanece a bordo, inclusive propelente reservado. Não deduzir um consumo percentual constante por manobra. Custos de gravidade/arrasto do lançador não desaparecem na equação ideal.

Contrato do lançador: capacidade de massa e envelope, órbita/energia entregue, responsabilidade pelo estágio de transferência e preço didático ou cotação identificada. Para escape, C₃ = v∞²; tabelas de capacidade em LEO não podem ser reutilizadas como capacidade para Marte. Para transferências ligadas à Terra, C₃ entendido como duas vezes a energia específica pode ser negativo; não tirar raiz de C₃ negativo [F14].

Segunda campanha recomendada: orbitador lunar polar a 100 km, começando após entrega em transferência translunar. Evita adicionar pouso, solo, navegação terminal e sobrevivência de um rover antes de estabilizar operações orbitais.

Uma experiência educativa pode usar uma elipse terrestre com perigeu a 200 km e apogeu em 384400 km:

a_t=(r_1+r_2)/2,\quad
\Delta v_\mathrm{TLI}=\sqrt{\mu_E(2/r_1-1/a_t)}-\sqrt{\mu_E/r_1},

t_t=\pi\sqrt{a_t^3/\mu_E}.

Resultados: Δv TLI = 3,131 km/s; tempo = 4,978 dias. Isso é uma aproximação de transferência mínima simplificada, não a trajetória de Apollo nem uma solução de encontro lunar validada.

Na aproximação coplanar e tangencial, velocidade relativa de chegada ≈ 0,832 km/s. Para captura diretamente em círculo lunar de 100 km:

\Delta v_\mathrm{LOI}=\sqrt{v_\infty^2+2\mu_M/r_p}-\sqrt{\mu_M/r_p},

resultando ≈ 0,822 km/s. Fase, plano de chegada e geometria favorável à órbita polar são hipóteses do cenário. Não adicionar gratuitamente uma rotação de plano de 90°. Uma alteração separada de plano em velocidade v custa 2v sin(Δi/2) no caso ideal.

Separar no painel: serviço de lançamento/TLI; LOI da espaçonave; correções; manutenção; reserva. Correções e manutenção não receberam aqui valores “NASA”: se for necessário, selecionar uma reserva didática transparente. Exemplo de Isp = 320 s e requisito total de 1000 m/s demanda fração ideal de propelente de 27,29%; Isp e requisito são escolhas do exercício.

Na órbita lunar de 100 km: v = 1,63350 km/s; T = 117,791 min; eclipse por sombra lunar em β = 0 = 46,469 min. Também existem eclipses causados pela Terra. Um documento NASA de ambientes inclui, para seu caso de 26/06/2029 e altitude lunar de 100 km, até 233 min sem fluxo solar [F15]. Não transformar esse caso em frequência universal, nem dimensionar uma missão longa só pelo eclipse de 46 min.

Regiões polares de superfície não recebem Sol continuamente por definição: topografia cria iluminação prolongada e sombras permanentes [F17]. Isso não deve ser confundido com o eclipse de um orbitador. Para ciência lunar, uma câmera comum não revela automaticamente gelo em sombra permanente. O payload e sua condição de observação devem corresponder à tarefa científica.

8. MMRTG: o que é fato, e o que é modelo

• NASA/JPL documenta cerca de 110 W elétricos no início da missão, aproximadamente 45 kg, declínio de alguns por cento por ano e projeto para pelo menos 14 anos [F18]. A potência térmica é muito maior; não confundir W térmicos e elétricos.
• Uma ficha de configuração mais antiga informa 43,6 kg e 1975 W térmicos [F19]. Não tratar 43,6 e 45 como uma contradição que exige “média”: versão/configuração/arredondamento precisam acompanhar o dado.
• Pu-238 possui meia-vida de aproximadamente 87,7–88 anos [F20]. Isso descreve decaimento do combustível; a saída elétrica também cai com envelhecimento dos conversores.
• NASA/TM-2019-219935 usa dados de Curiosity para discutir cerca de 4,8%/ano, incluindo aproximadamente 0,8% de decaimento e 4% de degradação termelétrica [F21]. Não apresentar 4,8% como taxa garantida universal para todo MMRTG.
• Se o exercício adotar P(t) = 110 × 0,952ᵗ, rotular como modelo anual composto de referência histórica. Não multiplicar novamente pelo decaimento de Pu-238. Ele resulta em cerca de 55,25 W após 14 anos; somente a meia-vida daria 98,48 W, diferença educacional relevante.
• Não há nesta pesquisa evidência para preço corrente universal por unidade. A solicitação NASA New Frontiers de 2016 apresentou custos para propostas de US$ 103 milhões para um MMRTG, US$ 133 milhões para dois e US$ 163 milhões para três, em dólares FY2015, com custos de aprovação incluídos [F22]. Isso demonstra contexto de programa e custos não lineares; não é tabela de varejo de 2026.

MMRTG não é uma opção proporcional ao CubeSat LEO atual. Pode ser objeto de comparação no laboratório ou extensão de superfície/Marte. Não converter o catálogo existente em “hardware nuclear de 45 kg para o mesmo CubeSat”.

9. Margens: evitar falsa autoridade

O documento ARC-STD-8070.1 para sistemas classes C/D lista margens de massa seca por revisão: SRR 30%, PDR 20%, CDR 15% e SIR 5%, com condições para hardware de herança [F24]. Sua fórmula é:

margem\%=100\frac{alocação-CBE}{alocação}.

Isso não equivale a “adicionar 20% ao CBE”. Se CBE = 100 kg, uma margem de 20% da alocação exige 125 kg de alocação; adicionar 20% ao CBE resulta em 120 kg. Mostrar o denominador. Não generalizar margens de massa para potência, dados, propulsão ou custo.

No jogo, separar “reserva escolhida no cenário” de “regra publicada para determinado programa”. Indicadores melhores: SOC mínimo, memória máxima ocupada, margem RF durante contato, propelente restante e capacidade do lançamento. Uma média positiva em W não prova sobrevivência no eclipse.

10. Motor temporal futuro, sem substituir a agenda atual

Uma arquitetura pequena e verificável:

1. Relógio da simulação independente de animação; cenário e semente reprodutíveis.
2. Provedor de eventos/geometria: agenda existente, ou órbita analítica para laboratório. Ambos entregam sol/sombra, alvos visíveis e contatos ao mesmo contrato.
3. Máquina de modos: espera, coleta, transmissão, carga, proteção. Regras de simultaneidade e apontamento explícitas.
4. Em cada passo: determinar eventos e modos válidos; calcular geração/cargas; limitar atividades pela energia disponível; integrar energia e bytes; agendar recepções; atualizar ciência apenas ao receber.
5. Separar passos nos limites de contato, eclipse, conclusão de pacote e esgotamento de bateria. Passo inicial de 10 s é uma escolha de desempenho; validar contra 1 s.
6. Registrar ledger de energia, bytes e eventos. Renderização lê o estado; FPS não altera resultado.

Não é necessário integrar numericamente forças para ensinar Kepler: propagação analítica de dois corpos evita deriva. Se futuramente usar SGP4, não misturar elementos médios TLE com elementos osculadores de um Kepler simplificado, nem referencias TEME/J2000 sem conversão.

Testes de alto valor para o laboratório:

• r₁ = r₂ produz transferência Hohmann com Δv = 0.
• Δv = 0 não consome propelente; aumentar massa seca reduz capacidade para o mesmo propelente; queima nunca consome massa seca.
• Período e velocidade reproduzem as referências LEO/lunar acima.
• β = 0 dá maior eclipse do modelo; acima do β crítico o eclipse é zero.
• Painel fora do Sol ou voltado de costas gera zero; dobro da área dobra potência; dobro da distância ao Sol reduz potência a um quarto.
• 10 W por 360 s = 1 Wh; carga/descarga com perdas não cria energia; trocar potência elétrica nominal por área/eficiência equivalente produz o mesmo resultado.
• Dobrar distância do link aumenta FSPL em 6,0206 dB; dobrar potência RF aumenta potência recebida em 3,0103 dB; dobrar taxa reduz Eb/N₀ em 3,0103 dB.
• Sem contato, sem transmissão; pacote parcial não pontua; retransmissão não duplica ciência; latência aumenta linearmente com distância.
• Resultado em passos de 10 s converge ao de 1 s; mesmos eventos e decisões com FPS diferente.
• Casos impossíveis falham com causa específica: energia, memória, massa, ausência de contato ou link insuficiente.

O motor existente já tem testes próprios e oracle independente segundo a frente principal; estes são testes para o novo laboratório, não uma exigência de reescrever o que passou.

11. Bibliotecas e repositórios validados

CML recomenda releases oficiais porque commits intermediários podem não ter verificação formal concluída; a maturidade é documentada por modelo [F26]. Usar código NASA não certifica automaticamente uma implementação derivada. Para o MVP, uma implementação pequena das equações do laboratório é mais simples que incorporar MATLAB/C++ ou compilar um simulador inteiro.

12. Extensão Marte

Manter a mesma camada de energia, contato, memória e ciência. Acrescentar geometria heliocêntrica, chegada/captura e interrupções de comunicação por conjunção solar quando essa fidelidade for desejada.

O modelo circular coplanar com Terra a 1 au e Marte a 1,52371034 au [F30] produz transferência Hohmann de aproximadamente 258,87 dias; v∞ de saída terrestre ≈ 2,945 km/s; v∞ de chegada marciana ≈ 2,649 km/s. Não somar os dois como se fossem as queimas locais de saída/captura: cada uma depende da gravidade e da órbita junto ao planeta. Não prometer que 259 dias é a duração real de qualquer missão.

Irradiância no raio orbital médio adotado ≈ 586,21 W/m², cerca de 43% da terrestre. Esse é fluxo fora da atmosfera; painéis em superfície também dependem de atmosfera, poeira, estação e ângulo. Latência deve vir de distância instantânea; Terra e Marte não permanecem a uma distância fixa. MMRTG se torna uma comparação útil, sem eliminar bateria para picos de carga.

13. Fontes primárias consultadas

Todas as fontes físicas são NASA/JPL. Os quatro repositórios foram consultados nos canais dos próprios mantenedores. Datas de pesquisa não substituem datas originais dos documentos.

Fórmulas e resultados numéricos deste relatório foram recomputados localmente em Python, sem dependência dos valores exibidos pelo jogo. São casos de validação do modelo declarado.

A3 — UX, acessibilidade, stack e repositórios para Missão Ipê

Pesquisa concluída em 14/11/2026. Escopo: referências primárias NN/g, W3C, documentação oficial e repositórios indicados. Avaliação documental: os projetos externos não foram instalados, executados ou auditados numericamente nesta frente.

Recomendação: construir a nova experiência em Vite + React + TypeScript, com React Three Fiber para Terra e satélite, sobre o motor determinístico existente. A campanha Cerrado/LEO precisa primeiro de decisões legíveis, orçamento visível, diagnóstico contextual e comparação de tentativas. Não precisa adotar uma nova biblioteca de efemérides ou um simulador científico externo para justificar o 3D. Expansão lunar deve ser um módulo posterior com hipóteses e modelos próprios.

Contexto informado pela coordenação, não revalidado nesta frente: repositório AB-NASA-TEAM-IPE; motor com 64 combinações, duas agendas didáticas e seis registros históricos NDVI Terra/MODIS. A arquitetura proposta preserva esse motor e trata a interface como consumidora dos seus resultados. Não apresentar a visualização como órbita calculada ou cobertura real se o motor ainda não produzir essa informação.

1. Evidência de UX e aplicação concreta

NN/g descreve as heurísticas como princípios gerais, não uma especificação pronta. São especialmente relevantes visibilidade de estado, correspondência com a linguagem do usuário, controle e liberdade, prevenção de erros, reconhecimento e recuperação. A divulgação progressiva recomenda expor as escolhas principais e oferecer parâmetros especializados sob demanda. A orientação de onboarding favorece ajuda contextual recuperável em vez de depender de uma apresentação inicial que o usuário precisa memorizar. Mensagens de erro devem ser visíveis, construtivas e preservar o trabalho. [S01–S04]

As decisões abaixo são uma proposta de produto aplicada a esses princípios, não recomendações literais da NN/g nem resultados de teste com o público da Missão Ipê.

O catálogo deve ajudar a reconhecer peças: nome curto, imagem ou miniatura, função e duas ou três características decisivas. Unidades, definição de siglas e modelo físico ficam em “Entender este cálculo”. Evitar tooltips como único acesso a instruções essenciais, pois precisam funcionar em toque e teclado.

Não transformar toda margem pequena em bloqueio. Separar configuração inválida, restrição operacional violada, alerta de margem e oportunidade de melhoria. Um modo de diagnóstico pode permitir simular um projeto inviável para aprender com ele; a interface deve explicar a condição antes de iniciar. Se um botão ficar indisponível, a razão e o caminho de correção permanecem visíveis.

2. Tutorial, ritmo e aprendizado

Proposta de primeira experiência: tutorial opcional e retomável com quatro tarefas reais — selecionar uma peça, observar uma mudança no orçamento, escolher a agenda e simular. Exibir uma dica no ponto da ação; permitir fechar e consultar novamente. A ajuda acompanha o trabalho, sem exigir lembrar uma sequência de telas. Essa escolha aplica a orientação contextual da NN/g. [S03]

Começar o hangar sem giro automático de câmera. Oferecer vistas “Geral”, “Instrumento” e “Energia”, além de “Recentrar câmera”. Manter “Reiniciar missão” visualmente separado; reiniciar câmera não apaga configurações. O histórico permite desfazer uma troca e duplicar uma tentativa. Acelerações de reprodução precisam ter rótulo explícito, por exemplo “1 segundo da interface representa X minutos da missão”, conforme o modelo.

O debrief pode convidar: “Qual mudança você faria primeiro?” antes de mostrar a sugestão. A sugestão deve ser produzida por regras do modelo e incluir o custo da alternativa. Não gerar uma nota de engenharia única que esconda objetivos incompatíveis: custo menor, margem maior e mais ciência podem apontar para soluções diferentes. Um painel com três indicadores e seus critérios explica melhor o compromisso.

Para os dados Terra/MODIS, distinguir observação histórica usada no desafio, resultado calculado pelo jogo e representação ilustrativa. Uma imagem bonita da Terra não valida previsão de NDVI, resolução de um instrumento ou cobertura de um satélite fictício. Rótulos de fonte e data pertencem à ficha de evidência e ao relatório.

3. Acessibilidade como parte da interface principal

Meta proposta: atender WCAG 2.2 AA; ainda depende de auditoria da implementação. A redução de animações por interação é uma recomendação adicional alinhada ao critério 2.3.3, que é AAA — não confundir seu nível com AA. [S05–S12]

Modos acessíveis não devem diminuir o conteúdo científico ou limitar a pontuação. O modo 2D também é a alternativa para WebGL indisponível, falha de carregamento ou dispositivos modestos. A escolha pode ficar visível em “Visualização: 3D / 2D”; a interface não precisa expor jargão de GPU para o jogador.

4. Avaliação dos seis repositórios indicados

“Disponível” significa página pública/README consultável nesta pesquisa. Não significa compilação confirmada, compatibilidade atual de dependências ou qualidade científica auditada.

NASA: a política consultada permite, em geral, utilização educativa/informativa de seu conteúdo sob as diretrizes, pede reconhecimento da fonte e não transfere direitos sobre material de terceiros. Marca e endosso têm tratamento próprio. A ação prática é manter um manifesto de assets com origem, autor, licença/termos, modificações e texto de crédito, mais uma tela “Fontes e créditos”. [S15]

5. Efemérides, órbitas e otimização são responsabilidades diferentes

No beta Cerrado/LEO: usar o modelo atual para resultados e a geometria que ele de fato disponibiliza. Não adicionar Astronomy Engine apenas para desenhar a Terra. Se o modelo não fornece estado orbital, a órbita de apresentação deve ser explicitamente ilustrativa e não determinar o resultado da missão.

Astronomy Engine é uma alternativa MIT para posições e eventos astronômicos no navegador. O projeto documenta vetores heliocêntricos/geocêntricos e precisão angular de aproximadamente um minuto de arco, insuficiente para navegação de espaçonaves. Seu escopo documentado não é um otimizador de transferências nem o cálculo do orçamento Δv de uma missão. Posições podem ser entradas de outro modelo; não substituem solver, condições de contorno e modelo propulsivo. [S24]

JPL Horizons fornece efemérides e estados; para uma expansão, um conjunto de dados pré-calculado e versionado evita depender de consulta de rede durante o jogo. Registrar corpo central, referencial, escala de tempo, unidades, período e método de interpolação. Usar estados geométricos quando o cálculo exigir geometria física; não misturar posições aparentes corrigidas por tempo de luz com estados dinâmicos. Essa escolha depende do cálculo científico e deve ser validada. [S25]

ESA PyKEP/kep3 é uma opção real de projeto de trajetória: documenta solução de Lambert e formulações de otimização, inclusive baixo empuxo. O repositório atual identifica MPL 2.0. A linha 3 está em evolução e a documentação/README consultados apresentam diferenças sobre disponibilidade de pacotes; selecionar uma versão comprovada por execução e fixar a dependência. [S26–S28] Recomendação de arquitetura: processo offline para gerar casos de referência ou serviço científico isolado numa expansão; não presumir que um pacote Python/C++ possa entrar diretamente no bundle Vite.

Um solver de Lambert fornece um arco sob hipóteses específicas. Δv de partida, chegada, captura e margens ainda dependem das condições da missão; otimizar um arco não prova viabilidade operacional total. A escolha de modelo lunar deve preceder a implementação visual dessa expansão. [S27]

6. Arquitetura proposta para implementação

React Three Fiber é um renderer React para Three.js. A documentação atual associa R3F 8 a React 18 e R3F 9 a React 19; R3F 10 aparece como alpha. Para o beta, manter um par estável compatível com o repositório e fixar versões. Vite oferece template React/TS; a documentação atual pede Node 20.19+ ou 22.12+, podendo haver exigência maior de templates. [S29–S30]

Zustand é adequado ao estado de produto. persist permite armazenar e selecionar campos persistidos; subscribeWithSelector observa fatias específicas. Proposta: configuração e preferências pequenas em armazenamento local; histórico volumoso em IndexedDB, se necessário. Versionar o esquema e tratar falhas de armazenamento sem perder a edição corrente. O usuário deve saber se “salvo” significa apenas neste navegador. [S31–S32]

Separar tempo físico, reprodução e renderização. A execução científica produz um resultado/série estável; mudar FPS, câmera ou velocidade visual não muda ciência, custo ou consumo. Em R3F, usar useFrame e referências para transformações rápidas. A documentação recomenda evitar setState dentro do loop e reutilizar geometrias/materiais. [S33] Durante edição estática, renderização sob demanda reduz trabalho; durante playback, atualizar apenas o necessário. [S34]

Modelos selecionados devem chegar ao produto como GLB/glTF, com orçamento de tamanho e testes no aparelho alvo. Three.js oferece GLTFLoader e extensões de compressão; KTX2Loader trata texturas GPU com transcodificação. [S35–S36] Compressão, sombras, atmosfera e pós-processamento são escolhas medidas: um planeta legível e o satélite selecionável valem mais que efeitos que atrasam feedback. Deixar cenas e assets pesados em carregamento tardio; carregar o briefing e os controles primeiro.

Para eventual estado orbital, definir contrato explícito com position, velocity, frame, origin, epoch, timeScale e units. Manter valores físicos separados de escala/offset de cena. Tipos TS ajudam, mas não substituem validação numérica, conversão de unidades ou testes de referencial.

7. Relatório causal e comparação de tentativas

Resultado proposto: inputs, modelVersion, scenarioVersion, summary, constraints, events, evidence, sourceRecords e assumptions. Cada problema aponta ruleId, métrica, valor, limite e campos de configuração envolvidos. O texto visível é formatado a partir desses dados, com linguagem pt-BR. Isso permite explicar a execução sem inventar uma narrativa após o cálculo.

Só afirmar uma causa específica se a regra do motor a demonstrar ou uma execução contrafactual controlada confirmar a diferença mantendo o restante igual. Para interações entre várias escolhas, o relatório deve reconhecer a combinação. Não atribuir a uma única peça a diferença de resultado entre duas tentativas que mudaram peça, agenda e cenário.

Comparação mínima: configuração A/B, mudanças, métricas lado a lado, deltas, condições cumpridas e limitações. Uma tentativa deve ser imutável após executar; editar cria um novo rascunho. Guardar a versão do modelo evita comparar como equivalentes resultados calculados sob regras diferentes. Se a expansão introduzir sorte, guardar a semente e usar condições iguais para comparação didática.

8. Critérios de aceite e validação focada

1. Primeiro contato: o participante identifica objetivo, orçamento e sucesso sem ajuda do facilitador.
2. Montagem: trocar uma peça atualiza a representação, a seleção e os valores no mesmo fluxo; é possível desfazer.
3. Compreensão: o participante explica um compromisso real do modelo com suas palavras, não apenas repete uma legenda.
4. Diagnóstico: diante de uma configuração inviável, encontra a causa e modifica uma escolha pertinente.
5. Ritmo: pausar, acelerar, abrir ajuda e trocar 2D/3D preserva a tentativa e seu resultado.
6. Comparação: identifica o que mudou entre duas tentativas e relaciona a diferença ao objetivo declarado.
7. Acesso: briefing → montagem → execução → debrief completo por teclado; testar leitor de tela, toque, zoom e movimento reduzido.
8. Regressão científica: para configurações conhecidas do motor, a nova UI produz os mesmos resultados e não introduz cálculos paralelos.
9. Robustez visual: ausência de WebGL ou falha de asset oferece modo 2D funcional; teste em dispositivo modestamente equipado.
10. Proveniência: todos os arquivos externos incorporados têm origem e termos registrados; conjunto de dados mostra data e limites.

Testes com novatos e pessoas com repertório técnico devem observar conclusão, erros, tempo até recuperar uma restrição e compreensão dos trade-offs. Não usar rapidez como único critério de aprendizagem. As metas quantitativas de FPS, payload e tempo de carregamento devem ser definidas pelo aparelho/rede alvo e medidas; esta pesquisa não mediu performance da aplicação.

9. Prioridade de implementação

Agora: preservar motor e fontes; construir briefing curto, hangar R3F, orçamento fixo, agenda, validação, debrief e comparação; garantir equivalência 2D e créditos. Usar poucos assets com licença confirmada.

Depois de testar o beta: refinar explicações conforme erros observados, histórico/exportação, cenários adicionais e visualização de séries realmente calculadas.

Expansão lunar: definir objetivos e regime orbital, validar solver/efemérides e referências, então adicionar conteúdo e cena. MuSCAT, CML e PyKEP são candidatos a referência ou infraestrutura científica futura, com papéis diferentes; nenhum deles deve substituir o motor atual por mera associação à NASA/ESA.

Fontes primárias consultadas

Missão Ipê — roteiro de investigação em 10–15 minutos

Revisão R9, 14 de novembro de 2026. Roteiro para a campanha ipe-64-v1, motor 0.1.1-rd. Os resultados abaixo foram recalculados com Node v24.22.1; são resultados do modelo educacional, não previsões de um satélite real.

O objetivo é entregar 6 de 6 registros científicos válidos, respeitando as condições do motor, até o fim de 180 minutos simulados. O envelope é de 3,6 kg e 86 créditos. Entregar seis registros com um projeto fora do envelope não significa missão cumprida. A proposta exploratória de 4/6 presente na pesquisa A1 não foi adotada.

Preparação do facilitador

Use uma sessão sem rascunho anterior, ou confira as seis escolhas da configuração inicial na tabela. Uma sessão existente pode recuperar um projeto salvo. A atividade pode ser individual ou feita por uma pequena equipe que discute o mesmo projeto; o roteiro não pressupõe multiplayer online.

Explique três limites em linguagem simples antes de começar. Os seis registros são dados históricos de Terra/MODIS; o CubeSat fictício processa e transporta arquivos do exercício. O relógio de 180 minutos é uma agenda didática e não comprime duas datas de observação real em três horas. A campanha possui seis decisões de catálogo: não permite configurar lançamento, órbita ou Δv. A cena 3D ilustra a missão; o laboratório de física explora modelos separados e não muda o resultado da campanha.

Não antecipe a configuração vencedora. A sequência é previsão → execução → investigação → redesign. Use a busca de alternativas depois de uma tentativa própria, quando a pessoa já formulou uma explicação.

Roteiro de 12 minutos, com extensão opcional até 15

O formulário exige uma hipótese e pelo menos oito caracteres de justificativa. Esse limite é uma condição de interação, não uma medida de qualidade da explicação. Não trate o cumprimento do formulário, a vitória ou a consulta à solução como demonstração de aprendizagem.

Resultados que o facilitador pode conferir

Mbit significa milhão de bits, usando unidades decimais. A taxa do rádio já é serviço útil; não desconte uma segunda vez um overhead inventado. A reserva da bateria inicial é 2,4 Wh; a reserva da bateria maior é 3,6 Wh.

No cenário curto inicial, duas janelas de 240 segundos a 960.000 bit/s oferecem 460,8 Mbit de serviço. Cada registro em BANDAS exige 180 Mbit. Assim, dois registros são recebidos por completo; 100,8 Mbit de um terceiro registro não bastam para conceder mais um resultado científico. O restante permanece em fila. A menor energia de 9,9236 Wh fica acima da reserva de 2,4 Wh: a falha observada é de entrega, não de esgotamento da bateria.

A configuração testemunha e sua explicação

Uma busca completa das 64 configurações no contato curto encontrou 9 projetos bem-sucedidos, 49 falhas operacionais e 6 projetos inválidos, com zero casos indeterminados. A distância mínima em relação à configuração inicial é duas escolhas, com uma única testemunha nessa distância:

{
  "battery": "large",
  "panel": "standard",
  "processing": "index",
  "radio": "economy",
  "buffer": "large",
  "policy": "every-contact"
}

ÍNDICE reduz os seis lotes de 1.080 para 360 Mbit, de modo que cabem no serviço de contato disponível. A troca aumenta a carga durante processamento de 26 para 38 W. Sob o fator de geração do cenário, o painel de 18 W fornece 9,9 W nessa operação. A bateria precisa fornecer (38 − 9,9) / 0,95 ≈ 29,58 W: a opção de 16 Wh permite apenas 20 W, enquanto a opção de 24 Wh permite 35 W. A opção de bateria muda capacidade e limite de potência; neste contrafactual, é o limite de potência que elimina a falha de pico.

Somente trocar para ÍNDICE termina a execução por pico no instante de 600 s, antes da produção do primeiro lote. Somente trocar a bateria mantém a insuficiência de serviço de comunicação e entrega 2/6. É a combinação que atende às condições desse caso. Os valores históricos de NDVI e a política científica são os mesmos nas duas rotas de processamento.

“Menos mudanças” significa menor número de escolhas diferentes, sob o mesmo cenário e objetivo. Não significa menor preço, menor massa ou projeto ótimo fora deste catálogo. Por exemplo, bateria maior + painel compacto + ÍNDICE + memória compacta, mantendo rádio econômico e todos os contatos, também entrega 6/6 no cenário curto por 75 créditos e 3,10 kg, mas exige quatro escolhas diferentes da inicial.

Contrafactuais opcionais

Escolha um exercício e mantenha o restante fixo. Peça uma previsão antes de executar e uma explicação apoiada nos eventos depois.

Falha de pico encerra a operação neste motor. Não a apresente como um modo seguro que depois retoma a coleta, pois essa recuperação não é modelada.

Uma extensão de física de três minutos

O laboratório é independente da campanha. Selecione uma relação, altere uma variável e observe a mudança. Voltar ao hangar deve preservar o projeto; os valores do laboratório não passam a ser novos componentes do catálogo.

O laboratório usa raio terrestre médio arredondado de 6.371 km. Um cálculo de referência que usa raio equatorial de 6.378,1366 km fornece números ligeiramente diferentes; compare hipóteses antes de atribuir a diferença a erro de fórmula.

O que o dado permite dizer

Os seis registros são três pixels selecionados e duas datas de composição MOD13Q1.061. Os compostos começam em 28/08/2024 e 13/09/2024; os dias de observação preservados no pacote são 01/09/2024 e 23/09/2024. O NDVI é calculado com vermelho e infravermelho próximo e passa por uma política de qualidade declarada. Não descreva esse conjunto como amostra representativa de todo o Cerrado.

O jogo altera a disponibilidade e a entrega dos registros. Ele não altera os valores históricos e não demonstra que uma mudança de NDVI foi causada por fogo, desmatamento, seca, produtividade ou saúde da vegetação. Um hash confere identidade dos bytes; sozinho, não autentica a origem nem valida uma interpretação científica.

Observação de aprendizagem e acesso

Registre separadamente comportamento e interpretação. “Encontrou o evento de pico e citou o limite de 20 W” é observação. “Aprendeu engenharia espacial” é uma conclusão que este roteiro não comprova. Para uma avaliação posterior, recolha previsão, explicação após execução e resposta a um caso novo; analise erros e autocorreções, além do sucesso da missão.

O fluxo principal deve ser possível por controles HTML: botões, seleção de subsistema, opções, campos, eventos e linha do tempo. A alternativa 2D deve preservar escolhas e resultados. O facilitador pode usar essa vista desde o início. A presença desses controles e os testes DOM não equivalem a uma auditoria de teclado, leitor de tela, contraste ou WCAG em navegador real.

Fontes e rastreabilidade

• Implementação auditada: src/core/catalog.ts, src/core/engine.ts, src/core/science.ts, src/core/search.ts, src/data/science-data.ts, src/lab/physics.ts e dados preservados em public/data/.
• MODIS, MOD13 Collection 6.1 User Guide, versão 3.10, setembro de 2019: produto, NDVI, escalas e campos de qualidade. Consultado nesta revisão em 14/11/2026.
• ORNL DAAC, documentação do serviço de subconjuntos: origem do serviço declarada nos recibos. Os hashes e os valores dos arquivos já preservados foram conferidos localmente; esta revisão não repetiu a aquisição remota.
• JPL, Astrodynamic Parameters: parâmetro gravitacional terrestre e velocidade da luz, consultado em 14/11/2026.
• NASA Glenn, Ideal Rocket Equation: relação ideal entre massas, Isp e Δv, consultada em 14/11/2026.
• W3C, WCAG 2.2: referência para a futura auditoria de acesso, consultada em 14/11/2026. Não constitui certificação deste protótipo.
• Sínteses de pesquisa fornecidas à revisão: a1-desafio.md, a2-fisica.md e a3-ux-tecnologia.md, de 14/11/2026. Recomendações pedagógicas foram confrontadas com o comportamento efetivamente calculado; o limiar proposto de 4/6 não substitui o contrato 6/6.

Missão Ipê — registro factual de QA R9

Data: 14/11/2026. Revisão independente A6. Projeto: missao-ipe-orbit, origem informada oalexandrebelo/AB-NASA-TEAM-IPE, base recuperada 73162276b46227e8965eed2b91a7dc8edae70b96. Este documento descreve verificações locais; não declara publicação, homologação de voo, certificação WCAG ou aprendizagem demonstrada.

Escopo e ambiente

Revisados o motor fechado, as seis escolhas do catálogo, os dois cenários, o pacote científico preservado, o fluxo de previsão e redesign, persistência, ponte assíncrona, testes existentes e as funções do laboratório de física. A pesquisa A1/A2/A3 foi lida como subsídio, sem tratar propostas como comportamento implementado.

• Node executado: v24.22.1.
• Motor da campanha: 0.1.1-rd; catálogo: ipe-64-v1; esquema do resultado: 1.
• Requisito científico preservado: 6/6 registros válidos, com as demais restrições do motor. A proposta exploratória A1 de 4/6 não foi adotada.
• A campanha não calcula lançamento, propagação orbital ajustável ou Δv. A cena é ilustrativa. O módulo src/lab/physics.ts é independente e não modifica a configuração nem o ledger da campanha.
• Nenhum arquivo de implementação ou dependência foi editado por A6. Foram adicionados dois contratos de proveniência em tests/ux-contract.test.mts porque uma divergência real de bytes foi encontrada. As asserções anteriores foram preservadas.

Matriz de execução

Resultado numérico de todo o catálogo

Sucesso requer o estado outcome === 'success', não apenas o contador 6/6. Há seis projetos inválidos no cenário longo que ainda calculam seis registros entregues. No curto, cinco dos seis inválidos entregam seis registros e um entrega três. O envelope não é compensado por ciência entregue.

A testemunha mínima é única a distância 2: large / standard / index / economy / large / every-contact, na ordem bateria / painel / processamento / rádio / memória / política. Em relação à inicial, muda bateria e processamento. Cada execução de referência tem residual de conservação de energia zero. A suíte completa verifica conservação de bits e energia em todo o domínio.

As seis alternativas de distância 1 no cenário curto falham:

“Distância mínima” é o número de escolhas diferentes dentro das 64 combinações. Não é menor custo, menor massa ou ótimo contínuo. O guia inclui um projeto curto de 75 créditos e 3,10 kg, viável a distância 4, para tornar o critério explícito.

Proveniência: achado e correção verificável

Achado inicial: os três arquivos mod13q1-{A,B,C}-raw.json tinham 4.233 bytes, mas seus recibos declaravam 4.232. O pacote mod13q1-research-pack.json também não correspondia ao hash publicado pela aplicação. Os quatro terminavam com um LF extra após o conteúdo recuperado.

Uma verificação sem modificar os arquivos demonstrou que remover somente o último byte de cada um restaurava exatamente os hashes esperados. A coordenação restaurou os bytes usando também o SHA do blob upstream como condição, sem reescrever recibos nem trocar o hash científico. Os dois testes novos passaram em seguida.

Os seis registros passam a política declarada de QA e a comparação entre NDVI reconstruído e produto. Os subconjuntos retidos têm um pixel por local e data; esta verificação não introduziu uma agregação espacial. As observações de 01/09 e 23/09/2024 foram conferidas contra os campos de dia do ano do serviço.

O pacote histórico possui status RESEARCH_ONLY_NOT_GAME_DATA_CONTRACT; o contrato fechado da campanha está nos tipos, registros compilados, política científica e versões do motor. Preservar essa distinção. Hashes verificam identidade, não autenticidade de quem forneceu um arquivo. A amostra de três locais escolhidos não representa toda a região e não permite atribuição causal de mudanças de vegetação.

Revisão dimensional e de domínio do laboratório

Foram conferidas as cinco funções de src/lab/physics.ts sem importá-las no motor da campanha. EngineeringLab.tsx declara hipóteses de uso. Os resultados abaixo empregam as entradas do teste independente, não necessariamente os valores iniciais da interface.

Relações verificadas: período cresce com altitude; fração de eclipse menor que meia órbita no domínio; dobro da área dobra a potência; dobro da distância ao Sol reduz potência a um quarto; incidência 90° produz zero; 10 W × 360 s = 1 Wh; eficiência e reserva não criam energia; propelente zero produz Δv zero; maior massa seca reduz Δv para mesmo propelente; dobrar distância de rádio soma 6,0206 dB à perda, reduz potência recebida a um quarto e dobra latência; dobrar potência RF acrescenta 3,0103 dB ao recebido.

As 14 entradas inválidas incluem altitude fora de 200–2.000 km, NaN, área negativa, eficiência acima de um, incidência acima de 90°, distância solar zero, reserva igual a um, duração negativa, massa seca zero, propelente negativo e entradas não positivas do rádio. Foram rejeitadas explicitamente. A relação de potência recebida foi comparada com tolerância relativa de escala de ponto flutuante, não por igualdade bit a bit de fórmulas logarítmicas equivalentes.

Não há bloqueador dimensional identificado nessas funções. O valor LEO difere ligeiramente da tabela A2 porque aquela pesquisa adotou raio equatorial de 6.378,1366 km; a implementação declara o raio médio arredondado. Essa diferença de hipótese não é erro aritmético. Não usar os tempos do laboratório como agenda de contato de Rio Verde.

UI, estado, armazenamento e rotina assíncrona

Constatado por leitura de código: a configuração de cada execução é copiada antes do cálculo. requestId e AbortController invalidam trabalho antigo; o cliente Worker valida envelope, identidade de configuração/cenário e resultado, termina o Worker ao resolver, e tem um limite de 15 segundos que gera erro técnico, sem classificar uma missão. O caminho sem Worker usa o mesmo motor.

O resultado anterior é preservado quando um replay inválido falha antes de aplicar nova entrada. Importação válida é recalculada e não conta como previsão própria. A busca exige tentativa própria no cenário. Aplicar uma alternativa cria um novo projeto e limpa a previsão, sem promovê-la automaticamente a resultado executado. Os testes DOM existentes exercitaram esses contratos na rodada R9 com a cena R3F integrada.

O IndexedDB salva snapshots, usa transação concluída como confirmação, confere integridade de leituras e controla conflito de revisão do rascunho. A suíte executada inclui escritas concorrentes, falha de quota, abort após sucesso de request, corrupção e preservação do rascunho. fake-indexeddb reproduz o contrato da API para testes; não demonstra durabilidade real de um navegador ou entre dispositivos. O diário em localStorage é relato local, não evidência inviolável.

A navegação usa botões, o catálogo usa fieldset e rádios, e o formulário usa rótulos explícitos. A mudança de vista tenta focar o elemento principal. Os diálogos usam <dialog> nativo. Isso é evidência de implementação semântica, não execução de teclado real. A animação do relatório percorre estados já calculados e não recalcula ciência.

Recomendações comunicadas e estado ao fechar a rodada:

1. Atendida na implementação: a tela de fontes recebeu links para pacote, recibo A, ORNL e guia MOD13. O link adicional ./research/index.html ainda precisava de arquivo/rota final na árvore pública quando inspecionado; sua entrega foi sinalizada à coordenação.
2. Atendida na implementação: chooseComponent limpa uma previsão já selecionada, preserva a justificativa e anuncia que a hipótese deve ser revista. Isso impede executar silenciosamente com a mesma seleção após uma troca de peça. Esse novo ramo foi conferido por leitura; não possui caso dedicado na suíte DOM existente.
3. Atendida no texto do produto: o cabeçalho declara “SIMULAÇÃO LOCAL” e a tela de fontes “Local no navegador”. Recarga offline continua fora do que A6 verificou.
4. Preservada e conferida: o estado geral vem de outcome, inclusive em projetos inválidos que entregam 6/6.

A coordenação adicionou CompareDialog durante a revisão. A leitura confirmou rótulos dos seletores A/B, tabela de escolhas e métricas, indicação textual de opções alteradas, aviso quando os cenários diferem e ressalva sobre múltiplas mudanças. A suíte DOM existente passou com essa integração, mas não abre e opera esse novo diálogo; sua interação e apresentação devem ser conferidas no navegador.

Verificações manuais ainda necessárias

Estas são tarefas de validação pendentes por A6, não falhas observadas:

• Completar observatório → hangar → previsão → execução → relatório → redesign usando somente teclado; conferir foco visível, ordem e retorno do foco após fechar diálogos.
• Conferir controles principais em 320 CSS px, zoom de 200% e 400%, sem ocultar ações de execução, cancelamento ou navegação.
• Testar leitor de tela, nome/estado de cada controle, mudanças de status sem anúncios excessivos e equivalência do conteúdo científico fora do canvas.
• Testar preferência de movimento reduzido, pausa, retorno de aba oculta e alternância 2D/3D sem alterar projeto ou resultado.
• Verificar WebGL indisponível e perda de contexto em navegador real; conferir performance em dispositivo alvo, carga inicial e erro de asset.
• Testar falha real de armazenamento, importação/exportação de arquivo, tentativa concorrente em abas e Worker em navegador.
• Confirmar o significado de “offline” no artefato distribuído, incluindo recarga sem rede. Não inferir esse comportamento dos testes Node.
• Avaliar compreensão com participantes usando o roteiro didático. Não confundir completar a missão com aprender o mecanismo.

Fontes e material consultado

Evidência primária de comportamento: código e testes do repositório, respostas preservadas de ORNL DAAC e recibos em public/data/. As três frentes de pesquisa foram fornecidas em research/a1-desafio.md, research/a2-fisica.md e research/a3-ux-tecnologia.md do workspace de pesquisa. A1 registra que não conseguiu abrir integralmente a página específica do desafio 2026; esta revisão não transforma essa limitação em uma leitura verificada.

Fontes externas reabertas nesta revisão em 14/11/2026:

• MOD13 Collection 6.1 User Guide, versão 3.10, setembro de 2019: produto e campos científicos.
• JPL Astrodynamic Parameters: μ terrestre de DE440 e velocidade da luz.
• NASA Glenn — Ideal Rocket Equation: relação ideal de Δv.
• W3C WCAG 2.2: referência de critérios de acesso, sem auditoria completa nem declaração de conformidade.

Outras referências rastreáveis usadas pelas frentes de pesquisa: ORNL MODIS Web Service, NASA Systems Engineering Handbook, NASA Small Spacecraft Power e NASA Small Spacecraft Communications. A6 não realizou uma nova consulta remota a todas elas.

Registro final de integração

Rodada final executada em 14/11/2026, aproximadamente 16:07 UTC, depois da integração dos arquivos R3F e do laboratório:

A suíte UI exercitou previsão obrigatória, execução inicial longa 6/6, transferência curta 2/6, busca de 64/64 com distância mínima 2, preservação após replay inválido, aplicação de testemunha como projeto ainda não executado, nova previsão e resultado 6/6. Também verificou importação sem tentativa própria e resultado/exportação preservados quando IndexedDB e localStorage falham. O fallback “3D indisponível · equivalente 2D ativo” foi alcançado pelo ambiente sem contexto, sem mock de física.

Evidência escrita pelo runner: evidence/ui-dom-test.tap e evidence/ui-dom-test.json. O relatório JSON registra início às 2026-11-14T16:07:05.781Z, fim às 2026-11-14T16:07:07.512Z, Node v24.22.1, contexto jsdom e limites. O shim de <dialog> só alterna o atributo open; ele não exercita foco modal real. Worker real, durabilidade de navegador, layout, árvore de acessibilidade, GPU e recarga offline não foram simulados como se tivessem sido verificados.

Houve um aviso não bloqueador de depreciação THREE_CJS_DEPRECATED no ambiente Node por require("three") em dependência. Não houve falha relacionada ao aviso. Nenhuma alteração em tests-ui/ foi necessária.

Bloqueadores de domínio encontrados e resolvidos: a divergência de bytes da proveniência foi restaurada e protegida por testes; a incompatibilidade transitória de props foi resolvida. Bloqueadores de domínio/compilação pendentes ao fechar esta rodada: nenhum observado. A inspeção de navegador é uma frente separada da coordenação; A6 não a realizou nem a substitui por uma declaração de acessibilidade. Antes de divulgar links de fontes, confirmar que a rota de pesquisa está presente no artefato final.

QA de navegador — Missão Ipê R9

Data: 14/11/2026. Verificação manual da coordenação no Chrome do ambiente de prévia, depois da integração das seis frentes. Esta verificação complementa QA-R9.

Resultado observado

• Abertura, hangar e sala de missão renderizados e operados no navegador.
• Configuração inicial: cenário longo terminou em 6/6, 1.080 Mbit recebidos, 3,05 kg, 71 créditos.
• Mesma configuração no cenário curto: 2/6, 460,8 Mbit recebidos e 619,2 Mbit na fila.
• Consulta pelo botão da interface: 64/64 combinações, 9 viáveis, 6 inválidas e 49 falhas; menor distância de 2 escolhas.
• Aplicação do projeto sugerido exigiu uma nova previsão antes de executar. Bateria 24 Wh + ÍNDICE chegou a 6/6, 360 Mbit recebidos, fila zerada, 3,50 kg e 84 créditos no cenário curto.
• Comparação abriu com as duas execuções recentes, mostrou cenários e escolhas, e diferenciou massa, créditos, energia mínima e quantidades de dados. Quando as condições diferem, o diálogo informa a limitação da comparação.
• Escape fechou o diálogo. Após a correção de foco, document.activeElement voltou ao botão Comparar missões.
• O caderno manteve execuções após recargas durante desenvolvimento; abrir um resultado preservado reproduziu seus indicadores. Isso não constitui garantia de durabilidade em todos os navegadores.

Laboratório

Os controles foram operados pelo teclado e seus resultados visíveis mudaram:

A análise numérica independente e os testes das equações estão em QA-R9. O laboratório não altera a configuração da campanha.

Responsividade e correções encontradas

A composição foi inspecionada também em um iframe de 390 × 844 px. Devido à barra de rolagem, a área útil medida foi de 375 px. Isso verifica regras CSS em viewport estreito; não substitui teste em aparelho físico.

Foram corrigidos durante a inspeção:

1. Duas legendas ocupavam o mesmo espaço no hangar: removida a legenda duplicada.
2. O título da abertura mantinha white-space: nowrap e uma regra antiga ocultava a primeira quebra: o título passou a caber e a separar suas frases.
3. O seletor de cenário herdava fundo claro e orientação horizontal no texto secundário: corrigidos fundo e empilhamento.
4. A tabela de comparação herdava cabeçalho claro com contraste insuficiente: aplicado o tema escuro e aumentado o texto.
5. Escape não devolvia o foco ao acionador do diálogo: restauração explícita implementada e observada.
6. As regras técnicas apareciam como expressões de código: o painel agora apresenta critérios em linguagem natural e unidades. Identificadores continuam disponíveis em uma seção expansível.

Depois das correções, abertura, hangar e formulário apresentaram scrollWidth = clientWidth = 375 px na área útil móvel. O formulário foi preenchido e habilitou a execução. As capturas estão em evidence/ui.

Limites desta verificação

O navegador selecionado exibiu o equivalente 2D após a tentativa de inicializar WebGL2. A cena R3F foi compilada e o caminho de fallback permaneceu operacional. A aparência e o desempenho da cena 3D não foram validados nesta sessão.

Não foram realizados estudo com participantes, auditoria completa WCAG, teste com leitor de tela, ensaio em celular físico, medição de FPS ou teste de recarga offline. Movimento reduzido e suspensão da animação têm implementação revisada, mas não foram alternados pelas preferências do sistema neste navegador.

As mensagens de erro observadas no console pertenciam à extensão do ambiente; a consulta filtrada pela origem local da aplicação não retornou erros naquele momento. Não se declara ausência universal de erros.

Refinamento R10 — ConOps, requisitos e retorno científico

Nova verificação em 14/11/2026, após integrar as referências adicionais fornecidas por AB.

• O briefing apresenta destinatário fictício, pergunta sobre a vegetação, entrega esperada, condições previstas e caminho dos arquivos até o solo.
• A revisão pré-voo inicia fechada. No projeto inicial com contato curto, a UI mostrou 1.080 Mbit previstos, teto de transmissão de 460,8 Mbit, memória de 1.536 Mbit, demanda de pico de 16,95 W e limite de descarga de 20 W. A energia acumulada permanece dependente da execução.
• A hipótese de transmissão foi registrada pela interface e executada: 2/6 registros, 460,8 Mbit recebidos, 619,2 Mbit em fila e mínimo de 9,92 Wh.
• A comparação científica dessa tentativa exibiu somente o par completo do ponto A: 1 de 3 comparações. B manteve uma recepção parcial; B/C não receberam valores NDVI ou diferenças preenchidos a partir do arquivo de origem.
• O resultado preservado da configuração bateria 24 Wh + ÍNDICE mostrou 3 de 3 comparações e 6/6 registros, 360 Mbit, 3,50 kg e 84 créditos. A tabela usa os valores NDVI do resultado executado, antes de arredondar as diferenças.
• A matriz separou limites de projeto, operação e entrega. No projeto curto inicial, os dois primeiros grupos foram atendidos e a entrega não foi atendida. O resultado global continuou sendo Missão não cumprida.
• O botão de evidência de entrega selecionou o evento real de insuficiência, posicionou a linha do tempo e moveu o foco para evidence-title.
• A revisão independente identificou uma redação ambígua em R06. Foi corrigida para Qualidade dos dados de origem, com explicação explícita de pré-validação do arquivo histórico. Esse requisito não atesta recepção ou cálculo do índice no solo.
• Abertura, relatório e revisão pré-voo foram novamente operados no iframe de 390 × 844 px. A página manteve 375 px de clientWidth e scrollWidth. As tabelas mantêm rolagem própria: ciência 560 px dentro de 309 px; requisitos 790 px dentro de 301 px. O foco e a seta direita moveram a tabela científica sem alargar a página.
• O texto da tabela científica em tela estreita foi aumentado, com uma indicação de rolagem. O layout evita reduzir os valores numéricos para caberem em quatro colunas estreitas.

Capturas adicionais: retorno-cientifico.jpg e retorno-mobile.jpg, disponíveis na galeria de evidências.

Verificação automatizada do conjunto integrado

• 101/101 testes de domínio e integridade passaram, incluindo os 30 testes novos de pré-voo, requisitos e retorno científico. Nenhum teste foi pulado.
• 9/9 testes de interface passaram, preservando o percurso de previsão, execução, consulta, novo projeto, importação e falhas de armazenamento.
• O veredito e as versões do motor e do catálogo permanecem os mesmos da base. O refinamento acrescenta interpretação e visualização, sem alterar as condições de sucesso.
• Permanecem os limites descritos acima: esta sessão não demonstra aprendizagem com participantes, desempenho 3D nem conformidade WCAG completa.