Automatización de diapositivas de sermones

Actualizado el 16 de agosto de 2026.

Consulte Alertas del flujo de trabajo del portal enfocado para obtener supervisión automatizada de fallos, frescura, notificaciones y recuperación.

El Portal River Oaks acepta cargas de diapositivas de sermones versionadas de Keynote. Almacena el original en la Unidad Compartida de Google configurada y en una caché segura del servidor, lee datos de texto y objetos directamente del paquete de Keynote y copia los bytes exactos del original a la Mac de diapositivas de adoración con un reconocimiento SHA-256. La representación de Keynote y el OCR no son la fuente del texto del sermón.

Destinos de grupos de carga

Los administradores del portal gestionan el almacenamiento y la automatización en Personal → Diapositivas de sermones → Administrador → Configuración de grupos de carga. Una regla de campus/servicio contiene los IDs de la Unidad Compartida y la carpeta raíz, la disposición de carpetas y controles independientes para tercios inferiores automáticos, la colocación en listas de reproducción semanales, la copia en la computadora de adoración, las vistas previas renderizadas y el despliegue iniciado por el administrador. Las credenciales de Google permanecen en el archivo de entorno seguro; la base de datos almacena solo los IDs de enrutamiento y el comportamiento.

Grupo	Disposición de almacenamiento	Tercios inferiores automáticos	Despliegue manual
Goshen / Servicio Dominical	`Sermon Slides/YYYY/Series`	Sí, incluyendo lista de reproducción semanal y vistas previas	Sí
Español / Servicio Dominical	un archivo actual en `Mensajes`; archivos anteriores en `Archive/YYYY/Series`	No	Sí
Otros grupos sin regla	Jerarquía de Unidad heredada configurada	No	Sí

Para un destino de archivo actual, el nuevo Keynote se carga antes de que los archivos .key actuales más antiguos se muevan al archivo. Las imágenes y los archivos no relacionados no se mueven. Un fallo es visible; el flujo de trabajo nunca elimina el archivo anterior.

Límites de carga del navegador y fiabilidad de la ingesta

portal.ro.church es proxy por Cloudflare. La documentación de Cloudflare indica que las zonas Gratuitas y Pro aceptan como máximo un cuerpo de solicitud de 100 MB, por lo que el portal no debe anunciar el límite de almacenamiento de backend de 250 MiB como un límite de carga del navegador. La aplicación establece por defecto SERMON_SLIDES_EDGE_MAX_REQUEST_BYTES en 100 000 000 bytes y reserva al menos 1 MiB para metadatos multipart. La página de carga muestra la asignación restante combinada de Keynote más notas, valida cada archivo seleccionado y su tamaño combinado antes de enviarlo, y utiliza el menor de esa asignación y los límites de archivo de la aplicación.

La ruta del sermón posee dashboard/v2/sermon-slides/.user.ini; su upload_max_filesize y post_max_size deben aceptar la solicitud completa segura del borde. La página compara los valores activos de PHP antes de mostrar el formulario. El monitor de flujo de trabajo de cinco minutos verifica de forma independiente los límites de ruta confirmados contra el entorno seguro. Una regresión bloquea el formulario y genera upload_runtime_limit_invalid antes de que un pastor seleccione un archivo. Un rechazo de ingesta escribe sermon_slides.upload_intake_rejected solo con el ID de la solicitud, el código de error PHP limitado, los recuentos de bytes, los límites y la duración, nunca un nombre de archivo o contenido del sermón.

El 16 de agosto, tres intentos a las 15:23, 15:24 y 15:28 llegaron a Nginx y PHP, y luego devolvieron HTTP 303 después de aproximadamente 0,18 segundos de trabajo de PHP. La página anunciaba 250 MiB mientras que el límite de PHP heredado del panel era de 10 MiB. No se inició ningún registro de carga, escritura en Drive ni trabajo de procesamiento. El límite limitado, la prevalidación del navegador/tiempo de ejecución, el evento de rechazo estructurado y el monitor de verificación son los controles permanentes para esa clase de incidente. La telemetría retenida de 2026 contiene 45 versiones cargadas distintas con datos de tamaño; la más grande es de 26 986 174 bytes (25,74 MiB), y ninguna se acerca al límite seguro del borde.

Biblioteca del portal y metadatos del sermón

La biblioteca de sermones mantiene la búsqueda como control principal. Los filtros de campus, servicio, orador, serie, estado y fecha permanecen disponibles en Más filtros y se mantienen cerrados hasta que un operador los necesite. Los valores del orador deben ser metadatos explícitos del sermón; nunca se asume que el cargador conectado es el orador. Una presentación histórica sin evidencia nombra a su orador como Orador no registrado. Los manifiestos de importación pueden suministrar un orador verificado, pero el operador de importación histórica no debe ser escrito en ese campo.

Las etiquetas de versión del portal y los nombres de archivo generados recientemente usan v1, v2, etc. Los objetos de Drive existentes con nombres anteriores rellenados con ceros no se renombra porque su identidad de archivo inmutable y sus enlaces siguen siendo parte del historial de auditoría.

Flujo de trabajo de tercios inferiores

Los tercios inferiores automáticos solo se ejecutan para Goshen / Servicio Dominical:

El código determinista identifica las diapositivas fuente de punto, Escritura, en blanco e con imágenes.
El texto se divide en los límites de versículo, oración y frase bajo los límites explícitos de línea y carácter del tema mapeado. El texto nunca se trunca.
La VM crea una presentación nativa de ProPresenter utilizando la instantánea inmutable del tema mapeado a la serie del sermón.
El receptor restringido de broadcast-gfx reemplaza la presentación estable exacta ya guardada en la lista de reproducción administrada, verifica los recuentos de texto y diapositivas ordenados, y genera una imagen de vista previa por cada diapositiva generada.
Las sumas de verificación de vistas previas, la identidad del contenido renderizado y la identidad de la lista de reproducción deben coincidir antes de que el trabajo esté listo.

Antes de la división de las Escrituras, el generador elimina solo artefactos de texto deterministas de Keynote: líneas solo de puntuación, períodos de artefacto inmediatamente antes de un número de versículo, falta de espacio entre un número de versículo y su texto, puntuación duplicada después de una comilla de cierre y un número de versículo final que no tiene texto de versículo. También vuelve a unir una referencia de versículo de dos dígitos inequívoca dividida entre ejecuciones nativas, como 18:1 9-20 que se convierte en 18:19-20. La extracción inmutable aún conserva la redacción original de la fuente para revisión por IA/humana. El generador no verifica la ortografía, parafrasea, sustituye una traducción de la Biblia ni aplica silenciosamente correcciones inciertas.

El receptor compara cada imagen renderizada con la identidad de texto generada para esa diapositiva. ProPresenter puede devolver brevemente una miniatura en caché obsoleta después de una importación. Si se devuelven imágenes idénticas para diapositivas con texto diferente, el receptor recupera el conjunto completo nuevamente con un retraso limitado. El intento continúa solo después de que cada diapositiva de texto diferente tenga una representación verificada distinta; ocho intentos fallidos fallan cerrados con propresenter_render_content_mismatch antes de la colocación en la lista de reproducción.

Después de la recuperación, una revisión determinista independiente del tema compara las diapositivas de punto renderizadas entre sí y las diapositivas de Escritura renderizadas entre sí. Detecta valores atípicos de diseño de material, regiones de tema faltantes y representaciones duplicadas exactas con texto generado diferente. Estas verificaciones no infieren ni reescriben el contenido del sermón. El modelo visual asesor luego revisa cada diapositiva renderizada con su texto de diapositiva fuente y sus vecinos generados inmediatos para ver si hay recortes, tipos pequeños, colocación inconsistente, saltos incómodos y errores de secuencia.

