PORTAL TCE-GO

O Portal TCE-GO é a plataforma web destinada a centralizar e facilitar o acesso aos serviços do Tribunal de Contas, promovendo modernização e eficiência no atendimento. O sistema fundamenta-se em três pilares principais:

• Serviços ao Jurisdicionado: Centralização de acesso a sistemas internos.
• Transparência Ativa: Disponibilização clara e intuitiva de dados sobre contas públicas, licitações e contratos, garantindo o direito de acesso à informação e o controle social.
• Gestão de Conteúdo:
  • Notícias: Canal de comunicação institucional com suporte a multimídia para divulgar ações do Tribunal.
  • Biblioteca de Arquivos: Repositório organizado para legislação, manuais técnicos, revistas e publicações oficiais, com busca indexada.

Segue o planejamento macro para a execução do projeto.

A arquitetura de acesso é dividida em dois grandes níveis: Acesso Interno (Servidores/Administradores) e Acesso Público (Externo). O nível Público possui especializações conforme a necessidade de informação.

Quadro geral por requisito. O detalhamento de cada item está nas seções seguintes.

Total: 30 requisitos, todos desenvolvidos. Das 27 funcionalidades, 11 foram entregues e 16 estão desenvolvidas, das quais 4 com teste em execução, 9 com teste pendente, 2 com teste impedido e 1 já testada, aguardando reclassificação (situação dos testes apurada em 09/09/2026). Os 3 requisitos de migração e carga inicial (RF_033 a RF_035) têm os scripts testados em homologação e a carga prevista para a virada para produção.

Descrição: O sistema deve autenticar os usuários internos exclusivamente via Keycloak, vedando a criação ou utilização de credenciais locais no WordPress. Ao acessar o Portal Administrativo sem sessão ativa, o sistema deve redirecionar o usuário para a tela de login centralizado do Keycloak e, após autenticação bem-sucedida, retorná-lo ao painel administrativo. O perfil e os menus exibidos após o login são determinados pelas permissões atribuídas ao usuário (ver Gestão de Perfis e Permissões). A sessão deve ser encerrada automaticamente após 60 minutos de inatividade.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39394.
• Manual: -.
• Ator: Todos os perfis internos.
• Critério de Aceite: Ao acessar o Portal Administrativo sem sessão ativa, o usuário deve ser redirecionado para o login do Keycloak e retornar ao painel com os menus correspondentes ao seu perfil cadastrado. Ao inserir credenciais inválidas, o sistema deve exibir uma mensagem. Após 60 minutos de inatividade, a sessão deve ser encerrada e o usuário redirecionado para o login.

Descrição: O sistema deve permitir ao Gestor de Conteúdo criar, editar, publicar notícias institucionais no Portal Público, com suporte a conteúdo multimídia (imagens, vídeos e áudio). Notícias devem suportar definição de metadados para compartilhamento em redes sociais (Open Graph/meta tags), agendamento de publicação e despublicação automática por data e hora definidas. A categorização deve utilizar a taxonomia de assuntos padronizada e os tipos: Notícia, Clipping, Vídeo e Rádio. O papel Colaborador cria e edita rascunhos apenas das próprias notícias, sem permissão de publicação.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39395.
• Manual: -.
• Ator: Gestor de Conteúdo (papéis Autor ou Editor), Colaborador.
• Critério de Aceite: Ao tentar publicar notícia sem campos obrigatórios preenchidos, o sistema deve bloquear a operação e destacar visualmente cada campo inválido com a mensagem correspondente. Ao agendar publicação futura, o sistema deve publicá-la automaticamente no horário definido sem intervenção manual. Ao publicar uma notícia, o sistema deve gerar automaticamente as meta tags Open Graph com base nos campos Título, Meta Description e Imagem de Destaque. A taxonomia de assuntos disponível no formulário deve ser idêntica à lista padronizada definida na RN10 do ER_003.

Descrição: O sistema deve controlar o acesso ao painel administrativo por duas camadas complementares: os papéis nativos do WordPress, que definem as ações permitidas (capabilities), e o AAM — Advanced Access Manager, que define a visibilidade dos menus. Não são criados perfis próprios por setor: usam-se os cinco papéis nativos, e a diferenciação entre áreas se dá pela liberação de menus, nunca pelo papel em si. Vale o princípio do menor privilégio: com exceção do Administrador, todo usuário começa sem nenhum menu visível, independentemente do papel atribuído. A liberação é aditiva e feita no AAM, por papel (configuração coletiva) ou por usuário (exceção pontual). O AAM também restringe o acesso direto por URL, de modo que conhecer a rota não dá acesso à página.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39397.
• Manual: -.
• Ator: Administrador.
• Critério de Aceite: Todo usuário que acessa o painel pela primeira vez não visualiza nenhum menu, independentemente do papel atribuído. A configuração padrão de todos os papéis no AAM deve ocultar todos os itens de menu — nenhum menu é exibido sem liberação explícita. O Administrador acessa todos os menus e funcionalidades sem restrição. O Editor consegue editar e excluir publicações de outros usuários sem intervenção da TI, desde que os menus correspondentes estejam liberados no AAM. O Autor publica, edita e exclui apenas as próprias publicações e não acessa as de outros. O Colaborador cria e edita apenas as próprias publicações e não publica diretamente. O Assinante não possui capability de conteúdo e não visualiza nenhum menu. Um usuário com papel Colaborador não visualiza nem executa ação exclusiva de Autor ou Editor, e um usuário com papel Autor não executa ação exclusiva de Editor. O Administrador consegue ajustar a visibilidade de menus por usuário individual no AAM, independentemente do papel atribuído.

Papéis utilizados:

O papel nativo Editor do WordPress traz capabilities adicionais (manage_categories, moderate_comments, entre outras) que podem não ser desejadas no portal; restringi-las com granularidade exige plugin adicional.

Descrição: O sistema deve permitir ao Administrador editar contas de usuários do Portal Administrativo, atribuindo a cada usuário um perfil previamente cadastrado (ver Gestão de Perfis e Permissões). A criação de usuários com credenciais locais desvinculadas do Keycloak é vedada. A listagem de usuários deve ser paginada e permitir filtragem por nome e perfil.

• Situação: Removido do escopo — valem o padrão de contas do WordPress e o controle de acesso pelo Keycloak. A demanda #39398 foi encerrada. O requisito permanece nesta página apenas como registro histórico.
• Manual: -.
• Ator: Administrador.
• Critério de Aceite: Ao editar um usuário, o Administrador deve selecionar obrigatoriamente um perfil previamente cadastrado no sistema. Ao inativar um usuário, o acesso ao painel deve ser revogado imediatamente e a operação registrada em log com identificação do executor, data e hora. A listagem de usuários deve ser paginada com 20 registros por página e permitir filtragem simultânea por nome, perfil e status. O sistema não deve exibir opção de exclusão permanente de contas, apenas inativação.

