Core framework

Create replaceable product behavior, then learn how Plugins, Capabilities, Hosts, Plans, and the portable Kernel fit together.

Start with one result

Create your first Plugin

Learn the mental model

Change your first App

Build products from replaceable Plugins

Lenso is a local-first, language-independent runtime for products whose behavior must be added, replaced, and removed without turning composition into hidden framework magic.

Define product roles as typed Capabilities, implement them as Plugins, and let each Host resolve one exact application before it boots. Humans and coding agents work against the same inspectable Plugin Root, while the runtime keeps lifecycle, failure, and execution choices explicit.

Lenso is designed for long-lived business systems, developer tools, automation products, and Agent applications. It is not a Web framework or a distributed control plane.

Create your first Plugin

Choose a supported workflow

Why Lenso exists

In a long-lived product, a feature rarely stays in one file. Its configuration, state, permissions, background work, and failure policy spread across the application. Removing or replacing it then becomes risky, and coding agents have to infer boundaries that the system never recorded.

Lenso makes those product boundaries executable:

Plugins own behavior. Removing a Plugin removes its product complexity.
Capabilities define collaboration. Consumers depend on typed roles, not a provider’s private code or transport.
The Plugin Root shows intent. An App owner changes visible Plugin selections and configuration instead of hand-authoring a runtime graph.
Resolution fails before boot. Incompatible or ambiguous selections do not become partially running applications.

Lenso separates those concerns:

Composition selects Plugins, binds Capabilities, and produces the Plan.
The Kernel validates and executes the Plan with portable lifecycle rules.
Runtime Drivers provide scheduling, clocks, cancellation, and shutdown.
Execution Adapters connect the Kernel to concrete Plugin implementations.
Plugins own product behavior behind typed Capability Interfaces.

This separation makes application structure inspectable before execution and keeps host-specific mechanisms out of the portable core.

The runtime model

The Plan is the complete execution input. It records Plugin identities, Capability bindings, execution classes, connections, policies, and the data needed to admit the application. Once resolved, the Plan is immutable; the Kernel does not discover or rewrite the graph while booting.

The Kernel owns graph validation, staged lifecycle, readiness, invocation, cancellation, supervision, and bounded diagnostics. It does not own network, filesystem, database, process, Auth, telemetry, Console, or business semantics.

Core concepts

Concept	Responsibility
App Composition	Declares the application and selects compatible implementations.
Resolved App Plan	Provides the canonical, immutable input accepted by the runtime.
Capability	Defines a versioned Interface with request, stream, or event Operations.
Plugin	Implements product behavior and declares the Capabilities it provides or requires.
Kernel	Owns portable admission, lifecycle, invocation, cancellation, and diagnostics.
Runtime Driver	Supplies host scheduling, time, task joining, cancellation, and shutdown.
Execution Adapter	Runs a Plugin implementation in a concrete environment or transport.

Portable does not mean environment-free

The same Kernel semantics can be compiled for native, browser JavaScript, and WASIp2 host profiles. Each profile still needs a Driver and compatible Execution Adapters. Portability means the Kernel does not absorb those host mechanisms; it does not imply that every Plugin runs unchanged in every environment.

Current implementation boundary

lenso-app-plan owns the serializable execution input.
lenso-kernel owns portable runtime semantics and deterministic conformance.
lenso-runtime-conformance owns product-neutral runtime proofs.
Drivers, Execution Adapters, protocols, optional Plugins, authoring, and examples live in separate owner repositories.
Runtime discovery, hot graph mutation, distributed placement, automatic replicas, and an independent Console product are not current runtime promises.

Use Supported workflows to choose an authoring and runtime path, and to check its platform, Auth, and isolation boundaries.

Where to go next

Choose a Plugin path

Add Plugins to an App

Author a Capability

Understand the runtime

Inspect a failing App

Build a Web backend

Build an Agent product