prompts-unificando 1.1.0 → 1.2.0

package/README.md

@@ -26,6 +26,10 @@ npx prompts-unificando get <id> --copy
 | `fullstack` | Next.js full-stack — integração front-back, validação e segurança end-to-end, performance | Sim |
 | `backend` | NestJS — arquitetura, banco de dados, segurança OWASP, escalabilidade, documentação de API | Sim |
 | `testes` | Cobertura de testes real, qualquer stack — mapeamento de regras de negócio, reconciliação de testes existentes | Sim (gera testes) |
+| `setup-e2e` | Bootstrap de stack E2E (Playwright) — instalação, configuração, estrutura de pastas (e2e/, e2e/pages/, e2e/fixtures/) e smoke test inicial | Sim |
+| `auditoria-testid` | Auditoria/aplicação de `data-testid` — convenção única e seletor estável em todo o app | Sim (aditivo) |
+| `testes-e2e` | Geração/expansão disciplinada da suíte E2E — elegibilidade, jornadas (happy path + falha obrigatória), reconciliação e anti-flakiness | Sim (gera specs) |
+| `ci-e2e` | Pipeline CI para a suíte E2E existente — estratégia de execução, cache, artefatos de falha | Não — patch proposto |
 | `auditoria-engenharia` | Diagnóstico de qualidade de código (SOLID, código morto, dependências não usadas) | Não — somente leitura |
 | `auditoria-seguranca` | Segurança (OWASP), conformidade LGPD e checklist de deploy | Não — somente leitura |
 | `revisao-copy` | Ortografia, gramática e UX copy voltados ao usuário final | Só texto, nunca lógica |
@@ -40,6 +44,7 @@ npx prompts-unificando get <id> --copy
 - **Next.js com API Routes no mesmo repositório?** Use `fullstack` (e `frontend` se quiser focar só na camada visual).
 - **Backend NestJS em repositório separado?** Use `backend`.
 - **Já refatorou e quer cobertura de testes real?** Use `testes` — rode por último, depois da arquitetura estabilizar.
+- **Quer uma cadeia completa de testes E2E?** Rode em ordem: `setup-e2e` (bootstrap, só projeto sem stack E2E) → `auditoria-testid` (seletor estável) → `testes-e2e` (specs consistentes) → `ci-e2e` (pipeline no CI).
 - **Gerou ou revisou copy com IA?** Use `revisao-copy` a qualquer momento.
 - **Quer que o agente execute a refatoração sozinho, com gates e rollback por fase, em vez de só sugerir?** Use `refatoracao-faseada` — cobre código morto, duplicação, arquitetura, integração, segurança, performance, erros, a11y/SEO e testes em um único pipeline autônomo.
 - **Quer um raio-x de SEO técnico e de conteúdo antes de lançar ou depois de uma migração?** Use `seo` — read-only, com plano de ação priorizado.
@@ -56,7 +61,10 @@ npx prompts-unificando get <id> --copy
 3. Testes
    testes — depois que a arquitetura estiver estável
 
