Empezamos por auditar, no por diseñar
Antes de tocar una línea de código le aplicamos a nuestro propio sitio lo mismo que le pedimos a cualquier proyecto: entender antes de decidir. Auditamos seguridad, SEO técnico, rendimiento, accesibilidad y consistencia de marca del sitio que ya teníamos — el que estás leyendo ahora, antes de que existiera esta sección.
El resultado no fue el catálogo de horrores que uno esperaría. Lint en cero, typecheck en cero, cero vulnerabilidades en npm audit, contraste de color dentro de rango AA, animaciones que ya respetaban prefers-reduced-motion. La base estaba sólida. Lo que faltaba no era corregir errores: era terminar de alinear el sitio con lo que dice ser.
El hallazgo más simple fue el más vergonzoso
El correo de contacto en cada página, en el pie de página y en los datos estructurados del sitio seguía siendo noonepages@gmail.com — un remanente del proyecto anterior a este rebrand. No era un bug técnico. Era una costura mal cerrada: la clase de detalle que un cliente no perdonaría en su propio sitio y que nosotros habíamos dejado pasar en el nuestro.
Lo corregimos primero, antes que cualquier otra cosa. No porque fuera lo más difícil, sino porque era la prueba más simple de si íbamos a aplicarnos nuestro propio criterio o no.
Elegimos el camino más difícil para la política de seguridad
El sitio ya tenía una Content-Security-Policy razonable, pero permitía script-src 'unsafe-inline' únicamente para poder inyectar los datos estructurados (JSON-LD) de cada página. Era una excepción cómoda y, en la práctica, inofensiva. También era exactamente la clase de atajo silencioso contra el que este sitio dice estar parado.
Como todo el sitio se exporta como HTML estático, el contenido de ese script no cambia entre visitas — así que en vez de abrir la política con unsafe-inline, calculamos el hash SHA-256 exacto de ese script y lo fijamos directo en la cabecera CSP. Si el contenido cambia, el build ya no coincide con el hash y hay que regenerarlo a propósito. Escribimos un script de una línea para eso y lo documentamos en el README. Es más trabajo que dejar la excepción abierta. Es también la diferencia entre una política de seguridad real y una que solo se ve bien en el reporte.
Sin cajas negras no es un eslogan de la página de Método. Es una restricción que también tiene que sobrevivir cuando el cliente somos nosotros mismos.
Una limitación real que no esperábamos
Este archivo que estás leyendo —Adversarixs— se construyó como una ruta dinámica de Next.js: cada historia nueva debía generar automáticamente su propia página. Pero el sitio se exporta 100% estático, sin servidor, y Next.js no permite publicar una ruta dinámica sin generar al menos una página real a partir de ella. No hay forma de dejar la plantilla "lista pero vacía".
Así que construimos toda la infraestructura del archivo —taxonomía, feed RSS, entrada en el mapa del sitio— y retiramos la plantilla de historia individual hasta tener la primera pieza real de contenido. En cuanto escribimos ese primer artículo, la plantilla volvió, ahora generando una página de verdad. Prototipos vacíos no cuentan como progreso; preferimos que el código refleje exactamente lo que existe.
El error que cometimos y deshicimos a mano
En algún punto corrimos el formateador automático del proyecto para prolijar los archivos que acabábamos de tocar. El formateador no se limitó a esos archivos: reescribió el estilo compacto de todo el sitio, incluyendo páginas y hojas de estilo que no teníamos ninguna intención de modificar. No hubo forma de deshacerlo con un solo comando seguro, así que restauramos cada archivo afectado a mano, comparando contra el original, hasta que el único cambio real en el repositorio volvió a ser exactamente el que habíamos pedido.
Pudimos simplemente dejarlo así — total, el sitio seguía funcionando y compilando sin errores. No lo hicimos, porque "funciona" y "es el cambio que dijimos que íbamos a hacer" no son lo mismo, y esa distinción es justamente lo que vendemos.
Por qué contamos esto en vez de ocultarlo
Ningún cliente iba a revisar este proceso línea por línea. Podríamos haber publicado solo el resultado final y dejar que pareciera que todo salió perfecto a la primera. Elegimos documentar el error del formateador, la limitación técnica del archivo y la decisión incómoda de la política de seguridad porque esa es, literalmente, la oferta: decisiones visibles en vez de una revelación teatral al final.
Si esto es lo que hacemos con nuestro propio sitio, cuando nadie está mirando, es lo que puedes esperar cuando sí lo estés.