Cada intento captura su contrato de entrega requerido en sermon_slide_processing_runs: broadcast-gfx, lista de reproducción semanal, copia de adoración y publicación de vistas previas. Los informes de notificación utilizan esa instantánea inmutable. Un cambio posterior en el entorno, el cambio de nombre de la lista de reproducción o un cambio en la regla del grupo de carga no deben reinterpretar una ejecución anterior como recién exitosa o fallida.

Iniciar un nuevo intento borra los campos mutables de trabajo y reconocimiento de entrega del intento anterior. La generación, la entrega de broadcast-gfx, la entrega de adoración y la publicación de vistas previas registran sus propios resultados verificados a medida que se completan. Si una etapa posterior falla, el informe final puede enumerar con precisión lo que se completó durante el intento actual sin tomar prestado el éxito obsoleto de un despliegue anterior.

Las cargas de Español y Eventos Especiales se almacenan y copian en la computadora de diapositivas de adoración sin generación automática de tercios inferiores. Un administrador puede elegir Desplegar tercios inferiores en el portal. Esa decisión manual se registra en la carga útil del evento y ejecuta el flujo de trabajo completo de verificación de broadcast-gfx.

El receptor de broadcast-gfx verifica si ProPresenter se está ejecutando. Una actualización de presentación estable semanal se realiza solo mientras ProPresenter está cerrado. Si ya hay una sesión de operador abierta, el receptor la deja intacta y devuelve propresenter_active_stable_update_deferred; el trabajador reintenta esa demora segura hasta 12 intentos limitados durante aproximadamente cuatro horas. Cuando la aplicación está cerrada, el receptor reemplaza atómicamente el archivo de biblioteca estable, inicia la aplicación firmada configurada, espera su proceso y API, y aplica un intervalo mínimo de calentamiento antes de la verificación. La API debe identificar la versión exacta de la aplicación configurada; un ayudante de red huérfano de un proceso anterior de ProPresenter no se acepta como prueba de que la aplicación recién iniciada está lista. El receptor solo cierra la instancia del proceso que la automatización lanzó.

Presentación administrada estable

El receptor posee una posición de presentación configurada en la lista de reproducción de broadcast-gfx. El punto final PUT /v1/playlist/{playlist_id} de ProPresenter 19.0.1 no es una interfaz de almacenamiento duradero en producción: devuelve éxito y expone el nuevo elemento a través de la API en vivo, pero el archivo de lista de reproducción guardado no cambia y un reinicio restaura el elemento anterior. Enfocar la lista de reproducción primero y extender la espera no hace que esa actualización sea duradera.

Por lo tanto, la producción nunca cambia el puntero de la lista de reproducción durante una carga. El instalador del receptor registra el UUID exacto de la presentación, el nombre de visualización y la ruta de la biblioteca que ya están guardados en la ranura administrada. La VM genera cada mazo semanal con la misma identidad de presentación. Mientras ProPresenter está cerrado, el receptor almacena una copia última conocida como buena en Library Backups, reemplaza atómicamente el archivo de biblioteca exacto, inicia ProPresenter y verifica todo lo siguiente antes de confirmar la entrega:

la aplicación configurada y la versión de la API están activas;
la ranura de lista de reproducción guardada aún se resuelve al UUID de la presentación estable;
la ruta de la presentación estable, la identidad del texto ordenado y el recuento de diapositivas coinciden;
cada diapositiva generada tiene una miniatura con representación verificada;
los elementos fuera de la posición de la lista de reproducción administrada no han cambiado.

La ruta de archivo exacta es parte de la identidad de la biblioteca guardada de ProPresenter. Cambiar solo el UUID interno de la presentación mientras se renombra o mueve el archivo hace que el elemento de lista de reproducción guardado quede huérfano. Renombre la presentación estable solo como una acción de mantenimiento deliberada de la interfaz de usuario de ProPresenter de una sola vez, luego vuelva a ejecutar el instalador del receptor y actualice las variables no secretas de UUID/nombre estable de la VM.

Si la verificación falla después del reemplazo, el receptor cierra solo su propio proceso de ProPresenter y restaura atómicamente el archivo último conocido como bueno. Un fallo de reversión se expresa como propresenter_stable_rollback_failed. Un puntero guardado inesperado falla cerrado como propresenter_playlist_slot_changed; la automatización no lo reescribe. Corrija la ranura guardada o la configuración del receptor y utilice el botón Redeploy de la versión existente. Un fallo de Mac o de lista de reproducción no requiere otra carga del pastor.

El incidente de carga 47 del 14 de agosto estableció este comportamiento. Tres despliegues limitados llegaron a la generación y al reconocimiento de la lista de reproducción en vivo, pero el almacén de la lista de reproducción nunca cambió. Un _River Oaks Automation Canary aislado reprodujo la sesión PUT y el reinicio de reversión sin tocar la lista de reproducción dominical en vivo. Una segunda prueba aislada demostró que el reemplazo del archivo estable de ruta exacta cargaba el nuevo contenido de 21 diapositivas después de un inicio limpio mientras el puntero del canario guardado permanecía intacto. Renombrar ese mismo archivo dejó huérfana intencionalmente la referencia del canario y confirmó por qué es necesaria la estabilidad de la ruta; el canario se restauró entonces.

La preparación profunda debe verificar el puntero estable guardado, la ruta exacta de la biblioteca, el inicio de la aplicación, la identidad de la API, los temas compatibles y la capacidad de representación. No debe mutar ni la lista de reproducción dominical en vivo ni una lista de reproducción sintética, ya que el mismo reconocimiento de API de sesión solamente crearía un resultado verde falso.

El receptor restringido se despliega independientemente de la raíz web del portal. Instale el scripts/sermon-propresenter-receive.py revisado exacto en broadcast-gfx utilizando un reemplazo atómico, conserve el ejecutable anterior como copia de reversión, compare SHA-256 antes y después de la activación, y ejecute la verificación de compilación de Python antes de volver a desplegar un sermón.

Retención en la computadora de adoración

Google Drive y la caché segura de la VM siguen siendo el archivo. El receptor dedicado de la Mac de adoración conserva solo las dos fechas de sermón distintas más recientes entre las copias de Keynote administradas por el portal. Su configuración segura puede establecer un valor de 1 a 12 en la segunda línea; una línea ausente tiene un valor predeterminado de dos.

La retención se ejecuta solo después de que se ha recibido y verificado el SHA-256 de un nuevo archivo. El receptor registra la ruta relativa, la fecha del sermón y el resumen esperado en un registro privado. Elimina un archivo más antiguo solo cuando esa ruta registrada exacta sigue siendo un archivo regular y su resumen actual aún coincide. Los archivos no rastreados, los archivos modificados por el operador, las filas de registro inválidas y las rutas fuera del destino dedicado se conservan. Los receptores aceptan tanto el protocolo de fecha completa actual como el protocolo heredado solo de año mientras se actualizan los trabajadores de producción; un nombre de archivo estandarizado suministra la fecha de retención para una entrega heredada.

Recuperación Wake-on-LAN

Wake-on-LAN es un paso de recuperación opcional para las dos Macs de entrega de sermones. Está deshabilitado por defecto y debe permanecer deshabilitado hasta que se haya verificado la dirección MAC de la interfaz cableada y la ruta de difusión VLAN para ese dispositivo administrado exacto. Nunca derive una MAC de una dirección IP arbitraria ni copie una de una entrada de inventario no verificada.

El trabajador utiliza esta secuencia:

Ejecute la sonda health de comando forzado del destino a través de SSH anclado al host.
Si el receptor está listo, omita el encendido y continúe. Si SSH es accesible pero el receptor no está saludable, omita el encendido porque un paquete mágico no puede reparar la configuración o el almacenamiento del receptor.
Solo cuando SSH no sea accesible y el encendido esté habilitado, envíe un paquete mágico UDP estándar a la MAC permitida y la dirección de difusión privada. Una verificación SQL deduplica las solicitudes por dispositivo y ejecución de procesamiento.
Sondee el receptor restringido hasta que informe que está listo o que el tiempo de espera limitado expira. Un paquete enviado nunca es un reconocimiento de entrega.
Al agotar el tiempo de espera, conserve el reintento limitado normal, el correo electrónico de fallo, el hallazgo del administrador, el evento de Loki y el comportamiento de rastreo de Tempo.

La configuración pertenece solo al archivo de entorno seguro:

SERMON_SLIDES_BROADCAST_GFX_WAKE_ENABLED, _MAC, y _BROADCAST;
SERMON_SLIDES_WORSHIP_WAKE_ENABLED, _MAC, y _BROADCAST;
SERMON_SLIDES_WAKE_TIMEOUT_SECONDS, SERMON_SLIDES_WAKE_POLL_SECONDS, y SERMON_SLIDES_WAKE_DRY_RUN.

Valide cada objetivo primero con scripts/sermon_slide_wake.py --target broadcast_gfx --dry-run o --target worship_slides --dry-run, ejecutado como la cuenta de trabajador con el entorno seguro cargado. Dry-run analiza la lista permitida y construye el paquete exacto de 102 bytes pero no abre ningún socket. El monitor normal de cinco minutos informa sobre la configuración habilitada mal formada antes de una carga.

Las direcciones de difusión privadas esperadas actuales son 10.200.21.255 para broadcast-gfx y 10.200.5.255 para diapositivas de adoración solo si esas redes se confirman como /24. Los enrutadores comúnmente bloquean las difusiones dirigidas entre VLANs. Antes de habilitar cualquier objetivo, demuestre que el paquete de la VM del portal llega a esa VLAN; no debilite la política de difusión del enrutador solo para que la prueba pase. Si se requiere un ayudante local, debe exponer los mismos dos alias fijos y ningún destino de paquete arbitrario.

En cada Mac, use la interfaz cableada, habilite Wake for network access en System Settings, mantenga Ethernet conectado y pruebe el estado de suspensión compatible real. El despertar de la suspensión es el caso de aceptación requerido; no se asume que funcionen el apagado completo, la pérdida de energía, el despertar solo por Wi-Fi, el prearranque de FileVault y los estados específicos del firmware. Registre la MAC de la interfaz verificada sin colocarla en el repositorio o en los registros.

La reversión es solo de configuración: establezca ambos valores ENABLED de wake en 0 y reinicie el trabajador de ProPresenter aplicable. No se requiere ningún cambio en el receptor o la entrega. Solucione problemas de *_wake_config_invalid como configuración segura, *_wake_send_failed como la ruta de difusión de la VM/red, y *_wake_timeout como la energía de la Mac, Ethernet, configuración de energía o inicio del receptor. Los eventos de auditoría no contienen contenido y utilizan solo los alias broadcast_gfx o worship_slides.

Imágenes de Keynote

El extractor inventaría los objetos de imagen de Keynote específicos de la diapositiva independientemente del texto del documento. Registra la diapositiva fuente, el estado de materialización, el tipo de medio, las dimensiones y el resumen SHA-256 para cada activo legible. Los bytes de la imagen nunca se tratan como texto de tercio inferior y no se procesan a través de OCR. Esto evita inventar silenciosamente palabras a partir de arte decorativo, capturas de pantalla o fotos.

Las diapositivas con imágenes siguen estas reglas de revisión deterministas:

Una diapositiva con texto de documento e imágenes genera tercios inferiores solo del texto del documento. El inventario de imágenes permanece disponible para revisión.
Una diapositiva con imágenes pero sin texto de documento se marca explícitamente como una diapositiva solo de imágenes. No puede convertirse silenciosamente en un tercio inferior en blanco o inferido.
Una imagen referenciada que no se puede materializar y verificar mediante hash es un hallazgo de revisión explícito. No pasa silenciosamente la verificación de imágenes.
Las imágenes nunca cambian su estado de preparación por sí solas a menos que falle una etapa determinista requerida. El hallazgo de revisión indica a un humano lo que la salida de tercios inferiores solo de texto no puede representar.

El arte de plantilla repetido se clasifica de forma conservadora a partir de metadatos nativos, sin reconocimiento de imágenes ni OCR. El mismo hash de imagen materializado debe aparecer en al menos la mitad del mazo, en al menos tres diapositivas, y junto al texto del documento nativo en al menos una diapositiva. Solo entonces se oculta de la lista de revisión específica de diapositivas. Un activo repetido que aparece solo en diapositivas solo de imágenes sigue siendo contenido de revisión significativo. Los activos ilegibles o no verificados también permanecen visibles y producen un hallazgo explícito. Esta regla solo cambia el ruido de la revisión; nunca agrega, elimina ni edita texto de tercios inferiores.

La auditoría del corpus heredado del 12 de agosto de 2026 proporcionó la evidencia faltante de activos repetidos. Cuarenta y siete de las 48 mazos de 2025 disponibles se analizaron, cubriendo 808 diapositivas fuente. Veinte mazos contenían imágenes: los 124 activos nativos se materializaron y verificaron mediante hash, sin activos no disponibles. Se presentaron cinco grupos de activos repetidos. Cuatro activos idénticos aparecieron en 17-24 de casi todas las diapositivas de su mazo junto con texto y se clasificaron como arte de plantilla; un activo se repitió en tres diapositivas solo de imágenes y permaneció en el conjunto de revisión humana. La validación de candidatos en esas cinco mazos anónimas confirmó la regla antes del lanzamiento. Un mazo heredado devolvió el error de compatibilidad limitado parser_output_missing y sigue siendo un seguimiento separado; no detuvo ni contaminó la cohorte.

Pruebas de sistema históricas

Ejecute scripts/sermon-slide-history-test.py contra un corpus limitado de Drive antes de cambiar la extracción, la división, los límites de ajuste o la generación nativa de ProPresenter. El arnés de generación utiliza el mismo perfil de ajuste seguro predeterminado que la producción: cuatro líneas/180 caracteres para puntos y dos líneas/136 caracteres con un ancho de envoltura de 68 columnas para Escritura. El perfil de Escritura es la opción intermedia de una comparación de 15 mazos: mejora materialmente el tamaño del tipo sin el aumento del recuento de diapositivas más grande del candidato más agresivo. Un perfil fuera de los límites aceptados del generador debe fallar cerrado.

La auditoría previa al lanzamiento del 11 de agosto de 2026 ejerció 31 mazos de servicio únicos de 2026: 544 diapositivas fuente de Keynote generaron 1205 tercios inferiores, los 31 mazos pasaron, y los 10 activos de imagen referenciados en siete diapositivas con imágenes se materializaron y verificaron mediante hash. Seis diapositivas fuente eran solo de imágenes y, por lo tanto, requerían revisión humana. Ninguna imagen fuente estuvo no disponible. Este corpus es evidencia de regresión, no prueba de que cada estructura o diseño visual futuro de Keynote sea compatible; conserve la revisión de la hoja de contacto para nuevos patrones de imágenes y cambios de tema.

Agregue --deliver --retrieve-previews cuando la prueba de aceptación deba ejercer la Mac. La entrega es solo de biblioteca a menos que el trabajador normal requiera explícitamente la lista de reproducción semanal administrada. El arnés recupera el paquete de vistas previas limitado del receptor, verifica cada JPEG numerado contra su manifiesto y el resumen de representación combinado, y registra el recuento de vistas previas y el resumen del manifiesto. El directorio de salida debe permanecer debajo de la raíz de salida segura de ProPresenter configurada.

