VENTICINQUE, MAURO

El sitio se lanzó con i18n configurado, las dos tablas de cadenas escritas, el fallback por entrada funcionando y los pares hreflang armados. Todo listo salvo lo único que el visitante ve: las páginas en inglés no existían.

El conmutador «English» aparecía en el header de todas las vistas. Los tres destinos —/en, /en/projects, /en/practice— devolvían 404. Reales, no soft-404, lo cual está bien para los buscadores y no cambia nada para la persona que hizo clic.

Lo dejé así a propósito, con un argumento que sonaba responsable: que una traducción automática en un sitio cuya tesis es la verificación se nota, y que el texto en inglés tenía que escribirse a mano. El argumento es correcto y la conclusión estaba mal. Con la infraestructura sin usar y el botón publicado, la opción honesta era ocultar el botón, no dejarlo apuntando a una pared.

Y hay algo peor que el 404. El Modo A de §2 dice que solapo la jornada con Barcelona y con la costa este de Estados Unidos, y que escucho propuestas remotas. El público que mejor paga eso es el que no lee español: exactamente el que tocaba el botón.

Lo que quedó instalado

El inglés existe, escrito y no traducido palabra por palabra.

Pero el guardarraíl real es estructural. El cuerpo del documento era markup dentro de pages/index.astro; para tener la versión en inglés había que duplicarlo, y dos copias del mismo documento se desincronizan — es literalmente el mecanismo de la errata anterior. Ahora §0 a §6 vive en un solo componente que reciben los dos idiomas, con las cifras saliendo de una fuente única y sólo la prosa por duplicado. Una sección nueva aparece en las dos versiones o en ninguna.

En la misma pasada se corrigió lo que el mismo revisor encontró y que venía del mismo descuido de fondo —dar por bueno lo que no miré—: los §5.x no significaban lo mismo en la portada que en /practica, y /errata y /notas se numeraban §7 y §8 en un documento que declara tener seis secciones. Ahora son Anexo I y Anexo II, que es lo que una hoja de datos usa para el material que respalda el documento sin formar parte de su cuerpo.

La skill korusuite-vtex-app describía cómo validar la licencia de una app de Koru desde el navegador, con un fail-open: si la verificación no responde, dejá pasar. El boilerplate 0.3.x ya no hacía eso. Había pasado la verificación al GET /health del node y reemplazado el fail-open por un stale allow con ventanas de 72 horas y 5 minutos, con siete razones distintas de rechazo.

La skill siguió afirmando lo viejo. Nadie lo notó, porque una skill que documenta un patrón que ya no existe no falla: acompaña. La contradicción apareció escribiendo la arquitectura de otra app, cuando lo que decía la skill y lo que decía el código del boilerplate no coincidían.

En la misma pasada encontré un segundo descuadre más chico y más vergonzoso: los README del plugin y del marketplace declaraban 7 y 8 skills. Eran 9. Los dos archivos omitían vtex-redclover-admin-app, y el del marketplace además vtex-third-party-tags.

Por qué no alcanzaba con corregir el archivo

Editar la skill arreglaba ese día. El problema real es que una skill puede envejecer sin avisar, y yo era la única verificación de que no hubiera pasado. Eso no escala a un equipo.

Quedaron instaladas dos piezas:

Un hook de SessionStart que compara, sin red, la versión de .koru-boilerplate.json del repositorio contra la constante fijada en el plugin. Avisa las migraciones pendientes con el documento exacto, y detecta el caso inverso —que el desactualizado sea el plugin— y sugiere verificación remota cada catorce días. Calcula la versión efectiva considerando appliedMigrations, porque en la primera versión pedía en cada sesión una migración que ya estaba aplicada. Doce tests con node --test.

Y un comando que sí usa red: consulta las tags del boilerplate, compara contra la constante del hook y contra la versión efectiva del repositorio, y contrasta el CHANGELOG contra lo que afirman las skills. Cuando encuentra una contradicción reporta archivo y línea de los dos lados, porque no siempre el equivocado es el mismo. Si la verificación remota falla, no escribe el archivo de estado: prefiero que vuelva a preguntar que registrar un resultado que no obtuvo.

Además, una directiva: cuando el plugin afirma algo que la realidad contradice, se anota en un journal local sin pedir permiso y sin interrumpir la tarea. Un comando aparte re-verifica cada nota contra la skill actual antes de proponer nada, y cosecha las que sobreviven en una rama del marketplace, dejando el pull request para que lo revise una persona.