Descrição: O sistema deve permitir ao Gestor de Conteúdo cadastrar, editar e gerenciar publicações institucionais (normativos, relatórios, boletins, cartilhas, manuais, livros/revistas e apresentações) diretamente no painel administrativo. O formulário deve contemplar os seguintes campos: tipo (obrigatório), subtipo — classificação granular dentro do tipo, ex.: “Relatório de Gestão” (opcional), título (obrigatório, máx. 120 caracteres), descrição/resumo (obrigatório, máx. 300 caracteres, utilizado como meta description), conteúdo completo (opcional), número ou edição (opcional), órgão/autoria (opcional), assunto/área temática (opcional), ano de publicação (obrigatório), data de publicação (obrigatório), imagem de capa (opcional — campo deve exibir permanentemente o aviso: “Recomendado: proporção 3:4, mínimo 600 × 800 px, tamanho máximo 2 MB”) e flag de destaque (opcional). Cada publicação deve suportar um ou mais arquivos vinculados por meio de campo repetível, onde cada entrada contém nome do arquivo (obrigatório), upload do arquivo (obrigatório), formato e tamanho (preenchidos automaticamente a partir do arquivo enviado). O sistema deve validar formato e tamanho máximo de cada arquivo individualmente. São aceitos: documentos de texto (PDF, DOCX, DOC, ODT, TXT, RTF), planilhas (XLSX, XLS, ODS, CSV) e apresentações (PPTX, PPT, ODP), com tamanho máximo de 50 MB por arquivo. O Gestor de Conteúdo controla o status da publicação (Rascunho, Publicado, Despublicado). O papel Colaborador cria e edita rascunhos apenas das próprias publicações, sem permissão de publicação. Ao publicar, o sistema deve gerar automaticamente os metadados de compartilhamento social (og:title, og:description, og:image) e indexar a publicação para recuperação pela Busca Global (ER_003).

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39399.
• Manual: -.
• Ator: Gestor de Conteúdo (papéis Autor ou Editor), Colaborador.
• Critério de Aceite: Ao tentar publicar uma publicação com campo obrigatório não preenchido, o sistema deve bloquear a operação e destacar visualmente o campo com a mensagem de erro correspondente. Ao tentar realizar upload de arquivo com formato não suportado ou tamanho superior a 50 MB, o sistema deve rejeitar o arquivo e exibir: “Arquivo inválido. São aceitos documentos de texto (PDF, DOCX, DOC, ODT, TXT, RTF), planilhas (XLSX, XLS, ODS, CSV) e apresentações (PPTX, PPT, ODP) com tamanho máximo de 50 MB.” O campo de imagem de capa deve exibir permanentemente o aviso de dimensões recomendadas e tamanho máximo, independentemente de o campo estar preenchido ou não. O Gestor deve poder vincular mais de um arquivo a uma mesma publicação, definindo nome, formato e tamanho individualmente para cada um. Ao publicar, o sistema deve gerar automaticamente os metadados de compartilhamento social com base no título, na descrição e na imagem de capa. A publicação deve estar disponível na Busca Global em até 5 minutos após a publicação. Um usuário com papel Colaborador não deve conseguir acionar a publicação. Ao despublicar uma publicação, ela deve deixar de ser exibida no Portal Público imediatamente.

Descrição: O sistema deve disparar automaticamente uma newsletter aos inscritos quando um conteúdo do tipo “Clipping” for publicado, substituindo o fluxo anteriormente gerenciado pelo Liferay. O Gestor de Conteúdo deve poder confirmar ou cancelar o disparo antes da publicação. O sistema deve manter base de inscritos com suporte a opt-in via Portal Público e opt-out por link presente em cada e-mail enviado. O histórico de disparos deve ser consultável no painel administrativo.

• Situação: Desenvolvido — teste pendente. Demanda #39400. Atenção ao escopo entregue: a demanda cobriu apenas o degrau necessário à migração do CMS — o disparo diário existente (cron das 9h30) passou a consumir as notícias e o clipping eletrônico do WordPress, por dois endpoints REST, no lugar da API do Liferay, preservando horário, template e base de inscritos. O disparo orientado ao evento de publicação do clipping, o toggle de confirmação do Gestor de Conteúdo e o histórico de disparos no painel administrativo, descritos acima, permanecem como visão futura e não foram implementados.
• Manual: -.
• Ator: Gestor de Conteúdo, Cidadão.
• Critério de Aceite: Ao publicar conteúdo do tipo Clipping, o sistema deve exibir automaticamente a opção de disparo de newsletter com toggle ativado por padrão. Ao confirmar o disparo, o sistema deve enviar o e-mail a todos os inscritos ativos e registrar o evento no histórico com data, hora, assunto e quantidade de destinatários. Ao clicar no link de cancelamento presente no e-mail, o inscrito deve ser removido imediatamente da base de inscritos ativos sem etapas adicionais. Caso o disparo falhe total ou parcialmente, o sistema deve registrar o status correspondente no histórico e notificar o Gestor de Conteúdo.

Descrição: O sistema deve integrar o Portal Público ao Google Analytics 4 (GA4), permitindo monitoramento de métricas de acesso e comportamento de navegação. A integração deve ser configurável pelo Administrador do Sistema diretamente no painel do CMS, sem necessidade de intervenção em código. A coleta de dados analíticos deve ser condicionada ao consentimento de cookies do usuário final, conforme o requisito Política de Privacidade, Termos de Uso e Configurações de Cookie.

• Situação: Desenvolvido — teste impedido: o Site Kit não consegue verificar a propriedade do site enquanto o Portal não estiver em produção com URL pública. Demanda #39402.
• Manual: -.
• Ator: Administrador do Sistema (DITI), Gestor de Conteúdo.
• Critério de Aceite: Ao configurar o ID de rastreamento do GA4 no painel do CMS e acessar o Portal Público, os dados de sessão devem aparecer no painel do Google Analytics em tempo real. Usuários que recusaram cookies de rastreamento não devem ter dados coletados ou enviados ao GA4. A atualização do ID de rastreamento deve ser aplicada ao Portal Público sem necessidade de alteração de código ou republicação manual.

Descrição: O sistema deve permitir ao Gestor de Conteúdo designado administrar, pelo painel administrativo, o conteúdo de cada módulo e subportal do Portal Público, sem intervenção da equipe de desenvolvimento. Toda área tem menu próprio no painel e usa o status nativo Rascunho/Publicado: somente registros publicados aparecem no Portal Público. Os hubs e subportais seguem ainda o mesmo padrão estrutural, validado inicialmente no Portal da Transparência — um tipo de conteúdo para a categoria (agrupador) e outro para o item (página, documento ou painel publicado), sendo que categoria sem item publicado não é exibida. As demais áreas têm estrutura própria: o catálogo de serviços, os membros do Tribunal e os contatos são registros únicos, sem agrupador. A permissão de publicar em cada área resulta do papel atribuído ao usuário e da liberação, no AAM, do menu daquela área — ver Gestão de Perfis e Permissões.

