Product Blueprints

Materialize an exact product-shaped app composition for local development.

Product Blueprints are the shortest path from a product idea to a runnable Lenso System. A blueprint creates the app source shape and the single lenso.app.json composition lock that selects its Modules.

Use the maintained blueprint

The Support Desk blueprint is the maintained product-level foundation. Compose it by name rather than depending on the hidden inspection commands used for repository development. By itself it selects auth, notification-worker, and support-api.

The product acceptance adds the Support Ticket and Story Module selections through its checked-in capability pack. Its runner builds the exact Support Ticket Console Surface from the Module-owned example package in lenso-examples, then reconciles that artifact through Console.

Compose the foundation

lenso app compose ./support-desk --blueprint support-desk --apply

Composition writes support-desk/lenso.app.json. The file records:

• the app protocol, identity, and monotonic revision;
• selected blueprint and capability packs;
• each immutable Module Release identity, version, owner, content digest, and business contributions;
• resolved dependency identities, versions, and content digests;
• linked or service-backed implementation bindings;
• blueprint and capability-pack provenance.

The composition file is not a process launcher, credential file, or production delivery record. lenso dev up realizes its Host and Provider selections for local development. The lower-level lenso system dev command remains a System Sandbox for isolated topology and Adapter checks.

Compose the product acceptance

lenso app compose ./support-desk \
  --blueprint support-desk \
  --pack ./fixtures/acceptance/support-desk/capability \
  --implementation support-api=linked \
  --implementation notification-worker=linked \
  --implementation lenso/platform-story=linked \
  --apply

Run this command from the lenso-examples repository root. The pack contributes support/tickets Service delivery and lenso/platform-story; the implementation flags make the local acceptance bindings explicit. Before startup, the runner uses public lenso service workspace init --force and lenso service workspace add support-ticket commands to register the one service-backed Provider with its lenso.service.json in the app workspace.

Run the supported black-box path rather than starting this pack-backed composition without that workspace entry:

pnpm acceptance:support-desk

Run and connect the foundation locally

cd support-desk
lenso dev up --console-root ../lenso-console

This starts the Host, auto-start Provider Services, and existing Console checkout in one foreground-bound session. It creates the signed local connection material, reconciles Module-owned UI artifacts, and connects the exact topology. Ctrl-C stops only processes started by that invocation.

Use the lower-level sandbox only when you need to validate or run its isolated System shape without the connected Host, Provider, and Console path:

lenso system dev --system-file lenso.app.json --dry-run --json
lenso system dev --system-file lenso.app.json

Use --cleanup to stop resources owned by that sandbox run.

Extend with a capability pack

A capability pack is reusable local composition input for Modules, Services, documentation, and agent context:

lenso capability init support-sla \
  --dir ./capabilities/support-sla \
  --lang ts \
  --for-blueprint support-desk
lenso capability library add ./capabilities/support-sla
lenso capability fit support-sla --repo-root .
lenso app compose --repo-root . --pack support-sla --apply

Capability packs do not install a Module Release, publish a Service, or mutate production infrastructure. Recompose the app so every accepted selection is captured by a new lenso.app.json revision.

Connect and inspect status

Console Service accepts an exact lenso.system.v2 topology and Management Binding derived from the composed app. Once connected, it loads only the receipt-bound Surfaces and reports direct object status. Console never widens the composition or selects a deployment target.

Follow Host Quickstart for the full four-step lifecycle or Examples for the Support Desk product acceptance.

Boundaries

• A blueprint creates source and local composition; it does not deploy.
• lenso.app.json is the exact application composition and lock.
• Modules retain stable business identity across linked and service-backed delivery.
• Provider Services remain Host-managed. Autonomous Services use the separate Rust lenso.service.v2 runtime.
• Production release, promotion, rollback, and infrastructure remain external delivery responsibilities.