Sistema de Resultados de Campeonatos (Chronosat)
Validacao em duas frentes, Alfa (interno) e Beta (com o cliente)
Sistema de Resultados de Campeonatos (Chronosat): Plano de Testes (Alfa e Beta)
| Campo | Valor |
|---|---|
| Projeto | Sistema de Resultados de Campeonatos (integração Chronosat) |
| Cliente | Sertões |
| Agência / Autor | Modulareasy |
| Documento | Plano de Testes (Alfa e Beta), companheiro do DRS |
| Data de revisão | 2026-09-18 |
Documentos da família
- DRS (resultados-chronosat), o que o sistema faz.
- Roadmap de Implementação (resultados-chronosat-roadmap), em que ordem construir e como verificar.
- Inventário de Artefatos (resultados-chronosat-inventario), tudo que precisa existir e como cada item deve ser.
- Jornadas dos Atores (resultados-chronosat-jornadas), como cada papel opera o sistema.
Este documento valida o sistema antes da entrega, em duas seções. Alfa: teste interno, um item por requisito funcional do DRS (usando o critério de aceite H1 de cada um), mais itens gerais de visual, segurança, desempenho, mobile e regressão. Beta: teste com o público, o operador e o administrador reais, um item por jornada de cada ator, mais a coleta de feedback do primeiro evento ao vivo. É a camada de validação do sistema inteiro, acima do "como verificar" que cada tarefa do Roadmap já traz embutido: o Roadmap prova que cada peça foi construída certa, este documento prova que o sistema completo funciona e está pronto para o público.
Como usar
Cada item é um card marcável. Um item Alfa só passa quando o critério (H1 do requisito, ou o critério do item geral) se confirma de fato, testado à mão ou de forma automatizada. Um item Beta só passa quando o usuário real completa a jornada ponta a ponta sem bloqueio. A entrega ao público só ocorre com a seção Alfa inteira concluída e a seção Beta observada em um evento real.
Verticais MTB e Kitesurf (validação com o primeiro pacote real, sem espera): a construção e os testes usam os dados reais já em mãos (rally); nenhum arquivo de exemplo de terceiros é aguardado. Quando o primeiro pacote real da Bike ou do Kite chegar, ele é validado no próprio teste de conexão do cadastro (conforme o Roadmap, F5-GATE e F6-GATE): no match, os testes daquela vertical ({TA-19}, {TA-41}, {TA-44}) rodam com renderização plena; na divergência estrutural (ex.: dupla com dois numerais na Bike, classificação por pontos no Kite), valida-se o fallback genérico útil e o adaptador de ingestão (ADR-012) entra como refinamento, sem bloquear os demais cards.
Alfa (testes internos)
INGEST, ingestão e cache
Cobre: RF-INGEST-001.
Como testar: publicar um evento com URLs válidas de crews, stagetimes e racetimes e observar as chamadas de rede do navegador do público.
Passa quando: o front recebe os dados sem chamar satcron.com diretamente, a resposta do servidor inclui cabeçalho de origem cruzada permitindo o domínio da página, e nenhuma chamada direta à Chronosat parte do navegador.
Cobre: RF-INGEST-002.
Como testar: disparar múltiplas requisições do público para o mesmo arquivo dentro de uma janela de 30 segundos e contar as chamadas efetivas à Chronosat.
Passa quando: todas as requisições dentro da janela são servidas do cache e a chamada à origem ocorre no máximo uma vez por minuto por arquivo.
Cobre: RF-INGEST-003.
Como testar: simular a Chronosat respondendo erro ou indisponível após uma leitura bem sucedida, e acessar a página.
Passa quando: a página exibe o último resultado válido conhecido com indicação de atualização suspensa, sem erro cru nem página em branco.
Cobre: RF-INGEST-004.
Como testar: conferir, para um competidor de numeral conhecido, se a visão consolidada reúne dados de crews, stagetimes e racetimes.
Passa quando: a visão do competidor reúne identificação, parciais, tempo do trecho e acumulado geral, todos com o mesmo numeral.
Cobre: RF-INGEST-005.
Como testar: com um evento ao vivo já com leituras bem-sucedidas, derrubar a origem (Chronosat fora do ar ou inacessível) SEM encerrar o evento no painel, e acessar a página; em seguida, consultar diretamente o banco de dados e conferir o payload bruto salvo para aquela fonte (evento, modalidade, tipo e trecho).
Passa quando: a página continua exibindo o último estado salvo no banco mesmo com a origem fora do ar e o evento ainda não encerrado, nenhum dado exibido anteriormente se perde, e a consulta ao banco mostra o payload bruto da última leitura bem-sucedida com o momento da leitura registrado.
API, leitura interna
Cobre: RF-API-001.
Como testar: chamar o endpoint de classificação geral de um evento e modalidade publicados.
Passa quando: retorna a lista de competidores ordenada pelo tempo total acumulado, cada um com numeral, tripulação, veículo, equipe, tempo total, penalidades e bônus.
Cobre: RF-API-002.
Como testar: chamar o endpoint de um trecho específico de um evento e modalidade publicados.
Passa quando: retorna a lista de competidores do trecho com tempo da especial, posições parciais e tempo total do trecho.
Cobre: RF-API-003.
Como testar: chamar o endpoint de detalhe para um competidor com parciais registradas em um trecho.
Passa quando: retorna os horários I1 a I7, os deltas tempo1 a tempo7 e as posições posI1 a posI7, omitindo os indicadores nulos.
Cobre: RF-API-004.
Como testar: carregar a página de um evento publicado e conferir os metadados recebidos.
Passa quando: retorna título e subtítulo da prova, a lista de trechos com atributos e status, as modalidades, as categorias e o estado ao vivo ou encerrado.
Cobre: RF-API-005.
Como testar: chamar o endpoint de classificação de uma categoria específica de um evento com categorias definidas.
Passa quando: retorna apenas os competidores da categoria, ordenados pelo tempo aplicável, com posição renumerada de 1 em diante.
PUB, página pública
Cobre: RF-PUB-001.
Como testar: abrir a página no celular e no desktop com um evento com classificação disponível, incluindo um competidor em abandono ou teto, num evento da vertical Series (piloto e navegador).
Passa quando: no celular cada competidor aparece como cartão com posição, numeral, tripulação, equipe e veículo, categoria, penalidades, tempo total e diferença; no desktop os mesmos dados aparecem em tabela na ordem definida; quem abandonou ou atingiu o teto exibe "Não completou".
Cobre: RF-PUB-001, RF-CONFIG-001.
Como testar: abrir a tabela (ou os cartões no celular) de um evento de cada perfil de tripulação: Series ou Petrobras (piloto e navegador), MTB (dupla), Kitesurf (solo).
Passa quando: no rally o piloto aparece em destaque com o navegador ao lado (formato "PILOTO (UF) | NAVEGADOR (UF)"); na bike os dois nomes da dupla aparecem em negrito; no kite aparece apenas o atleta solo; nenhuma vertical exibe a regra de exibição de outra.
Cobre: RF-PUB-002.
Como testar: abrir um recorte (geral, categoria ou etapa) com ao menos cinco competidores e outro com menos de cinco, num evento da vertical Series.
Passa quando: os cinco primeiros aparecem em ordem sequencial de 1º a 5º, cada lugar com posição, numeral, piloto, navegador, equipe, tempo total e diferença, refletindo o recorte selecionado; com menos de cinco, mostra os que houver na mesma ordem.
Cobre: RF-PUB-002, RF-CONFIG-001.
Como testar: abrir o pódio de um evento de cada perfil de tripulação: Series ou Petrobras (piloto e navegador), MTB (dupla), Kitesurf (solo).
Passa quando: cada lugar do pódio exibe os nomes conforme a regra da vertical (piloto e navegador no rally, os dois nomes da dupla em negrito na bike, o atleta solo no kite), coerente com {TA-10B}.
Cobre: RF-PUB-003.
Como testar: num evento com mais de uma modalidade, selecionar cada modalidade disponível.
Passa quando: a classificação, o pódio e os trechos passam a refletir apenas a modalidade selecionada.
Cobre: RF-PUB-004.
Como testar: num evento com categorias definidas, selecionar uma categoria no Geral e com um trecho selecionado.
Passa quando: a lista exibe apenas os competidores da categoria, ordenados pelo tempo aplicável, com posição renumerada de 1 em diante, e o pódio reflete os cinco primeiros da categoria.
Revisão (2026-09-17): o combinado categoria + trecho estava com um defeito (a categoria era ignorada quando havia trecho selecionado, achado no evento MTB Ibitipoca 2026); corrigido e agora coberto por teste automatizado (test/pages-route.test.ts, test/category-classification.test.ts).
Cobre: RF-PUB-005.
Como testar: num evento com trechos iniciados, selecionar um trecho e depois voltar para Geral.
Passa quando: a tabela exibe os tempos e posições do trecho selecionado, e ao selecionar Geral volta ao acumulado.
Cobre: RF-PUB-006.
Como testar: buscar pelo numeral de um competidor presente no evento.
Passa quando: a tabela destaca ou filtra esse competidor.
Cobre: RF-PUB-007.
Como testar: tocar um competidor da classificação, com e sem um trecho com parciais selecionado, incluindo um caso com posIx nulo.
Passa quando: o modal mostra equipe, veículo, categoria, posição, penalidades, tempo total e o tempo por especial SS1 a SSN; com trecho de parciais, mostra também I1 a I7 com deltas e posições, ocultando as sem indicador; o modal fecha sem recarregar a página.
Cobre: RF-PUB-008.
Como testar: abrir a página com um evento com documentos publicados e com um evento sem nenhum; publicar um documento com a página aberta em evento ao vivo, sem dar F5.
Passa quando: a barra aparece logo abaixo da faixa de etapas, antes do pódio e dos filtros, com um chip por documento na ordem do painel; sem documentos, a barra não aparece mas o container permanece vazio no HTML; o documento publicado ao vivo aparece no ciclo seguinte do refresh, sem recarregar. Coberto por test/render-documents.test.ts + test/pages-route.test.ts (suíte completa 1265/1265).
Cobre: RF-PUB-009.
Como testar: permanecer na página de um evento ao vivo e depois marcar o evento como encerrado.
Passa quando: os dados se atualizam automaticamente a cada cerca de 30 segundos com o indicador "ao vivo"; ao encerrar, o indicador muda para "encerrado" e a atualização automática para.
Cobre: RF-PUB-010.
Como testar: abrir a página de um evento de cada uma das quatro verticais (Series, Petrobras, MTB, Kitesurf) e comparar lado a lado.
Passa quando: a cor de destaque é o laranja oficial E96409 em Series e em Petrobras (que compartilham a cor e se distinguem pela marca), o rosa oficial E40E7F em MTB e o verde oficial 88BD23 em Kitesurf, cada uma sobre o fundo escuro comum conforme o Ap.4 do DRS, E nenhuma das quatro verticais exibe a marca ou a capa de outra.
Cobre: RF-PUB-011.
Como testar: abrir a página de um evento ao vivo e de um evento encerrado.
Passa quando: o cabeçalho exibe a barra na cor da marca, o logotipo oficial, a navegação e o selo "Ao Vivo" pulsante quando ao vivo; quando encerrado, o selo não pulsa.
Cobre: RF-PUB-012.
Como testar: abrir a página de um evento publicado e trocar de aba de modalidade.
Passa quando: o hero mostra nome e subtítulo do evento, as abas de modalidade com contador de competidores, a faixa de etapas com a visão Geral em destaque e cada trecho com nome, distância e estado (incluindo o Prólogo), e o indicador "atualizado há X"; ao trocar de aba, a página reflete a modalidade escolhida.
Cobre: RF-PUB-013.
Como testar: aplicar e limpar um filtro de categoria e uma busca.
Passa quando: o contador de competidores reflete a quantidade exibida no recorte ativo.
Cobre: RF-PUB-014.
Como testar: rolar até o fim de qualquer página de resultados publicada.
Passa quando: o rodapé exibe "Cronometragem por Chronosat" e "Desenvolvido por Modulareasy".
Cobre: RF-PUB-015.
Como testar: abrir a home de uma vertical (/<vertical>) com um ou mais eventos publicados, ao vivo e arquivados, e conferir a URL de um evento no padrão /<vertical>/<ano>/<evento>.
Passa quando: a home da vertical mostra a capa com a identidade do esporte, o evento ao vivo sinalizado em destaque quando houver, e a lista das edições por ano; escolher uma leva à página daquele evento nesse endereço; nenhuma outra vertical aparece nessa home.
Cobre: RF-PUB-016.
Como testar: abrir a raiz do subdomínio de resultados com as quatro verticais cadastradas.
Passa quando: a raiz mostra a lista dos sites das verticais (nome, marca e cor de cada uma) na ordem configurada, ao escolher uma o público é levado à home daquela vertical, e a home global não mistura classificações nem eventos de esportes diferentes.
REGRA, regras de interpretação dos dados
Cobre: RF-REGRA-001.
Como testar: usar um competidor com penais igual a " *" de um JSON real.
Passa quando: a célula de penalidades exibe o traço de ausência e não o texto literal *.
Cobre: RF-REGRA-002.
Como testar: usar um competidor com posI5 nulo num JSON real e abrir a janela de parciais.
Passa quando: a posição da parcial 5 não aparece e as demais parciais com posição aparecem normalmente.
Cobre: RF-REGRA-003.
Como testar: num evento com prólogo realizado, conferir o acumulado geral.
Passa quando: o tempo do prólogo não é somado ao tempo total, e o prólogo permanece consultável como trecho próprio.
Cobre: RF-REGRA-004.
Como testar: usar um competidor com tempo de especial 9000.00 ou tempo total 27000.00 de um JSON real.
Passa quando: o sistema exibe "Não completou" no lugar do número e mantém a posição conforme a ordenação aplicável.
Cobre: RF-REGRA-005.
Como testar: usar um competidor com L igual a 25680.00 de um JSON real.
Passa quando: o sistema interpreta o valor como segundos desde a meia-noite (07:08:00) para auditoria, sem confundir com tempo de prova.
Cobre: RF-REGRA-006.
Como testar: usar um competidor com _status igual a O de um JSON real.
Passa quando: esse competidor não aparece na página pública e os demais aparecem normalmente.
PAINEL, painel de gestão
Cobre: RF-PAINEL-001 na sua primeira versão (login único), como entregue em F3-01.
Como testar: tentar acessar uma rota do painel sem login, e depois com a credencial válida.
Passa quando: sem credencial o visitante é barrado; com a credencial válida, acessa as telas de gestão.
Nota: este card cobre a primeira versão (login único). A autenticação por conta nominal com papel (RF-PAINEL-001 revisado) é coberta por {TA-48B}; a evolução ainda não foi implementada.
Cobre: RF-PAINEL-001 revisado, RNF-SEG-002, RNF-SEG-005.
Como testar: entrar com uma conta de administrador e com uma de operador; tentar com senha errada; tentar com uma conta desativada; tentar uma rota do painel sem sessão.
Passa quando: cada conta ativa entra e a sessão carrega o papel certo; senha errada e conta desativada são recusadas; visitante sem sessão é barrado; nenhuma senha trafega ou fica guardada em texto puro (só hash).
Cobre: RF-PAINEL-002.
Como testar: iniciar um novo campeonato e selecionar vertical e nome.
Passa quando: o sistema registra a vertical (com sua cor e marca) e o nome, e habilita o passo 2.
Nota (2026-07-05, S64): provado ponta a ponta: vertical lida do banco (select real), rascunho criado no banco, redirecionamento 302 ao passo 2, passo 2 mostra o perfil da vertical escolhida, validações rejeitam campos vazios, entrada maliciosa (XSS) escapada, 586/586 testes verdes.
Cobre: RF-PAINEL-003.
Como testar: colar de uma vez o bloco inteiro de URLs de um evento válido (crews, racetimes e stagetimes de todas as modalidades e trechos) e acionar "testar conexão"; repetir com uma URL inválida ou inacessível no meio do bloco; incluir um arquivo de trecho ainda não iniciado (que retorna vazio).
Passa quando: o sistema extrai e classifica automaticamente cada URL pelo padrão do nome do arquivo, sem o operador separar campo a campo, e a pré-visualização mostra a contagem de modalidades, trechos e competidores encontrados; com URL inválida, exibe qual falhou sem publicar; o arquivo de trecho vazio é aceito e não bloqueia o teste.
Cobre: RF-PAINEL-004.
Como testar: concluir os passos 1 e 2 com teste de conexão bem sucedido e publicar.
Passa quando: o evento fica disponível na página pública da vertical correspondente, no estado inicial configurado.
Nota (2026-07-05, S66): provado com smoke visual real (desktop 1280 e mobile 390): evento de teste publicado apareceu na página pública e como 2º card, AO VIVO, na home da vertical, ao lado do evento real, sem regressão; deletado nominalmente após o smoke.
Cobre: RF-PAINEL-005.
Como testar: marcar um campeonato publicado como encerrado, e depois como ao vivo novamente.
Passa quando: ao encerrar, a página para a atualização automática e exibe o indicador de encerrado; ao voltar para ao vivo, a atualização automática retorna.
Cobre: RF-PAINEL-006.
Como testar: adicionar um PDF por link e outro por upload de arquivo, cada um com título, e depois remover um.
Passa quando: cada PDF adicionado por link ou por upload aparece na central de downloads pública; ao remover, deixa de aparecer.
Cobre: RF-PAINEL-007.
Como testar: ocultar um competidor exibido na página e depois reexibi-lo.
Passa quando: oculto, ele deixa de aparecer na página pública; reexibido, volta a aparecer.
Cobre: RF-PAINEL-008.
Como testar: abrir o painel com um ou mais campeonatos cadastrados.
Passa quando: a lista mostra vertical, nome, estado (rascunho, ao vivo, encerrado) e as ações de editar, publicar, alternar estado e gerenciar PDFs.
Cobre: RF-PAINEL-009.
Como testar: encerrar um evento ao vivo e, em seguida, simular a Chronosat retirando os dados da origem.
Passa quando: o sistema grava o resultado final num arquivo permanente e a página continua exibindo esse arquivo mesmo com a origem fora do ar, permanecendo acessível no endereço por evento e ano e listada na home.
Cobre: RF-PAINEL-010.
Como testar: cadastrar pelo assistente um evento de uma edição passada, a partir de URLs ou arquivos históricos.
Passa quando: a página daquela edição é gerada e arquivada no endereço por evento e ano, e passa a aparecer na home junto às demais.
Cobre: RF-PAINEL-011.
Como testar: com um administrador, criar uma conta de operador com senha inicial e confirmar que ela entra; mudar o papel de uma conta e confirmar que o acesso muda; desativar uma conta e confirmar que ela não entra mais e que o histórico dela permanece, depois reativá-la; redefinir a senha de uma conta e confirmar que a nova vale e a antiga não.
Passa quando: cada operação (criar, mudar papel, desativar/reativar, redefinir senha) tem o efeito esperado no acesso da conta, sem apagar o histórico, e nenhuma senha é exibida nem guardada em texto puro; não há autocadastro público.
Cobre: RF-PAINEL-012, RNF-SEG-004.
Como testar: com um administrador, executar ações sensíveis (login, criar conta, mudar papel, desativar conta, redefinir senha) e depois abrir a tela de auditoria; tentar (sem sucesso) editar um registro.
Passa quando: cada ação gera um registro com quem fez, o que fez, sobre o que e quando; a tela lista os registros do mais recente ao mais antigo; a redefinição de senha registra a troca sem o valor da senha; o log é imutável (não editável pelo painel).
Cobre: RF-PAINEL-001 revisado, RF-PAINEL-011, RF-PAINEL-012, RF-PAINEL-013, RNF-SEG-003.
Como testar: entrar com uma conta de papel operador e tentar abrir a tela de gestão de contas, a de auditoria e a de monitor de status (por menu e pela rota direta); entrar com uma conta de papel administrador e abrir as mesmas telas.
Passa quando: o operador não vê os itens de menu Contas, Auditoria e Status das páginas e é barrado ao tentar as rotas diretas; o administrador vê e acessa as três telas; nenhuma tela de gestão de campeonatos fica vedada ao administrador.
Cobre: RF-PAINEL-013.
Como testar: com um administrador, abrir a tela de monitor de status e conferir a lista curada de rotas com o código de resposta de cada uma; provocar uma rota no ar e confirmar que aparece 200; apontar (ou simular) uma rota inexistente ou fora do ar e confirmar que aparece com o código de erro (por exemplo 404 ou 503) sinalizado; acionar "verificar de novo" e confirmar que os códigos são reconsultados; conferir que nenhuma rota por evento aparece na lista; tentar (sem sucesso) abrir a tela com um papel operador.
Passa quando: a tela mostra a lista curada de rotas com um código HTTP por linha; uma rota no ar aparece como 200 e uma com erro aparece com o código do erro em destaque; "verificar de novo" reconsulta; a lista não inclui nenhuma rota por evento (só as principais curadas); o operador é barrado; e a verificação de uma rota que não responde é reportada como erro sem derrubar a tela.
Cobre: RF-PAINEL-014.
Como testar: no hub do evento (passo-2), marcar e desmarcar as 11 colunas ocultáveis, incluindo Parciais; verificar a tabela pública do recorte de Trecho com Parciais oculta e com o evento ao vivo (dados chegando aos poucos); conferir o seletor de visualização com Parciais oculta e visível.
Passa quando: desmarcar uma coluna a esconde na tabela pública sem afetar as essenciais; Penalidades, Bônus e Parciais nunca auto-ocultam mesmo vazias; com Parciais oculta, o preset "Parciais" some do seletor e o padrão passa a "completo"; evento existente sem a config nasce com Parciais visível.
Prova: suite completa 1272 de 1272 (test/render-table-colunas-ocultas.test.ts, test/render-table-auto-ocultar-vazias.test.ts, test/eventos-colunas-route.test.ts), medida diretamente antes desta publicação.
CONFIG, multi-evento e multi-vertical
Cobre: RF-CONFIG-001.
Como testar: consultar e ajustar, para uma vertical existente, todos os campos do perfil: cor de destaque, marca, capa da home (título, subtítulo, imagem), rótulos da hierarquia (modalidade, categoria, trecho), regra de exibição da tripulação e ordem na home global; em seguida adicionar uma vertical nova só por configuração.
Passa quando: cada campo do perfil é visível e editável, a mudança reflete no site daquela vertical sem novo deploy, e uma vertical nova pode ser adicionada sem alteração de código.
Cobre: RF-CONFIG-002.
Como testar: publicar um evento em Rally e outro em MTB ao mesmo tempo e abrir a página de cada vertical.
Passa quando: cada vertical exibe seu próprio evento com sua identidade, sem interferência entre elas.
Cobre: RF-CONFIG-003.
Como testar: configurar um evento com uma modalidade só (por exemplo só carros) e outro evento com várias modalidades diferentes das do primeiro (por exemplo caminhão e production), com URLs próprias em cada, e alternar o filtro de modalidade em cada evento; conferir o rótulo de cada modalidade vindo de crews e o caso de ajuste manual do rótulo pelo operador.
Passa quando: o número de modalidades nunca é fixo (um evento com uma só e outro com várias funcionam igualmente), cada modalidade guarda suas URLs de crews, racetimes e stagetimes por trecho com seu rótulo, o rótulo reflete o crews ou o ajuste do operador quando aplicável, e o sistema lê a fonte correta conforme o filtro.
Cobre: RF-CONFIG-004.
Como testar: com a vertical Series já publicada e no ar, cadastrar a vertical Petrobras do zero pelo painel (perfil próprio de RF-CONFIG-001) e um evento dela pelo assistente, sem tocar em código nem duplicar o sistema.
Passa quando: o site da vertical Petrobras fica no ar com identidade, home e eventos próprios, nenhuma linha de código foi alterada ou copiada, e a vertical Series continua funcionando normalmente e sem nenhuma mistura de identidade entre as duas.
Cobre: RF-CONFIG-005.
Como testar: publicar um evento e conferir o endereço gerado no padrão resultados.sertoes.com.br/<vertical>/<ano>/<evento>; publicar um segundo evento da mesma vertical no mesmo ano com nome diferente e conferir que o endereço distingue os dois.
Passa quando: cada evento recebe um endereço permanente com o nome do evento na slug que não muda depois, dois eventos da mesma vertical no mesmo ano têm endereços distintos, e a home e as páginas da vertical no site apontam para esse endereço.
Prova (S72 2026-07-06): test/f3-12-endereco-permanente.test.ts, 9 casos (C1 endereço no padrão mais o passo 3 do assistente; C2 comportamental de publicar, encerrar e reativar; C2 estrutural varrendo a lista de módulos exportados em busca de qualquer caminho de mutação da identidade do evento; C3 trilha de navegação e cabeçalho apontando para o endereço canônico; C4 fumaça), somados às provas de colisão já existentes em test/eventos-crud e test/eventos-route. 739 de 739 testes node:test passando.
Cobre: RF-CONFIG-006.
Como testar: com um operador ou administrador autenticado, abrir "Textos do site", alterar um texto removível e salvar; salvar em branco um texto removível; salvar em branco um texto não removível; usar "restaurar padrão" num campo alterado; conferir a página pública correspondente após cada ação; tentar salvar uma chave forjada fora do catálogo; testar um valor com script embutido e uma URL não http(s) num campo de link; abrir a rota sem sessão.
Passa quando: o texto alterado aparece na página pública no carregamento seguinte sem reinício; o texto removível salvo em branco some da página; o texto não removível salvo em branco volta ao padrão; "restaurar padrão" apaga o desvio e volta ao valor de fábrica; a chave forjada é ignorada sem quebrar a rota; o valor com script aparece escapado na página pública, nunca executável; a URL não http(s) não entra no link; sem sessão, a rota redireciona para o login; e a comparação byte a byte dos renders alterados contra o comportamento anterior, sem nenhum texto salvo, não muda nada (paridade 1:1).
Prova (2026-09-16): test/textos.test.ts e test/textos-route.test.ts; suite completa 1268 de 1268 node:test passando e tsc --noEmit limpo; gates .claude/gates/plan/f3-textos-do-site.gate, .claude/gates/qa/f3-textos-do-site.gate e .claude/gates/review/f3-textos-do-site.gate (planner APPROVED, qa PASS, review APPROVED); baseline vermelho confirmado contra a branch main antes do merge (código novo ausente); script de paridade 1:1 comparando main e branch sem override, zero diferença textual.
MEDIR, medição de audiência
Cobre: RF-MEDIR-001.
Como testar: com os dois destinos ligados e com identificador, pedir a home global, a home de uma vertical e a página de um evento, e contar as marcações no documento servido; depois pedir a tela de entrada do painel e uma tela interna do painel e contar de novo; por fim desligar um destino e repetir.
Passa quando: cada página pública traz exatamente uma etiqueta da plataforma de análise e exatamente um pixel da plataforma de anúncios, nenhuma tela do painel traz qualquer das duas, e com o destino desligado ou o identificador em branco aquela marcação não aparece em página alguma.
Resultado: PASS (2026-09-19). Placar do par invertido de AUD-00 fechou: as 3 páginas públicas medidas, painel 0, refresh 0; cada página com exatamente 1 etiqueta e 1 pixel.
Cobre: RF-MEDIR-002.
Como testar: entrar como administrador, ligar um destino, informar o identificador e gravar; recarregar a tela; gravar de novo com o campo de credencial em branco; consultar a auditoria; tentar abrir a rota com uma conta de operador.
Passa quando: a página pública passa a injetar a marcação sem reinício, a tela devolve a credencial apenas mascarada, gravar com o campo em branco preserva a credencial anterior, a auditoria registra quem gravou e quando sem o valor, e o operador é barrado.
Resultado: PASS (2026-09-19). Tela /painel/integracoes no ar, credencial sempre mascarada, operador barrado (achado do QA BUG-01 corrigido antes do fechamento).
Cobre: RF-MEDIR-003.
Como testar: em janela anônima, abrir a página de um evento e executar as sete ações (visualizar, trocar modalidade, trocar trecho, trocar categoria, buscar, abrir parciais, abrir documento), acompanhando o relatório de tempo real do destino de análise.
Passa quando: chegam exatamente os sete nomes de evento fichados no Ap.6 do DRS, todos carregando o parâmetro de site, e o evento de troca de filtro chega mesmo com a navegação acontecendo logo em seguida.
Resultado: PASS (2026-09-19). Os 7 eventos (troca_de_trecho, troca_de_modalidade, troca_de_categoria, busca_de_competidor, parciais_abertas, documento_oficial_aberto, atualizacao_ao_vivo) confirmados no relatório de Tempo real do GA4. Ressalva: o teste headless não prova o evento que dispara no clique que também navega (a página troca antes do teste conseguir observar a chamada); a prova válida é o Tempo real do GA4 durante a navegação manual, não a suíte automatizada.
Cobre: RF-MEDIR-004.
Como testar: deixar a página de um evento ao vivo aberta por mais de dez ciclos de atualização, observando o contador de visualizações dos dois destinos e, ao fim, a série de acessos interna daquele período.
Passa quando: o contador de visualizações não cresce durante os ciclos, exatamente um evento de atualização ao vivo foi enviado por carregamento de página, e a série interna tem um registro do tipo atualização para cada ciclo ocorrido.
Resultado: PASS (2026-09-19). Corrigido no QA BUG-02 (evento do GA4 sobrevive à navegação do ao vivo); confirmado sem visualização nova nos ciclos de atualização.
Cobre: RF-MEDIR-005.
Como testar: com a credencial configurada, abrir uma página pública e conferir na ferramenta do destino de anúncios a chegada pelos dois caminhos e a qualidade da correspondência; inspecionar a linha gravada na série de acessos; medir o tempo de resposta da página com e sem o envio ligado; apagar a credencial e repetir o acesso.
Passa quando: a visualização chega pelos dois caminhos com o mesmo identificador de evento e é contada uma única vez, o evento é aceito em vez de descartado por falta de correspondência, nenhuma das três informações de correspondência (endereço de rede, assinatura do navegador, identificador de navegador do pixel) aparece em coluna alguma da série, o tempo de resposta não muda com o envio ligado, e sem credencial nenhum envio pelo servidor é tentado e nada quebra.
Resultado: PASS (2026-09-19). CAPI confirmada: 2 PageView na condição "Servidor, Processado" com identificador de evento no Eventos de Teste da Meta; nenhum dado de correspondência gravado na série.
Cobre: RF-MEDIR-006.
Como testar: abrir a página de um evento, uma home de vertical, a home global e um documento oficial, e ler as linhas nascidas na série de acessos, campo a campo.
Passa quando: cada acesso gerou exatamente uma linha com evento, vertical, tipo de página, rota, recorte, instante, dia e hora locais, dispositivo, navegador, origem de referência, visitante do dia, tipo de acesso, momento e proveniência; nenhuma coluna guarda endereço de rede ou assinatura de navegador em texto legível; a abertura do documento gerou registro do tipo documento cuja rota é o caminho do arquivo; e as duas linhas de home nasceram com o momento nulo, sem erro.
Resultado: PASS (2026-09-19). 696 acessos gravados na série na primeira hora do ar, 0 descartados.
Cobre: RF-MEDIR-007, RNF-PERF-003.
Como testar: rodar a mesma carga de duzentas requisições por segundo durante trinta segundos sobre a página do mesmo evento, uma vez com o registro ligado e outra com ele desligado, comparando o percentil noventa e cinco; depois forçar o teto da fila e observar o contador de descarte.
Passa quando: a piora do percentil noventa e cinco fica em no máximo dez por cento, nenhuma requisição falha, e a fila cheia descarta contando, sem erro ao público.
Resultado: PASS (2026-09-19). Carga de prova: p95 1586 ms com medição ligada contra 2191 ms de referência sem medição (melhora, não piora), 0 erro em 531 pedidos (docs/carga/).
Cobre: RF-MEDIR-008, RNF-PRIV-001.
Como testar: fazer dois acessos do mesmo dispositivo no mesmo dia e comparar o identificador; adiantar a virada do dia e repetir; inspecionar as colunas da série e os cookies do navegador; rodar também uma importação de arquivo antigo e conferir que ela usou um segredo derivado do dia do arquivo e não o do dia corrente.
Passa quando: os dois acessos do mesmo dia trazem o mesmo identificador, o dia seguinte traz identificador diferente para o mesmo dispositivo, nenhuma coluna permite recuperar o endereço de rede, o sistema não criou cookie algum para esse fim, e o segredo usado na importação foi descartado ao fim dela como o do dia vivo.
Resultado: PASS (2026-09-19). Implementado em src/lib/visitante-dia.ts, revisão de código aprovada; nenhuma coluna grava endereço de rede.
Cobre: RF-MEDIR-009.
Como testar: disparar, contra a raiz e contra a home de uma vertical (as rotas que o monitor interno verifica), uma verificação de saúde, uma requisição da própria máquina, uma requisição com assinatura de agente automatizado reconhecido e uma requisição com sessão de painel ativa; em seguida um acesso comum do público, vindo de fora, exatamente nas mesmas duas rotas.
Passa quando: nenhuma das quatro gerou linha, cada um dos dois acessos comuns gerou exatamente uma linha (ou seja, a exclusão é por origem e não por rota, e não apagou audiência real da raiz nem da home), e nenhum número da tela de audiência nem de qualquer exportação inclui as quatro.
Resultado: PASS (2026-09-19). Corrigido no QA BUG-03 (carga interna identificada por X-Real-IP); exclusão por origem confirmada sem apagar audiência real da raiz nem da home.
Cobre: RF-MEDIR-010.
Como testar: com a janela no valor de fábrica (zero), semear registros antigos e rodar a limpeza diária, conferir que nada foi removido; ajustar a janela pela configuração para um valor maior que zero, semear registro dentro e fora dela, rodar a limpeza de novo e conferir o que sobrou.
Passa quando: com a janela em zero nenhum registro é removido por idade; com a janela ajustada para um valor maior que zero, só os registros fora dela somem, nenhum de dentro é removido, e o valor novo vale na execução seguinte sem novo deploy.
Resultado: PASS (2026-09-19). Rotina em src/lib/retencao-acesso.ts; janela de retenção configurável em src/config/audiencia.ts, valor de fábrica zero (sem prazo), 24 meses testado como exemplo de valor configurado, sem deploy.
Cobre: RF-MEDIR-011.
Como testar: com um evento de dados reais, abrir a tela de audiência, escolher o evento e conferir bloco a bloco contra a consulta direta à série; repetir o acesso com uma conta de operador e com uma de administrador; observar os recursos carregados pela tela.
Passa quando: aparecem pessoas e acessos, série por dia, série por hora com o pico destacado, ao vivo e repetição, dispositivo, navegador, tipo de página e origem do registro, todos conferindo com a consulta direta; a nota de que único é do dia acompanha o número de pessoas; a tela abre para os dois papéis; e nenhuma biblioteca externa de gráfico é carregada.
Resultado: PASS (2026-09-19). /painel/audiencia no ar com dado real do evento, gráficos em src/lib/grafico-svg.ts (sem biblioteca externa), aberto para os dois papéis.
Cobre: RF-MEDIR-012.
Como testar: gerar acessos, abrir a tela de audiência e observar o bloco de tempo presente sem recarregar a página; depois esperar a janela esvaziar e observar de novo.
Passa quando: o bloco mostra as pessoas dos últimos cinco minutos, as páginas e recortes em uso e os acessos de atualização, atualiza sozinho com a tela aberta, e com a janela vazia mostra zero em vez de erro ou tela quebrada.
Resultado: PASS (2026-09-19). Bloco do agora no ar em /painel/audiencia, atualização automática confirmada, janela vazia mostra zero.
Cobre: RF-MEDIR-013.
Como testar: semear acessos com referências de origens distintas (rede de fotos, rede social, mensageiro, domínio do cliente, buscador, sem referência e um domínio qualquer), mais buscas e aberturas de documento; abrir a tela.
Passa quando: a origem aparece agrupada exatamente nos sete grupos nominais, com a ausência de referência caindo em direto; as buscas mais feitas, os documentos mais abertos e o ranking de modalidades, trechos e categorias aparecem com contagem; e nenhum texto de busca aparece ligado a um identificador de visitante.
Resultado: PASS (2026-09-19). Sete grupos de origem confirmados em src/lib/render-audiencia.ts; nenhuma busca ligada a visitante.
Cobre: RF-MEDIR-014.
Como testar: com dois eventos semeados, incluindo ao menos um visitante de acesso único no dia, abrir a comparação e a distribuição de permanência.
Passa quando: os dois eventos aparecem lado a lado com as mesmas métricas e a mesma régua, a comparação aceita ao menos dois eventos, a permanência é apresentada com o rótulo de aproximada, e o visitante de acesso único entra na distribuição sem quebrar o cálculo.
Resultado: PASS (2026-09-19). Comparação entre eventos e permanência aproximada confirmadas na revisão de código aprovada da onda.
Cobre: RF-MEDIR-015.
Como testar: com um evento selecionado, exportar os dois arquivos, somar as colunas e confrontar com os totais da tela; mudar o recorte na tela e exportar de novo; abrir os arquivos numa planilha.
Passa quando: os totais dos arquivos conferem com os da tela, o recorte escolhido vale no arquivo, e os arquivos abrem em planilha com a acentuação correta.
Resultado: PASS (2026-09-19). Corrigido no code review (src/lib/csv-audiencia.ts sem fórmula), totais do arquivo conferindo com a tela.
Cobre: RF-MEDIR-016.
Como testar: importar um arquivo de registro do servidor web, conferir no painel; importar exatamente o mesmo arquivo uma segunda vez e comparar a contagem linha a linha; escolher no arquivo dois acessos legítimos e distintos do mesmo visitante no mesmo dia e conferir que os dois existem na série; procurar na série por agentes automatizados conhecidos do arquivo.
Passa quando: os acessos do período aparecem marcados como vindos do registro do servidor, a segunda importação não aumenta a contagem em uma única linha (barrada pelo índice de proveniência, arquivo mais resumo da linha), os dois acessos legítimos do mesmo visitante continuam sendo duas linhas, nenhum agente automatizado reconhecido entrou, e o painel exibe lado a lado quanto veio de cada origem.
Resultado: PASS (2026-09-19). 51.248 linhas importadas do registro do servidor (10 a 18 de setembro); reimportar o mesmo arquivo soma 0 linhas novas (índice de proveniência confirmado).
Cobre: RF-MEDIR-017.
Como testar: com as duas chaves no valor de fábrica, abrir as três páginas públicas e conferir o aviso e o vínculo; esvaziar a chave do texto pela tela de textos do painel e abrir de novo, sem novo deploy; restaurar e esvaziar apenas a chave do endereço, abrindo de novo; abrir também as telas do painel.
Passa quando: o aviso aparece no rodapé das páginas públicas com vínculo para a política de privacidade do cliente confirmada no ADR-019, some inteiro quando a chave do texto é esvaziada, continua visível sem vínculo quando só a do endereço é esvaziada, e nunca aparece em tela do painel.
Resultado: PASS (2026-09-19). ADR-019 confirmado; catálogo de textos a 41 chaves (duas para o aviso); aviso e vínculo presentes no rodapé público (src/lib/render-footer.ts), texto vazio remove o aviso inteiro, endereço vazio mantém o aviso sem vínculo, ausente no painel.
Gerais Alfa
Cobre: RF-CONFIG-004, RF-CONFIG-002, ADR-010, transversal ao módulo CONFIG.
Como testar: com a vertical Series publicada e um evento dela ao vivo, cadastrar a vertical Petrobras do zero apenas por configuração (perfil, sem alteração de código) e publicar um evento dela em paralelo; navegar entre os dois sites e o painel único.
Passa quando: o site da Petrobras nasce com identidade, home e regra de exibição próprias, nenhuma linha de código foi alterada ou copiada, os dois eventos convivem sem interferência (nenhum dado ou identidade de uma vertical vaza para a outra), e o operador administra as duas no mesmo painel com um único login.
Cobre: ADR-012, RF-INGEST-004, RF-INGEST-005, transversal.
Como testar: alimentar o sistema com um arquivo de teste contendo um campo desconhecido (fora do contrato do Ap.1), um arquivo com um campo esperado ausente, e um arquivo com mais parciais (IX) do que o usual; em seguida, alimentar com um pacote estruturalmente divergente do contrato conhecido (ex.: um formato de tripulação diferente do esperado).
Passa quando: nos três primeiros casos a página não quebra, exibe o que existe (o campo desconhecido é ignorado na tela mas preservado no banco; o campo ausente apenas omite o elemento; parciais a mais aparecem normalmente pelo padrão de nome); no caso do pacote divergente, o teste de conexão aponta ao operador exatamente o que divergiu, o dado é armazenado mesmo assim, e a página exibe uma tabela genérica sinalizada em vez de quebrar ou renderizar errado.
Cobre: RF-INGEST-003.
Como testar: simular a Chronosat indisponível já no primeiro acesso a um evento recém-publicado, antes de qualquer leitura bem-sucedida (sem cache ainda formado).
Passa quando: a página exibe um estado de "aguardando dados", nunca um erro cru nem uma página em branco.
Cobre: transversal (RF-PUB, Ap.4, Ap.5).
Como testar: abrir a página no celular (prioridade) e no desktop, para um evento de cada vertical, e conferir tela a tela: cabeçalho, hero, pódio, filtros, tabela ou cartões, modal de detalhe, central de documentos, rodapé, comparando com o protótipo aprovado.
Passa quando: todas as seções aparecem corretas, legíveis e com a identidade da vertical, em celular e desktop, sem elemento cortado, sobreposto ou quebrado.
Cobre: RNF-SEG-001, RF-PAINEL-001.
Como testar: tentar acessar o painel sem login; tentar acessar as URLs da Chronosat diretamente pelo navegador do público.
Passa quando: o painel exige autenticação em toda rota de gestão, e o público não consegue acessar satcron.com diretamente nem qualquer tela do painel.
Cobre: RNF-PERF-001, RNF-PERF-002, RNF-ESC-001, RF-INGEST-002.
Como testar: medir o carregamento da primeira tela útil no celular durante um pico simulado de acessos, e confirmar que as leituras da origem não excedem uma por minuto por arquivo.
Passa quando: a página carrega rápido mesmo sob pico, servindo do cache, e a Chronosat recebe no máximo uma chamada por minuto por arquivo.
Cobre: RNF-RESP-001.
Como testar: abrir todas as telas públicas no celular, incluindo a virada da tabela em cartões e o empilhamento do pódio de cinco lugares.
Passa quando: todas as telas funcionam corretamente no celular, com a tabela em cartões e o pódio empilhado em ordem de 1 a 5, e continuam corretas no desktop.
Cobre: transversal.
Como testar: trocar de modalidade, de categoria e de trecho em sequência, várias vezes, e conferir que nenhuma combinação anterior quebra ou apresenta dado de outra combinação.
Passa quando: a troca de modalidade, categoria ou trecho nunca deixa dado residual de outro recorte nem quebra a página.
Cobre: RNF-PERF-003, RF-MEDIR-007, RNF-PERF-001.
Como testar: medir a página de um evento ao vivo sob duzentas requisições por segundo durante trinta segundos, duas vezes contra o mesmo estado e o mesmo dado, uma com o registro de audiência ligado e outra com ele desligado; registrar o percentil noventa e cinco das duas passadas, a taxa de erro e o contador de descarte da fila ao fim.
Passa quando: a piora do percentil noventa e cinco fica em no máximo dez por cento, nenhuma requisição falha em qualquer das duas passadas, e o contador de descarte foi lido e registrado (zero, ou um número conhecido e explicado).
Cobre: o uso real do sistema pelas jornadas de cada papel (sanity de uso).
Como testar: percorrer cada jornada de cada papel usando a ferramenta de verdade, não apenas abrir as telas: completar o fluxo do início ao resultado, conferir tabelas com dado real, botões que executam e formulários que persistem.
Passa quando: toda jornada de todo papel completa do início ao resultado, sem elemento quebrado.
Cobre: o grafo de navegação de toda tela alcançada nas jornadas.
Como testar: de cada tela em que se cai, encontrar o caminho de volta pela própria interface (trilha, botão voltar da aplicação, menu ou link de origem).
Passa quando: nunca é preciso o voltar do navegador nem redigitar a URL para retornar, e nenhum item de menu leva a "sem permissão" para o próprio papel.
Cobre: a autonomia de cada papel conforme o RBAC e o DRS.
Como testar: com cada papel, executar criar, ler, atualizar e apagar em tudo que a especificação diz que ele pode, incluindo o super admin nas estruturas que são responsabilidade dele.
Passa quando: cada papel realiza todo o CRUD previsto e nada que a especificação libera aparece bloqueado.
Beta (testes com o cliente)
Público
Cobre: a jornada Acompanhar a classificação ao vivo (documento de Jornadas).
Quem testa: usuário real do público, pelo celular.
Como validar: o usuário entra pelo site da vertical (a home do esporte) ou direto no endereço do evento, e acompanha a classificação se atualizando sozinha durante um evento ao vivo.
Passa quando: completa sem bloqueio, confirma que chegou à página certa a partir do site da vertical, e confirma que a classificação faz sentido e se atualiza sem precisar recarregar.
Cobre: a jornada Trocar de modalidade.
Quem testa: usuário real do público.
Como validar: o usuário alterna entre as abas de modalidade do evento.
Passa quando: completa sem bloqueio e confirma que cada aba mostra a modalidade correta com o número certo de competidores.
Cobre: a jornada Ver o pódio.
Quem testa: usuário real do público.
Como validar: o usuário localiza e interpreta o pódio dos cinco primeiros de um recorte.
Passa quando: completa sem bloqueio e confirma que reconhece os cinco primeiros na ordem correta.
Nota (2026-07-04): pódio por recorte selecionado (categoria, etapa) agora tecnicamente no ar (F2-06 entregue); falta a validação Beta com usuário real do papel Público para fechar este item, que exige alguém de fora testando a jornada, não só a capacidade técnica confirmada no Alfa.
Cobre: a jornada Filtrar por categoria ou trecho e buscar um competidor.
Quem testa: usuário real do público.
Como validar: o usuário filtra por categoria, seleciona um trecho e busca um competidor pelo numeral.
Passa quando: completa sem bloqueio e confirma que os resultados batem com o filtro escolhido em cada caso.
Cobre: a jornada Ver o detalhe de um competidor.
Quem testa: usuário real do público.
Como validar: o usuário toca um competidor e explora o modal de detalhe, com e sem trecho selecionado.
Passa quando: completa sem bloqueio e confirma que os dados do modal são claros e o fechamento não recarrega a página.
Cobre: a jornada Baixar um documento oficial.
Quem testa: usuário real do público.
Como validar: o usuário localiza a barra de documentos oficiais logo abaixo da faixa de etapas e baixa um PDF disponível.
Passa quando: completa sem bloqueio e confirma que o arquivo baixado é o esperado.
Cobre: a home da vertical (arquivo por ano) e o endereço permanente por vertical, ano e evento.
Quem testa: usuário real do público.
Como validar: o usuário abre a home de uma vertical (o site do esporte) e navega até um evento arquivado de uma edição anterior.
Passa quando: completa sem bloqueio e confirma que a página arquivada mostra o resultado final congelado, e que a home lista as edições por ano daquela vertical.
Cobre: a home global enxuta, RF-PUB-010, RF-PUB-015, RF-PUB-016.
Quem testa: usuário real do público.
Como validar: o usuário parte da home global (a raiz do subdomínio) ou de um link externo, escolhe uma vertical diferente da que estava acompanhando e navega pelo site daquele esporte.
Passa quando: completa sem bloqueio e confirma que reconhece o site da nova vertical como um site próprio (cor, marca e capa diferentes), sem nenhum resquício visual ou de dado da vertical anterior.
Cobre: a jornada Acompanhar quando a origem oscila.
Quem testa: usuário real do público, durante uma oscilação real ou simulada da fonte.
Como validar: o usuário permanece na página enquanto a fonte de dados fica temporariamente indisponível.
Passa quando: completa sem bloqueio e confirma que a página não quebra nem fica em branco, mostrando o último resultado válido com aviso.
Operador
Cobre: a jornada Preparar um novo campeonato.
Quem testa: o operador real da Sertões.
Como validar: o operador recebe as URLs da Chronosat e abre o painel autenticado para iniciar o cadastro.
Passa quando: completa sem bloqueio e confirma que o acesso e o início do assistente são claros.
Nota (2026-07-05, S66): o assistente completo (passos 1, 2 e 3: F3-03, F3-04, F3-05) está construído e provado no Alfa ({TA-32}, {TA-33}, {TA-43}, {TA-34}). Segue aberta porque este card é validado pelo operador real da Sertões (Beta), não por teste interno.
Cobre: a jornada Passo 1, escolher a vertical e nomear.
Quem testa: o operador real da Sertões.
Como validar: o operador seleciona a vertical e nomeia o campeonato.
Passa quando: completa sem bloqueio e confirma que a vertical escolhida traz a cor e a marca certas.
Nota (2026-07-05, S66): passos 1, 2 e 3 entregues e provados no Alfa ({TA-32}, {TA-33}, {TA-43}, {TA-34}); este card Beta aguarda o teste real do operador da Sertões (não é validação interna), por isso segue aberto até a rodada Beta.
Cobre: a jornada Passo 2, colar as URLs e testar a conexão.
Quem testa: o operador real da Sertões, sem apoio técnico durante o teste.
Como validar: o operador cola as URLs recebidas e aciona "testar conexão".
Passa quando: completa sem bloqueio e confirma que a pré-visualização (trechos e competidores encontrados) é compreensível sem explicação técnica.
Cobre: a jornada Passo 3, publicar.
Quem testa: o operador real da Sertões.
Como validar: o operador confere o resumo e publica o campeonato.
Passa quando: completa sem bloqueio e confirma que o evento aparece na página pública da vertical correta.
Nota (2026-07-05, S66): o passo 3 (F3-05) está entregue e provado no Alfa ({TA-34}, smoke visual real); este card Beta aguarda o teste real do operador da Sertões, por isso segue aberto até a rodada Beta.
Cobre: a jornada Controlar o estado durante e depois da prova.
Quem testa: o operador real da Sertões, durante um evento real.
Como validar: o operador mantém o evento ao vivo durante a prova e o marca como encerrado ao final.
Passa quando: completa sem bloqueio e confirma que a mudança de estado reflete corretamente na página pública.
Cobre: RF-PAINEL-009, RF-INGEST-005, a fase de encerramento dentro da jornada Controlar o estado.
Quem testa: o operador real da Sertões, com evento real ou de teste.
Como validar: o operador encerra o evento e, depois, verifica a página com a origem da Chronosat já fora do ar; o operador também é informado de que, mesmo que esqueça de encerrar antes de a origem sair do ar, nada se perde (cada leitura já ficou salva ao longo da prova).
Passa quando: completa sem bloqueio, confirma que a página segue publicada com o resultado final no endereço por vertical, ano e evento, e confirma que entendeu que encerrar é só parar de buscar (não existe cópia nem risco de perda mesmo sem encerrar a tempo).
Cobre: a jornada de cadastro de uma edição passada (RF-PAINEL-010), complemento do arquivamento contínuo (RF-PAINEL-009) que é o caminho principal do histórico, como publicar um post antigo num blog.
Quem testa: o operador real da Sertões.
Como validar: o operador cadastra pelo mesmo assistente de sempre uma edição passada a partir dos dados históricos disponíveis, marcando-a como já encerrada.
Passa quando: completa sem bloqueio e confirma que a página daquela edição é gerada, congelada e arquivada no endereço por vertical, ano e evento, e aparece corretamente na home junto às demais.
Cobre: a jornada Gerir os PDFs oficiais.
Quem testa: o operador real da Sertões.
Como validar: o operador adiciona um documento oficial por link e outro por upload, e depois remove um.
Passa quando: completa sem bloqueio e confirma que cada forma (link e upload) funciona e o documento aparece e some corretamente na página pública.
Cobre: a jornada Ocultar um competidor.
Quem testa: o operador real da Sertões.
Como validar: o operador busca um competidor pelo numeral, oculta e depois reexibe.
Passa quando: completa sem bloqueio e confirma que a ocultação e a reexibição refletem corretamente na página pública.
Cobre: a jornada Gerir as verticais, RF-CONFIG-001, RF-CONFIG-004.
Quem testa: o operador real da Sertões.
Como validar: o operador edita o perfil completo (cor, marca, capa, rótulos, regra de tripulação) de uma vertical existente, e cadastra a vertical Petrobras do zero apenas por configuração, sem apoio de desenvolvimento.
Passa quando: completa sem bloqueio, confirma que a edição se reflete na página pública sem depender de desenvolvimento, e confirma que conseguiu criar a vertical Petrobras sozinho, com identidade própria, sem pedir ajuda técnica.
Cobre: a jornada Acompanhar a audiência durante a prova (documento de Jornadas).
Quem testa: operador real da equipe do cliente, durante um evento ao vivo.
Como validar: o operador abre a tela de audiência com a sua conta enquanto a prova acontece, acompanha o bloco do agora, vê a curva por hora subir e identifica de onde o público está vindo.
Passa quando: completa sem bloqueio, o número do agora muda sozinho na tela, e o operador confirma que entendeu a diferença entre pessoas e acessos sem precisar de explicação técnica.
Cobre: a jornada Prestar contas da audiência depois da prova (documento de Jornadas).
Quem testa: operador real da equipe do cliente, depois de um evento encerrado.
Como validar: o operador escolhe o evento encerrado, lê o resumo, compara com outro evento, exporta o agregado e abre o arquivo numa planilha para montar o que vai ao patrocinador.
Passa quando: completa sem bloqueio, os números do arquivo conferem com os da tela, e o operador confirma que o arquivo serve para a prestação de contas sem retrabalho manual.
Administrador
Cobre: as jornadas do Administrador (entrar com a própria conta, e o acesso às telas de administração), RF-PAINEL-001 revisado.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador entra no painel com a sua conta nominal e confirma que vê, além das telas de gestão de campeonatos, os itens de Contas e Auditoria.
Passa quando: completa sem bloqueio e confirma que o acesso é pela mesma porta autenticada, com a sua credencial própria, e que as telas de administração aparecem.
Nota (S62): capacidade no ar (contas nominais, papel na sessão, telas de Contas e Auditoria visíveis ao administrador); aguarda beta com administrador real.
Cobre: as jornadas de gestão de contas (criar conta, editar papel, desativar/reativar, redefinir senha), RF-PAINEL-011.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador cria uma conta de operador para a equipe da Sertões, redefine a senha de uma conta que "esqueceu", e desativa uma conta que não precisa mais de acesso.
Passa quando: completa sem bloqueio e confirma que cada ação teve o efeito esperado (a conta nova entra, a senha redefinida passa a valer, a conta desativada não entra e o histórico dela permanece), sem precisar de apoio técnico.
Nota (S62): capacidade no ar (tela de gestão de contas com criar, editar papel, desativar/reativar, redefinir senha); aguarda beta com administrador real.
Cobre: a jornada de consulta ao log de auditoria, RF-PAINEL-012.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: depois de algumas ações no painel, o administrador abre a tela de auditoria e procura por uma ação específica.
Passa quando: completa sem bloqueio e confirma que consegue ver quem fez, o que fez, sobre o que e quando, do mais recente ao mais antigo, de forma compreensível.
Nota (S62): capacidade no ar (auditoria imutável gravando login, gestão de contas e mudanças de papel); aguarda beta com administrador real.
Cobre: a jornada Consultar o status das páginas (documento de Jornadas), RF-PAINEL-013.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador abre a tela de sitemap e monitor de status para conferir se as páginas principais do sistema e do site estão no ar, e aciona "verificar de novo".
Passa quando: completa sem bloqueio e confirma que enxerga a lista curada de rotas com o código de cada uma (no ar ou com erro), entende de relance o que está no ar e o que está com problema, e reconsulta quando quer, sem precisar de apoio técnico.
Nota (S62): capacidade no ar (tela de sitemap e monitor de status, lista curada, botão verificar de novo); aguarda beta com administrador real.
Cobre: a jornada Ligar e conferir as integrações de medição (documento de Jornadas).
Quem testa: administrador real.
Como validar: o administrador abre a tela de integrações, liga cada destino, informa o identificador, guarda a credencial, envia o evento de teste e confere a chegada na ferramenta do próprio destino; depois abre uma página pública em janela anônima e confirma a medição.
Passa quando: completa sem bloqueio, o evento de teste aparece na ferramenta do destino, a página pública passa a medir sem reinício do sistema, a credencial nunca é exibida em texto legível, e a auditoria mostra o que ele fez.
Sustentação
Cobre: a jornada Provisionar e manter o servidor.
Quem testa: a equipe de sustentação (Modulareasy).
Como validar: provisionar o servidor dedicado isolado, configurar a borda e fazer o deploy do aplicativo.
Passa quando: completa sem bloqueio e o ambiente fica saudável e isolado dos demais produtos.
Cobre: a jornada Monitorar a saúde do sistema.
Quem testa: a equipe de sustentação (Modulareasy), durante um evento ao vivo real.
Como validar: acompanhar a disponibilidade da página, a saúde do intermediário de leitura, o sucesso das leituras da Chronosat e o estado do cache durante a prova.
Passa quando: completa sem bloqueio e confirma visibilidade suficiente para detectar um problema antes que o público perceba.
Cobre: a jornada Responder a incidente ao vivo.
Quem testa: a equipe de sustentação (Modulareasy), com uma queda real ou simulada da origem durante um evento.
Como validar: confirmar que a página segue servida do último estado salvo no banco e que o restabelecimento do serviço ocorre sem intervir na operação do conteúdo dos eventos.
Passa quando: completa sem bloqueio e a página nunca quebra durante o incidente, mesmo com a origem indisponível.
Coleta de feedback Beta
Cobre: a navegação das jornadas na perspectiva do usuário real.
Quem testa: cliente ou usuário real do papel.
Como validar: o usuário percorre suas jornadas e retorna às telas anteriores sempre pela interface.
Passa quando: o usuário confirma que nunca ficou preso numa tela sem caminho de volta.
Cobre: o Aprendizado Pós-Lançamento do DRS.
Quem testa: operador e sustentação, observando o público.
Como validar: observar o primeiro evento ao vivo publicado de ponta a ponta e registrar os ajustes necessários no painel e na exibição pública.
Passa quando: a observação está registrada, com os ajustes identificados encaminhados como pendência de melhoria, sem bloquear a operação do evento em curso.
Cobre: o Aprendizado Pós-Lançamento do DRS.
Quem testa: operador e sustentação.
Como validar: aplicar os ajustes levantados na coleta de feedback e confirmar com o operador que resolveram o incômodo observado.
Passa quando: os ajustes identificados foram aplicados e confirmados pelo operador, sem reabrir os itens já aprovados na seção Alfa.
Cada item Alfa só passa quando o H1 do seu requisito passa; um requisito sem H1 verificado não está pronto. A entrega ao público só ocorre com a seção Alfa inteira concluída e a seção Beta observada em um evento real.