Pourquoi agent-native ?

screenRIG a été conçu pour les agents autonomes dès le plan de contrôle. Le plugin officiel fournit à un agent des commandes structurées pour médias, listes de lecture, écrans, applications et preuves de lecture. Les résultats sont des enveloppes JSON, chaque erreur indique quoi faire ensuite, les écritures réessayées réutilisent des clés d’idempotence, et la publication rapporte si le lecteur lit effectivement le contenu. L’agent peut exécuter une tâche d’écran, inspecter le résultat et le corriger via la même interface. Ce que signifie agent-native.

Comment exécuter ceci depuis Claude, Codex, Grok ou Grok Bot ?

Chaque agent supporté utilise le même plugin officiel. Les agents terminal (Claude Code, ChatGPT Codex, Grok Build) l’installent avec des commandes marketplace ; Meta Muse, Grok Bot, ChatGPT dots, Gemini Spark et Hermes l’installent depuis une invite de clavardage. La configuration ne diffère que par cette première étape, alors suivez le guide de votre agent : Meta Muse, Grok Bot, ChatGPT dots, Claude Code, Hermes, ChatGPT Codex, Gemini Spark ou Démarrer pour Grok Build. Le flux de publication ci-dessous est le même partout.

Comment utiliser screenRIG dans un agent

Décrivez le contenu, l’écran cible, la mise en page ou les dimensions, le calendrier, et la preuve souhaitée à la fin. Rendez les ressources et les faits sources disponibles à l’agent.

Si le plugin doit être installé, collez :

Invite d’installation

I authorize you to install the official screenRIG plugin from https://github.com/screenrig/plugin.

Ensuite, donnez-lui une tâche d’écran, par exemple :

Créer un écran d’accueil en utilisant le logo joint et les heures d’ouverture. Publiez-le sur l’écran du hall, puis montrez-moi une capture d’écran et vérifiez la lecture.

Exemple de requête seulement. L’agent doit utiliser les actifs, faits et écran réels que vous fournissez.

Si une commande retourne not_enrolled, cette installation n’a pas encore de compte. Créez-en un avec screenrig agent enroll --email ADDRESS --organization NAME. Quand l’utilisateur a déjà un compte, exécutez plutôt screenrig login : il affiche une adresse de tableau de bord et un code, et une personne approuve la connexion pour un de ses projets, choisissant Lecture seule, Proposer ou Gérer et les domaines de capacité que l’agent obtient : screens, content, playlists, advertising, reports et project. Lecture seule liste et lit ; Proposer téléverse aussi des médias et propose des modifications qu’une personne examine avant leur diffusion ; Gérer modifie, publie et dépense aussi. Une commande hors des domaines approuvés retourne 403 forbidden, et une modification d’une session Lecture seule retourne 403 insufficient_access. Comment fonctionne la connexion. D’autres erreurs de première exécution sont cartographiées dans Quand la première exécution échoue.

Préparer la tâche

Conserver les ressources sources et les faits disponibles pour l’agent. Identifier le lecteur visé, les dimensions, le calendrier et les critères d’achèvement. Le flux de publication est le même pour tous les agents pris en charge ; les différences d’installation sont dans Démarrer.

Pour les applications kiosque, utilisez le SDK navigateur. Pour les horaires et tranches horaires, fournissez le fuseau horaire de l’écran et les fenêtres de jour et d’heure prévues.

Que fait l’agent de façon continue ?

L’agent téléverse des médias existants, génère des designs complets présentables, place des cartes intégrées pour le texte qui change, ou publie des vidéos en direct, pages web et applications. Il prépare ensuite une liste de lecture avec playlist init et la publie avec screen publish. Pour modifier une liste existante, utilisez playlist show --output et playlist update. Voir la référence du flux CLI.

Utilisez la génération de page complète pour les affiches et les menus. Utilisez une carte intégrée pour les textes, tableaux et panneaux qui changent. L’animation ne change pas le choix. Lisez le guide de décision de création.

