- 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>
- 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>
Leonardo