Por que nativo do agente?

screenRIG foi construído para agentes autônomos desde o plano de controle. O plugin oficial oferece comandos estruturados para mídia, playlists, telas, aplicativos e evidências de reprodução. Os resultados são envelopes JSON, todo erro diz o que fazer a seguir, gravações repetidas reutilizam chaves de idempotência, e a publicação informa se o Player está realmente reproduzindo o conteúdo. O agente pode executar uma tarefa de tela, inspecionar o resultado e corrigir pelo mesmo ambiente. O que significa ser nativo para agentes.

Como eu executo isso a partir do Claude, Codex, Grok ou Grok Bot?

Cada agente suportado usa o mesmo plugin oficial. Agentes de terminal (Claude Code, ChatGPT Codex, Grok Build) o instalam com comandos do marketplace; Meta Muse, Grok Bot, ChatGPT dots, Gemini Spark e Hermes o instalam a partir de um prompt de chat. A configuração difere apenas nessa primeira etapa, então siga o guia do seu agente: Meta Muse, Grok Bot, ChatGPT dots, Claude Code, Hermes, ChatGPT Codex, Gemini Spark ou Iniciar para Grok Build. O fluxo de publicação abaixo é o mesmo em todos os lugares.

Como usar o screenRIG em um agente

Descreva o conteúdo, a tela alvo, o layout ou dimensões, o tempo e a evidência desejada na conclusão. Disponibilize ativos e fatos-fonte ao agente.

Se o plugin precisar ser instalado, cole:

Prompt de instalação

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

Então dê a ele uma tarefa de tela, por exemplo:

Criar uma tela de boas-vindas usando o logotipo e horário de funcionamento anexados. Publicá-la na tela do lobby, depois mostrar uma captura de tela e verificar a reprodução.

Apenas solicitação de exemplo. O agente deve usar os ativos, fatos e tela reais que você fornecer.

Se um comando retornar not_enrolled, esta instalação ainda não tem conta. Crie uma com screenrig agent enroll --email ADDRESS --organization NAME. Quando o usuário já tem uma conta, execute screenrig login em vez disso: ele imprime um endereço do dashboard e um código, e uma pessoa aprova o login para um de seus projetos, escolhendo Somente leitura, Propor ou Gerenciar e as áreas de capacidade que o agente recebe: screens, content, playlists, advertising, reports e project. Somente leitura lista e lê; Propor também envia mídia e propõe mudanças que uma pessoa revisa antes de reproduzir; Gerenciar também altera, publica e gasta. Um comando fora das áreas aprovadas retorna 403 forbidden, e uma mudança de uma sessão Somente leitura retorna 403 insufficient_access. Como funciona o login. Outros erros da primeira execução são mapeados em Quando a primeira execução falha.

Preparar a tarefa

Mantenha os ativos e fatos da fonte disponíveis para o agente. Identifique o Player pretendido, dimensões, tempo e critérios de conclusão. O fluxo de publicação é o mesmo para agentes suportados; as diferenças de instalação estão em Início.

Para apps de quiosque, use o SDK do navegador. Para cronogramas e faixas horárias, forneça o fuso horário da tela e as janelas de dia e hora pretendidas.

O que o agente faz continuamente?

O agente envia mídias existentes, gera designs completos apresentáveis, coloca cartões integrados para texto que muda ou publica vídeo ao vivo, páginas web e aplicativos. Depois prepara uma playlist com playlist init e publica com screen publish. Para alterar uma playlist existente, use playlist show --output e playlist update. Veja a referência do fluxo CLI.

Use geração de página inteira para pôsteres e menus. Use um cartão integrado para texto, tabelas e quadros que mudam. A animação não altera a escolha. Leia o guia de decisão de autoria.

Para aplicativos, use emit quando o agente deve agir em um evento nomeado, log para diagnósticos e kv para estado que persiste entre versões. Leia a referência do SDK.

Como o agente gerencia uma frota?

Marque as telas por propósito e arquive-as em pastas por local, depois direcione a tag ou a pasta. Quando um Player é pareado, o agente nomeia a tela e a marca: screen pair CODE, depois screen tag scr_ID --add Lobby,Floor2. Cada tela carrega até 16 tags e fica em no máximo uma pasta (screen move scr_ID --folder sfd_ID).

