El pase de las 04:58 UTC dejó todos los feeds a 0 pendientes, así que la
bajada temporal a 3 h del commit 134449e ya no hace falta. En régimen
normal entra ~1 episodio al día: revisar cada 3 h solo repetiría la
descarga del RSS ocho veces para no encontrar nada.
El comentario deja de ser un aviso pendiente y pasa a explicar por qué 24
es lo correcto y cuándo conviene volver a bajarlo.
Las copias remotas se purgaron a mano el 2026-07-27 (8 objetos en Mega, 3 en
B2, con --mega-hard-delete y --b2-hard-delete para que no se queden en papelera
ni como versiones ocultas). Sin subdirectorio remoto que preservar, el exclude
solo era ruido en la orden.
Verificado: el ConfigMap parsea y los cuatro scripts pasan `sh -n`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Los manifiestos que amparaba ya no existen, así que la excepción solo podía
envejecer. La auditoría queda en 0 hallazgos nuevos y 4 esperados (antes 13:
los otros 8 eran precisamente reddit-intel inactivo).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El servicio se decomisó (Reddit denegó el acceso a la API), así que su CronJob
de n97 estaría empaquetando cada noche un directorio que ya nadie escribe, y
backup-verify seguiría exigiendo una copia fresca que nunca va a llegar: en
tres días habría empezado a sumar ERRORS y a disparar la alerta por una avería
que no existe.
Se van el CronJob, el script reddit-intel.sh y su comprobación en verify.sh.
El `--exclude /reddit-intel/**` de rclone-mega SE QUEDA a propósito: sync es un
espejo exacto y quitarlo borraría de un tirón las copias que aún viven en Mega.
Se retirará cuando se decida purgar ese remoto a mano.
Verificado: el ConfigMap sigue parseando y los cuatro scripts pasan `sh -n`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reddit nos ha denegado el acceso a la API —la misma respuesta que a
roswell-corpus—, así que la promoción a k3s que describía PROMOTION.md no va a
ocurrir nunca. Estos manifiestos nunca llegaron a aplicarse (el app-of-apps no
es recursivo y no había Application), así que quitarlos no cambia nada en el
clúster; el namespace vacío se ha borrado a mano.
El contenedor de n97 se paró el 2026-07-27 tras once días devolviendo 401, con
la base de datos vacía: nunca registró un solo post. Copia final en
~/decommissioned/reddit-intel-final-2026-07-27.tar.gz y el código sigue en su
repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 episodios pendientes = 33,8 h de audio ≈ 20 h de CPU, pero a una pasada
cada 24 h con tope de 5 el pod transcribía ~4 h y descansaba ~20: el atraso
tardaba 5 días. Con 3 h encadena pasadas y se va en algo más de un día.
No cambia el pico de memoria (sigue transcribiendo de una en una, y el
troceado en ventanas ya lo acotó). Revertir a 24 al terminar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El límite subió 4→6→8Gi persiguiendo episodios largos porque el pico de
whisper escalaba con la duración. Con el troceado en ventanas (roswell-corpus
c869b61) el pico dejó de depender del episodio, así que 8Gi pasa de ser el
siguiente escalón a tener margen de sobra. Se deja escrito para que nadie lo
suba por inercia sin mirar antes si el troceado sigue vivo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Los dos estaban en git sin ninguna Application que los gestionara: editar el
repo no desplegaba nada. De ahi que un pin de imagen de abril nunca llegara
al cluster y gitea se subiera solo de 1.25.5 a 1.27.0, y que vaultwarden se
parcheara con kubectl replace. A partir de ahora manda git.
Verificado en frio antes de adoptar: los 17 manifiestos coincidian campo a
campo con lo vivo, asi que la adopcion no revierte nada. Con
ServerSideApply/ServerSideDiff, igual que el kube-prometheus-stack: estos
objetos arrastran un last-applied viejo y el merge clasico intentaria borrar
lo que ese blob declaraba y git ya no; en un PVC eso es un campo inmutable y
el sync falla.
Limpieza que iba en el mismo paquete:
- Fuera la basura de export de 5 ficheros: last-applied-configuration, la
revision del Deployment y las anotaciones que pone el provisionador en los
PVC (bind-completed, selected-node...). Es lo que dejaba los recursos
OutOfSync para siempre. Verificado que el resto del manifiesto no cambia.
- Fuera serviceaccount-default y kube-root-ca.crt de los dos: los crea k8s
solo en cada namespace.
- RESCATADO configmap-gitea-runner-config: config del act_runner escrita a
mano en abril, montada por el runner y que NO estaba en git. Reconstruir
gitea desde el repo levantaba el runner sin configuracion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Las dos alertas de B2 llevaban desde esta manana en el ConfigMap y MUERTAS:
Grafana lee el provisioning de alerting solo al arrancar y el pod era del
dia 22. El sidecar de kiwigrid recarga dashboards y datasources, pero el
alerting entra por extraConfigmapMounts y ese camino no lo toca nadie.
Reiniciado Grafana: 7 reglas cargadas -> 9. Queda el aviso en la cabecera
del fichero, con el comando de reinicio y el de comprobacion contra la API,
que es la unica fuente de verdad aqui (el ConfigMap mentia).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
43 eran el render del kube-prometheus-stack, volcados con kubectl get -o yaml
y sin que nadie los aplicara: decoracion que solo servia para creerse que git
describia el cluster. Ahora los genera el chart desde la Application de la
Fase 2, que es su unico dueño.
Los 6 restantes los fabrica un controlador y en git no pintan nada:
rulefiles-0 (154KB que genera el prometheus-operator desde los
PrometheusRule), el StatefulSet, el service prometheus-operated y el PVC de
datos (los tres nacen del CR Prometheus / su volumeClaimTemplate), mas
serviceaccount-default y kube-root-ca.crt, que k8s crea solo en cada
namespace.
Ninguno estaba en la lista blanca del app de monitoring, asi que borrarlos de
git no toca el cluster. Clasificados uno a uno antes de borrar (render del
chart vs ownerReferences vivas), no a bulto.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
El chart era un release Helm gestionado a mano (helm upgrade) desde abril.
Ahora lo gestiona su propia Application con source Helm, version clavada a
83.2.0 (la que ya corria: esto es una adopcion, no una actualizacion).
Los valores se mudan de values-kube-prometheus-stack.yaml al valuesObject de
la Application, con sus comentarios: ahi esta el historial de los retoques a
mano que se recuperaron en julio (alerting, SSO de Authentik, token de
Telegram), y perderlo seria perder el mapa. Inline y no multi-source $values
porque ese montaje se auto-podo la Application de infisical el 2026-06-18, y
tener los valores en dos sitios es la deriva que veniamos a matar.
La adopcion se verifico ANTES de activar el auto-sync: aplicada sin
syncPolicy, ArgoCD daba 96/97 Synced sin haber sincronizado nunca. El que
faltaba era el Deployment de Grafana, y no por deriva: el render del subchart
no declara managed-by: Helm ni el restartedAt del podTemplate, asi que el
merge a 3 bandas del cliente los habria BORRADO (reinicio de Grafana + Helm
perdiendo la propiedad del objeto). Con ServerSideApply/ServerSideDiff ArgoCD
solo toca lo que declara: 97/97 Synced, cero operaciones de sync, cero pods
reiniciados. selfHeal probado con replicas 1->2 en kube-state-metrics,
revertido en 11s.
skipCrds: true a proposito: ArgoCD pasa --include-crds por defecto y los 10
CRD de monitoring.coreos.com no los gestiona nadie hoy. Contrapartida
documentada en el fichero: al subir de chart hay que aplicarlos a mano.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Basura del volcado con kubectl get -o yaml. Al estar versionada se muerde la
cola: ArgoCD la aplica, k8s genera una nueva que ya incluye el tracking-id, y
git y cluster no coinciden nunca -> los 4 recursos se quedaban OutOfSync para
siempre. Verificado que el resto del manifiesto queda byte a byte igual.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hasta ahora las alertas de Grafana se aplicaban a mano con kubectl apply,
asi que dependian de que alguien se acordara (se vio hoy al anadir las de B2).
Lista blanca explicita en vez del directorio entero: monitoring/ mezcla tres
duenos y solo uno es nuestro. Fuera quedan los ~40 renderizados del chart
kube-prometheus-stack (release Helm viva -> dos duenos del mismo objeto) y los
generados por controladores (rulefiles-0 del prometheus-operator, etc).
Adoptar el chart via source Helm queda como Fase 2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gemelas de las de MEGA: avisan si B2 factura >80% de los 10GB gratis
(b2_billed_bytes) o si las versiones ocultas pasan de 2GB (b2_hidden_bytes,
lo que indicaria que algun borrado no usa --b2-hard-delete).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
B2 tiene el mismo fallo que la papelera de MEGA con otro nombre: al
borrar/espejar no elimina, oculta la version vieja y la sigue facturando.
Las versiones ocultas llegaron al ~88% del tramo gratis de 10GB el
2026-07-25 (8.78 GiB facturados vs 1.75 GiB visibles).
- --b2-hard-delete en el sync de crown-jewels y en el delete de reddit-intel
- mega-quota-exporter ahora tambien exporta b2_visible/billed/hidden_bytes
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El incidente del 2026-07-25 (MEGA lleno -> dos CronJobs de backup caídos)
solo se detectó por el síntoma. La causa llevaba meses creciendo sin que
nada la mirase.
- backup-system/mega-quota-exporter: Deployment que sondea `rclone about`
y `rclone size` cada 15 min y los sirve a Prometheus vía ServiceMonitor.
mega_trash_bytes (usado - visible) es la métrica que habría cazado esto.
- monitoring: dos reglas de Grafana, cuota > 80% y papelera > 2GB.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La papelera de MEGA cuenta cuota. Los `rclone sync`/`rclone delete` de
rotación diaria enviaban ahí las copias antiguas, acumulando 16.6 GiB de
basura hasta llenar los 20 GiB de la cuenta. El 2026-07-25 eso tumbó los
jobs rclone-mega-backup y reddit-intel-backup con "Request over quota".
Papelera vaciada a mano (375 objetos); este flag evita que se repita.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La key de IndexNow solo autoriza URLs bajo su directorio, así que debe
vivir en /{key}.txt. Ghost no sirve ficheros arbitrarios en la raíz: el
middleware reescribe la ruta al fichero real en content/files/indexnow/
(PVC de Ghost, colocado con kubectl cp). El envío de URLs lo hace
~/seo-tools/indexnow_watch.py (timer horario en el master).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CronJob externo a n8n que lee la SQLite en solo-lectura por el hostPath y avisa
si el workflow del autopost desaparece (firma de la reversión del 2026-07-16) o
si el total de workflows se desploma. La reversión SUBE el nº de activos, así que
un umbral de activos no la cazaría; el disparador es la desaparición del autopost.
Cada 6h. Reutiliza telegram-notify-infisical.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Borrados qwen2.5:3b y nomic-embed-text (sin consumidores tras subir a 7b/bge-m3).
El script de arranque solo traía 3b: tras perder el PVC, un reinicio dejaba a
researchowl y roswell sin el modelo de embeddings. Ahora trae los dos reales.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Los 3990+ chunks existentes se re-embebieron a 1024d in situ antes de este
cambio; sin eso el coseno daría 0.0 por dimensión distinta y rompería la
recuperación. bge-m3 alinea researchowl con roswell (mismo modelo, multilingüe).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gitea CI
chemavx