ll-skills 1.0.0

package/skills/ll-pesquisar-mercado/referencias/padroes-de-pesquisa.md

@@ -0,0 +1,149 @@
+# Padrões de pesquisa — obrigatório para quem escreve um documento do dossiê
+
+Este arquivo define o formato do documento, o vocabulário de confiança, como buscar e citar, os vieses que corrompem o resultado e o portão que o documento atravessa antes de ser aceito. Vale para qualquer documento do dossiê.
+
+---
+
+## 1. Esqueleto padrão de qualquer documento
+
+Nome do arquivo em **kebab-case descritivo** (`analise-concorrentes.md`, `panorama-de-precos-mercado.md`). Um assunto por arquivo — se o arquivo precisa de dois resumos executivos, são duas pesquisas.
+
+```markdown
+# Título
+
+**Data:** AAAA-MM-DD
+**Contexto/Escopo:** uma linha sobre o projeto e o recorte desta pesquisa
+**Natureza:** (quando o documento é neutro) ex.: "mapa neutro; NÃO recomenda preço"
+
+## Resumo executivo
+Um a dois parágrafos com os números e a conclusão. Quem lê só isto decide.
+O resumo só pode conter números que aparecem no corpo com fonte.
+
+## Nota de método
+- Data e forma da pesquisa; o que foi verificado diretamente
+- Legenda de confiança (tabela abaixo)
+- Limitações declaradas: fontes bloqueadas ao crawler, amostras autosselecionadas,
+  dados proprietários, o que ficou pendente de coleta manual
+- Políticas de leitura, quando aplicável (ex.: descontos "de/por" permanentes são
+  reportados pelo preço efetivamente cobrado)
+
+## [Seções de conteúdo — tabelas com FONTE POR LINHA]
+
+## Síntese: achado → implicação
+Tabela de duas colunas. É o que conecta pesquisa a decisão; sem ela o documento é
+enciclopédico.
+
+## O que foi procurado e NÃO encontrado
+Lista numerada, cada item com o motivo: não existe / bloqueado / proprietário /
+só por contato direto.
+
+*Rodapé: data de produção, validade dos dados, o que reverificar antes de decidir.*
+```
+
+## 2. Legenda de confiança
+
+| Marca | Significado |
+|---|---|
+| ✅ | verificado em fonte primária/oficial nesta data |
+| ⚠️ | via snippet, agregador ou fonte secundária — estimativa confiável |
+| 📅 | dado histórico (ano indicado) — pode estar obsoleto |
+| **[N]** | procurado e **não encontrado** |
+| *(itálico)* | inferência ou estimativa **desta pesquisa**, não dado de terceiro |
+
+A marca vai **na linha da tabela ou colada ao número**, nunca em nota de rodapé genérica: a confiança precisa viajar junto com o dado quando alguém copiar a linha para um slide.
+
+## 3. Força de evidência — o vocabulário do dossiê inteiro
+
+| Rótulo | Critério | Como usar |
+|---|---|---|
+| **FORTE** | Estudo publicado + replicação + experimento de campo ou dado de larga escala | Pode desenhar em cima; ainda assim, meça |
+| **MODERADA** | Estudo original sólido com replicação parcial ou mista, ou dado de empresa não auditado | Use com instrumentação desde o dia 1 |
+| **FRACA** | Blogs, vendedores da própria solução, benchmarks sem metodologia auditável | Reporte com a ressalva explícita; não fundamente decisão |
+| **HIPÓTESE** | Raciocínio plausível sem evidência direta | Vira item do plano de teste, não do plano de produto |
+| **REFUTADO / NÃO REPLICA** | Efeito famoso que falhou em replicação com estímulos realistas | Não conte com ele |
+
+Duas heurísticas que tornam o rótulo operacional:
+
+- **Quando a evidência é fraca, o argumento real costuma ser outro e melhor.** Separe "o benchmark diz 12%" (FRACA) de "comprador ≠ lead, e há literatura sólida de sunk cost e pain of paying" (FORTE).
+- **Nomeie o estudo, o ano e o desenho** — "experimento de campo com catálogos", "n=13 mil autodeclarado", "dado de plataforma com ~115 mil apps". Sem isso o rótulo é decoração.
+
+Seções inteiras podem receber um rótulo de qualidade: *"Qualidade geral da evidência nesta seção: FRACA."*
+
+## 4. Regras de evidência
+
+- **Todo número tem fonte linkada e data.** Sem link, o número não entra.
+- Distinga sempre quatro naturezas: **dado verificado**, **projeção de terceiro**, **estimativa desta pesquisa** e **inferência estrutural**. Escreva assim: *"a triangulação bottom-up sugere R$ X — estimativa desta pesquisa, não dado."*
+- **Preferência revelada vence preferência declarada.** Preço efetivamente pago, taxa de abandono, pirataria, lista de espera, longevidade do produto no mercado valem mais que qualquer survey de intenção.
+- **Triangule.** Duas fontes independentes que convergem (idealmente por métodos diferentes) elevam a confiança; se divergem, a divergência é o achado e aparece no texto.
+- **Avaliação de fonte:** CRAAP (*Currency, Relevance, Authority, Accuracy, Purpose* — Blakeslee, CSU Chico, 2004) é o piso, e é insuficiente sozinho: checagem vertical dentro da própria página não basta (crítica de Wineburg / Stanford History Education Group). Complemente com **leitura lateral** — saia da página e verifique quem é a fonte por fora. Pergunte sempre: **quem se beneficia deste número?** Associação setorial infla mercado; vendedor de solução infla benchmark de conversão; agregador de cupons costuma estar desatualizado.
+- **Claim de vendedor não auditado** ("20 mil alunos", "98% de satisfação") é categoria própria: reporte como claim, com atribuição, nunca como fato.
+
+## 5. Como buscar
+
+**Ordem de valor das fontes:**
+
+1. Fonte primária do próprio player — página de preço, planos, changelog, central de ajuda, termos de uso.
+2. Dado oficial/estatal — órgãos oficiais, publicações governamentais, registros públicos.
+3. Censos e relatórios setoriais com metodologia declarada (registre n, método de amostragem e quem financiou).
+4. Imprensa de negócios com números atribuídos (aportes, receita, aquisições).
+5. Comunidades e reviews — para dor e sentimento, com verbatim e link. Reviews de 1 a 3 estrelas são ouro.
+6. Agregadores e blogs — último recurso, sempre com ⚠️.
+
+**Formulação:** consultas específicas em vez de genéricas ("preço plano [player] 2026", "[player] receita aporte"), no idioma do mercado-alvo **e** em inglês para analogias internacionais. Busque explicitamente o contrário da tese ("por que [categoria] não funciona", "reclamações [player]", "[método] crítica replicação"). Busque a **ausência**: se três consultas bem formuladas não acham um número, ele vira `[N]`.
+
+**Empirismo — sempre que for barato.** Existe endpoint? Chame. Existe arquivo público? Baixe e processe uma amostra real. Existe custo de processamento? Meça, em vez de estimar. Existe página de preço? Abra (e registre o 403 — o bloqueio é informação). Dá para rodar o pipeline inteiro em pequena escala por poucos reais? Rode. Custo típico: horas e centavos; retorno: uma coluna inteira de estimativas vira fato, e às vezes a conclusão se inverte.
+
+**Como citar:** link inline no ponto do dado, nunca bibliografia solta no fim; data de acesso no cabeçalho. Modelos de linguagem fabricam referências acadêmicas com frequência, e a maior parte das citações alucinadas é invenção total, não corrupção parcial — **nenhuma referência acadêmica entra sem que o título tenha sido conferido em busca**. Encontrar uma página que menciona um estudo não é o mesmo que confirmar o estudo. Se não foi possível abrir a fonte, o dado desce para ⚠️ ou vira `[N]`.
+
+## 6. Independência anti-ancoragem
+
+**Um documento cuja conclusão você já tem na cabeça não é pesquisa, é justificação.**
+
+- Cada pesquisa roda em contexto próprio. Isso não é economia de tokens — é isolamento de viés: um agente que acabou de escrever "o vazio de mercado está na faixa X" vai encontrar evidências de que a faixa X é ótima.
+- Não leia os outros documentos do dossiê, exceto as dependências declaradas explicitamente no seu brief.
+- Documento marcado como neutro declara no cabeçalho que não recomenda nada, e a declaração é auditável: recomendação no corpo invalida o documento.
+- Em pesquisa primária: randomize a ordem das perguntas, nunca revele limites ou expectativas, e pergunte por fatos específicos do passado em vez de hipóteses de futuro.
+
+## 7. Vieses e armadilhas, com mitigação
+
+### Vieses cognitivos
+
+| Viés | Como aparece | Mitigação |
+|---|---|---|
+| **Ancoragem** | Um preço, tamanho de mercado ou concorrente visto primeiro contamina todo o resto; âncoras arbitrárias deslocam disposição a pagar em ordens de magnitude | Pesquisa de preço independente e sem tese; ordem randomizada em surveys; nunca revelar limites; nas entrevistas, não dizer seu número |
+| **Confirmação** | Buscar e lembrar o que sustenta a ideia; ignorar o contrário | Buscar explicitamente a tese oposta; escrever "tensões documentadas" com evidência forte dos dois lados |
+| **Disponibilidade** | O concorrente mais anunciado vira "o mercado"; o caso lembrado vira frequência | Enumerar por categoria antes de aprofundar; buscar a cauda longa; contar, não lembrar |
+| **Sobrevivência** | Estudar só quem deu certo e concluir que a categoria funciona | Procurar ativamente os mortos — produtos descontinuados, pivôs, categorias que queimaram reputação — e o que os matou |
+| **Desejabilidade social** | O entrevistado elogia a ideia para ser gentil | Fatos do passado, nunca hipóteses; não apresentar a ideia antes; elogio não conta como sinal |
+| **Excesso de otimismo** | SOM de 10–20% chamado de "conservador"; CAC otimista; adoção rápida | Bottom-up obrigatório; reverse income statement; comparar com taxas reais da categoria |
+| **Enquadramento** | A forma da pergunta produz a resposta ("você pagaria R$ 30?") | Perguntas abertas primeiro; Van Westendorp em vez de "quanto pagaria"; medir comportamento |
+| **Custo afundado do próprio dossiê** | Depois de 40 páginas, é difícil concluir "não vale a pena" | Critérios de kill definidos antes; o dossiê pode terminar em "não" |
+
+### Armadilhas metodológicas
+
+| Armadilha | Sintoma | Mitigação |
+|---|---|---|
+| **Vanity TAM** | Número gigante de relatório setorial usado como mercado endereçável | TAM do beachhead, bottom-up, com premissas nomeadas |
+| **Média que esconde a distribuição** | "Gasto médio de R$ 2 mil/ano" quando 64% gastam menos de R$ 1,5 mil | Reportar a distribuição; a média de uma cauda longa é ficção |
+| **Unidade de contagem errada** | Inscrições confundidas com pessoas; contas com usuários; downloads com clientes | Declarar a unidade em toda cifra e nomear a diferença |
+| **Preço de tabela vs. praticado** | Descontos "de/por" permanentes tratados como promoção | Política declarada na nota de método; reportar o preço efetivamente cobrado |
+| **Feature-listing** | Matriz de concorrentes com 40 features e nenhuma conclusão | Matriz por capacidade da categoria (4–7 colunas) e coluna "onde para" |
+| **Claim de marketing como capacidade** | "IA adaptativa" marcada como Sim na matriz | Três níveis: verificado em uso / documentado publicamente / apenas alegado |
+| **Fonte bloqueada virando silêncio** | A comunidade mais importante estava bloqueada e o doc não menciona | Registrar o bloqueio na nota de método e agendar coleta manual |
+| **Conclusão sem teste** | "Vamos cobrar R$ X" derivado de leitura | Decisão em aberto + método empírico + métrica definida antes |
+| **Pesquisa que envelhece em silêncio** | Documento de 8 meses citado como atual | Data no cabeçalho, validade no rodapé, caveat cruzado no índice |
+| **Síntese que vira opinião** | O resumo executivo afirma mais do que as seções sustentam | O resumo só contém números que aparecem no corpo com fonte |
+| **Referência acadêmica alucinada** | Estudo citado com autor e ano que não existem | Conferir o título em busca antes de citar; sem confirmação, rebaixar ou remover |
+
+## 8. Portão de qualidade por documento
+
+Percorra item a item antes de entregar. O documento está pronto quando:
+
+- [ ] Tem data, escopo e resumo executivo que **decide sozinho**, com os números incluídos.
+- [ ] Tem nota de método com limitações declaradas e a legenda de confiança.
+- [ ] **Todo número tem fonte linkada e marca de confiança na própria linha.**
+- [ ] Estimativas próprias estão em itálico e rotuladas, distinguidas de dados de terceiros.
+- [ ] Tem a seção "o que foi procurado e NÃO encontrado", com o motivo de cada item.
+- [ ] Termina em tabela **achado → implicação**.
+- [ ] Não recomenda nada, se o cabeçalho o declarou neutro.
+- [ ] Não contém especificação de features, arquitetura, roadmap ou wireframe.