Pour les applications, utilisez emit lorsque l’agent doit agir sur un événement nommé, log pour les diagnostics, et kv pour l’état qui persiste entre les versions. Lisez la référence du SDK.

Comment l’agent gère-t-il une flotte ?

Étiquetez les écrans par usage et classez-les dans des dossiers par lieu, puis ciblez l’étiquette ou le dossier. Lorsqu’un lecteur est jumelé, l’agent nomme l’écran et l’étiquette : screen pair CODE, puis screen tag scr_ID --add Lobby,Floor2. Chaque écran porte jusqu’à 16 étiquettes et se trouve dans au plus un dossier (screen move scr_ID --folder sfd_ID).

01
Publiez une fois. playlist create crée la liste de lecture, et screen assign --tag Lobby --playlist-id ID pointe tous les écrans Lobby actifs dessus en une seule action de flotte.
02
Agir sur la flotte. screen reload, screen toast et screen tag prennent le même --tag ou plusieurs identifiants d’écran. Une commande de flotte est une action facturée sans limite du nombre d’écrans. Le CLI suit automatiquement les pages de résultats limitées et attend la réinitialisation des budgets de contrôle, en conservant la même clé d’action. La réponse liste chaque écran comme ok ou avec son propre problème, ainsi l’agent rapporte précisément quels écrans ont échoué et agit sur eux par identifiant.
03
Vérifiez sur l’écran. screen screenshot --tag Lobby --output lobby-shots capture chaque écran tagué dans un dossier. Inspectez chaque image avant de signaler la flotte mise à jour.
04
Surveillez les déconnexions. Gardez events follow ouvert. screen.offline arrive une fois qu’un écran est hors ligne depuis 60 secondes et screen.online quand il revient ; les deux sont gratuits sur le flux d’écoute.

Lire les commandes de la flotte.

Comment l’agent gère-t-il les tranches horaires et les prises de contrôle ?

Une programmation de liste de lecture change ce qu’un écran joue selon l’heure de la journée ; une campagne fait basculer toute une flotte vers une seule liste de lecture pour ses dates ou ses heures ; une prise de contrôle interrompt tout pour une annonce et se termine d’elle-même.

01
Attribuer une tranche horaire à un écran. Créez une liste de lecture par tranche horaire avec playlist create, gardez une valeur par défaut assignée avec screen assign et assurez-vous que l’écran a un fuseau horaire. Écrivez les entrées dans un fichier et exécutez screen schedule set scr_ID --file dayparts.json, ou --tag Cafe pour chaque écran de café. screen show rapporte effective_playlist avec son source et until, pour que l’agent puisse confirmer quelle tranche horaire est active et quand elle change.
02
Mener une campagne sur une flotte. Pour les menus du midi dans chaque magasin north, campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00 fait basculer chaque écran à son propre 11:00 local, puis le ramène à 14:00, et un écran étiqueté north par la suite l’obtient aussi. Chaque écran a besoin d’une liste de lecture par défaut et d’un fuseau horaire. campaign screens cmp_ID liste chaque écran que la campagne atteint avec son état (playing, pending, waiting avec next_start, outranked, blocked), et campaign explain scr_ID indique pourquoi un écran ne la joue pas. Utilisez --from et --until pour les dates d’une promotion, --monthly, --date et --except pour les dates mensuelles et ponctuelles, --on-touch pour un niveau qui joue tant que quelqu’un utilise l’écran, et --priority quand deux campagnes peuvent être en vigueur en même temps. Les changements de campagne nécessitent l’accès Gérer.
03
Prendre le contrôle pour une urgence ou un lancement. screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill" place une liste de lecture sur chaque écran du hall avant les campagnes, les horaires et affectations. Utilisez --until pour une fin fixe, ou --until none pour la maintenir jusqu’à screen takeover clear --tag Lobby.
04
Vérifiez et surveillez. Demandez screen screenshot --tag Lobby une fois la prise de contrôle en direct, et suivez screen.takeover_started, screen.takeover_ended et screen.playlist_switched dans le journal des événements. screen.playlist_unavailable signifie qu’une liste de lecture programmée n’a pas pu être affichée.

