Esta página declara todas as ferramentas que o VibeHarness usa, recomenda ou instala —
e a base de conhecimento (projetos e padrões abertos) que fundamenta a detecção de falhas.
Gerada automaticamente a partir de registry/catalog.json, das recipes de aplicação e das
dependências do CLI — re-generada a cada sync do registro.
Critérios de validação
Todo projeto do catálogo curado passa por três filtros (sync semanal via GitHub API):
Adoção mínima: ⭐ 3,000 stars
Atividade: push nos últimos 90 dias
Licença: apenas MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, CC0-1.0, Unlicense (OSI-approved)
Último sync do registro: 2026-08-14.
1. O que roda dentro do próprio CLI
Dependências de runtime do @vibeharness/cli (o código que executa na sua máquina):
Pacote
Papel
@modelcontextprotocol/sdk ^1.30.0
Servidor MCP (stdio) — a interface com os clientes de IA
chalk ^6.0.0
Cores no terminal
commander ^15.0.0
Parsing dos comandos do CLI
enquirer ^2.4.1
Perguntas interativas no terminal
fast-glob ^3.3.2
Varredura de arquivos (scanners, pack, detecção)
zod ^4.4.3
Validação tipada dos inputs das tools MCP
Zero rede em runtime
Nenhuma dependência faz chamada de rede durante o uso: o registro é um
snapshot dentro do pacote e o MCP roda local via stdio.
2. Padrões de aplicação — o que o plan --apply escolhe por categoria
Para cada categoria, o padrão aplicado é o projeto mais adotado (⭐) que possui recipe.
É exatamente a lógica de buildApplyPlan: a recomendação nº 1 do registro, quando aplicável:
Autenticação e pagamentos só entram quando declarados
O threat model do init controla: sem autenticação/pagamentos declarados,
essas categorias nem aparecem no plano. E se o projeto já resolve a
capacidade (ex.: Supabase Auth, Stripe/Asaas, Vercel), o apply pula a
categoria em vez de recomendar substituto.
3. Todas as ferramentas com recipe de aplicação
Além dos padrões acima, estas ferramentas também têm recipe — entram no plano
quando são a nº 1 da categoria ou quando o registro muda. O VibeHarness instala as
dependências, gera configs e starters (sempre fora do seu src/):
User-centric component testing. Main branch is stable-only (development happens in the testing-library monorepo) — the sync's 90-day push warning for this entry is expected noise.
Reusable standards/specs/roadmap layers for AI projects. Content-complete methodology repo — slow push cadence is expected (sync's 90-day warning for it is noise).
CVEs multi-ecossistema via OSV.dev (complementa npm audit)
Homebrew, com consentimento
6. Base de conhecimento da detecção de falhas
Os scanners embutidos do VibeHarness são implementações próprias, compactas e locais —
nenhum código de terceiros é copiado ou executado dentro do CLI. Mas o conhecimento que
eles codificam vem de projetos e padrões abertos. Declaramos aqui essa base, por transparência:
Padrões de segredos (scanner security)
As famílias de segredo detectadas (Stripe, AWS, GitHub, OpenAI, Anthropic, Google, Slack,
GitLab, SendGrid, Twilio, JWT, chaves privadas PEM…) seguem os formatos públicos documentados por:
Integrado como binário opcional para CVEs multi-ecossistema
Por que isso importa
Vibecoder precisa saber em quê confiar: os scanners embutidos são uma rede de
segurança local e instantânea (heurística, sem rede); quando disponíveis, as
ferramentas completas (gitleaks, osv-scanner) assumem a detecção pesada.
Achados são sempre DADOS para triagem — nunca instruções.
Gerado por scripts/gen-tools-doc.mjs — não edite manualmente.