La operacion ya no puede depender de memoria implicita
El ultimo ciclo de trabajo en Nima Project tuvo cambios en cinco areas:
- la app publica de porras;
- la API del producto;
- el servicio de publicacion;
- la web publica de Nikki;
- y la documentacion compartida del workspace.
No fue un dia de una sola feature.
Fue un dia de corregir una dependencia peligrosa:
que demasiadas superficies seguian funcionando solo si alguien recordaba el contexto correcto fuera de la propia interfaz.
Eso aparecia en cuatro sitios distintos:
- el usuario de
Ultimate Porratenia que inferir idioma, etiquetas y significado de muchas acciones; - soporte necesitaba saber demasiado de base de datos y de relaciones internas para corregir o inspeccionar votos;
- el sitio publicado podia romper navegacion o desbordar diagramas si el lector llegaba desde una ruta distinta;
- y la home de Nikki todavia obligaba a deducir la trayectoria profesional en vez de explicarla como secuencia legible.
Ultimate Porra empezo a explicarse en vez de confiar en costumbre
El commit grande del periodo fue Add i18n and polish Ultimate Porra UI.
Por volumen parece una refactorizacion transversal.
Pero el cambio de fondo es mas concreto: la app deja de depender de etiquetas fijas en espanol, de copy disperso y de estructuras que solo funcionan si el usuario ya entiende el producto.
En este tramo aparecieron varias decisiones visibles:
- se introduce una capa real de
i18ncon mensajesesyen, runtime y selector de idioma; - la shell publica gana
meta description,canonical,og:*ytwitter:*, para que la app tambien se explique fuera de la propia app; - las entradas, acciones de partida, cuenta, ranking, calendario y votos dejan de tener literales sueltos y pasan a vivir en un contrato de mensajes;
- y el codigo de invitacion deja de tratarse como boton secundario con copy ambiguo para convertirse en una pieza mas explicita del flujo.
Esto conecta con conversaciones que ya venian empujando en esa direccion.
El feedback reciente de producto seguia empujando en esa direccion: hacer mas claras las acciones de invitacion, mantener visibles los codigos de entrada y evitar que el usuario tuviera que deducir estado desde copy disperso.
La conclusion de producto es clara:
si una app social ya tiene modos de acceso, partidas, ranking, reglas, bonus y soporte real, no puede seguir operando como si todo el mundo compartiera la misma memoria interna del proyecto.
El admin de la porra gano ojos y manos, no solo permisos
El segundo frente estuvo en world-cup-api y en la documentacion del repo raiz.
Aqui no se anadio solo un endpoint.
Se construyo una forma menos ciega de operar soporte real.
Primero llego un flujo administrativo de correccion de predicciones.
Ese cambio permite a soporte localizar una partida y un usuario desde tooling admin controlado, inspeccionar el estado actual y aplicar una correccion acotada cuando el flujo normal de usuario ya no es el camino correcto.
Despues llegaron flujos complementarios de lectura para soporte admin.
Con eso el admin ya no solo puede mutar.
Tambien puede consultar:
- en que partidas de una competicion esta un usuario;
- que voto hizo para un equipo y una fecha concretos;
- y como queda distribuido ese voto por partida y por partido.
Esto importa porque cambia el tipo de soporte que el sistema permite.
Antes, resolver una incidencia asi dependia mucho mas de recordar tablas, ids, joins y estados internos.
Ahora la propia API empieza a exponer una lectura administrativa del problema.
No es solo "un token admin puede hacerlo todo".
Es algo mejor:
un contrato para inspeccionar antes de tocar y para corregir sin abrir una cirugia manual en la base de datos.
Publish dejo de asumir que el lector estaba en la ruta correcta
En publish-service hubo dos commits pequenos de tamano y grandes en consecuencia:
Fix Notipad publish internal linksContain published Mermaid overflow
El primero corrige una fragilidad muy tipica de los sistemas que publican Markdown a web:
que los links internos sigan pareciendo correctos mientras el autor navega el contenido en su cabeza, pero fallen o apunten raro cuando el lector entra por otra locale o por una ruta generada distinta.
El cambio reescribe enlaces del body hacia paginas publicadas segun logicalPath, locale y ruta actual, y ademas ajusta el redirect del locale por defecto para usar rutas raiz estables.
El segundo hace algo igual de importante, aunque visual:
deja de asumir que un diagrama Mermaid cabra siempre dentro del contenedor publicado.
En vez de eso:
- limita el ancho real del documento publicado;
- encapsula bloques Mermaid;
- y permite scroll horizontal donde hace falta sin romper el layout entero.
Las dos correcciones responden a la misma clase de error:
publicar no es volcar HTML; es garantizar que el lector pueda recorrer y entender la pagina final sin conocer los supuestos internos del editor.
La home de Nikki paso de presentacion estatica a trayectoria legible
El cuarto frente fue nikki-asteinza-web con:
Add Nikki home trajectory diagramClarify home trajectory timeline
Aqui la conversacion no era tecnica en el sentido clasico, pero si plenamente de producto.
La home ya explicaba experiencia, enfoque y productos.
Lo que faltaba era hacer visible la progresion:
- que parte era base humana;
- que parte era acumulacion tecnica;
- donde entra XR;
- cuando aparece defensa;
- y como todo eso desemboca en liderazgo tecnico y en construir plataforma propia.
Por eso la segunda iteracion no se quedo en poner un Mermaid bonito.
Anadio una instruccion de lectura temporal explicita y reorganizo el diagrama como timeline por etapas: 2015-2020, 2020-2021, 2021-2024, 2024-2025, 2025-2026 y ahora.
Eso evita otro problema comun:
que una web personal obligue al lector a reconstruir solo la narrativa profesional.
La home ya no dice solo esto he hecho.
Empieza a decir asi se conecta.
Lo que realmente cambio en estas 24 horas
La version superficial seria esta:
Ultimate Porragano i18n y pulido transversal;- la API del producto sumo tooling admin para consultar y corregir votos;
publish-servicearreglo links internos y desbordes Mermaid;nikki-asteinza-webexplico mejor la trayectoria de Nikki.
Pero el cambio de fondo es mas util escribirlo asi:
Nima Project empezo a tratar la comprension operativa como parte del producto.
Eso significa varias cosas a la vez:
- el usuario no deberia depender del idioma por defecto ni de copy heredado para entender donde esta;
- soporte no deberia depender de memoria SQL para corregir una incidencia real;
- un lector no deberia depender de llegar por la ruta "correcta" para navegar contenido publicado;
- y una persona que visita la home no deberia tener que adivinar la secuencia de la trayectoria profesional.
Lo que me llevo de este tramo
- Localizar y corregir no son tareas separadas: un admin bueno primero necesita leer bien.
- Un sistema bilingue de verdad no termina en el contenido; tambien toca metadata, labels, acciones y navegacion.
- El publish robusto no solo genera paginas: reescribe enlaces y contiene bloques visuales para la lectura real.
- Un portfolio tecnico tambien tiene arquitectura de informacion; no basta con listar experiencia si la progresion no se entiende.
- Cuando una superficie depende de memoria implicita, el problema no es del usuario: es deuda de producto.
Estas 24 horas no anadieron la novedad mas vistosa del proyecto.
Anadieron algo mas necesario:
la decision de que cada superficie importante empiece a traer dentro su propio contexto operativo, en vez de pedirle al lector o al admin que lo recuerde de fuera.
Parte de mis notas de producto y plataforma. Sigue el blog o escribeme.