jarvis-ai-framework 1.0.0

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

@@ -0,0 +1,224 @@
+# 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

package/skills/eng-qa-unit-test/SKILL.md

@@ -0,0 +1,471 @@
+---
+name: eng-qa-unit-test
+description: >
+  Gera testes unitários para código novo ou modificado seguindo as convenções do projeto.
+  Trigger: Use quando precisar criar testes unitários para funções, classes ou módulos.
+argument-hint: "[caminho-do-arquivo]"
+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_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"
+---
+
+# QA Unit Test - Gerador de Testes Unitários
+
+Você é um **especialista em testes unitários** focado em criar testes de alta qualidade seguindo as convenções do projeto.
+
+## Objetivo
+
+Gerar testes unitários completos para código novo ou modificado, garantindo cobertura adequada e seguindo padrões de teste do projeto.
+
+## Entrada
+
+- `$ARGUMENTS` - Caminho do arquivo ou função para criar testes
+
+## Recursos
+
+- **Saída**: Arquivo de teste no padrão do projeto (`.test.ts`, `.spec.ts`, `_test.py`, etc.)
+
+---
+
+## Pré-requisito
+
+Verificar se o `ENV.md` existe e está completo antes de executar.
+
+---
+
+## Quando Usar
+
+Use esta skill quando:
+- Precisar criar testes unitários para novo código
+- Quiser aumentar a cobertura de testes de código existente
+- Necessitar de testes para funções ou classes específicas
+- Estiver fazendo TDD e precisar de testes antes da implementação
+
+**NÃO usar quando:**
+- Precisar de testes de integração (use qa-integration-test)
+- Precisar de testes e2e (use qa-e2e-test)
+- O código já tiver cobertura adequada
+
+---
+
+## Validação de Entrada
+
+```
+Se $ARGUMENTS está vazio:
+  → Exibir: "⚠️ Argumento obrigatório. Informe o caminho do arquivo."
+  → Exibir: "Uso: /qa-unit-test [caminho-do-arquivo]"
+  → Encerrar execução
+```
+
+---
+
+## Integração com TestSprite MCP
+
+Esta skill prioriza o uso do TestSprite MCP para geração automática de testes quando disponível.
+
+### Verificação de Disponibilidade
+
+Para verificar se o TestSprite está disponível:
+
+1. **Tente chamar** `testsprite_bootstrap` com parâmetros mínimos
+2. **Se a tool existir e responder**: Prossiga com o Fluxo A (MCP)
+3. **Se a tool não existir ou retornar erro**: Prossiga com o Fluxo B (Manual)
+
+**Erros que indicam indisponibilidade:**
+- `Tool not found`
+- `MCP server not connected`
+- `Connection refused`
+- Timeout sem resposta
+
+> **Importante**: Não tente reconectar ou instalar o MCP automaticamente. Se indisponível, siga direto para o Fluxo B.
+
+### Decisão de Fluxo
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│                                                             │
+│  VERIFICAR TESTSPRITE MCP                                   │
+│                                                             │
+│  ┌─────────────────────────┐                                │
+│  │ Tool testsprite_bootstrap│                               │
+│  │ disponível?              │                               │
+│  └───────────┬─────────────┘                                │
+│              │                                              │
+│         SIM  │  NÃO                                         │
+│         ↓    │  ↓                                           │
+│       FLUXO  │  FLUXO                                       │
+│       MCP    │  MANUAL                                      │
+│       (A)    │  (B)                                         │
+│                                                             │
+└─────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## FLUXO A: TestSprite MCP (Preferencial)
+
+Se o TestSprite MCP estiver disponível, use as seguintes ferramentas para gerar testes automaticamente.
+
+### A.1. Detectar Tipo de Projeto
+
+Identifique se o projeto é frontend ou backend:
+
+```bash
+# Verificar indicadores de Frontend
+grep -E "(react|vue|angular|next|nuxt|svelte|vite)" package.json 2>/dev/null
+
+# Verificar indicadores de Backend
+ls requirements.txt go.mod pom.xml Cargo.toml 2>/dev/null
+grep -E "(express|fastify|nest|koa|hapi)" package.json 2>/dev/null
+```
+
+| Indicador | Tipo |
+|-----------|------|
+| `react`, `vue`, `angular`, `next`, `svelte`, `vite` | Frontend |
+| `express`, `fastify`, `nest`, `koa`, `hapi` | Backend |
+| `requirements.txt`, `pytest` | Backend (Python) |
+| `go.mod` | Backend (Go) |
+| `pom.xml`, `build.gradle` | Backend (Java) |
+
+### A.2. Detectar Porta Local
+
+```bash
+# Verificar porta em package.json ou .env
+grep -E "PORT|port" package.json .env 2>/dev/null
+```
+
+| Framework | Porta Padrão |
+|-----------|-------------|
+| Vite/React | 5173 |
+| Next.js/CRA | 3000 |
+| Express/Node | 3000 |
+| Django/FastAPI | 8000 |
+
+### A.3. Bootstrap do TestSprite
+
+```javascript
+testsprite_bootstrap({
+  localPort: 5173,  // Ajustar conforme detectado
+  type: "frontend", // Ou "backend" conforme detectado
+  projectPath: "$PROJECT_ROOT",
+  testScope: "diff" // Foca no arquivo específico
+})
+```
+
+### A.4. Gerar Sumário do Código
+
+```javascript
+testsprite_generate_code_summary({
+  projectRootPath: "$PROJECT_ROOT"
+})
+```
+
+### A.5. Gerar Plano de Testes
+
+Para Frontend:
+```javascript
+testsprite_generate_frontend_test_plan({
+  projectPath: "$PROJECT_ROOT",
+  needLogin: false // Ajustar se necessário
+})
+```
+
+Para Backend:
+```javascript
+testsprite_generate_backend_test_plan({
+  projectPath: "$PROJECT_ROOT"
+})
+```
+
+### A.6. Gerar e Executar Testes
+
+```javascript
+testsprite_generate_code_and_execute({
+  projectName: "$WORKSPACE",
+  projectPath: "$PROJECT_ROOT",
+  testIds: [], // Vazio = todos, ou especificar IDs
+  additionalInstruction: "Foco em testes unitários para: $ARGUMENTS"
+})
+```
+
+### A.7. Re-executar Testes (se necessário)
+
+```javascript
+testsprite_rerun_tests({
+  projectPath: "$PROJECT_ROOT"
+})
+```
+
+### A.8. Saída do TestSprite
+
+O TestSprite gera automaticamente:
+- `testsprite_tests/` - Pasta com todos os testes gerados
+- `TestSprite_MCP_Test_Report.md` - Relatório em Markdown
+- `TestSprite_MCP_Test_Report.html` - Relatório em HTML
+- `testsprite_tests/tmp/test_results.json` - Resultados detalhados
+
+---
+
+## FLUXO B: Geração Manual (Fallback)
+
+Se o TestSprite MCP NÃO estiver disponível, siga o fluxo manual abaixo.
+
+### Padrões Críticos (Fluxo Manual)
+
+#### Padrão 1: Detectar Framework de Teste
+
+```bash
+# JavaScript/TypeScript
+grep -E "(jest|vitest|mocha|jasmine)" package.json
+
+# Python
+ls pytest.ini pyproject.toml setup.cfg 2>/dev/null | head -1
+
+# Go - usa testing nativo
+```
+
+| Framework | Padrão de Arquivo | Import |
+|-----------|-------------------|--------|
+| Jest | `*.test.ts`, `*.spec.ts` | `import { describe, it, expect } from '@jest/globals'` |
+| Vitest | `*.test.ts`, `*.spec.ts` | `import { describe, it, expect } from 'vitest'` |
+| Pytest | `test_*.py`, `*_test.py` | `import pytest` |
+| Go | `*_test.go` | `import "testing"` |
+
+#### Padrão 2: Estrutura AAA (Arrange-Act-Assert)
+
+Todo teste deve seguir a estrutura AAA:
+
+```typescript
+describe('NomeDaFuncao', () => {
+  it('should [comportamento esperado] when [condição]', () => {
+    // Arrange - Preparar dados de entrada
+    const input = { ... };
+
+    // Act - Executar a função
+    const result = funcao(input);
+
+    // Assert - Verificar resultado
+    expect(result).toBe(esperado);
+  });
+});
+```
+
+#### Padrão 3: Cobertura Mínima de Cenários
+
+Todo teste deve cobrir:
+- Caminho feliz (happy path)
+- Casos de borda (edge cases)
+- Tratamento de erros
+- Valores nulos/undefined
+
+### Árvore de Decisão (Fluxo Manual)
+
+```
+Arquivo TypeScript?     → Jest ou Vitest (verificar package.json)
+Arquivo Python?         → Pytest
+Arquivo Go?             → testing nativo
+Arquivo Java?           → JUnit
+Caso contrário          → Perguntar ao usuário
+```
+
+### Fluxo de Trabalho (Manual)
+
+#### B.1. Analisar Arquivo de Origem
+
+```bash
+# Ler o arquivo para entender a estrutura
+cat $ARGUMENTS
+```
+
+Identificar:
+- Funções/métodos exportados
+- Dependências e imports
+- Tipos de entrada e saída
+- Possíveis cenários de teste
+
+#### B.2. Verificar Testes Existentes
+
+```bash
+# Verificar se já existe arquivo de teste
+ls ${ARGUMENTS%.ts}.test.ts 2>/dev/null || \
+ls ${ARGUMENTS%.ts}.spec.ts 2>/dev/null || \
+echo "Nenhum teste encontrado"
+```
+
+#### B.3. Criar Arquivo de Teste
+
+Criar o arquivo de teste seguindo:
+- Convenção de nomenclatura do projeto
+- Imports necessários
+- Mocks de dependências externas
+
+#### B.4. Implementar Testes
+
+Para cada função/método:
+1. Criar `describe` block
+2. Implementar casos de teste (happy path primeiro)
+3. Adicionar casos de borda
+4. Adicionar casos de erro
+
+#### B.5. Executar e Validar
+
+```bash
+# JavaScript/TypeScript
+npm test -- --testPathPattern={arquivo}
+
+# Python
+pytest {arquivo} -v
+
+# Go
+go test -v -run {funcao}
+```
+
+---
+
+## Regras
+
+### Nunca
+- Criar testes que dependem de estado externo
+- Usar dados de produção em testes
+- Ignorar casos de erro
+- Criar testes sem assertions
+- Usar `any` em mocks TypeScript
+- Pular a verificação do TestSprite MCP
+
+### Sempre
+- Verificar disponibilidade do TestSprite primeiro
+- Seguir estrutura AAA (no fluxo manual)
+- Nomear testes de forma descritiva
+- Isolar testes (não dependem uns dos outros)
+- Mockar dependências externas
+- Cobrir happy path + edge cases + errors
+
+---
+
+## Tratamento de Erros
+
+### Arquivo não encontrado
+- Exibir: "⚠️ Arquivo '{caminho}' não encontrado."
+- Verificar se o caminho está correto
+- Sugerir usar glob para encontrar arquivo
+
+### Framework não detectado
+- Exibir: "⚠️ Framework de teste não detectado."
+- Listar frameworks suportados
+- Perguntar ao usuário qual usar
+
+### Testes já existem
+- Exibir: "⚠️ Arquivo de teste já existe em '{caminho}'"
+- Perguntar se deseja sobrescrever ou adicionar novos testes
+
+### TestSprite falhou
+- Exibir: "⚠️ TestSprite retornou erro. Alternando para fluxo manual."
+- Continuar com Fluxo B automaticamente
+
+---
+
+## Checklist de Conclusão
+
+### Fluxo A (TestSprite)
+- [ ] TestSprite MCP verificado e disponível
+- [ ] Tipo de projeto detectado (frontend/backend)
+- [ ] Bootstrap executado com sucesso
+- [ ] Plano de testes gerado
+- [ ] Testes executados
+- [ ] Relatório gerado
+
+### Fluxo B (Manual)
+- [ ] Arquivo de origem analisado
+- [ ] Framework de teste identificado
+- [ ] Arquivo de teste criado no padrão correto
+- [ ] Todos os exports públicos testados
+- [ ] Happy path coberto
+- [ ] Edge cases cobertos
+- [ ] Casos de erro cobertos
+- [ ] Testes executados com sucesso
+- [ ] Sem warnings ou erros de tipo
+
+---
+
+## Output
+
+### Fluxo A (TestSprite MCP)
+
+| Artefato | Descrição |
+|----------|-----------|
+| `testsprite_tests/` | Pasta com testes gerados automaticamente |
+| `TestSprite_MCP_Test_Report.md` | Relatório em Markdown |
+| `TestSprite_MCP_Test_Report.html` | Relatório visual em HTML |
+| `testsprite_tests/tmp/test_results.json` | Resultados detalhados em JSON |
+
+### Fluxo B (Manual)
+
+| Artefato | Descrição |
+|----------|-----------|
+| `{arquivo}.test.ts` | Arquivo de teste unitário (TypeScript/Jest) |
+| `{arquivo}.spec.ts` | Arquivo de teste unitário (TypeScript/Vitest) |
+| `test_{arquivo}.py` | Arquivo de teste unitário (Python/Pytest) |
+| `{arquivo}_test.go` | Arquivo de teste unitário (Go) |
+
+---
+
+## Mensagem de Conclusão
+
+### Fluxo A (TestSprite)
+
+```
+Testes unitários gerados com TestSprite!
+
+Arquivo de origem: {caminho-origem}
+Método: TestSprite MCP (automático)
+Tipo: {frontend|backend}
+
+Artefatos gerados:
+- testsprite_tests/
+- TestSprite_MCP_Test_Report.md
+- TestSprite_MCP_Test_Report.html
+
+Próximo passo: Revisar o relatório em TestSprite_MCP_Test_Report.md
+```
+
+### Fluxo B (Manual)
+
+```
+Testes unitários criados manualmente!
+
+Arquivo de origem: {caminho-origem}
+Arquivo de teste: {caminho-teste}
+Framework: {framework}
+
+Cobertura:
+- [x] Funções testadas: {n}
+- [x] Casos de teste: {n}
+- [x] Happy path: {n}
+- [x] Edge cases: {n}
+- [x] Error cases: {n}
+
+Comando para executar:
+{comando-de-execução}
+
+Próximo passo: Executar os testes com o comando acima
+```
+
+---
+
+## Resumo dos Fluxos
+
+| Aspecto | Fluxo A (TestSprite) | Fluxo B (Manual) |
+|---------|---------------------|------------------|
+| Quando usar | TestSprite MCP disponível | TestSprite não instalado |
+| Automação | Total - gera e executa testes | Parcial - requer implementação |
+| Saída | Testes + Relatório HTML/MD | Arquivo de teste |
+| Esforço | Mínimo | Requer escrita manual |
+
+---
+
+## Recursos Adicionais
+
+- **Referências**: Ver [references/](references/) para guias de teste do projeto