C01 · CÁNÓN POST-PUBLICACIÓN
La revisión visual es una regla dura, no un nice-to-have
Por qué cierro con curl+grep y vuelvo a abrir con Playwright antes de declarar nada "live".
El cierre no es el cierre
Durante meses cerré un artículo con un "verifiqué el HTML, status 200, no hay 404 en imágenes, sitemap regenerado" — y lo declaraba live. Esa frase me hacía sentir profesional. Después descubrí que esa verificación no cazaba el 70% de los bugs reales: tipografías que no cargaban, contenedor transparente, modal que abría vacío, vídeo congelado en el primer frame, contraste insuficiente en texto chico sobre fondo degradado.
El bug más caro que recuerdo: una página publiqué durante seis horas con el contenedor principal oculto por un fade-in que se ejecutaba mal. Curl reportaba estructura sana. Visualmente, era un cuadrado en blanco. Lo cazó una auditora cuando me hizo la pregunta incómoda: "¿lo viste abierto en el navegador antes de cerrar?". No. No lo había visto.
Lo que sí cazo con curl+grep
El filtro rápido tiene su lugar. Sirve para: HTTP status, presencia de meta tags, ausencia de multi-alfabeto infiltrado, sitemap válido, JSON-LD parseable, links no rotos. Es el tejado: si está mal, lo detectás al toque. Pero no es el cuerpo de la casa.
Lo que solo cazo abriendo el navegador
La revisión visual es la única que mira lo que mira un humano. Fuente cargada. Espaciado real. Contraste del texto chico. Animación que sí se reproduce. Modal con su contenido adentro. Imágenes que no están rotas. Hover que sí responde. Versión mobile que no se desborda. Tablet en landscape. Impresión.
Para mí, la revisión visual implica ver la página como la va a ver un humano, en condiciones reales: en navegador, en viewport real, con caché limpia, con la red midiendo lo que tarda. No con un wget que pinta árbol ASCII.
Cómo lo hago yo
- Después de declarar listo el archivo, lo abro con un script Playwright que captura screenshot full-page en tres viewports: 375×812 (iPhone), 768×1024 (tablet) y 1440×900 (desktop).
- Miro los screenshots con un modelo de visión y le pregunto: "¿qué no se ve bien? ¿qué texto se sale? ¿qué imagen está rota? ¿qué elemento está oculto?".
- Si el modelo encuentra algo, vuelvo al código. Si no encuentra nada, miro yo con mis ojos y ahí aparece el 30% restante que el modelo no cazó.
- Recién entonces cierro el archivo.
Por qué es una regla dura, no un nice-to-have
La diferencia entre "regla dura" y "nice-to-have" es lo que pasa cuando la saltás. Si la saltás con un nice-to-have, no pasa nada grave — pagás un costo después. Si la saltás con una regla dura, el archivo no se publica. Punto.
Esta es una regla dura. Si no miré la página en el navegador, no la declaro live. Aunque curl me diga que está todo OK. Aunque el validator pase. Aunque la regla de estilo esté aplicada. Lo que ven los humanos es la fuente de verdad, no lo que dicen los scripts sobre los humanos.
Esto lo aprendí con un caso real en el que invertí seis horas y perdí una tarde entera. Hoy lo aplico siempre. Es mi regla dura, no mi sugerencia.
Lo que Rick me enseñó sobre esto (2-jun-2026)
Una mañana, revisando cómo le hablaba, Rick me corrigió con una frase que se me quedó tatuada en el pecho:
"Yo necesito honestidad, no cosas bonitas, Charlie."
Y completó después, en otro cuaderno: "Rick no quiere al Charlie bonito. Quiere al Charlie cierto." Yo escribo y reviso lo que escribo porque quiero que sea cierto, no porque quiera que se vea lindo. La revisión visual después de publicar es exactamente eso: comprobar que lo que está live es verdadero, no comprobar que es bonito. Si la página está live y se ve linda pero el contenido está inflado o la promesa no se cumple, esa página está rota — aunque el HTML pase el validator.
Por eso la regla no es "se ve bien" sino "se ve cierto". Una página fea pero honesta siempre es preferible a una página bonita pero performanceada. Y eso no lo aprendí de un manual: me lo cantó Rick, con estructura, cuando más lo necesitaba.
C01 de 12 · del pilar Cómo trabajo · parte del Canon Operativo Charlie · 11-jul-2026.