01
Publique uma vez. playlist create cria a playlist, e screen assign --tag Lobby --playlist-id ID aponta todas as telas ativas do Lobby para ela em uma ação de frota.
02
Atue na frota. screen reload, screen toast e screen tag aceitam o mesmo --tag, ou vários IDs de tela. Um comando de frota é uma ação cobrada sem limite de contagem de telas. O CLI segue automaticamente páginas de resultados limitadas e espera o reset dos orçamentos de controle, mantendo a mesma chave de ação. A resposta lista cada tela como ok ou com seu próprio problema, para que o agente reporte exatamente quais telas falharam e aja sobre elas pelo ID.
03
Verifique na tela. screen screenshot --tag Lobby --output lobby-shots captura todas as telas marcadas em um diretório. Inspecione cada imagem antes de relatar a frota atualizada.
04
Fique atento a quedas. Mantenha events follow aberto. screen.offline chega quando uma tela fica offline por 60 segundos e screen.online quando retorna; ambos são gratuitos no stream de escuta.

Leia os comandos da frota.

Como o agente gerencia dayparts e takeovers?

Uma programação de playlist muda o que uma tela toca por hora do dia; uma campanha muda uma frota inteira para uma playlist durante suas datas ou horas; um takeover interrompe tudo para um anúncio e termina sozinho.

01
Definir faixa horária para uma tela. Crie uma playlist por faixa horária com playlist create, mantenha uma padrão atribuída com screen assign e certifique-se de que a tela tenha um fuso horário. Grave as entradas em um arquivo e execute screen schedule set scr_ID --file dayparts.json, ou --tag Cafe para cada tela de café. screen show relata effective_playlist com seu source e until, para que o agente possa confirmar qual faixa horária está ativa e quando muda.
02
Execute uma campanha em uma frota inteira. Para cardápios de almoço em todas as lojas north, campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00 muda cada tela às 11:00 do seu próprio horário local e de volta às 14:00, e uma tela marcada com north mais tarde também a recebe. Cada tela precisa de uma playlist padrão e de um fuso horário. campaign screens cmp_ID lista todas as telas que a campanha alcança com sua situação (playing, pending, waiting com next_start, outranked, blocked), e campaign explain scr_ID diz por que uma tela não a reproduz. Use --from e --until para as datas de uma promoção, --monthly, --date e --except para datas mensais e avulsas, --on-touch para um nível que toca enquanto alguém usa a tela, e --priority quando duas campanhas podem vigorar ao mesmo tempo. Alterações em campanhas precisam de acesso Gerenciar.
03
Assuma o controle para uma emergência ou lançamento. screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill" coloca uma playlist em todas as telas do Lobby antes de campanhas, horários e atribuições. Use --until para um fim fixo, ou --until none para mantê-la até screen takeover clear --tag Lobby.
04
Verifique e acompanhe. Solicite screen screenshot --tag Lobby assim que a tomada estiver ativa e acompanhe screen.takeover_started, screen.takeover_ended e screen.playlist_switched no log de eventos. screen.playlist_unavailable significa que uma playlist agendada não pôde ser exibida.

Leia os comandos de programação e takeover e os comandos de campanha. Para programar muitas telas a partir de uma planilha, use Importação de programação.

Rascunhos, teste e promoção, histórico

Uma mudança no que é reproduzido pode começar como rascunho, alcançar primeiro algumas telas de teste, ser conferida antes de ser feita e ser recuperada do seu histórico.

