Una partida ya no es solo un enlace de invitacion

Las ultimas 24 horas en Nima Project dejaron una señal bastante clara.

Hubo actividad fuerte en tres repositorios:

world-cup-porra
world-cup-api
nima-system

Y aunque los commits son muchos, cuentan una sola historia:

Ultimate Porra ya no puede tratar la partida como una consecuencia secundaria del voto. Tiene que tratarla como una entidad completa de producto: visible, editable, reutilizable, compartible y administrable.

La alerta de producto venia de antes: una sola verdad y una entrada mas honesta

Las conversaciones del 16 de junio dejaron dos exigencias muy concretas:

Solo debe haber una fuente de puntuacion
la pagina de inicio debe ser la pagina principal al entrar en una partida

Ese contexto importa porque la jornada no empieza de cero.

El Inicio del dia anterior habia abierto la app por un sitio mas real, pero en estas 24 horas el foco cambia:

ya no basta con explicar el partido en directo;
ahora hay que explicar en que partida estas, a cuales perteneces, cual puedes crear, cual puedes editar y desde cual tiene sentido copiar trabajo ya hecho.

El front deja de asumir una sola partida implicita

El commit grande del frontal, Add entry hub for public games and vote copy UI, hace un movimiento bastante serio:

aparece un hub de entrada para partidas publicas;
la app empieza a listar partidas a las que ya te has unido;
y se introduce una herramienta explicita para copiar predicciones.

Esto cambia la semantica del producto.

Antes la partida podia sentirse como el contenedor silencioso dentro del que votabas.

Ahora la app tiene que responder preguntas mucho mas operativas:

a que partida quiero entrar;
desde cual quiero reutilizar mis votos;
cual es mi partida favorita;
y que competicion o temporada estoy configurando de verdad.

Eso explica por que despues llegan varios commits que parecen pequenos pero no lo son:

Show joined public games in entry
Improve setup page pool actions
Add favorite pools to setup
Make entry pool cards clickable
Stabilize public game join flow
Keep copy votes tool available

No son retoques sueltos.

Son la prueba de que, cuando una app deja de vivir en un flujo lineal, la entrada deja de ser un formulario y se convierte en una mesa de control.

Copiar votos deja de ser truco interno y pasa a ser herramienta de producto

Hay una decision especialmente reveladora en esta tanda: la copia de votos recibe interfaz propia, contrato propio y test propio.

No aparece solo un helper.

Aparecen:

actions-copy-predictions.js;
soporte API especifico;
persistencia de estado cliente;
y un commit dedicado a blindar el contrato: Cover prediction copy flow contract.

Eso dice mucho del momento del producto.

Copiar votos no es un "atajo simpatico".

Es una admision de realidad:

si la porra va a convivir con varias partidas, varias competiciones y varias fases, el usuario no puede estar reconstruyendo manualmente trabajo parecido una y otra vez.

La app empieza a asumir algo mas adulto:

reusar una prediccion anterior tambien es una accion principal, no una conveniencia escondida.

El ultimo commit de la ventana, Keep copy votes tool available, remata justo ese aprendizaje.

No basta con implementar la herramienta.

Hay que defender su presencia cuando cambian estados, layouts y caminos de entrada.

Configurar una partida ya no puede mezclar competicion y temporada como si fueran lo mismo

Otro cambio importante es Split competition and season selectors.

Parece detalle de formulario, pero en realidad corrige una confusion de dominio.

Mientras el producto era pequeno, competicion y temporada podian viajar casi pegadas.

Cuando empiezas a abrir:

partidas publicas,
vistas admin,
futuras ligas distintas del Mundial,
y reglas de fase configurables,

esa union deja de aguantar.

Separar selectores no es solo mejorar UX.

Es reconocer que la app necesita un modelo mas fiel para responder bien a preguntas como:

que competicion estoy creando;
que edicion concreta estoy usando;
y en que fase publica deberia exponerse esa partida.

