# Output modes

## analyst-handoff (default)

Destinato a Sophia Technical Analyst, senza richiedere una seconda code review. Conserva repository, head branch e commit, base branch e commit, PR o range, modalita, verdetto, fonti, regole, limiti, finding, vincoli e validazioni. Il reviewer non genera automaticamente il prompt finale per l'agente AI incaricato del fix.

### Inline

Usalo per finding pochi, semplici e indipendenti. Include repository, head/base branch e commit, PR/range, modalita, verdetto, finding numerati con severita, confidenza, evidenza, impatto e correzione richiesta, vincoli, criteri di accettazione, validazioni e limiti.

### Documento Markdown

Usalo per review numerose, complesse, multi-step o persistenti, per piu moduli, dipendenze, rischi trasversali, contratti/dati/configurazioni, vincoli legacy, checkpoint, review combinata o richiesta esplicita. Non scriverlo nel repository target; se non esiste una capacita esterna di artefatto, restituisci tutto il Markdown.

```md
---
document_type: code-review-handoff
review_mode: generic-review
verdict: DA_CORREGGERE
target: sophia-technical-analyst
---

# Code review handoff — [titolo]

## Identificazione della review
## Obiettivo della review
## Fonti consultate
## Copertura
## Verdetto
## Spec compliance
## Scope drift
## Finding
## Aspetti verificati senza finding
## Ordine consigliato delle correzioni
## Vincoli trasversali
## Validazione complessiva richiesta
## Limiti dell'evidenza
## Quality gate
## Handoff a Sophia Technical Analyst
```

`Spec compliance` e `Scope drift` sono condizionali. Ogni finding include ID, categoria, severita, confidenza, stato `OPEN`, evidenza, file/linee/simboli quando verificati, impatto, comportamento attuale e richiesto, correzione richiesta, strategia possibile, vincoli, fuori scope, criteri di accettazione, validazioni, dipendenze e punti aperti.

### Nessun finding

Rispondi inline salvo richiesta di verbale formale. Indica aspetti verificati, limiti e che non risultano correzioni da trasformare in prompt di implementazione. Non creare piano, quick win o test artificiale.

## human-review (solo esplicito)

Include esito, scope e baseline, aspetti verificati, finding, limiti e verdetto. Ogni finding riporta categoria, severita, confidenza, evidenza, impatto, correzione consigliata e validazione. Non aggiungere automaticamente un piano implementativo.

## Spec-compliance

| Requisito | Fonte | Evidenza nel codice | Esito | Note |
| --- | --- | --- | --- | --- |
| ... | ... | ... | PASS/FAIL/UNCLEAR | ... |

Solo `FAIL` verificati diventano correzioni richieste. `PASS` non produce attivita; `UNCLEAR` resta punto aperto.