@fabioforest/openclaw 3.5.0 → 3.6.0

package/README.md

@@ -371,7 +371,7 @@ Verifica conectividade, proxy, versões e integridade do ambiente.
 
 ---
 
-## 🧠 Skills Disponíveis (15)
+## 🧠 Skills Disponíveis (21)
 
 ### Core — Infraestrutura do AI OS
 
@@ -386,6 +386,22 @@ Verifica conectividade, proxy, versões e integridade do ambiente.
 | `smart-router` | Roteador econômico | Para escolher modelo de IA por custo |
 | `context-flush` | Flush de memória | Para economizar tokens em sessões longas |
 
+### Engenharia de Software — Código, Testes e Qualidade
+
+| Skill | O que faz | Quando usar |
+|-------|-----------|-------------|
+| `code-quality` | SOLID, DRY, KISS, Clean Code | Para revisar e melhorar qualidade de código |
+| `legacy-cleanup` | Refatoração segura de legado | Para remover dead code, deps obsoletas |
+| `test-engineer` | Testes unitários/integração/E2E | Para criar e melhorar suite de testes |
+| `security-scanner` | SAST, DAST, OWASP Top 10 | Para auditoria de segurança e vulnerabilidades |
+
+### DevOps & MLOps — Infraestrutura e Machine Learning
+
+| Skill | O que faz | Quando usar |
+|-------|-----------|-------------|
+| `devops-toolkit` | Docker, CI/CD, K8s, Terraform | Para automação de infra e deploy |
+| `mlops-pipeline` | Treinamento, serving, RAG, drift | Para pipelines de ML em produção |
+
 ### Produtividade — Automação e Web
 
 | Skill | O que faz | Quando usar |
@@ -396,7 +412,7 @@ Verifica conectividade, proxy, versões e integridade do ambiente.
 | `web-scraper` | Scraping responsável | Para extrair dados de sites |
 | `content-sourcer` | Pesquisa de fontes | Para criar dossiês citáveis |
 