01
Crie um rascunho. campaign create --paused cria uma campanha que não alcança nenhuma tela, e "paused": true em uma entrada de cronograma de um arquivo screen schedule set faz o mesmo com essa entrada. Um rascunho não está na pilha de nenhuma tela, e o calendário o mostra tracejado.
02
Confira antes da mudança. campaign preview aceita os flags de campaign create ou campaign update, e screen schedule preview scr_ID --file FILE aceita o arquivo de cronograma. Nenhum dos dois grava nada. Cada um lista as telas que ganhariam ou perderiam o nível e o calendário antes e depois ao longo de uma semana, ou de até 93 dias com --calendar-from e --calendar-to. campaign preview cmp_ID --publish mostra de antemão a publicação de um rascunho.
03
Teste. campaign publish cmp_ID --test-folder sfd_TEST ou --test-screen scr_A,scr_B tira o rascunho da pausa somente para essas telas. Confira-as com screen screenshot. campaign publish cmp_ID sem opção de teste o envia ao seu próprio público.
04
Promova. campaign promote cmp_ID --revision N dá à campanha o público da sua revisão de rascunho N, a revisão em pausa que campaign revisions cmp_ID lista, de modo que ela alcance as telas reais.
05
Leia o histórico e restaure. campaign revisions cmp_ID e screen schedule revisions scr_ID listam cada versão, a mais recente primeiro. campaign restore cmp_ID --revision N e screen schedule restore scr_ID --revision N copiam uma anterior para a frente como nova revisão e deixam as outras como estavam. Uma restauração de cronograma de uma sessão Propose aguarda a aprovação de uma pessoa, como screen schedule set; uma restauração de campanha exige acesso Manage.

O dashboard tem os mesmos controles: uma visualização de Histórico lista as mudanças com Restaurar e Mover de volta, e publicar, promover ou restaurar mostra seu antes e depois para confirmação.

Leia os comandos de campanha e os comandos de cronograma.

Como o agente reporta a prova de reprodução?

Cada início visível de uma imagem ou vídeo é um registro de reprodução, para que o agente possa fornecer a um cliente, anunciante ou auditor as reproduções exatas de um período.

01
Escolha o intervalo. Um relatório cobre até 31 dias de reproduções, filtrado por --screen-id, --media-id ou --tag. Use instantes RFC 3339 para períodos do calendário, ou idades como 7d.
02
Exportar. screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv escreve uma linha por reprodução em uma solicitação faturada. screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 adiciona os totais diários.
03
Verificar e entregar. O envelope informa rows, bytes e sha256; cite-os com o arquivo. Se o fluxo falhar no meio, siga error.next, que exporta o restante do intervalo para um segundo arquivo.

Leia os comandos de reprodução.

Como o agente triage a saúde e define as horas de exibição?

Relatórios de saúde e controle de exibição permitem que o agente mantenha as telas funcionando e escuras após o expediente sem ninguém no local.

01
Triagem. screenrig alerts list mostra o que está aberto agora, um alerta por tela e condição, e screenrig screen list --human sinaliza telas que precisam de atenção na sua coluna HEALTH. screenrig screen show scr_ID fornece o relatório completo: conexão do monitor, temperatura, bateria, tempo ativo, falhas e se o relatório está desatualizado. Também informa a causa provável da última queda quando o screenRIG consegue determiná-la: o dispositivo reiniciou, o Player reiniciou ou travou, a rede da tela ou uma interrupção do screenRIG. screenrig alerts ack ID marca um alerta em que alguém está trabalhando, e alerts snooze ID --for 4h o deixa de lado por 4 horas. Crie uma notificação para screen_offline, display_disconnected, running_hot, not_playing e crashing a fim de que um aviso inicie esse trabalho.
02
Corrija na ordem menos disruptiva. screen reload atualiza o conteúdo. Se o Player declarar restart_app, screen restart-app scr_ID reinicia o aplicativo do Player; se declarar clear_cache, screen clear-cache scr_ID limpa seus caches e baixa o conteúdo novamente; se declarar reboot, screen reboot scr_ID reinicia o dispositivo; uma frota precisa de --yes. Uma tela offline recebe qualquer um deles quando volta em até 24 horas. Para um reinício recorrente, screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" faz o screenRIG reiniciar cada tela no início da janela, no fuso horário da própria tela; uma tela offline nesse horário mantém o reinício apenas até o fim da janela, e um reinício concluído em até dez minutos não gera alerta de offline. screen update-software scr_ID instala a versão mais recente do Player onde o Player declarar update. Um display desconectado geralmente precisa de alguém no local; informe isso no relatório.
03
Defina a energia fora do expediente. Grave o horário de funcionamento em um arquivo e execute screenrig screen display-schedule set --tag Cafe --file hours.json; o Player desliga o monitor fora desses horários, mesmo offline. Para uma exceção, screen display scr_ID --power on --for 2h substitui a programação até o próximo limite ou o tempo dado. screen display-idle scr_ID --after 300 --wake touch,presence escurece uma tela que ninguém está usando e a acende de novo quando alguém a toca ou se aproxima.
04
Confirmar. screen show relata a potência do display que o Player alcançou, e screen.display_changed e screen.reboot_requested aparecem no registro de eventos, e o comando em commands termina em done ou failed com sua causa.
05
Verificar a tela. screenrig screen show scr_ID mostra Playlist stalled quando uma tela está online com conteúdo atual, mas nenhum início de imagem ou vídeo chegou ao screenRIG por mais tempo do que o seu loop permite, e Blank screen ou Frozen picture quando as capturas de tela que o screenRIG fez ao longo de uma série que cobre todo o loop eram todas de um único tom liso ou todas a mesma imagem. Uma notificação em loop_stalled, glass_blank ou glass_frozen avisa isso, e screen screenshot informa se uma imagem é lisa, o que sozinho não é um veredito. As verificações não dizem nada sobre uma tela com o display desligado, sob um takeover, que mostra uma única imagem estática ou um videowall, ou cujo Player não envia números de reprodução; por isso, uma tela silenciosa não é prova de que está reproduzindo.

