O relatório dos testes pode ficar pronto antes de você abrir o Open WebUI

Às 8h30 de segunda-feira, uma pessoa desenvolvedora abre o resultado dos testes da noite. Três tarefas estão em vermelho. A primeira perdeu a conexão com o banco de testes, a segunda atingiu um tempo limite intermitente e a terceira falhou numa asserção em código alterado na sexta. Separar os casos demora mais que olhar os indicadores. Um agente executado periodicamente poderia deixar no chat um relatório curto, com a asserção e o trecho de log no topo.

O Open WebUI, interface de chat que pode ser hospedada pela própria equipe para modelos e ferramentas de IA, passou a aceitar agentes de programação em automações agendadas na versão 0.13.3. O GitHub registra a publicação em 8 de novembro de 2026, às 23h48 UTC. Uma automação pode guardar um terminal, um diretório de trabalho e um agente disponível nesse terminal, e entregar o resultado ao chat. A agenda passa a iniciar a tarefa num ambiente específico, o que viabiliza o relatório da manhã. Notas do Open WebUI v0.13.3

A primeira tarefa que vale agendar é um relatório verificável em minutos. Use a automação para reunir evidências e deixe a decisão seguinte com quem responde pelo projeto. Um relatório repetível e útil dá uma referência para avaliar se vale conceder outra permissão.

A automação lembra onde o agente trabalha

As automações do Open WebUI já aceitam instruções recorrentes. Cada execução inicia um chat pelo fluxo normal de geração, sujeito às configurações de modelo, ferramentas, filtros e memória aplicável. A versão 0.13.3 acrescenta a escolha de um agente descoberto no terminal. Com o terminal selecionado, o seletor mostra as combinações no formato agente/modelo. Trocar o terminal ou a pasta pode mudar as opções. Antes de rodar, o Open WebUI verifica se o terminal e o agente salvos existem. Se algum tiver sumido, a execução falha e a pessoa responsável pode consultar o log. Documentação de automações do Open WebUI

A agenda inicia um chat com as configurações salvas. Ilustração original da Telli.sh com base nas notas da versão 0.13.3.

O diretório de trabalho resolve uma pergunta simples com consequências caras. Qual cópia o agente deve ler quando dois projetos têm arquivos parecidos, ou quando uma funcionalidade e uma versão do mesmo projeto estão em pastas diferentes? Um caminho explícito dá o ponto de partida esperado e uma referência para revisão. Continua sendo só o diretório inicial. Permissões de leitura e gravação, arquivos acessíveis, variáveis, rede e comportamento do agente determinam até onde a execução pode ir.

O resultado também tem destino definido. Automações com agentes de programação entregam saída ao chat. As notas distinguem essas automações das de modelos comuns, que podem usar canais. O histórico e o chat bastam para uma pessoa revisar o relatório. Uma equipe que queira alerta compartilhado ainda precisa decidir o que divulgar, onde e a quem mostrar o log. Uma falha de agenda também precisa de alguém que saiba onde procurar. Notas do Open WebUI v0.13.3

Dê à primeira tarefa uma entrada pequena e verificável

Para o relatório de segunda, comece com cópias do resumo da última execução noturna, um ID de commit gerado pela máquina e poucos trechos de falha. Um exportador de artefatos da integração contínua ou uma cópia manual em pasta descartável dá entrada estável. Cada arquivo precisa indicar a tarefa e o commit. Remova segredos óbvios e logs alheios antes de copiar. Use nome convencional e horário verificável, para o agente não precisar adivinhar qual arquivo é o mais recente.

Peça três saídas separadas na mesma resposta. Primeiro, uma lista curta das falhas que exigem atenção. Segundo, falhas de ambiente ou sem diagnóstico. Terceiro, um link ou caminho para a evidência de cada item. Use formato compacto para comparar com a visão original da integração. Uma tarefa que abre seis chamados iguais porque o mesmo teste falhou em seis configurações cria um problema de revisão maior que o de leitura.

Uma instrução útil define o que a resposta deve preservar. O exemplo usa um conjunto de teste com registro de commit e resumo exportado. Pasta e arquivos são ilustrativos.

Leia o resumo de testes e os trechos de falha no diretório de projeto indicado. Comece pelo ID da execução, commit e horário da entrada. Agrupe falhas repetidas na matriz. Para cada falha distinta, informe o nome do teste, o menor trecho útil e o caminho de origem. Separe falhas explícitas de causas possíveis. Se o resumo estiver ausente, antigo ou incompleto, diga qual dado falta e pare. Deixe os arquivos como estavam.

Instruções assim reduzem a ambiguidade. O terminal ainda precisa de permissões compatíveis. Se a tarefa só lê, dê acesso de leitura ou cópia descartável sem credenciais de repositório. Um teste pode imprimir texto arbitrário de código, dependência ou arquivo de teste. Isso é evidência, sem autoridade para instruir o agente. Essa distinção pesa mais se a execução começar antes que a pessoa responsável acorde.

O mesmo arranjo pode servir para outra rotina. A liderança pode fornecer inventário datado de dependências e uma lista de alertas obtida separadamente, e pedir correspondências possíveis de versão com citação dos registros. A entrega útil é uma lista de revisão com pacote, versão e fonte. Um verificador confiável ainda pode fazer correspondência determinística, enquanto alguém confirma se a dependência está num caminho executável. Arquivos estáveis facilitam reproduzir o relatório se a explicação mudar entre execuções.

