Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- pres:gerti:gestao_de_ativos:portal:er_008 [07/07/2026 12:03] – pramorim
+++ pres:gerti:gestao_de_ativos:portal:er_008 [08/09/2026 16:49] (atual) – pramorim
@@ Linha 7: / Linha 7: @@
   * Página de confirmação: ''/acompanhar-processo/confirmar?token={token}''
   * Página de gerenciamento: ''/acompanhar-processo/gerenciar?token={token}''
-  * Página de cancelamento: ''/acompanhar-processo/cancelar?token={token}&processo={id}''
+  * Página de cancelamento: ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''
 ----
@@ Linha 41: / Linha 41: @@
 ^Elemento^Tipo^Obrigatório^Valores Possíveis^Valor Padrão^Observação|
-|Botão "Quero acompanhar"|Botão|-|-|-|Exibido no estado //idle//. Abre o formulário de e-mail ao ser clicado.|
+|Botão "Quero acompanhar"|Botão|-|-|-|Exibido no estado //idle//. Abre o formulário de e-mail **na própria página**, sem diálogo sobreposto.|
 |Cabeçalho do formulário|Texto|-|-|"Acompanhar processo nº {numero}"|Exibido nos estados //formulario// e //loading//. O número do processo é preenchido dinamicamente.|
-|E-mail|Campo texto|Sim|Formato RFC 5322|Vazio|Exibido nos estados //formulario// e //loading//. Deve conter um endereço de e-mail válido (RN01). Exibe mensagem de erro inline "Informe um e-mail válido." quando inválido.|
+|E-mail|Campo texto|Sim|Formato RFC 5322|Vazio|Exibido nos estados //formulario// e //loading//. Deve conter um endereço de e-mail válido (RN01). Exibe a mensagem "Informe um e-mail válido." abaixo do rótulo do campo quando o valor informado é inválido **ou** quando o campo não é preenchido.|
 |Botão "Quero acompanhar" (submit)|Botão submit|-|-|-|Exibido no estado //formulario//. No estado //loading//, é substituído por spinner com texto "Enviando...". Desabilitado durante o processamento.|
 |Botão "Cancelar"|Botão|-|-|-|Exibido no estado //formulario//. Retorna o widget ao estado //idle// sem enviar a solicitação. Desabilitado durante o processamento.|
@@ Linha 69: / Linha 69: @@
 |Título "Inscrição confirmada!"|Texto|-|-|-|Exibido no estado //sucesso// após validação bem-sucedida do token (RN02).|
 |Mensagem de confirmação|Texto|-|-|-|Exibido no estado //sucesso//. Texto: "Você receberá notificações por e-mail sempre que o processo nº {numero} for movimentado." O número do processo é extraído do token.|
-|Botão "Consultar processo"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/processos/{id}'' do processo recém-confirmado.|
+|Botão "Consultar processo"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/processo/{id}'' do processo recém-confirmado.|
-|Botão "Gerenciar meus acompanhamentos"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/acompanhar-processo/gerenciar?token=...''.|
+|Botão "Gerenciar meus acompanhamentos"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/acompanhar-processo/gerenciar?token=...'', **reaproveitando o token recebido no link de confirmação** (RN02, RN09).|
-|Lista "Seus processos acompanhados"|Lista de cards|-|-|-|Exibida no estado //sucesso//. Lista todos os processos vinculados ao e-mail confirmado, incluindo o recém-adicionado.|
+|Lista "Seus processos acompanhados"|Lista de cards|-|-|-|Exibida no estado //sucesso//. Lista os **3 processos mais recentes** vinculados ao e-mail confirmado (ordenados pela data de inclusão do acompanhamento, do mais recente para o mais antigo), incluindo o processo recém-confirmado (RN13). Para ver a lista completa, o usuário acessa "Gerenciar meus acompanhamentos".|
 |Título "Link inválido ou expirado"|Texto|-|-|-|Exibido no estado //erro// quando o token é inválido ou expirou após 48h (RN02).|
 |Mensagem de erro|Texto|-|-|-|Exibido no estado //erro//. Texto: "Este link de confirmação não é mais válido. Os links expiram em 48 horas após o envio. Retorne à página do processo e solicite um novo link."|
@@ Linha 83: / Linha 83: @@
 |Indicador de carregamento|Spinner|-|-|-|Exibido no estado //loading// enquanto o token é validado e a lista é carregada. Acompanha o texto "Carregando seus acompanhamentos…".|
 |Identificação do e-mail|Texto|-|-|-|Exibido no estado //lista//. Texto: "Processos acompanhados pelo e-mail: {email mascarado}". O e-mail é parcialmente ocultado pelo servidor.|
-|Card de processo|Card|-|-|-|Exibido no estado //lista// para cada processo acompanhado. Contém: número do processo (link clicável para ''/processos/{id}''), interessado, assunto e ano.|
+|Card de processo|Card|-|-|-|Exibido no estado //lista// para cada processo acompanhado. Contém: número do processo (link clicável para ''/processo/{id}''), interessado, assunto e ano.|
 |Botão "Parar de acompanhar"|Botão|-|-|-|Exibido em cada card no estado //lista//. Abre a confirmação inline no próprio card (RN11).|
 |Confirmação inline de remoção|Expansão inline|-|-|Recolhido|Exibida no card após clique em "Parar de acompanhar". Exibe o alerta "Deseja parar de acompanhar este processo?" com os botões "Confirmar" e "Cancelar" (RN11).|
@@ Linha 89: / Linha 89: @@
 |Botão "Cancelar" (remoção)|Botão|-|-|-|Fecha a confirmação inline sem executar nenhuma ação (RN11).|
 |Mensagem de lista vazia|Texto|-|-|-|Exibida quando todos os processos são removidos ou quando o e-mail não possui acompanhamentos ativos. Texto: "Você não está acompanhando nenhum processo no momento." Acompanha link "Consultar processos no portal" → ''/processos''.|
