---
title: Product Blueprints
description: 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

```sh
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

```sh
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:

```sh
pnpm acceptance:support-desk
```

## Run and connect the foundation locally

```sh
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:

```sh
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:

```sh
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](/docs/quickstart) for the full four-step lifecycle or
[Examples](/docs/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.