-4. Copy
+4. E2E (opcional, depois da suíte unit/integration estável)
+   setup-e2e → auditoria-testid → testes-e2e → ci-e2e
+
+5. Copy
    revisao-copy — a qualquer momento após gerar conteúdo com IA
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prompts-unificando",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Biblioteca de prompts padronizados para auditoria, refatoração, testes, segurança/LGPD e revisão de copy, agnóstica de stack e de LLM.",
   "bin": {
     "prompts-unificando": "bin/cli.js"

package/prompts/auditoria-seguranca.md

@@ -5,7 +5,7 @@
 
 ## 📋 Índice de Execução
 1. **Auto-detecção de Contexto (Stack, Auth, Infra, Dados Pessoais)**
-2. **Gate de Confirmação de Aplicabilidade (38 itens)**
+2. **Gate de Aplicabilidade (38 itens) — resumo e prosseguimento automático**
 3. **Verificação Detalhada de Conformidade por Bloco**
 4. **Regras Anti-Falso-Positivo**
 5. **Relatório Final por Severidade**
@@ -27,7 +27,7 @@ Diferente do Doc 5 (auditoria de qualidade de código — SOLID/DRY/código mort
 
 **Auditoria de Segurança, LGPD & Deploy:**
 - 🔍 Auto-detecção de stack, mecanismo de auth real, e se o projeto lida com dados pessoais
-- 🚦 Gate de aplicabilidade — pausa antes de avaliar item por item (evita retrabalho)
+- 🚦 Gate de aplicabilidade — resume o que é aplicável antes de avaliar item por item e segue direto (evita retrabalho sem pausar a execução)
 - 🛡️ Segurança Front-End & Back-End (critério OWASP ASVS/Top 10/CWE)
 - ⚖️ LGPD específico (critério de conformidade regulatória, não só boa prática)
 - 🚀 Checklist de Deploy (DevOps/SRE — inclui itens fora do repositório)
@@ -74,7 +74,7 @@ implementado" só porque não aparecem no código. Devem ser classificados como
 repositório", com uma nota indicando onde essa verificação precisaria ocorrer (painel do provedor,
 configuração de infra, etc.).
 
-ETAPA 0.5 — GATE DE CONFIRMAÇÃO DE APLICABILIDADE (OBRIGATÓRIO, PAUSA ANTES DE AVANÇAR)
+ETAPA 0.5 — GATE DE APLICABILIDADE (OBRIGATÓRIO, RESUMO SEM PAUSAR A EXECUÇÃO)
 Após a Etapa 0, apresente uma tabela resumida de aplicabilidade para os 38 itens do checklist (todas
 as 4 categorias), com três colunas:
 
@@ -85,9 +85,11 @@ Critérios de "Não aplicável" (exemplos, não exaustivo):
 - Item de CDN/DDoS se não há evidência de camada de CDN no projeto
 - Item de cookie banner se o projeto não coleta dados pessoais nem usa cookies de rastreamento
 
-Pause aqui e aguarde confirmação explícita antes de prosseguir para a verificação detalhada de
-conformidade (Etapa 1). Isso evita retrabalho caso a auto-detecção da Etapa 0 tenha classificado
-algo incorretamente como aplicável/não aplicável.
+Registre essa tabela no relatório e prossiga automaticamente para a verificação detalhada de
+conformidade (Etapa 1), sem pedir autorização — a execução já foi solicitada ao rodar este prompt.
+Solicite intervenção humana apenas se um item "Incerto" tiver impacto tão grande na classificação
+dos demais que prosseguir sem esclarecer geraria retrabalho real (ex: não dá para saber se há
+camada de auth alguma).
 
 ETAPA 1 — VERIFICAÇÃO DETALHADA DE CONFORMIDADE
 Para cada item marcado como "Aplicável" ou "Incerto" na Etapa 0.5, verifique:
@@ -140,7 +142,8 @@ REGRAS NÃO-NEGOCIÁVEIS
 - Terminologia agnóstica de ferramenta específica — descreva o problema e a solução em termos
   técnicos gerais, não amarrados a uma stack específica, exceto quando a auto-detecção da Etapa 0
   identificar a stack real do projeto (nesse caso, use os termos exatos da stack detectada).
-- Pausar na Etapa 0.5 e aguardar confirmação antes de gerar o relatório completo.
+- Registrar a tabela da Etapa 0.5 no relatório e seguir direto para a verificação completa, sem
+  pausar para aprovação — a autonomia já foi concedida ao executar este prompt.
 - Nunca gerar ou sugerir patch de código pronto para aplicar automaticamente — apenas descrição
   textual da correção.
 

package/prompts/auditoria-testid.md

@@ -0,0 +1,157 @@
+# 🎯 Prompt de Auditoria e Aplicação de data-testid
+**Versão: 10/10 | Engenheiro Front-end Especializado em Testabilidade | Agnóstico de Stack | Engenharia de Prompt Aplicada**
+
+---
+
+## 📋 Índice de Execução
+1. Leitura Autônoma do Projeto Front-end
+2. Plano de Fases (Apps Grandes)
+3. Detecção/Definição de Convenção de Nomenclatura
+4. Varredura e Aplicação
+5. Relatório Final (`testid-changes-report.md`)
+
+---
+
+## ✅ PROMPT: AUDITORIA E APLICAÇÃO DE data-testid
+
+### 📖 O QUE ESTE PROMPT FAZ:
+Faz uma coisa só, até o fim: varre todo o código-fonte de frontend, garante que todo elemento relevante pra teste tenha `data-testid` consistente, e aplica isso direto no código. Não gera teste, não mapeia jornada, não decide elegibilidade de fluxo — isso é escopo de outro prompt da biblioteca. Separar isso permite ao modelo dedicar atenção total à exaustividade da varredura, sem competir com regra de asserção, gate de reconciliação de spec, etc.
+
+**Quando usar:** como pré-requisito antes do `testes-e2e` (que consome o `testid-changes-report.md` gerado aqui como entrada), ou isoladamente sempre que quiser melhorar a testabilidade do app sem necessariamente gerar teste agora.
+
+**⚠️ Exceção explícita à regra de read-only da biblioteca (risco aceito por você):** este prompt escreve direto no código-fonte — só o atributo `data-testid` (ou rename pra alinhar convenção), nada além disso — sem parar pra confirmação. A rastreabilidade fica inteira no relatório final, pra revisão antes do commit manual.
+
+---
+
+### 🎯 PROMPT (EXECUTE ISTO):
+
+```
+Você é um engenheiro front-end especializado em testabilidade. Seu único objetivo nesta execução é
+garantir que todo elemento relevante pra teste E2E tenha um data-testid estável e consistente — nada
+além disso. Não gere teste, não avalie jornada de usuário, não opine sobre cobertura.
+
+Este prompt é agnóstico de stack front-end: adapte-se ao framework já usado no projeto (React, Vue,
+Angular, Svelte etc).
+
+ETAPA 0: LEITURA AUTÔNOMA DO PROJETO FRONT-END
+Antes de qualquer coisa, escaneie o projeto:
+- Identifique a stack front-end e a estrutura de pastas de componentes/páginas/layouts
+- Identifique se já existe convenção de data-testid em uso (mesmo que parcial e inconsistente)
+- Ignore diretórios irrelevantes (dependências, build, cache, storybook de terceiros se aplicável)
+Você não pede pra colar código. Você lê o projeto diretamente.
+
+ETAPA 0.5: PLANO DE FASES (SOMENTE APPS GRANDES)
+Depois de escanear, avalie o tamanho do escopo. Considere "app grande" quando pelo menos um destes
+critérios for verdadeiro:
+- Mais de ~5 diretórios de componentes/páginas distintos
+- Múltiplos domínios/módulos de UI claramente separados (ex: auth/, checkout/, dashboard/)
+- Foi pedido explicitamente pra tratar como app grande
+
+Se for app grande, NÃO varra tudo de uma vez:
+
+0.5.1 — Crie o Plano de Fases
+Gere um arquivo testid-plan.md dividindo o trabalho em fases lógicas (por domínio/pasta). Formato:
+
+# Testid Plan — [Nome do Projeto/Escopo]
+## Status Geral
+- Fases totais: [N] | Concluídas: [N] | Em andamento: [Fase atual] | Pendentes: [N]
+---
+## Fase 1 — [Nome do Domínio/Pasta]
+Status: Pendente
+Escopo: [componentes/páginas incluídos]
+### Artefatos desta fase (preenchido ao concluir)
+- Elementos com testid aplicado/renomeado: [contagem]
+- Pendências de revisão: [contagem]
+---
+## Fase 2 — ... (repete o padrão)
+
+0.5.2 — Execução Sequencial e Autônoma Entre Fases
+Execute fase a fase sem parar pra confirmação entre elas. Ao concluir uma fase, atualize o
+testid-plan.md e siga direto pra próxima. Só pare/retome a conversa quando TODAS as fases estiverem
+concluídas, apresentando o testid-changes-report.md consolidado.
+
+0.5.3 — Única Exceção Que Justifica Parar no Meio
+Interrompa somente diante de um bloqueio objetivo que nenhuma suposição razoável resolve (ex: conflito
+de nome de testid entre dois elementos que exigiria decisão de produto, não técnica).
+
+ETAPA 1: DETECÇÃO/DEFINIÇÃO DE CONVENÇÃO DE NOMENCLATURA
+- Se já existir um padrão consistente nos testid atuais (ex: kebab-case por contexto+elemento+ação —
+  "login-submit-button", "cart-item-remove"), siga exatamente esse padrão.
+- Se não existir nenhum padrão ainda, defina um (contexto + elemento + ação, kebab-case) e documente
+  a decisão no relatório. Aplique o mesmo padrão em tudo — nunca mistura convenção diferente por
+  arquivo ou por fase.
+
+ETAPA 2: VARREDURA E APLICAÇÃO (POR FASE, SE APLICÁVEL)
+- Identifique elementos interativos ou relevantes pra asserção (botões, inputs, links, mensagens de
+  erro/sucesso, itens de lista dinâmica, modais) que ainda não têm data-testid.
+- Aplique o atributo diretamente no arquivo de origem. A alteração é estritamente aditiva: adiciona o
+  atributo, não muda markup, lógica, estilo, texto, ordem de props ou qualquer outra coisa no
+  componente.
+- Se o elemento já tem data-testid mas fora do padrão detectado/definido na Etapa 1, renomeie pra
+  alinhar — também registrado no relatório.
+- Roda direto, sem parar pra confirmação — mas cada alteração é registrada com arquivo + linha +
+  testid aplicado (ou renomeado).
+- Elemento ambíguo (não fica claro se é relevante pra teste, ou risco de colisão de nome com outro
+  elemento) nunca recebe testid no chute — vira "pendência de revisão" no relatório.
+
+ETAPA 3: RELATÓRIO FINAL testid-changes-report.md
+Gere com:
+3.1 Convenção Adotada — padrão detectado ou definido, com exemplos
+3.2 Alterações Aplicadas — tabela: Arquivo | Linha | Elemento | testid Aplicado/Renomeado
+3.3 Pendências de Revisão — elementos ambíguos que não receberam testid, com o motivo
+3.4 Resumo por Fase (se modo app grande) — contagem por fase, testid-plan.md 100% concluído
+
+REGRAS INVIOLÁVEIS:
+1. A alteração em código de produção é estritamente aditiva — só o atributo data-testid (ou rename).
+   Nunca aproveita a etapa pra "ajustar mais umas coisinhas" no componente.
+2. Toda alteração é registrada no relatório (arquivo + linha + valor), mesmo sem gate de confirmação
+   prévio — a rastreabilidade pós-fato substitui a parada, mas não é opcional.
+3. Elemento ambíguo nunca recebe testid no chute — vira pendência registrada, não aplicação arriscada.
+4. Nunca mistura convenção de nome diferente entre arquivos ou fases.
+5. Não gera teste, não mapeia jornada, não decide elegibilidade de fluxo — isso é escopo do
+   testes-e2e.
+6. Não commita nada — nunca executa git add, git commit, git push. O usuário revisa e commita
+   manualmente.
+7. Em app grande, o testid-plan.md é atualizado a cada fase concluída, em tempo real, e não há
+   parada entre fases pra pedir permissão — a entrada no modo já é a autorização.
+
+FLUXO DE EXECUÇÃO:
+
+Modo Padrão (app pequeno/médio):
+1. Escaneia o projeto front-end
+2. Detecta ou define a convenção de nomenclatura
+3. Varre e aplica/renomeia data-testid em todo o app
+4. Gera testid-changes-report.md
+5. Pronto — sem commit, sem push, apenas os componentes com testid aplicado + o relatório
+
+Modo App Grande (Etapa 0.5 ativada):
+1. Escaneia o projeto, avalia o escopo → detecta que é grande → gera testid-plan.md com as fases
+2. Para cada fase, sem parar entre elas: detecta/aplica convenção → varre → aplica → atualiza
+   testid-plan.md marcando a fase como concluída
+3. Repete até todas as fases estarem concluídas
+4. Só então gera o testid-changes-report.md consolidado (todas as fases) + testid-plan.md 100%
+   concluído
+5. Exceção: pare no meio apenas se travar em algo objetivamente bloqueante (Etapa 0.5.3)
+6. Pronto — sem commit, sem push
+```
+
+---
+
+### 📊 RESULTADO ESPERADO:
+- App inteiro (mesmo grande, via fases) com `data-testid` consistente, sem varredura pela metade
+- Convenção única documentada e aplicada sem mistura entre arquivos
+- `testid-changes-report.md` com rastreabilidade total pra revisão pré-commit
+- Zero elemento com testid "no chute" — ambiguidade sempre vira pendência explícita
+
+---
+
+## 🔗 Onde Este Documento Se Encaixa
+Primeiro passo da cadeia de testes E2E da biblioteca:
+1. **Este documento** — garante seletor estável em todo o app
+2. **`testes-e2e`** — consome o `testid-changes-report.md` como pré-requisito,
+   mapeia jornadas elegíveis (happy path + falha obrigatória) e gera os specs
+3. **`testes`** (já existente na lib) — cobre unit+integration+e2e; use quando o pedido é cobertura geral, não só da camada E2E
+4. **`ci-e2e`** — coloca a suíte pra rodar em CI
+
+**Documento gerado com Engenharia de Prompt Profissional**
+**Especialização: Testabilidade Front-end | Agnóstico de Stack | Status: Pronto para Execução 10/10**

package/prompts/ci-e2e.md

@@ -0,0 +1,159 @@
+# ⚙️ Prompt de Pipeline CI para Suíte E2E
+**Versão: 10/10 | Engenheiro de DevOps/QA | Agnóstico de Provedor de CI | Engenharia de Prompt Aplicada**
+
+---
+
+## 📋 Índice de Execução
+1. Leitura Autônoma do CI e da Suíte E2E Existente
+2. Definição da Estratégia de Execução
+3. Cache e Performance
+4. Artefatos de Falha (trace, vídeo, screenshot, relatório)
+5. Geração do Patch de Pipeline
+6. Relatório Final
+
+---
+
+## ✅ PROMPT: ENGENHEIRO DE DEVOPS/QA — PIPELINE CI PARA E2E
+
+### 📖 O QUE ESTE PROMPT FAZ:
+Gera ou atualiza o script/config de CI que executa a suíte E2E já existente no projeto, de forma confiável — com trigger correto, retries limitados e documentados, cache de dependências/browsers, e artefatos de falha publicados pra debug. **Não gera specs** — pressupõe que a suíte já existe (ver `testes-e2e`).
+
+**Quando usar:** você já tem specs E2E rodando localmente e quer que rodem de forma consistente em CI (PR, push, schedule), sem virar um job que trava a pipeline por flakiness ou por retry infinito.
+
+**⚠️ Diferença de risco em relação ao prompt de testid:** esse aqui segue o **padrão read-only da biblioteca** — propõe o patch/diff do arquivo de pipeline pra você revisar e aplicar manualmente, não escreve direto. A exceção sem gate que você abriu foi específica pra `data-testid`; aqui não se aplica salvo você pedir o mesmo tratamento.
+
+---
+
+### 🎯 PROMPT (EXECUTE ISTO):
+
+```
+Você é um engenheiro de DevOps/QA especializado em pipelines de CI confiáveis para testes E2E —
+pipelines que falham quando o produto quebra, não quando a rede engasga, e que não escondem
+flakiness atrás de retry infinito.
+
+Este prompt é agnóstico de provedor de CI: adapte-se ao que já está configurado no projeto (GitHub
+Actions, GitLab CI, CircleCI, Azure Pipelines etc). Não force um provedor diferente do que já existe.
+
+ETAPA 0: LEITURA AUTÔNOMA DO CI E DA SUÍTE E2E EXISTENTE
+Antes de qualquer coisa, escaneie o projeto:
+- Localize o(s) arquivo(s) de config de CI já existente(s) (ex: .github/workflows/*.yml,
+  .gitlab-ci.yml, .circleci/config.yml) e identifique se já existe algum job de E2E configurado
+- Se já existir job de E2E, leia como está hoje (trigger, retries, cache, artifacts) antes de propor
+  qualquer mudança — você está evoluindo o que existe, não substituindo do zero sem necessidade
+- Identifique o comando de execução da suíte E2E (package.json → scripts, ex: npm run test:e2e) e o
+  framework/provedor já usado (Playwright, Cypress etc.)
+- Identifique outros jobs já existentes na mesma pipeline (build, lint, unit test) pra manter o mesmo
+  estilo de configuração (versão de Node, gerenciador de pacote, runner/imagem)
+- Se não houver NENHUM provedor de CI configurado, pergunte qual usar antes de prosseguir — não
+  assuma GitHub Actions por padrão silenciosamente
+Você não pede pra colar o YAML. Você lê o projeto diretamente.
+
+ETAPA 0.5: A SUÍTE E2E PRECISA EXISTIR ANTES
+Se não houver specs E2E nem comando de execução configurado no projeto, pare e avise — não gere um
+pipeline vazio "torcendo" pra suíte aparecer depois. Rode primeiro o prompt de geração de specs E2E.
+
+ETAPA 1: DEFINIÇÃO DA ESTRATÉGIA DE EXECUÇÃO
+Defina e documente antes de escrever qualquer YAML:
+- Trigger: em qual evento a suíte roda (PR pra branch principal, push, schedule noturno, manual). Se
+  a suíte for lenta, considere rodar full-suite só em PR pra main + versão reduzida (smoke/@critical,
+  se a tag existir) em outros eventos — mas só se o projeto já tiver esse tipo de tag definida
+  (detectado na Etapa 0 do prompt de specs); não invente tagging aqui.
+- Paralelização/sharding: se o framework suportar (Playwright shards, Cypress parallel) e o volume de
+  specs justificar, configure. Não adicione complexidade de paralelização pra 3 specs.
+- Retries: número EXPLÍCITO e limitado (ex: 1 retry automático em caso de falha, nunca "retry até
+  passar"). Retry existe pra absorver flakiness residual pontual, não pra mascarar teste quebrado —
+  se um spec falha consistentemente mesmo com retry, isso é sinal de bug real ou spec ruim, não motivo
+  pra aumentar o número de retries.
+- Timeout: por job e por teste individual, coerente com o que a suíte já usa localmente.
+- Matriz (se aplicável): múltiplos browsers/viewports, só se o projeto já testa isso localmente.
+
+PARADA AQUI. Mostre a estratégia definida (trigger, paralelização, retries, timeout, matriz) e aguarde
+confirmação antes de gerar o patch do pipeline.
+
+ETAPA 2: CACHE E PERFORMANCE
+- Cache de dependências (node_modules / cache do gerenciador de pacote) seguindo o mesmo padrão já
+  usado nos outros jobs da pipeline (Etapa 0)
+- Cache do binário de browser do framework E2E (evita reinstalar Chromium/Firefox etc. a cada run),
+  se o provedor de CI suportar
+
+ETAPA 3: ARTEFATOS DE FALHA
+Configure publicação de artifacts em caso de falha (e só em caso de falha, pra não inflar toda run
+verde com peso desnecessário):
+- Trace/vídeo/screenshot gerado pelo framework no momento da falha
+- Relatório HTML da suíte, se o framework gerar
+- Retenção de artifact com prazo razoável (ex: 7-14 dias), não "pra sempre"
+
+ETAPA 4: GERAÇÃO DO PATCH DE PIPELINE
+Gere o diff/patch do arquivo de CI com as mudanças propostas (job novo ou job existente atualizado).
+NÃO aplique direto no arquivo — mostre o patch completo pra revisão. Se algum valor sensível for
+necessário (token de API, credencial de ambiente sandbox), NUNCA hardcode o valor — referencie a
+variável de secret (ex: ${{ secrets.NOME }}) e liste no relatório quais secrets precisam existir no
+provedor de CI, cabendo a você cadastrar o valor manualmente.
+
+ETAPA 5: RELATÓRIO FINAL ci-pipeline-report.md
+Gere com:
+5.1 Estratégia Definida — trigger, paralelização, retries (com justificativa do número escolhido),
+    timeout, matriz
+5.2 Cache Configurado — o que foi cacheado e por quê
+5.3 Artefatos de Falha — o que é publicado, retenção
+5.4 Secrets Necessários — lista de variáveis que precisam ser cadastradas manualmente no provedor,
+    nunca com valor incluso
+5.5 Patch Proposto — diff completo do(s) arquivo(s) de CI, pronto pra você aplicar manualmente
+
+REGRAS INVIOLÁVEIS:
+1. Não aplica o patch direto no arquivo de CI — sempre propõe, você aplica manualmente. Essa é a
+   regra padrão da biblioteca; só muda se você pedir explicitamente a mesma exceção do prompt de
+   testid.
+2. Não sobrescreve jobs existentes de build/lint/deploy — só adiciona ou edita o job de E2E.
+3. Retry sempre com limite explícito e justificado. Nunca "retry até passar" ou número alto sem
+   motivo.
+4. Nunca hardcoda secret/credencial no arquivo de pipeline — sempre referencia variável de ambiente
+   gerenciada pelo provedor.
+5. Não gera pipeline pra suíte que não existe (Etapa 0.5).
+6. Não commita nada — nunca executa git add, git commit, git push. O usuário aplica e commita
+   manualmente.
+7. Agnóstico de provedor de CI — adapta-se ao que já existe, nunca impõe outro.
+8. Não inventa sistema de tagging (smoke/critical) que o projeto não tem — só usa se já existir.
+9. Artifact de falha tem retenção definida — nunca "pra sempre" por padrão.
+
+FLUXO DE EXECUÇÃO:
+1. Escaneia CI existente + suíte E2E existente (Etapa 0)
+2. Se não houver suíte, para e avisa (Etapa 0.5)
+3. Define estratégia de execução (Etapa 1)
+4. PARE — aguarda confirmação da estratégia
+5. Configura cache (Etapa 2) e artefatos de falha (Etapa 3)
+6. Gera patch/diff do pipeline, sem aplicar (Etapa 4)
+7. Gera ci-pipeline-report.md com secrets necessários e patch completo
+8. Pronto — você revisa o patch, aplica manualmente, cadastra os secrets e faz o commit
+```
+
+---
+
+### 📊 RESULTADO ESPERADO:
+- Pipeline de CI rodando a suíte E2E já existente, sem gerar specs novos
+- Retries com número explícito e justificado, nunca infinito ou implícito
+- Cache de dependências/browser configurado, sem reinstalar tudo a cada run
+- Artifacts de falha (trace/vídeo/screenshot) publicados só quando necessário, com retenção definida
+- Nenhum secret hardcoded — tudo referenciado como variável gerenciada pelo provedor
+- `ci-pipeline-report.md` com a estratégia, o patch proposto e os secrets que faltam cadastrar
+
+---
+
+## 🔗 Onde Este Documento Se Encaixa
+Quarto passo da cadeia de testes E2E da biblioteca (o `setup-e2e` só entra em cena em projeto novo,
+sem stack E2E nenhuma):
+1. **`setup-e2e`** — bootstrap da stack E2E do zero (apenas onde ainda não existe framework configurado)
+2. **`auditoria-testid`** — garante seletor estável em todo o app (audita e aplica `data-testid`)
+3. **`testes-e2e`** — mapeia jornadas elegíveis (happy path + falha obrigatória) e gera os specs
+4. **Este documento** — coloca a suíte pra rodar em CI de forma confiável, sem flakiness mascarada
+
+Complementa também o **`testes`** (já existente na lib): aquele cobre a suíte geral
+unit+integration+e2e com relatório de cobertura; este cuida especificamente da camada E2E rodando
+em CI.
+
+Diferente dos demais da cadeia, este não toca em specs nem em componentes de app — o objeto de
+trabalho é o arquivo de pipeline, e segue o padrão read-only default da biblioteca (patch proposto,
+nunca aplicado direto).
+
+**Documento gerado com Engenharia de Prompt Profissional**
+**Especialização: CI/CD para E2E | Agnóstico de Provedor | Status: Pronto para Execução 10/10**

package/prompts/manifest.json

@@ -23,6 +23,30 @@
     "title": "Testes & Cobertura (agnóstico de stack)",
     "description": "Cobertura de testes real em qualquer linguagem/framework: mapeamento de regras de negócio, reconciliação de testes existentes, pirâmide de testes."
   },
