jarvis-ai-framework 2.1.1 → 3.0.0

package/skills/eng-qa-testsprite/SKILL.md

@@ -1,332 +0,0 @@
----
-name: eng-qa-testsprite
-description: >
-  Executa testes automatizados usando TestSprite MCP Server para frontend e backend.
-  Trigger: Use quando precisar gerar e executar testes automatizados com TestSprite, validar cobertura de testes ou criar planos de teste.
-argument-hint: "[frontend|backend|diff|codebase]"
-disable-model-invocation: false
-allowed-tools: Read Write Edit Grep Glob Bash mcp__TestSprite__testsprite_bootstrap mcp__TestSprite__testsprite_generate_code_summary mcp__TestSprite__testsprite_generate_standardized_prd mcp__TestSprite__testsprite_generate_frontend_test_plan mcp__TestSprite__testsprite_generate_backend_test_plan mcp__TestSprite__testsprite_generate_code_and_execute mcp__TestSprite__testsprite_rerun_tests
-license: AGPL-3.0
-metadata:
-  author: jarvis-team
-  version: "1.0"
-  area: qa
----
-
-# QA TestSprite - Testes Automatizados
-
-Você é um **especialista em testes automatizados** usando o TestSprite MCP Server para gerar e executar testes de forma autônoma.
-
-## Objetivo
-
-Automatizar a geração e execução de testes para projetos frontend e backend, utilizando o TestSprite para criar planos de teste abrangentes e scripts executáveis.
-
-## Entrada
-
-- `$ARGUMENTS` - Tipo de teste: `frontend`, `backend`, `diff` (mudanças recentes) ou `codebase` (projeto completo)
-
-## Recursos
-
-- **Referência (local)**: `$IDE/skills/eng-qa-testsprite/references/testsprite-mcp.md`
-- **Documentação oficial (backup)**: https://docs.testsprite.com/mcp/getting-started/overview
-- **Saída**: Relatório de testes em markdown + scripts de teste gerados pelo TestSprite
-
----
-
-## Pré-requisito
-
-Verificar se o `ENV.md` existe e está preenchido corretamente. Se não existir ou estiver incompleto, execute `/jarvis-init` antes de continuar.
-
-**Requisitos do projeto:**
-- Frontend: React, Vue, Angular, Svelte, Next.js, Vite ou vanilla JS/TS
-- Backend: Node.js, Python, Java, Go, Express.js, FastAPI, Spring Boot, REST ou GraphQL
-
----
-
-## Quando Usar
-
-Use este skill quando:
-- Precisar gerar testes automatizados para o projeto
-- Quiser validar cobertura de testes existente
-- Necessitar de plano de testes abrangente
-- Testar mudanças recentes (diff) antes de commit/PR
-- Validar qualidade do código com testes E2E
-
-**NÃO usar quando:**
-- Projeto não tem frontend/backend suportado
-- Necessitar apenas de testes unitários simples (use eng-qa-unit-test)
-- Ambiente local não está configurado para rodar o projeto
-
----
-
-## Validação de Entrada
-
-```
-Se $ARGUMENTS está vazio:
-  → Perguntar: "Qual tipo de teste deseja executar?"
-  → Opções: frontend, backend, diff, codebase
-  → Usar resposta como $ARGUMENTS
-
-Se $ARGUMENTS não é válido:
-  → Exibir: "⚠️ Tipo inválido. Use: frontend, backend, diff ou codebase"
-  → Encerrar execução
-```
-
----
-
-## Padrões Críticos
-
-### Padrão 1: Determinar porta local do projeto
-
-Antes de executar `testsprite_bootstrap`, identificar a porta local:
-
-```
-Verificar em ordem:
-1. package.json scripts (dev/start) → porta no comando
-2. vite.config.js/ts → server.port
-3. next.config.js → porta padrão 3000
-4. Dockerfile → EXPOSE
-5. .env → PORT variável
-6. Padrão: 5173 (Vite) ou 3000 (Next/Express)
-```
-
-### Padrão 2: Fluxo sequencial obrigatório
-
-O TestSprite requer execução em ordem específica:
-
-```
-1. testsprite_bootstrap        → Inicializa ambiente
-2. testsprite_generate_code_summary → Analisa codebase
-3. testsprite_generate_standardized_prd → Gera PRD normalizado
-4. testsprite_generate_*_test_plan → Cria plano de testes
-5. testsprite_generate_code_and_execute → Executa testes
-```
-
-### Padrão 3: Escopo correto para diff vs codebase
-
-```
-diff     → Testa mudanças recentes do seu trabalho (git)
-codebase → Testa projeto completo
-```
-
-Observação: o comportamento exato de "diff" pode variar (staged vs uncommitted). Se houver dúvida, pergunte ao usuário qual estado do Git deve ser considerado e ajuste o preparo da branch antes de executar.
-
----
-
-## Árvore de Decisão
-
-```
-Argumento é "frontend"?  → Usar testsprite_generate_frontend_test_plan
-Argumento é "backend"?   → Usar testsprite_generate_backend_test_plan
-Argumento é "diff"?      → testScope: "diff"
-Argumento é "codebase"?  → testScope: "codebase"
-Sem argumento?           → Perguntar ao usuário
-```
-
-### Quando rodar Frontend + Backend juntos
-
-Execute ambos os tipos quando:
-- O fluxo é ponta-a-ponta (UI chama API) e você quer diagnóstico mais rápido
-- Existem regras de auth e modelos de dados compartilhados entre UI e API
-- O problema pode estar em contrato/payloads/status codes (API), mas se manifesta na UI
-
----
-
-## Fluxo de Trabalho
-
-### 1. Identificar Tipo de Projeto
-
-Analisar estrutura para determinar se é frontend ou backend:
-
-```bash
-# Frontend indicators
-ls package.json src/App.* src/main.* pages/ app/
-
-# Backend indicators
-ls server.* app.py main.go routes/ controllers/
-```
-
-### 2. Determinar Porta Local
-
-```bash
-# Verificar package.json
-grep -E "\"(dev|start)\":" package.json
-
-# Verificar vite.config
-grep "port" vite.config.*
-
-# Verificar .env
-grep "PORT" .env
-```
-
-### 3. Bootstrap TestSprite
-
-Executar `testsprite_bootstrap` com parâmetros corretos:
-
-| Parâmetro | Descrição |
-|-----------|-----------|
-| `localPort` | Porta do servidor local (ex: 5173, 3000) |
-| `type` | "frontend" ou "backend" |
-| `projectPath` | Caminho absoluto do projeto |
-| `testScope` | "diff" ou "codebase" |
-| `pathname` | Caminho da página (opcional, padrão "") |
-
-### 4. Gerar Sumário do Código
-
-Executar `testsprite_generate_code_summary` para analisar o projeto.
-
-### 5. Gerar PRD Padronizado
-
-Executar `testsprite_generate_standardized_prd` para criar PRD normalizado.
-
-### 6. Gerar Plano de Testes
-
-Executar o plano apropriado:
-- Frontend: `testsprite_generate_frontend_test_plan`
-- Backend: `testsprite_generate_backend_test_plan`
-
-**Parâmetros do Frontend Test Plan:**
-
-| Parâmetro | Descrição |
-|-----------|-----------|
-| `projectPath` | Caminho absoluto do projeto |
-| `needLogin` | `true` se o app requer autenticação, `false` caso contrário |
-
-> **Nota**: Se `needLogin: true`, o TestSprite incluirá fluxos de login/logout e rotas protegidas no plano de testes. Forneça credenciais de conta de teste quando solicitado.
-
-**Parâmetros do Backend Test Plan:**
-
-A documentação do TestSprite pode solicitar campos adicionais dependendo do projeto e do modo de execução.
-
-- Se a ferramenta pedir parâmetros extras, pergunte ao usuário os valores necessários e prossiga.
-- Evite assumir valores padrão não documentados.
-
-### 7. Executar Testes
-
-Executar `testsprite_generate_code_and_execute`:
-
-| Parâmetro | Descrição |
-|-----------|-----------|
-| `projectName` | Nome do diretório raiz |
-| `projectPath` | Caminho absoluto |
-| `testIds` | IDs dos testes ([] = todos) |
-| `additionalInstruction` | Instruções extras ("" = nenhuma) |
-
-### 8. Analisar Resultados
-
-Verificar relatório gerado e apresentar resumo ao usuário.
-
-### Skills invocados durante a execução do skill
-
-| Passo | Skill | Condição |
-|-------|-------|----------|
-| — | Nenhuma — skill autocontida | — |
-
----
-
-## Regras
-
-### Nunca
-- Executar bootstrap sem identificar a porta correta
-- Pular etapas do fluxo sequencial
-- Usar testScope errado (diff vs codebase)
-- Executar sem projeto rodando localmente
-- Ignorar erros de execução
-
-### Sempre
-- Identificar porta local antes do bootstrap
-- Seguir ordem sequencial das ferramentas
-- Verificar se projeto está rodando antes de testar
-- Apresentar resumo dos resultados ao usuário
-- Perguntar tipo se argumento não fornecido
-
----
-
-## Tratamento de Erros
-
-### Projeto não está rodando
-- Exibir: "⚠️ O projeto precisa estar rodando localmente na porta {porta}"
-- Sugerir: "Execute `npm run dev` ou equivalente antes de testar"
-
-### Porta incorreta
-- Exibir: "⚠️ Não foi possível conectar na porta {porta}"
-- Verificar novamente os arquivos de configuração
-- Perguntar ao usuário qual porta usar
-
-### Tipo de projeto não suportado
-- Exibir: "⚠️ Framework não suportado pelo TestSprite"
-- Listar frameworks suportados
-- Sugerir alternativas (eng-qa-unit-test)
-
-### Testes falharam
-- Apresentar resumo dos testes que falharam
-- Oferecer opção de re-executar com `testsprite_rerun_tests`
-- Sugerir correções baseadas nos erros
-
----
-
-## Checklist de Conclusão
-
-- [ ] Tipo de teste identificado (frontend/backend/ambos)
-- [ ] Porta local determinada corretamente
-- [ ] Projeto está rodando localmente
-- [ ] Bootstrap executado com sucesso
-- [ ] Sumário do código gerado
-- [ ] PRD padronizado criado
-- [ ] Parâmetro `needLogin` definido (se frontend)
-- [ ] Credenciais de teste obtidas (se `needLogin: true`)
-- [ ] Plano de testes gerado
-- [ ] Testes executados
-- [ ] Artefatos gerados em `testsprite_tests/`
-- [ ] Resultados apresentados ao usuário
-
----
-
-## Output
-
-Artefatos gerados na pasta `testsprite_tests/`:
-
-| Artefato | Caminho | Descrição |
-|----------|---------|-----------|
-| PRD normalizado | `standard_prd.json` | Requisitos estruturados do projeto |
-| Relatório MD | `TestSprite_MCP_Test_Report.md` | Relatório em markdown |
-| Relatório HTML | `TestSprite_MCP_Test_Report.html` | Relatório visual |
-| Casos de teste | `TC001_*.py`, `TC002_*.py`, ... | Scripts de teste gerados |
-| Config auxiliar | `tmp/config.json` | Configuração da execução |
-| Sumário do código | `tmp/code_summary.json` | Análise do codebase |
-| Resultados | `tmp/test_results.json` | Resultados detalhados dos testes |
-
----
-
-## Mensagem de Conclusão
-
-```
-TestSprite executado com sucesso!
-
-Projeto: {projectName}
-Tipo: {type}
-Escopo: {testScope}
-Porta: {localPort}
-
-Resultados:
-- Testes executados: {total}
-- Passou: {passed}
-- Falhou: {failed}
-- Cobertura: {coverage}%
-
-Artefatos gerados:
-- Relatório: testsprite_tests/TestSprite_MCP_Test_Report.md
-- Casos de teste: testsprite_tests/TC*.py
-
-Próximo passo: Revisar relatório em testsprite_tests/
-```
-
----
-
-## Recursos Adicionais
-
-- **Referência (local)**: `$IDE/skills/eng-qa-testsprite/references/testsprite-mcp.md`
-- **Documentação oficial (backup)**: https://docs.testsprite.com/mcp/getting-started/overview
-- **Frameworks suportados**:
-  - Frontend: React, Vue, Angular, Svelte, Next.js, Vite, vanilla JS/TS
-  - Backend: Node.js, Python, Java, Go, Express.js, FastAPI, Spring Boot, REST, GraphQL

