Afinado y recuperación durante la noche del 19 al 20 de octubre de 2026

Guardado durable integrado en fuente, 20:49 CEST: PR87 fusionada tras revisión y CI Linux 3.10/3.12 y promtool correctos. Checkpoints con fsync de archivo/directorio, cancelación conservada y sin rollback ni segundo guardado tras un commit incierto. Backend sin instalar; coste de fsync por heartbeat pendiente de medir y causa de los resets abierta. Fuente y límites.

Falso éxito de originales corregido en fuente, 20:37 CEST: PR86 fusionada tras CI Linux 3.10/3.12 y promtool correctos. Informe ausente/inválido ya no aparenta colección correcta ni reinicia la edad en cada lectura. Se conserva historial legacy válido sin atribuir verificación a complete_existing. Backend manual sin instalar; wrapper, alertas y calendario intactos. Defecto, compatibilidad y límites.

Ejecución de CT280 acreditada a las 20:26 CEST: el log local registra su finalización individual en el lote de las 05:00, separada del éxito global. No acredita integridad, existencia actual, backend ni restauración del archivo. Configuración PBS y dumps nativos se distinguen en la tabla y evidencia.

Rol Remote-Pulse protegido20:15 CEST: PR85 fusionada3a90959 tras lint y fixtures Ansible Linux3.12/3.14 correctos. Aplicaciones manuales del rol obsoleto fallan antes de mutar; ordinary never continúa omitido, sin modificar servicio. Lectura20:13 sólo acredita plantillas PG disabled, sin instancias cargadas; backups reales siguen pendientes, sin lanzar trabajos. Evidencia y plan.

Privacidad fuente20:07 CEST: PR84 fusionada575121c; URL opcional de Healthchecks por stdin a curl, validación privada y script root0700. Once fixtures y lint/Linux3.12/3.14 correctos antes y después del merge. Conserva aviso/timeout, sin HTTP real ni aplicación del rol manual a CT280. Cambio y límites.

CT28019:46 CEST: script y unidades de la plantilla Remote-Pulse no están instalados; no se aplica el rol manual suponiendo equivalencia. Hace falta resolver persistencia/cobertura viva. Esto no demuestra ausencia de otras copias/PBS. PR82 es una prevención en fuente, no un backup aplicado. Lectura mínima y límites.

Fuente integrada19:39–19:42 CEST: PR82 corrige backup Remote-Pulse: verifica antes de publicar o retener, nueve fixtures y lint/Linux3.12/3.14 correctos antes y después del merge; rol manual, sin aplicación al host. Defecto, corrección y límites. PR83 guarda candidato Soularr OIDC inactivo, con login firmado ficticio, PKCE/nonce/cookie, Origin, headers y SSE probados localmente por dos revisores. Linux/Pocket ID real, renderer/ACL, clientes, recursos y recuperación pendientes. No protege todavía la UI activa. Plan.

Guard Immich corregido19:17 CEST, sólo fuente: PR81 fusionada tras CI Linux3.10/3.12 y alertas correcta;24 pruebas de recuperación y18 lifecycle. Raíz ausente ya no cuenta como cero, dump debe pertenecer a ella y se rechaza traversal antes de normalizar. Limpieza conserva error original en Python3.10. Ningún motor, dump real o restore lanzado; restauración completa pendiente. Detalle.

Lector propagado naturalmente19:15 CEST: pmx51 conserva boot y archivo instalado0697… exacto, root:root0755, tras ciclo Ansible ordinario19:13–19:14 correcto. Sin forzar pull ni ejecutar lector. Publicación documental PR80 ya fusionada y su despliegue39464018058 correcto; jobs serializados construyen main actual y registran HEAD real. Publicador FIFO de VM208 sigue sin instalar. Recibo y alcance.

Fuente y CI, 19:05 CEST: lector manual acotado integrado por PR79, doce pruebas y lint posteriores correctos; propagación natural a pmx51 aún pendiente de observar. No se ejecutó sobre logs reales como prueba. Publicador FIFO PR78 con56 pruebas correctas sigue sin instalar en VM208. CI de homelab-maint deja de persistir credenciales de checkout (PR2), sin cambio de app ni nuevo reinicio. Alcance y evidencias.

Recuperación observada18:59–19:00 CEST, sólo metadata:28/28 invitados running con los mismos propietarios; Docker90IDs/estados/proyectos conservados respecto15:10,47running/42exited/1created. Entre running:23healthy y24sin healthcheck,0unhealthy/restarting/paused/OOMKilled registrados. Las22marcas unhealthy son de exited, no nuevas averías. Hold RunWisp f7b3… intacto; nada autoriza despertar dormidos o copias migradas. No hubo llamadas a productos. Esquema y cobertura fechada.

Noveno arranque18:45:05 CEST: pmx50 boot 82d105f6…, expiración watchdog hardware SP5100 (0x02000800/bootstatus32), causa desconocida. VM208 arranca18:45:50; pmx51 conserva boot 86184726…. Último journal PRE 18:44:33 y pulso recibido hasta18:44:40 no acreditan último keepalive ni duración del bloqueo. Pull natural posterior18:51:10–18:51:58 rc0/71ok/0changed; caché limpia en alcance normal y ambas claves fsync retenidas, sin prueba causal de eficacia ni estabilidad. Nuevos cambios runtime detenidos; parche FIFO publicado sólo en fuente, sin instalar. Evidencia, hashes y límites.

Consola protegida18:39–18:40 CEST: app de CT212 actualizada y verificada con nueva invocación, L0 y cero tareas. Timeout/señal detienen el lote incluso con ignore_rc; estado, tareas, unidad, venv y logs preservados. Aplicación y recuperación.

Térmica nativa18:17 CEST: pmx50 Tctl49,75→48,375 °C; pmx51 package/cores81→74 °C en unos2 s, sin incremento de sus contadores en esa ventana corta. No equivale a resolver la alerta de5 min. Boots 248d8d61… y 86184726… conservados; Intel no_turbo=0 permite turbo, sin acreditar uso instantáneo ni causa. thermal.off=1 sigue en pmx51; ningún control cambiado. Muestra y límites.

PBS, lectura local17:59 CEST: archive prune OK del20oct00:00:01; el GC con registro00:02:31 queda UNKNOWN, sin terminal de éxito verificado. Bytes recuperables desconocidos, no cero. Rootfs y logs locales acreditados, sin abrir datastores/NAS ni ejecutar tareas; no se atribuyen causas a resets. Evidencia y horario histórico.

Protección del publicador, 17:32–17:33 CEST: v2 instalado y verificado independientemente, sin ejecutarlo. Backend, RunWisp y trece archivos de estado, incluido el lock permanecen iguales; ningún job ni acceso NAS. Primera publicación diaria y siguiente incremental real siguen pendientes: Required no se resuelve por instalar el archivo. Recibos y alcance.

Primer ciclo natural tras fsync, observado17:18:39 CEST: unidad Ansible 17:06:45–17:07:31, rc0 y boot 248d8d61…; lectura efectiva posterior conserva core.fsync=all y core.fsyncMethod=fsync. Son 46 s frente a 49 s de una muestra anterior: no acredita un efecto causal de rendimiento ni estabilidad futura. Evidencia y límites. No se forzó pull ni se consultaron aplicaciones; la causa de los resets sigue abierta.

Requisito de dump vencido, muestra16:41:38 CEST: OriginalsDumpPublicationRequired ya está firing, condición activa desde 16:30:09; no consta primer éxito aunque la configuración observada está habilitada. OriginalsCopyFailed y PBSDataReserveLow también están firing. Estados, métricas y límites. No se forzó publicación ni ningún job, ni se cambió la compuerta de alerta.

Alertas registradas16:23–16:27 CEST: 92 reglas sin errores de evaluación no equivalen a todo sano. A las 16:24 hay 5 reglas firing (8 instancias) y 2 pending: copias de originales, NFS del NAS, throttling y avisos Arr/RemotePulse siguen visibles. RemotePulse separa un cliente de Carmelo fuera de alcance y otro desconocido, sin contactar equipos. Publicación dump aún antes de su compuerta 16:30 más 10 min; no se interpreta inactive como éxito. Detalle fechado y límites.

Nuevo arranque confirmado a las 15:55:04 CEST: btime nativo 1792504504, boot 248d8d61…, observado a las 15:56:35. El kernel actual registra expiración del watchdog hardware; causa pendiente (octavo arranque registrado). evidencia y límites. El pull correcto de las 15:50–15:51 pertenece al boot anterior y no acredita estabilidad posterior. Ya en boot 248d8d61…, el primer pull natural posterior terminó16:01:41–16:02:28, rc0, 71 ok / 0 changed / 0 failed; HEAD6d1b30d y status limpio en alcance normal. Sólo acredita ese ciclo, no salud de apps ni estabilidad posterior. El plan de fsync no se aplicó.

Seguridad de CI, 16:05 CEST: las tres referencias remotas que aún usaban etiquetas móviles se fijaron a commits de sus repositorios oficiales: checkout v5, ansible-lint v25.12.2 y upload-artifact v4.6.2. El lint recibe sólo contents:read y su checkout no conserva credenciales Git. Se preservan argumentos, triggers y despliegue; YAML y revisión independiente correctos. En ba53001 terminaron correctamente ansible-lint39436016057 y docs-deploy39436016032. No cambia servicios.

Fuente de durabilidad Git, 16:18 CEST: lector compartido y transacción preparados con60 pruebas locales y revisión independiente. Incluyen rechazo de perfiles desconocidos y verificación de fuentes antes de consultar Git en contexto. Fuente y límites operativos. Falta evidencia real fresca; ejecución bloqueada antes del transporte y sin configuración instalada. CI39438143984 en62547c9 terminó correctamente: 60 pruebas por versión, Linux Python3.10 y3.12, y plan sin red.