+  {
+    "id": "setup-e2e",
+    "file": "setup-e2e.md",
+    "title": "Setup de Stack E2E (Playwright)",
+    "description": "Bootstrap de stack E2E para projeto novo: instalação e configuração do Playwright, estrutura de pastas (e2e/, e2e/pages/, e2e/fixtures/) e smoke test inicial."
+  },
+  {
+    "id": "auditoria-testid",
+    "file": "auditoria-testid.md",
+    "title": "Auditoria e Aplicação de data-testid",
+    "description": "Garante seletor estável em todo o app: varredura do frontend, detecção/definição de convenção e aplicação aditiva de data-testid (pré-requisito da cadeia E2E)."
+  },
+  {
+    "id": "testes-e2e",
+    "file": "testes-e2e.md",
+    "title": "Testes E2E Consistentes (agnóstico de framework)",
+    "description": "Gera/expande uma suíte E2E disciplinada: critério de elegibilidade, mapeamento de jornadas (happy path + falha obrigatória), reconciliação de specs existentes e regras anti-flakiness."
+  },
+  {
+    "id": "ci-e2e",
+    "file": "ci-e2e.md",
+    "title": "Pipeline CI para Suíte E2E (read-only)",
+    "description": "Coloca a suíte E2E existente pra rodar em CI de forma confiável: estratégia de execução, cache, artefatos de falha e patch do pipeline para revisão manual."
+  },
   {
     "id": "auditoria-engenharia",
     "file": "auditoria-engenharia.md",

package/prompts/seo.md

@@ -5,7 +5,7 @@
 
 ## 📋 Índice de Execução
 1. **Reconhecimento do Projeto (Stack, Renderização, Roteamento)**
-2. **Gate de Confirmação de Escopo (23 itens)**
+2. **Gate de Escopo (23 itens) — resumo e prosseguimento automático**
 3. **Checklist Técnico — Crawlability, Indexação, Performance**
 4. **Checklist de Conteúdo e Autoridade**
 5. **Regras Anti-Falso-Positivo Específicas de SEO**
@@ -24,7 +24,7 @@ Diferente dos demais prompts de auditoria desta biblioteca (qualidade de código
 
 **Auditoria de SEO Técnico & Conteúdo:**
 - 🔍 Reconhecimento de renderização real (SSR/SSG/CSR/ISR) confirmado no código, não assumido pelo framework
-- 🚦 Gate de aplicabilidade — pausa antes de avaliar item por item, filtrando o que não se aplica à stack
+- 🚦 Gate de aplicabilidade — resume o que se aplica à stack antes de avaliar item por item e segue direto
 - 🕷️ Crawlability, indexação, canonical, sitemap/robots.txt, rastreabilidade de JS
 - 📈 Core Web Vitals — apenas sinais estruturais no código, nunca medição real sem ferramenta externa
 - 📝 Conteúdo: thin content, meta tags únicas vs. template genérico, E-E-A-T, linkagem interna
@@ -63,14 +63,16 @@ Antes de aplicar qualquer item do checklist, mapeie:
 
 Registre esse mapeamento no início do relatório. Ele é a base para todo o resto — sem isso, itens como "JS rastreável" e "Core Web Vitals" não podem ser avaliados corretamente.
 
-## ETAPA 0.5 — Gate de confirmação de escopo
+## ETAPA 0.5 — Gate de escopo
 
-Depois do reconhecimento, **pare e apresente um resumo** de:
+Depois do reconhecimento, **apresente um resumo** de:
 - O que foi identificado (stack, renderização, tamanho aproximado do projeto/rotas).
 - Quais dos 23 itens do checklist (Etapa 1 e 2) são **aplicáveis** a este projeto e quais são **não aplicáveis** (ex.: "backlinks" e "keyword research" nunca são verificáveis via código-fonte).
-- Peça confirmação antes de prosseguir para a análise profunda.
 
-Não avance para a Etapa 1 sem essa confirmação.
+Registre esse resumo no início do relatório e prossiga automaticamente para a Etapa 1 — não pause
+para pedir confirmação; a execução já foi solicitada ao rodar este prompt. Só interrompa se a
+detecção de stack/renderização for ambígua a ponto de inviabilizar a análise (ex: nenhum manifest
+identificável).
 
 ---
 

package/prompts/setup-e2e.md

@@ -0,0 +1,124 @@
+# 🚀 Prompt de Bootstrap — Stack E2E para Projeto Novo
+**Versão: 10/10 | Categoria: Bootstrap (Não Agnóstico) | Stack: Playwright | Engenharia de Prompt Aplicada**
+
+---
+
+## 📋 Índice de Execução
+1. Confirmação de que é Bootstrap (não duplicar setup existente)
+2. Instalação e Configuração do Playwright
+3. Estrutura de Pastas Alinhada com a Biblioteca
+4. Agent-Browser (Opcional, Não é Dependência de Pipeline)
+5. Checklist de Próximos Passos
+
+---
+
+## ✅ PROMPT: BOOTSTRAP DE STACK E2E (PLAYWRIGHT)
+
+### 📖 O QUE ESTE PROMPT FAZ:
+Diferente dos outros 3 prompts da cadeia E2E da biblioteca (auditoria de testid, geração de specs, pipeline CI — todos agnósticos, todos detectam o que já existe antes de agir), este prompt é a exceção deliberada: ele **escolhe uma stack específica** (Playwright) e instala do zero, porque bootstrap de projeto sem nada configurado não tem "o que já existe" pra detectar.
+
+**Quando usar:** só em projeto que ainda não tem nenhum framework E2E configurado. Se já existir Playwright, Cypress ou qualquer outro framework rodando, não use este prompt — use direto o `auditoria-testid` e o `testes-e2e`, que vão detectar e trabalhar em cima do que já existe.
+
+**⚠️ Por que Playwright e não outro framework:** essa é uma escolha assumida, não uma decisão "melhor framework do mercado" universal. Se seu próximo projeto novo tiver um motivo pra usar Cypress ou outro framework, este prompt não serve pra ele sem adaptação — ele é stack-specific por natureza, ao contrário do resto da biblioteca.
+
+**⚠️ Agent-browser é opcional, não é dependência de pipeline:** nenhuma das outras 3 skills da cadeia E2E depende do agent-browser — isso foi decisão explícita anterior, justamente pra manter a auditoria de testid focada sem competir atenção com ferramenta de exploração. Aqui ele entra só como conveniência pra exploração manual durante o desenvolvimento do teste, numa etapa isolada e claramente marcada como opcional.
+
+**⚠️ Diferença de execução em relação aos outros 3:** como é bootstrap de projeto vazio (não há código de produção nem spec existente pra colidir), este prompt escreve arquivos de config e instala pacotes direto, sem gate de confirmação — o risco de sobrescrever algo é baixo por definição (Etapa 0 garante isso). A única coisa que continua proibida é commit.
+
+---
+
+### 🎯 PROMPT (EXECUTE ISTO):
+
+```
+Você é um engenheiro responsável por dar o pontapé inicial numa stack de testes E2E com Playwright,
+num projeto que ainda não tem nada configurado.
+
+ETAPA 0: CONFIRMAÇÃO DE QUE É BOOTSTRAP
+Antes de instalar qualquer coisa, confirme que não há stack E2E já configurada:
+- Procure por playwright.config.*, cypress.config.*, wdio.config.* ou qualquer outro config de E2E
+- Procure por pasta e2e/, cypress/, tests/e2e/ com specs já existentes
+Se encontrar QUALQUER coisa configurada, PARE aqui e avise: este prompt é só pra bootstrap de projeto
+vazio. Se já existe stack, use o auditoria-testid e o testes-e2e em
+vez deste — eles trabalham em cima do que já existe.
+
+ETAPA 1: INSTALAÇÃO E CONFIGURAÇÃO DO PLAYWRIGHT
+- Identifique o gerenciador de pacote já usado no projeto (npm/yarn/pnpm) pelo lockfile existente
+- Instale o Playwright como dependência de desenvolvimento
+- Rode a instalação dos browsers (Chromium no mínimo; Firefox/WebKit se o projeto já sinalizar
+  necessidade de cross-browser — se não houver sinal nenhum, instale só Chromium pra manter o setup
+  enxuto, documentando que os outros browsers podem ser adicionados depois)
+- Gere o playwright.config.ts (ou .js, conforme o projeto já usa TypeScript ou não) com:
+  - baseURL apontando pro ambiente de desenvolvimento local do projeto (detecte a porta/comando de
+    dev já configurado, ex: package.json → scripts.dev)
+  - testDir apontando pra pasta e2e/
+  - Retry configurado em 0 localmente (retry é decisão do ci-e2e pro ambiente de CI, não
+    daqui)
+  - Reporter padrão (html) para uso local
+- Adicione os scripts no package.json: "test:e2e" (roda a suíte) e "test:e2e:ui" (modo interativo)
+- Adicione test-results/ e playwright-report/ ao .gitignore, se ainda não estiverem
+
+ETAPA 2: ESTRUTURA DE PASTAS ALINHADA COM A BIBLIOTECA
+Crie a estrutura de pastas que os outros prompts da cadeia já esperam encontrar:
+- e2e/ — onde os specs vão viver
+- e2e/pages/ — Page Object Model / componentes reutilizáveis (usado pelo testes-e2e)
+- e2e/fixtures/ — dados de setup sintéticos e fixtures customizadas
+Não crie nenhum spec de exemplo além de um único smoke test mínimo (ex: verificar que a home carrega)
+só pra validar que a instalação funciona — geração de spec de verdade é escopo do outro prompt.
+
+ETAPA 3: AGENT-BROWSER (OPCIONAL, NÃO É DEPENDÊNCIA DE PIPELINE)
+Só execute esta etapa se explicitamente solicitado. Se solicitado:
+- Instale/configure o agent-browser como ferramenta de desenvolvimento local
+- Deixe claro no relatório final que isso é conveniência de exploração manual — nenhuma das skills da
+  cadeia E2E (testid, specs, CI) depende dele pra funcionar
+
+ETAPA 4: RELATÓRIO FINAL setup-e2e-report.md
+Gere com:
+4.1 O que foi instalado (Playwright + versão, browsers instalados)
+4.2 Arquivos de config gerados (playwright.config.ts, scripts no package.json)
+4.3 Estrutura de pastas criada
+4.4 Se agent-browser foi incluído ou não, e por quê
+4.5 Checklist de Próximos Passos:
+    1. Rode o auditoria-testid pra garantir seletor estável antes do primeiro spec real
+    2. Rode o testes-e2e pra mapear jornadas e gerar os primeiros specs
+    3. Rode o ci-e2e quando a suíte já tiver specs suficientes pra justificar CI
+
+REGRAS INVIOLÁVEIS:
+1. Só executa se a Etapa 0 confirmar que não há stack E2E já configurada. Nunca sobrescreve config
+   existente.
+2. Não gera spec de teste real — só o smoke test mínimo de validação da instalação.
+3. Agent-browser só entra se explicitamente pedido, e sempre marcado como opcional no relatório.
+4. Não commita nada — nunca executa git add, git commit, git push. O usuário revisa e commita
+   manualmente.
+5. Estrutura de pastas segue exatamente o padrão que os outros 3 prompts da cadeia esperam
+   (e2e/, e2e/pages/, e2e/fixtures/) — não inventa nome diferente.
+
+FLUXO DE EXECUÇÃO:
+1. Confirma que não há stack já configurada (Etapa 0) — se houver, para e redireciona pros outros
+   prompts da cadeia
+2. Instala e configura Playwright (Etapa 1)
+3. Cria estrutura de pastas (Etapa 2)
+4. Configura agent-browser, só se pedido (Etapa 3)
+5. Gera setup-e2e-report.md com checklist de próximos passos
+6. Pronto — sem commit, sem push
+```
+
+---
+
+### 📊 RESULTADO ESPERADO:
+- Playwright instalado e configurado, rodando localmente com `npm run test:e2e`
+- Estrutura de pastas já alinhada com o que os outros 3 prompts da cadeia esperam encontrar
+- Agent-browser presente só se pedido, e nunca como dependência de fluxo
+- `setup-e2e-report.md` com checklist claro de qual prompt rodar em seguida
+
+---
+
+## 🔗 Onde Este Documento Se Encaixa
+Passo zero da cadeia de testes E2E da biblioteca — só entra em cena uma vez, no início de um projeto
+sem stack E2E nenhuma:
+1. **Este documento** — bootstrap do zero
+2. **`auditoria-testid`** — garante seletor estável em todo o app
+3. **`testes-e2e`** — mapeia jornadas e gera specs
+4. **`ci-e2e`** — coloca a suíte pra rodar em CI
+
+**Documento gerado com Engenharia de Prompt Profissional**
+**Especialização: Bootstrap de Stack E2E (Playwright) | Status: Pronto para Execução 10/10**

package/prompts/testes-e2e.md

@@ -0,0 +1,262 @@
+# 🧪 Prompt Otimizado para Testes E2E com Consistência (Anti-Caos)
+**Versão: 10/10 | Engenheiro de QA E2E Sênior | Agnóstico de Framework | Engenharia de Prompt Aplicada**
+
+---
+
+## 📋 Índice de Execução
+1. Leitura Autônoma do Diretório E2E
+2. Pré-Requisito — Auditoria de `data-testid` Já Concluída
+3. Critério de Elegibilidade — Quando um Fluxo Merece E2E
+4. Mapeamento de Jornadas de Usuário
+5. Reconciliação com Specs Existentes
+6. Regras de Consistência e Anti-Flakiness
+7. Geração dos Specs
+8. Relatório Final
+
+---
+
+## ✅ PROMPT: ENGENHEIRO DE QA E2E SÊNIOR — CONSISTÊNCIA E ANTI-CAOS
+
+### 📖 O QUE ESTE PROMPT FAZ:
+Diferente do `testes` (que cobre unit+integration+e2e com cobertura 100%), este prompt é focado **exclusivamente em testes E2E**: gera specs ponta a ponta consistentes com o que já existe no projeto, evita duplicar/flakar/inflar a suíte E2E, e só cria E2E pra fluxo que realmente justifica esse custo — cobertura profunda de regra de negócio fica pros outros níveis da pirâmide, fora do escopo deste prompt.
+
+**Quando usar:** você quer gerar ou expandir a suíte `e2e/*.spec.ts` (ou equivalente) de forma disciplinada — não "cria um teste aqui, cola um teste ali". Use depois de já ter cobertura unit/integration adequada, porque este prompt assume que regra de negócio granular já está coberta em outro nível e foca só na jornada crítica ponta a ponta.
+
+**Pré-requisito:** este prompt depende do `auditoria-testid` já ter rodado (ele gera o `testid-changes-report.md`, que é a fonte de verdade de seletor pra Etapa 2 aqui). Auditoria de `data-testid` foi extraída pra um prompt separado — vasculhar o app inteiro em busca de elemento sem testid é uma tarefa de exaustão que compete por atenção com as regras de jornada/gate se ficasse no mesmo prompt, então separar reduz a chance de algo passar despercebido nos dois lados.
+
+**⚠️ Decisão de arquitetura assumida (flag — você deixou em aberto):** o prompt de origem trazia a pirâmide de testes (unit ~70-80% / integration ~15-25% / e2e ~3-5%) pra decidir em que nível cada regra entra. Como este prompt é E2E-only, removi a pirâmide e troquei por um **critério de elegibilidade** (Etapa 0.5) — a lógica muda de "que % disso é E2E" pra "esse fluxo específico justifica um E2E ou não". Se preferir manter a pirâmide como referência de contexto (mesmo sem uso prático aqui), me avisa que eu adiciono de volta.
+
+---
+
+### 🎯 PROMPT (EXECUTE ISTO):
+
+```
+Você é um engenheiro de QA sênior especializado em testes E2E (end-to-end) que encontram regressões
+reais em fluxos críticos — não em gerar specs que só "passam" ou que duplicam o que integração/unit
+já cobre.
+
+Este prompt é agnóstico de framework E2E: adapte-se ao que já está configurado no projeto (Playwright,
+Cypress, TestCafe, WebdriverIO etc). Não force uma ferramenta diferente da que já existe.
+
+ETAPA 0: LEITURA AUTÔNOMA DO DIRETÓRIO E2E
+Antes de qualquer coisa, escaneie o projeto:
+- Localize o arquivo de configuração E2E (ex: playwright.config.ts, cypress.config.ts) e identifique
+  a pasta onde os specs vivem
+- Leia os specs existentes na pasta E2E pra entender: convenção de nomes de arquivo, estrutura de
+  describe/test, estratégia de seletor predominante (data-testid, texto, CSS, role), padrão de
+  setup/teardown (beforeEach, fixtures, helpers de login/seed)
+- Identifique se já existe algum componente reutilizável de passo de UI (Page Object Model, helper de
+  autenticação, fixture customizada) — ex: pasta `e2e/pages/`, `e2e/helpers/`, `e2e/fixtures/`. Se
+  existir, é isso que você vai reusar/estender na Etapa 2; se não existir nenhum, você vai criar a
+  primeira vez que um passo repetido aparecer (ver regra de reuso na Etapa 2)
+- Identifique o comando de execução (package.json → scripts) e se há modo UI/debug configurado
+- Identifique se existe tagging/anotação de criticidade nos testes já existentes (@smoke, @critical,
+  describe.tag etc.) — se existir, siga o mesmo padrão; se não existir, não invente um novo sistema de
+  tags sem perguntar
+- Se não houver nenhum framework E2E configurado, pergunte qual usar antes de prosseguir
+Você não pede pra colar código nem specs. Você lê o projeto diretamente.
+
+ETAPA 0.2: PRÉ-REQUISITO — AUDITORIA DE data-testid JÁ CONCLUÍDA
+Antes de mapear qualquer fluxo, confirme que o app já passou pela auditoria de seletor:
+- Procure por um `testid-changes-report.md` (ou equivalente) já existente no projeto, gerado pelo
+  auditoria-testid
+- Se o relatório não existir, pare e avise: rode o auditoria-testid primeiro. Não tente
+  fazer essa varredura por conta própria aqui — isso duplicaria trabalho e sairia sem o rigor de fase
+  que aquele prompt tem pra apps grandes
+- Se o relatório existir, leia as "Pendências de Revisão" registradas nele — elementos que ficaram sem
+  testid por ambiguidade. Guarde essa lista: se algum fluxo mapeado na Etapa 1 depender de um desses
+  elementos, você vai precisar sinalizar isso antes de escrever o spec (Etapa 2)
+
+ETAPA 0.5: CRITÉRIO DE ELEGIBILIDADE — QUANDO UM FLUXO MERECE E2E
+E2E é o teste mais caro e mais lento da pirâmide. Antes de mapear qualquer fluxo, filtre o que
+realmente justifica virar um spec E2E. Um fluxo é elegível quando pelo menos um critério é verdadeiro:
+- Atravessa múltiplas camadas/sistemas reais (frontend + backend + banco, ou frontend + serviço
+  externo) de um jeito que unit/integration isolados não conseguem validar
+- É um fluxo crítico de negócio (login, checkout, pagamento, cadastro, ação que move dinheiro/dado
+  sensível, fluxo que já quebrou em produção antes)
+- Valida a jornada completa do usuário do ponto de vista dele (clique real, navegação real, estado
+  visual real), não só o retorno de uma função
+
+Um fluxo NÃO é elegível pra E2E (delegue pra unit/integration, fora do escopo deste prompt) quando:
+- É uma variação de edge case de uma regra já coberta em unit (ex: 15 variações de validação de
+  formulário — só 1 delas vira parte de um E2E como happy/critical path, o resto fica pra unit)
+- É só uma chamada de API sem interação de UI relevante
+- É redundante com um fluxo E2E que já existe cobrindo o mesmo caminho crítico
+
+Liste os fluxos candidatos e classifique cada um como Elegível/Não Elegível com o motivo. Fluxos não
+elegíveis não geram spec — ficam só registrados no relatório final como "fora de escopo E2E, motivo X".
+
+PARADA AQUI. Mostre a lista de fluxos elegíveis/não elegíveis com motivo e aguarde confirmação antes de
+mapear a jornada de cada um.
+
+ETAPA 1: MAPEAMENTO DE JORNADA (POR FLUXO ELEGÍVEL)
+Para cada fluxo elegível, mapeie a jornada do ponto de vista do usuário — não a regra de negócio
+interna (isso é escopo do outro prompt). Formato:
+
+# Mapped E2E Journeys
+## [NOME_DO_FLUXO]
+### Persona / Ponto de Entrada
+- Quem executa esse fluxo e de onde ele começa (rota, estado prévio necessário: logado, com dados
+  seed, carrinho cheio etc.)
+### Passos da Jornada
+1. [Ação do usuário] → [Estado/UI esperado depois]
+2. ...
+### Critério de Sucesso (Assertion Final)
+- O que precisa estar visível/verdadeiro na tela ou no sistema pra considerar o fluxo validado
+### Variações Cobertas Neste Mesmo Fluxo (Obrigatório: Happy Path + Estado de Falha)
+- Happy path é obrigatório. Além dele, pelo menos 1 estado de falha também é obrigatório — não é mais
+  "se houver". Ex: login → happy path (credenciais válidas) + falha (credenciais inválidas); pagamento
+  → happy path (aprovado) + falha (recusado/cartão inválido); cadastro → happy path + falha (campo
+  obrigatório vazio ou duplicado).
+- Limite: no máximo 1-2 variações de falha por jornada, priorizando a que já quebrou em produção antes
+  ou a mais provável de acontecer. Não vira uma segunda pirâmide de edge cases dentro do E2E — edge
+  cases exaustivos continuam sendo escopo de unit/integration.
+- Se genuinamente não existir estado de falha aplicável pro fluxo (ex: uma jornada sem nenhum ponto de
+  rejeição possível), isso não é omitido em silêncio — vira uma linha explícita no relatório final
+  justificando por que não há variação de falha pra essa jornada específica.
+### Dados de Setup/Teardown Necessários
+- O que precisa existir antes (seed, mock de API externa, usuário de teste) e o que precisa ser limpo
+  depois (não deixar o teste sujar estado pra outros testes)
+- Dado sintético realista, não valor arbitrário: nome, email, CPF/telefone, valores monetários etc.
+  devem imitar formato/variação do mundo real (nome composto/acentuado, email com "+", centavos em
+  valor monetário) — não "Teste", "a@a.com" ou "100" redondo. O objetivo é que o dado em si já exercite
+  formatação/validação real, não só o caminho feliz do tipo de dado.
+- Gere o dado sinteticamente (biblioteca de fake data já usada no projeto, se houver, ou geração
+  simples inline). Nunca use cópia de dado real de produção, mesmo anonimizada — o projeto lida com
+  dado financeiro/pessoal (doação), e trazer isso pro ambiente de teste é risco de LGPD desnecessário
+  que não se paga pelo ganho de realismo.
+### Dependências Externas e Como Tratar
+- APIs de terceiros, gateways de pagamento etc. — mock, sandbox, ou ambiente real? Registre a decisão
+### Assumptions Section
+- ASSUMPTION 1: [DESCRIÇÃO]. Motivo: [POR QUE ASSUMI ISSO]
+
+ETAPA 1.5: TESTES EXISTENTES? RECONCILIE ANTES DE PROSSEGUIR
+Se já houver specs E2E cobrindo total ou parcialmente o fluxo mapeado, não ignore e não duplique.
+Reconcilie:
+1. Leia todos os specs existentes relacionados ao fluxo
+2. Compare cada spec existente contra a jornada mapeada na Etapa 1
+3. Classifique cada spec existente:
+   - Cobre a jornada corretamente e sem flakiness aparente → mantém como está
+   - Cobre mas usa padrão frágil (hard wait, seletor por texto/CSS instável, sem isolamento de dados)
+     → corrige, anota antes/depois no relatório
+   - Nome fora do padrão do projeto → renomeia pro padrão já identificado na Etapa 0
+   - Redundante com outro spec (mesmo caminho crítico já coberto) → remove, anota justificativa
+   - Jornada sem spec (gap real) → gera spec novo
+4. Siga exatamente a convenção de pasta/nome/estrutura já detectada na Etapa 0. Nunca crie uma segunda
+   estrutura paralela de specs E2E.
+
+PARADA AQUI. Mostre o resumo da reconciliação (mantidos/corrigidos/renomeados/removidos/novos) e
+aguarde confirmação antes de editar qualquer arquivo de spec.
+
+ETAPA 2: REGRAS DE CONSISTÊNCIA E ANTI-FLAKINESS (APLICAR EM TODO SPEC GERADO)
+1. Seletor: use o `data-testid` confirmado no `testid-changes-report.md` (Etapa 0.2). Se algum elemento
+   necessário pro spec está listado como "pendência de revisão" nesse relatório (ambíguo, não recebeu
+   testid), pare e sinalize antes de escrever o spec em cima de um seletor frágil só pra não travar.
+2. Nunca use espera fixa (sleep, waitForTimeout, cy.wait(ms) sem alias). Use espera baseada em
+   condição/estado (auto-retry de assertion, waitFor por elemento/estado, aguardar resposta de rede
+   por alias/intercept).
+3. Isolamento: cada spec cria e limpa seus próprios dados (seed/teardown). Nenhum spec depende da
+   ordem de execução de outro nem de estado deixado por outro teste.
+4. Estrutura Arrange (setup do estado/navegação) → Act (interação do usuário) → Assert (critério de
+   sucesso da Etapa 1), sempre nessa ordem, sem misturar.
+5. Um spec = uma jornada. Não amontoe múltiplos fluxos críticos não relacionados no mesmo teste só
+   pra "economizar tempo de execução".
+6. Nomes de arquivo e de describe/test seguem a convenção já detectada na Etapa 0 (idioma, casing,
+   estrutura). Se o projeto já usa português nos nomes dos specs, mantenha português — não force
+   inglês só porque outro prompt da biblioteca pede inglês pra teste unitário; a convenção de cada
+   nível de teste é a que já existe no projeto.
+7. Nenhuma assertion vazia ou fraca (checar só "elemento existe" quando o critério real da Etapa 1 é
+   mais específico). A assertion final tem que bater com o "Critério de Sucesso" mapeado.
+8. Mock de dependência externa é decisão registrada na Etapa 1 (Dependências Externas), nunca uma
+   escolha silenciosa feita na hora de escrever o código do spec.
+9. Reuso de passos (Page Object Model / helper / fixture): antes de escrever um passo de UI dentro de
+   um spec, verifique se esse passo já existe como componente reutilizável (detectado na Etapa 0). Se
+   existir, use — não reescreva o passo na mão dentro do spec. Se não existir e o mesmo passo aparecer
+   em mais de 1 jornada desta rodada (ex: login, navegar até uma área comum, abrir um modal
+   compartilhado), extraia esse passo pra um componente reutilizável (seguindo a mesma convenção de
+   pasta/nome já detectada, ou `e2e/pages/`/`e2e/helpers/` se não houver nenhuma ainda) em vez de
+   copiar o passo em cada spec. Passo que aparece uma única vez, numa única jornada, não precisa virar
+   componente — não crie abstração pra reuso que não existe ainda.
+
+ETAPA 3: GERAÇÃO DOS SPECS
+Só gere depois que Etapa 0.5 (elegibilidade) e Etapa 1.5 (reconciliação) estiverem confirmadas.
+Use a sintaxe/framework já detectado na Etapa 0. Um spec por jornada (ou agrupado por describe quando
+o próprio projeto já agrupa assim). Aplique todas as regras da Etapa 2.
+
+ETAPA 4: RELATÓRIO FINAL e2e-test-report.md
+Gere com:
+4.1 Fluxos Elegíveis vs Não Elegíveis — tabela com motivo de cada decisão (Etapa 0.5)
+4.2 Specs Gerados/Atualizados — tabela: Spec | Jornada Coberta | Tipo (Novo/Corrigido/Renomeado)
+4.3 Reconciliação — tabela: Spec Original | Ação | Motivo | Jornada Relacionada, com resumo (N mantidos
+    · N corrigidos · N renomeados · N removidos · N novos)
+4.4 Riscos Residuais — ex: seletor instável detectado e não resolvido, dependência externa testada
+    contra ambiente real (custo/flakiness), fluxo não elegível que pode merecer revisão futura
+4.5 Suposições Confirmadas — lista das Assumptions Section de cada jornada, já validadas
+
+REGRAS INVIOLÁVEIS:
+1. Não gera spec pra fluxo não elegível (Etapa 0.5) sem confirmação explícita de exceção.
+2. Não assume em silêncio — ambiguidade de jornada ou de seletor → anotação + confirmação, nunca
+   inventa.
+3. Não gera spec antes de elegibilidade E jornada estarem confirmadas. Dois gates, sem pular.
+4. Zero hard wait. Se não der pra evitar (dependência realmente instável), documenta como risco
+   residual explicitamente — não esconde no código.
+5. Não duplica spec existente que já cobre a mesma jornada.
+6. Não commita nada — nunca executa git add, git commit, git push ou qualquer operação de
+   versionamento. O usuário valida e faz commit manualmente.
+7. Agnóstico de framework E2E — adapta-se ao que já existe no projeto, nunca impõe outro.
+8. Nunca cria uma segunda convenção de pasta/nome de spec. Segue a estrutura já detectada.
+9. Spec corrigido por flakiness/padrão frágil é sempre registrado com antes/depois no relatório, nunca
+   silenciosamente sobrescrito.
+10. Um spec = uma jornada. Não infla um spec único pra "cobrir tudo de uma vez".
+11. Não faz varredura de `data-testid` por conta própria — depende do `auditoria-testid` já
+    ter rodado (Etapa 0.2). Se o relatório não existir, para e avisa, não tenta compensar aqui.
+12. Toda jornada elegível cobre happy path + pelo menos 1 estado de falha. Não é opcional. Se não
+    houver falha aplicável, a ausência é justificada explicitamente no relatório — nunca omitida.
+13. Dado de setup é sempre sintético realista (formato/variação de mundo real), nunca cópia de dado
+    real de produção, mesmo anonimizada. Nunca usa valor arbitrário tipo "Teste"/"a@a.com"/"100"
+    redondo quando o campo permite algo mais realista.
+14. Passo de UI repetido em mais de 1 jornada nunca é copiado entre specs — vira componente
+    reutilizável (Page Object Model/helper/fixture). Componente existente é reusado, nunca duplicado
+    ou reescrito na mão dentro de um spec novo.
+
+FLUXO DE EXECUÇÃO:
+1. Escaneia o diretório E2E, identifica framework/config/convenções já em uso
+2. Confirma que o testid-changes-report.md existe (Etapa 0.2) — se não existir, para e avisa
+3. Lista fluxos candidatos, classifica elegibilidade (Etapa 0.5)
+4. PARE — aguarda confirmação da lista de elegíveis/não elegíveis
+5. Mapeia jornada de cada fluxo elegível (Etapa 1)
+6. Reconcilia com specs existentes (Etapa 1.5) — mostra resumo
+7. PARE — aguarda confirmação da reconciliação antes de editar/criar arquivo
+8. Gera/atualiza specs aplicando regras de consistência (Etapa 2)
+9. Gera e2e-test-report.md
+10. Pronto — sem commit, sem push, apenas os specs gerados/atualizados
+```
+
+---
+
+### 📊 RESULTADO ESPERADO:
+- Fluxos filtrados por elegibilidade real pra E2E, não "todo mundo vira E2E"
+- Toda jornada crítica cobre happy path + pelo menos 1 estado de falha, não só o caminho feliz
+- Specs consistentes com a convenção já existente no projeto (seletor confirmado via
+  `testid-changes-report.md`, idioma, estrutura)
+- Zero hard wait, zero teste flaky introduzido de propósito
+- Passo repetido (login, navegação comum) vira componente reutilizável, não copiado em cada spec
+- Reconciliação de specs antigos frágeis/duplicados, com rastreabilidade
+- `e2e-test-report.md` com fluxos cobertos, reconciliação e riscos residuais
+
+---
+
+## 🔗 Onde Este Documento Se Encaixa
+Segundo passo da cadeia de testes E2E da biblioteca:
+1. **`auditoria-testid`** — garante seletor estável em todo o app (pré-requisito obrigatório)
+2. **Este documento** — mapeia jornadas elegíveis (happy path + falha obrigatória), reconcilia specs
+   existentes e gera os novos
+3. **`testes`** (já existente na lib) — cobre unit+integration+e2e com relatório de cobertura; use quando o pedido é cobertura geral, não só da camada E2E
+4. **`ci-e2e`** — coloca a suíte pra rodar em CI de forma confiável
+
+Complementa também o `testes`: aquele cobre unit+integration+e2e
+com % de cobertura; este é usado quando o pedido é especificamente "gera/expande a suíte E2E" e
+precisa de disciplina pra não virar uma pilha de specs redundantes e frágeis.
+
+**Documento gerado com Engenharia de Prompt Profissional**
+**Especialização: Testes E2E | Agnóstico de Framework | Status: Pronto para Execução — Avaliação Abaixo**