camilafagundesandCursor
6e23f1533b
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>
47 lines
2.0 KiB
Markdown
47 lines
2.0 KiB
Markdown
# 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.
|