Capítulo 25 — Portal Web

25.1 Objetivo do Capítulo

Este capítulo detalha o Portal Web do Cidadão — o canal digital primário por meio do qual os cidadãos acessam, em navegador, os serviços públicos disponibilizados pelos órgãos participantes da plataforma.

O Portal Web não é uma página institucional. É uma aplicação digital completa que cobre o ciclo integral de relacionamento entre o cidadão e o órgão: descoberta de serviços, autenticação, abertura e acompanhamento de solicitações, envio de documentos, agendamentos, mensagens, ouvidoria, assistente de IA e gestão do perfil pessoal.

25.2 Papel do Portal Web na Plataforma

O Portal Web é o canal de autoatendimento principal para cidadãos que acessam a plataforma por navegador. Ele consome as mesmas APIs REST dos serviços de domínio que o aplicativo mobile e comparte os mesmos contratos — sem duplicação de regras de negócio.

Cidadão no navegador
        │
Portal Web (React)
        │
API Gateway
        │
Serviços de Domínio (Java / Spring Boot)
        │
IAM + GOV.BR + RabbitMQ + Data Lake + IA

O Portal concentra experiência e apresentação. Regras de negócio, autorização, persistência e processamento residem no backend.

25.3 Tecnologia e Arquitetura Frontend

25.3.1 Stack

O Portal Web é construído em React com TypeScript. O design system compartilhado com o aplicativo mobile garante consistência visual e comportamental entre os canais.

25.3.2 Responsividade

O portal é responsivo por design. Adapta-se a telas de dispositivos móveis, tablets e desktops sem degradação funcional. Em dispositivos móveis, o portal oferece as jornadas principais — o aplicativo mobile oferece adaptações de experiência específicas de dispositivo (câmera, push, biometria).

25.3.3 Renderização

A estratégia de renderização considera: SEO para páginas públicas do catálogo (Server-Side Rendering ou Static Generation para conteúdo indexável); experiência dinâmica para áreas autenticadas (Client-Side Rendering). A decisão de framework e modo de renderização é interna à implementação — o que o documento arquitetural registra é o contrato: nenhuma regra de negócio reside no frontend.

25.3.4 Design System

O portal consome o design system compartilhado da plataforma. Os tokens de design — cores, tipografia, espaçamento, bordas, ícones e componentes base — são definidos centralmente e aplicados pelo Portal e pelo aplicativo mobile. A identidade visual do tenant (cores primárias, logomarca, favicon) é configurada no Tenant Service e aplicada por injeção de tokens em tempo de carregamento — sem alterar o código do portal.

25.4 Princípios do Portal Web

1. Canal de apresentação — o portal renderiza e navega; não persiste nem decide;
2. Contratos compartilhados — consome as mesmas APIs que o aplicativo mobile; nenhum endpoint exclusivo do portal implementa lógica de negócio;
3. Identidade por tenant — a aparência e os serviços disponíveis refletem as configurações do tenant acessado, sem que o cidadão precise conhecer esse conceito;
4. Progressividade — o cidadão pode iniciar uma jornada sem autenticação (consultar o catálogo) e progredir para ações autenticadas (abrir solicitação) sem recomeçar do zero;
5. Acessibilidade — o portal observa WCAG 2.1 nível AA e eMAG onde pertinente; acessibilidade é requisito de projeto, não ajuste posterior;
6. Segurança no cliente — tokens nunca em localStorage sem criptografia; CSP ativa; XSS prevenido; autorização re-validada no backend em toda ação;
7. Degradação graciosa — quando uma capacidade está temporariamente indisponível (ex.: assistente de IA), o portal apresenta mensagem clara e mantém as demais funcionalidades operacionais.

25.5 Estrutura de Páginas e Jornadas

O portal é organizado em seis áreas principais:

┌──────────────────────────────────────────────────────────────┐
│  ÁREA PÚBLICA                                                  │
│  Página inicial, catálogo, detalhes de serviço, busca         │
├──────────────────────────────────────────────────────────────┤
│  AUTENTICAÇÃO                                                  │
│  Cadastro, login, recuperação, GOV.BR, MFA                    │
├──────────────────────────────────────────────────────────────┤
│  JORNADAS DO CIDADÃO (autenticado)                            │
│  Solicitações, documentos, agendamentos, mensagens, ouvidoria  │
├──────────────────────────────────────────────────────────────┤
│  ASSISTENTE DE IA                                              │
│  Chat, roteamento semântico, transferência para humano         │
├──────────────────────────────────────────────────────────────┤
│  PERFIL E CONFIGURAÇÕES                                        │
│  Dados pessoais, preferências, privacidade, consentimentos     │
├──────────────────────────────────────────────────────────────┤
│  AJUDA E INFORMAÇÕES INSTITUCIONAIS                           │
│  FAQ, contatos, termos, política de privacidade                │
└──────────────────────────────────────────────────────────────┘