El control de calidad histórico no debe publicar vistas previas, enviar correos electrónicos ni llamar a la IA por defecto. Ejecútelo a través de un servicio transitorio de mínimo privilegio que cargue el archivo de entorno seguro coincidente a través de systemd, no al obtener ese archivo como un script de shell. Utilice un directorio de descarga temporal modo-0700, devuelva solo resultados agregados, elimine las copias de mazo/representación de la VM al salir y elimine o mueva los archivos de biblioteca QA HISTORY - a la Papelera recuperable después de que ProPresenter se cierre.

La auditoría de entrega con imágenes del 11 de agosto seleccionó cinco mazos del corpus de 31 semanas. Las cinco llegaron al estado listo: 83 diapositivas fuente generaron 169 tercios inferiores, las 169 vistas previas se recuperaron y validaron mediante hash, los diez activos de imagen fuente se materializaron y ninguna diapositiva de imagen estuvo no disponible. ProPresenter volvió al estado cerrado, la lista de reproducción administrada no cambió, los medios temporales de la VM se eliminaron y cinco archivos de control de calidad se movieron a la Papelera. Esto demuestra la recuperación determinista de la representación; no reemplaza la aprobación humana de la hoja de contacto de tipografía, espaciado y ajuste específico del tema.

Para una ejecución de aceptación histórica a nivel de portal, utilice la herramienta sermon-slide-history-import.php con dry-run primero. Deduplica por ID de Drive y SHA-256, atribuye las notificaciones de prueba a un usuario explícito del portal y está limitada a desarrollo. Los eventos importados llevan trigger_mode=historical: los mazos de Goshen pueden ejercer la generación, la importación de biblioteca, las vistas previas de representación, la entrega de adoración, el registro, la revisión de IA y ambos correos electrónicos, pero no pueden ingresar ni reemplazar la lista de reproducción semanal administrada. La CC del informe de producción histórica se suprime para que el destinatario de prueba explícito sea el único destino de correo electrónico. Volver a ejecutar un manifiesto es idempotente.

La copia de seguridad administrada del 11 de agosto reconcilió 39 Keynotes de Goshen sin procesar en 36 versiones de sermón únicas después de excluir dos mazos solo de bautismo y un duplicado byte a byte idéntico. La recuperación de Español encontró seis Keynotes semanales del 5 de julio al 9 de agosto; cinco mazos anteriores se restauraron en Mensajes/Archive/2026, mientras que el archivo del 9 de agosto permaneció actual. La cohorte combinada del portal contiene 42 versiones.

La aceptación final del portal completó las 42 versiones sin un fallo terminal: 36 versiones de Goshen alcanzaron ready y seis versiones de Español alcanzaron solo almacenamiento stored. El sistema extrajo 753 diapositivas fuente, creó y verificó remotamente 1453 tercios inferiores, publicó las 1453 imágenes de vista previa y copió las 42 mazos fuente al destino de diapositivas de adoración. Se enviaron los 84 correos electrónicos específicos del destinatario. Las ejecuciones exitosas promediaron 89.411 segundos (0.327 segundos mínimo y 215.780 segundos máximo), 16 intentos fallidos se recuperaron a través de reintentos limitados, y las llamadas de IA de informes de producción costaron $0.049437 en total. Las ejecuciones históricas intencionalmente no modificaron la lista de reproducción semanal administrada. Los mapeos de temas temporales de control de calidad se desactivaron después de la ejecución de aceptación.

Notificaciones y límites de IA

El cargador y el personal de producción reciben correos electrónicos separados y rastreados de forma independiente. El cargador recibe una confirmación deliberadamente simple de que el Keynote está almacenado de forma segura en el portal y Google Drive, un enlace a la nueva versión y una breve lista de preocupaciones concretas de ortografía o Escritura si se encontraron. Nunca expone el estado del ordenador posterior, ProPresenter, lista de reproducción, vista previa, reintento, recuperación, temporización, costo o fallo de despliegue. La producción posee esos detalles operativos y hace seguimiento con el pastor solo cuando la acción humana es realmente necesaria.

El personal de producción recibe el nombre del cargador conectado, el estado de despliegue, los recuentos de origen/generado/diferencia, el tiempo de procesamiento, los recibos de ambos ordenadores, la verificación de la lista de reproducción y las vistas previas, los hallazgos de revisión, los detalles de fallo limitado y el costo de la IA. Una carga de versión dos o posterior crea una nueva revisión y nuevas notificaciones específicas del destinatario, al igual que la primera carga.

El almacenamiento, el hashing, la extracción de Keynote, la división, el formato, la entrega, la colocación en lista de reproducción y el estado de aprobación/fallo son código determinista. La IA no puede modificar palabras, diapositivas o estado de preparación. Una revisión de IA limitada se almacena con el informe de producción y se reutiliza para el mensaje del pastor para que los dos correos electrónicos no tengan doble costo.

La preparación requiere cada etapa determinista marcada como requerida por esa ejecución. Una notificación processing_ready no puede anular un estado de ejecución de procesamiento fallido o un reconocimiento requerido faltante. El mensaje de producción enumera cada verificación determinista fallida, su detalle seguro, el código de error técnico limitado y las etapas que se completaron antes del fallo. Evite frases genéricas como "la revisión de producción no finalizó" cuando el sistema conoce la etapa exacta.

Si la revisión de IA asesora no está disponible, la preparación determinista del despliegue no cambia. La confirmación del pastor sigue siendo simple y no inventa una advertencia de revisión. El informe de producción registra la disponibilidad y el costo de la revisión sin convertir un despliegue determinista exitoso en un fallo.

La validación de las Escrituras nunca se basa en la memoria del modelo. YouVersion proporciona NIV con licencia para la revisión en inglés y NVI-S para Español. API.Bible proporciona texto oficial NLT cuando una diapositiva en inglés cita explícitamente NLT. El portal recupera solo el pasaje citado, informa el uso de FUMS requerido y mantiene la respuesta en una caché privada que normalmente se actualiza después de siete días y nunca sirve contenido más antiguo de 30 días. Una vez configurado API.Bible, un pasaje en inglés sin etiqueta también se establece por defecto en NLT; sin el proveedor con licencia, se establece por defecto de forma segura en NIV.

La página del administrador de diapositivas de sermones debe mostrar la atribución del proveedor La verificación de NLT es proporcionada por API.Bible. New Living Translation © Tyndale House Foundation. con API.Bible enlazado a https://api.bible/. Mantenga este aviso en la superficie del administrador; no agregue texto legal de licencia a las confirmaciones del pastor ni a los correos electrónicos semanales ordinarios de producción.

La comparación exacta de la redacción de NLT es código determinista. Ignora solo mayúsculas, puntuación, espacios en blanco y diferencias de números de versículo inofensivas, y luego registra una coincidencia exacta, un extracto exacto, texto fuente insuficiente o una diferencia de redacción. El texto con licencia de API.Bible nunca entra en indicaciones de IA, SQL, registros, correos electrónicos, diapositivas generadas o rastreos. La IA solo ve hechos de resultados limitados y puede indicar a un humano que verifique una discrepancia; no puede inferir ni suministrar redacción de reemplazo. Si API.Bible no está disponible, la revisión es visiblemente parcial y recurre a NIV solo para referencias normalizadas y la identidad de pasajes amplios. La redacción inter-traducción, la gramática, la puntuación y las pequeñas omisiones o adiciones nunca se informan como errores de NLT. La verificación de las Escrituras aún se ejecuta cuando la IA está deshabilitada o no está disponible.

Registro operativo