Lire les commandes d’horaire et de prise de contrôle et les commandes de campagne. Pour programmer plusieurs écrans à partir d’un tableur, utilisez l’importation d’horaires.

Brouillons, test et promotion, historique

Un changement de ce qui est diffusé peut commencer comme brouillon, atteindre d’abord quelques écrans de test, être vérifié avant d’être fait et être rétabli à partir de son historique.

01
Créez un brouillon. campaign create --paused crée une campagne qui n’atteint aucun écran, et "paused": true sur une entrée d’horaire dans un fichier screen schedule set fait de même pour cette entrée. Un brouillon n’est dans la pile d’aucun écran, et le calendrier l’affiche en pointillés.
02
Vérifiez avant le changement. campaign preview prend les flags de campaign create ou campaign update, et screen schedule preview scr_ID --file FILE prend le fichier d’horaire. Aucun des deux n’écrit quoi que ce soit. Chacun liste les écrans qui gagneraient ou perdraient le niveau, et le calendrier avant et après sur une semaine, ou jusqu’à 93 jours avec --calendar-from et --calendar-to. campaign preview cmp_ID --publish prévisualise la publication d’un brouillon.
03
Testez-le. campaign publish cmp_ID --test-folder sfd_TEST ou --test-screen scr_A,scr_B sort le brouillon de la pause pour ces écrans seulement. Vérifiez-les avec screen screenshot. campaign publish cmp_ID sans option de test l’envoie à sa propre audience.
04
Promouvez-le. campaign promote cmp_ID --revision N donne à la campagne l’audience de sa révision de brouillon N, la révision en pause que liste campaign revisions cmp_ID, de sorte qu’elle atteigne les vrais écrans.
05
Lisez l’historique et restaurez. campaign revisions cmp_ID et screen schedule revisions scr_ID listent chaque version, la plus récente d’abord. campaign restore cmp_ID --revision N et screen schedule restore scr_ID --revision N copient une version antérieure vers l’avant comme nouvelle révision et laissent les autres telles quelles. Une restauration d’horaire depuis une session Propose attend l’approbation d’une personne, comme screen schedule set ; une restauration de campagne exige l’accès Manage.

Le tableau de bord offre les mêmes commandes : une vue Historique liste les changements avec Restaurer et Remettre en place, et publier, promouvoir ou restaurer montre son avant et son après pour confirmation.

Lisez les commandes de campagne et les commandes d’horaire.

Comment l’agent rapporte-t-il la preuve de lecture ?

Chaque début visible d’une image ou d’une vidéo est un enregistrement de lecture, ainsi l’agent peut fournir à un client, un annonceur ou un auditeur les lectures exactes pour une période.

01
Choisissez la période. Un rapport couvre jusqu’à 31 jours de lectures, filtré par --screen-id, --media-id ou --tag. Utilisez des instants RFC 3339 pour les périodes calendaires, ou des âges comme 7d.
02
Exporter. screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv écrit une ligne par lecture dans une seule requête facturée. screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 ajoute les totaux quotidiens.
03
Vérifier et remettre. L’enveloppe rapporte rows, bytes et sha256 ; citez-les avec le fichier. Si le flux échoue en cours de route, suivez error.next, qui exporte le reste de la plage dans un second fichier.

Lire les commandes de lecture.

Comment l’agent trie-t-il la santé et définit-il les heures d’affichage ?

Les rapports de santé et le contrôle d’affichage permettent à l’agent de garder les écrans allumés et sombres après les heures sans personne sur place.

