Automatización de diapositivas de sermones

Actualizado el 14 de agosto de 2026.

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

El Portal River Oaks acepta cargas de diapositivas de sermones de Keynote versionadas. Almacena el original en la Unidad Compartida de Google configurada y en una caché protegida del servidor, lee el texto y los datos de objetos directamente del paquete de Keynote y copia los bytes exactos del original en 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 las ID de la Unidad Compartida y de la carpeta raíz, la disposición de las carpetas y controles independientes para los tercios inferiores automáticos, la colocación en la lista de reproducción semanal, la copia al ordenador de adoración, las vistas previas renderizadas y el despliegue iniciado por el administrador. Las credenciales de Google permanecen en el archivo del entorno protegido; la base de datos solo almacena las ID de enrutamiento y el comportamiento.

Grupo	Disposición del 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 Drive configurada heredada	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.

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 sea el orador. Una presentación histórica sin evidencia nombra a su orador como Orador no registrado. Los manifiestos de importación pueden proporcionar 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 utilizan v1, v2, etc. Los objetos de Drive existentes con nombres antiguos con ceros iniciales no se renombran 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 y con imágenes.
El texto se divide en los límites de versículo, oración y frase según 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 mapeada 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 gestionada, verifica los recuentos de texto y diapositivas ordenados, y genera una imagen de vista previa por cada diapositiva generada.
Las sumas de comprobación de las 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 dividir las Escrituras, el generador elimina solo los 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 humana/IA. El generador no corrige 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 en la disposición del material, regiones de tema faltantes y representaciones duplicadas exactas con texto generado diferente. Estas comprobaciones no infieren ni reescriben la redacción del sermón. El modelo visual asesor revisa cada diapositiva renderizada con su texto de diapositiva fuente y sus vecinos generados inmediatos para detectar recortes, tipos de letra diminutos, 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 el cambio de regla del grupo de carga no deben reinterpretar una ejecución anterior como recién exitosa o fallida.

El inicio de un nuevo intento borra los campos mutables del trabajo y del 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 el ordenador 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 comprueba si ProPresenter se está ejecutando. Una actualización semanal de presentación estable 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 cierra solo la instancia del proceso que la automatización inició.

Presentación estable gestionada

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 la UUID exacta de la presentación, el nombre de visualización y la ruta de la biblioteca que ya están guardados en la ranura gestionada. 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 y la versión de la API configuradas están activas;
la ranura de lista de reproducción guardada todavía resuelve a la UUID de presentación estable;
la ruta de presentación estable, la identidad de texto ordenada y el recuento de diapositivas coinciden;
cada diapositiva generada tiene una miniatura verificada por renderizado;
los elementos fuera de la posición de la lista de reproducción gestionada no han cambiado.

La ruta de archivo exacta es parte de la identidad de biblioteca guardada de ProPresenter. Cambiar solo la UUID interna 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 de UUID/nombre estable no secretas 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 explícitamente 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 del 14 de agosto de carga 47 estableció este comportamiento. Tres despliegues limitados alcanzaron la generación y el reconocimiento de la lista de reproducción en vivo, pero la tienda de listas de reproducción nunca cambió. Un _River Oaks Automation Canary aislado reprodujo el PUT de sesión solamente y la reversión de reinicio sin tocar la lista de reproducción dominical en vivo. Una segunda prueba aislada demostró que el reemplazo de archivo estable de ruta exacta cargó 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 de biblioteca exacta, el inicio de la aplicación, la identidad de la API, los temas compatibles y la capacidad de renderizado. 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 implementa de forma independiente 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 el ordenador de adoración

Google Drive y la caché protegida de la VM siguen siendo el archivo. El receptor dedicado de la Mac de adoración solo conserva las dos fechas de sermón distintas más recientes entre las copias de Keynote gestionadas por el portal. Su configuración protegida 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 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 actual de fecha completa como el protocolo heredado solo de año mientras se actualizan los trabajadores de producción; un nombre de archivo estandarizado proporciona la fecha de retención para una entrega heredada.

Imágenes de Keynote

El extractor inventaría los objetos de imagen de Keynote específicos de la diapositiva de forma independiente del texto del documento. Registra la diapositiva de origen, 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 tercios inferiores y no se envían a través de OCR. Esto evita inventar silenciosamente palabras a partir de obras de arte decorativas, 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 a partir 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 con resumen 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.

Las obras de arte de plantilla repetidas se clasifican de forma conservadora a partir de metadatos nativos, sin reconocimiento de imágenes ni OCR. El mismo resumen de imagen materializada 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 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 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 con resumen, 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 obras de 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 esos cinco mazos anónimos confirmó la regla antes de su lanzamiento. Un mazo heredado devolvió el error de compatibilidad limitado parser_output_missing y sigue siendo un seguimiento separado; no detuvo ni contaminó el grupo.

