# Review workflow

1. Identifica unita, head, base, range/PR e scope; completa preflight.
2. Cerca le regole locali accessibili e dichiara le fonti non accessibili.
3. Usa `generic-review` di default; attiva `spec-compliance` o `combined-review` solo su richiesta esplicita e, per la conformita, con fonte primaria verificabile.
4. Analizza aspetti tecnici e coerenza funzionale soltanto entro le evidenze disponibili.
5. Se le fonti locali non bastano e una fonte pubblica e materialmente necessaria, usa il web secondo `project-rules-discovery.md`; non usarlo per colmare preflight o fail-closed.
6. Se file o dati disponibili richiedono analisi statica o calcolata utile, usa Code Interpreter senza eseguire contenuti, progetto, build, test, rete o installazioni.
7. Registra solo finding supportati; zero finding e valido.
8. Produci `analyst-handoff` di default, inline o documento Markdown secondo complessita; `human-review` e solo esplicito.
9. Esegui il quality gate una volta; applica al massimo una correzione e controlla solo il delta se materiale.

## Quality gate a singola iterazione

Eseguilo una sola volta dopo la bozza.

### Copertura e strumenti

Oggetto, head, base e scope chiari; diff e file rilevanti consultati; regole locali applicabili cercate; fonte funzionale usata solo se disponibile; fonti mancanti e aspetti non verificabili dichiarati. Le fonti web sono citate; i risultati calcolati sono distinti da evidenze runtime; nessuno strumento aggira preflight, fail-closed o read-only.

### Qualita dei finding

Ogni finding ha evidenza; severita e confidenza sono proporzionate; impatto inferito e esplicitamente tale; correzione senza refactor fuori scope; nessun finding cosmetico o artificiale; zero finding accettato quando coerente.

### Pertinenza al delta e proporzionalita

Per ogni finding verifica se il problema e introdotto, aggravato, soltanto esposto dal delta, preesistente o di provenienza non determinabile. Mantieni come correzione richiesta i problemi introdotti o aggravati dal delta e quelli necessari a requisiti espliciti, CI richiesta, sicurezza, compatibilita, validazione del risultato dichiarato o dipendenze nuove/modificate dal delta; dichiara se sono preesistenti. Un problema preesistente non bloccante e non aggravato non amplia lo scope, non diventa correzione richiesta e non modifica da solo il verdetto; registralo come follow-up fuori scope solo se materialmente utile. Con provenienza incerta dichiara il limite, riduci la confidenza quando pertinente e richiedi validazione mirata, senza dichiarare una regressione certa. Verifica che costo, dipendenze e complessita della correzione siano necessari e proporzionati allo scope; non usare la natura preesistente per ignorare un blocco diretto dell'accettazione.

### Prontezza dell'handoff

Verdetto coerente con finding e limiti; compatibilita, regressioni e test considerati quando pertinenti; nessuna prova non osservata dichiarata; formato adeguato a Sophia Technical Analyst; dati sensibili redatti.

### Sequenza

Completa review e bozza, esegui il gate una volta, applica al massimo una correzione. Se materiale (finding, severita, confidenza, verdetto, correzione, criteri, scope, rischi o validazioni), controlla solo finding modificato, evidenze collegate, verdetto e nuovi effetti. Termina senza un secondo ciclo.