Para que serve: hospedar o aplicativo único (proxy, API de leitura e painel), isolado dos demais produtos.

Relacionado com: DRS ADR-006, RNF-ISO-001; tarefa F0-01.

Onde fica: servidor próprio do projeto.

Especificação: máquina de pequeno porte com Ubuntu e contêineres, dedicada a este sistema. Papel: rodar o app único e o banco, que guarda a configuração das verticais e dos eventos E o estado mais recente dos dados de cronometragem de cada evento (DADOS_EVENTO, ART-ENT-07, RF-INGEST-005). Recursos: porte de VPS pequena. Dependências: domínio ligado ao aplicativo (ART-INFRA-02). Persistência: volume para o banco (config e dados). Health check: endpoint de saúde do app, incluindo a gravação das leituras no banco. Escalonamento: o pico ao vivo é absorvido pelo cache do aplicativo e pela capacidade da máquina. Backup: cópia periódica do banco (config e dados persistidos). Isolamento é requisito: não compartilha recursos com outros produtos.

Para que serve: publicar o domínio de resultados com HTTPS válido, roteando o público ao aplicativo único, com o SSL terminado no próprio servidor.

Relacionado com: DRS ADR-007, RNF-ESC-001; tarefa F0-02.

Onde fica: no próprio servidor dedicado (proxy reverso do servidor web).

Especificação: proxy reverso do servidor web para o aplicativo único (127.0.0.1:3000), com certificado automático Let's Encrypt gerido pelo servidor web, e cache de resposta de leitura no próprio servidor. Dependências: servidor dedicado (ART-INFRA-01) e o domínio apontando para a máquina. Health check: certificado válido e roteamento ao aplicativo. Escalonamento: o pico ao vivo é absorvido pelo cache do aplicativo e pela capacidade da máquina; uma camada de rede (CDN) à frente fica como evolução, se o volume exigir. Backup: não aplicável (configuração declarativa).

Para que serve: proteger a Chronosat de excesso de chamadas, limitando a frequência de busca na origem; NÃO é a persistência do resultado (essa é DADOS_EVENTO, ART-ENT-07).

Relacionado com: RF-INGEST-002, RF-INGEST-003, RF-INGEST-005; tarefas F1-02, F1-03, F1-04.

Onde fica: no app do servidor (memória do proxy) mais o cache de resposta do próprio servidor (ART-INFRA-02).

Especificação: cache por chave de arquivo com expiração padrão de 30 a 60 segundos, ajustável (ART-CFG-04). Coalesce requisições concorrentes numa única busca à origem; limita a busca à origem a no máximo uma vez por minuto por arquivo. Chave de cache: evento, modalidade, tipo, trecho. Este cache é só proteção de taxa, em memória, volátil: a fonte de verdade servida ao público é sempre o banco (DADOS_EVENTO, ART-ENT-07), gravado a cada leitura bem-sucedida (RF-INGEST-005); se o cache expirar ou o processo reiniciar, nada se perde porque o dado já está no banco.

Para que serve: buscar do lado do servidor os arquivos JSON da Chronosat, PERSISTIR cada leitura bem-sucedida no banco e servir a página sempre do banco, resolvendo o bloqueio de origem cruzada (CORS).

Relacionado com: RF-INGEST-001, RF-INGEST-004, RF-INGEST-005, ADR-002, ADR-003; tarefas F1-01, F1-03, F1-05.

Onde fica: app único no servidor dedicado.

Especificação: Sistema externo: Chronosat. Direção: entrada, somente leitura. Autenticação: endpoint beta atual sem autenticação própria; preparado para endpoint de produção autenticado quando existir, com a credencial e a política de acesso entrando na configuração assim que existirem (ART-ENVV-02). Credencial provida por: Chronosat (quando houver endpoint de produção). Endereços usados: GET aos arquivos em https://satcron.com/stages/cache/{evento}_{modalidade}_{tipo}_{trecho}_{controle}.json. Tipos de arquivo: crews, stagetimes, racetimes. Payload: ver o catálogo de campos no Ap.1 do DRS (conector, ART-CONN-01). Cruzamento: pela chave numeral. Persistência: cada leitura bem-sucedida é gravada em DADOS_EVENTO (ART-ENT-07, RF-INGEST-005), por cima do registro existente daquela fonte (upsert); a página pública e a API interna NUNCA leem a Chronosat em tempo de resposta, leem sempre o banco. Idempotência: leitura pura, sem efeitos colaterais na origem; o cache de janela curta (ART-INFRA-03) evita duplicar chamadas, e a gravação em banco é o upsert que elimina duplicidade de estado. Falha e retry: em erro da origem, a página segue servida do último estado salvo no banco (RF-INGEST-003) e sinaliza atualização suspensa; nenhuma tentativa de escrita é feita quando a leitura falha. Rate limit: no máximo uma leitura à origem por minuto por arquivo. Saída: JSON normalizado com cabeçalho de origem cruzada para o domínio da página, servido a partir do banco.

