adaptador-planilhas/docs/spreadsheet-adapter/00-repo-integration-audit.md

Auditoria de integração — Adaptador de Planilhas

Data da inspeção: 2026-10-02. O diretório de trabalho era um repositório Git vazio, sem aplicação Elo Pro.

O que não existia para reutilizar

• App Router, clientes Supabase, middleware e logout
• Resolução de workspace_id e workspace_members
• Papéis, RLS, feature flags, design system, TanStack Query, Sentry, Redis, audit log e storage
• Padrão de Route Handlers, Vitest, CI e migrations

Diferença em relação ao master context

O contexto pede para encaixar o módulo no Elo Pro existente. Como não havia código de plataforma, este repositório implementa o Adaptador como aplicação Next.js pronta para compartilhar a mesma identidade, com um shim SQL das tabelas profiles, workspaces, workspace_members, workspace_module_flags e audit_log. Essas tabelas não têm senha, hash ou refresh token. Em um monorepo Elo Pro real, a migration 0001_platform_shim.sql não deve recriar o que já existe (create table if not exists).

Decisões já fechadas pelo escopo V3

Identidade única via Supabase Auth, tenant workspace_id, RLS, limites do MVP, mapeamento manual 1:1, prévia obrigatória, modelo imutável, flag de módulo e papéis owner/admin/gestor/agent.

OPEN DECISIONS

Registradas em docs/decisions/:

1. Object storage definitivo
2. Topologia de cookie/login entre hosts
3. Job runner durável
4. TTL de temporários
5. Biblioteca XLSX de produção
6. Exclusão física versus soft delete

Arquitetura

flowchart LR
  browser[Browser Elo Pro] --> session[Sessão Supabase]
  session --> app[Next.js Adaptador]
  app --> domain[Domínio de planilhas]
  app --> pg[(PostgreSQL + RLS)]
  app --> redis[(Redis lock e progresso)]
  app --> storage[Storage privado]
  app --> sentry[Sentry sem células]

Fases

Fundação e flag, autorização, schema, shell visual, modelos, fontes, mapeamento, jobs, Redis, auditoria/Sentry, testes, operação e revisão de gaps. A implementação seguiu essa ordem no mesmo repositório.