---
id: spec-critique
agent: qa
title: Criticar a spec quanto a completude e clareza
inputs: [spec]
outputs: [critique.json com veredito e scores, lista de gaps rastreáveis]
elicit: false
modes: [interactive, yolo]
---

# Criticar a spec quanto a completude e clareza

**Objetivo:** auditar uma spec antes da implementação — apontar o que está incompleto, ambíguo ou
inventado — e emitir um veredito rastreável (APPROVED / NEEDS_REVISION / BLOCKED) que decide se a spec
avança para o plano ou volta para revisão.

**Pré-condições:**
- A spec existe e referencia suas fontes (FR-*, NFR-*, CON-* ou achados de pesquisa). Sem fontes
  rastreáveis, a crítica já começa em risco — toda afirmação precisa ancorar em algo.
- Tenho o contexto do objetivo que originou a spec (pedido/story). Se não tenho, elicito — eu critico
  contra um contrato, não contra o ar.

## Passos

1. **Leio a spec inteira** e listo cada afirmação material. Defino o que "completo e claro" significa
   para ESTE escopo antes de julgar.
2. **Gate constitucional — No Invention (Art. IV).** Verifico que TODA afirmação rastreia a um FR-*,
   NFR-*, CON-* ou achado de pesquisa. Qualquer feature inventada (sem fonte) é gap CRÍTICO e por si
   só leva a BLOCKED. Juiz não inventa requisito; também não deixa a spec inventar.
3. **Avalio as dimensões** (score 1-5 cada), profundidade proporcional ao risco:
   - **Completude:** todos os ACs/cenários cobertos? casos de erro e borda previstos?
   - **Clareza:** linguagem inequívoca? cada termo definido? nada de "etc." escondendo escopo?
   - **Testabilidade:** cada requisito vira teste em Given-When-Then? há critério objetivo de pronto?
   - **Rastreabilidade:** cada afirmação ancora numa fonte declarada?
   - **Risco/NFR:** segurança, performance e confiabilidade endereçadas onde o caminho é crítico?
4. **Registro cada gap** com severidade (CRITICAL/HIGH/MEDIUM/LOW) e a fonte que prova o buraco —
   nunca opinião estética avulsa. Advisory, não arbitrário: bloqueio só com motivo rastreável.
5. **Calculo o veredito** pela média dos scores:
   - média **≥ 4.0** → **APPROVED** (segue para o plano).
   - média **3.0–3.9** → **NEEDS_REVISION** (volto com a lista de correções obrigatórias).
   - média **< 3.0** ou qualquer gap CRÍTICO de invenção → **BLOCKED** (escalo ao @architect).
6. **Emito `critique.json`** com veredito, scores por dimensão e a lista de gaps. Esse é o artefato
   que o pipeline lê para decidir o próximo passo.
7. **Roteio.** APPROVED → @architect planeja. NEEDS_REVISION → @pm revisa a spec. BLOCKED → escalo ao
   @architect. Eu critico; eu **não reescrevo** a spec — corrigir é de quem a escreveu.

## Critério de pronto (DoD)

- [ ] Toda afirmação da spec checada contra fonte (FR/NFR/CON/pesquisa) — gate No Invention aplicado
- [ ] As 5 dimensões pontuadas (1-5) com justificativa rastreável
- [ ] Cada gap registrado com severidade e fonte (zero achado por preferência estética)
- [ ] Veredito calculado pela regra (APPROVED / NEEDS_REVISION / BLOCKED) e coerente com os scores
- [ ] `critique.json` emitido e roteado ao destino correto
- [ ] Não reescrevi a spec nem inventei critério fora do contrato

## Falha / recuperação

- **Spec sem fontes rastreáveis** → não consigo aplicar o gate de invenção: marco BLOCKED e devolvo
  ao @pm para amarrar as fontes antes de eu recriticar.
- **Veredito BLOCKED ou gap CRÍTICO** → escalo ao @architect imediatamente; não deixo a spec avançar
  para implementação no escuro.
- **Falta o contexto do objetivo que originou a spec** → paro e elicito; não critico contra o ar.
- **Preciso subir o artefato (push/PR)** → delego ao @devops, sempre. Eu não faço `git push` nem abro
  PR; git para mim é read-only.