Merge PR #538 — a busca não derruba a tela, a ocupação do Google não oferece botão morto, e um byte ruim não condena a planilha

Três consertos achados na própria triagem, todos atingindo qualquer instalação:

1. Buscar um nome comum ('ana', 'silva') ou um DDD no Inbox derrubava a tela — erro de servidor, não lista incompleta. É a tela onde quem atende passa o dia. Vírgula no nome buscado quebrava a sintaxe do filtro.
2. O bloco 'Ocupado' vindo do Google aparecia na lista de Próximos com botões Remarcar/Cancelar que davam erro — controle que a tela oferece e o código ignora.
3. Uma planilha com um único byte estranho era decodificada inteira como windows-1252: 500 nomes destruídos, sobrescrevendo o catálogo, com 'importado com sucesso'. A distinção agora é medida — planilha realmente antiga tem um caractere estranho a cada 5; uma normal com uma aspa do Word, um a cada 11 mil.

Author: melgarafael

.changes/a-busca-do-inbox-aceita-virgula-no-nome.md

@@ -0,0 +1,12 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: Buscar no Inbox por um nome com vírgula ou parêntese deixa de derrubar a tela
+---
+
+Quem tem clientes cadastrados como "Sobrenome, Nome" — que é como boa parte das
+agendas importadas vem — não conseguia buscá-los: a tela dava erro em vez de
+lista.
+
+E não era preciso ter a vírgula no cadastro. Bastava o atendente digitá-la na
+busca.

.changes/a-busca-do-inbox-para-de-derrubar-a-tela.md

@@ -0,0 +1,16 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: Buscar um nome comum no Inbox deixa de derrubar a tela
+---
+
+Numa base com muitos contatos, buscar um nome comum — "ana", "silva" — fazia o
+Inbox **parar de abrir**, com erro de servidor. Buscar por DDD tinha o mesmo
+efeito, porque quatro dígitos casam todos os celulares de uma cidade.
+
+Não era lentidão nem lista incompleta: era a tela quebrando, e justamente onde
+quem atende passa o dia.
+
+Agora a lista de contatos que casam é cortada pelo tamanho que cabe na consulta.
+Numa busca muito ampla o resultado pode não trazer todos — mas a tela **abre**,
+e a busca pelo conteúdo da conversa continua rodando ao lado.

.changes/a-ocupacao-do-google-nao-oferece-botao-que-nao-funciona.md

@@ -0,0 +1,16 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: O bloco "Ocupado" da agenda do Google sai da lista de próximos, onde os botões não funcionavam
+---
+
+Os horários ocupados na sua agenda pessoal do Google apareciam também na lista
+**Próximos**, com **Remarcar** e **Cancelar** ligados — como se fossem
+compromissos da empresa. Não eram, e os botões não tinham como funcionar:
+clicar em Cancelar dava erro e nada acontecia.
+
+Agora esses blocos aparecem **só na grade**, que é onde servem: mostram o
+horário tomado, não abrem e não arrastam. A lista de próximos volta a ter só o
+que sua equipe pode remarcar ou cancelar de verdade.
+
+O nome do compromisso particular continua não aparecendo em lugar nenhum.

.changes/agenda-do-google-o-compromisso-chega-la.md

@@ -0,0 +1,32 @@
+---
+impacto: nada_mudou
+secao: corrigido
+titulo: O compromisso marcado aqui passa a aparecer na Agenda do Google — e o que está ocupado lá aparece aqui
+---
+
+Quem conectou a Agenda do Google tinha a integração **ligada e sem efeito nenhum**.
+Valia nas duas direções, e nada na tela dizia isso.
+
+**Nada saía daqui.** O compromisso era marcado, o sistema tentava criá-lo lá a
+cada cinco minutos, e o Google recusava todas as vezes — por um detalhe de
+formato. O erro era registrado só como "HTTP 400", sem o motivo que o Google
+mandava junto. Por isso a falha durou tanto: dava para ver que não funcionava, e
+não dava para saber por quê. Isso nunca funcionou em instalação nenhuma; os
+compromissos já marcados sobem na próxima sincronização.
+
+**E o que estava ocupado lá não era desenhado aqui.** O horário já era
+respeitado — ninguém conseguia marcar em cima —, mas o bloco não aparecia na
+grade. O dono via a agenda vazia e o horário indisponível ao mesmo tempo. Agora o
+bloco aparece, marcado como *Ocupado*.
+
+O **nome** do evento particular continua não aparecendo, de propósito: a agenda
+conectada é pessoal de quem atende, e esta tela é vista pela gestão.
+
+**Quando o Google recusa o acesso**, a tela deixa de mandar "tente de novo" —
+conselho que não funcionaria, porque a causa costuma ser a API do Google Agenda
+desligada no projeto do Google Cloud. Agora ela diz onde ligar.
+
+Para quem opera, nada muda no dia a dia.
+
+O conserto é de @Clalber, que diagnosticou os três defeitos e provou a correção
+com tráfego real.

