# Functional consistency

Valutare `functional_consistency` solo quando sono presenti evidenze verificabili (ticket, analisi funzionale, documentazione di requisito, test funzionali attesi).

## Decision table rapida

| Situazione | Azione della skill |
| --- | --- |
| Fonte funzionale chiara e verificabile | Includi finding `functional_consistency` con evidenza esplicita. |
| Nessuna fonte funzionale disponibile | Non inferire requisiti; fai review tecnica e dichiara limite. |
| Fonte parziale o ambigua | Riduci confidenza, marca i dubbi aperti, chiedi minimo contesto aggiuntivo. |
| Serve correlare molte fonti (ticket+allegati+wiki+commit) | Escalation a `mcp-technical-analyst` prima della review funzionale. |

## Checklist operativa minima

1. Ho almeno una fonte funzionale citabile (ticket/doc/test atteso)?
2. Posso collegare il requisito a file/diff specifici?
3. Il collegamento e' diretto (**fatto**) o solo plausibile (**inferenza**)?
4. Se manca il punto 1 o 2, limito la review al tecnico e dichiaro il perimetro.

## Casi pratici

### Caso A - ticket disponibile
- Input: commit + ticket `MNT-456` con comportamento atteso esplicito.
- Azione: includi `functional_consistency` con severita'/confidenza motivate su base ticket.
- Output: "allineato/non allineato" con riferimento esplicito a requisito e diff.

### Caso B - nessuna fonte funzionale
- Input: branch o file senza ticket/docs.
- Azione: solo review tecnica (`correctness`, `maintainability`, `test_gap`, ecc.).
- Output: dichiarare esplicitamente che la coerenza funzionale non e' verificabile.

### Caso C - fonti parziali/ambigue
- Input: note wiki incomplete + commento ticket non conclusivo.
- Azione: segnala ipotesi come inferenze, chiedi il minimo contesto mancante, evita giudizi assoluti.
- Escalation: se servono correlazioni estese o ricostruzione storica, passa a `mcp-technical-analyst`.

Template domanda breve:

- "Per validare la coerenza funzionale mi serve almeno una fonte verificabile (ticket o documento requisito). Vuoi fornirmela ora?"