Nuevo evento15:11:50 CEST: otro arranque confirmado nativamente a las15:12:55, posterior al de13:35. El nuevo kernel registra hardware watchdog timer expired. Causa pendiente. Se recuperaron32objetos Git a15:19:51, con conectividad comprobada15:21; los 16 archivos vacíos se restauraron a las 15:34:56 y se verificaron por separado a las 15:37. El primer pull natural posterior pasó15:50–15:51, rc0, 71ok/0changed/0failed; caché en a98a9ad y status limpio en alcance normal. Las muestras PVE15:06 y Docker15:10 son anteriores al último evento.

Actualización20oct14:52 CEST: otro arranque de pmx50 confirmado directamente en /proc/stat y boot ID:13:35:18CEST. Es posterior al último arranque02:13 analizado abajo. El motivo de este nuevo arranque está en investigación; no se atribuye aún al watchdog ni se levanta el hold. Las observaciones anteriores conservan sus fechas y no acreditan continuidad de ese boot hasta ahora.

Última revisión de instalaciones:20oct14:41 CEST, con CI de código correcta. El backend de copias8581a6dc, colector PVE308f39d4 y92reglas están instalados y verificados; la sección final registra el ciclo natural y sus límites. Las protecciones de capacidad de originales, identidad LXC en PBS y estados OOM/reinicios están publicadas, instaladas y verificadas. La guarda de cancelación del publicador pasó CI, se instaló13:53 y se verificó mediante lectura independiente13:54. La regla de reserva se validó, recargó y se verificó en dos evaluaciones naturales13:42–13:43 tras una primera lectura incompleta sin causa acreditada. No se ha relanzado ninguna copia ni ensayo de recuperación. Japón mantiene sus parches y la imagen publicada, sin despliegue de aplicación. El esquema actual recoge28 invitados PVE y90 Docker en VM208 según observaciones12:25. Vera permanece en el trabajo paralelo del usuario; watch/updater siguen retenidos y no se aplica el role RunWisp completo.

Avance20oct13:33–13:54	Evidencia y límite
Capacidad de originales	Backend a09097db instalado13:33:46 y verificado13:34:44;13archivos de estado y RunWisp intactos. Estimación y alerta corregidas con fixtures, sin recorrer NAS ni ejecutar copia. Instalación y recuperación.
Consumidor de reserva	Una expresión cambiada, otras90reglas preservadas; promtool91reglas y reloadHTTP20013:35:02. Dos evaluaciones naturales13:42–13:43:91healthok, reserva y4publicación inactive; CopyFailed pending. Sin repetir escritura/recarga. Límites.
Guardas PBS LXC	Ambos nodos con helper650261f7 y compilación nativa correctos13:37:53–54. Proxmox actualizado; proxmox2 ya tenía el candidato. Sin drill ni VM temporal. Detalle.
Guarda OOM	Helpers2903a01f instalados VM208/CT21813:36:54–55, lecturas13:37:57–59 correctas.20archivos protegidos y locks intactos; sin pruebas a productos. Detalle y recuperación.
Contador de reinicios	Ya no acepta ausencia/bool/negativo como cero correcto.94tests+11lector y CI3.10/3.12 correctos. Helpersb95b04fa instalados13:48 y verificados13:48:30–32; protegidos/locks intactos. Instalación y límites.
Cancelación del publicador	TERM/INT/HUP recogen el grupo propio;46pruebas y CI Linux3.10/3.12 correctas. Fuente0a3a85f; instalado13:53 y verificado13:54, estados/RunWisp intactos, sin ejecutar publicación. Evidencia.
Primer watchdog	Rotaciones añaden51pulsos PRE hasta00:02:36 y7POST separados. Temperatura/memoria/PSI documentadas; causa sigue desconocida. Cobertura recuperada.
Retención PBS	Políticas y selección de invitados reconciliadas con metadatos13:15. Selección en job no equivale a copia exitosa o restore verificado. Políticas.

Las cinco comprobaciones CI de la fuente131253c→ba701c4 terminaron correctas: copias Python3.10/3.12, contratos, monitor Docker, ansible-lint y documentación. Las suites posteriores contratos39417299806 y copias39417996724 también terminan correctamente en Python3.10/3.12. Siguen pendientes la copia incremental real tras corregir el receptor, primera publicación diaria, recuperación completa de Immich, reparación segura de OnePacerr y causa de los watchdog. pics terminó00:30:08; ese pendiente histórico no debe confundirse con verificar la copia incremental siguiente.

pmx50 sufrió cinco reinicios sin orden de mantenimiento: 00:03,00:25,00:58, 02:11 y02:13 del día20. Los cinco arranques registran expiración del watchdog hardware; no se conoce la causa de la pérdida de actividad. Los dos últimos están documentados en incidente adicional y lectura del peer. A02:14:52 la API muestra 28/28invitados running con los mismos propietarios; pmx51 conserva su arranque. El cuarto episodio ocurrió antes de iniciar la prueba sintética en VM208; el quinto cortó su SSH sin resultado. Esa prueba queda interrumpida, sin PASS/FAIL ni atribución causal. A02:16:17 el guard natural había recuperado archive de PBS sobre ext4/loop0; la primera lectura posboot encontró el montaje aún ausente. No se lanzaron jobs. Se suspenden nuevos cambios runtime mientras se recoge evidencia de estabilidad. Como contención del incidente se aplicó una retención reversible de watch y updater: esos automatismos también podían recrear contenedores. El daemon conserva sus 19 tareas y sólo cambian dos comandos; a03:10:43 la última ejecución natural de watch ya muestra exit75. El updater04:00 queda retenido sin ejecutar manualmente. Esto pausa la autorreparación de watch; las otras17 tareas y los horarios se conservan. Sin caducidad automática: no aplicar el roleRunWisp completo ni restaurar el recibo hasta resolver la suspensión y revisar la estabilidad. Las copias se preservaron y pics quedó cerrado a las 00:30:08 del día 20, con cuatro muestras recuperadas y hashes coincidentes. El ensayo DB-only de Immich terminó satisfactoriamente en Bazzite: 31.595 assets, 10.803 fotos y 20.792 pics coinciden con el dump recuperado de Synology y sus clases de checksum. Contenedor aislado detenido, sin OOM ni swap adicional; el gate acreditó límites reales antes de inicializar PostgreSQL. No se ha restaurado la aplicación Immich ni validado todavía el contenido completo de los originales. El cotejo posterior de NAS encontró las31.595 referencias presentes, regulares y no vacías, sin ninguna anomalía de metadatos. A las02:05 se recuperaron además tres originales de upload (6098264bytes), con SHA1 cotejado contra el dump19 y SHA256 tras relectura local. Integridad del conjunto completo de bytes sigue pendiente. La publicación diaria del dump está habilitada en la tarea existente de originales. El ciclo natural del20oct11:10 falló antes de ejecutar el publicador: el receptor rechazaba la forma incremental de GNU rsync. Receptor corregido11:28, sin reintento forzado. Primera publicación automática y siguiente incremental real siguen pendientes; la configuración se conserva intacta. Véase la intervención posterior de copias.

El kernel registra «hardware watchdog timer expired» y el dispositivo SP5100 reporta bootstatus=32. Esto acredita el mecanismo del reset, no la causa de la pérdida de actividad. No se han cambiado watchdog, kernel, BIOS ni RAM. Incidente y recuperación observada, análisis con fuentes oficiales, segundo reinicio y correlación del otro nodo. El tercer reinicio conserva el mismo mecanismo; a las 01:06 la API vuelve a mostrar 28/28 invitados en marcha. El acceso SSH a Bazzite se comprobó directo a .141, sin proxy ni dependencia de pmx50. El ensayo sigue separado del host afectado.

Cambios aplicados y publicados

A las02:09 se instaló además la protección de cancelación de copias: creación y limpieza del grupo protegidas frente a TERM/INT/HUP, incluidos cambios de manejadores;36 pruebas con una omisión y revisión cruzada. Compilación nativa Python3.10.12, CAS y rollback privado, estado de copias y RunWisp intactos; sin ejecutar jobs.

Cambio	Estado y validación
Consola CT212	Limpieza de procesos al vencer timeout o cancelar; consultas compartidas entre pestañas y caché de cinco segundos. 34 pruebas; fuente y runtime coinciden. Maint main en 240dd0c.
PBS CT186	Selección paginada del último sync completado; errores de colección y HTTP diferenciados. 17 pruebas; instalación validada con --inspect, sin iniciar jobs ni enviar métricas artificiales. Timer de las 07:00 y contador conservados.
Frontend scanner	Stacks master en 1390e77: instalación limpia y build en Node 20, audit del árbol fuente en cero. Dependabot 33 confirmado como corregido. No se cambió el runtime ni la imagen del scanner.
Contratos de servicios y rutas	Validación de cobertura desplegada en VM208, CT212 y CT218. 72 pruebas; informes parciales rechazados. Inspector real: siete rutas correctas, sin HTTP a productos ni sync. Los 29 pendientes siguen explícitos. Infra main en 5b89557.
Dump independiente de Immich	Generación immich-dumps/20261019 cerrada en Synology a las 23:57. Hash idéntico origen → Synology → fichero recuperado; CRC de gzip correcto. Directorios 0700 y archivos 0600. Evidencia conservada tras el reinicio.

Detalles y recuperación: consola, PBS, scanner, contratos, Immich.

A las02:12 se incorporó la expectativa de publicación: primer éxito requerido tras20oct16:30CEST más10min de persistencia; luego antigüedad máxima26h, incluso si se pierde el flag. Promtool nativo validó87 reglas y cinco escenarios; tras reload87/87health=ok, sin reiniciar ni enviar notificaciones de prueba. El ciclo natural11:10 falló antes del publicador; el receptor se corrigió11:28 sin relanzar copias. La primera publicación automática sigue pendiente; la regla no inventa éxito ni cambia el plazo16:30.

