ConnectCond — Arquitetura Oficial RBAC Enterprise

---

---

Sumário

1. Objetivo da Arquitetura
2. Visão Geral da Arquitetura
3. Estrutura das Entidades
4. Relacionamento entre Entidades
5. Organização do Banco de Dados
6. Matriz Oficial de Roles
7. Matriz Mestre de Permissões
8. Segmentação por Perfil
9. Fluxo de Resolução das Permissões
10. Fluxo de Convites
11. Landing Page
12. Tela "Convidar Colaborador"
13. Regras de Governança
14. Segurança
15. Compatibilidade
16. Fluxo Completo da Arquitetura
17. Banco de Dados
18. Exemplos Práticos
19. Histórico da Arquitetura
20. Conclusão

---

1. Objetivo da Arquitetura

Por que foi criada

A ConnectCond opera como uma plataforma SaaS multi-tenant onde Administradoras, Condomínios, Prestadores de Serviço e Fornecedores coexistem em um mesmo ambiente. Cada perfil de organização possui necessidades de acesso radicalmente diferentes, e dentro de cada organização, colaboradores precisam de níveis distintos de controle.

A arquitetura RBAC Enterprise foi criada para resolver três problemas fundamentais:

1. Controle granular de acesso — Nem todo colaborador precisa de todas as permissões. Um síndico precisa aprovar cotações; um membro do conselho precisa apenas visualizar.
2. Separação entre função profissional e perfil de acesso — Um "Síndico" (função profissional) pode ter perfil de acesso "Gestor" ou "Consulta" — são conceitos independentes.
3. Governança centralizada — Apenas o Proprietário da organização pode personalizar permissões, garantindo que nenhum colaborador — mesmo com cargo de gestão — escalone privilégios além do autorizado.

Princípios de segurança adotados

Benefícios para a ConnectCond

• Onboarding seguro: Novos colaboradores recevem exatamente o acesso necessário, nem mais nem menos.
• Flexibilidade: O Proprietário pode ajustar permissões individualmente sem criar novos Perfis de Acesso.
• Conformidade: Auditoria completa para regulamentações e revisões internas.
• Escalabilidade: A mesma arquitetura atende desde um condomínio com 2 colaboradores até uma administradora com centenas.

---

2. Visão Geral da Arquitetura

Diagrama de Fluxo de Resolução

┌─────────────────────────────────────────────────────────────────┐
│                    ORGANIZAÇÃO (Tenant)                          │
│                                                                  │
│  ┌──────────────────┐                                           │
│  │ Perfil da Org    │  administration | condominium |             │
│  │ (organization_   │  provider | supplier                        │
│  │  type)           │                                             │
│  └────────┬─────────┘                                            │
│           │                                                      │
│           ▼                                                      │
│  ┌──────────────────┐                                           │
│  │ Role              │  Proprietário | Gestor |                  │
│  │ (Perfil de        │  Colaborador | Consulta                   │
│  │  Acesso)          │                                             │
│  │                   │  base_permissions = [                       │
│  │                   │    "quotations:create",                    │
│  │                   │    "proposals:approve",                   │
│  │                   │    ...                                     │
│  │                   │  ]                                         │
│  └────────┬─────────┘                                            │
│           │                                                      │
│           ▼                                                      │
│  ┌──────────────────┐                                           │
│  │ Permissões Base  │  Conjunto de permissões atômicas           │
│  │ (base_perms)     │  definidas pelo Perfil de Acesso           │
│  └────────┬─────────┘                                            │
│           │                                                      │
│           ▼                                                      │
│  ┌──────────────────┐                                           │
│  │ MemberPermission │  Overrides personalizados pelo             │
│  │ (Overrides)      │  Proprietário:                             │
│  │                   │                                            │
│  │                   │  ADD    → adiciona permissão extra         │
│  │                   │  REMOVE → subtrai permissão da base        │
│  └────────┬─────────┘                                            │
│           │                                                      │
│           ▼                                                      │
│  ┌──────────────────┐                                           │
│  │ PERMISSÕES       │  FÓRMULA OFICIAL:                          │
│  │ FINAIS            │                                            │
│  │                   │  base_permissions                          │
│  │                   │    + ADD(MemberPermission)                 │
│  │                   │    - REMOVE(MemberPermission)              │
│  │                   │    = Permissões Finais                      │
│  └────────┬─────────┘                                            │
│           │                                                      │
│           ▼                                                      │
│  ┌──────────────────┐                                           │
│  │ APLICAÇÃO        │  Frontend (usePermissions.can())            │
│  │                   │  Backend (orgContextResolver.hasPermission)│
│  └──────────────────┘                                           │
└─────────────────────────────────────────────────────────────────┘

Explicação em linguagem simples

Imagine que cada organização na ConnectCond é como um prédio de escritórios:

1. Perfil da Organização define que tipo de empresa é (Administradora, Condomínio, Prestador ou Fornecedor) — como o tipo de negócio do prédio.
2. Perfil de Acesso (Role) é como o cargo do funcionário: Proprietário (dono do escritório), Gestor (gerente), Colaborador (funcionário ativo) ou Consulta (visitante com acesso só para leitura).
3. Permissões Base são as chaves que cada cargo recebe por padrão — o Proprietário tem a chave-mestra, o Consulta só tem chaves de visualização.
4. MemberPermission (Overrides) são chaves extras que o Proprietário entrega ou retirada individualmente — como dar uma chave específica para um Colaborador acessar a sala de reuniões, ou retirar a chave do cofre de um Gestor.
5. Permissões Finais são todas as chaves que a pessoa realmente possui no final — o conjunto que de fato libera ou bloqueia cada porta do sistema.

---

3. Estrutura das Entidades

3.1 Role (Perfil de Acesso)

Finalidade: Define os 4 Perfis de Acesso oficiais da plataforma, cada um com um conjunto base de permissões atômicas. Existem 16 registros no total (4 Perfis × 4 tipos de organização).

Relacionamento: Cada Role pertence a um organization_type e é referenciada por OrganizationMember.role_id.

Campo de compatibilidade: permissions (array) — mantido em sincronia com base_permissions para código legado que ainda referencia role.permissions. Ambos são atualizados juntos pelo seedPermissions.

---

3.2 Permission (Permissão Atômica)

Finalidade: Catálogo mestre de todas as permissões atômicas da plataforma, organizadas por módulo e segmentadas por tipo de organização.