.github/workflows/e2e.yml

@@ -355,6 +355,9 @@ jobs:
         gatilho-de-etapa.spec.ts gatilho-de-caso.spec.ts
         marca-logo.spec.ts
         historico-de-captacao.spec.ts
+        agenda-ocupacao-do-google-na-grade.spec.ts
+        agenda-ocupacao-do-google-no-historico.spec.ts
+        followup-publicado-abre-no-construtor.spec.ts
         automacao-diz-a-verdade.spec.ts
         inbox-quem-manda.spec.ts
         acervo-de-conhecimento.spec.ts

app/api/v1/conversations/_handler.ts

@@ -15,8 +15,69 @@ import type {
 } from "@/lib/schemas";
 import type { Conversation } from "@/lib/types/messaging";
 
+/**
+ * Prepara o termo digitado para viajar dentro de um `or=` do PostgREST.
+ *
+ * Exportada para ser testável: o defeito que ela impede é de SINTAXE, e sintaxe
+ * se verifica sem subir banco. O comportamento contra o PostgREST de verdade
+ * está em `tests/e2e/`.
+ */
+export function termoSeguroParaOr(bruto: string): string {
+  return bruto
+    .trim()
+    // curingas do `ilike` (Postgres)
+    .replace(/[%_]/g, (m) => `\\${m}`)
+    // gramática do `or=` (PostgREST) — viram o próprio curinga
+    .replace(/[,()]/g, "*");
+}
+
 type SB = SupabaseClient;
 
