COMERCIAL-GTI/docs/superpowers/specs/2026-07-30-dark-saas-redesign-design.md

Redesign visual: paleta SaaS dark (app inteiro)

Contexto

Depois de uma sessão extensa corrigindo bugs funcionais da aba Campanhas, o usuário pediu para melhorar o frontend: visual/design + UX de feedback, aplicado ao app inteiro (não só Campanhas). Foram apresentadas 3 direções visuais via mockup (Artifact) com o card de campanha real: Dispatch Board (painel escuro técnico), Route Card (papel/serifada, verde-pinho), Night Shift (roxo-ameixa/dourado). O usuário escolheu Dispatch Board, depois pediu para trocar a paleta para um estilo "SaaS dark" (tipo Linear/Vercel).

Decisões confirmadas com o usuário

• Modo único, sempre escuro. Sem alternância clara/escura — o app vira dark-first como identidade fixa, não uma preferência de sistema.
• Escopo: app inteiro. Login, as 4 abas (Capturar Leads, Tratar Leads, Campanhas, Configurações), modais, tabelas, badges.
• UX incluído nesta leva: toast colorido por sucesso/erro (verde/vermelho). Estados de "carregando" nos botões ficaram fora do escopo por enquanto.
• Manter a estrutura "Dispatch Board" nos cards de campanha e blocos de estatística: números em fonte monoespaçada tabular, indicador de status como borda colorida à esquerda do card (em vez de só um chip).

Achado técnico relevante

public/css/app.css é quase inteiramente orientado por variáveis CSS (:root + @media (prefers-color-scheme: dark)), sem cores hardcoded em login.html, index.html ou nos arquivos .js (confirmado por grep). As únicas exceções são 3 gradientes em app.css que combinam var(--accent) com um tom claro hardcoded (#ff965b, #ff8b47, #ffb36d) — todos parceiros do laranja atual, que precisam de um substituto para o novo roxo-índigo. Isso torna a troca de paleta uma mudança de baixo risco, concentrada quase toda em um bloco de tokens.

Paleta nova (substitui :root; remove o bloco @media (prefers-color-scheme: dark) — deixa de existir modo claro)

--page: #0b0c10
--page-2: #0d0e13
--surface: #16171d
--surface-2: #1d1f27
--ink: #f4f4f6
--ink-2: #a4a6b0
--muted: #6c6e79
--grid: #2a2c35
--border: rgba(255, 255, 255, 0.08)
--accent: #6a63f6
--accent-light: #9d97ff   (novo token — substitui os 3 gradientes hardcoded)
--accent-2: #4f8cff
--accent-ink: #ffffff
--bar: #6a63f6
--good: #22c55e
--good-text: #4ade80
--warning: #f5a524
--critical: #fb5b7c
--critical-bg: rgba(251, 91, 124, 0.12)
--radius-sm: 8px
--radius: 12px
--radius-lg: 16px
--shadow: 0 20px 50px rgba(0, 0, 0, 0.45)
--shadow-soft: 0 8px 24px rgba(0, 0, 0, 0.3)

body usa font: 14px/1.5 Inter, ui-sans-serif, system-ui, ... — mantém Inter (já era a fonte usada; SaaS dark real como Linear também usa Inter).

Componentes com tratamento específico "Dispatch Board"

• .campaign-card: ganha border-left: 3px solid var(--muted), com border-left-color: var(--critical) quando pausada e var(--good) quando ativa (rodando).
• Números de uso/limite (.campaign-usage, .stat-row .mini b, .tile .valor): passam a usar font-variant-numeric: tabular-nums com uma pilha que prioriza ui-monospace, SFMono-Regular, Consolas, monospace para leitura tipo "painel".
• Chips de status (.chip, .chip.ok, .chip.warn) continuam existindo (não são removidos) — só herdam as cores novas automaticamente, via variáveis.

Toast colorido (UX)

public/js/api.js, função toast(message, ms): hoje sempre estiliza igual. Passa a inferir o tipo pela própria mensagem — se começar com "Erro" (case-insensitive), aplica um estado de erro (borda/texto vermelho); caso contrário, estado de sucesso (borda/texto verde). Isso evita precisar tocar em cada um dos ~40 pontos de chamada de toast(...) espalhados por app.js, tratamento.js, captura.js e campanhas.js — a lógica fica centralizada em api.js e no CSS (.toast.erro, .toast.sucesso).

Fora de escopo (explicitamente adiado)

• Estados de "carregando" em botões durante ações assíncronas.
• Qualquer redesign de copy/textos, ícones, ou reestruturação de layout além da troca de paleta/raio/sombra e do tratamento Dispatch Board nos cards de campanha.
• Modo claro (removido, não mantido como alternativa).

Verificação

Não há testes automatizados de aparência visual neste projeto. A verificação é:

1. Suíte de testes existente (node --test, Playwright) continua 100% verde — nenhuma lógica funcional deve quebrar.
2. Checagem visual ao vivo no navegador (via Claude Browser) de cada tela: login, Capturar Leads, Tratar Leads, Campanhas (cards, fila, modais), Configurações (modal grande, conexão WhatsApp, templates), toast de sucesso e de erro.