[Gestão] Resumo do Dia

Ficha canônica · pilar HQ · gerada em 10/08/2026 a partir da releitura do n8n

VEREDITO: workplace em analise — vermelho.
Dois defeitos que impediam a função foram corrigidos e confirmados por read-back. Mesmo assim não vira verde: o fluxo está inativo e arquivado desde 08/08, tem zero execuções no histórico, e o critério de verde exige efeito funcional comprovado. Sem uma execução real não há como provar que o resumo chega ao Telegram. Religar é decisão do Rafael, não correção técnica.

FICHA DE DECISÃO — AS-IS para o Rafael
O levantamento de negócio (o que faz hoje, as 13 fontes explicadas, a estrutura do report, o que já foi corrigido, o que ainda está errado e as 7 perguntas em aberto) está em ficha de decisão. Nenhum TO-BE foi escrito — função futura, conteúdo, periodicidade e vida/morte seguem em aberto. Boss HQ, definido pelo Rafael.

Proveniência / história

origemCriado em 08/06/2026 (createdAt do n8n). Última alteração de conteúdo em 29/06/2026. Nunca foi arquivado — ver correção abaixo.

criado paraDar ao operador um retrato diário da operação Rental às 19h — pipeline, agendamentos, reservas, financeiro, base de imóveis e fila de atendimento — num só lugar.

evidência da origemworkflows.tsv da auditoria (createdAt/updatedAt) · primeiro commit em 26/06/2026 (cf1b731, "global resync — 73 fluxos PROD") · docs/auditoria-n8n/projetos/gestão.md · nota do próprio nó de trigger

antecessorNão comprovado como antecessor formal, mas existe um irmão mais granular: [Rental] Resumo Horário Boss (xuD5cAKphssVPwsS, 14 nós, de hora em hora 10h–18h), que chama o mesmo hub de avisos e hoje está aposentado. Os dois entraram na mesma proposta de arquivamento de 08/08 — que não foi executada.

sucessornenhum — nada assumiu a função. O resumo diário simplesmente deixou de existir.

migração comprovadaKrolik/WhatsApp → Telegram. O nó Krolik · Enviar Resumo, hoje desabilitado, mandava o resumo por WhatsApp para o telefone do operador. Foi substituído pelo caminho Set → executeWorkflow → [Tech] Avisos Telegram. Isso alinha o fluxo à regra 7 do CLAUDE.md: aviso operacional ao Rafael é só Telegram.

nome original (fóssil)O monitor do Uptime Kuma preservou o nome antigo: [proprietarios] Resumo Diário 19h (monitor 75, grupo "🏠 Automações — Proprietários"). Não existe nenhum workflow com esse nome no n8n hoje — o fluxo foi renomeado para [Gestão] Resumo do Dia e o Kuma nunca acompanhou. Isso prova que ele nasceu no pilar Proprietários, não em HQ, e corrobora o conteúdo: as consultas Asaas são de assinatura de proprietário e as bases Notion são do pipeline Rental.

linha do tempo08/06 criado · 26/06 primeiro commit no Git · 29/06 última alteração · migração do envio para Telegram (nó Krolik desabilitado, data não isolada) · 08/08 entra na proposta de arquivamento (não executada) · 10/08 revisão e correção

função originalResumo diário da operação Rental entregue ao operador às 19h

função atualA mesma — o desenho não mudou; o que mudou foi o canal de entrega

função ainda necessáriaNÃO COMPROVADO Nada substituiu a função, mas nada indica que ela foi pedida de volta. Foi arquivada junto com 24 outros no bloco de 08/08.

confiançaALTA datas vêm do próprio n8n e do Git; a migração de canal é comprovada pelo nó desabilitado preservado dentro do workflow.

CORREÇÃO 10/08 — a afirmação "nunca rodou" era minha, e estava errada
Eu havia escrito aqui que este fluxo nunca rodou uma única vez, com base em last_exec.tsv → NUNCA. O cabeçalho do próprio censo diz "execuções reais (retenção ~14d)", e a auditoria rodou em 08/08 — a janela não alcança junho. Contra a afirmação pesam: o commit 8cb2445 (12/06) diz "religados"; o fluxo consta entre os 70 ativos de 29/06; e o cron 0 19 * * 1-6 estava armado.

Leitura correta: "sem execução na janela de ~14 dias antes de 08/08" = COMPROVADO · "nunca executou desde 08/06" = NÃO COMPROVADO, e provavelmente falso.

Consequência: não se pode mais explicar os BLOCKERs por "ninguém viu a saída". Datar os defeitos pelos exports de junho é impossível — os parameters vêm vazios inclusive no Build Resumo, que obrigatoriamente tinha código: é perda do export, não estado real. Linhagem completa em docs/proveniencia/XLaS3g39Mxibej62.md.

