Drivers and Adapters
Implement a host profile without importing host or transport policy into the portable Kernel.
Runtime Driver checklist
A real Driver provides scheduling, wakeups, monotonic timers, joins, cooperative cancellation, and shutdown translation. Target compilation alone is not runtime proof; each profile needs scheduler, timer, readiness, cancellation, and shutdown smoke evidence.
Execution Adapter checklist
An Adapter owns:
- the execution-class identifier advertised to Plan validation;
- Plugin factory or process generation;
- typed endpoint creation and Adapter-specific dispatch;
- framing, isolation, and resource ownership;
- failure classification and restart cleanup; and
- conformance against the published runtime Interface.
Current owners
| Implementation | Repository |
|---|---|
| Tokio Runner, native Adapter, browser and WASIp2 Drivers | LioRael/lenso-runtime-rust |
| Bun SDK, child-process Adapter, and prepared Host runtime | LioRael/lenso-bun-adapter |
| Descriptor code generation and portable value conformance | LioRael/lenso-protocols |
The Bun Adapter uses JSON-RPC over HTTP in production and implements Request,
bidirectional Stream, and volatile Event dispatch. Those are Adapter/wire
choices, not Capability or Kernel semantics. Plugin authors use the published
@lenso/bun server and lenso plugin dev; they do not implement
the handshake or process protocol. See
Bun Plugin authoring for the complete scaffold and
development path.
The CLI declares and prepares TypeScript/Bun Hosts; lenso-host-runtime
assembles the Rust Kernel and Bun/Process Adapters. See TypeScript Host
for the entrypoint and current limits.