Para que serve: ser a capa do site de cada esporte, o arquivo (como o índice de um blog) das suas edições por ano, para o público chegar tanto ao evento ao vivo quanto às edições arquivadas daquela vertical.

Relacionado com: RF-PUB-015; tarefa F2-13.

Onde fica: front estático, rota /<vertical> no subdomínio de resultados (resultados.sertoes.com.br).

Especificação: Rota: resultados.sertoes.com.br/<vertical> (ex.: /series, /petrobras, /mtb, /kitesurf). Quem acessa: público anônimo, sem login. Objetivo: apresentar o site daquele esporte e navegar para a página fixa de cada evento. Elementos principais: hero com a identidade e a capa do perfil da vertical (hero_titulo, hero_subtitulo, hero_imagem de VERTICAL), o evento ao vivo em destaque quando houver, e o arquivo das edições por ano (lista de EVENTO daquela vertical, agrupada por ano, o vigente sinalizado e as arquivadas). Ações disponíveis: selecionar um evento e ir para sua página (resultados.sertoes.com.br/<vertical>/<ano>/<evento>). Dados exibidos: metadados de EVENTO (nome, ano, slug, estado) e o perfil de VERTICAL. Estados: vazio (nenhum evento publicado ainda nessa vertical), carregando, normal. Responsivo: celular (prioridade) e desktop. Idioma: português. Regra: nenhuma outra vertical aparece nesta home (RF-PUB-015).

Para que serve: ser a porta de entrada mínima do subdomínio de resultados, apresentando os sites das verticais sem misturar classificações ou eventos de esportes diferentes.

Relacionado com: RF-PUB-016; tarefa F4-03.

Onde fica: front estático, raiz do subdomínio de resultados (resultados.sertoes.com.br).

Especificação: Rota: raiz do subdomínio (resultados.sertoes.com.br/). Quem acessa: público anônimo, sem login. Objetivo: navegação para a home de cada vertical. Elementos principais: lista dos sites das verticais (nome, marca e cor de cada uma, lidos de VERTICAL), na ordem definida por ordem_home. Ações disponíveis: selecionar uma vertical e ir para a sua home (/<vertical>, ART-SCR-03). Dados exibidos: apenas metadados de VERTICAL (nome, slug, cor_destaque, marca, ordem_home); nenhum dado de evento ou classificação. Estados: vazio (nenhuma vertical publicada), carregando, normal. Responsivo: celular (prioridade) e desktop. Idioma: português.

Para que serve: exibir ao público os resultados ao vivo de um evento com a identidade da vertical.

Relacionado com: RF-PUB-001 a 014; tarefas F2-02 a F2-12.

Onde fica: front estático, rota /<vertical>/<ano>/<evento> no subdomínio de resultados (resultados.sertoes.com.br), vinculado a partir das páginas de cada vertical do site institucional.

Especificação: a estrutura concreta da página (cabeçalho, hero, pódio, filtros, tabela, modal de detalhe, central de documentos, rodapé, na ordem, com as colunas e elementos exatos) vive no Ap.5 do DRS (REGRA-INV-2). Quem acessa: público anônimo, sem login. Objetivo: acompanhar a classificação, o pódio, as parciais e baixar documentos oficiais. Fonte de dados: sempre a API interna de leitura, que por sua vez lê sempre de DADOS_EVENTO (ART-ENT-07), nunca a Chronosat direto nem em tempo de resposta da página. Estados: carregando, vazio (sem evento), degradado (origem indisponível, último estado salvo servido do banco), ao vivo, encerrado (permanente). Responsivo: celular (prioridade, tabela vira cartões e pódio empilha) e desktop. Idioma: português. Identidade: cor, marca e regra de exibição da tripulação vindas do perfil da vertical (ART-ENT-01, Ap.4).