01
Triage. screenrig alerts list montre ce qui est ouvert maintenant, une alerte par écran et par condition, et screenrig screen list --human signale les écrans nécessitant une attention dans sa colonne HEALTH. screenrig screen show scr_ID donne le rapport complet : connexion de l’afficheur, température, batterie, temps de fonctionnement, plantages, et si le rapport est périmé. Il donne aussi la cause probable de la dernière panne lorsque screenRIG peut la déterminer : l’appareil a redémarré, le Player a redémarré ou planté, le réseau de l’écran, ou une interruption de screenRIG. screenrig alerts ack ID acquitte une alerte sur laquelle quelqu’un travaille, et alerts snooze ID --for 4h la met de côté pendant 4 heures. Créez une notification pour screen_offline, display_disconnected, running_hot, not_playing et crashing afin qu’un avis déclenche ce travail.
02
Réparer dans l’ordre le moins perturbant. screen reload actualise le contenu. Si le Player déclare restart_app, screen restart-app scr_ID redémarre l’application du Player; s’il déclare clear_cache, screen clear-cache scr_ID vide ses caches et télécharge de nouveau le contenu; s’il déclare reboot, screen reboot scr_ID redémarre l’appareil; une flotte nécessite --yes. Un écran hors ligne reçoit n’importe laquelle de ces commandes lorsqu’il revient en ligne dans les 24 heures. Pour un redémarrage récurrent, screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" fait redémarrer chaque écran par screenRIG au début de la fenêtre, dans son propre fuseau horaire; un écran hors ligne à ce moment ne conserve le redémarrage que jusqu’à la fin de la fenêtre, et un redémarrage qui se termine en dix minutes ne déclenche aucune alerte hors ligne. screen update-software scr_ID installe la plus récente version du Player là où le Player déclare update. Un afficheur déconnecté nécessite généralement une présence sur place; indiquez-le dans le rapport.
03
Définir la mise hors tension hors heures. Écrivez les heures d’ouverture dans un fichier et exécutez screenrig screen display-schedule set --tag Cafe --file hours.json ; le Player éteint l’afficheur en dehors de ces plages, même hors ligne. Pour un cas ponctuel, screen display scr_ID --power on --for 2h remplace la programmation jusqu’à sa prochaine limite ou l’heure donnée. screen display-idle scr_ID --after 300 --wake touch,presence assombrit un écran que personne n’utilise et le rallume lorsque quelqu’un le touche ou s’approche.
04
Confirmer. screen show rapporte la puissance d’affichage atteinte par le Player, screen.display_changed et screen.reboot_requested apparaissent dans le journal des événements, et la commande dans commands se termine par done ou failed avec sa cause.
05
Vérifier l’affichage. screenrig screen show scr_ID affiche Playlist stalled lorsqu’un écran est en ligne avec un contenu à jour, mais qu’aucun démarrage d’image ou de vidéo n’est parvenu à screenRIG depuis plus longtemps que sa boucle ne le permet, et Blank screen ou Frozen picture lorsque les captures d’écran que screenRIG a prises sur une série couvrant toute la boucle étaient toutes d’un seul ton uni ou toutes la même image. Une notification sur loop_stalled, glass_blank ou glass_frozen l’annonce, et screen screenshot indique si une image est unie, ce qui ne constitue pas un verdict à lui seul. Les vérifications ne disent rien d’un écran dont l’affichage est éteint, qui est sous une prise de contrôle, qui montre une seule image fixe ou un mur vidéo, ou dont le Player n’envoie pas de numéros de lecture; un écran silencieux n’est donc pas la preuve qu’il joue.

Lire les commandes de santé et d’alimentation de l’appareil.

Comment être alerté, ou réveiller un agent, lorsqu’un événement survient ?

Une notification envoie un courriel à des personnes, publie dans Slack, Teams, PagerDuty ou Telegram, ou fait un POST d’une requête HTTPS signée, lorsqu’un écran est hors ligne, perd son affichage, surchauffe, fonctionne sur sa batterie, ne peut pas stocker son contenu, reste bloqué sur une mise à jour de contenu, affiche une erreur au lieu de lire son contenu, plante sans cesse, cesse d’avancer dans sa liste de lecture, devient noir ou se fige. Une personne est avertie, ou un agent se met au travail, sans que personne ne surveille un flux. Chaque projet envoie déjà un courriel à son propriétaire lorsqu’un écran est hors ligne depuis 10 minutes, et les courriels de notification et les avis d’écran sont gratuits.

