ADR-0018 — Papel inicial VISITOR para novas contas

Status

Aprovado

Contexto

Os fluxos de autenticacao permitem que o usuario exista no Firebase Auth antes de concluir a criacao do perfil de dominio no backend.

Sem uma regra canonica de bootstrap de papeis, contas novas podem nascer sem roleAssignments, com activeRole inconsistente, ou com variacao entre fluxos (email, Google e auto registro no primeiro login).

Essa inconsistência afeta:

1. autorizacao por escopo e perfil;
2. UX de seleção de papel ativo;
3. rastreabilidade do estado inicial da conta.

---

Decisao

Toda nova conta deve iniciar com papel VISITOR, aprovado no ato da criacao.

Regra obrigatoria de bootstrap

Para qualquer fluxo de criacao de conta:

• primaryRole = "VISITOR"
• activeRole = "VISITOR"
• roleAssignments inclui:
  • { roleId: "VISITOR", status: "APPROVED", lastActionDate: now }

No modelo person embutido:

• person.roleAssignments inclui VISITOR com:
  • ministryId do tenant;
  • unitId (quando informado);
  • status = "APPROVED";
  • lastActionDate = now.

Catálogo de roleId

roleId deve ser restrito ao catálogo oficial compartilhado entre backend e frontend, incluindo VISITOR.

---

Abrangencia de fluxos

A regra vale para:

1. criacao via email/senha;
2. criacao via Google;
3. auto registro (USER_SELF_REGISTER) no primeiro acesso.

---

Consequencias

• Elimina contas novas sem papel inicial de dominio.
• Reduz divergencia entre autenticação e perfil de negocio.
• Padroniza a base para evolucao de solicitacao/aprovacao de papeis.
• Exige manutencao sincronizada do catálogo de roleId entre backend e frontend.

---

Integracao com ADRs existentes

• ADR-0003: reforca RBAC com estado inicial consistente.
• ADR-0005: preserva coerencia da entidade de usuario no dominio.
• ADR-0012: mantem escopo por tenant (inetDomain) no bootstrap do perfil.
• ADR-0013: complementa ciclo de vida com papel inicial definido.