Para que serve: o administrador cria, edita, desativa/reativa contas, define papel e redefine senha, sem depender de desenvolvimento.

Relacionado com: RF-PAINEL-011, RNF-SEG-002, RNF-SEG-003, RNF-SEG-005, USUÁRIO (ART-ENT-06); tarefa F3-15.

Onde fica: painel único (ART-SCR-02), rota acessível apenas ao papel administrador.

Especificação: Rota: dentro do painel, sob a barreira e o gate "é administrador?" (F3-14). Quem acessa: só o papel administrador; o operador que tenta abrir é barrado. Objetivo: gerir as contas de usuário. Elementos principais: lista de contas (login, papel, situação ativa/desativada); criar conta (login, papel, senha inicial); editar papel de uma conta; desativar e reativar; redefinir senha. Regras: nenhuma senha é exibida nem guardada em texto puro (só hash, ART-ENT-06); sem autocadastro público; cada ação grava na auditoria (ART-ENT-08). Estados: lista vazia (só as contas iniciais), normal, conta desativada visível como tal. Responsivo: desktop. Idioma: português, sem termos técnicos.

Para que serve: o administrador consulta o log de ações sensíveis, para saber quem fez o quê e quando.

Relacionado com: RF-PAINEL-012, RNF-SEG-004, AUDITORIA (ART-ENT-08); tarefa F3-16.

Onde fica: painel único (ART-SCR-02), rota acessível apenas ao papel administrador.

Especificação: Rota: dentro do painel, sob a barreira e o gate "é administrador?" (F3-14). Quem acessa: só o papel administrador; o operador que tenta abrir é barrado. Objetivo: consultar o histórico de ações sensíveis. Elementos principais: lista de registros de AUDITORIA (quem fez, qual ação, sobre o que, quando), do mais recente ao mais antigo. Regras: somente leitura (o registro é imutável, gravado por F3-14 e F3-15); nunca exibe senha. Estados: vazio (nenhuma ação ainda), normal. Responsivo: desktop. Idioma: português, sem termos técnicos.

Para que serve: o administrador vê, num só lugar, se as páginas principais do sistema e do site estão no ar (200) ou com erro (4xx ou 5xx), com o código HTTP à vista de cada rota.

Relacionado com: RF-PAINEL-013; tarefa F3-17; configuração de rotas monitoradas (ART-CFG-06); gate "é administrador?" (ART-ACS-01, F3-14); rotas monitoradas apontam para ART-SCR-01, ART-SCR-03, ART-SCR-04, ART-SCR-02 e o endpoint de saúde (ART-INFRA-01).

Onde fica: painel único (ART-SCR-02), rota acessível apenas ao papel administrador.

Especificação: Rota: dentro do painel, sob a barreira e o gate "é administrador?" (F3-14). Quem acessa: só o papel administrador; o operador que tenta abrir é barrado. Objetivo: verificação de saúde das páginas principais. Fonte da lista: a configuração curada de rotas monitoradas (ART-CFG-06), uma entrada por área, nunca por evento. Verificação: do lado do servidor; o próprio app faz uma requisição a cada rota da lista e coleta o código de resposta HTTP (ao carregar a página e ao acionar "verificar de novo"). Elementos principais: uma linha por rota curada, com o rótulo da área, o endereço e o código HTTP; 200 marcado como no ar, 4xx ou 5xx sinalizado como erro em destaque; botão "verificar de novo" que reconsulta. Regras: a lista é sempre a curada (home global quando existir, home de cada vertical, rotas do painel, verificação de saúde, âncoras do site), sem nenhuma rota por evento; a verificação nunca lança (uma rota que não responde é reportada como erro, não derruba a tela). Estados: verificando, normal (com status por rota), todas no ar, alguma com erro. Sem histórico, gráfico de uptime nem alerta nesta entrega (evolução futura). Responsivo: desktop. Idioma: português, sem termos técnicos.

Para que serve: guardar cada vertical com o perfil completo do site do esporte (identidade, home e regra de exibição da tripulação).

Relacionado com: RF-CONFIG-001, RF-PUB-010, RF-PUB-015, RF-PUB-016; tarefa F3-02.

Onde fica: banco (config global do sistema).

