Primeros pasos con Devin

Crea un nuevo endpoint /users/stats que devuelva un objeto JSON con el número de usuarios y la edad promedio al registrarse.

Usa nuestra tabla existente de users en PostgreSQL.

Puedes tomar como referencia el endpoint /orders/stats en statsController.js para ver cómo estructuramos las respuestas.

Asegúrate de que el nuevo endpoint esté cubierto por el conjunto de pruebas StatsController.test.js.

Agrega pruebas de Jest para los métodos de AuthService: login y logout.

Asegúrate de que la cobertura de pruebas para estas dos funciones sea de al menos el 80%.

Usa UserService.test.js como ejemplo.

Después de la implementación, ejecuta `npm test -- --coverage` y verifica que el informe de cobertura muestre >80% para ambas funciones.

Confirma también que las pruebas pasen tanto con credenciales válidas como inválidas y que logout limpie correctamente los datos de sesión.

Migra el archivo logger.js de JavaScript a TypeScript.

Ya contamos con un tsconfig.json y una suite de pruebas LoggerTest.test.js para validación.

Asegúrate de que compile sin errores y de no modificar la configuración existente.

Después de la migración, verifica:
1) ejecutando `tsc` para confirmar que no haya errores de tipo
2) ejecutando la suite de pruebas con `npm test LoggerTest.test.js` para asegurar que todas las pruebas pasen
3) comprobando que todas las llamadas existentes a los métodos del logger en todo el código sigan funcionando sin errores de tipo.

Estamos pasando de pg a Sequelize (consulta https://sequelize.org/api/v6/identifiers).

Actualiza las consultas de UserModel para usar los métodos de Sequelize.

Revisa OrderModel para ver cómo lo hacemos en este código.

Después de la implementación, verifica lo siguiente:
1) ejecuta `npm run test:integration UserModel.test.js` para comprobar que pasan todas las pruebas de integración
2) confirma que el rendimiento de las consultas no se ha degradado comprobando el tiempo de ejecución en un conjunto de datos de prueba de 1000 usuarios
3) valida que todas las operaciones CRUD siguen manteniendo la integridad de los datos ejecutando `npm run test:e2e user-flows.test.js`

## Descripción general
La tarea consiste en hacer un pull request rápido a un repositorio.
Como se trata de un PR "rápido", no necesitarás ejecutar código ni probar nada; simplemente crea el PR y el usuario se encargará de las pruebas. Tu única responsabilidad es leer y escribir código.

## Qué se necesita del usuario
- El repositorio al que se debe crear el pull request

## Procedimiento
### Prepara tu espacio de trabajo
1. Navega al repositorio correspondiente en tu máquina (acláralo con el usuario si no puedes averiguarlo).
    - Haz checkout a la rama principal y toma nota del nombre de la rama principal.
    - Haz checkout a una nueva rama, ya que vas a crear un pull request. El nombre de la rama debe tener el formato `devin/<your-branch-name>/X` donde X es un número aleatorio. Por ejemplo, `devin/fix-popup/3234`. Ejecuta `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` y reemplaza `{branch-name}` por el nombre de la rama que quieras crear.
2. Estudia la petición, el código base y planifica los cambios
    - Revisa los archivos y secciones de código más relevantes, identificando los fragmentos importantes.
    - Informa al usuario de tu plan.
### Trabaja en el PR
3. Realiza los cambios de código
    - No cambies nada que el usuario no haya solicitado específicamente.
4. Crea el PR
    - Haz commit y push de los cambios e informa al usuario.
    - Consulta la sección de consejos para ver el comando exacto para crear el PR.
    - Crea un pull request y revísalo para asegurarte de que se ve bien.
    - Asegúrate de que todas las GitHub Actions se ejecutan correctamente y haz los cambios necesarios hasta que lo hagan.
    - Envía al usuario el enlace del PR y resume lo que has cambiado.
5. Atiende cualquier comentario de la revisión; envía de nuevo el enlace del PR cada vez que hagas cambios
    - Si necesitas hacer actualizaciones, simplemente haz push de más commits a la misma rama; no crees una nueva.


## Especificación de la tarea
- El enlace del PR está incluido en tus mensajes al usuario.
- El PR fue revisado después de su creación.
- El PR no incluye cambios ajenos a la tarea.
- El PR no cambia nada que el usuario no haya solicitado específicamente.
- La descripción del PR debe incluir un resumen de los cambios, formateado como una checklist.
- La descripción del PR debe mencionar que el código se escribió sin pruebas e incluir `- [ ] Test the changes` como un ítem.
- La descripción del PR debe incluir el siguiente pie de página: "This PR was written by [Devin](https://devin.ai/) :angel:"
- La descripción del PR debe incluir cualquier metadato que haya proporcionado el usuario (por ejemplo, etiquetas de tickets de Linear con la sintaxis adecuada).
- La descripción del PR no debe estar mal formateada (usa `--body-file` en lugar de `--body` si los saltos de línea se corrompen).

## Acciones prohibidas
- NO intentes acceder a github.com mediante el navegador; no estarás autenticado.
- NUNCA hagas force push en ramas. Prefiere hacer merge en lugar de rebase para no perder trabajo.
- NO hagas push directamente a la rama principal.

## Consejos y recomendaciones
- Verifica dos veces el nombre de la rama principal (podría ser `main` o `master`) usando `git branch`.
- Para repos con CI/CD en GitHub Actions, puedes revisar los logs de compilación usando la CLI de `gh`. Si te piden corregir un fallo de build o de lint, deberías empezar consultando los logs de builds recientes.
- Revisa `git status` antes de hacer commit o añadir archivos.
- Usa `git diff` para ver qué cambios has hecho antes de hacer commit.
- Si estás actualizando un repositorio existente, usa la CLI de `gh` para crear pull requests.
- Envía al usuario el enlace del PR cada vez que lo actualices y pídele que lo revise de nuevo para que le resulte cómodo.
- Deberías estar ya autorizado para acceder a cualquier repositorio que el usuario te indique. Si no es así, pídele acceso al usuario.