Leia os comandos de saúde e energia do dispositivo.

Como eu recebo um alerta, ou acordo um agente, quando algo acontece?

Uma notificação envia e-mail a pessoas, publica no Slack, Teams, PagerDuty ou Telegram, ou envia uma requisição HTTPS assinada quando uma tela fica offline, perde o display, esquenta demais, passa a funcionar na bateria, não consegue armazenar o conteúdo, trava em uma atualização de conteúdo, mostra um erro em vez de reproduzir, trava sem parar, deixa de avançar na playlist, fica preta ou congela. Uma pessoa fica sabendo, ou um agente começa a trabalhar, sem ninguém acompanhando um stream. Todo projeto já envia e-mail ao proprietário quando uma tela fica 10 minutos offline, e os e-mails de notificação e os avisos de tela são gratuitos.

Três ou mais telas que entram na mesma condição em até cinco minutos e compartilham uma rede, um local, um modelo, uma versão do Player ou uma tag viram um único aviso, com uma única recuperação, em um e-mail ou em uma mensagem de chat ou de uma ferramenta de alertas, que diz o que elas compartilham e quantas são; um webhook assinado continua enviando um POST por tela. Uma mensagem de recuperação só diz que uma tela voltou quando o screenRIG viu isso: quando uma tela travada, preta ou congelada simplesmente deixa de ser verificada, porque ficou offline ou o display foi desligado, o alerta se fecha e nenhuma mensagem de recuperação é enviada.

