Standards¶

VibeCode QA standards are the reviewable rules a project is judged against after its stack has been detected.

The important boundary is this: VibeCode QA does not re-create broad framework doctrine. React, TypeScript, WCAG, OWASP, Cloudflare, MCP, GitHub Actions, and other ecosystem authorities already publish the broad rules. VibeCode QA cites those sources, then owns the stack-specific glue:

• repository and slice shape
• runtime and deployment constraints
• detection mapping
• exception policy
• anti-patterns a scanner or AI judge should flag

upstream standards + stack items + deploy/runtime seams = VCQA rubric

How this section is organized¶

• References: official specs and primary-source docs to cite before writing a VibeCode QA rule.
• Assessment: criteria for judging rubrics, reference repos, and VCQA itself.
• Assessment reports: dated independent reports on standards pages and reference implementations.
• Compositions: the linked map of stack items and composed standards.
• Graph: navigable graph of stack standards, stack-item leaves, templates, and VCQA reports.
• Examples: real repositories mapped to authored standards and open gaps.
• Authoring: lifecycle and templates for creating new standards.
• Stack standards: authored rubrics and planned stack charters.
• Stack items: reusable building blocks and upstream ownership.

Authored Stack Rubrics¶

Authored Cross-Cutting Rubrics¶

Published Aliases¶

• react-spa-on-cloudflare-pages resolves to /standards/cloudflare-pages-fullstack/v1/. Aliases: pages-fullstack.

Planned Standards¶

Ranked by maturity state. Only a candidate rubric is close enough to a versioned standard to review a repository against; a backlog entry exists so the resolver names the right standard, and nothing more.

Catalog entry points¶

• Stack standards: authored stack rubrics and planned stack charters.
• Stack items: reusable framework, runtime, protocol, testing, CI, docs, and security leaves.
• Standards graph: linked map of authored stack rubrics, cross-cutting rubrics, planned stack charters, item leaves, templates, and VCQA reports.
• Assessment reports: dated reviews for every stack charter page.
• Examples: real repositories mapped to authored rubrics and planned gaps.

Worked examples¶

• Cloudflare SaaS app coverage: how a real React/Cloudflare/D1/MCP repository maps to authored standards, planned standards, and the next authoring gaps.

Reference implementations¶

Reference implementations are one public GitHub template repo per reusable stack archetype or high-value stack composition. The intent is not to generate every possible combination up front; it is to keep a curated set where each repo demonstrates a standard, carries CI, and tracks its own VCQA report.

These templates do not replace vendor starters. Use official React, Vite, Cloudflare, MCP, and other ecosystem docs for basic project creation. VCQA templates show the extra composition layer: how upstream guidance, deploy/runtime seams, CI evidence, runbooks, and VCQA reports fit together.

Scores marked self-reported come from the reference repo's own tracked VCQA report at the listed commit. They are not independent assessments; treat them as claims with a visible provenance trail, not as third-party proof.

Status notes:

• ref-firebase-react-fullstack: Experimental. This repo was published before any Firebase stack standard existed, and no authored or planned VCQA standard describes the Firebase + React shape today (flutter-firebase-app is planned, but it targets Flutter). It is cataloged as experimental evidence for the cross-cutting TypeScript, Testing, and Security rubrics only, and is not a reference implementation of a stack standard.
• ref-typescript-sdk: Published against a charter, not a versioned rubric: typescript-sdk is planned with maturity candidate-rubric, so the score is the CLI composite over the generic, TypeScript, Testing and Security checks rather than proof that the charter is satisfied. The repo's report does not map R-SDK-1 to R-SDK-12 rule by rule, which is what the charter's promotion criteria still require.
• ref-github-action-package: Published against a charter, not a versioned rubric: github-action-package is planned with maturity candidate-rubric, so the score is the CLI composite and the repo's R-GHA-1 to R-GHA-10 mapping is argued by hand rather than machine-checked. No vX.Y.Z or moving v1 tag has been pushed, so the release-tag rule is documented rather than exercised, and only the JavaScript runtime is covered.
• ref-zensical-kb-site: Experimental rather than published: zensical-kb-site is planned with maturity draft-charter and carries no numbered rules, so there is no rule set for this repo to be the reference implementation of. The score is the CLI composite over roughly 600 lines of checker scripts and says nothing about knowledge-base quality; the repo separately publishes a self-assessment against its own KB quality model, which is not a VCQA score and is not recorded here. External reachability checking runs in a separate weekly non-blocking workflow, so it is not part of the CI run cited above.
• ref-vscode-extension-package: Experimental rather than published on two counts: vscode-extension-package is planned with maturity backlog and carries no numbered rules, and the resolver cannot detect the archetype at all — standards/resolve.mjs classifies this repo as typescript-sdk (#47). The catalog will not call a repo the reference implementation of a standard that has no rules and cannot be recognised. Promote once both are fixed.
• ref-tauri-react-desktop: Experimental rather than published: tauri-react-desktop is planned with maturity draft-charter and carries no numbered rules, so the score is a composite over the generic, React SPA, TypeScript, Testing and Security checks rather than evidence that the standard is satisfied. Packaging is verified as tauri build --no-bundle on Linux, not as a signed bundle, and there is no end-to-end layer driving the packaged window: the capability policy is proven by static validation and by the absence of the plugin crates.
• ref-flutter-firebase-app: Not yet re-judged against the v1 rubric published under #43: its score was assessed against the earlier charter plus testing@v1 and security@v1, so it stays experimental until a scan against flutter-firebase-app@v1 replaces the evidence below. The score is also self-reported and was not independently reproducible -- a bare-environment scan without a Flutter SDK and resolved Dart dependencies returns 78/100 for the same commit, because the analyzer cannot resolve imports. Two resolver limitations recorded here have since been fixed, and this note no longer claims them: detection no longer depends on melos.yaml -- the predicate accepts either that file or a melos: key in the workspace-root pubspec.yaml, and slicing reads the Dart workspace: list, so a Melos 7+ workspace resolves identically (#48, fixed in 80eb195, both layouts covered by fixtures); and the Cloud Functions package no longer resolves as typescript-sdk, because that archetype now also requires package.json:types, which a Functions package does not declare (#49). The repo still pins Melos 6.3.2, but for production fidelity to the repo this stack was modelled on -- not to stay detectable; whether to unpin is open in #51. The mobile build check is a debug APK compile: release signing, R8, App Bundle and iOS are never built.

Next template candidates:

• None. Every reference repository the catalog names has been built and carries score evidence.

Machine-readable files¶

• /standards/references.json: external source registry.
• /standards/compositions.json: composition map with docs/rubric URLs.
• /standards/registry.json: current resolver catalog.

What gets born from combinations¶

Combination-born guidelines are the reason VCQA standards exist. Examples:

• React plus Vite plus static hosting: client env vars are public, and deep links require SPA fallback.
• React plus Cloudflare Pages Functions: /api/* routes need server-side auth middleware and must not collide with SPA routes.
• Cloudflare D1 plus GitHub Actions: migrations need a local apply check and production promotion gate.
• Workers plus MCP plus OAuth: tool schemas, scopes, and audit trails become part of the security standard.
• VS Code webviews plus React: CSP and message bridge limits are required beyond normal React guidance.