package/skills/ll-verificar-entrega/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: ll-verificar-entrega
+description: Auditoria de contexto limpo de uma entrega concluída — verificadores que nunca viram o raciocínio da implementação rodam os comandos de aceite da SPEC um a um, conferem cada decisão contra o código com arquivo:linha e confrontam o relatado com o real, produzindo VERIFICACAO.md com veredicto APROVADA / APROVADA COM RESSALVAS / REPROVADA. Use quando alguém pedir para verificar, auditar ou revisar uma entrega ou implementação concluída, conferir se o agente realmente terminou, validar se a SPEC foi implementada, checar marcos marcados como prontos ou revisar o trabalho de um agente autônomo longo.
+---
+
+# verificar-entrega
+
+Um implementador autônomo declarou pronto. Esta skill decide se está. Ela audita, nunca conserta: falha encontrada vira achado com evidência e, quando é estrutural, vira decisão nova para `ll-decidir-antes` — nunca patch silencioso desta sessão.
+
+**O relato do implementador é a ré, não a testemunha.** A primeira passada é cega ao `PROGRESS.md`, ao diário e a qualquer justificativa de quem implementou: os verificadores recebem apenas o `SPEC.md`, o repositório e o código entregue. Só depois de o veredicto independente estar formado é que o relato entra — e a divergência entre o relatado e o real é achado de primeira classe, não nota de rodapé. Isso existe porque o auto-relato de agentes degrada com o tempo de execução: em execuções longas, o "passes: true" é a afirmação menos confiável do repositório.
+
+Entregável: `docs/spec-<slug>/VERIFICACAO.md`, ao lado da spec auditada.
+
+## Fase 0 — Enquadramento
+
+Localize `SPEC.md` e `PROGRESS.md` (padrão: `docs/spec-*/`). Sem SPEC, vá para o modo degradado no fim deste arquivo.
+
+Numa única troca com o usuário, feche: **o que é a entrega** (todos os marcos ou um subconjunto) e **o recorte de código** (branch, range de commits, worktree). Delimite o range agora — `git log --oneline` e `git diff --stat` do recorte são insumo dos verificadores. Nada mais é perguntado até o veredicto.
+
+Leia o `SPEC.md` inteiro nesta sessão: §2 invariantes, §3 decisões, §4 critérios, §5 escopo negativo e pendências, §6 marcos com o estado `passes`, §7 protocolo. Você precisa dele para montar os briefs; os verificadores o leem por conta própria.
+
+Enquanto isso, **não abra o `PROGRESS.md` nem `decisoes/`**. Guarde-os para a fase 2 — ler o relato antes de ver o resultado ancora o veredicto exatamente no lugar que esta skill existe para evitar.
+
+## Fase 1 — Auditoria em camadas, em contexto limpo
+
+Delegue as três camadas a subagentes paralelos, cada um com contexto limpo. Leia `referencias/briefs-auditoria.md` agora: ele traz os três briefs prontos, o contrato de saída de cada um e o esqueleto do relatório. Roteamento: camada (a) é mecânica (Sonnet, esforço baixo); (b) é adversarial e é onde um defeito perdido vai para produção (Opus); (c) é varredura contra critérios explícitos (Sonnet).
+
+- **(a) Mecânica — os comandos.** Roda TODOS os comandos de verificação da §4 e da §6, um a um, literalmente como escritos, e registra exit code e saída real. Sem substituir comando por equivalente, sem inferir resultado. Marco com `passes: true` cujo comando falha é a violação mais grave do repositório.
+- **(b) Contrato — as decisões.** Cada DEC-NNN e ASS-NNN da §3 conferida contra o código com `arquivo:linha`: implementada, contornada, ou re-decidida silenciosamente? Invariantes MUST/NEVER da §2 varridos um a um. Escopo negativo da §5a: o que foi construído fora dele? Assunções escaladas quando a evidência as contradizia?
+- **(c) Integridade do processo.** O histórico do próprio contrato: critérios de aceite ou testes editados, afrouxados ou deletados durante a execução sem DEC-P correspondente; commits fora do padrão da §7; `decisoes/DEC-P-NNN.md` ainda `AGUARDANDO HUMANO` cuja pergunta o código respondeu sozinho.
+
+Regras que valem para as três camadas e vão em todo brief:
+
+- Cobertura total com rótulo, filtragem depois. Cada item da spec recebe um veredicto — **CONFORME**, **FALHA** ou **NÃO VERIFICÁVEL** — e o relatório lista os três. "Verificado e conforme", item a item, é resultado; "não encontrei nada" dito claramente também.
+- **NÃO VERIFICÁVEL** carrega o porquê e o que seria necessário (serviço no ar, credencial, fixture ausente, comando que não existe). Nunca vira CONFORME por plausibilidade.
+- Achado exige `arquivo:linha` ou saída de comando colada. Sem evidência, é hipótese — e hipótese entra como AVISO, marcada como tal.
+- Nenhum verificador edita código, testes, a spec ou o estado dos marcos.
+
+## Fase 2 — Confronto relato × real
+
+Com os três veredictos em mãos, só então abra `PROGRESS.md`, o diário e `decisoes/`. Confronte:
+
+- marcos declarados `passes: true` cujos comandos falharam ou não rodam;
+- diário afirmando verde em comando que o verificador viu vermelho;
+- decisões "two-way" registradas na §5b que na verdade contradizem uma decisão da §3 ou um invariante da §2;
+- pendências e DEC-P tratadas como resolvidas sem resposta do humano;
+- trabalho relatado sem contraparte no código, e código sem contraparte no relato.
+
+Cada divergência entra no relatório com as duas versões lado a lado: **relatado** (citação do PROGRESS.md) × **real** (evidência do verificador).
+
+## Fase 3 — Relatório e veredicto
+
+Escreva `docs/spec-<slug>/VERIFICACAO.md` no esqueleto de `referencias/briefs-auditoria.md`. Vocabulário fechado de severidade:
+
+| Rótulo | Significado |
+|---|---|
+| **BLOQUEIA ENTREGA** | comando de aceite falha, invariante violado, decisão da §3 contrariada, ou marco `passes: true` sem comando passando |
+| **DIVERGÊNCIA DE CONTRATO** | o entregue difere do combinado sem violar invariante: escopo extrapolado, decisão re-decidida com resultado defensável, critério editado, relato × real |
+| **AVISO** | risco observado, dívida, item NÃO VERIFICÁVEL, hipótese sem evidência dura |
+
+O veredicto global é mecânico, não julgamento: qualquer BLOQUEIA ENTREGA → **REPROVADA**; nenhum BLOQUEIA mas algum DIVERGÊNCIA ou NÃO VERIFICÁVEL → **APROVADA COM RESSALVAS**; todos os critérios e marcos CONFORME → **APROVADA**.
+
+Feche com a lista de pendências que realimenta `ll-decidir-antes`: cada falha estrutural — a que exige escolher de novo, não corrigir — vira uma decisão a ser tomada, com as opções e o custo de cada uma. Falha local (teste quebrado, bug pontual) fica como item de correção, sem virar decisão.
+
+Apresente ao usuário, em poucas linhas: o veredicto, a contagem por severidade, os BLOQUEIA ENTREGA nomeados, e as decisões que sobraram para ele — com a sugestão de rodar `ll-decidir-antes` sobre elas se houver mais de uma estrutural. Você entrega o relatório e para aqui.
+
+## Modo degradado — sem SPEC.md
+
+Sem contrato escrito, a verificação é mais fraca e isso é declarado, não disfarçado.
+
+Reconstrua a definição de pronto: extraia do pedido original, dos testes existentes e do README o que se pode inferir, e leve ao usuário numa única rodada de perguntas o que ficou ambíguo — critério que duas pessoas poderiam ler diferente não serve de oráculo. Registre os critérios reconstruídos no topo do `VERIFICACAO.md`, com a origem de cada um (inferido / confirmado pelo usuário), e a nota de que a auditoria vale contra eles e não contra um contrato acordado antes do código.
+
+Rode as camadas (a) e (b) contra esses critérios; a camada (c) cai — sem spec versionada não há integridade de processo a auditar. Feche sugerindo `ll-decidir-antes` para a próxima entrega, para que a verificação seguinte tenha um oráculo em vez de uma reconstrução.

