docs/HANDOFF_E_TESTES.md consolida os dois epicos:
- estado atual (branches, banco local, o que falta em cada um)
- TODOS os riscos (3 criticos, 6 importantes, 5 menores)
- passo a passo de teste local (0..7) cobrindo schema-per-tenant + freemium
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
docs/DEPLOY_SCHEMA_PER_TENANT.md — pre-requisito do freemium. Cutover em fases:
- estrategia copia-nao-move (public + schemas coexistem ate o DROP)
- Risco #1 hosted: exposicao dinamica de schemas no PostgREST (ALTER ROLE
authenticator) + fallback Exposed schemas no dashboard
- Fase A migrations aditivas / B manual privilegiados / C pgrst dinamico (testar
cedo) / D migracao de dados (janela) / E frontend+edge / F smoke+soak /
G F6.3 DROP (gated, irreversivel)
- rollback por fase (botao de panico = redeploy do codigo antigo ate o DROP)
- freemium pode entrar apos as Fases A-F, sem depender do DROP
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- edge function send-welcome-email: e-mail de boas-vindas ao DONO do tenant
recem-provisionado (destinatario do JWT, SMTP global/sistema, defaults Mailpit).
Best-effort, disparada fire-and-forget no OnboardingPage so no provisionamento novo.
- vitrine: seed plan_public + bullets dos planos free (cartao "Gratis"); Landingpage
passa a mostrar "Gratis para sempre" (isFreePlan) em vez de "—".
- build OK
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- SaasAppConfigPage + rota /saas/app-config + menu "Config / Bloqueios"
- gerencia blacklist (email/slug, add/remove) e o root_redirect
- build OK
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- SaasUsuariosPage + rota /saas/usuarios + menu: 1 linha/tenant com dono/slug/
email/plano, realce verde + selo "Novo" 24h (saas_list_account_owners)
- esqueci-email no Login: dialog que chama a edge recover-access (acha dono por
slug, manda magic link, mostra so dica mascarada). Edge function recover-access.
- root_redirect: guard roteia "/" do visitante nao-logado pra /lp ou /auth/login
conforme get_root_redirect (cache TTL 5min)
- pegadinha #4: notificationStore.reset() no logout (limpa sino ao trocar user)
- build OK
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- saas_list_account_owners(): 1 linha/tenant com dono (master), nome/slug/email/
plano + selo "novo" (24h). Dev-only (is_saas_admin), cast text p/ varchar.
- notify_all_devs() insere em notifications_sistema p/ cada saas_admin
- trigger AFTER INSERT/UPDATE OF status em subscriptions avisa os devs com
deeplink /saas/usuarios
- testado em ROLLBACK: lista + notify ao inserir subscription
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Signup.vue reescrito: coleta tipo de conta + nome + nome do negocio + slug
(disponibilidade ao vivo via slug_disponivel) + email/senha; grava tudo no
raw_user_meta_data do signUp; PEGADINHA #2: signOut scope:local se nao veio
sessao + tela "confirme seu e-mail". Removido provisionamento/intent inline.
- OnboardingPage.vue (PEGADINHA #3): 1o login chama auto_provision_free_tenant
+ processar_pos_signup; resolve estados provisionando/slug-colidiu/erro;
redireciona pro painel conforme kind.
- guard: logado-sem-tenant (nao saas_admin) -> /onboarding em vez de /login
- rota /onboarding (meta.public; a pagina exige sessao)
NOTA: supabase/config.toml e gitignored — enable_confirmations=true foi setado
local (ativa no proximo restart do stack). No hosted, ligar em Auth>Email>Confirm.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Regressao do schema-per-tenant: o trigger de auditoria deriva tenant_id via
tenant_id_for_schema(TG_TABLE_SCHEMA), que retorna NULL para public.* (ex.:
tenant_members) -> violava audit_logs.tenant_id NOT NULL -> QUALQUER novo
membership (provisionamento, aceite de convite) falhava.
Fix: quando o schema nao resolve tenant, cai no tenant_id da propria linha;
se ainda NULL, nao audita mas nunca quebra a operacao.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- utils/planLimit.js: parsePlanLimitError + maybeShowPlanLimitToast (traduz
PLAN_LIMIT_REACHED em toast amigavel com CTA via grupo system-alerts)
- AppTopbar: botao "Upgrade PRO" quando plano ativo e gratuito (reusa
resolveActiveSubscriptionContext; plan_key nos selects)
- ligado nos 3 pontos de criacao de paciente: PatientsCadastroPage,
CadastrosRecebidos (intake), ComponentCadastroRapido (quick-create)
- build OK
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- therapist_free ganha max_patients=20 (clinic_free ja tinha 30)
- trigger BEFORE INSERT em patients le plan_features.limits em runtime,
resolve tenant por TG_TABLE_SCHEMA, plano ativo (clinica via tenant_id +
pessoal via owner user_id), conta vivos (status<>Arquivado) e da RAISE
PLAN_LIMIT_REACHED|patients|<n>
- helpers tenant_active_plan_id / plan_feature_limit (globais, sobrevivem F6.3)
- wiring: tenants novos ganham via trg_attach_business_triggers; 9 existentes backfill
- testado: clinic_free bloqueia em 30, therapist_free em 20, PRO ilimitado (rollback)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
manual/f6_3_drop_public_tenant_tables.supabase_admin.sql — ponto de nao-retorno,
revisar antes de aplicar:
- pre-flight assert (tenants=schemas, 78 tabelas, 6 anon NAO no template)
- 2 FKs public->tenant viram coluna solta (document_share_links.documento_id,
whatsapp_credits_transactions.conversation_message_id)
- dropa 9 views public (6 recriadas por schema + 2 dead + v_twilio item#1)
- DROP CASCADE das 78 tabelas (derivado de _tenant_template; dados ja nos schemas)
- limpa financial_records_inject_tenant (obsoleto)
ITENS EM ABERTO verificados (16 reads FE remanescentes, TODOS na superficie
SaaS-admin ja flagada na F3): SaasFeriadosPage (feriados defaults),
SaasNotificationTemplatesPage (templates default), SaasWhatsappPage +
v_twilio_whatsapp_overview/getAllChannels (whatsapp admin cross-tenant).
Resolver (apontar pra _tenant_template ou fan-out por schema) ANTES do DROP.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- attach_agnostic_triggers reescrito SELF-CONTAINED (dirigido por colunas: set_
updated_at em toda tabela com updated_at + prevent_* em patient_groups). Nao
le mais de public -> sobrevive ao DROP da F6.3.
- trigger AFTER INSERT em tenant_schemas (trg_attach_business_triggers) dispara
os 3 attach (agnostic + schema_aware + notif) pro schema novo. clone_tenant_
template nao precisou ser tocado (ele insere em tenant_schemas). GRANT EXECUTE
dos attach pra postgres/service_role.
- provision_account_tenant: clone ANTES do seed (seed_determined_commitments e
no-op se schema nao existe; precisa do schema criado primeiro)
Smoke: tenant novo nasce com 84 triggers automaticamente (vs 81 nos existentes,
que sao mais que suficientes). Provision order corrigida.
App agora testavel: dados nos schemas (F6.1) + funcoes/triggers/RPCs roteiam
(F6.2). Falta so F6.3 DROP (com OK + app testado).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DB (supabase_admin, manual/f6_2e_cron_rpcs.supabase_admin.sql):
- E2 (varrem TODOS os tenants via loop FROM tenant_schemas): cleanup/unstick_
notification_queue, sync_overdue_financial_records (EXECUTE format por schema),
populate_notification_queue (set_config search_path por tenant; profiles global)
- E1 (per-tenant via service_role): novo helper _tenant_schema_unchecked (sem
is_tenant_member — service_role nao e membro; REVOKE de anon/authenticated).
sla_open_breach, sla_mark_notified(+p_tenant_id), whatsapp_heartbeat_open_
incident/mark_notified/resolve(+p_tenant_id). convert_abandoned_intake_to_lead
resolve tenant internamente (intake public/F1b -> writes no schema).
first_response_stats/_runs: _tenant_route (user-facing, frontend ja passa
p_tenant_id); _first_response_runs computa thread_key (coluna nao existe).
- REVOKE das RPCs de servico de anon/authenticated; GRANT service_role
Edge: whatsapp-heartbeat-check (tdb.rpc->admin.rpc + p_tenant_id nos heartbeat
RPCs), conversation-sla-check (sla_mark_notified + p_tenant_id).
Gotchas: (1) service_role nao e tenant_member -> helper unchecked + REVOKE;
(2) conversation_messages nao tem coluna thread_key (computar); (3) DROP+CREATE
de nova assinatura precisa dropar ambas p/ idempotencia.
Smoke: E2 sync_overdue 13 across tenants; E1 sla_open_breach roteia; first_
response_stats user OK.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Aplicado como supabase_admin (trigger functions sao owned por supabase_admin).
14 funcoes reescritas pra operar no schema do TG_TABLE_SCHEMA (set_config
search_path dinamico + tenant_id_for_schema p/ tabelas globais audit_logs):
log_audit_change, trg_fn_patient_status_history/timeline/risco,
auto_create_financial_record_from_session, fn_sla_resolve_on_outbound,
fn_clinical_note_version, fn_document_signature_timeline,
fn_documents_timeline_insert, sync_legacy_email/phone_fields,
fn_agenda_regras_semanais_no_overlap, patients_validate_member_consistency.
sync_busy_mirror_agenda_eventos: cross-tenant via tenant_schema_for +
EXECUTE format (espelha "Ocupado" nos schemas das clinicas).
financial_records_inject_tenant: obsoleto, nao anexado nos schemas.
Detach dos 14 schema-aware das tabelas tenant em public (quebrariam la);
attach_schema_aware_triggers recria 22 triggers/schema (defs reais, tenant_id
removido de WHEN/UPDATE OF). agenda_cfg_sync e trg_fn_financial_records_auto_
overdue (agnosticos) ficam em public E nos schemas.
Smoke: sessao->realizado cria financial_record (R$250) no schema + marca billed;
audit roteia tenant_id correto; patient status muda -> timeline no schema.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
attach_agnostic_triggers(schema) recria nos schemas os triggers de public cuja
funcao e provadamente schema-agnostica (so mexe em NEW/OLD): familia updated_at
(8: set_updated_at, fn_clinical_notes_updated_at, set_insurance_plans/medicos/
services_updated_at, set_updated_at_recurrence, update_payment_settings/
professional_pricing_updated_at) + prevent_promoting_to_system +
prevent_system_group_changes. Backfill dos 9 (54 triggers/schema). Smoke:
set_updated_at dispara no schema. Schema-aware vem no Lote B; wiring no clone
no fim da F6.2
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- F6.0 (migration): clone_tenant_template pros 9 tenants existentes (schemas
vazios; dispara trigger F5 -> expostos no PostgREST)
- F6.1 (manual supabase_admin): copia dados public -> schemas com
session_replication_role=replica (desabilita FK check, so supabase_admin).
Tabelas com tenant_id por filtro; 3 filhas sem tenant_id (commitment_services,
insurance_plan_services, recurrence_rule_services) por JOIN no pai; exclui
colunas GENERATED (net_amount, margin_brl); reset de 4 sequences; ON CONFLICT
DO NOTHING (idempotente). Dados continuam em public (DROP so na F6.3)
- Verificado: contagens public vs schemas batem (35 patients, 37 eventos,
355 mensagens, 54 financeiro...); seeds default replicados por schema
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- manual/f5_pgrst_refresh_schemas.supabase_admin.sql: refresh_pgrst_schemas()
(owned supabase_admin, postgres nao e superuser neste stack) seta
pgrst.db_schemas in-database na role authenticator a partir de tenant_schemas
+ NOTIFY pgrst reload config/schema. Expoe/retira schema SEM restart; GUC
persiste entre stop/start
- migration 20260613000002: trigger em tenant_schemas dispara o refresh a cada
clone/drop (clone/drop nao precisam ser tocados)
- config.toml: baseline public,graphql_public + comentario explicando que a
config in-db supersede em runtime
- E2E testado via HTTP: clone -> pgrst.db_schemas inclui tenant_x -> REST
Accept-Profile retorna 200 (vs 406 schema inexistente); drop -> volta 406.
Sem restart de container
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fluxos anon identificam tenant por token/slug e nao resolvem o schema fisico.
Decisao (opcao C): manter em public com RLS por token. Volta a global:
patient_intake_requests, patient_invites, patient_invite_attempts,
document_share_links, agendador_configuracoes, agendador_solicitacoes.
- migration 20260613000001_f1b: remove as 6 do _tenant_template (template v2,
78 tabelas). Smoke: clone gera 78, zero tabelas anon no schema, drop limpo
- frontend: 38 cadeias em 14 arquivos revertidas tenantDb().from() ->
supabase.from() com tenant_id/owner_id restaurado (via comparacao com main)
- edge: convert-abandoned-intakes restaurada do main (SELECT global)
- save-intake-progress: ja usava public, sem mudanca
- doc F0 atualizado: 78 tenant + 59 global
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- _shared/tenant.ts: helper (adminClient, tenantDbForId, schemaForTenant,
listTenantSchemas, resolveTenantByChannel, tenantSchemaName)
- _shared/whatsapp-hooks.ts: hooks de tabela tenant recebem tdb; RPCs de
credito (deduct/add_whatsapp_credits) e tenant_members seguem em supa+p_tenant_id
- inbound (twilio/evolution): tenant_id da URL -> tdb pra conversation_messages
e notification_channels
- crons de fila (process-notification/email/sms/whatsapp-queue): varrem
listTenantSchemas e drenam a fila de cada schema (Q3: filas sao per-tenant);
modo single-tenant se body.tenant_id vier
- crons reminders/checks (send-session-reminders, conversation-sla-check,
whatsapp-heartbeat-check, convert-abandoned-intakes, sync-email-templates):
loop por tenant
- routing por tenant_id (send-whatsapp-message, send-session-reminder-manual,
twilio-provision, de/reactivate-channel, twilio-webhook): tenantDbForId;
channel-actions sem tenant_id varrem schemas por channel_id
- asaas-*: tenant_id do body -> tdb; asaas-webhook fica global (whatsapp_credit_purchases)
- notification-webhook (Meta): resolve tenant via channel_routing por phone_number_id,
fan-out por message_id quando nao resolve
- caller send-session-reminder-manual passa tenant_id (evento vive no schema)
Pendente: save-intake-progress e fluxos anon por token (decisao de roteamento)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Leonardo