Sistema de Resultados de Campeonatos (Chronosat): Documento de Requisitos de Software

Documentos da família (companheiros deste DRS):

• Roadmap de Implementação, em que ordem construir e como verificar cada parte.
• Inventário de Artefatos, tudo que precisa existir (telas, integrações, configurações, infraestrutura) e como cada item deve ser.
• Jornadas dos Atores, como cada papel (público, operador, sustentação) opera o sistema.
• Questionário de Elicitação, as decisões de negócio alinhadas com a Sertões e com a Chronosat, respondível online; as respostas já foram recebidas e estão reconciliadas neste DRS (ver bloco 9).
• Plano de Testes (Alfa e Beta), o que validar antes de entregar: os testes internos por requisito (Alfa) e os testes com o público e o operador reais (Beta).

Artefatos de apoio e protótipo

• Protótipo visual navegável (mockup) do sistema completo: modulareasy.com/sertoes/pagina-de-resultados. É a REFERÊNCIA VISUAL APROVADA e o GUIA DO DESENVOLVIMENTO: cada tela do sistema é construída seguindo a página correspondente do mockup. Cobre o sistema inteiro, com os logotipos e as cores oficiais 2026 de cada vertical (Ap.4): a home global (lista dos quatro sites), a home de cada vertical (capa do esporte com o arquivo de edições por ano) e a página de evento de cada vertical, cada uma demonstrando a regra do seu esporte (Sertões Series ao vivo com dados reais do Rally Jalapão; Sertões Petrobras encerrada, demonstrando a página permanente; Sertões MTB em duplas com os dois nomes em negrito; Sertões Kitesurf solo com classificação por pontos), além do painel único do operador em três telas (visão de eventos com o estado das fontes, cadastro de novo evento com o fluxo de colar o bloco de URLs da Chronosat, e perfis das verticais). Um navegador flutuante ("Mapa do mockup") liga todas as páginas. A fonte dos arquivos é a pasta mockup/ do projeto.
• Questionário de Elicitação: os pontos alinhados com a Sertões (Bloco A) e com a Chronosat (Bloco B), apresentável e respondível online. As respostas já foram recebidas e cada uma está reconciliada neste DRS (bloco 9).

O protótipo é a materialização visual das decisões de UI deste DRS e vincula o desenvolvimento: quando este documento descreve a estrutura da página pública (bloco 2 e Ap.5), das homes (RF-PUB-015 e RF-PUB-016) ou do painel (módulo PAINEL), descreve o que o protótipo já mostra, e divergências visuais na implementação se resolvem consultando o protótipo. Ele usa dados de demonstração (reais do Rally Jalapão na Series, fictícios nas demais verticais) e não se atualiza ao vivo sozinho.

Documentos de suporte (vivem fora deste DRS): premissas e decisões de produto em 00-requisitos/discovery-notes.md. Os insumos originais (Especificação Técnica V4, documento de API da Chronosat, exemplos de JSON e registro de alinhamento) vivem na pasta do projeto.

Este documento descreve o Sistema de Resultados de Campeonatos por inteiro: o que ele é, para quem serve, o que faz e o que não faz, como se comporta, como seus dados são organizados e em que ordem ele é construído. É a referência única sobre o sistema: quando houver dúvida sobre o que ele deve fazer, a resposta está aqui. O sistema está especificado por inteiro para ser construído na ordem do companheiro Roadmap. As decisões de negócio que antes seguiam em alinhamento com a Sertões e com a Chronosat (comportamento ao fim da prova, endereço de publicação, ranking por categoria, origem dos PDFs, política de acesso da API, entre outras) já foram respondidas e estão reconciliadas no bloco 9; cada uma aponta o requisito que passou a cravar.

O que é o sistema em 1 minuto

O Sistema de Resultados de Campeonatos é uma família de sites públicos de resultados ao vivo para os campeonatos da Sertões, servida por um motor único. Cada vertical tem o seu próprio site, com cor, marca, home e regras de exibição próprias; as quatro verticais iniciais são Sertões Series, Sertões Petrobras, Sertões MTB e Sertões Kitesurf, e novas entram por configuração. O motor lê automaticamente os arquivos de cronometragem que a Chronosat publica durante as provas, grava cada leitura no banco de dados (o resultado nunca se perde), organiza esses dados (classificação geral, pódio, parciais por trecho, downloads oficiais) e os exibe com a identidade de cada vertical, em vez do layout cru da cronometragem. Cada evento fica publicado num endereço próprio e permanente, por vertical, ano e evento; quando a prova termina, a página congela com o resultado final e permanece no ar, e a home de cada site lista as edições por ano, como o arquivo de um blog.

O cadastro de um novo campeonato é feito por uma pessoa não técnica (o operador da Sertões) num painel único de três passos: escolhe a vertical, cola o bloco de URLs que a Chronosat enviou, testa a conexão e publica. Não depende de programador a cada evento: cada novo campeonato, e cada nova vertical, é configuração, não código. Um motor, quantos sites forem precisos.

Para quem é o sistema

O que o sistema faz

• Lê os dados da Chronosat automaticamente e grava cada leitura no banco. Busca os arquivos JSON publicados pela Chronosat (atualizados a cada minuto durante as provas), resolvendo o bloqueio de origem cruzada (CORS) com um intermediário do lado do servidor, persiste cada leitura bem-sucedida no banco de dados (o banco é a fonte de verdade desde o primeiro minuto) e serve esses dados já organizados para a página pública.
• Exibe a classificação em tabela responsiva (cartões no celular), com posição, numeral, tripulação, veículo e equipe, tempo da especial, penalidades e tempo total, na visão Geral (acumulado), por dia ou etapa e por categoria (com o ranking recalculado dentro de cada categoria).
• Mostra o pódio virtual dos cinco primeiros, em ordem sequencial (1 a 5), no geral e por recorte (categoria ou etapa).
• Permite filtrar por modalidade, categoria, trecho e numeral do competidor.
• Exibe as parciais ao vivo de cada competidor (os tempos intermediários I1 a I7 de um trecho) em uma janela de detalhe.
• Aplica as regras de negócio da cronometragem: trata valores ausentes, posições sem indicador, prólogo que não conta, tempos de abandono e teto regulamentar, e horários de auditoria.
• Centraliza os PDFs oficiais (penalidades, acumulado final) numa central de downloads.
• Dá a cada vertical um site próprio. Cor, marca, home e regras de exibição (o perfil do esporte, incluindo como a tripulação aparece: piloto e navegador, dupla com os dois nomes em negrito, ou solo) vêm da configuração da vertical, sobre uma base comum; as quatro verticais iniciais são Sertões Series, Sertões Petrobras, Sertões MTB e Sertões Kitesurf.
• Oferece um painel único de gestão que administra todas as verticais num só lugar, com cadastro de campeonato em três passos, teste de conexão com pré-visualização, controle de estado (ao vivo / encerrado), gestão de PDFs, ocultação de competidor e edição do perfil de cada vertical. O acesso é por conta nominal com papel: o operador (equipe Sertões) gerencia os campeonatos; o administrador (equipe Modulareasy) faz isso e mais a gestão de contas e a auditoria, de forma declarada e rastreável.
• Atende múltiplos eventos e múltiplas verticais por configuração, sem precisar alterar código a cada nova prova ou novo esporte, e se adapta a quantas modalidades, categorias e etapas cada evento tiver.
• Congela e arquiva cada evento sem risco de perda. Como cada leitura já fica gravada no banco, encerrar um evento é apenas parar de buscar a origem; a página congela com o último estado salvo e permanece publicada de forma permanente, por vertical, ano e evento, mesmo que ninguém a encerre antes de a Chronosat retirar os dados do ar.
• Oferece homes de consulta (as páginas de arquivo, como num blog): a home de cada vertical lista as edições por ano (o evento ao vivo sinalizado e as arquivadas), e uma home global enxuta lista os sites das verticais.

• Mede quantas pessoas acompanham. Cada acesso do público é registrado pelo próprio sistema e apresentado ao operador num painel de audiência (quantas pessoas e quantos acessos por dia e por hora, o pico, de onde vieram, o que procuraram, em que dispositivo, ao vivo ou depois da prova), com exportação para prestação de contas; em paralelo, as páginas públicas alimentam as plataformas de análise e de anúncios do cliente, ligadas e configuradas pelo administrador no próprio painel. O painel de gestão nunca entra nessa contagem.

O que o sistema NÃO faz

• NÃO calcula a cronometragem. Todo o cálculo de tempos, posições e acumulado é feito pela Chronosat. O sistema apenas lê, organiza e exibe. A única ordenação que o sistema faz por conta própria é o ranking por categoria, a partir dos dados que a Chronosat já entrega (confirmado pela Sertões, ver bloco 9).
• NÃO depende da Chronosat para manter o histórico. A Chronosat expõe apenas o evento vigente e retira os dados do ar quando a prova termina. Por isso o sistema grava no banco de dados cada leitura bem-sucedida, desde o primeiro minuto: a página é servida sempre do banco, e quando a origem sai do ar nada se perde, com ou sem encerramento pelo operador (ver bloco 9).
• NÃO duplica código por vertical. Um site novo de esporte não é um sistema novo: é uma linha de configuração com identidade, home e perfil próprios, servida pelo mesmo motor. Não existem cópias do sistema para manter em paralelo.
• NÃO gera os PDFs oficiais. Penalidades e acumulado final oficial são produzidos pela Chronosat e disponibilizados como arquivos; o sistema apenas os disponibiliza para download.
• NÃO substitui o site institucional da Sertões. A página de resultados tem endereço próprio (um subdomínio de resultados, resultados.sertoes.com.br), vinculado a partir das páginas de cada vertical no site; complementa o site institucional, não o substitui.
• NÃO faz cadastro público nem autenticação do público. O público apenas consome; só as contas nominais autorizadas (administrador e operador) têm acesso autenticado, e só ao painel. Não há autocadastro: as contas são criadas pelo administrador.
• NÃO compartilha infraestrutura com outros sistemas. Roda em servidor dedicado e isolado (ver bloco 7), para não competir por recursos nem cair junto com outros produtos.

Como ler este documento

O leitor de negócio encontra o essencial nesta Contextualização e nos blocos 1 (Visão Geral), 2 (Atores) e 9 (Entrega). O leitor técnico encontra o detalhe nos blocos 3 (Requisitos Funcionais), 5 (Modelo de Dados), 6 (Interfaces e Integrações) e 7 (Arquitetura). Os requisitos funcionais usam o código RF-MODULO-NNN e cada um traz um critério de aceite (H1) no formato "Dado, Quando, Então, E", que é a prova binária de que aquele requisito está pronto. Os apêndices guardam as fichas longas (campos dos arquivos, regras de interpretação, telas, cores).

1. Visão Geral do Sistema

A.1 Propósito

Automatizar a publicação dos resultados dos campeonatos da Sertões, hoje montados manualmente e dependentes da memória de uma pessoa, transformando-os em uma página pública ao vivo, com a identidade visual da marca, alimentada diretamente pelos dados da cronometragem oficial (Chronosat) e operável por uma pessoa não técnica.

A.2 Problema que resolve

Nas edições anteriores, a montagem dos resultados era manual: o operador colava blocos de HTML em ordem cronológica conforme as etapas terminavam e ligava o layout cru da própria Chronosat. O processo é trabalhoso, propenso a erro, dependente de quem sabe o passo a passo, e não tem a identidade da marca. O sistema elimina o trabalho manual de montagem, dá identidade visual própria e torna o cadastro de um novo campeonato acessível a qualquer operador.

A.3 Objetivos e métricas de sucesso

• Cadastro sem programador. Um operador não técnico cadastra e publica um campeonato sozinho, sem suporte de desenvolvimento.
• Tempo de publicação. Do recebimento das URLs da Chronosat à página no ar em poucos minutos.
• Atualização ao vivo. A página reflete os dados da Chronosat com defasagem de poucas dezenas de segundos durante a prova.
• Aguenta o pico. A página permanece disponível durante o pico de acessos ao vivo sem degradar.
• Site próprio por vertical. Cada vertical (Sertões Series, Sertões Petrobras, Sertões MTB, Sertões Kitesurf) aparece ao público como um site próprio, com identidade, home e regras de exibição adequadas ao esporte.
• Reuso entre verticais. Uma nova vertical entra como configuração, sem novo desenvolvimento (a Sertões confirmou que todas as verticais usam a mesma Chronosat, ver bloco 9).
• Nada se perde. Cada leitura da Chronosat é gravada no banco; todo evento publicado fica permanente, por vertical, ano e evento, consultável a qualquer momento a partir das homes.

A.4 Premissas

Estas premissas foram cravadas a partir dos insumos e da validação empírica da API. As que dependem de confirmação do cliente ou da Chronosat estão marcadas e remetem ao bloco 9.

• A Chronosat publica, por evento, arquivos JSON estáticos atualizados a cada minuto durante as provas, em endereços do tipo https://satcron.com/stages/cache/{evento}_{modalidade}_{tipo}_{trecho}_{controle}.json.
• São três tipos de arquivo por modalidade: crews (dados do evento, trechos, categorias e tripulações; um por modalidade, estático no evento), stagetimes (tempos de um trecho específico, um por trecho, dinâmico a cada minuto) e racetimes (acumulado geral, um por modalidade, incremental ao longo dos dias). Todos cruzados pela chave numeral.
• No evento de referência do rally, a modalidade é codificada como 1=motos, 2=utv, 3=carros; os códigos, os nomes e a quantidade de modalidades variam por evento e são lidos dos próprios dados (crews), nunca fixados em código.
• Os arquivos JSON reais já em mãos (crews, stagetimes e racetimes do rally, mais o documento oficial da API) são suficientes para construir e testar o sistema inteiro; nenhum dado adicional de terceiros é pré-requisito da construção. Esportes cujo payload vier diferente são absorvidos pela renderização orientada a dados (ADR-012).
• Conforme o documento oficial da API, cada modalidade tem um arquivo crews e um racetimes que compartilham o mesmo controle (hash) por todo o evento, e um arquivo stagetimes por trecho, cada um com o seu próprio controle. Os controles são estáveis por arquivo durante a prova; o que muda ao longo dos dias é o surgimento de novos arquivos de stagetimes conforme os trechos começam. O sistema lê o bloco de URLs entregue pela Chronosat e acompanha esses arquivos; se a Chronosat vier a mudar um controle no meio da prova, o operador atualiza a URL da fonte pelo painel, sem depender de desenvolvimento (ver bloco 9).
• A Chronosat entrega o conjunto de URLs por evento; o operador as cola diretamente no painel, sem depender de programação (ver bloco 9).
• A API da Chronosat não expõe histórico: apenas o evento vigente, e ao fim da prova os dados saem do ar na origem. Por isso o próprio sistema persiste cada leitura bem-sucedida no banco de dados, desde a primeira: o banco é a fonte de verdade e a página é servida sempre dele, de modo que o resultado nunca se perde, mesmo que o evento não seja encerrado antes de a origem sair do ar. A Sertões confirmou que quer a página congelada e mantida permanentemente, por evento e por ano (ver bloco 9).
• A API não envia cabeçalho de origem cruzada (CORS bloqueado, validado empiricamente): o navegador do público não busca os arquivos diretamente, o que exige um intermediário do lado do servidor.
• Penalidades detalhadas e o acumulado final oficial chegam apenas em PDF, não nos JSON.
• O endpoint atual é beta (version 2.0.0-beta). A Sertões pediu que o sistema esteja pronto para todas as hipóteses de acesso, inclusive um endpoint de produção com autenticação própria; a credencial e a política de acesso entram na configuração quando existirem (ver bloco 9).

A.5 Escopo da entrega

Entram no escopo: o intermediário de leitura dos dados da Chronosat com persistência de cada leitura no banco, a API interna de leitura para as páginas públicas, a página pública de resultados (com filtros, pódio de cinco, classificação geral, por dia ou etapa e por categoria, parciais e downloads), o site próprio de cada vertical (identidade, home com as edições por ano e perfil de exibição, para as quatro verticais iniciais), a home global enxuta, o arquivo permanente de cada evento, o painel único do operador, o suporte a múltiplos eventos e múltiplas verticais por configuração, e a infraestrutura dedicada isolada. Ficam fora: cálculo de cronometragem, geração de PDFs oficiais, página de campeões históricos (incremento futuro já previsto), e qualquer alteração no site institucional além do vínculo para o subdomínio de resultados.

A.6 Glossário

2. Atores e Jornadas

A visão detalhada de como cada papel opera o sistema está no companheiro Jornadas dos Atores. Este bloco define os atores e o resumo de suas jornadas; o companheiro traz a operação assento a assento.

B.1 Atores

Governança do acesso administrativo. A equipe da Modulareasy, que constrói e opera o sistema para a Sertões, mantém acesso administrativo ao painel de forma declarada e auditável: por contas nominais individuais, cada uma com a sua própria senha (guardada só como hash), com o papel administrador registrado, e com cada ação sensível gravada no log de auditoria (RF-PAINEL-012). Não há acesso oculto nem atalho que contorne a autenticação: administrador e operador entram pela mesma porta autenticada, e a única diferença é o que cada papel pode fazer. Uma conta pode ser desativada a qualquer momento, revogando o acesso sem apagar o histórico do que já foi feito.

B.2 Resumo das jornadas

