feat(auth): adiciona confirmação de troca de e-mail

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae

[Jovinull]

Card

• PAV-36

Objetivo e escopo

• Exigir confirmação antes de efetivar a troca de e-mail de um usuário.
• Manter o e-mail atual até a confirmação do token recebido no novo endereço.

O que foi feito

• Adiciona a tabela e migration de pedidos de troca de e-mail.
• Cria o serviço que invalida pedidos anteriores, valida duplicidade de e-mail, gera o pedido e confirma a troca por token.
• Adiciona POST /users/email-change para solicitar a troca com sessão autenticada.
• Adiciona POST /auth/email-change/confirm para confirmar o token sem exigir sessão.
• Inclui template de e-mail, formulário no perfil e a tela /confirmar-email.
• Torna o campo de e-mail do perfil somente leitura, direcionando a alteração para o fluxo de confirmação.

Módulos afetados

• backend/drizzle/0014_panoramic_leopardon.sql
• backend/src/modules/users/emailChange.service.ts
• backend/src/routes/auth.routes.ts
• backend/src/routes/users.routes.ts
• backend/src/modules/email/templates/emailChangeConfirmation.tsx
• frontend/src/domains/new_dashboard/components/profile/EmailChangeForm.tsx
• frontend/src/domains/auth/presentation/pages/ConfirmEmailChangePage.tsx

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/integration/routes/auth.routes.test.ts tests/integration/routes/user.routes.test.ts tests/unit/modules/email/email.service.test.ts tests/unit/modules/users/emailChange.service.test.ts - 4 arquivos e 67 testes aprovados.
• npm exec --workspace=frontend vitest run tests/unit/new_dashboard/emailChange.test.tsx - 1 arquivo e 3 testes aprovados.
• Os testes cobrem solicitação autenticada, e-mail inválido, ausência de sessão, confirmação sem sessão, token inválido ou expirado, e-mail já utilizado, tela de confirmação e link sem token.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.
• Smoke manual em navegador: acessei /confirmar-email sem token, validei a mensagem de link inválido e a navegação para o login.

Riscos e observações

• A migration 0014_panoramic_leopardon.sql precisa ser aplicada antes de disponibilizar o fluxo.
• O envio efetivo pelo Resend não foi executado nesta validação, pois não há credencial configurada. O contrato de enfileiramento e o conteúdo da URL de confirmação foram validados por teste automatizado.
• A confirmação com token válido contra uma instância real de banco e serviço de e-mail permanece pendente de ambiente configurado.

[hltav]

PR fora do padrão de contribuição do projeto.

Antes da revisão técnica, por favor ajuste a descrição conforme o template/documentação do repositório, incluindo card relacionado, objetivo, resumo das alterações, arquivos/módulos afetados, validações executadas e observações relevantes.

Com 24 arquivos alterados e mais de 2 mil linhas adicionadas, precisamos desse contexto para realizar uma revisão segura e rastreável. Após a adequação da PR, seguimos com a revisão do código.

[hltav]

A implementação está bem encaminhada e cobre boa parte do fluxo da PAV-36, mas como esse PR altera um fluxo sensível de identidade/autenticação, ainda precisamos fechar alguns pontos antes da aprovação.

O principal problema está na relação entre a criação da solicitação de troca e o envio do e-mail de confirmação. Hoje a solicitação é persistida e considerada concluída mesmo quando o módulo centralizado de e-mail não consegue enfileirar a mensagem, porque esse módulo foi originalmente desenhado para tratar falha de envio como não bloqueante. Nesse fluxo específico, porém, o e-mail é parte obrigatória da operação: sem ele o usuário não consegue concluir a troca.

Revise esse comportamento para que a API não sinalize sucesso quando a confirmação não puder ser efetivamente disponibilizada ao usuário. Essa revisão também deve considerar o estado da solicitação já persistida e de eventuais solicitações anteriores invalidadas.

Além disso, gostaria que fossem revisados os cenários de concorrência do fluxo. Em especial, precisamos garantir consistência quando houver solicitações simultâneas para o mesmo novo e-mail, múltiplas solicitações para o mesmo usuário e concorrência entre confirmação de token e criação de uma nova solicitação. O banco e a camada de serviço precisam preservar as invariantes do fluxo também nesses casos.

A cobertura atual contempla bem o happy path, token inválido/expirado e e-mail já utilizado, mas precisa incluir os cenários de falha de infraestrutura e concorrência relevantes para essa feature. Como esse fluxo altera users, credentials e a nova tabela de solicitações dentro do processo de confirmação, gostaria também de cobertura explícita garantindo atomicidade: ou a troca é concluída integralmente, ou o estado anterior permanece consistente.

Por fim, valide o comportamento de sessão após a confirmação da troca de e-mail. Como a identidade persistida é alterada em users e credentials, precisamos garantir que sessões/autenticações existentes continuem com o comportamento definido pelo produto e que não exista inconsistência entre o e-mail exibido, o e-mail usado para login e os dados da sessão após a confirmação.

Com esses pontos tratados e cobertos por testes, o PR fica em condição de aprovação.

[Jovinull]

Atualiza??o aplicada em resposta ao review t?cnico:

• O envio do e-mail de confirma??o agora pode ser marcado como obrigat?rio.
• No fluxo de troca de e-mail, falhas ao enfileirar a confirma??o s?o propagadas para a API.
• A cria??o do pedido e o envio obrigat?rio s?o executados dentro da transa??o; se o envio falhar, a solicita??o n?o ? conclu?da.
• Adicionados testes para falha de infraestrutura no enqueue e para o comportamento de envio obrigat?rio.

Valida??o:

• Suite completa do backend: 61 arquivos e 584 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

Commit: 56d36ae