25.6 Área Pública

25.6.1 Página Inicial

A página inicial do tenant apresenta: identidade visual do órgão, serviços em destaque, busca de serviços, categorias e acesso ao assistente de IA. O conteúdo da página inicial é configurado pelo administrador do tenant — sem deploy de código.

Cidadãos não autenticados visualizam o catálogo completo e podem pesquisar serviços. Para iniciar uma solicitação, o nível de autenticação exigido é determinado pelo serviço, não pelo canal.

25.6.2 Catálogo de Serviços

Apresenta os serviços publicados pelo tenant com: categoria, nome, descrição resumida, canal de disponibilidade, prazo estimado e indicação de documentos exigidos. A busca por texto e por categoria filtra o catálogo em tempo real. Resultados de busca semântica (sugeridos pelo assistente de IA) são apresentados quando a capacidade está habilitada.

25.6.3 Detalhe do Serviço

Exibe: descrição completa, requisitos, documentos exigidos com formatos aceitos e tamanho máximo, prazo, custo quando aplicável, canais disponíveis, unidades de atendimento, perguntas frequentes e botão de início de solicitação.

A página de detalhe é indexável por mecanismos de busca quando configurada como pública pelo tenant.

25.7 Autenticação

25.7.1 Cadastro

O cidadão cria conta na plataforma com dados mínimos: nome, e-mail e senha. O e-mail é validado por link de confirmação. A criação de conta respeita a política de senha configurada pelo tenant.

25.7.2 Login por IAM Próprio

Autenticação por e-mail e senha. MFA configurável por tenant. Recuperação de acesso por fluxo de redefinição de senha com link temporário enviado ao e-mail.

25.7.3 Login via GOV.BR

O portal inicia o fluxo OpenID Connect com Authorization Code + PKCE. O cidadão é redirecionado ao GOV.BR, autentica, e retorna ao portal com sessão da plataforma estabelecida. O cidadão que já possui conta criada por IAM próprio tem sua identidade GOV.BR vinculada automaticamente pelo identificador estável do provedor.

25.7.4 Sessão e Segurança

A sessão é mantida de forma segura no cliente. Tokens nunca em localStorage sem proteção. A sessão expira conforme a política do tenant. Tentativas de autenticação com credenciais inválidas são limitadas por rate limiting. Logout encerra a sessão no backend (revogação) — não apenas no cliente.

25.8 Jornada: Abertura de Solicitação

25.8.1 Fluxo Completo

Cidadão seleciona serviço no catálogo
    │
Página de detalhe com requisitos e documentos exigidos
    │
"Iniciar solicitação"
    │
Verificação de autenticação (conforme nível exigido pelo serviço)
    ├── Não autenticado → login ou cadastro → retorna ao ponto de saída
    └── Autenticado → formulário
    │
Preenchimento do formulário dinâmico
    ├── Campos obrigatórios validados no submit (backend valida também)
    ├── Documentos exigidos: upload ou seleção de documento já enviado
    └── Formulário multipágina quando configurado pelo serviço
    │
Revisão antes de confirmar
    │
Confirmação → Protocolo gerado
    │
Tela de confirmação com número de protocolo e próximos passos
    │
Notificação enviada pelo canal preferido do cidadão

25.8.2 Formulários Dinâmicos

O formulário exibido é o formulário publicado pelo tenant para o serviço selecionado. O portal renderiza o schema recebido do Forms Service — não tem templates de formulário embutidos. Tipos de campo suportados: texto, número, data, hora, seleção, múltipla escolha, arquivo, endereço, CPF, CNPJ e outros definidos pelo schema. Campos condicionais são suportados (um campo aparece ou desaparece com base no valor de outro).

25.8.3 Documentos no Formulário

Para cada documento exigido pelo serviço, o cidadão escolhe: enviar novo arquivo agora, ou selecionar um documento já enviado anteriormente (se válido e compatível com o tipo exigido). A reutilização de documentos é apresentada com o tipo e a data de envio anterior, e requer confirmação explícita.

