1) remate-watch ya no elige los enlaces internos a ojo. El paso 3 del prompt
pregunta primero a seo_semantic (afines), que le da los publicados más
parecidos y le marca los que el borrador YA enlaza. Se le dice
explícitamente que es una sugerencia y no una orden, y que si nada pasa de
~0,55 lo diga en el informe en vez de forzar un enlace malo: un enlace
forzado es peor que ninguno.
Para que eso funcione, seo_semantic sabe ahora trabajar con un post que NO
está en el corpus: `ghst post list` sin filtro devuelve solo publicados y
programados, así que el borrador que remate-watch está preparando no
aparecía. Se baja suelto por slug y se embebe al vuelo. Verificado por
equivalencia: los vecinos de un post embebido al vuelo son idénticos, hasta
el cuarto decimal, a los del mismo post cacheado.
2) canibal-watch: a diario a las 07:00 UTC (una hora después de que publique
la cola de agosto). Telegram SOLO si hay algo nuevo.
Solo avisa de pares que además NO se enlazan. Un par muy parecido pero
cosido con un enlace ya le dice a Google cuál manda; avisar de él es ruido.
Los enlazados se guardan igual en el estado, porque hacen falta para
detectar que MÁS TARDE pierdan el enlace (una edición que se lleve por
delante la jerarquía). Con el filtro, el primer aviso baja de 19 líneas a 5
accionables.
Probado por el camino real, arrancándolo con systemctl y no desde una
shell con el PATH bueno: primera pasada avisa (5 pares), segunda se calla,
y con una regresión simulada en el estado la detecta.
No escribe en el blog. Coser o fusionar lo decide Jose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Embebe los 80 artículos de los dos blogs con bge-m3 (ya cargado en ollama,
100% GPU) y sobre los vectores contesta dos cosas: a qué artículos publicados
conviene enlazar desde uno nuevo, y qué pares compiten por la misma búsqueda.
Nunca escribe en el blog: imprime. Quien escribe el enlace es seo_link.py,
y publicar lo decide Jose.
Decisiones que no son de adorno:
- NUNCA se cruzan los dos sitios. bge-m3 es multilingüe y da 0,966 entre un
artículo y su traducción (medido): cruzarlos marcaría todo el espejo ES↔EN
como canibalización, justo lo contrario de la verdad.
- Endpoint de ollama por la ClusterIP del Service, no por la IP del pod (que
cambia en cada reinicio) ni por el Ingress (está tras Authentik). El host la
alcanza por kube-proxy, sin NodePort ni tocar la red.
- Sin keep_alive en las peticiones: bge-m3 es de producción (lo usa
researchowl) y mandar keep_alive:0 lo desalojaría, cobrándole a otro la
recarga.
- Umbral 0,78 calibrado contra el corpus real, no a ojo: el reparto no es
igual en los dos sitios (ES mediana 0,58 / p99 0,75; EN 0,64 / 0,80).
Absoluto y no percentil, porque un umbral relativo siempre encuentra "el 1%
más parecido" aunque no haya problema, y un vigilante que siempre avisa no
sirve.
- Se mira qué enlaces EXISTEN ya en el cuerpo, y en qué DIRECCIÓN. Sugerir un
enlace que ya está es ruido; y decir "se enlazan entre sí" cuando el enlace
va en un solo sentido es mentir sobre lo único accionable.
Caché en ~/.local/state/seo-semantic/, re-embebe solo lo que cambia (hash del
texto). Corpus vía fetch_corpus de seo_link, que ya trae la guarda de corpus
truncado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