• Público: entra pelo site da vertical (a home do esporte, que lista as edições por ano) ou direto na página de um evento, e encontra, de cima para baixo, o cabeçalho da Sertões com selo "Ao Vivo", o hero do evento (nome da prova, subtítulo do campeonato, abas de modalidade e faixa de etapas), o pódio dos cinco primeiros, os filtros, a tabela de classificação e a central de documentos oficiais. Alterna a modalidade pelas abas do evento (por exemplo Motos, UTV, Carros), filtra por categoria (com o ranking próprio da categoria) ou busca pelo numeral, toca um competidor para abrir o modal de detalhe com os tempos por especial, e baixa um PDF oficial. A página se atualiza sozinha durante a prova; encerrada a prova, congela com o resultado final e permanece consultável, e a home lista os eventos e anos. A estrutura concreta da página, materializada no protótipo aprovado, está fichada no Ap.5; o detalhe assento a assento está no companheiro Jornadas.
• Operador: recebe da Chronosat o conjunto de URLs do evento, abre o painel com a sua conta, percorre o assistente de três passos (escolhe a vertical e o nome, cola as URLs e testa a conexão vendo a pré-visualização, publica), e ao longo do evento alterna o estado (ao vivo / encerrado), sobe os PDFs oficiais e oculta um competidor se necessário; ao encerrar, o evento congela num arquivo permanente, e o operador também pode criar a página de um evento passado (retroativo). Detalhe no companheiro Jornadas.
• Administrador: entra com a sua conta e faz tudo que o operador faz, e mais: cria e edita as contas de usuário (define login, papel e senha inicial), desativa e reativa uma conta, redefine a senha de quem esqueceu, e consulta o log de auditoria para ver quem fez o quê e quando. Detalhe no companheiro Jornadas.
• Sustentação: provisiona e mantém o servidor dedicado, faz o deploy do sistema, monitora a saúde e responde a incidentes. Não cadastra eventos.

3. Requisitos Funcionais

Cada requisito tem código RF-MODULO-NNN, prioridade (Essencial / Alta / Média), atores, e um critério de aceite H1 ("Dado, Quando, Então, E") que é a prova binária de pronto. Os módulos são: INGEST (leitura e cache da Chronosat), API (leitura interna), PUB (página pública), REGRA (regras de interpretação dos dados), PAINEL (painel de gestão, incluindo contas e auditoria), CONFIG (multi-evento e multi-vertical), MEDIR (medição de audiência).

C.1 Ingestão e cache (módulo INGEST)

RF-INGEST-001: Proxy de leitura dos arquivos da Chronosat

• Descrição: o sistema busca, do lado do servidor, os arquivos JSON da Chronosat (crews, stagetimes, racetimes) a partir das URLs configuradas para o evento, e os serve para o front, resolvendo o bloqueio de origem cruzada (CORS).
• Prioridade: Essencial
• Atores: Público (indireto), Operador (configuração das URLs)
• Entrada: as URLs configuradas do evento (por modalidade e por trecho).
• Saída: o conteúdo JSON normalizado servido pela API interna.
• H1: Dado um evento publicado com URLs válidas de crews, stagetimes e racetimes, Quando o front solicita os dados ao servidor, Então o servidor responde com os JSON da Chronosat (sem que o navegador do público chame satcron.com diretamente), E a resposta inclui cabeçalho de origem cruzada permitindo o domínio da página.
• Notas: a Chronosat não envia Access-Control-Allow-Origin, por isso a leitura direta pelo navegador é inviável; o intermediário do lado do servidor é obrigatório.

RF-INGEST-002: Cache com janela curta

• Descrição: o servidor mantém em cache a resposta de cada arquivo da Chronosat por uma janela curta (configurável, padrão de 30 a 60 segundos) e busca a origem no máximo uma vez por minuto, coerente com a cadência de atualização da Chronosat.
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um arquivo já buscado há menos de 30 segundos, Quando chegam múltiplas requisições do público para o mesmo arquivo, Então todas são servidas do cache sem nova chamada à Chronosat, E a chamada à origem ocorre no máximo uma vez por minuto por arquivo.
• Notas: protege a Chronosat de excesso de chamadas e absorve o pico de acessos do público.

RF-INGEST-003: Resiliência a falha da origem

• Descrição: se a Chronosat estiver indisponível ou responder com erro, o sistema segue servindo o último estado salvo no banco (RF-INGEST-005) e sinaliza que a atualização está suspensa, em vez de quebrar a página.
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado que a última leitura de um arquivo foi bem-sucedida e a Chronosat passa a responder erro, Quando o público acessa a página, Então a página exibe o último resultado válido salvo no banco com indicação de que a atualização está temporariamente suspensa, E não exibe erro cru nem página em branco.
• Notas: ver também RF-PUB-009 (indicador de estado ao vivo). Se a origem estiver indisponível já no primeiro acesso, antes de qualquer leitura bem-sucedida (sem cache ainda), a página exibe um estado de aguardando dados, nunca um erro cru nem página em branco.

RF-INGEST-004: Cruzamento dos três arquivos pela chave numeral

• Descrição: o sistema relaciona os registros de crews, stagetimes e racetimes pela chave numeral, montando a visão consolidada de cada competidor (identificação, tempos do trecho e acumulado).
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um competidor de numeral X presente em crews, stagetimes e racetimes, Quando o sistema consolida os dados, Então a visão do competidor reúne identificação (de crews), parciais e tempo do trecho (de stagetimes) e acumulado geral (de racetimes), todos com numeral X.
• Notas: numeral é a única chave de junção; ver Ap.1.

RF-INGEST-005: Persistência de cada leitura no banco de dados

• Descrição: cada leitura bem-sucedida de um arquivo da Chronosat é gravada no banco de dados como o estado mais recente daquela fonte (o payload bruto, como veio, mais o momento da leitura). A página pública é servida sempre do banco, nunca da origem diretamente. O resultado de um evento nunca depende de a origem continuar no ar nem de o operador encerrar a tempo.
• Prioridade: Essencial
• Atores: Público (indireto), Operador (indireto)
• H1: Dado um evento ao vivo com leituras bem-sucedidas, Quando a Chronosat retira os arquivos do ar (com ou sem o evento ter sido encerrado no painel), Então a página continua exibindo o último estado salvo no banco, E nenhum dado exibido anteriormente se perde.
• Notas: o payload é guardado bruto e a normalização acontece na exibição, de modo que melhorias futuras de renderização se aplicam também aos eventos antigos sem re-buscar a origem (ver ADR-012). O cache de janela curta (RF-INGEST-002) continua existindo apenas como proteção de taxa.

C.2 API interna de leitura (módulo API)

RF-API-001: Endpoint de classificação geral

• Descrição: a API expõe, em modo somente leitura, a classificação geral de um evento e modalidade (acumulado), já cruzada e ordenada.
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um evento e modalidade publicados, Quando o front solicita a classificação geral, Então a API 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.

RF-API-002: Endpoint de classificação por trecho

• Descrição: a API expõe a classificação de um trecho específico (stagetimes), com os tempos e posições do trecho.
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um evento, modalidade e trecho publicados, Quando o front solicita o trecho, Então a API retorna a lista de competidores do trecho com tempo da especial, posições parciais e tempo total do trecho.

RF-API-003: Endpoint de detalhe de competidor (parciais)

• Descrição: a API expõe as parciais I1 a I7 de um competidor em um trecho, para a janela de detalhe.
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado um competidor de numeral X em um trecho, Quando o front solicita o detalhe, Então a API retorna os horários de passagem I1 a I7, os deltas tempo1 a tempo7 e as posições posI1 a posI7, omitindo os indicadores nulos.

RF-API-004: Endpoint de metadados do evento

• Descrição: a API expõe os metadados do evento vindos de crews (título, subtítulo, lista de trechos com nome, distância, origem, destino e status, modalidades e categorias) e o estado de publicação configurado.
• Prioridade: Essencial
• Atores: Público (indireto), Operador
• H1: Dado um evento publicado, Quando o front carrega a página, Então recebe título e subtítulo da prova, a lista de trechos com seus atributos e status (I iniciado / NI não iniciado), as modalidades e as categorias, e o estado ao vivo ou encerrado.

RF-API-005: Endpoint de classificação por categoria

• Descrição: a API expõe a classificação recalculada dentro de uma categoria, com as posições renumeradas entre os competidores daquela categoria.
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado um evento com categorias e uma categoria selecionada, Quando o front solicita a classificação da categoria, Então a API retorna apenas os competidores da categoria, ordenados pelo tempo aplicável, com a posição renumerada de 1 em diante.
• Notas: sustenta RF-PUB-004; a ordenação usa os dados que a Chronosat já entrega, sem recalcular cronometragem.

C.3 Página pública (módulo PUB)

RF-PUB-001: Tabela de classificação responsiva

• Descrição: a página exibe a classificação em tabela no desktop e em cartões no celular, com as colunas Posição, Numeral, Tripulação (piloto e navegador), Equipe e Veículo, Categoria, Penalidades, Tempo total e Diferença para o líder. O competidor em abandono ou teto regulamentar aparece com o rótulo "Não completou" no lugar do tempo (RF-REGRA-004). O tempo total, emitido pela fonte em segundos, é exibido como duração HH:MM:SS (as horas podem exceder 24). A diferença para o líder é computada na exibição (tempo total do competidor menos o do líder) e exibida como "+MM:SS" ou "+H:MM:SS"; o líder exibe "LÍDER" e quem não completou exibe travessão. No celular o cartão mostra os campos essenciais (posição, tripulação, equipe e veículo, tempo total e diferença); numeral, categoria e penalidades ficam na visão desktop e no detalhe do competidor (modal, RF-PUB-007).
• Prioridade: Essencial
• Atores: Público
• Saída: as colunas exatas, na ordem Posição, Numeral, Tripulação, Equipe e Veículo, Categoria, Penalidades, Tempo total, Diferença (ver Ap.5).
• H1: Dado um evento com classificação disponível, Quando o público abre a página no celular, Então cada competidor aparece como cartão legível com posição, tripulação (exibida conforme a regra da vertical), equipe e veículo, tempo total e diferença para o líder (numeral, categoria e penalidades ficam na visão desktop e no detalhe do competidor), E no desktop os mesmos dados aparecem em tabela com todas as colunas na ordem definida no Ap.5, E quem abandonou ou atingiu o teto exibe "Não completou".
• Notas: a exibição da tripulação segue o perfil da vertical (RF-CONFIG-001): no rally, piloto em destaque e navegador; na bike, dupla com os dois nomes em negrito; no kite, atleta solo.

RF-PUB-002: Pódio virtual (cinco primeiros)

• Descrição: a página exibe um pódio dos cinco primeiros do recorte selecionado (geral, por categoria ou por etapa), em ordem sequencial do 1º ao 5º (da esquerda para a direita no desktop, de cima para baixo no celular), não na disposição clássica de pódio. Cada lugar mostra a posição, o numeral, o piloto, o navegador, a equipe, o tempo total e a diferença para o líder.
• Prioridade: Alta
• Atores: Público
• H1: Dado um recorte com ao menos cinco competidores, Quando o público vê o pódio, Então os cinco primeiros aparecem em destaque na ordem sequencial de 1º a 5º, cada lugar exibindo posição, numeral, piloto, navegador, equipe, tempo total e diferença, E o recorte (geral, categoria ou etapa) é o selecionado nos filtros; Quando o recorte tem menos de cinco competidores, o pódio mostra os que houver, na mesma ordem.
• Notas: substitui o pódio de três da versão anterior; a ordem é sempre de 1 a 5, inclusive no celular (não a disposição 2, 1, 3). Os nomes de cada lugar seguem a regra de tripulação do perfil da vertical (dupla com os dois nomes em negrito na bike, solo no kite).

RF-PUB-003: Filtro por modalidade

• Descrição: o público filtra a exibição por modalidade; as modalidades disponíveis são as que o evento tiver (por exemplo motos, utv, carros), lidas dinamicamente dos dados.
• Prioridade: Essencial
• Atores: Público
• H1: Dado um evento com mais de uma modalidade, Quando o público seleciona uma modalidade, Então a classificação, o pódio e os trechos passam a refletir apenas aquela modalidade.

RF-PUB-004: Filtro e ranking por categoria

• Descrição: o público filtra por categoria (código e descrição vindos de crews, ex.: T1M, Stock) e vê a classificação recalculada dentro daquela categoria, com as posições renumeradas de 1 em diante entre os competidores da categoria. O filtro de categoria vale também quando um trecho está selecionado: a lista mostra só os competidores da categoria naquele trecho, com posição e pódio renumerados dentro do recorte combinado (categoria dentro do trecho), nunca a categoria ignorada em favor do trecho.
• Prioridade: Alta
• Atores: Público
• H1: Dado um evento com categorias definidas, Quando o público seleciona uma categoria, Então a lista exibe apenas os competidores daquela categoria, ordenados entre si pelo tempo aplicável (acumulado no Geral, tempo do trecho quando um trecho está selecionado), com a posição da categoria renumerada de 1 em diante, E o pódio reflete os cinco primeiros da categoria.
• Notas: a Sertões confirmou o ranking por categoria além da classificação geral (ver bloco 9); a ordenação é feita sobre os dados que a Chronosat já entrega (ver RF-API-005). Nota de revisão (2026-09-17): o filtro de categoria estava sendo ignorado quando havia um trecho selecionado (defeito constatado no evento MTB Ibitipoca 2026); corrigido para que a categoria valha dentro do recorte de trecho, conforme este H1 já exigia.

RF-PUB-005: Filtro por trecho

• Descrição: o público alterna entre a classificação geral (acumulado) e a classificação de um trecho específico.
• Prioridade: Essencial
• Atores: Público
• H1: Dado um evento com trechos iniciados, Quando o público seleciona um trecho, Então a tabela passa a exibir os tempos e posições daquele trecho; ao selecionar Geral, volta ao acumulado.

RF-PUB-006: Filtro e busca por numeral

• Descrição: o público localiza um competidor pelo numeral.
• Prioridade: Média
• Atores: Público
• H1: Dado um competidor de numeral X presente no evento, Quando o público busca por X, Então a tabela destaca ou filtra esse competidor.

RF-PUB-007: Modal de detalhe do competidor

• Descrição: ao tocar um competidor, o público abre um modal de detalhe com a identificação e o desempenho daquele competidor: equipe, veículo, categoria, posição, penalidades e tempo total, mais o tempo por especial (SS1 a SSN, o desempenho de cada trecho válido a partir de racetimes). Quando há um trecho selecionado com parciais registradas, o modal também traz as parciais intermediárias I1 a I7 daquele trecho (horários de passagem, deltas e posições parciais).
• Prioridade: Alta
• Atores: Público
• H1: Dado um competidor da classificação, Quando o público abre o detalhe, Então o modal mostra equipe, veículo, categoria, posição, penalidades, tempo total e o tempo por especial SS1 a SSN; Quando há um trecho com parciais, mostra também as passagens I1 a I7 com seus deltas e posições, ocultando as parciais sem indicador de posição (posIx nulo), E o modal fecha sem recarregar a página.
• Notas: o tempo por especial vem de racetimes (ssX); as parciais I1 a I7 vêm de stagetimes (ver Ap.1).

RF-PUB-008: Documentos oficiais do evento (barra compacta)

• Descrição: a página pública do evento exibe os documentos oficiais (resultado acumulado, penalidades, ordem de largada, regulamento, boletins) numa barra compacta no início da área de conteúdo, logo abaixo da faixa de etapas e antes do pódio e dos filtros, em um único lugar da página. Cada documento vira um chip de download que abre em nova aba, na ordem definida no painel (RF-PAINEL-006). Documento inválido (sem título ou com endereço inseguro) não aparece. Quando não há nenhum documento publicado, a barra não aparece (o container permanece no HTML, vazio e oculto), para que um documento publicado durante o evento ao vivo apareça no ciclo seguinte do refresh suave (RF-PUB-009), sem recarregar a página. Muitos documentos quebram em várias linhas, sem esconder nenhum link.
• Prioridade: Alta
• Atores: Público
• H1: Dado um evento com documentos publicados, Quando o público abre a página, Então a barra de documentos oficiais aparece antes do pódio e dos filtros, logo abaixo da faixa de etapas, com um chip de download por documento na ordem do painel; Quando não há nenhum documento válido, Então a barra não aparece, mas o container permanece presente e vazio no HTML; E quando um documento é publicado durante o evento ao vivo, o chip aparece no ciclo seguinte do refresh automático, sem recarregar a página.
• Notas: revisão de 2026-09-17, substitui a antiga Central de Documentos Oficiais ao fim da página; documento inválido é filtrado silenciosamente, sem erro visível.

RF-PUB-009: Indicador de estado e atualização automática

• Descrição: a página indica se o evento está ao vivo ou encerrado e atualiza os dados automaticamente em intervalo curto enquanto ao vivo.
• Prioridade: Alta
• Atores: Público
• H1: Dado um evento marcado como ao vivo, Quando o público permanece na página, Então os dados se atualizam automaticamente a cada cerca de 30 segundos e um indicador "ao vivo" é exibido; Quando o evento está encerrado, o indicador muda para "encerrado" e a atualização automática para.
• Notas: ao fim da prova, o operador encerra o evento e a página congela com o resultado final e permanece publicada de forma permanente (RF-PAINEL-009); a atualização automática para; o refresh automático também atualiza a barra de documentos oficiais (RF-PUB-008), sem recarregar a página.

RF-PUB-010: Identidade visual por vertical

