Ciência que chega.
Decisões que se sustentam.

CADERNO / 00

Missão Ipê — Ciência que chega

IPÊ — Science Delivered · protótipo de pesquisa 0.1.1 · AB / Hackatur–Zer0Slop · 14/11/2026.

Jogo local sobre projeto de missão espacial. O participante escolhe seis subsistemas/políticas, prevê o gargalo, executa a missão, investiga eventos e redesenha a solução. A tarefa é entregar seis resultados NDVI utilizáveis. A condição de comunicação curta mostra por que reduzir o volume transmitido e aumentar a potência disponível precisam ser decisões coordenadas.

Estado e procedência temporal

Esta entrega contém código, interface, dados NASA de arquivo, testes, documentos e pacotes compilados. O desenvolvimento específico começou antes das 09h BRT de 14/11/2026. A elegibilidade para NASA Space Apps não está estabelecida. A orientação do GO Team inclui o risco de desclassificação por trabalho antecipado. Separar ou declarar este material não resolve essa pendência. O registro original está em evidence/chronology.json; as fontes oficiais e os limites estão no dossiê.

O runtime implementado é educacional. Não é software de voo, gêmeo digital validado de Terra/MODIS ou previsão agrícola. O resultado dos testes executados fica em docs/09-VERIFICACAO.md; metas e trabalho pendente ficam no handoff. Não se realizou estudo com participantes nem benchmark nos equipamentos de AB.

Abrir o pacote compilado localmente

O ZIP inclui dist/, portable/ e o código-fonte. Para a variante com Worker, use Node 24 ou superior já instalado e, dentro desta pasta:

node scripts/serve.mjs

Abra o endereço informado: http://127.0.0.1:4173. O servidor usa apenas bibliotecas nativas do Node; não é necessário executar npm ci para servir o dist já incluído. Para outra porta:

node scripts/serve.mjs --port 4174

A porta e a origem participam da identidade do armazenamento do navegador. Exporte os recibos antes de mudar a instalação. O servidor escuta somente loopback. Não o exponha como serviço público sem revisar o novo contexto de implantação.

O arquivo portable/Missao_Ipe_Local.html incorpora JavaScript, CSS e os dez JSONs científicos. Essa variante executa o mesmo motor na thread principal, sem Worker. Sua compilação foi verificada; a abertura real por protocolo de arquivo, a persistência e o comportamento visual em cada navegador ainda precisam de validação no equipamento de apresentação. O ambiente de pesquisa bloqueou essa inspeção. O HTML não contém uma simulação alternativa nem um score previamente animado.

Desenvolver e verificar

O package-lock.json fixa as versões. A instalação exige o registro npm ou um cache previamente provisionado para a plataforma. Isso é diferente da execução local do pacote compilado.

npm ci
npm run dev

Verificação e distribuição:

npm test
npm run test:ui
node scripts/verify-science-data.mjs
npm run benchmark:engine
npm run build
npm run build:portable

npm test cobre motor, busca, ciência, importação e persistência, incluindo um oráculo independente. test:ui monta os componentes React em DOM simulado; isso não é uma validação visual de navegador. O benchmark mede o executor identificado no recibo, sem extrapolar o tempo para outras máquinas. A definição dos gates está no PRT e no handoff.

O contrato Prisma opcional pode ser validado separadamente:

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

O jogo atual usa IndexedDB. Não há backend Prisma, migração aplicada ou serviço SQLite iniciado por esse comando.

Experimento central reproduzível

Configuração-base: bateria pequena, painel padrão de 18 W, BANDAS R/NIR, rádio econômico, armazenamento grande e todos os contatos.

Há 64 configurações por condição. O catálogo longo tem 17 sucessos, 41 falhas e 6 configurações inválidas. O curto tem 9 sucessos, 49 falhas e 6 inválidas. Todas as sete configurações a distância zero ou um da base curta foram decididas sem sucesso. A prova é de mínimo de alterações nesse catálogo e sob essas hipóteses, não de projeto espacial universalmente ótimo.

Documentação e código

Reuso, IA e licenças

O código original é distribuído sob Apache-2.0. As bibliotecas de runtime React, ReactDOM, Scheduler e Three.js preservam os avisos MIT em licenses/. Os dados e projetos pesquisados mantêm termos próprios. Nenhum repositório privado AB foi publicado ou relicenciado.

AB-R3A/REA é uma ferramenta de análise estática usada na bancada de engenharia, com cobertura e limites no recibo. Não é o runtime gráfico, um modelo de inferência nem o serviço que executa os agentes Astra. AB-SMC1TY e AB-ET3TIV foram referências internas inspecionadas; não foram copiados assets privados para a entrega.

Pesquisa, documentos, código e testes tiveram assistência de IA, com dez frentes Astra 6 em esforço máximo. Nenhum modelo Fastino foi instalado ou executado no jogo. Não existe dependência de API de IA, mapa remoto, fonte externa ou GPU CUDA para o cálculo.

Consulte NOTICE.md para atribuições. Não foram incorporados logotipos NASA/Kapsch, nem código do jogo comparável pesquisado. A referência Kapsch orienta a interação espacial por pontos e painéis, sem reivindicar cópia da experiência ou de seus assets.

CADERNO / 01

01 — Dossiê de decisão: Missão Ipê — Ciência que chega

Rodada 4 · 14 de novembro de 2026 · AB / Hackatur–Zer0Slop. Produto escolhido: jogo de projeto de missão espacial. Esta revisão preserva o histórico das rodadas anteriores e inicia código de um protótipo local. As conclusões executadas estão discriminadas em 09-VERIFICACAO.md; as metas de produto permanecem separadas de resultados observados.

1. Decisão e vantagem que precisa ser demonstrada

A proposta para AB é uma missão educacional curta em que o participante projeta um satélite didático, entrega seis resultados científicos de arquivo e explica por que sua decisão funcionou. Energia disponível, potência instantânea, massa, orçamento, capacidade de armazenamento e tempo de contato produzem consequências acopladas. O catálogo permite conferir integralmente as alternativas. A experiência expõe o registro causal e exige uma previsão antes da execução.

A afinidade com o perfil informado por AB é concreta: UX Research entra no desenho e observação da tarefa; design de produto organiza restrições compreensíveis; dados sustentam os critérios científicos; conhecimento técnico permite transformar consequências em regras verificáveis. Isso é uma inferência de adequação, não uma medição de habilidade nem uma probabilidade de premiação. O desconhecimento sobre a composição humana da equipe impede atribuir competências adicionais a outras pessoas.

O diferencial proposto tem quatro partes inseparáveis: dado NASA com procedência rastreável; consequência física dentro de hipóteses declaradas; explicação ligada a eventos; reexecução que confere o resultado. O diorama orienta a leitura espacial. A decisão educativa permanece acessível por controles HTML quando WebGL não funciona. A missão precisa continuar inteligível sem a paisagem.

Não há base estatística para chamar qualquer projeto de “maior chance mundial” em percentual. Não possuímos notas dos concorrentes, função de decisão dos jurados ou amostra representativa de inscrições. A escolha é uma decisão de portfólio: concentrar o esforço no tema já escolhido, no perfil de AB e numa demonstração delimitada que pode ser terminada, inspecionada e explicada. A meta é uma candidatura defensável; o resultado competitivo não está sob nosso controle.

2. Pendência que antecede a candidatura

O GO Team informa início às 09h locais de 14/11/2026 e possibilidade de desclassificação por trabalho antecipado. Há orientação para esperar inclusive para discutir funcionalidades/esboçar UI. Uma resposta de 13/11 aborda especificações Markdown e prompts detalhados e reitera o horário. Portanto, a descrição anterior de toda a especificação como “preparação permitida” era ampla demais. Esta revisão corrige essa conclusão sem apagar a versão histórica. [R01–R03]

O usuário solicitou expressamente iniciar o projeto. A implementação desta rodada começou antes das 09h BRT e tem esse fato registrado em evidence/chronology.json. Trata-se de P&D específico pré-evento, sem elegibilidade temporal estabelecida. Citar a origem, separar diretórios, recompilar após o horário ou renomear o material não concedem autorização dos organizadores. Não declarar que a equipe foi desclassificada: não foi observada uma decisão sobre esta equipe. A questão exige uma resposta efetiva da organização antes de apresentar esse material como elegível. Nenhuma mensagem foi enviada em nome de AB.

Outro gate é o vínculo aos Resources do desafio. A exigência atual do GO Team é usar ao menos uma fonte NASA incluída nessa lista. A página específica continuou inacessível durante esta pesquisa. MOD13Q1 é um produto NASA real e foi conferido; sua inclusão específica na lista não foi demonstrada. O espelho HackAthlone aponta materiais de engenharia como Design and Develop Science Missions e CubeSat 101, mas não substitui a fonte oficial. A arquitetura permite fazer esses materiais comandarem o briefing, os segmentos e os critérios de verificação; esse uso só deve ser apresentado depois de confrontado com os Resources oficiais. [R04–R05]

3. O padrão mundial e os referenciais brasileiros

O estudo histórico integral está preservado em research/history/01-juri-mundial-rodada-anterior.md. Ele confronta casos 2023–2025 com NASA, AEB, instituições participantes e repositórios dos autores, distinguindo descrição, código inspecionado e execução não realizada.

O anúncio NASA de 2025 confirma PureFlow. A AEB documenta seis finalistas brasileiros: A.T.L.A.S., naiπ, PureFlow, Stellar Narrators, The new Saraquatys e Titan. O resultado posterior distingue PureFlow como vencedor. Não converter as demais equipes em vencedoras nem transformar “top 0,24%” em chance de AB: equipes, participantes e submissões são denominadores diferentes. [R06–R07]

Nesta rodada apareceu um comparável ainda mais direto: NASA-SPACEAPP-2026/Space-Mission-Design-Game descreve um jogo CubeSat estático com Vite, decisões de requisitos e armazenamento no navegador. A organização de GitHub tem “NASA” no nome, mas isso não demonstra vínculo oficial. O README foi inspecionado; não executamos o jogo, não certificamos sua elegibilidade e não incorporamos seu código. A existência desse comparável enfraquece a alegação de originalidade de “montar um CubeSat offline”. Sua documentação também descreve Three.js e fallback 2D; esses recursos não constituem exclusividade do Ipê. Não permite afirmar que a integração completa proposta pelo Ipê inexiste em todos os demais projetos. [R08]

4. Países e regiões: critério útil para pesquisa

Não escolher biblioteca pela nacionalidade presumida do criador. Repositórios globais têm autoria distribuída; país de um evento, sede de empresa e nacionalidade do mantenedor são variáveis diferentes. O anexo mistura essas três coisas e usa superlativos sem universo de comparação. A auditoria de repositórios classifica capacidade, licença, custo de integração e limite, preservando a localização institucional quando a fonte a sustenta.

Para aprofundamento técnico deste jogo, a lista operacional de três ecossistemas é Estados Unidos, França e Japão. É uma seleção de referências úteis ao recorte, não um ranking mundial de tecnologia. Estados Unidos fornecem a cadeia NASA de dados, engenharia e visualização; França acrescenta referências verificáveis de dinâmica orbital/engenharia como Orekit; Japão oferece S2E/C2A para separar ambiente de simulação e software de bordo. A matriz completa cobre também iniciativas chinesas, russas, europeias, canadenses e australianas. Nenhuma origem torna um projeto candidato a integração sem conferir o custo.

As tecnologias centrais desta entrega são uma biblioteca gráfica global, React, TypeScript e APIs locais do navegador. A nacionalidade das ferramentas não entra na condição de vitória. A prioridade de benchmark competitivo continua sendo proximidade do problema, como PureFlow, e não PIB ou contagem de estrelas.

5. O que a nova bateria alterou

A pesquisa de Fastino rejeitou três premissas do texto enviado: classificação sem sampling não garante acerto nem reprodutibilidade entre plataformas; rodar um detector PII local não garante conformidade integral; um runtime que aceita algum GGUF não aceita automaticamente qualquer checkpoint GLiNER/GLiDE. O relatório 02 contém as diferenças de versões, as licenças, os resultados publicados e o plano de ablação. Nenhum modelo foi baixado ou executado nesta rodada.

A segunda alteração é científica. BLUE existe nos arquivos já recuperados, e o EVI de três bandas foi recalculado com aritmética racional. Os seis valores conferem com diferença inferior a 0,0001 em relação ao produto publicado. Isso permite pesquisar uma missão posterior sobre a preservação de informação para responder a uma nova pergunta. Não modifica o objetivo NDVI da primeira missão nem prova equivalência entre uma rota que transmite R/NIR e outra que requer R/NIR/BLUE. O termo constante do EVI impede cancelar ingenuamente a escala das reflectâncias.

A terceira alteração é de implementação: catálogo, simulação, busca e recibo deixam de ser apenas especificações. O aceite depende dos comandos e recibos desta rodada, nunca do preflight AB-R3A ou dos cálculos manuais anteriores. Os documentos históricos continuam corretos sobre seu próprio estado de pesquisa; não devem ser reescritos para insinuar que o jogo já existia naquela etapa.

6. Proposta de demonstração competitiva

A demonstração deve mostrar uma pergunta: “O satélite coletou os dados. A ciência chegou?”. Em seguida, um resultado com entrega incompleta; uma inspeção do gargalo; uma mudança que resolve comunicação mas viola potência; e um redesenho verificado que entrega os seis resultados. Uma resposta escrita de um participante pode revelar entendimento, mas só depois de uma sessão real observada.

No vídeo curto, selecionar uma única cadeia causal. O formulário atual e a agenda local precisam ser conferidos; as orientações consultadas indicam até 30 segundos ou sete slides e submissão em inglês. A apresentação longa da equipe pode usar mais detalhe, mas não substitui o artefato global. Não apresentar uma categoria de prêmio como direito adquirido nem anunciar afiliação NASA. [R09]

Referências desta decisão

• R01: https://github.com/nasa/spaceapps/discussions/1827
• R02: https://github.com/nasa/spaceapps/discussions/1872
• R03: https://github.com/nasa/spaceapps/discussions/2009
• R04: https://github.com/nasa/spaceapps/discussions/1849
• R05: https://www.spaceappschallenge.org/2026/challenges/space-mission-design-game/?tab=resources — recuperação falhou; ver recibo em research/evidence.
• R06: https://www.nasa.gov/learning-resources/stem-engagement-at-nasa/nasa-announces-2025-international-space-apps-challenge-global-winners/
• R07: https://www.gov.br/aeb/pt-br/assuntos/noticias/seis-equipes-brasileiras-estao-entre-os-finalistas-do-nasa-space-apps-2025
• R08: https://github.com/NASA-SPACEAPP-2026/Space-Mission-Design-Game
• R09: https://github.com/nasa/spaceapps/discussions/1947 e https://github.com/nasa/spaceapps/discussions/1973

Os sete precedentes e suas fontes individuais estão no parecer histórico preservado. As escolhas de produto deste documento são decisões da coordenação, não recomendações atribuídas às instituições citadas.

CADERNO / 02

02 — PRD: Missão Ipê — Ciência que chega

Product Requirements Document · versão 0.1 de P&D · contrato ipe-64-v1. Uso pretendido: educação em decisões de missão; não planejamento operacional de voo. Documento produzido antes do início local oficial; elegibilidade de uso na competição não estabelecida.

1. Problema, público e tarefa

Um iniciante consegue reconhecer bateria, painel e antena, mas pode tratar cada escolha como uma melhoria independente. O problema de produto é permitir que ele observe um compromisso entre recursos: reduzir o volume transmitido exige processamento; aumentar a taxa de transmissão exige potência; escolher peças maiores pode ultrapassar o envelope de lançamento. A evidência de compreensão exige a pessoa justificar uma decisão sob uma condição diferente, não somente alcançar o estado verde.

Público inicial para validação: estudantes e visitantes de formação heterogênea em uma sessão acompanhada por educador ou facilitador. Não foi recrutada uma amostra nesta rodada. Não se presume idade, deficiência, escolaridade ou domínio de inglês dos participantes. A interface de pesquisa é pt-BR; a versão em inglês permanece tarefa de preparação da submissão, com revisão humana dos termos científicos.

Tarefa principal: entregar seis resultados NDVI utilizáveis ao solo dentro da missão simulada, preservando todos os limites do cenário. Meta de duração: oito minutos por ciclo introdutório. Essa duração é uma hipótese de UX, ainda não uma medição.

2. Fronteira funcional

P0 tem uma missão e duas condições de contato. O objetivo científico e o pacote de dados permanecem iguais. O lançador e o perfil orbital são fixos e declarados. As seis escolhas disponíveis são bateria, painel, representação/processamento, rádio, armazenamento e política de contato. O escopo não equivale a selecionar todos os subsistemas e destinos de uma missão real. A adequação integral ao enunciado oficial ainda precisa da leitura dos Resources e do brief integral.

A pergunta científica é calcular NDVI nos seis registros de arquivo MOD13Q1 selecionados para três coordenadas solicitadas no entorno de Rio Verde, em duas composições temporais de 2024. A nave didática não adquire fisicamente esses pixels em 180 minutos. O volume lógico de cada lote é uma hipótese de missão e não o tamanho dos JSONs empacotados.

Os números são hipóteses didáticas versionadas, não parâmetros atribuídos a MODIS, Terra ou um fornecedor de CubeSat. As massas/créditos ficam no catálogo executável. A capacidade total é limitada a 3,6 kg e 86 créditos, incluindo base fixa de 1,2 kg/20 créditos. Não exibir o maior valor de todas as peças como solução automaticamente válida.

3. Jornada e telas

Observatório

A primeira tela apresenta o pedido científico, a origem dos registros, as duas condições e um diorama procedural. O usuário pode escolher por botão HTML; clicar numa forma 3D nunca é o único acesso. “Contatos longos” introduz o ciclo; “Contatos curtos” funciona como transferência próxima. A Terra, o satélite e os arcos são representação explicativa, sem claim de efemérides ou geometria orbital calculada.

Bancada de projeto

As seis decisões mostram parâmetros, massa e créditos. A configuração padrão é bateria de 16 Wh, painel de 18 W, BANDAS R/NIR, rádio econômico, armazenamento grande e todos os contatos. Antes da primeira execução de cada condição, registrar uma previsão do gargalo. As hipóteses não podem ser alteradas por texto livre, e o usuário não edita números físicos arbitrários nesta versão.

A previsão é evidência de interação da pessoa, não dado NASA. Não registrar nome, email, CPF ou identificador externo. O diário local deve ser exportado deliberadamente, com aviso de que textos livres podem conter informações pessoais. Nenhum detector de PII é presumido instalado. Esse aviso é pertinente ao conteúdo efetivamente exportado e não uma promessa regulatória.

Sala de missão e debrief

A simulação produz o resultado independentemente da câmera e da taxa de quadros. A linha do tempo lê o trace já calculado; avançar, pausar ou arrastar o marcador não altera a física. A tela mostra resultados entregues, reserva, fila, balanço energético e eventos. Selecionar um evento revela regra, instante e valores. Distinguir lote parcialmente transmitido de registro científico utilizável.

O usuário volta à bancada para redesenhar. A busca oferece a menor quantidade de escolhas alteradas dentro das 64 configurações e da condição fixada, somente após uma tentativa própria. O caso curto bloqueia ajuda antes da primeira execução. Aplicar uma sugestão cria nova entrada; não edita retrospectivamente uma execução já salva. Empates, quando houver, precisam permanecer visíveis.

4. Requisitos funcionais e critérios de aceite

O documento de verificação registra quais desses aceites foram executados em Node, DOM de teste ou navegador. Um checkbox nesta especificação não é recibo de teste.

5. Vitória, falha e experiência de erro

Vitória exige simultaneamente: envelope estático admissível; conclusão do horizonte; nenhuma violação operacional; seis registros esperados inteiros recebidos e cientificamente utilizáveis. Missão inválida por massa/orçamento não se transforma em missão bem-sucedida porque alguma telemetria chegou. Falha de potência e esgotamento de energia interrompem a operação. Cruzar a reserva marca violação e preserva o trace. Buffer cheio perde o lote novo conforme política fixa do cenário.

Erro de software, timeout, cancelamento ou entrada inválida de replay nunca vira falha física nem vitória. O usuário recebe um estado de erro e pode repetir com a entrada preservada. Perder a cena WebGL mantém a interação HTML. Falhar um salvamento local mantém resultado e exportação; não prometer persistência que o navegador rejeitou.

6. Conteúdo, acessibilidade e imersão

A estética combina papel claro, carvão e âmbar de ipê, com números tabulares e rótulos visíveis. Cor reforça, mas não é a única informação de estado. Foco, labels, ordem de navegação, contraste e overflow exigem inspeção de navegador no equipamento real. O teste DOM só cobre parte disso. Redução de movimento interrompe animação contínua; a aba oculta não deve manter renderização desnecessária. A física não depende dessas otimizações.

A referência Kapsch é funcional: selecionar pontos espaciais e abrir informações contextualizadas. Não foram copiados os assets ou a identidade da empresa. O escopo usa Three.js procedural; não carrega cidade fotorrealista, terreno planetário global, áudio gerado ou catálogo de múltiplos planetas. Esses elementos ampliariam produção, licenças e tempo de carga antes de demonstrar a aprendizagem central.

7. Hipóteses e pesquisa com usuários

Hipótese H1: a inspeção de consequências ajuda o participante a distinguir energia de potência. H2: a pessoa transfere a relação processamento/comunicação para a condição curta sem abrir a solução. H3: a visualização permite localizar quando o problema ocorreu. H4: a missão cabe no tempo de demonstração previsto. Nenhuma hipótese foi confirmada por pessoas nesta rodada.

Protocolo: dois pilotos para corrigir instruções e seis sessões observadas; informar finalidade, evitar coleta pessoal e preservar erros/desistências. Pedir previsão, executar, solicitar explicação, mudar contato e registrar a primeira escolha antes da ajuda. Dois avaliadores classificam explicações por recurso limitante, mecanismo e justificativa da intervenção, documentando divergências. Isso é pesquisa formativa de compreensão imediata; não estima efeito causal, retenção ou generalização populacional.

Registrar tempo até primeira escolha, tempo por tarefa, ajuda solicitada, erros de interpretação, revisões de configuração e explicação final. Não otimizar uma taxa de conclusão sacrificando a dificuldade que revela o compromisso técnico. O objetivo não é forçar todas as pessoas a acertarem com o solver.

8. Evolução por gates

P1a: nova pergunta EVI3, com BLUE explicitamente transportada e política científica própria. P1b: conjunto finito de perturbações para comparar margens, sem chamar taxa na grade de probabilidade real. P1c: avaliação opcional de modelo compacto para escolher perguntas de acompanhamento, sem alterar pontuação. P1d: tradução integral e revisão terminológica em inglês.

P2: pacotes orbitais derivados de Orekit/Basilisk/SPICE, comparação com referência de maior fidelidade, criação de conteúdo por educadores e avaliação longitudinal. Cada incremento exige novo contrato, dados, oráculo, evidência e orçamento de desempenho. O primeiro núcleo não depende dessas entregas.

CADERNO / 03

03 — PRT: requisitos técnicos, modelo e verificação

PRT = Plano de Requisitos Técnicos nesta entrega. A sigla foi usada pelo usuário sem expansão; esta definição organiza o contrato técnico sem atribuí-la a uma norma externa. Estado: implementação de P&D educacional com fontes NASA históricas; elegibilidade competitiva pendente.

1. Topologia e domínio de falha

A arquitetura de execução é um monólito modular no navegador. React apresenta a tarefa; Three.js apresenta uma cena procedural; um Worker executa o motor e a busca; IndexedDB guarda rascunho e execuções; JSON versionado permite exportar e reexecutar. O servidor opcional serve arquivos estáticos em 127.0.0.1. Não há servidor de pontuação, serviço de inferência, autenticação remota, conta de aluno ou telemetria externa necessária.

A versão HTML portátil incorpora JavaScript, CSS e dados num único arquivo. Nela, o mesmo motor roda na thread principal para evitar dependência de Worker em origem file. Isso muda isolamento de latência, não equações. A variante estática com servidor mantém o Worker. Compilação a partir do código-fonte requer dependências previamente instaladas ou acesso ao registro npm; execução do pacote compilado não deve requerer esse registro. Não confundir runtime sem internet com bootstrap de desenvolvimento integralmente provisionado.

O custo científico é limitado: seis observações, número finito de fronteiras de evento e 64 configurações. Introduzir cluster, Kubernetes, fila externa, banco compartilhado ou GPU numérica acrescentaria coordenação, indisponibilidade e custo operacional antes de resolver um gargalo medido. Essa é uma decisão técnica decorrente do domínio, não uma proibição de distribuição em qualquer produto futuro.

2. Módulos, contratos e dependências

Entradas do motor são valores fechados, não código. Configurações têm exatamente seis chaves; valores fora do catálogo são rejeitados. O cenário público é um dos dois IDs conhecidos. O seam interno de testes permite cenários de fronteira, mas não é exposto pela UI, pelo importador ou pela busca do produto. Alterar o catálogo exige nova versão e nova evidência.

As versões npm foram fixadas no package-lock. A versão final instalada e as licenças observadas estão no inventário da entrega. Não atribuir manutenção oficial NASA a uma biblioteca de terceiros. AB-R3A/REA é usado como bancada de inspeção do código; não é runtime do jogo nem hospeda os agentes Astra.

3. Modelo temporal e simultaneidade