Fuentes reconciliadas y documentación

La plantilla de Prometheus representa los26jobs efectivos; cinco pruebas y promtool del par candidato/87reglas pasan. No se aplicó al runtime. Los procedimientos manuales antiguos de Prometheus, Grafana y Alertmanager para VM208 quedan bloqueados antes de escribir/HUP/API; conservan never y no alteran el autopull ordinario.

El perfil observado de CT217 recoge10servicios e identidades de imágenes/mounts, sin valores de entorno. Es inventario fechado, todavía no un Compose completo de recuperación. La muestra Docker02:28:30 de VM208 vuelve a contar90contenedores:53running, 35exited y2created; sin despertar productos ni atribuir fallos a los migrados.

La reparación de publicación de docs sustituye una acción inaccesible y corrige la selección del árbol redactado. Las nueve pruebas del redactor y el build completo strict pasan, conservando fechas Git. El endurecimiento posterior quedó publicado en run39350183799/605fbecSUCCESS; la página de coberturaCT217 del despliegue inmutable respondióHTTP200. El run 39350828446/c0114c8 también terminóSUCCESS. El dominio personalizado no se validó tras sus respuestas302/403 sin seguir redirecciones.

Las pruebas de mantenimiento ya se ejecutan automáticamente en Linux con Python 3.12 y 3.14: run39350794730, 62 pruebas por versión, main 65f713f. Es CI de fuente; no modifica el runtime de CT212. Las suites aisladas de copias/publicador pasan en Linux con Python 3.10 y 3.12: run39351465787, 36 + 36 pruebas por versión, sin omisión del fixture rsync moderno. No sustituye la prueba de VM208 interrumpida ni acredita una copia o restauración de producción.

El worker de Dependabot conserva ahora la última muestra global completa si falla un repositorio o se pide un subset; si no puede leer seguridad, omite decisiones de ese repo. Un intento de merge fallido cuenta como HUMANO. Fuente jev-gateway, main 5ad0771; CI39351506748 terminó con 160 passed y una omisión. La fase inicial fue sólo de fuente. A las 03:19:01 CEST se instaló la guarda protectora en CT215, preservando el default avisos.lan: runtime SHA91a329cc coincide con la copia de stacks master eb5d289 y con la fuente canónica salvo ese único destino configurado. Hubo backup privado, CAS, reemplazo atómico y compilación nativa Python3.13.5; servicio inactivo antes y después. No se ejecutó ni reinició el worker o su timer. Detalle y recuperación.

La métrica consultada a03:12:27 mostraba20pendientes y último PUT02:35:37; no acredita cobertura completa porque lo publicó el worker anterior. La unidad real de CT215 terminó correctamente a02:34:14; fuente del timer horario, activo esperando en la lectura. Resultado natural posterior al parche pendiente.

A las 03:19:33 CEST, pmx50 conservaba el arranque834ae68a y65 minutos de uptime, carga2,22/2,20/1,99. No se observó un sexto reset en esa lectura; la causa del watchdog y la estabilidad futura siguen pendientes.

La consulta pasiva térmica de las 03:02:21 sitúa el aviso de throttling en pmx51: 84 °C y 32,34 eventos/s agregados. Pmx50 aparece a 54 °C, sin esa serie de contador. No atribuye los resets a esa muestra ni cambia controles térmicos, recursos o cargas.

La auditoría individual de backupCT217 acredita selección en el job01:00 y entrada PBSconctime01:02:36 de hoy, rootfs40G sinmpN PVE declarados. Restore217/payload/coherencia siguen pendientes; no se amplió el drill ni se ejecutaron copias. Prometheus3.15.0 coincide con la última release oficial; Grafana/Alertmanager no tienen versión instalada acreditada, por lo que no se ha decidido un upgrade a partir de latest/Created.

Copias y recuperación pendientes

photos terminó a las 23:15 del día 19. Sus tres muestras restauradas son vídeos derivados de encoded-video; no acreditan la recuperación de originales. El reinicio interrumpió pics; se conservaron su carpeta temporal y el informe legado. La primera reanudación terminó de transferir los datos, pero falló al descargar muestras con espacios por una doble aplicación de comillas. El arreglo bbf7ff7 pasó tres pruebas reales entre VM208 y Synology, con espacios, apóstrofes y Unicode. La tarea existente se repitió una vez: generación pics/20261019 cerrada a las 00:30:08, cuatro muestras de 906.978, 5.113.691, 4.828.134 y 713.298.013 bytes, con hash de origen, destino y recuperación idénticos. Esto acredita esas muestras; no el cotejo de todos los originales de Immich.

El dump protegido contiene 31.595 assets: 10.803 de photos y 20.792 de pics. Había 29 fotos posteriores en la base viva. Los externos usan sha1-path, que no es un hash del contenido. El manifiesto mantiene coherence_verified=false: la restauración real de PostgreSQL y el cotejo de presencia de todas sus referencias ya pasaron. Quedan la integridad del conjunto de contenidos y la coherencia temporal entre dump y originales; tres muestras upload tienen cotejo criptográfico positivo.

VM208 no tenía margen para reservar 1 GiB al ensayo conservando otros 2 GiB libres. Bazzite ya estaba encendido y tiene Podman instalado; se preparó una alternativa aislada, pero su transferencia quedó vacía por el reinicio de pmx50. Ambos staging vacíos se conservan. Una transferencia posterior directa de Synology a Mac y Bazzite recuperó el dump; la imagen se obtuvo de GHCR verificando índice, manifiesto, configuración y 21 capas por digest. Podman cargó la imagen exacta; la comprobación automática posterior falló por usar .Id en vez de .ID, aunque la lectura corregida confirmó la identidad. La reconciliación terminó sin repetir descarga ni carga. Posteriormente, el tercer ensayo aislado restauró el SQL completo y confirmó los31595 assets; contenedor detenido tras éxito, límites kernel acreditados antes del bootstrap. Los dos intentos previos fallidos y sus artefactos se conservan. No se han tocado trabajos de IA/GPU.

Operación y próximos cambios

Distribución actual de servicios: 28 invitados, 26 LXC y dos VM. Estar en marcha no acredita por sí solo la salud de cada app.

La política futura de muestras reserva candidatos de library/upload, con el mismo presupuesto máximo de cuatro archivos. Añade limpieza del grupo de copia ante señales y preservación del estado legado al reanudar. Su despliegue y reanudación se registran en el informe de Immich cuando queden acreditados; no atribuir esas verificaciones nuevas al ciclo anterior.

Diseño de L2–L4: incluye escritores, lectores, cliente NFS de Home Assistant, dos mounts NAS en cada PVE, loop PBS en pmx50, mantenimiento y drenaje PBS, horarios, exports y selfheal del NAS. Las transiciones siguen deshabilitadas. El planner offline está publicado en maint main, commit dcaccac, con 62 pruebas en la suite. Siempre devuelve executable=false; no está conectado a un ejecutor ni a la consola.

En pmx51 sigue observándose limitación de CPU. La última muestra anterior al incidente era de 70 °C; el contador no identifica por sí solo la causa. Siguen pendientes diagnóstico físico, margen N-1 para picos y requisitos de SAI/Meross.

Protección añadida tras el incidente

La alerta de cambio de arranque está desplegada y verificada en dos evaluaciones: 84 reglas saludables, sin reiniciar Prometheus ni cambiar receptores. Detecta un salto de boot time superior a 30 segundos dentro de 15 minutos, sin atribuir la causa ni clasificarlo como inesperado. El incidente actual activó el aviso real.

Se preservó el informe legado antes de reanudar; el backend instalado incorpora la preservación de 008b9e9 y el arreglo de descarga de bbf7ff7. Se localizaron dos sesiones receptoras en Synology: la antigua permanecía inerte tras perder su productor. Se neutralizó sólo esa pareja tras comprobar identidad y detenerla, evitando su limpieza automática de archivos. Sus temporales siguen conservados y la sesión nueva continuó avanzando. El receptor Synology incorpora ahora exclusión remota por generación y rechazo de flags y operandos adicionales no validados. La revisión independiente y el fixture final en Python 2.7.18/rsync 3.0.9 pasaron antes del despliegue atómico. Hash instalado 6dcc7cca…, permisos 0700, privacidad específica de dumps verificada por transferencia real y rollback privado conservado. Las cinco generaciones de 20261019 siguen completas y sin staging; no se modificaron sus datos ni las claves. Evidencia y límites.

Memoria tras el arranque: sin OOM en la ventana observada, pero con paginación y margen limitado. No se recorta más RAM. Stash consume unos 52 MiB en una muestra; no hay evidencia suficiente para atribuir quién lo inició ni justificar cambios.

Siguiente fase preparada a las 00:50

El publicador diario del dump está implementado, publicado e instalado con el backend en VM208, con opt-in en el job existente y telemetría propia. Suite conjunta: 112 tests, uno omitido por el rsync antiguo del Mac. Sigue desactivado; no se ha exportado otra base ni añadido un horario. Las dos alertas nuevas están cargadas: 86 reglas sanas en dos evaluaciones distintas, sin reiniciar Prometheus; las nuevas permanecen inactivas con el publicador apagado. La configuración de RunWisp y last.json siguen intactos.

PBS y sus dos datastores están accesibles después del segundo arranque; el análisis de mounts distingue el montaje tardío acreditado de los accesos iniciales desconocidos. No se provocó ningún job.

Se verificó una cadena de digests OCI que conduce al ImageID exacto de PostgreSQL usado en producción. Permite preparar inputs en Bazzite sin exportar desde VM208: se revisa descarga serial limitada a 4 MiB/s y readback del dump desde Synology por Mac. Esta alternativa sustituye la preparación dependiente de pmx50; el contenedor y SQL siguen sin ejecutarse hasta acreditar inputs y aislamiento. El preflight detectó el enlace de sistema /home → /var/home de Bazzite; la preparación usa ahora la raíz canónica explícita sin relajar el rechazo de enlaces inesperados.