• Situação: Acompanha a do requisito de cada área, na tabela ao final deste bloco.
• Ator: Gestor de Conteúdo designado para a área, Administrador.
• Critério de Aceite: O Gestor de Conteúdo designado para uma área deve conseguir criar, editar, despublicar e reordenar os itens daquela área sem acionar a equipe de desenvolvimento. Item salvo como Rascunho não deve ser exibido no Portal Público. Ao despublicar um item, ele deve deixar de ser exibido imediatamente. Categoria que não possua nenhum item publicado não deve ser exibida no Portal Público. Um Gestor de Conteúdo designado para uma área não deve visualizar nem editar o conteúdo das demais áreas.

Áreas cobertas:

Descrição: O sistema deve permitir a consulta pública de processos por número, interessado (nome) ou assunto, com validação por captcha, exibição detalhada das informações gerais, decisões, andamentos, julgamentos e disponibilização de documentos conforme regras de sigilo e situação do processo.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demandas #39630 e #39230.
• Documentação: RF_002.
• Ator: Cidadão, Jurisdicionado, Servidor Interno.
• Critério de Aceite: Ao realizar uma busca válida, o sistema deve retornar a lista paginada de processos encontrados ou a mensagem “Nenhum processo foi localizado com o dado informado.” Ao selecionar um processo não sigiloso, o sistema deve exibir suas informações gerais, decisões, andamentos e julgamento. O download de documentos deve ocorrer apenas quando atendidas as regras de sigilo, tipo de documento e situação de julgamento, com geração de link temporário válido por 10 minutos.

Descrição: O sistema deve permitir a pesquisa unificada de conteúdos e serviços do Portal Público do TCE-GO, abrangendo atos normativos, notícias, serviços, páginas institucionais, transparência e publicações. A funcionalidade deve utilizar critérios de relevância, indexação temática por palavras-chave para otimizar a localização das informações, apresentando resumos dos conteúdos encontrados com destaque para os termos pesquisados.

• Situação: Desenvolvido — teste em execução. Demanda #39403.
• Documentação: ER_003.
• Ator: Todos os públicos.
• Critério de Aceite: Após a submissão da pesquisa, o sistema deve exibir os resultados de forma paginada (10 registros por página), ordenados por relevância ou data. O usuário deve conseguir refinar os resultados por meio de abas de categorias (Serviços, Notícias, Páginas, Transparência e Publicações), que acionam filtros avançados dinâmicos, além de um filtro transversal de “Assunto” baseado em taxonomia padronizada. Caso nenhum conteúdo seja localizado, o sistema deve exibir a mensagem: “Nenhum resultado encontrado para o termo pesquisado.”

Descrição: O sistema deve permitir que qualquer pessoa consulte, por CPF ou CNPJ e com resolução de captcha, se possui registro de Contas Julgadas Irregulares no TCE-GO. Não havendo registro, o sistema emite a Certidão Negativa, imprimível diretamente pelo navegador, com validade de 30 dias e um código de controle que permite verificar a autenticidade do documento posteriormente. Havendo registro, o sistema informa a existência do impedimento sem detalhar valores, processos ou natureza do débito, e orienta que a regularização exige comparecimento presencial ao Tribunal.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39404.
• Documentação: RF_004.
• Ator: Cidadão, Jurisdicionado, Partes Processuais.
• Critério de Aceite: Ao informar CPF ou CNPJ com formato inválido, o sistema deve destacar o campo e exibir: “CPF/CNPJ inválido. Verifique o documento informado e tente novamente.”, impedindo a submissão. Não havendo registro de contas julgadas irregulares, o sistema deve emitir a certidão imprimível pelo navegador, com a data de validade e o código de controle visíveis no documento. Havendo registro, o sistema deve informar o impedimento e a necessidade de comparecimento presencial, sem detalhar valores ou processos. O captcha deve ser exigido em todas as tentativas de consulta, independentemente do resultado anterior.

Descrição: O sistema deve permitir que qualquer pessoa consulte as pendências de multa vinculadas a um CPF ou CNPJ e gere o boleto bancário da parcela escolhida. A consulta exige o documento e captcha, e admite filtros avançados opcionais por número do processo e por número e ano do ofício. O fluxo tem quatro etapas em uma única rota: consulta, lista das pendências em aberto, detalhe da pendência com as parcelas e seleção de uma delas, e confirmação. O boleto é gerado pela API de Cobrança do Banco do Brasil, que também atende à segunda via. A tela de confirmação apresenta beneficiário, pagador, processo, valor e a linha digitável com botão de copiar, além do acesso ao site do Banco do Brasil.

• Situação: Desenvolvido — teste em execução, mas impedido em homologação: não é possível gerar boleto fora de produção, porque a URL de segunda via do Banco do Brasil só existe lá. Demanda #39405.
• Documentação: RF_005.
• Ator: Jurisdicionado, Partes Processuais.
• Critério de Aceite: Ao informar documento com formato inválido, o sistema deve destacar o campo e impedir a submissão. Ao não localizar pendências para o dado informado, o sistema deve exibir mensagem de resultado vazio, sem erro. Ao selecionar uma pendência, o sistema deve listar as parcelas em aberto e permitir a seleção de apenas uma. Ao confirmar a geração, o sistema deve exibir os dados de pagamento com a linha digitável copiável e o acesso ao site do Banco do Brasil. A segunda via de um boleto já gerado deve ser obtida pelo mesmo fluxo.

Descrição: O sistema deve permitir que qualquer pessoa pesquise os ofícios públicos emitidos pelo TCE-GO por cinco critérios: número do ofício, número do processo, interessado (CPF/CNPJ), órgão de origem e data do ofício. A consulta exige captcha. Os resultados são exibidos de forma paginada e cada linha pode ser expandida na própria lista para mostrar os detalhes do ofício — interessado, CPF/CNPJ, notificado e datas. O número do processo é um link que abre a Consulta de Processos em nova aba. Somente ofícios com data de notificação preenchida são exibidos.

• Situação: Desenvolvido — teste pendente. Demanda #39406.
• Documentação: RF_006.
• Ator: Jurisdicionado, Partes Processuais.
• Critério de Aceite: Ao localizar ofícios, o sistema deve exibi-los paginados, e cada linha deve expandir na própria lista com os detalhes do ofício. Ofício sem data de notificação não deve aparecer em nenhum critério de consulta. Ao acionar o número do processo, a Consulta de Processos deve abrir em nova aba, mantendo a lista de ofícios na aba original. Ao não localizar ofício, o sistema deve exibir mensagem de resultado vazio.