O horizonte é 10.800 s. Iluminação ocupa [0,5400) e [7200,9000). Seis trabalhos de 60 s começam em 600,1200,1800,2400,3000 e 3600 s. O cenário longo tem contatos [5400,6000), [9000,9600); o curto, [5400,5640), [9000,9240). Esses intervalos são hipóteses didáticas; não foram derivados de propagação orbital nesta versão.

O integrador avança até a próxima fronteira necessária: início/fim de trabalho, mudança de iluminação, abertura/fechamento de contato, término de um lote transmitido, saturação ou esgotamento da bateria e horizonte. A contribuição do intervalo anterior é concluída antes das ações da fronteira. Um último bit entregue exatamente no fim de um contato conta; produção só ocorre ao completar o trabalho inteiro. Não existe “meio lote científico” válido.

Os cenários fechados não sobrepõem processamento e contato. O validador rejeita essa combinação no seam de teste; não soma silenciosamente cargas que a especificação não definiu. Acrescentar concorrência de subsistemas requer revisar política de operação, carga total, precedência e oráculos. O tempo da câmera, o requestAnimationFrame e a posição do cursor não são fontes do relógio físico.

Relógio e energia usam frações racionais internas reduzidas com BigInt. A apresentação converte valores finais para number. Bits são inteiros seguros internamente e strings decimais no contrato externo. Os limites eliminam arredondamento por frame e epsilon de sucesso. A conversão para visualização ainda pode arredondar; por isso um valor mostrado como 20,00 W não pode ser usado para refazer a decisão de um valor exato ligeiramente maior que 20 W.

4. Energia e potência

Seja P_s a potência solar útil antes da carga, P_l a carga total no barramento, eta_c=eta_d=0,95, E a energia armazenada e C a capacidade. Durante luz, P_s é o painel nominal vezes 0,55 no processamento ou 0,85 na espera/transmissão; em eclipse, P_s=0.

Quando P_s >= P_l e E<C:

$$P_{in}=\min(P_s-P_l,10\ \mathrm{W}),\qquad \dot E=\eta_c P_{in}/3600.$$

O excedente não aproveitado é contabilizado como spill. A perda de conversão é (1−eta_c)P_in. Quando a bateria está cheia, a entrada de carga é zero e o excesso inteiro vai a spill. A integração divide no instante exato de saturação.

Quando P_l>P_s:

$$P_{bat}=\frac{P_l-P_s}{\eta_d},\qquad \dot E=-P_{bat}/3600.$$

A perda de descarga é P_bat−(P_l−P_s). P_bat acima do limite da bateria é falha instantânea terminal, mesmo com energia armazenada suficiente. E=0 com demanda não suprida é esgotamento terminal. A reserva é 15% da capacidade, e a carga inicial, 80%. Cruzar a reserva é violação de missão sem apagar o histórico. São políticas do cenário, não padrões universais de dimensionamento.

O balanço acumulado deve satisfazer:

$$E_{fim}=E_{inicio}+E_{solar}-E_{carga}-E_{perdas}-E_{spill}.$$

O motor reporta o residual; a revisão independente deve comparar um caso manual e casos de fronteira. Apenas testar a mesma função contra seus próprios valores não constitui oráculo independente.

Exemplo didático: BANDAS com painel de 18 W exige (26−18×0,55)/0,95 = 16,947368… W da bateria. ÍNDICE exige (38−18×0,55)/0,95 = 29,578947… W. A bateria de 16 Wh suporta 20 W; portanto pode satisfazer o primeiro pico e falhar no segundo apesar de o segundo transmitir menos dados. Rádio rápido em eclipse exige 26/0,95 = 27,368421… W. A capacidade em Wh não substitui esse limite em W.

5. Armazenamento, transmissão e significado da entrega

Cada trabalho completo gera um lote lógico inteiro. BANDAS produz 180.000.000 bits; ÍNDICE, 60.000.000. Um buffer não comporta parte de um lote novo: se faltar capacidade, o lote inteiro novo é perdido e registrado. A transmissão usa FIFO e conserva progresso parcial entre contatos. A fila vazia encerra imediatamente a carga de transmissão, em vez de cobrar rádio ligado até o fim da janela.

Em todo estado:

$$B_{gerados}=B_{recebidos}+B_{fila}+B_{perdidos}.$$

Há também contabilidade por observação, de forma que uma soma global correta não possa ocultar um registro entregue duas vezes. Frações de serviço inferiores a um bit não são re-arredondadas a cada frame. O motor contabiliza bits inteiros recebidos e o crédito fracionário de serviço conforme a semântica documentada no código e nos testes.

Na condição curta, rádio econômico oferece 480×960.000 = 460.800.000 bits de serviço. BANDAS exige 1.080.000.000 bits para seis registros; ÍNDICE exige 360.000.000. A taxa é serviço útil do modelo; não é promessa de link real com codificação, protocolo, ruído, atenuação, antena ou orçamento RF fisicamente calculados.

Receber bytes não basta. A observação só satisfaz a tarefa quando o lote é completo, o ID é esperado e único, a qualidade foi aceita e a transformação é válida. Perda de QA ou ausência de banda precisa produzir estado inválido, não NDVI zero. A apresentação distingue ainda-not-produced, queued, partial, delivered, lost e invalid.

6. Contrato científico

O pack provém de MOD13Q1 Collection 061, com três posições solicitadas e duas composições temporais. Os JSONs ORNL, metadados de bandas, CMR e horários de recuperação ficam preservados. O hash do pack vincula versões de replay. Ele prova correspondência dos bytes conhecidos, não autoria NASA sem a cadeia de recuperação/documentação.

NDVI=(NIR−RED)/(NIR+RED). Reflectâncias usam a escala publicada 0,0001 e offset 0; nesses termos a escala cancela no quociente. O validador confere domínio, máscara, sentinelas, denominador e concordância com o produto NDVI. A tolerância científica de 0,0001 é requisito explícito desta amostra; não é epsilon para energia, bits ou massa. Os seis registros atuais passam o QA, portanto testes negativos usam fixtures sintéticas rotuladas como tal.

As duas representações satisfazem o mesmo objetivo NDVI. No modelo atual, a disponibilidade das bandas e o QA são auditados antes de qualquer afirmação de ciência útil. O armazenamento e a comunicação usam volumes lógicos didáticos. Um futuro simulador de instrumento precisa acrescentar calibração, ruído, resolução e condições de observação; esses fenômenos não são presumidos por usar MOD13Q1.

EVI3 fica fora do P0. A validação de pesquisa usa 2,5(NIR−RED)/(NIR+6RED−7,5BLUE+1), com reflectâncias escaladas. BLUE é informação adicional; um pacote que transmitiu apenas RED/NIR não contém o insumo. O termo 1 impede cancelar a escala de modo geral. A mudança de pergunta deve criar outra versão de contrato, com dados e critérios próprios.

7. Busca exaustiva e limite da prova

O espaço C tem 64 tuplas. A distância é Hamming: número de escolhas diferentes da configuração-base. Para condição z fixa, o alvo é minimizar essa distância entre configurações com sucesso. A admissibilidade de massa/créditos participa da decisão; opções inválidas são contabilizadas e não entram como testemunha.

O solver enumera C, executa o mesmo motor e mantém contagem de resultados. Um mínimo só é exposto com cobertura completa, zero indeterminados e testemunha viável. Erro, duplicação, ausência ou interrupção invalida a certificação. Nenhuma solução no catálogo também requer enumeração completa. A ordenação estável só apresenta empates; não cria um peso de mérito oculto.

Essa prova é relativa ao catálogo, às hipóteses, à condição, ao motor e ao pacote de dados. Não demonstra menor custo industrial, missão fisicamente ótima, causalidade exclusiva da primeira falha ou confiabilidade de voo. Um replay no mesmo motor verifica consistência da execução; os oráculos manuais e testes independentes combatem erros compartilhados.

8. Concorrência e consistência

Cada execução assíncrona possui identidade e AbortSignal. Cancelar encerra o Worker e descarta a resposta. A UI mantém uma geração de requisição e confere se a entrada continua atual antes de publicar o retorno. Trocar configuração, importar outro caso ou mudar condição invalida resultados derivados. O limite de 15 s é um erro operacional do cálculo, não uma classificação da missão.

IndexedDB usa transações locais. Request success não é commit; a confirmação espera transaction.complete. O rascunho usa revisão esperada com compare-and-swap dentro da transação. Duas abas com a mesma revisão não podem ambas sobrescrever silenciosamente a vencedora. Run identity inclui entrada, resultado, versões e hash do pack. Uma nova execução idêntica não cria múltiplos registros só por repetir o botão.

O diário de aprendizagem é distinto dos resultados físicos. Seus timestamps são relógio do cliente e podem ser alterados; não há promessa de diário inviolável. Exportação voluntária, coleta mínima e ausência de envio externo são controles efetivos desta arquitetura. Um hash sem chave não autentica a pessoa ou a máquina.

Prisma fica como contrato futuro de armazenamento relacional local. O schema define relações e proveniência; o produto atual não inicia um backend Prisma. Validação do schema não equivale a geração de client, migração aplicada, durabilidade de SQLite ou teste de concorrência numa API.

9. Importação, dependências e falhas adversariais

O importador recebe texto limitado antes do parse. Rejeita chaves duplicadas, campos desconhecidos, profundidade/tamanho excessivos, protótipos perigosos, versões incompatíveis, números não finitos e strings de bits fora do formato. Compara hashes e sempre reexecuta a entrada admitida. Alterar o resultado e refazer o hash pode produzir um envelope íntegro, mas a reexecução deve acusar divergência. Não executar scripts, buscar URLs ou carregar plugins de um recibo importado.

O servidor local limita-se a GET/HEAD, confere caminhos, associa MIME, aplica CSP e escuta loopback. Ele não é um serviço multiusuário endurecido nem uma autorização para exposição pública. Publicar posteriormente exige revisar autenticação, tratamento de dados, observabilidade, política de origem, atualização e ameaças do novo contexto.

10. Desempenho e micro-otimização justificada

A primeira otimização é reduzir trabalho: avanço por eventos em vez de amostrar 180 min a cada frame; nenhuma física por pixel; dados compilados e localizados; cena carregada à parte na variante Vite; renderização limitada e suspensa quando não necessária. A enumeração calcula 64 casos; não precisa de chamadas a modelo ou 64 Workers.

Frações BigInt alocam objetos e executam gcd. Esse custo é escolhido para evitar erro de fronteira no domínio pequeno e deve aparecer no benchmark. Não declarar overhead zero. Se o perfil mostrar custo material, comparar representação inteira em escala comum com a versão racional como oráculo, preservando resultados. Não trocar por Float32 para obter FPS quando o gargalo está na renderização.

Metas iniciais no equipamento da demonstração: interação visível em até 3 s com arquivos locais; tempo de quadro no percentil 95 <= 33,3 ms no modo 3D; tarefa interativa sem long task recorrente; busca no Worker concluída em até 1 s; resultado exportável mesmo com falha de persistência. São metas, não resultados publicados. Medir resolução, DPR, navegador, CPU, GPU, RAM, temperatura/modo de energia e versão. Não transferir o tempo Node do executor para RTX 3070, RTX 2060 Super, Mac ou celular.

As máquinas citadas anteriormente por AB não foram benchmarkadas nesta rodada. A consulta antiga à Oficina encontrou outra GPU e carga transitória; não se presume que esse inventário continua disponível. Não parar serviços ou descarregar modelos para fabricar margem de VRAM. O jogo não requer CUDA, pesos LLM ou agregação de GPUs.

CADERNO / 04

04 — Fluxos Mermaid e fronteiras do sistema

Os diagramas descrevem a versão de pesquisa. O fluxo do produto e a semântica do motor não mudam por animação ou por implantação. Os arquivos .mmd correspondentes ficam em docs/diagrams.

1. Jornada e proteção da primeira decisão

Ver fonte Mermaid editável

flowchart TD
  A["Escolher condição"] --> B["Ler pedido e fontes"]
  B --> C["Projetar seis escolhas"]
  C --> D{"Primeira tentativa?"}
  D -->|Sim| E["Registrar previsão"]
  D -->|Não| F["Congelar entrada"]
  E --> F
  F --> G["Executar motor"]
  G --> H{"Execução concluída?"}
  H -->|Erro ou cancelamento| I["Preservar entrada e explicar erro"]
  I --> C
  H -->|Sim| J["Inspecionar ciência e eventos"]
  J --> K["Explicar consequência"]
  K --> L{"Consultar alternativas?"}
  L -->|Sim| M["Enumerar catálogo completo"]
  M --> N{"Cobertura sem indeterminados?"}
  N -->|Sim| O["Mostrar mínimo e testemunhas"]
  N -->|Não| P["Não certificar mínimo"]
  O --> C
  P --> C
  L -->|Não| Q["Redesenhar ou mudar condição"]
  Q --> C

No caso de transferência, o controle de ajuda permanece indisponível antes da primeira execução. Essa barreira registra ordem de interação; não prova, por si, compreensão ou autoria de uma justificativa.

2. Simulação por eventos

Ver fonte Mermaid editável

flowchart TD
  A["Validar cenário e configuração"] --> B["Inicializar ledger e observações"]
  B --> C["Concluir eventos na fronteira"]
  C --> D{"Horizonte ou término?"}
  D -->|Sim| N["Classificar resultado e residual"]
  D -->|Não| E["Determinar modo e potências"]
  E --> F{"Descarga instantânea admissível?"}
  F -->|Não| G["Registrar falha terminal"]
  G --> N
  F -->|Sim| H["Próxima fronteira temporal"]
  H --> I["Dividir por bateria e entrega"]
  I --> J["Integrar energia e serviço"]
  J --> K["Atualizar FIFO e lotes completos"]
  K --> L["Conferir reserva e contabilidade"]
  L --> M["Registrar trace e avançar relógio"]
  M --> C

A fração exata é a base da decisão. Os valores do tipo number exibidos na UI são conversões para apresentação. O último intervalo é integrado antes dos eventos de seu limite. A implementação tem testes específicos para último bit, último trabalho e energia zero.

3. Importação de resultado não confiável

Ver fonte Mermaid editável

flowchart TD
  A["Arquivo selecionado"] --> B["Limitar tamanho e profundidade"]
  B --> C["Parse estrito sem duplicatas"]
  C --> D["Validar campos e versões"]
  D --> E["Conferir hashes da entrada e alegação"]
  E --> F["Reexecutar entrada permitida"]
  F --> G{"Resultado confere?"}
  G -->|Sim| H["Exibir consistência verificada"]
  G -->|Não| I["Exibir divergência e novo resultado"]
  B -->|Rejeição| J["Manter estado atual"]
  C -->|Rejeição| J
  D -->|Rejeição| J
  E -->|Rejeição| J

Consistência verificada não é autenticidade, aprovação NASA ou correção física universal. O importador nunca executa uma URL, script ou trace fornecido pelo arquivo. O resultado recomputado permanece distinto da alegação importada.

4. Topologia local e ramo de IA opcional

Ver fonte Mermaid editável

flowchart TD
  A["Pacote local versionado"] --> B["React e controles HTML"]
  A --> C["Dados científicos preservados"]
  B --> D["Three.js procedural"]
  B --> E["Worker de simulação e busca"]
  C --> E
  E --> F["Resultado e eventos"]
  F --> B
  F --> G["IndexedDB local"]
  F --> H["Recibo JSON exportado"]
  H --> I["Validador e reexecução"]
  I --> E
  B -. "P1: texto consentido" .-> J["Classificador local opcional"]
  J -. "Sugestão validada ou abstenção" .-> B

A seta P1 não indica serviço já implementado. O modelo não acessa o ledger nem altera a condição de vitória. Na distribuição portátil, o motor ocupa a thread principal e não o Worker; a API matemática permanece a mesma. O schema Prisma descreve evolução relacional e não integra a topologia executada do browser.

CADERNO / 05

05 — Cronograma, responsabilidades e passagem de etapa

Calendário de referência: Rio Verde, UTC−03. A orientação global situa o início às 09h de 14/11/2026. A agenda local indexada indica entrega às 17h de 15/11 e apresentações às 18h; o formulário global aparece aberto até 23h59. O corte operacional é 17h, sujeito à confirmação no evento. Não usar o horário global mais tarde para ignorar um corte local. Fontes: GO Team, Rio Verde.

1. Gate de elegibilidade e estado atual

O protótipo e as especificações desta rodada foram iniciados antes da abertura local. Esse material já existe e não deve ser apresentado como produzido apenas depois das 09h. A resposta oficial sobre a possibilidade de aproveitamento é um gate de candidatura. Enquanto não houver confirmação, ele pode ser estudado e revisado como P&D, sem alegar autorização competitiva. Recriar uma solução a partir de especificações antecipadas não deve ser apresentado como exceção automaticamente válida.

A segunda verificação inicial é conferir o Resources oficial e vincular uma fonte qualificada a uma decisão substancial do jogo. O terceiro gate é registro/composição da equipe no evento e acesso ao formulário real. Não foram efetuados inscrição, envio, publicação ou contato externo em nome de AB.

2. Sequência operacional para a equipe

O calendário abaixo é um plano para desenvolvimento permitido na janela oficial ou para continuação de P&D identificada como tal. A aprovação de uso do material anterior não é presumida.

O calendário não é um relatório de atividades realizadas nem reserva a disponibilidade das pessoas. O trabalho de dez agentes de pesquisa não substitui a equipe humana inscrita, e não acrescenta dez membros à competição.

3. Responsabilidades humanas por função

AB coordena produto, priorização e narrativa, coerentemente com o perfil informado. As demais funções precisam ser distribuídas entre pessoas disponíveis: ciência/procedência, motor/testes, frontend/3D, validação com usuários e preparação da submissão. Uma pessoa pode acumular funções; a revisão cruzada de ciência e código deve permanecer independente quando possível. Não atribuímos nomes ou formações não informados.

A pessoa que desenvolve uma regra não é sua única verificadora. A pessoa que conduz a sessão não deve ensinar a resposta antes de registrar a primeira decisão. A pessoa que grava a demo precisa usar o build congelado, e não uma animação com números escolhidos à mão.

4. Política de escopo

Às 12h de domingo, congelar novas funcionalidades. Se a tarefa central tiver defeito, corrigir esse defeito antes de acrescentar EVI, IA, novos mapas, áudio, multiplayer ou banco relacional. O jogo pode explicar limites do modelo sem adicionar um subsistema que a equipe não consegue conferir.

Cortes previstos: remover efeitos gráficos antes de reduzir a validade dos dados; reduzir número de telas auxiliares antes de remover diagnóstico; retirar um módulo de IA experimental antes de torná-lo obrigatório; manter texto inglês e fontes mesmo quando o vídeo precisa ser mais simples. O motor, a reexecução e a atribuição são requisitos do recorte escolhido.

5. Continuação após o evento ou como P&D

Os prazos são estimativas de planejamento para o recorte descrito, não compromissos de equipe ou serviços externos. Um gate reprovado reabre a etapa; o prazo não torna um resultado verdadeiro.

CADERNO / 06

06 — Fastino, execução local e análise do texto enviado

1. O que foi recebido

Os arquivos Texto colado(1).txt e Texto colado(2).txt são byte a byte iguais: 32.575 bytes, SHA-256 62fa654201593bf9dd4f62667dcb91d3e89f98f00cf001ac1506847d0506dc51. O original está preservado em research/anexo-original.txt. O conteúdo é um catálogo de ferramentas espaciais/geoespaciais por região. As afirmações sobre Fastino, GLiNER, GLiDE, Unsloth e Spec Kit estão na mensagem do usuário, e não nesses arquivos.

A mensagem termina com frases incompletas sobre “limites” de domínio e “modelagem de efei…”. Não há texto suficiente para reconstruir a intenção específica desses trechos. A arquitetura desta entrega foi desenvolvida a partir das partes legíveis; não se apresenta uma continuação inventada como parte do anexo.

O relatório research/02-fastino-anexos.md contém 37 fontes primárias, diferenças de versões, métricas, licença e protocolo de avaliação. research/08-auditoria-repositorios.md trata o catálogo completo. Esta seção registra as decisões que afetam o projeto.

2. O que muda ao substituir um modelo grande por um classificador

Um classificador pode receber rótulos candidatos e retornar scores em uma passada. Isso elimina geração autoregressiva para aquela tarefa, mas não torna a decisão correta por construção. O conjunto de classes, a representatividade dos exemplos, a distribuição de entrada e o custo assimétrico do erro continuam fazendo parte do sistema. JSON válido apenas mostra conformidade estrutural; uma classe incorreta continua incorreta quando está num enum permitido.

A alegação de economia superior a 95% frente a um modelo de 70B não foi sustentada por comparação primária aplicável com mesmo workload, qualidade, hardware e política de custos. O correto é medir custo por decisão aceita, incluindo abstenções, revisão humana, carga do modelo, tokenização, serialização, inferência e manutenção. Parâmetros e tokens de saída são variáveis úteis, não uma conta completa de custo operacional.

Ausência de sampling também não estabelece reprodutibilidade entre CPU/GPU, kernels, quantização ou versões. O objetivo físico do Ipê pode ser determinístico dentro de seu contrato; um modelo que interpreta a frase do aluno permanece uma aproximação estatística.

3. Auditoria das três aplicações propostas

A fonte PII possui uma divergência material: card informa F1 médio de 0,477, enquanto o artigo arXiv v1 informa 0,471. Recalls legal/médico também diferem. A avaliação do artigo utiliza 200 documentos e sete categorias mapeadas. Não extrapolar para todos os 42 tipos e sete idiomas declarados. Não converter 1−recall de spans exatos em probabilidade de um documento vazar; a exposição parcial de uma entidade e a persistência/transmissão do dado precisam de medições próprias.

4. Modelo candidato para o Ipê

O candidato específico é fastino/GLiNER2.5-multi-Decide, de 287M conforme seu card, para selecionar uma pergunta de acompanhamento a partir da explicação do participante. O benchmark divulgado do card continua sendo inglês: 56,7% exact-match médio nessa suíte. Esse número não é acurácia prevista para português brasileiro ou conceitos de engenharia espacial. O card indica Apache 2.0; GLiDE usa outra licença, Fastino Community. Não atribuir a licença de um modelo a toda a família.

A inferência opcional poderia classificar sinais como “confunde potência com energia”, “assume que o rádio resolve sozinho” ou “não identificou o limite”, mas a taxonomia deve nascer de entrevistas/observações reais e revisão humana. O texto mostrado em resposta é um item editorial conferido, condicionado à interpretação proposta. A correção científica do item não garante que ele se aplica à intenção daquela pessoa.

No P0, a pessoa escolhe uma previsão e recebe diagnóstico ligado a eventos. Nenhuma chamada Fastino, LLM remoto ou modelo local foi integrada. Não foram baixados pesos, medidos tokens/s ou executada inferência em GPU. A decisão mantém a tarefa utilizável antes de provar o ganho de IA.

5. Runtime e dimensionamento

A rota inicial verificável para GLiNER é a biblioteca oficial gliner2 e AutoExtractor. Há port comunitário sandrohanea/gliner.cpp. O PR llama.cpp #30504 observado nesta pesquisa está aberto e é limitado a classificação Decide, excluindo spans, records e outros checkpoints. Isso impede declarar PII suportado só porque existe um conversor GGUF. Unsloth possui ferramentas próprias, mas não foi encontrada integração documentada que autorize presumir suporte aos IDs pesquisados.

GLiDE 27B documenta 52,2 GB de pesos e 56,4 GB de pico de GPU na amostra publicada, em GPU de 96 GB, com recomendação de 80 GB ou mais. Esse perfil não deve ser transferido à RTX 3070 ou RTX 2060 Super relatadas anteriormente. Versões menores podem ser avaliadas separadamente, mas a simples existência de uma versão menor não demonstra o mesmo comportamento/qualidade da maior.

Para um serviço local futuro: processo dedicado de inferência, um único modelo carregado, fila limitada, concorrência inicial 1 e limite de entrada explícito. Validar ganho antes de aumentar batch. Transportar somente texto consentido e IDs de contexto; não enviar a simulação inteira por conveniência. Depois da medição, definir timeout e circuit breaker. HTTP em loopback com controle de origem ou socket local autenticado pode bastar; gRPC/contêineres não são obrigatórios sem requisito concreto.

O servidor não pode executar comandos fornecidos pelo modelo. Decisões sobre retry, timeout ou descarte decorrem da política da aplicação. Alternar uma chave de API não resolve erro de contrato e não deve ser interpretado como autorização para contornar limitação do serviço. Toda ação proposta fica subordinada ao estado permitido e à validade do request ID.

6. Experimento de ablação proposto

O protocolo detalhado prevê 1.200 explicações pedagógicas e 600 textos de privacidade, com revisão humana e separação por família de cenário. Não é dataset já produzido. Para o jogo, começar com corpus menor de observações reais para formar a taxonomia e só então congelar um teste de aceitação. Textos sintéticos podem ampliar casos de fronteira, mas não substituem pessoas reais no teste do produto.

Comparar: regras/editorial; modelo sem regras; híbrido com validação; híbrido com abstenção. Medir macro F1 por classe, confusão de conceitos críticos, cobertura×erro, taxa de abstenção, adequação da pergunta, latência fria/quente, RAM/VRAM e comportamento sob concorrência. Segregar português coloquial, negações, ironia, mistura de idiomas, Unicode, erros de digitação e instruções adversariais embutidas.