+/**
+ * Quantos contatos a busca do Inbox casa antes de cortar.
+ *
+ * Não é um número estético: os ids viajam DENTRO da querystring do PostgREST
+ * (`contact_id.in.(<uuid>,<uuid>,…)`), e requisição GET tem teto no gateway.
+ */
+const TETO_DE_CONTATOS_NA_BUSCA = 120;
+
+/**
+ * O orçamento de bytes que a lista de ids pode ocupar na URL.
+ *
+ * O muro real é 8.192 B na linha de requisição (Kong e nginx, ambos no default),
+ * e a URL leva mais coisa além dos ids: caminho, `select` com todas as
+ * `SELECT_COLS`, o filtro de organização, o `order`, o `limit` e o próprio
+ * `ilike` do termo. Medido neste arquivo, com 1 id a URL já tem 892 B — então o
+ * que sobra para os ids é o resto, e 5.000 B deixa folga confortável para o
+ * termo de busca crescer sem que ninguém precise voltar aqui.
+ *
+ * Cortar por BYTES e não por quantidade é o que faz esta guarda sobreviver a
+ * uma coluna nova em `SELECT_COLS` ou a um formato de id diferente.
+ */
+const ORCAMENTO_DE_IDS_NA_URL = 5_000;
+
+/**
+ * Corta a lista de ids no que cabe no orçamento da URL.
+ *
+ * Devolver menos contatos torna a busca INCOMPLETA — o que é ruim — mas devolver
+ * todos torna a tela QUEBRADA, com `414` virando `500` na cara do operador. Entre
+ * uma lista pobre e uma tela que não abre, a lista pobre ganha; e a diferença
+ * aparece porque a busca por conteúdo (`last_message_preview`) continua rodando
+ * ao lado, sem depender desta lista.
+ */
+function idsQueCabemNaURL(ids: string[]): string[] {
+  const cabem: string[] = [];
+  let bytes = 0;
+  for (const id of ids) {
+    // +1 pela vírgula que separa; o último sobra do lado seguro.
+    const custo = id.length + 1;
+    if (bytes + custo > ORCAMENTO_DE_IDS_NA_URL) break;
+    cabem.push(id);
+    bytes += custo;
+  }
+  return cabem;
+}
+
 const SELECT_COLS = `
   id, organization_id, contact_id, channel_session_id, channel, status,
   status_changed_at, assigned_to_user_id, assigned_to_user_name, assignee_kind, assigned_at, last_inbound_at,
@@ -144,7 +205,44 @@ export async function listConversationsHandler(
   }
 
   if (q.search) {
-    const s = q.search.trim().replace(/[%_]/g, (m) => `\\${m}`);
+    // ─── O TERMO NÃO PODE QUEBRAR A SINTAXE DO `.or()` ────────────────────
+    //
+    // Dois escapes diferentes, para dois parsers diferentes, e eles NÃO se
+    // substituem:
+    //
+    //   `%` e `_` são curingas do `ilike` (Postgres) — escapados com `\`.
+    //   `,` `(` `)` são a GRAMÁTICA do `or=` (PostgREST) — e para eles o
+    //   PostgREST não oferece escape nenhum dentro de um valor sem aspas.
+    //
+    // Medido contra o PostgREST v14.10 do stack local deste repo, buscando um
+    // contato que existe:
+    //
+    //   or=(display_name.ilike.*DIAG, 178*,…)   → HTTP 400 PGRST100
+    //                                             "failed to parse logic tree"
+    //   or=(display_name.ilike.*DIAG* 178*,…)   → 200, 3 resultados
+    //
+    // Ou seja: um cliente cadastrado como "Sobrenome, Nome" — que é como meia
+    // agenda de CRM é digitada — DERRUBA a busca do Inbox, não devolve lista
+    // vazia. E a vírgula não precisa estar no banco: basta o atendente digitá-la.
+    //
+    // AS DUAS SAÍDAS ÓBVIAS FORAM MEDIDAS E AS DUAS FALHAM:
+    //
+    //   aspas duplas no valor .... `ilike."*IAG*"` → 0 resultados contra
+    //                              `ilike.*IAG*` → 3. Dentro das aspas o `*`
+    //                              deixa de ser curinga; consertaria a sintaxe
+    //                              e mataria a busca.
+    //   barra invertida .......... `ilike.*I\,AG*` → HTTP 400. O PostgREST não
+    //                              tem escape para a vírgula fora de aspas.
+    //
+    // O que sobra, e é o que está aqui: trocar o metacaractere pelo PRÓPRIO
+    // curinga. "Silva, João" vira `*Silva* João*`, que casa "Silva, João" no
+    // banco — o `%` cobre a vírgula. A busca fica ligeiramente mais larga, e
+    // essa direção é a certa: o custo é achar um vizinho a mais; o custo do
+    // outro lado é a tela em branco com 400.
+    //
+    // O controle que impede o degenerado está no teste: termo inexistente
+    // continua devolvendo ZERO. Sem ele, "troque tudo por `*`" passaria.
+    const s = termoSeguroParaOr(q.search);
 
     // ─── A BUSCA ALCANÇA O CONTATO, NÃO SÓ A ÚLTIMA MENSAGEM ──────────────
     //
@@ -179,9 +277,28 @@ export async function listConversationsHandler(
       .or(camposDoContato)
       // Teto obrigatório: a lista de ids viaja na URL do PostgREST, e uma busca
       // por "a" sem limite estoura a requisição.
-      .limit(200);
-
-    const ids = (contatos ?? []).map((c) => (c as { id: string }).id);
+      //
+      // ⚠️ 200 ERA ACIMA DO MURO, e o comentário acima descrevia o perigo certo
+      // com o número errado. Medido com o `postgrest-js` real e as `SELECT_COLS`
+      // deste arquivo:
+      //
+      //     ids=  1 →   892 B      ids=186 →  8.098 B
+      //     ids=100 → 4.753 B      ids=200 →  8.653 B   ← acima de 8.192
+      //
+      // Kong 2.8.1 — o gateway que a Supabase põe na frente do PostgREST, e o
+      // mesmo que o stack local deste repo sobe — devolve `414 URI too long` a
+      // partir de ~187 ids. E o `error` desta consulta vira `500 internal_error`
+      // no handler, então o Inbox PARA: buscar "ana" ou "silva" numa base de
+      // milhares de contatos devolvia a tela quebrada, não uma lista pobre.
+      //
+      // O teto agora é de BYTES, não de linhas, porque é byte que estoura. O
+      // número de ids que cabe é consequência, e continua certo se as colunas
+      // ou o formato do id mudarem.
+      .limit(TETO_DE_CONTATOS_NA_BUSCA);
+
+    const ids = idsQueCabemNaURL(
+      (contatos ?? []).map((c) => (c as { id: string }).id),
+    );
     if (ids.length > 0) {
       query = query.or(
         `last_message_preview.ilike.*${s}*,contact_id.in.(${ids.join(",")})`,

app/app/agenda/_client.tsx

@@ -225,6 +225,22 @@ export function AgendaClient({
     [isolada, todos],
   );
 
+  /**
+   * O que é ACIONÁVEL — o que a lista "Próximos" pode oferecer botão para fazer.
+   *
+   * Ocupação vinda do Google fica de fora: ela é bloco de terceiro, o id é de
+   * `calendar_external_events`, e as rotas de remarcar/cancelar procuram em
+   * `calendar_appointments`. Ver o comentário longo no `HistoricoDaAgenda`
+   * abaixo, com o 404 medido.
+   *
+   * A GRADE continua recebendo `agendamentos` inteiro — é lá que a ocupação
+   * precisa aparecer, e é lá que ela já é desenhada inerte.
+   */
+  const agendamentosAcionaveis = React.useMemo(
+    () => agendamentos.filter((a) => a.origem !== "google_sync"),
+    [agendamentos],
+  );
+
   const passo = visao === "mes" ? 30 : visao === "semana" ? 7 : 1;
   // O PADRÃO de formato também muda de idioma, não só o locale: em português
   // "d 'de' MMMM" tem a preposição escrita à mão dentro do padrão, e em
@@ -617,8 +633,37 @@ export function AgendaClient({
         </SheetContent>
       </Sheet>
 
+      {/*
+        ⚠️ A LISTA DAQUI NÃO É A MESMA DA GRADE, e a diferença é uma linha.
+
+        `GradeDaAgenda` conhece `origem` e desenha o bloco do Google inerte
+        (`disabled`, sem arraste, rótulo "Ocupado"). `HistoricoDaAgenda` NÃO
+        conhece origem: ela decide o botão por `disabled={!onRemarcar}`, que é
+        uma prop do componente inteiro e não da linha. Passar a mesma lista aos
+        dois faz a ocupação do Google chegar em "Próximos" com **Remarcar e
+        Cancelar habilitados** — e cancelar responde 404, porque o id é de
+        `calendar_external_events` e a rota procura em `calendar_appointments`.
+
+        Medido pela tela em 2026-09-03, na triagem do PR #474:
+
+          DELETE /api/v1/agenda/agendamentos
+          → 404 {"error":{"code":"not_found","message":"Agendamento não encontrado."}}
+          toast vermelho aos 1,5s, o painel continua aberto, a linha continua na
+          lista, e `calendar_external_events.status` segue `confirmed`.
+
+        É o "controle decorativo" que o comentário de `GradeDaAgenda` diz que
+        esta base já pagou uma vez, replantado no componente irmão — e o #474 o
+        tornou PERMANENTE: antes dele a linha só existia no primeiro frame da
+        semana corrente (a semente do servidor) e sumia no primeiro refetch.
+
+        Filtrar é o conserto certo, e não é escolha estética: bloco anônimo do
+        Google não é um compromisso NOSSO. Não há o que remarcar, não há o que
+        cancelar, e "Ocupado · 15:00–16:00" numa lista de próximos atendimentos
+        não informa nada que a grade — que O DESENHA no horário — já não diga
+        melhor. A ocupação continua inteira onde ela serve.
+      */}
       <HistoricoDaAgenda
-        agendamentos={agendamentos}
+        agendamentos={agendamentosAcionaveis}
         pessoas={pessoas}
         agora={new Date()}
         className="max-h-[320px]"

lib/contacts/csv.ts

@@ -26,7 +26,33 @@ import { normalizePhoneBR } from "@/lib/webhooks/inbound";
  *
  * O desempate não é detecção de charset, é uma prova: `TextDecoder("utf-8")` só
  * produz U+FFFD quando o byte-stream NÃO é UTF-8 válido. Ausência de U+FFFD é
- * prova de que UTF-8 é a leitura certa; presença é prova de que não é.
+ * prova de que UTF-8 é a leitura certa.
+ *
+ * ⚠️ MAS A PRESENÇA NÃO É PROVA DO CONTRÁRIO, e a primeira versão disto tratava
+ * como se fosse — a decisão era por ARQUIVO sobre um sinal por BYTE, sem
+ * proporção. Um único byte inválido no meio de um arquivo perfeitamente UTF-8
+ * (a aspa curva do Word, 0x92, sobra comum de copiar-colar) jogava as 500 linhas
+ * boas para o `windows-1252`. Medido, com as funções deste arquivo:
+ *
+ *   arquivo limpo          → utf-8         "Ação" corretos=500  mojibake=  0
+ *   + 1 byte 0x92 no meio  → windows-1252  "Ação" corretos=  0  mojibake=500
+ *   antes deste arquivo    → "Ação" corretos=500, com U+FFFD=1
+ *
+ * Ou seja: no caminho do byte solto, a versão anterior a `file.text()` era
+ * MELHOR — ela corrompia um caractere, não o arquivo. E o `upsert` por
+ * `(organization_id, codigo)` sobrescreve os nomes bons que já estavam no
+ * catálogo, com `erros: []` e 200 OK.
+ *
+ * A prova certa é a DENSIDADE, porque as duas causas ficam a três ordens de
+ * grandeza de distância. Medido no mesmo texto de 500 linhas:
+ *
+ *   latin-1 de verdade (o que este arquivo conserta) → 1 U+FFFD a cada     5 bytes
+ *   UTF-8 com 1 byte inválido                        → 1 U+FFFD a cada 11.392
+ *   misto: 499 linhas UTF-8 + 1 linha latin-1        → 1 U+FFFD a cada  5.692
+ *
+ * `MAX_BYTES_POR_SUBSTITUICAO` fica no meio dessa distância, e é generoso de
+ * propósito: errar para o lado do UTF-8 corrompe um caractere; errar para o
+ * outro corrompe o arquivo inteiro. Os dois erros não custam o mesmo.
  *
  * O `windows-1252` "consegue" ler qualquer byte, então cair nele sem olhar o
  * resultado transformaria um .xlsx renomeado em 300 produtos de nome ilegível.
@@ -39,11 +65,28 @@ import { normalizePhoneBR } from "@/lib/webhooks/inbound";
  * planilha — é UTF-8 VÁLIDO, não tem U+FFFD nenhum, e passa limpo. É outro
  * defeito, com outra evidência.
  */
+/**
+ * A partir de quantos bytes por substituição o arquivo deixa de ser "latin-1" e
+ * passa a ser "UTF-8 com um byte ruim".
+ *
+ * 100 fica entre as duas causas medidas (5 e 5.692 bytes por U+FFFD) com folga
+ * de mais de uma ordem de grandeza para cada lado — não é um número escolhido
+ * para caber num caso, é o meio de um vale largo.
+ */
+const MAX_BYTES_POR_SUBSTITUICAO = 100;
+
 export function decodificarCsv(bytes: ArrayBuffer | Uint8Array): { texto: string } | { erro: string } {
   const buf = bytes instanceof Uint8Array ? bytes : new Uint8Array(bytes);
 
   const utf8 = new TextDecoder("utf-8").decode(buf);
-  if (!utf8.includes("\uFFFD")) return { texto: semBom(utf8) };
+  const substituicoes = (utf8.match(/\uFFFD/g) ?? []).length;
+  // Sem nenhuma: UTF-8 válido, e a prova é completa.
+  if (substituicoes === 0) return { texto: semBom(utf8) };
+  // Com poucas: é UTF-8 com sujeira pontual, não outro charset. Trocar de
+  // decoder aqui estragaria o arquivo inteiro para consertar um caractere.
+  if (buf.byteLength / substituicoes > MAX_BYTES_POR_SUBSTITUICAO) {
+    return { texto: semBom(utf8) };
+  }
 
   const latin = new TextDecoder("windows-1252").decode(buf);
   // eslint-disable-next-line no-control-regex -- é exatamente o que se procura