Mi corrección fue correcta todo el tiempo, mi servidor de desarrollo simplemente se negaba a decirlo

Una revisión de diseño señaló algo simple: en el teléfono, el aviso de consentimiento de analítica aparece de inmediato al cargar la página y tapa el hero. Antes de leer una sola palabra de la presentación, aparece una hoja inferior preguntando sobre cookies. La corrección, una vez que supe cuál era, llevó unas diez líneas: en anchos de teléfono, no mostrar el aviso hasta que la persona visitante haga scroll, o después de unos segundos si nunca lo hace. El escritorio mantiene su pequeña tarjeta en la esquina exactamente igual que antes.

Esa parte salió bien. Lo que no salió bien fue demostrar que funcionaba.

Esta corrección vive en un paquete compartido pequeño, no en el sitio en sí, una de varias bibliotecas @vdaluz/* que este sitio y sus hermanos incorporan como dependencia fija de tarball. El proceso de lanzamiento dice: empaquetar la nueva versión, instalarla localmente en un consumidor, probarla de verdad antes de etiquetar nada. Así que eso hice. Edité el código fuente del paquete, corrí npm pack, instalé el tarball en este sitio con --no-save, y empecé a probarlo en un navegador real con ancho de teléfono.

No pasó nada. El aviso aparecía de inmediato, exactamente igual que antes de la corrección. Releí mi propio código tres veces buscando el error que no estaba ahí.

Hizo falta un curl para resolverlo de verdad: pedir el archivo exacto que el servidor de desarrollo estaba sirviendo, y leerlo. Los bytes en disco tenían la corrección. Los bytes que el servidor devolvía por HTTP no. Vite no vigila node_modules por defecto, trata todo ese directorio como “de terceros, no va a cambiar,” lo cual normalmente es una suposición sensata y es exactamente incorrecta la única vez que se está editando deliberadamente algo ahí adentro para probar un lanzamiento todavía sin etiquetar. Limpiar la caché de compilación tampoco ayudó, porque el servidor que estaba corriendo ya tenía el contenido viejo cargado en memoria. La caché en disco nunca fue el problema.

Así que reinicié el servidor de desarrollo. Mismo resultado obsoleto. Esa fue la parte que realmente costó tiempo: una llamada para detener el proceso reportó éxito, y le creí. El servidor viejo seguía bien vivo, seguía escuchando, seguía respondiendo cada solicitud con el código de la semana pasada, mientras mi servidor “nuevo” había caído en silencio al siguiente puerto disponible y yo seguía probando contra el equivocado. Nada en la falla parecía “esto es un proceso zombi.” Parecía exactamente “esta corrección no funciona.”

Lo que realmente rompió el ciclo: dejar de confiar en que una solicitud exitosa significa estar hablando con lo que uno cree que está hablando. Empecé a buscar con grep directamente en los archivos servidos un marcador único de mi última edición, y a verificar procesos sobrevivientes por PID en vez de confiar en el mensaje de éxito de una herramienta. Una vez que hice eso, el panorama cambió al instante: los bytes servidos coincidían con el archivo en disco, no quedaba ningún proceso suelto, el aviso se comportaba exactamente como estaba diseñado. Había sido correcto desde la primera edición.

Se publicó como @vdaluz/astro-opt-in-analytics v0.5.0: empaquetado, probado, etiquetado, y luego incorporado a este sitio una vez que la etiqueta se hizo pública. Confirmado en producción buscando con grep la nueva lógica en el bundle real de JS, no solo cargando la página y mirándola a simple vista.