Um modelo só entra no produto se acrescentar benefício na tarefa sem comprometer os limites de tempo/memória definidos e se não houver degradação material em classes críticas. O limiar deve ser calibrado no conjunto de desenvolvimento; não ajustado repetidamente no teste fechado. Quando a confiança não sustenta uma interpretação, pedir ao usuário que escolha uma alternativa explícita.

7. Spec Kit aplicado ao projeto

Foi observada a release github/spec-kit v1.4.0, de 10/11/2026, commit 0019fa14d12f45edabc2cc3176c9168a68bd0f97. A documentação atual inclui convergência entre especificação e implementação. Nenhum instalador ou CLI foi executado. O projeto incorpora a disciplina por arquivos: constituição, spec, plano, tarefas e rastreabilidade.

O gate de convergência é concreto: requisito → função → teste/oráculo → recibo → limitação. Corrigir a especificação para concordar silenciosamente com um bug não é convergência. Um achado de revisão deve conservar o contraexemplo, registrar a decisão e repetir o teste afetado. Converged emitido por um agente não substitui execução e inspeção.

Fontes centrais

• https://huggingface.co/fastino/GLiNER2.5-Decide
• https://huggingface.co/fastino/GLiNER2.5-multi-Decide
• https://huggingface.co/fastino/gliner2-privacy-filter-PII-multi
• https://arxiv.org/html/2605.09973v1
• https://fastino.ai/blog/training-glide-sota-decision-model
• https://huggingface.co/fastino/GLiDE-27B/blob/main/README.md
• https://huggingface.co/fastino/GLiDE-0.4B/blob/main/LICENSE
• https://github.com/ggml-org/llama.cpp/pull/30504
• https://github.com/sandrohanea/gliner.cpp
• https://github.com/github/spec-kit/releases/tag/v1.4.0

Os números de terceiros são reportados pelos autores e não reproduzidos nesta bancada. As fontes completas, limitações e diferenças de versões ficam no parecer integral da frente 2.

CADERNO / 07

07 — Schema Prisma e persistência implementada

O schema completo está em prisma/schema.prisma; a configuração CLI 7 está em prisma/prisma.config.ts. O comando prisma validate com versão 7.10.1 foi executado e aprovou a estrutura. Não houve geração de client, aplicação de migração, inicialização de serviço Node/SQLite nem conexão da UI ao Prisma. O produto implementado usa IndexedDB, conforme src/persistence/store.ts.

1. Modelo relacional proposto

As FKs compostas impedem associar uma observação ou parâmetro a uma fonte de outro pacote apenas porque os IDs individuais existem. onDelete:Restrict preserva dependências de execução; cascatas ficam nos filhos pertencentes ao mesmo agregado. Isso não substitui uma política operacional de retenção e backup quando houver backend real.

2. Tipos e limitações

BigInt no banco representa contadores de bits; na API JSON, a representação é string decimal. A versão atual também limita os contadores ao domínio de inteiros seguros usado no motor. Float no schema para energia/tempo é uma projeção, não a representação racional interna. Uma evolução que precise preservar cada fração deve armazenar numerador/denominador ou unidade inteira documentada e versionar o contrato.

O schema não impõe todos os checks de domínio: faixa de NDVI, energia não negativa, relação entre bits, validade das datas, replay compatível e ordem temporal continuam em validadores/transações de aplicação. SQLite e Prisma não transformam um JSON de resultado em prova científica. A integração futura precisa implementar transação única para Run, eventos, observações e trace e testar interrupção antes/depois do commit.

3. IndexedDB efetivo

Nesta entrega, o banco local mission-ipe-research-v1 contém runs e drafts. A escrita resolve após transaction.complete. O índice composto inputHash + resultHash impede duplicação da mesma execução. Cada leitura confere formato e integridade. O rascunho usa compare-and-swap atômico; duas abas com a mesma revisão não confirmam duas escritas concorrentes como se ambas fossem atuais.

Os testes fake-indexeddb exercitam conflito, quota, rollback e request success seguido de abort. São testes de contrato com implementação de teste da API; não substituem comportamento real de quota/evicção em Chromium, Firefox ou Safari. Alterar porta/origem ou localização do HTML pode mudar o armazenamento do navegador; exportar recibos antes de mover a instalação. Um arquivo JSON exportado permanece portátil dentro das versões suportadas.

4. Comando de validação

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

Esse comando pode acessar o registro se a CLI não estiver no cache. O runtime do jogo não precisa dele. Para offline de desenvolvimento integral, provisionar também CLI e dependências na plataforma-alvo. Não executar migrate/reset em dados existentes sem revisar o destino e a operação.

CADERNO / 08

08 — Handoff: o que existe, como conferir e quando avançar

Missão Ipê — Ciência que chega · 14/11/2026. Entrega de P&D pré-evento. Rodada iniciada às 08h23 UTC / 05h23 BRT; abertura local oficial às 09h BRT / 12h UTC. Código e especificações específicos são anteriores à abertura. A autorização de trabalho dada por AB não estabelece elegibilidade NASA Space Apps. Não existe decisão observada de aprovação especial ou de desclassificação desta equipe.

Uso atual recomendado: estudar e verificar um protótipo educacional local. O produto tem uma missão NDVI, duas condições de contato e 64 configurações. A candidatura permanece condicionada à decisão dos organizadores, à qualificação de um recurso nos Resources oficiais e à adequação ao enunciado completo. Preservar, separar, declarar ou reescrever o material não garante regularização.

1. Estado atual e leitura dos artefatos

Os relatórios de pesquisa preservam o estado observado por cada frente. Não somar suas contagens de testes como execuções independentes nem copiar metas como medições. evidence/final-validation.json, concluído às 09h05min34s UTC, registra 51 testes Node, nove testes DOM simulado, ciência, TypeScript/Vite, build portátil e Prisma 7.10.1 aprovados. O recibo DOM posterior das 09h05min40s também registra nove aprovados. Existem benchmark e nova inspeção AB-R3A, com limites abaixo. PDF/ZIP ficam sob fechamento da coordenação; testes de navegador e pesquisa humana permanecem abertos.

Para orientar a equipe: docs/01 contém decisão e elegibilidade; 02, produto; 03, contrato técnico; 04, fluxos; 05, cronograma; 06, modelos e anexos; 07, Prisma e persistência. docs/09-VERIFICACAO.md consolida os recibos e docs/10-FRENTES-E-RASTREABILIDADE.md relaciona as dez frentes e seus artefatos. research/07 conserva contraprovas independentes; research/08 audita 33 famílias e 67 consultas de repositório; research/10 registra esta revisão final. evidence/chronology.json preserva a cronologia e evidence/adversarial-review.json, as correções verificadas. O fechamento de PDF/ZIP deve ser conferido pelos recibos artifact-build e package-manifest emitidos pela coordenação; ele não fecha o gate de navegador real.

2. Responsáveis, entradas e saídas

AB é a referência humana de produto e coordenação informada. As demais linhas designam funções a distribuir entre as pessoas disponíveis, sem inventar composição de equipe. As dez frentes de IA são trabalho de pesquisa assistida, não dez participantes inscritos.

A pessoa que implementa uma regra não deve ser sua única verificadora. A explicação do facilitador não pode anteceder a primeira decisão que será reportada como transferência sem ajuda. Quem grava a demo usa o build identificado, sem substituir os resultados por números editados.

3. Reprodução técnica

Executar os comandos a partir da raiz de ab-mission-ipe. O ambiente declarado requer Node 24 ou superior. O lockfile fixa dependências. A primeira instalação precisa de registro npm acessível ou de dependências/cache previamente provisionados; não faz parte da alegação de runtime offline.

node --version
npm ci
npm test
npm run test:ui
node --experimental-strip-types scripts/verify-science-data.mjs
npm run benchmark:engine
npm run build
npm run build:portable
node scripts/export-examples.mjs