Ensayo DB-only, 01:18 CEST

Inputs acreditados en Bazzite y fuente publicada en 4e6a091. El primer intento pasó preflight, pero Podman rechazó uid=999 del tmpfs antes de crear el contenedor. La consulta independiente de existencia confirma ausencia; no hubo prueba kernel ni SQL ejecutado. Se preservaron work, log y resultado privados. El resultado inicial indica limpieza no verificada porque inspect no encontró objeto; no se presenta como un contenedor detenido.

Se prepara compatibilidad específica: --mount type=tmpfs con tamaño8MiB, modo3775 y U=true limitado a ese tmpfs nuevo. La documentación oficial de Podman describe ownership por usuario seleccionado en tmpfs. El bind privado pgdata con SELinuxZ y todos los límites permanecen iguales. Sin reintento automático.

Una consulta posterior de reloj y hardware a los tres boots sólo aporta inicialización informativa MCE; no registra firmas seleccionadas de salto de reloj o error MCE/EDAC/AER. No identifica una causa ni excluye fallo sin registro. No se modificó la configuración de pmx50.

La revisión añadió, exclusivamente para la variante Podman autorizada, una espera programática antes del entrypoint PostgreSQL: /bin/sh sólo espera una señal en un control privado, montado read-only y separado de pgdata. El ejecutor verifica argv, dos binds exactos y carpetas vacías, además de kernel/UID/GID; guarda y sincroniza kernel-proof antes de crear la señal0400. Así también initdb/bootstrap quedan después de la prueba, sin otro paso manual. Runner c52391e0…, plan d07b5f92…: 17 pruebas dedicadas locales pasan, incluida una espera real de shell con entrypoint sintético. No se inició otro contenedor durante esta validación local.

Segundo intento DB-only en curso, 01:26 CEST

Tras publicar 765dad4, el nuevo work0125 pasó la prueba del kernel: memory.max1073741824, memory.swap.max0, cpu.max50000/100000, pids.max128, networknone, rootfsRO, User999:999 y ambos mapeos UID/GID. Entrypoint y dos binds exactos comprobados, controlRO y pgdata vacío. Kernel-proof durable precede a la liberación del bootstrap; la restauración sigue en curso. Ningún contenedor de producción ni trabajo GPU participa. Resultado pendiente.

Resultado del segundo intento

La imagen arrancó su servidor temporal en /tmp, pero el cliente psql interno del entrypoint buscó el socket por defecto en /var/run/postgresql. Salió2 a las01:25:29, OOMfalse, antes de restaurar el dump. Kernel-proof y gate sí funcionaron: incluso la inicialización ocurrió después de su liberación. El runner cerró con stopped=true y cleanup_errors vacío. Se conservan work0125, prueba y logs privados; no se reinició el contenedor. Corrección mínima en fuente: ofrecer /tmp,/var/run/postgresql en el servidor, ambos dentro de tmpfs privados. Se descartó añadir sólo PGHOST: el entrypoint oficial vacía esa variable antes de llamar a su cliente interno; no se ejecutó ese arreglo insuficiente. 18 pruebas legacy y 17 de lifecycle pasan; pendiente revisión/publicación antes de nuevo intento.

Restauración PostgreSQL acreditada, 01:31 CEST

Tercer intento único en work0132, fuente 5bbc06c: exit0, status=db_restored. Conteos exactos: assets31595/photos10803/pics20792, content_sha1=10803 y path_sha1=20792. Dump SHA6c3b… e imagen769aa… verificados; prueba kernel y gate previo al bootstrap confirmados. Sin OOM, stopped=true, cleanup_errors=[]; SwapFree16.771.444.736 sin disminución. Postflight MemAvailable25.805.119.488, disco libre274.693.378.048 y presupuesto inputs+work1.943.101.440 bytes, sin blockers. Los intentos previos se conservan aparte y la reserva global de disco sigue holgada. No se reinició ni alteró PostgreSQL de producción.

restore_complete=false es la bandera global conservadora del runner: este resultado acredita DB-only, no restauración integral de Immich. Continúan originals_verified=false y coherencia pendiente. A las01:30:50 pmx50 mantiene bootdb3a862a y32min de uptime; no demuestra estabilidad futura.

Publicación diaria habilitada

Cambio transaccional aplicado desde e4d4cfb; la fuente y el runtime incluyen el mismo flag. ConfigSHA63af5296…, las18tareas restantes intactas, reloadrc0. RPC01:48:59 confirma healthy=true, scheduling_active=true y config_stale=false y siguiente originals11:10, Europe/Madrid. Estado de copias previo intacto; backup/rollback privado conservado. Detalle, límites y recuperación. La primera publicación natural y sus métricas continúan pendientes.

La fuente Ansible se reconcilió después con las19 tareas efectivas: imports literales de Gitstacks, routes antigua retirada y campos omitidos NAS conservados. Ocho pruebas pasan; render y runtime coinciden en todas las tareas y daemon mediante comparación en memoria. No se aplicó el role completo.

Última comprobación de ubicación y arranques, 01:55 CEST

Pmx50 conserva boot00:58 con56min de uptime. API desde pmx51 muestra28/28 ejecutándose, mismos8/20propietarios; el peer mantiene su boot anterior. No hay cuarto reinicio observado en esa muestra ni cambio de distribución. Esto no sustituye salud de cada aplicación ni resuelve el origen de los watchdogs.

Referencias NAS verificadas

Cotejo de31595/31595 sobre las generaciones19: photos10803/pics20792, cero faltantes o anomalías de tipo/UID/tamaño; raíces revalidadas. 72461operaciones y8FD, sin abrir archivos de fotos. Recibo privado8910d2a4… y reporte agregado con content/coherence=false. Prueba, límites y recibo. Se preparan hasta tres muestras de originales verdaderos para una fase separada, no para convertir esta cobertura de metadatos en una restauración integral.

Automatismos y fuentes: observaciones de las 04:47–04:51

La reconciliación de Git resolvió la divergencia que hizo fallar el autocommit de03:17: se conservaron el commit local y los cinco remotos en una fusión sin conflictos, con Gitleaks sin hallazgos. Mac/GitHub y VM208 avanzaron a master46d3b68 y después2d96e3d; checkout limpio y guard de ascendencia satisfecho. No se retiró la guarda, no hubo force y no se ejecutaron hooks o servicios. Los cambios frontend no están montados en el scanner vivo; no se reconstruyó su imagen.

La retención de ciclo de vida funcionó en horarios naturales: updater04:00 exit75 en35ms y watch04:45 exit75 en112ms. A04:48:44 RunWisp seguía healthy, con19 tareas y configuración cargada. El helper preparado para restauración incorpora la corrección probada en Linux: 72 pruebas de copia/publicación en3.10, otras72 en3.12 y16 de hold en3.12. No se ejecutó una restauración del hold. Docs ya usa acciones Node24 y runner Ubuntu24.04; run39353192722SUCCESS sin annotations.

Jev completó un ciclo natural04:39:22–04:40:32 con exit0 y worker91a329cc; esa versión todavía podía ocultar un fallo publicando métricas. La corrección PUT de fuente f23cbfa pasó CI39353213974 (164passed/1skip) y se instaló a 04:51:26 CEST: worker028d8703, preservando sólo el destino Jev del host, backup privado y CAS, compilación nativa3.13.5. Servicio inactivo antes y después; no se ejecutó el worker ni se dispararon merges de prueba. Su primer ciclo natural con el fix PUT queda pendiente.

A 04:48:39 CEST, pmx50 mantenía boot834ae68a y2h34 deuptime, con carga 0,91/0,99/1,09. No se observó un sexto reset; la causa de los cinco anteriores sigue pendiente. La térmica de pmx51 no se revalidó en esa consulta. No se reactivaron watchdog tuning, cambios de recursos, Meross/SAI ni cargas de prueba.

La muestra térmica posterior de04:54:02 registra pmx51 a70°C/load1 1,05 y1,27 eventos/s de throttling, con la alerta aún firing; pmx50 a48,875°C/load1 0,57 y sin serie de ese contador. El descenso respecto a03:02 no se atribuye al hold ni demuestra una causa de los resets.

Cierre de progreso: 07:05–07:09 CEST

La muestra pasiva de capacidad de07:06 conserva ambos boots: pmx50 lleva4h52min y pmx51 9h7min. Temperaturas CPU 48,875/80°C; tasa de throttles de pmx51 3,035eventos/s (5min), sin serie en pmx50. Frente a04:54, suben los valores puntuales de pmx51; no se atribuyen a una causa ni se certifica estabilidad o margen N-1. El informe conserva fechas, edad de muestras y límites; CT217 se revalidó en pmx51 antes de la consulta.

Las dos reglas PBS incorporadas al runtime conservan las87 previas, total89, con health=ok y dos evaluaciones distintas acreditadas. El seguimiento del ciclo natural confirma sync06:00–06:38:28 statusOK y checker07:00:31–07:00:32 RC0, sin dispararlos para probarlos.

Las guardas de preflight de Paperless y del owner del drill PBS quedaron publicadas en fuente, commits b9e4ca9 / 28e070e. CI39373278716 y39372960508 terminaron SUCCESS con tres jobs; son pruebas sintéticas, no una nueva restauración de datos ni despliegue de esos drills.

El fix de precisión del epoch (4e83af8, CI39373304025 SUCCESS) se instaló después, a 07:09:46,968 CEST, sólo en el helper de PBS, mediante reemplazo atómico con backup privado y compilación nativa3.13.5. No hubo ejecución, POST ni cambios del shim, contador, unidades o timer. El valor histórico redondeado de Pushgateway se conserva; acreditar el próximo export natural, previsto para21oct07:00, sigue pendiente. Recibos y recuperación en el informe del checker y el informe de sus reglas.