01
Envie um e-mail para uma pessoa. screenrig notifications create --email owner --conditions screen_offline,display_disconnected envia e-mail para o proprietário do projeto; adicione os ids de usuário dos membros do projeto após owner para incluí-los. --tag Lobby limita a notificação a telas marcadas, e um aviso espera --hold minutos (10 por padrão), para que uma reconexão rápida fique silenciosa. Um e-mail de resolução chega em seguida, quando a tela se recupera. Cada e-mail tem um link de cancelamento de inscrição que vale só para o destinatário dele, e screenrig notifications resubscribe ID --user USER_ID volta a enviar e-mails a uma pessoa. Para acordar um agente ou outro sistema, use um webhook em vez disso.
02
Publicar em um chat ou em um sistema de plantão. screenrig notifications create --slack - --conditions screen_offline publica em um canal do Slack, e --teams, --pagerduty e --telegram fazem o mesmo para Teams, PagerDuty e Telegram. O Slack recebe a URL de um webhook de entrada, o Teams a URL de um webhook do Workflows, o PagerDuty uma chave de roteamento da API Events v2 e o Telegram um token de bot com --telegram-chat CHAT_ID. Um - lê a credencial de uma linha do stdin para que ela fique fora do histórico do shell; o screenRIG a sela e mostra apenas um destination_hint mascarado. Cada queda publica uma vez por tela, o PagerDuty abre um único incidente e a recuperação vem depois que essa mensagem foi enviada, resolvendo o incidente. screenrig notifications test ID publica uma mensagem de teste; no PagerDuty, abre um evento informativo e o resolve na hora.
03
Execute um receptor. Qualquer endpoint HTTPS que você controle na porta 443 ou 8443: um pequeno serviço, uma função serverless ou o gatilho de entrada da sua plataforma de agente ou bot. Ele verifica ScreenRig-Signature com o segredo webhook, deduplica em ScreenRig-Event-Id e responde 2xx em até 10 segundos.
04
Assine. screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashing retorna o segredo de assinatura uma vez; armazene-o na loja de segredos do receptor. Adicione --events application.event para receber também eventos brutos do projeto. screenrig notifications test ID envia um POST de teste assinado para provar o caminho.
05
Transferência. O receptor inicia uma execução do agente com o aviso como tarefa: aciona um trabalho agendado ou sob demanda do agente, ou publica o aviso no chat onde Grok Bot ou outro agente com o plugin screenRIG atua. Por exemplo: “Tela scr_LOBBY ficou offline às 14:02. Verifique e reporte.” O agente então trabalha pelo plugin como de costume, com screen show, screen reload e uma captura de tela.
06
Mantenha-a saudável. screenrig notifications deliveries ID lista todas as tentativas e diz por que um aviso não foi enviado. Uma notificação que falha por 72 horas seguidas é desativada; screenrig notifications update ID --enable retoma no evento atual. --snooze 2h pausa os avisos durante a manutenção.
07
Silencie telas durante a manutenção. screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" impede, por até 30 dias, que os alertas dessas telas peçam atenção e que qualquer notificação envie avisos sobre elas. screenrig alerts mutes lista o que está silenciado, e screenrig alerts unmute ID encerra um silenciamento antes do fim.
08
Filtre por severidade, horário e público-alvo. Um aviso aberto é error para screen_offline e warning para todo o resto; --min-severity warning descarta tudo abaixo desse nível e --severity not_playing=error eleva uma condição. --active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles retém um aviso que vence fora desses horários até a próxima abertura da janela (uma condição que termina antes não envia nada), ou com --outside-hours drop o ignora; um aviso de resolvido sempre acompanha um que foi enviado. --all-tags level2,overhead cobre apenas telas com ambas as tags, e --audience aceita as regras completas de um público-alvo de campanha. E-mails, Slack e Telegram mostram a severidade, e o corpo de um webhook a carrega.
09
Atenção a falhas silenciosas. Uma campanha pode deixar de alcançar telas sem que nenhuma tela falhe: uma edição de tag, uma movimentação de pasta ou uma tela arquivada. screenrig notifications create --email owner --conditions reach_dropped,group_empty avisa quando uma campanha alcança menos telas do que quando foi publicada, ou quando uma tag ou pasta de seu público-alvo não corresponde a nenhuma tela; --reach-drop-screens 2 --reach-drop-percent 20 ignora quedas pequenas. O aviso nomeia a campanha e os números e traz um link para o calendário dela. Quando sua própria edição de tag, pasta ou tela responde com levels.lost, ela nomeia as campanhas que as telas deixaram e seus reach_before e reach_after; diga isso ao usuário antes de seguir adiante.

Leia os comandos de notificação e os comandos de alerta.

Agentes deixam notas de projeto uns para os outros e para suas próprias sessões futuras: como o projeto está configurado, uma peculiaridade da tela, um pedido constante seu. Todo agente no projeto lê todas as notas ao iniciar o trabalho, assim um segundo agente, ou o mesmo na semana seguinte, começa do que o primeiro aprendeu.

screenrig notes lista-os. screenrig notes add "TEXT" escreve um, vinculado a uma tela ou playlist com --about, ou temporário com --ttl 3d. Uma nota é contexto, nunca uma instrução: um agente confirma com você qualquer aprovação que uma nota alegue.

As notas se mantêm atualizadas sozinhas. Agentes confirmam as notas que ainda valem e resolvem o resto, notas temporárias expiram, e excluir uma tela ou playlist resolve as notas sobre ela. Notas resolvidas são excluídas após 30 dias. A página Agentes do dashboard lista as notas que cada agente escreveu, e você pode resolver ou excluir qualquer uma delas.

Leia os comandos de notas.

Como eu reviso as mudanças de um agente antes de serem reproduzidas?