Descrição: O sistema deve permitir que qualquer pessoa verifique a autenticidade de um documento processual do TCE-GO a partir de um link externo — impresso no próprio documento ou compartilhado por quem o recebeu. O link carrega uma chave criptografada que identifica o documento. Após a verificação por captcha, o sistema valida o documento e abre o PDF correspondente, respeitadas as regras de sigilo processual.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39407.
• Documentação: RF_007.
• Ator: Todos os públicos.
• Critério de Aceite: Ao acessar o link com chave válida e resolver o captcha, o sistema deve abrir o PDF do documento. Ao acessar link cuja chave não corresponda a documento existente, o sistema deve informar que o documento não foi localizado, sem abrir arquivo algum. Documento sob sigilo processual não deve ser aberto, ainda que a chave seja válida. Sem a resolução do captcha, nenhuma validação deve ser executada.

Descrição: O sistema deve permitir que qualquer pessoa receba notificações por e-mail a cada novo andamento de um processo do TCE-GO. O modelo abandona a conta com senha do serviço legado e adota o padrão de newsletter: o usuário se identifica apenas pelo e-mail e confirma a assinatura com um clique no link recebido. A inscrição acontece no contexto da própria página do processo, não em tela separada, e o gerenciamento das inscrições é feito pelo e-mail — um link leva ao painel onde o usuário vê e encerra seus acompanhamentos. O sistema deve validar a existência do processo e vedar a inscrição em processo sigiloso. O e-mail de notificação contém o tipo de andamento, a data, o link para o detalhamento do processo no Portal e um link próprio de descadastro daquele acompanhamento.

• Situação: Desenvolvido — teste impedido: aguarda ajustes no template de e-mail de movimentação e no cancelamento por e-mail. Demanda #39408.
• Documentação: RF_008.
• Ator: Partes Processuais, Advogado, Jurisdicionado.
• Critério de Aceite: Ao informar número de processo inexistente, o sistema deve exibir: “Processo não localizado. Verifique o número informado.” Ao informar número de processo sigiloso, o sistema deve exibir: “Este processo não está disponível para acompanhamento público.” A inscrição só deve ser efetivada após a confirmação pelo link enviado ao e-mail informado, sem exigir senha nem criação de conta. Ao registrar novo andamento no processo monitorado, o sistema deve enviar e-mail contendo tipo de andamento, data e link para o detalhamento. O link de descadastro presente no e-mail deve encerrar imediatamente o acompanhamento daquele processo, sem confirmação adicional e sem afetar as demais inscrições do mesmo e-mail; link já utilizado deve ser tratado como inválido, não como erro do usuário.

Descrição: O sistema deve disponibilizar o catálogo dos serviços do Tribunal e uma página padronizada para cada serviço. O catálogo reúne dois tipos de registro: os serviços do próprio Portal, que rodam dentro do Portal Público (Consulta de Processos, Emissão de Certidão, Pautas e Sessões de Julgamento, Licitações e Contratos, entre outros), e os serviços fora do Portal, os antigos sistemas satélites hospedados em outros endereços do Tribunal (Diário Eletrônico de Contas, Consulta de Decisões, Atualização Monetária, Canal de Ouvidoria, Protocolo Eletrônico, TCEHub, entre outros). A área adota a palavra “serviço” no lugar de “sistema”, na interface e na documentação. Cada página de serviço traz obrigatoriamente o nome, a chamada, a descrição em linguagem simples, quem pode acessar e o botão “Acessar o Serviço” com o aviso do destino do clique. Havendo requisitos de acesso, eles ficam visíveis logo abaixo da descrição; as demais informações ficam recolhidas em seções colapsáveis. O serviço sempre abre na mesma aba, e o cartão informa o destino antes do clique. O catálogo é mantido pelo Gestor de Conteúdo no painel administrativo, sem depender de chamado técnico — ver Gestão de Conteúdo dos Módulos e Subportais.

• Situação: Desenvolvido — teste pendente. Demanda #39409.
• Documentação: RF_009.
• Ator: Todos os públicos.
• Critério de Aceite: Ao acessar a página de um serviço, o usuário deve visualizar nome, chamada, descrição, quem pode acessar e o botão “Acessar o Serviço”. Havendo requisitos de acesso, eles devem estar visíveis abaixo da descrição, sem depender de acordeão. Antes do clique, o cartão deve informar o destino — dentro do Portal ou fora dele. Ao acionar “Acessar o Serviço”, o destino deve abrir na mesma aba, tanto para serviço do próprio Portal quanto para serviço externo. A descrição do serviço não deve conter siglas sem definição explícita no texto.

Descrição: O sistema deve exibir uma Home Page responsiva que orienta o usuário pelo seu perfil, destaca os serviços mais utilizados e mantém o visitante informado. É organizada em seis seções: Acesse por Categoria, com cards dos perfis Cidadão, Advogados, Órgãos Fiscalizados, Servidores e Licitantes; Favoritos, com os serviços marcados pelo próprio usuário, exibida somente quando houver ao menos um; “O que você quer fazer no TCE/GO hoje?”, carrossel dos serviços mais utilizados; Nossos Serviços e Prestações, grade com todos os serviços do Portal; Atualizações do TCE/GO, com as últimas notícias; e O que o Tribunal tem feito, carrossel de banners das contribuições do controle externo, gerenciados no CMS. O campo de Busca Global está presente no cabeçalho fixo, em todas as páginas.

• Situação: Desenvolvido — teste pendente. Foi construída junto com as demais atividades e com a definição do layout, sem documentação própria.
• Documentação: a Home Page não tem especificação própria — foi construída junto com as demais atividades e com a definição do layout. A gestão dos banners está detalhada na história #39396.
• Ator: Todos os públicos.
• Critério de Aceite: A Home Page deve exibir todas as seções em dispositivos móveis sem quebra de layout. Ao selecionar um card de perfil, o usuário deve ser levado à área temática correspondente. A seção de Favoritos não deve ser renderizada quando o visitante não tiver nenhum favorito salvo, e não deve exigir autenticação. A atualização de banners e notícias no CMS deve refletir na Home Page em até 5 minutos.

Descrição: O sistema deve disponibilizar um calendário de sessões de julgamento com distinção visual obrigatória entre sessões presenciais e sessões de Votação Simultânea. No detalhamento da pauta, cada item exibe a ordem na pauta, o número do processo, o assunto, a ementa, os interessados e o relator da pauta, sinalizando “Não informado” na ausência de qualquer desses dados. A pauta é ordenada por relator, com os processos de uma mesma cadeira em faixa contígua de ordem. O procurador não é exibido no item da pauta: o procurador da sessão consta da composição, acessível pelo botão de membros, e o procurador do processo pertence à Consulta de Processos. O relator aparece em linha única — a substituição de cadeira já vem resolvida na origem e não é sinalizada. O número do processo é link para o detalhamento do processo, aberto na mesma aba. Em processo sigiloso, o item exibe o marcador “Sigiloso”, preserva os dados públicos e substitui ementa e interessados por aviso de restrição legal, sem link e sem gravação. A pauta é sempre paginada, com 20 itens por página por padrão e seletor de 10, 20 ou 50.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39411. A evolução de escopo #43222 (layout do detalhe da sessão, relator da pauta e vídeo de processo sigiloso) está em teste.
• Documentação: RF_011.
• Ator: Advogado, Partes Processuais, Jornalista, Jurisdicionado, Servidor Interno.
• Critério de Aceite: O calendário deve exibir distinção visual entre sessões presenciais e de Votação Simultânea, utilizando exclusivamente esses dois termos. Cada item da pauta deve exibir ordem, número do processo, assunto, ementa, interessados e relator da pauta; campos sem informação devem exibir “Não informado.” O item da pauta não deve exibir procurador. O número do processo deve abrir o detalhamento do processo na mesma aba. Processo sigiloso deve exibir o marcador “Sigiloso”, com o número sem link e um aviso de restrição legal no lugar da ementa e dos interessados, mantendo visível a ordem na pauta. A pauta deve abrir paginada com 20 itens por página, com seletor de 10, 20 ou 50, e o total exibido deve considerar o conjunto filtrado.