Com dependências já instaladas e corretas, não é necessário repetir npm ci para usar o pacote. npm test executa núcleo, persistência, replay e revisão adversarial encontrados em tests/*.test.mts; test:ui usa jsdom, núcleo real e fake-indexeddb, sem navegador real. O verificador científico lê originais locais sem buscar URLs e sem escrever neles. O build portátil atual, de 09h05min25s UTC, tem 1.008.522 bytes e sucede as correções. Uma mudança futura exige novo build e recibo.

export-examples.mjs regenera examples/01-long-base.json (6/6), 02-short-base.json (2/6) e 03-short-repaired.json (6/6), importáveis pelo caderno. Também atualiza evidence/catalog-enumeration.json com 128 resultados de pesquisa gerados pelo motor. Não é certificado independente de busca; os oráculos e a revisão adversarial são evidências distintas.

Para servir o build estático:

npm start -- --port 4173

O endereço anunciado é http://127.0.0.1:4173; Ctrl+C encerra. Esse modo usa o Worker. A aplicação não precisa de banco remoto, chave de API, CUDA ou modelo local. O servidor serve arquivos em loopback e não deve ser apresentado como backend multiusuário.

O recibo evidence/server-http-smoke.json registra oito casos HTTP aprovados, incluindo arquivos servidos, métodos e rejeição de caminhos inválidos. Isso testa o servidor por requisições HTTP, sem executar a interface num navegador.

portable/Missao_Ipe_Local.html incorpora bibliotecas, CSS e dados. Sua execução por arquivo usa o núcleo na thread principal. A abertura por duplo clique e o comportamento de armazenamento ainda precisam de teste em navegador real autorizado. Mudar origem, porta ou localização do HTML pode mudar o armazenamento disponível; exportar recibos antes de mover a instalação. A origem de arquivo não garante IndexedDB em todos os navegadores.

A validação opcional de Prisma é independente do jogo:

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

Esse comando pode usar a rede se a CLI não estiver no cache. Valida o schema; não cria backend integrado. Não são necessários comandos de geração, migração ou reset para demonstrar o P0.

O benchmark de evidence/engine-benchmark.json usa Node 24.22.1 em AMD EPYC 9V45, 30 aquecimentos e 200 amostras por carga. Na busca de 64 tuplas, mediana/p95: 4,201/4,936 ms no caso longo e 3,994/4,237 ms no curto. O máximo curto foi 32,073 ms. Isso exclui inicialização, transporte Worker, React, persistência e GPU; não é medida do computador de AB.

A conferência EVI3 de pesquisa pode ser repetida com Python 3, sem alterar o recibo histórico:

python3 research/evidence/validate-evi3-research.py

O script corrigido lê public/data relativa ao projeto e imprime JSON. --out caminho-novo.json cria um recibo novo e recusa sobrescrita. evidence/evi3-rerun.json registra seis comparações aprovadas às 09h02min40s UTC, com diferença máxima de 0,00009379329454142421. É conferência de P1; EVI3 não entrou no jogo.

4. Casos de conferência e roteiro da demonstração

Configuração padrão: bateria pequena, painel standard, BANDAS R/NIR, rádio econômico, memória grande e todos os contatos. O objetivo continua sendo receber seis resultados científicos válidos nas duas condições.

A enumeração longa registra 17 sucessos, 41 falhas e 6 inválidas; a curta, 9 sucessos, 49 falhas e 6 inválidas. São 64 avaliações em cada condição, sem indeterminadas. O mínimo curto é limitado a esse catálogo e foi conferido por um oráculo independente. O replay exporta a missão executada; não exporta a prova completa da busca.

Na demonstração, pedir previsão, executar o padrão curto, inspecionar a restrição, experimentar uma alteração isolada e só então revelar o redesenho verificado. O participante precisa distinguir W de Wh e dado recebido de registro utilizável. O roteiro é uma proposta de apresentação, não evidência de que alguém aprendeu. No estudo humano, preservar a primeira tentativa e o nível de ajuda; não ensinar a solução antes de registrá-la.

5. Gates de avanço

É possível continuar P&D com G0 aberto, mantendo o status explícito. Fechar G1/G2 não fecha G0, G4 ou G5. A nova execução AB-R3A começou às 09h05min21s UTC e terminou em 7,634 s, saída 0: 43 arquivos, 40 JS/TS analisados, zero falhas de parse, 40.369 nós AST e 596 achados estruturais. O digest em evidence/ab-r3a-digest.json declara cobertura de aplicação parcial e semântica parcial/truncada, além de alteração posterior apenas no teste DOM. Esses achados não são vulnerabilidades confirmadas, e a execução não certifica segurança, equivalência, navegador ou aprendizagem.

6. Cronograma crítico em BRT

O prazo global de 23h59 de domingo não substitui o prazo local. O cronograma é planejamento, não relato de execução, escala de pessoas confirmada ou mecanismo de regularização temporal.

7. Limites a repetir na apresentação

MOD13Q1 é produto histórico composto em intervalos de 16 dias. O jogo usa seis registros arquivados de 2024 e não simula aquisição MODIS pelo CubeSat em 180 minutos. Os seis QA têm usefulness 1 e reliability 0. Volumes de lote e números de hardware são hipóteses didáticas. EVI3 foi recalculado apenas como pesquisa P1 e exige BLUE adicional.

Hash confere identidade de conteúdo em relação aos bytes esperados. Reexecução verifica consistência com o motor atual. Nenhum deles autentica autoria, identidade do aluno, aprovação NASA ou verdade física universal. O diário de previsão/reflexão é armazenado localmente no fluxo normal, pode conter texto pessoal e pode ser alterado por quem controla o navegador; não há filtro de PII instalado. A exportação é uma ação deliberada.

O ambiente desta rodada não permitiu iniciar Chromium com socket, e o CUA recusou explicitamente a navegação file:. Essas restrições não foram contornadas. DOM, FakeWorker e fake-indexeddb verificam contratos em ambiente simulado; não são screenshots, medições de GPU ou ensaio de navegador. Não foram medidos RTX 3070, RTX 2060 Super, Mac, celular, FPS ou latência de interface no equipamento de AB.

Fastino permanece pesquisa documental, sem pesos ou inferência. GLiDE 27B demanda cerca de 52,2 GB apenas nos pesos publicados e não deve ser prometido para as GPUs citadas. Licença, arquitetura e qualidade variam por modelo/revisão; formato GGUF não garante compatibilidade de runtime. O P0 funciona sem IA interpretando o aluno e sem IA decidindo ciência ou física.

Após a verificação do P0, cada expansão abre seu próprio contrato: EVI3 com três bandas; grade de robustez sem probabilidades inventadas; modelo compacto com abstenção e avaliação pt-BR; agenda orbital comparada com referência; backend relacional com transações reais. Nenhuma expansão é necessária para tornar o estado atual honesto e revisável.

CADERNO / 09

09 — Verificação executada e limites da versão 0.1.1

Motor 0.1.1-rd · catálogo ipe-64-v1 · 14/11/2026. Este capítulo registra a implementação entregue. Os relatórios individuais preservam o estado observado em cada frente; propostas anteriores e falhas históricas não são apagadas. Desenvolvimento específico anterior à abertura local: elegibilidade competitiva pendente.

1. Gate de integração

evidence/final-validation.json conserva comando, horário, duração, código de saída, stdout/stderr e hashes das fontes. A execução consolidada passou em todas as seis etapas:

O TAP DOM conta um teste pai da jornada, seis checkpoints encadeados e dois casos independentes. Não são nove jornadas humanas nem nove navegadores. Após o gate, a frente 9 reforçou duas assertivas da importação para conferir a configuração ativa na bancada e reexecutou o teste; evidence/ui-dom-test.json e .tap registram esse complemento. Não houve alteração do código da aplicação nessa etapa.

2. Matriz de resultados do catálogo

A revisão independente usa constantes literais do contrato e integração alternativa por segundos, com tratamento analítico do término de transmissão. Ela comparou classificação, massa, créditos, bits, energia final/mínima e conclusão em 128 casos. Quatro ordens de enumeração conservaram o resultado. Todas as sete configurações a distância zero ou um da base curta falharam; a única testemunha a distância dois é bateria grande + ÍNDICE.

evidence/catalog-enumeration.json acrescenta uma tabela de pesquisa com as 128 saídas do motor atual. Esse arquivo é uma reprodução do motor, não outro oráculo independente. Os exemplos 01-long-base, 02-short-base e 03-short-repaired são replays completos importáveis. O JSON exportado pela interface é recibo de uma execução; não inclui um certificado exportado completo da busca.

3. Defeitos encontrados e correções preservadas

Os registros vermelhos da frente 7 permanecem em evidence/adversarial-review.json. A versão do motor foi incrementada. O máximo erro EVI3 observado foi 0,00009379329454142421; isso valida a comparação desses seis registros, não o algoritmo MODIS inteiro nem uma missão EVI implementada.

4. Persistência e fluxo de interface

Os testes de persistência verificam concorrência de gravações idênticas, um vencedor no CAS de revisão entre conexões, quota injetada, erro assíncrono, request bem-sucedido seguido de abort, corrupção persistida e snapshot da entrada antes dos awaits. Os 128 roundtrips exportam e reexecutam as configurações dos dois cenários. Uma alegação alterada com hash novo correto retorna divergência; um hash sem chave não autentica autor.

O fluxo DOM exige previsão e justificativa, executa a base longa com 6/6, a curta com 2/6, abre a busca de 64 alternativas, aplica a solução e chega a 6/6. Também verifica que importar uma execução válida não concede a ajuda reservada à primeira tentativa própria e que indisponibilidade de IndexedDB/localStorage mantém resultado e exportação.

O ambiente de teste fornece substitutos apenas para APIs ausentes: contexto WebGL retorna null; scroll é neutro; diálogo usa atributos de abertura. Não simula a pontuação. O teste não mede layout, foco real, contraste, leitor de tela, renderização, GPU ou execução real de Web Worker. Testes de contrato do bridge usam Worker controlado para reproduzir ordem/cancelamento/erros; não equivalem ao escalonamento de um browser.

5. Servidor e dependências locais

O smoke HTTP executou uma única instância de servidor em 127.0.0.1, depois encerrada. Oito casos passaram: GET e HEAD 200; POST 405; ausente 404; tentativa de atravessar diretório 403; byte nulo, barra invertida e codificação inválida 400. O recibo conserva cabeçalhos e hashes dos corpos. Não foi teste de navegador nem tentativa de contornar o bloqueio de acesso visual.

A auditoria estática da aplicação leu 28 arquivos e não localizou chamada de rede nem asset remoto obrigatório. A URL NASA observada era comentário de fonte. O HTML portátil final tem 1.008.522 bytes, incorpora os dez JSONs e tem zero dependências externas de runtime no metadado do build. Isso sustenta o empacotamento local; o teste de abertura fria sem rede no navegador-alvo permanece pendente.

O inventário registrou 157 entradas no lock e 83 pacotes instalados nesta plataforma, sem divergência de versão nem ausência de metadado de licença entre os pacotes instalados. As quatro dependências de runtime — React, ReactDOM, Scheduler e Three.js — possuem avisos MIT preservados. Metadado não é auditoria jurídica de toda dependência ou dataset. Pacotes opcionais de outras plataformas não foram executados. Nenhum node_modules é necessário para servir o dist com o script Node incluído.

6. Benchmark do núcleo

Recibo: evidence/engine-benchmark.json, medido às 09h04min05s UTC. Node 24.22.1, V8 13.6, Linux x64, executor identificado como AMD EPYC 9V45, nove CPUs lógicas disponíveis e aproximadamente 10,45 GB de memória total informada. Foram 30 aquecimentos e 200 amostras por carga, em sequência. Percentis por nearest rank; amostras completas preservadas.

Os tempos excluem inicialização de Node, carregamento de módulo, Worker, renderização React/Three, GPU, hash, IndexedDB e abertura fria offline. O executor é compartilhado, sem fixação de CPU ou controle térmico. Não se convertem esses valores em latência de ponta a ponta, FPS ou desempenho de RTX 3070/2060 Super/Mac. Eles mostram que o núcleo finito não exige cluster ou modelo de linguagem para a carga medida.

7. AB-R3A / REA

Foi executado o runtime local REA 6.7.0 disponibilizado no AB-R3A. O wrapper fixa versão, limita fontes/bytes/tempo/output, cria snapshot e não executa a aplicação inspecionada. O recibo completo está em evidence/ab-r3a-analysis.json; a leitura compacta está em evidence/ab-r3a-digest.json.

Resultado: exit 0, 7,634 s; 43 arquivos, 244.722 bytes de fonte; 40 arquivos JavaScript/TypeScript processados; zero falhas de parsing; 40.369 nós AST visitados. Os 596 findings são observações estruturais, não 596 vulnerabilidades confirmadas. O grafo de aplicação tem cobertura parcial; o semântico também é parcial e contém truncamento por orçamento de resultado. Há 5.460 unknowns semânticos no retorno. Não anunciar análise completa, ausência de falhas ou certificação de segurança.

O snapshot antecede o reforço de duas assertivas em tests-ui/flows.test.mjs. A conferência de hashes identifica somente esse arquivo alterado; o runtime auditado permanece o da entrega. Dependências externas, assets e builds não pertencem ao escopo de fontes da análise. Os limites de heap são por processo, não um teto agregado da família de processos; execução local tampouco é uma sandbox de rede do sistema operacional.

8. Gates ainda abertos

Navegador real, experiência visual, foco/teclado/leitor de tela, FPS, abertura fria offline, armazenamento em Safari/Firefox/Chromium, tolerância a contexto WebGL perdido, equipamentos de AB e pesquisa humana não foram qualificados. O Chromium local falhou por restrição de socket; a superfície de browser recusou protocolo de arquivo explicitamente. Não foi usado contorno desse bloqueio. DOM e HTTP verificam outras camadas.

Elegibilidade temporal, Resources específicos e adequação ao enunciado integral são gates da candidatura. Lançador/perfil orbital estão fixos no P0; não há propagador, link budget RF, ambiente térmico ou hardware em loop. A entrega de P&D é concreta e reproduzível nas camadas verificadas; esses limites fazem parte da especificação, dos recibos e do cronograma.

CADERNO / 10

10 — Dez frentes, fontes e rastreabilidade

Foram recrutadas dez frentes distintas com modelo gpt-6-astra, esforço max, conforme o pedido de AB. O limite de concorrência comporta três auxiliares junto à coordenação, portanto a execução ocorreu em ondas. Os agentes participaram remotamente desta pesquisa e implementação; eles não constituem dez modelos Astra executados nos equipamentos locais de AB.

A coordenação integrou contratos, corrigiu os defeitos reproduzidos, reconstruiu os distribuíveis, aplicou AB-R3A, verificou artefatos e consolidou esta documentação. A responsabilidade de verificar decisões científicas, adequação à competição e uso humano continua com a equipe; multiplicar revisores de IA não cria aprovação institucional.

Fontes e anexo

Os dois arquivos colados recebidos são idênticos: 32.575 bytes cada, SHA-256 62fa654201593bf9dd4f62667dcb91d3e89f98f00cf001ac1506847d0506dc51. Uma cópia está preservada em research/anexo-original.txt. O catálogo contém 33 famílias editoriais auditadas; Fastino e Spec Kit vieram da mensagem, não desse catálogo. Trechos incompletos do briefing não foram reconstruídos por suposição.

O inventário de repositórios registra 67 consultas GitHub, URLs, correções, termos identificados, hashes e estados de recuperação. Número de consultas não é número de tecnologias integradas, número de países nem avaliação universal de qualidade. Repositórios indisponíveis permanecem “não recuperados”; isso não é prova de inexistência.

Os READMEs integrais obtidos para inspeção são material temporário e não entram na distribuição. A entrega preserva matrizes, URLs, hashes, metadados selecionados e paráfrases. Os relatórios indicam limites de licença e maturidade, sem atribuir termos de uma biblioteca a pesos, datasets ou assets independentes.

evidence/source-index.json indexa os links mencionados nos documentos atuais. O índice é ferramenta de navegação: inclusão nele não equivale a recuperação bem-sucedida, verificação de toda a página ou endosso. Cada parecer conserva a evidência e a limitação associadas ao link. Os estudos anteriores sobre o júri mundial e a seleção estão preservados em research/history/.

Requisito → implementação → prova

specs/traceability.json relaciona requisitos científicos, físicos, de busca, persistência, UX e execução local a funções, testes, fontes e recibos. Os hashes permitem identificar a versão lida. O campo de estado distingue Node, DOM simulado, IndexedDB de teste e validação de navegador pendente. A matriz não conta como uma execução adicional de teste.

O processo documental segue constituição, especificação, plano, tarefas e conferência, inspirado no github/spec-kit. O CLI upstream não foi instalado. A release pesquisada e suas limitações estão no parecer 03. Nenhum script upstream foi executado apenas porque apareceu numa página pesquisada.

O manifesto do ZIP identifica os arquivos distribuídos. Artefatos visuais do dossiê foram renderizados para inspeção de paginação; isso não deve ser confundido com uma captura ou teste da interface do jogo. A cronologia real de criação permanece registrada, inclusive o início anterior ao evento.

CADERNO / 11

11 — Apêndice: schema Prisma integral

Cópia exata do contrato opcional de persistência relacional. A validação estrutural foi executada; o runtime atual usa IndexedDB. O schema não é evidência de backend integrado. Arquivos editáveis preservados no pacote.

schema.prisma

// MISSÃO IPÊ — P&D específico iniciado em 14/11/2026 antes das 09h BRT.
// Elegibilidade NASA não estabelecida. Datas e autoria não são retroagidas.
// Arquitetura OPCIONAL para Node/SQLite: NÃO é o IndexedDB que a UI usa.
// Não há backend, client gerado, migração aplicada nem integração Prisma no app.

generator client {
  provider = "prisma-client"
  output   = "../server/generated/prisma"
}

datasource db {
  provider = "sqlite"
}

enum ProvenanceKind {
  OBSERVATIONAL_PRODUCT
  TRANSCRIBED
  DERIVED
  ASSUMPTION
}

enum ParameterSourceRole {
  VALUE
  DERIVATION_INPUT
  CONCEPT
}

enum MissionOutcome {
  SUCCESS
  FAILURE
  INVALID
}

enum ReplayVerification {
  LOCAL_COMPUTED
  RECOMPUTED_MATCH
  RECOMPUTED_MISMATCH
}

enum ObservationState {
  NOT_PRODUCED
  QUEUED
  PARTIAL
  DELIVERED
  LOST
  INVALID
}

enum EventSeverity {
  INFO
  WARNING
  ERROR
}

// Revisão imutável. Hash de conteúdo não autentica a origem nem prova física.
model ScenarioPack {
  id                      String                @id
  key                     String
  version                 String
  sciencePackHash         String
  contentHash             String                @unique
  engineVersion           String
  catalogVersion          String
  resultSchemaVersion     Int
  canonicalizationVersion String
  numericPolicy           String
  content                 Json
  createdAt               DateTime              @default(now())
  sources                 SourceReference[]
  scienceRecords          ScienceRecord[]
  parameters              ScientificParameter[]
  missionConfigs          MissionConfig[]

  @@unique([key, version])
}

// URLs são apenas proveniência. Importação não as acessa automaticamente.
model SourceReference {
  id                  String              @id
  packId              String
  key                 String
  title               String
  publisher           String
  url                 String
  productDoi          String?
  serviceDoi          String?
  retrievedAt         DateTime?
  originalSha256      String?
  originalByteLength  Int?
  originalLocalPath   String?
  licenseNote         String?
  pack                ScenarioPack        @relation(fields: [packId], references: [id], onDelete: Cascade)
  records             ScienceRecord[]
  parameterReferences ParameterSource[]

  @@unique([packId, key])
  @@unique([id, packId])
}

// Datas de arquivo não são segundos simulados. Coordenadas são as solicitadas,
// não uma alegação de centro preciso de pixel. Um registro referencia fonte no mesmo pack.
model ScienceRecord {
  id                 String              @id
  packId             String
  key                String
  sourceId           String
  kind               ProvenanceKind      @default(OBSERVATIONAL_PRODUCT)
  latitudeRequested  Float
  longitudeRequested Float
  compositeStart     String
  observationDate    String
  modisDate          String
  redInteger         Int
  nirInteger         Int
  viQuality          Int
  pixelReliability   Int
  ndviProduct        Float
  scale              Float
  offset             Float
  pack               ScenarioPack        @relation(fields: [packId], references: [id], onDelete: Cascade)
  source             SourceReference     @relation(fields: [sourceId, packId], references: [id, packId], onDelete: Restrict)
  observations       Observation[]
  events             RunEvent[]

  @@unique([packId, key])
  @@unique([id, packId])
  @@index([sourceId, packId])
}

model ScientificParameter {
  id               String              @id
  packId           String
  key              String
  provenanceKind   ProvenanceKind
  value            Json
  unit             String
  conditions       String
  transformation   String?
  dependencyKeys   Json
  uncertaintyNote  String?
  pack             ScenarioPack        @relation(fields: [packId], references: [id], onDelete: Cascade)
  sourceReferences ParameterSource[]

  @@unique([packId, key])
  @@unique([id, packId])
}

// FKs compostas: fonte e parâmetro obrigatoriamente pertencem ao mesmo pack.
model ParameterSource {
  packId      String
  parameterId String
  sourceId    String
  locator     String
  role        ParameterSourceRole @default(CONCEPT)
  parameter   ScientificParameter @relation(fields: [parameterId, packId], references: [id, packId], onDelete: Cascade)
  source      SourceReference     @relation(fields: [sourceId, packId], references: [id, packId], onDelete: Restrict)

  @@id([parameterId, sourceId])
  @@index([sourceId, packId])
}

// inputHash cobre escolhas, cenário, modo de trace, versões e hash do pack.
model MissionConfig {
  id                  String       @id
  packId              String
  inputSchemaVersion  Int
  engineVersion       String
  catalogVersion      String
  inputHash           String       @unique
  input               Json
  createdAt           DateTime     @default(now())
  pack                ScenarioPack @relation(fields: [packId], references: [id], onDelete: Restrict)
  runs                Run[]

  @@unique([id, packId])
  @@index([packId, createdAt])
}

// Persistir Run, eventos, observações e chunks na MESMA transação de aplicação.
// O schema não implementa essa transação; não é alegação de integração concluída.
model Run {
  id                  String             @id
  packId              String
  missionConfigId     String
  inputHash           String
  resultHash          String
  resultSchemaVersion Int
  outcome             MissionOutcome
  verification        ReplayVerification
  completedAtS        Float
  result              Json
  createdAt           DateTime           @default(now())
  missionConfig       MissionConfig      @relation(fields: [missionConfigId, packId], references: [id, packId], onDelete: Restrict)
  observations        Observation[]
  events              RunEvent[]
  traceChunks         TraceChunk[]
  importClaims        ImportClaim[]

  @@unique([inputHash, resultHash])
  @@unique([id, packId])
  @@index([missionConfigId, packId])
  @@index([createdAt])
}

// BigInt no banco; string decimal no JSON. Aplicação limita a 2^53−1 nesta versão.
// Aplicação valida 0 <= downlinkedBits + lostBits <= generatedBits e QA.
model Observation {
  runId          String
  packId         String
  scienceRecordId String
  generatedBits  BigInt
  downlinkedBits BigInt
  lostBits       BigInt
  state          ObservationState
  producedAtS    Float?
  deliveredAtS   Float?
  ndvi           Float?
  expectedNdvi   Float
  scienceValid   Boolean
  run            Run           @relation(fields: [runId, packId], references: [id, packId], onDelete: Cascade)
  scienceRecord  ScienceRecord @relation(fields: [scienceRecordId, packId], references: [id, packId], onDelete: Restrict)

  @@id([runId, scienceRecordId])
  @@index([scienceRecordId, packId])
  @@index([runId, state])
}

model RunEvent {
  runId           String
  packId          String
  eventId         String
  ordinal         Int
  timeS           Float
  code            String
  severity        EventSeverity
  rule            String
  message         String
  scienceRecordId String?
  value           Float?
  limit           Float?
  run             Run            @relation(fields: [runId, packId], references: [id, packId], onDelete: Cascade)
  scienceRecord   ScienceRecord? @relation(fields: [scienceRecordId, packId], references: [id, packId], onDelete: Restrict)

  @@id([runId, eventId])
  @@unique([runId, ordinal])
  @@index([scienceRecordId, packId])
}

model TraceChunk {
  runId       String
  packId      String
  ordinal     Int
  startTimeS  Float
  endTimeS    Float
  sampleCount Int
  contentHash String
  samples     Json
  run         Run    @relation(fields: [runId, packId], references: [id, packId], onDelete: Cascade)

  @@id([runId, ordinal])
  @@index([runId, packId])
}

// Alegação importada preservada separadamente do resultado recalculado.
// Match apenas confirma consistência com esta versão do motor, não verdade física.
model ImportClaim {
  id                  String   @id
  packId              String
  recomputedRunId     String
  replaySchemaVersion Int
  envelopeHash        String   @unique
  claimedInputHash    String
  claimedResultHash   String
  importedClaim       Json
  matchesClaim        Boolean
  importedAt          DateTime @default(now())
  recomputedRun       Run      @relation(fields: [recomputedRunId, packId], references: [id, packId], onDelete: Cascade)

  @@index([recomputedRunId, packId])
}

// CAS futuro exige UPDATE ... WHERE id=? AND revision=? dentro da transação.
// Esta tabela não é usada pelo browser; store.ts implementa CAS no IndexedDB.
model Draft {
  id         String   @id
  revision   BigInt   @default(0)
  config     Json
  scenarioId String
  updatedAt  DateTime @updatedAt
}

prisma.config.ts

// CLI opcional fixada: prisma@7.10.1. Caminhos relativos a este arquivo.
// Sem dotenv, credenciais, geração de client ou conexão do app ao banco.
export default {
  schema: './schema.prisma',
  migrations: { path: './migrations' },
  datasource: { url: 'file:./mission-local.db' },
};

CADERNO / 12

Frente 1 — Regras atuais, procedência científica e limites da Missão Ipê

Pesquisa concluída em 14/11/2026, por uma frente de IA da rodada solicitada por AB. A frente recebeu como marco de coordenação 08h23 UTC / 05h23 BRT. O recálculo científico abaixo foi realmente executado às 08:28:17 UTC / 05:28:17 BRT. Não se implementou o jogo nesta frente. Os arquivos do estudo anterior foram somente lidos.

Conclusão operacional: a autorização de AB para iniciar código agora é inequívoca como instrução de trabalho. Ela não altera a orientação externa do evento: o GO Team situa o início às 09h locais de sábado, 14/11/2026, e informa que desenvolvimento antecipado pode levar à desclassificação. Não há exceção documentada para esta equipe. Registrar a produção real antes desse horário, sem declarar que a transparência garante elegibilidade e sem rebatizar implementação específica como pesquisa. A escolha de executar é da coordenação; este parecer não determina uma desclassificação nem certifica conformidade.

A segunda pendência permanece: a lista oficial de Resources do desafio não foi recuperada. Foram renovadas tentativas por busca, abertura direta, variações públicas de URL e HTTP no executor. O espelho do evento HackAthlone permite localizar nove candidatos, mas não fecha a confirmação na página oficial. MOD13Q1 é uma fonte científica primária válida; sua inclusão específica na lista de Space Mission Design Game continua não demonstrada.

1. Autoridade das regras e leitura sem exceções inventadas

Trecho curto de R01, nove palavras: “Working ahead of the hackathon can lead to disqualification.” A modalidade é possibilidade, não um veredito automático sobre Ipê. O horário autorizado pelo usuário e o horário publicado pelo organizador são fatos diferentes e precisam coexistir no registro.

Cronologia que deve permanecer visível

Na data/hora recebida, faltavam 3h37 até as 09h BRT. Iniciar antes disso produz código específico anterior à janela. Não adiar artificialmente timestamps, apagar histórico ou afirmar que recompilar depois das 09h transforma toda a autoria em trabalho do evento. Se houver material anterior incorporado, manter nome, origem, licença e papel concreto na entrega. Não foi constatada autorização especial escrita dos organizadores para AB.

2. Datas, submissão e o que ainda requer o formulário vigente

R07 — página oficial 2026 foi recuperada no índice atual: evento em 14–15/11; acesso à edição/submissão na aba Project da equipe de 09h sábado a 23h59 domingo; equipes com no máximo seis participantes. Isso sustenta a janela geral, não a inscrição ou composição humana de Ipê. A página também permite registro até o fechamento, enquanto a redação de R08 — termos diz registro antes do início; portanto não tratar inscrição tardia como garantia universal sem observar o estado real do formulário.

R09 — Rio Verde aparece indexada com pré-apresentações às 15h30, entrega na plataforma às 17h e apresentações às 18h de domingo. O texto português contém um ponto de interrogação após a indicação de plataforma; a versão inglesa não contém esse marcador. Tratar 17h como prazo operacional conservador, confirmar a agenda presencial e não inventar que a abertura de sexta antecipa o início global às 09h de sábado.

As respostas atuais R10 — #1947 e R11 — #1973, ambas de Navigators em 12/11, orientam demonstração de até 30 segundos ou até sete slides, incluindo capa/encerramento; submissão em inglês e links acessíveis, com legendas em inglês quando necessário. R10 é resposta a outro desafio, não um regulamento específico de Ipê. O guia de submissão direto retornou 502. Aplicar esses limites ao preparo, mas conferir o formulário efetivo quando disponível. A regra de mínimo de duas pessoas citada em R10 refere-se ao Universal Event e não foi generalizada aqui a Rio Verde.

Os termos R08 pedem direitos de uso, documentação de licenças e citação de fontes, incluindo materiais abertos. Conteúdo original deve ser livre ou sob licença OSI; o termo prevê Apache 2.0 quando uma licença conforme não é especificada. Não há motivo para publicar ativos privados AB sem autorização/licença compatível: basta conservar só os componentes realmente necessários e autorizados. Nenhum envio ou publicação ocorreu nesta frente.

Para IA, R06 exige identificação em texto/metadados para código e dados; imagem e vídeo gerados exigem marca visível. Conteúdo gerado não deve usar/conter/modificar elementos de marca NASA conforme a orientação publicada. A documentação de Ipê deve dizer assistência de IA, dados NASA de arquivo e hipóteses didáticas separadamente. Nenhuma simulação fictícia deve receber selo de validação, aprovação ou certificação NASA.

3. Resources: recuperação renovada, autoridade ainda pendente

URLs oficiais tentadas novamente em 14/11:

• https://www.spaceappschallenge.org/2026/challenges/space-mission-design-game/: 502 na abertura e no link que parte do espelho.
• https://www.spaceappschallenge.org/2026/challenges/space-mission-design-game/?tab=resources: inacessível pela ferramenta de busca; requisição HTTP normal no executor retornou 503 às 08:25:08 UTC.
• A variação sem www, âncora #resources e subdomínio público de staging também não forneceram a lista.
• https://www.spaceappschallenge.org/resources/team-formation-guide/ e /resources/project-submission-guide/: 502.

Não houve autenticação, contato com organizadores ou uso de conteúdo privado. A indisponibilidade observada é desta recuperação; não comprova indisponibilidade universal. Uma página de staging localizada pela busca continha datas de outubro de uma edição anterior, apesar de metadados recentes: foi descartada como confirmação de regras 2026.

R12 — espelho HackAthlone contém nove entradas e aponta expressamente a página oficial como autoridade final. Sua lista recuperada é esta, provisória enquanto não confrontada com a aba oficial:

Não foi encontrada MOD13Q1 nessa relação secundária. Isso não prova ausência na lista oficial não recuperada, mas impede usá-la agora como comprovação documental de qualificação. Também não há prova de que citar qualquer página NASA seja suficiente: o GO Team exige recurso da lista; o Navigator R10 reforça uso substantivo e demonstrado.

Como os documentos podem determinar o funcionamento

R13 — NTRS 20250002492, Julie Levri, Ames Research Center, documenta o webinar de 26/03/2025. Seu PDF primário de 29 páginas foi recuperado: slide 6 apresenta lançamento, espaço, solo e usuário; slide 7 trata de ConOps; slides posteriores cobrem requisitos, trocas e verificação/validação. É uma edição distinta do arquivo NASA de abril listado pelo espelho; não intercambiar paginação, hash ou afirmar que ambos são o mesmo arquivo.

A aplicação proposta, de autoria da equipe, é concreta: compatibilidade de lançamento e massa; geração/armazenamento a bordo; serviço finito de enlace e recepção; avaliação no usuário apenas de dados recebidos e válidos. Cada fase deve emitir evidência de requisito atendido ou não. Um requisito de entregar seis índices válidos só é satisfeito no receptor, mesmo que a memória a bordo esteja cheia. Esse encadeamento é substantivo; uma página de créditos sem efeito no motor não o demonstra.

R14 — CubeSat 101, revisão de outubro/2017, reforça a inclusão da estação de solo e da operação na missão. Usá-lo para essa estrutura é defensável. Seu exemplo histórico de restrição de rádio não deve se converter em regra universal 2026. Potência, massa, custos, taxa de enlace e agenda escolhidos pela equipe continuam hipóteses didáticas até serem sustentados por fontes de hardware específicas.

Parecer de qualificação: docs de engenharia listados podem ser recursos NASA substantivos porque seus conceitos comandam regras do jogo. Isso é uma interpretação tecnicamente motivada, ainda condicionada à lista oficial e à avaliação dos organizadores. MOD13 pode fortalecer a ciência como fonte adicional; isoladamente não fecha o requisito de lista. Não escrever “elegível” como estado já conferido.

4. Ciência P0 preservada: arquivo MODIS, NDVI, qualidade e entrega

Foram lidos o pack e os três JSONs anteriores, sem modificação. O serviço ORNL DAAC TESViS, DOI 10.3334/ORNLDAAC/1600, documenta extrações públicas por REST e os campos de pedido. Produto: MOD13Q1 coleção 061, DOI 10.5067/MODIS/MOD13Q1.061. Coordenadas pedidas não devem ser apresentadas como centro preciso do pixel.

O guia oficial MOD13 C6.1 abriu nesta rodada. Confirma bandas, escala, QA e composição de 16 dias. Seus metadados e equações sustentam as transformações, não a agenda de 180 minutos fictícios. A fórmula NDVI continua (NIR − RED)/(NIR + RED); escala comum se cancela. Fill, denominador inválido e QA rejeitado precisam continuar inválidos, não virar zero.

Os seis registros mantêm VI_Quality = 2116 e pixel_reliability = 0; o uso de um filtro didático não autoriza chamá-los de máxima qualidade. Os dias selecionados são 245 e 267 de 2024, isto é, 01/09 e 23/09, distintos dos inícios dos compostos A2024241/A2024257. São medidas de arquivo; o CubeSat fictício não coletou MODIS. A amostra de três pontos não valida saúde de lavoura, rendimento, causa, tendência regional ou alerta ambiental.

P0 continua o mesmo objetivo NDVI nas duas rotas. As alterações de hardware/representação devem ser avaliadas sob objetivo fixo para sustentar qualquer alegação de mínimo redesenho. O resultado científico depende das bandas reais; a viabilidade de transmissão depende de recursos didáticos declarados. Não atribuir aos números NDVI a inversão de uma escolha que é determinada por watts e Mbit arbitrados.

5. Oportunidade P1 comprovada: EVI3 após um novo pedido científico

Há um ganho científico pequeno em implementação e claro em significado: os JSONs originais já trazem BLUE e EVI publicado. Foi realizado um recálculo independente de EVI de três bandas, com aritmética racional exata. Não houve novo download de pixels nem seleção oportunista de novas observações.

Equação 2 do guia MOD13, página impressa 3 / sexta página PDF, conferida visualmente:

EVI3 = 2,5 × (NIR − RED) / (NIR + 6×RED − 7,5×BLUE + 1).

Usar reflectâncias após multiplicação dos inteiros por 0,0001. A escala não se cancela, por causa do termo constante 1. Todos os BLUE observados estão abaixo de 0,1 e os denominadores são positivos. O guia descreve comportamento problemático de EVI3 em alvos brilhantes e um algoritmo alternativo EVI2; esta análise não implementa o algoritmo completo de seleção/composição NASA.

Máximo observado: 0,0000937932945414, inferior a 0,0001 nos seis registros. É concordância nesta amostra, não acurácia física garantida nem tolerância universal do produto. EVI2 foi calculado separadamente no recibo apenas para mostrar que não é intercambiável com EVI3.

O benefício informacional é demonstrável: NDVI sozinho comprime três ou mais graus de informação em um escalar e não permite recuperar BLUE ou as reflectâncias absolutas. Conservando RED, NIR e BLUE recebidos, torna-se possível responder a um pedido EVI3 posterior. Isso explica a utilidade de reprocessamento sem declarar EVI universalmente superior, sem inventar correção ambiental e sem exigir novo mundo no jogo.

Condições de incorporação P1:

1. O modo precisa se chamar e transportar explicitamente BANDAS R/NIR/B, com RED, NIR e BLUE; NIR não é o canal verde de uma imagem RGB comum. Se BANDAS P0 contém só RED/NIR, não atribuir a ele capacidade EVI3.
2. Um pedido científico EVI3 é um contrato novo, apresentado como extensão após a missão NDVI. Não mudar o objetivo ocultamente no meio da demonstração nem atribuir essa mudança à prova de transferência original.
3. Índice transmitido deve continuar válido para a pergunta NDVI original. O insucesso no pedido adicional é falta de informação suficiente, não perda retroativa de uma vitória legítima.
4. Rejeitar fill e valores não finitos; exigir os três campos, intervalos documentados e a política QA declarada. Denominador nulo ou não positivo é inválido no contrato didático; valores fora do intervalo de produto são sinalizados, sem clamp silencioso.
5. Para entradas externas ou BLUE alto, não extrapolar a validação de seis amostras nem implementar uma troca EVI3→EVI2 ad hoc. Manter “fora do domínio validado” até verificar a lógica NASA aplicável. Nenhum limiar simplificado é atribuído à NASA como algoritmo completo.
6. Volume, custo computacional e energia da terceira banda são novamente hipóteses do jogo. Os poucos bytes dos JSONs não justificam 180 Mbit físicos; separar carga lógica de tamanho de arquivo.

Este P1 cabe como painel curto de reprocessamento e oportunidade educativa posterior. Não integra a pontuação P0, não altera o objetivo fixo do certificado de redesenho e não constitui requisito para liberar a implementação.

6. Evidência entregue e redação recomendada

• evidence/evi3-validation.json: seis cálculos, frações exatas, denominadores, EVI2 distinguido, hashes e caminhos dos três JSONs originais.
• evidence/validate-evi3-research.py: reproduz somente a conferência de pesquisa; não é motor do jogo.
• evidence/resources-retrieval-20261114.json: resultados das novas tentativas de acesso; não contém uma lista oficial recuperada.
• Os capítulos 01, 03, 05 e 06 do caderno anterior e seus recibos permanecem intactos.

Redação defensável na documentação: “Usamos dados arquivados MOD13Q1.061 para verificar os índices recebidos e referências NASA de engenharia para estruturar requisitos e segmentos da missão. A órbita, agenda e recursos operacionais são simplificações didáticas. A confirmação da lista oficial de Resources e da elegibilidade temporal permanece pendente. A cronologia identifica materiais anteriores ao início local do evento.”

Redações sem evidência, que não devem ser usadas: “NASA validou o simulador”; “projeto inteiramente desenvolvido no evento”, se houver implementação anterior; “MODIS comprova nossa elegibilidade”; “dados atuais do Cerrado”; “EVI corrige qualquer nuvem”; “BANDAS reprocessa EVI3”, se o pacote não inclui BLUE; “seis usuários aprenderam”, sem sessões realizadas.

Referências primárias suplementares

• NASA — Measuring Vegetation, NDVI & EVI: contextualização científica, não diagnose local.
• Material oficial de registro 2026: calendário indexado com novembro/2026 e vencedores previstos para janeiro/2027.
• Página oficial geral de Resources: a disponibilidade de guias deve ser observada, sem usar edições antigas como substituição silenciosa.

Todas as URLs foram consultadas ou tentadas em 14/11/2026. Buscas em dois índices foram usadas para distinguir ausência de indexação de falha de abertura. As fontes secundárias servem exclusivamente para localizar a lista candidata, nunca para inventar autorização oficial. Nenhuma mensagem foi enviada a organizadores, nenhuma inscrição foi alterada e nenhum artefato foi publicado por esta frente.

CADERNO / 13

Missão Ipê — verificação adversarial de Fastino e dos anexos

Pesquisa em português brasileiro. Consulta em 14 de novembro de 2026. Escopo: uso opcional de modelos locais para interpretar explicações escritas pelo jogador, identificar possíveis concepções equivocadas e selecionar feedback previamente verificado. Não é um projeto de triagem clínica.

Decisão recomendada

Manter regras determinísticas como autoridade sobre pontuação, fatos científicos, progressão e ações do jogo. Avaliar um encoder multilíngue local apenas como auxiliar de interpretação, com abstenção e feedback editorial. O candidato inicial é fastino/GLiNER2.5-multi-Decide; se a extração literal de evidências da resposta trouxer ganho demonstrável, comparar com fastino/gliner2.5-multi-v1. Adoção depende de avaliação em português brasileiro, não de ranking do fornecedor.

As alegações de economia superior a 95%, determinismo universal, conformidade total e controle instantâneo de DOM/API não foram demonstradas para esse aplicativo. Há capacidades reais por trás da proposta, mas cada uma tem um limite diferente. O filtro de PII pode ser uma defesa adicional; não é uma certificação de privacidade. GLiDE existe, mas adiciona custo operacional e restrições de licença sem resolver uma necessidade evidente do MVP.

O que foi executado e o que não foi

• Executado: leitura integral do primeiro anexo; leitura dos bytes e cálculo SHA-256 dos dois; consulta a model cards, configurações, árvores de arquivos, artigo técnico, documentação oficial e PR do runtime; comparação das alegações com essas fontes; elaboração do protocolo de avaliação abaixo.
• Não executado: download de pesos; inferência CPU/GPU; treinamento; medição própria de precisão, latência ou memória; inspeção de tráfego de uma aplicação integrada. Os números publicados continuam sendo resultados declarados pelos respectivos autores.
• Proposto: arquitetura, conjunto de avaliação, metas e critérios de adoção deste relatório. Estes itens são decisões de engenharia sugeridas, não resultados obtidos.

Os dois anexos têm 32.575 bytes e SHA-256 idêntico:

62fa654201593bf9dd4f62667dcb91d3e89f98f00cf001ac1506847d0506dc51

Arquivos: upload/Texto colado(1).txt e upload/Texto colado(2).txt. O texto é um catálogo de bibliotecas espaciais/geoespaciais, organizado por regiões, seguido de quatro blueprints e um dicionário de formatos. Não contém Fastino, GLiNER, GLiDE, Unsloth ou spec-kit. As alegações Fastino vieram do briefing da mensagem do usuário, não desses anexos. Não se pode apresentar o catálogo como evidência dos modelos. A verificação detalhada das demais bibliotecas está fora desta frente; não se inferiu validade científica das expressões promocionais do anexo. A referência a github/spec-kit não apareceu, portanto não foi investigada nesta frente.

Matriz de alegações

Legenda: D = documentado pelo autor; V = observado nesta pesquisa documental; P = proposta/inferência de engenharia. Documentação de uma capacidade não prova sua qualidade no domínio do jogo.

O exemplo médico não fundamenta uma nova função do produto. Detectar uma intenção textual chamada clinic_request não equivale a validar triagem clínica, gravidade de sintomas ou encaminhamento seguro. Não há motivo para introduzir essas decisões na Missão Ipê.

Identidade, autores, licença e shortlist

Todos os IDs abaixo foram encontrados em repositórios da organização fastino. Isso confirma existência documental, não que os pesos tenham sido testados nesta sessão. Para reproduzir um experimento, registrar SHA completo do checkpoint e hash dos arquivos de pesos; abreviações visíveis em páginas não bastam como lockfile.

O artigo GLiNER2-PII é assinado por Urchade Zaratiana, Ash Lewis e George Hurn-Maloney, submetido em maio de 2026; o registro consultado indica trabalho sob submissão. Não o apresentar como certificação independente. [S24] O GLiDE é distribuído por Fastino; o NOTICE do 0.4B identifica Ettin-encoder-400m, da Johns Hopkins University CLSP, como base. [S22]

A licença GLiDE consultada exige atribuição em uso comercial; produção comercial por entidade com receita anual consolidada acima de US$10 milhões exige acordo separado. Também contém obrigações para derivados, inclusive quantização e destilação. Não é a mesma permissão que Apache-2.0/MIT, embora preserve licenças de componentes upstream. É necessário manter LICENSE/NOTICE correspondentes à revisão efetivamente distribuída. Esta é uma leitura das condições publicadas, não uma certificação jurídica. [S21]

O que os benchmarks permitem afirmar

Decide: classificação, inglês e teste do próprio fornecedor

O card informa média exact-match de 60,2% para Decide inglês e 56,7% para multi-Decide em Fast Decisions. O conjunto avaliado é inglês. [S01, S02] O dataset distingue o material público de desenvolvimento, 100 exemplos × 17 domínios, do teste retido, 300 × 17. Assim, baixar o split público não reproduz automaticamente os números de teste. Há classificações de uma ou mais cabeças, com comparação de conjuntos quando multilabel; não se deve confundir essa média com acurácia de toda uma resposta pedagógica. [S25]

Esses números não demonstram qualidade em nomes brasileiros, escrita infantil, explicações sobre órbitas, clima, incêndios, incerteza observacional ou relação entre satélite e fenômeno. Traduzir literalmente o benchmark para português também não substitui amostras naturais do público.

PII: divergência entre fontes e denominadores

Não houve reconciliação experimental dessa divergência. Pode decorrer de revisão de modelo, avaliação ou documentação; não selecionar o número mais favorável sem explicar. O card usa ainda a nomenclatura gliner2-pii-v1 na tabela, diferente do ID de carregamento. O card declara treino sintético sem validação humana e avaliação multilíngue mais ampla ainda pendente. [S06]

Os valores são de correspondência exata de limites de span e tipo. 1 − recall não é automaticamente a taxa de documentos vazados, pois erro de fronteira/tipo e vazamento efetivo são métricas diferentes. Para privacidade do aplicativo, é necessário medir se cada valor sensível ficou completamente mascarado, se restou qualquer parte identificável e se texto bruto foi transmitido ou registrado. A preocupação persiste mesmo que a precisão seja aumentada: subir threshold geralmente altera o equilíbrio entre falso positivo e falso negativo; é uma hipótese a medir, não uma correção gratuita.

GLiDE: versões e endpoints diferentes

O anúncio de 30/09 apresenta Adaptive Thinking para decisões difíceis; o artigo atualizado em 06/11 descreve v1.2 destilado, sem texto de pensamento, e divulga latência em GPU específica. [S08, S09] Não juntar a capacidade anunciada de um release, o custo de outro e uma promessa de execução CPU como se fossem a mesma configuração.

A documentação atual da API define confiança como separação entre alternativas: em Choice/Score, top1 − top2; em Noul, abs(2p − 1). Isso não é a probabilidade empiricamente garantida de a resposta estar certa. Perguntas são independentes contra o mesmo estado. A API hospedada documenta limite de 65.536 tokens por prompt, enquanto cards locais consultados usam 40.000 ou, no 0.4B, 7.999 com truncamento. Tratar limites e comportamento como propriedades da versão/serviço, não do nome “GLiDE”. [S26, S10–S12]

Não foi encontrado benchmark primário que mensure recuperação completa de falhas DOM/API da Missão Ipê. A interface documentada produz decisões; executar a ação, observar resultado e validar pós-condições continua sendo responsabilidade do aplicativo. [S27]

Runtime: matriz de compatibilidade

O port comunitário documenta offsets em bytes UTF-8. Python e JavaScript podem representar índices de texto de maneira diferente; caracteres acentuados, emoji e normalização NFC/NFD merecem testes explícitos. Paridade de alguns exemplos F32 não permite assumir igualdade em português, quantização ou entradas longas. [S15]

Memória: conferir o artefato, não só o nome

Os ensaios GLiDE citados usam RTX PRO 6000 Blackwell Server Edition de 96 GB. Esses picos não são uma promessa para CPU, celular, Mac ou contexto máximo. O card PII fala em 205M enquanto o artigo fala em aproximadamente 0,3B; o Decide também apresenta discrepância entre contagem declarada e tamanho total F32 exibido. Sem contar tensors, não se resolveu a convenção de contagem. Dimensionar usando o arquivo real e RSS/pico medidos, incluindo tokenizer, runtime, buffers, batch e contexto.

P: iniciar com no máximo um modelo pedagógico residente; carregar dois encoders e PII simultaneamente só após medir memória sob concorrência. Quantizar ou exportar para outro backend é uma condição experimental separada e requer reavaliação de precisão, calibração e estabilidade.

Arquitetura proposta para o jogo

Baseline determinístico

1. O jogador escolhe uma ação/opção ou ajusta controles. IDs de cenário, limites numéricos, estado e resposta esperada são definidos no conteúdo do jogo.
2. O motor calcula resultado e pontuação a partir desses valores. A ciência vem de regras e material revisado, com vínculo de proveniência.
3. Uma explicação livre é opcional. Regras estritas podem reconhecer fatos explícitos ou formatos conhecidos; a ausência de correspondência significa “não identificado”, não “errado”.
4. O feedback explica o resultado verificado e pode fazer uma pergunta fechada que permita ao aluno corrigir sua hipótese. Não infere conhecimento apenas por palavras-chave.

Variante com modelo local

1. Passar ao modelo apenas a resposta, uma descrição curta da tarefa e uma taxonomia fechada. Manter políticas de execução fora do texto controlado pelo jogador.
2. Produzir rótulos candidatos como conceito_coerente, possivel_confusao_temporal, correlacao_como_causa, escala_incompativel, evidencia_insuficiente, fora_do_escopo e ambiguo. A taxonomia definitiva deve derivar dos cenários reais e revisão pedagógica.
3. Quando houver extração, exigir trechos literalmente presentes na entrada. Validar índices, limites, Unicode e correspondência ao texto original. Isso prova origem do trecho, não que a classificação esteja correta.
4. Validar o resultado contra enums permitidos e invariantes do cenário. Com conflito, baixa confiança, timeout, input fora de distribuição ou resposta malformada, abster-se.
5. Escolher um feedback_id de catálogo editorial. A redação pode explicar a diferença científica sem afirmar categoricamente “você pensa X”. O modelo não altera nota, gabarito, dataset, fonte nem próximo estado autorizado.

“Feedback sempre verificado” precisa de duas definições: a correção científica do texto pode ser garantida pelo catálogo e pelas regras; a adequação daquele texto à intenção do jogador permanece uma previsão sujeita a erro. Para essa segunda dimensão, usar linguagem condicional e perguntas de confirmação no próprio jogo. Se for exigida garantia de adequação, reduzir a interação a respostas fechadas verificáveis.

Contrato e falhas

P: usar tipos estritos, enums, limites de tamanho e rejeição de campos extras no sidecar. A biblioteca de validação pode ser Pydantic em Python ou um validador equivalente na linguagem efetivamente adotada. JSON Schema descreve o contrato; a camada do jogo precisa validar semântica e pós-condições. [S18, S19]

P: expor o sidecar apenas na interface local necessária, com origem/autorização explícitas, fila limitada, timeout e cancelamento. Não autorizar ferramentas, shell, rede ou acesso ao DOM com base no texto classificado. Erros HTTP e transporte devem seguir política determinística de retry limitado, idempotência e fallback. Classificar uma falha não a corrige.

P: preparar modelos em etapa separada e operar offline quando esse for o requisito. HF_HUB_OFFLINE=1 evita chamadas do Hub e usa cache; não desativa toda a rede do processo nem telemetria de outras bibliotecas. Complementar com bloqueio real de saída e teste de tráfego. [S33] Não registrar entradas rejeitadas integralmente em logs de validação. A promessa verificável deve descrever o fluxo de dados observado, não “100% privado”.

Riscos adversariais e testes que os discriminam

Ausência de geração livre reduz uma superfície de injeção, mas não elimina manipulação de classificação. A defesa principal é limitar o que a previsão tem autorização para afetar. O caso de maior risco do jogo não é JSON inválido: é um JSON perfeitamente válido associar ao aluno uma concepção equivocada que ele não expressou.

Plano quantitativo de ablação — ainda não executado

Conjunto e revisão humana

P: construir 1.200 explicações pedagógicas a partir dos cenários finais, sem dados pessoais reais:

• 400 respostas naturais em pt-BR, cobrindo correção, parcialidade, ausência de evidência e erro conceitual;
• 200 respostas com negação, citação, contradição ou múltiplas hipóteses;
• 200 variantes de escrita, acentuação, vocabulário regional e ruído;
• 200 casos fora de escopo, adversariais e tentativas de injeção;
• 200 casos curtos/longos, mistos pt/en e com posição de evidência controlada.

Dois revisores em português anotam independentemente conceito, rótulos admissíveis, spans de evidência e feedbacks aceitáveis; desacordos passam por adjudicação. Registrar concordância entre revisores antes de ajustar o modelo. Exemplo de categoria ambígua não deve receber rótulo forçado para facilitar uma métrica.

Dividir por família de cenário e origem da paráfrase, não aleatoriamente por linha: 300 desenvolvimento, 300 calibração e 600 teste fechado. Todas as variantes de uma mesma frase ficam na mesma partição. Se houver ajuste fino posterior, criar conjunto de treino adicional; não consumir o teste. Incluir amostras humanas naturais na avaliação, pois só texto sintético pode favorecer o gerador e esconder dificuldades do público.

P: construir separadamente 600 textos de privacidade: 300 com PII/segredos sintéticos, 200 sem PII e 100 com obfuscação/multilinguismo. Exigir ao menos 100 spans de avaliação por tipo crítico; um texto pode conter múltiplos spans. Reportar também interseções pt-BR × tipo. Nenhum número dessa suíte deve ser tratado como garantia jurídica.

Braços experimentais

Decide inglês pode ser incluído somente como controle, nos mesmos exemplos em inglês/pt-BR emparelhados. Um 70B só faz sentido como braço adicional se for uma alternativa real do projeto, com ID/revisão, quantização, contexto, prompt, decoder e hardware especificados. Não é necessário executá-lo para escolher entre regras e encoder.

Métricas e protocolo

• Qualidade: macro-F1 e recall por concepção; precisão de atribuições feitas com alta confiança; adequação do feedback julgada por revisores; custo de falso positivo, que acusa um erro não expresso; matriz de confusão.
• Abstenção: coverage e selective risk. Comparar sistemas à mesma taxa de erro ou mesma cobertura; não premiar um sistema que “acerta” apenas por abster-se sempre.
• Calibração: Brier, NLL quando probabilidades completas existirem, reliability plot e ECE com bins declarados. Ajustar só no split de calibração. Não reutilizar threshold do benchmark ou da PII para pedagogia.
• Evidência: F1 de span exato e localização correta após round-trip Python/JavaScript; medir separadamente tipo e fronteira.
• Privacidade: recall de máscara integral de cada valor sensível; taxa de documentos com qualquer valor parcialmente exposto; taxa de caracteres não sensíveis removidos; erros por tipo e locale. Manter métricas SPY separadas.
• Latência: p50/p95/p99, inicialização, primeira resposta e estado aquecido; 1, 4 e 8 requisições concorrentes; respostas de 32/128/512 palavras e schema fixo de 6/12 labels. Medir pelo relógio externo ao processo, incluindo serialização/fila.
• Recursos: tamanho instalado, RSS inicial/pico, memória GPU se aplicável, utilização CPU, energia quando houver medidor confiável. Registrar também falhas e throttling; não apagar outliers do resultado.
• Estabilidade: 100 repetições de 100 casos de fronteira em configuração fixa; reiniciar processos em subamostra; comparar batch 1/8 e ordem de labels. Reportar discordância de classe e maior diferença de probabilidade.
• Comparação estatística: intervalos bootstrap de 95% emparelhados, agrupados por cenário/origem; diferenças absolutas e relativas; não tratar paráfrases correlacionadas como observações independentes.

Metas propostas de adoção

As metas abaixo são critérios de produto a acordar/ajustar antes de medir; não alegações de desempenho disponível:

1. Zero alterações indevidas de nota/estado em 600 casos de teste, incluindo adversariais; a propriedade deve ser imposta pelo código, não “aprendida”.
2. Em feedbacks específicos não abstidos, erro de atribuição pedagógica ≤2% e cobertura ≥70%, com intervalos e subconjuntos reportados; não aprovar apenas por média global.
3. A3/A4/A5 precisa melhorar a cobertura em pelo menos 10 pontos percentuais à mesma taxa de erro, ou reduzir o erro com intervalo favorável, comparado a A1. Se não houver ganho útil, manter o baseline.
4. Meta inicial no computador-alvo: p95 ≤500 ms aquecido para uma explicação curta, RSS do processo ≤3 GB com um único modelo pedagógico, e fallback em ≤1 s. São orçamentos experimentais, sujeitos ao hardware real.
5. Nenhuma requisição externa com texto bruto na condição offline; revisar tráfego e logs. Uma falha de detector não deve liberar transmissão de dados sob uma promessa de privacidade.
6. Caso ocorra zero falhas em uma amostra, relatar denominador e intervalo: zero observado não prova risco zero. Como aproximação, com 600 eventos independentes sem falha, o limite superior unilateral de 95% é cerca de 0,5%; correlação entre exemplos pode piorar essa evidência.

Como testar a alegação de economia

P: definir C = infraestrutura + energia + armazenamento + operação amortizada + custo de fallback/revisão, dividido pelo número de respostas entregues dentro do limite de erro. A economia seria 1 − C_candidato/C_baseline, reportada apenas para a carga e hardware medidos. A taxa de acerto deve ser equivalente; não comparar um classificador que sempre responde com um gerador que produz explicação completa.

Reportar duas referências: A1 (regras), que é a alternativa concreta mais simples, e o modelo maior se ele realmente estiver em consideração. Uma redução de parâmetros frente a 70B não demonstra 95% de economia de ponta a ponta; em baixa utilização, memória residente e operação podem dominar o custo.

Fontes primárias consultadas

URLs consultadas em 14/11/2026. Model cards, README e blogs representam documentação/declarações dos autores. Nenhum benchmark foi reproduzido nesta frente. As páginas main são mutáveis.

• S01 — Decide inglês: https://huggingface.co/fastino/GLiNER2.5-Decide
• S02 — multi-Decide: https://huggingface.co/fastino/GLiNER2.5-multi-Decide
• S03 — implementação oficial GLiNER2: https://github.com/fastino-ai/GLiNER2
• S04 — anúncio TLM de 07/05/2025, reproduzido por investidor participante, tratado como comunicado da empresa: https://www.insightpartners.com/ideas/fastino-launches-tlms-task-specific-language-models-with-17-5m-seed-round-led-by-khosla-ventures/
• S05 — PyTorch, reprodutibilidade: https://docs.pytorch.org/docs/2.15/notes/randomness.html
• S06 — card PII: https://huggingface.co/fastino/gliner2-privacy-filter-PII-multi
• S07 — relatório PII versionado: https://arxiv.org/html/2605.09973v1
• S08 — lançamento GLiDE/Adaptive Thinking em setembro: https://fastino.space/blog/introducing-glide-the-first-thinking-decision-model
• S09 — GLiDE destilado, artigo atualizado em novembro: https://fastino.ai/blog/training-glide-sota-decision-model
• S10 — GLiDE 0.4B: https://huggingface.co/fastino/GLiDE-0.4B
• S11 — GLiDE 0.8B: https://huggingface.co/fastino/GLiDE-0.8B
• S12 — GLiDE 2B: https://huggingface.co/fastino/GLiDE-2B
• S13 — modelos suportados vLLM: https://docs.vllm.ai/en/latest/models/supported_models/
• S14 — PR llama.cpp #30504, aberto na consulta: https://github.com/ggml-org/llama.cpp/pull/30504
• S15 — port comunitário e limites de paridade: https://github.com/sandrohanea/gliner.cpp
• S16 — Unsloth, repositório oficial: https://github.com/unslothai/unsloth
• S17 — Unsloth, catálogo: https://unsloth.ai/docs/get-started/unsloth-model-catalog.md
• S18 — Pydantic strict mode: https://pydantic.dev/docs/validation/latest/concepts/strict_mode/
• S19 — JSON Schema, validação básica: https://json-schema.org/understanding-json-schema/basics
• S20 — GLiNER2.5 multilíngue: https://huggingface.co/fastino/gliner2.5-multi-v1
• S21 — licença GLiDE 0.4B: https://huggingface.co/fastino/GLiDE-0.4B/blob/main/LICENSE
• S22 — NOTICE GLiDE 0.4B: https://huggingface.co/fastino/GLiDE-0.4B/blob/main/NOTICE
• S23 — GLiDE 27B, hardware e runtime: https://huggingface.co/fastino/GLiDE-27B/blob/main/README.md
• S24 — autoria e status do artigo PII: https://arxiv.org/abs/2605.09973
• S25 — Fast Decisions, desenvolvimento público/teste retido: https://huggingface.co/datasets/fastino/fast-decisions
• S26 — GLiDE, confiança e limites atuais da API: https://docs.fastino.ai/concepts/glide-capabilities
• S27 — chamada e contrato GLiDE: https://docs.fastino.ai/inference/systemone
• S28 — config Decide: https://huggingface.co/fastino/GLiNER2.5-Decide/blob/main/config.json
• S29 — arquivos Decide: https://huggingface.co/fastino/GLiNER2.5-Decide/tree/main
• S30 — arquivos multi-Decide: https://huggingface.co/fastino/GLiNER2.5-multi-Decide/tree/main
• S31 — arquivos GLiNER2.5 multi: https://huggingface.co/fastino/gliner2.5-multi-v1/tree/main
• S32 — arquivos PII: https://huggingface.co/fastino/gliner2-privacy-filter-PII-multi/tree/main
• S33 — Hugging Face, modo offline: https://huggingface.co/docs/huggingface_hub/package_reference/environment_variables
• S34 — discussão precursora de suporte llama.cpp: https://github.com/ggml-org/llama.cpp/discussions/30387
• S35 — config PII, base mDeBERTa: https://huggingface.co/fastino/gliner2-privacy-filter-PII-multi/blob/main/config.json
• S36 — SPY, artigo/dataset original: https://aclanthology.org/2025.naacl-srw.23/
• S37 — Fastino, guia diferencia encoders/decoders e bibliotecas de serving: https://fastino.ai/blog/a-guide-to-small-language-models

Lacunas e cautelas de reprodutibilidade

• O link fastino.ai/privacy retornou 404; agent.fastino.ai/privacy e outros caminhos não entregaram política verificável nesta coleta. Uma versão indexada de termos e sua abertura posterior divergiram, esta última mostrando página genérica da API. Não se concluiu política contratual atual de retenção/treino da API. Isso não afeta a recomendação de inferência local sem envio, mas impede prometer ZDR ou conformidade de serviço hospedado.
• Não foi localizado benchmark primário do percentual exato “>95% versus 70B” aplicável à configuração proposta. A afirmação fica sem suporte, não convertida em “falsa em todas as situações”.
• README de framework, snippet automático do Hub, card, arquivo de configuração e artigo podem refletir revisões diferentes. As divergências de PII, contagem de parâmetros e contexto GLiDE devem ser resolvidas ao fixar artefatos antes do teste.
• As instruções genéricas “Use this model” do Hub incluem exemplos generativos ou de entidades que não comprovam suporte ao head/uso específico. A implementação oficial e um teste mínimo de contrato são a referência operacional.
• Não há evidência produzida aqui de ganho pedagógico, robustez pt-BR, privacidade completa ou latência no equipamento do usuário. O relatório oferece uma hipótese testável e critérios de rejeição, não uma homologação.

CADERNO / 14

03 — Oportunidades concretas e protocolo spec ↔︎ código ↔︎ prova

Parecer de pesquisa, 14/11/2026. Base: capítulos 01, 02 e 04 de ab-global-final-round/docs/ e upload/Texto colado(1).txt. Este documento propõe decisões; não implementa o jogo, instala ferramentas, mede desempenho ou demonstra aprendizagem. As fontes abaixo foram consultadas nesta data. O escopo é o Ipê local, com seis registros MOD13Q1, duas representações científicas e catálogo finito.

Nota de integração da coordenação: o contrato implementado posteriormente nesta rodada fixa 64 configurações e meta de busca de 1 s no equipamento de demonstração. O orçamento anterior de 256 candidatas/3 s citado no parecer é histórico. O replay implementado contém versões, sciencePackHash, entrada e resultado, mas não exporta um certificado completo da busca nem campos scenarioHash/catalogHash. A demonstração do mínimo está na enumeração e nos testes independentes; exportar esse certificado é trabalho adicional. O diário atual persiste previsões/reflexões localmente por decisão de produto, explicitada no PRD. Metas e propostas deste parecer não são alegações automáticas sobre o código entregue.

1. A novidade que merece começar agora

Escolher P0: um recibo verificável de missão, gerado pelo mesmo contrato que determina a vitória. A contribuição demonstrável é conectar pedido científico, procedência, execução, explicação e decisão de transferência. O jogador deve conseguir abrir uma afirmação como “faltou entregar um registro”, localizar o evento e recalcular a consequência. Um avaliador recebe os mesmos arquivos e confere o resultado offline.

Isso aprofunda o projeto existente sem acrescentar outro simulador, backend ou agente em tempo de execução. Procedência deixa de ser uma aba de créditos: a ausência de uma banda, um QA inadmissível ou uma versão incompatível impede aquele registro de satisfazer o objetivo. A origem NASA influencia o que pode ser declarado recebido e cientificamente utilizável.

“Proof-carrying explanation” é aqui um nome de projeto para explicação acompanhada de evidência verificável. Proof-carrying code já possui fundamento anterior, baseado em produtor de prova e verificador [S01]. Um JSON, um hash ou um replay não constituem, por si, prova formal dessa tradição. Nosso compromisso menor é especificar exatamente o que um verificador aceita e quais erros ele detecta. Não reivindicar originalidade absoluta: jogos NASA já relacionam objetivos científicos, instrumentos e missões reais [S02]; procedência e recourse também têm precedentes consolidados [S03–S04].

O primeiro incremento revisável deve conter contrato, um caso de sucesso, um caso de falha, recibos esperados e verificação independente da aritmética. Somente depois integra-se a apresentação. Isso produz uma tese concreta de produto: o estudante aprende a justificar por que a ciência chegou ou não chegou, dentro de hipóteses inspecionáveis. Ainda é hipótese educativa, não resultado observado.

2. Do catálogo de fontes ao contrato executável

O contrato separa três classes: fatos do arquivo científico; parâmetros didáticos do cenário; resultados calculados. Nunca atribuir os dois últimos à NASA por estarem no mesmo pacote. MOD13Q1 é produto processado e composto temporalmente; carregar seus registros não significa simular sua aquisição instantânea por um CubeSat. A qualificação do recurso perante o desafio permanece um gate próprio: procedência NASA não substitui confirmar o vínculo exigido aos Resources oficiais.

Cada requisito ganha ID estável e vínculo explícito:

A estrutura mínima associa contractVersion, packHash, scenarioHash, catalogHash, engineVersion, entrada congelada e resultado. Para cada transformação: IDs de entrada e saída, função/versionamento, unidade, arredondamento e referência documental. PROV fornece um vocabulário útil de entidades, atividades e responsáveis e distingue história consistente de mera coleção de metadados [S03]. Não é necessário implementar RDF ou toda a especificação no P0.

O diário de missão para investigação registra eventos discretos com sequência, tempo simulado, precondição, mudança de estado, regra aplicada e registros afetados. Eventos do estudante ficam separados dos eventos simulados: a ordem local de uma resposta não é instante orbital. Preservar falhas e tentativas, inclusive abandono, ajuda e gravação abortada.

Um cartão de explicação deve responder: o que ocorreu; qual condição foi violada; que evidência sustenta isso; que entrega foi afetada; qual intervenção foi testada. “Rádio insuficiente” sem janela, volume, fila e consequência é interpretação solta. O primeiro evento observável pode ser um sintoma: buffer cheio pode decorrer de contato curto, representação volumosa ou política de captura. A interface deve chamar o dado de “primeira violação” até existir evidência para a alegação causal mais forte.

Hashes detectam alteração em relação a bytes conhecidos; não autenticam quem produziu o arquivo. Uma cadeia de hashes local pode ser inteiramente recalculada por quem controla o arquivo. No P0, preferir manifesto completo e comparação com pacotes confiáveis, evitando promessa de diário inviolável. O verificador rejeita referências ausentes, recalcula saídas e diferencia resultado declarado de resultado conferido. Seu uso do mesmo motor testa consistência; oráculos manuais independentes continuam necessários para detectar erro compartilhado.

3. Menor redesenho: uma afirmação matemática delimitada

Definir o conjunto finito de projetos admissíveis $C$, a configuração inicial $x$, condições externas fixas $z$ e predicado de sucesso $F(y,z)$. A métrica inicial deve ser transparente:

$$d(x,y)=\sum_j \mathbf{1}[x_j\ne y_j],\qquad k^*=\min_{y\in C:F(y,z)}d(x,y).$$

Essa é a menor quantidade de escolhas alteradas neste catálogo, não o menor custo industrial, a melhor missão universal ou a intervenção fisicamente mais barata. Se massa, preço ou energia desempatarem alternativas, publicar a ordem e provar também esse critério; não ocultar pesos dentro de um score. Empates devem permanecer visíveis.

O certificado contém uma testemunha viável $y$, sua distância $k$, versões congeladas e o registro completo da verificação de todas as candidatas admissíveis com distância menor que $k$. O conferidor reconstrói o catálogo e reexecuta essas candidatas. Contagem e digest desacompanhados dos dados necessários não demonstram cobertura. Se nenhuma candidata funciona, só a enumeração integral permite “sem solução neste catálogo”. Cancelamento antes de concluir as camadas menores deixa “testemunha viável; mínimo não certificado”. Enumerar todos os empates é obrigação adicional caso se prometa listá-los.

Karimi e colaboradores distinguem proximidade entre descrições e ação com efeitos causais [S04]. Para Ipê, a consequência prática é recalcular todos os efeitos de trocar uma peça: massa, consumo, fila e compatibilidade. Não basta editar o valor final da bateria. Preservar objetivo, dados e condição externa; mudar hardware significa novo projeto antes do lançamento. Trocar simultaneamente objetivo e peça deixa de responder à pergunta original.

Uma intervenção suficiente para reparar a missão não identifica necessariamente sua única causa. Pode haver falhas concomitantes ou redundância. O jogo deve mostrar quando uma mudança isolada elimina a violação local, mas a missão continua falhando. Essa distinção entre diagnóstico e reparo é uma oportunidade educativa melhor que uma seta determinista com aparência científica.

4. Aprender investigando, com transferência observável

A evidência externa justifica experimentar o ciclo, não declarar sua eficácia antecipadamente. Kapur encontrou benefícios de resolução anterior à instrução em estudos controlados de matemática [S05]. O desenho inclui consolidação; simplesmente deixar o participante falhar não equivale à intervenção estudada. Hassan e Zilles observaram que ferramentas precisam expor o erro relevante e que chegar à saída correta pode preservar um entendimento errado [S06]. Não transferir automaticamente esses resultados para engenharia espacial.

O ciclo proposto é: prever o gargalo; executar; inspecionar um evento; explicar com suas palavras; redesenhar; receber uma explicação consolidada; decidir numa condição nova. A ajuda cresce de recurso para evento e depois alternativa. A sugestão mínima aparece depois da tentativa própria. A pessoa pode completar a missão por tentativa e erro e ainda precisar aprender a relação técnica.

Na transferência, mudar a disponibilidade relativa de energia e comunicação sem ensinar uma regra nova escondida. O catálogo deve comprovar que as duas representações têm regiões de utilidade; inverter arbitrariamente o vencedor seria um truque de puzzle. Registrar a primeira escolha antes do resultado ou da sugestão. Usar uma rubrica simples: identificou o recurso limitante; conectou decisão e mecanismo; justificou a mudança sob a nova condição. Dois avaliadores podem codificar explicações anonimizadas e registrar divergências.

Seis sessões e até dois pilotos podem revelar defeitos e exemplos de transferência próxima imediata. Não estimam eficácia populacional, retenção ou causalidade do jogo frente a outro ensino. Acertos, erros, ajuda e desistências pertencem ao resultado. Uma avaliação posterior pode contrabalançar cenários e comparar o diário explicativo com uma condição equivalente sem ele.

O portfólio NASA entra após a decisão: relacionar a pergunta, a grandeza observada e o compromisso técnico a missões documentadas. O jogo oficial Build It Yourself já oferece esse tipo de conexão [S02]. No Ipê, a correspondência deve ser por atributo, sem sugerir que o satélite didático reproduz Terra/MODIS ou recebe validação NASA.

5. Robustez: ensinar margem sem inventar distribuição

P0 usa parâmetros didáticos nominais, identificados e versionados. P1 acrescenta um conjunto explícito de condições $U$: contatos mais curtos, potência disponível menor ou demanda maior. Projeto robusto significa $F(y,u)$ verdadeiro para todo $u\in U$. Com conjunto finito, enumerar $C\times U$ é verificável. Com intervalos contínuos, testar extremos só basta se houver argumento de monotonicidade ou propriedade matemática equivalente. Políticas, saturações e mudança da ordem de eventos podem invalidar essa simplificação.

Não chamar taxa de sucesso numa grade de “probabilidade real de missão”. Monte Carlo exige distribuições justificadas e produz estimativas com incerteza amostral. Intervalos escolhidos para ensino devem ser rotulados como tais. A mesma disciplina vale para “reserva de 20%”: sem fonte ou hipótese declarada, o percentual é uma regra de cenário, não engenharia validada.

NASA-STD-7009B e o handbook ativo de 2026 tratam credibilidade, uso pretendido, verificação, validação, sensibilidade e incerteza [S07]. Aproveitar essa estrutura sem alegar conformidade formal. Verificar conservação prova coerência de implementação; comparar com um referencial apropriado investiga adequação física. Nenhuma biblioteca elimina essa diferença.

6. Protocolo Spec Kit, sem instalador remoto

O upstream observado é github/spec-kit, MIT, release v1.4.0 de 10/11/2026, commit 0019fa14d12f45edabc2cc3176c9168a68bd0f97 [S08]. A documentação corrente oferece constituição, especificação, plano, tarefas, implementação e convergência [S09]. O CLI não foi executado. A abertura web de três arquivos no caminho da tag falhou; release, commit, README e documentação pública foram recuperados. Portanto, não se declara auditoria integral dos bytes da release.

Usar agora a disciplina documental do Spec Kit. Para uma futura instalação, preparar cópia revisada e fixada; conferir licença, scripts e dependências. O guia oficial descreve wheels transferíveis e inicialização sem rede, mas alerta que catálogos, adaptadores externos e bundles possuem limites próprios [S10]. Offline do scaffold não significa agente de IA offline. Nenhum desses componentes deve entrar no runtime do jogador.

Na integração Codex atual, a sintaxe documentada é $speckit-specify; Copilot usa /speckit-specify, e referências também mostram notação pontuada [S11]. Não colar todos os comandos no terminal nem pressupor habilidades instaladas. Sem instalação, o procedimento é uma aplicação documental do método, explicitamente identificada.

A matriz traceability.json proposta liga requirementId → source/model-assumption → function → test/oracle → evidencePath → outcome. Alterar o contrato invalida evidências vinculadas à versão anterior até nova execução. Corrigir o motor exige conservar a entrada que reproduz o defeito. Mudar o texto para fazê-lo concordar com um bug exige ADR explícito e nova justificativa; não é convergência aceitável por conveniência.

7. Decisões, gates e opções posteriores

P1: robustez em cenários enumerados; comparação de alternativas empatadas; tarefa de transferência contrabalançada; testes gerativos do diário. P2: cenários produzidos com Orekit/Basilisk, comparação com modelo de maior fidelidade, prova formal de um subsistema e estudo controlado de aprendizagem. Nenhuma opção deve atrasar o contrato P0. Model checking ou solver só entra quando existir uma propriedade e um contraexemplo que o verificador simples não consegue resolver adequadamente.

8. Ferramentas reais e auditoria do anexo

Registro de disponibilidade, não promessa de integração. Nenhum dos projetos abaixo foi instalado ou executado nesta frente. Licenças referem-se ao upstream consultado; dependências e dados exigem inventário próprio.

O anexo chama SpiceyPy de wrapper oficial NASA. Corrigir: NAIF o lista entre interfaces de terceiros, ainda que o projeto atual tenha apoio NASA e lições NAIF [S12]. “Precisão submétrica” não é garantia geral: a documentação SPICE exige atenção a modelos, arquivos, tempos e precisão esperada [S13]. A promessa de “rigor matemático e físico irrefutável” atribuída a Skyfield/Astropy/SunPy também excede a evidência; Astropy documenta resultados com precisão IERS degradada [S14]. Nomes institucionais, Kalman e linguagens não substituem hipóteses, condições de validade e validação.

A expressão literal “zero overhead” não foi encontrada no anexo fornecido. Se proposta para Ipê, deve ser rejeitada como não medida: validação, hashing, serialização, armazenamento e enumeração executam trabalho. Ajv permite antecipar compilação, não tornar validação gratuita [S15]. Medir comparação com/sem diário, em entradas idênticas, informando latência, memória e bytes. A meta existente de busca em três segundos admite menos de 11,72 ms médios por candidata para 256 candidatas, antes do overhead. É orçamento aritmético, não benchmark.

Fontes primárias e limites de uso

• S01: Necula, Proof-Carrying Code, POPL 1997. Precedente de verificação; não certifica nosso recibo.
• S02: NASA, Build It Yourself. Objetivos científicos, escolhas e missões reais.
• S03: W3C, PROV Constraints. Consistência de procedência; não veracidade automática.
• S04: Karimi, Schölkopf e Valera, Algorithmic Recourse. Intervenções e dependências; adaptação ao jogo é nossa proposta.
• S05: Kapur, 2014. Estudos de matemática, não validação do Ipê.
• S06: Hassan e Zilles, SIGCSE 2022. Estudo qualitativo de erros e visibilidade.
• S07: NASA-STD-7009B e NASA-HDBK-7009. Credibilidade e uso pretendido; consulta não significa conformidade.
• S08: Spec Kit releases e commit observado.
• S09: Spec Kit README e quickstart.
• S10: Instalação e air-gapped. Procedimento não executado.
• S11: Spec Kit, invocação por integração.
• S12: NAIF, interfaces de terceiros.
• S13: NAIF, Common Problems.
• S14: Astropy, IERS. Página de desenvolvimento consultada; fixar versão antes de uso.
• S15: Ajv, standalone validation. Otimização de implantação, não custo zero.

CADERNO / 15

Frente 4 — Motor determinístico, catálogo e prova finita

Implementação específica de P&D realizada em 14/11/2026, antes das 09h BRT do evento. O benchmark foi executado às 08:46:05 UTC / 05:46:05 BRT. Este código não estabelece elegibilidade NASA, não é calibração de hardware e não deve ser apresentado como produção realizada durante a janela do hackathon.

Entrega e domínio

Foram implementados src/core/catalog.ts, engine.ts, science.ts, search.ts, os auxiliares exact.ts/power.ts e tests/engine.test.mts. contracts.ts permaneceu sob propriedade da coordenação, sem alteração nesta frente. A API pública é a prevista no contrato. O catálogo também exporta BASE_MASS_KG, BASE_CREDITS, getConfigTotals e PHYSICS para impedir cópias divergentes na interface.

O domínio jogável permanece fechado: seis escolhas binárias, 64 tuplas, dois cenários, seis registros MOD13Q1 de arquivo, 10.800 s de relógio fictício. simulateMission é o único ponto de execução usado por busca, interface e replay. simulateMissionModel e evaluateConfigurations são pontos internos para contraprovas de teste; não acrescentam cenários ou dados importáveis ao produto.

Todos os números propostos para massa, créditos, potência, energia, taxa e memória foram mantidos. O padrão foi explicitado como small/standard/bands/economy/large/every-contact. O painel padrão precisa ser standard, pois BANDAS com painel compact requer (26 − 6,6)/0,95 = 20,42105263157895 W na bateria pequena, acima de 20 W. Com standard, a exigência é 322/19 W ≈ 16,947368421 W. A memória grande acomoda os seis lotes de 180 Mbit antes do primeiro contato.

Regras executadas

As janelas são intervalos [início,fim). O motor conclui o intervalo anterior, contabiliza a última recepção e o fim de trabalho, depois aplica as mudanças de luz/contato e inicia o próximo modo. Um último bit recebido exatamente no fim do contato conta. Um lote só surge após todos os 60 s de trabalho. A fila é FIFO; pode transmitir um lote parcialmente entre contatos; falta de espaço descarta o lote novo inteiro. A fila vazia muda imediatamente o consumo de rádio para os 8 W de espera.

As cargas de 26/38/16/26 W são totais, já incluindo a base. O fator solar é 55% durante trabalho e 85% nos outros modos. Nos dois cenários, todos os contatos ocorrem em eclipse. A entrada de carga é limitada a 10 W; a eficiência é 95% tanto na carga quanto na descarga. O pico compara a potência retirada da bateria, (carga − solar)/0,95, com seu limite. A violação é terminal e interrompe produção e transmissão posteriores. Energia zero também encerra a operação. A reserva é inclusiva: energia igual à reserva atende; continuar a descarga abaixo dela registra falha e preserva o restante do trace.

Massa e orçamento são verificados separadamente, sem encerrar a avaliação na primeira restrição. Tuplas que violam ambos registram ambos. Sua trajetória física também é calculada para diagnóstico, mas o resultado continua invalid mesmo quando os seis dados chegam ao solo. Entradas fora do catálogo ou cenários desconhecidos falham explicitamente; não são convertidos silenciosamente em uma opção padrão.

Aritmética e conservação

Relógio, energia, fluxos de potência e fração de bit usam frações BigInt reduzidas por MDC. Exemplos efetivamente usados: eficiência 19/20, energia inicial pequena 64/5 Wh, solar standard em espera 153/10 W, solar standard em trabalho 99/10 W, carga química em espera 1387/200 W e descarga BANDAS 322/19 W. A primeira saturação do baseline ocorre em 60111540/26353 s, exposta como 2281,013167381323 s. Não há passo de frame nem epsilon de sucesso.

Os contadores inteiros de bits são verificados como números seguros. Totais e observações são serializados como strings decimais; TracePoint conserva números seguros conforme o contrato. Nenhum BigInt sai no resultado JSON. O ledger verifica exatamente:

energia inicial + solar − carga − perdas de conversão − descarte − energia final = 0

bits gerados = bits recebidos + bits perdidos + bits na fila

O residual interno de energia foi zero nas 128 combinações testadas. Os valores finais de energia são convertidos a Number apenas para o contrato externo; o recálculo do balanço a partir desses valores pode mostrar arredondamento IEEE. O teste desse arredondamento não altera a classificação. A repetição foi verificada neste runtime; não se promete equivalência bit a bit entre motores JavaScript distintos.

Ciência e contraprovas

A interpretação de campos segue o guia primário MOD13 C6.1, tabelas 1, 4 e 5, consultado nesta frente. A seleção é política didática declarada: MODLAND 0; usefulness 0/1/2; aerosol 0/1/2; reliability 0; classe de terra 1; rejeição de nuvem adjacente, nuvem mista, neve/gelo e sombra. Não se chama o pack de qualidade máxima.

As duas representações usam (NIR−RED)/(NIR+RED), as mesmas máscaras e a mesma pergunta. Os inteiros de reflectância devem estar entre 0 e 10.000; escala 0,0001 e offset zero são fixos. Fill, denominador zero e valores não finitos resultam em ndvi:null, nunca zero substituto. Há verificação da data selecionada dentro do composto e coerência da data MODIS.

A concordância com NDVI publicado usa a quantização explícita do pack: truncamento para inteiro de escala 10.000 e aceitação das representações IEEE de multiplicar/dividir pela escala. Isso valida estes seis registros, não oferece um limiar universal de acurácia MODIS. Um payload integralmente recebido com QA adulterado entrega zero registros científicos válidos. EVI não foi introduzido no objetivo.

Resultados reais da enumeração

A única testemunha de distância 2 no contato curto é bateria large + processamento index, mantendo painel standard, rádio economy, buffer large e every-contact. Custa 84 créditos e pesa 3,5 kg. Bateria large + rádio fast pesa 3,7 kg, excedendo 3,6 kg, apesar de transmitir todos os dados. Os sete projetos de distância 0 ou 1 foram avaliados e nenhum teve sucesso curto. Essa é uma prova finita relativa a estas versões, este catálogo e este objetivo; não é otimização de todas as arquiteturas espaciais possíveis.

A busca não para ao achar uma testemunha. A ordem reversa produz o mesmo resultado. Uma avaliação que lança erro, uma lista incompleta ou uma tupla repetida remove complete, minimumDistance e best; não conserva um selo anterior. A execução síncrona não oferece cancelamento interno. O cancelamento/descartamento de respostas de Worker deve continuar sob controle da coordenação, sem publicar resultados de uma solicitação anterior.

Verificação e medição

Foram aprovados 22 testes próprios do motor. Eles cobrem 64×2 ledgers; limites seguros; fila parcial e descarte atômico; pico terminal; igualdade da reserva; continuidade após violação de reserva; energia zero; saturação; carga máxima; fim de trabalho no início do contato; último bit no fim da janela; interrupção durante transmissão; política de último contato; QA e metadados adversariais; mesma ciência nas duas rotas; prova mínima; erro e incompletude; repetição e supressão de trace.

Fixtures fora do catálogo exercitam limites não alcançados pelas condições jogáveis. Em eclipse contínuo, a bateria pequena toca a reserva em 4.446 s sem falhar se o horizonte termina ali, e esgota em 5.472 s sem energia negativa. Uma interrupção durante TX termina em 5.356,125 s, com 52.920.000 bits recebidos e 127.080.000 bits ainda na fila. Uma entrada solar sintética de 30 W e carga de 8 W aceita 10 W no carregador, armazena 9,5 W, perde 0,5 W e descarta 12 W. Essas fixtures são testes do núcleo, não novos fatos de missão.

npx tsc --noEmit passou. A execução integrada npm test feita nesta frente após os testes próprios aprovou 43/43 testes, incluindo os testes da frente de persistência e replay disponíveis naquele momento. Nenhum teste de integração foi editado por esta frente.

Medição local em Node v24.22.1, CPU AMD EPYC 9V45 96-Core Processor, às 08:46:05 UTC: dez aquecimentos e cem chamadas completas de searchCatalog(DEFAULT_CONFIG,'short-contact'), cada uma calculando as 64 tuplas. Mínimo 3,927 ms, mediana 4,201 ms, p95 7,879 ms, máximo 20,041 ms. Isso mede o núcleo nesse executor e não prevê latência de interface, navegador, dispositivo móvel ou acesso a disco.

Limites mantidos

O modelo não estima link budget RF, apontamento orbital real, degradação térmica, envelhecimento de bateria, codificação/FEC, perdas de pacote, retransmissões ou tamanho físico dos arquivos MODIS. As taxas representam serviço útil assumido. Volumes de 60/180 Mbit são cargas lógicas didáticas; não provêm dos bytes dos seis JSONs. O CubeSat fictício não adquire os dados MODIS históricos em 180 minutos. A política de QA e a quantização são fixas para esta amostra. A prova do catálogo não mede aprendizagem nem constitui certificação NASA. Nenhuma implementação de UI, persistência, configuração de build ou documentação geral foi alterada nesta frente.

Correção posterior da revisão independente — engine0.1.1-rd

A frente7 reproduziu um desacordo entre a primeira implementação e o contrato: exigir truncamento do NDVI rejeitava produtos que satisfaziam a tolerância científica declarada de0,0001. O guia documenta escala e tipo, mas não fundamenta esse algoritmo de truncamento. A coordenação corrigiu somente a comparação de concordância para abs((NIR−RED)*10000−produtoInteiro*(NIR+RED)) <= NIR+RED, mantendo a quantização do campo armazenado separada. A versão do motor mudou de0.1.0-rd para0.1.1-rd; catálogo e dados não mudaram. O achado e o teste vermelho anterior permanecem em evidence/adversarial-review.json. As contagens e benchmarks acima descrevem a execução inicial desta frente; o recibo final da rodada registra a verificação após a correção.

CADERNO / 16

05 — Interface funcional e limites da verificação

Frente 5 de implementação. Protótipo de pesquisa Missão Ipê — Ciência que chega, iniciado em 14/11/2026 antes do evento. A elegibilidade permanece pendente. Este relatório descreve código implementado; não apresenta observação de participantes nem validação educacional.

Entrega

Foram criados src/App.tsx, src/main.tsx, src/styles.css, index.html e os componentes de src/ui/. Os módulos do motor, do catálogo, do Worker e da persistência são consumidos diretamente pelas APIs acordadas em specs/IMPLEMENTATION-CONTRACT.md. Nenhum parâmetro físico ou resultado de missão é calculado pelo diorama.

Decisões de interação

• A entrada em edição e o resultado executado são estados distintos. Editar componente ou condição limpa o resultado e a busca, cancela trabalho ativo e invalida a identidade da chamada.
• A navegação para outra etapa cancela uma operação ativa. Uma Promise tardia não muda a etapa nem publica resultado de uma entrada abandonada.
• A execução recebe cópia da configuração. O debrief apresenta a entrada do próprio MissionResult, e não valores posteriores de controles.
• Antes de executar, a pessoa escolhe uma hipótese de gargalo e escreve uma justificativa com pelo menos oito caracteres. Trata-se de requisito de presença de resposta, não de avaliação da sua qualidade.
• O diário registra a previsão antes da chamada ao motor e preserva conclusão, cancelamento, erro, solicitação de ajuda, redesenho sugerido e reflexão. Tempos de interação são datas locais; não são instantes do relógio simulado.
• A busca só é disponibilizada depois de uma previsão e execução próprias concluídas naquela condição. Abrir uma execução salva ou importar um replay não cria essa evidência. A primeira transferência para contatos curtos, portanto, exige sua própria decisão.
• A interface não atribui eficácia educativa a cliques ou sucesso. A reflexão é texto do usuário, vinculado ao identificador do evento selecionado.
• Uma alternativa da busca é aplicada como novo projeto, limpando o resultado anterior. Ela não altera hardware de uma execução em andamento.
• A afirmação de mínimo exige busca completa, zero indeterminados, distância mínima não nula e testemunha disponível. Todas as alternativas retornadas em best são apresentadas; a ordem não recebe interpretação de preferência técnica.

Explicação e ciência

O painel de evidência exibe event.message, event.rule, event.id, tempo e, quando presentes, registro afetado, valor e limite. Ao selecionar um evento, o controle salta para o estado temporal registrado mais próximo. A interface avisa que uma violação observada não determina sozinha a única causa da falha.

O controle temporal percorre os pontos reais do trace. A reprodução avança entre esses estados; não integra equações nem interpola valores para criar telemetria. A curva conecta os pontos registrados como representação visual. Contatos, iluminação e horizonte vêm do cenário; a reserva vem do resultado. A reprodução pausa quando a aba fica invisível.

Datas dos compostos e das observações históricas aparecem separadas do relógio de 180 minutos. NDVI é exibido com quatro casas decimais; os balanços e o replay preservam os números originais. A interface explica que o CubeSat fictício não adquire MODIS em tempo real. O painel de fontes distingue dado científico, hipótese de engenharia, resultado calculado e pesquisa educacional.

Estado, armazenamento e erro

• simulateAsync e searchAsync recebem AbortSignal; toda publicação é condicionada a um token vigente.
• Uma importação inválida preserva configuração, resultado e busca publicados. A substituição ocorre somente após validação/reexecução bem-sucedida e conferência do token. Divergência válida entre alegação e recálculo é informada e apenas o resultado recalculado é apresentado.
• Erro de gravação de execução não apaga o resultado em memória. Avisos de armazenamento de uma ação antiga não substituem avisos da ação atual.
• A leitura de histórico usa identidade própria para impedir que uma consulta antiga substitua uma lista mais recente.
• O rascunho usa revisão esperada da API de persistência. Um conflito de duas abas é informado, sem sobrescrita automática.
• O diário pedagógico usa localStorage com formato versionado, validação de leitura e exportação própria. É um relato local editável, separado dos recibos do motor. Não é um log inviolável nem um certificado de aprendizagem.
• A importação de replay usa seletor local de arquivo e limite de tamanho da API. A UI não executa nem busca URLs contidas em conteúdo importado.

Apresentação, acessibilidade e recursos

O sistema visual usa papel creme, carvão esverdeado, âmbar-ipê, títulos em fonte serifada do sistema e informação técnica em fontes locais. Não há CDN, fontes remotas, texturas baixadas, logotipos institucionais ou selos de validação NASA. O rodapé identifica o produto como protótipo de pesquisa; a área de fontes declara o desenvolvimento pré-evento e a elegibilidade pendente.

O diorama Three.js é carregado por React.lazy em módulo separado. Terra em disco, relevo gráfico, CubeSat, painéis, estação e pontos luminosos são geometrias procedurais. O movimento discreto de apresentação não calcula uma órbita; a vista está marcada como ilustração sem escala. Há no máximo um requestAnimationFrame ativo por instância, e somente uma instância é montada. O renderer limita pixel ratio a 1,5, acompanha tamanho por ResizeObserver, pausa em aba invisível e descarta geometrias, materiais, contexto, observadores e listeners ao desmontar.

Com prefers-reduced-motion, o diorama permanece estático e só redesenha quando necessário. Indisponibilidade ou perda de WebGL ativa a alternativa 2D. Os hotspots são controles DOM nativos com aria-pressed, os campos são grupos de rádio com fieldset/legend, o trace possui slider nativo rotulado e o diálogo usa <dialog>. Há link de salto, foco visível, leitura textual equivalente aos gráficos e layout responsivo. Estes mecanismos foram implementados; a experiência com leitor de tela, zoom e dispositivos reais ainda precisa ser avaliada.

Verificação realizada e pendente

npm run build passou após os ajustes finais desta frente: TypeScript estrito e Vite concluídos. Os artefatos principais foram CSS de 55,25 kB / 11,95 kB gzip, JavaScript inicial de 311,60 kB / 98,26 kB gzip, Worker de 20,16 kB e módulo lazy do diorama de 567,25 kB / 142,28 kB gzip. Esses números medem o tamanho dos arquivos gerados, não inicialização ou FPS. Vite avisou sobre o chunk Three superior a 500 kB e sobre importação dinâmica do motor também alcançado pela importação estática de replay.

O build acima inclui a conferência TypeScript dos arquivos de interface e dos testes presentes no repositório. A coordenação ainda fará a verificação consolidada do pacote distribuível.

Foi lida e aplicada a skill c24/react-best-practices: importação lazy do módulo pesado, componentes em escopo de módulo, IDs de requisição, efeitos com cleanup, estado derivado simples em render e refs para valores transitórios do diorama. A interface não instala uma biblioteca de componentes nem um framework de estilos para cumprir recomendações genéricas dessa skill.

Não foi possível realizar QA visual em navegador nesta frente. A coordenação informou bloqueio do Chromium por permissão de socket e rejeição de acesso file:// no ambiente CUA. Não houve contorno dessas restrições. Permanecem pendentes inspeção de screenshots, medição de FPS, inspeção visual de clipping, teste manual de teclado/leitor de tela e comportamento em dispositivos reais. Testes DOM independentes, motor/persistência e empacotamento final pertencem às frentes de QA/coordenação.

O protocolo de primeira decisão está implementado para preservar relato e ordem local. Aplicação com participantes, rubrica de explicações, avaliação de transferência, retenção e qualquer inferência de eficácia educativa continuam pendentes.

CADERNO / 17

Persistência e replay — implementação e verificação

Registro de 14/11/2026. Este é desenvolvimento específico do protótipo Missão Ipê iniciado antes das 09h BRT. A elegibilidade NASA permanece não estabelecida. Nenhum arquivo original de public/data foi alterado, nenhuma data foi retroagida e esta implementação não altera o status de pesquisa anterior ao evento.

Resultado entregue. O navegador tem persistência real por IndexedDB, com gravação atômica de cada execução, identidade determinística e revisão de rascunho por comparação e troca. O replay é JSON estrito, limitado e versionado: uma importação aceita passa por validação e hashes e executa novamente simulateMission. O schema Prisma é uma arquitetura local opcional validada estruturalmente; não há backend Prisma integrado, client gerado ou migração aplicada.

API para a interface

Arquivo: src/persistence/store.ts.

SavedRun contém exatamente id, createdAt, result, inputHash e resultHash. A interface foi avisada do protocolo de revisão. Em conflito, DraftConflictError possui code='DRAFT_CONFLICT', expectedRevision e currentRevision; o chamador deve manter as escolhas locais visíveis e oferecer recarga/revisão do conflito. Não há sobrescrita silenciosa nem retry que descarte a comparação.

O banco atual se chama mission-ipe-research-v1, versão 1, com stores runs e drafts. runs possui chave primária id, índice composto único byIdentity=[inputHash,resultHash] e índice byCreatedAt. Instâncias independentes abertas com createMissionStore usam conexões distintas ao mesmo banco. A serialização das transações de leitura/escrita do IndexedDB protege o CAS entre abas; não depende de uma variável JavaScript compartilhada.

Falhas de abertura, bloqueio, quota, request, abort e integridade chegam ao chamador. O módulo não converte falha em sucesso, não remove o resultado em memória e não cria um fallback silencioso para armazenamento efêmero. A UI controla a mensagem e a preservação da execução visível. complete é a confirmação da transação; não constitui garantia de retenção eterna contra limpeza do site, expulsão pelo navegador ou falha do dispositivo.

Identidade e formato de replay

Arquivos: json.ts, validation.ts, identity.ts, replay.ts em src/persistence.

exportReplay(result): Promise<string> produz o envelope canônico abaixo. importReplay(text) retorna {result, matchesClaim, importedClaim}: result é sempre a reexecução local; importedClaim conserva a alegação validada recebida, separada do resultado calculado.

O ID da execução é run- seguido do SHA-256 canônico de {kind:'mission-ipe-run-v1',inputHash,resultHash}. A mesma entrada e o mesmo resultado têm o mesmo ID, inclusive em gravações simultâneas. Repetir a gravação preserva createdAt da primeira confirmação. Resultados diferentes sob a mesma entrada são evidências distintas, não sobrescritas. O store valida integridade estrutural e de bytes; a reexecução de alegações importadas pertence ao importador.

Canonicalização: chaves dos objetos ordenadas, ordem dos arrays preservada, strings JSON e codificação UTF-8, representação numérica de JSON.stringify para números finitos seguros. Não se declara conformidade com RFC 8785. O formato próprio tem versão explícita. Timestamps de gravação não entram no ID. As versões e o hash do pacote entram nos hashes de entrada e resultado.

O parser rejeita chaves duplicadas depois de decodificar escapes, incluindo duplicatas como battery e \u0062attery. Rejeita chaves __proto__, prototype e constructor em qualquer nível, além de campos fora das allowlists. Limites: 1.048.576 bytes UTF-8, profundidade máxima 20, 60.000 nós, strings de até 8.192 unidades UTF-16, arrays genéricos de até 8.192 itens; o schema restringe ainda eventos a 2.048, trace a 4.096 e observações a seis. Surrogates isolados, JSON incompleto, comentários, conteúdo extra, NaN, Infinity e estouros numéricos são recusados. O serializador também rejeita ciclos, acessores, arrays esparsos, símbolos e tipos fora de JSON.

Os totais de bits e bits por observação permanecem strings decimais, sem conversão intermediária para ponto flutuante; o limite desta versão é 2^53−1, conforme o motor. Os campos de bits das amostras TracePoint preservam o tipo numérico seguro definido pelo contrato TypeScript. A validação não aplica tolerâncias que mudem o resultado: uma divergência canônica do resultado recalculado resulta em matchesClaim=false.

Entrada, formato, versões ou hashes inválidos são rejeitados antes da reexecução. Uma alegação adulterada acompanhada de um novo hash correto continua sendo reexecutada e devolve mismatch. Nenhuma URL importada é buscada. Nenhum script, trace ou instrução do arquivo é executado. O importador não grava automaticamente o arquivo no histórico.

Limite de confiança. SHA-256 detecta alterações em relação ao hash fornecido; qualquer pessoa pode recalcular esse hash. Ele não autentica NASA, ORNL, o autor do replay ou a identidade de quem executou. Concordar com a reexecução confirma consistência com esta implementação e suas hipóteses, não verdade física, validade experimental ou aprendizado do participante. Não se promete resultado numérico idêntico entre futuros motores ou runtimes. Esta versão rejeita versões e pacotes diferentes, sem migração automática.

Dados científicos preservados

scripts/verify-science-data.mjs lê os originais offline e não escreve arquivos nem busca URLs. A execução passou para:

• SHA-256 do pacote original: 6f49100126a82e1783281083e2c268bcf7b4661b500280de4dc96123036b2a1e.
• Hash e tamanho dos três JSONs originais A, B e C; concordância com os receipts e as referências do pacote.
• Identidade e todos os campos transcritos dos seis registros usados pelo motor.
• Bandas RED, NIR, QA, pixel reliability e NDVI produto contra os arrays originais.
• Datas de composição contra calendar_date, coordenadas solicitadas contra os pedidos e datas do pixel derivadas do dia do ano original: 2024-09-01 e 2024-09-23.
• Timestamps originais de recuperação preservados: 2026-11-14T07:44:09.037615+00:00, 2026-11-14T07:44:09.093483+00:00 e 2026-11-14T07:44:09.060103+00:00.

Isso verifica integridade local e transformação entre artefatos; não transforma composites históricos em aquisições do satélite fictício ou prova a autenticidade remota apenas pelo hash local.

Schema Prisma opcional

prisma/schema.prisma e prisma/prisma.config.ts foram validados com Prisma CLI 7.10.1, sem adicionar dependência Prisma ao app e sem executar migração.

O schema inclui ScenarioPack, SourceReference, ScienceRecord, ScientificParameter, ParameterSource, MissionConfig, Run, Observation, RunEvent, TraceChunk, ImportClaim e Draft. Relações compostas incluem packId para impedir referência entre fonte/parâmetro, registro/fonte, configuração/execução e execução/observação/evento/importação de pacotes distintos. Bit counts são BigInt no modelo opcional, com strings na fronteira JSON. IDs de entidades por versão devem ser globalmente únicos; os identificadores originais permanecem no campo key.

Esse schema descreve uma arquitetura futura. Não implementa transações Prisma, migrations, aplicação de constraints de domínio além das relações, servidor, transporte HTTP, sincronização ou autenticação. Uma implementação futura deverá gravar execução e filhos na mesma transação, habilitar/verificar FKs SQLite, aplicar o mesmo parser e schema de entrada, e usar atualização condicional de revisão para CAS. ImportClaim é armazenamento planejado para conservar a alegação separada; no browser atual ela é apenas devolvida pela API de importação.

Verificações executadas

Os testes de persistência usam fake-indexeddb@6.2.8; verificam operações e rollback do modelo de IndexedDB em Node. Não equivalem a um teste manual em duas abas de um navegador real, a uma medição de quota real, retenção após falha de sistema ou backup. Essas verificações de integração de navegador ficam para a validação do protótipo completo.

Uma checagem global de TypeScript durante edição simultânea da interface encontrou um erro JSX em src/ui/MissionControl.tsx linha 65; a frente da interface foi avisada. A checagem isolada de todos os arquivos desta frente e os testes passou depois. A coordenação deve rodar o build global quando os arquivos de todas as frentes estiverem concluídos.

Referências técnicas consultadas

• Indexed Database API 3.0 — W3C, Editor’s Draft de 30/10/2026: ciclo, agendamento e conclusão de transações. Referência consultada como draft, sem alegar recomendação final da W3C.
• Prisma ORM v7 — Config API: configuração de schema e datasource; caminhos resolvidos em relação ao arquivo de configuração. A compatibilidade concreta foi conferida pela CLI 7.10.1.

Nenhum SDK de IA foi instalado ou usado. Não há LLM decidindo hash, QA, energia, resultado ou verificação do replay.

CADERNO / 18

Frente 7 — Revisão independente adversarial

Revisão feita em 14/11/2026 sobre o motor, prova finita, recibo e bridge de Worker do Missão Ipê. O trabalho é P&D específico anterior ao evento. A elegibilidade competitiva continua pendente; estes testes não certificam participação, hardware, dados futuros nem aprendizagem.

Estado final: PASS nos oito testes distintos desta frente, após reexecuções dos casos afetados. Houve defeitos reais antes das correções: tolerância NDVI e respostas malformadas do Worker. Houve também endurecimento de imutabilidade dos metadados compilados. A evidência vermelha permanece em evidence/adversarial-review.json, junto das versões, comandos e hashes SHA-256 das fontes. Esta frente só alterou seus testes e seus dois arquivos de relatório/evidência. A coordenação corrigiu a implementação.

Método independente

Foram lidos os contratos, specs/IMPLEMENTATION-CONTRACT.md, docs/03-PRT.md, os módulos de núcleo, persistência e Worker, além dos testes já existentes. O objetivo não foi copiar assertions de regressão. tests/adversarial.test.mts constrói as 64 tuplas por uma máscara binária independente e usa valores literais do contrato para massa, créditos, taxa, lote, memória, geração e consumo.

O oráculo alternativo percorre segundos inteiros; quando a fila esvazia durante um segundo, divide apenas esse segundo entre transmissão e espera. Ele não importa a aritmética racional, powerFlow, catálogo, enumeração ou distância da implementação. Nesta versão fechada, trabalhos, contatos e luz têm fronteiras inteiras; saturação resulta de limitar o armazenamento em cada intervalo constante. Portanto esse oráculo é adequado às 128 combinações atuais. Ele não reivindica suportar cenários futuros com fronteiras fracionárias arbitrárias.

Para cada uma das 64×2 execuções foram comparados classificação, massa, créditos, bits gerados, recebidos, perdidos e em fila, registros entregues, energia final e mínima e instante de conclusão. Conferiram-se também os somatórios globais e por observação. A diferença admitida de menos de 1e-8 Wh/segundo existe apenas na comparação dos números de saída com o oráculo numérico independente; ela não altera qualquer limite ou resultado do motor.

A busca foi confrontada com as soluções do oráculo e executada em quatro ordens: natural, reversa, permutação modular por 17 e Gray code. O mínimo, as testemunhas e os contadores permaneceram iguais. Todas as alternativas de distância inferior ao mínimo foram decididas pelo oráculo; a resposta fornecida pela busca não foi usada como premissa.

Resultado do domínio e prova mínima

A testemunha curta a distância 2 é única: bateria large e processamento index, mantendo painel standard, rádio economy, buffer large e política every-contact. Sua massa é 3,5 kg e seu custo é 84 créditos. Os sete projetos a distância 0 ou 1 não satisfazem a missão curta. A alternativa bateria grande + rádio rápido transmite o volume de BANDAS, mas pesa 3,7 kg e viola o envelope de 3,6 kg. Nenhuma dessas conclusões extrapola o catálogo de 64 tuplas.

Como verificação aritmética legível do padrão longo, a bateria já está cheia em 5400 s. Até 7200 s, há 600 s de rádio e 1200 s de espera: E7200 = 16 − (16×600 + 8×1200)/(0,95×3600). Seguem 1800 s de carga solar, acrescentando (18×0,85 − 8)×0,95×0,5 = 3,4675 Wh. Os 504 Mbit restantes exigem 525 s de rádio no segundo contato; o restante até 10800 s ocupa 1275 s de espera. O resultado é 8,414868421052631 Wh, consistente com a implementação e o oráculo. O serviço curto econômico é 480×960000 = 460800000 bits, insuficiente para os 1080000000 bits de BANDAS, mas suficiente para os 360000000 de ÍNDICE quando as demais restrições são satisfeitas.

Achado NDVI-TOLERANCE-001 — corrigido

No estado ENGINE_VERSION=0.1.0-rd, o validador exigia igualdade com o truncamento da razão de bandas escalada. Isso contradizia a tolerância científica inclusiva de 0,0001 declarada no PRT.

O guia primário MOD13 C6.1, seção 5.2/tabela 1, documenta armazenamento int16, escala 0,0001 e domínio do produto. A consulta não encontrou regra explícita que autorize truncar o NDVI reconstruído dessas bandas; as buscas por trunc e round também não retornaram texto. Isto limita a alegação sustentada por essa fonte: seis exemplos concordantes não demonstram um algoritmo NASA de quantização. A tolerância é política declarada deste protótipo, não garantia universal de acurácia MODIS.

A coordenação passou o motor para 0.1.1-rd e separou o campo escalado da concordância científica. Para s=NIR+RED, d=NIR−RED e p inteiro do produto, a comparação inclusiva é abs(d×10000 − p×s) <= s. Os inteiros nesse domínio são seguros. Não se introduziu epsilon em energia, massa, pico ou bits. As duas representações IEEE do campo MOD13 escalado continuam tratadas separadamente.

Os testes agora passam nos dois sinais, exatamente no limite e logo além dele: razão ±1/9999 contra produto zero deve ser rejeitada porque seu erro supera 1e-4. Os seis registros originais e os resultados das 128 combinações permaneceram iguais após a correção.

Worker — defeitos corrigidos e alcance do teste

Antes da correção, uma mensagem com ID atual, ok:true e result:{} resolvia a Promise com um objeto que não satisfazia o contrato. Uma mensagem null lançava TypeError no listener; a Promise só era rejeitada depois de cancelamento explícito ou timeout. São falhas de tratamento e validação do transporte, não demonstração de Worker hostil executado no produto.

O bridge corrigido rejeita mensagem malformada pelo caminho de encerramento e valida resultado, configuração e cenário. Os testes também provocam retorno de outro cenário, outra configuração, busca incompleta que ainda tenta certificar mínimo, soma inconsistente de contagens, distância incompatível e testemunha duplicada. Todos são rejeitados.

O FakeWorker confirmou que duas chamadas concorrentes têm identidades independentes, a configuração enviada é um snapshot, ID estrangeiro válido é ignorado, cancelamento termina o Worker, mensagem posterior não reabre uma Promise cancelada e um sinal já cancelado não cria um Worker. O retorno válido da busca continua aceito. Isso testa o protocolo no Node; não mede inicialização real de Worker, rendering, GPU ou responsividade em navegador. Nenhum navegador real foi usado nem houve tentativa de contornar as restrições informadas.

Metadados e recibo

Antes do endurecimento, a anotação TypeScript readonly não impedia mutação em runtime. Alterar temporariamente sourceId, latitude e longitude do primeiro registro para outros valores admissíveis preservou sua aprovação, o sucesso da missão e o hash do resultado, porque esses campos não integram a saída numérica. O hash fixo do pack também permaneceu igual. Os valores originais foram restaurados imediatamente.

Esse experimento exigia mutação direta do módulo em memória. O importador não oferece uma entrada para substituir o pack, portanto não foi classificado como bypass remoto ou falsificação de procedência via replay. A coordenação congelou o array e cada registro. O teste agora exige essa imutabilidade e verifica que a tentativa de alteração lança TypeError. O congelamento evita alteração acidental; não constitui prova criptográfica de autoria NASA.

No recibo, seis adulterações distintas foram feitas após exportação, recalculando corretamente o hash da alegação: ID científico, NDVI esperado, timestamp de evento, redistribuição de bits entre observações sem mudar total global, modo do trace e quantidade requerida. Todas produziram matchesClaim:false, e o resultado reexecutado permaneceu idêntico ao original. Aceitar uma alegação estrutural para compará-la não significou confiar nela. Não foi encontrado bypass dessa reexecução nas contraprovas aplicadas.

Execuções registradas

Runtime: Node v24.22.1, TypeScript executado por strip types. Não há revisão git disponível nesta raiz; o recibo usa hashes dos arquivos para identificar os estados inspecionados.

Na primeira repetição após o bridge corrigido, um teste rejeitou a redação correta de ReplayValidationError por usar regex excessivamente estreita. O teste passou a verificar o tipo Error e o comportamento de rejeição/encerramento; esse ajuste não alterou a implementação. Houve nova execução dos quatro casos afetados, todos aprovados. Foram aprovados oito testes distintos ao longo das reexecuções; não se declara uma execução final única de oito testes que esta frente não realizou.

Não foi ampliado o backend nem a revisão de Prisma: o esquema opcional não participa do caminho ativo de persistência no browser e não surgiu um risco concreto que justificasse ampliar o escopo. A validação visual e a integração real de interface continuam fora da evidência desta frente.

CADERNO / 19

08 — Auditoria mundial dos repositórios do anexo

Missão Ipê · Rodada 4 · consulta em 14/11/2026. Auditoria documental de fontes primárias, sem instalar bibliotecas, executar os projetos, baixar pesos ou copiar código para o jogo. O arquivo anexo-original.txt tem 32.575 bytes e 33 famílias editoriais, distribuídas por cinco blocos geográficos. Os dois anexos são duplicatas, conforme o relatório 02; não são duas evidências independentes. A pesquisa inclui todos os caminhos dessas 33 famílias, os componentes SatNOGS nomeados, correções de endereço e o comparável CubeSat. Fastino permanece no relatório 02.

Decisão de integração

Nenhuma biblioteca adicional do catálogo é necessária ao P0 atual. O produto já tem um problema delimitado: escolher entre 64 configurações, transportar seis resultados MODIS, explicar restrições e conferir um recibo. Python científico, Java, Rust, C++, servidores geoespaciais, redes de rádio e modelos fundacionais podem apoiar a produção futura de cenários. Inserir qualquer um desses ambientes no navegador agora aumentaria dependências sem resolver uma lacuna demonstrada do contrato.

O achado mais valioso do catálogo é a diferença entre camadas: renderizador não é propagador orbital; simulador não é software de voo; software de voo não é backend de telemetria; máscara produzida por IA não é medição validada; licença da biblioteca não licencia dados, pesos ou mapas. Os blueprints do anexo conectam nomes plausíveis, mas não especificam interfaces, unidades, convenções temporais, erros, formatos intermediários ou critérios de aceite. Portanto, são esboços, não integrações prontas.

As correções materiais são: LSR foi descrito como outro programa; SAMRS foi confundido com SamGeo; NISAR foi ligado genericamente ao ISCE2 em vez da base explícita ISCE3; MintPy foi apresentado como se seu fluxo principal produzisse o desdobramento inicial, embora consuma interferogramas já desdobrados; vários caminhos estão errados ou mudaram; cFS é um bundle demonstrativo que expressamente não deve voar como está. Em contrapartida, jaxa/open-set existe, tem documentação JAXA e não deve ser descartado como referência inventada.

Critério e força da evidência

P0 significa indispensável ao contrato atual; P1, melhoria pequena após o aceite; P2, expansão que exige experimento e integração própria; Excluir, sem encaixe no problema atual ou com identidade/permissão insuficiente. Excluir do Ipê não desqualifica o projeto em sua área. As prioridades são julgamento desta auditoria, não recomendação dos mantenedores.

O inventário evidence/repository-audit.json conserva caminhos solicitados e corrigidos, retorno da API pública, licença identificada, pushed_at, indicador archived, fontes e decisão. repository-metadata.json contém 67 consultas de repositório GitHub; READMEs recuperados estão em repository-sources/. Uma data de push não prova release estável, CI verde, suporte ou prontidão industrial. Nenhum dos repositórios acessíveis na coleta inicial estava marcado como arquivado, mas vários tinham última atividade antiga. As datas referem-se ao estado observado, não à versão que eventualmente será adotada.

A API devolveu 404 para alguns caminhos literais. Isso foi registrado como caminho não recuperado, não como prova de inexistência do software. Os GitLabs Orekit/OTB devolveram proteção Anubis; consultamos espelho ou documentação oficial, sem contornar a barreira. NOASSERTION da API significa classificação automática inconclusiva: quando o README ou LICENSE esclarece, isso está indicado. Sem declaração identificada, não se presume permissão de reutilização.

Matriz completa: EUA e fundamentos espaciais

Matriz completa: Europa

Matriz completa: ferramentas agrupadas pelo anexo como russas

A seção preserva a organização recebida; não confirma nacionalidade de autores por nome, idioma ou satélite suportado. Ligação empresarial SPUTNIX pode ser documentada; isso não torna toda biblioteca comunitária um produto nacional ou institucional.

Matriz completa: Ásia e Ásia-Pacífico

Matriz completa: infraestrutura global

Cinco oportunidades priorizadas

1. P0: procedência que participa da vitória. A melhor transferência deste catálogo para Ipê é um contrato de dados, não outra dependência. O pacote deve preservar produto, coleção, data, bandas, escala, QA, coordenadas/recorte, transformações e hash. Cada um dos seis resultados recebidos deve resolver para a origem; duplicata, fragmento e dado inválido não completam a missão. O ganho demonstrável é o usuário conseguir distinguir dado NASA, hipótese didática e resultado calculado. Gate: recibo exportado conferido localmente, adulteração material rejeitada e valor reproduzido por oráculo independente. A linguagem STAC pode organizar metadados; não precisa instalar pystac-client no navegador.

2. P1: explicar a diferença entre receber e reconstruir. SX-Files, SatsDecoder e gr-satellites dão exemplos reais de arquivos montados a partir de fragmentos. Oportunidade: uma missão em que chegam muitos bytes, mas falta um bloco necessário à ciência. Mostrar quais registros podem ser reconstruídos e por que informação incompleta não equivale a entrega. Implementar a regra de modo independente e usar um exemplo real apenas com termos identificados. Gate: casos de fragmento ausente, duplicado, fora de ordem e retransmissão; quantidade de bytes não pode substituir conjunto íntegro. Não chamar o modelo simplificado de implementação CCSDS ou DTN.

3. P1: investigação temporal com referência Open MCT. Estudar organização de séries, eventos e inspeção de telemetria para tornar visível a primeira violação e o efeito da mudança. O benefício depende de o participante conseguir apontar o evento e a restrição, não da aparência de sala de controle. Implementar controles HTML e um traço curto no stack já escolhido; não importar Open MCT inteiro sem necessidade. Gate: pessoa explica o gargalo antes da sugestão e resolve condição nova; medir ajuda, erro e abandono. Uma lista de eventos auditável sustenta melhor a tese educativa que alertas decorativos.

4. P2: agenda orbital confrontada com uma ferramenta externa. Escolher Orekit ou Basilisk, fixar cenário e gerar contatos/eclipses fora do aplicativo. Comparar tempos e balanços com uma aproximação declarada, preservando diferença e tolerância. S2E/C2A são alternativa se a pergunta mudar para interação de software de bordo e componentes. Gate: uma discrepância identificada, explicada e reproduzida; manifesto de versão, dados auxiliares, referenciais, unidades e passo. Resultado pré-calculado pode viajar offline sem JVM/Python/C++ no runtime. A referência externa não transforma automaticamente todo o motor em fisicamente validado.

5. P2: terreno planetário local subordinado a uma decisão. 3DTilesRendererJS tem aderência técnica ao Three existente. Usá-lo somente quando relevo, visibilidade ou localização mudarem uma escolha compreensível. Selecionar recorte pequeno, atribuição e licença, limitar LOD/memória e guardar todos os assets. Gate: abrir sem rede, carregar dentro do orçamento medido, manter alternativa HTML e provar que o terreno participa do mecanismo. Se servir apenas de paisagem, o diorama procedural é suficiente. SPICE seria outro módulo, com geometria e kernels explícitos; o renderizador não os fornece por associação institucional.

Estas cinco oportunidades têm ordem de dependência: terminar contrato e verificador; melhorar investigação; só então aumentar fidelidade ou volume. Prithvi, mudança semântica e segmentação permanecem experimentos posteriores. A potência de um modelo não é critério de prioridade quando sua entrada, saída e erro não participam da tarefa.

Prithvi: memória, dados e alegação offline

O card EO2 descreve seis bandas HLS em ordem específica e reflectância, com versões temporais/geográficas distintas. O card consultado já lista variantes tiny e 100M além de 300M/600M; portanto, “Prithvi” não identifica um único tamanho. Nenhuma variante foi testada aqui. Como conta inferior de engenharia, somente os pesos de 300M parâmetros a 2 bytes ocupam aproximadamente 0,6GB; 600M, 1,2GB; WxC2,3B, 4,6GB. Em 4 bytes, dobram. São valores decimais calculados, não medição de VRAM: faltam ativações, cabeças, buffers, framework, dados e estados de treinamento. O dtype efetivamente suportado também deve ser verificado.

Offline exige pesos completos, configuração, normalização, dependências, codecs e dados disponíveis localmente, além de desativar downloads automáticos e provar a execução desconectada. A possibilidade de cache não comprova isso. Fine-tuning para inundação ou deslizamento tampouco se transfere sem teste para vegetação brasileira, outra resolução, bandas ou dispositivo. Para Ipê, um modelo pode futuramente produzir uma hipótese de máscara confrontada com referência; não deve decidir se os seis valores científicos chegaram corretamente.

Correções do dicionário e dos blueprints

A linha SPICE do anexo agrupa capacidades diferentes: SpiceyPy envolve CSPICE; Skyfield utiliza determinados tipos de efemérides; 3DTilesRendererJS renderiza geometrias. Retirar a afirmação de que os três leem nativamente todos os kernels listados. A linha SAR deve separar SLC complexo, GRD e interferogramas já processados; MintPy não é leitor genérico de qualquer produto SAR cru. A linha de telemetria agrega CCSDS, XTCE, CSP e AX.25 como se cada ferramenta implementasse todos; suporte deve ser verificado por protocolo, módulo e missão. Formato legível não garante calibração, QA ou equivalência científica.

Reescrever promessas de “elimina pré-processamento”, “sem travar GPU”, “imediatamente”, “qualquer lugar do planeta”, “precisão exata” e “rigor irrefutável” como capacidades condicionais com entrada, orçamento e teste. Para modelos de mudança, incluir co-registro, nuvens, iluminação, sazonalidade e domínio no plano de avaliação. Para nuvens/dehazing, distinguir reconstrução inferida de observação realmente feita. Para InSAR, separar sensibilidade de deformação, incerteza e previsão de desastre. Nenhum desses termos deve aparecer no pitch sem evidência correspondente.

Limite de diferenciação e ecossistemas

O Space-Mission-Design-Game comparável declara no README jogo CubeSat estático, Vite, construção/teste/operação e persistência localStorage. A arquitetura também declara Three.js local, editores de satélite/órbita, SVG e fallback 2D quando WebGL falta. Há diretórios de testes e documentação; isso não prova qualidade executada nem acessibilidade avaliada. Não copiamos código nem verificamos funcionamento. O namespace com NASA não comprova vínculo institucional, e o repositório não fornece evidência de elegibilidade da equipe. A licença não foi identificada na API/README consultados.

Consequência competitiva: montar CubeSat, negociar requisitos, ter fases de missão, visualização 3D com fallback 2D e salvar localmente já não são diferenciais exclusivos. A tese específica do Ipê precisa ser apresentada como combinação verificável: entrega científica de arquivo NASA, 64 alternativas enumeráveis, consequências acopladas, explicação ligada a eventos e recibo conferível. Não afirmar que essa combinação é inédita no mundo; esta auditoria não cobre todo o universo de jogos. O teste é demonstrar o benefício em poucos minutos e mostrar evidência de aprendizagem em sessão observada, sem transformar intenção em resultado.

A seleção EUA/França/Japão do dossiê é defensável como três ecossistemas de referência para este recorte, nunca como ranking tecnológico mundial. NASA fornece ligação institucional explícita; Orekit é licenciado por CS GROUP e tem ecossistema francês, sem ser simplesmente uma biblioteca criada pela ESA; S2E identifica ISSL/Universidade de Tóquio e Open-SET identifica JAXA. Prithvi inclui Jülich e múltiplas instituições internacionais; PASEOS inclui AI Sweden/ESA; SamGeo identifica apoio NASA e comunidade aberta. A rede de autoria atravessa os blocos nacionais do anexo. Não atribuir nacionalidade a mantenedores pelo username, nem usar país como proxy de licença, qualidade ou adequação.

Limites finais da auditoria

Esta é uma triagem documental ampla com aprofundamento nos erros que mudam decisões. Não é auditoria linha a linha de 67 bases de código, avaliação de segurança, reprodução de benchmarks ou certificação de licenças transitivas. Nem acesso à API nem existência de README provam instalação bem-sucedida. Antes de adotar qualquer P2, fixar commit/release, recuperar LICENSE/NOTICE e dados, executar exemplo mínimo, medir recursos no equipamento alvo e registrar o que falhou. Os itens não resolvidos permanecem explícitos; a decisão P0 não depende deles.

CADERNO / 20

09 — QA de integração, release e desempenho

Frente 9 de 10, execução em 14/11/2026 UTC. Projeto de P&D pré-evento, com elegibilidade competitiva pendente. A validação abaixo foi executada em Node e DOM simulado; não houve navegador, avaliação com participantes ou medição de FPS nesta frente. Nenhum arquivo de src/ precisou de alteração.

Resultado observado

A jornada React passou com motor, catálogo, busca, reexecução de replay e adaptador de persistência reais. O runner Node reporta 9/9 PASS, zero falhas e zero skips: uma jornada principal com seis subtestes, mais dois testes independentes. O total do runner inclui o teste pai; não são nove ensaios independentes.

Os testes estão em tests-ui/flows.test.mjs; scripts/test-ui.mjs transforma TSX por esbuild, mantendo pacotes externos, e executa o runner Node. Não há mocks de score, ciência, equações, resultados, busca ou importação. O cliente usa seu fallback normal quando Worker não existe. fake-indexeddb fornece o armazenamento em memória do teste; a transação e a validação de registros continuam sendo código do produto.

As adaptações do ambiente são explícitas: contexto canvas nulo, scrollTo sem efeito e métodos showModal/close que mudam o atributo open. A importação recebe um File de Node porque jsdom não implementa File.text(). Os logs de erro WebGL são esperados e preservados no TAP; a última execução não contém warnings de act. Durante a construção do harness, um cleanup que alcançava subtestes foi corrigido no próprio teste, sem modificar o produto.

Comandos e recibos

A coordenação informou execução separada de npm test com 51/51 PASS às 08:59:39 UTC. Esse resultado não foi reexecutado nem somado como execução própria desta frente. Build, HTML portátil, empacotamento, AB-R3A, PDF e entrega persistente pertencem à coordenação. evidence/release-qa-manifest.json identifica por SHA-256 os scripts, teste e recibos desta rodada, além das limitações declaradas.

O recibo DOM final foi preservado separadamente: execução de 09:05:39.122 a 09:05:40.353 UTC, duração do runner de 1.182,983 ms. Inclui a inspeção dos rádios da configuração ativa após rejeitar o replay. O gate da coordenação e o snapshot AB-R3A podem conter a versão imediatamente anterior desse teste; o código runtime é o mesmo. Essa diferença é explicitada, sem atribuir ao snapshot antigo as asserções acrescentadas.

Benchmark do motor 0.1.1-rd

Medição final às 09:04:05.479 UTC, com ENGINE_VERSION=0.1.1-rd, catálogo ipe-64-v1 e hash do pack registrado no recibo. A segunda rodada foi feita depois de concluir DOM/HTTP/auditoria para evitar a concorrência que existiu na primeira tentativa. Ainda é um executor compartilhado, sem exclusividade de CPU, afinidade, controle térmico ou controle de energia.

Ambiente observado: Node v24.22.1, V8 13.6.233.17-node.58, Linux 6.18.57, x64, identificação de CPU AMD EPYC 9V45 96-Core Processor, nove CPUs lógicas expostas e availableParallelism=9. Memória total exposta: 10.451.427.328 bytes. RSS do processo ao final: 150.294.528 bytes; isso inclui Node e o carregamento TypeScript, não é consumo isolado da aplicação no navegador. Nenhuma máquina pessoal de AB foi medida.

Cada workload usa 30 aquecimentos descartados e 200 execuções medidas por performance.now(), sequenciais, com trace padrão habilitado. Os percentis usam nearest rank: posição ceil(N × p) − 1 na série ordenada. As 800 amostras brutas e hashes de todos os módulos numéricos estão no JSON. Não se força coleta de lixo e os máximos permanecem registrados.

A enumeração longa registrou 17 sucessos, 41 falhas e seis inválidas, com distância mínima zero para a configuração padrão. A curta registrou nove sucessos, 49 falhas e seis inválidas, com distância mínima dois. Ambas avaliaram 64, com zero indeterminados. Esses totais também são assertados pelo script para que um benchmark rápido com trabalho incompleto não seja aceito.

O tempo medido inclui cálculo e construção do resultado/trace. Exclui startup de Node, importação de módulos, Worker e mensagens, React, persistência, hashing de replay, carregamento inicial de página e renderização. Portanto, ele não demonstra que a meta de busca no Worker, carregamento offline em três segundos ou frame p95 de 33,3 ms foi cumprida no equipamento de demonstração. Não há FPS publicado.

Dependências, licenças e rede

O inventário leu o package-lock.json e os metadados efetivamente instalados: 157 entradas de pacote no lock, 83 instaladas, zero divergências entre versão instalada e fixada e zero entradas sem metadado de licença. As entradas não instaladas incluem variantes opcionais de outras plataformas; não foram tratadas como execução comprovada. Não foi executada uma auditoria de vulnerabilidades remota nesta frente.

Hashes e tamanho dos arquivos de licença estão no inventário. Os avisos de distribuição estão em licenses/ e NOTICE.md; o código original tem LICENSE Apache-2.0. O campo license de package.json estava ausente no instantâneo inventariado; a licença do projeto foi observada nos documentos, sem inferir licença das dependências a partir dela. Este inventário de metadados e avisos não constitui revisão jurídica nem certificação de compatibilidade de todo uso futuro.

A varredura estática de 28 arquivos (src/**/*.ts, TSX, CSS e index.html) encontrou zero referências a APIs de rede pesquisadas, zero assets/imports remotos e uma URL HTTPS, localizada apenas no comentário de proveniência em src/core/science.ts. O código de aplicação não usa CDN, fonte externa, serviço de IA ou pesos de modelo no caminho inspecionado. A ausência de correspondências em uma varredura por padrões não é prova formal de toda execução possível. Não foi realizado teste de rede de navegador, primeira abertura offline ou medição de cache. Instalar dependências para recompilar continua sendo uma etapa distinta do runtime distribuído.

