Status: DECIDIDO
usuario (account) é separado de atleta (profile). Um atleta pode existir como perfil no sistema — criado a partir de um resultado importado — antes de ter conta. Quando a pessoa se cadastra, ela reivindica (claim/merge) o perfil que já existia, com histórico já populado.
Esse é um gancho de crescimento orgânico: o atleta descobre que já tem um ranking esperando por ele, montado a partir de competições reais.
A reversão de um resultado recalcula o que precisa, mas notifica apenas os diretamente interessados (os atletas da partida, o organizador) — não o feed inteiro. Evita poluir a experiência de muitos por uma correção pontual.
Definidas centralmente pelo proprietário via admin global. Não há fluxo público de "solicitar modalidade".
| NÃvel | O que é | Responsabilidades |
|---|---|---|
| Multimodalidade | camada suprema/global, posto de comando do proprietário | criar modalidades, gerir academias/parcerias, supervisionar importação, planos/cotas, visão consolidada |
| Segmentado por modalidade | painel operacional por esporte | ranking, atletas, eventos, validações/recursos daquele esporte |
O multimodalidade contém os segmentados; criar uma modalidade gera seu painel. Operação: o proprietário opera tudo no lançamento. O modelo de papéis já inclui um papel delegável de "admin de modalidade" (estrutura pronta, delegação ativada depois).
Escolher uma região + poucas modalidades, firmar parceria com academias locais e importar os resultados históricos delas, para o ranking nascer cheio, não vazio.
Decisão: a região é apenas critério do proprietário para escolher onde firmar parcerias — não vira dado (sem campo, sem filtro, sem ranking regional).
Porta fechada por opção, não por esquecimento: se um dia quiser ranking/filtro por cidade/estado, será preciso coletar a localização naquele momento, e ela só valerá dali pra frente — os dados importados no lançamento não terão essa informação retroativa. Custo aceitável dado o escopo escolhido.