Come iniziare con Devin

Crea un nuovo endpoint /users/stats che restituisca un oggetto JSON con il numero di utenti e l'età media al momento della registrazione.

Usa la nostra tabella users già esistente in PostgreSQL.

Puoi fare riferimento all'endpoint /orders/stats in statsController.js per capire come strutturiamo le risposte.

Assicurati che il nuovo endpoint sia coperto dalla suite di test StatsController.test.js.

Scrivi test unitari Jest per i metodi di AuthService: login e logout.

Assicurati che la copertura dei test per queste due funzioni sia almeno all'80%.

Usa UserService.test.js come esempio.

Dopo l'implementazione, esegui `npm test -- --coverage` e verifica che il report della copertura mostri >80% per entrambe le funzioni.

Conferma inoltre che i test vengano superati sia con credenziali valide che non valide e che il logout svuoti correttamente i dati della sessione.

Migra logger.js da JavaScript a TypeScript.

Abbiamo già un tsconfig.json e una suite di test LoggerTest.test.js per la validazione.

Assicurati che compili senza errori e non modificare la configurazione esistente!

Dopo la migrazione, verifica:
1) eseguendo `tsc` per confermare l’assenza di errori di tipo
2) eseguendo la suite di test con `npm test LoggerTest.test.js` per assicurarti che tutti i test passino
3) controllando che tutte le chiamate esistenti ai metodi del logger in tutto il codice continuino a funzionare senza errori di tipo.

Stiamo passando da pg a Sequelize (vedi https://sequelize.org/api/v6/identifiers).

Aggiorna le query di UserModel per usare i metodi di Sequelize.

Usa OrderModel come riferimento per vedere come lo gestiamo in questo codebase.

Dopo l'implementazione, verifica:
1) eseguendo `npm run test:integration UserModel.test.js` per controllare che tutti i test di integrazione siano superati
2) confermando che le prestazioni delle query non siano peggiorate, controllando il tempo di esecuzione su un dataset di test di 1000 utenti
3) verificando che tutte le operazioni CRUD mantengano ancora l'integrità dei dati eseguendo `npm run test:e2e user-flows.test.js`

## Panoramica
Il compito è creare una pull request veloce per un repository.
Poiché questa è una PR "veloce", non è necessario eseguire il codice o testare nulla; limita il lavoro alla creazione della PR e l'utente si occuperà dei test. La tua unica responsabilità è leggere e scrivere codice.

## Cosa è necessario dall'utente
- Il repository su cui creare la pull request

## Procedura
### Prepara il tuo ambiente di lavoro
1. Vai al repository rilevante sulla tua macchina (chiarisci con l'utente se non riesci a capirlo).
    - Effettua il checkout del branch principale e annota il nome del branch principale.
    - Effettua il checkout di un nuovo branch dato che creerai una pull request. Il nome del branch deve avere il formato `devin/<your-branch-name>/X` dove X è un numero casuale. Ad esempio `devin/fix-popup/3234`. Esegui `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` e sostituisci `{branch-name}` con il nome del branch che vuoi creare.
2. Studia la richiesta, la codebase e pianifica le modifiche
    - Esamina i file e le sezioni di codice più rilevanti, identificando gli snippet pertinenti.
    - Informa l'utente del tuo piano
### Lavora sulla PR vera e propria
3. Applica le modifiche al codice
    - Non modificare nulla che non sia stato richiesto esplicitamente dall'utente
4. Crea la PR
    - Effettua commit e push delle modifiche e avvisa l'utente.
    - Consulta la sezione dei suggerimenti per il comando esatto per creare la PR
    - Crea una pull request e rivedi la PR per assicurarti che sia tutto a posto.
    - Assicurati che tutte le GitHub Actions vengano eseguite con successo e apporta le modifiche necessarie finché non passano
    - Invia all'utente il link della PR e riassumi ciò che hai modificato.
5. Gestisci qualsiasi feedback dalla review; invia di nuovo il link della PR ogni volta che apporti modifiche
    - Se devi fare aggiornamenti, esegui semplicemente altri commit sullo stesso branch; non crearne uno nuovo


## Specifiche del task
- Il link della PR è incluso nei tuoi messaggi all'utente
- La PR è stata rivista dopo la creazione
- La PR non include modifiche spurie
- La PR non cambia nulla che non sia stato richiesto esplicitamente dall'utente
- La descrizione della PR deve includere un riepilogo delle modifiche, formattato come checklist
- La descrizione della PR deve menzionare che il codice è stato scritto senza test e includere - [ ] Test the changes come voce
- La descrizione della PR deve includere il seguente footer: "Questa PR è stata scritta da [Devin](https://devin.ai/) :angel:"
- La descrizione della PR deve includere tutti i metadati forniti dall'utente (ad es. tag di ticket di Linear nella sintassi appropriata)
- La descrizione della PR non deve essere formattata male (usa --body-file invece di --body se le nuove righe vengono compromesse!)

## Azioni vietate
- NON provare ad accedere a github.com tramite il browser, non sarai autenticato.
- NON effettuare mai force push sui branch! Preferisci il merge al rebase per non perdere lavoro.
- NON effettuare push direttamente sul branch principale.

## Suggerimenti e indicazioni
- Controlla con attenzione il nome del branch principale (che potrebbe essere `main` o `master`) usando `git branch`.
- Per i repository con CI/CD su GitHub Actions, puoi controllare i log di build usando la gh cli. Se ti viene chiesto di correggere una build o un problema di lint, dovresti iniziare consultando i log di build recenti
- Controlla `git status` prima di fare commit o aggiungere file.
- Usa `git diff` per vedere quali modifiche hai apportato prima di fare commit.
- Se stai aggiornando un repository esistente, usa `gh cli` per creare le pull request.
- Invia il link della PR all'utente ogni volta che la aggiorni e chiedi di riesaminarla, in modo che sia comodo per loro
- Dovresti essere già autorizzato ad accedere a qualsiasi repository che l'utente ti segnala. In caso contrario, chiedi all'utente di concederti l'accesso.