Relacionamento: Referenciada por Role.base_permissions (por chave) e por MemberPermission.permission_key.

Módulos disponíveis: dashboard, team, solicitations, quotations, proposals, orders, contracts, documents, finance, chat, ai, subscription, settings, integrations, calendar, reports, erp, whatsapp, reviews, condominiums, suppliers, providers, notifications.

---

3.3 MemberPermission (Override Personalizado)

Finalidade: Armazena as personalizações individuais de permissão aplicadas pelo Proprietário a um colaborador específico, além (ou aquém) do que seu Perfil de Acesso define.

Relacionamento: Pertence a um OrganizationMember (via member_id) e a uma organization_id.

---

3.4 OrganizationMember (Vínculo Colaborador ↔ Organização)

Finalidade: Entidade central que vincula um usuário autenticado a uma organização, definindo seu Perfil de Acesso e status dentro daquela organização.

Relacionamento: Referencia Role (via role_id e role), User (via user_id), e é pai de MemberPermission.

Estratégia Dual-Field: role (string) e role_id (UUID) são mantidos em sincronia automática. role_id é a fonte oficial da verdade; role (string) é mantido para compatibilidade com as regras RLS existentes que comparam por nome.

professional_function vs role: A função profissional (professional_function) é estritamente informativa — exibida na UI, nunca usada em autorização ou RLS. O Perfil de Acesso (role/role_id) é o que determina permissões.

---

3.5 AuditLog (Trilha de Auditoria)

Finalidade: Registra toda ação relevante executada no sistema, com foco em alterações de permissão, convites e mudanças de cargo.

Relacionamento: Referencia User (via user_id e user_email) e qualquer entidade afetada (via entity_name + entity_id).

Valores de action: create, update, delete, login, logout, export, view, approve, reject.

RLS do AuditLog: Apenas Super Admins (role: "admin") podem ler, atualizar ou excluir registros de auditoria. A criação é aberta para que funções de backend possam registrar eventos.

---

4. Relacionamento entre Entidades

Diagrama de Relacionamento (DER)

    ┌──────────────────┐
    │      Role        │
    │──────────────────│
    │ id               │
    │ name             │
    │ organization_type│
    │ base_permissions │
    │ is_system        │
    │ is_default       │
    └────────┬─────────┘
             │
             │ role_id (UUID)
             │ role (string, compatibilidade)
             ▼
    ┌──────────────────┐         ┌──────────────────────┐
    │ OrganizationMember│─────────│ MemberPermission     │
    │──────────────────│  1 : N  │──────────────────────│
    │ id               │────────▶│ id                   │
    │ user_id          │         │ member_id ───────────┘
    │ organization_id  │         │ organization_id
    │ organization_type│         │ permission_key
    │ role             │         │ operation (ADD/REMOVE)
    │ role_id          │         │ granted_by
    │ status           │         │ granted_at
    │ professional_    │         └──────────────────────┘
    │   function       │                  │
    │ invited_by       │                  │ permission_key
    │ accepted_at      │                  │ (referência por chave)
    └────────┬─────────┘                  ▼
             │                    ┌──────────────────────┐
             │ user_id            │ Permission           │
             │ (UUID)             │──────────────────────│
             ▼                    │ id                   │
    ┌──────────────────┐         │ key (único)         │
    │ User (Base44)    │         │ module              │
    │──────────────────│         │ description          │
    │ id               │         │ organization_types   │
    │ email             │         └──────────────────────┘
    │ role (platform)  │
    │ organization_ids │
    └──────────────────┘
             │
             │ Toda ação relevante
             ▼
    ┌──────────────────┐
    │ AuditLog         │
    │──────────────────│
    │ id               │
    │ user_id          │
    │ user_email       │
    │ action           │
    │ entity_name      │
    │ entity_id        │
    │ description      │
    │ metadata         │
    └──────────────────┘

Explicação dos Relacionamentos

---

5. Organização do Banco de Dados

Onde cada informação fica armazenada

┌─────────────────────────────────────────────────────────────────┐
│                    BANCO DE DADOS BASE44                         │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela: Role        │  → Armazena os 16 Perfis de Acesso     │
│  │                      │    (4 roles × 4 org_types)             │
│  │  • base_permissions  │    e suas permissões base              │
│  └─────────────────────┘                                        │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela: Permission  │  → Armazena o catálogo de 52           │
│  │                      │    permissões atômicas, segmentadas    │
│  │  • key (único)       │    por organization_types              │
│  │  • organization_types│                                       │
│  └─────────────────────┘                                        │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela:             │  → Armazena os overrides               │
│  │  MemberPermission   │    personalizados (ADD/REMOVE)          │
│  │                      │    aplicados a cada colaborador        │
│  │  • member_id         │                                       │
│  │  • operation         │                                       │
│  └─────────────────────┘                                        │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela:             │  → Armazena o VÍNCULO do usuário       │
│  │  OrganizationMember │    com cada organização, incluindo:    │
│  │                      │                                       │
│  │  • role (string)     │  → Compatibilidade RLS                 │
│  │  • role_id (UUID)    │  → Fonte oficial da verdade            │
│  │  • professional_     │  → Informativo (sem autorização)       │
│  │    function          │                                       │
│  │  • status            │  → pending | active | blocked          │
│  └─────────────────────┘                                        │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela: AuditLog    │  → Armazena a trilha completa de       │
│  │                      │    auditoria de todas as ações         │
│  │  • action            │    relevantes (permissões, convites)   │
│  │  • entity_name       │                                       │
│  │  • metadata          │                                       │
│  └─────────────────────┘                                        │
│                                                                  │
│  ┌─────────────────────┐                                        │
│  │ Tabela: User        │  → Identidade autenticada (Base44)     │
│  │  (sistema)          │                                       │
│  │  • organization_ids  │  → Cache sincronizado (RLS support)   │
│  │  • role (platform)   │  → admin | condominio | prestador...  │
│  └─────────────────────┘                                        │
└─────────────────────────────────────────────────────────────────┘

Campos de Compatibilidade

Os seguintes campos existem apenas para compatibilidade e NÃO são a fonte da verdade:

Regra arquitetural: Toda nova implementação deve usar a fonte oficial. Os campos de compatibilidade são mantidos em sincronia automática e nunca devem ser editados diretamente.