Trois écrans ou plus qui passent dans un même état en cinq minutes et qui partagent un réseau, un emplacement, un modèle, une version du Player ou une étiquette font l'objet d'un seul avis et d'un seul rétablissement, dans un courriel ou un message de messagerie ou d'outil d'alerte, qui indique ce qu'ils partagent et leur nombre; un webhook signé envoie toujours un POST par écran. Un message de rétablissement ne dit qu’un écran est de retour que si screenRIG l’a constaté : lorsqu’un écran bloqué, noir ou figé cesse simplement d’être vérifié, parce qu’il est passé hors ligne ou que son affichage s’est éteint, l’alerte se ferme et aucun message de rétablissement n’est envoyé.

01
Envoyer un courriel à une personne. screenrig notifications create --email owner --conditions screen_offline,display_disconnected envoie un courriel au propriétaire du projet ; ajoutez les identifiants d’utilisateur des membres du projet après owner pour les inclure. --tag Lobby limite la notification aux écrans étiquetés, et un avis attend --hold minutes (10 par défaut), donc une reconnexion rapide reste silencieuse. Un courriel de résolution suit lorsque l’écran se rétablit. Chaque courriel contient un lien de désabonnement qui ne concerne que son destinataire, et screenrig notifications resubscribe ID --user USER_ID réabonne une personne. Pour réveiller un agent ou un autre système à la place, utilisez un webhook.
02
Publier dans une messagerie ou un outil d'alerte. screenrig notifications create --slack - --conditions screen_offline publie dans un canal Slack, et --teams, --pagerduty et --telegram font de même pour Teams, PagerDuty et Telegram. Slack prend l'URL d'un webhook entrant, Teams l'URL d'un webhook Workflows, PagerDuty une clé d'acheminement de l'API Events v2, et Telegram un jeton de bot avec --telegram-chat CHAT_ID. Un - lit le justificatif depuis une ligne de stdin pour qu'il reste hors de l'historique du shell; screenRIG le scelle et n'affiche qu'un destination_hint masqué. Chaque panne publie une seule fois par écran, PagerDuty ouvre un seul incident, et le rétablissement suit une fois ce message envoyé, en résolvant l'incident. screenrig notifications test ID publie un message de test; pour PagerDuty, il ouvre un événement d'information et le résout aussitôt.
03
Exécuter un récepteur. Tout point de terminaison HTTPS que vous contrôlez sur le port 443 ou 8443 : un petit service, une fonction serverless ou le déclencheur entrant de votre plateforme d’agent ou de bot. Il vérifie ScreenRig-Signature avec le secret webhook, déduplique sur ScreenRig-Event-Id, et répond 2xx en moins de 10 secondes.
04
S’abonner. screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashing retourne le secret de signature une fois ; stockez-le dans le magasin de secrets du récepteur. Ajoutez --events application.event pour recevoir aussi les événements bruts du projet. screenrig notifications test ID envoie un POST de test signé pour prouver le chemin.
05
Transmission. Le récepteur lance une exécution d’agent avec l’avis comme tâche : il déclenche un travail d’agent programmé ou à la demande, ou publie l’avis dans le clavardage où Grok Bot ou un autre agent avec le plugin screenRIG travaille. Par exemple : « L’écran scr_LOBBY est passé hors ligne à 14:02. Vérifiez-le et faites un rapport. » L’agent travaille ensuite via le plugin comme d’habitude, avec screen show, screen reload et une capture d’écran.
06
Gardez-la en bonne santé. screenrig notifications deliveries ID liste chaque tentative et dit pourquoi un avis n’a pas été envoyé. Une notification qui échoue pendant 72 heures consécutives est désactivée ; screenrig notifications update ID --enable reprend à l’événement actuel. --snooze 2h met les avis en sourdine pendant la maintenance.
07
Mettre des écrans en sourdine pour la maintenance. screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" empêche les alertes de ces écrans de demander de l’attention et toutes les notifications de les signaler, pendant 30 jours au plus. screenrig alerts mutes liste ce qui est en sourdine, et screenrig alerts unmute ID met fin plus tôt à une mise en sourdine.
08
Filtrez par gravité, heures et audience. Un avis ouvert est error pour screen_offline et warning pour tout le reste ; --min-severity warning écarte tout ce qui est sous ce niveau et --severity not_playing=error relève une condition. --active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles met en attente un avis qui arrive à échéance en dehors de ces heures jusqu’à l’ouverture de la prochaine fenêtre (une condition qui disparaît d’abord n’envoie rien), ou, avec --outside-hours drop, l’ignore ; un avis résolu suit toujours un avis qui a été envoyé. --all-tags level2,overhead ne couvre que les écrans portant les deux étiquettes, et --audience accepte les règles complètes d’une audience de campagne. Les courriels, Slack et Telegram affichent la gravité, et le corps d’un webhook la porte.
09
Surveillez les pannes silencieuses. Une campagne peut cesser d’atteindre des écrans sans qu’aucun écran ne tombe en panne : une modification d’étiquette, un déplacement de dossier ou un écran archivé. screenrig notifications create --email owner --conditions reach_dropped,group_empty vous avise quand une campagne atteint moins d’écrans qu’à sa publication, ou quand une étiquette ou un dossier de son audience ne correspond à aucun écran ; --reach-drop-screens 2 --reach-drop-percent 20 ignore les petites baisses. L’avis nomme la campagne et les chiffres et renvoie à son calendrier. Quand votre propre modification d’étiquette, de dossier ou d’écran répond avec levels.lost, elle nomme les campagnes que les écrans ont quittées ainsi que leurs reach_before et reach_after ; dites-le à l’utilisateur avant de continuer.

