# CHECK-IN DE USUÁRIOS NO SISTEMA Documento pai: Especificação Funcional de Software — Gemed Onco Versão: 2.13 Data: 15/09/2026 --- ## 1. Objetivo Definir e especificar todas as funcionalidades relacionadas ao check-in de usuários no sistema Gemed — o conjunto de fluxos que permite que um profissional crie sua conta, autentique-se, recupere seu acesso, seja convidado por clínicas, selecione onde trabalhar e navegue entre os módulos que seu perfil de acesso libera. --- ## 2. Escopo ### 2.1 Dentro do escopo - Login com documento único e senha - Controle de tentativas de login com bloqueio parametrizável - Recuperação de senha via código de verificação - Auto-cadastro público (conta global do usuário) - Validação de documento e conselho profissional no cadastro - Dados avançados opcionais conforme SBIS ECF.02.01 - Convite de profissionais por clínicas (E3) - Vínculo entre usuário e clínica (E3) - Seleção de clínica quando o usuário possui múltiplos vínculos (a especificar — E6) - Menu lateral de navegação entre os módulos liberados pelo perfil de acesso, transversal a qualquer profissional autenticado (E5) - Meu Perfil — visualização e edição dos dados do usuário (a especificar — E4) ### 2.2 Fora do escopo - Single Sign-On (SSO) externo - Gestão de identidade federada - Controle biométrico de acesso - Criptografia de dados em repouso - Gestão de perfis de acesso (RBAC) — tratado no Contexto de Segurança - Gestão de sessão e timeout por inatividade — tratado no Contexto de Segurança - Mecanismo de desativação de uma `ClienteEmpresa` (tela, fluxo administrativo, quem pode acioná-lo) — pertence à gestão de usuários da clínica, fora do escopo deste conjunto. O efeito já está confirmado: ao ser desativada, todos os usuários hoje associados a ela perdem o acesso a essa clínica — ela deixa de contar como clínica acessível para fins de roteamento (RN-CIU-009, RN-CIU-022), mesmo que o vínculo (UsuarioCliente) e o Perfil de acesso (ClientePerfilAcessoUsuario) permaneçam intactos. Como e quando a desativação é acionada segue **[A DEFINIR]**, a especificar junto da gestão de usuários da clínica. --- ## 3. Personas |Persona|Descrição| |---|---| |Profissional não cadastrado|Médico, enfermeira, farmacêutica ou outro profissional de saúde que ainda não possui conta no Gemed| |Usuário autenticado|Profissional com conta ativa, autenticado no sistema| |Administrador da clínica|Usuário com perfil de administrador que convida e vincula profissionais à sua clínica| |Suporte técnico Gemed|Usuário N1/N2 que auxilia na resolução de conflitos de cadastro e conselho| --- ## 4. Workflows do Profissional Esta seção documenta, uma única vez, os workflows que atravessam mais de um épico do Check-in (conforme a seção "Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos" da Skill Designer). Workflows específicos de um único épico — como a recuperação de senha, ou a navegação pelo menu lateral (CIU-E5) — ficam documentados no próprio épico dono. ### 4.1 Entrada do profissional no sistema **Resumo do workflow:** todo profissional de saúde ou de apoio precisa, em algum momento, obter uma conta no Gemed e, a partir daí, acessar o sistema no seu dia a dia. Esse workflow tem dois momentos: a criação da conta (uma única vez, se ainda não existir) e o acesso recorrente (a cada dia de trabalho). Ele atravessa os épicos E1 e E2 porque a conta é sempre a mesma (RN-CIU-002 — unicidade global do usuário): quem se cadastra pelo E2 é a mesma pessoa que depois faz login pelo E1. **Touchpoints:** |Momento do workflow|Necessidade do profissional|O que a funcionalidade oferece|Decisão de design justificada| |---|---|---|---| |Profissional ainda não tem conta no Gemed|Criar sua conta sem depender de um administrador de clínica, e começar a usar o sistema imediatamente|Wizard de auto-cadastro em 3 etapas (E2); ao concluir com sucesso, o sistema autentica o profissional automaticamente e aplica o mesmo roteamento pós-login do E1 (RN-CIU-009 e RN-CIU-022)|Wizard dividido em etapas, não um formulário único, para não sobrecarregar quem só quer os dados básicos — os dados avançados (SBIS ECF.02.01) ficam numa etapa separada e opcional (E2, RN-CIU-018). A autenticação automática ao final evita um segundo passo manual de login logo após o cadastro| |Profissional já tem conta e retorna ao sistema (a cada dia de trabalho)|Autenticar rapidamente e ser levado direto ao seu contexto de trabalho, sem etapas extras|Login com documento único + senha (E1); após autenticação, o sistema decide automaticamente para onde direcionar o profissional, conforme seus vínculos com clínicas (E1, RN-CIU-009) — a menos que exista um convite pendente (ver linha abaixo)|O direcionamento automático pós-login (cockpit do profissional / seleção de clínica / Meu Perfil) elimina uma etapa manual de navegação — a decisão de para onde ir é do sistema, não do profissional| |Profissional foi convidado por uma clínica (com ou sem conta prévia no Gemed)|Formalizar o vínculo com a clínica que o convidou, sem repetir dados que ela já informou, e sem telas desnecessárias se já usa o sistema em outra clínica|Convite registrado pelo administrador da clínica (E3), que já cria a conta do usuário (Usuario + UsuarioCliente com Situacao = 'C', RN-CIU-011). O link do e-mail leva à tela de conclusão de cadastro do E3 (RN-CIU-012) se a senha ainda não foi definida, ou ao login (E1) se já foi (RN-CIU-023). Ao autenticar, com convite pendente: sem nenhum vínculo ativo, vai para a tela de aceite do vínculo do E3 (RN-CIU-014), com leitura das regras básicas; com ao menos um vínculo ativo, o convite aparece como card na tela de seleção de clínica (E6, RN-CIU-025), aceito sem releitura (RN-CIU-022)|Criar a conta já no convite simplifica o modelo de dados e reaproveita a estrutura existente de Usuario/UsuarioCliente. O E2 nunca participa desse fluxo — o CPF já estaria duplicado (RN-CIU-004). O aceite é sempre uma ação explícita; a diferença entre tela cheia (E3) e card (E6) está em quanto o profissional já conhece o sistema — releitura de regras só faz sentido na primeira vez| |Profissional esqueceu a senha|Recuperar o acesso sem precisar de suporte técnico|Fluxo de recuperação por código de verificação (E1)|Fica documentado inteiramente em (CIU-E1) — não é um touchpoint transversal, pois não envolve o E2| O roteamento completo pós-autenticação — para onde cada combinação de vínculos ativos e convite pendente leva o profissional — está registrado uma única vez em RN-CIU-022 (Seção 5), não repetido aqui. Uma vez que o profissional chega a uma clínica de trabalho definida, a navegação entre os módulos que seu perfil de acesso libera passa a ser feita pelo menu lateral (CIU-E5) — funcionalidade transversal a qualquer profissional autenticado, documentada inteiramente no próprio épico, por não atravessar mais de um épico deste conjunto. --- ## 5. Regras de Negócio Transversais Regras que se aplicam a mais de um épico do Check-in de Usuários. A redação completa de cada uma vive aqui — os épicos não a repetem, apenas referenciam o ID (RN-CIU-XXX). Regras que pertencem a um único épico ficam no documento do épico dono (ver Seção 7 — Épicos do Conjunto, para a lista completa de qual RN pertence a qual épico). ### RN-CIU-005 — Exclusão lógica (sem campo Status) O conceito de campo Status foi abolido das tabelas IpSeguranca. A exclusão lógica utiliza a estrutura padrão da infraestrutura: - RemovidoEm (datetimeoffset) — registra a data e hora da exclusão - UsuarioIdRemovido (uniqueidentifier) — identifica quem fez a exclusão Um registro é considerado ativo quando RemovidoEm é nulo. Um registro é considerado excluído quando RemovidoEm possui uma data/hora preenchida. Todas as consultas, validações e verificações de duplicidade consideram apenas registros ativos. Usada por: (CIU-E1) — verificação de login e de recuperação de senha; (CIU-E2) — verificação de duplicidade de CPF e de conselho profissional. ### RN-CIU-006 — Qualidade e histórico de senha parametrizados Os seguintes parâmetros de qualidade e histórico de senha são parametrizáveis via tabela UsuarioSenhaParametros (IpSeguranca): |Parâmetro|Descrição|Valor atual| |---|---|---| |TamanhoMinimo|Mínimo de caracteres na senha|8| |MinimoCaracterEspecial|Mínimo de caracteres especiais|1| |MinimoLetraMaiuscula|Mínimo de letras maiúsculas|1| |MinimoLetraMinuscula|Mínimo de letras minúsculas|1| |MinimoNumero|Mínimo de números (dígitos)|1| |CaracteresEspeciais|Caracteres especiais válidos aceitos|!@#$%^&*-_+=?;:\|| |MinutosValidadeNovaSolicitacao|Validade do código de recuperação (minutos)|15| |QuantidadeMemoria|Quantidade de senhas anteriores guardadas (0 = não guarda)|7| Nota: os parâmetros de tentativas de login e bloqueio (QuantidadeTentativas, MinutosBloqueado) não fazem parte desta regra — são específicos do fluxo de login e estão em RN-CIU-010 (CIU-E1). A tabela UsuarioSenhaParametros também guarda, desde a v3.1 do E3, um parâmetro de outra natureza — `DiasValidadeConviteVinculo`, prazo de validade de convite de vínculo — que também não faz parte desta regra; redação completa em RN-CIU-024 (CIU-E3). Usada por: (CIU-E1) — redefinição de senha na recuperação; (CIU-E2) — definição de senha no auto-cadastro. ### RN-CIU-007 — Suporte multilíngue O sistema suporta três idiomas: pt-BR (português do Brasil), en-US (inglês) e es-419 (espanhol latino-americano). Todas as mensagens exibidas ao usuário são catalogadas com IDs (MSG-E01, MSG-S01, etc.) e traduzidas para os três idiomas. As mensagens inline nos documentos referenciam os IDs do catálogo. Usada por: (CIU-E1) e (CIU-E2) — catálogos de mensagens (Seção 10 de cada épico). ### RN-CIU-008 — Comportamento de campos de input Todo campo de input possui um placeholder que é o nome do campo (apenas o nome, sem verbos de comando). Quando o usuário clica no campo para digitar, o placeholder some e se torna um label acima do campo (colado à borda superior do campo). O label é sempre igual ao placeholder. Usada por: (CIU-E1) e (CIU-E2) — todos os campos de todas as telas. ### RN-CIU-022 — Autenticação automática e roteamento pós-autenticação conforme convite pendente **Parte 1 — Autenticação automática pós-auto-cadastro (inalterada desde a v2.1):** ao concluir o wizard de auto-cadastro (E2) com sucesso, o sistema autentica o profissional automaticamente — sem exigir um login manual subsequente pela tela do E1. **Parte 2 — Roteamento pós-autenticação:** após a autenticação — automática ao final do auto-cadastro (E2), automática ao final da tela de conclusão de cadastro por convite (E3, RN-CIU-012), ou manual pelo login (E1) — o sistema verifica primeiro se existe um convite pendente (UsuarioCliente com Situacao = 'C', E3, RN-CIU-011) associado ao usuário, e cruza com a existência de vínculo(s) ativo(s) (Situacao = 'V'): 1. **Convite pendente e nenhum vínculo ativo** — o profissional é genuinamente novo no sistema. É direcionado para a tela de aceite do vínculo (E3, RN-CIU-014), antes de qualquer outro destino, com leitura das regras básicas de uso. Somente após o aceite, com a verificação de Perfil de acesso (E3, RN-CIU-015), o profissional chega à sua tela inicial de fato: cockpit, quando esse vínculo (o primeiro e único até então) já dá acesso a exatamente 1 `ClienteEmpresa`; tela de seleção de clínica (E6), quando dá acesso a mais de 1 `ClienteEmpresa`; ou mensagem de bloqueio orientativa, quando ainda não há nenhum Perfil de acesso associado ao vínculo. 2. **Convite pendente e ao menos um vínculo ativo** — o profissional já usa o sistema em outra(s) clínica(s). O aceite não passa pela tela de aceite do E3 — é direcionado para a tela de seleção de clínica (E6), que exibe um card em destaque com o convite pendente, aceito diretamente ali, sem releitura das regras básicas (E6, RN-CIU-025). Isso vale mesmo quando os vínculos ativos que o profissional já tem, somados, dão acesso a exatamente 1 clínica — caso que, sem convite pendente, iria direto ao cockpit (item 3) — pois é o único jeito de esse profissional ver e aceitar o convite. 3. **Sem convite pendente** — aplica-se o roteamento padrão por clínicas acessíveis, já descrito em RN-CIU-009: 0 clínicas acessíveis (por não ter nenhum vínculo ativo, ou por ter vínculo(s) ativo(s) sem nenhum Perfil de acesso associado a nenhuma clínica) → Meu Perfil (E4) com banner MSG-I01; acesso a exatamente 1 clínica → cockpit do profissional; acesso a mais de 1 clínica → seleção de clínica (E6). O caso do auto-cadastro público (E2) recai sempre no item 3, com 0 vínculos ativos (e portanto 0 clínicas acessíveis) — resultando no direcionamento a Meu Perfil, exatamente como descrito na decisão original da v2.1: quem se cadastra pelo E2 nunca tem convite pendente, pois se tivesse, o CPF já pertenceria a uma conta criada pelo administrador e o cadastro teria sido bloqueado por duplicidade (RN-CIU-004). Um profissional convidado (itens 1 ou 2) chega pela tela de conclusão de cadastro ou pelo login do E1 — nunca pelo E2 — e segue um caminho diferente antes de chegar a qualquer tela final. A verificação de convite pendente também se aplica ao fluxo de login manual (E1), não apenas ao pós-cadastro — item 2 acima em particular: um usuário já existente que recebe um convite de uma nova clínica vê o convite ao fazer login, mas não é interrompido pela tela cheia de aceite do E3 — o convite aparece como card na tela que ele já usa para escolher a clínica. Uma vez que o profissional chega a uma clínica de trabalho definida (cockpit ou qualquer outra tela inicial de perfil), o menu lateral (CIU-E5) passa a ser o ponto de navegação entre os módulos que seu perfil de acesso libera — não é, ele mesmo, um destino deste roteamento, mas o componente que acompanha o profissional a partir daí. Usada por: (CIU-E2) — tela de sucesso do wizard, ao final da Etapa 3 (verificação de convite pendente sempre negativa, por construção — ver Seção 1.2 do E2); (CIU-E1) — reaproveita o mecanismo de autenticação e passa a consultar `convitesPendentes` na resposta do login (Seção 2 do E1, "Integração com Backend") antes de aplicar o roteamento por vínculos (RN-CIU-009); (CIU-E3) — dona da tela de conclusão de cadastro (que também autentica automaticamente ao final, RN-CIU-012), da tela de aceite do vínculo (item 1) e da verificação de Perfil de acesso; (CIU-E6) — dona da tela de seleção de clínica e do card de aceite (item 2, RN-CIU-025). --- ## 6. Requisitos SBIS Aplicáveis |Requisito|Estágio|Descrição|Épicos que atendem| |---|---|---|---| |ECF.02.01|1 (obrigatório)|Identificação dos profissionais — campos presentes no formulário|E2| |ECF.02.02|1 (obrigatório)|Duplicidade de cadastros — validação por CPF e conselho|E2| |NGS1.02.01|1 (obrigatório)|Método de autenticação — usuário + senha, validação no servidor|E1| |NGS1.02.02|1 (obrigatório)|Proteção dos parâmetros de autenticação — hash de no mínimo 160 bits|E1| |NGS1.02.03|1 (obrigatório)|Qualidade da senha — mínimo 8 caracteres, 1 alfabético, 1 numérico|E1, E2| |NGS1.02.11|1 (obrigatório)|Igualdade de senhas — nova senha diferente da atual e da imediatamente anterior|E1| |NGS1.02.12|1 (obrigatório)|Obtenção de nova senha — opção "esqueci a senha" na tela de login|E1| |NGS1.02.13|1 (obrigatório)|Controle de tentativas de login — bloqueio após máximo configurável (≤10)|E1| |NGS1.02.16|1 (obrigatório)|Informações em autenticação inválida — mensagem genérica sem revelar motivo|E1| |NGS1.02.17|1 (obrigatório)|Revelação de credenciais — máscara de caracteres, sem memorização|E1, E2| |NGS1.02.19|2 (recomendado)|Uso de SALT — novo salt para cada senha|E1, E2| |ECF.17.18|1 (obrigatório)|Idioma do S-RES — rótulos, mensagens, menus em português do Brasil|E5| |ECF.17.19|1 (obrigatório)|Mensagens do sistema — linguagem não técnica em português do Brasil|E1, E2, E3, E5| |NGS1.03.01|1 (obrigatório)|Impedir acesso por pessoas não autorizadas — permissões atribuídas a perfis de usuário|E3, E5| |NGS1.03.03|1 (obrigatório)|Gerenciamento de perfis — cadastro, ativação/inativação, atribuição de permissões|E3, E5| |NGS1.03.07|1 (obrigatório)|Atribuição de mais de um perfil para um usuário — mais de um perfil pode ser atribuído a um usuário, um por clínica|E5| |NGS1.03.08|1 (obrigatório)|Gerenciamento de usuários — cadastro, ativação/inativação, alteração|E3| |NGS1.03.09|1 (obrigatório)|Identidade única da pessoa e responsabilização — unicidade de CPF|E1, E2, E3| --- ## 7. Épicos do Conjunto ### 7.1 Status e versões |Épico|Título|Status|Versão|Dependências| |---|---|---|---|---| |E1|Núcleo de Identidade e Autenticação|✅ Finalizado (Seção 1-4 completas)|v2.3|Nenhuma (épico base)| |E2|Auto-cadastro Público|✅ Finalizado (Seção 1-4 completas; pendências de BD registradas em Seção 4 do épico)|v2.0|E1| |E3|Convite e Vínculo|✅ Finalizado (Seção 1-4 completas)|v3.4|E1 (reaproveita definições de campo do E2, sem depender do fluxo)| |E4|Meu Perfil|⏳ A especificar|—|E1, E2| |E5|Menu Lateral|✅ Finalizado (Seção 1-4 completas)|v1.0|E1 (autenticação, clínicas acessíveis); E6 (perfil de acesso vigente na clínica atual, destino do botão Trocar); Contexto de Segurança (configuração de perfis de acesso e itens liberados)| |E6|Seleção de Clínica|✅ Finalizado (Seção 1-4 completas)|v1.3|E1 (roteamento pós-login); E3 (reaproveita aceite de vínculo e verificação de Perfil de acesso)| ### 7.2 Regras de negócio específicas de cada épico As regras abaixo pertencem a um único épico — a redação completa está no documento do épico correspondente. Aqui consta apenas a referência, para não duplicar conteúdo. |RN|Título|Épico dono| |---|---|---| |RN-CIU-001|Documento único como chave de identificação|(CIU-E1), Seção 2| |RN-CIU-002|Unicidade global do usuário|(CIU-E2), Seção 2| |RN-CIU-003|Campos do auto-cadastro|(CIU-E2), Seção 2| |RN-CIU-004|Validação de documento no cadastro|(CIU-E2), Seção 2| |RN-CIU-009|Autenticação|(CIU-E1), Seção 2| |RN-CIU-010|Tentativas de login (parametrizável)|(CIU-E1), Seção 2| |RN-CIU-013|Auto-cadastro não gera vínculo|(CIU-E2), Seção 2| |RN-CIU-016|Sem validação de formato nem máscara no login|(CIU-E1), Seção 2| |RN-CIU-017|Estrutura genérica de conselho profissional|(CIU-E2), Seção 2| |RN-CIU-018|Dados avançados opcionais (SBIS ECF.02.01)|(CIU-E2), Seção 2| |RN-CIU-019|Identificação do tipo de profissional|(CIU-E2), Seção 2| |RN-CIU-020|Máscara de celular parametrizada por país|(CIU-E2), Seção 2| |RN-CIU-021|Documentos condicionais por nacionalidade|(CIU-E2), Seção 2| |RN-CIU-011|Convite de profissional pela clínica|(CIU-E3), Seção 2| |RN-CIU-012|Tela de conclusão de cadastro para convite|(CIU-E3), Seção 2| |RN-CIU-014|Tela de aceite do vínculo|(CIU-E3), Seção 2| |RN-CIU-015|Verificação de Perfil de acesso pós-aceite|(CIU-E3), Seção 2| |RN-CIU-023|Roteamento do link de convite conforme senha já definida|(CIU-E3), Seção 2| |RN-CIU-024|Expiração e cancelamento de convite [PROPOSTA]|(CIU-E3), Seção 2| |RN-CIU-025|Aceite de convite pendente na tela de seleção de clínica|(CIU-E6), Seção 2| |RN-CIU-026|Estrutura e transversalidade do menu lateral|(CIU-E5), Seção 2| |RN-CIU-027|Filtragem de itens do menu por Perfil de acesso|(CIU-E5), Seção 2| |RN-CIU-028|Favoritos do menu|(CIU-E5), Seção 2| |RN-CIU-029|Comportamento responsivo do menu|(CIU-E5), Seção 2| |RN-CIU-030|Busca no menu|(CIU-E5), Seção 2| ### 7.3 Resumo dos épicos finalizados E1 — Núcleo de Identidade e Autenticação (v2.3): Tela de login com documento único + senha, sem máscara nem validação de formato (anti-enumeração). Controle de tentativas parametrizável (QuantidadeTentativas = 5, MinutosBloqueado = 15). Recuperação de senha em 2 etapas com código de 6 dígitos, dupla verificação de documento e critérios de complexidade parametrizados. Antes de aplicar o roteamento por clínicas acessíveis, verifica convite pendente (UsuarioCliente com Situacao = 'C', RN-CIU-022) e direciona para a tela de aceite do vínculo (E3) quando aplicável, apenas para quem ainda não tem nenhum vínculo ativo — quem já tem ao menos um vínculo ativo vê o convite como card no E6; um vínculo só é considerado ativo, para fins de roteamento, quando Situacao = 'V' (RN-CIU-009); a quantidade de clínicas acessíveis é a contagem de ClienteEmpresa distintas associadas aos vínculos ativos via ClientePerfilAcessoUsuario, não a contagem de vínculos, e pode ser 0 mesmo com vínculo(s) ativo(s) quando nenhum Perfil de acesso foi associado ainda, ou quando a `ClienteEmpresa` associada foi desativada (RN-CIU-009, corrigido em 14/09/2026). Mensagens multilíngues (pt-BR, en-US, es-419). Reconstruído no modelo padrão Seção 1-4 (v2.0, 30/08/2026) — deixa de ser legado. 2 histórias de usuário, 19 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 8 tabelas (todas existentes). E2 — Auto-cadastro Público (v2.0): Wizard de 3 etapas (dados básicos com complemento profissional condicional, dados avançados opcionais, definição de senha). Validação de CPF com dígitos verificadores. Verificação de duplicidade de CPF e conselho em tempo real. Estrutura genérica de conselho profissional (tipo, número, UF). Identificação de tipo de profissional de saúde (médico, enfermeira, farmacêutica, psicólogo, etc.). Documentos condicionais por nacionalidade. Dados avançados opcionais conforme SBIS ECF.02.01. Máscara de celular parametrizada por país. Conflito de conselho não bloqueia o cadastro — permite concluir sem conselho. Ao final, autentica automaticamente e direciona sempre para Meu Perfil (RN-CIU-022) — este épico nunca é acessado por quem foi convidado por uma clínica, pois o CPF já estaria cadastrado pelo administrador (RN-CIU-004): a pessoa convidada usa a tela de conclusão de cadastro do E3, não este wizard. Reconstruído no modelo padrão Seção 1-4 (v2.0, 30/08/2026) — deixa de ser legado; as pendências de banco de dados (campos avançados SBIS, estrutura de conselho, tabelas de terminologia) foram trazidas para a Seção 4 do próprio épico (ver Seção 9 abaixo). 2 histórias de usuário, 22 critérios de aceitação, 6 fluxos de exceção, 4 endpoints, 4 tabelas existentes. E3 — Convite e Vínculo (v3.4): Administrador da clínica cadastra CPF, e-mail, celular e nome de um profissional, o que cria diretamente a conta (Usuario, sem senha) e o vínculo em situação de convite (UsuarioCliente com Situacao = 'C', RN-CIU-011), e dispara um e-mail com link de convite. O link leva a uma tela própria de conclusão de cadastro (RN-CIU-012, confirmação/complemento de dados + definição de senha) se a senha ainda não foi definida, ou ao login normal (E1) se já foi (RN-CIU-023). Ao autenticar sem nenhum vínculo ativo, convite pendente direciona para a tela de aceite do vínculo — leitura das regras básicas e aceite explícito, que atualiza o vínculo existente para Situacao = 'V' (RN-CIU-014; com ao menos um vínculo ativo, o aceite ocorre em E6, RN-CIU-025). Administrador pode selecionar o Perfil de acesso já no cadastro do convite — e, junto dele, a(s) clínica(s) (ClienteEmpresa) às quais aquele perfil se aplica, já que um Cliente pode ter mais de uma; se não, a seleção de ambos fica pendente, e o vínculo permanece bloqueado (RN-CIU-015) até que o administrador os associe posteriormente — fluxo de gestão de usuários da clínica fora do escopo deste épico. Token e prazo de validade do convite não são atributos de UsuarioCliente (o vínculo permanente) — ficam em tabela complementar nova, `UsuarioClienteConvite`, com dado apagado fisicamente assim que o convite é resolvido (aceito, cancelado ou expirado); prazo parametrizado em 7 dias (`UsuarioSenhaParametros.DiasValidadeConviteVinculo`). Convite expirado sem senha nunca definida: rotina periódica exclui logicamente Usuario + UsuarioCliente. Restruturado no modelo padrão da Skill Designer (Seção 1-4, v3.0); v3.2 corrigiu a granularidade Cliente × ClienteEmpresa na seleção de Perfil de acesso; v3.3 ajustou a redação de RN-CIU-011 sobre o que acontece quando essa seleção fica pendente, e corrigiu uma referência cruzada desatualizada ao E1; v3.4 restringiu o campo "Clínica(s)" a `ClienteEmpresa` ativas (14/09/2026). 2 histórias de usuário, 14 critérios de aceitação, 7 fluxos de exceção (todos confirmados), 6 endpoints, 6 tabelas existentes, 1 tabela nova (UsuarioClienteConvite). Seção 3 (Protótipo HTML) ainda pendente. E5 — Menu Lateral (v1.0): Ponto único de navegação entre os módulos liberados pelo perfil de acesso do profissional na clínica em que está trabalhando — transversal a qualquer profissional autenticado, não uma tela exclusiva de um perfil. Itens organizados em grupos de uma única camada (sem sub-grupos), filtrados e ordenados pelo Perfil de acesso vigente (RN-CIU-027); sem nenhum item liberado, exibe mensagem orientando a contatar o administrador da clínica (EX-E5-01). Seção Favoritos, destacada no topo, some por completo quando não há nenhum favorito; favoritos são específicos da combinação vínculo × perfil × clínica — um item favoritado numa clínica não aparece necessariamente favoritado ao trocar para outra, e o menu inteiro recarrega a cada troca de clínica (RN-CIU-028). Busca em tempo real, resolvida no front-end sobre a árvore já carregada, achata os grupos durante a digitação (RN-CIU-030). No desktop, o menu recolhido mostra só os ícones dos favoritos e libera espaço para o conteúdo; no mobile, abre como camada sobre o conteúdo, sem redimensioná-lo (RN-CIU-029). Botão "Trocar" (destino: E6) visível apenas com mais de uma clínica acessível (RN-CIU-009, em CIU-E1). Nenhuma tabela nova — estrutura de itens, agrupamento, habilitação por cliente, liberação/ordem por perfil de acesso e favoritos já existe por completo no banco IpSeguranca (`Processo`, `ProcessoGrupo`, `ClienteProcesso`, `ClientePerfilAcessoProcesso`, `ClienteUsuarioMenuFavorito`); um schema legado equivalente (`GescomZeradoPadronizacao.dbo.SegMenu`/`SegPastaMenu`/`SegMenuGrupo`/`SegMenuDetalhe`) foi identificado e descartado por pertencer ao template pré-Clean-Architecture, sem os conceitos de Cliente/ClienteBD/ClienteEmpresa/Perfil de acesso do projeto atual. Árvore completa de grupos/itens do menu em produção não disponível (levantamento original perdido) — itens usados na Especificação e no Protótipo são exemplos, claramente marcados como tal. 1 história de usuário, 9 critérios de aceitação, 4 fluxos de exceção, 3 endpoints, 8 tabelas existentes (nenhuma nova). E6 — Seleção de Clínica (v1.3): Tela exibida após o login quando o profissional tem acesso a mais de uma clínica, ou tem ao menos um vínculo ativo e um convite pendente simultâneo (RN-CIU-022, item 2). Lista as clínicas acessíveis (nome e logo, de `ClienteEmpresa`) e, separado dela, um card em destaque por convite pendente, aceito sem releitura das regras básicas (RN-CIU-025) — aceitar não seleciona nenhuma clínica automaticamente, apenas as adiciona à lista (podendo ser mais de uma de uma vez), e a verificação de Perfil de acesso (RN-CIU-015, reaproveitada do E3) só roda na seleção manual, não no aceite. Nenhuma tabela nova — reaproveita integralmente UsuarioCliente, ClienteEmpresa, ClientePerfilAcesso, ClientePerfilAcessoUsuario e UsuarioClienteConvite, já mapeadas no E3. Personas ampliadas (v1.2) para reconhecer também quem chega a esta tela ao aceitar seu primeiro vínculo (E3), quando ele já dá acesso a mais de uma `ClienteEmpresa`; nomes de campos padronizados entre E3 e E6 (`clienteEmpresas`/`clienteEmpresaId`) e o array de convites pendentes do endpoint de listagem renomeado para `convites`, para não colidir com o campo numérico de mesmo nome no login (E1). 2 histórias de usuário, 9 critérios de aceitação, 5 fluxos de exceção (um marcado como proposta — cenário de borda), 3 endpoints, protótipo HTML atualizado na v1.1 para refletir o endpoint de seleção com 2 identificadores no path; v1.3 passou a filtrar a Lista de Clínicas às apenas `ClienteEmpresa` ativas. --- ## 8. Convenções de Documentação ### Estrutura de cada épico Cada épico é uma instância completa da metodologia Skill Designer — Seção 1 (Definição), Seção 2 (Especificação), Seção 3 (Protótipo HTML) e Seção 4 (Mapeamento de Banco de Dados), restrita ao escopo daquele épico (ver "Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos" na Skill Designer). Não há uma estrutura própria de épico definida neste documento — a estrutura vive em um lugar só, na Skill Designer, e vale tanto para um documento único quanto para cada filho de um guarda-chuva. **Não há mais épicos legados neste conjunto.** E1 e E2 foram construídos originalmente com uma estrutura própria de 12 itens (Visão Geral, Regras de Negócio, Histórias de Usuário, Descrição Funcional, Critérios de Aceitação, Fluxos de Exceção, Validações de Campos, Mapeamento de Componentes, Integração com Backend, Catálogo de Mensagens, Conformidade SBIS, Metadados) — sem Seção 3 (Protótipo HTML) nem Seção 4 (Mapeamento de BD) completa. Reconstruídos integralmente no modelo padrão Seção 1-4 em 30/08/2026 (E1 v1.9 → v2.0, E2 v1.6 → v2.0), a pedido do solicitante — mesmo tratamento já aplicado ao E3 (v2.1 → v3.0); E4, E5 e E6 já seguiam a Seção 1-4 da Skill Designer desde a criação. Dois itens da estrutura legada provaram valor e foram promovidos ao padrão único da Skill Designer — deixam de ser exclusividade de épico: Fluxos de Exceção como catálogo com ID próprio (não só um bullet) e Catálogo de Mensagens do Sistema e Termos de Interface (i18n) como sub-seção oficial. Ambos agora fazem parte da Seção 2 — Especificação de qualquer documento deste projeto, não só de épicos. ### Numeração - Regras de negócio: RN-CIU-XXX (CIU = Check-in de Usuários) - Histórias de usuário: US-CIU-XXX - Critérios de aceitação: CA-XXX.X - Fluxos de exceção: EX-EXX-XX, vinculado ao épico (ex.: EX-E3-01) — corrigido nesta revisão: a prática real desde o E1 já segue esse padrão por épico, não o "EX-XXX global" descrito em revisões anteriores deste documento - Mensagens: MSG-EXX (erro), MSG-SXX (sucesso), MSG-IXX (informativa), MSG-PXX (placeholder), MSG-TXX (texto orientador), MSG-BXX (botão/link), MSG-CXX (checkbox) ### Separação de preocupações - Regras de Negócio: descrevem o que o sistema faz, em linguagem de negócio. Sem nomes de tabelas, campos ou mecanismos técnicos. - Descrição Funcional: descreve como o sistema funciona, incluindo detalhes técnicos (campos de banco, mecanismos de hash/salt, etc.). - Mapeamento de Tabelas: lista as tabelas e campos utilizados, com o banco de dados correspondente. --- ## 9. Bancos de Dados Utilizados |Banco|Descrição|Uso no Check-in| |---|---|---| |IpSeguranca|Segurança e configuração|Tabelas Usuario, UsuarioSenhaHistorico, UsuarioSenhaParametros, UsuarioCliente, Processo, ProcessoGrupo, ClienteProcesso, ClientePerfilAcessoProcesso, ClienteUsuarioMenuFavorito| |IpTerminologia|Tabelas de domínio|Listas de tipos de conselho, tipos de profissional, especialidades, CBO| ### Tabelas existentes utilizadas |Tabela|Banco|Épicos| |---|---|---| |Usuario|IpSeguranca|E1, E2, E3| |UsuarioSenhaHistorico|IpSeguranca|E1, E2| |UsuarioSenhaParametros|IpSeguranca|E1, E2| |UsuarioCliente|IpSeguranca|E1, E2, E3| |ClientePerfilAcesso|IpSeguranca|E3, E5| |ClientePerfilAcessoUsuario|IpSeguranca|E1, E3, E5, E6| |ClienteEmpresa|IpSeguranca|E1, E3, E5, E6| |Cliente|IpSeguranca|E1| |ClienteBD|IpSeguranca|E1| |Processo|IpSeguranca|E5| |ProcessoGrupo|IpSeguranca|E5| |ClienteProcesso|IpSeguranca|E5| |ClientePerfilAcessoProcesso|IpSeguranca|E5| |ClienteUsuarioMenuFavorito|IpSeguranca|E5| ### Campos e tabelas a criar (pendências de BD) - Campos de dados avançados (SBIS ECF.02.01), estrutura genérica de conselho profissional/tipo de profissional e tabelas de terminologia (IpTerminologia) — pendências do E2, consolidadas na Seção 4 do próprio épico desde 30/08/2026 (antes viviam apenas aqui, como nota textual sem seção própria — Lição #10 da Skill Designer: uma informação em um lugar só). Ver (CIU-E2), Seção 4, "Pendências de banco de dados". - **[PROPOSTA]** Domínio do campo `UsuarioCliente.Situacao` (IpSeguranca) — C (Convidado), V (Vinculado), B (Bloqueado); não documentado anteriormente em EsquemaGemed21.csv. - **[PROPOSTA]** Tabela nova `UsuarioClienteConvite` (IpSeguranca) — token e prazo de validade do convite não são atributos do vínculo permanente (`UsuarioCliente`), por isso ficam numa tabela complementar própria, útil apenas entre o convite e sua resolução (aceite, cancelamento ou expiração), quando o registro é apagado fisicamente. PK/FK `UsuarioClienteId` → `UsuarioCliente.Id`, campos `Token` e `DataExpiracao`. Substitui a proposta anterior de duas colunas (`TokenConvite`, `DataExpiracaoConvite`) na própria tabela `UsuarioCliente` — rejeitada pelo solicitante em 27/08/2026 por não pertencerem à entidade de vínculo. Detalhamento completo, com justificativa da modelagem, em (CIU-E3), Seção 4. - O Menu Lateral (E5) não adiciona pendência de schema — as duas lacunas registradas no próprio épico (árvore completa de itens do menu; interpretação do campo `ClienteUsuarioMenuFavorito.ProcessoAbertura`) são pendências de conteúdo/dado e de confirmação de significado, não de estrutura; ver (CIU-E5), Seção 4, "Seeds da Funcionalidade". --- ## 10. Metadados | Atributo | Valor | | ------------------------------ | ------------------------------------------------------------ | | Funcionalidade pai | Check-in de Usuários no Sistema | | Workflows do profissional documentados | 1 (Entrada do profissional no sistema — E1 + E2) | | Épicos finalizados | 5 (E1 v2.3, E2 v2.0, E3 v3.4, E5 v1.0, E6 v1.3) — nenhum épico legado; todos no modelo padrão Seção 1-4 | | Épicos pendentes | 1 (E4) | | Regras de negócio transversais (redação completa nesta seção) | 5 (RN-CIU-005, 006, 007, 008, 022) | | Regras de negócio específicas de épico (referenciadas aqui) | 25 (RN-CIU-001, 002, 003, 004, 009, 010, 011, 012, 013, 014, 015, 016, 017, 018, 019, 020, 021, 023, 024, 025, 026, 027, 028, 029, 030) | | Requisitos SBIS aplicáveis | 18 | | Bancos utilizados | 2 (IpSeguranca, IpTerminologia) | | Tabelas existentes utilizadas | 14 | | Pendências de BD | 4 grupos (dados avançados, conselho genérico, terminologias, domínio Situacao [PROPOSTA] + tabela UsuarioClienteConvite [PROPOSTA]) — mais 1 lacuna comportamental registrada como [A DEFINIR] na Seção 2.2 (mecanismo de desativação de ClienteEmpresa; o efeito sobre o acesso já está confirmado); o Menu Lateral (E5) não contribui pendência de schema, só de conteúdo/dado (ver Seção 9) | | Idiomas suportados | 3 (pt-BR, en-US, es-419) | --- ## 11. Histórico de Versões - **v1.0** (12/08/2026) — versão original, 9 regras de negócio transversais (incluía regras que hoje são específicas de épico). - **v1.1** (27/08/2026) — numeração de RN reorganizada: 4 regras verdadeiramente transversais com redação única aqui; as demais movidas para o épico dono, apenas referenciadas aqui. - **v2.0** (27/08/2026) — estrutura reorganizada conforme a nova seção "Funcionalidades Grandes: Documento Guarda-Chuva + Documentos Filhos" da Skill Designer: adicionada a Seção 4 (Workflows do Profissional, antes inexistente); consolidada em uma única tabela (Seção 7.2) a lista de RN específicas por épico, que antes vivia apenas ao final da Seção 5; Requisitos SBIS movidos para logo após as Regras de Negócio (Seção 6), refletindo a ordem Definição → RN → SBIS da metodologia. - **v2.1** (27/08/2026) — resolvida a lacuna registrada na v2.0 sobre o handoff E2→E1: confirmado que o auto-cadastro autentica automaticamente o profissional ao final, direcionando para Meu Perfil (decisão do usuário do projeto, 27/08/2026). Criada RN-CIU-022 (transversal) para registrar essa decisão; atualizados a Seção 4.1 (touchpoint e nota) e os Metadados. - **v2.2** (27/08/2026) — correção da RN-CIU-022: a decisão da v2.1 cobria apenas o auto-cadastro sem convite (permanece correta para esse caso). Adicionado o segundo cenário, descrito pelo solicitante no mesmo dia: profissional convidado por uma clínica (E3) antes de se cadastrar ou logar. RN-CIU-022 reescrita para descrever o roteamento por convite pendente, cobrindo ambos os cenários; a extensão da verificação de convite ao fluxo de login (E1), além do pós-cadastro (E2), é uma proposta de consistência não explicitamente confirmada pelo solicitante (marcada como tal na própria regra). Adicionado o Épico 3 (Convite e Vínculo, v1.0), elaborado nesta mesma revisão — inclui a proposta de tabela nova `Convite` (IpSeguranca), não existente em EsquemaGemed21.csv. Atualizadas as Seções 2, 4, 5, 6, 7, 9, 10 e este Histórico. - **v2.3** (27/08/2026, mesmo dia) — atualização de referência: o Épico 3 foi revisado para v1.1 (duas correções do solicitante na RN-CIU-015 — projeto não possui DOC-001 acessível, referência removida; "Perfil de acesso" esclarecido como distinto de "perfil profissional"). Nenhum conteúdo deste documento guarda-chuva foi alterado além da atualização do número de versão do E3 nas Seções 7.1, 7.3, 10 e neste Histórico. - **v2.4** (27/08/2026, mesmo dia) — arquitetura de convite redesenhada, a pedido do solicitante: em vez de uma tabela nova `Convite`, o administrador cria a conta do usuário diretamente ao registrar o convite (Usuario + UsuarioCliente com Situacao = 'C' — domínio C/V/B definido nesta revisão, RN-CIU-011 em (CIU-E3)). O roteamento do link de convite passou a se basear na existência de senha (Usuario.Hash nulo ou não — RN-CIU-023), em vez de na existência prévia de Usuario; quem ainda não definiu senha vai a uma tela própria de conclusão de cadastro do E3 (RN-CIU-012), não mais ao auto-cadastro pré-preenchido do E2. Como consequência: o E2 (v1.6) reverteu integralmente sua participação no fluxo de convite — nunca é alcançado por uma pessoa convidada, pois o CPF já estaria duplicado (RN-CIU-004); o E1 (v1.9) corrigiu a definição de "vínculo ativo" (RN-CIU-009) para exigir Situacao = 'V', não apenas RemovidoEm nulo; o E3 foi reescrito integralmente (v2.0). Atualizadas as Seções 4, 5 (RN-CIU-022), 7, 9, 10 e este Histórico. - **v2.5** (27/08/2026, mesmo dia) — RN-CIU-022 refinada, a pedido do solicitante, resolvendo a proposta sinalizada na v2.4 sobre estender a verificação de convite pendente ao login manual (E1): confirmado que se aplica, mas com um desdobramento novo — profissional com pelo menos um vínculo ativo que recebe um convite não passa mais pela tela cheia de aceite do E3 (RN-CIU-014, agora escopada a quem não tem nenhum vínculo ativo); o convite aparece como card na tela de seleção de clínica (E6), aceito sem releitura das regras básicas, já lidas no primeiro vínculo. Criada RN-CIU-025 (específica do E6, referenciada na Seção 7.2) e ajustada RN-CIU-014 em (CIU-E3), que passou para v2.1. Seção 8 (Convenções de Documentação) reescrita: épicos deixam de ter uma estrutura própria de 12 itens e passam a usar a Seção 1-4 da Skill Designer, como qualquer documento — E1/E2/E3 mantidos como legado, sem reestruturação retroativa; Fluxos de Exceção e Catálogo de Mensagens/i18n promovidos a sub-seções oficiais da Seção 2 na Skill Designer. Corrigida também a convenção de numeração de Fluxos de Exceção nesta seção (EX-EXX-XX por épico, refletindo a prática já usada desde o E1 — não o "EX-XXX global" que estava documentado). - **v2.6** (27/08/2026, mesmo dia) — Seção 4.1 ("Entrada do profissional no sistema") consolidada a pedido do solicitante: a linha da tabela de touchpoints sobre "profissional convidado por uma clínica" foi reescrita para refletir, num texto coeso, o roteamento já registrado em RN-CIU-022 (Seção 5); os parágrafos fragmentados que narravam o histórico da decisão (várias correções e ampliações sucessivas ao longo do dia) foram removidos do corpo — essa narrativa já está preservada neste Histórico de Versões (entradas v2.1 a v2.5) — e substituídos por uma única frase de referência cruzada a RN-CIU-022. *Nota de processo: esta consolidação havia sido aplicada diretamente no arquivo de trabalho antes desta entrada, sem arquivamento prévio da v2.5 nem registro de versão — falha na disciplina de versionamento do próprio projeto. Corrigida agora: a v2.5 (já incluindo a consolidação da Seção 4.1) foi arquivada em Histórico/ antes desta v2.6, e o incidente está registrado aqui para rastreabilidade.* Seção 9 ("Campos e tabelas a criar") atualizada: a proposta de duas colunas (`TokenConvite`, `DataExpiracaoConvite`) em `UsuarioCliente` foi rejeitada pelo solicitante — token e data de expiração não são atributos do vínculo permanente — e substituída pela proposta de tabela complementar nova `UsuarioClienteConvite`, detalhada em (CIU-E3), Seção 4. Seções 7.1, 7.3 e 10 atualizadas para refletir a reconstrução do Épico 3 no modelo padrão da Skill Designer (v3.0, Seção 1-4 completas) e o estágio atual do Épico 6 (v0.1, Seção 1 concluída — antes não refletido nestas tabelas). - **v2.7** (27/08/2026, mesmo dia) — Épico 6 completado no modelo padrão Seção 1-4 (v1.0): Seções 2, 3 e 4 desenvolvidas, com protótipo HTML produzido. Confirma que nenhuma tabela nova é necessária — reaproveita integralmente a estrutura já mapeada em CIU-E3. Seções 7.1, 7.3 e 10 deste guarda-chuva atualizadas: E6 passa de "em definição" para "finalizado"; adicionado o resumo do Épico 6 à Seção 7.3, junto aos demais épicos finalizados; contagem de épicos finalizados em 10 passa de 3 para 4. Seção 8 corrigida: a nota "Legado (E1, E2, E3)" estava desatualizada desde a v2.6 (quando o E3 deixou de ser legado) — agora lista corretamente apenas E1 e E2 como legado. - **v2.8** (27/08/2026, mesmo dia) — quatro propostas do E3 confirmadas pelo solicitante, refletidas no épico (v3.1) e propagadas até aqui: prazo de validade do convite (7 dias) parametrizado em `UsuarioSenhaParametros.DiasValidadeConviteVinculo`, mesma tabela usada pelos parâmetros de senha (RN-CIU-006) — nota cruzada adicionada a RN-CIU-006 apontando para RN-CIU-024 (CIU-E3), para deixar claro que a tabela agora serve dois propósitos distintos. Seções 7.1 e 7.3 atualizadas com a versão e o resumo do E3 (v3.1): 5 tabelas existentes (adicionada UsuarioSenhaParametros), 7 fluxos de exceção todos confirmados, seleção de Perfil de acesso já no convite e rotina de expiração confirmadas. - **v2.9** (30/08/2026) — E1 e E2 reconstruídos integralmente no modelo padrão Seção 1-4 da Skill Designer, a pedido do solicitante ("recrie CIU-E1 e CIU-E2 no novo formato") — E1 de v1.9 para v2.0, E2 de v1.6 para v2.0 — mesmo tratamento já aplicado ao E3 (v2.1 → v3.0). Este conjunto não tem mais nenhum épico legado (Seção 8 corrigida). As pendências de banco de dados do E2 (campos avançados SBIS ECF.02.01, estrutura genérica de conselho, tabelas de terminologia), antes registradas apenas na Seção 9 deste documento, foram consolidadas na Seção 4 do próprio épico (CIU-E2) — este documento passa a apenas referenciá-las (Lição #10 da Skill Designer: uma informação em um lugar só); nenhuma delas foi resolvida, seguem [A DEFINIR]. Seções 7.1, 7.3, 8, 9 e 10 atualizadas. Nome do arquivo deste documento atualizado de `00 - Guarda-chuva v2.8.md` para `00 - Guarda-chuva v2.9.md` — cabeçalho de irmãos de (CIU-E3) e (CIU-E6) atualizado para apontar para o novo nome. - **v2.10** (14/09/2026) — corrigida a RN-CIU-022 (item 3) e propagada a três épicos: o roteamento pós-login entre cockpit direto e seleção de clínica (E6) decidia pela quantidade de vínculos ativos (registros em UsuarioCliente); a granularidade correta é a quantidade de clínicas (`ClienteEmpresa`) acessíveis, já que um único vínculo (com um Cliente) pode compreender mais de uma `ClienteEmpresa` — filiais de uma mesma rede, ou clínicas de um conglomerado que não compartilham dados entre si. Achado ao consultar a Biblioteca de Schema (DDL) a pedido do solicitante durante a especificação do Menu Lateral (ainda não parte deste conjunto), que confirmou a granularidade e a regra de que o administrador escolhe clínicas específicas ao atribuir um Perfil de acesso (não há liberação automática de todas as `ClienteEmpresa` de um Cliente). Corrigidos E1 (v2.0 → v2.1, RN-CIU-009), E3 (v3.1 → v3.2, RN-CIU-011/015, novo campo "Clínica(s)" no cadastro de convite) e E6 (v1.0 → v1.1, Lista de Clínicas e card de convite por `ClienteEmpresa`, não por `Cliente`) — nenhum dos três precisou de tabela nova, `ClienteEmpresa` já existe em produção. Adicionada `ClienteEmpresa` às tabelas existentes utilizadas (Seção 9); `ClientePerfilAcessoUsuario` passa a constar também como usada por E1 e E6. Seções 5, 7.1, 7.3, 9 e 10 atualizadas. - **v2.11** (14/09/2026) — correções apontadas por revisão de negócio e técnica sobre a v2.10, mesmo dia: (1) RN-CIU-022 item 1 passa a descrever os três destinos possíveis após o aceite do primeiro vínculo (cockpit, seleção de clínica E6, ou bloqueio), não apenas dois — alinhado à RN-CIU-015 (CIU-E3), que já previa o encaminhamento ao E6 quando o primeiro vínculo dá acesso a mais de uma `ClienteEmpresa`; (2) RN-CIU-022 item 2 corrigido — o parêntese que descrevia "1 vínculo ativo" como sinônimo de ida direta ao cockpit sem convite era um resquício da granularidade antiga, substituído por "clínicas acessíveis", como o item 3 já refletia; (3) RN-CIU-022 item 3 esclarecido: 0 clínicas acessíveis pode ocorrer tanto por 0 vínculos ativos quanto por vínculo(s) ativo(s) sem nenhum Perfil de acesso associado — mesma correção propagada ao E1 (RN-CIU-009); (4) título da RN-CIU-022 e o parágrafo de aplicação ao login manual reescritos em linguagem atemporal, sem data/versão no corpo — a proveniência (confirmação do solicitante em 27/08/2026) permanece registrada nas entradas v2.2/v2.5 deste Histórico; (5) adicionada, na Seção 2.2, a lacuna [A DEFINIR] sobre o comportamento quando uma `ClienteEmpresa` que hoje dá acesso a um profissional é desativada — não resolvida, apenas registrada; (6) Seção 9 (Tabelas existentes utilizadas) ganhou `Cliente` e `ClienteBD`, usadas por E1 para compor nome/logo do Cliente na resposta do login — lacuna de mapeamento encontrada na revisão técnica. Corrigidos também E1 (v2.1 → v2.2), E3 (v3.2 → v3.3) e E6 (v1.1 → v1.2) — detalhamento em cada épico. Seções 2, 5, 7.1, 7.3, 9, 10 e este Histórico atualizados. - **v2.12** (14/09/2026) — confirmado pelo solicitante o efeito da desativação de uma `ClienteEmpresa`: todos os usuários hoje associados a ela perdem o acesso a essa clínica (deixa de contar como clínica acessível). Bullet da Seção 2.2 reescrito para registrar esse efeito como fato confirmado, mantendo apenas o mecanismo de desativação em si (quando/como é acionado) como [A DEFINIR], fora do escopo deste conjunto — pertence à gestão de usuários da clínica. `ClienteEmpresa` já tem o campo `RemovidoEm` (soft delete, mesmo padrão usado em todo o schema — confirmado na Biblioteca de Schema (DDL), `IpSeguranca.sql`), mas nenhum dos 3 épicos filtrava por ele nas consultas de clínica acessível/lista de clínicas/multi-select de convite — corrigidos E1 (v2.2 → v2.3, RN-CIU-009 e Mapeamento de BD), E3 (v3.3 → v3.4, RN-CIU-011, campo "Clínica(s)" do convite e Mapeamento de BD) e E6 (v1.2 → v1.3, RN-CIU-025, Lista de Clínicas e Mapeamento de BD) para filtrar `RemovidoEm IS NULL` em `ClienteEmpresa`. Seções 7.1, 7.3 e 10 atualizadas. Nome do arquivo atualizado de `00 - Guarda-chuva v2.11.md` para `00 - Guarda-chuva v2.12.md` — cabeçalho de irmãos de (CIU-E1), (CIU-E3) e (CIU-E6) atualizado para apontar para o novo nome. - **v2.13** (15/09/2026) — criado o Épico 5 (Menu Lateral, v1.0), confirmando o achado registrado na entrada v2.10 deste Histórico ("ainda não parte deste conjunto"): o menu lateral de navegação, transversal a qualquer profissional autenticado, é agora um épico completo (Seção 1-4). Estrutura de dados localizada por inteiro na Biblioteca de Schema (DDL), banco IpSeguranca (`Processo`, `ProcessoGrupo`, `ClienteProcesso`, `ClientePerfilAcessoProcesso`, `ClienteUsuarioMenuFavorito`) — nenhuma tabela nova; um schema legado equivalente (`GescomZeradoPadronizacao.dbo.SegMenu`/`SegPastaMenu`/`SegMenuGrupo`/`SegMenuDetalhe`) foi identificado e descartado por não ter os conceitos de tenant/clínica/perfil de acesso do projeto atual. Criadas RN-CIU-026 a RN-CIU-030 (específicas do E5): estrutura e transversalidade do menu, filtragem por Perfil de acesso, favoritos (com o achado de que a granularidade por clínica de `ClientePerfilAcessoUsuario` faz o favorito não se repetir automaticamente entre clínicas), comportamento responsivo (recolhido/expandido no desktop, overlay no mobile) e busca em tempo real. Duas lacunas de conteúdo (não de schema) registradas no próprio épico: a árvore completa de grupos/itens do menu em produção, e a interpretação do campo `ClienteUsuarioMenuFavorito.ProcessoAbertura` — ambas [PROPOSTA], a confirmar contra o mockup original, hoje indisponível. Seções 2.1 (novo bullet de escopo), 4.1 (nota de encerramento do workflow transversal), 5 (RN-CIU-022, nota de handoff ao menu), 6 (2 requisitos SBIS novos — ECF.17.18, NGS1.03.07 — e 2 linhas existentes ganharam E5), 7.1, 7.2 (5 RNs novas), 7.3 (resumo do E5), 8 (E5 confirmado como não-legado), 9 (5 tabelas novas na lista, 3 linhas existentes ganharam E5) e 10 atualizadas. Nome do arquivo atualizado de `00 - Guarda-chuva v2.12.md` para `00 - Guarda-chuva v2.13.md` — cabeçalho de irmãos de (CIU-E1), (CIU-E3), (CIU-E5) e (CIU-E6) atualizado para apontar para o novo nome.