Start Here

Compose a Lenso app, run it locally, connect Console, and read exact System status.

Lenso is an agent-ready modular application and microservice framework for Rust business systems. Start with one explicit app composition. Keep business capabilities as linked Modules or Provider-backed Modules, then move a stable boundary to an Autonomous Service only when it needs independent ownership.

The public developer lifecycle has four steps.

Compose

Materialize one exact lenso.app.json from a product blueprint:

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

The bare blueprint selects auth, notification-worker, and support-api. The resulting file binds the app revision, artifact digests, dependency selections, and linked or service-backed Module implementations. Treat it as the application composition and lock; do not copy process commands into it by hand. The Support Ticket and Story product seam is the pack-backed Support Desk acceptance.

Run locally

Start the generated Host, auto-start Provider Services, and a connected local Console through the public CLI:

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

The command creates loopback-only signed enrollment material, reconciles Module-owned UI artifacts, and connects the exact topology before it reports the System ready. Local development does not require Kubernetes. Production release and deployment remain owned by external delivery systems, not Console.

Connect

lenso dev up --console-root writes .lenso/console-connect.json and applies that exact bundle through the authenticated Console connection boundary. The bundle contains signed local Service enrollments, the topology digest, Management Binding, and optional Console artifact effect. Console records the connection and loads receipt-bound console_ui_esm Module Surfaces. It does not create, deploy, adopt, delete, release, or repair workloads.

Continue with Lenso Console for the server-side connection boundary and browser flow.

Status

Read the connected System in Console. System, Service, Module, Surface, and Adapter projections report one of connected, unavailable, incompatible, or unmanaged, with a direct reason when action is needed. Workload operational state is separate. An unavailable control Adapter leaves Workload observation unknown and rejects mutation without queueing or fallback.

Choose a build path

Core boundaries

• Modules keep business identity. Delivery may be linked or provided by a Service without renaming the capability.
• Business APIs stay typed. Module Surfaces call declared operations with a generated client and an exact Surface Grant.
• Console is a System Plane. It reports current state and invokes supported target-owned operations; it is not a deployment plane.
• Rust owns both service tiers. TypeScript currently supports Provider authoring only. See Service Capability Tiers.
• Split only stable boundaries. Autonomous Services own their runtime, storage, identity, and operations; they are not the default starting point.

Install

• Rust Module and Host declarations use the current lenso facade.
• @lenso/cli and lenso-cli both expose the lenso command.
• @lenso/service-kit authors TypeScript Provider services.
• Lenso Console is installed independently with lenso console install.