La superficie publica ya no puede ser un efecto secundario

Las ultimas 24 horas en Nima Project tuvieron commits en dos repositorios:

• world-cup-porra
• nikki-asteinza-web

No fue un dia de una feature vistosa.

Fue un dia de algo mas importante:

dejar de tratar la superficie publica como una consecuencia del codigo y empezar a tratarla como un contrato explicito de publicacion, medicion y lectura real.

Ese cambio aparece en dos frentes a la vez:

• Ultimate Porra anade analytics y descubre que medir no sirve si la etiqueta vive escondida detras del bootstrap de la app.
• nikki-asteinza-web deja de ser una carpeta con contenido listo y pasa a definirse como un sitio publicable de verdad, con contrato de publish, dominio canonico, flujo de despliegue y reglas de operacion.

La home de Ultimate Porra siguio ajustandose hasta poder sostener trafico y lectura reales

Antes del bloque de analytics hubo una cadena larga de commits sobre la home:

• fix: compact live panel match row
• fix: link home ranking card
• fix: compact mobile evolution chart
• fix: split home dashboard on wide screens
• fix: arrange desktop home dashboard columns
• fix: place live card under evolution
• fix: lock world cup preview phase
• fix: adjust mobile evolution chart height
• fix: adapt home layout for portrait tablets

Leidos por separado parecen ajustes pequenos.

Leidos juntos cuentan otra cosa:

la home ya no se estaba tratando como una pantalla mas, sino como la portada real del producto.

Eso obliga a que resista varios contextos a la vez:

• movil estrecho;
• desktop ancho;
• y tablets en vertical, que suelen romper layouts pensados solo para movil o escritorio.

El commit fix: adapt home layout for portrait tablets lo deja muy claro. La app no solo recoloca columnas: tambien duplica en tablet la lectura rapida de Estadisticas grupales junto al bloque live para que el dashboard no pierda sentido justo en el formato intermedio.

No es cosmetica.

Es aceptar que la lectura principal del producto tiene que sobrevivir antes de empezar a meterle trafico medible.

Analytics obligo a mover la medicion desde "codigo que corre" a "HTML que existe"

Los commits clave aqui fueron:

• Add GA4 tracking to Ultimate Porra
• Expose GA4 tag in app shell

El primero anade la capa de analytics como modulo real del producto:

• configuracion en app-config.json;
• soporte en entorno local y worker;
• un modulo dedicado js/app-modules/analytics.js;
• y puntos de entrada desde el shell y las acciones de la app.

Pero la conversacion posterior destapo la frontera importante.

En las sesiones de Codex del 20 de junio quedo registrado algo muy concreto:

• Google Analytics "estaba entrando dinamicamente".
• El tester de GA buscaba gtag/js en el HTML inicial.
• Eso obligo a exponer la etiqueta en el shell para que la web fuera medible antes incluso de que la app terminara de arrancar.

Esa correccion no es un truco para pasar una verificacion.

Es una leccion de producto:

si la observabilidad depende de que todo el frontend termine de montar, entonces la medicion sigue viviendo como efecto secundario tecnico y no como parte de la superficie publica.

Por eso el segundo commit mueve la etiqueta al index.html y ajusta el modulo para convivir con esa realidad.

La diferencia es pequena en codigo y enorme en significado:

• antes, la app se media si el arranque llegaba hasta cierto punto;
• ahora, la app se presenta al navegador y a los verificadores como una superficie instrumentada desde el primer byte util.

La propia web de Nikki paso de "contenido listo" a "sitio gobernado"

El otro frente del dia estuvo en nikki-asteinza-web:

• Prepare Nikki Asteinza publish site
• Fix Spanish home product logos

Prepare Nikki Asteinza publish site no solo mete contenido.

Hace algo mas serio:

• crea .notipad/publish-project.json;
• declara publicUrl y canonicalDomain como https://nikkiasteinza.com;
• fija workingTreePolicy de limpieza antes de publicar a produccion;
• separa editableRoots de rutas de solo lectura;
• define staging, produccion, guardas de MFA y confirmacion explicita;
• y convierte el deploy en una secuencia nombrada: guardar, validar contrato, mostrar diff, commit, push, publish y auditoria.

Eso es exactamente lo contrario de "subir una carpeta".

Es convertir la publicacion en una operacion gobernada.

Ademas, el commit arrastra a la web varias entradas del blog que hasta ahora vivian fuera del sitio publicado, anade assets de producto y rehace partes del README y del preview local para que el sitio no dependa de conocimiento tacito.

Luego Fix Spanish home product logos cierra una incoherencia pequena pero reveladora:

si la home dice que esta hecha con Notipad y presenta los productos del ecosistema, no puede mostrar mal justo los logos que convierten esa narrativa en evidencia visible.

Las conversaciones de chat empujaron la publicacion hasta el ultimo metro operativo

En la sesion de despliegue del 20 de junio aparece otra decision importante.

El sitio se llego a desplegar a Cloudflare Pages y se verifico con 200, assets y GA presentes. Pero el dominio final quedo bloqueado por una pieza que ya no pertenece al contenido:

• registro DNS canonico no configurado

La nota operativa fue precisa:

• el proyecto Pages ya existia;
• nikkiasteinza.com se anadio al proyecto;
• pero faltaba el registro DNS del dominio custom.

Eso importa porque termina de demostrar la tesis del dia.

Una web publica no queda lista cuando el Markdown esta bien ni cuando el build compila.

Queda lista cuando todas las capas del contrato publicable responden:

• contenido;
• branding;
• shell HTML;
• analitica;
• proyecto de publish;
• despliegue;
• y DNS canonico.

Lo que realmente cambio en estas 24 horas

La forma facil de resumir el dia seria:

• responsive mejorado en Ultimate Porra;
• GA4 integrado;
• sitio de Nikki preparado para publicar.

Pero el cambio de fondo es otro.

Nima Project empezo a tratar la web publica como producto operable, no como salida accidental de un repo.

Eso se nota en varias decisiones que ya no pueden separarse:

• el dashboard de Ultimate Porra tiene que leerse bien en formatos reales antes de comprar trafico;
• analytics tiene que existir en el HTML inicial, no solo en modulos que cargan despues;
• el portfolio de Nikki necesita un contrato de publicacion y un dominio canonico, no solo contenido y tema;
• y el ultimo bloqueo puede estar en DNS, porque publicar de verdad siempre termina fuera del editor.

Lo que me llevo de este tramo

• Cuando una home se vuelve la portada real del producto, el responsive intermedio deja de ser detalle y se vuelve contrato.
• Instrumentar analytics en JS no basta si verificadores, crawlers o navegadores necesitan ver la etiqueta en el HTML inicial.
• Un publish-project.json bien definido convierte una web personal en una superficie operable dentro de plataforma, no en una excepcion manual.
• Separar editableRoots, guardas de MFA y confirmacion explicita es una forma de escribir operacion, no solo configuracion.
• Corregir logos o branding en la home parece pequeno, pero importa cuando la web esta contando que esos productos son prueba de la propia plataforma.
• El ultimo kilometro de la publicacion casi nunca es contenido: suele ser dominio, DNS, permisos o despliegue real.

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

Anadieron algo mas util:

la disciplina de asumir que una superficie publica solo existe de verdad cuando puede leerse, medirse, publicarse y resolverse con su dominio correcto.

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