---

6. Matriz Oficial de Roles

Os 4 Perfis de Acesso Oficiais

Permissões de Segurança Exclusivas do Proprietário

As seguintes permissões são sempre excluídas dos Perfis Gestor, Colaborador e Consulta (apenas Proprietário as possui por padrão):

Nota: O Proprietário pode conceder essas permissões individualmente via MemberPermission (ADD), mas por padrão apenas o Proprietário as possui.

---

7. Matriz Mestre de Permissões

Catálogo Completo (52 Permissões Atômicas)

Módulo: Dashboard

Módulo: Equipe (Team)

Módulo: Solicitações (Solicitations)

Módulo: Cotações (Quotations)

Módulo: Propostas (Proposals)

Módulo: Pedidos (Orders)

Módulo: Contratos (Contracts)

Módulo: Documentos (Documents)

Módulo: Financeiro (Finance)

Módulo: Chat

Módulo: IA

Módulo: Assinatura (Subscription)

Módulo: Configurações (Settings)

Módulo: Integrações (Integrations)

Módulo: Agenda (Calendar)

Módulo: Relatórios (Reports)

Módulo: ERP

Módulo: WhatsApp

Módulo: Avaliações (Reviews)

Módulo: Condomínios (Administration only)

---

8. Segmentação por Perfil

Cada permissão do catálogo é segmentada por tipo de organização. Abaixo, os módulos disponíveis para cada Perfil da Organização:

Administradora

┌──────────────────────────────────────────┐
│           ADMINISTRADORA                  │
│                                           │
│  Módulos disponíveis:                     │
│  ├── dashboard        (view)              │
│  ├── team             (view, invite,      │
│  │                     manage, remove)     │
│  ├── solicitations    (view, create,      │
│  │                     edit, cancel)       │
│  ├── quotations       (view, create,      │
│  │                     edit, approve,      │
│  │                     cancel)             │
│  ├── proposals        (view, approve,      │
│  │                     reject)             │
│  ├── contracts        (view, sign)         │
│  ├── documents        (view, upload,       │
│  │                     delete)             │
│  ├── finance          (view, create,       │
│  │                     approve)            │
│  ├── chat             (view, send)         │
│  ├── ai               (view, use)          │
│  ├── subscription     (view, manage*)      │
│  ├── settings         (view, edit*)        │
│  ├── integrations     (view, configure*)   │
│  ├── calendar         (view, manage)       │
│  ├── reports          (view, export)       │
│  ├── erp              (view, sync*)        │
│  ├── whatsapp         (view, configure*)   │
│  ├── reviews          (create)             │
│  └── condominiums     (view, manage)       │
│                                           │
│  * Apenas Proprietário                    │
└──────────────────────────────────────────┘

Condomínio

┌──────────────────────────────────────────┐
│             CONDOMÍNIO                    │
│                                           │
│  Módulos disponíveis:                     │
│  ├── dashboard        (view)              │
│  ├── team             (view, invite,      │
│  │                     manage, remove)     │
│  ├── solicitations    (view, create,      │
│  │                     edit, cancel)       │
│  ├── quotations       (view, create,      │
│  │                     edit, approve,      │
│  │                     cancel)             │
│  ├── proposals        (view, approve,      │
│  │                     reject)             │
│  ├── contracts        (view, sign)         │
│  ├── documents        (view, upload,       │
│  │                     delete)             │
│  ├── finance          (view, create,       │
│  │                     approve)            │
│  ├── chat             (view, send)         │
│  ├── ai               (view, use)          │
│  ├── subscription     (view, manage*)      │
│  ├── settings         (view, edit*)        │
│  ├── integrations     (view, configure*)   │
│  ├── calendar         (view, manage)       │
│  ├── reports          (view, export)       │
│  ├── erp              (view, sync*)        │
│  ├── whatsapp         (view, configure*)   │
│  └── reviews          (create)             │
│                                           │
│  * Apenas Proprietário                    │
└──────────────────────────────────────────┘

Prestador

┌──────────────────────────────────────────┐
│             PRESTADOR                     │
│                                           │
│  Módulos disponíveis:                     │
│  ├── dashboard        (view)              │
│  ├── team             (view, invite,      │
│  │                     manage, remove)     │
│  ├── quotations       (view)              │
│  ├── proposals        (view, create)       │
│  ├── orders           (view, create,      │
│  │                     edit, approve)      │
│  ├── contracts        (view, manage)       │
│  ├── documents        (view, upload,       │
│  │                     delete)             │
│  ├── finance          (view, create,       │
│  │                     approve)            │
│  ├── chat             (view, send)         │
│  ├── ai               (view, use)          │
│  ├── subscription     (view, manage*)      │
│  ├── settings         (view, edit*)        │
│  ├── integrations     (view, configure*)   │
│  ├── calendar         (view, manage)       │
│  ├── reports          (view, export)       │
│  ├── erp              (view, sync*)        │
│  └── whatsapp         (view, configure*)   │
│                                           │
│  * Apenas Proprietário                    │
│                                           │
│  NOTA: Prestador NÃO tem acesso a:        │
│  - solicitations ( módulo de quem cria)    │
│  - quotations:create/edit/approve/cancel   │
│  - proposals:approve/reject               │
│  - reviews (módulo de quem avalia)         │
│  - condominiums (módulo da administradora) │
└──────────────────────────────────────────┘

Fornecedor

┌──────────────────────────────────────────┐
│             FORNECEDOR                    │
│                                           │
│  Módulos disponíveis:                     │
│  ├── dashboard        (view)              │
│  ├── team             (view, invite,      │
│  │                     manage, remove)     │
│  ├── quotations       (view)              │
│  ├── proposals        (view, create)       │
│  ├── orders           (view, create,      │
│  │                     edit, approve)      │
│  ├── contracts        (view, manage)       │
│  ├── documents        (view, upload,       │
│  │                     delete)             │
│  ├── finance          (view, create,       │
│  │                     approve)            │
│  ├── chat             (view, send)         │
│  ├── ai               (view, use)          │
│  ├── subscription     (view, manage*)      │
│  ├── settings         (view, edit*)        │
│  ├── integrations     (view, configure*)   │
│  ├── calendar         (view, manage)       │
│  ├── reports          (view, export)       │
│  ├── erp              (view, sync*)        │
│  └── whatsapp         (view, configure*)   │
│                                           │
│  * Apenas Proprietário                    │
│                                           │
│  NOTA: Fornecedor NÃO tem acesso a:        │
│  - solicitations                          │
│  - quotations:create/edit/approve/cancel  │
│  - proposals:approve/reject               │
│  - reviews                                │
│  - condominiums                           │
└──────────────────────────────────────────┘