Jev completó un ciclo natural06:43:14–06:44:23, exit0, con el PUT guard instalado. La consulta07:05 observó last_run1792471463 y push_time1792471463.659143, coincidentes con su fin y posteriores a la instalación. Esto acredita publicación completa según ese código, no merge de una PR ni resolución del backlog. Prueba y límites canónicos.

Los dos README de stacks se reconciliaron en fuente ee092dd; VM208 hizo fast-forward a 07:07:55,905 CEST, tracked limpio. Quedó un aviso de permisos sobre wallet-signing privado, cuyo contenido no se inspeccionó ni se corrigieron permisos. Contexto de sincronización y límites. El hold de watch/update se mantiene: estos cierres no lo restauran ni cambian propietarios, programación o cargas.

Cierre de progreso: 07:52–07:56 CEST

La protección del ciclo de vida PBS quedó publicada en main 98d81f5, con50 pruebas locales e independientes y CI39377198784SUCCESS (Python3.10/3.12). El runbook sustituye el procedimiento VMID999 retirado y explica reservas retenidas, workers desconocidos y cancelación. Pmx50 convergió naturalmente al helper7e2c3fda a07:55; pmx51 seguía f7b4f654 en esa observación, pendiente del siguiente pull natural. Ningún restore nuevo.

Las tres correcciones de consola quedaron aplicadas selectivamente a CT212: estado manual no avanza si falla el guardado, Docker propaga error y Vera ya no oculta fallo remoto con tail. Fuentes main fcf3426/edf71bd, CI74pruebas correctas en3.12/3.14, instalación sólo app/tasks con backup privado y reinicio único de consola. Postcheck RUNS0/L0/sin recovery pendiente, hash e identidad de state.json intactos. Prueba y recuperación.

La observación pasiva07:53 conserva boots, con pmx50 5h39 desde último arranque. Pmx51 está a87°C y 7,322807eventos/s de throttling con alerta firing: sigue pendiente comprobar físicamente refrigeración/ventilación y aclarar los resets de pmx50. Las métricas PVE posteriores señalan CT100 como principal carga guest de ese instante, ≈1,43cores, sin demostrar causalidad. Se mantiene el hold de watch/updater y la suspensión de cargas pesadas, cambios de recursos y actualizaciones generales.

07:58 CEST — PBS convergido en ambos nodos. La lectura de pmx51 encontró helper7e2c3fda después de su pull natural07:55:59–07:57:15, success0. Se cierra la instalación del motor compartido, sin ensayo ni reconciliación forzada; la recuperación real con esa nueva versión sigue sin probarse.

Cierre de progreso: 08:17 CEST

El lector de informes de contratos ya rechaza vacío, contadores incoherentes y esquemas desconocidos. Checker y consumer de la skill comparten el contrato validado, con RC coherente y sin fallback al JSON bruto. Fuente main1758160, CI84+11 pruebas en3.10/3.12 correcto. Se instaló sólo el helper de VM208 y la copia local de la skill, con backups/CAS; no se regeneró el informe ni se ejecutaron jobs o sondas. El estado conserva fecha07:23, 2 fallos en Hunter/Scanner y29 pendientes. Los fallos son una diferencia de N8N_API_KEY, no un fallo funcional de autenticación acreditado.

El segundo runbook PBS de la navegación aún mostraba restores a998/999 y arranques anteriores al aislamiento, además de prometer un canario no implementado. Se retiraron esos ejemplos y se enlazó el motor validado. La arquitectura de agosto queda marcada como histórica; la navegación lleva al esquema fechado de servicios. No se ejecutó ninguna de las instrucciones retiradas.

La lectura de CT100 a08:01 ya no encontró el PID57081 de la muestra de carga. Otros procesos pertenecían a vera-upgrade-20261020.service, que a08:03 seguía active/running desde07:53:07. No se atribuye al proceso desaparecido ni a los87°C. Esa unidad y un archivo nuevo de Vera no proceden de esta ronda; se solicitó coordinación al usuario y se preservan sin modificar. No se ejecutan cambios de Vera mientras la operación ajena permanezca sin resolver.

Seguimiento pasivo20oct10:02 CEST

Una lectura porSSH de boot_id/uptime/loadavg y una consulta a métricas ya almacenadas, sin sondas ni operaciones de producto: pmx50 conserva boot , uptime7h48m28s; pmx51 conserva , uptime12h03m17s. No se observa un nuevo reinicio entre esas lecturas y las08:35; no se acredita su causa.

Prometheus10:02:12: ambosup1, muestras con unos12s de edad. CPU pmx50 49,25°C y throttling ausente/desconocido; pmx51 74°C y tasa5min10,8842eventos/s, CPUThrottling firing, CPUTempHigh no firing/pending. Frente08:35 aumentan temperatura71→74°C y tasa5,393→10,884eventos/s; no se atribuye a Vera ni a ninguna carga concreta. No hubo tuning, reinicios ni cambios de hardware.

Seguimiento pasivo20oct10:44–10:48 CEST

A10:44:40, originals_backup conserva próxima ejecución20oct11:10 en Europe/Madrid. RPC saludable, scheduling activo y configuración vigente;19tareas, flag de publicación activo y sin disabled explícito para originales. Los helpers backend4aeba3bd y publisher9063a799 coinciden con Git. Dump de hoy presente regular0600,183629054bytes y antigüedad9h12; sólo metadatos, sin leer contenido. Última ejecución terminó00:30:08,372 CEST con exit0; ledger generación19 con documents/proyectos/photos/pics completos, aún sin primera publicación last_success. Preparación local comprobada: no acredita el resultado futuro, espacio posterior ni conectividad NAS. No se adelantó la tarea ni se ejecutó el helper de métricas.

A10:48:28–41, ambos boot IDs siguen iguales a10:02; uptime pmx50 8h35m y pmx51 12h49m49s. Prometheus devuelve up1 en ambos, muestras de unos13s y sin warnings. CPU pmx50 48°C; pmx51 83°C frente74°C a10:02. En pmx51 la tasa5min de throttling sube10,8842→22,0035eventos/s y CPUThrottling sigue firing. En pmx50 sigue sin serie de throttling: desconocido. CPUTempHigh no aparece pending/firing en esa consulta. Load1/5/15 de pmx51:3,76/3,58/3,00. No se observa nuevo reinicio entre lecturas ni se acredita causa de la subida. Se mantiene el hold; no hubo cambios de CPU, cargas, aplicaciones ni Vera.

La lectura PVE /cluster/resources --type vm a10:51:08–10 devuelve20guests ejecutándose en pmx51, todos con CPU positiva. Estimación cpu×maxcpu total 0,5795cores; principales VM1710,3681, CT2170,0702, CT1000,0450, CT2180,0214, CT1100,0128. El endpoint no expone antigüedad de cada muestra; no es consumo instantáneo acreditado. Los endpoints nodales qemu/lxc previos devolvieron CPU0 en todos y no se usaron para inferir inactividad. Esta lectura modesta no explica por sí sola los83°C ni prueba causalidad; no se inspeccionó HA dentro del guest ni se modificó Vera o ningún invitado.

Muestra breve HOST10:52:23 (delta1,089s/4CPUs): CPUocupada49,88%, iowait8,55%, un procesoD. Nombres con consumo observado:kvm, MainThread, ansible-playboo, python3, promtail; nombres genéricos y agregados no identifican responsable ni autorizan intervenir. Observador incluido potencialmente en python3; no se leyeron cmdline/environ ni se entró en invitados. Nueva muestra Prometheus 10:53:03,864, edad4,196s, sin warnings:74°C y throttling5min9,22456eventos/s. Bajan ambas medidas frente10:48. Son intervalos distintos de las métricas PVE; no se resta guestCPU de hostCPU ni se acredita una causa térmica concreta.

Afinado posterior al ciclo11:10, hasta20oct12:13 CEST

Área	Aplicado y comprobado	Pendiente
Receptor Synology	Compatibilidad incremental GNU rsync instalada11:28; backup privado y compilación nativa.	Incremental real posterior.
CLI de copias	Ayuda y errores sin efectos; instalada11:51.	Seguimiento natural.
Histórico y antigüedad	Manifiestos antes de rollover11:54; inicio persistente12:07; último intento de publicación preservado12:13.	Primer rollover/reintento real; no se reconstruyó evidencia perdida.
Configuración de publicación	Lectura TOML estricta, directorio0755 conforme Ansible, métricas conocidas/habilitadas1 en ciclo natural12:10.	Adaptar alertas a intención configurada.
Docker	Alerta de publicaciones atrasadas instalada11:29,90reglas correctas y dos evaluaciones naturales.	Seguimiento de incidentes reales.
OnePacerr	ESTALE demostrado; cierre sin drenaje y posible importación independiente identificados.	Reparación controlada y recuperación NFS selectiva segura.

Backend actual81481eb, main30cd7c5, CI39406236074 correcta:56tests backend, 17configuración y38receiver porPython3.10/3.12, además de las suites existentes. Los13archivos de estado y configRunWisp f7b3 permanecen idénticos; no se lanzaron copias, publicador ni cambios de generación como prueba. Se conserva el hold de actualizaciones/recreaciones generales. Las intervenciones de control y monitor fueron acotadas con respaldo y CAS; Vera sigue fuera de este trabajo paralelo.

Alertas de publicación aplicadas20oct12:22–12:23 CEST

Failed/Stale evalúan la intención configurada y la nueva advertencia distingue configuración desconocida/ausente de desactivada; el requisito de primer éxito conserva todos sus campos. Fuente mainff9a090, CI39406961586 y lint39406961491 correctas;15tests Python y17escenarios Promtool. Instaladas91reglas sin reinicio, recarga200 e inodo/permisos conservados, con respaldo privado. Dos evaluaciones naturales muestran91healthok y4reglas de publicación inactive/sin errores; OriginalsCopyFailed sigue firing. Observación natural del backend12:20:01: colección1/proceso0/configuración conocida1/habilitada1. No se ha relanzado copia.