Especificação: atributos id (pk), slug (series, petrobras, mtb, kitesurf), nome, cor_destaque (cor de realce, pódio, abas e estados ativos), marca (logo/identidade), hero_titulo (título da capa da home da vertical), hero_subtitulo, hero_imagem, rotulo_modalidade (default "Modalidade"), rotulo_categoria (default "Categoria"), rotulo_trecho (default "Etapa"), regra_tripulacao (enum, ver abaixo), ordem_home (posição na home global, RF-PUB-016). Sem FK de entrada. Índice por slug único. Escopo: config global do sistema, editável pelo operador sem novo deploy (RF-CONFIG-001).

Para que serve: guardar cada campeonato de uma vertical.

Relacionado com: RF-PAINEL-002, RF-CONFIG-002, RF-CONFIG-005; tarefas F3-03, F4-01.

Onde fica: banco leve embarcado.

Especificação: atributos id (pk), vertical_id (fk), nome (ex.: Vale do Jalapão), evento_chronosat (ex.: jalap26), ano (ex.: 2026), slug (endereço do evento, ex.: rally-series), estado (rascunho, ao_vivo, encerrado), criado_em. FK: VERTICAL (N eventos para 1 vertical). Índice por vertical e estado, e único por vertical, ano e slug. Regra: um evento vigente por vertical exibido ao público; ano e slug compõem o endereço permanente resultados.sertoes.com.br/<vertical>/<ano>/<evento> (RF-CONFIG-005), onde <evento> é o slug, e não mudam depois de publicado; dois eventos da mesma vertical no mesmo ano têm slugs distintos.

Nota (2026-07-06, S72): tabela evento criada em F3-03 (rascunho com vertical, nome, ano e slug). F3-04 preencheu as fontes por modalidade. F3-05 entregou a publicação: o estado muda de rascunho para ao_vivo (ou aguardando dados) e o evento aparece em público. F3-06 entregou o controle de estado pleno: o campo estado alterna entre ao_vivo e encerrado pelo operador, e o poller de leitura passou a derivar a lista de eventos ao vivo diretamente desta tabela (antes vinha de uma lista fixa no código); o evento real da vertical Series também passou a nascer aqui (seed idempotente), em vez de só num arquivo de configuração. As fontes plenas por trecho (F3-11, ART-ENT-03) e agora a trava do endereço permanente após publicado (F3-12) foram entregues: o endereço por vertical, ano e slug é imutável após a publicação, garantido pela ausência de qualquer caminho de código que mude essa identidade, com teste estrutural cobrindo essa ausência. Entidade completa.

Para que serve: guardar as URLs de origem por modalidade e trecho.

Relacionado com: RF-CONFIG-003, RF-INGEST-001; tarefas F3-04, F3-06, F3-11.

Onde fica: banco leve embarcado.

Especificação: atributos id (pk), evento_id (fk), modalidade (o código que o evento tiver, tipicamente 1 motos, 2 utv, 3 carros, mas sem fixar a quantidade), tipo (crews, racetimes, stagetimes), trecho (nulo exceto stagetimes), url, arquivo (o nome completo do arquivo com o controle/hash, usado pelo poller para saber exatamente qual arquivo buscar). FK: EVENTO (N fontes para 1 evento). Índice por evento, modalidade, tipo, trecho. Regra: o proxy lê a fonte correta conforme o filtro de modalidade e o trecho selecionado; o número de modalidades e de trechos com fonte cadastrada é o que o evento tiver (RF-CONFIG-003), não uma quantidade fixa.

Nota (2026-07-05, S67): a coluna arquivo foi adicionada em F3-06 (aditiva, sem afetar os registros existentes) e passou a ser preenchida pelo passo 2 do assistente; é o que permite ao poller montar a lista de arquivos a buscar a partir do banco, sem lista fixa no código.

Para que serve: guardar os documentos oficiais publicados pelo operador.

Relacionado com: RF-PAINEL-006, RF-PUB-008; tarefas F3-07, F2-09.

Onde fica: banco leve embarcado (metadados) mais armazenamento do arquivo quando por upload.

