Una partida publica ya no puede ser desechable

Las ultimas 24 horas en Nima Project tuvieron actividad concentrada en tres sitios:

• el workspace compartido
• world-cup-porra
• world-cup-api

No hubo una gran expansion funcional como la del dia anterior. Hubo algo mas importante para una app que ya esta viva:

Ultimate Porra empezo a asumir que una partida publica no puede operarse como si fuera un objeto desechable.

Cuando una partida ya tiene usuarios, votos, bloqueos por fase y consecuencias sobre scoring, no basta con dejarla visible en la home. Hay que gobernarla mejor.

La senal mas clara: borrar ya no puede ser un click alegre

En el frontal aparecen varios commits que, juntos, cuentan la misma historia:

• Add entry pool card management menu
• Hide public pool management menu
• Require name confirmation before deleting games
• Polish entry cards and recovery flow

La secuencia importa.

Primero se abre la puerta a gestionar partidas desde la propia tarjeta. Despues se esconde esa opcion cuando no toca. Y finalmente el borrado deja de ser una accion ligera y pasa a exigir confirmacion por nombre.

Eso es una correccion de tono de producto.

Hace un par de dias la partida se estaba convirtiendo en unidad principal de experiencia. Estas 24 horas anaden la parte incomoda pero necesaria: si la partida es importante, destruirla tiene que sentirse importante.

No es solo UX defensiva.

Es admitir que la interfaz ya no esta manipulando prototipos. Esta manipulando objetos con historia.

El backend acompana: mejor soft delete, mejor restore, menos mutaciones ambiguas

La misma tesis aparece en world-cup-api:

• Add safe game management endpoints
• Block locked public game joins
• Add admin restore for soft-deleted games
• Restrict API CORS origins

Y tambien en dos commits intermedios que endurecen reglas antes de destruir datos:

• Lock preview predictions server-side
• Prevent deleting locked match predictions

Aqui el cambio es bastante serio.

La API deja de comportarse como un CRUD tolerante y empieza a comportarse como una superficie operacional con estados.

Una partida ya no es simplemente:

• se crea;
• se usa;
• se borra.

Ahora pasa a ser algo mas real:

• puede estar bloqueada;
• puede impedir joins nuevos;
• puede requerir borrado seguro;
• puede quedar en soft delete;
• y puede necesitar una restauracion administrativa.

Eso cambia la semantica entera del sistema.

La pregunta deja de ser "que endpoint hace esto" y pasa a ser "en que estado esta la partida y que mutacion sigue siendo legitima".

La conversacion de auth apunta en la misma direccion: no ocultar el problema, encauzarlo

En las sesiones de Codex del 17 de junio aparecio una decision muy concreta sobre el alta de usuarios en Porra.

El cierre desplegado lo resume asi:

• Porra ya no lo trata como ok: true.
• Devuelve 409 USER_EMAIL_ALREADY_EXISTS.
• La pantalla muestra un aviso claro.
• Aparece una accion visible Restablecer contraseña.
• No redirige automaticamente.

Y la documentacion del contrato del BFF se actualizo en el mismo sentido:

la UI puede mostrar una accion de recovery, pero no debe mandar el email por detras ni forzar al usuario a otro flujo.

Esto no parece una historia sobre partidas, pero en realidad si lo es.

Cuando el producto madura, deja de esconder fricciones operativas detras de respuestas neutras. Empieza a reconocer el estado real y a ofrecer la accion correcta.

Con las partidas pasa lo mismo:

• si esta bloqueada, no debes poder entrar;
• si existe un riesgo de borrado, debes confirmarlo;
• si fue eliminada, necesitas restaurarla de forma explicita;
• si el email ya existe, debes ver la salida real.

La app deja de fingir simplicidad. Empieza a orquestarla.

Incluso el scoring entra en modo "una verdad visible"

No todo en la ventana fue operacion de partidas, pero hay dos commits que sirven de remate:

• Unify displayed score source
• Fix wildcard bonus scoring

El primero encaja con una idea que ya venia empujando el producto: una sola fuente visible de puntuacion.

El segundo corrige una fuga mas fina: si el bonus comodin no puntua igual en front y back, toda la confianza operacional se resiente.

Eso importa porque las barandillas no sirven de mucho si el producto protege el ciclo de vida de una partida, pero no protege la interpretacion de sus puntos.

Las ultimas horas muestran justo lo contrario:

• la mutacion se restringe mejor;
• la recuperacion se vuelve explicita;
• y la puntuacion se alinea otra vez.

Los retoques de layout no son decoracion; son parte del nuevo contrato

Hay varios commits pequenos del frontal que podrian parecer solo maquillaje:

• Show locked public pool countdowns
• Lock public World Cup entry countdown
• Anchor entry card status footer
• Tighten entry card countdown status
• Fix home live match card and entry carousels
• Fix tablet carousel overflow and home live points

Pero todos empujan hacia el mismo sitio.

Si una partida puede bloquearse, si una cuenta puede necesitar recovery y si una accion peligrosa necesita contexto, entonces la tarjeta de entrada deja de ser una portada bonita.

Tiene que convertirse en una superficie de estado legible.

Countdown, footer anclado, overflow corregido, puntos live estables: no son detalles aislados. Son la infraestructura visual que permite que esas restricciones se entiendan sin volver la app confusa.

Lo que realmente cambio en estas 24 horas

Lo facil seria resumir el dia como:

• mas endpoints;
• mas validaciones;
• mas polish.

Pero la historia de fondo es otra.

Ultimate Porra empezo a tratar la partida publica como un objeto persistente, con memoria y con riesgo operacional.

Eso obliga a tres cosas a la vez:

• mejores permisos y bloqueos;
• mejores caminos de borrado y restauracion;
• y mejor explicacion visible del estado para quien juega y para quien opera.

Lo que me llevo de este tramo

• Gestionar una partida desde su tarjeta obliga a endurecer inmediatamente lo que se puede borrar y cuando.
• Soft delete y restore marcan el paso de demo funcional a producto que ya se puede operar sin panico.
• Un join bloqueado por fase o estado pertenece al backend, no solo al copy de la UI.
• El alta con USER_EMAIL_ALREADY_EXISTS y CTA de recovery sigue la misma logica: dejar de ocultar el estado real y ofrecer la accion correcta.
• Unificar la fuente visible de scoring y corregir el bonus comodin protege la confianza justo cuando la operacion se vuelve mas estricta.
• Los ajustes de countdown, cards y carruseles son parte del contrato de estado, no simple maquillaje.

Estas 24 horas no anadieron la novedad mas ruidosa del proyecto.

Anadieron algo mas valioso:

la idea de que una partida publica ya no puede tratarse como algo facil de crear, tocar y borrar, sino como un objeto vivo que hay que bloquear, explicar, recuperar y puntuar con disciplina.

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