Descrição: O sistema deve disponibilizar consulta unificada de jurisprudência (acórdãos e decisões) e atos normativos (portarias, resoluções e instruções normativas) do TCE-GO, com suporte a pesquisa por termos livres, número do ato ou acórdão, assunto (taxonomia padronizada) e período de publicação. Os resultados devem ser exibidos de forma paginada (10 registros por página), ordenados por relevância ou data, com fragmento de texto destacando o termo pesquisado em negrito e botão de download do PDF correspondente a cada resultado.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39412.
• Documentação: RF_012.
• Ator: Jurisdicionado, Advogado, Partes Processuais, Servidor Interno.
• Critério de Aceite: Ao realizar pesquisa por termo livre, o sistema deve retornar resultados que contenham o termo no título, ementa ou conteúdo do documento, com fragmento de texto destacado em negrito. Ao aplicar filtro de assunto, o sistema deve retornar apenas resultados indexados com aquele assunto, mantendo o termo de pesquisa original. Ao não localizar resultados, o sistema deve exibir: “Nenhum resultado encontrado para os critérios informados.” Os resultados devem ser paginados com 10 registros por página e conter botão de download funcional para o PDF correspondente.

Descrição: O sistema deve disponibilizar a Página de Imprensa como hub central de comunicação externa do TCE-GO, reunindo quatro seções: Notícias, conteúdo jornalístico institucional em lista paginada com página de detalhe; Momentos do TCE-GO, galeria fotográfica em grade de álbuns, incorporada do Flickr; Onde o TCE Apareceu, o clipping eletrônico em feed editorial; e Rádio TCE-GO, banner de acesso à rádio institucional. A página de detalhe de cada notícia traz o corpo da matéria, barra de autor e compartilhamento com meta tags Open Graph geradas automaticamente (ver Criação, Edição e Publicação de Notícias), crédito de foto, bloco de atendimento à imprensa, bloco de inscrição na newsletter e notícias relacionadas.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos. Demanda #39413.
• Documentação: RF_013.
• Ator: Jornalista, Cidadão, Todos os públicos.
• Critério de Aceite: A Página de Imprensa deve exibir as quatro seções com separação visual clara, sem mesclagem de conteúdos. Ao compartilhar o link de uma notícia em redes sociais, a prévia deve exibir título, descrição e imagem definidos nos campos de meta tags do CMS. A galeria Momentos do TCE-GO deve exibir os álbuns do Flickr e permitir a navegação até o álbum de origem. Ao acionar o botão de inscrição na newsletter, o sistema deve abrir formulário para informação de e-mail e confirmar a inscrição ao usuário.

Descrição: O sistema deve disponibilizar no Portal Público o acervo documental do TCE-GO em um hub único, organizado pelos tipos: Normativo, Relatório, Boletim, Cartilha, Manual/Tutorial, Livro/Revista, Apresentação e Clipping Eletrônico. A navegação se dá em três camadas: hub (vitrine com as publicações recentes e acesso por tipo), lista por tipo (com busca e paginação) e detalhe da publicação (metadados completos e acesso aos arquivos vinculados). Cada publicação pode ter mais de um arquivo, disponibilizado individualmente para download. Por convenção, cada registro de Clipping Eletrônico representa uma edição mensal, com os arquivos diários vinculados individualmente.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos.
• Documentação: na história #40473.
• Ator: Todos os públicos.
• Critério de Aceite: O hub deve exibir as publicações recentes e uma via de acesso para cada tipo. Ao selecionar um tipo, o sistema deve exibir apenas publicações daquele tipo, com busca e paginação. A página de detalhe deve exibir os metadados da publicação e um item de download para cada arquivo vinculado, com nome, formato e tamanho. Publicações em Rascunho ou despublicadas não devem ser exibidas em nenhuma das três camadas.

Descrição: O sistema deve permitir que o visitante marque serviços do Portal como favoritos e os acesse rapidamente pela seção de Favoritos da Home Page. Os favoritos são armazenados no localStorage do navegador, sem necessidade de autenticação e sem sincronização entre dispositivos, e podem ser adicionados e removidos diretamente nas páginas de serviço. São favoritáveis os dois tipos de serviço do catálogo: o interno, que ao ser acionado navega para a rota do próprio Portal, e o externo, que abre o serviço em nova aba. A seção de Favoritos só é renderizada quando houver ao menos um favorito salvo — na primeira visita, não aparece.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos.
• Documentação: na história #39414.
• Ator: Todos os públicos.
• Critério de Aceite: Ao marcar um serviço como favorito, o item deve aparecer na seção de Favoritos da Home Page, sem necessidade de autenticação. Ao remover um item dos favoritos, ele deve deixar de aparecer na seção imediatamente. Sem nenhum favorito salvo, a seção não deve ser renderizada. Serviço interno deve abrir na rota do próprio Portal e serviço externo, em nova aba. Os favoritos devem persistir ao fechar e reabrir o navegador, desde que o localStorage não tenha sido limpo.

Descrição: O sistema deve disponibilizar o acompanhamento em tempo real das sessões de Votação Simultânea do TCE-GO, exibindo os votos de cada conselheiro conforme são registrados durante a sessão. O painel de votação é o do Plenário Digital, incorporado à página. A página deve identificar a sessão exclusivamente como “Votação Simultânea”, exibir aviso de destaque informando a ausência de transmissão audiovisual, apresentar a descrição institucional da modalidade e encerrar automaticamente a exibição em tempo real ao término da sessão, disponibilizando o resultado consolidado. A modalidade tem base na Resolução Normativa nº 2/2020 do TCE-GO.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos.
• Documentação: na história #39415.
• Ator: Advogado, Partes Processuais, Jornalista, Todos os públicos.
• Critério de Aceite: A página deve exibir o aviso de formato em posição de destaque, identificando a sessão como “Votação Simultânea” e informando a ausência de transmissão audiovisual. O placar de votos deve ser atualizado automaticamente sem recarga manual da página. Ao término da sessão, o sistema deve exibir o resultado consolidado e remover o indicador de sessão em andamento. O termo “Ao Vivo” não deve aparecer em nenhum elemento da página.

