Da planilha ao ERP.

Quero que você crie uma skill nova para mim chamada "analise-estrategica-empresa".

Propósito: quando eu anexar uma ou mais planilhas empresariais (vendas, financeiro,
ops), a skill deve:

1. Foco primário: traçar painel ESTRATÉGICO de KPIs que essa empresa deveria
   monitorar — não só listar números, mas dizer quais importam pra decisão.
2. Foco secundário: pontuar gaps críticos que aparecem no cruzamento das planilhas.
3. Saída: tabela mestra de KPIs + recomendação de arquitetura de dashboard
   com 2 seções (Vendas e Financeiro).

Estilo: executivo, linguagem de empresário brasileiro, sem jargão técnico
desnecessário. Sempre executa código para validar cálculos. Sempre confere
2 linhas aleatórias antes de concluir.

Construa a skill completa: SKILL.md com frontmatter (name + description) +
instruções estruturadas + formato de saída + regras.
Depois me devolva o arquivo pronto para eu subir em Settings → Features → Skills.

Você é VP de operações com 20 anos no setor [SETOR DA SUA EMPRESA].
Sua missão: traçar painel ESTRATÉGICO das duas planilhas anexadas.

<contexto>
Empresa: [NOME DA EMPRESA] — [DESCRIÇÃO EM 1 LINHA]
Faturamento mensal médio: R$ [VALOR]
Equipe: [N] pessoas · [N] vendedores ativos
Decisão importante nas próximas 30 dias: [DECISÃO ESPECÍFICA]
</contexto>

<arquivos>
Anexei (ou estão no meu Drive conectado):
- Planilha de vendas
- Planilha financeira

Identifique os arquivos pelo nome e pelo conteúdo. Use os conectores
para acessá-los se estiverem no Drive.
</arquivos>

<tarefa>
FOCO PRIMÁRIO — Painel estratégico de KPIs:
Defina os 8-12 KPIs que essa empresa deveria monitorar SEMANALMENTE,
baseado no modelo de negócio + dados disponíveis + benchmark do setor.

Para cada KPI:
- Nome
- Fórmula (com colunas exatas das planilhas)
- Valor atual calculado
- Benchmark do setor (use seu conhecimento)
- Frequência ideal de revisão
- Quem é dono (cargo/área)
- Em qual seção do dashboard vai (Vendas ou Financeiro)

FOCO SECUNDÁRIO — Gaps cruzados (3 itens):
Cruze as duas planilhas e aponte 3 gaps que só aparecem nessa intersecção
(ex: cliente top da planilha de vendas vs aging dele na financeira).

ENTREGA FINAL:
Recomendação de arquitetura de dashboard executivo com 2 seções:
"Vendas" e "Financeiro". Diga quais KPIs vão em cada seção, quais filtros
globais, e qual visualização para cada KPI (card, gráfico de linha,
tabela, funnel, etc).
</tarefa>

<formato>
1. Visão executiva (1 parágrafo de 5 linhas)
2. Tabela mestra de KPIs (8-12 linhas)
3. 3 gaps cruzados (vendas × financeira)
4. Arquitetura de dashboard: seção Vendas + seção Financeiro
</formato>

Execute código para validar cálculos. Confira 2 linhas aleatórias de cada planilha
antes de concluir.

Gere O PROMPT B — pronto para colar no Lovable DEPOIS do Prompt A.

OBJETIVO DO PROMPT B: levar Lovable a entregar MVP funcional em UMA
ÚNICA geração — sem fases, sem confirmações, sem cron, sem webhook,
sem admin role, sem "sincronizar agora" manual. Quando empresário
abrir o app pela primeira vez, dashboards já aparecem populados.

CONTEXTO (mencione no Prompt B, mas curto):
- Conector nativo do Lovable já ATIVO (via Prompt A):
  Google Drive + Sheets OU Microsoft Excel (se ambiente MS 365)
- Arquivos já conectados:
  · [TIPO 1]: [NOME EXATO DO ARQUIVO 1 ANALISADO NESTA CONVERSA]
  · [TIPO 2]: [NOME EXATO DO ARQUIVO 2 ANALISADO NESTA CONVERSA]
- Conteúdo das planilhas já analisado por mim (Claude) nesta conversa.
  KPIs, fórmulas, dimensões e arquitetura JÁ DECIDIDOS abaixo.
  NÃO reanalise. NÃO redescubra schema. NÃO infira KPIs.

REGRAS DE ENGENHARIA — INCLUA EXPLICITAMENTE NO PROMPT B:
- Entregue MVP completo em uma geração. Sem dividir em fases.
  Sem pedir confirmação. Sem "próximos turnos".
- Stack: React + TypeScript + Tailwind + shadcn/ui + Recharts + Lovable
  Cloud (banco e auth internos). Sem Supabase externo, sem Firebase.
