Product Blueprints

Create service-ready product apps, add product addons, and hand the result to Runtime Console or a coding agent.

Product Blueprints are the fastest path from product idea to a runnable Lenso system. A blueprint creates a host, service processes, module manifests, lenso.system.json, lenso.workspace.json, and Launchpad state. Addons extend that generated app without making you hand-edit service graph JSON first. Capability packs bundle a reusable product slice around modules, services, seed manifests, docs, and agent handoff context.

Use this path when you want a product-shaped starting point instead of a blank host.

Built-in blueprints

List and inspect what your installed CLI supports:

lenso app list
lenso app inspect support-desk

Create and extend an app

lenso app compose ./acme-support \
  --blueprint support-desk \
  --addon support-sla \
  --addon customer-profile \
  --apply
cd acme-support
lenso app next
lenso app explain
lenso dev doctor --write-state
lenso app verify --write-proof
lenso app diff
lenso agent task --from-app-plan "add overdue ticket escalation"
lenso dev up

lenso app compose is the app-level composition command. It can create the app, apply several addons, and write composition context into .lenso/app-change-plan.json. lenso app add remains available for one addon at a time. Addons can add another service, module, capability dependency, workspace entry, Launchpad checklist item, and agent context in one step. It is not a replacement for lenso module install. Use lenso app plan --addon <name> --write-plan first when you want a reviewable App Change Plan for Console, agents, or a dry-run apply step.

Compose with a capability pack

Use a capability pack when a slice should travel as one local unit across apps: for example, a support SLA pack with one service-provided module, a seed module manifest, and an agent task prompt.

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 ./acme-support \
  --blueprint support-desk \
  --pack support-sla \
  --apply
cd acme-support
lenso agent task --for-capability support-sla "add enterprise SLA escalation"

lenso capability library add records the pack in the local app library. lenso capability fit checks blueprint support, duplicate modules and services, and validation failures before Compose records the pack in Launchpad and App Change Plan state.

What gets written

Verify generated state

Use App Change Plan before applying addons or generated-state repairs:

lenso app compose --repo-root . --addon support-sla --addon customer-profile --write-plan
lenso app plan --addon support-sla --write-plan
lenso app apply .lenso/app-change-plan.json --dry-run

app compose writes a reviewable local plan with requested, applied, and pending addons or capability packs. app plan writes the same generated-state repair surface. app apply only applies safe generated control-plane changes and supported addon applications from that plan. It does not overwrite existing service source files or delete unknown services.

Use App Proof after adding addons or before handing work to another agent:

lenso app verify --write-proof
lenso app diff
lenso app repair --dry-run

app verify compares Launchpad state, workspace services, system services, and the latest dev doctor output. app diff fails when generated state drift is present. app repair writes only safe generated control-plane state and missing scaffold directories; existing service source files stay user-owned.

App Proof is local generated-state evidence. It is not a security attestation, deployment gate, signature system, or distributed version negotiation layer.

Runtime Console reads the Launchpad, doctor, and proof endpoints through the host admin API. /launchpad shows generated services, modules, applied addons, capability packs, supported addons, doctor status, proof drift, App Change Plan status, and the next operator command.

Boundaries

• Product Blueprints create an app and local service graph.
• Addons extend a generated app.
• Capability packs compose reusable slices across modules, services, docs, and agent handoff context.
• Capability libraries are local discovery files; they do not install modules or services.
• lenso module install remains the module-level install entrypoint.
• lenso service install remains the service provider install entrypoint.
• Kubernetes delivery remains optional; generated apps run locally without a cluster.

The result is service-ready, not service-mesh-required. Start locally, keep the host-owned runtime and observability model, then move services to independent deployment when their boundaries are stable.