Tu primera sesión

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 users en PostgreSQL. 

Puedes usar 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 la suite StatsController.test.js.

En UserProfileComponent, añade un menú desplegable que muestre una lista de roles de usuario (admin, editor, viewer). 

Usa el estilo de DropdownBase. 

Cuando se seleccione un rol, llama a la API existente para configurar el rol del usuario. 

Valida verificando que la selección actualiza el rol del usuario en la base de datos. Consulta tu Knowledge para ver cómo probarlo correctamente.

Añade 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 un 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. 

También confirma que las pruebas pasen tanto con credenciales válidas como inválidas, y que logout borre correctamente los datos de sesión.

Migra logger.js de JavaScript a TypeScript. 

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

Asegúrate de que compile sin errores y de no cambiar 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 asegurarte de que todas las pruebas pasen
3) comprobando que todas las llamadas existentes a métodos de logger en toda la base de código sigan funcionando sin errores de tipo.

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

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

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

Después de implementar, verifica lo siguiente:
1) ejecutando `npm run test:integration UserModel.test.js` para comprobar que pasan todas las pruebas de integración
2) confirmando 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) validando que todas las operaciones CRUD siguen manteniendo la integridad de los datos, ejecutando `npm run test:e2e user-flows.test.js`

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

## What's Needed From User
- El repositorio al que se debe crear la pull request

## Procedure
### Prepare your workspace
1. Navega al repositorio correspondiente en tu máquina (acláralo con el usuario si no puedes identificarlo).
    - Haz checkout de la rama principal y toma nota del nombre de esa rama.
    - Haz checkout a una rama nueva, ya que vas a crear una pull request. El nombre de la rama debe tener el formato `devin/<nombre-de-tu-rama>/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}` con el nombre de la rama que quieres crear.
2. Estudia la petición, el codebase y planifica los cambios
    - Revisa los archivos y secciones de código más relevantes, identificando los fragmentos pertinentes.
    - Informa al usuario de tu plan
### Work on the PR itself
3. Realiza los cambios de código
    - No cambies nada que el usuario no haya solicitado específicamente
4. Crea la 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 la PR
    - Crea una pull request y revísala para asegurarte de que se ve bien.
    - Asegúrate de que todas las GitHub Actions pasan correctamente y realiza los cambios necesarios hasta que lo hagan
    - Envía el enlace de la PR al usuario y resume lo que cambiaste.
5. Atiende cualquier comentario de la revisión; envía el enlace de la PR de nuevo cada vez que hagas cambios
    - Si necesitas hacer actualizaciones, simplemente haz push de más commits a la misma rama; no crees una nueva


## Task Specification
- El enlace de la PR se incluye en tus mensajes al usuario
- La PR fue revisada después de su creación
- La PR no incluye cambios accidentales
- La PR no cambia nada que el usuario no haya solicitado específicamente
- La descripción de la PR debe incluir un resumen de los cambios, con formato de checklist
- La descripción de la PR debe mencionar que el código se escribió sin pruebas, e incluir - [ ] Test the changes como un elemento
- La descripción de la PR debe incluir el siguiente pie de página: "This PR was written by [Devin](https://devin.ai/) :angel:"
- La descripción de la PR debe incluir cualquier metadata que el usuario haya proporcionado (por ejemplo, etiquetas de tickets de Linear con la sintaxis adecuada)
- La descripción de la PR no debe estar malformateada (usa --body-file en lugar de --body si los saltos de línea se estropean)

## Forbidden Actions
- NO intentes acceder a github.com a través del 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.

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