SQL es el registro operativo duradero. sermon_slide_processing_runs conserva una fila por intento de generación/despliegue con modo de activación automático/manual/solo almacenamiento, inicio, finalización, duración, resultado, código de error limitado, recuentos de diapositivas y reconocimientos del ciclo de vida de ProPresenter. También captura si ese intento exacto requirió entrega broadcast-gfx, colocación en lista de reproducción semanal, copia de adoración y publicación de vistas previas renderizadas.

sermon_slide_processing_events es el libro de contabilidad de etapas de solo anexión. Registra transiciones iniciadas, completadas, omitidas, programadas para reintento, en espera y fallidas para la ingesta del portal, el almacenamiento seguro en caché, Google Drive, la conversión de notas, la extracción de Keynote, la selección de tema, la generación de tercios inferiores, broadcast-gfx, diapositivas de adoración, verificación de representación, publicación de vistas previas, revisión de IA y cada notificación por correo electrónico. La revisión de Escrituras tiene su propio evento con recuentos sin contenido para pasajes verificados, comparaciones exactas de NLT, diferencias de redacción, aciertos de caché, reversiones y falta de disponibilidad del proveedor. Cada fila puede incluir un número de intento, milisegundos transcurridos, destino lógico, código de error limitado, contadores de lista permitida y costo de IA. Nunca almacena texto de sermón o diapositiva, nombres de archivo, rutas locales o remotas, direcciones de correo electrónico o cuerpos, indicaciones o respuestas de IA, cargas útiles del proveedor, claves de API, detalles de SSH o credenciales.

Dos identificadores conectan el flujo de trabajo:

sermon_slide_uploads.upload_uuid es el ID de correlación para toda la versión, comenzando con la carga web y continuando a través de cada reintento.
sermon_slide_processing_runs.run_uuid identifica un intento exacto de generación y despliegue. Un reintento recibe un nuevo UUID de ejecución pero conserva el mismo ID de correlación de carga.

Cada carga también tiene un valor requerido source_environment de development o production. El tiempo de ejecución confiable del portal registra ese valor durante la ingesta. Cada consulta de extracción, ProPresenter, notificación, salud del administrador y alerta enfocada filtra por él. Esto evita que los dos portales compitan por una fila de cola compartida o envíen un informe de producción a través de credenciales de desarrollo, aunque ambos entornos utilizan la misma base de datos. Las filas heredadas tienen por defecto production; no cambie ese valor predeterminado sin una migración de datos revisada.

Las filas de cola, los trabajos, los artefactos de entrega y las notificaciones conservan los registros del estado actual. No deben tratarse como el registro histórico porque los reintentos actualizan esas filas en su lugar. El contenido completo de la revisión de IA permanece en el JSON del informe seguro.

Los fallos de entrega transitorios utilizan un máximo limitado de tres intentos con un retraso seguro entre intentos. Los eventos de reintento registran si el error era reintentable, si la decisión era terminal y el retraso del próximo reintento. Los fallos de configuración y seguridad de la lista de reproducción, como un cambio en la ranura de la lista de reproducción administrada, se detienen inmediatamente y alertan a un operador; tocar repetidamente una ranura de lista de reproducción inesperada no es seguro. Cada reintento recibe un nuevo UUID de ejecución mientras conserva el ID de correlación de carga.

El diario de systemd es un rastro corto limitado. Puede incluir identificadores de carga/ejecución, etapa, estado, intento, duración, destino lógico, contadores y códigos de error seguros, pero no debe imprimir valores de entorno, texto de diapositiva fuente, rutas, cuerpos de respuesta del proveedor, contenido de correo electrónico, indicaciones o credenciales. Las líneas del diario utilizan correlation_id=<upload UUID> y, después de que comienza la generación, run_id=<run UUID> y trace_id=<run UUID sin guiones>.

Vista de operaciones del portal

Los administradores pueden usar Personal → Diapositivas de sermones → Administrador para una vista de preparación Este domingo más una descripción general de salud de siete días. La vista dominical encuentra el próximo Servicio Dominical de Goshen más cercano y muestra la carga de Keynote de la última versión, la extracción, el tema de la serie, la representación de broadcast-gfx verificada, la posición de la lista de reproducción semanal guardada, el recibo de la Mac de adoración, las vistas previas de Drive y el informe de producción. También muestra la frescura de la prevalidación de la plataforma y la prueba del sistema histórico diario. El estado general es Esperando carga, Procesando, Aplazado de forma segura, Necesita atención o Listo para el domingo; un esquema de observabilidad faltante falla cerrado como Datos de preparación no disponibles.

La descripción general de siete días utiliza el último resultado de cada carga: ejecuciones actuales, resultados exitosos, fallos no resueltos, intentos de reintento recuperados, tiempo promedio de ejecución y costo de IA. La sección colapsada Fallos no resueltos enlaza solo a las cargas cuya última ejecución sigue fallando; los intentos fallidos anteriores que luego se recuperaron no hacen que el panel actual parezca poco saludable. En una página de sermón, expanda Registro de procesamiento debajo de una versión para ver el historial completo de reintentos etapa por etapa, números de intento, tiempos transcurridos, destinos, costo, UUID de ejecución y código de error seguro exacto. La línea de tiempo solo es visible para los usuarios con sermon_slides.manage.

Registros centrales y rastreos de extremo a extremo

La auditoría SQL del portal sigue siendo autoritativa. La observabilidad central agrega dos vistas de diagnóstico sin convertirse en una dependencia del procesamiento de sermones:

Portal Alloy lee solo los ocho diarios de trabajadores de sermones y los envía a Loki con etiquetas de baja cardinalidad environment y component.
Un trabajador de telemetría separado reconstruye un rastreo OTLP por intento de procesamiento completado a partir de los eventos SQL confirmados. Central Alloy lo recibe en la red privada y lo envía a Tempo.
El panel de Grafana Diapositivas de sermones — Fiabilidad muestra resultados recientes, fallos, reintentos de exportación de rastreos y registros combinados de trabajadores. Un trace_id en una línea de Loki enlaza con la cascada de Tempo correspondiente.

El ID del rastreo es determinista: run_uuid en minúsculas sin guiones. El span raíz de Tempo es sermon_slides.workflow; los hijos incluyen extracción, selección de tema, generación, entrega broadcast-gfx, verificación de representación, colocación en lista de reproducción, entrega de adoración, publicación de vistas previas, revisión de IA y entrega de notificaciones cuando esas etapas se ejecutaron. Por lo tanto, el rastreo puede responder qué etapa se ejecutó, cuánto tiempo tomó, qué reintento tuvo éxito y si cada reconocimiento requerido se completó.

El exportador utiliza sermon_slide_trace_exports, una cola duradera de una fila por ejecución. Espera hasta que la ejecución y sus notificaciones pendientes se asienten, utiliza un tiempo de espera OTLP corto y reintento exponencial limitado, recupera reclamos interrumpidos y marca la exportación como fallida solo después de doce intentos. Nunca cambia una carga, trabajo, artefacto de entrega, notificación o resultado de preparación. El monitor de flujo de trabajo enfocado alerta cuando una exportación falla o permanece retrasada más allá de la ventana de ejecución obsoleta, y envía recuperación después de que la cola se vacía.

Los atributos de rastreo se restringen a identificadores de ejecución/carga, disparador y estado, etapa/intento/duración, destino lógico, código de error seguro, recuentos de diapositivas, requisitos de destino, indicadores del ciclo de vida de ProPresenter, contadores de revisión de Biblia seguros y costo de IA. Nunca agregue texto de sermón, nombres de archivo, rutas, IDs de Drive, direcciones o cuerpos de correo electrónico, metadatos de pastor/serie/título, indicaciones, respuestas del proveedor o credenciales.