• Descrição: cada site de vertical aplica a sua cor, marca e capa sobre a base comum, conforme o perfil configurado (Series e Petrobras no laranja oficial E96409, MTB no rosa E40E7F, Kitesurf no verde 88BD23).
• Prioridade: Essencial
• Atores: Público
• H1: Dado um evento da vertical Series, Quando o público abre a página, Então a cor de destaque é a laranja da vertical sobre fundo escuro; para cada outra vertical, a cor e a marca são as do seu perfil, conforme Ap.4, E duas verticais nunca compartilham a identidade uma da outra.

RF-PUB-011: Cabeçalho com identidade do Sertões e selo Ao Vivo

• Descrição: a página exibe no topo o cabeçalho com a identidade do site do Sertões: barra na cor da marca, logotipo oficial, navegação e o selo "Ao Vivo" pulsante quando o evento está ao vivo.
• Prioridade: Alta
• Atores: Público
• H1: Dado um evento ao vivo, Quando o público abre a página, Então o cabeçalho exibe a barra na cor da marca, o logotipo oficial do Sertões, a navegação e o selo "Ao Vivo" pulsante; Quando o evento está encerrado, o selo "Ao Vivo" não pulsa (coerente com RF-PUB-009).
• Notas: o selo de estado é o mesmo conceito do indicador de RF-PUB-009; aqui está posicionado no cabeçalho.

RF-PUB-012: Hero do evento com abas de modalidade e faixa de etapas

• Descrição: abaixo do cabeçalho, o hero exibe o nome do evento (ex.: "XII Rally Jalapão"), o subtítulo do campeonato, as abas de modalidade do evento (por exemplo Motos, UTV, Carros) cada uma com o contador de competidores, e a faixa de etapas ou trechos, com a visão Geral em destaque seguida de Prólogo, Dia 1 a Dia N, com a distância e o estado de cada trecho, além do indicador "atualizado há X".
• Prioridade: Alta
• Atores: Público
• Saída: nome do evento, subtítulo, abas de modalidade com contador, faixa de etapas com distância e estado, indicador de frescor "atualizado há X" (ver Ap.5).
• H1: Dado um evento publicado, Quando o público abre a página, Então o hero mostra o nome do evento e o subtítulo do campeonato, as abas de modalidade do evento (por exemplo Motos, UTV, Carros) com o número de competidores de cada, 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"; Quando o público troca de aba de modalidade, a página passa a refletir aquela modalidade (coerente com RF-PUB-003).
• Notas: as abas de modalidade são a forma concreta do filtro de modalidade (RF-PUB-003); a faixa de etapas é a forma concreta da seleção de trecho (RF-PUB-005), com o status I iniciado ou NI não iniciado vindo de crews (Ap.1).

RF-PUB-013: Contador de competidores nos filtros

• Descrição: a área de filtros exibe, além do seletor de categoria e da busca por nome ou numeral, o contador de competidores do recorte ativo (total exibido após filtros).
• Prioridade: Média
• Atores: Público
• H1: Dado um evento com competidores, Quando o público aplica ou limpa um filtro de categoria ou uma busca, Então o contador de competidores reflete a quantidade exibida no recorte ativo.
• Notas: o seletor de categoria é RF-PUB-004; a busca por nome ou numeral é RF-PUB-006; este RF cobre o contador que os acompanha.

RF-PUB-014: Rodapé com créditos de cronometragem e desenvolvimento

• Descrição: o rodapé da página exibe o crédito "Cronometragem por Chronosat" e o crédito "Desenvolvido por Modulareasy".
• Prioridade: Média
• Atores: Público
• H1: Dado qualquer página de resultados publicada, Quando o público chega ao fim da página, Então o rodapé exibe "Cronometragem por Chronosat" e "Desenvolvido por Modulareasy".

RF-PUB-015: Home da vertical (o site do esporte)

• Descrição: cada vertical tem a sua home em /<vertical>, a capa do site do esporte: hero com a identidade e a capa do perfil, o evento ao vivo em destaque quando houver, e o arquivo das edições por ano (como o índice de um blog), cada uma levando à sua página fixa.
• Prioridade: Alta
• Atores: Público
• H1: Dado uma vertical com um ou mais eventos publicados (ao vivo ou arquivados), Quando o público abre a home da vertical, Então vê a capa com a identidade do esporte, o evento ao vivo sinalizado em destaque quando houver, e a lista das edições por ano, e ao escolher uma é levado à página daquele evento, E nenhuma outra vertical aparece nessa home.
• Notas: é a home que faz cada vertical parecer um site próprio; a página de cada evento vive em resultados.sertoes.com.br/<vertical>/<ano>/<evento> (ver F.2 e RF-CONFIG-005).

RF-PUB-016: Home global enxuta

• Descrição: a raiz do subdomínio de resultados tem uma home global mínima que apresenta os sites das verticais (nome, marca e cor de cada uma) e leva à home de cada esporte. Não mistura classificações nem eventos de esportes diferentes.
• Prioridade: Média
• Atores: Público
• H1: Dado o subdomínio publicado com uma ou mais verticais, Quando o público abre a raiz, Então vê a lista dos sites das verticais na ordem configurada e, ao escolher um, é levado à home daquela vertical.
• Notas: complementa RF-PUB-015; a navegação principal do público é dentro do site de cada esporte.

C.4 Regras de interpretação dos dados (módulo REGRA)

As regras abaixo derivam do documento da API e dos exemplos de JSON. A ficha completa está no Ap.2.

RF-REGRA-001: Renderizar valor ausente

• Descrição: quando um campo de bônus ou penais traz o marcador " *", o sistema exibe um traço de ausência (hífen simples) no lugar.
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um competidor com penais igual a " ", Quando a linha é renderizada, Então a célula de penalidades exibe o traço de ausência, E não exibe o texto literal .

RF-REGRA-002: Ocultar indicador de posição nulo

• Descrição: quando uma posição parcial posIx é nula, o sistema oculta aquele indicador.
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado um competidor com posI5 nulo, Quando a janela de parciais é exibida, Então a posição da parcial 5 não aparece, E as demais parciais com posição aparecem normalmente.

RF-REGRA-003: Prólogo (trecho zero) não conta no acumulado

• Descrição: o trecho zero (prólogo, ss0) define a ordem de largada e não entra no acumulado geral. O acumulado oficial vem pronto do racetimes, que já não inclui o prólogo (o ss0 não aparece no racetimes), então o sistema apenas exibe esse acumulado e nunca soma o prólogo por conta própria.
• Prioridade: Essencial
• Atores: Público (indireto)
• H1: Dado um evento com prólogo realizado, Quando o sistema exibe o acumulado geral, Então o tempo do prólogo não é somado ao tempo total, E o prólogo permanece consultável como trecho próprio (pela sua etapa de stagetimes).
• Notas: confirmado nos dados reais, o racetimes traz os trechos de ss1 em diante e o tempoTotal já é tempo mais penais menos bônus, sem o prólogo; nada precisa ser recalculado pelo sistema.

RF-REGRA-004: Tempos de abandono e teto regulamentar

• Descrição: tempos fixos de 9000.00 segundos na especial e 27000.00 segundos no total indicam abandono ou teto regulamentar; além disso, a Chronosat penaliza especiais não completadas somando blocos de 1.000.000 segundos ao tempo total (ex.: oito especiais faltando ≈ 8.000.000), de modo que qualquer tempo total a partir de 900.000 segundos (limiar acima de qualquer prova real e abaixo do menor bloco observado, 1.003.887) também indica não completou; em todos os casos o sistema exibe "Não completou" em vez do número.
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado um competidor com tempo de especial igual a 9000.00, tempo total igual a 27000.00, ou tempo total a partir de 900.000 segundos (bloco de penalidade da Chronosat por especiais não completadas), Quando a linha é renderizada, Então o sistema exibe "Não completou" no lugar do número, E mantém a posição conforme a ordenação aplicável.

RF-REGRA-005: Horários de auditoria (L e C decimais)

• Descrição: quando L (largada) e C (chegada) vêm em formato decimal, representam segundos desde a meia-noite e servem para auditoria; o sistema os interpreta e exibe em formato de horário quando exibidos.
• Prioridade: Média
• Atores: Público (indireto)
• H1: Dado um competidor com L igual a 25680.00, Quando o valor é interpretado, Então o sistema o entende como segundos desde a meia-noite (07:08:00) para fins de auditoria, E não o confunde com um tempo de prova.

RF-REGRA-006: Competidor oculto pela origem

• Descrição: quando um competidor vem com status oculto na origem (_status igual a O), o sistema não o exibe em nenhuma superfície pública de leitura dos dados de classificação: nem na página pública, nem na API interna de leitura (RF-API-001 a RF-API-005), que serve os mesmos dados e é acessível publicamente. A leitura pela origem considera as duas formas em que a Chronosat carimba o campo (nos registros de crews e de racetimes).
• Prioridade: Alta
• Atores: Público (indireto)
• H1: Dado um competidor com _status igual a O, Quando a classificação é montada em qualquer superfície pública (a página pública ou a API interna de leitura), Então esse competidor não aparece publicamente, E os demais aparecem normalmente.
• Notas: distinto da ocultação manual pelo operador (RF-PAINEL-007), que é canal independente. A ocultação por origem aplica-se a toda leitura pública dos dados de classificação, incluindo os endpoints de lista e de detalhe da API (RF-API-001, RF-API-002, RF-API-003, RF-API-005); os metadados do evento (RF-API-004) não listam competidores e não são afetados. A leitura autenticada do operador (painel) continua vendo o competidor. Escopo da API explicitado em F2-15 (2026-07-07), após o teste de aceitação constatar que a API retornava o competidor que a página pública já ocultava (mesma regra, superfície diferente).

C.5 Painel de gestão (módulo PAINEL)

Todas as telas do painel estão fichadas no Ap.3. O painel é único para todas as verticais e para os dois papéis (administrador e operador): o operador tem as telas de gestão de campeonatos; o administrador tem essas e mais duas (gestão de contas e auditoria). O painel segue o princípio de que tudo que precisa ser ajustado durante a operação tem interface própria, sem depender de desenvolvimento (ver bloco 11).

RF-PAINEL-001: Autenticação por conta nominal com papel

• Descrição: cada pessoa autorizada acessa o painel com a sua própria conta (login e senha própria); o público não tem acesso ao painel. Cada conta tem um papel (administrador ou operador) que define o que ela pode fazer, e uma conta desativada não entra. A senha é guardada apenas como hash, nunca em texto puro. Substitui a primeira versão deste requisito, que previa uma credencial única compartilhada (ADR-011 revisado): administrador e operador entram pela mesma porta autenticada, cada um com a sua credencial, sem acesso oculto que contorne a autenticação.
• Prioridade: Essencial
• Atores: Operador, Administrador
• H1: Dado um usuário com conta ativa e credencial válida, Quando faz login no painel, Então acessa as telas de gestão conforme o seu papel, e a sua sessão fica associada ao seu usuário; Quando um visitante sem credencial tenta acessar uma rota do painel, Então é barrado; Quando as credenciais estão erradas ou a conta está desativada, Então o acesso é negado.
• Notas: o papel administrador habilita, além de tudo que o operador faz, a gestão de contas (RF-PAINEL-011), a auditoria (RF-PAINEL-012) e o monitor de status das páginas (RF-PAINEL-013); o papel operador não vê essas três telas. Não há tela de gestão de campeonato vedada ao administrador: quem é administrador tem acesso a todas as telas do operador e às suas próprias.

RF-PAINEL-002: Assistente de cadastro, passo 1 (vertical e nome)

• Descrição: no primeiro passo do assistente, o operador escolhe a vertical e dá um nome ao campeonato.
• Prioridade: Essencial
• Atores: Operador
• H1: Dado o operador iniciando um novo campeonato, Quando seleciona a vertical (Series, Petrobras, MTB ou Kitesurf, ou outra cadastrada) e informa o nome, Então o sistema registra a vertical (com o seu perfil de identidade) e o nome, e habilita o passo 2.

RF-PAINEL-003: Assistente de cadastro, passo 2 (fontes e teste de conexão)

• Descrição: no segundo passo, o operador cola de uma vez o bloco de URLs que a Chronosat enviou (o documento de integração do evento inteiro, com os arquivos crews, racetimes e stagetimes de cada modalidade e trecho). O sistema extrai e classifica cada URL automaticamente pelo nome do arquivo, sem o operador precisar separar campo a campo, e aciona "testar conexão", que busca os arquivos e mostra uma pré-visualização ("achei N modalidades, N trechos, N competidores").
• Prioridade: Essencial
• Atores: Operador
• H1: Dado o operador com o bloco de URLs do evento, Quando cola o bloco e aciona "testar conexão", Então o sistema reconhece cada arquivo pelo padrão do nome e o associa à modalidade, tipo e trecho corretos, e exibe a contagem de modalidades, trechos e competidores encontrados; se uma URL for inválida ou inacessível, exibe qual falhou sem publicar; um arquivo de trecho ainda não iniciado (que retorna vazio) é aceito e passa a valer quando o trecho começar.
• Notas: o teste usa o mesmo proxy de leitura (RF-INGEST-001); o padrão do nome é {evento}_{modalidade}_{tipo}_{trecho}_{controle}.json. O operador pode voltar e adicionar ou trocar URLs depois de publicado (RF-CONFIG-003), por exemplo quando a Chronosat disponibiliza o arquivo de um novo trecho ao longo dos dias.

RF-PAINEL-004: Assistente de cadastro, passo 3 (publicar)

• Descrição: no terceiro passo, o operador publica o campeonato, que passa a aparecer na página pública da vertical.
• Prioridade: Essencial
• Atores: Operador
• H1: Dado um campeonato com passos 1 e 2 concluídos e teste de conexão bem-sucedido, Quando o operador publica, Então o evento fica disponível na página pública da vertical correspondente, E o estado inicial é o configurado (ao vivo ou aguardando).

RF-PAINEL-005: Controle de estado (ao vivo / encerrado)

• Descrição: o operador alterna o estado do campeonato entre ao vivo e encerrado.
• Prioridade: Essencial
• Atores: Operador
• H1: Dado um campeonato publicado, Quando o operador o marca como encerrado, Então a página pública para a atualização automática e exibe o indicador de encerrado; Quando o marca como ao vivo, a atualização automática volta.
• Notas: como cada leitura já fica gravada no banco (RF-INGEST-005), encerrar apenas para de buscar a origem (RF-PAINEL-009); a página continua no ar com o último estado salvo mesmo depois de a Chronosat retirar os dados da origem.

RF-PAINEL-006: Gestão de PDFs oficiais

• Descrição: o operador adiciona, nomeia e remove os PDFs oficiais do evento (penalidades, acumulado final), que aparecem na central de downloads pública. As duas formas concretas de fornecer o documento são link e upload de arquivo; o sistema é construído de forma aberta a outras formas de entrada (por exemplo um recebimento automático por webhook) sem retrabalho, caso venham a ser necessárias.
• Prioridade: Alta
• Atores: Operador
• H1: Dado um campeonato publicado, Quando o operador adiciona um PDF com título por link ou por upload de arquivo, Então ele aparece na central de downloads pública; Quando o remove, ele deixa de aparecer.
• Notas: a Sertões pediu que o sistema aceite várias formas de passar os documentos; link e upload cobrem o dia a dia, e a arquitetura fica pronta para acrescentar outras entradas (webhook, integração automática) quando fizer sentido (ver bloco 9).

RF-PAINEL-007: Ocultar competidor

• Descrição: o operador oculta manualmente um competidor da exibição pública.
• Prioridade: Média
• Atores: Operador
• H1: Dado um competidor exibido na página, Quando o operador o oculta no painel, Então ele deixa de aparecer na página pública, E pode ser reexibido pelo operador.
• Notas: distinto da ocultação vinda da origem (RF-REGRA-006); a ocultação manual é uma decisão do operador e é reversível.

RF-PAINEL-008: Lista de campeonatos

• Descrição: o painel lista os campeonatos cadastrados, com vertical, nome, estado e ações.
• Prioridade: Alta
• Atores: Operador
• H1: Dado um ou mais campeonatos cadastrados, Quando o operador abre o painel, Então vê a lista com vertical, nome, estado (rascunho / ao vivo / encerrado) e as ações de editar, publicar, alternar estado e gerenciar PDFs.

RF-PAINEL-009: Congelar e arquivar o evento

• Descrição: ao encerrar um evento, o sistema para de buscar a origem e marca o estado salvo no banco como final. Nada precisa ser copiado nesse momento: cada leitura já foi persistida ao longo da prova (RF-INGEST-005). O evento arquivado permanece publicado no seu endereço por vertical, ano e evento, servido do banco.
• Prioridade: Essencial
• Atores: Operador, Público (indireto)
• H1: Dado um evento ao vivo com leituras persistidas, Quando o operador o encerra, Então o sistema para de consultar a origem e a página passa a exibir permanentemente o último estado salvo, mesmo depois de a Chronosat retirar os dados da origem, E o evento continua acessível no seu endereço e listado na home da vertical; E se o operador NÃO encerrar antes de a origem sair do ar, o último estado salvo continua sendo servido do mesmo jeito, sem perda.
• Notas: o congelamento é uma marcação de estado, não uma cópia de dados; a proteção contra perda vem da persistência contínua (RF-INGEST-005), não do ato de encerrar.

RF-PAINEL-010: Criar evento de uma edição passada (retroativo)

