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.