Identidade

fluxo[Gestão] Resumo do Dia

id n8nXLaS3g39Mxibej62

link n8nn8n.rbrtecnologia.com.br/workflow/XLaS3g39Mxibej62 ↗

empresarbr-rental

pilarHQ tópico TG não localizado

bossboss_key hq (tag boss:hq) · agente boss: não formalizado
divergência o nó Set · Aviso Boss Resumo envia boss: "rental"

funçãoResumir o dia da operação Rental e mandar para o boss às 19h

tag antesarquivado-2026-08-08 ⚠ a tag foi aplicada, mas o arquivamento não: isArchived=false no n8n vivo audit:pendente boss:hq canal:krolik tipo:cron

tag depoisworkplace em analise + as históricas preservadas

O que faz hoje

comportamento real Às 19h (seg–sáb) dispara 13 consultas em paralelo — 7 no Notion, 4 no Asaas, 1 no Krolik — junta tudo num Merge, monta um texto de resumo com pipeline, agendamentos, reservas Stays, financeiro Asaas, base de imóveis e fila do Krolik, e manda para o boss via sub-workflow do Telegram. No fim bate um heartbeat no Uptime Kuma.

O que deveria fazer

fonte Nota do próprio nó de trigger: "Roda 19:00 BRT seg-sab. Resumo diário pro Rafael." E a regra 7 do CLAUDE.md: notificação operacional ao Rafael é só Telegram.

divergência Nenhuma fonte descreve o conteúdo exato que o resumo deve ter. O texto atual foi lido do código, não de especificação. fonte insuficiente para o conteúdo.

Critério de sucesso e de verde

sucesso funcional Não basta execution success. É preciso que a mensagem com os números do dia chegue ao tópico do boss no Telegram — não a frase genérica de fallback.

para receber verde 1. Fluxo ativo · 2. uma execução real após as correções · 3. mensagem recebida no Telegram contendo os blocos Pipeline/Financeiro/Base · 4. heartbeat do Kuma no mesmo ciclo · 5. read-back das tags.

Trigger

tipoCRON — scheduleTrigger

expressão0 19 * * 1-6 — 19:00, segunda a sábado

timezoneRESOLVIDO settings.timezone: "America/Sao_Paulo" no próprio workflow. Dispara 19:00 BRT de verdade. Meu alarme anterior sobre UTC era falso — corrigido aqui em vez de deixar passar.

Relações N×N

upstreamnenhum — é gatilho de tempo

downstream [Tech] Avisos Telegram ↗ WFaxEkSrowybjrLI · ativo · via executeWorkflow com waitForSubWorkflow: false

cadeia[Gestão] Resumo do Dia → [Tech] Avisos Telegram → Telegram (tópico do boss)

Integrações e credenciais

integração	finalidade	auth	credencial n8n	crítica
Notion	7 consultas: conversas, imóveis (hoje/ontem), agendamentos, clientes, pipeline, comercial, hóspedes	httpHeaderAuth	Notion API - PROD	SIM
Asaas	4 consultas: recebidos, pendentes, vencidos, a vencer 5d	httpHeaderAuth	Asaas API - PROD	SIM
Krolik	contagem de chats aguardando	httpHeaderAuth	Krolik API - PROD	NÃO
Uptime Kuma	heartbeat push no fim	token na URL	nenhuma — literal	NÃO
Telegram	entrega, via sub-workflow	—	herda do sub-workflow	SIM

Segurança

segredo expostoSIM token de push do Uptime Kuma literal na URL do nó Kuma · push OK — e repetido no id do nó. Valor não reproduzido aqui.

demais credenciaisOK Notion, Asaas e Krolik usam credential nativa. Zero token literal.

PIISIM telefone pessoal do operador hardcoded em Get Config (rafael_telefone)

dados financeirosSIM valores Asaas — recebidos, vencidos, a vencer

dados de clienteSIM conversas, pipeline e hóspedes (agregados, não nominais no texto final)

Resiliência

retrynenhum nó tem retry

timeoutOK 15s–30s em todos os HTTP

tratamento de erroOK onError: continueRegularOutput nas 13 consultas — uma fonte fora do ar não derruba o resumo

idempotênciaRodar duas vezes duplica a mensagem no Telegram. Não duplica reserva, cobrança nem registro — é só leitura + envio.

fallback manualNenhum. Sem o fluxo, o resumo simplesmente não sai; ninguém é notificado da ausência.

Execuções e saúde

status n8nINATIVO nunca arquivado — n8n vivo: isArchived=false

execuçõeszero no histórico consultado

último sucesso funcionalnunca comprovado