---

9. Fluxo de Resolução das Permissões

Diagrama do Fluxo de Resolução

┌─────────────────────────────────────────────────────────────┐
│                  FLUXO DE RESOLUÇÃO                          │
│                                                              │
│  1. Requisição chega                                         │
│     ├── Frontend: usePermissions(user, orgType, org)        │
│     └── Backend: orgContextResolver.hasPermission(          │
│                  base44, userId, orgId, permissionKey)      │
│                                                              │
│  2. Verificar Super Admin?                                   │
│     ├── User.role === 'admin' → ✅ Todas as permissões     │
│     │                                                         │
│  3. Verificar Proprietário?                                  │
│     ├── OrganizationMember.role === 'Proprietário'           │
│     │   → ✅ Todas as permissões implícitas                  │
│     │                                                         │
│  4. Verificar Owner Legado? (apenas frontend)               │
│     ├── Sem OrganizationMember mas:                          │
│     │   org.manager_email === user.email                     │
│     │   org.created_by_id === user.id                        │
│     │   → ✅ Todas as permissões (compatibilidade)           │
│     │                                                         │
│  5. RESOLVER PERMISSÕES VIA FÓRMULA HÍBRIDA                 │
│     │                                                         │
│     │  5a. Buscar Role (por role_id ou name+org_type)       │
│     │       └── base_permissions = Role.base_permissions     │
│     │                                                          │
│     │  5b. Buscar MemberPermission overrides                │
│     │       └── WHERE member_id = X AND organization_id = Y  │
│     │                                                          │
│     │  5c. APLICAR FÓRMULA:                                  │
│     │       ┌──────────────────────────────┐                 │
│     │       │  Permissões Finais =         │                 │
│     │       │    base_permissions          │                 │
│     │       │      + ADD(overrides)        │                 │
│     │       │      - REMOVE(overrides)     │                 │
│     │       └──────────────────────────────┘                 │
│     │                                                          │
│     │  5d. Verificar se permissionKey ∈ Permissões Finais   │
│     │       ├── Sim → ✅ Permitido                           │
│     │       └── Não → ❌ Negado                              │
│     │                                                         │
│  6. Retornar resultado                                      │
│     ├── Frontend: can('quotations:create') → true/false     │
│     └── Backend: hasPermission(...) → true/false             │
└─────────────────────────────────────────────────────────────┘

Passo a Passo (Explicação Técnica)

No Frontend (src/hooks/usePermissions.js)

// 1. Carrega o vínculo OrganizationMember do usuário na organização
const membership = await base44.entities.OrganizationMember.filter({
  organization_id: orgId, user_id: user.id
});

// 2. Carrega a Role (por role_id primeiro, depois por name)
if (membership?.role_id) {
  const byId = await base44.entities.Role.filter({ id: membership.role_id });
  // ...
}

// 3. Carrega os overrides de MemberPermission
const overrides = await base44.entities.MemberPermission.filter({
  member_id: membership.id, organization_id: orgId
});

// 4. Aplica a fórmula híbrida
const finalSet = new Set(role.base_permissions);
for (const override of overrides) {
  if (override.operation === 'ADD') finalSet.add(override.permission_key);
  if (override.operation === 'REMOVE') finalSet.delete(override.permission_key);
}

// 5. can() verifica hierarquia + permissão resolvida
const can = (key) => {
  if (isSuperAdmin || isOwner || isLegacyOwner) return true;
  return finalSet.has(key);
};

No Backend (base44/shared/orgContextResolver.ts)

// resolvePermissions() implementa a fórmula oficial:
export async function resolvePermissions(base44, memberId, organizationId) {
  // 1. Buscar OrganizationMember
  const member = await base44.asServiceRole.entities.OrganizationMember.filter({ id: memberId });

  // 2. Buscar Role (por role_id ou name + organization_type)
  let role = null;
  if (member.role_id) {
    role = await base44.asServiceRole.entities.Role.filter({ id: member.role_id });
  }
  if (!role && member.role) {
    role = await base44.asServiceRole.entities.Role.filter({
      name: member.role, organization_type: member.organization_type
    });
  }

  // 3. Base permissions da Role
  const basePermissions = new Set(role?.base_permissions || role?.permissions || []);

  // 4. Buscar MemberPermission overrides
  const overrides = await base44.asServiceRole.entities.MemberPermission.filter({
    member_id: memberId, organization_id: organizationId
  });

  // 5. Aplicar fórmula: base + ADD - REMOVE
  const finalPermissions = new Set(basePermissions);
  for (const override of overrides) {
    if (override.operation === 'ADD') finalPermissions.add(override.permission_key);
    if (override.operation === 'REMOVE') finalPermissions.delete(override.permission_key);
  }

  return finalPermissions;
}

Hierarquia de Autorização

---

10. Fluxo de Convites

Fluxograma do Fluxo de Convites

