@lionchat/mcp-server 1.10.2 → 1.11.0

package/dist/docs/instructions.md

@@ -374,6 +374,9 @@ Antes de escolher a ferramenta, cheque se a intenção bate com a coluna da dire
 | **Definir supervisor** de caixa | `lionchat_inbox_members_create` / `_update` com `supervisor_ids[]` | Supervisor vê TUDO da caixa mas fica fora do rodízio (ver abaixo) |
 | **Definir supervisor** de time | `lionchat_team_members_create` / `_update` com `supervisor_ids[]` | Contrato diferente do da caixa: `user_ids[]` é a lista COMPLETA e `supervisor_ids[]` um subconjunto dela. Omitir `supervisor_ids` não mexe em papel nenhum (seção 2) |
 | **Mudar a fila do time** (teto por atendente, janela, online/offline) | `lionchat_teams_update` (`assignment_mode`, `fair_distribution_limit`, `fair_distribution_window`) | Time tem PREFERÊNCIA sobre a caixa na distribuição. Leia a config atual antes de mudar (ver `lionchat://docs/conversation-flows`) |
+| **Criar/atualizar time** | `lionchat_teams_create` / `_update` | **Preencha `description`**: desde 03/08 é ela que o AI Agente lê pra decidir o roteamento por time. Descreva QUANDO mandar pra lá, não o que o time é |
+| **Pausar a automação no meio** (esperar atribuição/card antes da próxima ação) | ação `wait` em `lionchat_automation_rules_create` / `_update` | Segundos, teto 300. Acima disso é caso de FlowBuilder. Ver `lionchat://docs/conversation-flows` |
+| **Buscar contato/conversa/card** | `lionchat_search_*`, `lionchat_contacts_search` | **Termo com letra exige 3+ caracteres** (dígito é isento). Menos que isso volta VAZIO sem erro — não conclua que o registro não existe. Ver `lionchat://docs/api-conventions` |
 | **Migrar conversas** de uma caixa WhatsApp pra outra (ex.: QR Code → Oficial) | `lionchat_inboxes_inbox_migration_list` (prévia) → `_execute` → acompanhar status | Admin-only e IRREVERSÍVEL: sempre mostre os números da prévia e confirme (seção 7a). Grupos não vão pro canal oficial — ficam na caixa de origem |
 | Qualquer coisa de Ligação WP (Wavoip) | **NÃO HÁ TOOL** — removidas em 2026-07-16 por decisão do dono | Ligação WP é contratada e configurada **manualmente pelo cliente no painel**. O MCP não conecta, não desconecta, não entrega token de discagem nem muda config. Oriente o usuário a fazer pelo painel (Configurações da caixa → Ligação WP). |
 | Restringir agendas que a IA oferece | `lionchat_captain_assistants_update` (`config.booking_event_type_ids: [Int]`) | binding de agenda por cenário NÃO é settable via API |

package/dist/docs/resources/api-conventions.md

@@ -198,7 +198,7 @@ Ou para listas grandes (cursors):
 - `includes` / `excludes` (relacionamentos)
 - `before` / `after` (datas)
 
-### Atributos personalizados — operadores por TIPO (2026-07-21)
+### Atributos personalizados — operadores por TIPO (2026-08-07)
 
 Vale pra automações, filtro avançado de conversas/contatos e busca "+ Filtro" (motor compartilhado):
 
@@ -207,10 +207,17 @@ Vale pra automações, filtro avançado de conversas/contatos e busca "+ Filtro"
 | texto / link | equal_to, not_equal_to, contains, does_not_contain, is_present, is_not_present |
 | lista | equal_to, not_equal_to, is_present, is_not_present |
 | número / data | equal_to, not_equal_to, is_present, is_not_present, is_greater_than, is_less_than |
+| moeda / porcentagem / hora / data+hora | equal_to, not_equal_to, is_present, is_not_present, is_greater_than, is_less_than |
 | sim/não (checkbox) | equal_to, not_equal_to, is_present, is_not_present |
 
 - Em atributo de LISTA, `equal_to` com vários `values[]` casa QUALQUER um deles (multi-seleção).
 - NUNCA use `contains` em número/data/checkbox — o backend rejeita (cast inválido).
+- Moeda e porcentagem são castados como número, hora como hora e data+hora como data —
+  por isso desde 30/07 (filtros) e 07/08 (automações) esses quatro tipos também aceitam
+  `is_greater_than` / `is_less_than`. Base técnica: `FilterService::ATTRIBUTE_TYPES` casta
+  currency/percent como `numeric`, time como `time` e datetime como `date`; `coerce_lt_gt_value`
+  aceita numeric/date/time. Tipo NOVO de atributo sem entrada em `ATTRIBUTE_TYPES` quebra o
+  filtro com erro de sintaxe SQL (não "não acha nada") — a entrada é obrigatória no mesmo commit.
 
 > **Contatos — busca parcial por nome/ID externo:** no `POST /contacts/filter`, os campos `name` e
 > `identifier` aceitam `contains` / `does_not_contain` (match parcial, case-insensitive). Use isso
