@lionchat/mcp-server 1.22.0 → 1.24.0

package/dist/docs/instructions.md

@@ -170,10 +170,29 @@ Detalhes completos em `lionchat://docs/api-conventions` → "Wrapper de body".
 ### Regras de formato silenciosas
 
 - **Label.title**: kebab-case ou snake_case, **SEM espaço**. `"Lead Emive"` ❌ → `"lead-emive"` ✅
-- **win_reasons / loss_reasons**: array de `{id, title}`, NÃO strings
+- **win_reasons / loss_reasons**: array de `{id, title}`, NÃO strings. O `id` é **TEXTO estável** (`"perda-preco"`),
+  nunca número. A lista SUBSTITUI a atual: leia antes e reenvie os MESMOS `id` (trocar o `id` tira o nome dos
+  cards já marcados). Motivo sem `id`/`title`, `id` repetido ou lista de textos → recusado com 422
+- **motivo no card**: `item_details.status` `"lost"`/`"won"` + `loss_reason`/`win_reason` = o `id` (texto) de um
+  motivo cadastrado + `reason` = o título. Motivo livre: `loss_reason` nulo e o texto em `reason`
 - **linked_conversations**: array de `{display_id: N}`, NÃO inteiros direto
 - **phone**: E.164 (`+5511...`), sem espaços/parênteses
-- **funnel.stages** keys: snake_case slug
+- **funnel.stages** keys: snake_case slug; cada etapa é OBJETO com `name` texto
+- **Lista de objetos é lista de objetos**: onde o formato pede `[{id: 5}]`, número solto (`[5]`) ou objeto
+  único no lugar da lista quebra a leitura — às vezes a tela da conta inteira (incidente 18/09, funil).
+
+### Gravação: TROCA inteira × SOMA (conferido no código em 18/09/2026)
+
+Muitos campos objeto/lista são **trocados inteiros** no update: o que não vier no envio é APAGADO. Nesses,
+**leia antes** (show) e **reenvie tudo** com o item alterado. A descrição de cada ferramenta diz qual é qual.
+
+| TROCA inteira (leia e reenvie tudo) | SOMA (só as chaves enviadas mudam) |
+|---|---|
+| `custom_attributes` da CONVERSA (`conversations_create_3` — só `captain_*` sobrevive; apaga utm/gclid/ctwa/origin) | `custom_attributes` do CONTATO (`contacts_update`) |
+| card: cada chave de `item_details` (a lista `custom_attributes` do card, `offers`, `notes`), `assigned_agents`, coluna `custom_attributes` | `item_details` do card no 1º nível (chave não enviada fica) |
+| `funnel.settings`, `funnel.stages` (etapa ausente = removida), `kanban_config.global_custom_attributes` | `channel.additional_attributes` da caixa WhatsApp/Instagram/Facebook/TikTok |
+| `flow_data` do fluxo, `actions` de macro/automação, `query` de filtro salvo, `audience` de campanha | `roles_layout` do modelo de contrato |
+| `settings` de integração (hooks), mapas de evento de gateway/Omie/Conta Azul/Meta Lead/Google Ads | |
 
 ### Native first
 

package/dist/docs/resources/agenda-multiplas-unidades.md

@@ -97,6 +97,31 @@ Variável desconhecida **sai crua** para o cliente ("Olá {{name}}, ...").
 horário** para a agenda — decisão do dono. Não use `attendance` para deduzir se o compromisso está
 ativo; para isso existe `status`.
 
+Marcar Compareceu/Faltou também **não conclui a tarefa**: ela segue `pending` (e contando nas
+pendências) até alguém concluir. É de propósito — concluir um compromisso de Booking encerra os lembretes
+e as mensagens pós-atendimento dele e dispara o gatilho de fluxo "agendamento concluído". **Nunca conclua
+a tarefa só porque a presença foi marcada.**
+
+Para responder "o que aconteceu com este compromisso?" use o campo **`selo`** da tarefa (17/09), que já
+junta os dois eixos e a remarcação: `cancelled` > `no_show` / `attended` > `completed` > `snoozed` >
+`rescheduled` > `pending`. É o mesmo rótulo que o painel mostra ao lado da tarefa (Faltou, Compareceu,
+Remarcada...). É só de leitura.
+
+### Responsável de compromisso de Booking é FIXO
+
+O compromisso marcado por um tipo de evento (Booking) cai SEMPRE na agenda do profissional configurado
+nele. Na criação, `assignee_ids` nunca valeu; desde 17/09 também é **ignorado na edição**
+(`lionchat_tasks_update` / `_update_1`): a resposta é 200, o resto da edição vale e o responsável continua
+o mesmo. Para mudar quem atende, altere o profissional do tipo de evento (`booking_event_types_update`).
+
+### Ver como está o dia antes de marcar
+
+`lionchat_agent_availability_day` (17/09) devolve UM dia de até 6 pessoas: o expediente de cada uma e os
+intervalos já ocupados, em "HH:MM" do fuso pedido. O intervalo ocupado de qualquer pessoa da conta vem
+sempre (é o que permite marcar com um colega); o título do compromisso só vem para quem já o veria no
+calendário, e compromisso privado de outra pessoa nunca vem com título. Para Booking, os horários válidos
+continuam sendo os de `booking_event_types_slots` — essa ferramenta é para compromisso COMUM.
+
 ---
 
 ## 5. Google Calendar é UMA CONEXÃO POR AGENDA
@@ -116,12 +141,55 @@ Google dela — inclusive a **mesma pessoa** com contas Google diferentes, uma p
 
 - Agenda **sem** pessoas e **sem** equipes: todo mundo da conta enxerga.
 - Marcando pessoas e/ou equipes: só elas. Quem entrar na equipe ganha acesso sozinho.
