feat(atendimento): fila de leads por atendente ganha porta, e o rodízio passa a distribuir lead (#144)

Pedido por @WerikoEntusiasta: distribuir leads em rodízio entre atendentes, com
cada um vendo só os seus. Medido antes de escrever uma linha: as duas coisas já
existiam INTEIRAS no backend — o worker de rodízio (`lib/routing/`, modo
`round_robin`, elegibilidade por disponibilidade e horário) e a RLS de
visibilidade (`fn_can_view_lead`, `fn_can_view_conversation`, modo `own`).

O que não existia era a PORTA. Nenhum arquivo de `app/` ou `components/`
consumia `/api/v1/settings/routing`, e `visibility_mode` só aparecia sendo LIDO
em `app/app/layout.tsx` — escrito por ninguém. O único jeito de ligar a feature
que o contribuidor pediu era `UPDATE` à mão no Postgres. Num produto self-host
isso é a feature não existir.

TRÊS BURACOS, e os dois últimos só apareceram porque a prova foi pela tela:

1. **Sem tela.** Entra `/app/settings/atendimento` (manager+, que é o que a
   matriz da spec 13 §4 dá para "atendimento/routing"), com as duas decisões
   juntas porque uma sem a outra quebra: distribuir sem restringir deixa todos
   vendo a carteira do colega; restringir sem distribuir deixa o funil vazio. A
   tela avisa justamente essa combinação morta. Registrada em
   `lib/navigation/registry.ts` — tela sem porta é o mesmo defeito de novo.

2. **O rodízio distribuía CONVERSA e não LEAD.** `fn_conversation_assign` grava
   `conversations.assigned_to_user_id` e não toca em `crm_leads.owner_user_id`.
   Com `visibility_mode='own'` — exatamente o que a issue pede — lead sem dono
   não aparece para NINGUÉM: o atendente receberia a conversa e abriria um funil
   vazio. A restrição funcionaria e a fila não existiria. O worker agora adota os
   leads abertos do contato, e só os SEM DONO (nem humano nem agente de IA):
   roubar lead com dono transformaria o rodízio em reatribuição silenciosa a
   cada mensagem nova.

3. **`PATCH /api/v1/settings/routing` era um no-op silencioso.** A única policy
   de escrita de `organizations` é `orgs_write_platform_admin`, com
   `USING (fn_is_platform_admin())`. Pelo client de sessão o UPDATE de um manager
   casa ZERO linhas — e o PostgREST devolve sucesso, porque "nada casou o filtro"
   não é erro. A tela dizia "salvo" e o reload trazia o estado antigo. Medido no
   banco: manager → 0 linhas, postgres → 1 (controle positivo). Ninguém tinha
   notado porque o dono do repo e o owner criado pelo `bootstrap-owner.ts` são
   platform_admin; quem tropeça é o segundo admin convidado e todo manager.
   Consertei a CLASSE, não a instância: `updateTenant` (perfil da org, admin-only)
   tinha o mesmo defeito e está no mesmo commit.

PROVAS
- `distribuicao-atendimento.spec.ts` dirige o frontend: acha a tela pela
  navegação (não pela URL), liga rodízio + restrição, salva, RECARREGA e confere
  que o estado voltou do banco, e confirma que a API concorda com a tela. Mais o
  RBAC pelo servidor (agent → 403), porque o redirect da página é conforto, não
  defesa. **3 testes verdes** contra Supabase local com o `baseline.sql` aplicado.
- Sabotagem: voltar o PATCH para o client de sessão deixa a spec vermelha — foi
  assim que o defeito nº 3 apareceu.
- Unit: `routing-adota-lead.test.ts` guarda as condições da adoção (sabotado nos
  dois eixos) e `atendimento-config-visibilidade.test.ts` cobra que um corpo sem
  `visibility_mode` PRESERVE a restrição em vez de voltar ao default — o jeito de
  uma org perder a restrição sem ninguém pedir.
- Sem mudança de schema: `settings` é jsonb e as colunas de dono já existem.
- gov:verify verde: 258 arquivos, 2381 testes.

Closes #144

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HstH7nNmrTvCtZsasppeHj

Author: melgarafael

.github/workflows/e2e.yml

@@ -124,7 +124,8 @@ jobs:
             rbac-roles.spec.ts inbox-scope.spec.ts reset-password-mfa.spec.ts \
             degradacao-silenciosa.spec.ts vps-webhook-outbound-ssrf.spec.ts \
             kanban-owner-filter.spec.ts queue-assign.spec.ts \
-            risk-radar.spec.ts invite-lifecycle.spec.ts system-update.spec.ts
+            risk-radar.spec.ts invite-lifecycle.spec.ts system-update.spec.ts \
+            distribuicao-atendimento.spec.ts
         env:
           INTERNAL_SECRET: ci-placeholder-nao-e-segredo
           CPF_ENCRYPTION_KEY: ci-placeholder-nao-e-segredo
@@ -143,10 +144,11 @@ jobs:
           {
             echo "## E2E — cobertura deste job"
             echo ""
-            echo "**Rodou (15 de 20 specs):** smoke, auth, error-pages, password-recovery,"
+            echo "**Rodou (16 de 33 specs):** smoke, auth, error-pages, password-recovery,"
             echo "signup-journey, rbac-roles, inbox-scope, reset-password-mfa,"
             echo "degradacao-silenciosa, vps-webhook-outbound-ssrf, kanban-owner-filter,"
-            echo "queue-assign, risk-radar, invite-lifecycle, system-update."
+            echo "queue-assign, risk-radar, invite-lifecycle, system-update,"
+            echo "distribuicao-atendimento."
             echo ""
             echo "**Não rodou (5):**"
             echo "- precisa de WAHA: followup-journey, webhooks"

app/actions/settings/updateTenant.ts

@@ -3,6 +3,7 @@
 import { headers } from "next/headers";
 import { revalidatePath } from "next/cache";
 
+import { createAdminClient } from "@/lib/supabase/admin";
 import { createClient } from "@/lib/supabase/server";
 import { audit } from "@/lib/audit";
 import { tenantSchema, type TenantInput } from "@/lib/schemas/settings";
@@ -27,7 +28,26 @@ export async function updateTenant(input: TenantInput): Promise<UpdateTenantResu
     return { ok: false, error: "forbidden_role" };
   }
 
-  const supabase = await createClient();
+/**
+ * A ESCRITA EM `organizations` VAI PELO ADMIN CLIENT — e não é preguiça.
+ *
+ * A única policy de escrita da tabela é `orgs_write_platform_admin`, com
+ * `USING (fn_is_platform_admin())`. Pelo client de sessão, o UPDATE de quem não
+ * é super-admin de plataforma casa ZERO linhas — e o PostgREST devolve sucesso,
+ * porque "nenhuma linha casou o filtro" não é erro. Resultado: a tela dizia
+ * "salvo", nada era gravado, e recarregar mostrava o estado antigo.
+ *
+ * Medido em Postgres com o baseline aplicado (issue #144): sob `authenticated`
+ * com o JWT de um manager, `update organizations` devolve 0 linhas; sob
+ * postgres, 1. Ninguém tinha notado porque o dono do repo e o owner criado pelo
+ * `bootstrap-owner.ts` SÃO platform_admin — quem tropeça é o segundo admin
+ * convidado e qualquer manager.
+ *
+ * O gate continua sendo o de cima (papel resolvido de fonte confiável), e o
+ * filtro por `organization_id` é explícito, como a doutrina exige de todo
+ * handler que usa service role.
+ */
+  const supabase = createAdminClient();
   const hdrs = await headers();
   const requestId = hdrs.get("x-request-id");
   const ip = hdrs.get("x-forwarded-for")?.split(",")[0]?.trim() ?? null;

app/api/v1/settings/routing/route.ts

@@ -1,6 +1,7 @@
 /**
- * GET  /api/v1/settings/routing — lê organizations.settings.routing (manager+).
- * PATCH /api/v1/settings/routing — grava a config de roteamento (manager+).
+ * GET  /api/v1/settings/routing — lê a config de ATENDIMENTO (manager+):
+ *      `organizations.settings.routing` + `settings.visibility_mode`.
+ * PATCH /api/v1/settings/routing — grava as duas (manager+).
  *
  * Rota v1 dedicada (não o Server Action updateTenant): a matriz spec 13 §4 nota
  * 5 separa autz — routing/atendimento é manager+, enquanto o perfil da org
@@ -9,6 +10,22 @@
  *
  * knobs (max_retries, backoff_seconds) são CONFIG — o worker de G5-02 LÊ daqui;
  * nunca constantes hardcoded no worker (doutrina). org de fonte confiável.
+ *
+ * POR QUE `visibility_mode` ENTRA AQUI (issue #144). A matriz de papéis da spec
+ * 13 §4 trata as duas como a MESMA linha — "config de atendimento/roteamento:
+ * manager+" — e a §3.5 as declara no mesmo bloco. Separar em duas rotas com o
+ * mesmo gate seria inventar uma fronteira que a spec não tem, e deixaria a tela
+ * fazendo dois round-trips para salvar uma decisão só ("como distribuo, e quem
+ * enxerga o quê").
+ *
+ * Até esta mudança, `visibility_mode` era LIDO em `app/app/layout.tsx` e escrito
+ * por NINGUÉM: a restrição existia na RLS, no schema e na doutrina, e não havia
+ * caminho no produto para ligá-la — só `UPDATE` à mão no banco. Num produto
+ * self-host isso equivale a não existir.
+ *
+ * `visibility_mode` fica em `settings.visibility_mode`, irmão de
+ * `settings.routing` e não dentro dele: é esse caminho exato que
+ * `fn_can_view_lead`/`fn_can_view_conversation` leem na RLS.
  */
 import { randomUUID } from "node:crypto";
 import type { NextRequest } from "next/server";
@@ -17,7 +34,9 @@ import { ok, fail } from "@/lib/api/wrappers";
 import { ApiError } from "@/lib/api/types";
 import { audit } from "@/lib/audit";
 import { requireRole } from "@/lib/auth/require-role";
-import { routingConfigSchema, validateRequest } from "@/lib/schemas";
+import { atendimentoConfigPatchSchema, routingConfigSchema, validateRequest } from "@/lib/schemas";
+import { DEFAULT_VISIBILITY_MODE, type VisibilityMode } from "@/lib/auth/types";
+import { createAdminClient } from "@/lib/supabase/admin";
 import { createClient } from "@/lib/supabase/server";
 
 export const dynamic = "force-dynamic";
@@ -41,7 +60,11 @@ export async function GET(_req: NextRequest): Promise<Response> {
 
   const settings = (orgRow?.settings as Record<string, unknown> | null) ?? {};
   const routing = routingConfigSchema.catch(DEFAULT_ROUTING).parse(settings.routing ?? {});
-  return ok(routing, { requestId });
+  // O default é o MESMO de `lib/auth/types.ts`, que é o que a RLS assume quando
+  // a chave não existe (`coalesce(..., 'own_and_unassigned')`). Divergir aqui
+  // faria a tela mostrar um estado que o banco não pratica.
+  const visibility_mode = (settings.visibility_mode as VisibilityMode | undefined) ?? DEFAULT_VISIBILITY_MODE;
+  return ok({ ...routing, visibility_mode }, { requestId });
 }
 
 export async function PATCH(req: NextRequest): Promise<Response> {
@@ -52,7 +75,7 @@ export async function PATCH(req: NextRequest): Promise<Response> {
 
   let input;
   try {
-    input = await validateRequest(routingConfigSchema, req);
+    input = await validateRequest(atendimentoConfigPatchSchema, req);
   } catch (err) {
     if (err instanceof ApiError) {
       return fail(err.code, err.message, err.status, {
@@ -63,7 +86,26 @@ export async function PATCH(req: NextRequest): Promise<Response> {
     throw err;
   }
 
-  const supabase = await createClient();
+/**
+ * A ESCRITA EM `organizations` VAI PELO ADMIN CLIENT — e não é preguiça.
+ *
+ * A única policy de escrita da tabela é `orgs_write_platform_admin`, com
+ * `USING (fn_is_platform_admin())`. Pelo client de sessão, o UPDATE de quem não
+ * é super-admin de plataforma casa ZERO linhas — e o PostgREST devolve sucesso,
+ * porque "nenhuma linha casou o filtro" não é erro. Resultado: a tela dizia
+ * "salvo", nada era gravado, e recarregar mostrava o estado antigo.
+ *
+ * Medido em Postgres com o baseline aplicado (issue #144): sob `authenticated`
+ * com o JWT de um manager, `update organizations` devolve 0 linhas; sob
+ * postgres, 1. Ninguém tinha notado porque o dono do repo e o owner criado pelo
+ * `bootstrap-owner.ts` SÃO platform_admin — quem tropeça é o segundo admin
+ * convidado e qualquer manager.
+ *
+ * O gate continua sendo o de cima (papel resolvido de fonte confiável), e o
+ * filtro por `organization_id` é explícito, como a doutrina exige de todo
+ * handler que usa service role.
+ */
+  const supabase = createAdminClient();
   const { data: orgRow, error: readErr } = await supabase
     .from("organizations")
     .select("settings")
@@ -72,7 +114,13 @@ export async function PATCH(req: NextRequest): Promise<Response> {
   if (readErr) return fail("internal_error", readErr.message, 500, { requestId });
 
   const currentSettings = (orgRow?.settings as Record<string, unknown> | null) ?? {};
-  const nextSettings = { ...currentSettings, routing: input };
+  const { visibility_mode, ...routing } = input;
+  // Merge não-destrutivo em DOIS níveis: preserva as demais chaves de `settings`
+  // e, quando `visibility_mode` não vem no corpo, preserva a que já valia — um
+  // cliente antigo (que só conhece o roteamento) não pode desligar a restrição
+  // de visibilidade sem pedir.
+  const nextSettings: Record<string, unknown> = { ...currentSettings, routing };
+  if (visibility_mode !== undefined) nextSettings.visibility_mode = visibility_mode;
 
   const { error: updErr } = await supabase
     .from("organizations")
@@ -87,8 +135,16 @@ export async function PATCH(req: NextRequest): Promise<Response> {
     resourceType: "organization",
     resourceId: activeOrg.orgId,
     requestId,
-    metadata: { routing: input },
+    metadata: { routing, ...(visibility_mode !== undefined ? { visibility_mode } : {}) },
   });
 
-  return ok(input, { requestId });
+  return ok(
+    {
+      ...routing,
+      visibility_mode:
+        visibility_mode ??
+        ((currentSettings.visibility_mode as VisibilityMode | undefined) ?? DEFAULT_VISIBILITY_MODE),
+    },
+    { requestId },
+  );
 }