infraMONITOR QUEBRADO monitor 75 existe e está DOWN há 50 batidas seguidas, uptime 24h = 0% — alarmando sem parar por um fluxo que está apenas inativo em 08/08.

defeito do próprio monitorIntervalo incompatível com a função. As batidas caem de 600 s em 600 s; o fluxo empurra 1× por dia. Mesmo operando com perfeição ele ficaria vermelho ~99,3% do tempo — este monitor nunca teve como ficar verde. Corrigir exige intervalo ≥ 24 h + folga, no admin do Kuma (a página pública é só leitura).

ligação monitor ↔ fluxoFORTE, NÃO PROVADA batem nome-fóssil, horário 19h, tipo push e o DOWN desde o arquivamento. O token do push não é exposto na página pública, então o vínculo não é demonstrável sem acesso admin ao Kuma.

execuçãoSEM EVIDÊNCIA

funçãoPENDENTE

errorWorkflowSIM DgtGSwuX98yGhYsg = [Tech] Alerta de Erro — conforme a regra 4 do CLAUDE.md

Cobertura: as 13 fontes contra os 16 pilares

Mapa do que o resumo de fato enxerga. Nenhum KPI inventado — só o que existe como consulta no fluxo hoje.

Pilar	Fonte no fluxo	Cobertura
HQ	é o agregador, não uma fonte	N/A
Comercial Proprietários	Conversas Hoje · Pipeline Quente · Imóveis Comercial	COBERTO
Financeiro Proprietários	Asaas: Recebidos · Pendentes · Vencidos · A Vencer 5d	COBERTO
Operações Proprietários	Agendamentos Hoje · Imóveis Hoje/Ontem · Clientes Ativos	COBERTO
Reservas	Hospedes Hoje (Notion — não é o Stays)	PARCIAL
Concierge · Operações Hóspedes	Krolik · List Aguardando (fila, sem recorte de hóspede)	PARCIAL
Comercial Hóspedes · Financeiro Hóspedes · Pricing · Repasse · Marketing · Branding · Conteúdo · Estratégia · Tech	—	SEM FONTE (9 pilares)

A cobertura desmente a etiqueta
Toda a cobertura firme cai nos três pilares de Proprietários. O lado hóspede aparece de raspão e nove pilares não têm fonte alguma. Somado ao nome-fóssil do Kuma ([proprietarios] …), a conclusão é uma só: isto é um fechamento de Proprietários usando uma etiqueta de HQ. A leitura de "fechamento executivo da operação" vem da tag boss:hq, não do conteúdo.

Consequência para o Boss: criar um Boss HQ a partir deste fluxo seria fabricar um chefe para uma casa que ele não representa — exatamente o que a ADR 001.R proíbe. Se ele voltar a operar, entra sob Proprietários; um fechamento de HQ de verdade precisaria de fontes dos outros nove pilares, que não existem.

Criticidade

nívelMÉDIO — é informativo: sua falha não quebra operação, mas cega o operador sobre o dia

impacto se quebrarcliente NÃO · financeiro NÃO · reserva NÃO · proprietário NÃO · comercial NÃO · segurança NÃO · operação SIM (perda de visibilidade diária)

Potenciais erros encontrados

BLOCKER · CORRIGIDO — o resumo era descartado antes de sair

Build Resumo devolve o campo mensagem. O Set · Aviso Boss Resumo lia .resumo || .message || .text || 'Resumo diário 19h executou' — nunca .mensagem. O fallback vencia sempre: 13 consultas eram feitas, o texto era montado, e o Telegram recebia cinco palavras genéricas.

antes:  .resumo || .message || .text || 'Resumo diário 19h executou'
depois: .mensagem || .resumo || .message || .text || 'Resumo diário 19h executou'

Origem provável: na migração do envio por WhatsApp/Krolik para Telegram, o nó novo foi escrito com o nome de campo errado. O nó antigo — hoje desabilitado — lia $json.mensagem, o correto.

BLOCKER · CORRIGIDO — o Merge descartava 11 das 13 fontes

Merge Todos recebia 13 conexões mas estava sem numberInputs, cujo padrão é 2. O n8n ignorava as entradas 2 a 12: além de descartar itens, o Merge não esperava por 11 ramos, o que deixava o Build Resumo livre para rodar antes de as consultas terminarem. Corrigido para numberInputs: 13.

RESOLVIDO na fonte + 1 GATE — boss: `hq` é taxonomia, `rental` é roteamento

Consultei o motor.channels e os dois existem, em grupos diferentes:

hq     → empresa board  · chat -1003799565626 · thread 16
rental → empresa rental · chat -1003903892978 · thread NULL (raiz)

Não é conflito: são camadas distintas com colisão de nome. A tag boss:hq classifica o pilar (taxonomia); o campo boss do payload escolhe o destino (roteamento). O conteúdo é 100% operação Rental, então rotear para o grupo Rental é coerente — e por isso não alterei o payload.

