Primeiros passos com o Devin

Crie um novo endpoint /users/stats que retorne um objeto JSON com a contagem de usuários e a média de idade no momento do cadastro.

Use nossa tabela existente users no PostgreSQL.

Você pode usar o endpoint /orders/stats em statsController.js como referência para como estruturamos as respostas.

Garanta que o novo endpoint esteja coberto pela suíte de testes StatsController.test.js.

Adicione testes do Jest para os métodos login e logout de AuthService.

Garanta que a cobertura de testes para essas duas funções seja de pelo menos 80%.

Use UserService.test.js como referência.

Após a implementação, execute `npm test -- --coverage` e verifique se o relatório de cobertura apresenta >80% para ambas as funções.

Confirme também que os testes passam com credenciais válidas e inválidas e que o logout limpa corretamente os dados de sessão.

Migre logger.js de JavaScript para TypeScript.

Já temos um tsconfig.json e uma suíte de testes LoggerTest.test.js para validação.

Certifique-se de que o arquivo seja compilado sem erros e não altere a configuração existente!

Após a migração, verifique:
1) executando `tsc` para confirmar que não há erros de tipo
2) executando a suíte de testes com `npm test LoggerTest.test.js` para garantir que todos os testes sejam aprovados
3) verificando se todas as chamadas existentes dos métodos do logger em toda a base de código ainda funcionam sem erros de tipo.

Estamos migrando de pg para Sequelize (leia https://sequelize.org/api/v6/identifiers).

Atualize as queries de UserModel para usar os métodos do Sequelize.

Use OrderModel como referência para ver como fazemos isso neste codebase.

Após a implementação, verifique:
1) executando `npm run test:integration UserModel.test.js` para checar se todos os testes de integração passam
2) confirmando que a performance das queries não piorou, verificando o tempo de execução em um dataset de teste com 1000 usuários
3) validando que todas as operações CRUD ainda mantêm a integridade dos dados executando `npm run test:e2e user-flows.test.js`

## Visão geral
A tarefa é fazer um pull request rápido para um repositório.
Como este é um PR "rápido", você não precisará executar nenhum código ou testar nada; basta abrir o PR e o usuário cuidará dos testes. Sua única responsabilidade é ler e escrever código.

## O que precisamos do usuário
- O repositório para o qual criar um pull request

## Procedimento
### Prepare seu workspace
1. Navegue até o repositório relevante na sua máquina (confirme com o usuário se você não conseguir descobrir qual é).
    - Faça checkout da branch principal e anote o nome da branch principal.
    - Faça checkout para uma nova branch, já que você fará um pull request. O nome da branch precisa estar no formato `devin/<your-branch-name>/X`, em que X é um número aleatório. Por exemplo, `devin/fix-popup/3234`. Rode `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` e substitua `{branch-name}` pelo nome da branch que você deseja criar.
2. Estude a solicitação, a base de código e planeje as mudanças
    - Revise os arquivos e seções de código mais relevantes, identificando trechos importantes.
    - Informe ao usuário o seu plano
### Trabalhe no PR em si
3. Faça as mudanças de código
    - Não altere nada que não tenha sido especificamente solicitado pelo usuário
4. Abra o PR
    - Faça commit e push das mudanças e avise o usuário.
    - Veja a seção de recomendações para o comando exato de criação do PR
    - Crie um pull request e revise o PR para garantir que está tudo correto.
    - Garanta que todas as GitHub Actions sejam aprovadas com sucesso e faça as alterações necessárias até que isso aconteça
    - Envie o link do PR para o usuário e resuma o que você mudou.
5. Trate qualquer feedback da revisão; envie o link do PR novamente sempre que fizer alterações
    - Se você precisar fazer atualizações, apenas faça push de mais commits para a mesma branch; não crie uma nova


## Especificação da tarefa
- O link do PR está incluído nas suas mensagens para o usuário
- O PR foi revisado após a criação
- O PR não inclui mudanças irrelevantes
- O PR não altera nada que não tenha sido especificamente solicitado pelo usuário
- A descrição do PR deve incluir um resumo das mudanças, formatado como uma checklist
- A descrição do PR deve mencionar que o código foi escrito sem testes e incluir - [ ] Test the changes como um item
- A descrição do PR deve incluir o seguinte rodapé: "Este PR foi escrito por [Devin](https://devin.ai/) :angel:"
- A descrição do PR deve incluir quaisquer metadados fornecidos pelo usuário (por exemplo, tags de ticket do Linear com a sintaxe apropriada)
- A descrição do PR não deve estar malformatada (use --body-file em vez de --body se as quebras de linha estiverem corrompidas!)

## Ações proibidas
- NÃO tente acessar github.com pelo navegador, você não estará autenticado.
- NUNCA dê force push em branches! Prefira fazer merge em vez de rebase para não perder nenhum trabalho.
- NÃO faça push diretamente para a branch principal.

## Recomendações e orientações
- Verifique duas vezes o nome da branch principal (que pode ser `main` ou `master`) usando `git branch`.
- Para repositórios com CI/CD em GitHub Actions, você pode verificar os logs de build usando o gh CLI. Se pedirem para você corrigir um build/corrigir lint, você deve começar analisando os logs de build recentes
- Verifique `git status` antes de fazer commit ou adicionar arquivos.
- Use `git diff` para ver quais mudanças você fez antes de fazer commit.
- Se estiver atualizando um repositório existente, use o gh CLI para criar pull requests.
- Envie o link do PR para o usuário sempre que atualizar e peça para ele revisar novamente, para ficar mais conveniente para ele
- Você já deve estar autorizado a acessar qualquer repositório que o usuário mencionar. Caso contrário, peça acesso ao usuário.