La configuración de tiempo de ejecución de API.Bible vive solo en el entorno seguro del portal: SERMON_SLIDES_API_BIBLE_ENABLED, SERMON_SLIDES_API_BIBLE_API_KEY, y SERMON_SLIDES_API_BIBLE_NLT_ID. La clave se envía solo en la cabecera api-key. El SERMON_SLIDES_BIBLE_CACHE_DIR opcional debe ser una ruta privada absoluta; de lo contrario, el trabajador utiliza ${SERMON_SLIDES_CACHE_DIR}/bible-passages con directorios 0700 y archivos 0600. Nunca pegue credenciales en tickets, Notion, documentación, commits de GitLab, registros o salida de shell.

En Loki, comience con:

{job="sermon-slides", environment="production"}

Filtre una ejecución sin convertir el ID del rastreo en una etiqueta:

{job="sermon-slides"} |= "trace_id=REPLACE-WITH-32-HEX-TRACE-ID"

En Tempo Explore, busque:

{ resource.service.name = "riveroaks-sermon-slides" && resource.deployment.environment = "production" }

La ventana de exportación histórica predeterminada es de 30 días y está limitada de 1 a 400 días. Una interrupción de LGTM pone en cola la evidencia localmente; nunca debe hacer que una carga de pastor o una entrega de Mac fallen.

Monitoreo preventivo de preparación

El monitor enfocado de cinco minutos ahora valida el servicio alrededor de cada carga, no solo los fallos después de una carga. Verifica el estado del trabajador, la base de datos/esquema, la capacidad de escritura y capacidad del almacenamiento seguro, la configuración de notificación, las reglas de destino activas, el tiempo de ejecución/espacio de trabajo de conversión de notas, el permiso de Google Drive para agregar hijos, los hashes de tema inmutables y los contratos de salud restringidos en ambas Macs de diapositivas. Las sondas ordinarias no abren ProPresenter ni mutan los archivos de sermón.

Un canario profundo de producción solamente, de jueves a domingo, genera una presentación nativa sintética a través del generador real y el tema activo, y luego solicita al receptor de broadcast-gfx que valide el lanzamiento de ProPresenter, la API/versión, los temas compatibles, la resolución de la biblioteca y la ranura de la lista de reproducción administrada sin importar ni cambiar nada. Una sesión de ProPresenter ya abierta se deja abierta; una abierta por el canario se cierra después. El último resultado profundo debe permanecer más fresco que 30 horas.

Un canario histórico separado agrega cobertura de mazo real. A las 03:15 America/Indiana/Indianapolis, con hasta 20 minutos de retraso aleatorio, selecciona una Keynote de Goshen/Domingo de producción completada elegible de antes del día actual y un tema compatible activo. Valida los hashes de origen y plantilla inmutables, ejecuta la extracción directa de Keynote y la generación determinista de tercios inferiores, importa la presentación a la biblioteca de broadcast-gfx sin colocación en lista de reproducción, verifica cada miniatura renderizada y recupera el paquete de vistas previas limitado.

Esta prueba está estructuralmente aislada de las notificaciones semanales y el almacenamiento. No crea una fila de notificación de procesamiento, no contacta al pastor de origen, no contacta al personal de producción, no cambia la lista de reproducción dominical en vivo, no copia un mazo histórico al directorio en vivo de la Mac de adoración, ni publica imágenes de prueba en la salida de Drive semanal. Su único informe diario de aprobación/fallo va solo a cgood@riveroaks.org. La prevalidación frecuente sin contenido continúa verificando la conectividad de Drive y la Mac de adoración de forma segura.

El resultado se almacena atómicamente en /var/lib/riveroaks-workflow-health/sermon-daily-canary-production.json. Contiene solo IDs, hashes, códigos de estado/error, recuentos de diapositivas y vistas previas, y tiempo de ejecución, no texto de sermón, credenciales, cuerpos de correo electrónico o rutas. Las presentaciones de prueba utilizan el prefijo visible QA DAILY CANARY y nunca ocupan la posición de la lista de reproducción dominical administrada.

El monitor de flujo de trabajo normal de cinco minutos verifica de forma independiente que el temporizador esté habilitado y activo, luego lee su estado. Un temporizador deshabilitado o inactivo, un resultado fallido/faltante/inválido, o un resultado de más de 30 horas de antigüedad alerta en la primera verificación, marca el contrato de salud del sermón limitado como no disponible y, por lo tanto, es visible para Uptime Kuma, así como para el monitor de correo electrónico enfocado. Un temporizador y resultado saludables no envían otra alerta operativa.

La activación de producción es de cierre por fallo. El trabajo de aceptación manual seguro deshabilita el temporizador antes de probar y lo deja deshabilitado después de cualquier ejecución fallida; solo una ejecución verificada y exitosa lo vuelve a habilitar e imprime el próximo disparador. Cada correo electrónico de aceptación utiliza una clave de idempotencia por ejecución para que las pruebas manuales repetidas no supriman silenciosamente un informe posterior.

Comandos del operador:

systemctl status riveroaks-sermon-daily-canary-production.timer
systemctl list-timers riveroaks-sermon-daily-canary-production.timer
systemctl start riveroaks-sermon-daily-canary-production.service
journalctl -u riveroaks-sermon-daily-canary-production.service -n 100 --no-pager

El instalador habilita el temporizador pero intencionalmente no inicia el canario largo durante el despliegue. Utilice el trabajo seguro de GitLab accept_sermon_daily_canary_production para la aceptación de producción; confirme su estado limitado, informe directo, próximo disparador del temporizador y tarjeta de preparación dominical. La aceptación de producción inicial el 16 de agosto de 2026 probó el mazo del 9 de agosto: 20 diapositivas de Keynote produjeron 28 tercios inferiores y 28 vistas previas verificadas en 11.6 segundos, y el informe se dirigió solo a cgood@riveroaks.org.

El contrato /health/sermon-slides.php sin contenido está destinado a Uptime Kuma. Se vuelve no disponible para dependencias sistémicas o monitoreo obsoleto, mientras que un fallo de procesamiento específico del sermón sigue siendo una alerta enfocada procesable en lugar de informar erróneamente a todo el servicio como fuera de línea. Consulte Alertas del flujo de trabajo del portal enfocado para ver umbrales, ventanas de mantenimiento, comandos y triaje.

Trabajadores propiedad del entorno

Cada entorno tiene cuatro trabajadores persistentes. Los servicios de producción ejecutan solo código desplegado bajo /usr/share/nginx/portal con /etc/riveroaks-portal/production.env; los servicios de desarrollo utilizan /usr/share/nginx/html/dev-portal y el archivo de desarrollo seguro.

Etapa	Desarrollo	Producción
Extracción de Keynote	`sermon-slide-extraction-dev.service`	`sermon-slide-extraction-production.service`
Entrega de ProPresenter y Mac	`sermon-slide-propresenter-dev.service`	`sermon-slide-propresenter-production.service`
Correo electrónico específico del destinatario	`sermon-slide-notification-dev.service`	`sermon-slide-notification-production.service`
Exportación de rastreo Loki/Tempo	`sermon-slide-telemetry-dev.service`	`sermon-slide-telemetry-production.service`

Instale o actualice las unidades solo desde la raíz desplegada correspondiente:

sudo scripts/install-sermon-slide-workers.sh development
sudo scripts/install-sermon-slide-workers.sh production

El instalador ancla SERMON_SLIDES_ENVIRONMENT en cada unidad, recarga systemd, habilita los servicios y verifica que estén activos. Nunca apunte una unidad de producción al checkout de desarrollo, y nunca ejecute ambos sufijos con el mismo valor de entorno.