GATE RAFAEL, único: o resumo deve cair no grupo Rental (raiz, como está) ou no grupo board no tópico 16 (que é o que a tag de pilar sugere)? São grupos diferentes; a escolha é de operação, não técnica.

RELATED · CORRIGIDO — patch órfão removido do `Get Config`

O nó carregava duas chaves órfãs — assignments[2] e assignments[10] — irmãs do array em vez de dentro dele. Alguém tentou trocar o ID do banco de Conversas e o formato da data; a alteração nunca se aplicou.

Investiguei qual ID é o certo: o valor vivo (2f6aa842…) é usado também pelo laura-disparo-sdr; o do patch órfão (ce5f6fcc…) não aparece em nenhum outro fluxo do repo. Sem corroboração, o vivo prevalece. Removi as duas chaves mortas — funcionalmente inertes, mas uma armadilha para quem ler depois.

LATER — token do Kuma literal na URL

Tentei migrar para credential nativa e não é tecnicamente possível: o token do Kuma vive no caminho da URL (/api/push/<token>), e os tipos de credential do n8n injetam em header, query ou body — nenhum injeta em path. Sem mudar o Kuma para aceitar o token por query/header, não há mecanismo seguro disponível. Some-se que o padrão está em dezenas de fluxos: trocar num só criaria inconsistência. Fica como decisão de padrão.

Nota de auditoria: o detector de hardcode do repo pegou o telefone deste fluxo, mas não pegou este token — a regra dele não olha segredo em path de URL.

RESOLVIDO — nó morto removido, evidência preservada por escrito

Krolik · Enviar Resumo está desabilitado e órfão: nenhuma conexão o alimenta. Ele mandava WhatsApp para o telefone do operador, o que contraria a regra 7 do CLAUDE.md — aviso operacional ao Rafael é só Telegram. Desabilitá-lo foi certo.

Eu havia decidido mantê-lo como evidência — era a única prova, dentro do workflow, da migração WhatsApp→Telegram. O Rafael determinou a retirada. Removido em 10/08 (read-back: 21→20 nós), e a decisão está certa porque a proveniência já estava escrita aqui: a evidência não morre com o nó, ela mudou de suporte. A regra que fica: só se apaga um nó-fóssil depois que a proveniência dele está documentada.

Krolik como fonte é caso separado e foi preservado: Krolik · List Aguardando continua entre as 13 consultas. O que morreu foi o canal de envio, não a leitura da fila de atendimento.

CORRIGIDO — o heartbeat parou de mentir

O Kuma · push OK disparava logo após o executeWorkflow, que rodava com waitForSubWorkflow: false — o heartbeat dizia "up" mesmo que o envio no Telegram falhasse. Um monitor que mente é pior que monitor nenhum: ensina a operação a confiar num sinal vazio. Corrigido para waitForSubWorkflow: true; agora o push só ocorre depois de o sub-workflow concluir.

Correções aplicadas e rollback

aplicado 1. Set · Aviso Boss Resumo → lê .mensagem primeiro (BLOCKER)
2. Merge Todos → numberInputs: 13 (BLOCKER)
3. Telegram · Boss Resumo → waitForSubWorkflow: true (heartbeat honesto)
4. Get Config → removidas as 2 chaves órfãs do patch que nunca pegou
5. tag workplace em analise adicionada

read-backOK releitura do n8n confirmou as cinco mudanças persistidas, campo a campo

rollbackRemover .mensagem || do início da expressão · remover numberInputs do Merge · voltar waitForSubWorkflow para false · repor as chaves órfãs (inertes) · remover a tag. Nenhuma mudança tocou dado externo — o fluxo não rodou.

teste executadoBLOQUEADO POR INTERFACE
Tentei acionar e a API recusou, com esta razão literal:
"Workflow has trigger nodes but none support external triggering (found: n8n-nodes-base.scheduleTrigger)"
A API do n8n só dispara webhook, form e chat. Fluxo cron exige execução manual no editor ou ativação com espera da janela das 19h — as duas são decisão do Rafael, não correção técnica. É este critério, e só ele, que segura o verde.

fontes desta ficha
n8n PROD — releitura de XLaS3g39Mxibej62 em 10/08/2026 (estrutura, nós, expressões, código, tags, execuções)
n8n PROD — WFaxEkSrowybjrLI para a relação downstream
validador n8n — perfil runtime, 11 avisos no Merge Todos
cockpit @ nmwawblixowbqtxoaksj · CLAUDE.md regra 7 · taxonomia canônica de 10/08

Campo sem fonte aparece como não coletado / a confirmar. Nada foi inferido.