Requisição 196 — Página Inicial por Perfil de Usuário e Mapeamento Dinâmico de Layout por Perfil nas Páginas

Origem: Solicitação do Engenheiro Chefe Humano (2026-09-30) decorrente dos testes de homologação do portal do cliente no conn2flow-site (REQ-073).
Lote Vinculado: BATCH-200 (conn2flow core).
Status: ready-for-intake.
Repositório: [REDACTED]

1. Contexto e Motivação

1. Página Inicial pós-login por Perfil (usuarios-perfis):

   • Atualmente, ao efetuar login no sistema, todos os usuários são redirecionados indiscriminadamente para o mesmo destino padrão (/dashboard/).

   • Perfis de clientes ou usuários com funções específicas necessitam ser direcionados imediatamente para rotas especializadas (ex: /minha-hospedagem/, /user-subscription/, /loja/, etc.).

   • O módulo administrativo usuarios-perfis deve permitir configurar formalmente a página inicial de destino pós-login por perfil.

2. Mapeamento de Múltiplos Layouts por Perfil em paginas:

   • No modelo atual do Conn2Flow, cada registro da tabela paginas possui uma única coluna referencial layout.

   • Com o advento de portais de autoatendimento com layout próprio (como o layout-portal-cliente do conn2flow-site), surge uma quebra de consistência: páginas compartilhadas entre perfis (como /perfil-usuario/) precisam ser renderizadas com o layout do portal do cliente para consumidores finais, mas devem preservar o layout administrativo padrão para a equipe interna.

   • É necessário estender o modelo de dados de paginas, os CRUDs administrativos (publisher-pages e admin-paginas), o roteador central (gestor_roteador) e os controladores de sincronização de recursos para permitir mapear layouts específicos por perfil de usuário.

2. Escopo Detalhado por Item

? Item 1 — Módulo usuarios-perfis: Abas e Seleção de Página Inicial pós-login

• Arquivos: gestor/modulos/usuarios-perfis/ (PHP, JS, JSON e templates).

• Interface e Comportamento:

  1. No formulário de inclusão/edição de perfis (usuarios-perfis), transformar a estrutura do formulário em abas:

     • Aba "Módulos": Contém a listagem atual de permissões de módulos e operações.

     • Aba "Acesso": Nova aba para configurações gerais de acesso daquele perfil.

  2. Dentro da aba "Acesso":

     • Incluir campo de seleção com autocomplete pesquisando todas as páginas ativas da tabela paginas (id, nome, caminho).

     • Rótulo: "Página Inicial pós-login" (placeholder: "Padrão do sistema (/dashboard)").

     • Valor salvo: identificador ou caminho da página escolhida.

  3. Persistência:

     • Adicionar coluna pagina_inicial (VARCHAR(255) NULL) na tabela usuarios_perfis via migração Phinx.

  4. Lógica de Redirecionamento no Login:

     • No fluxo de autenticação pós-login (autenticacao.php ou rotina de finalização de login):

     • Obter o perfil do usuário autenticado. Se o campo pagina_inicial estiver preenchido com uma rota válida, redirecionar o usuário para ela. Caso contrário, aplicar o fallback padrão do sistema (/dashboard).

? Item 2 — Schema do Banco: Coluna layouts_users_profiles em paginas

• Migração: Criar migração Phinx em gestor/db/migrations/ alterando a tabela paginas:

  • Coluna: layouts_users_profiles

  • Tipo: JSON (ou LONGTEXT para compatibilidade MariaDB/MySQL legados), NULL por padrão.

? Item 3 — CRUDs Administrativos (publisher-pages e admin-paginas)

• Arquivos:

  • gestor/modulos/admin-paginas/

  • gestor/modulos/publisher-pages/