Japón: fuentes y pruebas corregidas20oct12:53 CEST

Trip-planner publica en master a24997b cuatro parches de dependencias: Sharp0.35.5 en servidor y herramientas del Worker, fast-copy4.1.0 y source-map-js1.2.2. Wrangler4.151.2 aporta su árbol compatible de Miniflare; sin overrides ni actualización general. Node-forge sigue pendiente por falta de parche publicado; no se descarta el aviso. Versiones, fuentes y límites.

La CI anterior se detenía en frontend. La reproducción completa descubrió59 fallos tras retirar el bloqueo inicial; fixtures de tipos de cambio sin fecha, mocks obsoletos, acciones asíncronas y pases archivados por la fecha de ejecución. Las correcciones conservan los contratos actuales sin cambiar código de producto, skips, timeouts ni umbrales. Resultado local integrado Node24.19.0:165archivos y 1707pruebas correctas con cobertura, lint, TypeScript y build Vite correctos. Revisión independiente por agentes. Seis renderizados sintéticos y protocolo Worker con60mensajes/cupo50 también pasan; cero fetch externo del Worker. Estos fixtures se añaden como puertas de CI antes de construir la imagen.

La ejecución Linux39411090038 a12:58 acredita lint, test (frontend y Worker) y test-server correctos; la construcción de imagen falló después: falta server/lib/walletNavigation.ts en los COPY de la etapa frontend. No se publicó la imagen de ese run. La corrección del empaquetado se publica en master 9531fb7: contexto reducido real antes falla por TS2307 y después pasa TypeScript/Vite; la CI Linux39412033062 termina SUCCESS a13:08: lint, frontend/Worker, servidor y build/publicación de imagen correctos. No se desplegó la aplicación en el homelab. El SBOM de GitHub ya recoge Sharp0.35.5 en ambos árboles, fast-copy4.1.0 y source-map-js1.2.2; la API de avisos todavía mantiene abiertos los cinco. No se declara cierre automático hasta observar su estado actualizado. No se desplegó la aplicación ni el Worker, no se leyeron datos personales, no se firmaron pases ni se enviaron notificaciones/correos. El push puede publicar una imagen en DockerHub si pasa la CI; el hold de actualizaciones runtime sigue vigente. El checkout del usuario se conserva intacto.

La guía de copias de Japón ya recoge el manifiesto actual415archivos,285fotos; la restauración de esa generación y recuperación de claves Wallet/DO/R2 siguen pendientes. Los parches de fuente no acreditan que la imagen desplegada use las dependencias nuevas.

Watchdog: evidencia retenida del pulso revisada20oct12:58 CEST

La lectura pasiva de dos registros existentes del peer encuentra59pulsos de pmx50 recibidos02:12:15–02:13:13, con uptime creciente, 50s después de la última recepción del journal_stream. No equivale al journal local, retenido hasta02:12:42. Se separó el pulso posterior al cuarto arranque para no mezclar estadísticas PRE/POST. El primer evento queda fuera de la cobertura de los archivos actuales.

En el quinto segmento se observa más presión IO que en los anteriores, CPU muestreada53–60,5°C y PSI de memoria full0; ninguna de esas muestras identifica la causa ni excluye un fallo brusco posterior. Sin nuevos datagramas, sensores, instrumentación, cargas o cambios de configuración. Revisión independiente correcta; hold y políticas conservados.

Verificación de cierre de esta tanda: Trip-planner master9531fb7, CI39412033062 completa correcta, imagen publicada. La documentación infra previa db91818 también terminó correctamente. Consulta puntual de estado Docker13:06:22CEST: trip-planner running, restart_count0, sin acreditación funcional de aplicación. No se cambia el hold ni se declara recuperado el problema de watchdog.

Cobertura de dependencias revisada20oct14:04 CEST

GitHub confirma ahora como fixed los cuatro avisos de Japón corregidos antes: Sharp125/124 (Worker/servidor), fast-copy123 y source-map-js121, con cierre13:31CEST. La observación API14:01 mantiene sólo node-forge122 abierto sin parche publicado; Braces146 de infraestructura también sigue sin parche. Stacks devuelve cero avisos abiertos, sin que eso audite las imágenes desplegadas.

La PR53 es un lote separado de Dependabot de268actualizaciones, abierto y sin fusionar en la lectura14:00: CI39415602012 falla por3errores de lint y1prueba TripList con timeout; build omitido. No es un fallo nuevo de master9531fb7 ni autoriza incorporar el lote o saltar CI. No se modificó esa PR, sus pruebas ni el runtime.

El fork propio monxas/media-ai-homelab tenía las alertas deshabilitadas. Tras verificar permiso admin e identidad se habilitaron sólo mediante un PUT oficial 14:03:23–25:204 y GET posterior204. Las correcciones/PRs automáticas continúan enabled=false; no se modificó el upstream ni se accedió a GPU/servicios. README y reversión publicados en main propio, avance FF y checkout limpio. No hay workflows propios versionados. GitHub ejecutó automáticamente su análisis dynamic/dependabot/update-graph: 39419416428, correcto14:05:07 sobre3e0a4a8; no se despachó ninguna CI ni proceso GPU. SBOM14:04:14 contiene28dependencias más el repo, incluidos los4pins CUDA; alertas14:03:45 devuelve0abiertas. No prueba completitud transitiva ni ausencia de vulnerabilidades en paquetes instalados/modelos. Recibo privado de la única mutación SHA256 <REDACTED>.

Revisión de fuente20oct14:32 CEST

El backend de originales8581a6dc corrige una carrera reproducida con dos procesos: el fallo se persiste bajo el flock original antes de que otro propietario pueda entrar.58tests backend,14capacidad,17configuración y46publicador correctos en validación local y revisión independiente. Todavía no se ha instalado este candidato: fuente y límites.

La lectura nativa acotada de PVE14:17 encontró0trabajos en pmx50 y14en pmx51, todos con StateOK/FailCount0. No acredita RPO ni recuperación. La fuente del colector corrige el silencio ante un error de pvesr, mantiene los otros dos segmentos y añade éxito/frescura por nodo. Helper308f39d4:25fixtures locales, 34pruebas del rol; nueva alerta con14escenarios promtool y92reglas válidas. El preflight permitió comprobar formato y la cuenta prometheus legítima, sin publicar métricas ni iniciar jobs. Diseño, pruebas y límites. Instalación y evaluaciones naturales pendientes de CI y verificación separada.

La observación Prometheus14:04:50 conserva CopyFailedfiring por documents, PBSDataReserveLowpending por archive y CapacityCollectorinactive. Muestra PBS 14:00:01: archive186,35GiB disponibles de1510,82GiB(12,33%); main155,50GiB de 475,54GiB. No se borraron generaciones, ejecutaron prune/GC ni ampliaron discos.

El informe guardado validado13:23 confirma2fallos de compose.environment en Hunter/Scanner, ambos por N8N_API_KEY, y29pendientes; es anterior al despliegue OOM/contador y no se presenta como primera colección natural posterior. Se conservan los fallos reales sin allowlist ni recreación bajo el hold. El índice Lidarr ya distingue ruta corregida17septiembre de importación real sin ensayar, sin revalidar hoy el producto. El análisis OnePacerr incorpora tres reproducciones de riesgos de drain y un diseño completo; no hay endpoint de pausa ni transición sin pérdida del proceso actual acreditados.

Protecciones instaladas20oct14:41 CEST

Área	Hecho y evidencia	Lo que queda pendiente
Originales	Backend8581a6dc instalado14:40:11; comprobado14:40:51, 13estados y RunWisp intactos en dos lecturas. Corrige la carrera de fallo entre dos propietarios del lock.	Siguiente incremental real tras el fallo11:10 y primera publicación diaria Immich; sin relanzar manualmente.
Replicación PVE	Helper308f39d4/wrapperb733a08f comprobados en ambos nodos; cron intacto. Ciclo natural14:40 con colección válida,0trabajos en pmx50 y14OK/FailCount0 en pmx51.	La colección no prueba RPO, recuperación ni estabilidad física.
Alertas	Regla de colección/frescura añadida;92reglas nativas válidas y saludables en dos evaluaciones naturales. Recarga200 sin reinicio; nueva regla inactive.	Última observación de copias14:04 conservaba CopyFailedfiring y reserva PBSpending; esta instalación no las resuelve ni revalida.
CI/Git	Fuente en main, copias39423177307/Ansible/docs correctos; Docker39423911108 correcto tras adelantar instalación Jinja2/PyYAML al discovery.	No equivale a actualización de aplicaciones desplegadas.
Seguridad	Cuatro avisos de Japón confirmados fixed; alertas del fork propio media-ai activadas y documentadas en su main, sin PRs automáticas.	node-forge122/Braces146 sin parche observado; SBOM no audita todos los paquetes instalados.
Recuperación	Plan OnePacerr y tres reproducciones offline publicados, con conservación de estado y bootstrap pendientes explícitos.	Reparación de ESTALE retenida; no existe drain seguro acreditado del proceso actual.

Instalación/recuperación de originales y colector/alerta PVE registran hashes, recibos privados y rollback manual. pmx se instaló una vez; pmx2 abortó sin escribir porque ya tenía ambos candidatos desde14:38. Se verificó ese estado en vez de reintentar o adjudicar su autoría a Ansible sin evidencia.

Sin ejecuciones manuales de copias/publicadores/replicación/restore, role apply completo, reinicios ni cambios de hold. Vera sigue siendo trabajo paralelo del usuario. Continúan abiertos: causa de los cinco resets pmx50, refrigeración de pmx51, restauración completa Immich, autonomía SAI/Meross y verificaciones funcionales/acceso/recuperación que los contratos mantienen como no verificadas.

Nueva evidencia20oct14:51–14:52 CEST

