siae-blind-review

name	siae-blind-review
description	Use when performing a blind code review: receive ONLY the spec, locate the code autonomously, evaluate as a hostile auditor. Review cieca: riceve SOLO la spec, trova il codice autonomamente, valuta come auditor ostile. Trigger: "blind review", "review cieca", "audit spec", "verifica spec vs codice", "review senza diff", REQUIRED SUB-SKILL da siae-finishing-branch.
validates_via	{"predicate":"blind_review_completed","evidence_type":"log_event","evidence_check":"DEVFORGE_LOG_FILE contains blind_review_verdict event for current sid"}

SIAE Blind Review — Audit Ostile Spec vs Codice

Tipo: Rigid | Fase SDLC: 6. QA Gate

---

LA LEGGE DI FERRO

NESSUN BIAS DI CONFERMA. IL REVIEWER PARTE DALLA SPEC, NON DAL DIFF.

Stai per leggere il git diff, il piano implementativo, i commit messages, o l'output dei test? FERMATI. Questa skill ti VIETA di leggere qualsiasi cosa che non sia il design doc e il codice sorgente.

Il bias di conferma e' il nemico. Se sai cosa l'implementer ha fatto, cercherai conferme invece di cercare problemi. L'auditor ostile non sa. Trova.

🧪 Nota harness (batch 3, 2026-07-15): l'isolamento sopra e' disciplina, non un vincolo tecnico — nulla impedisce di leggere il diff per errore. Il frontmatter context: fork (Claude Code, skill run in un subagent isolato) lo renderebbe strutturale, ma la doc ufficiale (code.claude.com/docs/en/skills + /hooks + /sub-agents) NON specifica se un'invocazione forkata resta osservabile come tool call Skill nel transcript del parent — condizione necessaria perche' hooks/post-skill (matcher Skill) continui a scrivere il ledger ~/.claude/.devforge-session-skills che i gate backbone leggono. Finche' questo non e' verificato manualmente in sessione interattiva, context: fork NON va applicato qui (rischio morte silenziosa del gate, stessa classe di #390). Nel frattempo il pattern raccomandato — gia' in uso in pratica — resta il dispatch esplicito via subagent (Task/Agent tool) quando serve isolare il contesto, non l'annotazione automatica in frontmatter. Vedi docs/plans/2026-07-15-aisdlc-batch3-harness-novita-design.md.

📊 Dai repo itsiae: Il 28% dei task implementati senza blind review conteneva spec drift scoperto solo in produzione.

---

Quando si Applica

Sempre:

• Come REQUIRED SUB-SKILL di siae-finishing-branch (prima di ogni PR)
• Quando l'utente chiede esplicitamente una blind review

Eccezioni (chiedi esplicitamente al partner umano):

• Hotfix P1 dove il tempo e' critico (l'utente deve autorizzare esplicitamente lo skip)

Scaling automatico (no conferma umana richiesta):

• Modifiche con risk=low (doc-only / manifest plugin, classificato da lib/diff-risk-classifier.sh): il gate pr-blind-review-gate è advisory automatico. Per qualsiasi diff risk=code la blind review resta obbligatoria.

---

Istruzioni

Step 1 — Carica la Spec (🟢 SICURO)

1. Cerca il design doc piu' recente in docs/plans/:

   ls -t docs/plans/*-design.md 2>/dev/null | head -1
   

   Se formato split: cerca docs/plans/*/overview.md e il design doc associato.

2. Leggi SOLO il design doc. Estrai: requisiti funzionali, criteri di accettazione, ADR, componenti/file previsti.

3. NON leggere: piano implementativo, commit messages, git diff, output test.

Se non esiste un design doc: BLIND REVIEW: IMPOSSIBILE — Nessun design doc trovato in docs/plans/. Senza spec, non c'e' metro di giudizio. Procedi senza blind review o scrivi una spec retroattiva con siae-brainstorming.

Step 2 — Trova il Codice (🟢 SICURO)

Per ogni requisito estratto dal design doc:

1. Usa Grep e Glob per trovare il codice che lo implementa (parti da keyword: classi, funzioni, endpoint, tabelle).
2. Naviga e leggi le implementazioni trovate.
3. Mappa: Requisito N → file:riga trovato.

Regole: NON usare git diff o git log. Codice non trovato → MISSING. Codice senza requisito → YAGNI.

Step 3 — Audit Ostile (🟡 MEDIO — produce il verdetto)

Per ogni requisito, emetti verdetto: PASS (soddisfatto), DRIFT (diverge), MISSING (non trovato), YAGNI (extra non richiesto), PARTIAL (parziale).

Output obbligatorio: header BLIND REVIEW REPORT, spec path, Reviewer mode: BLIND (no diff, no plan, no commit history), tabella | # | Requisito | Codice trovato | Verdetto | Note |, riepilogo counts per verdetto, verdetto finale PASS o FAIL.

Regola FAIL: Missing > 0 OR Drift critico OR YAGNI con rischio sicurezza.

Se FAIL: elenca finding bloccanti. La PR NON si apre finche' non risolti o l'utente autorizza bypass. Se PASS: procedi con finishing-branch.

---

Classificazione Rischio / Limiti / Permission Denied

Vedi lib/risk-taxonomy.md, lib/operational-limits.md, lib/permission-denied-handling.md.

In questa skill: Step 1-2 e verdetto PASS → 🟢 Sicuro. Verdetto FAIL (blocca PR) → 🟡 Medio (il blocco e' il comportamento corretto). Step 1-3 sono tutti read-only (Read/Grep/Glob): se Bash negato, richiedi contenuto design doc all'utente e prosegui.

---

Vincoli

1. NON leggere git diff, git log, commit messages, piano implementativo
2. NON leggere output di test o CI
3. SEMPRE partire dal design doc come unica fonte di verita'
4. SEMPRE produrre il report strutturato con verdetto per ogni requisito
5. PRE-FLIGHT OBBLIGATORIA per operazioni con rischio >= 🟡