Dos falsas señales, una en cada sentido.
seo_watch guardaba UNA huella de los dos blogs juntos. Una ejecución manual con
--site en la machacaba con media huella, y el siguiente disparo del timer creía
que todo había cambiado: te reenviaba hallazgos viejos como si fueran nuevos.
Un vigilante que cría falsas alarmas se acaba ignorando, que es justo lo que
este no se puede permitir. Ahora el estado es por sitio y solo se toca el de
los sitios revisados. El formato antiguo migra solo.
seo_link, en mobiledoc, solo miraba cards[0]. Un cuerpo repartido en varias
tarjetas —lo que pasa en cuanto el artículo lleva una imagen intercalada—
respondía «no aparece en la prosa» con el anchor delante. Como los dos formatos
acaban en diccionarios con clave "html", ahora se tratan igual: una lista de
trozos que se recorre entera. Sale más corto que antes.
Probado con la secuencia que rompía —revisión completa, manual solo de EN,
completa otra vez sin cambios— comprobando que la huella del ES sobrevive y que
la última calla; más un cambio real, que sí avisa. Y el de seo_link con el
anchor en la SEGUNDA tarjeta, verificado además contra el código viejo, donde
falla.
Migrado el estado real en el master: los dos blogs siguen sin hallazgos y la
migración no ha generado ningún aviso.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1) El corpus se pedía con --limit 100. Con 40 posts en EN y 29 en ES sobraba,
pero a 2 por semana habría cruzado los 100 hacia 2027 y se habría truncado
EN SILENCIO. Y un corpus truncado no da error: da falsos «enlaces rotos»
contra los posts que faltan, que es peor que no mirar. Pasa a --limit all
y, sobre todo, se comprueba el número contra meta.pagination.total: eso es
lo que convierte un fallo mudo en uno que se oye. En seo_link el truncado
era aún peor, porque haría rechazar como inexistente un destino que sí
está.
2) check_sitemap daba VERDE cuando curl fallaba: 0 URLs descargadas son 0
problemas encontrados, y el informe decía «✅ sin hallazgos». O sea que
justo el rato en que el sitio está caído era cuando este check se callaba.
Un sitemap vacío pasa a ser hallazgo con mensaje propio; en un blog con
29-40 artículos nunca lo está legítimamente.
Probado con casos que DEBEN fallar: corpus recortado a 3 de 40 (revienta y lo
dice), corpus completo (pasa limpio), y sitemap vacío (hallazgo, informe claro
y notificaría). Y en real contra los dos blogs: EN 40 posts / 33 URLs, ES 29 /
31, ambos sin hallazgos.
No toca seo_rules.py, así que el vendor-sync con ResearchOwl sigue en verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Faltaba la pieza de ESCRITURA en el cuerpo. El resto de herramientas leen
`html`, que Ghost renderiza venga de donde venga, y por eso el formato les da
igual; para escribir hay que tocar la fuente, y la fuente viene en tres sabores:
lexical con un bloque html los 29 del ES y casi todo el EN
lexical con nodos nativos roswell-341 y yellow-sea (extended-text)
mobiledoc con tarjetas html lo que genera ResearchOwl HOY en los borradores
El tercero se descubrió el 2026-07-21 con el Canarias de prueba: los scripts
que veníamos usando asumían lexical y habrían abortado sobre el próximo
artículo recién generado.
Las salvaguardas son cicatrices de errores reales de estos días: destino en el
corpus del sitio correcto, aviso si el destino está programado (enlace
prematuro → 404 en la ventana), URL con el canónico de cada sitio (EN www, ES
apex), el anchor nunca dentro de un <a> existente, y comprobación de anclas
balanceadas y no anidadas antes de escribir. Sin --apply no toca nada.
Probado en los tres formatos. El de mobiledoc, de punta a punta contra Ghost
con un borrador de usar y tirar: Ghost acepta la escritura, renderiza el
enlace, el mobiledoc sigue siendo válido y el texto queda intacto (2.143
palabras antes y después). Borrador borrado tras la prueba.
Lo que la herramienta NO hace es decidir: en la prueba encontró «Roswell»
dentro de «Roswell Daily Record», que sería un anchor pésimo. Elegir el anchor
sigue siendo humano.
