MOJ: Manual do organizador (o painel .admin do contest)

Este manual é para quem opera um contest: o dono da conta .admin. Ele explica cada aba do painel de administração, cada opção de configuração, como habilitar os papéis especiais (.judge, .cjudge, .staff, .cstaff, .mon), e como ligar a correção validada por juízes — incluindo quantas pessoas você precisa.

Criar o contest (wizard, problemas, contas) é o outro guia: o tutorial do organizador. Aqui é a OPERAÇÃO, do dia da prova.

Você chega ao painel logando com a conta .admin do contest e clicando em ⚙ Administração na barra do topo.

1. O painel: a Central e os 4 grupos

O painel abre na 🏁 Central e tem quatro grupos na barra de cima; cada grupo tem seus painéis na segunda linha. O endereço guarda o painel (#grupo/painel), então dá para salvar o link — e os links antigos (#settings, #users, #machines…) continuam funcionando, redirecionados.

[🏁 Central] [🧩 Prova] [👥 Pessoas] [🎛️ Operação]                        📖 Manual

🏁 Central — o que falta e o que gerar

🧩 Prova — o conteúdo

Balão e o freeze. Por padrão, acerto feito com o placar congelado não gera tarefa de balão — e esses balões não são entregues depois: a tarefa não existe. É a regra de competição (o balão andando pela sala revela o que o freeze esconde), e vale só para o balão: pedido de impressão continua livre. Se você quiser o clássico do ICPC — balão circulando durante o freeze, plateia adivinhando — marque Entregar balão durante o freeze em Central › Regras; marcar também libera os que já ficaram retidos. O checklist pré-prova mostra qual política está valendo, e Operação › Situação mostra quantos balões estão retidos.

Como o placar marca quem resolveu. Por padrão a célula de quem resolveu é sempre igual (verde) e a cor do balão vai numa bolinha ao lado. É de propósito: a paleta ICPC dá o problema A branco, e branco sobre o fundo branco do placar é o mesmo pixel — quem resolvia o A parecia não ter resolvido (a queixa que originou a mudança veio de um estudante). Se você preferir o clássico — a célula inteira pintada com a cor do balão — marque em Central › Regras › Célula "resolveu" no placar; as cores claras ganham contorno para não sumirem. Vale para o placar, a cerimônia de revelação e o relatório.

👥 Pessoas — quem entra, quem é quem

🎛️ Operação — o dia da prova

Fora do painel, mas linkadas da Central: etiquetas de credenciais, cerimônia de revelação, jplag, fila do staff e placar.

2. Configurações — opção por opção

Identidade e janela

• Nome — o título exibido; o id (que vira o subdomínio) não muda.
• Início / Fim — a janela da prova. Antes do início: contagem regressiva; depois do fim: ninguém mais submete (exceto papéis de juiz). Prorrogação fina é na seção ⏱ (por regex de login — ex.: só uma sala que ficou sem luz).
• Abertura do login — a partir de quando o aluno consegue LOGAR (antes disso, contagem regressiva na tela de login). Útil p/ liberar o login minutos antes da largada.
• Freeze — congela o placar público a partir deste horário (estilo ICPC). Juízes e admin seguem vendo tudo; a revelação acontece na cerimônia.
• Idioma — o idioma default das telas do competidor.

O que o aluno vê/pode

• Login habilitado — desliga p/ trancar a porta (quem já está dentro continua).
• Ver código das submissões — o aluno rever o próprio código enviado.
• Ver log de execução — o relatório teste-a-teste. ⚠ Em prova valendo nota, deixar o log visível pode vazar os testes (o aluno vê entrada/saída) — o clássico "SHOWLOG" — desligue.
• Editor no browser — o editor lado a lado com o enunciado.
• Mostrar time-limit — exibe os TLs por linguagem no enunciado.
• Aceitar atrasados — permite login de conta criada depois da largada.
• Backup / Impressão — habilitam o upload de backup pelo aluno e os pedidos de impressão (que caem na fila do staff).
• Placar anônimo — esconde o desempenho individual (só a posição do próprio aluno).
• Gate de login por UA — só navegadores cuja identificação contém a substring conseguem logar (máquina de prova travada). Papéis privilegiados são isentos.
• 🕵️ SUPER SECRETO — o contest some da home/arquivo/status e até o placar exige login. Para provas que não podem nem constar que existem.

Julgamento

• Linguagens — a lista permitida no contest (cada problema pode restringir mais, em Prova › Problemas).
• Pool de juízes (máquinas) — quais MÁQUINAS de julgamento atendem este contest (vazio = qualquer juiz online). Não confundir com juízes HUMANOS (seção 4).
• Veredicto manual — liga a correção validada por juízes humanos (seção 4).
• Nº de juízes que validam cada veredicto — o quórum da correção manual: 1 a 5, padrão 2. Com 1, um único voto decide (revisão simples); com N≥2, o veredicto só sai com N votos unânimes — qualquer divergência vira conflito p/ o juiz-chefe.
• Penalidade (ICPC) — minutos somados por tentativa não aceita antes do Accepted (padrão 20) e QUAIS veredictos penalizam (padrão wa/tle/mle/rte — Compilation Error fica de FORA por padrão; vazio = nada penaliza).
• Placar completo p/ logins — allowlist de logins que veem o placar sem freeze (além de admin/juízes).

Pela CLI, tudo isso é moj contest -c <cid> settings set chave=valor (ex.: settings set manual_verdict=true review_judges=3).

3. Papéis especiais — o que são e como habilitar

Habilitar um papel é só criar a conta com o sufixo certo no login — na aba Usuários & sessões (ou moj contest -c <cid> users add fulano.judge). Não há caixinha de permissão: o sufixo É o papel. O auto-cadastro público nunca cria conta com esses sufixos (reservados), e operações em massa (reset de senha, desabilitar) pulam contas privilegiadas de propósito.

Regra de ouro: nenhuma conta com sufixo de papel entra no placar ou nas estatísticas — crie quantas precisar sem medo de sujar o resultado.

4. Correção validada por juízes (veredicto manual)

Com Veredicto manual ligado, o julgamento automático continua rodando, mas o veredicto fica retido: o aluno vê a submissão pendente até juízes humanos validarem.

O fluxo, na aba ⚖️ Avaliar (página do .judge):

1. O juiz pega uma submissão da fila (reserva com prazo; máx. N juízes na mesma).
2. Vê o veredicto computado, o log e o código, e vota (confirmar ou trocar o rótulo).
3. Quando N votos unânimes se acumulam (N = Nº de juízes que validam, padrão 2), o veredicto é liberado: entra no histórico do aluno e no placar na hora.
4. Votos divergentes viram conflito: o juiz-chefe (.cjudge) decide no painel dele (um alerta global avisa).

Quantas pessoas você precisa? No mínimo N contas .judge (o quórum) + 1 .cjudge para conflitos — e recomendo N+1 juízes para a fila não travar quando alguém pausa. O .admin também vota (conta como juiz), mas em prova grande deixe o admin livre p/ operar. Com N=1 um único juiz revisa tudo (bom p/ prova pequena); N=2 é o padrão equilibrado; N≥3 é para finais onde o veredicto precisa de banca.

5. Documentos da prova (Prova › Documentos)

A aba existe para o .admin e para o juiz-chefe (.cjudge), e produz os documentos da prova — cada um em PDF e HTML, em português, inglês e espanhol:

Fluxo, do começo ao fim

1. Preencha os dados (⚙️ Dados dos documentos): versão do caderno (v1.0), nota da capa e errata. Salve.
2. Ajuste a capa, se quiser (🎨 Capa do caderno). São três modos, nesta ordem de precedência: PDF enviado › texto editado › capa padrão. O texto editado é Markdown e aceita marcadores substituídos na geração: {{CONTEST_NAME}}, {{DATE}}, {{N_PROBLEMS}}, {{N_PAGES}}, {{SITES}}, {{VERSION}}. Envie um PDF quando a capa for arte pronta do evento — ela entra como está e o resto do caderno é anexado depois dela.
3. Ajuste o texto do info sheet, se quiser (📝): também Markdown, com os marcadores {{TOOLCHAIN}}, {{TL_TABLE}}, {{LANGS_TABLE}}, {{MEMLIMIT}}, {{STACK}}, {{CONTEST_NAME}} e {{DATE}}. Apagar o texto volta ao padrão embarcado.
4. Gere (botão de cada linha, ou Gerar todos (pt+en+es)). Converter os PDFs leva alguns segundos — o caderno é o mais demorado, porque junta um PDF por problema.
5. Confira: cada linha tem PDF, HTML e abrir. Reveja antes de publicar.
6. Publique o que a sede pode ver. Publicar faz duas coisas: o documento passa a aparecer na seção Prova da página do contest e toda a organização (.judge, .staff, .cstaff, .mon) consegue baixá-lo em 📄 Documentos, inclusive antes do início — o TIME é que espera a fase. Times NÃO veem caderno/time limits publicados antes do INÍCIO da prova — publicar cedo serve para a sede imprimir, sem vazar nada (o + notícia desses dois é recusado antes do início, porque a notícia anexa o PDF). O editorial só publica depois do fim. Marcando + notícia, o MOJ ainda cria uma notícia com o PDF anexado. Despublicar desfaz (o link some; a notícia, se criada, continua — apague-a na aba de notícias se for o caso).

Regenerou? Publique de novo não é preciso — o link publicado aponta para o documento atual, então gerar de novo já entrega a versão nova a quem baixar. Mas avise a sede: quem já imprimiu ficou com a versão velha (é para isso que serve o campo versão do caderno na capa).

⚠️ Enunciado não é traduzido. PT/EN vale para a capa, os títulos, as tabelas e o info sheet. O corpo do enunciado sai no idioma em que foi escrito — o MOJ guarda um enunciado por problema, não dois. Prova bilíngue continua exigindo dois problemas (ou um enunciado que já traga as duas versões).

🔒 Antes de publicar, o caderno é conteúdo de prova: só .admin e .cjudge conseguem baixá-lo. Para todo o resto (inclusive .cstaff e times) a API responde 404 — não é uma trava de interface.

6. Rodadas: aquecimento e prova oficial (Prova › Rodadas)

Toda maratona roda um aquecimento (dress rehearsal) antes da prova: dois ou três problemas fáceis, no dia anterior ou na manhã do dia, para o time ligar a máquina, testar o login, o editor, a impressão e o balão — e para a sua equipe de juízes e staff ensaiar. Depois disso a prova começa no mesmo contest, porque é a configuração dele (contas, senhas, sedes, cores de balão, time limits, linguagens, pool de juízes) que você quer garantir.

No MOJ isso são rodadas. A rodada no ar é a que aparece em Central › Regras e em Prova › Problemas; as demais ficam planejadas até você promover.

O roteiro (repare na ordem: o aquecimento vem PRIMEIRO)

1. Monte o contest normalmente, com os problemas do aquecimento e a janela do aquecimento.
2. Em Prova › Rodadas, dê o nome certo à rodada no ar (aquecimento, tipo aquecimento) e crie a próxima (oficial): janela, freeze e a lista de problemas da prova de verdade. A lista fica guardada e só entra no ar na promoção — ninguém vê os problemas da prova antes.
3. Rode o aquecimento. O time vê uma faixa fixa dizendo que é aquecimento e que aquele placar não é o da prova. Trate-o como ensaio geral da operação inteira: se o login abre no minuto do início (modelo ICPC), esse é o único momento em que cada papel toca as telas de verdade sem nada em jogo. Entregue antes a cada pessoa o tutorial do papel dela (/contest/ajuda/) e peça que rode a própria lista: o time (entrar, abrir problema, enviar de propósito, clarification, impressão, backup, placar), a equipe de sala (impressora, o pop-up liberado, kiosk, o trajeto), o chefe de sede (todo time da sede entrou pelo menos uma vez), os juízes (opções de veredicto, log/código, a dupla lendo igual), o chefe (nº de juízes, auto-veredicto, alarme de conflito) e o telão (projetor, chave de webcast no Animeitor, fotos e músicas).
4. Quando terminar, clique 🚀 Promover. O MOJ confere o checklist e, se estiver tudo pronto:
   • arquiva a rodada — submissões (com código-fonte), veredictos, log do juiz, placar, estatísticas, clarifications, notícias, tarefas do staff e os logs de acesso ficam guardados em rounds/<rodada>/, mais um relatório navegável da rodada;
   • zera o placar e o histórico dos times, reinicia a numeração da impressão e limpa as prorrogações por sede;
   • aplica a janela e os problemas da prova oficial. Você digita o id do contest para confirmar. Tudo é auditado.

Registrei a PROVA primeiro — e agora? Aconteceu de montar o contest já com a prova e só depois criar a rodada de aquecimento? Não promova — promover arquiva a rodada no ar (a sua prova, vazia), e arquivo é imutável. O certo é inverter editando as duas rodadas ali mesmo (o painel avisa quando detecta uma planejada começando antes da que está no ar):

1. Edite a rodada planejada: renomeie para prova, tipo prova oficial, e dê a ela a janela + freeze da prova; em Problemas da rodada, coloque a lista da prova (fica guardada, ninguém vê).
2. Edite a rodada no ar: renomeie para aquecimento, tipo aquecimento, janela do aquecimento (sem freeze) e troque os problemas pelos do aquecimento — na rodada no ar, salvar aplica na hora.
3. Confira em Central › Regras que a janela vigente é a do aquecimento — e siga o roteiro normal a partir do passo 3.
4. Depois: o placar e as submissões do aquecimento continuam legíveis em 🔁 Rodadas (e você pode publicar a rodada para os times verem). O arquivo bruto em .tar.gz — com código-fonte — sai por um clique, para a auditoria posterior.

O checklist é sério. A promoção RECUSA enquanto houver:

Há um --force (checkbox "ignorar os bloqueadores"), para emergência: ele não desfaz o risco, só assume que você sabe o que está fazendo. O único que o --force não ignora é o no_next_round (sem rodada planejada não há para onde promover).

Contest que usa as contas de outro (USERS_FROM) promove normalmente — o arquivamento só mexe no users/ local. Já foi bloqueador; deixou de ser, porque é justamente o caso de uso real (aquecimento + prova com as contas do treino).

O que NÃO muda na promoção: contas e senhas, times/sedes/bandeiras, escopo do staff, cores de balão, regiões, time limits calibrados, linguagens, pool de juízes, matriz de auto-veredicto e os textos/capa dos documentos. O que zera: placar, histórico e submissões dos times (arquivados, não perdidos), balões, numeração de impressão, prorrogações, e a lista de documentos publicados.

⚠️ Cores de balão são por LETRA. Se o problema A do aquecimento e o A da prova são diferentes, a cor do balão A é a mesma nas duas rodadas. Confira em 🎨 Aparência antes da prova.

Na CLI: moj contest -c <cid> rounds ls | add | set | problems | promote | publish | archive.

6½. Depois da prova: encerrar o evento

Quando a prova acaba, o placar continua congelado e os documentos seguem não publicados até alguém mandar liberar — nada disso vira automático com o relógio. A Central passa a mostrar o bloco "Depois da prova" com o checklist do que ainda está fechado e o botão 🏁 Encerrar evento, que faz de uma vez as duas coisas que todo mundo esquece:

1. abre o placar — tira o congelamento (FREEZE_TIME=0), então o resultado final fica público (é o mesmo efeito do botão "🔓 Descongelar tudo" da cerimônia de revelação);
2. publica os documentos já gerados que ainda não estavam publicados — caderno, folha de limites de tempo, info sheet e editorial passam a aparecer em "Arquivos & Recursos" para os times. (O editorial só pode ser publicado depois do fim; por isso ele entra aqui.)

O botão não mexe no resto: liberar o relatório de correção para os times (SHOWLOG), abrir o código das outras equipes (SHOWCODE), mostrar os limites de tempo e liberar as coortes (convidados) continuam sendo escolha sua — cada um aparece no checklist com o atalho "resolver →" para a tela certa. Só roda depois que a prova terminou para todas as sedes (prorrogação por sede conta) e pode ser repetido à vontade: na segunda vez ele não faz nada.

Fecha o ciclo com o relatório final (Operação › Situação): o tar.gz navegável leva o placar aberto, as submissões, as estatísticas completas, os enunciados e os documentos publicados — é o pacote que se manda para os participantes e para o arquivo do evento.

7. Máquinas dos times (Pessoas › Máquinas & gate)

É no aquecimento que os times ligam de fato os computadores — e é dali que o MOJ tira o mapa time × IP × navegador da sala (do log de acessos do contest, recortado pela janela da rodada: nada novo é capturado). A aba mostra, por rodada:

• por time: nome, sede, IPs e navegadores usados, primeiro login e um alerta quando o time usou mais de um IP;
• por IP: quais times vieram de cada máquina — e marca IP compartilhado (dois times na mesma máquina é sinal de mesa trocada ou conta emprestada);
• quem trocou de máquina: na prova oficial, o time que loga de IP/navegador diferente do que usou no aquecimento aparece marcado em vermelho;
• ⇣ CSV de tudo, para conferir com a planilha da sede.

Duas ações saem daqui e escrevem no lugar de sempre:

• aplicar sede: na visão por IP, digitar o nome da sede e clicar grava a sede dos times daquele IP (o mesmo campo de Pessoas › Times) — o placar, as etiquetas e o escopo do staff passam a respeitá-la;
• configurar o gate de navegador: a seção 🔒 no topo da aba (logo abaixo) — os navegadores realmente vistos na rodada ficam listados lá, e cada um pode virar o fallback com um clique.

O gate POR SEDE (o caso da maratona)

Quando cada sede roda a sua imagem, o UA de cada máquina carrega um pedaço do próprio login do time: teambrspso001 (Brasil/BR, São Paulo/SP, Sorocaba/SO) roda numa imagem cujo UA contém brspso. Uma substring única não serve — então o MOJ deriva o esperado do login.

Na web (seção 🔒 no topo de Pessoas › Máquinas & gate): a chave "Barrar quem não vem da imagem da sede" liga/desliga; abaixo dela vão a regex do login com captura e o UA esperado (\1), com um testador ao vivo ("testar com o login" → UA precisa conter brspso · sede Sorocaba), e três listas dobráveis — overrides por sede, regras por regex de login e isentos. Salvar já vale para o próximo login.

Na CLI, o mesmo:

moj contest -c <cid> ua-gate set --from-login '^team([a-z]{6})[0-9]{3}$' --expect '\1'
moj contest -c <cid> ua-gate set --region 'Sorocaba=brspso-v2'     # sede fora do padrão
moj contest -c <cid> ua-gate set --exempt '^ccl' --exempt time-reserva-07
moj contest -c <cid> ua-gate check teambrspso001                   # o que se espera dele
moj contest -c <cid> ua-gate show

Uma regra cobre todas as sedes de uma vez. A ordem de resolução é: isentos › conta de papel (sempre entra) › regra por regex › override da sede › captura no login › substring única (o login_ua_substring de sempre, que continua valendo como último recurso).

• Quem não casa é barrado no login (403) — a decisão foi barrar, com a lista de isentos como margem. --mode off desliga o gate sem apagar a configuração.
• O painel Máquinas & gate mostra UA esperado × UA visto por time e conta quantos estão fora da imagem da sede: é assim que se conserta a sala no aquecimento, antes de o gate barrar alguém na prova.
• Quem já está logado com o navegador errado sai com "Deslogar UA divergente" (Pessoas › Sessões & anomalias), que compara cada sessão com o esperado daquele time.
• Trava de sede por IP (chave na mesma seção 🔒, DESLIGADA por padrão — ligue na prova): o gate e o isolamento por subdomínio não seguram curl --resolve moj…:443:<IP> da máquina de prova ao site base (treino, backups que o aluno subiu antes, outro contest). Com a trava, cada login de competidor prende o IP de origem (a saída da sede) a esta prova até o fim + folga; daquele IP qualquer outro alvo responde 403 site_locked, inclusive sessão do treino aberta antes. Contas de papel são isentas. Toda reivindicação e todo bloqueio vão ao audit (site-lock-claim, site-lock-block) e aparecem em Pessoas › Sessões & anomalias, com "soltar" por IP e "prender IPs já vistos" (útil na manhã da prova). Efeito colateral aceito: durante a janela, todo mundo atrás daquele IP público perde o treino.
• Sessão única por time (chave na mesma seção 🔒, ligada por padrão): com o gate valendo, um login novo em outra máquina derruba a sessão anterior do time. Trocar de máquina por defeito continua funcionando (o time loga na nova e a velha perde a sessão); recarregar a página na mesma máquina não derruba nada. Cada queda vira um evento em Sessões & anomalias.

7½. Sessões & anomalias (Pessoas › Sessões & anomalias)

Na Maratona 2026 só deu para responder "algum time usou duas máquinas?" depois da prova, cruzando logs à mão. Este painel responde durante a prova. Ele só vale com o gate de UA ligado: é o navegador da imagem do mlinux que identifica a máquina (machine_id/boot_id). Login de navegador comum só tem o IP, e atrás de NAT o IP é a sede inteira: esses logins ficam fora das anomalias de máquina (aparecem só em "UA fora da sede" e na lista de sessões). Com o gate desligado o painel avisa e mostra só as sessões e o log de acessos.

• Cartões (clique = filtro): sessões ativas, 👥 2 sessões vivas (o mesmo time em duas máquinas — com a sessão única ligada isso só acontece por token copiado), 🖥 máquina compartilhada (2+ times logaram na mesma máquina na prova; grave se os dois estão vivos nela), 📤 submissão de outra máquina (a submissão veio de uma máquina diferente da que fez o login; mesma máquina reiniciada aparece como info), 🧭 UA fora da sede, 🏫 sede sem máquina por time (da última coleta do nutellaboot), 🔁 trocou de máquina (info: normal quando a máquina falha) e as revogações da sessão única.
• Linha do tempo: cada evento com hora, tipo, time, máquina e detalhe; filtros por tipo e texto; CSV; botão deslogar o time.
• Times: só os com alguma anomalia (ou todos com sessão): sessões vivas e em quantas máquinas, as máquinas usadas na prova em ordem, a última submissão (✓ veio da máquina da sessão; ✗ não) e as anomalias como etiquetas.
• 🚪 Sair em massa e trava de login: a troca de rodada em três cliques — fechar o login (competidor recebe 403 login_disabled; a organização entra), deslogar competidores, staff e chefes de sede ou os dois (nunca admin, juízes, chefe, monitor nem telão), promover a rodada em Prova › Rodadas, e reabrir o login quando os times puderem entrar. Cada sessão derrubada vira evento na linha do tempo; a ação vai ao audit (logout-all).
• 🔒 Trava de sede: os IPs presos a esta prova (logins, bloqueios, até quando), os bloqueios registrados (quando, IP, alvo, rota, sessão) e os botões soltar e prender IPs já vistos. O cartão "bloqueios da trava" e os eventos 🔒 da linha do tempo vêm do audit. A seção 7 explica.
• Canais: quantos logins e submissões da prova vieram da web, da CLI (moj-comp) e de pacotes offline. Vale mesmo sem gate. A CLI se identifica no User-Agent (moj-comp/<build>) e, na máquina de prova, manda na frente o mesmo User-Agent do navegador da imagem (lido de /etc/moj/user-agent, gravado pela imagem): é assim que ela passa no gate por sede e fica com a mesma chave de máquina do browser — usar as duas na mesma máquina não derruba a sessão. Fora da máquina de prova a CLI é barrada pelo gate (403), de propósito.
• Atualiza sozinho a cada 30 s. A submissão grava a origem (IP, navegador e a sessão usada) em var/submit-origin.log; os logins em var/access.log; as quedas de sessão em var/session-events.log — os três atravessam as rodadas e entram no arquivo.

8. Times convidados (coortes de placar)

Maratona convida times que competem sem entrar na disputa oficial — o pessoal chama de convidado, extra-oficial, "CCL". O MOJ trata isso como coorte: um grupo de times com política de visibilidade própria.

O que uma coorte privada garante

• os times dela não aparecem no placar público;
• os times regulares não sabem que ela existe — nem no placar, nem no diretório de times (/contest/teams, que é público e listava todo login);
• os próprios convidados veem todos (o placar deles traz oficiais + convidados);
• quando você libera os resultados, todo mundo passa a ver todos, e o convidado aparece intercalado pelo desempenho mas sem consumir posição oficial — o pódio combinado continua batendo com o oficial.

Como configurar (Pessoas › Coortes)

Uma linha por coorte, com o que decide o comportamento: id, nome, regex do login, pública (aparece no placar público), extra-oficial (entra sem consumir posição), padrão (quem não casa nada cai nela) e vê — as caixas que dizem quais coortes aquela visão enxerga (a coorte sempre vê a si mesma). A coluna times conta quantos estão em cada uma.

• + criar coorte: nasce privada e extra-oficial vendo todas — que é o caso do CCL.
• atribuir: escolhe um time e a coorte dele (o campo vence a regex); "— pela regra —" solta o time de volta para o regex.
• 📌 Materializar (N): carimba a coorte de quem hoje só casa por regex — depois disso, mudar o regex não remaneja ninguém. O contador diz quantos times estão nessa situação.
• 🔓 Liberar resultados: pede o id do contest digitado para confirmar (é irreversível na prática — o placar público passa a mostrar todos).
• Placares gerados: as visões que o build.sh mantém (uma por coorte que vê um conjunto diferente, mais a pública).

Para mudar a coorte padrão, marque o rádio da outra linha e salve aquela linha. Remover uma coorte exige que ela esteja vazia (e a padrão nunca é removível).

A mesma coisa na CLI:

moj contest -c <cid> cohorts ls
moj contest -c <cid> cohorts add ccl --name "Café com Leite" --regex ccl --private --unranked
moj contest -c <cid> cohorts assign timeconvidado07 ccl     # convidado sem 'ccl' no login
moj contest -c <cid> cohorts materialize                    # carimba a regra em campo por time
moj contest -c <cid> cohorts release                        # o "liberamos tudo" (pede o id)

A coorte casa por regex no login e/ou pelo campo .team.cohort de cada time (o campo vence). materialize transforma a regra em dado: depois disso, mudar o regex não remaneja ninguém. Quem não casa nada cai na coorte default (a dos oficiais).

O que continua completo, de propósito — são papéis privilegiados, e você precisa deles: ⚖️ Todas as Submissões, 📊 Estatísticas (inclusive quem resolveu primeiro), a fila do staff (o balão do convidado tem de ser entregue) e o relatório final. Duas consequências práticas:

• não ligue "ver código das submissões" (SHOWCODE) numa prova com convidados: ela abre o fonte de qualquer submissão para qualquer login;
• publicar o arquivo de uma rodada (Prova › Rodadas) exige os resultados liberados quando há coorte privada — o relatório da rodada traz o placar aberto com todos.

ℹ️ Sobram dois canais numéricos que não escondem identidade mas existem: a página de status pública conta as submissões pendentes de todos os times, e a numeração de tarefas de impressão é única por contest (saltos indicam atividade que o time não vê).

8½. Inscrição prévia e times de 3 contas do treino

Vale para contest criado com "usuários compartilhados do Treino Livre". Ligando a inscrição (Pessoas › Inscrições → Ligar inscrição), o contest passa a ter uma porta: quem não se inscreveu não entra (a API recusa o login, não é só a tela).

Como a pessoa se inscreve: no site principal, logada no treino, em /contests/inscricao/?c=<id> (o cartão do contest na home ganha o botão 📝 Inscreva-se). Ela escolhe individual ou criar um time: dá um nome e convida até 2 logins do treino; cada convidado precisa aceitar. Enquanto a janela estiver aberta dá para sair, renomear e desfazer. Participação é exclusiva — aceitar convite desfaz a inscrição individual.

O convite avisa sozinho. No instante em que o capitão convida, o mojinho manda uma DM ao convidado com o link de aceitar/recusar; e na véspera do fechamento (24 h antes) manda um único último aviso para quem ainda não respondeu (a mensagem sai em português; se o contest estiver com LOCALE=en, vai em inglês e português no mesmo texto — DM não tem seletor de idioma). Só alcança quem tem Telegram vinculado (perfil do treino → 📨 Telegram) — por isso a lista de convites mostra 📨 (alcançável) ou ⚠️ (sem canal), e o resumo conta quantos ficaram sem. Na tabela de times, cada convite pendente tem o botão 🔔 para cutucar na hora, e o cabeçalho tem 🔔 Lembrar todos; cutucar à mão não cancela o aviso automático da véspera. Para desligar o automático neste contest, desmarque lembrete automático na caixa da janela (grava REG_REMIND=n). Isso importa porque quem não aceita o convite não entra no time — e às vezes nem está inscrito.

Na prova, cada membro entra com o PRÓPRIO login e senha do treino e a sessão vira a do time: o placar, os balões e a impressão veem uma linha só. Quem estava no teclado fica registrado (var/actor-log e a 5ª coluna do var/access.log) — útil para conferir depois.

A janela (Pessoas › Inscrições → Janela de inscrição): abre (vazio = já aberta), fecha (vazio = o início da prova) e atraso (min) — minutos após o início em que ainda dá para entrar, mas na coorte …-atrasado, que aparece no placar sem ocupar posição (é a extra registration do Codeforces). Passou disso, a porta fecha.

Em que relógio estão esses campos: no do seu navegador — a caixa mostra qual é, logo abaixo. Já as horas que o MOJ escreve para as pessoas (a DM do mojinho, o checklist pré-prova, a data do caderno, o relatório final) saem no fuso da prova, que você define em Central › Regras → 🕒 Identidade e janela → Fuso horário da prova (vazio = America/Sao_Paulo). Quando os dois relógios diferem, a caixa da janela mostra também o horário no fuso da prova, para não haver dúvida.

Placar: a inscrição semeia as coortes individual e times, cada uma com placar próprio — o seletor "Placar: Geral | Times | Individual" aparece sozinho na página do placar. Se o contest já tinha coortes configuradas, o checklist pré-prova avisa que faltam essas duas.

Com AQUECIMENTO (o esquenta que fica dias no ar): planeje as duas rodadas em Prova → Rodadas (aquecimento agora, prova oficial na data real). Por padrão o aquecimento também exige inscrição — é nele que o competidor resolve login, submissão e placar; deixar entrar sem inscrição só empurra o problema para o dia da prova. A inscrição fecha sozinha no início da prova oficial (é essa data que o "fecha" herda, não a do aquecimento). Se você preferir o aquecimento de porta aberta (qualquer conta da fonte entra sem inscrição), ligue REG_WARMUP_OPEN=y no conf — nesse caso a promoção derruba a sessão de quem não se inscreveu e o placar da prova nasce só com os inscritos; o painel mostra o selo 🔥 aquecimento: entrada livre enquanto isso vale.

O modo de participação é definitivo: depois de inscrito (individual ou em time), o competidor não cancela nem troca de modo sozinho — a página de inscrição deixa isso claro antes da escolha, e qualquer mudança passa por você (Pessoas › Inscrições: remover, dissolver, inscrever à mão).

O time também declara na inscrição: a universidade (vira o prefixo [SIGLA] Nome do Time no placar e a coluna/filtro de escola), o uso de IA (aparece como 🤖 ao lado do nome — é transparência, não julgamento), a bandeira (país ou estado do Brasil — a bandeirinha do placar) e uma foto do time (a que vai ao telão; reprocessada no servidor, sem metadados). Tudo editável pelo capitão enquanto a janela estiver aberta, e visível no seu painel e no CSV. O inscrito INDIVIDUAL declara as mesmas coisas (menos a foto): universidade, IA e bandeira, na inscrição ou depois, pela mesma página. A organização ajusta qualquer um pelas ações team-meta/individual-meta do painel — sem regra regex no teams-meta.json (o mecanismo legado continua valendo só como sobreposição visual).

Dica de dia de prova: o checklist da Central mostra quantos se inscreveram e quantos convites ficaram pendentes — convite não aceito significa gente achando que está no time e que, na hora, não entra.

9. Template de usuários (habilita todas as funções)

Cole na carga em lote de Pessoas › Contas (uma linha por conta: login nome), ou crie um a um com moj contest -c <cid> users add <login> --name "<nome>":

juiz1.judge      Juiz Um
juiz2.judge      Juiz Dois
juiz3.judge      Juiz Três (reserva do quórum de 2)
chefe.cjudge     Juiz Chefe
apoio1.staff     Staff de impressão e balões
sede1.cstaff     Chefe da Sede 1 (etiquetas + revelação)
monitor1.mon     Monitor (responde clarifications)

Depois: ligue Veredicto manual (e ajuste o Nº de juízes) em Central › Regras; distribua as senhas geradas; cada pessoa loga na MESMA tela do contest e vê os botões do seu papel.

10. Referências

• Manual do juiz humano — a operação da aba ⚖️ Avaliar e do juiz-chefe.
• Manual do staff — impressão, balões, etiquetas, revelação por sede.
• Manual do competidor — o que o aluno vê (distribua com as senhas).
• Tutorial do organizador — criar o contest (wizard e CLI).
• CLI do competidor — envio pelo terminal, com modo sem-Internet.