Smoke HTTP do servidor local

Uma instância de scripts/serve.mjs foi iniciada em 127.0.0.1:45179, recebeu as oito requisições abaixo e foi encerrada pelo teste. Este é um teste do serviço Node, não uma tentativa de abrir ou contornar restrições de navegador.

Todas as respostas incluíram CSP e X-Content-Type-Options: nosniff. O recibo preserva cabeçalhos, status, hashes de corpo, horário e hash do servidor. Não foram testados concorrência de alto volume, travessia por symlink ou publicação fora de loopback. O script faz uma única tentativa de inicialização e registraria EPERM/EACCES sem tentar bypass; nesta execução o socket HTTP foi permitido.

Pendências reais para liberação de demonstração

É necessário testar em navegador e hardware de demonstração: primeira abertura sem rede, Worker real, seleção e download nativo de arquivos, persistência após reiniciar, teclado/foco/modal, leitor de tela, contraste, zoom, clipping responsivo, qualidade e descarte do WebGL, carga inicial e orçamento de frames. O bloqueio anterior do Chromium e a rejeição CUA de file:// foram respeitados; nenhum navegador ou workaround foi usado nesta frente.

O DOM simulado não substitui esses testes. Tampouco comprova aprendizagem, validade física de voo, integração Fastino, disponibilidade de um modelo offline ou elegibilidade de submissão. A evidência desta rodada sustenta a integração funcional examinada e o custo do núcleo neste executor, com entradas, versões e comandos reproduzíveis.