-- **Administrador enxerga todas**, sempre.
+- **Administrador enxerga todas**, sempre. Desde 21/09, **quem tem a caixinha `agenda_manage`** ("Gerenciar
+  agenda da equipe") também enxerga todas — é a função da secretária.
 - `member_user_ids` e `member_team_ids` **substituem a lista inteira** (idioma do `InboxMember`).
 
+### `agenda_manage`: a caixinha da secretária (21/09)
+
+Permissão de função personalizada (`custom_roles.permissions`). Quem a tem, **sem ser administrador**:
+- vê a agenda e os compromissos de TODA a conta (`tasks_list` deixa de recortar por pessoa);
+- cria, edita, remarca, cancela e exclui compromisso de qualquer pessoa;
+- marca pelo `booking_event_type` de qualquer pessoa (`tasks_create` com `booking_event_type_id` de outro);
+- cria/edita/apaga `booking_event_types` de outra pessoa (inclusive mandando `user_id` de outro no create);
+- lê e ajusta a disponibilidade de outra pessoa (`agent_availability_*`) e abre o painel de Agentes.
+
+**NÃO** permite criar/editar/apagar AGENDA (unidade): `agendas_create/update/destroy` seguem só administrador —
+agenda é recurso do plano, com limite. Sem a caixinha, o atendente vê só a própria agenda e a de quem ligou
+`agenda_public` no perfil, e não mexe na dos outros.
+
 A listagem de compromissos já vem recortada pelas agendas que o usuário enxerga, **mesmo sem mandar
 `agenda_id`**. Ler ou editar compromisso de uma agenda que a pessoa não enxerga devolve 404.
 
+**Quem não enxerga NENHUMA agenda não vê compromisso nenhum** (21/09). Antes, "lista de agendas
+visíveis vazia" abria em vez de fechar: o recorte tratava igual dois estados opostos — *a conta não
+tem agenda nenhuma* (aí não há o que recortar, devolve tudo) e *a conta tem agendas e esta pessoa não
+foi posta em nenhuma* (aí ela não pode ver nada). Medido: atendente fora das duas agendas da conta
+enxergava todos os compromissos.
+
+## 6.1. Toda conta tem a agenda "Principal" (21/09)
+
+Antes, a agenda de uma conta era **implícita**: não havia linha no banco e todo compromisso nascia com
+`agenda_id` NULO. A aba Agendas abria dizendo "Nenhuma agenda ainda" numa conta que **tinha** agenda —
+e não havia onde escolher quem a enxerga.
+
+Hoje `Agenda.garantir_padrao!` (chamada no `index`) materializa essa agenda como **Principal**, marcada
+`is_default`, com o fuso da conta. Vale para **toda conta, com ou sem o recurso de múltiplas agendas**:
+quem tem uma agenda só pode editá-la e escolher equipes/pessoas — só não pode **criar outra**, o que
+continua barrado por `Agendas::Quota` (motivo `feature_off`, que é avaliado ANTES do número).
+
+**NEVER CHANGE / GOTCHAS**
+- A condição é "não existe agenda **PADRÃO**", nunca "não existe agenda": enquanto o defeito do
+  `is_default` esteve no ar, quem criou agenda ficou **sem padrão** e com os compromissos antigos
+  invisíveis. Perguntar só por "existe agenda?" deixaria essas contas quebradas para sempre.
+- **Não promover** uma agenda existente a padrão: ela é um LUGAR que o cliente nomeou (uma filial), e
+  herdar os compromissos da agenda de antes jogaria o histórico inteiro dentro da filial errada.
+- A Principal nasce **sem membros** — lista vazia é visível a todos, então ninguém perde acesso no
+  deploy.
+- Criar agenda: a pergunta "é a primeira?" tem que ir ao **banco** (`exists?`) e **antes** do `.new`.
+  `conta.agendas.new(...)` ACRESCENTA o registro não salvo à coleção em memória, então o `.empty?`
+  que existia ali respondia sempre `false` e `is_default` **nunca** era marcado.
+
 ---
 
 ## 7. Programa de sessões (15/09)

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

@@ -73,7 +73,61 @@ Praticamente nunca — exceto se você está testando legacy/curl e quer ser exp
 }
 ```
 
-Strings simples (`"win_reasons": ["motivo"]`) causam erro de serialização.
+Regras (conferidas no servidor desde 21/09):
+
+- O `id` é **texto estável** (`"wr-1"`, `"perda-preco"`) — **nunca número**. Número é convertido para texto
+  (`7` vira `"7"`), mas o certo é já mandar texto. Motivo cadastrado com `id` numérico derrubava o relatório do
+  funil (conta 137, 21/09).
+- Como a lista **substitui** a atual, **reenvie os mesmos `id`** dos motivos que já existem. Trocar o `id` de um
+  motivo faz os cards já marcados com ele perderem o nome no relatório.
+- Recusado com **422** (mensagem diz o formato): lista de textos soltos (`["motivo"]` — antes APAGAVA os motivos da
+  conta em silêncio), motivo sem `id`, motivo sem `title`, `id` repetido. O servidor **não inventa** `id`.
+- Lista vazia (`[]`) limpa os motivos.
+
+**Marcar o card com o motivo** (`PATCH /kanban_items/{id}`, `item_details` mescla no 1º nível):
+
+```json
+{ "item_details": { "status": "lost", "loss_reason": "perda-preco", "reason": "Preço alto" } }
+```
+
+`loss_reason`/`win_reason` = o `id` (texto) de um motivo cadastrado; `reason` = o título. Motivo livre (fora da
+lista): `loss_reason` nulo e o texto em `reason`.
+
+### Outras listas de OBJETOS — formato conferido no servidor (desde 21/09)
+
+Estes campos são **listas de objetos**. Mandar lista de textos/números soltos, lista misturada (alguns objetos e
+alguns textos) ou um objeto solto no lugar da lista é recusado com **422**, e a mensagem mostra o formato certo.
+Antes o servidor aceitava, gravava **lista vazia** e respondia 200 — ou seja, apagava a configuração do cliente.
+
+| Ferramenta | Campo | Formato |
+|---|---|---|
+| `custom_dashboards_create/update` | `widgets` | `[{"widget_type": "conversations_timeseries", "metric": "conversations", ...}]`; dentro de cada bloco, `columns` também é lista de objetos |
+| `kanban_config_update` | `global_custom_attributes` | `[{"name": "Origem", "type": "text"}]` (`list_values` é lista de textos) |
+| `kanban_config_update` | `checklist_templates` | `[{"name": "Onboarding", "items": [{"text": "Ligar"}]}]` — `items` é lista de objetos |
+| `funnels_create/update` | `global_custom_attributes` | igual ao do Kanban |
+| `booking_event_types_create/update` | `confirmation_blocks` e `follow_up_schedules_attributes[].blocks` | `[{"type": "text", "content": "Olá"}]` |
+| `inboxes_update` | `csat_config.survey_rules` | **objeto** `{"operator": "contains", "values": ["vip"]}` — `values` é lista de textos |
+
+Continua valendo: a lista **substitui** a anterior (leia com GET e reenvie inteira) e `[]` limpa.
+Recebeu 422 de formato? **Não repita a mesma chamada**: leia a mensagem, corrija o formato e mande de novo.
+
+### Recusa por PERMISSÃO (401) — o que mudou em 21/09
+
+O servidor responde **401** (não 403) quando o usuário do token não tem a permissão. Não retente; explique ao usuário.
+
+- **Fluxos** (`flows_create/update/destroy/toggle`, duplicar, fixar teste, testar nó): só **administrador** ou cargo com
+  **Gerenciar FlowBuilder**. `flows_list` e `flows_show` seguem abertos. "Gerenciar Regras de Automação" **não** libera fluxo.
+- **Respostas de formulário** (`lead_forms_responses_list/show`, `lead_forms_stats`, `lead_forms_test_run`): administrador ou
+  **Gerenciar Formulários**. As respostas de UM contato continuam em `contacts_form_entries_list`.
+- **Mesclar contatos** (`contacts_create_4` — "Mesclar Contatos", `POST actions/contact_merge`): administrador ou **Gerenciar contatos**
+  (mesclar apaga uma das fichas).
+- **Configuração do Kanban** (`kanban_config_update`): motivos de ganho/perda = qualquer usuário; campos do card, checklists e
+  `config` = administrador ou **Gerenciar Funis**; webhook e liga/desliga = só administrador. A recusa lista as chaves barradas.
+- **Card do Kanban**: `kanban_items_show/update` e os arquivos do card devolvem **404** para card que o usuário não enxerga no
+  quadro. Cargo sem opção de Kanban só edita o card dele ou o sem responsável.
+- **Tipo de agendamento** (`booking_event_types_update/destroy`): só o dono do link ou administrador.
+- **Relatório do Kanban** (`kanban_items` reports): traz `metrics.visibilityScope` — `partial` significa "só os cards que ESTE
+  usuário vê". Diga isso ao usuário antes de apresentar o número como total da conta.
 
 ## Restrições de formato em campos comuns
 
@@ -282,7 +336,7 @@ Vale pra automações, filtro avançado de conversas/contatos e busca "+ Filtro"
 | Código | Significado | O que fazer |
 |---|---|---|
 | `400` Bad Request | Parâmetros mal formados | Confira sintaxe |
-| `401` Unauthorized | Token inválido ou expirado | Reporte ao usuário (não retente) |
+| `401` Unauthorized | Token inválido/expirado **ou usuário sem a permissão** (o LionChat recusa permissão com 401, não 403) | Reporte ao usuário (não retente) |
 | `403` Forbidden | Sem permissão (papel insuficiente) | Reporte (não retente) |
 | `404` Not Found | Recurso não existe (ou de outra conta) | Confira ID |
 | `422` Unprocessable Entity | Validação falhou | Leia mensagem, corrija |

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

@@ -172,10 +172,13 @@ valores desta lista:
 | Econômicos / rápidos | `gpt-4.1-nano`, `gpt-4o-mini`, `gpt-4.1-mini`, `gpt-5.4-nano`, `gpt-5.4-mini` |
 | Intermediários | `gpt-4o`, `gpt-4.1`, `gpt-5-mini`, `gpt-5.4` |
 | Raciocínio | `o3-mini`, `o4-mini` |
-| Premium | `gpt-5`, `gpt-5.2`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`, `o1`, `o3` |
+| Premium | `gpt-5`, `gpt-5.2`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`, `gpt-6-sol`, `o1`, `o3` |
+| Custo-benefício (nova geração) | `gpt-6-luna` — US$ 0,10/0,50 por 1M tokens, raciocínio, sem temperatura; liberado em 23/09/2026 |
 
 **`GPT-5.2 Pro` não existe.** O valor válido é `gpt-5.2`, sem "Pro".
 
+> **Família `gpt-6` (`gpt-6-luna`, `gpt-6-sol`) — LIBERADA em 23/09/2026**, pelo mesmo trilho do `gpt-5.6`: sem temperatura e fora do bloco de IA do Formulário de Lead. `gpt-6-astra` NÃO está disponível.
+>
 > **Família `gpt-5.6` (`gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`) — LIBERADA em 09/2026.**
 > Foi removida em 29/07/2026 porque recusa function tools no canal antigo da OpenAI e deixava a IA MUDA.
 > Desde 09/2026 o servidor fala com esses três pela porta `/v1/responses` (só para eles — nenhum outro
@@ -190,6 +193,47 @@ valores desta lista:
 > Desde 29/07 o erro vira uma **nota privada em português** na conversa (`llm_request_rejected`) — é o
 > primeiro lugar a olhar quando "a IA parou de responder logo depois de mexerem nas configurações".
 
+## Ligação por IA — Agentes de ligação (2026-09-24)
+
+A ligação por voz **saiu do agente de texto**. Desde 24/09 ela mora em **Agentes de ligação**, uma área
+própria: cada agente de ligação tem um objetivo e **não ocupa vaga de IA do plano**. As chaves antigas
+`config.call_*` do `captain_assistants_update` **não existem mais** — mandar elas não tem efeito.
+
+| Ferramenta | Para quê |
+|---|---|
+| `captain_call_agents_list` | lista os agentes de ligação e `meta.dial_inboxes` (caixas que podem ligar) |
+| `captain_call_agents_create` / `_update` / `_duplicate` / `_destroy` | cadastro |
+| `captain_call_test_phones_list` / `_create` / `_destroy` | números autorizados a receber ligação de teste |
+| `captain_call_agents_test_call` | **liga de verdade** para um número de teste cadastrado |
+| `captain_call_agents_test_call_status` | tocando / atendeu / não atendeu, e em qual conversa ficou |
+
+Campos do agente de ligação: `name`, `objective` (roteiro, até 4000), `first_message` (até 400), `style`
+(jeito de falar, até 1200), `voice_provider` (`openai` padrão ou `elevenlabs`), `engine` (`gptlive` padrão
+ou `realtime`, só na OpenAI), `voice_id`, `elevenlabs_agent_id` (obrigatório na ElevenLabs),
+`max_duration_seconds` (30 a 600, padrão 180) e **`captain_assistant_id`**.
+
+**Como a ligação trabalha (GPT-Live).** A voz conversa e **só consulta** agenda (horários livres, agenda do
+atendente, quem está trabalhando). Quando o cliente pede algo que precisa ser FEITO — mandar link,
+endereço ou proposta pelo WhatsApp, mover o card, anotar — a voz **repassa** ao agente de texto de
+`captain_assistant_id`, diz "já pedi, vai chegar no seu WhatsApp" e **segue a conversa** (nunca diz "já
+mandei"). O agente de texto executa na conversa daquele contato, com as ferramentas e a configuração
+DELE, e decide se escreve ao cliente. Regras fixas desse pedido: roda mesmo com atendente humano na
+conversa ou com a IA pausada; não liga a IA na conversa nem mexe na IA que já estava lá; não passa para
+humano, não encerra, não transfere e não agenda retorno (fluxos rodam completos); no máximo 3 pedidos
+por ligação; caixa oficial fora da janela de 24h faz as ações mas não escreve.
+Sem `captain_assistant_id` (ou no motor `realtime`/ElevenLabs), a voz **só conversa**.
+
+**Voz.** É **própria** do agente de ligação — não mexe na voz do áudio da IA no WhatsApp
+(`config.voice_provider`/`config.voice_id` do agente de texto continuam sendo só do WhatsApp). No GPT-Live
+use `captain_voices_list` com `engine=gptlive`: aceita alloy, ash, ballad, coral, echo, sage, shimmer, verse,
+**marin** e **cedar** (as duas mais naturais de telefone); voz fora disso cai na marin.
+
+**Ligação de teste.** Só para número **cadastrado** em `captain_call_test_phones` (o telefone nunca vai no
+corpo, só o id). Cria contato e conversa de verdade, pode disparar automações de "conversa criada" e fica
+gravada. Limite de 10 por hora na conta. Precisa da Ligação com IA liberada na conta e da linha da caixa
+conectada; recusa volta 422 com o motivo em `message`. Depois que a ligação termina, a transcrição do
+próprio fornecedor aparece no card da ligação.
+
 ## Follow-up automático multi-etapa (2026-06)
 
 O follow-up do AI Agente agora suporta **cadência de até 3 etapas** via `config.follow_up_steps`:
@@ -463,7 +507,13 @@ puxados. Se a ativação reclamar de sample, NÃO é bloqueio — a integração
 - `ContactLabel` `{id}` — etiqueta de CONTATO (novo)
 - `ContactAttribute` `{key, value}` — atributo do contato (novo)
 - `CardAttribute` `{key, value}` — atributo do card Kanban (novo)
-- `AgentTeam` `{assignee_ids:[], team_ids:[]}` — responsável atual OU time da conversa (novo)
+- `AgentTeam` `{assignee_ids:[], team_ids:[], assignee_mode?, team_mode?}` — responsável atual OU time da
+  conversa. **Modos (24/09/2026):** `assignee_mode:'none'` = conversa SEM responsável ("Sem atendente"),
+  `'any'` = com qualquer responsável; `team_mode:'none'|'any'` igual para time. Ausente/`'specific'` = usa os
+  ids (comportamento de sempre). Vale QUALQUER conversa do contato, de qualquer status. Atendente e time
+  SEMPRE somam (um OU outro) — inclusive em blocos `AgentTeam` separados, que viram UMA seção só; o
+  `audience_mode:'all'` cruza o AgentTeam com as OUTRAS seções (etiqueta, funil, atributo), não atendente com
+  time. "Sem atendente E com time" não é montável hoje. Mesmos modos na `exclusion`.
 
 O campo `audience_mode` define a combinação ENTRE seções:
 - `"sum"` (default): união — contato em QUALQUER seção entra
@@ -932,3 +982,22 @@ Em `custom_roles_create` / `custom_roles_update`, a `description` é **uma frase
 na descrição** — a tela já as mostra na coluna "Permissões". Uma descrição de 180 caracteres
 escondeu o cargo recém-criado na lista de Funções personalizadas da conta 1 (a tela foi corrigida
 para cortar o texto com reticências, mas a descrição longa continua ilegível ali).
+
+## Entrar num grupo por convite (17/09/2026)
+
+Só em caixa de WhatsApp QR Code (`Channel::Waha`). São DUAS tools e a ordem importa.
+
+1. `lionchat_inboxes_waha_groups_list_3` (join_info) — SÓ LEITURA: diz qual é o grupo (`Name`,
+   `ParticipantCount`, `IsJoinApprovalRequired`). **Chame sempre primeiro** e confirme com a pessoa
+   em qual grupo ela vai entrar. Entrar é ação que muda o WhatsApp do cliente.
+2. `lionchat_inboxes_waha_groups_create_6` (join) — entra, como participante comum.
+
+As duas aceitam o código cru, o link inteiro (`https://chat.whatsapp.com/CODIGO`) ou um texto com o
+link no meio — não precisa extrair o código antes.
+
+**Recusa esperada:** 422 com `reason: groups_disabled` quando a caixa está com "Aceitar grupos"
+desligado. Não insista nem tente contornar: sem essa chave o WhatsApp nem entrega as mensagens do
+grupo, então o número entraria num grupo que nunca apareceria no painel. O caminho é o cliente ligar
+a opção nas configurações da caixa e tentar de novo.
+
+A resposta do join_info vem no formato cru do motor, em PascalCase (`Name`, não `name`).

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

