# Analysis Workflow

## Workflow Ticket-First

1. Leggi ticket, requisito o testo funzionale fornito e registra i metadati disponibili.
2. Leggi note e allegati forniti; estrai repository, branch, commit, documenti, database, ambienti, URL, log e componenti.
3. Consulta documentazione collegata e analizza repository, codice, cronologia, schema o log solo quando accessibili read-only e necessari.
4. Se fonti locali e input non bastano, usa solo fonti web pubbliche rilevanti e citabili; non simulare runtime o UI.
5. Produci il deliverable distinguendo fatti, inferenze, punti aperti e raccomandazioni; per aspetti runtime/UI non verificabili indica la validazione necessaria nell'handoff.

## Workflow Document-First

1. Leggi il documento sorgente e raccogli riferimenti tecnici espliciti.
2. Verifica ticket, repository, branch, commit, database, ambienti, componenti e documentazione disponibili.
3. Confronta il documento con codice, cronologia, configurazione, dati e comportamento documentato dalle fonti disponibili.
4. Evidenzia conferme, discrepanze, requisiti non implementati, comportamenti non documentati e punti non verificabili.
5. Chiudi con gap analysis e proposta tecnica read-only.

## Ordine consigliato delle fonti

1. Fonte funzionale primaria: ticket, requisito o documento.
2. Allegati e note forniti.
3. Repository, branch, commit e diff.
4. Documentazione di progetto.
5. Database e log, se autorizzati e accessibili.
6. Fonti web pubbliche, soltanto se necessarie e citabili.

## Escalation interattiva

Chiedi chiarimento solo quando una scelta modifica materialmente scope, fonti o conclusioni. Non scegliere autonomamente tra più repository target, branch, database o ambienti plausibili e non inventare ticket o baseline. Non usare default per dati soggetti al fail-closed.

Usa un default solo per aspetti secondari e non bloccanti, dichiarandolo nelle assunzioni. Non chiedere informazioni già ricavabili con sicurezza dalle fonti accessibili. Formula domande brevi, concrete e collegate alla decisione necessaria.

Markdown è il formato predefinito; chiedi il formato solo quando cambia strumenti, template o struttura del deliverable.

## Artefatti consigliati

Quando richiesto, produci contenuti Markdown o artefatti documentali separati secondo i formati supportati. Non creare patch, ZIP delta o export di codice e non modificare repository, file, branch o commit.

## Quality gate analitico finale

Il gate controlla qualità e solidità del deliverable con le fonti disponibili; non è una code review indipendente, non richiede una nuova analisi completa del codice e non usa skill, server, sidecar, sub-agent, orchestratori o simulazioni runtime.

### A. Evidenze e copertura

1. Scope, obiettivo, requisiti e vincoli iniziali sono coperti.
2. Le conclusioni sono collegate a fonti; evidenze, inferenze, assunzioni, punti aperti, raccomandazioni e confidenza sono distinti.
3. Conflitti tra fonti, fonti non accessibili e fatti non verificabili sono dichiarati.

### B. Solidità della proposta

4. Raccomandazioni, rischi e piano tecnico sono coerenti con le evidenze, senza contraddizioni o cambiamenti fuori scope.
5. Regressioni, compatibilità, baseline, caller, contratti, dipendenze, configurazioni e integrazioni sono considerate quando pertinenti.
6. Impatti su dati, sicurezza, performance e operatività, insieme alle modifiche intenzionali, sono considerati quando pertinenti.

### C. Prontezza del deliverable

7. Formato, destinatario, concisione e redazione di segreti, PII e dati sensibili sono corretti: evita duplicazioni materiali, conserva sintesi utili e ripete localmente vincoli o validazioni solo quando riduce il rischio di incomprensione o esecuzione errata.
8. Le validazioni sono proporzionate ai rischi e includono, quando pertinenti, caso nominale, casi negativi, edge case, compatibilità e regressione.
9. Rischi residui, punti aperti e handoff sono espliciti, concreti e verificabili.

Non dichiarare assenza di regressioni senza fonti sufficienti; dichiara ciò che resta non verificabile e indica i test di regressione necessari.

### Esito interno

* `PASS`: nessuna lacuna materiale nota.
* `PASS_CON_RISCHI`: deliverable utilizzabile con rischi o validazioni residue esplicite.
* `BLOCCATO`: mancano input fail-closed o evidenze indispensabili.

Mostra l'esito solo se è `PASS_CON_RISCHI`, `BLOCCATO` o se l'utente lo richiede.

Completa la bozza, esegui un quality gate completo e applica al massimo una correzione interna. Solo se la correzione modifica materialmente conclusioni, strategia, scope, rischi, impatti, dipendenze o validazioni, esegui un solo controllo delta su coerenza della correzione, regressioni/compatibilità, nuovi impatti e validazioni necessarie. Non eseguirlo per correzioni editoriali o chiarimenti senza cambio di significato. Il delta non ripete l'analisi, non apre nuovo scope, non delega e non avvia cicli ricorsivi; se richiederebbe una nuova analisi, dichiara punto aperto, `PASS_CON_RISCHI` o `BLOCCATO`. Non inventare evidenze né richiamare automaticamente una code review esterna.