# Performance Improvement Registry

| ID | Miglioria | Priorita | Impatto | Costo | Rischio | Evidenza base | Stato |
|---|---|---|---|---|---|---|---|
| PR-01 | Checklist tecnica per griglie avanzate e filtri | P1 | Alto | Basso | Basso | `structure_and_functions.md`, `sophia_customizations.md`, `07_differenze_cross_app.md` | Proposta |
| PR-02 | Standard operativo per sessione e browser-back | P1 | Alto | Basso | Basso | `structure_and_functions.md`, `sophia_customizations.md`, `08_migliorie_app.md` | Proposta |
| PR-03 | Riduzione costo logging eccezioni ripetute | P2 | Medio-alto | Medio | Medio | `structure_and_functions.md`, `sophia_customizations.md` | Proposta |
| PR-04 | Consolidamento configurazioni di rendering ricorrenti | P2 | Medio | Medio | Medio-basso | `structure_and_functions.md` | Proposta |
| PR-05 | Baseline misurabile per griglie, sessione ed error handling | P3 | Alto | Medio | Basso | `07_differenze_cross_app.md`, `08_migliorie_app.md` | Proposta |
| PR-06 | Registry performance come artefatto vivo | P3 | Medio | Medio | Basso | `07_differenze_cross_app.md`, `cross_app_capability_registry.md` | Proposta |

## Regole di lettura

- `Priorita` ordina il backlog in base a valore operativo e urgenza.
- `Impatto` descrive il beneficio atteso su performance percepita, stabilita o costo di manutenzione.
- `Costo` indica il principale sforzo richiesto, privilegiando le modifiche documentali quando possibile.
- `Rischio` valuta la probabilita di regressioni o di perdita di chiarezza diagnostica.

## Note operative

- Il registry e uniforme e pensato per essere esteso senza cambiare struttura.
- Le voci sono collegate a evidenze gia presenti nel corpus locale, senza introdurre benchmark non disponibili.
- Le metriche numeriche andranno aggiunte solo dopo una verifica strumentale nel repository applicativo o in ambiente di test.

## Scopo
Descrivere obiettivo operativo e risultato atteso.

## Perimetro
Definire modulo, confini funzionali e prerequisiti.

## Flusso
1. Input e contesto.
2. Esecuzione del processo.
3. Output e verifica.

## Componenti
- Controller/servizi.
- Model e tabelle.
- Job/log/integrazioni correlate.

## Failure mode
- Errori ricorrenti.
- Cause tipiche.
- Segnali diagnostici.

## Checklist
- Pre: prerequisiti validati.
- Post: outcome e coerenza dati verificati.

## Criteri di accettazione
Contenuto azionabile, verificabile e coerente con il codice.