Versão: 2.0
Público: produto, engenharia, operações de arena, organizadores e treinadores.
Relaciona com: Booking Onda 3.1, Dono da arena — agenda, Academy — horários e holds, ACL.
Definir um módulo de torneios alinhado com o que há de melhor no mercado, sem duplicar verdades no KOLOS, com visão explícita de todos os personagens, gargalos conhecidos e um Padrão Ouro Universal (POU-KOLOS) aplicável a qualquer actor.
Esta tabela não afilia o KOLOS a terceiros; resume estratégias observadas em plataformas e guias da indústria para extrair padrões reutilizáveis.
| Família / referência | O que fazem bem (estratégia) | Lição para KOLOS |
|---|---|---|
| Clube + reserva + comunidade (ex.: Playtomic, conceitos CourtReserve / club apps) | Torneio e atividades como extensão da ocupação do clube; níveis de jogo; dono controla o que entra no espaço. | Torneio sempre ancorado em venue_id com aceite do dono; categorias conversam com Play Card quando existir dados. |
| Gestão de brackets e inscrições (ex.: Challonge, Toornament, Start.gg — forte em esports mas padrões transversais) | Estados de evento claros; brackets vivos; WO/desistência; partilha pública de chave. | Máquina de estados explícita; URL estável por evento; leitura pública controlada por TournamentStatus. |
| Operação desportiva / youth & club (ex.: LeagueApps, Fastbreak — literatura registo/pagamentos) | Registo ↔ pagamento confirmado ↔ roster; import CSV; menos reconciliação manual. | Fase 2: inscrição só confirmed após pagamento (ou exceção manual); audit log de quem alterou estado. |
| Scheduling & conflitos (ex.: Brakto — guia de scheduling) | Mau calendário = principal fonte de insatisfação; variáveis múltiplas (recurso, tempo, clima, deslocações). | Motor de publicação de jogos falha fechado se overlap; mensagens acionáveis; buffers entre jogos. |
| Instalação física (ex.: literatura PlayRez / club scheduling, Score7 — organizar torneio) | Blocos 60–90 min; 10–15 min buffer entre partidas; não destinar 100% do clube a aulas programadas — reservar fatia para membros e eventos. | TOURNAMENT_BUFFER opcional; política de pool de quadras; dashboard “% ocupação por tipo” (fase 2). |
| Manual vs software (ex.: TourneyMaker — evolução gestão) | Processos manuais não escalam; erros propagam-se (nomes, contactos). | Formulários validados, duplas completas antes de confirmar, notificações automáticas. |
Conclusão transversal: o KOLOS evita uma segunda “agenda paralela”. A verdade de ocupação física é bookings por court_id; torneios materializam jogos nessa fila (Onda 3.1).
Cada linha é um papel de produto (um utilizador pode acumular vários).
| # | Personagem | Papel no torneio | O que precisa ver/fazer (resumo) |
|---|---|---|---|
| P1 | Organizador | Dono do evento competitivo | Criar/editar evento, categorias, regulamento, inscrições, chave, resultados, comunicação. |
| P2 | Staff do organizador (opcional) | Ajuda operacional | Entrada de resultados, check-in, mensagens (permissões delegadas). |
| P3 | Dono da arena | Guardião do espaço e da agenda real | Aprovar hospedagem, definir pool de quadras, blackouts, resolver choque com aulas. |
| P4 | Staff da arena (opcional) | Operação no chão | Vista agenda dia D, apoio a atrasos, sem poder mudar regras do torneio sem policy. |
| P5 | Atleta (capitão da inscrição) | Quem inicia a dupla/equipa | Inscrever, convidar parceiro, pagar (fase 2), ver próximo jogo e chave. |
| P6 | Parceiro de dupla | Confirma vínculo | Aceitar convite, dados mínimos, notificações. |
| P7 | Treinador (Academy) | Aulas com holds na mesma arena | Alerta de conflito ou exceção quando torneio mexe na “sua” janela; canal com dono. |
| P8 | Jogador casual (booking) | Reservas BOOKING na arena |
Não ver torneio como surpresa: slots bloqueados ou fora do pool; mensagens na reserva se afetado. |
| P9 | Árbitro / mesa (futuro) | Resultados oficiais | Conta técnica com permissão só de match outcome e hora real de início. |
| P10 | Público / espectador | Acompanhamento | Chave e horários read-only (sem dados sensíveis). |
| P11 | Super admin KOLOS | Plataforma | Moderação, featured, políticas globais, suporte a disputas graves. |
| P12 | Entidade externa (futuro: federação) | Sanções / ranking oficial | API ou export (fora do MVP); não bloquear desenho interno. |
flowchart TB
subgraph plataforma [KOLOS]
T[Tournament core]
B[Bookings motor tempo]
end
P1[Organizador] --> T
P2[Staff org] --> T
P3[Dono arena] --> T
P3 --> B
P4[Staff arena] --> B
P5[Atleta] --> T
P6[Parceiro] --> T
P7[Treinador Academy] -.->|alertas conflito| P3
P8[Jogador booking] -.->|ocupação| B
T -->|publica jogos| B
P10[Público] -->|read-only| T
P11[Super admin] --> T
Os gargalos abaixo aparecem repetidamente em literatura de registo, scheduling e operação de instalações (secção 2). A coluna Antídoto é o comportamento mínimo que o produto deve garantir.
| Personagem | Gargalo típico (dor) | Antídoto POU-KOLOS |
|---|---|---|
| P1 Organizador | Reconciliação manual inscrições/pagamentos; erros de dados que rebentam na chave | Estados explícitos; validação na entrada; (fase 2) pagamento ligado a confirmed; export auditável |
| P1 Organizador | Calendário fraco → insatisfação geral | Nunca publicar slot com overlap; sugestão de buffer; simulador “preview” antes de commit |
| P2 Staff org | Permissões confusas → erros ou fraude leve | Permissões finas (tournament.record_result vs tournament.edit_structure); log de alterações |
| P3 Dono arena | Torneio “invade” aulas ou clientes sem aviso | Gate de aprovação; pool de quadras obrigatório; vista de impacto antes de aceitar |
| P3 Dono arena | Não sabe o que está a correr no dia D | Agenda unificada com legenda TOURNAMENT_MATCH + dono como fonte de verdade do espaço |
| P4 Staff arena | Atrasos em cadeia; comunicação por WhatsApp solta | “Quadro do dia” por quadra; botão atraso X min propaga novos horários (fase 2) + notificação |
| P5 Atleta | Não sabe onde/quando é o próximo jogo | Uma linha do tempo: próximo jogo + quadra + link arena; push/email |
| P5/P6 Dupla | Parceiro não aceita a tempo; equipa incompleta entra na chave | Inscrição incompleta não fecha chave; lembretes; expiração configurável |
| P7 Treinador | Aula cancelada em cima da hora por evento | Fluxo humano dono↔treinador + registo de exceção; sistema não apaga holds sem confirmação |
| P8 Booking casual | Reserva anulada porque torneio ocupou a quadra | Política clara: ou não há booking em slot torneio, ou avisos ao reservar semana do evento |
| P9 Árbitro (futuro) | Disputa resultado | Resultado com dupla confirmação ou janela de contestação (fase 3) |
| P10 Público | Informação desatualizada | Chave pública derivada da mesma fonte que o organizador; timestamp “última atualização” |
| P11 Super admin | Eventos fraudulentos ou spam | KYC leve / limite de eventos / denúncias (roadmap compliance) |
Conjunto de regras invariantes — independentemente de personagem, modalidade ou fase do roadmap. Se uma feature violar o POU, deve ser redesenhada ou explicitamente marcada como exceção documentada.
| ID | Princípio | Significado operacional |
|---|---|---|
| POU-1 | Uma verdade no tempo | Ocupação de quadra = bookings + constraint de overlap (Postgres). Sem segundo calendário “só para torneio”. |
| POU-2 | Fail-closed em conflito | Publicar horário de jogo só se passar no motor de conflito; erro humano-legível + sugestão (outra quadra, outro horário). |
| POU-3 | Estados explícitos | Torneio, inscrição e partida têm enum documentado; proibidas transições “mágicas” sem policy + (quando crítico) audit. |
| POU-4 | Hierarquia de soberania | Dono da arena > ocupação física; Organizador > regras competitivas dentro do contrato de hospedagem aceite. |
| POU-5 | Cada actor tem um “próximo passo” | UI e notificações respondem: “O que faço agora?” (ex.: parceiro pendente → convidar; arena → aprovar pool). |
| POU-6 | Transparência por papel | O mesmo evento tem vistas diferentes por role (organizador vê tudo operacional; público vê só o seguro). |
| POU-7 | Buffers configuráveis | Entre jogos consecutivos na mesma quadra, respeitar buffer_minutes (default alinhado a boas práticas 10–15 min). |
| POU-8 | Rastreabilidade | Quem fechou inscrição, quem publicou horários, quem registou resultado (user id + timestamp). |
| POU-9 | Academy é cidadã de primeira classe | Qualquer torneio que toque em holds exige política explícita (secção 8): dedicado, blackout, ou reagendar — nunca overwrite silencioso. |
| POU-10 | Acessibilidade operacional | Dia D: uma vista “por quadra” e uma “por hora” (duas lentes do mesmo dado). |
Antes de marcar uma entrega de torneios como pronta:
BOOKING / ACADEMY_CLASS_HOLD → deve falhar com mensagem clara.tournament_court_pool aprovado.| Permissão (exemplo) | Personas típicos |
|---|---|
tournament.create |
Organizador verificado, dono arena |
tournament.manage |
Organizador, staff org delegado |
tournament.publish_schedule |
Organizador + pré-condição arena aceite |
venue.tournament_host |
Dono arena — aprovar pool, blackout |
tournament.operate_day_of |
Staff org, staff arena (limitado) |
tournament.record_result |
Organizador, staff org, (futuro) árbitro |
(Nomes finais alinhar com PermissionName na implementação.)
court_id + [starts_at, ends_at).BookingType com TOURNAMENT_MATCH e opcionalmente TOURNAMENT_BUFFER; metadata com tournament_id, match_id, ronda, categoria.docs/changes/ + registro de rotas em cada entrega com rotas novas.Tournament, TournamentCategory, TournamentRegistration, TournamentMatch.tournament_court_pool na aceitação de hospedagem.bookings.flowchart TD
A[Criar torneio rascunho] --> B[Definir arena datas categorias]
B --> C{Solicitar hospedagem?}
C -->|Arena externa| D[Pendente aprovação arena]
C -->|Própria arena| E[Aceite automático ou manual]
D --> F{Arena aceita + pool quadras?}
F -->|Não| G[Ajustar ou cancelar]
F -->|Sim| H[Abrir inscrições]
H --> I[Fecho / seeds]
I --> J[Gerar chave]
J --> K[Preview conflitos + buffers POU-7]
K --> L[Publicar → bookings]
L --> M[Dia D: resultados]
M --> N[Encerramento]
flowchart LR
A[Explorar] --> B[Filtrar]
B --> C[Detalhe]
C --> D{Inscrições abertas?}
D -->|Sim| E[Pedido + convite P6]
E --> F{Dupla completa?}
F -->|Não| G[Lembretes POU-5]
F -->|Sim| H[Confirmada / pagamento F2]
C --> I[Chave pública P10]
flowchart TD
A[Pedido torneio] --> B[Simulador impacto agenda]
B --> C{Conflito Academy/BOOKING no pool?}
C -->|Sim| D[Estratégia A/B/C/D sec.9]
C -->|Não| E[Aprovar pool + janela]
E --> F[Dia D: vista quadra/hora POU-10]
TOURNAMENT_MATCH ou aviso explícito na semana do evento (política comercial da arena).| ID | Estratégia | Uso |
|---|---|---|
| A | Blackout arena | Evento ocupa o dia/complexo; aulas em pausa ou exceção assinada. |
| B | Quadras dedicadas | Default MVP recomendado — pool court_id disjoint das turmas. |
| C | Reagendar aulas | Exceção manual com registo. |
| D | Bloquear publicação | Até conflito zero no motor. |
Checklist dia D: agenda com TOURNAMENT_MATCH; permissão tournament.operate_day_of; WO e reagendamento com audit POU-8.
| Entidade | Notas |
|---|---|
tournaments |
venue_id, organizador, estado, timezone, buffer_minutes, política A/B/C/D. |
tournament_hosting (ou campos em tournaments) |
Aceite arena, court_pool[], janela horária. |
tournament_categories |
Limites, género, nível. |
tournament_registrations |
Dupla/equipa, estado, seed. |
tournament_matches |
Ronda, dependências, resultado. |
bookings |
TOURNAMENT_MATCH + ligação ao match; TOURNAMENT_BUFFER opcional. |
Invariantes: match scheduled implica booking; cancelamento liberta intervalo conforme política de status.
| Risco | Mitigação POU |
|---|---|
| Double booking | POU-1 |
| Organizador fantasma | POU-4 + aprovação arena |
| Caos dia D | POU-10 + P4 |
| Dados errados | POU-8 + validação |
Métricas: tempo médio aprovação arena; % publicações bloqueadas por conflito (deve ser baixo após ajuste); Nº WO; NPS pós-evento (fase 2).
BookingType + metadata + buffer.Documento vivo — v2.0: visão 360°, gargalos e POU-KOLOS. Revisar após MVP.