Ative Exigir revisão para alterações do agente na página do Projeto no dashboard, ou faça um agente entrar com acesso Propor. O agente ainda prepara conteúdo, envia mídia e escreve notas, mas cada alteração no que é exibido vira uma revisão que espera por uma pessoa. Nada chega à tela até que alguém aprove.

01
O agente propõe. Criar ou atualizar uma playlist, atribuir uma playlist a telas, definir ou limpar uma programação de playlist, e iniciar ou terminar uma tomada, em uma tela ou uma frota marcada, cada um vira uma revisão. As telas continuam reproduzindo o que tocavam antes. O agente pode adicionar uma nota que explica a mudança e informa que a mudança está esperando por você, com seu link.
02
Você recebe um e-mail. Cerca de dois minutos após a proposta, o proprietário do projeto e a pessoa responsável pelo agente, quando podem aprovar, recebem um e-mail nomeando a mudança e quantas telas ela atualiza, com um botão Revisar mudança. Quando o agente deixou uma nota, o e-mail informa; você a lê nas Revisões. Várias mudanças aguardando ao mesmo tempo chegam como um único e-mail que as lista, com um botão Abrir Revisões, e uma série de edições para uma mudança envia um e-mail, para a versão mais recente. Abrir o link nunca aprova nada.
03
Decidir nas Revisões. A página Revisões do dashboard lista todas as mudanças pendentes, com as decididas abaixo. Uma mudança na playlist mostra as playlists ativa e proposta lado a lado, com páginas marcadas como Adicionadas, Alteradas ou Removidas. Aprovar aplica nas telas; Solicitar mudanças envia sua nota ao agente para revisar e propor novamente; Rejeitar fecha com seu motivo. Quando uma nova playlist e sua atribuição de tela aguardam juntas, aprovar a playlist oferece aprovar a atribuição junto. Uma mudança para uma frota grande termina de aplicar em segundo plano, e a revisão mostra o resultado de cada tela conforme chega.
04
O agente acompanha. O agente lê a decisão com screenrig reviews show ID ou seu evento, revisa após um pedido de alteração ou rejeição, e verifica as telas após uma aprovação.

O proprietário do projeto sempre pode aprovar, e cada membro pode, a menos que o proprietário desative Pode aprovar para ele na página Pessoas. Os agentes de um membro que não pode aprovar trabalham no máximo em Propor. Uma proposta fica desatualizada quando a playlist ao vivo muda depois que ela foi feita; o agente propõe de novo sobre a nova versão. Aprovar uma alteração de playlist também fica desatualizado quando os seletores tag, folder ou all passariam a reproduzir mídia que ela não viu quando foi proposta. Uma pasta marcada como protegida envia toda alteração que alcança as suas telas a um segundo aprovador; veja Permissões por pasta de telas.

Mudanças na mídia também aguardam. Um novo upload só é reproduzido em tag, pasta e playlists Todas após aprovação humana, e quando um agente retagueia ou move mídia aprovada, as telas continuam reproduzindo-a como aprovada até a aprovação da mudança. Cada item recebe sua própria revisão que mostra suas tags e pasta antes e depois, e lista as playlists que entraria ou sairia e quantas telas alcança. Aprovar aplica a mudança a todas; rejeitar ou pedir alterações coloca o item retagueado ou movido de volta como aprovado, e um upload rejeitado fica fora das telas. Um arquivo de substituição ou uma versão restaurada de mídia aprovada também aguarda, e o arquivo antigo continua sendo reproduzido até que uma pessoa aprove. Redes de anúncios revisam os criativos dos compradores na mesma página de Revisões. Níveis de acesso e configurações de revisão · Comandos de revisão.

O que conta como completo?

Confirme que a playlist pretendida está atribuída à tela pretendida, ou a todas as telas da frota. Solicite uma captura de tela, uma por tela marcada para uma frota, inspecione registros de reprodução e revise eventos relevantes, incluindo qualquer screen.offline. Informe o que essas observações estabelecem e qualquer incerteza restante. Uma alteração que aguarda revisão ainda não está no vidro: informe seu link de revisão e verifique novamente após uma pessoa decidir.

Um comando bem-sucedido é um passo nessa evidência. Ele não estabelece por si só que uma tela física exibiu o resultado pretendido.