@@ -379,6 +386,29 @@ falha silenciosa, sem erro na tela. Conversa se altera por `fields` (+ `labels:
 **Multi-termo com E:** `q` aceita String (espaços = AND implícito) ou Array (`q[]=joao&q[]=silva`),
 cap de 5 termos — cada termo precisa bater (cada um mantém seu OR entre campos).
 
+**PISO DE 3 LETRAS (novo 2026-08-04) — leia antes de concluir "não existe".**
+
+Termo com LETRA precisa de **3 caracteres ou mais**. Termo **só de dígitos** é isento (é assim
+que se busca pelo número da conversa ou do card, e conta nova tem todos com 1-2 dígitos).
+
+| Busca | O que acontece |
+|---|---|
+| `q=Bo` | Devolve **vazio**. Não é erro, não é 422 — vem `payload: []` |
+| `q=Bor` | Busca normal |
+| `q=42` | Busca normal (só dígitos, isento) |
+| `q=jo silva` | Vale: basta **um** termo utilizável na frase |
+| `q=zq` + `contact_filters=[...]` | Vazio. O termo curto **invalida a busca inteira**, mesmo com filtro junto |
+
+Vale nas CINCO buscas (contato, conversa, mensagem, card e artigo).
+
+**Consequência prática:** resultado vazio com termo de 1-2 letras **não significa que o registro
+não existe** — significa que a busca não rodou. Nunca responda "não encontrei esse contato" nessa
+situação. Ou complete o termo, ou pergunte o nome inteiro, ou use `/contacts/filter` com
+`filter_operator: "contains"`, que não tem esse piso.
+
+Sem `q` e só com filtros estruturados continua funcionando normalmente (contrato antigo, busca só
+por condições) — o piso só descarta termo de texto curto, não o pedido inteiro.
+
 **Busca cadastral:** CPF/CNPJ/RG/endereço/profissão entram na busca de contatos e conversas, com
 match por dígitos que ignora pontuação (`31.104.475/0001-51` == `31104475000151`; mín 3 dígitos).
 Telefone idem. Cards do Kanban são achados pelo contato/conversa vinculados.

package/dist/docs/resources/best-practices.md

@@ -131,6 +131,32 @@ Pra reativar: `paused=false`. Toggle é auditado (`audited only: [:paused]`).
 
 O `config` DEVE ser enviado como **objeto** (ex.: `config: { disabled_tools: [...] }`), NUNCA como string/texto. Se vier em formato errado, o backend retorna **422** (não salva ignorando em silêncio). O update do `config` é **merge parcial** — mandar só o subset que muda (ex.: só `disabled_tools`) preserva os demais campos.
 
+## AI Agente roteando por TIME (novo 2026-08-03)
+
+O AI Agente ganhou 3 ferramentas de time: **Listar Times**, **Mover para Time** e **Tirar do Time**.
+Antes ele só conseguia atribuir uma PESSOA; trocar de time exigia automação ou bloco de fluxo, com
+o time escolhido de antemão por quem montou a regra.
+
+**A descrição do time virou peça funcional.** É lendo `teams.description` que a IA decide para onde
+mandar a conversa. Time sem descrição obriga a chumbar o nome no cenário — que é justamente o que
+essas ferramentas vieram resolver.
+
+> **Ao criar ou atualizar time (`lionchat_teams_create` / `_update`), preencha `description`
+> dizendo QUANDO mandar para lá.** Ex.: `"Financeiro — cobrança, boleto, nota fiscal, reembolso,
+> segunda via"`. Não é enfeite de tela: é o que a IA lê.
+
+Travas que valem conhecer (não dá pra desligar):
+
+| Trava | Efeito |
+|---|---|
+| Conta sem nenhum time | As 3 ferramentas nem aparecem para o agente |
+| Alguém está atendendo (`assignee_id` preenchido) | Mover e Tirar **não agem**. Evita a IA arrancar a conversa da mão do atendente |
+| Nome do time no cenário | Resolve por nome exato; não achando, tenta CONTÉM. Se der mais de um candidato, devolve a lista e **não adivinha** |
+| Mover de time | **Não** faz handoff sozinho. Se a intenção é o humano assumir, o cenário precisa mandar chamar o handoff no mesmo turno |
+
+`list_teams` é ferramenta de descoberta: fica escondida da tela de ferramentas e só carrega se
+"Mover para Time" estiver ativa. Não tente ligá-la ou desligá-la sozinha em `config.disabled_tools`.
+
 ## Limite do prompt e cache OpenAI (2026-05-22)
 
 - `config.instructions` (system prompt do agente) aceita até **20.000 caracteres** (antes 10k). Acima de 15k, o frontend mostra aviso "lost in the middle" — prefira colocar instruções críticas no início ou final.
@@ -306,6 +332,7 @@ Como a coleta de dados/cenários funciona hoje (importante pra diagnosticar "IA
 - Quando UM cenário fixa a tool, a execução vira determinística (a IA não escolhe): mídia e kanban são aplicados pós-turno pelo BindingResolver (ordem texto→ação, sem duplicar, idempotente); o agendamento força/restringe a agenda mas a IA ainda define data/hora.
 - Via MCP: scenarios_create/update persiste binding de send_media_asset e create_kanban_item/move_kanban_item (re-escopados por conta). O binding de create_booking NÃO é aceito pela API — pra limitar agendas via MCP, use config.booking_event_type_ids no assistente (captain_assistants_update).
 - Receita pra criar/editar cenário com binding via MCP (scenarios_create / scenarios_update): (1) o corpo vai SEMPRE embrulhado em `scenario`; (2) a instrução PRECISA mencionar a ferramenta como link markdown `[Rótulo](tool://slug)` — menção crua `(tool://slug)` NÃO conta e o binding é descartado no salvamento; (3) envie `tool_bindings` com o shape: `send_media_asset` → `{ "asset_ids": [Int] }`, `create_kanban_item`/`move_kanban_item` → `{ "funnel_id": Int, "stage": "<chave da etapa>" }`. Não precisa mandar `tools` (é auto-extraído da instrução e sobrescrito). `create_booking` NÃO entra em tool_bindings pela API.
+- Pra APONTAR uma página da base de conhecimento num cenário via MCP, escreva `[@Nome](document://ID)` (o ID numérico do documento) DENTRO do texto da `instruction` — igual ao link de tool, o motor deriva daí o campo `document_ids`. NÃO existe param `document_ids` na API/MCP (mandar seria descartado em silêncio). Teto de 3 documentos; a página apontada ganha PRIORIDADE na busca RAG, NÃO exclusividade (o resto da base continua pesquisável).
 
 ## Variáveis {{ }} nas instruções do AI Agente (2026-06)
 
@@ -502,6 +529,20 @@ opcional `variable_mapping` junto.
 - Só entram no mapping as que devem auto-preencher; as demais `{{N}}` continuam manuais.
 - O `variable_mapping` é salvo localmente (NÃO vai pra Meta) e usado no momento do envio.
 
+**Variável sem mapping tem preço (2026-08-04).** Placeholder que ninguém disse como preencher:
+
+1. **Tira o modelo do alcance do AI Agente.** Basta UMA variável sem mapping para o modelo inteiro
+   deixar de ser oferecido no follow-up automático fora da janela de 24h.
+2. **Faz o envio manual falhar** com o erro `#132000` da Meta (número de parâmetros não bate).
+
+Vale para os dois formatos de marcador: posicional (`{{1}}`) e nomeado (`{{nome_cliente}}`).
+
+> Ao registrar modelo por API, **mapeie todas as variáveis do corpo** — ou preencha na hora do envio
+> via `processed_params`. Modelo com variável órfã é modelo que a IA não usa e que o disparo derruba.
+
+Confira o que ficou de fora lendo o modelo com `lionchat_inboxes_whatsapp_templates_list` e
+comparando os `{{...}}` do texto do BODY com as chaves do `variable_mapping`.
+
 Exemplo — `{{1}}` vira o primeiro nome do contato:
 
 ```json
@@ -533,6 +574,29 @@ Fontes/campos disponíveis (`source` / `field`):
 Lembrete: todo template recém-criado pelo MCP só mostra o texto na tela depois de **sincronizar**
 (o MCP cria na Meta, mas o "puxar de volta" o conteúdo é o que a tela faz com o botão Sincronizar).
 
+### Apontar variáveis SEM reenviar pra Meta (2026-08-07)
+
+Antes, mudar o `variable_mapping` de um template JÁ APROVADO exigia o endpoint de update
+(`POST .../whatsapp_templates/{id}`) — que reenvia o modelo pra Meta e o status volta pra
+**Pendente** à toa. Agora existe um endpoint SÓ pro apontamento local:
+
+```
+PATCH /api/v1/accounts/{account_id}/inboxes/{inbox_id}/whatsapp_templates/{template_id}/variable_mapping
+Body: { "variable_mapping": { "1": { "source": "contact", "field": "name", "label": "Nome do contato" } } }
+```
+
+- **ZERO chamada à Meta**: o template continua Aprovado, sem nova revisão. Use SEMPRE este quando a
+  mudança for só o apontamento; o update de verdade fica pra quando o TEXTO/estrutura mudar.
+- `{template_id}` é o **id numérico da Meta** (o campo `id` do template na listagem), não o nome.
+- O conjunto enviado **substitui** todos os apontamentos de corpo: mande TODAS as variáveis que
+  devem ficar apontadas, não só a que mudou (a ausente é removida). Vazio `{}` limpa tudo.
+- Chaves `_` (`_button_url`, `_header_media`, `_header_location`) são preservadas sozinhas e
+  **recusadas** como entrada — pra mexer nelas, use o update normal.
+- Recusas (422): categoria AUTHENTICATION, chave que não existe no corpo aprovado, valor sem
+  `{source, field}`, `source` fora de contact/conversation/account/custom, caixa que não seja
+  WhatsApp Cloud oficial.
+- Papel: administrador.
+
 ### Botão de link do template com variável — link rastreável por cliente (2026-07-25)
 
 O botão de URL do template pode terminar com uma variável, pra montar um link diferente por contato

package/dist/docs/resources/conversation-flows.md

@@ -255,6 +255,33 @@ Conversa resolvida que recebe nova mensagem do cliente:
 - Default: cria NOVA conversa (mantém histórico)
 - Se locked: reabre a mesma conversa (`status` volta a 0)
 
+### 10. Criar conversa por API — REGRA NOVA (2026-08-04)
+
+**Nunca nasce conversa nova se o contato já tem uma ABERTA naquela caixa.** Vale para todo caminho
+iniciado por nós: `lionchat_conversations_create`, campanha, flow, booking, integração.
+
+| Situação do contato naquela caixa | O que `conversations_create` devolve |
+|---|---|
+| Tem conversa **aberta / pendente / adiada / silenciada** | A **conversa existente**, com o mesmo `id`. Não cria |
+| Só tem conversa **resolvida** | Cria conversa NOVA (invariante do produto: "fechou = abre nova") |
+| Caixa com `lock_to_single_conversation` LIGADO | **Sempre** a existente, mesmo resolvida — reabre |
+| Caixa de **e-mail** | Sempre cria nova (o assunto da thread vem da conversa; reusar mandaria o e-mail com o assunto velho) |
+
+**Como saber se reusou:** compare o `id` devolvido com o que você esperava. Vem HTTP 200 nos dois
+casos, sem aviso. Se precisa garantir conversa nova, feche a anterior antes
+(`conversations_toggle_status` para `resolved`).
+
+**O que é DESCARTADO no reuso** (a conversa já existe; o disparo não reescreve o estado dela):
+`status`, `snoozed_until`, `additional_attributes` e `assignee_id`. Se você precisa trocar o
+responsável, chame `conversations_update` depois — não adianta mandar junto na criação.
+
+**O que É aproveitado:** `custom_attributes` entram por merge, **sem sobrescrever chave que já tem
+valor**. A conversa mantém a origem com que nasceu e só ganha o que ainda não tinha.
+
+**Reuso não dispara `conversation_created`** — automação, gatilho de flow, webhook de saída,
+notificação e a Agenda não rodam. Se o seu fluxo depende de um desses, ele não vai acontecer
+quando houver reuso.
+
 ## Estado relacional
 
 ```
@@ -634,10 +661,41 @@ Todos os formatos abaixo foram conferidos linha a linha em `app/services/action_
 | `add_note_to_kanban_item` | `[{"funnel_id": 31, "text": "texto da nota"}]` — a chave e **`text`**, nao `note` |
 | `set_kanban_item_status` | `[{"funnel_id": 31, "status": "won"}]` — `won`, `lost` ou `open`. Status fora disso e ignorado |
 | `start_kanban_item_timer` / `stop_kanban_item_timer` | `[{"funnel_id": 31}]` |
+| `wait` | `[30]` — segundos. Ver "Acao Aguardar" abaixo |
 
 **Acoes de Kanban:** todas precisam que a conversa ja tenha um card no funil informado. Sem card,
 a acao e pulada (fica so no log do servidor). Use `create_kanban_item` antes, na mesma regra.
 
+### Acao `wait` (Aguardar) — novo 2026-08-04
+
+Pausa a regra: as acoes **seguintes** so rodam depois do tempo passar. As anteriores ja rodaram.
+
+```json
+{ "action_name": "wait", "action_params": [30] }
+```
+
+| Regra | Detalhe |
+|---|---|
+| Unidade | **segundos** |
+| Teto | **300** (5 minutos). Valor maior e limitado a 300 em silencio, sem erro |
+| Formatos aceitos | `[30]`, `30`, `"30"` e `{"seconds": 30}` — todos funcionam |
+| Tempo invalido | `[]`, `[0]`, `[""]` ou ausente = **nao pausa**, a regra segue direto. Nao da erro |
+| Ultima acao da regra | Nao agenda nada (nao ha o que retomar depois) |
+| Pilula "Automacao X disparou" | So aparece na 1a rodada, nao se repete na volta |
+
+**Para que serve.** O caso que originou: a regra mandava a mensagem **antes** da politica de
+atribuicao carimbar o responsavel, entao a variavel com o nome do atendente saia vazia. Meio
+segundo de espera resolve. Use quando a acao seguinte depende de algo que outro processo ainda
+esta gravando (atribuicao, card recem-criado, atributo que outra regra vai escrever).
+
+**Precisa de mais de 5 minutos?** O lugar certo e o FlowBuilder, que tem espera em horas e sessao
+propria pra sustentar o estado. A automacao nao foi feita pra isso.
+
+**A regra nao "dorme":** ao encontrar a espera ela encerra a rodada e agenda a retomada. Varias
+conversas esperam ao mesmo tempo sem travar o atendimento. Na volta, o sistema confere se a regra
+ainda existe e esta ligada, se a conversa ainda existe e se a caixa nao foi excluida — se algo
+disso mudou, ele simplesmente nao retoma.
+
 Lista autoritativa de nomes validos: `AutomationRule#actions_attributes` no backend. Nome de acao
 fora dessa lista e recusado com 422 ao salvar — isso a API valida. O que ela **nao** valida e o
 conteudo do `action_params`. `apply_kanban_checklist_template` existe no motor mas **nao** e uma

package/dist/docs/resources/data-model.md

@@ -286,12 +286,16 @@ Captain::Scenario (cenários do assistente — instruções inline, sem handoff)
 │     ⚠️ trigger_type NAO é editável via API hoje — todo cenário criado por API fica em
 │     llm_interpreted (a IA decide aplicar lendo a conversa). Os modos programáticos só
 │     via banco/console por enquanto.
-└── tool_bindings (jsonb — parâmetro FIXADO pelo admin por tool; "IA decide" = ausente/vazio)
-      send_media_asset → { asset_ids: [Int] } | create_kanban_item / move_kanban_item →
-        { funnel_id: Int, stage: "<key>" } | create_booking → { event_type_ids: [Int] }
-      Obs: via API/MCP, scenarios_update SÓ persiste send_media_asset/create_kanban_item/
-        move_kanban_item. O binding create_booking é só de UI/runtime — NÃO round-trippa pela API.
-        Use config.booking_event_type_ids no assistente pra restringir agendas via MCP.
+├── tool_bindings (jsonb — parâmetro FIXADO pelo admin por tool; "IA decide" = ausente/vazio)
+│     send_media_asset → { asset_ids: [Int] } | create_kanban_item / move_kanban_item →
+│       { funnel_id: Int, stage: "<key>" } | create_booking → { event_type_ids: [Int] }
+│     Obs: via API/MCP, scenarios_update SÓ persiste send_media_asset/create_kanban_item/
+│       move_kanban_item. O binding create_booking é só de UI/runtime — NÃO round-trippa pela API.
+│       Use config.booking_event_type_ids no assistente pra restringir agendas via MCP.
+└── document_ids (jsonb, default [] — DERIVADO das menções [@Nome](document://ID) escritas na
+      instruction; NUNCA aceito como param na API/MCP (é ignorado se enviado); re-escopado por
+      assistente+conta; teto de 3 documentos. Serve pra IA PRIORIZAR a busca RAG naquelas páginas —
+      NÃO é exclusividade: o resto da base continua pesquisável)
 
 Captain::AssistantResponse (FAQ)
 ├── assistant_id (FK)
@@ -412,14 +416,25 @@ Atributos de sistema no CONTATO (prefixo `eclinica_`, protegidos, usáveis como
 | `eclinica_idagenda` | text | ID do último agendamento |
 | `eclinica_data_consulta` | date | Data da consulta, ISO |
 | `eclinica_hora_consulta` | **time** | Hora da consulta 24h `"HH:MM"` (novo 2026-07-06) |
+| `eclinica_hora_final` | **time** | Hora final da consulta (novo 2026-07-27) |
 | `eclinica_status_agendamento` | text | agendado / no_show / atendido / desmarcado |
-| `eclinica_compromisso` | text | Tipo da consulta (ex: Consulta, Retorno, Exame) |
+| `eclinica_situacao` | text | Situação crua da agenda (age_situacao do webhook) |
+| `eclinica_compromisso` | text | Tipo da consulta — TEXTO LIVRE da recepção (ex: Consulta, Retorno) |
+| `eclinica_agendatipo` | text | Tipo de Agendamento — NOME da lista fixa do painel, resolvido por unidade (novo 2026-07-28). **Filtrar sempre pelo NOME, nunca pelo número: os números colidem entre filiais** |
+| `eclinica_agendatipo_id` | text | Tipo de Agendamento — número cru (não comparável entre filiais) |
+| `eclinica_profissional` | text | NOME do profissional, resolvido por unidade (novo 2026-07-10) |
+| `eclinica_profissional_id` | text | Número do profissional (não comparável entre filiais) |
+| `eclinica_convenio_id` | text | Convênio (número) |
+| `eclinica_ultimo_evento` | text | Tipo do último webhook recebido (ex: falta, agendamento_novo) |
 | `eclinica_ultimo_pagamento` | text | Valor do último pagamento |
 | `eclinica_ultimo_pagamento_data` | date | Data do último pagamento/baixa (novo 2026-07-06) |
 | `eclinica_ultimo_pagamento_descricao` | text | Descrição da baixa (ex: CONSULTA INICIAL) |
 | `eclinica_laboratorio_data_prevista` | date | Previsão de entrega da medicação (novo 2026-07-23) |
 | `eclinica_laboratorio_data_moldagem` | date | Data do pedido da medicação |
-| `eclinica_laboratorio_data_entrega` | date | Data de entrega da medicação |
+| `eclinica_laboratorio_data_entrega` | date | Data em que a medicação CHEGOU na unidade — é a data que dispara o aviso de retirada do flow |
+| `eclinica_laboratorio_data_retirada` | date | Data em que o paciente RETIROU a medicação (coa_datainstalacao; novo 2026-08-03). NÃO confundir com a entrega. Vazia = peça atual não retirada |
+| `eclinica_laboratorio_trabalho_id` | text | Trabalho/tipo da medicação — número cru (aparelho_id; novo 2026-08-03). Lista própria de cada unidade (COMPRIMIDO/POMADA/SPRAY...); número não comparável entre filiais |
+| `eclinica_laboratorio_trabalho` | text | Trabalho/tipo da medicação — NOME resolvido na lista da própria unidade ("SPRAY", "POMADA"...; novo 2026-08-03). Best-effort: pode ficar vazio se a API da unidade estiver fora do ar. Para filtrar/personalizar flows, use SEMPRE este NOME, nunca o número |
 | `eclinica_laboratorio_situacao` | text | Situação do pedido no laboratório |
 | `eclinica_ultima_cobranca_valor` | text | Valor da última cobrança/carnê gerado |
 | `eclinica_ultima_cobranca_vencimento` | date | Vencimento da última cobrança |

package/dist/docs/resources/filtros-e-relatorios.md

@@ -108,6 +108,12 @@ stage_id/inbox_id/sort_by/sort_direction/page foram REMOVIDOS, eram ignorados pe
 - `funnel_id` (obrigatório), `stages[]` (chaves internas das etapas), `priorities[]`,
   `statuses[]` (open/won/lost), `agent_id`, `value_min`/`value_max`
 - `date_start`/`date_end` (criação do card, YYYY-MM-DD)
+- `stage_date_start`/`stage_date_end` (2026-08-07) — **quando o card ENTROU na etapa em que ele está
+  agora** (`stage_entered_at`, caindo em `created_at` para card que nunca se moveu). NÃO confundir com
+  `date_start`/`date_end`: um card criado em janeiro e arrastado ontem casa AQUI e não casa lá. É o que
+  responde "o que se mexeu essa semana". Pontas independentes, e os dois períodos podem ser combinados.
+  Nuance ao explicar pro usuário: card criado ontem que nunca se moveu TAMBÉM entra (ele entrou na
+  etapa ao nascer) — o que o filtro separa de verdade é o card VELHO que se moveu.
 - `scheduled_date_start`/`scheduled_date_end` (agendamento: scheduled_at/deadline_at do card E
   tarefas da agenda vinculadas)
 - `task_filter`: has_task | no_task | today | tomorrow | this_week | overdue
@@ -125,9 +131,47 @@ NÃO há filtro por time aqui (por time: use o relatório agregado abaixo, ou fi
 
 `GET /kanban_items/reports` — a resposta é um OBJETO de métricas (não lista): valores GANHOS,
 contagem/valor por etapa, forecast ponderado, top negócios, cards parados, metas do funil.
-Params: `funnel_id` (obrigatório), `from`, `to`, `user_ids[]` (agentes), `team_id`.
+Params: `funnel_id` (obrigatório), `from`, `to`, `user_ids[]` (agentes), `team_id`, `date_basis`.
 É a ferramenta certa pra "relatório de vendas/ganhos do mês por agente ou time".
 
+**`date_basis` (2026-08-07) — qual data o período considera.** A resposta devolve a régua aplicada em
+`dateBasis`; valor inválido cai no padrão sem erro.
+
+| Valor | O que o período recorta | Quando usar |
+|---|---|---|
+| `any` (PADRÃO) | criado no período **OU** fechado no período | É a régua histórica e a mais larga. **Omitir mantém exatamente os números de sempre.** É a certa pra RECEITA: com qualquer outra, venda fechada no período de um lead antigo some (medido 07/08: 17% dos ganhos da frota) |
+| `created` | só quando o card nasceu | "quantos leads entraram" |
+| `moved` | só quando entrou na etapa atual (mesma expressão do `stage_date_*` da seção 3) | "o que se mexeu no período" |
+| `closed` | só ganhos/perdidos no período | **a pergunta de receita** — é a régua certa pra "quanto vendemos em julho" |
+
+O relatório de UMA etapa — tool `lionchat_funnels_stage_report` (`GET /funnels/:id/stage_report`, o
+painel que abre dentro do quadro) — tem as MESMAS 4 opções de régua, mesmo parâmetro `date_basis` e as
+MESMAS expressões da seção 3, mas o **padrão dele é `moved`**, não `any`. Não é inconsistência: ele
+responde uma pergunta só ("quantos cards entraram nesta etapa no período"), enquanto o
+`/kanban_items/reports` é uma rede larga que alimenta várias métricas de uma vez. Se o usuário disser
+que as duas telas não batem, a resposta é: escolha a MESMA régua nas duas.
+
+Ela devolve números calculados no SERVIDOR (total de cards da etapa, faixa de valores, ganhos/perdidos,
+distribuição por prioridade, ranking de vendedores da etapa) — antes a tela só somava os cards já
+carregados na coluna.
+
+**Parâmetros de `lionchat_funnels_stage_report`:**
+
+| Param | Obrigatório | O que faz |
+|---|---|---|
+| `id` (path) | sim | id do funil |
+| `stage` | sim | chave interna da etapa |
+| `date_basis` | não | `any` / `created` / `moved` / `closed` — **PADRÃO `moved`** (entrada na etapa). ATENÇÃO: no relatório agregado do funil o padrão é `any`; aqui é `moved` de propósito |
+| `report_from` / `report_to` | não | janela (YYYY-MM-DD) da régua de data do relatório |
+| `priorities[]` | não | array de prioridades |
+| `agent_id` | não | responsável; `-1` = sem responsável |
+| `value_min` / `value_max` | não | faixa de valor do card (número) |
+| `date_start` / `date_end` | não | filtro por data de CRIAÇÃO do card |
+| `scheduled_date_start` / `scheduled_date_end` | não | filtro por agendamento |
+
+Ao apresentar número pro usuário, DIGA qual régua usou. Duas réguas diferentes respondem a mesma
+pergunta com números diferentes, e o usuário conclui que o relatório está errado.
+
 ## 5. Busca com filtro estruturado
 
 `search_search` (tudo), `conversations_search`, `contacts_search`, `kanban_items_search` aceitam

package/dist/docs/resources/flowbuilder-design-guide.md

@@ -24,7 +24,7 @@ Como criar fluxos do LionChat (FlowBuilder) que abrem certinhos no canvas, sem n
 | Analisar sentimento | `ai` mode `sentiment` | - |
 | Encerrar fluxo no meio | `action` com `key: 'deactivate_flow'` OU `exit_conditions` no nível do flow | - |
 | Distribuir aleatório entre branches | `randomizer` | - |
-| Atualizar info de grupo WhatsApp (WAHA) | `update_group` | - |
+| Gerir grupo WhatsApp: criar/buscar, nome/foto/descrição, participantes, admins, convite (WAHA) | `update_group` (uma operação por bloco via `groupOperation`) | - |
 | Iniciar outro fluxo | `action` com `key: 'start_flow'` OU node `activate_flow` | - |
 | Encerrar ramo / definir retorno de ai_tool | `end` | - |
 | Anotação visual no canvas (não executa) | `note` | - |
@@ -337,6 +337,7 @@ só pra destravar, ela pode sair.
 | `is_number` / `is_letter` / `is_email` / `is_phone` | validação de formato |
 | `regex` | padrão regex em `value` |
 | `equal_any` / `not_equal_any` / `contains_any` / `not_contains_any` | multi-valor (usa `values` array). `contains_any` = contém ALGUMA; `not_contains_any` = não contém NENHUMA (útil pra "seguir só quando a msg não tem nenhuma das palavras-chave de outros flows") |
+| `starts_with_any` / `ends_with_any` (novo 2026-08-07) | multi-valor (usa `values` array), caixa-insensível. `starts_with_any` = o texto COMEÇA com ALGUMA das palavras da lista; `ends_with_any` = o texto TERMINA com alguma |
 | `business_hours` / `outside_business_hours` | horário comercial (par: dentro/fora). `business_hours` aceita `start_hour`/`end_hour` (0-23), `days` (array 0=Dom..6=Sab, ausente=todos) e **`timezone`** (IANA, ex.: `America/Sao_Paulo` — default se ausente). **REGRA:** a saída `outside_business_hours` HERDA `start_hour`/`end_hour`/`days`/`timezone` da `business_hours` ANTERIOR no array — pode deixá-los ausentes na "fora" (o backend preenche). O horário é avaliado no `timezone` (não em UTC) |
 | `can_reply` / `can_reply_closed` | janela 24h aberta/fechada |
 | `conversation_has_agent` / `conversation_no_agent` / `conversation_not_agent` | agente atribuído (HUMANO) |
@@ -433,6 +434,7 @@ o botão "Usar variável" ao lado do campo alterna lista fixa ↔ variável.
 | `add_conversation_label` | `{ labels: ['slug'] }` | Adiciona labels à CONVERSA (não ao contato) |
 | `remove_conversation_label` | `{ labels: ['slug'] }` | Remove labels da CONVERSA |
 | `mute_conversation` | `{}` | Silencia notificações |
+| `mark_unread` | `{}` | Marca a conversa como NÃO LIDA pro time (espelho do `mute_conversation`; típico logo após `assign_agent`/`assign_team` numa transferência) |
 | `add_private_note` | `{ content: 'texto' }` | Adiciona nota interna |
 | `create_kanban_item` | `{ funnel_id, funnel_stage, title?, description? }` | Cria card no Kanban — `funnel_id` e `funnel_stage` OBRIGATÓRIOS; `title`/`description` aceitam variáveis `{{ }}` |
 | `move_kanban_item_to_stage` | `{ funnel_stage }` | Move card (precisa ter card vinculado) |
@@ -696,9 +698,29 @@ tela do cliente (a tela lê só `percent`).
 
 **Handles que SAEM:** o `id` de cada branch (`A`, `B`, ...). Em `mode: 'distribute_agents'` é `success`.
 
-### 2.11 `update_group` (WAHA apenas)
+### 2.11 `update_group` — Gestão de Grupos (WAHA apenas)
 
-Atualiza nome/descrição/foto de grupo WhatsApp. Use só quando flow roda em inbox WAHA e a conversa for de grupo.
+Bloco "Gestão de Grupos". Faz **UMA operação por bloco** (não mais um formulário-só com nome/foto/descrição
+juntos) — a operação vai em `data.groupOperation`. São **17 operações**, agrupadas por tema:
+
+- **Grupo:** `create` (criar), `find_by_id` (buscar por id), `find_by_name` (buscar por nome), `update_subject`
+  (mudar nome), `update_description` (mudar descrição), `update_picture` (mudar foto), `settings` (3
+  permissões: quem edita infos, quem manda mensagem, quem adiciona membro), `leave` (sair do grupo).
+- **Participantes:** `list_participants` (listar), `add_participants` (adicionar), `remove_participants` (remover).
+- **Admins:** `promote_admin` (promover a admin), `demote_admin` (rebaixar).
+- **Convite:** `get_invite` (pegar link/código de convite), `revoke_invite` (revogar), `send_invite` (mandar
+  o convite por mensagem a um telefone).
+
+**Disponível em fluxo de QUALQUER canal**, desde que a conta tenha uma caixa **WhatsApp QR Code
+(`Channel::Waha`)** — informe a caixa em `data.groupInboxId`. Esse campo é **OBRIGATÓRIO em fluxo não-grupo**
+(individual/qualquer canal) e **opcional em fluxo de grupo** (ali o padrão é o grupo da própria conversa).
+
+Cada operação guarda o resultado na variável `data.groupResponseVar` (padrão `"grupo"`) — leia depois com
+`{{grupo.CAMPO}}` (ex.: `{{grupo.id}}`, `{{grupo.participants_count}}`, `{{grupo.invite_link}}`).
+
+Teto de **20 participantes por execução** (trava anti-banimento — adicionar em lote é o que mais rápido
+derruba número no WhatsApp não-oficial). Detalhe das chaves de `data` por operação: ver o pattern
+"Gestão de Grupos WhatsApp por fluxo" no `flowbuilder-patterns`.
 
 **Handles que SAEM:** `success`, `error`.
 
@@ -803,14 +825,15 @@ Na tela o usuário vê isso como TRÊS opções ao criar: "Mensagem" (= `convers
 
 | | individual (Mensagem) | group (Grupo) |
 |---|---|---|
-| Node `update_group` (Configurar Grupo: nome, foto, permissões — WAHA) | NÃO existe | **SÓ aqui** |
+| Node `update_group` (Gestão de Grupos — WAHA) | disponível se a conta tem caixa QR Code — exige `groupInboxId` | disponível; `groupInboxId` opcional (padrão = grupo da conversa) |
 | Gatilhos e condições de **LionTrack** (visita de página / evento do site) | disponíveis | **NÃO** (grupo não tem um contato único navegando) |
 | Gatilho `date_trigger` (data do contato) | disponível | **NÃO** (grupo não tem um contato único) |
 | Todos os outros nodes (`send_message`, `wait_response`, `condition`, `action`, `api`, `ai`, `set_variable`, `wait`, `randomizer`, `note`, `end`) | iguais | iguais |
 
 Regras práticas ao montar via API:
-- Só use o node `update_group` se o flow foi criado com `conversation_mode: "group"`. Colocá-lo num flow
-  individual é rejeitado pela validação.
+- O node `update_group` (Gestão de Grupos) funciona em fluxo de QUALQUER canal, desde que a conta tenha
+  caixa WhatsApp QR Code (`Channel::Waha`): informe a caixa em `data.groupInboxId` (OBRIGATÓRIO em fluxo
+  não-grupo; opcional em fluxo de grupo, onde o padrão é o grupo da própria conversa).
 - Não use gatilho/condição de LionTrack (pagetrack) em flow de grupo.
 - Na dúvida entre os dois, é `individual` (o default).
 Não tente contornar criando flows intermediários.
@@ -866,6 +889,14 @@ Presentes conforme o evento (ausente = resolve vazio, sem erro):
 | `{{trigger.contact.*}}` | `id`, `name`, `phone` |
 | `{{trigger.ad.*}}` (anúncio/CTWA) | `id`, `name`, `creative_id`, `creative_name`, `adset_id`, `adset_name`, `campaign_id`, `campaign_name`, `source`, `headline`, `description`, `cta`, `url` |
 | `{{trigger.attribute.*}}` | `name`, `previous_value`, `current_value`, `changed_at` — o valor ANTES e DEPOIS do atributo que disparou (só nos gatilhos de mudança de atributo) |
+| `{{trigger.user_name}}` | nome do usuário/atendente que disparou (gatilho manual ou ativação manual) |
+| `{{trigger.campaign_title}}` | título da campanha (quando disparado por Campanha de Fluxo) |
+| `{{trigger.event_name}}` | nome do evento do site que disparou (LionTrack / visita de página) |
+| `{{trigger.page_url}}` | URL da página (LionTrack / visita de página) |
+| `{{trigger.source_flow_name}}` | nome do flow de origem (quando outro flow iniciou este, ex.: action `start_flow`) |
+
+Os cinco últimos são **novos 2026-08-07** e passam a aparecer no autocomplete de TODO bloco (ausente para
+o gatilho que não os fornece = resolve vazio, sem erro).
 
 Dois atalhos: `{{trigger}}` devolve o contexto INTEIRO em JSON e `{{trigger.data}}` devolve o mesmo
 sem os metadados — úteis pra jogar tudo dentro de um node `ai` ou `api`. Bloco (Hash/Array) inteiro

package/dist/docs/resources/flowbuilder-patterns.md

@@ -551,6 +551,78 @@
 
 ---
 
+## 17. Gestão de Grupos WhatsApp por fluxo (`update_group`)
+
+**Caso:** ao marcar um lead como GANHO no Kanban, criar automaticamente um grupo de onboarding com ele e
+confirmar pela conversa. Usa o node `update_group` (bloco "Gestão de Grupos") na operação `create`. Só
+funciona em conta com caixa **WhatsApp QR Code (`Channel::Waha`)** — a caixa vai em `groupInboxId`
+(OBRIGATÓRIO neste fluxo, que não é de grupo).
+
+```json
+{
+  "nodes": [
+    { "id": "n1", "type": "start", "position": { "x": 50, "y": 300 }, "data": { "label": "Início", "triggers": [{ "type": "card_won", "funnel_ids": ["1"] }] } },
+    { "id": "n2", "type": "update_group", "position": { "x": 370, "y": 300 }, "data": {
+      "label": "Cria grupo de onboarding",
+      "groupOperation": "create",
+      "groupInboxId": 5,
+      "groupName": "Onboarding — {{contact.name}}",
+      "groupParticipants": ["5511999999999@c.us"],
+      "groupResponseVar": "grupo"
+    } },
+    { "id": "n3", "type": "send_message", "position": { "x": 690, "y": 300 }, "data": { "label": "Confirma", "messageItems": [
+      { "id": "m1", "type": "text", "content": "Prontinho, {{contact.name}}! Criei seu grupo de onboarding (id {{grupo.id}}) com {{grupo.participants_count}} participante(s). Já te chamo por lá." }
+    ] } }
+  ],
+  "edges": [
+    { "id": "e1", "source": "n1", "target": "n2", "sourceHandle": "success", "type": "deletable", "animated": true },
+    { "id": "e2", "source": "n2", "target": "n3", "sourceHandle": "success", "type": "deletable", "animated": true }
+  ]
+}
+```
+
+**Chaves de `data` por operação (`groupOperation`):**
+
+Comuns a (quase) todas:
+- `groupOperation` — a operação (uma por bloco).
+- `groupTargetId` — o grupo alvo. Vazio = grupo da conversa (só faz sentido em fluxo de grupo); aceita
+  `"1203...@g.us"`, só dígitos ou uma variável `{{var}}`. **Ignorado** em `create` e `find_by_name` (não têm alvo).
+- `groupInboxId` — id da caixa QR Code que fala com o WhatsApp. **OBRIGATÓRIO em fluxo não-grupo**; opcional em
+  fluxo de grupo (padrão = grupo da conversa).
+- `groupResponseVar` — nome da variável de saída (padrão `"grupo"`); leia com `{{grupo.CAMPO}}`.
+
+| Operação | Chaves específicas | Retorno (`{{grupo.*}}`) |
+|---|---|---|
+| `create` | `groupName` (obrig), `groupDescription`, `groupPicture` (url), `groupInitialAdmins`, `groupParticipants` | `id`, `name`, `participants_count` |
+| `add_participants` | `groupParticipants` (obrig — ex.: `["5511999999999@c.us"]` ou lista) | `added`, `not_added`, `added_count` |
+| `send_invite` | `groupInviteTo` (obrig — telefone de destino), `groupInviteMessage` (opc) | `invite_link` |
+| `settings` | pelo menos uma de `infoAdminOnly` / `messagesAdminOnly` / `membersCanAddNewMember` (booleans) | — |
+
+**ATENÇÃO na `settings` — semântica INVERTIDA de `membersCanAddNewMember`:** `true` = **TODOS** podem adicionar
+membros. Já `infoAdminOnly: true` e `messagesAdminOnly: true` = **SÓ admin** edita infos / manda mensagem.
+Confundir os dois LIBERA o grupo achando que está trancando.
+
+**Gatilho novo `group_participant_joined` (entrou no grupo → manda boas-vindas):** em um flow de grupo
+(`conversation_mode: "group"`), o start pode ter o item `{ "key": "group_participant_joined", "config": {
+"group_match": "any", "group_name": "", "group_ids": [] } }`. Filtro OPCIONAL de quais grupos disparam:
+`group_match` (`any` padrão, ou os mesmos operadores do "Buscar por nome": `contains`, `equal_to`, `starts_with`,
+`ends_with`, `does_not_contain`, `not_equal_to`) + `group_name`, e/ou `group_ids` (mira exata por id — casa por
+dígitos, aceita `1203...@g.us` ou só o número). Quando alguém entra, o `send_message` seguinte cai **no próprio
+grupo** (o grupo é a conversa do flow).
+
+**Lembretes:**
+- **Teto de 20 participantes por execução** (`add_participants`/`create`) — trava ANTI-BANIMENTO, não performance.
+  Adicionar em lote é o que mais rápido derruba número no WhatsApp não-oficial.
+- O fluxo só dispara/roda em caixa `Channel::Waha` (QR Code). WhatsApp oficial/Instagram/Facebook/e-mail não
+  têm grupo.
+- No fluxo de card ganho acima, o `send_message` vai para a conversa do CONTATO (o lead), não para o grupo
+  criado. Para postar DENTRO do grupo, use um flow de grupo (`conversation_mode: "group"`) — normalmente com o
+  gatilho `group_participant_joined`.
+- Em `add_participants`, quem tem privacidade de grupo ligada pode não entrar mesmo com resposta de sucesso do
+  WhatsApp: confira `{{grupo.not_added}}` / `{{grupo.not_added_count}}`.
+
+---
+
 ## Como usar este catálogo
 
 1. **Identifique o pattern mais próximo** do que o cliente pediu

package/dist/docs/resources/glossary.md

@@ -254,7 +254,10 @@ comportamento intencional.
 - `config.instructions`: prompt sistema (Liquid template, até 20.000 chars)
 - `config.activation_label`: etiqueta que ativa o agente na conversa (única por conta)
 - **Cenário (Captain::Scenario)**: instrução situacional inline do assistente; o raciocínio de
-  aplicação fica no "caderninho do cenário" da conversa (scenario_checklist, card Raciocínio)
+  aplicação fica no "caderninho do cenário" da conversa (scenario_checklist, card Raciocínio).
+  Pode apontar páginas da base de conhecimento escrevendo `[@Nome](document://ID)` na instrução
+  (campo derivado `document_ids`, teto de 3) para a IA PRIORIZAR a busca RAG naquelas páginas —
+  prioridade, não exclusividade
 - **Regra DITO ≠ SALVO**: a IA só considera coletado o dado que foi PERSISTIDO — salva cada dado
   na hora e não repergunta o que já salvou
 - **Cenário com parâmetro fixo (tool_bindings)**: o admin pode fixar o parâmetro de uma ferramenta do cenário — quais mídias enviar, qual funil+etapa criar/mover o card, quais agendas usar no agendamento. Com 1 cenário fixando a tool, a execução é DETERMINÍSTICA (a IA não escolhe): mídia/kanban rodam pós-turno (BindingResolver); o agendamento força/restringe a agenda mas a IA ainda escolhe a data/hora.

package/dist/docs/resources/kanban-deep-dive.md

@@ -115,7 +115,8 @@ Um card individual dentro de uma etapa.
 | `funnel_stage` | Chave da etapa (ex: `"novo_lead"`) |
 | `position` | Ordem dentro da etapa |
 | `stage_entered_at` | Quando entrou na etapa atual (pra métrica de tempo) |
-| `conversation_display_id` | Conversa principal vinculada |
+| `conversation_display_id` | Conversa principal vinculada. **O sistema move este ponteiro sozinho (desde 04/08/2026)**: quando nasce uma conversa nova do mesmo contato naquela caixa, o card passa a apontar pra ela. O card é da PESSOA, não do atendimento. **NÃO trate este valor como estável** — releia antes de usar. Enviar `conversation_display_id` num UPDATE de card é ignorado de propósito (senão o reenvio do formulário regravaria o número antigo por cima). |
+| `origin_conversation_display_id` | Conversa em que o card NASCEU (só preenchida se o vínculo já foi movido). É o que o relatório de origem de lead usa, pra uma venda não mudar de mês nem de anúncio quando o card anda. |
 | `linked_conversations` | jsonb array `[{display_id: 123}, {display_id: 456}]` — múltiplas conversas |
 | `item_details` | jsonb (ver abaixo) |
 | `custom_attributes` | jsonb — campos custom (igual contatos) |

package/dist/docs/resources/reports-guide.md

@@ -90,10 +90,12 @@ um número errado com confiança.
 | Cumprimento de prazo (SLA) | "100%" para conta com ZERO prazo aplicado — escondia "o SLA não está rodando" | Vazio = sem dados |
 | Por CANAL — conversa de caixa EXCLUÍDA (29/07) | Sumia do relatório: excluir a caixa deixa a conversa sem caixa, e o join descartava essas linhas em silêncio. 512 conversas órfãs de 10 contas em 30 dias; a **conta 60 perdia 76%** do total, a 40 perdia 38%, a 38 perdia 24% | Entram sob a chave **`Channel::None`** ("Caixa excluída"). Some essa chave também — se ignorar, você subconta de novo |
 | Horário de PICO do mapa de calor (29/07) | Dias e horas saíam em **UTC** mesmo mandando `timezone_offset`: no Brasil, o pico aparecia **3 horas adiantado** (o movimento das 11:00 de Brasília era rotulado como 14:00). O cabeçalho do CSV escrevia "(GMT-03:00) Brasília", o que dava aparência de certo | Balde de dia/hora sai do fuso pedido |
+| "Nº de Conversas" por ETIQUETA (07/08) | Contava conversas **CRIADAS** no período que têm a etiqueta — etiquetar hoje uma conversa antiga não mexia no relatório de hoje (caso real: dono etiquetou 2 e o número ficou em 1) | Conta conversas que **RECEBERAM a etiqueta** no período (`taggings.created_at`), no resumo E no detalhe (cartão + gráfico). Renomear etiqueta preserva as datas. Consequência: mês fechado passa a MUDAR se etiquetas forem adicionadas/removidas retroativamente |
 
 **Como reconhecer instalação antiga:** soma dos canais menor que o total do resumo; tempo médio por
 etiqueta absurdamente baixo perto do tempo por atendente; "pendentes" zerado no ao vivo tendo
-conversa pendente na lista; "100%" de prazo com nenhum prazo aplicado.
+conversa pendente na lista; "100%" de prazo com nenhum prazo aplicado; etiqueta aplicada hoje em
+conversa antiga que NÃO aparece no relatório de hoje (régua antiga por criação da conversa).
 
 ## Mapeamento dos endpoints `lionchat_reports_*`