Boolgool — infraestructura de torneos ITF

Un torneo ITF es un problema de programación y de arbitraje simultáneos: decenas de combates repartidos en varios tatamis, con jueces que rotan y resultados que tienen que llegar a entrenadores y atletas sin ambigüedad.

Un torneo se coordina hoy con planillas impresas y mensajería. El coste no es la incomodidad: es que nadie tiene el estado real del evento en un momento dado — ni el director, ni los jueces, ni los entrenadores, ni las familias.

Producto propio, nacido del mismo hilo que Caucana y Academy Manager: operar y competir en Taekwon-Do ITF y encontrarse con los mismos problemas operativos resueltos con papel y grupos de WhatsApp.

• Director de torneo — programa, supervisa y resuelve conflictos.
• Director de jueces — asigna arbitraje y controla incompatibilidades.
• Jueces — puntúan combates en su tatami.
• Entrenadores — siguen a sus atletas y reciben resultados.
• Atletas — consultan su llave, su tatami y su horario.
• Público — sigue el evento sin interferir en la operación.

• Conectividad de polideportivo: la app no puede asumir red estable.
• Seis roles con permisos distintos sobre el mismo evento.
• Reglamento ITF: las reglas de puntuación no son negociables ni configurables a gusto.
• El tiempo real importa de verdad — un resultado que llega tarde ya no sirve.

Modelé el torneo como una jerarquía explícita en lugar de como un bracket genérico, porque las decisiones operativas ocurren en los niveles intermedios: es en el tatami y en la asignación de jueces donde un torneo se atasca, no en la llave.

• El tatami es una entidad de primera clase, no un atributo del combate: es la unidad que se programa y la que se atasca.
• Los roles se modelan por permiso sobre el evento, no por pantalla. Un juez y un entrenador ven el mismo combate con derechos distintos.
• La puntuación sigue el reglamento ITF: no se hace configurable lo que el reglamento ya define.

AI-assisted delivery en modelado del dominio, generación de estructura y documentación. Las reglas de arbitraje y puntuación se validan a mano contra el reglamento: es exactamente el tipo de regla que no se delega.

• Programación con paralelismo real: varios tatamis avanzando a ritmos distintos sobre un mismo calendario.
• Incompatibilidades de arbitraje — un juez no puede puntuar a su propio alumno — como regla del sistema, no como convención social.
• Estado compartido y en vivo entre seis roles con permisos distintos.

• Modelo de dominio completo de un torneo ITF: competencia, tatamis, combates, jueces, puntuación y resultados.
• Seis roles con permisos diferenciados sobre el mismo evento.
• Software vertical en un dominio donde no necesito que nadie me traduzca los requisitos.

• En software vertical, el conocimiento del dominio vale más que la elección de stack.
• Modelar la entidad que se atasca —el tatami— antes que la que se ve —la llave— cambia todo el producto.