25.9 Jornada: Acompanhamento de Protocolo

25.9.1 Lista de Solicitações

O cidadão autenticado acessa a lista de suas solicitações com: número de protocolo, serviço, data de abertura, situação atual e canal de abertura. A lista é paginada e filtrável por serviço, situação e período.

25.9.2 Detalhe do Protocolo

Exibe: dados da solicitação, formulário submetido, documentos vinculados, histórico de situações com datas, mensagens relacionadas e ações disponíveis conforme a situação atual.

25.9.3 Complementação

Quando a solicitação está aguardando complementação, o cidadão visualiza o que foi solicitado pelo órgão e pode responder diretamente da tela do protocolo: informar dados adicionais, enviar documento complementar ou confirmar informação.

25.10 Jornada: Documentos

25.10.1 Área de Documentos

O cidadão acessa todos os documentos que enviou à plataforma. Lista com: tipo, data de envio, situação (válido, vencido, em processamento, rejeitado) e validade quando informada.

25.10.2 Envio de Documento

Upload de arquivo com validação de formato e tamanho antes do envio. Indicador de progresso durante o upload. Feedback de sucesso ou erro com motivo.

25.10.3 Alertas de Vencimento

Documentos com data de validade próxima ao vencimento são destacados na lista e geram notificação conforme a política configurada.

25.11 Jornada: Agendamentos

25.11.1 Novo Agendamento

Selecionar serviço agendável
    │
Selecionar unidade de atendimento
    │
Visualizar calendário de disponibilidade
    │
Selecionar data e horário
    │
Confirmar (protocolo de agendamento gerado)
    │
Receber confirmação e lembrete automático

25.11.2 Meus Agendamentos

Lista de agendamentos futuros e históricos com: serviço, unidade, data, horário e situação. Opções de remarcar ou cancelar conforme as regras do serviço e o prazo configurado.

25.12 Jornada: Mensagens

25.12.1 Central de Mensagens

Caixa de mensagens unificada com: mensagens recebidas, enviadas, lidas e não lidas. Cada mensagem exibe: origem (órgão, serviço), data e conteúdo. Link para o protocolo relacionado quando aplicável.

25.12.2 Resposta

Canais bidirecionais (portal, WhatsApp quando configurado) permitem resposta diretamente da central de mensagens. O cidadão responde no mesmo contexto da mensagem original.

25.12.3 Notificações In-App

Alertas visuais para novas mensagens, mudanças de situação e prazos próximos aparecem na interface enquanto o cidadão navega no portal, sem exigir acesso à central de mensagens.

25.13 Jornada: Ouvidoria

25.13.1 Registro de Manifestação

O portal oferece formulário específico para registro de manifestações de ouvidoria: seleção do tipo (reclamação, sugestão, denúncia, elogio, pedido de informação), assunto, descrição, documentos opcionais e escolha de identificação ou anonimato quando o tipo permite.

25.13.2 Acompanhamento

O cidadão acompanha o status de suas manifestações pelo número de protocolo. Visualiza: situação, data de registro, prazo de resposta e resposta registrada pelo órgão.

25.14 Assistente de IA no Portal

O assistente de IA está disponível no portal via ícone flutuante ou pela área dedicada. No canal web, suporta texto e renderiza respostas com formatação, links de navegação e citações da base de conhecimento do tenant.

A continuidade entre o assistente e o atendimento humano preserva o contexto completo da sessão — o cidadão não repete informações ao ser transferido para um atendente.

Detalhamento no Capítulo 22 (Atendimento Digital e Copiloto de IA).

25.15 Perfil e Configurações

25.15.1 Dados Pessoais

O cidadão visualiza e edita seus dados cadastrais: nome, data de nascimento, documentos identificadores, endereços e meios de contato. Campos vindos de fonte oficial (GOV.BR) são apresentados como verificados e somente editáveis por fluxo específico quando a política permite.

25.15.2 Empresas Representadas

O cidadão que representa pessoas jurídicas gerencia seus vínculos: visualizar empresas, alternar o contexto ativo entre pessoa física e empresa, e acessar serviços disponíveis para o CNPJ selecionado.

25.15.3 Preferências de Comunicação

O cidadão configura: canal preferido para receber notificações, opt-in e opt-out por categoria de comunicação, horário de preferência quando suportado pelo provedor.

25.15.4 Privacidade e Consentimentos

