Duas lacunas impediam qualquer uso de homologação. Primeira: sem SSO do Elo
Pro e sem o login local, não havia como entrar. Segunda, mais grave: nada no
repositório gravava o cookie `elo_pro_workspace_id`, que era lido como origem
do workspace ativo — mesmo com sessão válida a resposta era sempre "sem
workspace".
- `identity-provider.ts` define o contrato de identidade. Trocar o Supabase de
homologação pelo SSO do Elo Pro passa a ser acrescentar uma implementação;
nenhum outro arquivo conhece o mecanismo.
- `/api/auth/staging/session` autentica com `signInWithPassword` no projeto
Supabase de homologação. Há senha, emitida e validada pelo Supabase, e o
Adaptador continua sem tabela de usuário, senha ou sessão própria.
- O login local sem senha existe apenas em `ADAPTER_ENV=development`, e não
por configuração: fora de development o provedor nem entra na lista.
- `workspace.ts` resolve o workspace por associação real lida sob RLS. O
cookie passa a ser preferência, não prova: aceitá-lo como autorização
transformava um valor editável pelo cliente em credencial.
- `/api/auth/workspace` grava a preferência só depois de confirmar a
associação, e `/selecionar-workspace` existe para quem participa de mais de
um workspace.
- Rate limiting por usuário e bucket nas rotas do módulo, com Retry-After.
Upload e processamento custam muito mais que leitura.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>