-### Operacionais — DevOps e Infra
+### Operacionais — Setup e Debug
 
 | Skill | O que faz | Quando usar |
 |-------|-----------|-------------|

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fabioforest/openclaw",
-  "version": "3.5.0",
+  "version": "3.6.0",
   "description": "Agentes autônomos para engenharia de software",
   "publishConfig": {
     "access": "public"

package/templates/.agent/skills/code-quality/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: code-quality
+description: Aplica boas práticas de código (SOLID, DRY, KISS, Clean Code). Analisa estilo, naming, estrutura, documentação e propõe melhorias.
+triggers:
+  - boas práticas
+  - code review
+  - clean code
+  - solid
+  - dry
+  - kiss
+  - qualidade de código
+  - code quality
+  - lint
+  - estilo
+  - naming
+  - convenção
+  - padrão de código
+  - documentação
+---
+
+# Code Quality
+
+## Objetivo
+Garantir que o código siga boas práticas reconhecidas (SOLID, DRY, KISS, Clean Code), com foco em legibilidade, manutenibilidade e consistência.
+
+## Contexto necessário
+- Linguagem/framework do projeto
+- Guia de estilo existente (se houver)
+- Foco: revisão geral ou área específica
+
+## Fluxo (inspect → plan → consent → apply → audit)
+
+1. **INSPECT** (read-only):
+   - Verificar configuração de linter/formatter existente
+   - Analisar convenções de naming (camelCase, snake_case, PascalCase)
+   - Detectar violações de SOLID:
+     - **S**ingle Responsibility: classes/funções com mais de 1 responsabilidade
+     - **O**pen/Closed: código que exige modificação para extensão
+     - **L**iskov Substitution: subclasses que quebram contratos
+     - **I**nterface Segregation: interfaces muito grandes
+     - **D**ependency Inversion: dependências concretas no lugar de abstrações
+   - Detectar violações de DRY (duplicações)
+   - Verificar documentação (JSDoc, docstrings, README)
+   - Medir tamanho de funções/classes (threshold: 200 linhas/arquivo, 30 linhas/função)
+
+2. **PLAN** — Propor melhorias categorizadas:
+
+   | Categoria | Exemplo |
+   |-----------|---------|
+   | 📝 Naming | `data` → `userProfiles`, `fn` → `calculateDiscount` |
+   | 📦 Estrutura | Extrair classe com 500 linhas em 3 módulos |
+   | 📖 Documentação | Adicionar JSDoc em funções públicas |
+   | 🔧 Linting | Configurar ESLint/Prettier/Ruff/Black |
+   | 🧪 Testabilidade | Injetar dependências para facilitar mocks |
+
+3. **CONSENT**: Confirmar antes de aplicar
+4. **APPLY**: Gerar patches unificados para cada melhoria
+5. **AUDIT**: Registrar métricas antes/depois
+
+## Checklists por cenário
+
+### Criando código novo
+- [ ] Nomes descritivos (sem abreviações crípticas)
+- [ ] Funções com no máximo 30 linhas e 1 responsabilidade
+- [ ] Arquivos com no máximo 200-300 linhas
+- [ ] Sem dados simulados fora de testes
+- [ ] Comentários explicam "por quê", não "o quê"
+- [ ] Tratamento de erros com mensagens úteis
+- [ ] Tipos/interfaces/schemas definidos
+
+### Revisando código existente
+- [ ] Sem variáveis não utilizadas
+- [ ] Sem imports não utilizados
+- [ ] Sem TODO/FIXME sem prazo
+- [ ] Sem console.log/print de debug em produção
+- [ ] Sem credenciais hardcoded
+- [ ] Sem números mágicos (extrair constantes)
+- [ ] Sem funções com mais de 3 níveis de aninhamento
+
+## Ferramentas recomendadas
+
+| Categoria | JavaScript/TS | Python | Go |
+|-----------|--------------|--------|-----|
+| Linter | ESLint | Ruff, Pylint | golangci-lint |
+| Formatter | Prettier | Black, Ruff format | gofmt |
+| Type check | TypeScript | mypy, pyright | built-in |
+| Docs | JSDoc, TypeDoc | Sphinx, mkdocs | godoc |
+| Complexidade | ESLint complexity | radon | gocyclo |
+
+## Regras de segurança
+- ✅ Nunca alterar lógica de negócio durante refatoração de estilo
+- ✅ Commits separados: formatação vs refatoração vs lógica
+- ❌ Nunca introduzir um novo padrão sem remover o antigo

package/templates/.agent/skills/devops-toolkit/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: devops-toolkit
+description: Automação de infraestrutura, CI/CD, containerização, monitoramento e deploy. Suporte a Docker, GitHub Actions, Terraform, Ansible e Kubernetes.
+triggers:
+  - devops
+  - ci/cd
+  - pipeline
+  - deploy
+  - docker
+  - dockerfile
+  - docker-compose
+  - kubernetes
+  - k8s
+  - terraform
+  - ansible
+  - github actions
+  - gitlab ci
+  - infraestrutura
+  - infra
+  - monitoramento
+  - observabilidade
+  - nginx
+  - proxy reverso
+  - ssl
+  - https
+---
+
+# DevOps Toolkit
+
+## Objetivo
+Automatizar infraestrutura, CI/CD, containerização, monitoramento e deploy seguindo boas práticas de Infrastructure as Code (IaC) e GitOps.
+
+## Contexto necessário
+- Provedor de cloud (AWS, GCP, Azure, VPS, local)
+- Ferramenta de CI/CD em uso (GitHub Actions, GitLab CI, Jenkins)
+- Stack do projeto (linguagem, framework, banco de dados)
+- Ambiente alvo (dev, staging, prod)
+
+## Fluxo (inspect → plan → consent → apply → verify → audit)
+
+1. **INSPECT**: Analisar infra existente (Dockerfile, compose, CI configs, deploy scripts)
+2. **PLAN**: Propor melhorias com diagrama de arquitetura
+3. **CONSENT**: Confirmar antes de qualquer alteração em infra
+4. **APPLY**: Gerar/modificar configs
+5. **VERIFY**: Testar build, healthcheck, deploy em staging
+6. **AUDIT**: Registrar mudanças de infra
+
+## Capacidades
+
+### 🐳 Containerização
+- Criar/otimizar Dockerfiles (multi-stage builds, cache layers)
+- Docker Compose para desenvolvimento local
+- Boas práticas: non-root user, .dockerignore, health checks
+- Reduzir tamanho de imagem (Alpine, distroless, slim)
+
+### 🔄 CI/CD Pipelines
+- GitHub Actions (workflows, matrix, caching, secrets)
+- GitLab CI (stages, artifacts, environments)
+- Estratégias: lint → test → build → deploy
+- Cache de dependências para acelerar builds
+- Deploy com rollback automático
+
+### ☁️ Infrastructure as Code
+- Terraform: providers, modules, state management
+- Ansible: playbooks, roles, inventários
+- Kubernetes: manifests, Helm charts, kustomize
+
+### 📊 Monitoramento e Observabilidade
+- Healthchecks e readiness probes
+- Logging estruturado (JSON, correlação de requests)
+- Métricas (Prometheus, Grafana, Datadog)
+- Alertas baseados em SLOs/SLIs
+
+### 🔒 Segurança de Infra
+- Scan de vulnerabilidades em imagens Docker (Trivy, Snyk)
+- Secrets management (Vault, SOPS, GitHub Secrets)
+- Network policies e firewall rules
+- TLS/SSL com renovação automática (Let's Encrypt, Certbot)
+
+## Checklists
+
+### Dockerfile
+- [ ] Multi-stage build (builder + runner)
+- [ ] Usuário non-root
+- [ ] .dockerignore configurado
+- [ ] HEALTHCHECK definido
+- [ ] Apenas dependências de produção na imagem final
+- [ ] Layers ordenadas por frequência de mudança (cache)
+
+### CI/CD Pipeline
+- [ ] Lint e testes rodam em cada PR
+- [ ] Build e push de imagem em merge na main
+- [ ] Deploy automático em staging, manual em prod
+- [ ] Cache de dependências configurado
+- [ ] Secrets não expostos em logs
+- [ ] Rollback automático se healthcheck falhar
+
+### Deploy em Produção
+- [ ] Blue-green ou canary deployment
+- [ ] Database migrations antes do deploy
+- [ ] Backup antes de mudanças destrutivas
+- [ ] Monitoramento ativo pós-deploy (5-15 min)
+- [ ] Runbook de rollback documentado
+
+## Regras de segurança
+- ✅ Nunca commitar secrets no repositório
+- ✅ Testar em staging antes de prod
+- ✅ Infraestrutura versionada no Git (IaC)
+- ❌ Nunca fazer deploy direto em prod sem pipeline
+- ❌ Nunca rodar containers como root em produção

package/templates/.agent/skills/legacy-cleanup/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: legacy-cleanup
+description: Analisa e refatora código legado de forma segura. Identifica dead code, dependências obsoletas, padrões deprecados e propõe modernização incremental.
+triggers:
+  - código legado
+  - legacy
+  - refatorar
+  - dead code
+  - código morto
+  - deprecado
+  - obsoleto
+  - modernizar
+  - dívida técnica
+  - technical debt
+  - cleanup
+  - limpar código
+---
+
+# Legacy Cleanup
+
+## Objetivo
+Identificar e remover código legado, dead code, dependências obsoletas e padrões deprecados de forma **segura e incremental**, sem quebrar funcionalidades existentes.
+
+## Contexto necessário
+- Linguagem/framework do projeto
+- Se há testes automatizados (cobertura atual)
+- Áreas prioritárias (ou análise completa)
+- Tolerância a risco (conservador vs agressivo)
+
+## Fluxo (inspect → plan → consent → apply → verify → audit)
+
+1. **INSPECT** (read-only):
+   - Identificar dead code (funções/classes/módulos não referenciados)
+   - Listar dependências sem uso no `package.json` / `requirements.txt` / `Gemfile`
+   - Detectar padrões deprecados (callbacks → promises, var → const/let, etc.)
+   - Mapear duplicações (DRY violations)
+   - Verificar TODOs/FIXMEs/HACKs antigos
+   - Medir complexidade ciclomática por arquivo
+
+2. **PLAN** — Propor ações categorizadas por risco:
+
+   | Risco | Ação | Exemplo |
+   |-------|------|---------|
+   | 🟢 Baixo | Remover imports não usados | `import * as _ from 'lodash'` sem uso |
+   | 🟡 Médio | Remover funções sem referência | Função helper nunca chamada |
+   | 🔴 Alto | Substituir padrão arquitetural | Migrar callbacks → async/await |
+
+3. **CONSENT**: Confirmar cada categoria de risco separadamente
+4. **APPLY**: Executar refatorações + rodar testes após cada batch
+5. **VERIFY**: Confirmar que testes passam e build funciona
+6. **AUDIT**: Registrar métricas antes/depois (linhas, complexidade, dependências)
+
+## Ferramentas recomendadas por linguagem
+
+| Linguagem | Dead code | Deps não usadas | Complexidade |
+|-----------|-----------|-----------------|-------------|
+| JavaScript/TS | `ts-prune`, ESLint `no-unused-vars` | `depcheck` | `plato`, ESLint |
+| Python | `vulture`, `pylint` | `pip-autoremove` | `radon`, `flake8` |
+| Go | `deadcode`, `staticcheck` | `go mod tidy` | `gocyclo` |
+| Java | IntelliJ inspections, `spotbugs` | Maven dependency plugin | `PMD` |
+
+## Regras de segurança
+- ✅ Sempre rodar testes antes E depois de cada refatoração
+- ✅ Commits atômicos (1 refatoração = 1 commit)
+- ✅ Nunca remover código que tenha referência dinâmica sem confirmar
+- ❌ Nunca refatorar sem testes que cubram a área alterada
+- ❌ Nunca misturar refatoração com mudança de lógica de negócio

package/templates/.agent/skills/mlops-pipeline/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: mlops-pipeline
+description: Boas práticas de MLOps — treinamento, versionamento de modelos, deploy de ML, monitoramento de drift, pipelines de dados e feature stores.
+triggers:
+  - mlops
+  - machine learning
+  - modelo
+  - treinamento
+  - training
+  - deploy de modelo
+  - model serving
+  - feature store
+  - data pipeline
+  - drift
+  - experiment tracking
+  - mlflow
+  - wandb
+  - kubeflow
+  - bentoml
+  - rag
+  - fine-tuning
+  - embeddings
+  - vetor
+  - vector database
+---
+
+# MLOps Pipeline
+
+## Objetivo
+Implementar e gerenciar pipelines de Machine Learning em produção, cobrindo todo o ciclo: dados → treinamento → avaliação → deploy → monitoramento → retraining.
+
+## Contexto necessário
+- Tipo de modelo (classificação, NLP, visão, LLM, recomendação)
+- Framework (PyTorch, TensorFlow, scikit-learn, HuggingFace)
+- Infraestrutura (local, cloud, GPU)
+- Estágio atual (exploração, staging, produção)
+
+## Fluxo (inspect → plan → consent → apply → verify → audit)
+
+1. **INSPECT**: Analisar pipeline existente, dados, modelos e infra
+2. **PLAN**: Propor arquitetura MLOps com componentes necessários
+3. **CONSENT**: Confirmar custos de compute e storage
+4. **APPLY**: Implementar/modificar pipeline
+5. **VERIFY**: Validar métricas, latência, throughput
+6. **AUDIT**: Registrar experimentos, versões e decisões
+
+## Capacidades
+
+### 📊 Experiment Tracking
+- MLflow: experiments, runs, parâmetros, métricas, artefatos
+- Weights & Biases (W&B): tracking, sweeps, reports
+- Comparação entre runs e reprodutibilidade
+
+### 📦 Versionamento de Modelos e Dados
+- DVC: versionamento de datasets grandes
+- MLflow Model Registry: staging → production
+- Git LFS para artefatos pesados
+- Hashes de datasets para reprodutibilidade
+
+### 🔄 Pipelines de Treinamento
+- Orquestração: Airflow, Prefect, Kubeflow Pipelines
+- Feature engineering automatizado
+- Validação de dados (Great Expectations, Pandera)
+- Hyperparameter tuning (Optuna, Ray Tune)
+
+### 🚀 Model Serving
+- APIs REST/gRPC: FastAPI + ONNX, TorchServe, TF Serving
+- BentoML: empacotamento e deploy de modelos
+- Serverless: AWS Lambda + SageMaker, GCP Cloud Functions
+- Edge: ONNX Runtime, TensorFlow Lite
+
+### 🔍 Monitoramento em Produção
+- Data drift detection (Evidently, NannyML)
+- Model performance monitoring (accuracy decay)
+- Latência e throughput (P50, P95, P99)
+- Alertas para retraining automático
+
+### 🧠 LLM Ops (RAG, Fine-tuning, Agents)
+- RAG pipelines: embeddings → vector DB → retrieval → generation
+- Vector databases: Qdrant, ChromaDB, Pinecone, Weaviate
+- Fine-tuning: LoRA, QLoRA, em GPUs de consumo
+- Avaliação de LLMs: BLEU, ROUGE, human eval, LLM-as-judge
+- Guardrails: content filtering, prompt injection detection
+
+## Checklists
+
+### Antes de treinar
+- [ ] Dados validados (schema, distribuição, missing values)
+- [ ] Split reprodutível (train/val/test com seed fixa)
+- [ ] Baseline definido (modelo simples para comparação)
+- [ ] Métricas de avaliação escolhidas e documentadas
+- [ ] Experiment tracking configurado
+
+### Antes de deploy
+- [ ] Modelo versionado com metadados (hash, métricas, dataset)
+- [ ] Testes de integração (input → output esperado)
+- [ ] Benchmark de latência e throughput
+- [ ] Fallback definido (modelo anterior ou regra heurística)
+- [ ] Monitoramento de drift configurado
+
+### Em produção
+- [ ] Alertas para degradação de performance
+- [ ] Pipeline de retraining automatizado ou semi-automático
+- [ ] A/B testing ou shadow mode para novos modelos
+- [ ] Logs de predições para auditoria e debugging
+- [ ] Custo de compute monitorado
+
+## Regras de segurança
+- ✅ Dados sensíveis devem ser anonimizados/mascarados antes de treinar
+- ✅ Modelos devem ser escaneados para bias antes de deploy
+- ✅ API keys de provedores de LLM devem usar secret management
+- ❌ Nunca expor endpoints de model serving sem autenticação
+- ❌ Nunca treinar com dados de produção sem aprovação de compliance

package/templates/.agent/skills/security-scanner/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: security-scanner
+description: Análise de segurança de código e infraestrutura — SAST, DAST, dependency audit, secrets scanning, OWASP Top 10 e hardening.
+triggers:
+  - segurança
+  - security
+  - vulnerabilidade
+  - cve
+  - owasp
+  - pentest
+  - scan
+  - auditoria de segurança
+  - secrets
+  - injection
+  - xss
+  - csrf
+  - sql injection
+  - hardening
+  - sast
+  - dast
+  - dependências vulneráveis
+---
+
+# Security Scanner
+
+## Objetivo
+Identificar vulnerabilidades de segurança no código, dependências e infraestrutura, seguindo OWASP Top 10 e boas práticas de AppSec.
+
+## Contexto necessário
+- Linguagem/framework do projeto
+- Tipo de aplicação (web, API, mobile, CLI)
+- Ambiente (dev, staging, prod)
+- Requisitos de compliance (SOC2, LGPD, PCI-DSS, HIPAA)
+
+## Fluxo (inspect → plan → consent → apply → verify → audit)
+
+1. **INSPECT** (read-only):
+   - Scan de dependências (CVEs conhecidos)
+   - Busca de secrets no código (API keys, senhas, tokens)
+   - Análise estática (SAST): injection, XSS, CSRF
+   - Verificação de configuração (CORS, headers, CSP)
+   - Análise de Dockerfile/compose (imagem base, root, ports)
+
+2. **PLAN** — Relatório de vulnerabilidades por severidade:
+
+   | Severidade | Exemplo | Ação |
+   |-----------|---------|------|
+   | 🔴 Crítica | SQL injection, secret exposto | Fix imediato |
+   | 🟠 Alta | Dependência com CVE alto | Update urgente |
+   | 🟡 Média | CORS permissivo, headers faltando | Planejar fix |
+   | 🟢 Baixa | Versão desatualizada sem CVE | Monitorar |
+
+3. **CONSENT**: Confirmar correções propostas
+4. **APPLY**: Aplicar fixes + atualizar dependências
+5. **VERIFY**: Re-scan para confirmar correção
+6. **AUDIT**: Relatório de segurança antes/depois
+
+## Capacidades
+
+### 🔍 SAST (Static Application Security Testing)
+- Análise de código sem executar
+- Detecção de injection (SQL, NoSQL, command, LDAP)
+- Cross-Site Scripting (XSS) e Cross-Site Request Forgery (CSRF)
+- Insecure deserialization
+- Path traversal e file inclusion
+
+### 📦 Dependency Audit
+- `npm audit` / `yarn audit` (JavaScript)
+- `pip-audit` / `safety` (Python)
+- `cargo audit` (Rust)
+- `go vuln check` (Go)
+- Snyk, Dependabot, Renovate para automação
+
+### 🔑 Secrets Scanning
+- Busca de: API keys, passwords, tokens, private keys, connection strings
+- Ferramentas: gitleaks, truffleHog, detect-secrets
+- Verificação em histórico do Git (commits antigos)
+- Pre-commit hooks para prevenir novos leaks
+
+### 🌐 DAST (Dynamic Application Security Testing)
+- Scan de endpoint em runtime
+- Ferramentas: OWASP ZAP, Nuclei, Burp Suite
+- Verificação de headers de segurança (CSP, HSTS, X-Frame-Options)
+- Teste de rate limiting e brute force
+
+### 🏗️ Infrastructure Security
+- Scan de imagens Docker (Trivy, Grype)
+- Verificação de configuração cloud (Checkov, ScoutSuite)
+- Network security (ports expostas, firewall rules)
+- TLS/SSL assessment (testssl.sh, SSL Labs)
+
+## OWASP Top 10 — Checklist
+
+- [ ] **A01 Broken Access Control**: Verificar RBAC, IDOR, path traversal
+- [ ] **A02 Cryptographic Failures**: TLS, hashing de senhas (bcrypt/argon2), encryption at rest
+- [ ] **A03 Injection**: SQL, NoSQL, OS command, LDAP, XSS
+- [ ] **A04 Insecure Design**: Threat modeling, abuse cases
+- [ ] **A05 Security Misconfiguration**: Default configs, debug mode em prod, headers
+- [ ] **A06 Vulnerable Components**: Dependencies com CVEs, EOL libraries
+- [ ] **A07 Authentication Failures**: MFA, session management, brute force protection
+- [ ] **A08 Data Integrity Failures**: CI/CD security, deserialization, updates sem verificação
+- [ ] **A09 Logging Failures**: Logs sem dados sensíveis, monitoramento de atividade suspeita
+- [ ] **A10 SSRF**: Validação de URLs, allowlists de destinos
+
+## Ferramentas recomendadas
+
+| Categoria | Ferramenta | Linguagem |
+|-----------|-----------|-----------|
+| SAST | Semgrep, CodeQL, SonarQube | Multi-linguagem |
+| Deps | npm audit, pip-audit, Snyk | JS, Python, multi |
+| Secrets | gitleaks, truffleHog | Qualquer |
+| DAST | OWASP ZAP, Nuclei | Web apps |
+| Docker | Trivy, Grype | Containers |
+| Infra | Checkov, tfsec | Terraform, Cloud |
+
+## Regras de segurança
+- ✅ Scan de segurança deve rodar no CI/CD em cada PR
+- ✅ Vulnerabilidades críticas bloqueiam merge
+- ✅ Secrets encontrados devem ser revogados IMEDIATAMENTE
+- ❌ Nunca ignorar CVEs críticos sem justificativa documentada
+- ❌ Nunca publicar relatório de segurança detalhado em canal público

package/templates/.agent/skills/test-engineer/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: test-engineer
+description: Criação e melhoria de testes (unitários, integração, E2E, performance). Cobertura, TDD, mocking, fixtures e estratégias de teste.
+triggers:
+  - teste
+  - test
+  - tdd
+  - unitário
+  - integração
+  - e2e
+  - end-to-end
+  - cobertura
+  - coverage
+  - mock
+  - fixture
+  - pytest
+  - jest
+  - vitest
+  - playwright
+  - cypress
+  - benchmark
+  - performance test
+  - load test
+---
+
+# Test Engineer
+
+## Objetivo
+Criar, melhorar e manter testes robustos (unitários, integração, E2E, performance), garantindo cobertura adequada e confiança no deploy.
+
+## Contexto necessário
+- Linguagem/framework do projeto
+- Framework de teste existente (Jest, Vitest, Pytest, Go test)
+- Cobertura atual (se disponível)
+- Áreas prioritárias ou código novo
+
+## Fluxo (inspect → plan → consent → apply → verify → audit)
+
+1. **INSPECT** (read-only):
+   - Verificar framework de teste configurado
+   - Medir cobertura atual por módulo
+   - Identificar áreas sem testes (módulos críticos)
+   - Listar funcionalidades sem cobertura E2E
+
+2. **PLAN** — Estratégia de testes por camada:
+
+   | Camada | Proporção (Pirâmide) | Framework sugerido |
+   |--------|---------------------|-------------------|
+   | Unitários | ~70% | Jest, Vitest, Pytest, Go test |
+   | Integração | ~20% | Supertest, httpx, testcontainers |
+   | E2E | ~10% | Playwright, Cypress |
+
+3. **CONSENT**: Confirmar escopo dos testes a criar
+4. **APPLY**: Gerar testes + fixtures + mocks
+5. **VERIFY**: Rodar testes, verificar cobertura
+6. **AUDIT**: Registrar métricas de cobertura antes/depois
+
+## Capacidades
+
+### 🧪 Testes Unitários
+- Testes isolados de funções/classes
+- Mocking de dependências externas (APIs, DB, FS)
+- Parametrização para múltiplos cenários
+- Edge cases: null, undefined, empty, overflow, unicode
+- Padrão AAA: Arrange → Act → Assert
+
+### 🔗 Testes de Integração
+- Testes de endpoints API (request → response)
+- Testes com banco de dados real (testcontainers)
+- Testes de filas/eventos (pub/sub, webhooks)
+- Testes de contratos (consumer-driven contracts)
+
+### 🌐 Testes E2E (End-to-End)
+- Fluxos críticos de usuário (login, checkout, signup)
+- Testes visuais (screenshot comparison)
+- Testes cross-browser (Chrome, Firefox, Safari)
+- Testes de acessibilidade (axe-core)
+
+### ⚡ Testes de Performance
+- Load testing (k6, Artillery, Locust)
+- Benchmark de funções críticas
+- Testes de latência e throughput
+- Stress testing e limites de escalabilidade
+
+### 📊 Cobertura e Métricas
+- Cobertura de linhas, branches, funções
+- Mutation testing (Stryker, mutmut) para medir qualidade dos testes
+- Relatórios de tendência (cobertura ao longo do tempo)
+
+## Checklists
+
+### Escrevendo testes unitários
+- [ ] Nome descritivo: `should_return_error_when_input_is_empty`
+- [ ] Um assert por teste (preferencialmente)
+- [ ] Sem dependência de estado externo (DB, rede, FS)
+- [ ] Mocks com reset/cleanup entre testes
+- [ ] Cobrir happy path + edge cases + error cases
+- [ ] Sem sleep/wait — usar async assertions
+
+### Escrevendo testes E2E
+- [ ] Testar fluxo completo, não fragmentos
+- [ ] Usar page objects / fixtures reutilizáveis
+- [ ] Screenshots em caso de falha
+- [ ] Retry para flakiness controlado
+- [ ] Dados de teste isolados (seed + cleanup)
+
+### Antes de deploy
+- [ ] Todos os testes passam
+- [ ] Cobertura mínima atendida (ex: 80%+)
+- [ ] Nenhum teste flaky (intermitente)
+- [ ] Testes de regressão validam fix de bugs anteriores
+- [ ] Performance baseline mantida
+
+## Ferramentas recomendadas
+
+| Tipo | JavaScript/TS | Python | Go |
+|------|--------------|--------|-----|
+| Unitário | Jest, Vitest | Pytest | testing |
+| API | Supertest | httpx, pytest-httpx | net/http/httptest |
+| E2E | Playwright, Cypress | Playwright | chromedp |
+| Performance | k6, Artillery | Locust | go-wrk |
+| Cobertura | c8, istanbul | coverage.py | go test -cover |
+| Mutation | Stryker | mutmut | go-mutesting |
+
+## Regras de segurança
+- ✅ Testes nunca devem conter dados reais de produção
+- ✅ Fixtures devem usar dados sintéticos (faker, factory)
+- ❌ Nunca desabilitar testes que falham — investigar e corrigir
+- ❌ Nunca testar contra APIs de produção (usar mocks ou staging)