Los commits Prioritize active competition lifecycle in setup, Rename competition display labels y Respect configurable preview phase van exactamente en esa direccion.

El producto deja de maquillar estados.

Empieza a nombrarlos.

La API deja de ser solo scoring y resultados: ahora carga con el ciclo de vida de las partidas

La misma historia aparece en world-cup-api.

En menos de un dia entran:

Add public games and prediction copy API
Allow admin public game owners by auth subject
Make preview phase configurable
Add admin public game editing endpoints
Add admin private games listing

Esto es importante porque desplaza el centro de gravedad del backend.

Hasta hace nada, la API de la porra estaba muy asociada a:

partidos,
resultados,
bonus,
scoring,
y sincronizacion externa.

Ahora tiene que sostener algo mas parecido a un sistema de gestion de partidas.

Ya no solo calcula.

Tambien:

crea;
lista;
edita;
decide propiedad;
y gobierna visibilidad publica o privada.

Ese cambio de responsabilidad es justo lo que suele separar una demo funcional de un producto operable.

El admin deja de ser frontera abstracta y pasa a gestionar superficies concretas

La tercera pata del cambio esta en nima-system.

Los commits del admin console son muy directos:

Add Porra public game admin creation
Add public games admin view
Add private games admin view
Add competitions admin view
Pin public game form in admin sidebar

Hace unos dias, la tesis era que el admin no debia vivir incrustado dentro de la app publica.

Estas 24 horas convierten esa tesis en mobiliario real.

Ya no se habla solo de separacion arquitectonica.

Se habla de:

pantallas especificas para partidas publicas;
pantallas para partidas privadas;
vistas de competiciones;
formularios fijados en sidebar para operar sin perder contexto.

Eso importa porque completa el triangulo:

el usuario entra y se une desde la app publica;
la API sostiene reglas y mutaciones;
el operador administra el catalogo y el ciclo de vida desde consola.

La frontera ya no es teorica.

Es una coreografia entre superficies.

Incluso los detalles pequenos del UI confirman el cambio de etapa

Hay dos pistas pequenas que me parecen especialmente buenas:

las tarjetas de partida pasan a ser clicables;
y aparece la idea de favorite pools dentro del setup.

Ambas cosas parecen menores.

No lo son.

Son sintomas de que la partida ya no es solo un registro.

Es una unidad de trabajo recurrente.

Cuando algo puede marcarse como favorito, reabrirse rapido o convertirse en punto de entrada, ese algo ha dejado de ser accesorio.

Ha ganado persistencia mental en el producto.

Lo que realmente cambió en estas 24 horas

Lo facil seria describir esta ventana como:

mas vistas,
mas endpoints,
mas admin.

Pero eso se queda corto.

Lo que de verdad paso fue esto:

Ultimate Porra empezo a tratar la partida como el objeto que organiza la experiencia completa.

La partida ya no es solo donde acabas despues de votar.

Es donde:

aterrizas;
eliges contexto;
ves tus opciones;
copias trabajo previo;
distingues publico de privado;
y separas operacion de jugador y operacion de admin.

Lo que me llevo de este tramo

Inicio ya no solo explica el directo; prepara una entrada mas honesta al universo de partidas.
Copiar votos sube de hack util a capacidad oficial del producto.
Separar competicion y temporada corrige una deuda de modelo, no solo de formulario.
La API empieza a cargar con propiedad, visibilidad y edicion de partidas, no solo con scoring.
El admin console deja de ser una promesa de frontera y pasa a gestionar publicas, privadas y competiciones con vistas propias.
Favoritos, tarjetas clicables y flujos de union estables son senales de que la partida se ha vuelto una unidad recurrente de uso.

Estas 24 horas no fueron solo una tanda de pantallas nuevas.

Fueron el momento en que la porra empezo a entender que una partida no es un enlace que te mete dentro, sino el objeto principal que hay que saber crear, leer, reutilizar y gobernar.

Parte de mis notas de producto y plataforma. Sigue el blog o escribeme.