Exibe: finalidades de tratamento dos dados, consentimentos registrados com data e canal, opções de revogação disponíveis, histórico de acessos à conta e link para solicitar direitos de titular (acesso, correção, portabilidade, exclusão).

25.16 Acessibilidade

25.16.1 WCAG 2.1 — Nível AA

O portal observa as diretrizes WCAG 2.1 nível AA:

• Perceptível: conteúdo textual para todo conteúdo não textual; legendas para áudio quando disponível; contraste mínimo de 4,5:1 para texto normal; redimensionamento sem perda de conteúdo até 200%;
• Operável: toda funcionalidade acessível por teclado; sem armadilhas de foco; tempo ajustável ou descartável; nenhum conteúdo pisca mais de três vezes por segundo;
• Compreensível: idioma da página declarado; navegação consistente; erros de formulário identificados e sugestão de correção fornecida;
• Robusto: compatibilidade com tecnologias assistivas; status de componentes dinamicamente atualizados comunicados via ARIA.

25.16.2 eMAG

O portal considera as diretrizes do eMAG (Modelo de Acessibilidade em Governo Eletrônico) como referência complementar ao WCAG para contexto de serviços públicos brasileiros.

25.16.3 Testes de Acessibilidade

A acessibilidade é verificada por ferramentas automatizadas no pipeline (WAVE, axe) e por testes manuais com leitores de tela representativos (NVDA, JAWS, VoiceOver). A automação detecta parte das violações; os testes manuais cobrem fluxos e interações que a automação não alcança.

25.17 Performance

25.17.1 Core Web Vitals

O portal monitora as métricas de performance que impactam a experiência real do cidadão:

• LCP (Largest Contentful Paint): ≤ 2,5 segundos;
• FID (First Input Delay) / INP (Interaction to Next Paint): ≤ 200ms;
• CLS (Cumulative Layout Shift): ≤ 0,1.

25.17.2 Estratégias de Performance

• separação de bundles por rota (code splitting) para não carregar código de jornadas não visitadas;
• lazy loading de componentes pesados (editor de formulário, visualizador de documento);
• cache de recursos estáticos com estratégia de versionamento de hash no nome do arquivo;
• imagens otimizadas com formatos modernos (WebP) e carregamento preguiçoso;
• prefetch de rotas próximas na navegação;
• conteúdo do catálogo cacheado no cliente com TTL e invalidação por evento de publicação.

25.17.3 Performance em Conexões Lentas

O portal é funcional em conexões 3G moderadas. Indicadores de carregamento evitam que o cidadão interprete carregamento como falha. Operações críticas (envio de formulário, upload de documento) exibem progresso e confirmação antes de prosseguir.

25.18 Segurança no Cliente

25.18.1 Tokens e Sessão

Tokens de acesso são armazenados de forma segura. A estratégia específica (cookie HttpOnly com SameSite Strict vs. token em memória com refresh via cookie) é definida alinhada ao mecanismo de autenticação final (ADR-190). Nenhum token em localStorage sem criptografia.

25.18.2 Content Security Policy

CSP é configurada para restringir fontes de scripts, estilos, imagens e frames. eval() é proibido. Inline scripts são evitados. A política é testada por ambiente.

25.18.3 XSS

Saída renderizada pelo React é sanitizada. dangerouslySetInnerHTML é proibido sem revisão de segurança explícita. Conteúdo gerado por IA ou por usuário é sempre tratado como dado, nunca como markup.

25.18.4 CSRF

A estratégia de proteção CSRF é alinhada ao mecanismo de autenticação. Tokens em headers Authorization: Bearer não são vulneráveis ao CSRF clássico de cookies. Quando cookies são utilizados, SameSite e CSRF tokens são aplicados.

25.18.5 Source Maps

Source maps de produção não são expostos publicamente. O código-fonte do bundle não é acessível por terceiros.

25.19 Personalização por Tenant

O portal apresenta a identidade visual do tenant ao cidadão:

• logomarca e nome institucional no cabeçalho;
• paleta de cores derivada dos tokens configurados no tenant;
• favicon;
• textos institucionais (boas-vindas, sobre o órgão, contatos);
• rodapé com links definidos pelo tenant;
• termos de uso e política de privacidade específicos do tenant.

A personalização é aplicada via tokens carregados dinamicamente na inicialização do portal, sem bifurcar o código da aplicação. Um mesmo build serve todos os tenants — apenas os tokens e o conteúdo mudam.