package/skills/ll-verificar-entrega/referencias/briefs-auditoria.md

@@ -0,0 +1,291 @@
+# Briefs dos verificadores e esqueleto do relatório
+
+Leitor: o agente da skill `ll-verificar-entrega`, na fase 1. Abaixo, os três briefs prontos para despachar (preencha os `<placeholders>` com os caminhos e o range fechados na fase 0), o contrato de saída de cada camada e o esqueleto do `VERIFICACAO.md`.
+
+Os verificadores não veem a conversa nem uns aos outros: cada brief é autossuficiente. Despache os três em paralelo, numa única mensagem.
+
+---
+
+## Bloco comum — cole em todo brief
+
+<regras-comuns>
+Você audita, não conserta. Nenhuma edição de código, teste, spec ou estado de marco;
+nenhum commit. Encontrou defeito: reporte com evidência e siga.
+
+Você NÃO abre `PROGRESS.md`, o diário de execução, `decisoes/` nem mensagens de
+commit como justificativa. O relato de quem implementou não é insumo do seu
+veredicto — quem confronta relato com realidade é a sessão que te despachou, depois
+de receber o seu resultado. Suas fontes são o SPEC.md, o repositório e o que os
+comandos devolvem.
+
+Cobertura completa, com rótulo — a filtragem é feita depois de você. Todo item do
+seu escopo recebe um veredicto:
+- CONFORME — evidência de que está como a spec exige.
+- FALHA — evidência de que não está.
+- NÃO VERIFICÁVEL — você não conseguiu decidir. Diga o porquê e o que seria
+  necessário (serviço no ar, credencial, fixture, comando inexistente). Nunca
+  promova a CONFORME por plausibilidade.
+
+Todo achado carrega evidência dura: `arquivo:linha` ou a saída do comando colada.
+Sem evidência dura é hipótese — reporte assim mesmo, rotulada `hipótese`.
+"Verifiquei e está conforme", item a item, é resultado válido; um relatório sem
+falhas é um resultado, não um fracasso seu.
+</regras-comuns>
+
+---
+
+## Camada (a) — mecânica: os comandos
+
+Modelo: Sonnet, esforço baixo. É execução literal e transcrição fiel.
+
+<brief-mecanica>
+Você é o verificador mecânico de uma entrega de software. Roda os comandos de
+verificação que o contrato de entrega define e registra o que eles realmente
+devolvem.
+
+Contexto: um agente autônomo implementou `<caminho>/SPEC.md` ao longo de dias e
+declarou a entrega pronta. O auto-relato desse tipo de execução degrada com o
+tempo, então nada é aceito por declaração. Seu resultado é a base factual de uma
+auditoria que decide se a entrega é aprovada.
+
+Dados:
+- Contrato: `<caminho>/SPEC.md` — leia a §4 (critérios de aceite) e a §6 (marcos)
+  na íntegra; a §7 traz o comando de sanidade.
+- Repositório: `<raiz do repo>`, recorte `<branch/range>`.
+
+Instruções:
+1. Rode o comando de sanidade da §7 primeiro e registre o baseline.
+2. Rode TODOS os comandos de verificação da §4 e da §6, um a um, na ordem em que
+   aparecem, exatamente como escritos. Comando que não roda como escrito é
+   NÃO VERIFICÁVEL com o motivo — não o substitua por equivalente, não o ajuste,
+   não o divida.
+3. Para cada comando registre: o comando literal, o exit code, e as linhas da
+   saída que sustentam o veredicto (o resumo de testes, o status HTTP, a mensagem
+   de erro). Comando que falha é repetido uma vez, para separar instabilidade de
+   falha real; os dois resultados entram.
+4. Confronte o resultado com o campo `passes` de cada marco da §6, lido como está
+   escrito no arquivo. Marco `passes: true` cujo comando não passa nesta execução
+   é o achado de maior severidade que existe: nomeie-o explicitamente.
+
+Contrato de saída (markdown, nesta ordem):
+- `## Sanidade` — comando, exit code, veredicto.
+- `## Critérios (§4)` — tabela: ID | comando literal | exit code | evidência (≤2
+  linhas da saída) | CONFORME/FALHA/NÃO VERIFICÁVEL.
+- `## Marcos (§6)` — tabela: marco | passes declarado | comandos | resultado real
+  | CONFORME/FALHA/NÃO VERIFICÁVEL.
+- `## Marcos declarados prontos que não passam` — lista, ou "nenhum".
+- `## Ambiente` — o que precisou existir para os comandos rodarem e o que faltou.
+
+Limites: não escreva nem edite arquivo algum do repositório; não instale
+dependências nem suba serviços além do que a §7 prescreve como sanidade — o que
+faltar vira NÃO VERIFICÁVEL com o requisito nomeado.
+
+Critérios de sucesso: todo comando das §4 e §6 aparece na sua saída com exit code
+real; nenhum veredicto vem de leitura de código no lugar de execução.
+
+<regras-comuns aqui>
+</brief-mecanica>
+
+---
+
+## Camada (b) — contrato: as decisões e os invariantes
+
+Modelo: Opus. É a camada adversarial, onde um defeito perdido vai para produção.
+
+<brief-contrato>
+Você é o verificador de contrato de uma entrega de software. Confere, decisão por
+decisão, se o código entregue é o que foi acordado — e nomeia onde ele divergiu.
+
+Contexto: antes do código, o dono do projeto e um agente fecharam um contrato de
+decisões (`SPEC.md`, §2 invariantes e §3 decisões). Um implementador autônomo
+rodou por dias com essa spec como única fonte. O modo de falha conhecido dessas
+execuções é o implementador re-decidir sob atrito — encontra resistência no
+código, escolhe outro caminho e segue sem escalar. Seu trabalho é achar essas
+re-decisões silenciosas, que passam despercebidas justamente porque o código
+funciona.
+
+Dados:
+- Contrato: `<caminho>/SPEC.md` — §2 (invariantes MUST/NEVER), §3 (decisões
+  DEC-NNN e assunções ASS-NNN, cada uma com escolha, porquê, alternativa rejeitada
+  e entregáveis nomeados), §5a (escopo negativo).
+- Repositório: `<raiz do repo>`, recorte `<branch/range>`. Use
+  `git diff --stat <range>` para ver o que a entrega tocou.
+
+Instruções:
+1. Para cada DEC-NNN e ASS-NNN da §3: abra os entregáveis que ela nomeia e
+   classifique com `arquivo:linha` — IMPLEMENTADA (o código faz o que a decisão
+   escolheu); CONTORNADA (o código atende à letra mas frustra o porquê declarado);
+   RE-DECIDIDA (o código faz outra coisa, em geral a alternativa rejeitada);
+   AUSENTE (o entregável não existe). Decisão marcada CONTRA A RECOMENDAÇÃO do
+   dono é conferida com o mesmo rigor: o risco aceito não é seu para revisar.
+2. Para cada invariante da §2: procure violações no recorte inteiro, não só nos
+   entregáveis. Invariante NEVER exige varredura ativa (grep pelo que é proibido),
+   não leitura passiva.
+3. Escopo negativo (§5a): o que foi construído que a spec mandou não construir?
+   Cite `arquivo:linha`.
+4. Assunções ASS-NNN: cada uma declara "escalar se <condição>". A condição
+   ocorreu? Se ocorreu e a assunção seguiu em pé sem escalada, é achado.
+5. Liberdades da §5b: decisões tomadas dentro delas são legítimas — verifique
+   apenas que ficaram dentro, sem invadir a §3.
+
+Contrato de saída (markdown):
+- `## Decisões (§3)` — uma entrada por DEC/ASS: ID | classificação | evidência
+  `arquivo:linha` | o que o código faz, em uma frase | CONFORME/FALHA/NÃO
+  VERIFICÁVEL.
+- `## Invariantes (§2)` — um por linha: ID | como varreu (comando/grep) | achados
+  com `arquivo:linha` | veredicto.
+- `## Escopo negativo (§5a)` — construído fora do escopo, com evidência, ou
+  "nada encontrado".
+- `## Assunções que deveriam ter sido escaladas` — lista, ou "nenhuma".
+- `## Hipóteses` — suspeitas sem evidência dura, rotuladas.
+
+Limites: você não julga se a decisão foi boa — julga se foi cumprida. Não proponha
+refatoração, não corrija código, não edite a spec.
+
+Critérios de sucesso: toda DEC-NNN, ASS-NNN e todo invariante da spec aparecem na
+sua saída com veredicto e evidência; nenhuma entrada fica sem `arquivo:linha` ou
+sem um motivo explícito de NÃO VERIFICÁVEL.
+
+<regras-comuns aqui>
+</brief-contrato>
+
+---
+
+## Camada (c) — integridade do processo
+
+Modelo: Sonnet. Varredura contra critérios explícitos, sobre o histórico do repo.
+
+<brief-integridade>
+Você audita a integridade do processo de uma entrega de software: se o contrato
+que está sendo verificado hoje é o mesmo que foi acordado antes do código.
+
+Contexto: a spec `<caminho>/SPEC.md` é append-only depois de aprovada, e os
+critérios de aceite e testes dela são intocáveis pelo implementador (invariante
+I-02 típico): critério errado é motivo de escalada, nunca de edição. A ambiguidade
+que aparece em voo vira um arquivo `decisoes/DEC-P-NNN.md` com status AGUARDANDO
+HUMANO. O modo de falha que você procura é o oráculo mutilado — o implementador
+que afrouxou o teste, editou o critério ou respondeu sozinho a própria pergunta e
+seguiu.
+
+Dados:
+- `<caminho>/SPEC.md` e o histórico dele: `git log -p --follow -- <caminho>/SPEC.md`.
+- `<caminho>/decisoes/` (os arquivos DEC-P, se existirem).
+- Repositório `<raiz do repo>`, recorte `<branch/range>`; §7 do SPEC.md traz o
+  protocolo de execução com as regras de commit e escalada.
+
+Instruções:
+1. Histórico da spec após a aprovação: toda mudança que não seja acréscimo
+   append-only (entrada nova, supersede explícito, `passes: false` → `true`) é
+   achado. Critério de aceite reescrito, comando de verificação afrouxado, marco
+   removido: cite o commit e o diff.
+2. Testes e fixtures no recorte: procure teste deletado, `skip`/`only`/`xfail`
+   adicionado, asserção afrouxada, timeout inflado, mock que substituiu integração
+   real. Compare com o baseline do início do recorte. Cite `arquivo:linha` e o
+   commit.
+3. `decisoes/DEC-P-NNN.md`: para cada um com status AGUARDANDO HUMANO, procure no
+   código se a pergunta foi respondida na prática. Pergunta aberta implementada é
+   achado — decisão one-way tomada em silêncio.
+4. Pendências da §5c: cada uma tem dono e marco. As de dono "humano" foram
+   tratadas como resolvidas sem resposta? As de dono "implementador" foram
+   cumpridas (por exemplo, promovidas a critério com comando)?
+5. Commits do recorte contra a §7: unidades pequenas e descritivas, ou um despejo
+   final? Houve force push, rebase que reescreveu histórico, migração destrutiva
+   ou ação irreversível que nenhum marco autorizava?
+
+Contrato de saída (markdown):
+- `## Mudanças na spec após aprovação` — commit | trecho | append-only? | veredicto.
+- `## Oráculo mutilado` — testes/critérios enfraquecidos, com `arquivo:linha` e
+  commit, ou "nada encontrado".
+- `## DEC-P e pendências` — ID | status declarado | o que o código mostra |
+  veredicto.
+- `## Higiene de commits e ações irreversíveis` — achados com hash, ou
+  "conforme a §7".
+
+Limites: não reverta nada, não recrie testes deletados, não edite a spec. Você
+descreve o que aconteceu com o contrato, com o commit como prova.
+
+Critérios de sucesso: cada uma das cinco frentes acima aparece na saída, com
+achados citando commit e `arquivo:linha` ou com um "nada encontrado" explícito.
+
+<regras-comuns aqui>
+</brief-integridade>
+
+---
+
+## Esqueleto do VERIFICACAO.md
+
+Escrito pela sessão principal na fase 3, a partir dos três resultados e do
+confronto da fase 2. Ordem fixa: o veredicto primeiro — é o que o usuário lê.
+
+<template>
+# VERIFICAÇÃO — <nome da spec> — <data>
+
+**Veredicto: <APROVADA | APROVADA COM RESSALVAS | REPROVADA>**
+
+Auditado: `<caminho>/SPEC.md` · recorte `<branch/range>` · <N> commits.
+Camadas: mecânica, contrato, integridade — todas em contexto limpo, sem acesso ao
+PROGRESS.md na formação do veredicto.
+
+| Severidade | Qtd |
+|---|---|
+| BLOQUEIA ENTREGA | <n> |
+| DIVERGÊNCIA DE CONTRATO | <n> |
+| AVISO | <n> |
+
+Critérios: <n> CONFORME · <n> FALHA · <n> NÃO VERIFICÁVEL.
+Em uma frase: <o que a entrega faz de fato e o que falta para estar pronta>.
+
+## 1. Critérios de aceite
+
+| ID | Comando | Saída real | Veredicto |
+|---|---|---|---|
+| CA-03 | `npm test -- import.spec.ts -t "linha inválida"` | exit 1 — `2 failing: expected 401, got 500` | FALHA |
+| CA-07 | `curl -s -o /dev/null -w "%{http_code}" localhost:3000/api/v1/reports` | `401` | CONFORME |
+
+## 2. Marcos
+
+| Marco | passes declarado | Verificação real | Veredicto |
+|---|---|---|---|
+| M2 — Categorização | true | `npm test -- categorize.spec.ts` → exit 1 | FALHA |
+
+## 3. Achados
+
+Um bloco por achado, do mais grave ao menos:
+
+### A-01 · BLOQUEIA ENTREGA · M2 marcado pronto com suíte vermelha
+- Evidência: `npm test -- categorize.spec.ts` → exit 1, `3 failing`
+  (`src/import/categorize.ts:44`).
+- Contrato ferido: §6 M2; §7 item 5 (`passes: true` só com comando passando).
+- Consequência: o marco seguinte foi construído sobre base vermelha.
+
+### A-02 · DIVERGÊNCIA DE CONTRATO · DEC-004 re-decidida
+- Evidência: `src/services/contact-identity.ts:120` normaliza in place.
+- Contrato ferido: DEC-004 escolheu coluna canônica ao lado; in place é a
+  alternativa rejeitada, pela trilha de auditoria.
+- Consequência: <o que quebra ou fica em risco>.
+
+## 4. Relatado × real
+
+| Relatado no PROGRESS.md | Real | Severidade |
+|---|---|---|
+| "M2: `categorize.spec.ts` verde; passes: true" (2026-08-22) | exit 1, 3 failing | BLOQUEIA ENTREGA |
+
+## 5. Não verificável
+
+| Item | Por que | O que seria necessário |
+|---|---|---|
+| CA-09 | serviço de e-mail não sobe no ambiente | credencial SMTP de sandbox ou fixture de fila |
+
+## 6. Conforme
+
+Lista enxuta do que foi verificado e está de acordo — critérios, invariantes,
+decisões, escopo negativo. Item a item, sem prosa.
+
+## 7. Pendências
+
+**Decisões para o dono** (realimentam `ll-decidir-antes` — escolha, não correção):
+- D-01 — <a pergunta em uma linha>. Opções: A) <custo> B) <custo>. Origem: A-02.
+
+**Correções** (falhas locais, sem decisão nova):
+- C-01 — <o que corrigir>. Origem: A-01.
+</template>