Los cuatro trabajadores también protegen contra la deriva de archivos desplegados/tiempos de ejecución. Al inicio, cada trabajador huella solo sus propias dependencias de origen de Python. Si un despliegue de portal reemplaza atómicamente cualquier archivo vigilado, el trabajador en ejecución finaliza su trabajo reclamado actual, cierra su conexión a la base de datos y se re-ejecuta antes de reclamar otro trabajo. Esto carga el código recién desplegado sin interrumpir una carga, entrega de ProPresenter, envío de correo electrónico o exportación de telemetría. El diario registra sermon_slide_worker_reloading con nombres de archivo de origen limitados seguidos del evento ordinario sermon_slide_worker_started.

Cambiar un EnvironmentFile o una unidad de systemd es diferente: una re-ejecución en proceso hereda su entorno actual. Utilice el instalador anterior para esos cambios. Después de un lanzamiento solo de código, verifique que el diario del trabajador relevante muestre la secuencia de recarga/inicio y que los cuatro servicios permanezcan activos.

Aceptación de lanzamiento de producción

Lanzamiento del 13 de agosto de calidad de renderizado y mapeo de temas

La administración de temas es ahora una operación. En Personal → Diapositivas de sermones → Administrador, un administrador ingresa una serie, selecciona cualquier tema compatible del catálogo de ProPresenter de broadcast-gfx en caché, elige el alcance del campus/servicio y guarda. El portal importa el tema nativo seleccionado a través del receptor restringido, valida sus diapositivas Cortas y de Escritura, almacena una instantánea inmutable de la VM y crea o actualiza el mapeo. El panel anterior separado de "seleccionar y validar" ya no forma parte del flujo de trabajo del operador. La carga de plantilla nativa del portal sigue siendo una solución alternativa avanzada.

Cada mapeo activo tiene una acción Cambiar. Un sermón existente también expone Cambiar tema junto a Redeploy. Al ingresar desde un sermón, guardar un nuevo tema actualiza el mapeo de serie/alcance coincidente y pone en cola una regeneración completa y un redespliegue de la última versión cargada de ese sermón. Una edición solo de mapeo afecta el procesamiento futuro sin cambiar silenciosamente los artefactos históricos.

El control de calidad de lanzamiento utilizó el mazo de producción del 16 de agosto en modo solo de biblioteca para que la lista de reproducción semanal administrada no se viera afectada. El perfil de Escritura de 68 columnas/136 caracteres elegido produjo 31 tercios inferiores de 21 diapositivas fuente. Las 31 miniaturas fueron recuperadas y verificadas; los únicos dos grupos de representación duplicados fueron contenido repetido intencional. Una cohorte de defectos controlada separada insertó un tema faltante, texto de tamaño insuficiente, texto recortado y salida generada intercambiada. El pase determinista detectó defectos de representación estructurales, mientras que el pase visual asesor identificó el tema faltante, el tipo pequeño, el cuerpo recortado y la falta de coincidencia del orden de origen/representación. Las cuatro solicitudes de IA visual cubrieron las 26 imágenes de prueba y costaron aproximadamente $0.0051.

El mismo control de calidad expuso el comportamiento transitorio de miniaturas obsoletas de ProPresenter: cuatro diapositivas diferentes inicialmente devolvieron imágenes en blanco idénticas, luego devolvieron el contenido correcto en una recuperación posterior. El reintento limitado del receptor descrito anteriormente se agregó y se validó contra la recuperación transitoria y las pruebas de discrepancia persistentes. Una importación final en vivo solo de biblioteca devolvió 31 de 31 vistas previas correctas sin representación duplicada de texto diferente.

El lanzamiento de preparación del 12 de agosto se promocionó a través del MR del portal !500 como un lanzamiento estrecho desde la rama main actual; no se incluyeron cambios de desarrollo no relacionados. El commit de despliegue de producción b3456f133d496507acdf4e33fe098922d776e544 contiene requisitos de entrega inmutables por ejecución, puntos de control del intento actual, clasificación segura de reintentos, informes de fallos exactos y la corrección de la redacción del correo electrónico del pastor.

La aceptación posterior al despliegue demostró lo siguiente sin leer valores seguros:

las cuatro columnas de requisitos existen y la migración idempotente tiene éxito;
los tres trabajadores de sermones de producción y el temporizador de flujo de trabajo de cinco minutos están habilitados y activos;
las pruebas de notificación enfocada desplegada, trabajador de ProPresenter, observabilidad, revisión de Biblia, informe de IA, transcripción y monitor de flujo de trabajo pasan en los tiempos de ejecución anclados del servidor;
el enrutamiento de producción dirige los informes de administradores a productionstaff@riveroaks.org, mientras que las notificaciones del cargador continúan capturando el correo electrónico de la cuenta del cargador conectado;
MailerSend, LiteLLM, YouVersion, entrega broadcast-gfx, entrega de adoración y publicación de vistas previas están configurados y habilitados;
la producción no tiene ejecuciones de sermones actuales no resueltas ni notificaciones de sermones pendientes/fallidas después del despliegue;
el monitor de producción está fresco y saludable, y su ejecución de prueba de fallo de sermón sintético se representa sin enviar correo ni cambiar el estado del incidente;
la Mac de diapositivas de adoración es accesible;
la ruta de catálogo de temas restringida de broadcast-gfx encontró 40 temas, 21 que coinciden con el contrato de plantilla del portal, y devolvió ProPresenter a su estado cerrado original después de que la automatización lo abriera;
las reglas de destino mantienen los tercios inferiores automáticos y la lista de reproducción semanal administrada limitados a Goshen Sunday Service. Español permanece solo de almacenamiento con despliegue manual de tercios inferiores permitido; otros grupos no coincidentes utilizan la solución alternativa segura solo de almacenamiento/despliegue manual.

El límite de aceptación de producción activado por humanos se completó el 12 de agosto con la carga genuina firmada 46, sermón 4, versión 2. La ingesta primero expuso una discrepancia SQL de reserva de carga determinista. Los MR del portal !505 y !506 centralizaron la declaración de reserva y el contrato de enlace, eliminaron el marcador de posición adicional y agregaron verificaciones de regresión para recuentos de columnas/valores y marcadores de posición/enlaces. La carga corregida llegó a Drive, caché segura, extracción directa de Keynote y generación de tercios inferiores.

El primer intento de entrega se detuvo de forma segura con propresenter_playlist_slot_changed: el estado del receptor todavía nombraba la presentación del 9 de agosto mientras que la posición 3 de la lista de reproducción ya contenía una presentación de Goshen v001 del 16 de agosto. No se reconoció ninguna entrega de Mac. Se enviaron correos electrónicos de fallo separados al cargador y al personal de producción; la copia de producción incluyó el código exacto y las verificaciones afectadas. Los MR del portal !507 y !508 agregaron la regla de reconciliación de versiones de la misma fecha/campus limitada descrita anteriormente sin un nuevo servicio, dependencia, migración o configuración.

Luego, un administrador utilizó Redeploy en la versión existente. La ejecución c20c15ce-4840-4e79-abfd-a39347dded80 alcanzó ready en 86 segundos:

21 diapositivas de Keynote produjeron 26 tercios inferiores y pasaron la integridad del contenido;
ProPresenter 19.0.1 importó y verificó la representación de las 26 diapositivas;
la posición 3 de la lista de reproducción reconoció el UUID de la presentación 6986C2D8-B242-40A4-9E49-F5B49B11484A;
ProPresenter comenzó cerrado, la automatización lo lanzó y la automatización lo devolvió a cerrado;
el receptor de adoración verificó mediante hash el Keynote v2 bajo la ruta administrada del 16 de agosto con SHA-256 6f24d908a206dad71eacc3002905707eda8ae5dd47274360dd136cba9d4e6fa3;
Drive recibió exactamente 001.jpg a 026.jpg; las imágenes representativas de punto y Escritura pasaron la revisión visual a tamaño completo, y los marcos de apertura/cierre en blanco siguieron siendo intencionales;
los correos electrónicos de éxito del cargador y de producción informaron 1 minuto 27 segundos y $0.001228 de costo de IA. El cargador recibió orientación de alto nivel sobre entrega y corrección de pruebas; producción recibió la identidad del cargador, recuentos de 21 a 26, confirmaciones de ambas Macs, colocación en lista de reproducción, detalle de división y el enlace al conjunto renderizado;
la línea de tiempo de la versión conservó 45 eventos operativos seguros que abarcan ingesta, Drive, extracción, generación, ambas Macs, renderizado, publicación de vistas previas, IA y las dos notificaciones rastreadas de forma independiente.

El MR del portal !509 también cambia un recibo de receptor final ausente de una redacción de importación cero engañosa a "no se devolvió un reconocimiento verificado". El código de fallo limitado exacto permanece en el informe de producción. Esta distinción es importante porque un receptor puede preparar e inspeccionar una presentación antes de que una verificación posterior de la lista de reproducción detenga el intento; solo un recibo completo es autoritativo.

Consultas de operador

Todas las marcas de tiempo son UTC. Los intentos de procesamiento recientes, incluidos los reintentos, se pueden revisar sin abrir el JSON del informe:

SELECT
  r.started_at,
  u.upload_uuid,
  r.run_uuid,
  r.trigger_mode,
  r.status,
  r.attempt_number,
  r.duration_ms,
  r.source_slide_count,
  r.generated_slide_count,
  r.remote_slide_count,
  r.broadcast_gfx_required,
  r.playlist_required,
  r.worship_required,
  r.preview_required,
  r.error_code,
  r.propresenter_was_running,
  r.propresenter_launched,
  r.propresenter_closed_after_processing
FROM sermon_slide_processing_runs AS r
JOIN sermon_slide_uploads AS u ON u.id = r.upload_id
WHERE u.source_environment = 'production'
ORDER BY r.started_at DESC
LIMIT 50;

Los fallos y los intentos de reintento deben revisarse por código de error limitado. El UUID de ejecución conecta la fila SQL con la línea de systemd journal correspondiente:

SELECT r.started_at, r.run_uuid, r.upload_id, r.status, r.attempt_number, r.duration_ms, r.error_code
FROM sermon_slide_processing_runs AS r
JOIN sermon_slide_uploads AS u ON u.id = r.upload_id
WHERE u.source_environment = 'production'
  AND r.status IN ('failed', 'retry', 'waiting_theme', 'deferred')
ORDER BY started_at DESC
LIMIT 50;

Revise una carga a través de la ingesta, extracción, cada intento de despliegue, revisión de IA y ambos correos electrónicos por su ID de correlación de carga:

SELECT
  e.occurred_at,
  u.upload_uuid AS correlation_id,
  r.run_uuid,
  e.stage,
  e.event_type,
  e.status,
  e.attempt_number,
  e.duration_ms,
  e.target_name,
  e.error_code,
  e.cost_usd,
  e.metrics_json
FROM sermon_slide_processing_events AS e
JOIN sermon_slide_uploads AS u ON u.id = e.upload_id
LEFT JOIN sermon_slide_processing_runs AS r ON r.id = e.processing_run_id
WHERE u.upload_uuid = 'REPLACE-WITH-UPLOAD-UUID'
ORDER BY e.occurred_at, e.id;

Encuentre fallos de etapa recientes sin leer el contenido del sermón:

SELECT
  e.occurred_at,
  u.upload_uuid AS correlation_id,
  r.run_uuid,
  e.stage,
  e.attempt_number,
  e.duration_ms,
  e.error_code
FROM sermon_slide_processing_events AS e
JOIN sermon_slide_uploads AS u ON u.id = e.upload_id
LEFT JOIN sermon_slide_processing_runs AS r ON r.id = e.processing_run_id
WHERE e.status = 'failed'
  AND u.source_environment = 'production'
ORDER BY e.occurred_at DESC
LIMIT 100;

El rastro del diario a corto plazo correspondiente se puede filtrar sin exponer el archivo de entorno:

journalctl \
  -u sermon-slide-extraction-production.service \
  -u sermon-slide-propresenter-production.service \
  -u sermon-slide-notification-production.service \
  -u sermon-slide-telemetry-production.service \
  --since '24 hours ago' --no-pager \
  | grep 'correlation_id=REPLACE-WITH-UPLOAD-UUID'

Solo la fila de notificación de personal de producción registra el costo de inferencia. Las filas del pastor reutilizan ese resultado y deliberadamente tienen un costo nulo, por lo que este total no duplica las llamadas:

SELECT
  DATE_FORMAT(n.created_at, '%Y-%m-01') AS month_utc,
  COUNT(*) AS inference_calls,
  ROUND(SUM(n.inference_cost_usd), 6) AS ai_cost_usd
FROM sermon_slide_processing_notifications AS n
JOIN sermon_slide_uploads AS u ON u.id = n.upload_id
WHERE n.inference_cost_usd IS NOT NULL
  AND u.source_environment = 'production'
GROUP BY DATE_FORMAT(n.created_at, '%Y-%m-01')
ORDER BY month_utc DESC;

Al diagnosticar el desarrollo, sustituya development en SQL y los sufijos de unidad -dev. Nunca combine entornos en una conclusión de salud o costo.

Utilice processing_duration_seconds en las filas de notificación para el tiempo de carga a finalización visible para el pastor. Utilice duration_ms en las filas de ejecución al diagnosticar un intento individual de generación, almacenamiento, entrega o reintento.

Triaje de fallos

Abra el sermón afectado y expanda Registro de procesamiento para la versión más reciente. Comience con la primera etapa fallida, no con la redacción final del correo electrónico.
Copie el ID de correlación y el UUID de ejecución. Confirme si un reintento posterior ya se completó antes de intervenir.
Verifique el código de error limitado exacto y el destino lógico. No pida a un pastor que vuelva a cargar por un fallo de Mac, lista de reproducción, vista previa, límite de tasa de Drive o proveedor de correo electrónico; utilice Redeploy después de corregir la dependencia.
Compare las líneas del diario coincidentes solo cuando la línea de tiempo de la base de datos carezca de suficientes detalles operativos. No envíe archivos de entorno ni JSON de informes a tickets o chats.
Confirme que ambos eventos de notificación específicos del destinatario llegaron a sent. Un correo electrónico de producción exitoso no prueba que el correo electrónico del cargador se envió, y viceversa.

Trate cualquier fallo de ejecución terminal como procesable. Investigue una ejecución que permanezca en processing durante más de 20 minutos, una notificación pendiente/reintento durante más de 15 minutos, cualquier costo de IA individual superior a $2, o un gasto mensual de IA cercano a $10. Estos son umbrales operativos; las alertas automatizadas y los límites máximos del proveedor deben configurarse por separado del registro de auditoría.

Retención

Conserve las filas agregadas de resultados de procesamiento y notificación durante la vida útil del registro del sermón. Conserve los sermon_slide_processing_events detallados durante al menos 400 días para que los incidentes dominicales interanuales sigan siendo diagnosticables. La tabla es pequeña (normalmente decenas de filas por carga), y no hay ningún trabajo de eliminación automática habilitado a partir de esta actualización. Antes de agregar la limpieza de retención, verifique una copia de seguridad y elimine solo los eventos anteriores al umbral aprobado; nunca elimine filas de cola activas, trabajos, ejecuciones de procesamiento o resultados de notificación como parte del mantenimiento de eventos.