Extend the framework

Use this path for Host, Engine, protocol, Driver, or Execution Adapter mechanics. Product behavior belongs in a Plugin instead. The Rust main chain is in LioRael/lenso; JavaScript and TypeScript distribution sources are in LioRael/lenso-js. Former split Rust repositories are migration sources, not places to start a new framework change.

Tutorial: run one Engine extension

Build a local Engine extension starts from a source-built CLI and a small Site fixture. You will explicitly select a Node processor, inspect its plan without executing it, run it, and verify that a changed locked artifact is rejected. The result is a local Engine resource, not a business Plugin installation or a new runtime target.

Task guide: identify the contract for a framework change

1. Read Core architecture and apply its ownership test to the behavior you want to change.

2. Use the Repository map to find the current crate or package. Read the relevant architecture decision before changing a stable boundary.

3. In a matching lenso source checkout, run the existing portable runtime conformance suite before editing runtime mechanics:

   cargo test --locked -p lenso-runtime-conformance

   This checks the existing contract. It does not qualify a new Driver or Adapter by itself.

4. Add a focused failing case at the owning public boundary, implement the change there, then run that case and the applicable real Host or target proof. Do not turn a target-specific failure into a Kernel feature to make one test pass.

The tutorial above covers Engine processor extension. A new target or Adapter still needs its own scoped behavior and conformance evidence.

Choose the right guide

The runtime lifecycle explains the portable behavior these extensions must preserve. Use Supported workflows to distinguish a maintained local proof from a released target.