Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Correções e Documentações do Projeto - #214

Merged
hltav merged 23 commits into
masterfrom
develop
Aug 3, 2026
Merged

Correções e Documentações do Projeto#214
hltav merged 23 commits into
masterfrom
develop

Conversation

@Benevanio

@BenevanioBenevanio commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Alterações realizadas

  • Criada documentação com o processo de configuração do ambiente local.
  • Adicionado o padrão de desenvolvimento e organização dos testes.
  • Documentado o conceito e utilização de TC (Test Case) e TP (Test Plan), visando padronizar a criação e manutenção dos testes unitários.

Correção relacionada ao cadastro de telefone

  • Resolvido o problema identificado no campo de telefone durante o cadastro de usuários.
  • Ajustada a regra para tratar corretamente números no formato brasileiro.

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

  • Correção do campo de telefone BR
  • Documentação de onboarding adicionada
  • Documentação de ambiente local adicionada
  • Padronização de testes unitários documentada
  • Ajustes relacionados ao PAV-111 concluídos

Jeremias Santosand others added 19 commits July 27, 2026 18:45
…bilita JSX no backend
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…endUrl
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…getMailProvider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a e enqueue com retry
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…acha via provider
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e sendWelcome
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utdown
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…luxo
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es/providers
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# 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:
…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 <noreply@anthropic.com>
…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 <noreply@anthropic.com>
Jeremias Santosand others added 2 commits August 2, 2026 21:35
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 <noreply@anthropic.com>
## 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
CopilotAI review requested due to automatic review settings August 3, 2026 09:19
CopilotAI reviewed Aug 3, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

@hltav
hltav merged commit 587b491 into masterAug 3, 2026
3 checks passed
@github-project-automationgithub-project-automationBot moved this from Backlog to Done in JobAtlas – KanbanAug 3, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Benevanio@hltav@nayarakarinesilva