┌─────────────────────────────────────────────────────────────────┐
│                    FLUXO DE CONVITES                              │
│                                                                  │
│  ┌──────────────┐                                               │
│  │ Página Equipe │  Usuário clica em "Convidar Colaborador"     │
│  │ (Frontend)    │                                               │
│  └──────┬───────┘                                                │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ InviteMemberDialog│  Formulário:                             │
│  │ (Frontend)        │  • Nome Completo                         │
│  │                   │  • E-mail                                 │
│  │                   │  • Perfil de Acesso (Role)               │
│  │                   │  • Cargo/Função (informativo)            │
│  │                   │  • [Opcional] Personalizar Permissões   │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ notifyOrganization│  Backend:                                 │
│  │ Invitation       │  1. Valida permissão team:invite          │
│  │ (Backend)        │  2. Valida que a Role existe              │
│  │                   │  3. Verifica duplicidade (convite/membro)│
│  │                   │  4. Cria OrganizationInvitation         │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ├──────────────────────────────┐                        │
│         ▼                              ▼                        │
│  ┌──────────────┐              ┌──────────────┐                │
│  │ EmailService │              │ manageMember │                │
│  │ (Facade)     │              │ Permissions  │                │
│  └──────┬───────┘              │ (Backend)    │                │
│         │                      │               │                │
│         ▼                      │ Salva         │                │
│  ┌──────────────────┐          │ custom_perms  │                │
│  │ EmailProvider    │          │ no convite    │                │
│  │ Factory          │          └──────────────┘                │
│  │                   │                                           │
│  │ EMAIL_PROVIDER →  │                                           │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ ResendProvider   │  POST https://api.resend.com/emails       │
│  │ (API Resend)     │  Authorization: Bearer RESEND_API_KEY     │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ Resend (Cloud)  │  E-mail transacional enviado               │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ Novo Colaborador│  Recebe e-mail com link do convite         │
│  │ (caixa de entrada)│  Link: /register/invite?token=XXX        │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ RegisterInvite   │  Página de validação do convite           │
│  │ (Frontend)       │  (validate → Auth → complete)             │
│  └──────┬───────────┘                                           │
│         │                                                        │
│         ▼                                                        │
│  ┌──────────────────┐                                           │
│  │ completeInvitation│  Backend:                                 │
│  │ Registration     │  1. Valida token + e-mail autenticado     │
│  │ (Backend)        │  2. Cria OrganizationMember (active)      │
│  │                   │  3. Sincroniza role_id + role             │
│  │                   │  4. Aplica custom_permissions (se houver) │
│  │                   │  5. Marca convite como accepted           │
│  │                   │  6. Sincroniza organization_ids (User)   │
│  │                   │  7. Atualiza User.role (platform)       │
│  │                   │  8. Registra AuditLog                     │
│  │                   │  9. Retorna redirect_path do dashboard   │
│  └──────────────────┘                                           │
└─────────────────────────────────────────────────────────────────┘

Explicação de Cada Etapa

Secrets Utilizados no Fluxo de Convites

---

11. Landing Page

Implementação

A Landing Page da ConnectCond (rota /) continua utilizando exclusivamente o fluxo nativo da Base44.

Características confirmadas:

• ✅ A Landing Page NÃO utiliza o Resend ou qualquer infraestrutura de e-mail personalizada.
• ✅ A Landing Page NÃO é afetada pela arquitetura RBAC Enterprise.
• ✅ A Landing Page é uma rota pública, acessível sem autenticação.
• ✅ Qualquer formulário de contato ou captura de leads na Landing Page utiliza os mecanismos nativos da plataforma Base44.

Diferença do Fluxo de Convites: O fluxo de convites de colaboradores (Seção 10) utiliza o Resend via EmailService. A Landing Page é completamente independente desse fluxo.

---

12. Tela "Convidar Colaborador"

Componente: InviteMemberDialog.jsx

A tela de convite de colaboradores é implementada como um diálogo modal (Dialog) acessível a partir da página Equipe de cada organização.

Campos da Interface

Fluxo Visual do Diálogo

┌─────────────────────────────────────────────────────┐
│  [👤] Convidar colaborador                          │
│                                                       │
│  O colaborador receberá um convite por e-mail com    │
│  um link para concluir o cadastro e acessar a        │
│  plataforma.                                         │
│                                                       │
│  ┌─────────────────┐  ┌─────────────────┐            │
│  │ Nome completo   │  │ E-mail *        │            │
│  │ [João Silva   ] │  │ [joao@...     ] │            │
│  └─────────────────┘  └─────────────────┘            │
│                                                       │
│  Perfil de Acesso *                                  │
│  ┌─────────────────────────────────────────┐        │
│  │ Gestor                                    │        │
│  │ Administrador operacional. Gerencia...    │        │
│  └─────────────────────────────────────────┘        │
│                                                       │
│  Cargo/Função                                        │
│  [Síndico, Comprador, Financeiro...]               │
│  Campo informativo — não concede permissões.        │
│                                                       │
│  ┌─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┐    │
│  │ [☑] 🛡️ Personalizar permissões deste       │    │
│  │       colaborador                           │    │
│  │    Ajuste permissões individuais além do    │    │
│  │    Perfil de Acesso selecionado.            │    │
│  │                                              │    │
│  │  ┌─────────────────────────────────────┐   │    │
│  │  │  Permissões (scroll)                 │   │    │
│  │  │                                       │   │    │
│  │  │  📋 Equipe                           │   │    │
│  │  │  ☑ Visualizar membros da equipe      │   │    │
│  │  │  ☑ Convidar novos colaboradores [Extra]│  │    │
│  │  │  ☐ Gerenciar cargos  [Removida]      │   │    │
│  │  │                                       │   │    │
│  │  │  📄 Cotações                         │   │    │
│  │  │  ☑ Visualizar cotações               │   │    │
│  │  │  ☑ Criar cotações                    │   │    │
│  │  │  ...                                  │   │    │
│  │  └─────────────────────────────────────┘   │    │
│  └─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┘    │
│                                                       │
│                    [Cancelar]  [Enviar convite]     │
└─────────────────────────────────────────────────────┘

PermissionMatrix (Matriz de Permissões)

Quando o Proprietário ativa "Personalizar permissões", a PermissionMatrix é exibida com as seguintes características:

A matriz é segmentada por organization_type — apenas as permissões aplicáveis ao Perfil da Organização são exibidas.

---

13. Regras de Governança

Matriz Oficial de Governança

Regras de Governança Críticas

1. Apenas o Proprietário pode personalizar permissões — Validado no backend manageMemberPermissions (função isProprietario). Retorna HTTP 403 se o solicitante não for Proprietário ou Super Admin.

2. O Gestor pode gerenciar a equipe mas NUNCA pode alterar permissões — O Gestor tem team:manage (pode alterar cargos), mas a função manageMemberPermissions verifica especificamente role === 'Proprietário', não team:manage.

3. Todas as alterações de permissão são auditadas — O manageMemberPermissions registra no AuditLog toda criação, atualização e remoção de MemberPermission, com descrição legível e metadados estruturados.

4. O Super Admin (plataforma) bypassa todas as verificações — User.role === 'admin' tem acesso irrestrito a todas as operações.

---

14. Segurança

Princípio do Menor Privilégio

Toda implementação parte da premissa de que cada colaborador deve ter apenas as permissões mínimas necessárias para executar sua função:

• O Perfil Consulta recebe apenas permissões :view (somente leitura).
• O Perfil Colaborador recebe permissões operacionais (view, create, edit, send, use, upload), mas nunca manage, approve, delete, configure ou sync.
• Permissões de segurança (subscription:manage, settings:edit, integrations:configure, erp:sync, whatsapp:configure) são exclusivas do Proprietário por padrão.

Segregação de Funções

A arquitetura garante que funções sensíveis sejam separadas:

Auditoria

Toda alteração de permissão gera um registro no AuditLog:

Cada registro contém: user_email, user_id, action, entity_name, entity_id, description (legível), metadata (estruturado).

Compatibilidade com RLS (Row-Level Security)

A arquitetura RBAC Enterprise opera em conjunto com o RLS nativo da Base44:

• RLS controla quais registros um usuário pode ver/editar (isolamento multi-tenant).
• RBAC controla quais ações um usuário pode executar dentro dos registros que o RLS permite.

Exemplo: O RLS garante que um colaborador do Condomínio A não veja as cotações do Condomínio B. O RBAC garante que, dentro do Condomínio A, um Colaborador possa criar cotações mas não possa aprová-las.

Compatibilidade com Autenticação

A autenticação é exclusivamente gerenciada pela Base44:

• Criação de identidade (conta, senha, verificação de e-mail) → Base44 Auth.
• Sessões e tokens → Base44 Auth.
• A arquitetura RBAC não cria identidades — apenas gerencia vínculos (OrganizationMember) e permissões (Role, MemberPermission) para identidades já autenticadas.

Governança

A governança é enforced no backend, não apenas no frontend:

Princípio: O frontend é uma camada de UX; a segurança real é sempre validada no backend.

---

15. Compatibilidade

Esta arquitetura foi projetada para ser totalmente compatível com todos os módulos homologados da ConnectCond, sem quebrar funcionalidade existente:

Campos de compatibilidade ativos: Role.permissions (sincronizado com base_permissions), OrganizationMember.role (sincronizado com role_id), OrganizationMember.user_email (mantido para exibição). Todos são atualizados automaticamente — nunca editados diretamente.

---

16. Fluxo Completo da Arquitetura

Diagrama Geral da Arquitetura RBAC Enterprise

┌─────────────────────────────────────────────────────────────────────┐
│                    ARQUITETURA RBAC ENTERPRISE                       │
│                    CONNECTCOND — VISÃO COMPLETA                     │
│                                                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                     CAMADA DE IDENTIDADE                      │   │
│  │                                                                │   │
│  │  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐   │   │
│  │  │ Base44 Auth  │───▶│ User Entity  │───▶│ organization │   │   │
│  │  │ (Login/Senha)│    │ (id, email,  │    │ _ids (cache) │   │   │
│  │  │              │    │  role, ...)  │    │              │   │   │
│  │  └──────────────┘    └──────────────┘    └──────────────┘   │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                       │
│                              │ user_id                              │
│                              ▼                                       │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                   CAMADA DE VÍNCULO                           │   │
│  │                                                                │   │
│  │  ┌──────────────────────────────────────────┐               │   │
│  │  │ OrganizationMember                        │               │   │
│  │  │  • user_id ──────────────────────────────│───────────────│   │
│  │  │  • organization_id                        │               │   │
│  │  │  • organization_type (admin/cond/         │               │   │
│  │  │    provider/supplier)                     │               │   │
│  │  │  • role (string, compat RLS) ────────────│───────────────│   │
│  │  │  • role_id (UUID, fonte oficial) ────────│───────────────│   │
│  │  │  • professional_function (informativo)   │               │   │
│  │  │  • status (pending/active/blocked)       │               │   │
│  │  └──────────────┬───────────────────────────┘               │   │
│  │                 │                                               │   │
│  │         ┌───────┴────────┐                                    │   │
│  │         ▼                ▼                                     │   │
│  │  ┌──────────┐     ┌──────────────────┐                        │   │
│  │  │ Role     │     │ MemberPermission │                        │   │
│  │  │          │     │  (Overrides)     │                        │   │
│  │  │ base_    │     │                  │                        │   │
│  │  │ perms[]  │     │  ADD / REMOVE    │                        │   │
│  │  └────┬─────┘     └────────┬─────────┘                        │   │
│  │       │                    │                                    │   │
│  │       │     ┌──────────────┘                                    │   │
│  │       │     │ (referência por key)                              │   │
│  │       ▼     ▼                                                    │   │
│  │  ┌──────────────────┐                                          │   │
│  │  │ Permission       │  Catálogo de 52 permissões atômicas     │   │
│  │  │  (key, module,   │  segmentadas por organization_types      │   │
│  │  │   org_types)     │                                          │   │
│  │  └──────────────────┘                                          │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                       │
│                              ▼                                       │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                  CAMADA DE RESOLUÇÃO                          │   │
│  │                                                                │   │
│  │  orgContextResolver.ts (Backend)                              │   │
│  │  usePermissions.js (Frontend)                                 │   │
│  │                                                                │   │
│  │  FÓRMULA:                                                      │   │
│  │  Permissões Finais = base_permissions + ADD - REMOVE          │   │
│  │                                                                │   │
│  │  Hierarquia:                                                   │   │
│  │  1. Super Admin → tudo                                        │   │
│  │  2. Proprietário → tudo                                       │   │
│  │  3. Owner legado → tudo (compat)                              │   │
│  │  4. Demais → fórmula híbrida                                  │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                       │
│                              ▼                                       │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    CAMADA DE APLICAÇÃO                        │   │
│  │                                                                │   │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │   │
│  │  │ Frontend     │  │ Backend      │  │ RLS (Base44) │       │   │
│  │  │ can(key)     │  │ hasPermission│  │ Isolamento   │       │   │
│  │  │              │  │ (key)        │  │ multi-tenant │       │   │
│  │  └──────────────┘  └──────────────┘  └──────────────┘       │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                       │
│                              ▼                                       │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    CAMADA DE AUDITORIA                        │   │
│  │                                                                │   │
│  │  ┌──────────────────┐                                        │   │
│  │  │ AuditLog         │  Toda alteração registrada             │   │
│  │  │  (action, user,  │  com descrição e metadados             │   │
│  │  │   entity, desc)  │                                        │   │
│  │  └──────────────────┘                                        │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

---

17. Banco de Dados

Diagrama das Tabelas

