ADR-0013 — Perfil de Usuário e Ciclo de Vida da Conta

Status

Proposto

Contexto

O EBDbe já define identidade, autenticação, RBAC e multitenancy nos ADRs anteriores, mas ainda não formaliza em um único documento:

1. O ciclo de vida completo da conta de usuário (da criação à exclusão)
2. A matriz de transição de status com regras explícitas
3. O modelo de perfil de aplicação (dados pessoais autorizados + dados de plataforma)
4. O modelo de preferências pessoais segmentadas
5. O comportamento de sessão na interface (avatar/foto no header e popup de conta)

Além disso, é obrigatório manter coerência com o modelo tenant-aware:

• Usuário pertence a tenant ministerial (ministry_id)
• Operações dependem de escopo organizacional (unit_id quando aplicável)
• Backend é autoridade para validação de estado, escopo e permissão

---

Decisão

O sistema adotará um modelo unificado de perfil e ciclo de vida de usuário, com estados e transições formalizados.

1. Estados Oficiais do Usuário

Os nomes de status serão mantidos conforme legado e ADR-0005 (formato padronizado em caixa alta):

• PENDING
• ACTIVE
• INACTIVE
• BLOCKED
• SUSPENDED
• BANNED
• DELETION_REQUESTED
• DELETED

Observações:

• DELETION_REQUESTED e DELETED são adicionados para fechar o ciclo de vida até exclusão.
• none do legado não é estado operacional de conta.

2. Matriz de Transição de Status

Todas as transições devem ser validadas no backend, com trilha de auditoria (actor_id, from_status, to_status, reason, timestamp, ministry_id, target_user_id).

De	Para	Permitido?	Quem pode executar	Regra
(novo cadastro)	PENDING	Sim	Sistema	Criação inicial de conta
PENDING	ACTIVE	Sim	Aprovador autorizado	Ativação manual conforme ADR-0010
PENDING	BANNED	Sim	MINISTRY_ADMIN ou PLATFORM_ADMIN	Fraude/abuso antes da ativação
PENDING	DELETED	Sim	Sistema ou PLATFORM_ADMIN	Expurgo técnico/legal
ACTIVE	INACTIVE	Sim	Próprio usuário (autodesativação) ou administrador autorizado	Conta sem uso ou pausa voluntária
ACTIVE	SUSPENDED	Sim	Administrador autorizado	Suspensão temporária disciplinar/operacional
ACTIVE	BLOCKED	Sim	Sistema	Bloqueio automático de segurança (risco detectado)
ACTIVE	BANNED	Sim	MINISTRY_ADMIN ou PLATFORM_ADMIN	Banimento definitivo por violação grave
ACTIVE	DELETION_REQUESTED	Sim	Próprio usuário ou titularidade validada	Solicitação de exclusão
INACTIVE	ACTIVE	Sim	Próprio usuário (quando permitido) ou administrador autorizado	Reativação de conta
INACTIVE	SUSPENDED	Sim	Administrador autorizado	Evolução para medida temporária
INACTIVE	BANNED	Sim	MINISTRY_ADMIN ou PLATFORM_ADMIN	Violação detectada após inativação
INACTIVE	DELETION_REQUESTED	Sim	Próprio usuário ou titularidade validada	Solicitação de exclusão
BLOCKED	ACTIVE	Sim	Sistema ou administrador autorizado	Desbloqueio após validação de segurança
BLOCKED	SUSPENDED	Sim	Administrador autorizado	Conversão para medida temporária
BLOCKED	BANNED	Sim	MINISTRY_ADMIN ou PLATFORM_ADMIN	Reincidência ou fraude comprovada
BLOCKED	DELETION_REQUESTED	Sim	Próprio usuário (se autenticado por fluxo seguro) ou titularidade validada	Direito de exclusão
SUSPENDED	ACTIVE	Sim	Administrador autorizado	Fim da suspensão
SUSPENDED	BANNED	Sim	MINISTRY_ADMIN ou PLATFORM_ADMIN	Agravamento disciplinar
SUSPENDED	DELETION_REQUESTED	Sim	Próprio usuário ou titularidade validada	Direito de exclusão
BANNED	ACTIVE	Excepcional	PLATFORM_ADMIN	Reversão administrativa extraordinária, auditada e justificada
BANNED	DELETED	Sim	PLATFORM_ADMIN	Expurgo técnico/legal
DELETION_REQUESTED	DELETED	Sim	Sistema ou controlador autorizado	Conclusão do processo de exclusão
DELETION_REQUESTED	ACTIVE	Sim	Próprio usuário (arrependimento dentro da janela) ou administrador autorizado	Cancelamento da exclusão
DELETED	qualquer outro	Não	—	Estado terminal

3. Regras de Escopo (Tenant)

