# lenso-cli
Command-line interface for the Lenso backend framework.
## Install
```sh
cargo install lenso-cli
```
## Scaffold a host application
```sh
lenso host init my-app
cd my-app
cp .env.example .env
docker compose up -d postgres
cargo run --bin migrate
cargo run --bin api
```
The package name defaults to the target directory name and can be overridden with
`--name`. Pass `--force` to scaffold into a non-empty directory.
The generated host depends on the transitional `lenso-host` crate while the
stable public host facade is still being designed. See
[`docs/architecture/framework-public-surface.md`](../../docs/architecture/framework-public-surface.md)
for the host-facade roadmap.
## Scaffold a module
```sh
lenso module create billing
```
Add `--with-console` when the linked module should also get a Runtime Console
workspace package:
```sh
lenso module create billing --with-console
```
For a standalone remote package:
```sh
lenso module create billing --remote --output-dir ../module-packages
```
The Runtime Console package generator is available directly as:
```sh
lenso console-package create billing
```
## Install a remote module
```sh
lenso module install https://example.com/lenso/module/v1/manifest
```
`module install` updates `REMOTE_MODULES`, writes the local console package
install plan, and applies Runtime Console package registration when the manifest
declares console packages. `module add` remains a compatibility alias for remote
installs. Use `--runtime-console-root` when the console app lives outside the
host repository, and `--no-console-plan` when you want to apply the plan later
with:
```sh
lenso console-package apply-plan
```
Remote manifests may also declare `install.env` values and `install.commands`.
Env values are written to `.env`; commands are recorded in the plan and run only
when you pass:
```sh
lenso module install https://example.com/lenso/module/v1/manifest --run-install-commands
```
For long-running remote module backends, declare `install.services`. These are
stored in `.lenso/module-services.json` and started before the host loads remote
modules on API/worker startup. Services started by the host are tracked with
`.lock`/`.pid` files and stopped when the owning API/worker process exits;
services that are already ready before startup are treated as external and are
not stopped by the host.
Diagnose installed remote-module service state with:
```sh
lenso module doctor
lenso module doctor billing
```
The doctor reads `REMOTE_MODULES` and `.lenso/module-services.json`, checks
service `readyUrl` endpoints, and points to stale `.lock`/`.pid` files when a
host-started service did not become ready.
Remove the local remote-module source and its pending console package plan with:
```sh
lenso module uninstall billing
```
Enable or disable an already-linked module without deleting source files:
```sh
lenso module install auth --source linked
lenso module uninstall auth --source linked
```