Conversation
…bilita JSX no backend Co-Authored-By: Claude Opus 4.8 <[email protected]>
…endUrl Co-Authored-By: Claude Opus 4.8 <[email protected]>
…getMailProvider Co-Authored-By: Claude Opus 4.8 <[email protected]>
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Co-Authored-By: Claude Opus 4.8 <[email protected]>
…a e enqueue com retry Co-Authored-By: Claude Opus 4.8 <[email protected]>
…acha via provider Co-Authored-By: Claude Opus 4.8 <[email protected]>
…e sendWelcome Co-Authored-By: Claude Opus 4.8 <[email protected]>
…utdown Co-Authored-By: Claude Opus 4.8 <[email protected]>
…luxo Co-Authored-By: Claude Opus 4.8 <[email protected]>
…es/providers Co-Authored-By: Claude Opus 4.8 <[email protected]>
Co-Authored-By: Claude Opus 4.8 <[email protected]>
# Correção do Campo Telefone ## Problema Atualmente o campo **Telefone** aceita valores inválidos, por exemplo: ``` +55 1891898989989999 ``` Esse valor **não deveria ser aceito**. A implementação atual não respeita o padrão brasileiro de telefonia nem limita corretamente a quantidade de dígitos. --- # Objetivo Corrigir completamente o campo Telefone para seguir o padrão brasileiro. O campo **continua sendo opcional**, porém, quando preenchido, deve aceitar **apenas números válidos**. --- # Formatos aceitos ## Celular Formato: ``` (XX) 9XXXX-XXXX ``` Quantidade de dígitos: - DDD: 2 - Número: 9 dígitos Total: ``` 11 dígitos ``` Exemplos válidos: ``` (11) 91234-5678 11912345678 +55 (11) 91234-5678 +55 11 91234-5678 ``` --- ## Telefone Fixo Formato: ``` (XX) XXXX-XXXX ``` Quantidade de dígitos: ``` 10 dígitos ``` Exemplos válidos: ``` (11) 3456-7890 1134567890 +55 (11) 3456-7890 ``` --- # Formatos inválidos Os seguintes exemplos devem ser rejeitados: ``` +55 1891898989989999 111 999999999999999999999 abcdefgh +551234567890123456 +44 11111111111 (11) 999999999999 ``` Também não aceitar: - quantidade maior de dígitos - quantidade menor de dígitos - DDD inválido - DDI diferente de +55 - múltiplos sinais "+" - caracteres inválidos --- # Máscara Aplicar máscara automaticamente enquanto o usuário digita. Exemplos Entrada: ``` 11912345678 ``` Saída: ``` (11) 91234-5678 ``` Entrada: ``` 1134567890 ``` Saída: ``` (11) 3456-7890 ``` Entrada: ``` 5511912345678 ``` Saída: ``` +55 (11) 91234-5678 ``` --- # Limite de caracteres Após remover toda a formatação: Celular: ``` 11 dígitos ``` Fixo: ``` 10 dígitos ``` Internacional: ``` +55 ``` seguido de ``` 10 ou 11 dígitos ``` Não permitir continuar digitando após atingir o limite. Também configurar corretamente o `maxLength` considerando a máscara. --- # Fluxo de validação A validação **não deve depender apenas da Regex**. Executar as seguintes etapas: 1. Remover espaços. 2. Remover parênteses. 3. Remover hífen. 4. Remover caracteres da máscara. 5. Validar DDI. 6. Validar DDD. 7. Validar quantidade exata de dígitos. 8. Aplicar Regex. 9. Persistir o valor apenas se todas as validações forem aprovadas. --- # Implementação Verificar se existe: - máscara de input - formatter - parser - onChange - transform - schema (Zod, Yup, Joi, etc.) A implementação deve impedir que o usuário digite além do limite permitido. --- # Critérios de aceite - Campo continua opcional. - Máscara aplicada automaticamente. - Limite máximo de caracteres respeitado. - Não permite números maiores que o padrão. - Não permite números menores que o padrão. - Aceita apenas telefones brasileiros válidos. - Aceita celular e telefone fixo. - Aceita DDI +55. - Rejeita qualquer outro DDI. - Exibe mensagem de erro apenas quando um telefone informado for inválido. - Não gera regressões em outros formulários.
…testes (#213) # Documentação de desenvolvimento local e padrão de testes automatizados ## Objetivo Criar uma documentação para facilitar o onboarding de novos contribuidores no projeto, centralizando informações sobre execução local da aplicação e o padrão utilizado para criação de testes automatizados. ## O que foi alterado Foi criada uma documentação contendo: ### Desenvolvimento local - Pré-requisitos necessários para executar o projeto. - Configuração inicial do ambiente. - Instalação das dependências. - Configuração das variáveis de ambiente. - Comandos utilizados para executar os serviços localmente. - Orientações para execução e validação da aplicação. ### Padrão de testes automatizados Foi documentado o padrão utilizado no projeto para organização de testes utilizando: - TP (Test Plan) - TC (Test Case) A documentação explica: - Diferença entre TP e TC. - Como estruturar cenários de teste. - Como criar novos casos de teste. - Boas práticas para testes unitários. - Quando utilizar `it.each`. - A importância de validar comportamento e regras do sistema, evitando testes acoplados a detalhes de implementação. ## Exemplo utilizado Foi utilizado como referência o fluxo de testes do Go Scraper:
Benevanio
requested review from
hltav,
lima300 and
nayarakarinesilva
as code owners
August 2, 2026 16:00
Benevanio
requested review from
GiovanniDonati and
jeremiassnts
and removed request for
Copilot
August 2, 2026 16:00
…AV-76)
Estende o gatilho de boas-vindas para o login social (Google, GitHub,
LinkedIn), apenas quando a conta é criada pela primeira vez.
- findOrCreateUser passa a retornar { user, isNewUser }: true só quando
um usuário é realmente criado; false em relogin (achado por provider)
ou ao vincular provider a usuário existente (achado por e-mail).
- auth.service.handleCallback dispara emailService.sendWelcome após a
transação, em try/catch que só loga (login nunca quebra) — mesmo
padrão resiliente do CredentialsService.register.
- Atualiza spec/design do módulo (ACs, edge cases, EMAIL-12/13).
- Testes: novos casos de novo usuário, relogin/vínculo e resiliência.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
…ndas Atualiza subject, preview e corpo do e-mail de boas-vindas de "Painel Vagas" para "Candidate", refletindo o novo nome do projeto. Co-Authored-By: Claude Opus 4.8 <[email protected]>
nayarakarinesilva
approved these changes
Aug 2, 2026
Adiciona @emnapi/core e @emnapi/runtime que faltavam no lock, fazendo `npm ci` passar no CI (node 22 / npm 10). O lock havia sido atualizado com npm 11, que resolve deps opcionais napi/wasm de forma diferente. Co-Authored-By: Claude Opus 4.8 <[email protected]>
## Descrição
Introduz o módulo de e-mail transacional centralizado do backend: uma
API interna única (`EmailService`) que enfileira envios de forma
assíncrona e resiliente via BullMQ/Valkey, com worker in-process que
renderiza templates (react-email) e despacha por um provider trocável
(Resend em produção, Noop quando não há credencial). Entrega o e-mail de
boas-vindas como primeiro consumidor real, disparado tanto no registro
por e-mail/senha quanto no primeiro login social (Google, GitHub e
LinkedIn) — apenas quando a conta é criada pela primeira vez
(relogin/vínculo de provider não reenviam). O envio nunca derruba o
fluxo de origem: falhas são apenas logadas. Inclui envs, documentação e
artefatos spec-driven do módulo, e adota o novo nome do projeto
("Candidate") na mensagem de boas-vindas.
## Linear link
https://linear.app/tatame/issue/PAV-76/modulo-de-e-mail-sistema-centralizado-de-envio
## Como foi testado
Testes unitários passando — Backend: 550/550 | Frontend: 320/320
hltav
approved these changes
Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alterações realizadas
Correção relacionada ao cadastro de telefone
Objetivo da PR
Esta PR tem como objetivo corrigir problemas encontrados no cadastro de telefone e melhorar a experiência dos desenvolvedores no projeto, fornecendo documentação clara para configuração do ambiente e seguindo um padrão definido para criação de testes unitários.
Checklist