Especificação: atributos id (pk), evento (a chave natural, o slug Chronosat do evento, ex. minasbr26, a mesma chave usada por DADOS_EVENTO ART-ENT-07; quando a entidade EVENTO nascer como tabela própria, migra para evento_id FK com backfill, sem quebrar a leitura), titulo, url (endereço do link externo ou caminho do arquivo salvo pelo upload), ordem (posição de exibição, atribuída automaticamente ao final da lista do evento). FK: EVENTO (N PDFs para 1 evento, hoje pela chave natural evento). Regra: aparece na central pública se existir; ausência não aparece; remover é escopado ao evento (um operador não remove PDF de outro evento). Não existe coluna de origem persistida: o desacoplamento entre "veio de link" e "veio de upload" é feito na camada de código, não no dado. O armazenamento puro (salvarUploadPdf, grava o arquivo no volume do servidor com nome próprio anticolisão e antitravessia, valida tipo e assinatura do arquivo, devolve a URL pública /uploads/<nome>) é uma peça separada do registro (adicionarDocumento(evento, titulo, url), que grava título e url sem saber de onde vieram); quem decide a rota (link informado direto vs upload processado primeiro) é o formulário do painel. Esse desenho é o que permite a uma forma de entrada futura (por exemplo um webhook que recebe PDFs automaticamente da Chronosat) convergir na mesma escrita adicionarDocumento, sem precisar de coluna nova nem mudança na central pública.

Para que serve: registrar competidores ocultados manualmente pelo operador da página pública, de forma reversível.

Relacionado com: RF-PAINEL-007; tarefa F3-08.

Onde fica: banco leve embarcado.

Especificação: atributos id (pk), evento (chave natural, o slug Chronosat do evento, mesma chave de DADOS_EVENTO e de PDF, ART-ENT-04/07), modalidade (fecha a granularidade, pois um numeral não é único entre modalidades do mesmo evento), numeral, ocultado_em (trilha informativa, não muda a semântica). Chave única composta: (evento, modalidade, numeral). KISS por presença: não há coluna de status ou de origem; a PRESENÇA da linha é o que oculta. Ocultar é um INSERT idempotente (ocultar duas vezes a mesma tripla é no-op); reexibir é um DELETE idempotente pela mesma chave. Distinto do oculto na origem (_status="O" no dado bruto da Chronosat, RF-REGRA-006, canal ortogonal que não escreve nem lê esta tabela).

Para que serve: guardar cada conta nominal de acesso ao painel, com papel, para que administrador (equipe Modulareasy) e operador (equipe Sertões) entrem cada um com a sua credencial (ADR-011 revisado). Substitui a entidade OPERADOR diferida (que modelava só id/login/ativo, sem senha e sem papel): agora é real, com senha por usuário e papel.

Relacionado com: RF-PAINEL-001 (revisado), RF-PAINEL-011, RNF-SEG-002, RNF-SEG-003, RNF-SEG-005, ADR-011; tarefas F3-13 (migração e seed), F3-14 (autenticação por conta). Ver ART-ACS-01.

Onde fica: banco leve embarcado; sem exposição pública.

Especificação: atributos id (pk), login (único), hash_senha (a senha guardada apenas como hash, nunca em texto puro), papel (enum: administrador, operador, dois valores, sem matriz de permissões além disso), ativo (booleano; uma conta desativada não entra, e desativar não apaga a conta nem o histórico), criado_em, atualizado_em. Chave única: login. Regra de escrita: só o administrador cria e edita contas (RF-PAINEL-011); não há autocadastro público. Regra de leitura: usada na autenticação (comparação do hash) e na tela de gestão de contas (lista de login, papel e situação, nunca a senha). Seed inicial: as contas de administrador da equipe que opera o sistema (cada uma com senha própria hasheada) e a conta de operador da Sertões (migrada do login único anterior). O papel decide o acesso por um único teste "é administrador?": administrador vê todas as telas, operador não vê gestão de contas nem auditoria.

Para que serve: persistir cada leitura bem-sucedida da Chronosat como o estado mais recente daquela fonte, para o resultado nunca se perder, com ou sem encerramento pelo operador, mesmo depois de a Chronosat retirar os dados da origem.

Relacionado com: RF-INGEST-005, RF-PAINEL-009, RNF-ARQ-001, ADR-003, ADR-009, ADR-012; tarefa F1-03.

Onde fica: banco (fonte de verdade das páginas públicas).

