Documentación

Registro de auditoría

El registro de auditoría anota cada cambio en la configuración de un proyecto: quién lo hizo, qué cambió, cuándo, por qué superficie y el valor de cada campo modificado antes y después. Admite búsqueda, está encadenado para que una reescritura sea detectable, se conserva 400 días en todos los planes y se exporta a CSV, XLSX o PDF.

Qué se registra

Un cambio en una pantalla, una carpeta de pantallas, una lista de reproducción, un archivo o una carpeta multimedia, una aplicación, una tarjeta, un horario o un nivel, una campaña, una notificación, un webhook, un disparador, una fuente, un enlace de flota, un horario de informe, un silencio de alerta, un miembro o un rol, una invitación, un cliente de servicio, una conexión de agente, un ajuste de inicio de sesión único o de SCIM, un usuario o grupo que aprovisiona un proveedor de identidad, un vínculo de grupo, o un ajuste del proyecto o de la organización es una entrada. También lo es un comando enviado a una pantalla (reiniciar, recargar, identificar, vaciar la caché, reiniciar la aplicación, actualizar, aviso en pantalla, captura de pantalla) y una acción de flota, con los parámetros que llevaba.

Una entrada contiene:

MiembroSignificado
atCuándo se confirmó el cambio (UTC)
actorQuién: kind person, agent, service_client, staff o system, con id y name
approved_by, review_idLa persona que aprobó un cambio propuesto por un agente, y la revisión que lo retuvo
sourceLa superficie: dashboard, api, cli, mcp, staff, device, webhook o system
actionUn código estable, tipo de recurso y verbo: screen.update, playlist.create, webhook.rotate_secret
resourcetype, id y el name del recurso después del cambio
changesCada miembro modificado: path (un puntero JSON como /label), before y after
revisionLa revisión que produjo el cambio, enlazada en lugar de copiada (una revisión de lista de reproducción, una versión de archivo multimedia, el número de revisión propio del recurso)
request_id, route, client, client_ipLa solicitud por la que llegó
seq, prev_hash, hashEl lugar de la entrada en la cadena

Los valores son los almacenados: nombres, correos, direcciones, URL e ids se leen tal cual. Un secreto (un token, una clave de API, una contraseña, un secreto de webhook o de firma, una credencial de fuente, un código de emparejamiento, una URL de receptor que es en sí la credencial) aparece como (redacted) en ambos lados, de modo que una rotación se ve como un cambio sin mostrar ninguno de los dos valores. Un valor de más de 1 KiB se sustituye por su tamaño y su SHA-256, y una entrada conserva como máximo 100 cambios y 16 KiB; truncated indica que cambió más. Las páginas de una lista de reproducción y los bytes de un archivo multimedia no se copian: la entrada enlaza la revisión.

Los datos de tarjeta, los valores clave/valor (incluidos los que escriben los webhooks y las fuentes) y la telemetría del Player son datos, no configuración. No están en el registro de auditoría; el registro de eventos del proyecto deja constancia de que se escribieron.

Quién puede leerlo

El propietario del proyecto, un administrador de su organización y un miembro del personal que observa el proyecto lo leen en el panel. Un agente o un cliente de servicio con la capacidad del proyecto lo lee a través de la API y la CLI. Los cambios en los administradores, dominios y ajustes de facturación de una organización son el registro propio de la organización: GET /api/organizations/{org_id}/audit, para sus administradores.

Resistencia a la manipulación

Nada escribe, modifica ni elimina una entrada: no existe ninguna ruta para ello. Cada entrada está encadenada a la anterior en su proyecto: su hash es el SHA-256 del hash de la entrada anterior, de su posición y de su contenido. Unos segundos después de un cambio, la entrada lleva su seq y su hash.

screenrig audit head
screenrig audit verify
screenrig audit verify --anchor 128:3f2c0b6e9a4d81c7f5e0a2b4c6d8e0f1a3b5c7d9e1f30415263748596a7b8c9d

audit verify (GET /api/audit/verify) recalcula cada hash a partir del contenido almacenado y comprueba cada enlace, la continuidad de seq y la cabecera de la cadena; informa de hash_mismatch, prev_mismatch, gap, head_mismatch, anchor_mismatch o floor_mismatch para la entrada defectuosa y termina con el código 13 cuando la cadena no se verifica. Cada llamada comprueba hasta 5000 entradas y devuelve next_seq para continuar. Un ancla es una cabecera de cadena (SEQ:HASH) que conservó de una exportación anterior o de audit head: verificar contra ella demuestra que el historial hasta esa entrada no ha cambiado y no se ha truncado.

Retención y eliminación

Las entradas se conservan 400 días en todos los planes. Una entrada que supera ese plazo se elimina empezando por la más antigua, y la cadena registra dónde empieza ahora (floor_seq, floor_hash), de modo que una eliminación en cualquier otro punto se detecta. Cuando se elimina un proyecto, su registro de auditoría se elimina con él. screenrig project export DIR escribe el registro en log/audit.jsonl, con la cabecera de la cadena en log/audit-head.json, de modo que una copia sobrevive al proyecto y sigue verificándose contra su ancla.

Exportación

screenrig audit export --format csv --output audit.csv
screenrig audit export --format xlsx --since 2026-07-01T00:00:00Z --until 2026-10-01T00:00:00Z
screenrig audit export --format pdf --resource-type playlist --output playlist-changes.pdf

GET /api/audit?format=csv|xlsx|pdf escribe el registro filtrado con el mismo motor de generación que todos los informes: una fila por campo modificado, de la más antigua a la más reciente, los últimos 30 días salvo que since indique otra cosa, hasta 50 000 filas (truncated indica cuándo el archivo solo contiene las primeras filas). La cabecera de la cadena y el límite de retención están en el archivo, de modo que una copia que conserve sirve de ancla para un audit verify posterior.