CADERNO / 21

10 — Revisão final independente e limites da entrega

Missão Ipê · 14 de novembro de 2026 · frente 10 de 10. Leitura inicial às 09h01 UTC / 06h01 BRT, atualizada com os recibos finais das 09h05 UTC. A rodada começou às 08h23 UTC / 05h23 BRT. Código e especificações específicos foram produzidos antes da abertura oficial local, às 09h BRT / 12h UTC. Toda a entrega permanece P&D pré-evento, com elegibilidade competitiva não estabelecida.

Parecer

Existe um protótipo implementado, com um núcleo pequeno que pode ser confrontado integralmente com um oráculo independente. A evidência disponível sustenta resultados no domínio fechado de 64 configurações e duas condições, integridade local dos arquivos científicos, reexecução de recibos e contratos de persistência. Ela não sustenta elegibilidade, execução em navegador real, desempenho no equipamento de AB, eficácia educativa, fidelidade orbital ou integração de modelos de IA.

Não há base para estimar a chance de premiação. O potencial competitivo é uma hipótese de produto: tornar visível a relação entre decisão, restrição, ciência recebida e explicação verificável. Montagem de CubeSat, Three.js, funcionamento local e alternativa 2D já aparecem em um comparável identificado. Não são exclusividades do Ipê. O conjunto específico deve ser demonstrado e avaliado; não pode ser anunciado como inédito no mundo.