• Descrição: o operador cadastra a página de um evento de um ano anterior fornecendo os dados daquela edição (o bloco de URLs, se a Chronosat ainda os servir, ou os arquivos correspondentes que a Sertões tenha guardado), gerando a página fixa e arquivada daquela edição, do mesmo jeito que um blog publica um post antigo. É o mesmo fluxo de cadastro de um evento novo, apenas com dados de uma prova já ocorrida.
• Prioridade: Média
• Atores: Operador
• H1: Dado o operador com os dados de uma edição passada, Quando cadastra o evento pelo assistente marcando-o como já encerrado, Então a página daquela edição é gerada, congelada e arquivada no endereço por vertical, ano e evento, E passa a aparecer na home junto às demais.
• Notas: reaproveita o assistente de cadastro (RF-PAINEL-002 a 004) e o congelamento (RF-PAINEL-009). O caminho principal do histórico é o arquivamento contínuo: todo evento que o sistema publica fica guardado para sempre (RF-PAINEL-009), então a home cresce naturalmente a cada evento; o retroativo é o complemento para trazer edições anteriores ao início do sistema, quando há dados para elas.

RF-PAINEL-011: Gestão de contas de usuário (administrador)

• Descrição: o administrador cria, edita, desativa e reativa as contas de usuário do painel. Ao criar ou editar uma conta ele define o login, o papel (administrador ou operador) e uma senha inicial; pode também redefinir a senha de uma conta existente (por exemplo quando o usuário esqueceu a sua). Desativar uma conta revoga o acesso sem apagar a conta nem o histórico do que ela já fez; reativar devolve o acesso. A senha informada é guardada apenas como hash. Esta tela existe só para o papel administrador; o operador não a vê.
• Prioridade: Essencial
• Atores: Administrador
• H1: Dado um administrador autenticado, Quando cria uma conta com login, papel e senha inicial, Então a conta passa a poder entrar no painel com o papel definido; Quando edita o papel de uma conta, Então o que aquela conta pode fazer muda de acordo; Quando desativa uma conta, Então ela deixa de conseguir entrar, sem perder o histórico já registrado, e pode ser reativada; Quando redefine a senha de uma conta, Então o usuário passa a entrar com a nova senha e a antiga deixa de valer; Quando um usuário com papel operador tenta abrir esta tela, Então é barrado.
• Notas: a senha nunca é exibida nem guardada em texto puro; a tela mostra login, papel e situação (ativa ou desativada) de cada conta. Não há autocadastro público: só o administrador cria contas.

RF-PAINEL-012: Auditoria de ações administrativas

• Descrição: o sistema registra num log consultável as ações sensíveis do painel, para que se saiba quem fez o quê e quando. São registrados no mínimo: entrada no painel (login bem-sucedido e tentativa negada), criação, edição, desativação e reativação de conta, mudança de papel e redefinição de senha. Cada registro guarda quem fez a ação (o usuário), o que foi feito, sobre o que (por exemplo qual conta), e o momento. O administrador consulta esse log no painel, do mais recente para o mais antigo. Esta tela existe só para o papel administrador.
• Prioridade: Alta
• Atores: Administrador
• H1: Dado um administrador que executa uma ação sensível (login, criação, edição, desativação, reativação de conta, mudança de papel ou redefinição de senha), Quando a ação acontece, Então fica gravado um registro com quem fez, o que fez, sobre o que e quando; Quando o administrador abre a tela de auditoria, Então vê esses registros em ordem do mais recente ao mais antigo; Quando um usuário com papel operador tenta abrir a auditoria, Então é barrado.
• Notas: o log de auditoria é somente de escrita e consulta, não é editável pelo painel (registro imutável). A redefinição de senha registra que a senha foi trocada, nunca o valor da senha.

RF-PAINEL-013: Monitor de status das páginas (sitemap, administrador)

• Descrição: o administrador acessa uma página de sitemap que lista as rotas das páginas principais do sistema e do site e mostra, para cada uma, se está no ar ou com erro. A lista é curada: uma rota representativa por área (a home global quando existir, a home de cada vertical, as rotas do painel, a verificação de saúde e as rotas âncora do site), nunca a enumeração de todas as páginas por evento (que produziria rotas demais e não ajudaria). Para cada rota o sistema faz uma verificação do lado do servidor (o próprio sistema consulta a rota) e exibe o código de resposta HTTP: 200 quando a página está no ar; 404, 503 ou qualquer 4xx ou 5xx sinalizado como erro, sempre com o código à vista. A verificação acontece quando a página carrega e pode ser refeita quando o administrador aciona "verificar de novo". Esta tela existe só para o papel administrador; o operador não a vê.
• Prioridade: Média
• Atores: Administrador
• H1: Dado um administrador na página de monitor de status, Quando a página carrega (ou o administrador aciona "verificar de novo"), Então o sistema consulta cada rota da lista curada e exibe o código de resposta HTTP de cada uma, com 200 mostrado como no ar e 4xx ou 5xx sinalizado como erro; Quando uma rota curada está no ar, Então aparece com 200; Quando uma rota da lista responde com erro (por exemplo 404 ou 503), Então aparece com o código do erro em destaque; Quando um usuário com papel operador tenta abrir esta tela, Então é barrado; E a lista nunca inclui uma rota por evento (só as rotas principais curadas).
• Notas: a lista de rotas monitoradas é configuração curada (uma entrada por área), não a enumeração dos eventos: adicionar uma vertical, uma área do painel ou uma âncora do site é acrescentar uma entrada na configuração, não escrever código novo (config-driven, alinhado ao ADR-010 e ao RF-CONFIG-001). A verificação é do lado do servidor: o próprio sistema faz a requisição às suas rotas e reporta o código. Esta fatia é uma verificação de status simples (código HTTP por rota); histórico de disponibilidade, gráficos de uptime e alertas automáticos ficam fora deste escopo (evolução futura). A tela vive junto das demais telas exclusivas do administrador, atrás do mesmo teste "é administrador?" que protege a gestão de contas (RF-PAINEL-011) e a auditoria (RF-PAINEL-012).

RF-PAINEL-014: Colunas visíveis da tabela por evento

• Descrição: o operador escolhe, por evento, quais colunas opcionais aparecem na tabela de classificação pública. São 11 colunas ocultáveis: Numeral, Categoria, (Pos)Categoria, Penalidades, Bônus, Largada, Parciais (Parc 1 a N, exclusiva do recorte de Trecho), Chegada, Velocidade média, Diferença anterior e Diferença líder. As colunas essenciais (Posição, Tripulação, Equipe e Veículo, Apurado/Tempo na especial e Tempo total/Tempo do trecho) nunca podem ser ocultadas. Além da escolha manual do operador, o sistema auto-oculta uma coluna opcional quando ela está vazia em todos os competidores do evento, exceto Penalidades, Bônus e Parciais, que nunca auto-ocultam (permanecem conforme a escolha manual do operador, para não "piscarem" durante o evento ao vivo enquanto os dados chegam). A escolha de colunas afeta também o seletor de visualização do trecho: com Parciais oculta, o preset "Parciais" some do seletor e o padrão passa a ser "completo".
• Prioridade: Média
• Atores: Operador, Público
• H1: Dado um evento, Quando o operador desmarca uma das 11 colunas opcionais no painel, Então essa coluna some da tabela pública (cabeçalho e células) sem afetar as colunas essenciais; Quando uma coluna opcional está vazia em todos os competidores e não é Penalidades, Bônus nem Parciais, Então ela some automaticamente da exibição; Quando Penalidades, Bônus ou Parciais estão vazias, Então continuam visíveis até o operador ocultá-las manualmente; E quando Parciais está oculta, o preset "Parciais" do seletor de visualização não aparece e o padrão passa a ser "completo".
• Notas: retroativo (funcionalidade em produção desde 2026-07-10 para as 10 colunas originais); o grupo Parciais entrou no conjunto ocultável e ficou fora da auto-ocultação em 2026-09-17, junto da correção de RF-PUB-004 (categoria dentro do trecho). Ficha completa das 11 colunas e da tela "Colunas da tabela" no Inventário de Artefatos (ART-SCR-02).

C.6 Multi-evento e multi-vertical (módulo CONFIG)

RF-CONFIG-001: Cadastro de verticais com perfil completo (o site do esporte)

• Descrição: o sistema mantém as verticais (Series, Petrobras, MTB, Kitesurf e futuras) com o perfil completo do site de cada uma, editável pelo operador: cor de destaque, marca, capa da home (título, subtítulo e imagem do hero), rótulos da hierarquia (modalidade, categoria e trecho, com valores padrão), regra de exibição da tripulação (piloto e navegador, dupla com os dois nomes em negrito, ou solo) e ordem na home global.
• Prioridade: Essencial
• Atores: Operador
• H1: Dado o conjunto de verticais, Quando o operador consulta ou ajusta uma vertical, Então vê e edita todos os campos do perfil (cor, marca, capa, rótulos, regra de tripulação, ordem), E a mudança reflete no site daquela vertical sem novo deploy, E uma nova vertical pode ser adicionada sem alteração de código.
• Notas: ver Ap.4 e bloco 11. O perfil é um conjunto de campos e uma regra de exibição com três valores; não há templates de layout por vertical nem personalização além destes campos (decisão de arquitetura, ADR-010).

RF-CONFIG-002: Múltiplos eventos simultâneos por vertical

• Descrição: o sistema suporta o evento vigente de cada vertical de forma independente; cada vertical exibe seu evento publicado.
• Prioridade: Essencial
• Atores: Operador, Público
• H1: Dado um evento publicado na Series e outro na MTB, Quando o público abre o site de cada vertical, Então cada um exibe seu próprio evento com sua identidade, sem interferência entre eles.

RF-CONFIG-003: Fontes e modalidades por evento

• Descrição: cada evento guarda suas URLs de origem por modalidade e por trecho, conforme entregue pela Chronosat. As modalidades de um evento são as que ele tiver, em qualquer quantidade: podem ser várias (no Jalapão são motos, utv e carros), pode ser uma só, e mudam de um evento para outro (uma edição pode ter caminhões, outra ter production, outra ser só de carro). O número de modalidades, categorias e trechos é sempre o do evento, nunca fixo. O rótulo de cada modalidade vem do arquivo crews quando disponível e pode ser confirmado ou ajustado pelo operador no painel.
• Prioridade: Essencial
• Atores: Operador
• H1: Dado um evento com uma ou mais modalidades quaisquer, Quando o operador cadastra as fontes, Então cada modalidade guarda suas URLs de crews, racetimes e stagetimes por trecho, com o seu rótulo, e o sistema lê a fonte correta conforme o filtro de modalidade, sem depender de uma lista fixa de modalidades no código.

RF-CONFIG-004: Vertical nova por configuração, nunca por cópia

• Descrição: o mesmo motor atende qualquer vertical que use o formato de dados da Chronosat: criar o site de um esporte novo é cadastrar uma vertical com o seu perfil (RF-CONFIG-001), sem novo desenvolvimento e sem duplicar o sistema. A vertical Petrobras é o primeiro caso concreto: nasce como configuração ao lado da Series, com identidade própria, provando o modelo.
• Prioridade: Alta
• Atores: Operador
• H1: Dado o motor no ar com uma vertical publicada, Quando o operador cadastra uma segunda vertical com o seu perfil e um evento dela, Então o site da nova vertical fica no ar com identidade, home e eventos próprios, E nenhuma linha de código foi alterada nem copiada para isso.
• Notas: a Sertões confirmou que todas as verticais usam a mesma Chronosat (ver bloco 9); se um esporte vier com um modelo de dados estruturalmente diferente, a diferença é absorvida por um adaptador no módulo de ingestão (ADR-012), não por uma cópia do sistema.

RF-CONFIG-005: Endereço permanente por vertical, ano e evento

• Descrição: cada evento tem um endereço estável e permanente no subdomínio de resultados, no padrão resultados.sertoes.com.br/<vertical>/<ano>/<evento> (ex.: /series/2026/parana), definido no cadastro e imutável depois de publicado. O nome do evento na URL (o slug) distingue eventos diferentes da mesma vertical no mesmo ano.
• Prioridade: Alta
• Atores: Operador, Público
• H1: Dado um evento cadastrado, Quando é publicado, Então recebe um endereço permanente no padrão vertical, ano e evento que não muda depois, E a home e as páginas da vertical no site apontam para esse endereço, E dois eventos da mesma vertical no mesmo ano têm endereços distintos.
• Notas: sustenta o arquivo permanente (RF-PAINEL-009) e a home (RF-PUB-015); o conjunto funciona como um blog, a home é a página de arquivo e cada evento é a página fixa daquela edição.

RF-CONFIG-006: Textos do site editáveis no painel

• Descrição: os textos fixos das páginas públicas (título da aba, chamadas da home global, itens do menu do cabeçalho, créditos e copyright do rodapé, rótulos de estado e de seção da página do evento e da home de cada vertical) são configuração, não código: o operador ou o administrador altera ou remove cada um pelo painel, sem deploy. Um catálogo reúne 39 chaves em quatro grupos (Home global, Cabeçalho e rodapé, Home de cada vertical, Página do evento); cada chave tem um valor padrão de fábrica e a marca removível (o campo em branco apaga o elemento da página) ou não removível (o campo em branco volta ao padrão). Há restauração do padrão por campo.
• Prioridade: Média
• Atores: Operador, Administrador
• H1: Dado um operador ou administrador autenticado no painel, Quando altera um texto em "Textos do site" e salva, Então a página pública correspondente exibe o novo texto no próximo carregamento sem reinício do sistema; Quando salva em branco um texto removível, Então o elemento some da página; Quando salva em branco um texto não removível, Então o texto volta ao padrão de fábrica; E Quando marca "restaurar padrão" num campo, Então o texto volta exatamente ao valor de fábrica.
• Notas: rota comum a operador e administrador, mesma precedência do perfil de vertical (RF-CONFIG-001); toda alteração é auditada (ação editar_textos); literais que continham marcação HTML no código de origem viraram dois campos no catálogo (prefixo e nome, linha 1 e linha 2), sem marcador de realce dentro do valor; os glifos de estado (confirmação e atualização) ficam fixos no template, fora do valor editável. Fora do escopo desta fatia: o crédito de desenvolvimento no rodapé (fixo, decisão da agência) e os rótulos de coluna de tabela e pódio (rótulos de dado, não texto institucional). Revisão de 2026-09-17: a chave evento.docs_vazio (aviso de ausência da antiga central de documentos) foi removida do catálogo porque o RF-PUB-008 deixou de ter estado vazio visível; o catálogo passou de 40 para 39 chaves.

C.7 Medição de audiência (módulo MEDIR)

Este módulo responde a uma pergunta que o primeiro evento grande no ar deixou sem resposta: quantas pessoas acompanharam. Ele tem duas metades que não se substituem. A metade externa entrega os números às plataformas de análise e de anúncios do cliente, que já medem o site institucional. A metade interna guarda, dentro do próprio sistema, o registro de cada acesso público e o exibe num painel para o operador, sem depender de consentimento de cookie, de bloqueador de anúncio nem de amostragem. Os dois números não batem, e não devem bater: o porquê está no ADR-013. Nenhuma tela do painel entra na audiência, porque painel não é público.

RF-MEDIR-001: Medição externa apenas nas páginas públicas, ligada pela configuração do painel

• Descrição: os três tipos de página pública do sistema (home global, home da vertical e página do evento) injetam a etiqueta de medição da plataforma de análise e o pixel da plataforma de anúncios, lidos da configuração de rastreamento gravada no banco (RF-MEDIR-002). Nenhuma tela do painel injeta qualquer das duas. Cada destino tem a sua chave própria e o seu próprio interruptor: destino desligado, ou com identificador em branco, não injeta nada. A leitura da configuração vem de um estado carregado em memória na partida e recarregado a cada gravação, de modo que servir a página não faz consulta ao banco por causa da medição.
• Prioridade: Essencial
• Atores: Público / fã (gera a medição), Administrador (liga e configura), Sustentação (primeira carga)
• Entrada: a configuração de rastreamento vigente.
• Saída: o HTML público com as marcações de medição, ou sem nenhuma quando o destino está desligado.
• H1: Dado os dois destinos ligados e com identificador preenchido, Quando o público abre a home global, a home de uma vertical ou a página de um evento, Então o HTML servido traz exatamente uma etiqueta da plataforma de análise e exatamente um pixel da plataforma de anúncios, E 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.
• Notas: este requisito é violado quando uma tela do painel serve uma das marcações, quando uma página pública serve a mesma marcação duas vezes, ou quando um destino desligado continua injetando. Os tipos de página pública são exatamente três; a rota de documento entrega um arquivo, não um documento HTML, e por isso é medida pelo registro interno (RF-MEDIR-006), nunca por marcação de página.

RF-MEDIR-002: Tela de integrações de medição (administrador)