• Interface e Comportamento:

  1. No campo onde é selecionado o layout:

     • Adicionar um controle de Toggle (ou checkbox estilizado): "Mapear layouts por perfil de usuário".

     • Toggle Desligado (Padrão): Exibe apenas o campo select/autocomplete simples de layout padrão (layout), como funciona hoje.

     • Toggle Ligado:

     • Exibe um componente repetidor dinâmico (pares chave-valor):

       • Coluna 1: Layout (select/autocomplete dos layouts do sistema).

       • Coluna 2: Perfil de Usuário (select/autocomplete dos perfis cadastrados em usuarios_perfis).

       • Ações: Botão "Adicionar mapeamento" (+) e botão de exclusão de linha (lixeira/remover).

  2. Persistência:

     • O valor padrão layout permanece como layout fallback obrigatório.

     • A coleção mapeada é gravada como objeto JSON na coluna layouts_users_profiles:

       {
       "layout-id-1": "user-profile-id-1",
       "layout-id-2": "user-profile-id-2"
       }

? Item 4 — Roteamento Central em gestor/gestor.php

• Arquivo: gestor/gestor.php

• Função: gestor_roteador()

• Comportamento Normativo:

  1. No trecho onde a página é localizada e sua referência de layout é extraída:

  2. Verificar se a coluna layouts_users_profiles está preenchida na página resolvida:

     • Decodificar o JSON para array associativo.

     • Identificar o perfil do usuário logado na sessão ativa ($_GESTOR['usuario']['id_usuarios_perfis'] ou identificador do perfil).

     • Iterar sobre o mapeamento: se o perfil do usuário atual der match com algum perfil mapeado, o layout referenciado no mapeamento substitui o layout padrão.

     • Caso o usuário não esteja logado (visitante) ou seu perfil não conste no mapeamento, utilizar o layout padrão da coluna layout.

? Item 5 — Serialização em Recursos JSON e Controladores de Sincronização

• Arquivos:

  • gestor/resources/pt-br/pages.json e gestor/resources/en/pages.json

  • Manifestos de páginas em módulos (*.json)

  • gestor/controladores/atualizacoes/atualizacoes-banco-de-dados.php

  • gestor/controladores/agents/arquitetura/atualizacao-dados-recursos.php

  • gestor/controladores/agents/arquitetura/recuperacao-dados-recursos.php

• Comportamento Normativo:

  1. Garantir que a propriedade layouts_users_profiles seja suportada nos manifestos JSON de páginas:

     "layouts_users_profiles": {
     "layout-id-1": "user-profile-id-1",
     "layout-id-2": "user-profile-id-2"
     }

  2. Atualização de Banco: No controlador atualizacoes-banco-de-dados.php, incluir a coluna layouts_users_profiles nas rotinas de sincronização/atualização das tabelas de páginas a partir dos dados do projeto e core (PaginasData.json).

  3. Atualização e Recuperação de Recursos: Nos controladores de arquitetura (atualizacao-dados-recursos.php e recuperacao-dados-recursos.php), garantir a extração e recomposição bidirecional do campo layouts_users_profiles durante compilações e geração de manifests.

3. Critérios de Aceite

1. Página Inicial em usuarios-perfis: O formulário exibe as abas "Módulos" e "Acesso"; o autocomplete de página inicial grava e recupera a rota; o login com usuário desse perfil redireciona diretamente para a rota configurada.

2. Migrações Limpas: As migrações de usuarios_perfis (pagina_inicial) e paginas (layouts_users_profiles) executam com sucesso no MariaDB sem afetar registros legados.

3. Toggle de Mapeamento: admin-paginas e publisher-pages permitem alternar entre layout padrão e pares dinâmicos de layout ➔ perfil, com adição e remoção fluida de itens.

4. Roteamento Dinâmico: gestor_roteador() aplica o layout mapeado correspondente ao perfil do usuário autenticado e mantém o layout padrão para usuários não mapeados ou anônimos.

5. Pipeline de Recursos Íntegro: c2f resources:sync e os controladores de atualização exportam e importam layouts_users_profiles sem perda de dados.

6. Suíte de Testes: Testes automatizados cobrindo o roteador e o novo campo verdes.