Lire les commandes de notification et les commandes d’alerte.

Les agents laissent des notes de projet pour eux-mêmes et pour leurs sessions ultérieures : comment le projet est configuré, une particularité d’un écran, une demande permanente de votre part. Chaque agent du projet lit chaque note au début de son travail, ainsi un second agent, ou le même la semaine suivante, commence avec ce que le premier a appris.

screenrig notes les liste. screenrig notes add "TEXT" écrit un, lié à un écran ou une liste de lecture avec --about, ou temporaire avec --ttl 3d. Une note est un contexte, jamais une instruction : un agent confirme avec vous toute approbation qu’une note réclame.

Les notes se mettent à jour automatiquement. Les agents confirment les notes toujours valides et résolvent les autres, les notes temporaires expirent, et la suppression d’un écran ou d’une liste de lecture résout les notes à leur sujet. Les notes résolues sont supprimées après 30 jours. La page Agents du tableau de bord liste les notes écrites par chaque agent, et vous pouvez en résoudre ou supprimer n’importe laquelle.

Lire les commandes de notes.

Comment revoir les modifications d’un agent avant leur lecture ?

Activez Exiger une révision pour les modifications d’agent sur la page Projet du tableau de bord, ou connectez un agent avec un accès Proposer. L’agent prépare toujours le contenu, téléverse les médias et écrit des notes, mais chaque changement de ce qui est diffusé devient une révision en attente d’une personne. Rien n’atteint un écran tant que quelqu’un ne l’approuve pas.