┌─────────────────────────────────────────────────────────────────┐
│                        BANCO DE DADOS                            │
│                                                                  │
│  ┌──────────────────────┐        ┌──────────────────────┐       │
│  │     Role             │        │    Permission         │       │
│  │──────────────────────│        │──────────────────────│       │
│  │ id          (UUID)   │        │ id          (UUID)   │       │
│  │ name        (string) │        │ key         (string) │       │
│  │ organization_type     │        │ module      (enum)  │       │
│  │   (enum)             │        │ description (string)│       │
│  │ base_permissions      │        │ organization_types   │       │
│  │   (array<string>)    │        │   (array<enum>)     │       │
│  │ permissions* (compat) │        │                      │       │
│  │ description (string) │        │ RLS: read=public     │       │
│  │ is_system  (boolean) │        │      CUD=admin       │       │
│  │ is_default (boolean) │        └──────────────────────┘       │
│  │                      │                    ▲                  │
│  │ RLS: read=public     │                    │ (key ref)        │
│  │      CUD=admin       │                    │                  │
│  └──────────┬───────────┘                    │                  │
│             │ role_id                         │                  │
│             ▼                                 │                  │
│  ┌──────────────────────┐        ┌───────────┴──────────┐     │
│  │ OrganizationMember   │────────│  MemberPermission     │     │
│  │──────────────────────│  1:N   │──────────────────────│     │
│  │ id          (UUID)   │        │ id          (UUID)   │     │
│  │ user_id     (UUID)   │        │ member_id   (UUID)   │     │
│  │ user_email* (compat) │        │ organization_id(UUID)│     │
│  │ full_name   (string) │        │ permission_key(string)│     │
│  │ phone       (string) │        │ operation   (enum)   │     │
│  │ position    (string) │        │   ADD | REMOVE       │     │
│  │ professional_function│        │ granted_by  (UUID)   │     │
│  │   (string, informat.)│        │ granted_at  (datetime)│    │
│  │ department (enum)    │        │                      │     │
│  │ organization_id      │        │ RLS: read=org member │     │
│  │   (UUID)             │        │      CUD=admin       │     │
│  │ organization_type     │        └──────────────────────┘     │
│  │   (enum)             │                                      │
│  │ role        (string) │        ┌──────────────────────┐     │
│  │   (compat RLS)       │        │     AuditLog          │     │
│  │ role_id     (UUID)   │        │──────────────────────│     │
│  │   (oficial)         │        │ id          (UUID)   │     │
│  │ status      (enum)  │        │ user_email (string)  │     │
│  │   pending/active/   │        │ user_id     (UUID)   │     │
│  │   blocked/expired   │        │ action      (enum)   │     │
│  │ invited_by  (UUID)  │        │ entity_name(string) │     │
│  │ invited_by_name      │        │ entity_id   (UUID)  │     │
│  │ invited_at(datetime)│        │ description (string)│     │
│  │ accepted_at(datetime)│       │ ip_address (string) │     │
│  │ last_access(datetime)│       │ metadata    (object)│     │
│  │                      │        │                      │     │
│  │ RLS: read=self/org   │        │ RLS: read=admin      │     │
│  │      CUD=self/admin  │        │      CUD=admin       │     │
│  └──────────────────────┘        │      create=open     │     │
│                                   └──────────────────────┘     │
│                                                                  │
│  * Campo de compatibilidade (não é fonte da verdade)           │
└─────────────────────────────────────────────────────────────────┘

Tabela de Campos por Entidade

Role (16 registros: 4 Perfis × 4 org_types)

Permission (52 registros)

MemberPermission (dinâmico)

OrganizationMember (dinâmico)

AuditLog (dinâmico)

---

18. Exemplos Práticos

Exemplo 1: Criando um Proprietário

Cenário: Maria Souza registra a Administradora "CondAdmin Ltda" na plataforma.

Registros criados:

1. Administration
   { id: "admin-001", name: "CondAdmin Ltda", ... }

2. User (via Base44 Auth)
   { id: "usr-maria", email: "maria@condadmin.com.br", role: "administradora" }

3. OrganizationMember
   {
     id: "member-001",
     user_id: "usr-maria",
     organization_id: "admin-001",
     organization_type: "administration",
     role: "Proprietário",
     role_id: "role-prop-admin",   ← Role "Proprietário" + org_type "administration"
     status: "active",
     professional_function: "Diretor"
   }

Permissões recebidas: Todas as permissões do organization_type: "administration" (implícitas — Proprietário tem tudo).

Resolução:

Hierarquia → Proprietário → ✅ Todas as permissões implícitas
(MembroPermission overrides não são consultados — Proprietário tem tudo)

---

Exemplo 2: Criando um Gestor

Cenário: Maria (Proprietária) convida João Silva como Gestor da Administradora.

Registros criados:

1. OrganizationInvitation
   {
     id: "inv-001",
     organization_id: "admin-001",
     email: "joao@condadmin.com.br",
     role: "Gestor",
     token: "abc-token-123",
     status: "pending",
     custom_permissions: []
   }

2. (E-mail enviado via Resend com link /register/invite?token=abc-token-123)

3. OrganizationMember (criado quando João aceita o convite)
   {
     id: "member-002",
     user_id: "usr-joao",
     organization_id: "admin-001",
     organization_type: "administration",
     role: "Gestor",
     role_id: "role-gestor-admin",  ← Role "Gestor" + org_type "administration"
     status: "active",
     professional_function: "Gerente"
   }

Permissões recebidas: base_permissions da Role "Gestor" + organization_type: "administration", exceto as 5 permissões de segurança exclusivas do Proprietário.

Resolução:

base_permissions (Gestor, administration) = [
  "dashboard:view", "team:view", "team:invite", "team:manage", "team:remove",
  "solicitations:view", "solicitations:create", "solicitations:edit", "solicitations:cancel",
  "quotations:view", "quotations:create", "quotations:edit", "quotations:approve", "quotations:cancel",
  "proposals:view", "proposals:approve", "proposals:reject",
  "contracts:view", "contracts:sign",
  "documents:view", "documents:upload", "documents:delete",
  "finance:view", "finance:create", "finance:approve",
  "chat:view", "chat:send",
  "ai:view", "ai:use",
  "subscription:view",
  "settings:view",
  "integrations:view",
  "calendar:view", "calendar:manage",
  "reports:view", "reports:export",
  "erp:view",
  "whatsapp:view",
  "reviews:create",
  "condominiums:view", "condominiums:manage"
]
+ ADD: (nenhum override)
- REMOVE: (nenhum override)
= Permissões Finais (sem subscription:manage, settings:edit, integrations:configure, erp:sync, whatsapp:configure)

