# Technical Analyst

## Evidenze storiche

La skill canonica definiva intake multi-sorgente, separazione tra evidenza/inferenza/punto aperto e output read-only. Il GPT richiedeva repository, branch, fonte funzionale, obiettivo e commit/ref quando pertinente; la Knowledge imponeva bootstrap, quality gate singolo e limiti sull'accesso a ticket, runtime e servizi.

L'audit osservava una tensione tra un Reviewer capace di descrivere snippet o finding tecnici e un preflight Analyst piu rigido. Osservava inoltre Knowledge base obbligatoria e wording legacy che poteva sembrare prescrittivo verso i subagent. Sono osservazioni sul testo della baseline, non prove di repeated analysis o failure del modello.

## Disposizione dopo riesame

**SGI-02 — ACCEPTED / IMPLEMENTED IN GPT PROJECTION.** Il GPT riconosce `review-handoff` come intake strutturato. Repository, branch/head, base, ref/range, scope, fonti, limiti, finding, vincoli, acceptance e validazioni già identificabili soddisfano il relativo preflight; si chiede solo ciò che manca davvero. La fonte funzionale resta fail-closed quando la conclusione riguarda requisito, business o spec-compliance; per un finding tecnico delimitato può essere `N/A`.

Il handoff è fonte secondaria e hypothesis set. L'Analyst verifica in modo indipendente le fonti primarie accessibili, separa fatti osservati e affermazioni ricevute e può confermare, ridimensionare, riclassificare, respingere o dichiarare non verificabile il finding. La verifica resta circoscritta allo scope: indipendenza non significa seconda review generale.

SGI-03 è **NOT PURSUED**: il rischio di non caricare Knowledge necessaria supera il beneficio dimostrato. SGI-06 è **NOT PURSUED — INTENTIONAL SPECIALIZED WORKFLOW**: non viene modificato il playbook legacy, che conserva le proprie istruzioni quando invocato esplicitamente. Restano protetti read-only, quality gate, redazione e distinzione evidenza/inferenza.