Skip to content

Supported stacks

VibeCode QA auto-detects your stack from package.json, pubspec.yaml, lockfiles, and config files — no flags required.

Languages & frameworks

  • Frameworks: React, Vue (.vue SFC), Svelte (.svelte SFC), Next.js, Nuxt, SvelteKit
  • Type checking: tsc --noEmit (per-package in monorepos)
  • Lint: Biome or ESLint, auto-detected
  • Single-file components have their <script> extracted for complexity, duplication, error handling, and the import graph.
  • Analysis: dart analyze
  • Tests: flutter_test, _test.dart convention
  • Type safety: dynamic, missing late, and more
  • Complexity, duplication, error handling, secrets, security, architecture, confusion, context, docs, best practices, and performance all run on Dart code.

Monorepos

Workspaces are detected and checks run per-package where it matters (types, lint):

  • pnpm / npm / yarn workspaces
  • Lerna, Turborepo, Nx
  • Melos (Dart)

What adapts per stack

Concern TypeScript/JS Dart/Flutter
Type errors tsc --noEmit dart analyze
Tests vitest / jest flutter_test
Lint Biome / ESLint dart analyze
Test convention *.test.ts *_test.dart
Components .vue / .svelte SFC widgets

If a check doesn't apply to your stack, it's skipped and excluded from the score rather than counted against you.

Standards

Detection is only half the story - once VibeCode QA knows what your code is, it judges it against a published, reviewable standard, not against a model's memory.

Each authored standard is a versioned, reviewable rubric where every rule has a stable ID (R-<AREA>-n), the reason it exists, examples, and a machine-readable detection signal. VibeCode QA does not re-create generic React, TypeScript, OWASP, WCAG, Cloudflare, or MCP doctrine. It cites those upstream standards, then authors the stack-specific or cross-cutting glue: repo shape, runtime/deploy constraints, detection mapping, exception policy, and anti-patterns.

Authored stack rubrics

  • React SPA v1 - React, client-rendered, hosted as static files. No SSR, no server of its own.
  • Cloudflare Pages Fullstack v1 - Server-side API co-deployed with a static frontend as Cloudflare Pages Functions. Edge runtime, bindings, no long-lived server. Also cataloged as react-spa-on-cloudflare-pages.
  • Cloudflare D1 App v1 - SQLite-at-the-edge: schema, migrations discipline, parameterized queries, local/remote parity.
  • Cloudflare Worker MCP Server v1 - A remote MCP server hosted on Cloudflare Workers, with Worker-bound authorization, tool schemas, validation, storage boundaries, and auditability.
  • Tenant-Deployed Cloudflare SaaS v1 - A tenant-scoped Cloudflare SaaS deployment model composing Pages Functions, D1, Worker MCP, bindings, secrets, aliases, promotion gates, provisioning, and auditability.
  • Flutter Firebase App v1 - Flutter app/admin/shared workspace backed by Firebase Auth, Firestore, Storage, Messaging, Hosting, and Cloud Functions, with Melos orchestration and deploy/test gates.

Authored cross-cutting rubrics

  • Security v1 - Secrets handling, input validation, XSS/injection, dependency supply chain.
  • Testing v1 - Behavior-focused test strategy, required test layers, coverage risk, CI evidence, and fake/flaky test controls.
  • TypeScript v1 - Strict flags, project references, no-any, typed-and-validated boundaries.

The public catalog starts at Standards. Use Stack standards for deployable stack charters, Stack items for reusable leaves, Graph for the composed map, and Assessment reports for the dated page reviews.

Machine-readable files live at /standards/references.json, /standards/compositions.json, and /standards/registry.json.