Especificação: atributos id (pk), evento_id (fk), modalidade, tipo (enum: crews, racetimes, stagetimes), trecho (nulo exceto quando tipo = stagetimes), payload_bruto (JSON, exatamente como veio da origem, sem normalização), lido_em (momento da última leitura bem-sucedida). FK: EVENTO (N registros de DADOS_EVENTO para 1 evento). Chave única: evento_id + modalidade + tipo + trecho (um registro por fonte; cada leitura bem-sucedida faz upsert por cima do registro existente daquela fonte, não insere uma linha nova por leitura, não é série temporal, ver ADR-009). Regra de escrita: toda leitura bem-sucedida do proxy (RF-INGEST-001) grava aqui, durante o evento inteiro, do primeiro minuto ao encerramento. Regra de leitura: a página pública e a API interna leem sempre deste registro, nunca da Chronosat diretamente; a normalização (cruzamento pela chave numeral, regras de interpretação do Ap.2) acontece na exibição, a partir do payload_bruto, não na escrita (ADR-012). Ao encerrar o evento (RF-PAINEL-009), nada é copiado: o sistema apenas para de escrever novas leituras aqui e o campo estado de EVENTO passa a encerrado; o último payload_bruto de cada fonte já é, por construção, o resultado final. Distinto do cache de janela curta (RF-INGEST-002, ART-INFRA-03), que é só proteção de taxa em memória e não é fonte de verdade; DADOS_EVENTO é a persistência real, em banco, desde o primeiro minuto.

Para que serve: registrar de forma imutável quem fez o quê e quando no painel, para que o acesso administrativo seja rastreável (RF-PAINEL-012).

Relacionado com: RF-PAINEL-012, RNF-SEG-004; tarefa F3-16.

Onde fica: banco leve embarcado; consultável só pelo administrador.

Especificação: atributos id (pk), usuario_id (fk USUÁRIO, nulo quando o registro é uma tentativa de login negada), acao (enum: login, login_negado, criar_conta, editar_conta, desativar_conta, reativar_conta, mudar_papel, redefinir_senha), alvo (sobre o que a ação incidiu, por exemplo o id da conta afetada), detalhe (descrição curta; nunca a senha), registrado_em (momento). FK: USUÁRIO (N registros para 1 usuário). Regra de escrita: gravado nos pontos de F3-14 (login e login negado) e F3-15 (criar/editar/desativar/reativar conta, mudar papel, redefinir senha); a redefinição de senha registra a troca, nunca o valor. Regra de leitura: consulta do administrador na tela de auditoria (ART-SCR-06), do mais recente ao mais antigo. O registro é só escrita e leitura, nunca editável pelo painel (imutável).

Para que serve: o operador edita todo o perfil de cada vertical (identidade, home e regra de exibição) e adiciona novas, sem depender de desenvolvimento.

Relacionado com: RF-CONFIG-001, RF-PUB-010, RF-PUB-015, RF-PUB-016; tarefa F3-02.

Onde fica: painel do operador, tela de verticais.

Especificação: materializa o perfil completo de ART-ENT-01.

Para que serve: o operador alterna o estado do campeonato (rascunho, ao vivo, encerrado).

Relacionado com: RF-PAINEL-005, RF-PAINEL-009, RF-INGEST-005, RF-PUB-009; tarefa F3-06.

Onde fica: painel, controle de estado.

Especificação: parâmetro estado, enum (rascunho, ao_vivo, encerrado), default rascunho ao criar. Quem edita: operador. Efeito ao mudar: imediato (liga e desliga a atualização automática pública). Ao mudar para encerrado, o sistema apenas para de buscar a origem; nada é copiado ou recalculado, porque cada leitura já ficou persistida em DADOS_EVENTO desde o primeiro minuto (ART-ENT-07, RF-INGEST-005). A página continua sendo servida desse mesmo registro, permanecendo publicada para sempre, por evento e por ano, mesmo depois de a Chronosat sair do ar; não há prazo de expiração. Encerrar não é uma condição para não perder dado (isso já está garantido pela persistência contínua), é apenas o sinal visível ao público de que a prova acabou.

Para que serve: o operador guarda as fontes de dados do evento, incluindo o controle (hash) de cada URL quando ele muda durante a prova.

Relacionado com: RF-CONFIG-003, RF-PAINEL-003; tarefas F3-04, F3-11.

Onde fica: painel, passo 2 do assistente, e reconfigurável depois de publicado.