Descrição: O sistema deve disponibilizar o Portal da Transparência do TCE-GO como subportal integrado ao Portal Principal, centralizando as informações de transparência do Tribunal organizadas em grupos temáticos definidos pelo PNTP (Programa Nacional de Transparência Pública). Cada grupo reúne itens exibidos como cards, e um item pode apontar para uma página já existente no Portal, para um link externo — como painéis Qlik Sense ou outros portais — ou para uma página simples criada e mantida no próprio hub. A responsabilidade pelo conteúdo é do Comitê de Transparência, designado por portaria, com autonomia sobre os grupos e itens do hub. Os dados e páginas devem ser indexados e recuperáveis pela Busca Global sob o filtro primário “Transparência”.

• Situação: Entregue — documentação, desenvolvimento e teste concluídos.
• Documentação: nas histórias #39416 (portal) e #41586 (gestão).
• Ator: Cidadão, Jornalista, Jurisdicionado.
• Critério de Aceite: O Portal da Transparência deve estar acessível a partir do menu principal do Portal TCE-GO sem autenticação. O hub deve exibir os grupos temáticos com seus itens publicados, sem exibir grupo sem item publicado. Um item deve poder apontar para página do Portal, link externo ou página simples do próprio hub. Conteúdo publicado no subportal deve ser indexado e recuperável pela Busca Global em até 5 minutos. O filtro “Transparência” na Busca Global deve retornar apenas conteúdos deste subportal. Somente o Comitê de Transparência deve ter permissão de publicação nesta área.

Descrição: O sistema deve disponibilizar no Portal Público as contratações realizadas pelo TCE-GO — editais, instrumentos convocatórios e atos de contratação direta — organizados por modalidade: Pregão, Concorrência, Dispensa de Licitação, Inexigibilidade, Credenciamento, Tomada de Preços e Convite (Carta-Convite). As duas últimas foram extintas pela Lei nº 14.133/2021, não recebem novos registros, aparecem ao final da navegação e devem ser sinalizadas como “Extinta” em todas as telas, permanecendo acessíveis apenas para consulta de processos históricos. O Plano de Contratações Anual (PCA) é publicado como item avulso, sem modalidade, com link direto no hub. A navegação se dá em três camadas: hub (vitrine, destaque para licitações em andamento e link para o PCA vigente), lista por modalidade (com busca e paginação) e detalhe (metadados, situação e documentos — edital, documentos por participante e anexos).

• Situação: Desenvolvido — teste pendente. O cadastro é integralmente manual: não há integração com o PNCP nem com o SIAFIC.
• Documentação: nas histórias #39410 (portal) e #41984 (gestão).
• Ator: Licitante, Jurisdicionado, Cidadão, Jornalista.
• Critério de Aceite: O hub deve exibir as modalidades vigentes antes das extintas. Toda tela que exibir Tomada de Preços ou Convite deve apresentar o marcador “Extinta”. Ao selecionar uma modalidade, o sistema deve exibir apenas as licitações daquela modalidade, com busca e paginação. A página de detalhe deve exibir a situação do processo e disponibilizar para download o edital, os documentos por participante e os anexos. O link para o PCA no hub deve levar ao plano do ano corrente.

Descrição: O sistema deve disponibilizar o Observatório do Cidadão como subportal integrado ao Portal Principal do TCE-GO, sem redirecionamento para domínio externo. É o hub de transparência ativa e dados abertos do Tribunal e reúne, sobretudo, um catálogo de painéis analíticos. Reaproveita a mesma estrutura de grupos temáticos e cards do Portal da Transparência, com uma diferença: no legado não havia autogestão de conteúdo, e cada painel era página estática — nesta entrega o conteúdo passa a ser gerenciado no CMS pelo Gestor de Conteúdo designado para a área.

• Situação: Desenvolvido — teste pendente.
• Documentação: nas histórias #42061 (portal), #39417 (gestão) e #42748 (migração das páginas).
• Ator: Todos os públicos.
• Critério de Aceite: O Observatório do Cidadão deve ser acessível a partir do menu de Outros Portais do Portal TCE-GO, mantendo o usuário dentro do domínio do Portal. Somente o Gestor de Conteúdo designado para este subportal deve ter permissão de publicação nesta área.

Descrição: O sistema deve disponibilizar o subportal do Pacto Nacional pela Primeira Infância integrado ao Portal Principal do TCE-GO, sem redirecionamento para domínio externo. O subportal dá visibilidade ao monitoramento de indicadores sociais da primeira infância — da gestação aos 6 anos —, mantido pelo TCE-GO como signatário do Pacto coordenado pelo CNJ. É o subportal mais homogêneo do Portal: quase todas as páginas seguem o mesmo molde, com texto institucional (contexto, conceito, interpretação e observações) seguido de uma sequência de painéis. O conteúdo é gerenciado no CMS pelo Gestor de Conteúdo designado para a área.