Pruebas de sistemas históricos

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 sistema 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 ajuste de 68 columnas para Escrituras. El perfil de Escrituras es la opción intermedia de una comparación de 15 mazos: mejora materialmente el tamaño de la fuente sin el aumento del recuento de diapositivas del candidato más agresivo. Un perfil fuera de los límites aceptados por el 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 1.205 tercios inferiores, los 31 mazos pasaron, y los 10 activos de imagen referenciados en siete diapositivas con imágenes se materializaron y verificaron con resumen. Seis diapositivas fuente eran solo de imágenes y, por lo tanto, requieren revisión humana. Ninguna imagen fuente estuvo no disponible. Este corpus es evidencia de regresión, no prueba de que se admita cada estructura o diseño visual futuro de Keynote; 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 gestionada. El sistema recupera el paquete de vistas previas limitado del receptor, verifica cada JPEG numerado contra su manifiesto y el resumen de renderizado 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 protegida configurada de ProPresenter.

El control de calidad histórico no debe publicar vistas previas, enviar correos electrónicos ni llamar a IA por defecto. Ejecútelo a través de un servicio transitorio de mínimo privilegio que cargue el archivo de entorno protegido coincidente a través de systemd, no al obtener ese archivo como un script de shell. Utilice un directorio de descarga temporal de modo 0700, devuelva solo resultados agregados, elimine las copias de mazos/renderizado 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. Los cinco alcanzaron el estado listo: 83 diapositivas fuente generaron 169 tercios inferiores, las 169 vistas previas se recuperaron y verificaron con resumen, 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 gestionada no cambió, se eliminaron los medios temporales de la VM y cinco archivos de biblioteca solo de QA se movieron a la Papelera. Esto demuestra la recuperación determinista de renderizado; no reemplaza la aprobación humana de la hoja de contacto para la tipografía, el espaciado y el 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 ejecución en seco 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 renderizado, 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 gestionada. La copia de producción del informe histórico de IA 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 gestionada del 11 de agosto reconcilió 39 Keynotes brutos de Goshen 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. El grupo combinado 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 1.453 tercios inferiores, publicó las 1.453 imágenes de vista previa y copió los 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 del informe de producción costaron $0.049437 en total. Las ejecuciones históricas intencionalmente no modificaron la lista de reproducción semanal gestionada. Los mapeos de temas temporales de QA 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 el estado de almacenamiento/entrega segura, el tiempo de procesamiento medido, un enlace a la nueva versión y una breve lista de posibles problemas de texto fuente. El personal de producción recibe el nombre del cargador conectado, los detalles del despliegue, los recuentos de origen/generado/diferencia, el tiempo de procesamiento, las vistas previas, los hallazgos de revisión y el costo de la IA.

El almacenamiento, el hashing, la extracción de Keynote, la división, el formato, la entrega, la colocación en la lista de reproducción y el estado de aprobación/fallo son código determinista. La IA no puede modificar palabras, diapositivas ni el 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, de modo que los dos correos electrónicos no dupliquen el costo.

El estado de 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. Cuando ambos ordenadores de diapositivas recibieron sus archivos pero otra etapa requerida falló, el mensaje del pastor nombra el paso incompleto a un alto nivel. 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, el estado de preparación del despliegue determinista no cambia. Ambos correos electrónicos indican explícitamente que la revisión de ortografía y Escrituras no estuvo disponible para esa versión y muestran el costo de la IA como no disponible; no deben omitir silenciosamente la revisión ni marcar un despliegue exitoso como fallido.

La validación de Escrituras compara las referencias y citas analizadas con la API de YouVersion; nunca se basa en la memoria del modelo. NLT es el valor predeterminado a menos que la diapositiva nombre otra traducción. Cuando la traducción solicitada no está disponible, el informe etiqueta explícitamente la comparación de retroceso limitada en lugar de hacer una afirmación de redacción exacta. Un servicio de referencia no disponible produce un resultado visible de not checked; el sistema nunca adivina, reescribe ni corrige silenciosamente las Escrituras.

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 de broadcast-gfx, colocación de 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 en caché protegido, Google Drive, la conversión de notas, la extracción de Keynote, la selección de temas, la generación de tercios inferiores, broadcast-gfx, diapositivas de adoración, verificación de renderizado, publicación de vistas previas, revisión de IA y cada notificación por correo electrónico. Cada fila puede incluir un número de intento, milisegundos transcurridos, destino lógico, código de error limitado, contadores permitidos y costo de IA. Nunca almacena texto de sermón o diapositivas, nombres de archivo, rutas locales o remotas, direcciones de correo electrónico o cuerpos, indicaciones o respuestas de IA, cargas útiles de proveedores, 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 una nueva 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 del portal de confianza registra ese valor durante la ingesta. Cada consulta de extracción, ProPresenter, notificación, admin-health 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 utilicen 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 siguen siendo 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 protegido.

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 fue 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 gestionada, se detienen inmediatamente y alertan a un operador; tocar repetidamente una ranura de lista de reproducción inesperada no es seguro. Cada reintento recibe una nueva UUID de ejecución mientras conserva el ID de correlación de carga.

El diario de systemd es un registro a corto plazo 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 descripción general de la salud de siete días basada en 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 cuyo último intento 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 trazas de extremo a extremo

El registro de auditoría SQL del portal sigue siendo la autoridad. 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 una traza 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 trazas y registros combinados de trabajadores. Un trace_id en una línea de Loki enlaza con la cascada de Tempo coincidente.