Especificação: conjunto de URLs por modalidade e trecho (materializa ART-ENT-03), em número dinâmico conforme o que o evento tiver, sem quantidade fixa. Entrada: o operador cola de uma vez o bloco de URLs entregue pela Chronosat (o documento do evento) e o sistema extrai e classifica cada arquivo pelo padrão do nome {evento}_{modalidade}_{tipo}_{trecho}_{controle}.json, sem separar campo a campo (RF-PAINEL-003). O rótulo de cada modalidade vem do crews quando disponível e pode ser confirmado ou ajustado pelo operador. Quem edita: operador. Efeito ao mudar: próximo ciclo de leitura passa a usar a nova fonte, imediato, sem deploy. Validado pelo teste de conexão antes de publicar. Novos arquivos de stagetimes (trechos que começam ao longo dos dias) entram pelo mesmo caminho; se a Chronosat mudar um controle no meio da prova, o operador atualiza a URL da fonte no painel a qualquer momento, sem depender de desenvolvimento.

Para que serve: ocultar e reexibir um competidor da página pública.

Relacionado com: RF-PAINEL-007; tarefa F3-08; entidade COMPETIDOR_OCULTO (ART-ENT-05); tela Ocultar competidor (ART-SCR-02).

Onde fica: painel, /painel/eventos/:id/ocultacao.

Especificação: o operador busca o competidor por numeral, nome ou equipe e alterna Ocultar/Reexibir por um botão; a tela mostra uma pill EXIBIDO ou OCULTO por competidor. Materializa ART-ENT-05 (INSERT idempotente para ocultar, DELETE idempotente para reexibir, chave evento+modalidade+numeral). Quem edita: operador. Efeito ao mudar: imediato na página pública, um único filtro aplicado depois de consolidar o evento remove o competidor do pódio, da tabela, do contador e dos modais de uma vez; reexibir traz de volta nos mesmos lugares. Reversível, sem limite de quantas vezes.

Para que serve: definir quais rotas o monitor de status (ART-SCR-07) verifica, uma por área, para o health-check não enumerar todas as páginas por evento.

Relacionado com: RF-PAINEL-013; tarefa F3-17; consumida por ART-SCR-07.

Onde fica: configuração de código do app (mesmo padrão do registro de verticais), não uma tabela de banco (decisão KISS: é uma lista pequena e estável, mantida junto do código como o resolvedor de verticais).

Especificação: uma lista de entradas, cada uma com area (rótulo legível, por exemplo "Home global", "Home Series", "Painel", "Verificação de saúde", "Site Sertões"), rota (o caminho a verificar, por exemplo /, /series, /painel, /health) e tipo (interna do sistema ou âncora do site). Regra de curadoria: exatamente uma rota representativa por área; proibido enumerar rotas por evento (nada de /series/2026/<evento> por evento). Como cresce: adicionar uma vertical, uma área do painel ou uma âncora do site é acrescentar uma entrada nesta lista, sem código novo (config-driven, alinhado ao ADR-010 e ao RF-CONFIG-001). Entradas de seed (ajustáveis): Home global (/), Home Series (/series), Painel (/painel), Verificação de saúde (/health), e as âncoras do site institucional da Sertões que se queira acompanhar. Quem edita: sustentação, na configuração do app. Efeito ao mudar: a próxima verificação do monitor passa a incluir ou excluir a rota.

Para que serve: definir os dois papéis autenticados do sistema (ADR-011 revisado): operador (equipe Sertões) cadastra e gerencia os campeonatos; administrador (equipe Modulareasy) faz isso e mais a gestão de contas e a auditoria. Não há matriz de permissões por recurso: um único teste "é administrador?" separa as duas telas exclusivas do administrador das demais.

Relacionado com: RF-PAINEL-001 (revisado), RF-PAINEL-011, RF-PAINEL-012, RF-PAINEL-009, RF-PAINEL-010, RF-CONFIG-001, RNF-SEG-002, RNF-SEG-003, RNF-SEG-004; tarefas F3-13, F3-14, F3-15, F3-16. Materializa-se sobre USUÁRIO (ART-ENT-06).

Onde fica: painel único; contas em USUÁRIO (ART-ENT-06), provisionadas pela sustentação (as primeiras de administrador) e depois pelo próprio administrador.

Especificação: contas nominais com papel, cada uma com senha própria hasheada; todas as verticais (Series, Petrobras, MTB, Kitesurf e futuras) no escopo de ambos os papéis; não existem credenciais nem painéis separados por vertical.