# 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.