| 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)
-
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.
-
Leggi SOLO il design doc. Estrai: requisiti funzionali, criteri di accettazione, ADR, componenti/file previsti.
-
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:
- Usa Grep e Glob per trovare il codice che lo implementa (parti da keyword: classi, funzioni, endpoint, tabelle).
- Naviga e leggi le implementazioni trovate.
- 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
- NON leggere git diff, git log, commit messages, piano implementativo
- NON leggere output di test o CI
- SEMPRE partire dal design doc come unica fonte di verita'
- SEMPRE produrre il report strutturato con verdetto per ogni requisito
- PRE-FLIGHT OBBLIGATORIA per operazioni con rischio >= 🟡