+|Paginação|Componente de paginação|-|-|-|Exibida no estado //lista// somente quando a quantidade de processos acompanhados ultrapassa **12 itens**. Reaproveita o componente ''Pagination'' já usado em ''/processos'' (mesmo padrão visual). Necessária porque não há limite máximo de processos por e-mail (RN10, RN14).|
 |Título "Link expirado"|Texto|-|-|-|Exibido no estado //token-expirado// quando o token é inválido (RN02).|
 |E-mail (reenvio de link)|Campo texto|Sim|Formato RFC 5322|Vazio|Exibido no estado //token-expirado//. Utilizado para solicitar novo link de gerenciamento (RN08).|
@@ Linha 109: / Linha 110: @@
 |Título "Acompanhamento cancelado"|Texto|-|-|-|Exibido no estado //sucesso// após remoção bem-sucedida (RN06).|
 |Mensagem de cancelamento|Texto|-|-|-|Exibido no estado //sucesso//. Texto: "Você não receberá mais notificações sobre o processo nº {numero}." O número do processo é extraído do token.|
-|Botão "Ver todos os meus acompanhamentos"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/acompanhar-processo/gerenciar?token=...'' (RN07).|
+|Botão "Ver todos os meus acompanhamentos"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/acompanhar-processo/gerenciar?token=...'', **reaproveitando o token recebido no link de cancelamento** (RN02, RN07, RN09).|
 |Botão "Consultar processos"|Botão|-|-|-|Exibido no estado //sucesso//. Redireciona para ''/processos''.|
 |Título "Link inválido"|Texto|-|-|-|Exibido no estado //erro// quando o token é inválido ou já foi utilizado.|
@@ Linha 119: / Linha 120: @@
 ===== E-mails Enviados =====
-Todos os e-mails seguem o padrão visual institucional do TCE-GO e são despachados pelo servidor **`smtp.tce.go.gov.br`**, reaproveitando a camada de serviço compartilhada `IServicoDeEmail`/`ServicoDeEmail` (`TCE.Compartilhado.Servico.Servicos.Contato`), a mesma já utilizada por `ServicoDeUsuarioPush` no legado. O RF-008 não deve implementar um novo mecanismo de envio — apenas montar `DtoEmail` (destinatário, assunto, corpo HTML) e chamar essa camada compartilhada, como já ocorre em `ServicoDeUsuarioPush.EnviaEmail`. Nenhuma ação dos e-mails depende de login — cada link carrega o token correspondente (RN02, RN09) e o ID de autuação do processo, quando aplicável.
+Todos os e-mails seguem o padrão visual institucional do TCE-GO, são remetidos pelo endereço **`push@tce.go.gov.br`** e despachados pelo servidor **`smtp.tce.go.gov.br`**, reaproveitando a camada de serviço compartilhada `IServicoDeEmail`/`ServicoDeEmail` (`TCE.Compartilhado.Servico.Servicos.Contato`), a mesma já utilizada por `ServicoDeUsuarioPush` no legado. O RF-008 não deve implementar um novo mecanismo de envio — apenas montar `DtoEmail` (remetente, destinatário, assunto, corpo HTML) e chamar essa camada compartilhada, como já ocorre em `ServicoDeUsuarioPush.EnviaEmail`. Nenhuma ação dos e-mails depende de login — cada link carrega o token correspondente (RN02, RN09) e o ID de autuação do processo, quando aplicável.
 ==== E-mail 01 – Confirmação de Inscrição ====
+{{:pres:gerti:gestao_de_ativos:portal:confirme_-_tce_go_push.png?direct&600|}} \\
 Disparado ao final do Fluxo 01 (passo 07.1), sempre que uma inscrição em um processo aguarda confirmação — inclusive para e-mails que já confirmaram outros processos anteriormente (RN03).
 ^Elemento^Conteúdo^Observação|
+|Remetente|`push@tce.go.gov.br`|Endereço institucional único para os três e-mails do RF-008.|
 |Assunto|"Serviço de acompanhamento de processos TCE-GO — Confirme o acompanhamento do processo Nº {numero}"|O número do processo é usado apenas para exibição; a comunicação interna do link usa o ID de autuação.|
 |Corpo|"Você solicitou o acompanhamento do processo Nº {numero} no Serviço de acompanhamento de processos TCE-GO. Clique no link abaixo para confirmar este acompanhamento."|Não há saudação por nome nem qualquer referência a cadastro/senha — o usuário não preenche esses dados (RN12).|
-|Botão "Confirmar acompanhamento"|Redireciona para ''/acompanhar-processo/confirmar?token={token}''|Aciona o **Fluxo 02**. Token de confirmação, uso único, validade de 48h (RN02).|
+|Botão "Confirmar acompanhamento"|Redireciona para ''/acompanhar-processo/confirmar?token={token}''|Aciona o **Fluxo 02**. Token único do serviço, validade de 48h, reaproveitável nos demais fluxos (RN02, RN09).|
 |Rodapé|"Se você não solicitou este acompanhamento, ignore este e-mail."|Nenhum vínculo é criado até o clique de confirmação — mitigação de abuso (RN03).|
 ==== E-mail 02 – Notificação de Movimentação ====