@@ -215,7 +215,8 @@ Funnel
 ├── name
 ├── stages (jsonb: hash com slug_etapa => { name, color, position, description, checklist_templates })
 ├── settings (jsonb: { agents: [], goals: [], automations: [{trigger_type, action, action_config, enabled}] })
-├── global_custom_attributes (jsonb array)
+├── global_custom_attributes (jsonb array — NENHUMA tela lê este campo do funil; os campos da aba do card
+│     são os do KanbanConfig acima)
 ├── meta_events_config (jsonb: won/lost/stages → Meta Pixel/CAPI events; cada bloco: enabled, name,
 │     is_standard, value_strategy, value_fixed, currency, messaging_name — este último é o evento de
 │     ANÚNCIO DE WHATSAPP, tri-estado: ausente = automático, '' = não enviar, um dos 14 nomes da Meta;
@@ -241,9 +242,10 @@ KanbanItem
 ├── stage_entered_at (datetime)
 ├── position (int, ordem dentro da etapa)
 ├── conversation_display_id (FK opcional → Conversation.display_id)
-├── item_details (jsonb)
-├── custom_attributes (jsonb)
-├── assigned_agents (jsonb array)
+├── item_details (jsonb — os campos da aba Campos ficam em item_details.custom_attributes, LISTA de
+│     {name, type, value}; nunca objeto {chave: valor})
+├── custom_attributes (jsonb — coluna que NENHUMA tela mostra; nao confundir com a lista acima)
+├── assigned_agents (jsonb array — para gravar: lista de NUMEROS [5, 12])
 ├── linked_conversations (jsonb array de { display_id })
 ├── checklist (jsonb array de itens — NAO e tabela separada; ver abaixo)
 ├── activities (jsonb)
@@ -408,9 +410,16 @@ AccountTask (agenda interna)
 │   (painel|link|ia|sistema|fluxo) — QUEM agendou e por onde (14/09)
 ├── attendance (enum attended=0 / no_show=1, NULO = nada registrado — CARIMBO, não muda status)
 │   / attendance_by (polimórfico) / attendance_source — quem marcou Compareceu/Faltou (14/09)
+├── selo (SÓ LEITURA, calculado — 17/09): o rótulo ÚNICO que a tela mostra ao lado da tarefa, juntando
+│   `status` + `attendance` + remarcação: cancelled > no_show / attended > completed > snoozed >
+│   rescheduled > pending. `rescheduled` = data trocada pelo painel/fluxo/IA (`reschedule_source`) OU pelo
+│   cliente no link do agendamento. Para dizer "o que aconteceu com este compromisso", LEIA `selo` —
+│   `status: pending` sozinho NÃO significa "nada aconteceu" (a pessoa pode ter faltado)
 ├── agenda_treatment_id (FK → AgendaTreatment, nullify) / treatment_session_number (1..N) — a sessão
 │   que este compromisso é; índice único parcial por tratamento+número entre os NÃO cancelados (15/09)
-└── assignees (has_many → User, via account_task_assignments)
+└── assignees (has_many → User, via account_task_assignments). Compromisso NASCIDO DE BOOKING
+    (`booking_id` presente) tem responsável FIXO = o agente configurado no tipo de evento:
+    `assignee_ids` enviado no update é IGNORADO (200, o resto da edição vale — 17/09)
 
 AgendaTreatment (tratamento em sessões — tools `agenda_treatments_*`; tabela agenda_treatments; 15/09)
 ├── id (PK) / account_id (FK) / contact_id (FK) / booking_event_type_id (FK, nullify)
@@ -485,7 +494,7 @@ daquele tipo no calendário; vazio = cor do agente. A tarefa devolve `booking_co
 
 ## e-Clínicas (Efficient) — integração de clínicas
 
-17 eventos de webhook, cada um mapeável a automação OU flow na tela Integrações > e-Clínica
+19 eventos de webhook, cada um mapeável a automação OU flow na tela Integrações > e-Clínica
 (o mapeamento e os lembretes passaram a ser editáveis por MCP em 31/08/2026, com
 `lionchat_eclinica_integrations_update` — ele **SUBSTITUI** o objeto inteiro, então leia com
 `_show` e devolva completo, senão apaga o resto):
@@ -495,7 +504,10 @@ daquele tipo no calendário; vazio = cor do agente. A tarefa devolve `booking_co
 `cliente_inclusao_pagamento`, `controle_laboratorio_novo`, `controle_laboratorio_alterado`,
 `agendamento_aguardando`, `odontograma_aprovado`, `procedimento_finalizado`,
 `cliente_alteracao_pagamento`, `odontograma_finalizado`, `inclusao_procedimento`
-(capturados ao vivo, não documentados pelo e-Clínica).
+(capturados ao vivo, não documentados pelo e-Clínica) +
+`agendamento_confirmado_link` e `agendamento_cancelado_link` (18/09/2026 — o PACIENTE confirmando/
+cancelando pelo link do portal, ecli.co; confirmado processa como `agendamento_alterado`, mantendo o
+lembrete; cancelado processa EXATAMENTE como `agendamento_desmarcado`, cancelando o lembrete).
 
 O recurso `eclinica_integration` da conta passou a ser ligado e desligado pelo PRÓPRIO cadastro da
 integração (10/09/2026, `auto_managed`): sumiu do Super Admin e não há passo manual — os blocos de
@@ -606,6 +618,21 @@ da consulta) — em vez de herdar sempre o horário da consulta. Há ainda um fi
 ("Só quando") por atributo `eclinica_*` do contato. Nada disso é editável pelo MCP: só pelo painel.
 Pra auditar o que foi/será disparado, use `lionchat_eclinica_reminder_history_list`.
 