La observación Prometheus14:51 muestra un boot distinto en pmx50. La lectura nativa14:52:30 confirma btime1792496118,20oct13:35:18CEST, bootcff5c198 y4632s encendido. Es otro arranque posterior al conocido02:13; todavía no se clasifica como watchdog ni parada ordenada sin revisar el registro correspondiente. Evidencia nativa privada SHA256 <REDACTED>. No se levantan las retenciones ni se atribuye causa por coincidencia temporal.

Muestra Prometheus14:51: ambos nodos up1; boot/up/temperatura con edades reales 15s(pmx50)/0,6s(pmx51). CPU47,875/82°C; pmx51 conserva su arranque19oct21:58:51 y throttling4,1614eventos/s en5min, contador1088474 y0resets del contador en esa ventana. pmx50 sin serie de throttling: desconocido. Las tasas PSI disponibles sugieren presión IO en pmx51, pero no se acreditó la antigüedad individual de sus muestras; no se usan para atribuir causa. La consulta inicial devolvió422 por una colisión de etiquetas al usar timestamp sobre varias familias; la consulta se corrigió tras reproducción local, sin tratar el error como caída de infraestructura. No se añadieron colectores, cargas, instrumentos o probes. Proyección privada68bcad36; interpretaciónf7527e0d.

El primer informe natural de contratos posterior a las guardas está fechado14:23:03,970:11contratos/2fallos conocidos/29pendientes. Estado y contador de reinicios11PASS; todos los contadores0. No expone OOMKilled explícito ni hash del productor: no se usa como prueba autónoma de la guarda OOM.

La revisión offline del publicador encontró una colisión de identidad entre el mismo dump y referencias de originales distintas. Candidato de formato v2 en implementación y revisión, sin instalar ni ejecutar. Las generaciones existentes se conservan; no se cambia el calendario ni la exigencia de la primera publicación diaria. Las siguientes decisiones runtime quedan sujetas además a la revisión de este nuevo arranque.

Revisión15:06 CEST: watchdog y sincronización Git

La cronología del arranque adicional13:35 separa las observaciones PRE/POST y acredita bootstatus32 más el código 0x02000800 del arranque nuevo. Es compatible con el mecanismo watchdog; la causa sigue sin identificarse. La última actividad retenida de Ansible-pull previa al corte no acredita ejecución de un rol ni causalidad.

Existe otra avería verificable y posterior: Ansible-pull de pmx50 falló14:45 al hacer fetch, con objeto Git vacío e index-pack inválido, antes de ejecutar el playbook. pmx51 completó su ciclo14:53–14:54 correctamente. Se prepara una revisión acotada del checkout afectado; no se ha hecho fetch, reparación ni role apply manual. No se borra o sustituye un checkout sin conservar su estado.

El arreglo de identidad del publicador está en main3c662710, candidatoa3acd931, sólo fuente, sin instalar ni publicar datos. CI Linux Python3.10/3.12 39426607588 correcta:55tests publisher por versión,58backend,17configuración y14capacidad, sin skips en ese bloque Linux; también pasan los jobs de receptor, PBS y promtool. Documentación39426607659 publicada correctamente. V2 liga la identidad al contexto inmutable completo, conserva v1 local válido y rechaza manipulación antes del canal remoto; no acredita coherencia con originales, deduplicación global ni recuperación real.

Nuevo reinicio confirmado15:11:50 CEST

Informe completo del evento y límites.

La lectura nativa15:12:55 registra btime1792501910 y bootdecded74, uptime65,6s. Evidencia privada SHA256 <REDACTED>. Revisión independiente15:14: kernel actual con firma explícita hardware watchdog timer expired, hex0x02000800 y bootstatus32. El journal previo termina15:11:00,697; el pulso del peer continúa hasta15:11:24. Temperatura CPU última47,4°C, MemAvailable13880MiB, lag0,01s; no identifican la causa ni el último keepalive. No aparecen filas de Ansible en la ventana15:09–15:11:50; su fallo Git anterior no debe presentarse como causa de este reset.

Antes de este último evento, el mapa actualizado observó28invitados running y reparto8/20 a15:06, sin cambios de propietario respecto12:25. Docker15:10:90contenedores,47running/42exited/1created, 26proyectos. Los13cambios running→exited no se clasifican automáticamente como averías ni se despiertan servicios. Esas muestras no acreditan el estado posterior al nuevo arranque y no se extrapolan a recuperación de aplicaciones.

El inventario de la caché Git está completo a las15:12: 32 objetos loose vacíos entre 4897 entradas; todos disponen de bytes verificados en el repositorio Mac y son alcanzables desde main3c662710 ya publicado. Ése fue el estado previo al plan acotado, aplicado después a las15:19:51 y verificado15:21. No se ejecutó fetch, reset, reclone, playbook ni cambios de timer.

Recuperación Git15:19–15:21 CEST

Procedimiento, respaldo y límites:32objetos vacíos sustituidos por sus bytes Git verificados y publicados, sin refs/index, árbol de trabajo, fetch, reset, timers o role apply. Posverificación32/32 correcta y conectividad Git offline rc0. En esa fase se conservaron los 16 archivos tracked modificados, clasificados a las 15:25 como regulares vacíos. La fase posterior se detalla abajo. No hay despliegue del publicador v2 ni prueba real de copias, y la causa de los resets sigue abierta.

Restauración de la caché15:34–15:37 CEST

Se restauraron 16 archivos vacíos, 270382 bytes, desde los blobs del HEAD e índice ba701c46 existentes: no se mezclaron versiones de main ni se cambiaron refs, índice, packs, helpers instalados, servicio o timer. Respaldo privado y recibo durable conservan la evidencia previa y el estado histórico files_restored_integrity_pending; no se reescribió ese recibo.

La posverificación independiente15:37 comprobó 16/16 archivos y sus hashes; Git 2.47.3 devolvió conectividad offline rc0 sin salida y status rc0 con cero registros tracked/untracked en alcance normal. No verifica todos los blobs, todos los descendientes untracked ni salud física. El siguiente pull natural sigue pendiente y los resets no están resueltos. core.fsync y core.fsyncMethod no estaban configurados: su evaluación de durabilidad pendiente no ha aplicado cambios ni protege por sí sola el árbol de trabajo.

Primer pull natural recuperado15:50–15:51 CEST

La invocación natural posterior a las reparaciones terminó15:50:51 con rc0: 71ok, cero cambios, fallos e inalcanzables, 17 tareas omitidas. HEAD y origin/main en a98a9ad, status normal limpio y mismo boot decded74 en la lectura15:51:02. El timer sigue activo; no hubo arranque manual. Esto sustituye la espera indicada en las fases previas, pero no resuelve los watchdog ni acredita todas las aplicaciones. El endurecimiento fsync continúa en revisión local sin aplicación, y el publicador v2 sigue retenido.

Durabilidad Git aplicada por el helper: 16:55 CEST

El intento único de las 16:55:07 terminó SSH rc0 y installed_local_config_verified: sólo agregó core.fsync=all y core.fsyncMethod=fsync al config local de la caché de Ansible. Respaldo y recibo privados quedaron conservados. La lectura independiente de las 16:56:01 CEST confirmó bytes, fundamento, cinco perfiles protegidos y metadatos de 30 packs sin cambios. No se ejecutó Ansible ni se modificaron unidades o timers. Es una mejora de durabilidad Git, no una corrección del watchdog: la causa de los reinicios continúa abierta y la persistencia del checkout no está probada.

Trip-planner: PR53 fusionada20oct16:51 CEST

La PR53, pendiente en la observación14:00 anterior, se fusiona a16:51:49CEST mediante merge normal y comprobación del head exacto 68a594e; sin admin, bypass ni force. GitHub confirma master b1c9047, con padres 9531fb7 y 68a594e. No se modifica el checkout compartido ni se ejecuta despliegue, recreación o acceso a datos de la aplicación.

La CI de la PR39441565883 termina correcta: lint, servidor, frontend y construcción. Frontend conserva 165 archivos/1707 pruebas y el protocolo Worker usa sólo fixtures, con external_fetches=0. Se corrigen tres diagnósticos lint mediante un alias de ref y el orden de declaración de un estado, sin cambiar carga ni votación. TripList reproduce antes el timeout y pasa después esperando interacciones async con act, sin retirar assertions ni ampliar5000ms: 4722ms en Linux. El margen es reducido; una ejecución verde no demuestra estabilidad temporal bajo cualquier carga. El servidor completa sus fixtures en9s; seis marcadores literales identifican cada invocación, sin shell tracing ni imprimir entorno. La cancelación histórica de diez minutos no vuelve a ocurrir, pero su causa no queda demostrada retrospectivamente.

El diff final respecto de master anterior contiene los cuatro manifests originales de la PR y cinco archivos de corrección/documentación. Hay36rangos directos cambiados (23frontend/13servidor), ningún salto major estable directo y dos saltos pre1 (@anthropic-ai/sdk0.39→0.133, sin uso encontrado en TS, y eslint-plugin-react-refresh0.4→0.5). Los saltos de ubicación de paquetes en locks no equivalen por sí solos a cambios del mismo consumidor. Se conservan source-map-js1.2.2, Sharp0.35.5 en servidor/Worker y fast-copy4.1.2. La revisión de fuente y CI no acreditan dependencias o funcionalidad desplegadas.

La CI normal de master39443118320 se inicia automáticamente sobre b1c9047 y termina fallida: lint correcto, frontend con 1706 correctas y el mismo timeout5000ms de TripList, servidor cancelado al límite de diez minutos y construcción omitida. No publica imagen ni se ejecuta despliegue. El último marcador real del servidor es calendario 16:52:21.894740CEST; después constan PASS16:52:22.547051 y cierre de DB 16:52:22.556185, sin llegar al marcador de importación. Esto acota el bloqueo al cierre/salida de ese proceso, pero no identifica aún su recurso retenido. Treinta ejecuciones locales aisladas terminan correctamente; no reproducen el entorno Linux de CI. Log privado servidor SHA256 <REDACTED>, frontend <REDACTED>. El árbol Git es idéntico al de la PR verde (<REDACTED>): la variabilidad y el bloqueo siguen abiertos. No se relanzan jobs ni se amplían timeouts. Recibo privado de merge SHA256 <REDACTED>; inventario de dependencias <REDACTED>.

