Package map

Choose packages by the job they do. Your product owns its model and integrations; shared packages carry that model into storage, APIs, and screens.

1. Assemble the model

Declare → contribute → assemble → validate.

A Blueprint groups modules. Modules own entities; descriptors add capabilities to existing entities. Blueprint.assemble() composes them into an EffectiveBlueprint, including the origins of contributed members. Validation checks the model; assembly alone is not proof of validity.

This is model assembly, not database installation or server startup. The current runtime assembles its model when constructed and shares it with persistence. Assembly is not a global “run once on page load” hook.

2. Host it and connect clients

The protocol is the shared language, not another running service between client and server. The client sends requests; the server enforces rules and returns results. Blueprint UI adapts metadata and results into Studio screens.

During server startup, the Blueprint plugin resolves configured targets, validates the combined declaration, and checks required bindings. Installing database artifacts is a separate operation. Opening a client page does not install or reconfigure the server.

3. Keep package dependencies separate

• Server and client both depend on vyuh_blueprint_protocol.
• Server and client also use vyuh_blueprint model types.
• The protocol package does not depend on server, client, or Flutter.
• Blueprint UI uses the client and maps model metadata into Studio contracts.
• Studio owns generic UI; CDX supplies underlying controls and view engines.
• The CLI manages local processes, SQL generation, and product migrations.

These are library responsibilities, not a deployment sequence.

Core packages

Package	Use it for
vyuh_blueprint	Entities, facets, descriptors, assembly, and validation
vyuh_blueprint_server	Run the API and enforce actions against configured providers
vyuh_blueprint_protocol	Shared request, response, metadata, and error contracts
vyuh_blueprint_client	Call the API from Dart; no Flutter dependency
vyuh_blueprint_ui	Map Blueprint metadata and runtime state into application shells, workspaces, editors, and collections
vyuh_blueprint_cli	Run local services, emit SQL, and cut and deploy product migrations

Add capabilities when needed

Package	Responsibility
vyuh_blueprint_auth	Authentication adapters and authoritative session routes
vyuh_iam	Identity and access-management contracts
vyuh_blueprint_storage	Pure Dart file storage: object stores, upload rules, signed links, and the ledger and processor ports; see File storage
vyuh_query	Typed queries shared across layers
vyuh_query_cache	Query caching and invalidation
vyuh_blueprint_replay	Action timelines and evidence views; the host supplies data

CDX provides the underlying controls and view engines. Studio owns the shared enterprise UI; Blueprint UI adapts the model to it.

Build designers and viewers with kits

A kit is the registry behind a designer and a viewer: the field kinds of a form, the rule types of a checklist, the components of a dashboard, the blocks of a report. Each family has a pure Dart package that also runs on a server, a Flutter viewer, and a designer.

Package	Responsibility
vyuh_kit_types	The kit, its extensions and parts, the codec contract, design issues, edit history
vyuh_kit	The designer controller, kit scope, autosave, and the editor chrome every kit shares
vyuh_form_types, vyuh_form_kit, vyuh_form_kit_editor	Forms; see Form Kit
vyuh_checklist_types, vyuh_checklist_kit	Checklists and their editor
vyuh_dashboard_types, vyuh_dashboard_kit	Dashboards and their editor
vyuh_report_types, vyuh_report_kit, vyuh_report_kit_editor	Reports, their viewer, and the editor core

All kits follow one written standard: the packages a kit has, a new-kit checklist, the shared editor chrome, the visual and test rules, and where each rule is checked. Read the kit design rules before you build or change a kit.

What your product supplies

• Domain modules and descriptors that extend shared entities.
• API composition, database configuration, and provider bindings.
• Application-specific screens and integrations.

These are roles, not a requirement to depend directly on every package. Start with the packages needed by your server or client.

Get access first

Request a pub.vyuh.tech token from Vyuh Technologies. Follow package access, then local development.