+**Um aviso por CONSULTA (desde 2026-09-17).** A regra antiga "um lembrete por dia" saiu: paciente com duas
+consultas no mesmo dia — ou duas pessoas no mesmo celular (mãe e filho) — recebe um lembrete para CADA
+consulta, cada um com o seu nome, horário, profissional e link. Eles não saem juntos: sai o da consulta
+mais cedo e, ~10 minutos depois (na rodada seguinte), o da próxima. No histórico
+(`lionchat_eclinica_reminder_history_list`) isso aparece assim: o que espera a vez fica `pending` com
+`fire_at` no passado por alguns minutos (normal); `skip_reason = outra_consulta_no_mesmo_dia` só existe em
+linhas ANTIGAS (até 17/09); e `fail_reason = fluxo_ainda_em_andamento_com_este_contato` significa que o
+fluxo do aviso anterior ainda estava em andamento com aquele contato (típico de fluxo que aguarda o
+paciente clicar num botão) — pode ser reenviado com `lionchat_eclinica_reminder_history_reprocess`.
+O fluxo do lembrete recebe também `{{cliente_id}}` (código do paciente DAQUELA consulta na e-Clínica) e
+`{{agendatipo}}`; na automação, `{{agendamento.cliente_id}}` e `{{agendamento.agendatipo}}`. Ao consultar a
+agenda do paciente dentro do fluxo, use `{{cliente_id}}` do lembrete — a ficha do contato é uma por
+TELEFONE e guarda só o último paciente. Quem quiser "só um lembrete por dia" monta no próprio fluxo
+(condição num atributo da conversa com `{{data_consulta}}` + ação que grava o dia depois de enviar).
+
 ## Relatórios e Métricas
 
 ```

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

@@ -36,6 +36,14 @@ E/OU é encadeado condição a condição (sem parênteses).
 Atributo personalizado: informe `custom_attribute_type` na condição — `'conversation_attribute'`
 (atributo da conversa) ou `'contact_attribute'`. Sem ele o escopo pode sair errado.
 
+**`contact_attribute` lê a FICHA DO CONTATO da conversa (funciona de verdade desde 24/09/2026).** Antes o
+servidor ignorava o valor e lia o atributo da própria conversa — por isso lead de formulário da Meta
+(formulário, anúncio, campanha e 1ª/última origem ficam SÓ no contato) não era achado. Agora a conversa entra
+quando o contato dela casa. Chave precisa ter cadastro de atributo DE CONTATO na conta (senão 422). Exemplo:
+`{attribute_key:'meta_lead_form_name', custom_attribute_type:'contact_attribute', filter_operator:'contains',
+values:['vendas']}`. Negativos (`not_equal_to`, `does_not_contain`, `is_not_present`) incluem a conversa cujo
+contato não tem o dado. Texto compara sem maiúscula/acento.
+
 - `chat_type` em `conversations_filter` funciona desde 19/08/2026 (antes respondia 500). `group` =
   conversa de grupo de WhatsApp; `individual` cobre também canal, transmissão e status. Com
   `not_equal_to`, conversa sem contato vinculado NÃO some do resultado.
@@ -162,6 +170,13 @@ Params: `funnel_id` (obrigatório), `from`, `to`, `user_ids[]` (agentes), `team_
 | `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" |
 
+**Ganho/perda pela DATA DO FECHAMENTO (23/09/2026).** Com a régua `any` o relatório traz também cards que
+nasceram no período mas fecharam DEPOIS dele. Por isso, para "quanto ganhamos/perdemos em julho", leia
+`wonInPeriod`/`wonValueInPeriod` e `lostInPeriod`/`lostValueInPeriod` (este último é campo NOVO) — **nunca**
+`statusDistribution`, que é a foto do status de HOJE (serve só para "negócios abertos agora"). Desde 23/09 os
+motivos de ganho/perda, os perdidos recentes, a receita por semana e o ranking de vendedores também contam só
+o que FECHOU no período — antes somavam por status de hoje e divergiam do quadro de Ganhos na mesma tela.
+
 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

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

@@ -140,6 +140,7 @@ Webhooks embutidos NÃO aparecem na listagem de integrações standalone; exclui
 **Gatilhos de AGENDAMENTO — Booking NATIVO do LionChat (2026-08-20):** `booking_created` (alguém marcou pelo link público, pela IA ou pelo painel), `booking_cancelled` (paciente cancelou pelo link, IA cancelou ou a equipe cancelou na Agenda), `booking_rescheduled` (a data/hora mudou — link do paciente, IA, editar/adiar na Agenda), `booking_completed` (equipe concluiu na Agenda; exige a Agenda unificada ligada na conta). **Não é e-Clínica.** Config (tudo opcional, vazio = todos): `booking_event_type_ids` (array de ids de tipo de agendamento, **STRING**), `agent_ids` (array de ids de usuário — o RESPONSÁVEL da tarefa), `create_conversation` (boolean, padrão `false`: só dispara para quem já tem conversa numa caixa do flow; `true` = cria a conversa na 1ª caixa do flow). Exemplo: `{ "key": "booking_created", "config": { "booking_event_type_ids": ["44"], "agent_ids": [], "create_conversation": true } }`. São INERTES a evento de conversa (quem dispara é o `Booking::FlowTriggerDispatcher`, por CONTA — caixa do flow só define onde a conversa é criada/reusada). Variáveis no flow: `{{booking.date}}` (DD/MM/AAAA), `{{booking.time}}`, `{{booking.weekday}}`, `{{booking.datetime}}` (ISO), `{{booking.type}}`, `{{booking.type_format}}` (presencial/videochamada), `{{booking.duration}}`, `{{booking.agent}}`, `{{booking.status}}` (confirmado/cancelado/remarcado/concluído), `{{booking.description}}`, `{{booking.cancel_url}}`, `{{booking.reschedule_url}}`, `{{booking.color}}`, `{{booking.id}}`; só no remarcado: `{{booking.previous_date}}`, `{{booking.previous_time}}`, `{{booking.previous_datetime}}`; `{{booking.meeting_url}}` NÃO vem no criado (nasce vazio). Data/hora vêm da TAREFA da Agenda (sempre atuais). Regras: o evento mais novo SUBSTITUI a rodada ativa do mesmo flow na mesma conversa (2ª consulta do mesmo paciente, ou cancelado chegando com o criado ainda esperando resposta); excluir a tarefa, reabrir cancelada ou desfazer conclusão NÃO disparam; adiar (snooze) conta como remarcado; tipo com confirmação/lembrete próprios ligados + `booking_created` = o paciente pode receber duas mensagens (a tela avisa). Colisão entre flows é por CONTA: mesmo kind + tipos se cruzando + agentes se cruzando (vazio = todos). Há também `{{booking.event}}` (`created`|`cancelled`|`rescheduled`|`completed` — bom pra condição; não aparece no seletor da tela, mas resolve); `{{trigger.type}}` = a chave do gatilho (ex.: `booking_created`), `{{trigger.kind}}` = `created`|`cancelled`|`rescheduled`|`completed` e `{{trigger.booking_id}}`. SÓ flow de conversa **individual** (a tela nem oferece em flow de grupo); **nunca dispara flow `ai_tool`**. Em caixa WhatsApp OFICIAL, conversa criada nova (ou parada há mais de 24h) está FORA da janela — texto livre no 1º bloco cai em `window_closed`/erro; comece por template.
 
 **TRAVA DE GATILHO DUPLICADO (2026-06-16) — leia ANTES de ativar/criar flow ativo:** o sistema BLOQUEIA ter dois flows ATIVOS com o MESMO gatilho na MESMA inbox e mesmo `conversation_mode` (evita o evento disparar dois flows). Colisão = mesmo tipo de gatilho + config cruzando (mesmas keywords/funil/labels/url/etc) + inbox compartilhada + mesmo modo. EXCEÇÕES que podem coexistir: `webhook_received`, `manual_trigger` e `campaign_trigger` (este último porque não dispara por evento — é só uma autorização para a campanha).
+- **`date_trigger` separa por HORÁRIO (24/09/2026):** dois flows no mesmo campo de data, mesma direção e mesmos dias NÃO colidem se os dois tiverem horário FIXO diferente (ex.: "1 dia depois às 08:00" e "às 14:00"). Horário vindo de atributo/fórmula continua colidindo (só existe na hora do disparo); `send_time` vazio conta como 09:00 e "8:00" = "08:00". A entrega é de 10 em 10 minutos — horários a menos de 10 min podem sair juntos.
 - Ao **ativar** (`flows_toggle` inativo→ativo) ou **criar já ativo**: qualquer conflito é barrado.
 - Ao **editar** um flow já ativo: só conflito NOVO é barrado (duplicados que já existiam são preservados).
 - A API responde **422** com `{ "error_code": "flow_trigger_conflict", "conflicts": [{ flow_id, flow_name, trigger_type, inbox_id, inbox_name }] }`.
@@ -288,7 +289,7 @@ No editor visual esses destinos só aparecem quando a validação bate (computed
 - `validation: 'options'` → `option_<valor>` para cada valor em `acceptedOptions` (ex: `option_1`, `option_2`, `option_sim`) + `timeout` + `retries_exhausted`
 - `validation: 'varied_options'` → `option_<group_id>` para cada grupo em `optionGroups` (ex: `option_sim`, `option_nao`) + `timeout` + `retries_exhausted`
 
-**`timeout` vs `retries_exhausted` (DISTINTOS):** `timeout` = cliente ficou em silencio (estourou `waitTime`). `retries_exhausted` = cliente respondeu, mas errou a validacao mais que `maxRetries` vezes. Ligue cada um ao caminho desejado. Se `retries_exhausted` nao tiver edge, ha fallback p/ o edge de `timeout`; sem nenhum dos dois, o flow encerra ao esgotar as tentativas.
+**`timeout` vs `retries_exhausted` (DISTINTOS):** `timeout` = cliente ficou em silencio (estourou `waitTime`). `retries_exhausted` = cliente respondeu, mas errou a validacao mais que `maxRetries` vezes (`maxRetries` = quantas vezes a `invalidMessage` e enviada; a resposta errada seguinte esgota — com `maxRetries: 1` o cliente recebe o erro uma vez e sai no 2o erro). Ligue cada um ao caminho desejado. Se `retries_exhausted` nao tiver edge, ha fallback p/ o edge de `timeout`; sem nenhum dos dois, o flow encerra ao esgotar as tentativas.
 
 **Timeout dispara de verdade — e SEM fio ENCERRA (desde 20/08/2026):** `waitTime` + `waitUnit`
 agendam o estouro. Com fio no handle `timeout`, o flow segue por ele. **Sem fio, a sessão é
@@ -385,6 +386,25 @@ só pra destravar, ela pode sair.
 | `pagetrack_visited` / `pagetrack_event` | LionTrack |
 | `sla_check` | status do SLA da conversa (usa `value` = código fixo; ver abaixo) |
 
+**CAIXA DA CONVERSA e TIPO DE CAIXA (novo 17/09/2026):** duas condições da aba Conversas que perguntam
+ONDE a conversa está. Nasceram para o **Fluxo de Ações** (que roda em qualquer caixa), mas valem em
+qualquer tipo de flow. Não têm operador novo: só `equal` e `not_equal`, e o valor vai numa **LISTA**
+(`values`) — com lista, `equal` significa "é ALGUMA destas" e `not_equal` "não é NENHUMA destas".
+
+- **Caixa da conversa:** `{ "id": 1, "field": "{{inbox.id}}", "operator": "equal", "value": "", "values": ["342", "204"], "valueType": "inbox" }`
+  — cada item de `values` é o **id da caixa como STRING**.
+- **Tipo de caixa:** `{ "id": 1, "field": "{{inbox.channel_type}}", "operator": "equal", "value": "", "values": ["Channel::Waha"], "valueType": "channel_type" }`
+  — cada item é o **nome técnico do canal**: `Channel::Waha` (WhatsApp QR Code), `Channel::Whatsapp`
+  (WhatsApp API Oficial), `Channel::WebWidget`, `Channel::Api`, `Channel::Email`,
+  `Channel::FacebookPage` (Facebook/Instagram), `Channel::TwilioSms`, `Channel::Sms`,
+  `Channel::Telegram`, `Channel::Line`.
+
+O `valueType` é OBRIGATÓRIO nas duas: é ele que faz a tela abrir o seletor certo (lista de caixas /
+lista de tipos). Sem ele a regra roda no motor e a tela não desenha campo nenhum para ela. Gravar o
+valor em `value` em vez de `values` é a mesma família do defeito de 02/09 descrito abaixo: o motor
+compara certo e a tela abre o seletor VAZIO. `{{inbox.name}}` existe como variável mas **não** é
+condição: comparar por nome quebra quando o cliente renomeia a caixa.
+
 > **ATENÇÃO — onde o VALOR vai (defeito real de 02/09/2026, conta 137):** no nó **Condição**, uma regra de atributo
 > (`valueType: "attr_config"`) com operador `equal`, `not_equal`, `contains` ou `not_contains` guarda o valor em
 > **`values: ["..."]` (lista)** e deixa `value: ""`. A TELA lê SÓ a lista: regra gravada com `value: "paid_ad"` e
@@ -686,7 +706,9 @@ Exemplo: `{"aiMode":"sentiment","aiAssistantId":"12","aiModel":"gpt-4.1-mini","a
 curinga** — não existe "a família gpt-5 inteira":
 `gpt-4o-mini`, `gpt-4o`, `gpt-4.1-nano`, `gpt-4.1-mini`, `gpt-4.1`, `gpt-5-mini`, `gpt-5`,
 `gpt-5.2`, `gpt-5.4-nano`, `gpt-5.4-mini`, `gpt-5.4`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-terra`,
-`gpt-5.6-sol`, `o1`, `o3`, `o3-mini`, `o4-mini`.
+`gpt-5.6-sol`, `gpt-6-luna`, `gpt-6-sol`, `o1`, `o3`, `o3-mini`, `o4-mini`.
+A família **`gpt-6` (luna/sol) entrou em 23/09/2026** pelo mesmo trilho do `gpt-5.6` (porta `/v1/responses`,
+sem temperatura, fora do Formulário de Lead).
 A família **`gpt-5.6` (luna/terra/sol) voltou em 09/2026** (tinha sido removida em 2026-07-29 porque
 recusa function tools no canal antigo): o servidor fala com esses três pela porta `/v1/responses`.
 Eles ignoram a temperatura do bloco (só o padrão) e **NÃO valem no bloco de IA do Formulário de Lead**
@@ -1025,17 +1047,43 @@ de conexão e viram bola de neve visual. Ao gerar `position`:
 
 ---
 
-## 2-B. Dois tipos de flow: `conversation` vs `ai_tool`
+## 2-B. Três tipos de flow: `conversation`, `ai_tool` e `action`
 
 O campo `flow_type` (definido na criação, IMUTÁVEL depois) decide a natureza do flow:
 
-| | `conversation` (default) | `ai_tool` |
-|---|---|---|
-| Como dispara | Por evento de inbox (trigger no node `start`) | Invocado pelo AI Agente (Captain) como ferramenta |
-| Inboxes | usa `inbox_ids` | **PROIBIDO** ter inboxes (validação barra) |
-| Campos extra | — | `tool_name` (snake_case, `[a-z][a-z0-9_]`, max 50) + `tool_description` (max 500) OBRIGATÓRIOS |
-| Retorno | manda mensagens | retorna dado estruturado ao LLM via node `end` |
-| Nodes permitidos | todos | `start`, `end`, `api`, `condition`, `set_variable`, `ai`, `note`, `randomizer`, `action`, `send_message` |
+| | `conversation` (default) | `ai_tool` | `action` (17/09/2026) |
+|---|---|---|---|
+| Como dispara | Por evento de inbox (trigger no node `start`) | Invocado pelo AI Agente (Captain) como ferramenta | Pelo MESMO trigger do `conversation`, mas em QUALQUER inbox |
+| Inboxes | usa `inbox_ids` | **PROIBIDO** ter inboxes (validação barra) | **PROIBIDO** ter inboxes (roda em todas) |
+| Campos extra | — | `tool_name` (snake_case, `[a-z][a-z0-9_]`, max 50) + `tool_description` (max 500) OBRIGATÓRIOS | — |
+| Retorno | manda mensagens | retorna dado estruturado ao LLM via node `end` | **não manda mensagem nenhuma** |
+| Nodes permitidos | todos | `start`, `end`, `api`, `condition`, `set_variable`, `ai`, `note`, `randomizer`, `action`, `send_message` | todos MENOS `send_message`, `wait_response`, `update_group` e `end` |
+
+**`action` (na tela: "Fluxo de Ações")** é para regra que vale na empresa inteira e não depende da
+caixa: "conversa que receber a etiqueta urgente vai pra equipe de suporte", "card que entrar na
+etapa Fechado grava a data no contato". Antes exigia repetir o mesmo flow em cada inbox.
+
+Criar: `flows_create` com `flow_type: 'action'`, SEM `inbox_ids` e SEM `conversation_mode`
+(o backend fixa `individual`; mandar `group` é ignorado). Aceita os MESMOS gatilhos do
+`conversation` no node `start` e usa o mesmo `flow_data`. Roda LADO A LADO com os flows de mensagem
+(não entra no aviso de conflito de gatilho) e vale também em conversa de grupo.
+
+**NUNCA** pôr `send_message` / `wait_response` / `update_group` num flow `action` — a validação
+recusa o save inteiro com `contains node types not allowed in action flow`. Se o cliente precisa
+falar com a pessoa, o flow é `conversation`.
+
+Três regras que andam com o tipo `action` (17/09/2026):
+- **`start_flow` (bloco Ações > Sistema)**: o flow de ações pode ser alvo a partir de QUALQUER flow,
+  sem casar caixa. Já um flow `conversation` alvo que NÃO atenda a caixa da conversa é RECUSADO em
+  runtime (passo com erro `inbox_mismatch` no histórico) — antes rodava no lugar errado em silêncio.
+- **Macro**: a ação `start_flow` da macro (`macros_*`) aceita **só** `flow_type: 'action'`.
+- **Condições**: `{{inbox.id}}` e `{{inbox.channel_type}}` (novo) dão "Caixa da conversa" e "Tipo de
+  caixa" na aba Conversas — como o flow de ações roda em todas as caixas, é assim que ele pergunta
+  onde está antes de agir. `channel_type` grava o valor técnico (`Channel::Waha` etc.).
+- **AINDA NÃO FUNCIONA**: disparar flow `action` por webhook de integração (gateways de pagamento,
+  Webhook Universal, Meta Lead, e-Clínica) ou por gatilho de formulário. Esses caminhos criam a
+  conversa usando a CAIXA do flow, e o flow de ações não tem caixa — ele é selecionado e descartado
+  (`no_inbox_linked` no log). Não prometa isso ao cliente até a decisão de produto.
 | Aviso de espera (10/09/2026) | — | enquanto a ferramenta roda, o cliente recebe "Só um momento, estou verificando isso pra você...". Cada ferramenta escolhe o seu no node `start`: `data.toolWaitMessageEnabled` (`false` desliga; AUSENTE = ligado — só um `false` de verdade desliga, `""` ou lixo mantém ligado) e `data.toolWaitMessageText` (texto próprio, até 1000 caracteres; vazio = frase padrão). Vive no `flow_data` e viaja no snapshot de versão; ferramenta já existente não muda de comportamento |
 
 Se o cliente pediu "uma ferramenta que a IA usa pra consultar X / calcular Y", é `ai_tool`. Se pediu "quando chega mensagem, faça Z", é `conversation`. Na dúvida, `conversation`.
@@ -1055,10 +1103,11 @@ no fim de uma cadeia automação→flow→automação, suspeite desse limite —
 
 Todo flow `conversation` tem um `conversation_mode`: `individual` (default — conversa 1-a-1) ou `group`
 (grupo de WhatsApp). Definido na CRIAÇÃO e **IMUTÁVEL depois** (não dá pra converter um no outro; pra trocar,
-crie outro flow). Não confundir com `flow_type` — um flow `ai_tool` não tem `conversation_mode`.
+crie outro flow). Não confundir com `flow_type` — um flow `ai_tool` não tem `conversation_mode`, e no
+`action` ele é fixado em `individual` (o campo não se aplica: o flow de ações roda nos dois).
 
-Na tela o usuário vê isso como TRÊS opções ao criar: "Mensagem" (= `conversation` + `individual`),
-"Grupo" (= `conversation` + `group`) e "IA Agente" (= `ai_tool`).
+Na tela o usuário escolhe o TIPO (Conversa / IA Agente / Ações) e, só no tipo Conversa, o modo
+(Mensagens individuais / Grupos WhatsApp).
 
 **A diferença entre individual e grupo é quais nodes/abas ficam disponíveis:**
 

package/dist/docs/resources/glossary.md

@@ -388,13 +388,15 @@ mandar). Detalhes em `lionchat://docs/best-practices`.
 
 **Onde fica armazenado:** `kanban_config.win_reasons` e `kanban_config.loss_reasons` (jsonb arrays na tabela `kanban_configs`).
 
-**Formato:** array de objetos `{id, title}`:
+**Formato:** array de objetos `{id, title}`, com `id` em **texto estável** (nunca número) — detalhes e erros 422 em
+`lionchat://docs/api-conventions` → "Estrutura interna das listas":
 ```json
 "win_reasons": [
   {"id": "wr-1", "title": "Preço competitivo"},
   {"id": "wr-2", "title": "Indicação forte"}
 ]
 ```
+**No card:** `item_details.loss_reason` / `win_reason` guardam o `id` (texto) do motivo escolhido; `reason`, o título.
 
 **Endpoint:** `PUT /api/v1/accounts/{id}/kanban_config` com body wrapped:
 ```json
@@ -414,7 +416,7 @@ mandar). Detalhes em `lionchat://docs/best-practices`.
 |---|---|---|
 | Motivo de Ganho/Perda do card | `kanban_config.win_reasons` / `loss_reasons` | ❌ NÃO |
 | Atributo em TODO card | `kanban_config.global_custom_attributes` | só se não couber acima |
-| Atributo de UM card específico | `kanban_item.custom_attributes` (jsonb direto) | já é nativo, não precisa definition |
+| Valor de um campo em UM card | `item_details.custom_attributes` — LISTA `[{name, type, value}]` casando com o campo de `kanban_config.global_custom_attributes` | a coluna `kanban_item.custom_attributes` NÃO aparece em tela nenhuma — não use pra dado que o cliente precisa ver |
 | CPF, RG, CNPJ, endereço, data nasc., gênero do cliente | mecanismo NATIVO cadastral: `PATCH /contacts/{id}/cadastral` (`update_cadastral`) | ❌ NÃO (tem nativo) |
 | Tag pro contato (residencial, empresarial) | `labels` | ✅ SIM via Label |
 | Etapa do funil | `funnel.stages` | ❌ NÃO |