---

Exemplo 3: Criando um Colaborador com Permissões Personalizadas

Cenário: Maria (Proprietária) convida Carlos como Colaborador, mas personaliza suas permissões para também poder aprovar propostas (proposals:approve), que normalmente o Colaborador não tem.

Registros criados:

1. OrganizationInvitation
   {
     id: "inv-002",
     organization_id: "admin-001",
     email: "carlos@condadmin.com.br",
     role: "Colaborador",
     token: "def-token-456",
     status: "pending",
     custom_permissions: [
       { permission_key: "proposals:approve", operation: "ADD" }
     ]
   }

2. (E-mail enviado via Resend)

3. OrganizationMember (criado quando Carlos aceita)
   {
     id: "member-003",
     user_id: "usr-carlos",
     organization_id: "admin-001",
     organization_type: "administration",
     role: "Colaborador",
     role_id: "role-colab-admin",
     status: "active",
     professional_function: "Assistente"
   }

4. MemberPermission (criado a partir do custom_permissions do convite)
   {
     id: "mp-001",
     member_id: "member-003",
     organization_id: "admin-001",
     permission_key: "proposals:approve",
     operation: "ADD",
     granted_by: "usr-maria",
     granted_at: "2026-08-06T14:30:00Z"
   }

Resolução:

base_permissions (Colaborador, administration) = [
  "dashboard:view", "team:view", "team:invite",
  "solicitations:view", "solicitations:create", "solicitations:edit",
  "quotations:view", "quotations:create", "quotations:edit",
  "proposals:view", "proposals:create",
  "contracts:view", "contracts:manage",
  "documents:view", "documents:upload",
  "finance:view", "finance:create",
  "chat:view", "chat:send",
  "ai:view", "ai:use",
  "subscription:view", "settings:view", "integrations:view",
  "calendar:view",
  "reports:view",
  "erp:view", "whatsapp:view",
  "reviews:create",
  "condominiums:view"
]
+ ADD: "proposals:approve"     ← do MemberPermission
- REMOVE: (nenhum)
= Permissões Finais:
  (...todas as base...) + "proposals:approve"

Carlos agora PODE aprovar propostas, mesmo sendo Colaborador.

---

Exemplo 4: Criando um Consulta com Permissão Removida

Cenário: Maria (Proprietária) convida Ana como Consulta (somente leitura), mas remove explicitamente a permissão finance:view (que o Consulta normalmente tem).

Registros criados:

1. OrganizationInvitation
   {
     custom_permissions: [
       { permission_key: "finance:view", operation: "REMOVE" }
     ]
   }

2. OrganizationMember
   { role: "Consulta", role_id: "role-cons-admin", ... }

3. MemberPermission
   {
     permission_key: "finance:view",
     operation: "REMOVE",
     ...
   }

Resolução:

base_permissions (Consulta, administration) = [
  "dashboard:view", "team:view",
  "solicitations:view", "quotations:view", "proposals:view",
  "contracts:view", "documents:view", "finance:view",    ← está na base
  "chat:view", "ai:view",
  "subscription:view", "settings:view", "integrations:view",
  "calendar:view", "reports:view",
  "erp:view", "whatsapp:view",
  "condominiums:view"
]
+ ADD: (nenhum)
- REMOVE: "finance:view"     ← do MemberPermission
= Permissões Finais:
  (...todas as base...) - "finance:view"

Ana NÃO pode visualizar o módulo Financeiro, mesmo sendo Consulta
(que normalmente teria finance:view).

---

19. Histórico da Arquitetura

Decisões Técnicas Registradas

Arquitetura Homologada

Esta versão (1.0.0) foi homologada em 06 de Agosto de 2026 após:

• ✅ Implementação completa das 5 entidades (Role, Permission, MemberPermission, OrganizationMember, AuditLog)
• ✅ Catálogo de 52 permissões atômicas + 16 Perfis de Acesso populado via seedPermissions
• ✅ Resolvedor central (orgContextResolver.ts) implementado e testado
• ✅ Hook frontend (usePermissions.js) evoluído com fórmula híbrida
• ✅ Fluxo de convites refatorado com role_id + custom_permissions
• ✅ Tela "Convidar Colaborador" com PermissionMatrix implementada
• ✅ Governança de permissões (apenas Proprietário) validada no backend
• ✅ Auditoria de todas as alterações de permissão

---

20. Conclusão

Esta passa a ser a Arquitetura Oficial Homologada da ConnectCond para controle de acesso baseado em papéis (RBAC Enterprise).

Pontos-Chave

1. Modelo Híbrido: Perfil de Acesso (Role) define a base; MemberPermission permite personalizações individuais (ADD/REMOVE).
2. Fórmula Determinística: Permissões Finais = base_permissions + ADD - REMOVE — sempre previsível e auditável.
3. Governança Centralizada: Apenas o Proprietário pode personalizar permissões; o Gestor gerencia a equipe mas não pode escalonar privilégios.
4. Auditoria Completa: Toda alteração de permissão é registrada no AuditLog com rastreabilidade total.
5. Compatibilidade Total: Nenhum módulo homologado foi quebrado; campos de compatibilidade mantêm o funcionamento de código legado.
6. Segurança em Camadas: Frontend (UX) + Backend (validação real) + RLS (isolamento multi-tenant) operam em conjunto.

Referência Oficial

Este documento serve como referência oficial para:

• Novos desenvolvedores integrando à equipe
• Futuras evoluções da plataforma
• Auditorias de segurança e conformidade
• Homologações de novos módulos
• Documentação interna
• Entendimento do negócio por stakeholders técnicos e não técnicos

Nota de Fidelidade: Este documento reflete a implementação real do ambiente de produção. Caso discrepâncias sejam identificadas entre este documento e o comportamento observado do sistema, o código-fonte em produção deve ser considerado a fonte definitiva, e este documento deve ser atualizado para refletir a realidade.

---

ConnectCond © 2026 — Arquitetura RBAC Enterprise v1.0.0 — Documento Oficial Homologado