GOAL: {verbo + resultado observável + cenário que importa}.
      (ex.: "Adicionar flag --json ao parser, cobrindo input vazio e input malformado"
       — nunca "melhorar o parser")

CONTEXT: Trabalhe em {arquivo(s)/diretório exatos}.
         Leia ANTES de editar: {arquivo-exemplo} — siga esse padrão.
         {se houver: erro/log/spec relevante, colado ou referenciado}

CONSTRAINTS:
- Não altere {API pública / schema / arquivos fora do escopo}.
- Não adicione dependências além das já usadas no projeto.
- Trate a causa raiz — não suprima erro, não desative teste para passar.
- {constraint específica do seu domínio}

DONE WHEN:
- {comando exato: npm test / pytest tests/x -v / npm run build} sai com exit 0.
- Rode o check e ME MOSTRE A SAÍDA — saída colada, não "feito".

GOAL: Corrigir o bug: {sintoma específico — o que acontece, quando, para quem}.

CONTEXT: Erro exato (não resuma, use isto):
{cole o erro/stack trace completo}
Onde olhar primeiro: {diretório/módulo}, especialmente {função/fluxo}.
Como reproduzir: {passos ou comando}.

CONSTRAINTS:
- Corrija a CAUSA RAIZ. Proibido: suprimir o erro, capturar exceção genérica,
  ajustar o teste para passar, adicionar retry que mascara o problema.
- Mudança mínima: não refatore nada além do necessário para o fix.

DONE WHEN:
1. Existe um teste novo que FALHAVA antes do fix (mostre-o falhando).
2. O teste passa após o fix.
3. {suite completa: comando exato} sai com exit 0 — nenhum outro teste quebrou.
Cole o output dos 3 passos como evidência.

SESSÃO 1 (spec — só conversa, nenhum código):
Quero construir {descrição breve}. Me entreviste em detalhe.
Pergunte sobre implementação técnica, UX, edge cases, riscos e tradeoffs.
Não pergunte o óbvio — cave nas partes difíceis que eu posso não ter considerado.
Continue até cobrirmos tudo, depois escreva a spec completa em SPEC.md contendo:
- Objetivos E não-objetivos (o que está explicitamente FORA de escopo)
- Requisitos funcionais + constraints (libs proibidas, padrões a manter)
- Arquivos e interfaces envolvidos (a spec deve ser autocontida:
  quem ler SÓ a spec consegue implementar)
- Exemplos concretos de input/output
- Critérios de aceite: 1 por linha, cada um verificável por teste ou comando
- Verificação end-to-end final que PROVA que a feature funciona

SESSÃO 2 (execução — sessão NOVA, contexto limpo):
Leia SPEC.md POR INTEIRO antes de qualquer edição.
Implemente exatamente o que está na spec — nada além (não-objetivos são vetos).
DONE WHEN: todos os critérios de aceite passam + a verificação end-to-end
da spec executa com sucesso. Rode e cole o output de cada critério.

/goal {ação no codebase}. {Condição de término: comando exato + exit code ou threshold}.

/goal Migrar src/ de JavaScript para TypeScript. `npx tsc --noEmit --strict` sai com exit 0 e o diff não contém nenhum `any` explícito.

/goal Eliminar os warnings de lint. `npm run lint` sai com exit 0.

/goal Subir a cobertura de payments/ para >= 80%. `npm run coverage` reporta >= 80% no módulo e todos os testes passam.

Use um subagente (ou sessão nova) para revisar o diff de {feature} contra {SPEC.md / plano / critérios}.
O revisor deve verificar:
- todo requisito listado está implementado (cite requisito → arquivo:linha que o cumpre)
- os edge cases listados têm teste correspondente
- nada FORA do escopo declarado mudou (liste qualquer arquivo tocado que a spec não prevê)
Reporte GAPS DE CORREÇÃO, não preferências de estilo.
Sinalize apenas o que afeta correção ou os requisitos declarados — gap apontado
sem requisito correspondente será descartado.
Formato do veredito: APROVADO ou lista numerada de gaps com requisito + evidência.

/goal {condição binária verificável: comando + exit/threshold}. Trabalhe item a item em {fonte dos itens: lista/diretório/arquivo}: conclua e verifique UM item antes de começar o próximo. Constraints: {o que não tocar}; causa raiz sempre, nunca suprimir erro. Se travar num item: registre o bloqueio em {progress.txt} com o motivo, PULE para o próximo e liste os bloqueios no final — não invente solução, não declare concluído com bloqueio aberto.

/goal `npm test` sai com exit 0 em todos os arquivos de tests/legacy/ e nenhum teste está marcado como skip. Trabalhe arquivo por arquivo: corrija, rode o teste do arquivo, só então avance. Constraints: não altere o código de produção em src/core/; causa raiz sempre. Se um teste depender de serviço externo indisponível: registre em progress.txt, pule, e liste no final — não marque skip para passar.

/loop {intervalo: 5m / 30m / 1h} {prompt idempotente e autossuficiente, com os 3 ramos: estado-bom / estado-ruim / não-sei}

/loop 10m Verifique o status do CI no branch {branch} via `gh run list --branch {branch} -L 1`. Se o último run FALHOU: leia o log com `gh run view --log-failed`, corrija a causa raiz, commite e push. Se PASSOU: responda só "verde" e nada mais. Se o comando falhar ou o estado for ambíguo: reporte o que viu e NÃO aja.

/loop 1h Rode {validador: comando exato}. Se exit != 0: corrija as violações apontadas e commite com mensagem "fix: {escopo}". Se exit 0: não faça NADA (nenhum commit, nenhuma melhoria espontânea).

/loop Processe o PRÓXIMO item pendente de {arquivo de backlog: tasks.yaml / prd.json}.
UNIDADE: 1 item = {defina exatamente o que conta como 1 item — ex.: "1 story do prd.json com passes:false"}.
Por ciclo: implemente o item, rode {checks: comando exato}, e SÓ com exit 0 commite ({formato: feat: [ID] - título}) e marque o item como concluído no arquivo.
Item grande demais para 1 ciclo: quebre-o em sub-itens NO PRÓPRIO arquivo de backlog e conclua só o primeiro.
Item bloqueado: marque "blocked: {motivo}" no arquivo e siga para o próximo.
Encerre o loop quando não houver itens pendentes nem desbloqueáveis — diga quantos ficaram blocked.

## Gate de conclusão (obrigatório)
Antes de declarar conclusão:
1. Rode: {comando literal do validador — ex.: node scripts/validate-x.cjs --file out.yaml}
2. Critério: {exit 0 / score >= N / 0 erros — o número exato}.
3. Se o critério falhar: corrija e repita. Você NÃO está autorizado a concluir
   com o gate falhando, nem a relaxar o critério, nem a editar o validador.
4. Somente com o gate passando: cole o OUTPUT COMPLETO do comando e então declare concluído.
A sua avaliação de "parece pronto" não substitui o gate. Evidência, não asserção.