Trip-planner: PR54 fusionada y CI de master verificada

La PR54 se fusiona17:29:21CEST en 75a3b35. La CI combinada39447661927, head 905b273, termina correcta en lint, frontend, servidor y construcción. Conserva 165 archivos/1707 pruebas; catálogo3994ms y compartido994ms, sin ampliar5000ms ni retirar assertions. Calendario registra cierre del servidor, DB y temporal; pasa al siguiente fixture en0,710s, sin activarse el diagnóstico unref de cinco segundos. El diagnóstico sólo cuenta tipos de recursos y fase, sin handles, rutas ni entorno. Esta pasada no demuestra corregido el bloqueo intermitente histórico ni garantiza margen temporal bajo cualquier carga.

La CI posterior de master39448873360 también termina correcta en sus cuatro jobs sobre 75a3b35: 165/1707, catálogo2226ms y compartido498ms. El artefacto coverage-report existe y no está expirado; el log confirma restauración de caché npm y exportación de caché GHA en construcción. BuildKit registra push completado de latest y sha-75a3b35, ambos con digest sha256:<REDACTED>. Es evidencia de publicación del workflow, no una lectura independiente del registry ni de la imagen desplegada. No se recrea ni se prueba la aplicación; no cambian el hold ni las políticas de runtime.

Proof privado combinado SHA256 <REDACTED>; logs de master frontend <REDACTED> y build <REDACTED>. La PR55, de referencias SHA y permisos de Actions, se fusiona a las 17:41:21 CEST en be43c24; su CI39449323906 sobre ae83b0a termina correcta en sus cuatro jobs: 165/1707, catálogo3854ms y compartido1005ms. El artefacto de cobertura, restauración npm y exportación de caché GHA pasan; no constan errores de permisos. La construcción usa push:false y no publica manifest. Log frontend SHA256 <REDACTED>; build <REDACTED>. La fuente fija 13 referencias de ocho acciones, desactiva credenciales persistidas en los cuatro checkouts y limita el token a contents: read. La CI posterior39450735724 termina correcta sobre be43c24 en sus cuatro jobs, con el token limitado a contents: read: 165/1707, catálogo3188ms y compartido813ms. El artefacto de cobertura existe y npm restaura su caché; la exportación GHA de BuildKit termina sin errores de permisos ni warnings. El workflow registra publicación completada de latest y sha-be43c24, ambas con digest sha256:<REDACTED>. Es publicación de imagen, no despliegue ni comprobación funcional de la app; no se relanza la CI manualmente ni se toca runtime. Recibo privado SHA256 <REDACTED>; log build <REDACTED>.

Protocolo incremental GNU validado en CI: 17:48 CEST

PR74/CI39451463152 validó GNU rsync real con --link-dest PATH, contenido, hardlink reutilizado y generación previa conservada:39 tests del receptor y12 de recuperación sin omisiones en Linux Python3.10/3.12. Integrado en main a6184354… a las17:48:40. Alcance y evidencia. Es una ampliación de pruebas sobre temporales locales; no ejecutó copia al NAS, publicador, job o cambio runtime. La deuda de primera publicación sigue separada.

Loki y continuidad nativa: 17:56–17:58 CEST

La consulta histórica acotada a Loki revalidó CT217 en proxmox2 y Loki ya activo en 3101. Devolvió 92 coincidencias del selector exacto de pmx50, todas con fechas posteriores al btime de las 15:55:04. No hay cobertura PRE conocida: no se interpreta cero coincidencias previas como ausencia de fallos ni se atribuye la causa a categorías nvme/watchdog. Sólo se conservaron hashes, categorías y timestamps; ningún mensaje crudo.

La muestra nativa de las 17:58:32 conserva boot 248d8d61… y uptime 7408,36 s. La unidad Ansible registra ciclo natural 17:54:45–17:55:31, rc0 y Result=success, inactive/dead y MainPID=0. No se leyeron recap, Git, configuración ni aplicaciones. Son observaciones fechadas, sin nuevos jobs o cambios de servicio; la causa de los reinicios sigue abierta. Los hashes de ambas proyecciones privadas constan en el informe enlazado.

Instalador manual Promtail y plan Alloy: 18:12 CEST

La PR75 se fusiona a las 18:11:58 CEST en <REDACTED>. Corrige el creates que impedía reemplazar un binario de versión distinta ya existente. El instalador valida SHA256 del ZIP oficial y versión antes de sustituirlo, con staging privado, respaldo, reemplazo atómico y notificación al handler. Ambas ejecuciones de lint, PR39454953383 y rama39454928524, terminan correctas. Los seis casos Ansible sintéticos pasan en ejecución del agente y repetición independiente: instalar, actualizar, segunda aplicación, versión incorrecta, check mode y checksum incorrecto. Los rechazos conservan bytes/inode y no notifican reinicio; checksum incorrecto evita ejecutar candidato.

El play conserva promtail,never, la versión fuente3.6.10 y el handler existente. No se aplica el rol, no se descarga el ELF upstream ni se contactan agentes, Loki o productos. /ready anterior al handler no acredita el proceso posterior. El plan de equivalencia con Alloy registra labels, ventanas journal12h/24h, cursores, ficheros, timestamps y corte con un escritor por flujo. Es documentación, no conversión o migración aplicada; Promtail sigue fuera de soporte y la causa del watchdog sigue abierta.

La publicación documental39454513640 sobre 405b429 terminó correctamente, incluida compilación estricta y despliegue. Ese resultado corresponde al paquete previo de evidencia PBS/Loki/GNU; no se atribuye a documentos incorporados después.

Pulso remoto PRE del reset15:55 recuperado:18:17 CEST

La lectura acotada del receptor existente recupera67 pulsos PRE hasta15:54:37, unos9,19s después del último journal local; 16 POST separados por caída de uptime. Acredita progreso del emisor, no del watchdog-mux/HA ni causa del reset. Sin nuevas sondas o cambios runtime.

Readiness Promtail corregida y copias observadas:18:20–18:22 CEST

La PR76 se fusiona18:21:20 CEST en <REDACTED>, después de ambas CI lint correctas (PR39456378060, rama39456346682) y revisión independiente. El play dedicado ahora vacía sus handlers pendientes antes de /ready: un fallo de reinicio aborta antes del GET y --check omite la consulta al proceso antiguo. Cinco casos Ansible sintéticos, repetidos por root, comprueban orden anterior, orden correcto, reinicio fallido sin GET, apply sin cambios sin reinicio y check sin GET/reinicio. No se modifican handlers, versión, posiciones o hosts; conserva never. HTTP200 no acredita ingesta. Si el rol se reutiliza en un play con otros handlers, hay que revisar ese alcance.

Cinco consultas a métricas existentes a las18:20:08, tras resolver CT217 en proxmox2, mantienen la deuda operativa: publicación known/configured_enabled=1, last_success=0, sin progreso activo y Required firing; ninguna copia activa, documents failed=1 y CopyFailed firing. Archive186,353GiB/12,3346% y reserva baja; main155,369GiB/32,6815%. El scrape tiene3–14s, pero las observaciones originals/capacidad son de18:15:01 (308s), no una ejecución nueva del productor. Sync conserva check/collection=1, failures=0, publicación07:00:32 y gauge latest_completed06:20:00. Es el redondeo ya diagnosticado, no otro sync: el historial acreditó fin06:38:28; la corrección instalada espera la siguiente publicación natural, sin POST manual. Scrape reciente no acredita sync nuevo ni sustituye las evidencias fechadas de tareas. La serie NAS cacheada marca D-state1/16, up=1 y degradación activa: no se contactó al NAS ni se verificó su salud global. No se disparan copias, restore, colector o limpieza a partir de estas alertas. Proyección privada0600 ~/.local/state/backup-cached-state-20261020-vykt84fq/projection.json, SHA256 <REDACTED>.

Contratos Hunter/Scanner: deriva confirmada, 20 de octubre a las 18:27 CEST

El informe natural de las 18:23:03 conserva las dos diferencias de N8N_API_KEY. Una lectura selectiva posterior acredita presencia no vacía en Compose y contenedores, pero valores distintos; no son credenciales ausentes ni un fallo de mapeo. La fuente Stacks b1ae78c ya declara la máscara vacía, aún sin convergencia runtime acreditada. Se mantienen el checker y el hold: ninguna recreación, prueba de autenticación ni llamada a N8N. Comparación de secretos sólo en RAM y evidencia minimizada en el diagnóstico canónico de contratos.

Consola aplicada y CI Promtail Linux cerrada:20oct18:40 CEST

Consola: PR1 de homelab-maint fusionada9616b37,81 pruebas correctas en Linux3.12/3.14 antes y después del merge; app-only aplicada18:39, verificación independiente18:40 correcta. No hay tareas ni recovery pendientes; no se ejecuta una acción real como prueba. Estado y17 logs preservados. No se habilitan transiciones bloqueadas.

La PR77 de infra se fusiona 18:32:23 en <REDACTED>. La CI39458015775 y CI posterior39458338221 terminan correctas: lint más seis fixtures binario y cinco readiness en cada Python3.12.15/3.14.8 Linux, controlador ansible-core2.21.5 y PyYAML6.0.3 fijados. No se despliega Promtail ni se instala su ELF; son flujos Ansible locales reales sobre archivos sintéticos y HTTP loopback. Los intérpretes son de CI, sin nuevo requisito añadido al Python de Proxmox.