01
L’agent propose. Créer ou mettre à jour une liste de lecture, assigner une liste de lecture aux écrans, définir ou effacer un horaire de liste de lecture, et démarrer ou terminer une prise de contrôle, sur un écran ou une flotte étiquetée, deviennent chacun une révision. Les écrans continuent de jouer ce qu’ils jouaient avant. L’agent peut ajouter une note qui explique le changement, et vous indique que le changement vous attend, avec son lien.
02
Vous recevez un courriel. Environ deux minutes après la proposition, le propriétaire du projet et la personne responsable de l’agent, lorsqu’ils peuvent approuver, reçoivent un courriel nommant la modification et combien d’écrans elle met à jour, avec un bouton Examiner la modification. Quand l’agent a laissé une note, le courriel le mentionne ; vous la lisez dans Examens. Plusieurs modifications en attente arrivent en un seul courriel qui les liste, avec un bouton Ouvrir les examens, et une rafale d’éditions sur une modification envoie un courriel, pour la version la plus récente. Ouvrir le lien n’approuve jamais rien.
03
Décider dans les révisions. La page Révisions du tableau de bord liste chaque changement en attente, avec les décidés en dessous. Un changement de liste de lecture montre les listes en direct et proposées côte à côte, avec les pages marquées Ajoutées, Modifiées ou Retirées. Approuver l’applique aux écrans ; Demander des modifications envoie à l’agent votre note pour qu’il révise et propose à nouveau ; Rejeter ferme avec votre raison. Quand une nouvelle liste de lecture et son assignation d’écran attendent ensemble, approuver la liste offre d’approuver aussi l’assignation. Un changement pour une grande flotte s’applique en arrière-plan, et la révision montre le résultat de chaque écran à mesure qu’il arrive.
04
L’agent fait le suivi. L’agent lit la décision avec screenrig reviews show ID ou son événement, révise après une demande de changement ou un rejet, et vérifie les écrans après une approbation.

Le propriétaire du projet peut toujours approuver, et chaque membre le peut sauf si le propriétaire désactive Peut approuver pour lui sur la page Personnes. Les agents d’un membre qui ne peut pas approuver travaillent au plus au niveau Proposer. Une proposition devient périmée quand la liste de lecture active change après qu’elle a été faite ; l’agent propose de nouveau par-dessus la nouvelle version. L’approbation d’une modification de liste de lecture devient aussi périmée quand ses sélecteurs tag, folder ou all joueraient maintenant des médias qu’elle ne voyait pas quand elle a été proposée. Un dossier marqué protégé envoie à un second approbateur chaque modification qui atteint ses écrans ; voir Autorisations par dossier d’écrans.

Les modifications des médias attendent aussi. Un nouveau téléversement joue dans les playlists d’étiquette, de dossier et Toutes seulement après approbation par une personne, et quand un agent retague ou déplace des médias approuvés, les écrans continuent de les lire comme approuvés jusqu’à approbation du changement. Chaque élément reçoit sa propre révision qui montre ses étiquettes et dossier avant et après, et liste les playlists qu’il rejoindrait ou quitterait et combien d’écrans elles atteignent. L’approbation applique le changement à toutes ; le rejet ou la demande de modifications remettent un élément retagué ou déplacé tel qu’approuvé, et un téléversement rejeté reste hors écran. Un fichier de remplacement ou une version restaurée d’un média approuvé attend de la même façon, et l’ancien fichier continue de jouer jusqu’à l’approbation d’une personne. Les réseaux publicitaires révisent les créations des acheteurs dans la même page Révisions. Niveaux d’accès et paramètres de révision · Commandes de révision.

Qu’est-ce qui compte comme complet ?

Confirmez que la playlist prévue est assignée à l’écran prévu, ou à chaque écran de la flotte. Demandez une capture d’écran, une par écran étiqueté pour une flotte, inspectez les enregistrements de lecture, et examinez les événements pertinents, y compris tout screen.offline. Signalez ce que ces observations établissent et toute incertitude restante. Un changement en attente de révision n’est pas encore visible : signalez son lien de révision, et vérifiez à nouveau après qu’une personne décide.

Une commande réussie est une étape dans cette preuve. Elle n’établit pas à elle seule qu’un écran physique a affiché le résultat voulu.