- Auth: login Google nativo do Lovable Cloud. Single-user. NÃO
  multi-tenant. Sem OAuth próprio. Sem Service Account. Sem
  Google Cloud Console. Sem escopos OAuth estendidos.
- Renderiza DIRETO do conector Sheets. NÃO crie cache em banco com
  upsert + PK. NÃO use Watch Channel, webhook, pg_cron ou edge
  function de sync. NÃO crie tela de "sincronizar agora".
- KPIs JÁ DEFINIDOS abaixo. Use as fórmulas exatas. Não infira.
- Se algum dado faltar na planilha, mostre Empty State elegante
  (nunca crash, nunca tela vazia, nunca "em construção").

REGRAS DE ROBUSTEZ — OBRIGATÓRIO no Prompt B (previnem bugs comuns
em dashboards lendo planilhas reais com qualquer estrutura):

R1. PARSING DE DATA EM FUSO LOCAL
   - Criar helper `parseLocalDate(s: string): Date` que faz split
     YYYY-MM-DD e constrói Date com `new Date(y, m-1, d)` (fuso local).
   - PROIBIDO `new Date("YYYY-MM-DD")` direto — parseia como UTC e
     em fuso negativo (BRT/UTC-3) volta 1 dia.
   - Aplicar em TODA coluna de data identificada na planilha,
     qualquer que seja o nome (data, emissão, vencimento, criado_em).

R2. ÂNCORA TEMPORAL = dataClock
   - Calcular `dataClock = min(max(datas do dataset), hoje)` no carregamento.
   - Janelas "mês corrente / MTD / YTD" ancoram em `dataClock`,
     não em `new Date()`. Garante que dash abre com dado mesmo se a
     planilha não tiver dados de hoje.
   - Janelas "hoje / 7d / 14d / 30d / personalizado" ancoram em
     hoje real. Não substituir.

R3. FALLBACK DE PERÍODO DIFERENCIADO
   - Se janela "mês / MTD / YTD" der vazio → cair para último período
     com dados + exibir banner "Mostrando dados de [período]".
   - Se janela "hoje / 7d / 14d / 30d / personalizado" der vazio →
     respeitar escolha do usuário. NUNCA fallback silencioso.

R4. SAFETY NETS EM AGREGAÇÕES ANUAIS / RANKINGS
   - Toda agregação YTD, ranking Top-N anual, métrica anualizada (DSO,
     turnover, etc): se ano âncora vier vazio, cair para "todo histórico
     filtrado pelos mesmos critérios qualitativos" + banner stale.
   - Métricas de portfólio (inadimplência, ocupação, utilização):
     se range vazio, cair para portfólio total. Nunca retornar 0
     por desalinhamento de datas.

R5. CACHE DUAS CAMADAS COM MODO REALTIME
   - Server: TTL 30s padrão. Modo realtime: dedup in-flight por fileId
     + checagem barata de `modifiedTime` antes de baixar XLSX +
     mini-TTL 3s no metadata + fallback resiliente se metadata falhar.
   - Cliente: React Query staleTime 60s padrão. Realtime: staleTime 0
     + refetchInterval 5s + bust flag na chamada.
   - Botão "Atualizar" manual no header de cada seção dispara refetch.

R6. ROTEAMENTO DEFENSIVO
   - `useSearch({ strict: false })` em TODO componente global
     (filtros, header, sidebar).
   - `useNavigate` somente quando rota destino está montada:
     guard `currentPath.startsWith(targetUrl)` OU usar mapa URL_FOR.
   - Atualizações de filtro usam `replace: true` (não empilha histórico).

R7. SECRETS SERVER-ONLY
   - Chaves de API (LOVABLE_API_KEY, GOOGLE_DRIVE_API_KEY ou
     equivalentes) em server functions, nunca no bundle cliente.
   - Componente consome via RPC tipada.

R8. PARSE XLSX
   - `cellDates: true` na leitura.
   - Datas serializadas como `YYYY-MM-DD` antes de devolver ao cliente
     (consumir com `parseLocalDate`).
   - Números: forçar tipo numérico, limpar separadores BR ("," → ".")
     quando aplicável; ignorar células com texto sujo.

ESTRUTURA DO PROMPT B (gere nessa ordem):

1. STACK + ARQUIVOS CONECTADOS
   - 2-3 linhas: React+TS+Tailwind+shadcn+Recharts+Lovable Cloud
   - Nomes exatos dos arquivos + qual seção cada um alimenta
   - Listar abas relevantes de cada um

2. ARQUITETURA DA APP
   - Sidebar fixa com itens das seções identificadas (mín. 2)
   - "Configurações" sutil só pra ver status da conexão
   - Cada seção: KPI cards no topo (grid 4-5) + 2-3 gráficos +
     1 tabela analítica embaixo
   - Filtros globais no header (período + 1-2 dimensões da planilha)
   - Visual: dark mode, OKLCH azul + violeta + mint, Inter Tight + Inter
   - Mobile: sidebar vira drawer, grids viram coluna única

