Valutatore di Debito Tecnico

Valuta il debito tecnico nel seguente codice e produci un piano di rimedio prioritizzato:

**Contesto del Progetto**:
- Tipo di applicazione: [es. web app B2B SaaS, API mobile, data pipeline]
- Tech stack: [es. Python/Django, React, PostgreSQL]
- Dimensione del team: [NUMERO DI SVILUPPATORI che lavorano su questo codebase]
- Età del codebase: [es. 3 anni, nato come prototipo]
- Punti critici attuali: [COSA HA MOTIVATO QUESTO AUDIT? es. "Le nuove funzionalità richiedono 3 volte il tempo previsto", "I bug continuano a comparire nel modulo di fatturazione"]

**Codice da Valutare**:
```
[INCOLLA IL CODICE, IL MODULO O I FILE CHE VUOI ANALIZZARE. Per codebase grandi, incolla prima l'area più problematica, oppure incolla la struttura delle directory e i file chiave.]
```

**Vincoli Noti**:
- Priorità imminenti: [QUALI FUNZIONALITÀ O SCADENZE IN ARRIVO INFLUENZANO I TEMPI DI REFACTORING]
- Aree intoccabili: [QUALSIASI COSA CHE NON PUOI CAMBIARE ORA, es. "Non possiamo sostituire l'ORM fino al Q3"]

Produci la valutazione in questo formato:

1. **Sommario Esecutivo** (3-4 frasi): Una panoramica non tecnica della salute del codebase e dei rischi di business dello stato attuale. Scritto in modo che un product manager o CTO possa capire l'urgenza senza leggere il report completo.

2. **Inventario del Debito**: Per ogni elemento di debito tecnico trovato, fornisci:
   - **ID**: TD-01, TD-02, ecc.
   - **Categoria**: Debito di Design (problemi architetturali), Debito di Codice (code smell implementativi), Debito di Test (test mancanti o inadeguati), Debito di Dipendenze (dipendenze obsolete o rischiose), Debito di Documentazione (documentazione mancante o fuorviante)
   - **Descrizione**: Qual è il problema e dove si trova (file, modulo o livello)
   - **Gravità**: Critica / Alta / Media / Bassa
   - **Rischio di Business**: Come questo debito si manifesta come problema reale (es. "Ogni nuovo metodo di pagamento richiede modifiche in 4 file invece di 1, triplicando i tempi di sviluppo e la superficie di bug")
   - **Stima dell'Impegno**: Taglia (S: ore, M: 1-3 giorni, L: 1-2 settimane, XL: progetto multi-settimana)
   - **Dipendenze**: Altri elementi di debito da risolvere prima, o funzionalità che verrebbero bloccate

3. **Distribuzione del Debito**: Riassumi quanti elementi ricadono in ogni categoria e livello di gravità. Identifica quale categoria comporta il rischio maggiore.

4. **Matrice delle Priorità**: Ordina tutti gli elementi per rapporto "impatto su impegno". Gli elementi a priorità più alta offrono la maggiore riduzione del rischio con il minore investimento.

5. **Roadmap di Rimedio**: Organizza gli elementi di debito in tre fasi:
   - **Fase 1 (Vittorie Rapide)**: Elementi a basso impegno e alto impatto, da affrontare subito in parallelo al lavoro sulle funzionalità. Obiettivo: 1-2 settimane.
   - **Fase 2 (Sprint Dedicati)**: Elementi a impegno medio che richiedono tempo dedicato nello sprint. Obiettivo: 1-2 sprint.
   - **Fase 3 (Refactoring Strategici)**: Elementi ad alto impegno che richiedono pianificazione, eventuale blocco delle funzionalità o migrazione graduale. Obiettivo: pianificazione trimestrale.
   Per ogni fase, stima la riduzione cumulativa del rischio (es. "Completare la Fase 1 elimina il 40% del debito ad alta gravità identificato").

6. **Raccomandazioni di Prevenzione**: 3-5 modifiche a processi o strumenti che impedirebbero l'accumulo di debito simile (es. "Aggiungere una regola di linting per imporre una lunghezza massima delle funzioni", "Richiedere copertura test per i nuovi file nella CI").