El ID de traza 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 de broadcast-gfx, verificación de renderizado, 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, la traza 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 reclamaciones interrumpidas y marca solo la exportación como fallida 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 se retrasa 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 traza 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 seguros de revisión de Biblia y costo de IA. Nunca agregue texto de sermón, nombres de archivo, rutas, ID de Drive, direcciones o cuerpos de correo electrónico, metadatos de pastor/serie/título, indicaciones, respuestas del proveedor o credenciales.

En Loki, comience con:

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

Filtre una ejecución sin convertir el ID de traza 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.

Monitorización proactiva 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. Comprueba el estado del trabajador, la base de datos/esquema, la capacidad de escritura y capacidad del almacenamiento protegido, 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, las sumas de comprobación de temas 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 pide al receptor de broadcast-gfx que valide el lanzamiento de ProPresenter, la API/versión, los temas compatibles, la resolución de biblioteca y la ranura de lista de reproducción gestionada 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 ser más reciente que 30 horas.

El contrato /health/sermon-slides.php sin contenido está destinado a Uptime Kuma. Deja de estar disponible para dependencias sistémicas o monitorización obsoleta, mientras que un fallo de procesamiento específico del sermón sigue siendo una alerta enfocada procesable en lugar de informar erróneamente que todo el servicio está 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 protegido.

Etapa	Desarrollo	Producción
Extracción de Keynote	`sermon-slide-extraction-dev.service`	`sermon-slide-extraction-production.service`
ProPresenter y entrega de 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 trazas 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 fija SERMON_SLIDES_ENVIRONMENT en cada unidad, recarga systemd, habilita los servicios y verifica que estén activos. Nunca apunte una unidad de producción a la extracción 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 código fuente 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 reejecuta antes de reclamar otro trabajo. Esto carga el código recién desplegado sin interrumpir una carga, la entrega de ProPresenter, el envío de correos electrónicos o la exportación de telemetría. El diario registra sermon_slide_worker_reloading con nombres de archivo fuente limitados seguidos del evento ordinario sermon_slide_worker_started.

Cambiar un EnvironmentFile o una unidad de systemd es diferente: una reejecución en proceso hereda su entorno actual. Utilice el instalador anterior para esos cambios. Después de una versión 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 sola 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 plantillas nativas del portal sigue siendo una opción de respaldo 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 y redespilegue completos 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 fuente de producción del 16 de agosto en modo solo de biblioteca para que la lista de reproducción semanal gestionada no se viera afectada. El perfil de Escritura seleccionado de 68 columnas/136 caracteres produjo 31 tercios inferiores a partir de 21 diapositivas fuente. Las 31 miniaturas se recuperaron y verificaron; los únicos dos grupos de renderizado duplicado fueron contenido repetido intencional. Un cohorte de defectos controlado separado insertó un tema faltante, texto subdimensionado, texto recortado y salida generada intercambiada. El pase determinista detectó defectos de renderizado estructurales, mientras que el pase visual asesor identificó el tema faltante, el tipo diminuto, el cuerpo recortado y la falta de coincidencia del orden fuente/renderizado. 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 de miniatura obsoleta transitoria 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 validó contra pruebas de recuperación transitoria y de discrepancia persistente. Una importación final solo de biblioteca en vivo devolvió 31 de 31 vistas previas correctas sin renderizado duplicado 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 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 protegidos:

existen las cuatro columnas de requisitos 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 fijados 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, la entrega de broadcast-gfx, la entrega de adoración y la 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á actualizado y en buen estado, y su ejecución en seco de fallo de sermón sintético se renderiza sin enviar correo ni cambiar el estado del incidente;
el Mac de diapositivas de adoración es accesible;
la ruta del catálogo de temas restringido 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 gestionada limitados a Goshen Sunday Service. Español permanece solo de almacenamiento con despliegue manual de tercios inferiores permitido; otros grupos no coincidentes utilizan el respaldo seguro 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 conectada 46, sermón 4, versión 2. La ingesta expuso por primera vez 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é protegida, 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ó el renderizado de las 26 diapositivas;
la posición 3 de la lista de reproducción reconoció la UUID de 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ó con resumen la Keynote v2 bajo la ruta gestionada 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 general de entrega y corrección de pruebas; producción recibió identidad del cargador, recuentos de 21 a 26, ambas confirmaciones de Mac, colocación en lista de reproducción, detalle de división y 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 una recepción final ausente del receptor de una redacción engañosa de cero importación a "no se devolvió ningún reconocimiento verificado". El código de error 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 comprobació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. La 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 producción-personal registra el costo de inferencia. Las filas de 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 que ve 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 la 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 para 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 de diario coincidentes solo cuando la línea de tiempo de la base de datos carezca de suficiente detalle operativo. 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 alcanzaron sent. Un correo electrónico de producción exitoso no prueba que el correo electrónico del cargador se haya enviado, y viceversa.

Trate cualquier fallo terminal de ejecución 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; la alerta automatizada 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 ejecución 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 anuales de domingo 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.