• Descrição: o administrador liga, configura e testa as integrações de medição numa tela própria do painel, sem depender de desenvolvimento nem de novo deploy. A tela guarda, por destino: o interruptor de ligado ou desligado, o identificador público do destino, e, quando o destino exige credencial para envio pelo servidor, essa credencial. A credencial é de escrita apenas: a tela exibe somente uma máscara do que está guardado, nunca o valor, e só grava quando um valor novo é enviado; enviar o campo em branco mantém o valor anterior. A tela oferece a ação de enviar um evento de teste a cada destino, identificado como teste, para que a chegada seja conferida na ferramenta do próprio destino antes de o público ser medido. Toda gravação e todo envio de teste ficam registrados na auditoria (RF-PAINEL-012).
• Prioridade: Essencial
• Atores: Administrador
• Entrada: interruptores, identificadores e credencial informados pelo administrador.
• Saída: a configuração de rastreamento gravada e o estado em memória recarregado.
• H1: Dado o administrador na tela de integrações, Quando ele liga um destino, informa o identificador e grava, Então a página pública passa a injetar aquela marcação sem reinício do sistema, E a tela volta a exibir a credencial apenas mascarada, E a ação aparece na auditoria com quem gravou e quando, E o operador que tenta abrir a tela é barrado.
• Notas: violado quando a tela devolve a credencial em texto legível, quando gravar com o campo de credencial em branco apaga a credencial guardada, quando a gravação exige reinício para valer, ou quando o operador alcança a tela. Configuração de ambiente existe apenas como semente da primeira carga: se a tabela estiver vazia na partida e a semente existir, ela cria a linha uma única vez e nunca mais é lida. O campo de credencial segue o padrão de todo campo de senha do sistema, com o botão de ver o que foi digitado.

RF-MEDIR-003: Eventos de interação com nome em português, nos dois destinos

• Descrição: além da visualização de página, a página pública envia aos dois destinos um evento por interação do público, com nome em português e com os parâmetros do recorte que estava sendo visto. Os eventos são exatamente estes sete, e não uma lista de exemplos: pagina_de_evento_vista (a visualização de página, com os parâmetros do recorte), troca_de_modalidade, troca_de_trecho, troca_de_categoria, busca_de_competidor, parciais_abertas e documento_oficial_aberto. Todo evento carrega os parâmetros site (com o valor fixo que identifica este sistema), evento e vertical, e, quando existirem no recorte, modalidade, trecho e categoria. Os eventos ligados a troca de filtro, a busca e à abertura de documento acontecem imediatamente antes de uma navegação nova, então são enviados por transporte de sinal, que sobrevive à saída da página.
• Prioridade: Essencial
• Atores: Público / fã, Operador (lê o resultado no destino)
• Entrada: a interação do público e o recorte vigente da página.
• Saída: o evento entregue aos dois destinos.
• H1: Dado a medição externa ligada, Quando o público abre a página de um evento, troca a modalidade, troca o trecho, troca a categoria, busca um competidor, abre as parciais e abre um documento oficial, Então cada uma das sete ações produz no destino de análise um evento com exatamente o nome correspondente da lista acima, E todo evento carrega o parâmetro site com o valor que identifica este sistema, E o evento de troca de filtro chega mesmo quando a navegação acontece logo em seguida.
• Notas: violado quando qualquer nome de evento sai diferente dos sete, quando um evento chega sem o parâmetro site, ou quando a troca de filtro se perde por causa da navegação. O parâmetro site existe porque a propriedade de análise é compartilhada com o site institucional do cliente (ADR-014) e os caminhos de endereço colidem entre os dois.

RF-MEDIR-004: A atualização ao vivo não conta como visualização de página

• Descrição: durante um evento ao vivo a página se atualiza sozinha em ciclo curto, pedindo a mesma rota de novo. Esse ciclo não é uma visita nova e não pode ser contado como visualização de página em destino algum. Ele produz um evento próprio de nome atualizacao_ao_vivo, enviado aos destinos externos apenas uma vez por carregamento de página (no primeiro ciclo que trocar o conteúdo), para não inflar a contagem de um público que deixa a aba aberta durante horas. No registro interno (RF-MEDIR-006) cada ciclo é gravado, com tipo de acesso próprio, porque ali não há cota a proteger e a série completa é o que permite ver o público minuto a minuto.
• Prioridade: Essencial
• Atores: Público / fã, Operador (lê a distinção no painel)
• H1: Dado a página de um evento ao vivo aberta por mais de dez ciclos de atualização, Quando os ciclos acontecem, Então nenhuma visualização de página adicional é registrada em qualquer dos dois destinos externos, E exatamente um evento atualizacao_ao_vivo é enviado aos destinos por carregamento de página, E o registro interno contém um registro do tipo atualização para cada ciclo ocorrido.
• Notas: violado quando o contador de visualizações do destino cresce com a página parada, quando o segundo ciclo em diante envia evento externo, ou quando o registro interno perde ciclos. A razão da amostragem está no ADR-017. O ciclo se distingue da navegação porque a requisição de atualização vem marcada como pedido de conteúdo pelo próprio código da página.

RF-MEDIR-005: Envio da visualização pelo servidor, sem contar duas vezes

• Descrição: a visualização de página pública é enviada também pelo servidor ao destino de anúncios, para sobreviver a bloqueador de anúncio e a navegador que recusa marcação de terceiro. O mesmo evento sai pelos dois caminhos (navegador e servidor) carregando o mesmo identificador de evento, que é o que permite ao destino contar uma vez só. O envio pelo servidor sai pela mesma fila assíncrona do registro interno (RF-MEDIR-007) e nunca entra no caminho de resposta da página. Sem credencial configurada, o envio pelo servidor simplesmente não acontece, e o envio pelo navegador continua.
• Exceção declarada de dado (ver F.4): para que a plataforma de anúncios aceite o evento vindo do servidor, ele precisa ir acompanhado de dado de correspondência, sem o qual a plataforma o descarta. São três, e apenas três: o endereço de rede do visitante, a assinatura do navegador dele e, quando existir, o identificador de navegador que o próprio pixel do cliente já gravou. Esse dado é repassado, nunca guardado: ele sai na chamada e não entra em nenhuma coluna da série de acessos, que continua guardando apenas o identificador de visitante do dia (RF-MEDIR-008). O destino é o pixel do próprio cliente, sob a política de privacidade do cliente, exatamente como já acontece no site institucional dele.
• Prioridade: Alta
• Atores: Público / fã (indireto), Administrador (configura a credencial)
• H1: Dado a credencial de envio pelo servidor configurada, Quando o público abre uma página pública, Então a mesma visualização chega ao destino pelos dois caminhos com o mesmo identificador de evento, E a ferramenta do destino a contabiliza uma única vez, E o evento é aceito pela plataforma em vez de descartado por falta de correspondência, E nenhuma das três informações de correspondência aparece em qualquer coluna da série de acessos, E a resposta da página não espera o envio, E sem credencial configurada nenhum envio pelo servidor é tentado.
• Notas: violado quando a contagem do destino dobra, quando a plataforma descarta o evento por falta de correspondência, quando qualquer informação de correspondência é gravada na série, quando o tempo de resposta da página cresce com o envio ligado, ou quando a falta de credencial produz erro em vez de silêncio. Apenas a visualização de página sai pelo servidor; os eventos de interação ficam só no navegador, pelo motivo do ADR-015.

RF-MEDIR-006: Registro próprio de cada acesso público

• Descrição: o sistema grava, no próprio banco, uma linha por acesso público, formando a série de audiência que o painel do operador consulta. A linha guarda: o evento e a vertical, o tipo de página (home global, home da vertical, página de evento ou documento), a rota pedida (o caminho mais a consulta normalizada, ou o caminho do arquivo quando o acesso é a um documento), o recorte pedido (modalidade, trecho, categoria e o texto buscado, quando houver), o instante em tempo universal, o dia e a hora locais já desnormalizados para agregação barata, o tipo de dispositivo, a família do navegador, o grupo de origem da referência, o país e a unidade federativa quando existirem, o identificador de visitante do dia (RF-MEDIR-008), o tipo de acesso (navegação, atualização ou documento), o momento do evento no instante do acesso (ao vivo ou repetição, nulo nas homes, que não pertencem a evento algum) e a proveniência do próprio registro (gravado pelo sistema ou importado dos registros do servidor web, e neste caso com o arquivo e o resumo da linha de origem). Nenhum endereço de rede e nenhuma assinatura de navegador são guardados de forma legível. A ficha completa da entidade está no bloco 5 (E.4) e no companheiro Inventário de Artefatos.
• Prioridade: Essencial
• Atores: Público / fã (gera), Operador e Administrador (consultam)
• Entrada: a requisição pública atendida.
• Saída: uma linha na série de acessos.
• H1: Dado a página de um evento servida ao público, Quando ela é aberta, Então nasce exatamente um registro de acesso 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, E nenhuma coluna da série guarda endereço de rede ou assinatura de navegador em texto legível, E abrir um documento oficial gera um registro do tipo documento cuja rota é o caminho do arquivo, E o mesmo acesso a uma home nasce com o momento nulo, sem erro.
• Notas: violado quando um acesso público não gera linha, quando uma coluna carrega endereço de rede legível, quando a abertura de documento não é distinguida da navegação, ou quando o acesso a uma home exige um momento que não existe. A série é o registro, nunca um contador somado por cima: a razão está no ADR-018.

RF-MEDIR-007: A gravação do acesso nunca atrasa a página

• Descrição: a gravação do acesso acontece fora do caminho de resposta. Cada acesso entra numa fila em memória e a fila é descarregada em lote, numa única transação com comando preparado, a cada intervalo curto ou ao atingir um número de registros, o que vier primeiro. A página nunca espera a gravação. A fila tem teto: ao atingi-lo, os registros excedentes são descartados e o descarte é contado, e esse contador fica visível para a sustentação e no próprio painel de audiência, para que perda de registro seja um número conhecido e não um silêncio. Sob nenhuma circunstância a fila cheia vira erro para o público.
• Prioridade: Essencial
• Atores: Público / fã (indireto), Sustentação
• H1: Dado o registro de audiência ligado, Quando a página do evento recebe duzentas requisições por segundo durante trinta segundos, Então o tempo de resposta no percentil noventa e cinco não piora mais de dez por cento contra a mesma medição com o registro desligado, E nenhuma requisição falha, E se a fila atinge o teto os registros excedentes são descartados e o contador de descarte cresce, sem erro ao público.
• Notas: violado quando a página espera a gravação, quando a piora passa de dez por cento, quando a fila cheia derruba requisição, ou quando o descarte acontece sem ser contado.

RF-MEDIR-008: Visitante único do dia, sem identificar pessoa

• Descrição: para contar pessoas e não apenas acessos, cada registro guarda um identificador de visitante do dia, calculado por uma função de resumo criptográfico sobre um segredo do dia somado ao endereço de rede e à assinatura do navegador, guardado truncado. O segredo muda a cada dia e não é preservado além do dia a que serve, o que torna o identificador irreversível e impede que dois dias sejam ligados à mesma pessoa. O endereço de rede nunca é gravado. O sistema não cria cookie próprio para isso. Por construção, único é único do dia, e o painel diz isso ao leitor em vez de somar dias e chamar o resultado de pessoas.
• Prioridade: Essencial
• Atores: Público / fã (indireto), Operador (lê a contagem)
• H1: Dado dois acessos do mesmo dispositivo no mesmo dia, Quando os registros nascem, Então os dois trazem o mesmo identificador de visitante do dia, E o mesmo dispositivo no dia seguinte traz identificador diferente, E nenhuma coluna do banco permite recuperar o endereço de rede a partir do identificador, E nenhum cookie é criado pelo sistema para esse fim.
• Notas: violado quando o identificador sobrevive à virada do dia, quando o segredo do dia é guardado, ou quando aparece cookie próprio de medição. É o que sustenta o RNF-PRIV-001. Na importação de registros antigos (RF-MEDIR-016) o segredo não pode ser o do dia corrente, porque as linhas são de outros dias: usa-se um segredo derivado do dia do próprio arquivo, gerado no momento da importação e descartado ao fim dela, do mesmo modo que o segredo do dia vivo. Por isso a repetibilidade da importação não se apoia neste identificador, e sim na proveniência da linha.

RF-MEDIR-009: O que não é audiência não entra na contagem

• Descrição: quatro classes de requisição tocam as rotas públicas sem serem público, e nenhuma delas gera registro de acesso. São exatamente estas: requisições originadas da própria máquina do sistema, as verificações periódicas de saúde e o monitor interno de rotas, os agentes automatizados reconhecidos pela assinatura do navegador, e as requisições que chegam com sessão de painel ativa. A exclusão é por ORIGEM da requisição, nunca por rota. As duas primeiras classes são reconhecidas pelo endereço de origem repassado pelo servidor web, que nelas é de retorno local ou está ausente, mais o cabeçalho próprio que o monitor interno envia. Excluir por rota seria um defeito, e não um detalhe: as rotas que o monitor verifica são a raiz e a home de uma vertical, que são páginas públicas legítimas e representam audiência real; barrá-las apagaria público de verdade da contagem. O requisito PROÍBE nominalmente que qualquer uma das quatro gere registro, seja contada como pessoa, apareça em qualquer número do painel de audiência ou entre em qualquer exportação.
• Prioridade: Essencial
• Atores: Público / fã (contraste), Sustentação
• H1: Dado uma verificação de saúde, uma requisição da própria máquina, um agente automatizado reconhecido e uma requisição com sessão de painel ativa, Quando cada uma toca uma rota pública, Então nenhuma das quatro gera registro de acesso, E um acesso do público à mesma rota que o monitor verifica gera exatamente um registro, E nenhum número do painel nem nenhuma exportação inclui as quatro.
• Notas: violado quando qualquer das quatro aparece em qualquer número, e igualmente violado quando um acesso real do público à raiz ou à home de uma vertical deixa de ser contado por causa da exclusão. A lista é fechada e nominal, não ilustrativa: uma classe nova de exclusão exige alterar este requisito.

RF-MEDIR-010: Retenção configurável da série de acessos

• Descrição: a série de acessos não expira por padrão: a janela de retenção nasce em zero (sem prazo, nunca remove), porque a série é o histórico plurianual de audiência do cliente e serve de comparação entre edições e anos. A limpeza roda uma vez por dia dentro do próprio processo do sistema, sem agendador externo; com a janela em zero ela roda e não remove nada, e só passa a remover quando a janela for ajustada pela configuração para um valor maior que zero (por exemplo, vinte e quatro meses), sem novo deploy.
• Prioridade: Alta
• Atores: Sustentação, Administrador
• H1: Dado a janela de retenção no valor de fábrica (zero, sem prazo), Quando a limpeza diária roda, Então nenhum registro é removido por idade; Dado a janela ajustada pela configuração para um valor maior que zero, Quando a limpeza diária roda, Então todo registro mais antigo que essa janela deixa de existir, E nenhum registro dentro da janela é removido, E alterar a janela pela configuração muda o alcance da próxima limpeza sem novo deploy.
• Notas: violado quando o valor de fábrica (zero) remove algum registro, quando um registro dentro de uma janela configurada some, quando um registro fora de uma janela configurada sobrevive a uma execução, ou quando mudar a janela exige deploy.

RF-MEDIR-011: Painel de audiência, a visão do evento

• Descrição: o painel tem uma tela de audiência, alcançável pelos dois papéis, em que se escolhe um evento e se lê a sua audiência inteira. A tela apresenta: pessoas (visitantes únicos por dia, somados, com a nota explícita de que único é único do dia) e acessos, a série por dia e a série por hora com o pico destacado (a hora de maior número de pessoas), a divisão entre acesso ao vivo e repetição, a divisão por tipo de dispositivo, a divisão por família de navegador, a divisão por país e unidade federativa quando existirem, a divisão por tipo de página, e a divisão por origem do registro (gravado pelo sistema ou importado dos registros do servidor web). Os gráficos são desenhados pelo próprio sistema, sem biblioteca externa pesada, porque o sistema não tem empacotador de código.
• Prioridade: Essencial
• Atores: Operador, Administrador
• H1: Dado um evento com acessos registrados, Quando o operador abre a tela de audiência e escolhe o evento, Então vê pessoas e acessos, a série por dia, a série por hora com o pico destacado, a divisão entre ao vivo e repetição, por dispositivo, por navegador, por tipo de página e por origem do registro, E a tela declara que único é do dia, E a tela abre igualmente para o papel de administrador, E nenhuma biblioteca externa de gráfico é carregada.
• Notas: violado quando uma dessas divisões falta, quando a tela some para um dos dois papéis, ou quando a palavra pessoas aparece sem a nota do dia.

RF-MEDIR-012: Painel de audiência, o agora

• Descrição: para a operação durante a prova, a tela de audiência abre com um bloco de tempo presente: quantas pessoas estiveram na página nos últimos cinco minutos, em que páginas e em que recortes elas estão, e quantos desses acessos são atualização ao vivo. O bloco se atualiza sozinho enquanto a tela fica aberta e é o primeiro número que o operador vê.
• Prioridade: Alta
• Atores: Operador, Administrador
• H1: Dado acessos gravados nos últimos cinco minutos, Quando o operador abre a tela de audiência, Então o bloco do agora mostra o número de pessoas dessa janela, as páginas e recortes em que estão e quantos acessos são de atualização ao vivo, E o bloco se atualiza sozinho com a tela aberta, E com nenhum acesso na janela ele mostra zero em vez de erro ou tela vazia.
• Notas: violado quando o bloco exige recarregar a página, quando a janela vazia quebra a tela, ou quando o agora conta acessos e os chama de pessoas.

RF-MEDIR-013: Painel de audiência, de onde vem e o que procuram