• Todo User deve possuir ministry_id.
• unit_id permanece obrigatório para usuários de escopo local e pode ser nulo para escopo ministerial/global conforme ADR-0003.
• Toda mudança de status deve validar coerência entre:
  • domínio de entrada (quando aplicável)
  • ministry_id do alvo
  • escopo/papel de quem executa a ação
• Operações cross-tenant só podem ocorrer com PLATFORM_ADMIN e target_ministry_id explícito (ADR-0012).

4. Modelo de Perfil de Usuário (Aplicação)

O perfil de usuário é a fonte de verdade de aplicação para exibição e preferências, composto por:

• Identificação de plataforma: id, ministry_id, unit_id, status, status_date
• Dados básicos: name, alias_name (opcional), email, phone (opcional)
• Foto/avatar:
  • avatar_source (OAUTH | CUSTOM | DEFAULT)
  • avatar_url (opcional)
  • avatar_updated_at (opcional)
• Governança temporal:
  • created_at
  • updated_at
  • last_login_at (opcional)
  • deletion_requested_at (opcional)
  • deleted_at (opcional)
• Consentimentos e autorizações:
  • flags de consentimento para dados opcionais
  • origem do consentimento e timestamp

Princípio de precedência para identidade visual:

1. Se avatar_source = CUSTOM, usar avatar customizado
2. Caso contrário, se houver foto do provedor OAuth, usar foto OAuth
3. Caso contrário, usar avatar padrão

5. Preferências Segmentadas

As preferências devem ser separadas por domínio funcional, no mínimo:

• preferences.notifications (push, email, categorias)
• preferences.appearance (tema, cores, skin, densidade visual)
• preferences.usage (atalhos, comportamento inicial, recursos habilitados)

As preferências são vinculadas ao perfil do usuário no tenant e devem respeitar:

• minimização de dados (ADR-0006)
• não usar preferências para ampliar escopo/permissão
• leitura/escrita validadas no backend para operações sensíveis

6. Regras de Interface de Sessão

Após autenticação com sucesso:

1. A ação "Entrar" no topo deve ser substituída por foto/avatar do usuário.
2. Ao clicar no avatar, abrir popup/menu de conta com informações básicas:
   • nome
   • email
   • papel principal (quando aplicável)
   • status da conta (quando relevante)
3. O popup deve oferecer ação de saída (Sair) com encerramento de sessão.

Essas regras são mandatórias para consistência de UX em toda a aplicação.

7. Onboarding de Perfil Pos-Autenticacao

• Apos autenticacao valida do mecanismo de identidade (email/senha com verificacao concluida ou OAuth), o usuario deve ser conduzido para fluxo de onboarding de perfil quando houver dados obrigatorios pendentes.
• O onboarding deve coletar somente dados adicionais necessarios ao contexto de aplicacao, respeitando minimizacao e consentimento (ADR-0006).
• Enquanto o onboarding obrigatorio nao for concluido, o backend pode restringir operacoes nao essenciais, mantendo o usuario em fluxo guiado de conclusao de perfil.
• A conclusao do onboarding deve ser auditavel (quem, quando, quais campos obrigatorios) sem expor dados sensiveis desnecessarios.

---

Regras Arquiteturais Derivadas

1. Backend é autoridade para transição de status e validação de escopo.
2. Nenhuma transição de status ocorre sem auditoria e justificativa quando aplicável.
3. DELETED é estado terminal e irreversível no fluxo padrão.
4. Foto/avatar não altera regras de autorização; é apenas aspecto de perfil.
5. Preferências pessoais são segmentadas e não devem misturar dados sensíveis sem consentimento.

---

Integração com ADRs existentes

• ADR-0003: transições e operações respeitam RBAC + escopo
• ADR-0005: estende modelagem conceitual de User com perfil e ciclo de vida completo
• ADR-0006: coleta mínima e consentimento para dados pessoais opcionais
• ADR-0009: formaliza comportamento de avatar e menu de conta no estado logado
• ADR-0010: complementa ativação manual, autenticação e segurança de conta
• ADR-0011: preferências de notificação passam a integrar preferências segmentadas de perfil
• ADR-0012: mantém coerência com multitenancy por domínio e operações cross-tenant auditadas
• ADR-0014: aplicacao de operacoes de perfil via gateway unico com validacao de acao, escopo e auditoria

---

Consequências

• O domínio passa a ter ciclo de vida de usuário explicitamente governado.
• O backend deve implementar máquina de estados de conta com matriz de transição.
• O modelo de dados de perfil deve incluir avatar, consentimentos e preferências segmentadas.
• O sistema passa a ter onboarding de perfil pos-autenticacao como etapa governada por backend para dados obrigatorios pendentes.
• A UI deve padronizar header pós-login com avatar e popup de conta.
• Alterações nos estados ou nas regras de transição exigirão novo ADR ou revisão deste ADR.