Escopo e método

Foi feito inventário com rg --files, excluindo node_modules e artefatos compilados da leitura de fonte. Foram confrontados os documentos 01–07, relatórios de pesquisa 01–08, contratos em specs/, módulos de núcleo, dados, Worker, persistência, trechos da interface, scripts e recibos existentes. A pesquisa 09 de DOM e benchmark estava em execução paralela; seus recibos foram incorporados depois de existirem. Esta frente não usou navegador, não modificou código, testes, dependências ou Prisma e não contatou organizadores.

Esta revisão não refez toda a pesquisa externa. As conclusões de regras, modelos e bibliotecas remetem às fontes primárias e aos limites preservados nos relatórios 01, 02 e 08. Falhas HTTP 502/503 nos Resources são registros de recuperação, não prova de que a página inexiste. O exame da implementação não substitui auditoria integral de segurança ou de licenças transitivas.

Foi reexecutado node --experimental-strip-types scripts/verify-science-data.mjs, com saída ok:true: seis registros, três originais, campos transcritos, datas e hashes conferiram. O hash do pack é 6f49100126a82e1783281083e2c268bcf7b4661b500280de4dc96123036b2a1e. Não foram alterados os arquivos de origem. A leitura posterior de evidence/final-validation.json, concluído às 09h05min34s UTC, confirmou seis comandos com saída 0: 51 testes Node, nove testes DOM simulado, ciência, TypeScript/Vite, HTML portátil e validação estrutural Prisma 7.10.1. Uma nova execução DOM às 09h05min40s também registra nove aprovados. São execuções das respectivas frentes/coordenação, não comandos reivindicados por esta frente.

