Documentação HorusBI
Buscar K

Aparência

Abrir no Claude Abrir no ChatGPT

Revisando o trabalho da IA ​

A IA opera o lumo, mas o resultado é seu. A boa notícia: tudo o que ela faz vira arquivos YAML num diretório local — então dá para revisar com calma, com as mesmas ferramentas que você já usa para código (Git, diff).

Você não precisa escrever YAML à mão — isso é trabalho da IA. Esta página é para você reconhecer e conferir o que ela produziu.

Onde o trabalho fica ​

Cada recurso vira um arquivo na pasta correspondente do workspace (flows/, tables/, apps/, credentials/…). Para ver o que mudou, peça à IA — ou olhe você mesmo:

  • "o que você mudou?" — a IA resume e pode rodar lumo status / git diff.
  • Se o workspace está em Git, git diff mostra exatamente o que entrou, linha a linha.

TIP

Manter o workspace em Git é a melhor rede de segurança: você revisa as mudanças da IA como um code review e desfaz com git checkout se não gostar.

Anatomia de um arquivo (para reconhecer) ​

Todo arquivo do Lumo tem duas partes separadas por ---: um cabeçalho gerenciado pelo CLI e o corpo com a configuração de fato.

yaml
lumo: v2                 # versão do schema — gerenciado pelo CLI
kind: flow               # tipo do recurso
id: 42866                # id no servidor — gerenciado pelo CLI
tenantId: 522            # checagem de segurança — gerenciado pelo CLI
---
nome: Carga Vendas       # ↓ daqui pra baixo é a configuração (o que a IA monta)
load_type: Temporal
# nós do flow, dashboards, colunas, etc.
  • Cabeçalho (acima do ---): não mexa. O CLI preenche id/tenantId ao criar o recurso.
  • Corpo (abaixo do ---): é a configuração do recurso. É o que você lê para entender o que a IA fez.

NOTE

Recursos grandes (flows e apps) podem aparecer como uma pasta em vez de um arquivo único — com _flow.yaml, nodes/, dashboards/ etc. É o mesmo conteúdo, só fatiado para facilitar o diff. A IA cuida disso.

O que conferir antes de publicar ​

Antes de dar o ok para publicar, vale checar — e dá para pedir tudo isso à IA:

  • Dashboard: peça a imagem exportada e confira o visual (layout, legendas, rótulos). Os números podem estar certos e o visual quebrado.
  • Tabela: confira que tem as colunas e as linhas esperadas (peça a prévia / a contagem). "Enfileirado" não é "carregado".
  • Nomes e destino: os nomes dos recursos e a mesa de destino estão certos?

TIP

Depois de cada push, o CLI reescreve o YAML local com a resposta do servidor. Ou seja: o que está no arquivo é exatamente o que está no servidor — sem divergência silenciosa.

O que não mexer ​

Alguns pontos são gerenciados pelo sistema. Se você (ou a IA) editar à mão, a mudança é ignorada ou causa inconsistência:

  • A pasta interna .lumo/state/ — é cache do CLI.
  • id / tenantId no cabeçalho — preenchidos pelo servidor.
  • deskId — quem controla é a publicação, não a edição do arquivo.
  • Colunas estruturais de tabela (nome da coluna, tipo, chave) — pertencem ao flow que produz a tabela, não à tabela.

Você não precisa decorar isso: a IA conhece essas regras. É só para você não se assustar se vir um campo desses "voltar ao normal" sozinho.

Publicar é o ponto de virada ​

Lembre-se: publicar é decisão sua e tem peso. Um recurso publicado fica somente-leitura, é compartilhado com outros usuários, e republicar sobrescreve a versão anterior (só reversível por clonar → editar → republicar). Por isso a IA constrói tudo como rascunho e espera seu ok.

Construa e itere à vontade como rascunho; quando estiver realmente pronto e revisado, aí sim diga para publicar.

Veja também ​