Implementa o MVP do Adaptador de Planilhas no Elo Pro.

O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas.

Co-authored-by: Cursor <cursoragent@cursor.com>

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

@@ -0,0 +1,46 @@
+# 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
+
+```mermaid
+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.