25.20 Telemetria e Observabilidade Frontend

25.20.1 Real User Monitoring (RUM)

O portal emite telemetria de experiência real do cidadão: Core Web Vitals por página, tempo de carregamento, erros de JavaScript, falhas de API (sem payload sensível), navegação e sessão. Os dados são enviados ao backend de observabilidade sem incluir dados pessoais ou conteúdo de formulários.

25.20.2 Error Tracking

Erros de runtime no frontend são capturados, agrupados e reportados com: tipo, mensagem, stack trace (sanitizado), rota e identificador de sessão técnico. Nenhum dado pessoal do cidadão é incluído no report de erro.

25.20.3 Feature Flags

Feature flags permitem ativar ou desativar funcionalidades por tenant, por percentual de usuários ou por condição de ambiente, sem deploy. Flags são avaliadas no backend — não em JavaScript do cliente como único controle.

25.21 Internacionalização

O portal é desenvolvido com suporte a internacionalização (i18n) desde a arquitetura. O conteúdo de interface — rótulos, mensagens de erro, textos de ajuda — é externalizado em arquivos de tradução. O idioma padrão é Português do Brasil. Suporte a outros idiomas é adicionado por arquivo de tradução sem alterar componentes.

Conteúdo gerado pelo tenant (nome do serviço, descrição, formulário) é responsabilidade do tenant — a plataforma oferece o mecanismo de internacionalização, não o conteúdo traduzido.

25.22 Continuidade entre Canais

O cidadão que inicia uma jornada no portal pode:

• consultar o status da sua solicitação no aplicativo mobile;
• receber a resposta do atendente por WhatsApp;
• completar um agendamento iniciado no portal pelo mobile.

O portal não armazena estado de jornada localmente. O estado é sempre consultado do backend — o que garante que qualquer canal apresente a situação atual sem sincronização manual.

25.23 Rastreabilidade com o Anexo III

O Portal Web atende, como canal, aos itens transversais de todos os Blocos do Anexo III:

25.24 Benefícios do Portal Web

• ponto de acesso unificado para todos os serviços digitais do órgão via navegador;
• responsivo sem necessidade de app instalado para acesso digital básico;
• identidade visual por tenant sem bifurcar código;
• jornadas completas do cidadão: descoberta, autenticação, solicitação, acompanhamento e avaliação;
• acessibilidade como requisito, não como ajuste posterior;
• segurança no cliente com CSP, tokens seguros e autorização re-validada no backend;
• performance monitorada via Core Web Vitals com estratégias de otimização;
• continuidade com outros canais por estado sempre consultado do backend;
• assistente de IA integrado com streaming de resposta e transferência para humano com contexto.

25.25 Riscos e Mitigações

25.26 Decisões Arquiteturais

25.27 Considerações Finais

O Portal Web é o rosto digital do órgão para o cidadão. A qualidade da experiência que ele oferece determina, em grande medida, a percepção do cidadão sobre a qualidade do serviço público. Por isso, performance, acessibilidade, clareza nas jornadas e continuidade entre canais não são características adicionais — são requisitos centrais do portal.

A separação entre apresentação (portal) e lógica (backend) garante que o portal possa evoluir independentemente dos serviços de domínio, e que a segurança e a consistência dos dados não dependam da disciplina do código frontend.

O Capítulo 26 detalha o Aplicativo Mobile do cidadão.

25.28 Controle de Versão

25.29 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 1 — itens 1.1, 1.2, 1.6, 1.10, 1.11 cobertos conforme seção 25.23.
• [ANX-IV] — Capacidades técnicas de canal web responsivo, autenticação GOV.BR, formulários dinâmicos, acessibilidade e personalização por tenant.
• [ANX-V] Item 2.2 — Acessibilidade digital: o portal observa WCAG 2.1 nível AA e eMAG como referência para serviços públicos digitais, com testes automatizados e manuais no pipeline.
• [ANX-V] Item 2.3 — Proteção do usuário: CSP, gestão segura de tokens, LGPD aplicada às jornadas do cidadão, privacidade e consentimentos gerenciáveis pelo próprio cidadão.
• [PNR] — Portal Web como canal primário de autoatendimento digital, integrado às capacidades de CRM, BPM, ECM/GED, IA e comunicação da plataforma.
• [EDITAL] — Edital CP001/2026: canal web do cidadão com jornadas completas de autoatendimento, integrado ao ecossistema da plataforma e ao GOV.BR.