Standards

This is the standards hub for VibeCode QA. It separates three things: authored rubrics, upstream authority references, and the composition plan that turns individual framework/platform docs into stack-specific VCQA standards.

How To Read This

VibeCode QA should not re-create generic React, TypeScript, OWASP, WCAG, Cloudflare, or MCP doctrine. Those sources already exist. VCQA standards cite them, then own the repo-shape and deploy-shape rules needed to judge real projects consistently.

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

Published Rubrics

Authoring Maps

Reference Implementations

Reference implementations are product-neutral GitHub template repos. They complement the rubrics: the standard defines the rules, and the repo shows a passing implementation with CI and a tracked VCQA report. The pathway is one curated template per reusable stack archetype or high-value composition, not every possible combination up front. They do not replace official vendor starters; they show the VCQA composition layer on top of those starters.

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

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](https://github.com/vibecodeqa/vibecodeqa/issues/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](https://github.com/vibecodeqa/vibecodeqa/issues/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](https://github.com/vibecodeqa/vibecodeqa/issues/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](https://github.com/vibecodeqa/vibecodeqa/issues/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](https://github.com/vibecodeqa/vibecodeqa/issues/51). The mobile build check is a debug APK compile: release signing, R8, App Bundle and iOS are never built.

Next candidates: none — every reference repository the catalog names has been built.

Next Standards To Author

Edition Policy

Authored rubrics are versioned on change, not dated. A new edition is cut only when the stack's best practice materially shifts. Each edition carries a review date so a scan can surface when a repo was judged against a stale rubric.

Run it yourself: npx @vibecodeqa/cli · Sources: references.json · compositions.json · registry.json