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.

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).

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.
• 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).

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: Central de Documentos Oficiais (PDFs)

• Descrição: a página oferece uma central com os documentos oficiais do evento como botões de download, tipicamente Resultado Acumulado, Penalidades e Ordem de Largada, disponibilizados pelo operador. A central exibe os documentos que existem para o evento; um documento ausente não aparece.
• Prioridade: Alta
• Atores: Público
• H1: Dado um evento com documentos publicados, Quando o público abre a Central de Documentos Oficiais, Então cada documento (ex.: Resultado Acumulado, Penalidades, Ordem de Largada) aparece como botão de download com título e link funcional, E se não houver documentos a central exibe estado vazio sem erro.

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.

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).

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.

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.

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).

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.

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.
• 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 e endereço permanente (CONFIG). 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.
• 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).

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.
• 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.

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.