• Descrição: a tela de audiência mostra de onde o público chegou e o que ele procurou. De onde: a origem da referência agrupada por domínio, em grupos nominais (instagram, facebook, whatsapp, site_do_cliente, motor_de_busca, direto e outros), onde direto é a ausência de referência. O que procuram: as buscas mais feitas (apenas o texto digitado, sem qualquer ligação com quem digitou), os documentos oficiais mais abertos, e o ranking dos recortes mais vistos (modalidades, trechos e categorias), cada um com a sua contagem.
• Prioridade: Alta
• Atores: Operador, Administrador
• H1: Dado acessos com referências de origens distintas, buscas feitas e documentos abertos, Quando o operador abre a tela de audiência, Então vê a origem agrupada exatamente nos sete grupos nominais, as buscas mais feitas, os documentos mais abertos e o ranking de modalidades, trechos e categorias, E cada item traz a sua contagem, E nenhum texto de busca aparece ligado a um visitante.
• Notas: violado quando um grupo de origem foge da lista dos sete, quando um texto buscado aparece ao lado de um identificador de visitante, ou quando um ranking sai sem contagem.

RF-MEDIR-014: Painel de audiência, permanência aproximada e comparação entre eventos

• Descrição: a tela calcula a permanência aproximada de cada visitante do dia como a distância entre o seu primeiro e o seu último acesso naquele dia e naquele evento, e apresenta a distribuição dessa permanência, sempre rotulada como aproximada. E permite comparar eventos: escolhidos dois ou mais, a mesma tabela os apresenta lado a lado, com as mesmas métricas e a mesma régua, para que a audiência de uma prova se leia contra a de outra.
• Prioridade: Alta
• Atores: Operador, Administrador
• H1: Dado dois eventos com acessos registrados, Quando o operador escolhe a comparação, Então os dois aparecem lado a lado na mesma tabela com as mesmas métricas, E a comparação aceita ao menos dois eventos ao mesmo tempo, E a permanência é apresentada com o rótulo de aproximada, E um visitante com um único acesso no dia entra na distribuição sem quebrar o cálculo.
• Notas: violado quando a comparação aceita só um evento, quando as métricas diferem entre as colunas, ou quando a permanência aparece sem o rótulo de aproximada. Permanência é aproximada por construção: o sistema mede a distância entre acessos, não o tempo com a aba em foco.

RF-MEDIR-015: Exportação da audiência em arquivo de planilha

• Descrição: tudo que a tela mostra pode sair em arquivo de valores separados por vírgula, em dois níveis: o agregado (os números consolidados do evento, prontos para a prestação de contas a patrocinador) e o detalhe por dia e por hora. A exportação respeita o recorte escolhido na tela e os números do arquivo conferem com os da tela.
• Prioridade: Alta
• Atores: Operador, Administrador
• H1: Dado um evento selecionado na tela de audiência, Quando o operador pede a exportação, Então recebe um arquivo do agregado e um arquivo do detalhe por dia e hora, E os totais do arquivo conferem com os exibidos na tela, E o recorte escolhido na tela vale no arquivo.
• Notas: violado quando um total do arquivo diverge do da tela, ou quando o arquivo ignora o recorte escolhido.

RF-MEDIR-016: Importação dos registros de acesso já gravados pelo servidor web

• Descrição: os acessos anteriores à existência deste módulo existem apenas nos registros que o servidor web guarda por alguns dias. Enquanto esses arquivos existirem, o sistema os importa para a mesma série de acessos, preenchendo o que der para preencher e marcando cada linha com a origem de registro de servidor, para que o painel nunca confunda dado importado com dado gravado pelo sistema. Na importação, um acesso cuja referência é igual ao próprio endereço pedido é classificado como atualização, e os demais como navegação. Agentes automatizados reconhecidos ficam de fora, como no registro vivo. A importação é repetível por proveniência, não por semelhança de conteúdo: cada linha importada guarda o nome do arquivo de origem e o resumo criptográfico da linha bruta, e um índice único parcial sobre esses dois campos (válido apenas para as linhas importadas) impede que a mesma linha do mesmo arquivo entre duas vezes. O identificador de visitante do dia não serve de chave aqui, porque na importação ele é calculado com um segredo derivado do dia do arquivo, gerado na hora e descartado ao fim, e dois acessos distintos do mesmo dispositivo no mesmo dia compartilham esse identificador de propósito.
• Prioridade: Média
• Atores: Sustentação (executa), Operador e Administrador (leem o resultado)
• H1: Dado os arquivos de registro do servidor web de um período ainda disponível, Quando a importação roda, Então os acessos daquele período aparecem na tela de audiência marcados como vindos do registro do servidor, E rodar a importação duas vezes sobre o mesmo arquivo não aumenta a contagem em uma única linha, E dois acessos legítimos e distintos do mesmo visitante no mesmo dia continuam sendo duas linhas, E nenhum agente automatizado reconhecido entra na contagem, E o painel exibe lado a lado a origem de cada número.
• Notas: violado quando a segunda execução duplica, quando a proteção contra duplicata come acessos legítimos repetidos do mesmo visitante, quando dado importado se mistura sem distinção ao gravado pelo sistema, ou quando agente automatizado entra. A classificação por referência igual ao endereço pedido é uma aproximação declarada, porque o registro do servidor não guarda a marca que o sistema usa no registro vivo; a origem de servidor existe justamente para que essa aproximação nunca seja lida como medição direta.

RF-MEDIR-017: Aviso de medição no rodapé público

• Descrição: o rodapé das páginas públicas traz um aviso curto de que o sistema mede a audiência de forma anônima, com vínculo para a política de privacidade do cliente (ADR-019). Como o catálogo de textos não aceita marcação dentro do valor, o aviso ocupa duas chaves, no mesmo padrão já usado pelas demais chaves que precisaram ser quebradas: uma com o texto do aviso e outra com o endereço da política. Ambas são editáveis no painel (RF-CONFIG-006) e removíveis, com efeitos distintos e declarados: esvaziar a chave do texto remove o aviso inteiro da página, e esvaziar apenas a do endereço mantém o aviso visível sem vínculo. O aviso nunca aparece nas telas do painel.
• Prioridade: Média
• Atores: Público / fã, Operador (edita o texto)
• H1: Dado as duas chaves com os seus valores de fábrica, Quando o público abre qualquer página pública, Então o rodapé exibe o aviso de medição com vínculo para a política de privacidade do cliente, E esvaziada a chave do texto pela tela de textos o aviso some da página sem novo deploy, E esvaziada apenas a chave do endereço o aviso continua visível sem vínculo, E o aviso não aparece em nenhuma tela do painel.
• Notas: violado quando o aviso sobrevive à chave de texto esvaziada, quando esvaziar o endereço apaga o aviso inteiro, quando aparece no painel, ou quando exige deploy para mudar. A chave do endereço aceita apenas endereço de página, e o valor vigente é o da política confirmada no ADR-019.

4. Requisitos Não-Funcionais

5. Modelo de Dados

O sistema guarda no banco a configuração das verticais e dos eventos E o estado mais recente dos dados de cronometragem de cada evento: cada leitura bem-sucedida da Chronosat é gravada por cima da anterior (RF-INGEST-005), com o payload bruto preservado. O banco é a fonte de verdade das páginas públicas; ao encerrar um evento, o estado salvo é apenas marcado como final. O Inventário de Artefatos (companheiro) traz o checklist de provisionamento destas entidades.

E.1 Entidades persistidas (configuração)