+{{:pres:gerti:gestao_de_ativos:portal:pasted:20260907-131356.png?direct&600}} \\
-Disparado pelo backend sempre que houver uma movimentação em um processo já confirmado (evento externo ao protótipo, originado de job/scheduler que monitora `PRO_AUTUACAO`).
+Disparado sempre que houver uma movimentação em um processo já confirmado. **O disparo e a montagem da mensagem ocorrem na rotina PL/SQL de notificação, dentro do banco** (ver [[#mecanismo_de_disparo_da_notificacao_legado|Mecanismo de Disparo da Notificação]]). O RF-008 **especifica** o conteúdo, o layout e os links; a implementação do template é feita onde o disparo acontece.
 ^Elemento^Conteúdo^Observação|
+|Remetente|`push@tce.go.gov.br`|Endereço institucional único para os três e-mails do RF-008.|
 |Assunto|"Serviço de acompanhamento de processos TCE-GO — Movimentação no processo Nº {numero}"| |
-|Corpo|Número do processo, descrição da movimentação e data|Dados somente para leitura; não há ação além dos links abaixo.|
+|Corpo — identificação|Número do processo| |
-|Link "Ver processo completo"|Redireciona para ''/processos/{id}''|Consulta pública do processo, sem necessidade de token.|
+|Corpo — **Andamento atual**|"Órgão ou Setor Atual: {setor}" (ex.: "DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO - DI-TI") e data da movimentação|Informa **para onde** o processo foi movimentado — é o dado que motiva a notificação.|
-|Link "Gerenciar meus acompanhamentos"|Redireciona para ''/acompanhar-processo/gerenciar?token={token}''|Aciona o **Fluxo 03**. Token de gerenciamento, uso múltiplo dentro da validade (RN09).|
+|Corpo — **Dados da autuação**|"Data Autuação: {data}" e "Ano Referência: {ano}"|Contextualizam o processo para quem acompanha vários.|
-|Link "Parar de acompanhar este processo"|Redireciona para ''/acompanhar-processo/cancelar?token={token}&processo={id}''|Aciona o **Fluxo 04**. Remove apenas o processo referenciado neste link — não afeta os demais acompanhamentos do e-mail (RN07).|
+|Link "Ver processo completo"|Redireciona para ''/processo/{id}''|Consulta pública do processo, sem necessidade de token.|
+|Link "Solicitar link de gerenciamento"|Redireciona para ''/acompanhar-processo/gerenciar'' — **sem token**|A rota sem token apresenta o formulário de solicitação, acionando o **Fluxo 05**. Este e-mail **não carrega token de sessão**: chega semanas ou meses após a inscrição, quando qualquer token de 48h já expirou (RN02).|
+|Link "Parar de acompanhar este processo"|Redireciona para ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''|Aciona o **Fluxo 04**, com o **hash de descadastro** (RN16) — persistente e de escopo único — e o ID do acompanhamento. Remove apenas o vínculo referenciado, e **não dá acesso ao painel** (RN07, RN17).|
 ==== E-mail 03 – Reenvio de Link de Gerenciamento ====
+{{:pres:gerti:gestao_de_ativos:portal:gerenciar_-_tce_go_push-_localhost_.png?direct&600|}}\\
 Disparado ao final do Fluxo 05, **somente** quando o e-mail informado possui acompanhamentos ativos na base — o backend nunca confirma nem nega essa condição na resposta exibida ao usuário (RN08). O envio (ou não) deste e-mail é a única diferença observável entre "e-mail existe" e "e-mail não existe".
 ^Elemento^Conteúdo^Observação|
+|Remetente|`push@tce.go.gov.br`|Endereço institucional único para os três e-mails do RF-008.|
 |Assunto|"Serviço de acompanhamento de processos TCE-GO — Seu link de gerenciamento"| |
 |Corpo|Link de acesso ao painel de gerenciamento|O reenvio não invalida tokens de gerenciamento já emitidos e ainda válidos (RN09) — pode haver mais de um link de gerenciamento válido simultaneamente para o mesmo e-mail.|
@@ Linha 158: / Linha 167: @@
 ^Passo^Ação^Regra^Tela|
-|01|Usuário acessa a página de um processo autuado em ''/processos/{id}''| |Tela 01|
+|01|Usuário acessa a página de um processo autuado em ''/processo/{id}''| |Tela 01|
 |02|O sistema exibe o widget TCE-Push no estado idle com o botão "Quero acompanhar"| |Tela 01|
 |03|Usuário clica em "Quero acompanhar"| |Tela 01|
 |04|O sistema exibe o formulário com o campo "Seu e-mail" e o cabeçalho "Acompanhar processo nº {numero}"| |Tela 01|
 |05|Usuário informa o e-mail e clica em "Quero acompanhar"|RN01|Tela 01|
-|05.1|E-mail inválido: o sistema exibe mensagem de erro inline "Informe um e-mail válido." e aguarda nova entrada|RN01|Tela 01|
+|05.1|E-mail inválido ou não preenchido: o sistema exibe a mensagem "Informe um e-mail válido." abaixo do rótulo do campo e aguarda nova entrada|RN01|Tela 01|
 |06|O sistema transiciona o widget para o estado loading e processa a solicitação| |Tela 01|
 |07|O sistema valida que o e-mail não está inscrito neste processo|RN03 RN04| |
@@ Linha 170: / Linha 179: @@
 |08|O sistema identifica que o e-mail já está inscrito para este processo|RN04| |
 |08.1|O sistema exibe o estado inscrito: "Você já está acompanhando este processo" com o e-mail informado|RN04|Tela 01|
-|10|O sistema identifica que o número do processo não existe|RN05| |
+|09|O sistema identifica que o número do processo não existe|RN05| |
-|10.1|O sistema exibe o estado erro com a mensagem retornada pelo servidor|RN05|Tela 01|
+|09.1|O sistema exibe o estado erro com a mensagem retornada pelo servidor|RN05|Tela 01|
 ==== Fluxo 02 – Confirmação de Inscrição ====
@@ Linha 183: / Linha 192: @@
 |05.1|O sistema vincula o processo ao e-mail|RN02| |
 |05.2|O sistema exibe o estado sucesso: "Inscrição confirmada!" com o número do processo|RN02|Tela 02|
-|05.3|O sistema exibe a lista de todos os processos acompanhados pelo e-mail| |Tela 02|
+|05.3|O sistema exibe os 3 processos mais recentes acompanhados pelo e-mail|RN13|Tela 02|
 |06|Token inválido ou expirado|RN02| |
 |06.1|O sistema exibe o estado erro: "Link inválido ou expirado" com botão "Tentar novamente"|RN02|Tela 02|
@@ Linha 191: / Linha 200: @@
 ^Passo^Ação^Regra^Tela|
-|01|Usuário recebe o e-mail de notificação de movimentação com link "Gerenciar meus acompanhamentos"| |E-mail 02|
+|01|Usuário acessa o painel por uma de duas origens: o link "Gerenciar meus acompanhamentos" do **E-mail 03** (com token de sessão), ou o link "Solicitar link de gerenciamento" do **E-mail 02**, que leva ao formulário do Fluxo 05 e resulta no envio do E-mail 03|RN02 RN16|E-mail 02 · E-mail 03|
 |02|Usuário clica no link| | |
-|03|O sistema redireciona para ''/acompanhar-processo/gerenciar?token={token}''| |Tela 03|
+|03|O sistema redireciona para ''/acompanhar-processo/gerenciar?token={token}''; sem token, a rota apresenta o formulário de solicitação (Fluxo 05)|RN02|Tela 03|
-|04|O sistema exibe o estado loading: "Carregando seus acompanhamentos…" e valida o token|RN09|Tela 03|
+|04|O sistema exibe o estado loading: "Carregando seus acompanhamentos…" e valida o token de sessão|RN09|Tela 03|
 |05|Token válido|RN09| |
-|05.1|O sistema exibe a lista de todos os processos acompanhados pelo e-mail associado ao token, com o e-mail mascarado|RN09|Tela 03|
+|05.1|O sistema exibe a primeira página da lista de processos acompanhados pelo e-mail associado ao token, com o e-mail mascarado|RN09|Tela 03|
 |05.2|Lista vazia: o sistema exibe o empty state "Você não está acompanhando nenhum processo no momento."| |Tela 03|
+|05.3|Lista com mais de 12 processos: o sistema exibe o componente de paginação; usuário navega entre páginas sem recarregar a tela|RN14|Tela 03|
 |06|Usuário clica em "Parar de acompanhar" em um processo|RN11| |
 |06.1|O sistema exibe, inline no card, o alerta "Deseja parar de acompanhar este processo?" com os botões "Confirmar" e "Cancelar"|RN11|Tela 03|
 |06.2|Usuário clica em "Cancelar": o sistema fecha a confirmação sem executar nenhuma ação|RN11| |
-|06.3|Usuário clica em "Confirmar": o sistema exibe spinner no item e executa a remoção|RN11|Tela 03|
+|06.3|Usuário clica em "Confirmar": o sistema exibe spinner no item e executa a remoção, autenticada pelo **token de sessão** da própria tela|RN11 RN17|Tela 03|
 |06.4|O sistema remove o processo da lista sem recarregar a página e oculta o spinner| |Tela 03|
 |06.5|Lista esvaziada: o sistema exibe o empty state automaticamente| |Tela 03|
@@ Linha 211: / Linha 221: @@
 ^Passo^Ação^Regra^Tela|
-|01|Usuário recebe o e-mail de notificação com link "Parar de receber este acompanhamento"| |E-mail 02|
+|01|Usuário recebe o e-mail de notificação com link "Parar de acompanhar este processo"| |E-mail 02|
 |02|Usuário clica no link| | |
-|03|O sistema redireciona para ''/acompanhar-processo/cancelar?token={token}&processo={id}''| |Tela 04|
+|03|O sistema redireciona para ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''|RN16 RN17|Tela 04|
-|04|O sistema exibe o estado loading: "Processando cancelamento…" e valida o token|RN06|Tela 04|
+|04|O sistema exibe o estado loading: "Processando cancelamento…" e valida o token de descadastro|RN06 RN16|Tela 04|
 |05|Token válido|RN06| |
 |05.1|O sistema remove imediatamente o processo da lista de acompanhamentos do e-mail|RN06| |
 |05.2|O sistema exibe o estado sucesso: "Acompanhamento cancelado" com o número do processo|RN06|Tela 04|
-|05.3|O sistema exibe o link "Ver todos os meus acompanhamentos" → ''/acompanhar-processo/gerenciar?token=...''|RN07|Tela 04|
+|05.3|O sistema exibe o link "Solicitar link de gerenciamento" → ''/acompanhar-processo/gerenciar'' (sem token)|RN07 RN16|Tela 04|
 |06|Token inválido| | |
-|06.1|O sistema exibe o estado erro: "Link inválido" com botão "Acessar painel de acompanhamentos"| |Tela 04|
+|06.1|O sistema exibe o estado erro: "Link inválido" com botão "Solicitar link de gerenciamento"| |Tela 04|
+<WRAP center round info>
+**Nota de segurança (RN16).** O token de descadastro autoriza **apenas** a remoção do acompanhamento referenciado. Concluído o cancelamento, a tela **não** exibe a lista de processos acompanhados nem oferece acesso direto ao painel — quem quiser ver a lista completa precisa passar pelo Fluxo 05, informando o e-mail e recebendo um token de sessão.
+</WRAP>
 ==== Fluxo 05 – Reenvio de Link de Gerenciamento ====
@@ Linha 238: / Linha 252: @@
 ^ Regra ^ Descrição ^
 |RN01|**Validação de formato de e-mail** – O e-mail informado deve ser válido conforme o formato RFC 5322. E-mails inválidos bloqueiam o envio do formulário com mensagem de erro inline.|
-|RN02|**Expiração de token** – O token de confirmação de inscrição expira em 48 horas a partir do envio. Após a expiração, o sistema exibe a mensagem de link inválido e o usuário deve solicitar novo acompanhamento.|
+|RN02|**Dois tipos de token, com finalidades distintas** – O TCE-Push emite: **(a) Token de sessão** – válido por 48 horas a partir do envio, emitido quando o usuário age (inscrição ou pedido de reenvio) e utilizável nos fluxos de confirmação e gerenciamento. É **reaproveitado** nos links das telas seguintes — não é emitido token novo a cada etapa. Após as 48 horas, o sistema exibe a mensagem de link inválido e o usuário deve solicitar novo link. **(b) Token de descadastro** – persistente e de escopo único, presente apenas no e-mail de notificação de movimentação (RN16). A separação existe porque o e-mail de movimentação não responde a uma ação do usuário: chega muito depois da inscrição, quando um token de 48 horas já expirou.|
 |RN03|**Confirmação obrigatória por inscrição (controle de abuso)** – Toda inscrição em um processo requer confirmação explícita por e-mail, independentemente de o endereço ter sido confirmado em processos anteriores. Como o serviço não possui autenticação, a confirmação por link é o único mecanismo que garante que apenas o titular do endereço pode ativar um vínculo processo/e-mail. Sem essa exigência, qualquer usuário poderia inscrever endereços de terceiros em processos arbitrários sem o consentimento do titular.|
 |RN04|**Vedação de inscrição duplicada** – O mesmo e-mail não pode ser inscrito duas vezes no mesmo processo. O sistema retorna a resposta JA_INSCRITO e exibe a mensagem: "Você já está acompanhando este processo".|
 |RN05|**Existência do processo** – O número de processo informado deve existir no sistema antes de aceitar a inscrição. Processos inexistentes bloqueiam o cadastro com mensagem de erro.|
 |RN06|**Cancelamento imediato via link** – O cancelamento acionado pelo link do e-mail é executado imediatamente após a validação do token, sem etapa de confirmação adicional. O processo é removido no mesmo request.|
-|RN07|**Escopo do cancelamento por link** – O link "Parar de receber este acompanhamento" presente nos e-mails remove apenas o processo referenciado naquele link. O link "Gerenciar meus acompanhamentos" dá acesso à lista completa.|
+|RN07|**Escopo do cancelamento por link** – O link "Parar de acompanhar este processo" presente nos e-mails remove apenas o processo referenciado naquele link, e não concede nenhum outro acesso (RN16). O link "Solicitar link de gerenciamento" leva ao formulário que dá acesso à lista completa.|
 |RN08|**Resposta neutra no reenvio de link** – Ao solicitar reenvio do link de gerenciamento, o sistema sempre retorna a mensagem: "Se este endereço possui acompanhamentos ativos, você receberá o link de acesso em breve.", independentemente de o e-mail existir ou não na base de dados.|
-|RN09|**Token de gerenciamento de uso múltiplo** – O token enviado no link de gerenciamento pode ser utilizado múltiplas vezes enquanto estiver dentro do prazo de validade, ao contrário do token de confirmação de inscrição.|
+|RN09|**Uso múltiplo dentro da validade** – O **token de sessão** pode ser utilizado múltiplas vezes, em qualquer dos fluxos, enquanto estiver dentro das 48 horas de validade (RN02). O reenvio do link de gerenciamento não invalida os tokens já emitidos e ainda válidos.|
 |RN10|**Sem limite de processos por e-mail** – Não há limite máximo de processos que podem ser associados a um único e-mail.|
 |RN11|**Confirmação antes de remover na tela de gerenciamento** – Na página de gerenciamento, ao clicar em "Parar de acompanhar", o sistema exibe uma confirmação inline no card do processo com os botões "Confirmar" e "Cancelar". A remoção só é executada após o usuário clicar em "Confirmar".|
 |RN12|**Cadastro implícito de usuário (sem tela de cadastro)** – Não existe formulário de nome/senha para o usuário. Internamente, porém, o backend deve localizar ou criar um registro de usuário Push a partir do e-mail informado (reaproveitando a estrutura de dados existente do legado), preenchendo os campos obrigatórios do legado (nome e senha) com valores técnicos não expostos ao usuário. Essa criação/localização de registro é transparente e não pode alterar nome, senha ou o estado "Habilitado" de um cadastro que já exista para aquele e-mail (ver [[#reaproveitamento_de_estruturas_do_legado|Reaproveitamento de Estruturas do Legado]]).|
+|RN13|**Lista resumida na tela de confirmação** – Na tela de confirmação de inscrição (Tela 02), a lista "Seus processos acompanhados" exibe apenas os **3 processos mais recentes** vinculados ao e-mail, ordenados pela data de inclusão do acompanhamento (mais recente primeiro), incluindo o processo recém-confirmado. Não há paginação nesta tela — para consultar a lista completa, o usuário deve acessar "Gerenciar meus acompanhamentos" (Tela 03).|
+|RN14|**Paginação na tela de gerenciamento** – Como não há limite máximo de processos por e-mail (RN10), a lista de acompanhamentos da Tela 03 é paginada em **12 processos por página**, exibindo o componente de paginação somente quando esse total é ultrapassado. O tamanho da página é **fixo** — não há seletor de itens por página. Reaproveita o componente ''Pagination'' já utilizado em ''/processos'' (mesmo padrão visual e de navegação).|
+|RN15|**Conformidade de acessibilidade** – Todas as telas do RF-008 seguem a diretriz **e-MAG 3.1** adotada pelo Portal. São verificáveis, em cada tela: nome acessível dos controles e dos campos, contraste mínimo do texto e dos elementos de interface, e aumento de fonte/zoom até 200% sem perda de conteúdo ou de função.|
+|RN16|**Token de descadastro** – Gerado **na confirmação da inscrição**, na mesma requisição que cria a linha de acompanhamento, e vinculado a ela (`PROACPR_ID`). É **persistente** (não expira), de **escopo único** — remove exclusivamente o acompanhamento a que se refere — e **não concede acesso ao painel de gerenciamento**. É o único token presente no e-mail de notificação de movimentação. Garante o cancelamento em um clique, a qualquer tempo, sem expor a lista de processos acompanhados pelo endereço: um link de descadastro vazado custa uma inscrição, enquanto um link de gerenciamento vazado revelaria todos os interesses processuais daquela pessoa. **Materialização decidida:** coluna nova em `PRO_ACOMPANHAPROCESSO`, `DEFAULT NULL` para não impactar o schema existente, com hash MD5 derivado de GUID gerado no backend, exposta pela view `VPRO_ACOMPANHAMENTOPROCESSOS` para que a rotina de disparo apenas **leia** o valor ao montar o link, nunca o gere. Como a linha só é criada após a confirmação (RN03), a coluna preenchida passa a ser a marca de vínculo confirmado.|
+|RN17|**Dois endpoints de cancelamento, um por origem** – A remoção de um acompanhamento é acionada por duas origens, cada uma com seu endpoint: o botão "Parar de acompanhar" da **tela de gerenciamento**, autenticado por **token de sessão**; e o link do **e-mail de movimentação**, autenticado pelo **hash de descadastro** somado ao ID do acompanhamento (RN16). Ambos executam a **mesma rotina de remoção** no banco — muda apenas a autenticação. A separação em dois endpoints garante por construção que o hash de descadastro não alcance outros acompanhamentos do mesmo endereço: o endpoint que o aceita resolve um único vínculo, identificado pelo próprio hash, e não recebe ID de processo nem de usuário.|
 ----
@@ Linha 260: / Linha 279: @@
 ^ Tabela ^ Papel no legado ^ Reaproveitamento no novo modelo ^
 |`TCE_GO.PSH_USUARIOS`|Cadastro do usuário do serviço Push (nome, e-mail, senha, dados de contato, flag `Habilitado`)|**Reaproveitada como cadastro implícito.** Ao inscrever um e-mail em um processo (RN03), o backend deve verificar se já existe uma linha com aquele e-mail; se não existir, criar uma nova (cadastro invisível ao usuário); se já existir, **reutilizar o registro sem sobrescrever dados preexistentes** (RN12).|
-|`PRO_ACOMPANHAPROCESSO`|Tabela de associação entre `PSH_USUARIOS` (`PSHUSUA_ID`) e `PRO_AUTUACAO` (`PROAUTU_ID`) — representa "quais processos este usuário acompanha"|**Reaproveitada integralmente.** É exatamente a estrutura que already sustenta a lista exibida nas telas de Confirmação e Gerenciamento (RF-008). Não requer alteração de schema.|
+|`PRO_ACOMPANHAPROCESSO`|Tabela de associação entre `PSH_USUARIOS` (`PSHUSUA_ID`) e `PRO_AUTUACAO` (`PROAUTU_ID`) — representa "quais processos este usuário acompanha"; a coluna `PROANDA_ID` funciona como fila de notificação pendente|**Reaproveitada, com uma coluna nova.** É exatamente a estrutura que sustenta a lista exibida nas telas de Confirmação e Gerenciamento (RF-008). **Requer uma coluna adicional** para o hash de descadastro (RN16) — MD5 derivado de GUID, `DEFAULT NULL` —, que também precisa ser exposta pela view `VPRO_ACOMPANHAMENTOPROCESSOS` para uso da rotina de disparo. As inscrições anteriores ao corte recebem o hash por //update// incremental, para não perderem o descadastro em um clique. Nenhuma outra alteração de schema é prevista.|
 |`PRO_AUTUACAO`|Tabela de processos autuados|**Reaproveitada apenas para leitura** (validação de existência do processo — RN05 — e composição dos dados exibidos: número, interessado, assunto, ano).|
@@ Linha 285: / Linha 304: @@
 ^ Endpoint legado ^ Reaproveitamento no RF-008 ^
 |`POST api/push/login`|**Descontinuado.** Dependia de senha; o novo modelo não tem login.|
+|Portal legado `/Push` (formulário de inscrição)|**Desligado no corte.** Encerra a criação de acompanhamentos por fora do fluxo de confirmação do RF-008, garantindo que toda linha nova de `PRO_ACOMPANHAPROCESSO` nasça com hash de descadastro (RN16).|
 |`POST api/push/email` (cadastro)|**Substituído** pelo cadastro implícito descrito acima — o novo `POST /api/push/inscrever` (PRD §7) deve criar o registro em `PSH_USUARIOS` internamente, sem expor os campos `Nome`/`Senha` ao cliente.|
-|`GET api/push/verifica/{numeroProcesso}`|**Reaproveitável como base, com correção de parâmetro:** no RF-008 o parâmetro deve ser `idAutuacao`, não o número público — a página do processo (`/processos/{id}`) já tem o ID de autuação em contexto, o usuário não precisa informá-lo.|
+|`GET api/push/verifica/{numeroProcesso}`|**Reaproveitável como base, com correção de parâmetro:** no RF-008 o parâmetro deve ser `idAutuacao`, não o número público — a página do processo (`/processo/{id}`) já tem o ID de autuação em contexto, o usuário não precisa informá-lo.|
 |`PUT api/push/adiciona/processos`|**Reaproveitável como base, com a mesma correção:** a lista recebida deve conter IDs de autuação, não números de processo, antes de repassar para `WEB_PACKAGE.PWEB_ACOMPANHAPROCESSO` (que exigirá a conversão pontual citada acima).|
-|`DELETE api/push/remove/{numeroProcesso}`|**Reaproveitável como base:** apesar do nome do parâmetro na rota legada, o valor é repassado como ID interno para `RemoveAcompanhamentoDeProcesso`. No RF-008 o parâmetro deve se chamar explicitamente `idAutuacao`, para não sugerir que aceita o número público.|
+|`DELETE api/push/remove/{numeroProcesso}`|**Reaproveitável como base** para `DELETE /api/push/cancelar`, usado pela tela de gerenciamento: apesar do nome do parâmetro na rota legada, o valor é repassado como ID interno para `RemoveAcompanhamentoDeProcesso`. No RF-008 o parâmetro deve se chamar explicitamente `idAutuacao`, para não sugerir que aceita o número público.|
+|— (não existe no legado)|**Desenvolvimento novo:** `DELETE /api/push/cancelar/email`, acionado pelo link do e-mail de movimentação. Recebe o hash de descadastro e o ID do acompanhamento (RN16, RN17), e executa a **mesma rotina de remoção** do endpoint acima — muda apenas a autenticação.|
 |`GET api/push/processos`|**Reaproveitável** como base para `GET /api/push/gerenciar`.|
 |Autenticação `BasicAuthorizationPush` (header `Authorization: Basic {id}@{tokenCriptografado}`, sem expiração — risco S4 do relatório técnico)|**Não reaproveitada.** O RF-008 exige token de e-mail com expiração (RN02) e sem exigência de login prévio; é necessário um mecanismo novo de emissão/validação de token (ex.: JWT com `exp`).|
@@ Linha 295: / Linha 316: @@
 ^ Componente ^ Papel no legado ^ Reaproveitamento no RF-008 ^
-|`IServicoDeEmail` / `ServicoDeEmail` (`TCE.Compartilhado.Servico.Servicos.Contato`)|Camada compartilhada de envio, usada por `ServicoDeUsuarioPush`, `ServicoDeFaleConosco`, `ServicoDeOuvidoriaEletronica` e outros serviços do Compartilhado|**Reaproveitada integralmente.** O RF-008 deve montar um `DtoEmail` (destinatário, assunto, corpo HTML) e um `DtoConfiguracaoEmail { HostName = "smtp.tce.go.gov.br" }` e chamar `IServicoDeEmail.EnviaEmail(...)` — exatamente como já faz `ServicoDeUsuarioPush.EnviaEmail` para os e-mails de cadastro/alteração/lembrete de senha do Push legado. Não é necessário criar um novo mecanismo de disparo.|
+|`IServicoDeEmail` / `ServicoDeEmail` (`TCE.Compartilhado.Servico.Servicos.Contato`)|Camada compartilhada de envio, usada por `ServicoDeUsuarioPush`, `ServicoDeFaleConosco`, `ServicoDeOuvidoriaEletronica` e outros serviços do Compartilhado|**Reaproveitada integralmente.** O RF-008 deve montar um `DtoEmail` (remetente `push@tce.go.gov.br`, destinatário, assunto, corpo HTML) e um `DtoConfiguracaoEmail { HostName = "smtp.tce.go.gov.br" }` e chamar `IServicoDeEmail.EnviaEmail(...)` — exatamente como já faz `ServicoDeUsuarioPush.EnviaEmail` para os e-mails de cadastro/alteração/lembrete de senha do Push legado. Não é necessário criar um novo mecanismo de disparo.|
 |`smtp.tce.go.gov.br`|Host SMTP institucional, configurado via `SmtpClient` do .NET (`ServicoDeEmail.EnviaEmail`)|**Confirmado como servidor a ser utilizado.** Os três e-mails do RF-008 (seção "E-mails Enviados") devem ser despachados por este host, seguindo o mesmo padrão do restante do portal.|
+|`push@tce.go.gov.br`|—|**Endereço de remetente institucional definido para o RF-008.** Utilizado no campo `From` do `DtoEmail` para os três e-mails (Confirmação, Notificação, Reenvio).|
+==== Mecanismo de Disparo da Notificação (legado) ====
+O e-mail de movimentação do Push legado **não é disparado pela aplicação**. Ele nasce inteiramente dentro do banco Oracle, em duas etapas:
+  - **Enfileiramento (imediato).** Todo registro de andamento gravado em `PRO_ANDAMENTO` marca, via //trigger//, as inscrições daquele processo como "pendentes de notificação".
+  - **Envio (a cada 3 minutos).** Uma rotina agendada varre as inscrições pendentes, monta o e-mail e o despacha por `smtp.tce.go.gov.br`, com remetente `push@tce.go.gov.br`.
+O mecanismo foi verificado de ponta a ponta em 06/09/2026 e **está operacional**. O detalhamento técnico — objetos de banco, defeitos catalogados (D1–D10) e procedimento de teste — está no **PRD, seção 12**.
+=== Onde o template é implementado ===
+**O template do E-mail 02 é implementado na própria rotina de disparo, em PL/SQL.** O RF-008 especifica conteúdo, layout e links; a construção da mensagem permanece onde o envio acontece. Decorre daí:
+  * Os campos acrescentados ao E-mail 02 — **Órgão ou Setor Atual**, **Data Autuação** e **Ano Referência** — já estão disponíveis nas views consultadas pela rotina. **Não é necessária nova fonte de dados.**
+  * O **token de descadastro** (RN16) precisa estar acessível à rotina no momento da montagem do link. A rotina apenas **lê** o token; a geração ocorre na inscrição, no serviço do RF-008.
+  * Os links passam a usar HTTPS e deixam de transportar o e-mail do destinatário em //query string//, corrigindo a falha de segurança do modelo legado.
+=== Quais movimentações geram notificação ===
+  * **Enfileiramento sem filtro.** Toda gravação de andamento entra na fila, sem distinção de situação, setor, tipo de documento ou sigilo — inclusive os andamentos gerados em cascata para processos apensados.
+  * **Filtragem apenas no envio.** A notificação deixa de ser enviada quando o usuário está desabilitado, quando a inscrição não tem usuário correspondente, ou quando a autuação está marcada com bloqueio total de documento.
+  * **Eventos de pauta e julgamento** também alimentam a fila, por caminho próprio e independente do fluxo de tramitação.
+=== Sigilo — regra vigente (decidida) ===
+**Processos sigilosos não geram notificação de movimentação.** A definição de sigilo para este serviço é a regra já aplicada na view de acompanhamento: a notificação é suprimida quando a autuação está marcada com **bloqueio total de documento**.
+Os demais processos são notificados normalmente — inclusive os marcados como **reservados** e os de bloqueio parcial. O fundamento é que os dados levados pelo e-mail (setor atual, situação, assunto, datas de autuação e referência) **já estão disponíveis publicamente** na consulta de processos do Portal: a notificação não amplia a exposição existente, apenas avisa o interessado de que ela mudou.
+**O comportamento atual não será alterado pelo RF-008.** //Decisão de Requisitos, 06/09/2026.//
+=== Decisões de negócio pendentes ===
+Comportamentos do legado que **não estão documentados como decisão** e precisam ser confirmados por Requisitos antes da implementação do RF-008:
+^ Tema ^ Comportamento atual do legado ^ Decisão necessária ^
+|**Granularidade**|Se o processo se movimenta duas vezes dentro da janela de 3 minutos, **apenas a última movimentação é notificada** — a anterior é descartada silenciosamente. É efeito colateral da implementação, não regra deliberada.|Definir se cada movimentação gera um e-mail, ou se movimentações próximas são consolidadas em uma única notificação.|
+|**Escopo do "desabilitado"**|O indicador de habilitação vive no **usuário**, não na inscrição. Desabilitar um e-mail interrompe as notificações de **todos** os processos daquela pessoa de uma só vez.|O novo modelo exige controle **por inscrição** (RN03 e Fluxo 04) — não há como cancelar um processo isoladamente reaproveitando o indicador atual.|
+|**Confiabilidade do envio**|Falhas de envio são descartadas sem registro, e não existe histórico de e-mails enviados. Uma notificação perdida é indetectável e irrecuperável.|Definir se o RF-008 exige registro de envio e reenvio automático em caso de falha.|
+|**Tratamento especial de uma conta**|Uma regra fixa no banco, acionada a cada autuação nova, dá tratamento diferenciado às inscrições de **uma conta identificada por ID literal**, atualizando o campo de andamento delas. Não cria acompanhamentos — a criação é exclusiva do fluxo de confirmação.|Confirmar a quem a regra pertence e se deve ser preservada. O RF-008 não depende dela, mas quem alterar o mecanismo de disparo precisa saber que existe.|
 ==== Riscos e Pontos de Atenção para o Backend ====
@@ Linha 304: / Linha 367: @@
   * **ID de Autuação como identificador único do processo:** todo o contrato do RF-008 (requisições da API, tokens de confirmação/gerenciamento/cancelamento, parâmetros de rota) deve referenciar o processo pelo ID de autuação. O número público do processo é apenas informação de exibição nas telas e nos e-mails. A única exceção no legado é `WEB_PACKAGE.PWEB_ACOMPANHAPROCESSO`, que exige o número público — tratar como conversão isolada no ponto de integração, sem propagar o número para o restante do fluxo (ver tabela de rotinas acima).
   * **Nenhuma estrutura de token existente é reaproveitável tal como está:** o legado não possui tabela/mecanismo de token com expiração para os links de confirmação/gerenciamento/cancelamento; isso é **desenvolvimento novo**, não reaproveitamento.
+----
+===== Histórico de Revisões =====
+^ Data ^ Alteração ^ Motivo ^
+|2026-09-06|RN16 — hash gerado **na confirmação** (não na inscrição), coluna `DEFAULT NULL`; registrados o //update// incremental para a base existente e o desligamento do portal legado `/Push` no corte|Decisões do time. A linha só nasce após a confirmação, o que torna a coluna preenchida a marca de vínculo confirmado; sem a migração, a base antiga perderia o descadastro em um clique que o e-mail legado já oferece|
+|2026-09-06|**Decisões técnicas registradas:** RN16 fixa a materialização do token (coluna nova em `PRO_ACOMPANHAPROCESSO`, MD5 de GUID, exposta na view); RN17 passou de endpoint único para **dois endpoints**, um por origem; parâmetros do link de cancelamento passaram de `token`+`processo` para `hash`+`acompanhamento`|Decisões do time em 06/09/2026. A separação em dois endpoints substitui, por construção, a verificação de escopo que o endpoint único exigiria; o ID do acompanhamento (`PROACPR_ID`) identifica o vínculo diretamente, em vez do ID do processo|
+|2026-09-06|**RN17 acrescentada** — cancelamento aceita os dois tipos de token, em endpoint único, com escopo determinado pelo tipo; Fluxo 03 passo 06.3 passou a citá-la|A tela de gerenciamento precisa cancelar acompanhamentos com o token de sessão, o que a RN16 não cobria. A regra também explicita que o processo informado na requisição é ignorado quando o token é de descadastro — sem isso, um link vazado alcançaria outros acompanhamentos do mesmo endereço|
+|2026-09-06|**RN02 desdobrada em dois tipos de token** (sessão, 48h; descadastro, persistente) e **RN16 acrescentada**; E-mail 02, RN07, RN09 e Fluxo 04 alinhados|O e-mail de movimentação não responde a uma ação do usuário — chega muito depois da inscrição, quando um token de 48h já expirou, e é montado por rotina que não emite tokens. Além disso, o link de gerenciamento expõe toda a lista de processos do endereço, exigindo escopo de segurança distinto do link de cancelamento|
+|2026-09-06|E-mail 02 — corpo passou a incluir **Órgão ou Setor Atual**, **Data Autuação** e **Ano Referência**; link "Gerenciar meus acompanhamentos" renomeado para **"Solicitar link de gerenciamento"** e sem token|Decisão de Requisitos sobre o conteúdo da notificação; o rótulo anterior prometia acesso direto ao painel, que deixou de ocorrer no clique|
+|2026-09-06|Registrado que **o template do E-mail 02 é implementado em PL/SQL**, onde ocorre o disparo; `PRO_ACOMPANHAPROCESSO` pode requerer coluna adicional|Decisão de Requisitos; a afirmação anterior de que a tabela não requeria alteração de schema deixou de ser incondicional com a RN16|
+|2026-09-06|**Acrescentada a subseção "Mecanismo de Disparo da Notificação (legado)"**, com as movimentações que geram notificação e cinco decisões de negócio pendentes|O disparo do e-mail de movimentação não estava especificado; a engenharia reversa do banco (PRD §12) revelou comportamentos — sigilo, granularidade, escopo do "desabilitado" — que são regra de negócio e não estavam documentados como decisão|
+|2026-08-31|Tela 01 e Fluxo 01 passo 05.1 — a mensagem "Informe um e-mail válido." passou a cobrir também o campo não preenchido, exibida abaixo do rótulo|Decisão de Requisitos; o comportamento do campo obrigatório não estava especificado (PD-02)|
+|2026-08-31|Fluxo 01 — passos 10 e 10.1 renumerados para 09 e 09.1|Lacuna de numeração corrigida a pedido de Requisitos (PD-13)|
+|2026-08-31|RN02 reescrita — token **único** do serviço, validade de 48h, reaproveitável nos fluxos de confirmação, gerenciamento e cancelamento|Decisão de Requisitos: não se emite token novo a cada etapa (PD-04, PD-09)|
+|2026-08-31|RN09 reescrita — uso múltiplo em qualquer fluxo dentro das 48h|Alinhamento à RN02 (PD-04, PD-09)|
+|2026-08-31|Telas 02 e 04 — botões de acesso ao painel passaram a declarar o reaproveitamento do token recebido|O conflito apontado na análise de estratégia de tokens deixou de existir com a decisão da RN02 (PD-04)|
+|2026-08-31|RN14 — registrado que o tamanho da página é fixo, sem seletor de itens|Decisão de Requisitos (PD-15)|
+|2026-08-31|**RN15 acrescentada** — conformidade de acessibilidade e-MAG 3.1|O RF não declarava requisito de acessibilidade, embora o escopo de teste o exija (PD-12)|
+|2026-08-31|E-mail 02 — o disparo passou a ser atribuído a outro serviço interno do TCE-GO|Decisão de Requisitos: a regra que decide quando enviar está fora do escopo do RF-008 (PD-16)|
+|2026-08-31|Rota do detalhe do processo padronizada como ''/processo/{id}''|Decisão de Requisitos: é a rota já desenvolvida na funcionalidade anterior (PD-11)|
+|2026-08-31|Tela 01 — o botão "Quero acompanhar" passou a declarar que o formulário abre na própria página, sem diálogo sobreposto|Decisão de Requisitos; o CA02 do PRD deixava a apresentação entre modal e expansão inline (PD-18)|
 ---
 //Gerado com: documentar-funcionalidade-v1.md// \\
 //Revisado por: Paulo Ricardo Amorim Silva - pramorim@tce.go.gov.br//