O benchmark das 09h04 UTC usa Node 24.22.1, CPU AMD EPYC 9V45, 30 aquecimentos e 200 amostras por carga. Busca de 64 tuplas: mediana/p95 de 4,201/4,936 ms no caso longo e 3,994/4,237 ms no curto; o máximo curto foi 32,073 ms. Exclui carregamento, Worker, React, persistência e GPU. A nova inspeção AB-R3A/REA terminou com saída 0 em 7,634 s: 43 arquivos, 40 JS/TS analisados, zero falhas de parse, 40.369 nós AST e 596 achados estruturais. Cobertura de aplicação parcial e semântica parcial/truncada continuam explícitas. Achados estruturais não são 596 vulnerabilidades confirmadas; saída 0 não certifica segurança ou equivalência. O digest registra mudança posterior apenas em tests-ui/flows.test.mjs.

Alegações examinadas

As contagens verificadas são 17 sucessos, 41 falhas e 6 inválidas no contato longo; 9 sucessos, 49 falhas e 6 inválidas no curto. Ambas as buscas cobrem 64 tuplas sem indeterminadas. Os denominadores descrevem o catálogo artificial, sem distribuição de amostragem da engenharia real.

Achados que precisam acompanhar a entrega

RT-01 — Elegibilidade temporal e qualificação do recurso continuam abertas

As discussões oficiais #1827, #1872 e #2009 situam desenvolvimento específico às 09h locais e tornam inadequada a classificação automática de especificações antecipadas como preparação permitida. #1924 trata da reutilização de código anterior que não tenha sido criado especificamente para o challenge. A autorização de AB para trabalhar não é autorização dos organizadores. Separar, declarar, renomear, recompilar ou reescrever o material não garante regularização. Tampouco existe decisão observada que permita declarar desclassificação automática desta equipe.

MOD13Q1 tem procedência NASA, mas não foi comprovada sua inclusão nos Resources oficiais do desafio. Recursos de engenharia localizados no espelho são candidatos até confronto com a lista oficial. O enunciado também deve ser confrontado com o recorte: lançador e perfil orbital estão fixos, enquanto o desafio pede decisões de missão mais amplas. Isso é gate de adequação, não defeito oculto a resolver adicionando funcionalidades às pressas.

Responsável: AB e responsável humano pela candidatura. Saída exigida: resposta identificável da organização, brief/Resources vigente e agenda/formulário confirmados. A revisão não enviou nenhuma mensagem externa.

RT-02 — Distribuíveis regenerados depois do último código

O recibo portátil inicialmente observado foi gerado às 08h52min05s UTC, antes das correções de Worker e congelamento dos registros verificadas às 08h57min13s UTC. O achado foi encaminhado e a coordenação reconstruiu dist e HTML; evidence/portable-build.json agora registra 09h05min25s UTC e 1.008.522 bytes. evidence/final-validation.json preserva comandos e hashes. A montagem final de PDF/ZIP ainda deve usar esses bytes e os documentos concluídos. Alteração apenas editorial posterior não invalida o cálculo, mas deve entrar no manifesto final do pacote.

Responsável: integração/release. Estado: rebuild corrigido e verificado; fechamento do pacote documental sob coordenação. A inspeção desta frente não marcou o artefato antigo como aprovado.

RT-03 — Dependência absoluta e sobrescrita EVI3 corrigidas

Na leitura inicial, research/evidence/validate-evi3-research.py usava SOURCE absoluto apontando para ab-global-final-round/research/evidence e regravava evi3-validation.json. Um pacote isolado não reproduziria o caminho, e o recibo histórico seria substituído. Depois do reporte, a coordenação mudou a entrada para public/data relativa ao projeto. Sem --out, o script só imprime o resultado; com --out, cria um arquivo novo em modo exclusivo e recusa sobrescrita. A alteração foi inspecionada nesta frente.

Responsável: coordenação científica/release. Estado: corrigido; evidence/evi3-rerun.json, às 09h02min40s UTC, registra seis comparações aprovadas e diferença máxima de 0,00009379329454142421. O achado não alterou os seis cálculos históricos nem o motor NDVI.

RT-04 — Propostas anteriores não são contratos implementados

research/03-oportunidades-spec.md inclui orçamento ilustrativo de 256 candidatas em três segundos e campos propostos de certificado como scenarioHash e catalogHash. O domínio atual tem 64 tuplas e meta de busca de um segundo no equipamento de demonstração; o replay implementado carrega versões e sciencePackHash. O relatório se apresenta como proposta, mas essas diferenças precisam ficar explícitas na síntese para evitar copiar uma intenção como capacidade entregue.

O mesmo cuidado vale para a recomendação de pesquisa de não persistir texto livre por padrão: a interface atual salva previsões e reflexões no diário local quando o armazenamento funciona. A exportação é deliberada; o armazenamento local acontece no fluxo normal. Não há detector de PII instalado, anonimização garantida, identidade autenticada ou diário inviolável. Uma pessoa com controle do armazenamento local pode alterá-lo; o bloqueio de ajuda não é fiscalização de prova escolar.

Responsável: produto/documentação. Saída exigida: relato fiel do fluxo atual e decisão explícita antes de estudar pessoas. Não são necessários novos serviços para esclarecer esses limites.

Atualização: a coordenação inseriu nota de integração no início de research/03, distinguindo 64/1 s de 256/3 s e recibo implementado de certificado proposto. Três replays importáveis foram gerados em examples/; evidence/catalog-enumeration.json contém 128 resultados produzidos pelo motor. Essa tabela é artefato de pesquisa, não um novo formato de certificado de busca do browser e não substitui o oráculo independente.

RT-05 — Correções anteriores têm contraprovas preservadas

A revisão independente registrou: regra de truncamento NDVI incompatível com a tolerância; resposta Worker malformada aceita; mensagem null sem encerramento correto; metadados científicos mutáveis em runtime. O fonte atual contém comparação científica racional inclusiva, validação de resultado/identidade no bridge e congelamento dos registros. O recibo adversarial conserva os estados anteriores e os testes afetados aprovados. Isso é uma boa cadeia de correção; não se deve apagar os defeitos históricos ou chamar a primeira versão de integralmente correta.

O congelamento previne mutação acidental no módulo. A importação não permite substituir o pack. A contraprova de mutação direta não era exploração remota do importador e não deve ser descrita assim. A reexecução detecta adulterações materiais do resultado mesmo com hash refeito, dentro dos casos aplicados.

Limites científicos e educacionais que mudam a narrativa

O satélite é didático. Agenda de luz e contatos, massas, créditos, potências, reservas e volumes lógicos são hipóteses. Não foram calculados orçamento de enlace RF, antena, propagação orbital, apontamento, térmica, degradação, erro de instrumento ou perda de pacotes. A aritmética exata evita certos erros de implementação; ela não valida as hipóteses contra uma missão real. Os 60/180 Mbit por lote não são tamanhos medidos dos JSONs MODIS.

Previsão escrita e sucesso podem revelar pistas de compreensão, mas também podem resultar de tentativa e erro ou uso da sugestão. Uma sessão deve registrar ajuda, primeira decisão de transferência, explicação, erro e abandono. Dois pilotos e seis sessões formativas podem encontrar problemas e descrever casos; não estimam efeito causal, retenção ou eficácia populacional. A visualização orbital permanece ilustração sem escala, e a finalidade educativa precisa continuar compreensível sem ela.

GLiDE 27B tem aproximadamente 52,2 GB de pesos e pico publicado de 56,4 GB em uma configuração específica; não deve ser prometido para RTX 3070/2060 Super. Os modelos compactos também exigem experimento próprio. Não há prova local de economia superior a 95%, paridade entre runtimes, classificação correta em português ou privacidade integral. O modelo não participa de energia, QA, resultado ou prova de mínimo no P0.

Gates de fechamento

1. Entrega de P&D reproduzível: preservar as correções verificadas, congelar versões e concluir PDF/ZIP com os distribuíveis regenerados, hashes e comandos executados. Um relatório antigo não aprova bytes novos.
2. Demonstração no equipamento: executar a tarefa completa em navegador real autorizado, com rede externa desligada, testar alternativa 2D, importação/exportação e origem de armazenamento. Registrar navegador, sistema, CPU/GPU/RAM, resolução e observações. Chromium sem socket neste ambiente e recusa explícita de file: no CUA não foram contornados.
3. Pesquisa humana: revisar instruções e tratamento do diário, realizar pilotos/sessões com finalidade clara, preservar resultados negativos e limitar as conclusões à amostra.
4. Candidatura: resolver elegibilidade, lista Resources, adequação ao brief, equipe, agenda e formulário. Prazo local indexado: 15/11 às 17h BRT, a confirmar; 23h59 global não substitui o corte local.
5. Expansão: só depois dos gates pertinentes, abrir novo contrato para EVI3, IA, agenda orbital ou persistência relacional. Cada um precisa de entrada, saída, oráculo e orçamento próprio.

O handoff operacional está em docs/08-HANDOFF.md. Os recibos finais conferidos cobrem DOM simulado, benchmark, build, Prisma e AB-R3A com os limites acima. O fechamento de PDF e pacote pertence à coordenação; esta revisão não antecipou essa aprovação.