Global product audit and Nuxt module readiness — 0.1.29

Reference date: 28 June 2026
Audited version: QForm Builder Community 0.1.29

Executive conclusion

QForm Builder Community is no longer a prototype. The repository contains a complete visual builder, a runtime viewer, a frozen candidate public contract, exported pure engines, bilingual documentation and a substantial quality pipeline.

Scope	Status	Decision
Community features	Phase 2 scope complete	usable as a Nuxt Layer
Public API	candidate-frozen	stable enough for a second distribution
Nuxt Layer packaging	mature	keep as compatibility package
Nuxt module packaging	not implemented	M1 can start now
Immediate stable module release	premature	start as 0.x/alpha
Hidden Pro code in Community	none found	healthy open-core boundary
RC reproducibility	incomplete	refresh lockfile and confirm remote CI/browser evidence

Recommended decision: start a new module package under a different name now, without changing the functional contract and without deprecating the existing layer.

Verified inventory

The audited repository contains:

• 85 Vue components;
• 72 TypeScript files under app/;
• roughly 25,000 Vue/TypeScript/SCSS runtime lines;
• 51 Community elements;
• 24 FormKit/Quasar adapters;
• 29 props, 30 events and 27 public FormBuilder methods;
• 149 public types;
• 20 npm subpath exports;
• 9 E2E specs and 1 Playwright documentation spec;
• 22 playground pages;
• 82 FR/EN Markdown pages;
• 101 patch-memory documents;
• 335 files in the planned npm tarball.

Community features included

Community ships:

• Nuxt Layer integration through extends;
• standalone FormBuilder and FormViewer;
• multi-instance isolation;
• controlled schema, values, settings, theme and drawer state;
• imperative public API and rich events;
• 27 input fields, 19 static elements and 5 structures;
• root and recursive drag-and-drop;
• nested sections, fieldsets, columns, tabs and steps;
• responsive viewport simulation and column designer;
• editing/preview modes and live values panel;
• retained values after final submission;
• advanced steps/pages with blocking validation;
• recursive AND/OR conditions, simulator and trace;
• typed validation, guarded regex, cross-field rules and custom sync/async registry;
• visible history, undo/redo, branches and explicit restoration;
• advanced tree editing and keyboard reordering;
• Theme Builder with presets, tokens, gradients, motion, Quasar/Iconify icons and dark mode;
• four built-in templates and an extensible registry;
• schema and versioned document import/export;
• independent document/schema/theme migrations;
• public catalog, config-panel, locale, validation, template and theme extension points;
• keyboard accessibility, live regions, focus restoration and axe testing;
• Windows/Linux CI, SSR host build, bundle budget and verified npm artifact;
• bilingual VitePress documentation and automated illustrated guide.

Catalog details

27 fields: text, textarea, number, email, phone, password, URL, color, rich text, checkbox, toggle, checkbox group, radio group, select, multiselect, button toggle, date, multiple dates, date range, time, datetime, slider, range slider, rating, file, multifile and hidden.

19 static elements: submit/primary/secondary/destructive buttons, separator, spacer, H1–H6, paragraph, quote, link, image, information banner, warning banner and code block.

5 structures: section, fieldset, responsive columns, tabs and stepper/pages.

Managed by the repository but not delivered as end-user Community runtime features

No hidden licensed or commercial implementation was found. The repository does manage several concerns through tooling, extension contracts or documentation without delivering them as standalone runtime features:

• playground routes, E2E tests, SSR host fixture and CI workflows are repository tooling and are excluded from the npm runtime package;
• Feathers/NFZ persistence is documented and supported through events/documents, but no deployable service, Mongo model, RBAC hooks or Zod backend validation is shipped;
• QFile handles client-side selection and constraints, but not object storage, multipart upload, antivirus or signed URLs;
• async validation handlers are supported, but remote request orchestration is host-owned;
• buttons are configurable renderers, not a generic workflow engine;
• the SSR host build is tested, while the highly interactive builder should still be hydrated/client-wrapped according to the host architecture;
• extension registries are ready to receive Pro/business elements, rules, templates, themes and migrations, but that content is not embedded in Community.

Not implemented yet

• real Nuxt module entrypoint under modules;
• Zod to QForm schema adapter;
• JSON Schema import adapter;
• NFZ/Feathers service to form generation;
• form to CRUD service/page generation;
• Vue/TypeScript code export;
• headless canvas package;
• versioned business packs beyond four generic templates;
• Form generation from business descriptions;
• real-time collaboration;
• multi-actor publication/approval;
• persistent RBAC/audit/versioning backend;
• component marketplace;
• generic workflows/webhooks.

Community / Pro boundary

Community should keep the generic builder/viewer, catalog, structures, validation, conditions, history, tree, theme, migrations, extensibility and accessibility.

Separate Pro or business packages should contain Zod/NFZ adapters, CRUD generation, business packs, code/page export, workflows, collaboration, server governance and guided generation. Sensitive licensing, RBAC, audit, file storage, secrets and webhooks belong on a backend.

Documentation inconsistencies found

Historical pages had drifted from the runtime:

• the Pro roadmap still listed Theme Builder, advanced conditions, validation, templates and history even though they are Community features;
• the future module page still used installModule() and described completed features as future work;
• the Vueform comparison still claimed the project forced ssr:false, while the layer no longer does and an SSR host fixture is built.

Nuxt module readiness

Yes for M1, not yet for a stable release

The project can start module migration because the public API is frozen, pure engines and public types are separated, the runtime has no mandatory backend, extension points are present, and independent host/browser tests already exist.

The remaining module packaging work is:

1. refresh the stale Bun lockfile;
2. create a compiled src/module.ts entrypoint;
3. make FormKit adapter registration independent from layer #components scanning;
4. replace inherited layer auto-imports with explicit Nuxt Kit registration or direct imports;
5. register only intended public components globally;
6. use a module resolver for styles and runtime paths;
7. declare Pinia/FormKit/Quasar/UnoCSS as module dependencies/options;
8. publish compiled module/runtime output instead of raw layer entrypoints;
9. migrate package-name references while retaining layer compatibility;
10. test an installed module tarball in clean Nuxt applications on SSR, Windows and Linux.

Recommended architecture

packages/
├── qform-core/          # pure types and engines
├── qform-runtime/       # Vue/Quasar/FormKit runtime
├── nuxt-form-builder/   # Nuxt module
└── qform-builder-layer/ # temporary compatibility wrapper

playground/
docs/
tests/

A single module package with src/runtime/ is possible, but extracting the pure core provides a cleaner foundation for Pro and server adapters.

Recommended future name

Preferred generic package name:

@vevedh/nuxt-form-builder

Other branding options:

@vevedh/nuxt-form-studio
@vevedh/nuxt-schema-form
@vevedh/nfz-form-studio

The generic module should use @vevedh/nuxt-form-builder; NFZ Form Studio is better suited to a business edition. npm and trademark availability must be checked before publication.

Migration plan

• M0: freeze and validate the layer reference, lockfile, remote CI and screenshots.
• M1: create the official module skeleton and new package without functional changes.
• M2: move engines, types, runtime, stores, components, styles and FormKit registration.
• M3: add prefix, locale, CSS and separate Builder/Viewer options.
• M4: test installed tarballs, SSR, Windows/Linux and layer/module API parity.
• M5: publish module alpha, validate in a real product, then RC and stable.

Final verdict

The project is functionally ready to enter the module phase. The remaining risk is packaging and integration rather than missing builder features. Keep the layer stable, create a new module package, preserve the same runtime contract, and postpone Phase 3 features until module parity is proven.