Was erfasst wird
Eine Änderung an einem Bildschirm, einem Bildschirmordner, einer Wiedergabeliste, einer Mediendatei oder einem Medienordner, einer Anwendung, einer Karte, einem Zeitplan oder einer Ebene, einer Kampagne, einer Benachrichtigung, einem Webhook, einem Auslöser, einer Quelle, einem Flottenlink, einem Berichtszeitplan, einer Alarm-Stummschaltung, einem Mitglied oder einer Rolle, einer Einladung, einem Service-Client, einer Agentenverbindung, einer Single-Sign-on- oder SCIM-Einstellung, einem von einem Identitätsanbieter bereitgestellten Benutzer oder einer solchen Gruppe, einer Gruppenbindung oder einer Projekt- oder Organisationseinstellung ist ein Eintrag. Ebenso ein an einen Bildschirm gesendeter Befehl (Neustart, Neuladen, Identifizieren, Cache leeren, App neu starten, Aktualisieren, Hinweis einblenden, Screenshot) und eine Flottenaktion, mit den Parametern, die sie trug.
Ein Eintrag enthält:
| Feld | Bedeutung |
|---|---|
at | Wann die Änderung festgeschrieben wurde (UTC) |
actor | Wer: kind person, agent, service_client, staff oder system, mit id und name |
approved_by, review_id | Die Person, die eine von einem Agenten vorgeschlagene Änderung genehmigt hat, und die Prüfung, die sie zurückgehalten hat |
source | Die Oberfläche: dashboard, api, cli, mcp, staff, device, webhook oder system |
action | Ein stabiler Code, Ressourcentyp und Verb: screen.update, playlist.create, webhook.rotate_secret |
resource | type, id und der name der Ressource nach der Änderung |
changes | Jedes geänderte Mitglied: path (ein JSON-Pointer wie /label), before und after |
revision | Die Revision, die die Änderung erzeugt hat, verlinkt statt kopiert (eine Wiedergabelisten-Revision, eine Medienversion, die eigene Revisionsnummer der Ressource) |
request_id, route, client, client_ip | Die Anfrage, über die sie kam |
seq, prev_hash, hash | Die Position des Eintrags in der Kette |
Werte sind die gespeicherten Werte: Namen, E-Mail-Adressen, Adressen, URLs und IDs werden unverändert gelesen. Ein Geheimnis (ein Token, ein API-Schlüssel, ein Passwort, ein Webhook- oder Signaturgeheimnis, eine Quellen-Zugangsdaten-Angabe, ein Kopplungscode, eine Empfänger-URL, die selbst als Zugangsdaten dient) erscheint auf beiden Seiten als (redacted), sodass eine Rotation als Änderung sichtbar wird, ohne einen der beiden Werte zu zeigen. Ein Wert über 1 KiB wird durch seine Größe und seinen SHA-256 ersetzt, und ein Eintrag enthält höchstens 100 Änderungen und 16 KiB; truncated zeigt an, dass mehr geändert wurde. Die Seiten einer Wiedergabeliste und die Bytes einer Mediendatei werden nicht kopiert: Der Eintrag verlinkt die Revision.
Kartendaten, Schlüssel-Wert-Einträge (einschließlich der von Webhooks und Quellen geschriebenen) und Player-Telemetrie sind Daten, keine Konfiguration. Sie stehen nicht im Audit-Protokoll; das Ereignisprotokoll des Projekts hält fest, dass sie geschrieben wurden.
Suche
GET /api/audit listet Einträge, neueste zuerst:
screenrig audit list --resource-type screen --resource-id scr_ID
screenrig audit list --actor-kind agent --since 2026-10-01T00:00:00Z
screenrig audit list --action 'playlist.*' --source mcp --limit 20
screenrig audit list --field /label
screenrig audit show aud_ID| Filter | Bedeutung |
|---|---|
actor | Die ID der Person, des Agenten oder des Service-Clients |
actor_kind | person, agent, service_client, staff oder system |
source | dashboard, api, cli, mcp, staff, device, webhook oder system |
resource_type, resource_id | Was geändert wurde |
action | Ein Aktionscode oder ein Präfix, das auf * endet |
field | Ein JSON-Pointer: Einträge, die dieses Mitglied oder ein darunterliegendes geändert haben |
since, until | Ein Zeitfenster |
cursor, limit | Blättern: next_cursor als cursor zurückgeben; 1 bis 200 pro Seite |
Die Audit-Seite des Dashboards unter Projekt listet dieselben Einträge mit diesen Filtern und zeigt jede Änderung mit Vorher und Nachher.
Wer es lesen kann
Der Inhaber des Projekts, ein Administrator seiner Organisation und ein Mitarbeiter, der das Projekt mitverfolgt, lesen es im Dashboard. Ein Agent oder Service-Client mit der Projektberechtigung liest es über die API und die CLI. Änderungen an den Administratoren, Domains und Abrechnungseinstellungen einer Organisation stehen im eigenen Protokoll der Organisation: GET /api/organizations/{org_id}/audit, für ihre Administratoren.
Manipulationssicherheit
Nichts schreibt, ändert oder löscht einen Eintrag: Dafür gibt es keine Route. Jeder Eintrag ist in seinem Projekt mit dem vorherigen verkettet: Sein hash ist der SHA-256 aus dem Hash des vorherigen Eintrags, seiner Position und seinem Inhalt. Wenige Sekunden nach einer Änderung trägt der Eintrag sein seq und sein hash.
screenrig audit head
screenrig audit verify
screenrig audit verify --anchor 128:3f2c0b6e9a4d81c7f5e0a2b4c6d8e0f1a3b5c7d9e1f30415263748596a7b8c9daudit verify (GET /api/audit/verify) berechnet jeden Hash aus dem gespeicherten Inhalt neu und prüft jedes Glied, die Lückenlosigkeit von seq und den Kettenkopf; es meldet hash_mismatch, prev_mismatch, gap, head_mismatch, anchor_mismatch oder floor_mismatch für den fehlerhaften Eintrag und endet mit Code 13, wenn die Kette nicht verifiziert wird. Ein Aufruf prüft bis zu 5.000 Einträge und liefert next_seq zum Fortsetzen. Ein Anker ist ein Kettenkopf (SEQ:HASH), den Sie aus einem früheren Export oder von audit head aufbewahrt haben: Die Prüfung gegen ihn beweist, dass der Verlauf bis zu diesem Eintrag unverändert ist und nicht gekürzt wurde.
Aufbewahrung und Löschung
Einträge werden in jedem Tarif 400 Tage aufbewahrt. Ein abgelaufener Eintrag wird beginnend mit dem ältesten entfernt, und die Kette hält fest, wo sie jetzt beginnt (floor_seq, floor_hash), sodass eine Entfernung an anderer Stelle erkannt wird. Wird ein Projekt gelöscht, wird sein Audit-Protokoll mit gelöscht. screenrig project export DIR schreibt das Protokoll nach log/audit.jsonl, mit dem Kettenkopf in log/audit-head.json, sodass eine Kopie das Projekt überdauert und sich weiter gegen ihren Anker verifizieren lässt.
Export
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.pdfGET /api/audit?format=csv|xlsx|pdf schreibt das gefilterte Protokoll mit demselben Renderer wie jeden Bericht: eine Zeile pro geändertem Feld, älteste zuerst, die letzten 30 Tage, sofern since nichts anderes angibt, bis zu 50.000 Zeilen (truncated zeigt an, wenn die Datei nur die ersten Zeilen enthält). Kettenkopf und Aufbewahrungsgrenze stehen in der Datei, sodass eine aufbewahrte Kopie als Anker für ein späteres audit verify dient.