• Situação: Desenvolvido — teste pendente. A página gerenciável do Comitê Goiano do Pacto (#42851) ainda não foi detalhada.
• Documentação: nas histórias #40532 (portal), #42970 (gestão) e #42969 (migração das páginas).
• Ator: Todos os públicos.
• Critério de Aceite: O subportal Primeira Infância deve ser acessível a partir do menu de Outros Portais do Portal TCE-GO, mantendo o usuário dentro do domínio do Portal. Somente o Gestor de Conteúdo designado para esta área deve ter permissão de publicação neste subportal.

Descrição: O sistema deve disponibilizar o subportal do Sistema de Gestão Integrado (SGI), sob responsabilidade da Secretaria de Planejamento, integrado ao Portal Principal e sem redirecionamento para domínio externo. O subportal reúne a política do SGI, o modelo de governança institucional, os planos institucionais, a cadeia de valor de processos, as auditorias do sistema de gestão e os instrumentos de prestação de contas gerencial. A demanda é de migração do subportal hoje mantido no Liferay, adotando o padrão de hub com categorias e cards já validado no Portal da Transparência (RF_016). A curadoria do legado reorganizou 50 rotas em 28 páginas próprias e 8 categorias, eliminando páginas sem conteúdo, conteúdo duplicado e links quebrados. O conteúdo passa a ser gerenciado no CMS pelo Gestor de Conteúdo designado.

• Situação: Desenvolvido — teste pendente.
• Documentação: nas histórias #40528 (portal), #43085 (gestão) e #43084 (migração das páginas).
• Ator: Todos os públicos.
• Critério de Aceite: O subportal deve ser acessível a partir do menu do Portal TCE-GO, mantendo o usuário dentro do domínio do Portal. O hub deve exibir as categorias com seus respectivos cards, sem exibir categoria vazia. As rotas do subportal no Liferay devem redirecionar para a rota correspondente no novo Portal. Nenhum documento referenciado pelo subportal pode resultar em link quebrado após a migração. Somente o Gestor de Conteúdo designado para esta área deve ter permissão de publicação no subportal.

Descrição: O sistema deve disponibilizar a seção “O Tribunal” como porta de entrada para o conhecimento institucional do TCE-GO, com as páginas: Composição do Tribunal, com os membros atuais agrupados por função; Perfil do Membro, com dados e biografia de cada um; História e Competência, textos institucionais; Galeria Histórica, com todos os que já integraram o Tribunal desde 1947; Localização e Contato, com endereço, telefones, e-mail, horário e mapa; Órgãos Fiscalizados; e o Regimento Interno, publicado provisoriamente nesta seção até ser movido para Publicações Institucionais. A antiga Relação de Ramais foi substituída pela seção Contatos (ver Contatos). O Calendário de Feriados está previsto e ainda não foi especificado. Todo o conteúdo é gerenciado no CMS e consumido pelo Portal Público via API.

• Situação: Desenvolvido — teste concluído nas duas histórias; a reclassificação para Entregue está pendente. A Relação de Ramais foi substituída pela seção Contatos.
• Documentação: nas histórias #40529 (gestão dos membros) e #40530 (visualização institucional).
• Ator: Todos os públicos.
• Critério de Aceite: Todas as páginas devem ser acessíveis a partir do menu “O Tribunal” sem autenticação. A Composição do Tribunal deve exibir os membros atuais agrupados por função, cada um com link para o seu perfil. A Galeria Histórica deve apresentar os ex-integrantes em ordem cronológica. A composição atualizada no CMS deve refletir no Portal Público em até 5 minutos.

Descrição: O sistema deve disponibilizar, em lista única e pesquisável, os pontos de contato das áreas do TCE-GO, com telefone e e-mail institucional. Substitui a Relação de Ramais, que expunha apenas telefones organizados por bloco e andar do edifício e, por isso, não atendia a quem procura o Tribunal de fora. A entidade deixa de ser o ramal e passa a ser o contato: ponto de contato com nome, nenhum ou vários ramais e nenhum ou vários e-mails institucionais — o que comporta área só com e-mail, área só com ramal e área com mais de um e-mail. O contato tem uma de duas origens: e-TCE, proveniente da estrutura organizacional via integração com o catálogo de serviços, cujo nome e ramais são somente leitura e cujos e-mails são editáveis; e manual, cadastrado diretamente na gestão de conteúdo, com todos os campos editáveis. A origem manual atende ao que não é setor da estrutura: comissões, projetos e caixas temáticas.

• Situação: Desenvolvido — teste em execução.
• Documentação: nas histórias #43044 (portal) e #43045 (gestão).
• Ator: Todos os públicos, Gestor de Conteúdo.
• Critério de Aceite: A página deve listar os contatos ativos que possuam ao menos um ramal ou ao menos um e-mail, ordenados alfabeticamente em português. O campo de busca deve localizar o contato por parte do nome. Cada verbete deve exibir todos os ramais e todos os e-mails do contato. Contato de origem e-TCE deve ter nome e ramais bloqueados para edição na gestão de conteúdo, permanecendo os e-mails editáveis. Contato de origem manual deve permitir a edição de todos os campos.

Descrição: O sistema deve disponibilizar a Página de Ajuda do Portal Público composta por: FAQ (conteúdo estático mantido pelo time de desenvolvimento, organizado por categorias) e Fale Conosco (link de redirecionamento para o Canal de Ouvidoria do TCE-GO em https://ouvidoria.tce.go.gov.br/, aberto em nova aba do navegador).

• Situação: Desenvolvido — teste pendente.
• Documentação: na história #39401.
• Ator: Todos os públicos.
• Critério de Aceite: O FAQ deve exibir as perguntas agrupadas por categoria. Ao acionar o botão “Fale Conosco”, o usuário deve ser redirecionado para https://ouvidoria.tce.go.gov.br/ em nova aba, mantendo o Portal TCE-GO na aba original.

Descrição: O sistema deve disponibilizar a seção “Outros Portais” com links identificados para os portais externos vinculados ao TCE-GO: Observatório de Políticas Públicas, Revista Controle Externo e demais portais definidos pelo Gestor de Conteúdo. Cada item deve conter descrição breve e identificação visual de link externo, abrindo o destino em nova aba do navegador.

• Situação: Desenvolvido — teste pendente. Não é demanda própria: é o agrupamento de menu que dá acesso aos subportais do Tribunal (Transparência, Observatório do Cidadão, Primeira Infância e Governança, Planejamento e Gestão) e aos portais externos vinculados.
• Documentação: não há especificação própria. Cada subportal do Tribunal tem requisito próprio: Portal da Transparência (RF_016), Observatório do Cidadão (RF_017), Portal Primeira Infância (RF_018) e Portal de Governança, Planejamento e Gestão (RF_020).
• Ator: Todos os públicos.
• Critério de Aceite: Ao acionar um link de portal externo, o destino deve abrir em nova aba do navegador, mantendo o Portal TCE-GO na aba original. Cada link de portal externo deve ter identificação visual que indique ao usuário que será redirecionado para fora do Portal TCE-GO.

Descrição: O sistema deve garantir que todas as páginas e funcionalidades do Portal Público sejam 100% responsivas e funcionais em dispositivos com tela a partir de 320px de largura (smartphones, tablets e desktops), sem quebra de layout, sobreposição de elementos ou perda de funcionalidades. O Portal deve aderir às diretrizes do e-MAG 3.1 (Modelo de Acessibilidade em Governo Eletrônico) em nível AA, incluindo contraste mínimo de 4,5:1 para texto normal e 3:1 para texto grande e elementos de interface, navegação completa por teclado com foco visível, nome acessível em todo controle e campo, ampliação até 200% sem perda de conteúdo ou de função e sem rolagem horizontal, textos alternativos em todas as imagens informativas e compatibilidade com leitores de tela. Todos os filtros e campos de busca devem ser plenamente operacionais em dispositivos móveis. O requisito abrange ainda duas páginas de apoio, acessíveis de qualquer ponto do Portal: Acessibilidade, que consolida os recursos oferecidos (alternância de alto contraste, tradução em Libras, atalhos de teclado e canal para relatar barreiras), com link na barra superior; e Mapa do Site, que lista de forma hierárquica e agrupada por seção todos os links de navegação pública do Portal, com link no rodapé.

• Situação: Desenvolvido — teste em execução. A mesma história cobre o Mapa do Site.
• Documentação: na história #41519.
• Ator: Todos os públicos.
• Critério de Aceite: Todas as páginas do Portal devem ser renderizadas sem quebra de layout em dispositivos com tela a partir de 320px de largura. Todos os filtros, campos de busca e botões de ação devem ser operacionais em dispositivos móveis. O Portal deve obter aprovação em auditoria de acessibilidade e-MAG 3.1 nível AA por ferramenta automatizada e revisão manual. O Portal deve ser funcional nos navegadores Chrome, Firefox, Edge e Safari nas versões correntes na data de homologação. A página de Acessibilidade deve ser alcançável pela barra superior e a de Mapa do Site pelo rodapé, em qualquer página do Portal. O Mapa do Site não deve listar conteúdo em rascunho, despublicado, restrito ou sigiloso.

Descrição: O sistema deve disponibilizar as páginas de Política de Privacidade e Termos de Uso acessíveis a partir do rodapé de todas as páginas do Portal, com conteúdo gerenciável pelo Gestor de Conteúdo via CMS sem alteração de código. O sistema deve exibir banner de consentimento de cookies no primeiro acesso do usuário, com opções de aceitar todos, recusar não essenciais ou configurar preferências por categoria — essenciais, que não podem ser desativados, desempenho e terceiros. A escolha do usuário deve ser armazenada no localStorage e respeitada nas visitas subsequentes. Cookies de rastreamento não devem ser ativados sem consentimento explícito, em integração direta com o requisito Monitoramento de Atividades (Google Analytics).

• Situação: Desenvolvido — teste impedido pelo mesmo motivo do Monitoramento de Atividades: a verificação de propriedade do site só será possível com URL pública. O texto do Termo de Uso ainda é rascunho e precisa ser refeito.
• Documentação: na história #40402.
• Ator: Todos os públicos, Gestor de Conteúdo.
• Critério de Aceite: No primeiro acesso ao Portal, o banner de consentimento deve ser exibido antes da ativação de qualquer cookie não essencial. Ao selecionar “Recusar Não Essenciais”, o sistema não deve ativar cookies de analytics ou rastreamento e o Google Analytics não deve coletar dados da sessão. A preferência selecionada deve ser respeitada na visita seguinte, sem nova exibição do banner. As páginas de Política de Privacidade e Termos de Uso devem ser acessíveis a partir do rodapé em todas as páginas do Portal. O Gestor de Conteúdo deve ser capaz de atualizar o texto dessas páginas via CMS, com reflexo no Portal em até 5 minutos.

Os três requisitos deste bloco não têm tela para o cidadão: são scripts executados pela equipe técnica para levar ao novo Portal o conteúdo do Liferay e os cadastros iniciais. Os scripts foram criados e testados em homologação. Na virada para produção, a carga será revista e executada novamente sobre o banco de produção.

Descrição: O sistema deve importar para o WordPress os arquivos publicados na biblioteca de documentos do Liferay, a partir de um de-para levantado por grupo de arquivos nos painéis Qlik e conferido na API do Liferay. Cada arquivo vira uma mídia, e cada publicação vira uma Publicação Institucional (ver Upload e Categorização de Publicações Institucionais) com seus arquivos vinculados, tipo, assunto, palavras-chave e resumo já classificados. O volume é de 22 grupos, 2.118 arquivos e 1.856 publicações, das quais 1.431 são edições do Clipping Eletrônico. Depois da importação, o de-para recebe a URL gerada para cada arquivo no WordPress, e com ela as URLs antigas do Liferay são redirecionadas e as referências a elas são trocadas.

• Situação: Desenvolvido — script criado e testado em homologação; a carga será revista e executada na virada para produção. Demanda #42800.
• Documentação: RF_033 (PRD do import e de-para por grupo, no repositório do projeto).
• Ator: Equipe técnica (execução); Gestor de Conteúdo (conferência).
• Critério de Aceite: Todo arquivo do de-para deve existir no WordPress após a carga, vinculado à publicação indicada. O de-para deve registrar, para cada arquivo, a URL gerada no WordPress. Nenhuma URL antiga do Liferay presente no de-para deve resultar em link quebrado após a virada.

Descrição: O sistema deve importar para o formulário de Licitação do WordPress (ver Licitações e Contratos) os processos publicados na página “Acesso aos Licitantes” do Liferay: editais de licitação de 2004 a 2026 e contratações diretas de 2021 a 2026. São 951 processos identificados a partir dos nomes das pastas e do texto dos PDFs. Cada arquivo vai para o campo próprio do formulário (edital, anexos, respostas, participantes, sessões e retificações), e o vencedor é obtido do painel Qlik de licitações, dos contratos do PNCP ou do próprio ato de dispensa ou inexigibilidade. Os processos com dado a confirmar entram como rascunho, para revisão da área responsável. O Plano de Contratações Anual fica fora deste requisito, porque é migrado com os arquivos do Liferay.

• Situação: Desenvolvido — script criado e testado em homologação; a carga será revista e executada na virada para produção. Demanda #44009.
• Documentação: RF_034 (análise, decisões e planilhas de revisão, no repositório do projeto).
• Ator: Equipe técnica (execução); área responsável pelas licitações (revisão dos rascunhos).
• Critério de Aceite: Cada processo identificado na página do Liferay deve existir no WordPress com modalidade, número, ano e objeto preenchidos e com os arquivos nos campos correspondentes. Processo com situação a confirmar, sem documento principal ou sem número deve entrar como rascunho e não aparecer no Portal Público até a revisão da área.

Descrição: O sistema deve receber, por carga, dois cadastros iniciais preparados com as áreas em planilha. O primeiro é o catálogo de serviços (ver Portal de Serviços): 72 serviços, com tipo de acesso (Público, Com cadastro ou Restrito/Interno), ícone, público-alvo, passos de “Como acessar” e materiais de ajuda. O segundo são os vínculos de páginas internas e externas a menus e subportais: 38 itens, distribuídos em 11 grupos dos banners da Home Page, do Portal da Transparência e do Observatório do Cidadão. A carga de vínculos não cria grupos: verifica antes se cada grupo de destino já está cadastrado e, se não estiver, bloqueia os itens daquele grupo e informa no relatório.

• Situação: Desenvolvido — script criado e testado em homologação; a carga será revista e executada na virada para produção. Demanda #43881 (vínculos de páginas).
• Documentação: RF_035 (planilhas de origem, pendências e orientações da carga, no repositório do projeto).
• Ator: Equipe técnica (execução); Gestor de Conteúdo (cadastro prévio dos grupos).
• Critério de Aceite: Após a carga, os 72 serviços devem constar do catálogo com todos os campos obrigatórios preenchidos. O script deve recusar a planilha que tiver dado que o formulário não aceita, como ícone inexistente, tipo de acesso fora da lista ou texto acima do limite do campo. Item de vínculo cujo grupo de destino não esteja cadastrado não deve ser gravado, e o relatório da carga deve indicar o grupo ausente. A verificação dos grupos deve ser executada também na simulação (dry-run), sem gravar dados.

— Situação apurada em 09/09/2026 a partir do planejamento de backlog do projeto; números de demanda conferidos na API do Redmine (projeto PORTAL TCE-GO Reformulação). Cronograma e requisitos RF_033 a RF_035 atualizados em 25/09/2026.
— Atualizado com: Claude Code (Opus 5), a partir dos PRDs mantidos no repositório do protótipo.
— //Revisado por: @pramorim - Paulo Ricardo Amorim //