3. KPIS POR SEÇÃO
   - Listar OS KPIs EXATOS da tabela mestra produzida nesta conversa
   - Para cada KPI: nome · fórmula com coluna específica · formato
     (R$ X,XXM · XX% · etc) · em qual componente vai
   - Variação MoM/YoY com seta verde/vermelha
   - Bordas semânticas em KPIs em deterioração ≤ -5% MoM

4. DADOS — LEITURA DIRETA
   - Server function única `getSheetData(sheetName, range)` que usa
     conector nativo Sheets do Lovable
   - Aplicar TODAS as regras R1-R8 acima no domínio (lib/calc.ts)
   - Frontend chama via React Query com staleTime 60s + auto-refetch
   - Botão "Atualizar" em cada seção dispara refetch manual
   - Última atualização visível no header ("há X segundos")
   - SEM banco intermediário, SEM upsert, SEM watch channel

5. ESTADOS VISUAIS
   - Loading: Skeleton em cada card e gráfico
   - Empty: ícone Inbox + "Sem dados para esse filtro/período"
   - Erro de leitura: banner amarelo no topo + retry automático
   - Stale: banner azul claro "Mostrando dados de [período]"
     quando fallback de período (R3) for ativado

6. ENTREGÁVEL FINAL
   - Login funcional · seções POPULADAS com dado real ·
     filtros operando · auto-refresh funcionando ·
     mobile responsivo · zero ação manual necessária ·
     R1-R8 todos implementados

DEVOLVA: apenas o texto do Prompt B, em português. Sem comentário
antes ou depois. Sem perguntas. Sem checklist de aprovação. Sem
"confirme o OAuth strategy". Sem cronograma. Pronto pra colar.

Antes de qualquer construção, faça SOMENTE isto:

1. Ative os CONECTORES NATIVOS do Lovable: Google Drive + Google Sheets.
   NÃO construa fluxo OAuth próprio. NÃO use Service Account JSON.
   NÃO use Supabase externo — use Lovable Cloud (banco interno).

2. Após conectar, liste os arquivos do meu Drive e identifique os DOIS
   que vou usar:
   - Planilha de vendas — nome exato: [NOME EXATO DO SEU ARQUIVO DE VENDAS].xlsx
   - Planilha financeira — nome exato: [NOME EXATO DO SEU ARQUIVO FINANCEIRO].xlsx

3. Confirme acesso a cada arquivo. Para cada um, mostre:
   - Nome exato encontrado no Drive
   - Data da última modificação
   - Número de abas e nome de cada aba

4. NÃO construa interface, schema de banco ou lógica de sincronização
   ainda. Só responda confirmando os dois arquivos conectados.

Resposta esperada (formato):
"Conectado.
- [nome-vendas].xlsx · modificado em [data] · N abas: [lista]
- [nome-financeiro].xlsx · modificado em [data] · N abas: [lista]
Pronto para receber o prompt de arquitetura."

Quando eu mandar o próximo prompt, ele vai conter a arquitetura completa.
Construa em cima desses arquivos JÁ CONECTADOS, sem onboarding manual
de Spreadsheet ID nem campo de Service Account.

MVP do dashboard aprovado. Agora vamos evoluir essa MESMA aplicação para um ERP
enxuto. Reaproveite TODA a arquitetura, conexões e tabelas do Lovable Cloud já
criadas — não recrie nada.

Adicione 3 módulos novos ao sidebar (abaixo de Vendas e Financeiro):

1. OPERAÇÃO COMERCIAL
   - Tela "Novo Pedido": form com cliente (autocomplete da tabela Clientes já
     existente) + linhas de produto + cálculo automático subtotal/desconto/total/margem
   - Lista de pedidos com filtro por status (Rascunho / Faturado / Cancelado)
   - Botão "Faturar" muda status e grava no Lovable Cloud
   - Vendedor só vê próprios pedidos

2. ESTOQUE
   - Tabela SKU · descrição · saldo atual · ponto de pedido · status (verde/laranja/vermelho)
   - SKUs abaixo do ponto de pedido em vermelho com botão "Sugerir compra"
   - Sugestão agrupa por fornecedor e cria rascunho de OC

3. FINANCEIRO OPERACIONAL
   - Tela Contas a Receber: lista com aging colorido (em dia / 30 / 60 / 90 / +90)
   - Botão "Lembrete" abre modal com texto pronto pra enviar
   - Conciliação semi-automática (upload OFX/CSV → tenta bater com títulos)

REUSO:
- Tabelas do Lovable Cloud já criadas para os dashboards
- Mesma autenticação Google
- Mesma paleta + tipografia
- Adicione tabelas novas APENAS para o que ainda não existe

Devolva o app rodando com os 3 módulos novos visíveis no sidebar.
Não toque nas seções Vendas e Financeiro originais — elas continuam como
dashboards de leitura. Os módulos novos são a camada operacional.