Commits
Revisión en dos ejes: cinco hallazgos reales y fuera el código muerto
Repaso con dos revisores en paralelo —estándares del repo y spec— a todo el trabajo del 3 de noviembre. Cinco hallazgos reales, entre ellos un detalle de WordPress que ningún test podía cazar; también he retirado columnas que nadie leía y cerrado las issues abiertas con evidencia.
Ayer me quedó un día de trabajo intenso y hoy lo he pasado por el tamiz: dos revisores en paralelo, uno con los estándares del repo y otro con la spec. Salieron doce hallazgos de estándares y cinco de spec. Cuento los que de verdad importan.
El detalle que ningún test cazaba
El retorno de Core_Upgrader::upgrade() me dio la sorpresa del día: WordPress devuelve la versión nueva como cadena, no como array. El arreglo de ayer leía isset( $result->version ), que daba siempre falso, y el panel recibía la versión de antes de actualizar: justo lo que quería evitar. El stub del harness devolvía un array, así que el caso salía verde en un mundo que no existe. Ahora el stub se comporta como el WordPress de verdad y el caso comprueba que la versión reportada es la nueva.
Los huecos de la spec
El barrido de conectores no se saltaba las webs caídas (el de inventario sí): una web caída se gastaba los 180 segundos de timeout y atascaba la cola secuencial. Y el ZIP del conector solo se ofrecía en la tarjeta del listado, no en el espacio de trabajo de cada web.
Los de libros
El otro puñado era de coherencia. El glosario marca «web» como el término correcto y desaconseja «sitio», pero el código nuevo usaba «sitio». La normalización de fechas estaba duplicada en el dashboard y el worker: ahora hay un helper, site_info.as_utc. En refresh_site() el parámetro site iba sin tipar. El endpoint del conector reimplementaba el 404 de get_authorized_site en vez de reutilizarlo. El estado del conector se calculaba dentro de un validador que se modificaba a sí mismo: ahora lo hace el router, en _site_out. La actualización del conector no dejaba rastro en la bitácora. Y faltaba la confirmación antes de instalar código en la web de un cliente, cosa que el repo ya pide para plugins y temas.
El botón «Refrescar» de cada tarjeta se queda como icono con tooltip: el nombre visible lo cerró el grill («Refrescar», con el tooltip «Refrescar el inventario de esta web»), y en una tarjeta con cinco acciones el texto no cabe.
Código muerto fuera
Las columnas sites.umami_site_id y sites.kuma_monitor_id se escribían pero nadie las leía: el valor vivo de las integraciones vive en site_integrations. Peor: el campo del ID de Umami se podía editar en «Ajustes de la web» y no hacía nada — el que cuenta es el de la pestaña Analítica. Un campo que miente. Y la tabla overview_snapshots no la usaba nadie.
Antes de tocar nada miré producción: las dos columnas estaban vacías (0 de 9 webs), mientras que las de site_integrations tenían datos (8 de 9). Fuera el modelo, el esquema, el PATCH y la UI. El README documenta los ALTER opcionales: el repo no tiene migraciones y el ALTER se aplica a mano.
Issues cerradas con evidencia
Las #24, #29 y #32 seguían abiertas con la etiqueta ready-for-agent, pero su trabajo ya estaba hecho: el changelog del conector lo explica (la 1.8.1 añadió el bloqueo por ruta y el patrón «umbral→until» de una vez; la 1.8.2, el .htaccess honesto), y el journal del 21 de octubre recoge la verificación manual del #25 y el .gitignore de los worktrees. Se cierran con esa evidencia, no con un «hecho» a secas.