erDiagram
    VERTICAL ||--o{ EVENTO : "tem"
    EVENTO ||--o{ FONTE : "configura"
    EVENTO ||--o{ PDF : "publica"
    EVENTO ||--o{ OCULTACAO : "registra"
    EVENTO ||--o{ DADOS_EVENTO : "persiste leituras"
    USUARIO ||--o{ EVENTO : "cadastra"
    USUARIO ||--o{ AUDITORIA : "gera"

    VERTICAL {
        id pk
        slug "series / petrobras / mtb / kitesurf"
        nome
        cor_destaque "ex E96409"
        marca "logo/identidade"
        hero_titulo "capa da home"
        hero_subtitulo
        hero_imagem
        rotulo_modalidade "default Modalidade"
        rotulo_categoria "default Categoria"
        rotulo_trecho "default Etapa"
        regra_tripulacao "piloto_navegador / dupla / solo"
        ordem_home
    }
    EVENTO {
        id pk
        vertical_id fk
        nome "ex Sertoes Series Parana"
        evento_chronosat "ex jalap26"
        ano "ex 2026"
        slug "ex parana (endereco)"
        estado "rascunho / ao_vivo / encerrado"
        criado_em
    }
    FONTE {
        id pk
        evento_id fk
        modalidade "codigo dinamico por evento"
        tipo "crews / racetimes / stagetimes"
        trecho "null exceto stagetimes"
        url
    }
    PDF {
        id pk
        evento_id fk
        titulo
        url_ou_arquivo
        ordem
    }
    OCULTACAO {
        id pk
        evento_id fk
        numeral
        ativo
    }
    DADOS_EVENTO {
        id pk
        evento_id fk
        modalidade
        tipo "crews / racetimes / stagetimes"
        trecho "null exceto stagetimes"
        payload_bruto "JSON como veio da origem"
        lido_em "momento da ultima leitura"
    }
    USUARIO {
        id pk
        login "unico"
        hash_senha "hash, nunca texto puro"
        papel "administrador / operador"
        ativo "conta desativavel sem apagar"
        criado_em
        atualizado_em
    }
    AUDITORIA {
        id pk
        usuario_id fk "quem fez (null se login negado)"
        acao "login / login_negado / criar_conta / editar_conta / desativar_conta / reativar_conta / mudar_papel / redefinir_senha"
        alvo "sobre o que (ex id da conta afetada)"
        detalhe "descricao curta, nunca a senha"
        registrado_em
    }

E.2 Dados de cronometragem (persistidos a cada leitura)

Durante o evento ao vivo, cada leitura bem-sucedida de um arquivo da Chronosat é gravada em DADOS_EVENTO como o estado mais recente daquela fonte (evento, modalidade, tipo e trecho), com o payload bruto preservado como veio da origem (RF-INGEST-005). A página pública lê sempre do banco; a normalização (cruzamento pela chave numeral, regras de interpretação) acontece na exibição, o que permite melhorar a renderização no futuro e re-renderizar eventos antigos sem depender da origem (ADR-012). Ao encerrar o evento, o sistema apenas para de buscar; o estado salvo passa a ser o resultado final permanente (RF-PAINEL-009). O campo estado de EVENTO registra o encerramento; não existe cópia separada de congelamento. O catálogo completo de campos de cada arquivo está no Ap.1, e as regras de interpretação no Ap.2.

E.3 Contas de usuário e auditoria (acesso ao painel)

A entidade USUÁRIO guarda cada conta nominal de acesso ao painel: login (único), hash_senha (a senha guardada apenas como hash, nunca em texto puro), papel (administrador ou operador, dois valores, sem matriz de permissões além disso, ADR-011), ativo (uma conta desativada não entra, e desativar não apaga a conta nem o histórico), e os momentos de criação e atualização. Só o administrador cria e edita contas (RF-PAINEL-011); não há autocadastro público. O papel decide o que a sessão pode fazer: um único teste "é administrador?" separa as duas telas exclusivas do administrador (gestão de contas e auditoria) das demais, que ambos os papéis acessam.

A entidade AUDITORIA guarda o registro imutável das ações sensíveis (RF-PAINEL-012): usuario_id (quem fez; nulo quando o registro é uma tentativa de login negada), acao (login, login negado, criar/editar/desativar/reativar conta, mudar papel, redefinir senha), alvo (sobre o que, por exemplo a conta afetada), detalhe (descrição curta, nunca a senha) e o momento. É gravada e consultada, nunca editada pelo painel; a consulta é do administrador, do mais recente para o mais antigo.

E.4 Série de acessos (audiência)

Referenciada pelo módulo MEDIR (C.7) e pelo companheiro Inventário de Artefatos. A audiência é guardada como série, uma linha por acesso, e nunca como contador somado por cima (ADR-018): é a série que permite abrir recortes novos sobre o passado (por hora, por categoria, por origem) sem ter medido esse recorte antes.

erDiagram
    EVENTO ||--o{ ACESSO : "recebe"
    ACESSO {
        id pk
        evento_id fk "nulo nas homes"
        vertical "slug, nulo na home global"
        tipo_pagina "home_global / home_vertical / evento / documento"
        rota "caminho mais query normalizada; caminho do arquivo quando documento"
        modalidade "recorte pedido, quando houver"
        trecho
        categoria
        busca "texto procurado, quando houver"
        instante_utc "momento do acesso"
        dia_local "AAAA-MM-DD em Sao Paulo"
        hora_local "0 a 23 em Sao Paulo"
        dispositivo "celular / tablet / computador"
        navegador "familia apenas"
        origem_referencia "instagram / facebook / whatsapp / site_do_cliente / motor_de_busca / direto / outros"
        pais "previsto, vazio ate a camada de rede existir"
        uf "previsto, vazio ate a camada de rede existir"
        visitante_dia "resumo truncado, segredo do dia descartado"
        tipo_acesso "navegacao / atualizacao / documento"
        momento "ao_vivo / replay; NULO nas homes, que nao tem evento"
        origem "app / log_nginx"
        arquivo "nome do arquivo de origem; so quando origem log_nginx"
        linha_hash "resumo da linha bruta; so quando origem log_nginx"
    }
    CONFIG_RASTREAMENTO {
        destino pk "analise / anuncios"
        ligado "interruptor por destino"
        identificador "id publico do destino"
        credencial "so escrita, nunca devolvida"
        atualizado_em
        atualizado_por fk "USUARIO que gravou"
    }

A entidade ACESSO é escrita apenas por acréscimo: nenhuma linha é alterada depois de gravada, e a agregação (pessoas por dia, pico por hora, permanência aproximada, ranking de recortes) é calculada na consulta, não guardada. Os índices que sustentam o painel são o composto por evento e dia local, e o composto por evento e instante. A retenção não expira por padrão (zero, o valor de fábrica), porque a série é o histórico plurianual de audiência do cliente; configurável para um valor maior que zero quando fizer sentido, por exemplo vinte e quatro meses (RF-MEDIR-010).

Três campos merecem regra explícita. O campo rota guarda o caminho pedido mais a sua consulta normalizada, e no acesso do tipo documento guarda o caminho do arquivo aberto: é ele que responde "qual documento foi aberto" no ranking de documentos (RF-MEDIR-013) e é parte do que identifica o acesso. O campo momento é nulo nas homes, porque home não pertence a um evento e portanto não tem estado de prova a registrar; ele é obrigatório apenas no acesso a página de evento e a documento. E a repetibilidade da importação não se apoia no identificador de visitante, e sim na proveniência: origem distingue o que o sistema gravou do que foi importado, e quando a origem é o registro do servidor web as colunas arquivo e linha_hash (o resumo criptográfico da linha bruta) formam um índice único parcial que impede a mesma linha de entrar duas vezes, ainda que a importação seja repetida (RF-MEDIR-016).

A entidade CONFIG_RASTREAMENTO guarda uma linha por destino de medição, com o interruptor, o identificador público e, quando o destino exige, a credencial de envio pelo servidor. A credencial é de escrita apenas: nenhuma leitura do sistema a devolve para a tela, que exibe somente uma máscara (RF-MEDIR-002). Toda gravação registra quem gravou e quando, e gera linha na auditoria (RF-PAINEL-012). O estado é carregado em memória na partida e recarregado a cada gravação, como o catálogo de textos, para que servir a página não faça consulta ao banco por causa da medição.

6. Interfaces e Integrações

F.1 Integração com a Chronosat (entrada, somente leitura)

F.2 Interface com o site da Sertões (vínculo)

Os sites de resultados vivem no subdomínio resultados.sertoes.com.br: a raiz tem a home global enxuta que apresenta os sites das verticais (RF-PUB-016); /<vertical> é a home do site de cada esporte, com a capa da vertical e o arquivo das edições por ano (RF-PUB-015); e cada evento tem página permanente em /<vertical>/<ano>/<evento> (RF-CONFIG-005). É a estrutura de um blog por esporte: a home da vertical é o arquivo e cada evento é a página fixa daquela edição. As páginas do site institucional apenas vinculam (linkam) para o site da vertical correspondente; tudo funciona de forma autônoma, sem incorporação. Endereço confirmado com a Sertões (bloco 9, A6).

F.3 Interface pública (front)

Front estático que consome apenas a API interna de leitura (módulo API), nunca a Chronosat diretamente. A cor e a marca vêm da configuração da vertical (Ap.4).

F.4 Integrações de medição (saída)

7. Arquitetura e Tecnologia

G.1 Visão geral

Arquitetura híbrida enxuta, um motor e N sites: um único aplicativo de servidor que busca os arquivos da Chronosat (com cache de proteção de taxa), grava cada leitura no banco, expõe a API interna de leitura para o front e serve o painel único do operador. O front serve os sites das verticais (cada um com identidade e home próprias, vindas do perfil da vertical) consumindo a API. O banco guarda a configuração das verticais e eventos E o estado mais recente dos dados de cada evento, e é a fonte de verdade das páginas. O SSL é terminado no próprio servidor (certificado automático Let's Encrypt gerido pelo servidor web) e o domínio de resultados aponta direto para a máquina dedicada; o pico ao vivo é absorvido pelo cache do aplicativo e pela capacidade da máquina, e uma camada de rede (CDN) à frente fica prevista como evolução, se o volume exigir.

flowchart LR
    Publico["Publico (celular/desktop)"] --> Web["Servidor web: SSL Lets Encrypt + cache"]
    Operador["Operador Sertoes"] --> Web
    Web --> App["Motor unico (servidor):\nbusca+persiste, API leitura, painel unico"]
    App --> Banco["Banco leve embarcado:\nconfig das verticais/eventos\n+ estado mais recente dos dados"]
    App -->|1x por minuto, evento ao vivo| Chronosat["Chronosat\nsatcron.com/stages/cache"]
    App --> Sites["Sites por vertical:\n/series, /petrobras, /mtb, /kitesurf\n(identidade e home proprias)"]
    SiteInst["Site Sertoes institucional"] -. linka .-> Sites

G.2 Decisões de arquitetura (ADR)

ADR-001: Aplicativo único híbrido enxuto, não site puro nem stack completa. O sistema é um único aplicativo de servidor (proxy, API e painel) mais um front estático. Descartou-se a montagem manual no site (o problema que originou o projeto) e descartou-se uma stack completa com banco relacional pesado, ingestor permanente e microserviços, por excesso de complexidade para o porte. O racional do council está em discovery-notes.md.

ADR-002: Intermediário do lado do servidor obrigatório (CORS). Como a Chronosat não envia cabeçalho de origem cruzada (validado empiricamente), o navegador do público não pode buscar os arquivos diretamente. O proxy do servidor é a única forma viável de servir os dados ao front.

ADR-003: Persistência contínua no banco; o banco é a fonte de verdade. Cada leitura bem-sucedida da Chronosat é gravada no banco como o estado mais recente daquela fonte, com o payload bruto preservado, desde o primeiro minuto da prova. A página pública é servida sempre do banco; o cache de janela curta existe apenas como proteção de taxa. Encerrar um evento é somente parar de buscar a origem: nada precisa ser copiado, o resultado já está salvo, e nada se perde mesmo que o evento nunca seja encerrado antes de a origem sair do ar. Guarda-se o estado mais recente por fonte, não a série minuto a minuto (não é um armazém de série temporal).

ADR-004: Atualização por consulta periódica do front, sem rotina agendada nem ingestor permanente. O front consulta o servidor em intervalo curto; o servidor serve do cache ou busca a origem no máximo uma vez por minuto. Não há rotina agendada nem processo de ingestão rodando o tempo todo.

ADR-005: Multi-evento e multi-vertical por configuração, não por código. Cada novo campeonato ou vertical é uma linha de configuração; o código é o mesmo para todos. Isso sustenta o requisito de cadastro sem programador.

ADR-006: Servidor dedicado e isolado. O sistema roda em servidor próprio, separado dos demais produtos, para não competir por recursos nem ser afetado por incidentes alheios. Ver bloco 10 e o item de ação de infraestrutura no bloco 9.

ADR-007: SSL automático no próprio servidor; camada de rede (CDN) à frente como evolução. O SSL é terminado no próprio servidor, com certificado automático Let's Encrypt gerido pelo servidor web, e o domínio de resultados aponta direto para a máquina dedicada. O pico de acessos do público ao vivo é absorvido pelo cache do aplicativo e pela capacidade da VPS dedicada. Uma camada de rede gratuita (CDN) à frente foi avaliada e fica prevista como evolução, a ser adotada se e quando o volume de um evento exigir, sem mudança de arquitetura, porque a página já é servida do banco com cache (ADR-003).

ADR-008: Endereço próprio (subdomínio de resultados), não incorporação no site. A página de resultados fica em resultados.sertoes.com.br, servida pelo próprio aplicativo, e o site institucional apenas vincula para ela. Descartou-se a incorporação (embed) na página de cada vertical do site existente, que acoplaria o sistema ao hosting e ao tema do site institucional; o endereço próprio é mais simples de publicar, isolar e manter, e sustenta o arquivo permanente por evento e por ano (RF-CONFIG-005).

ADR-009: Histórico como estado mais recente persistido, não como série temporal. O histórico permanente (RF-INGEST-005, RF-PAINEL-009, RNF-ARQ-001) é o próprio estado mais recente de cada fonte, gravado por cima a cada leitura; não se monta um armazém com o fluxo minuto a minuto. É a forma mais simples de manter cada página para sempre: o último estado salvo é, por construção, o resultado final quando a prova acaba.

ADR-010: Multisite por configuração, nunca duplicação de código. Cada vertical é um site próprio aos olhos do público (identidade, home e regras de exibição próprias), mas todos são servidos por um único motor, um único deploy e um único banco; o que varia por vertical é um perfil de configuração (campos mais uma regra de exibição com três valores), não código. Duplicar o sistema por vertical foi avaliado e rejeitado: cada correção teria de ser aplicada N vezes, as cópias divergiriam com o tempo e a operação se fragmentaria em N painéis. Fica igualmente rejeitado o excesso oposto: não há engine de templates, temas programáveis nem sistema de plugins por vertical.

ADR-011: Painel único para todas as verticais, com contas nominais e papel. A gestão de todas as verticais acontece num único painel autenticado (eventos, PDFs, estado, perfil de cada vertical, e a própria gestão de contas). Painéis separados por vertical foram rejeitados por multiplicarem logins, treinamento e manutenção sem ganho para um time pequeno.

O acesso é por conta nominal: cada pessoa autorizada entra com a sua própria credencial (login e senha própria, guardada apenas como hash), e cada conta tem um papel que define o que ela pode fazer. São dois papéis, nem mais nem menos: administrador (a equipe da Modulareasy, que opera o sistema para a Sertões, tem tudo que o operador tem mais a gestão de contas e a auditoria) e operador (a equipe da Sertões, que cadastra e gerencia os campeonatos). Não há matriz de permissões por tela nem controle de acesso granular além destes dois papéis: um único indicador "é administrador?" separa as funções de administração das demais, e o administrador tem acesso a todas as telas de gestão, sem tela vedada. Contas são desativáveis (o acesso é revogado sem apagar o histórico), e cada ação sensível fica registrada num log de auditoria consultável.

Revisão (evolução do ADR). A primeira versão deste ADR previa "um único login" (uma credencial só, guardada em configuração do servidor, sem tabela de contas). Essa forma foi entregue na abertura do painel (RF-PAINEL-001, primeira versão) e agora é substituída: para que a equipe da Modulareasy administre o sistema por completo de forma transparente e rastreável, o acesso passa a ser por contas nominais com papel, senha por usuário e auditoria (RF-PAINEL-001 revisado, RF-PAINEL-011, RF-PAINEL-012, entidade USUÁRIO em E.1). A decisão de "painel único" (uma superfície de gestão para todas as verticais) permanece; o que muda é "um login" para "contas nominais com papel". Manteve-se deliberadamente fora o excesso: nada de RBAC por recurso, grupos, escopos por vertical ou permissões por tela, que não têm uso para o tamanho da operação.

ADR-012: Renderização orientada a dados com tolerância de esquema. A exibição é dirigida pelos dados recebidos, em três níveis: (1) modalidades, categorias, trechos e competidores são lidos dinamicamente dos arquivos, sem lista fixa em código; (2) o payload bruto é persistido como veio e a normalização acontece na exibição, campos seriados (ssX, IX, posIX) são reconhecidos por padrão de nome em qualquer quantidade, e cada elemento da página é condicional à presença do dado (campo desconhecido é ignorado na tela mas preservado no banco; campo ausente apenas omite o elemento); (3) se um pacote vier estruturalmente diferente do contrato conhecido, 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 do que veio, até um adaptador específico entrar no módulo de ingestão, pequeno e contido, sem tocar o resto do sistema. Fica explicitamente fora a inferência de layout por inteligência artificial em tempo de execução: resultado oficial renderizado errado é pior que não renderizado.

ADR-013: Duas medições com propósitos diferentes, e os números não batem por construção. O sistema mede a audiência por dois caminhos que não se substituem. O registro interno (RF-MEDIR-006) é a verdade operacional: grava do lado do servidor, então não depende de consentimento de cookie, não é barrado por bloqueador de anúncio, não é amostrado e não perde quem usa navegador restritivo. A medição externa é a visão de marketing: cruza o público do site institucional com o dos resultados, alimenta os públicos de anúncio e entrega os relatórios que a equipe de mídia já usa. Os dois números serão sempre diferentes, e o maior será quase sempre o interno. Isso é esperado e está declarado aqui para que a diferença nunca seja tratada como defeito: para dizer quantas pessoas acompanharam a prova, a resposta é o número interno; para comparar o desempenho de canais e campanhas, a resposta é o número externo. O painel de audiência exibe apenas o número interno, e declara a origem de cada linha.

ADR-014: A mesma propriedade de análise e o mesmo pixel do site institucional, separados por host, parâmetro e público. O sistema não cria propriedade de análise nova nem pixel novo: usa exatamente os mesmos do site institucional do cliente. O motivo é que o cookie de análise vive no domínio principal do cliente, então a mesma pessoa que visita o site e depois os resultados é contada uma vez, e o total apresentado a patrocinador é real; uma propriedade nova duplicaria pessoas e ainda exigiria refazer o vínculo com a plataforma de anúncios. O custo aceito é que os caminhos de endereço colidem entre os dois sites (uma vertical tem o mesmo caminho no site institucional e aqui), e por isso este DRS exige três separadores, não um: (a) o nome do host entra como dimensão de recorte obrigatória nos relatórios; (b) todo evento carrega o parâmetro site com o valor que identifica este sistema, registrado como dimensão de evento na plataforma, porque o relatório de tempo real não aceita recorte por host e sem o parâmetro não haveria como separar ao vivo; e (c) existe um público salvo próprio para os resultados na propriedade. Para a plataforma de anúncios vale o mesmo raciocínio: o mesmo pixel, porque os públicos e o aprendizado pertencem ao conjunto de dados e o domínio já verificado cobre o subdomínio.

ADR-015: Envio pelo servidor só para a visualização de página. A visualização de página é o evento que mais se perde para bloqueadores, e é o que sustenta a contagem de alcance; por isso ela sai também pelo servidor, com identificador de evento compartilhado para o destino contar uma vez só (RF-MEDIR-005). Os sete eventos de interação ficam apenas no navegador. Enviá-los pelo servidor colocaria uma chamada externa no caminho quente do ao vivo, a cada troca de filtro do público, contra o RNF-PERF-001 e o RNF-PERF-003, em troca de um ganho pequeno: interação de quem bloqueia medição é uma fração de uma fração. O envio pelo servidor sai pela mesma fila assíncrona do registro interno, então também não entra no caminho de resposta.

ADR-016: Geolocalização adiada, com as colunas previstas desde já. País e unidade federativa nascem como colunas da série de acessos e permanecem vazias nesta entrega. Descartou-se a base de geolocalização instalada junto ao sistema porque ela exige conta, licença e atualização periódica junto a um fornecedor externo, ou seja, uma dependência de terceiro e de cota para um número que não é o objetivo principal do módulo. Descartou-se também o cabeçalho de país, porque ele só existe quando há uma camada de rede à frente do servidor, que hoje não há (ADR-007 a prevê como evolução). Enquanto isso, a visão geográfica continua disponível na plataforma de análise externa, que já a entrega pronta. Quando a camada de rede entrar, as colunas passam a ser preenchidas sem mudança de modelo, e o painel já as exibe quando existirem (RF-MEDIR-011). O que se perde por ora está declarado: a geografia do público não aparece no painel interno, só no externo.

ADR-017: Amostragem declarada da atualização ao vivo nos destinos externos. A página de um evento ao vivo se atualiza sozinha em ciclo curto. Um acompanhante que deixa a aba aberta durante um dia de prova produz milhares de ciclos, e enviar um evento externo por ciclo estouraria a cota de eventos da plataforma de análise e inflaria a contagem da plataforma de anúncios, tornando ambas inúteis justamente no dia em que mais importam. A decisão é enviar aos destinos externos um evento atualizacao_ao_vivo por carregamento de página, que já responde à pergunta de negócio (a pessoa ficou tempo suficiente para receber atualização ao vivo). O registro interno grava todos os ciclos, porque ali não há cota e é a série completa que desenha a curva de público minuto a minuto. O que se perde: nos destinos externos não dá para medir quantos ciclos cada pessoa recebeu; essa pergunta se responde pelo painel interno.

ADR-018: Audiência guardada como série, nunca como contador agregado. Cada acesso é uma linha e a agregação acontece na consulta. Guardar contadores somados por recorte (update no lugar) foi avaliado e rejeitado: economizaria espaço, mas congelaria para sempre os recortes escolhidos no dia em que o módulo nasceu, e qualquer pergunta nova sobre o passado (a curva por hora daquele dia, a categoria mais vista naquela etapa, a origem do público de uma prova encerrada) ficaria sem resposta, porque o dado que a responderia teria sido somado e descartado. O custo aceito é volume, contido por índices compostos e, quando o administrador configurar uma janela de retenção maior que zero (RF-MEDIR-010), por ela também. A série é o histórico plurianual de audiência do cliente, a base de comparação entre edições e anos, e por isso a janela de retenção nasce em zero, sem prazo, e não expira por padrão; a salvaguarda contra o crescimento sem limite é o backup diário do banco (cron 03:17 na VPS, 30 cópias, mais cópia no Drive), não a expiração automática. É a mesma decisão do ADR-003 aplicada à audiência: guardar o que veio e derivar na exibição.

ADR-019 (confirmado em 2026-09-19): a política de privacidade do cliente cobre o sistema de resultados, e não há aviso próprio de consentimento. O aviso de medição do rodapé (RF-MEDIR-017) aponta para a política de privacidade publicada pelo cliente em https://sertoes.com.br/politica-de-privacidade/, cujo controlador declarado é a Dunas Race Promoções S.A. (CNPJ 01.121.018/0001-04), com contato em contato@sertoes.com.br. A política tem uma seção própria sobre o Sistema de Resultados, que declara a medição de audiência anônima (sem endereço de rede em claro e sem cookie próprio do sistema) e registra que a medição de navegação do sistema usa a mesma propriedade de análise e o mesmo pixel do site institucional. Com isso, o sistema segue a política de consentimento do cliente, sem aviso próprio de consentimento, e a decisão deixa de ser inferida.

Esta confirmação fecha uma pendência e corrobora duas decisões anteriores: o ADR-014 (mesma propriedade de análise e mesmo pixel do site institucional) passa a ter respaldo na política publicada, e o RNF-PRIV-001 (dado anônimo por construção, sem cookie próprio e sem endereço de rede legível) passa a ser também compromisso declarado do cliente ao público, e não apenas regra interna deste documento. O endereço permanece editável pelo painel sem novo deploy (RF-CONFIG-006), de modo que uma mudança futura de endereço não exige alteração de código.

G.3 Cortes deliberados (simplicidade)

Estão fora por decisão de arquitetura, para manter o sistema simples e adequado ao porte: banco relacional pesado, armazém de série temporal com o fluxo minuto a minuto (guarda-se o estado mais recente de cada fonte), microserviços (é um único aplicativo), conexão persistente em tempo real, motor de cálculo (a Chronosat já calcula), plugin customizado no site institucional, duplicação do sistema por vertical, engine de templates ou plugins por vertical, e inferência de layout por inteligência artificial. O detalhamento do racional está em discovery-notes.md.

8. Estratégia de Validação

• Base de dados da montagem e dos testes: os arquivos JSON reais já em mãos (crews, stagetimes e racetimes do rally, mais o documento oficial da API) são a base de toda a construção e validação; nenhum dado adicional de terceiros é aguardado. Verticais novas são validadas com o primeiro pacote real no próprio teste de conexão.
• Leitura real da Chronosat: validar contra os arquivos reais em mãos (o intermediário busca, cruza pela chave numeral e serve), incluindo o caso de origem cruzada bloqueada.
• Regras de interpretação: validar cada regra do Ap.2 com os exemplos de JSON reais (valor ausente, posição nula, prólogo fora do acumulado, abandono e teto, horários de auditoria, oculto na origem).
• Smoke visual real: abrir a página no celular e no desktop, em cada vertical, e conferir tela a tela (classificação, pódio, filtros, parciais, downloads, identidade da cor), porque o público vai abrir e ver.
• Teste do painel: percorrer o assistente de três passos com um operador não técnico, incluindo o teste de conexão com pré-visualização e os controles de estado, PDFs e ocultação.
• Teste ao vivo: validar a atualização automática e o comportamento sob carga com um evento real; os dados do Rally do Jalapão servem de referência para essa validação.
• Persistência e arquivo: confirmar que cada leitura fica salva no banco durante o ao vivo; retirar a origem do ar SEM encerrar o evento e confirmar que a página continua servindo o último estado salvo; encerrar e confirmar que o endereço permanente e as homes seguem funcionando.
• Multisite: cadastrar uma segunda vertical por configuração (com perfil próprio) e confirmar que o site dela nasce com identidade, home e regra de tripulação próprias, sem alteração de código e sem interferir na primeira.
• Tolerância de esquema: alimentar o sistema com um arquivo contendo campo desconhecido, campo ausente e mais parciais que o usual, e confirmar que a página não quebra, exibe o que existe e preserva o payload no banco; alimentar com um pacote estruturalmente divergente e confirmar a detecção com aviso ao operador e o fallback genérico.
• Medição de audiência: conferir, em janela anônima, que a página pública traz exatamente uma etiqueta de análise e um pixel, que nenhuma tela do painel traz qualquer das duas, que os sete eventos de interação chegam ao destino com os nomes em português e o parâmetro de site, e que a atualização ao vivo não produz visualização nova; conferir no painel de audiência que o acesso apareceu, e que verificação de saúde, agente automatizado e sessão de painel não apareceram.
• Carga do registro de audiência: medir a página do evento com o registro ligado e desligado sob a mesma carga e confirmar que a piora fica dentro do limite do RNF-PERF-003.
• Aceite por H1: cada requisito do bloco 3 só é considerado pronto quando seu H1 passa.

9. Entrega e Evolução

A ordem de construção está detalhada no companheiro Roadmap de Implementação, derivada das ondas abaixo e de suas dependências.

J.1 Ondas de entrega

• Onda 1, motor de leitura e persistência. Intermediário de leitura da Chronosat com cache de proteção (INGEST), persistência de cada leitura no banco (RF-INGEST-005), cruzamento pela chave numeral, API interna de leitura, incluindo a classificação por categoria (API). Dependência: nenhuma além das URLs de um evento de referência.
• Onda 2, página pública e site da primeira vertical (Series). Tabela de classificação responsiva, filtros, pódio dos cinco, ranking por categoria, parciais, central de downloads, indicador de estado e atualização automática (PUB), as regras de interpretação (REGRA), e o site da vertical Series com sua home (RF-PUB-015). Dependência: Onda 1.
• Onda 3, painel único do operador. Autenticação, assistente de três passos, teste de conexão com pré-visualização, controle de estado, congelamento (parar de buscar), criação de evento retroativo, gestão de PDFs (link e upload), ocultar competidor, lista de campeonatos (PAINEL), e a configuração de verticais com perfil completo, eventos, fontes, endereço permanente e textos do site (CONFIG, incluindo RF-CONFIG-006). Dependência: Onda 1.
• Onda 4, segunda vertical por configuração (Petrobras) e home global. Cadastrar a vertical Petrobras com identidade própria, provando que uma vertical nova é configuração e não código (RF-CONFIG-004); home global enxuta (RF-PUB-016); endurecimento para o pico ao vivo (cache e capacidade do servidor). Dependência: Ondas 2 e 3.
• Onda 5, vertical MTB (Bike). Ativar a vertical com perfil de tripulação dupla (os dois nomes em negrito). A construção não espera nenhum dado de terceiros: quando o primeiro pacote real da Bike chegar, o teste de conexão do próprio cadastro o valida contra o contrato conhecido e, se algo divergir (ex.: dupla com dois numerais), a tolerância de esquema garante exibição útil imediata e o ajuste fino entra como um adaptador contido na ingestão (ADR-012). Dependência: Onda 4.
• Onda 6, vertical Kitesurf. Ativar a vertical com perfil de tripulação solo e a hierarquia do Kite (modalidades Kite e Wing com suas categorias). Referência observada na página de resultados atual do kite da Sertões: a classificação final é por PONTOS somados por etapa (Geral mais Etapas 1 a 4), com divisões como Pro e Elite, Adventure Master e Jr, e Open; ou seja, o acumulado do Kite tende a ser pontuação, não tempo, e o sistema exibe a métrica que o payload entregar (renderização orientada a dados). Mesma regra da Onda 5: sem espera de dados de terceiros; o primeiro pacote real é validado no teste de conexão e divergências são absorvidas por adaptador contido (ADR-012). Dependência: Onda 4.
• Onda AUD, audiência (medição do público). Medir quantas pessoas acompanham. Metade externa: a configuração de rastreamento no painel pelo administrador, a injeção das marcações apenas nas páginas públicas, os sete eventos de interação com nome em português, a separação do site institucional por host, parâmetro e público, o envio da visualização pelo servidor sem contar duas vezes, e a regra de que a atualização ao vivo não é visualização nova (RF-MEDIR-001 a 005). Metade interna: a série de acessos, a fila de gravação que não atrasa a página, o visitante único do dia sem identificar pessoa, as exclusões do que não é público, a retenção, a tela de audiência completa (o agora, a série por dia e hora com pico, origem, buscas, documentos, recortes, dispositivo, navegador, permanência aproximada), a comparação entre eventos, a exportação e a importação dos registros do servidor web ainda disponíveis (RF-MEDIR-006 a 017). Dependência: Ondas 2 e 3 (a página pública e o painel já existem). É a primeira onda de construção da fase seguinte do sistema e não altera arquitetura: entra pelo motor único e vale para as quatro verticais.
• Evolução, fotos e bandeiras no pódio. A bandeira (a UF de cada integrante) já vem nos dados da Chronosat (a tripulação traz a UF), então depende só de exibição e pode entrar cedo. A foto dos cinco primeiros depende de uma fonte de fotos: um pré-cadastro de competidores associando numeral ou nome à foto, com uma automação de imagens. Dependência: a foto entra quando essa fonte existir, não por calendário.
• Evolução, página de campeões históricos. Uma página por vertical com os campeões de todas as edições, alimentada por conteúdo fornecido pela Sertões (planilha), em formato simples primeiro. Adiada por decisão do cliente; entra quando o conteúdo chegar, sem mudança de arquitetura.

J.2 Sequência de uso

O sistema serve qualquer evento das verticais da Sertões; cada edição é cadastrada pelo operador quando a Chronosat entrega as URLs, e a página nasce, fica ao vivo durante a prova e congela ao encerrar. A ordem de construção do sistema em si está nas ondas acima e no companheiro Roadmap; a agenda de quais eventos entram primeiro é decisão de operação da Sertões, não deste documento.

J.3 Item de ação de infraestrutura

Provisionar o servidor dedicado isolado (porte equivalente a uma VPS de pequeno porte, com Ubuntu e contêineres), separado dos demais produtos. Esse isolamento é requisito (RNF-ISO-001, ADR-006): o sistema de resultados não pode cair junto com outros sistemas nem disputar recursos. O servidor já está disponível; resta prepará-lo para receber o aplicativo. Detalhe operacional no bloco 10.

J.4 Decisões de negócio reconciliadas

As decisões que antes estavam em alinhamento com a Sertões (Bloco A) e com a Chronosat (Bloco B) já foram respondidas, pelo questionário e pela conversa de alinhamento, e estão cravadas neste DRS. A tabela abaixo registra cada pergunta, a resposta recebida e onde o sistema passou a cravá-la.

Cada linha traz o código da pergunta no Questionário (Q), a resposta recebida e o requisito que ela ajusta.

10. Operação em Produção

• Servidor dedicado isolado (ver J.3 e ADR-006), com Ubuntu e contêineres, separado dos demais produtos.
• SSL automático no próprio servidor (certificado Let's Encrypt gerido pelo servidor web), com o domínio de resultados apontando direto para a máquina dedicada; o pico ao vivo é absorvido pelo cache do aplicativo e pela capacidade da VPS. Uma camada de rede (CDN) à frente fica como evolução, se o volume exigir.
• Monitoramento de saúde: disponibilidade dos sites, saúde do intermediário de leitura, sucesso das leituras da Chronosat, gravação das leituras no banco e estado do cache.
• Plano de incidente ao vivo: se a Chronosat cair durante a prova, a página segue servida do último estado salvo no banco (RF-INGEST-003, RF-INGEST-005); o contato com a equipe da Chronosat é conduzido pelo operador do painel, que gere essa relação, e não pela sustentação técnica (bloco 9, B5).
• Acessos: os acessos do site da Sertões já existem e estão documentados na estrutura do projeto. As contas do painel são nominais e com papel: as primeiras contas de administrador (a equipe da Modulareasy que opera o sistema) são provisionadas pela sustentação no início; a partir daí, o próprio administrador cria e mantém as demais contas, inclusive as de operador, pela tela de gestão de contas (RF-PAINEL-011), sem depender de desenvolvimento.

11. Configurabilidade

O sistema segue o princípio de que tudo que o operador precisa ajustar durante a operação tem interface própria, sem exigir desenvolvimento, banco mexido à mão ou novo deploy. São configuráveis pelo operador:

• Verticais (o perfil do site de cada esporte): cor de destaque, marca, capa da home (título, subtítulo, imagem), rótulos da hierarquia, regra de exibição da tripulação e ordem na home global, e adição de uma nova vertical (RF-CONFIG-001).
• Eventos: nome, vertical, estado (rascunho / ao vivo / encerrado) e as URLs de origem por modalidade e trecho (RF-CONFIG-002, RF-CONFIG-003).
• PDFs oficiais: título e disponibilização de cada PDF do evento (RF-PAINEL-006).
• Ocultação de competidor: ocultar e reexibir um competidor (RF-PAINEL-007).
• Janela de atualização e cache: o intervalo de consulta do front e a janela de cache têm valor padrão e são ajustáveis sem novo deploy.
• Contas de usuário: o administrador cria, edita, desativa e reativa contas, define papel e redefine senha pela tela de gestão de contas, sem depender de desenvolvimento (RF-PAINEL-011).

• Integrações de medição: o administrador liga e desliga cada destino, informa o identificador público de cada um, guarda a credencial de envio pelo servidor (escrita apenas, exibida sempre mascarada) e envia um evento de teste, tudo pela tela de integrações do painel, sem novo deploy e sem depender de desenvolvimento (RF-MEDIR-002).
• Registro de audiência: o intervalo e o tamanho do lote da gravação, o teto da fila e a janela de retenção da série de acessos têm valor padrão e são ajustáveis sem novo deploy (RF-MEDIR-007, RF-MEDIR-010).
• Aviso de medição no rodapé: é uma chave do catálogo de textos do site, editável e removível pelo painel (RF-MEDIR-017, RF-CONFIG-006).

O Inventário de Artefatos (companheiro) traz a ficha de cada parâmetro configurável.

12. Automação e Inteligência Artificial

Não se aplica nesta entrega. O sistema não usa inteligência artificial nem automações de fluxo: a única automação é a leitura periódica dos dados da Chronosat, descrita na arquitetura (módulo INGEST). Não há geração de conteúdo, classificação automática nem decisão assistida. Registrado como não aplicável para conformidade com a estrutura do documento.

13. Aprendizado Pós-Lançamento

• Sinal primário: a página se manteve no ar e atualizada durante a prova ao vivo, com o pico de acessos absorvido sem queda.
• Sinal do operador: o operador conseguiu cadastrar e publicar o evento sozinho, sem suporte de desenvolvimento.
• Coleta de feedback: observação do primeiro evento ao vivo, registrando o que precisou de ajuste no painel ou na exibição.
• Sinal de audiência: com o módulo MEDIR no ar, o tamanho do público de cada prova deixa de ser estimativa e passa a ser número: pessoas e acessos por dia e por hora, o pico, de onde vieram e o que procuraram, comparáveis entre eventos. É o insumo da prestação de contas a patrocinador e da decisão sobre onde divulgar a próxima prova.
• Evolução prevista: (a) foto e bandeira dos cinco primeiros no pódio, com a bandeira (UF) já disponível nos dados da Chronosat e a foto dependente de um pré-cadastro de competidores com automação de imagens (ver J.1, Evolução); (b) caso a Chronosat venha a oferecer um endpoint de produção com autenticação ou uma API com histórico, o sistema pode evoluir para consumir essa fonte mais robusta. Dependem de fonte de dados, não de calendário.

Apêndices

Ap.1 Catálogo de campos dos arquivos Chronosat

Referenciado por RF-INGEST-004, RF-API-001 a 004 e pelo Inventário (conector de dados). Fonte: documento oficial da API e exemplos de JSON do projeto.

Arquivo crews (estático por modalidade no evento):

As modalidades (mods) e as categorias (cats) são lidas dinamicamente de crews; a quantidade varia por evento. Os códigos 1 motos, 2 utv, 3 carros são os do evento de referência, não um conjunto fixo (edições passadas tiveram, por exemplo, caminhão e quadriciclo, e há eventos com uma categoria adicional de carro do tipo production).

Arquivo stagetimes (por trecho, dinâmico a cada minuto):

Arquivo racetimes (acumulado geral por modalidade, incremental):

Controle (hash) nas URLs. O nome de cada arquivo segue {evento}_{modalidade}_{tipo}_{trecho}_{controle}.json. Crews e racetimes de uma modalidade compartilham o mesmo controle por todo o evento; cada stagetimes tem o seu, por trecho. Os controles são estáveis por arquivo; novos arquivos de stagetimes surgem conforme os trechos começam ao longo dos dias. O sistema recebe o bloco de URLs da Chronosat e reconhece cada arquivo pelo padrão do nome (RF-PAINEL-003). O racetimes já traz o acumulado por modalidade (a base da classificação geral), então a visão Geral não depende de somar os stagetimes.

Esportes por pontos. Este catálogo descreve o contrato validado com dados reais do rally, e é a base da construção. A referência observada do Kite (a página de resultados atual do kite da Sertões) mostra classificação final por PONTOS somados por etapa, com divisões próprias; quando o payload de um esporte trouxer pontuação em vez de tempos, o sistema exibe a métrica recebida, sem recalcular nada (ADR-012). Nenhum arquivo de exemplo adicional é pré-requisito: o primeiro pacote real de cada esporte é validado no teste de conexão do cadastro.

Ap.2 Regras de interpretação dos dados

Referenciado pelos RF do módulo REGRA (C.4).

Ap.3 Catálogo das telas do painel

Referenciado pelos RF do módulo PAINEL (C.5) e pelo Inventário (telas). Fichas detalhadas no companheiro Inventário de Artefatos. A coluna "Quem acessa" indica o papel: as telas de gestão de campeonatos servem os dois papéis; gestão de contas e auditoria são só do administrador.

Ap.4 Identidade visual por vertical

Referenciado por RF-PUB-010, RF-PUB-011 e RF-CONFIG-001. Identidade extraída do site atual do Sertões (sertoes.modulareasy.com); o protótipo publicado já materializa esta identidade.

Tipografia

Paleta base (comum a todas as verticais)

Botões em caixa alta, com cantos quase retos.

Cor de marca por vertical (acento principal)

Fonte dos assets (logos, marcas e cores por vertical): os logotipos oficiais 2026 das quatro verticais já estão em mãos, na pasta de identidade visual do cliente no workspace da Modulareasy (01 - Clientes/Sertões/00 - Infos/00 - Identidade Visual/02 - Logos, com versões em quadrado colorido e em branco horizontal/vertical por vertical), e as cores oficiais da tabela acima foram extraídas do fundo desses logotipos. Fonte complementar: a biblioteca de mídia dos sites da Sertões (sertoes.com.br e sertoes.modulareasy.com, WordPress multisite, pasta de uploads). Nada depende de envio do cliente.

A cor de destaque da vertical é aplicada a realces, pódio, abas ativas e estados ativos, sobre a paleta base; o preto institucional e os fundos claros são comuns a todas as verticais. Cada vertical também define no perfil a capa da home, os rótulos da hierarquia e a regra de exibição da tripulação. Novas verticais entram com o seu próprio perfil (RF-CONFIG-001).

Ap.5 Catálogo da página pública de resultados

Referenciado pelos RF do módulo PUB (C.3). Esta é a estrutura concreta da página pública, materializada no protótipo aprovado (modulareasy.com/sertoes/pagina-de-resultados). De cima para baixo, a página tem as seções abaixo. O protótipo usa dados reais do Rally Jalapão apenas como demonstração e não se atualiza ao vivo sozinho.

Responsividade: no celular a tabela de classificação vira cartões e o pódio empilha os cinco lugares em ordem de 1 a 5; no desktop a tabela e o pódio aparecem na forma padrão (RNF-RESP-001).

Homes: além da página de cada evento, cada vertical tem a home do seu site (a capa do esporte com o arquivo das edições por ano, RF-PUB-015) e a raiz do subdomínio tem a home global enxuta que apresenta os sites das verticais (RF-PUB-016).

Exibição da tripulação: a forma de exibir os nomes em tabela, pódio e modal segue a regra do perfil da vertical: piloto em destaque e navegador (rally), dupla com os dois nomes em negrito (bike), atleta solo (kite).

Ajustes sobre o protótipo: o protótipo já reflete o pódio dos cinco em ordem sequencial (1 a 5) e a visão Geral (acumulado) em destaque antes do Prólogo, conforme acordado.

Ap.6 Catálogo da medição de audiência

Referenciado pelos RF do módulo MEDIR (C.7), pelo bloco E.4 e pelo companheiro Inventário de Artefatos. Reúne as fichas longas que os requisitos citam por nome, para que o requisito se leia curto e a ficha viva num lugar só (as três tabelas abaixo são a definição fechada; um item novo exige alterar o requisito correspondente).

Os eventos enviados aos destinos externos (RF-MEDIR-003, RF-MEDIR-004)

Os grupos de origem da referência (RF-MEDIR-013)

O que NÃO entra na audiência (RF-MEDIR-009)

A exclusão é por ORIGEM, nunca por rota. As rotas que o monitor interno verifica incluem a raiz e a home de uma vertical, que são páginas públicas legítimas: excluir por rota apagaria audiência real da contagem (RF-MEDIR-009).

Os blocos da tela de audiência (RF-MEDIR-011 a 015)

Sistema de Resultados de Campeonatos (integração Chronosat). Documento de Requisitos de Software preparado pela Modulareasy para a Sertões. Estágio: Validado (v2.0). Cobre o motor único que serve os sites das quatro verticais (Sertões Series, Sertões Petrobras, Sertões MTB e Sertões Kitesurf), a integração com a Chronosat com persistência de cada leitura no banco, as regras de interpretação e a renderização orientada a dados, a página pública (pódio dos cinco, ranking por categoria, visão Geral e por etapa), o arquivo permanente por vertical, ano e evento com as homes de consulta, e o painel único do operador. As decisões de negócio que estavam em alinhamento foram respondidas e estão reconciliadas no bloco 9.