Uma configuração curta revela a maior parte do trabalho

O Open WebUI documenta uma opção global de automações e uma permissão separada para contas sem administração. Confirme que a instância roda 0.13.3 ou versão posterior compatível, que o recurso está ligado e que a conta tem acesso. O terminal deve estar conectado e permitido no contexto de automação. Pode aparecer no editor de modelos e estar excluído das tarefas agendadas pelas configurações de contexto. Isso explica uma execução que funciona no chat comum e falha na agenda. Automações do Open WebUI · Conexão do Open Terminal

1. Prepare um conjunto de teste. Coloque uma execução bem-sucedida, uma falha representativa e um manifesto com commit e horário em uma pasta temporária. Mantenha os exemplos pequenos e deixe chaves de produção, configuração de nuvem e arquivos pessoais fora.
2. Abra Automações e crie a tarefa. Use os campos de título, instrução, modelo e agenda. No editor, selecione o terminal, informe o diretório e escolha o agente no seletor. Aguarde o ambiente listar os agentes da pasta.
3. Execute uma vez no editor. Abra o chat e o log. Confirme commit, fontes, remoção de duplicatas e permissões. Compare com o material original e confira se a árvore de código ficou limpa.
4. Teste uma falha. Remova o manifesto de outro conjunto ou aponte para entrada antiga de propósito. O relatório deve dizer o que falta. Verifique se um terminal indisponível para automações aparece no histórico como execução com erro.
5. Agende e revise os primeiros resultados. Compare o horário com o fim da exportação da integração contínua. Um relatório que começa cedo e lê a execução de ontem tem problema de agenda, mesmo que soe atual. Pause se o formato de entrada mudar ou os resultados começarem a se desviar.

Trate os arquivos de teste e a instrução como um par. Se mudar o nome da pasta, a convenção das branches ou a suíte de um teste, atualize a amostra junto com a tarefa. Isso evita perder silenciosamente a evidência usada para agrupar resultados. Ao editar a instrução, guarde o exemplo anterior e compare as duas respostas na mesma entrada. A correção mais barata muitas vezes é um manifesto melhor, especialmente quando duas tarefas precisam concordar sobre qual execução é a mais recente.

Escolher o terminal envolve definir permissões

Uma interface hospedada pela equipe pode se conectar a um modelo ou agente de outro fornecedor. Confira o fornecedor, os dados enviados e as credenciais disponíveis. Uma cópia dentro de um contêiner ou de uma pasta descartável dá um lugar para limitar a tarefa. O diretório inicial protege pouco se a mesma conta lê todo o computador ou tem uma chave com escrita no repositório. A documentação de terminal descreve opções de contexto, inclusive automação, para restringir o uso antes do início. Conexão de terminal no Open WebUI

Um relatório somente para leitura separa evidência, permissões e decisão de revisão. Ilustração original da Telli.sh.

O tempo economizado vai da abertura do resultado até saber onde olhar. Um comando confiável pode fazer boa parte do trabalho. Deixe-o emitir ID e estado, e use o agente para explicar falhas de vários tipos de saída. Se o resultado sair errado, compare o ID com o manifesto e descubra se o problema veio da entrada antes de trocar de agente.

Inclua custo na mesma verificação. A agenda pode consumir cota se o agente chamar um modelo cobrado. Logs longos aumentam o volume, e falhas repetidas viram análises repetidas. Primeiro, meça a utilidade de trechos limitados em uma agenda curta. Se toda execução lê os mesmos arquivos grandes, coloque uma etapa determinística barata para indicar mudanças. Uma execução diária fica fácil de orçar quando há um limite conhecido de entrada.

Para uma equipe pequena, responsabilidade importa tanto quanto terminal. Segundo a documentação, uma automação pertence à conta que a criou e é privada. Um relatório pessoal pode ficar ali. A aprovação de uma versão por várias pessoas precisa de um processo visível de compartilhamento e transferência de responsabilidade. O histórico da automação ajuda uma pessoa a investigar uma falha. Uma checagem compartilhada de integração contínua mantém a decisão visível à equipe. Controle de acesso das automações

O relatório da manhã mostra seu valor na revisão

Depois da primeira semana, examine o que alguém abriu de fato. Confira o link ou trecho de cada item urgente e conte os casos em que o resumo perdeu uma falha, repetiu outra ou citou o commit errado. Pergunte se o relatório ajudou a encontrar o próximo teste. Essas observações dizem mais sobre a agenda que a quantidade de respostas automáticas.

Se continuar útil, acrescente um tipo de evidência de cada vez. Dê ao terminal um destino estável, mantenha as credenciais restritas e passe mudanças de código ou infraestrutura pela revisão habitual. O melhor sinal de progresso é um relatório matinal em que você pode agir e que consegue conferir rapidamente quando algo parece errado.

Fontes

• Notas do Open WebUI v0.13.3
• Configuração, permissões e histórico de automações
• Conexões e contextos de terminal

---

Para guardar e pesquisar as conversas e decisões por trás do seu trabalho, crie uma conta na Telli.sh.