Plataforma y servicios

Ultimate Porra dejó de tratar una eliminatoria como un marcador con extras ocultos. Cuando avanzar depende de penaltis, identidad de goleador y desglose visible, el voto necesita modelar el camino completo del partido.

Ultimate Porra dejó de tratar los cambios del torneo oficial como un reimport que cae por encima del producto. Cuando ya existen votos y clasificaciones, la sincronización necesita alcance, memoria y reversibilidad.

Ultimate Porra dejó de reconstruir la verdad oficial en el cliente. La clasificación, los nombres canónicos y el historial de correcciones tuvieron que volverse contratos explícitos y compartidos.

Corregir una porra no puede significar resetearla. El sistema tuvo que aprender a separar resultado oficial, voto guardado y acción de soporte sin destruir el sentido de la predicción.

Entre el 23 y el 24 de junio, Ultimate Porra dejó de tratar la entrada pública como un salto directo al registro y empezó a escribir una landing propia, con propuesta, acceso y una promesa temporal que respeta la hora local del usuario.

Entre el 21 y el 22 de junio, Nima Project dejo de asumir que usuario, admin y lector recordarian el contexto correcto y empezo a escribirlo dentro de cada superficie.

El 9 y 10 de junio dos frontends distintos, `Reveal It` y `Loop It Synth`, terminaron enseñando la misma lección: cuando un experimento empieza a parecer producto, ya no basta con mover la UI; hay que alinear datos, pruebas y despliegue.

El 8 de junio moví `nima-agent` a `packages`. Parecía un cambio pequeño de ruta, pero en realidad obligó a realinear consumidores, documentación, bootstrap del workspace y la manera de sincronizar más de veinte repos sin borrar a ciegas.

El segundo producto expuso un problema de coordinación en los ficheros de configuración estáticos. El catálogo de productos fue la respuesta — no por elegancia, sino porque editar tres ficheros en sincronía deja de funcionar alrededor del tercer producto.

Después de hacer que auth reconociera el producto y de construir el catálogo, quedaba una brecha visible — el usuario seguía viendo la marca incorrecta en su buzón y en la página de setup de contraseña. El logo la cerró.

Los hostnames públicos canónicos de una API no deberían conectarse directamente a cualquier backend que los sirva hoy. Una capa de enrutado pequeña y sustituible mantiene estable el contrato público mientras los backends de debajo quedan libres para moverse.

El momento en que un servicio compartido dejó de tratar todos los productos como uno y empezó a saber a qué producto pertenecía cada acción — y por qué fue un segundo consumidor real lo que lo forzó.

Por qué el mismo motor de Markdown puede alimentar un editor desktop, un SaaS de publicación, un portal de clientes y una API de exports — y cómo evitar que se convierta en un monolito disfrazado.

Tener un solo caso de uso interno no valida un producto. Tener dos casos con exigencias muy distintas, sí.