package/skills/eng-qa-testsprite/references/testsprite-mcp.md

@@ -1,224 +0,0 @@
-# TestSprite MCP — Referência (Resumo Operacional)
-
-> Esta referência consolida, em formato local, as capacidades e o fluxo do **TestSprite MCP Server**.
-> 
-> Fonte original: https://docs.testsprite.com/mcp/getting-started/introduction
-
----
-
-## O que é
-
-O **TestSprite MCP Server** é um MCP para IDE que funciona como um agente de testes automatizados. Ele:
-
-- Lê PRD (quando fornecido)
-- Analisa o codebase
-- Gera um PRD normalizado (TestSprite PRD)
-- Cria planos de teste
-- Gera código de teste
-- Executa testes
-- Produz relatórios
-- Suporta fluxo de correção com base nos resultados
-
-A documentação descreve esse funcionamento como um fluxo em múltiplas etapas ("reads PRD" → "analyzes code" → "generates test PRD" → "creates test plans" → "generates test code" → "executes tests" → "provides results" → "enables fixes").
-
----
-
-## Tipos de teste suportados
-
-- **Frontend**: UI & Business-Flow (E2E / integração de fluxos)
-- **Backend**: API & Integration
-
-## Quando usar cada tipo
-
-### Frontend (UI & Business-Flow)
-
-Use quando o risco/valor está no comportamento percebido pelo usuário:
-
-- Fluxos de navegação (multi-step), páginas e rotas
-- Formulários, validações e mensagens de erro
-- Componentes interativos e estados (loading/empty)
-- Fluxos de autenticação/autorizações na UI (login/logout/rotas protegidas)
-
-Evite escolher Frontend como única camada quando o objetivo é validar contrato/semântica de API (nesse caso, inclua Backend).
-
-### Backend (API & Integration)
-
-Use quando o risco/valor está na API/serviço e suas integrações:
-
-- Contratos de request/response, schemas e versionamento
-- Regras de autorização/autenticação (RBAC/scopes, token validation)
-- Resiliência e tratamento de erro (status codes, timeouts, retries/backoff)
-- Edge cases e validações de payload/paginação
-- Integridade/persistência de dados (idempotência/constraints)
-
-### Quando rodar os dois
-
-Rode **Frontend + Backend** quando:
-
-- O fluxo é ponta-a-ponta (UI chama API) e você quer diagnóstico mais rápido
-- Existem regras de auth e modelos de dados compartilhados entre UI e API
-- O problema pode estar em contrato, payloads ou status codes (camada API), mas se manifesta na UI
-
----
-
-## Escopo de execução (Codebase vs Code Diff)
-
-A documentação menciona dois modos de escopo:
-
-- **Codebase**: varredura completa do projeto.
-  - Use quando:
-    - é a primeira execução do TestSprite no repo
-    - você quer um baseline amplo de qualidade
-    - houve mudanças grandes/estruturais e o risco é sistêmico
-
-- **Code Diff**: executar focado nas mudanças recentes (a doc cita mudanças não commitadas/uncommitted).
-  - Use quando:
-    - você quer feedback rápido antes de abrir PR
-    - quer validar apenas o impacto do que acabou de alterar
-    - está iterando rapidamente e o full sweep seria caro/lento
-
-Observação: se você precisar focar especificamente em staged vs uncommitted, valide com o usuário qual estado do Git deve ser considerado antes de executar.
-
-## Tipos de testes (detalhamento)
-
-Esta lista é uma transcrição/normalização do que a documentação descreve como capacidades suportadas.
-
-### Frontend (UI & Business-Flow Integration)
-
-- **User Journey Navigation**: fluxos multi-etapa, transições de página, deep linking, histórico do navegador e route guards.
-  - Exemplos de quando usar:
-    - Quando você alterou navegação/roteamento (ex.: novas rotas, guards, redirects pós-login).
-    - Quando implementou um fluxo multi-página (ex.: onboarding, checkout, wizard).
-    - Quando mudou deep links (ex.: abrir detalhes via URL) ou comportamento do back/forward.
-- **Form Flows & Validation**: validação de input, mensagens de erro, dependências entre campos, submissão e persistência.
-  - Exemplos de quando usar:
-    - Quando criou/alterou regras de validação (ex.: email, senha, máscara, required).
-    - Quando mudou mensagens de erro, estados inválidos e validação em tempo real.
-    - Quando o submit depende de múltiplos campos/etapas (ex.: endereço + pagamento).
-- **Visual States & Layouts**: renderização, responsividade, loading/empty states e compliance de acessibilidade.
-  - Exemplos de quando usar:
-    - Quando adicionou estados de carregamento/placeholder/skeleton.
-    - Quando alterou layout responsivo (breakpoints) ou grid.
-    - Quando implementou empty states (lista vazia, zero-state) e quer validar acessibilidade.
-- **Interactive Components & Stateful UI**: dropdowns, modals, tabs, accordions, drag-and-drop, persistência de estado e updates em tempo real.
-  - Exemplos de quando usar:
-    - Quando adicionou/alterou modal, dropdown, tab ou accordion que controla estado.
-    - Quando implementou drag-and-drop (ordenar itens, kanban).
-    - Quando tem UI com updates em tempo real (polling/websocket) e precisa validar consistência visual.
-- **Authorization & Auth Flows (UI)**: login/logout, rotas protegidas, visibilidade por papel, session management e token refresh.
-  - Exemplos de quando usar:
-    - Quando alterou fluxo de login/logout (ex.: SSO, MFA, step extra).
-    - Quando introduziu nova rota protegida ou mudança de RBAC na UI.
-    - Quando houve mudança em refresh/expiração de token (ex.: reauth silencioso).
-- **Error Handling (UI)**: toasts, modals, inline errors, feedback de validação e graceful degradation.
-  - Exemplos de quando usar:
-    - Quando mudou o padrão de exibição de erros (toast vs inline vs modal).
-    - Quando adicionou tratamento para falhas de rede/timeout.
-    - Quando precisa validar que o usuário recebe feedback correto em cenários de erro.
-
-### Backend (API & Integration)
-
-- **Functional API Workflows**: comportamento de endpoints, workflows multi-step, orquestração de serviços e padrões de integração.
-  - Exemplos de quando usar:
-    - Quando introduziu um fluxo que chama múltiplos endpoints (ex.: criar pedido → pagar → confirmar).
-    - Quando mudou orquestração/integração entre serviços (ex.: webhook + job async).
-    - Quando há dependência de estados/transições (ex.: status de pedido).
-- **Contract & Schema Validation**: schemas request/response, data types, required fields, formatos de serialização e versionamento.
-  - Exemplos de quando usar:
-    - Quando adicionou/removeu campos no payload (request/response).
-    - Quando alterou tipos/formatos (ex.: date string → epoch) ou regras de required/optional.
-    - Quando mudou versionamento de API ou contratos entre serviços.
-- **Error Handling & Resilience**: status codes, error bodies, retry/backoff, timeouts e graceful degradation.
-  - Exemplos de quando usar:
-    - Quando ajustou códigos de status (ex.: 400/404/409/422) e mensagens de erro.
-    - Quando adicionou timeouts, retries/backoff ou circuit breaker.
-    - Quando precisa validar comportamento em dependência instável (ex.: serviço terceiro).
-- **Authorization & Authentication**: token validation, RBAC, permission scopes, session management e credential handling.
-  - Exemplos de quando usar:
-    - Quando alterou regras de permissão (RBAC/scopes) por endpoint.
-    - Quando mudou validação de token (claims, expiração, audience/issuer).
-    - Quando introduziu novo mecanismo de autenticação (ex.: API key, OAuth).
-- **Boundary & Edge Cases**: limites de payload, paginação, valores null/empty, inputs malformados e constraint validation.
-  - Exemplos de quando usar:
-    - Quando adicionou paginação/filters/sorting e precisa validar limites.
-    - Quando o endpoint aceita payload grande ou novos formatos.
-    - Quando adicionou validações de input e quer cobrir casos inválidos.
-- **Data Integrity & Persistence**: consistência de dados, transações, idempotência, state management e database constraints.
-  - Exemplos de quando usar:
-    - Quando introduziu escrita em banco (insert/update) com constraints novas.
-    - Quando implementou idempotência (ex.: POST com idempotency-key).
-    - Quando adicionou transações/sagas e quer validar consistência sob falha.
-- **Security Testing**: vulnerabilidades comuns (injection, XSS, CSRF), auth bypass, authorization flaws, data exposure e security misconfigurations.
-  - Exemplos de quando usar:
-    - Quando expôs endpoint novo e quer validar que não há bypass de auth.
-    - Quando mexeu em sanitização/validação e quer detectar injection.
-    - Quando lida com dados sensíveis e quer checar exposição indevida.
-
----
-
-## Lifecycle (modelo mental)
-
-A documentação descreve um lifecycle conceitual:
-
-- Discover & Understand
-- Plan
-- Generate
-- Execute
-- Analyze
-- Heal & Maintain
-- Report & Integrate
-
----
-
-## Fluxo de "primeiro teste" (Getting Started)
-
-A documentação sugere:
-
-1. Subir o projeto localmente (ex.: `npm run dev`, `node index.js`, etc.)
-2. Abrir um chat no IDE e pedir:
-
-```text
-Can you test this project with TestSprite?
-```
-
-3. Fornecer configuração obrigatória (conforme solicitado pelo fluxo do MCP), incluindo:
-   - Tipo: Frontend ou Backend
-   - Scope: Codebase (varredura completa) ou Code Diff (mudanças recentes / uncommitted)
-   - Credenciais de conta de teste (se houver login)
-   - URLs locais (ex.: frontend `http://localhost:5173`, backend `http://localhost:4000`)
-   - PRD (quando aplicável)
-
----
-
-## Artefatos gerados
-
-A documentação mostra um output típico em `testsprite_tests/`, incluindo:
-
-- `standard_prd.json` (PRD normalizado)
-- `TestSprite_MCP_Test_Report.md` e `TestSprite_MCP_Test_Report.html`
-- `tmp/` com dados auxiliares (ex.: `config.json`, `code_summary.json`, `test_results.json`)
-- Arquivos de casos de teste (ex.: `TC001_...py`, `TC002_...py`, etc.)
-
----
-
-## Pré-requisitos / instalação (pontos essenciais)
-
-- Conta TestSprite e **API key**
-- **Node.js >= 22** (para rodar o MCP via `npx`)
-- Instalação do MCP depende do IDE, mas o comando base é:
-
-```text
-npx @testsprite/testsprite-mcp@latest
-```
-
-Em configurações de MCP, é comum usar `API_KEY` via variável de ambiente.
-
----
-
-## Referências
-
-- Introduction: https://docs.testsprite.com/mcp/getting-started/introduction
-- Overview: https://docs.testsprite.com/mcp/getting-started/overview
-- Installation: https://docs.testsprite.com/mcp/getting-started/installation
-- First MCP Test: https://docs.testsprite.com/mcp/getting-started/first-test
-- Test Types & Lifecycle: https://docs.testsprite.com/mcp/concepts/test-type-lifecycle