@lenso/cli 0.1.24 → 0.1.27

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Lenso contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -16,27 +16,30 @@ cargo install lenso-cli
 lenso host init my-app
 cd my-app
 cp .env.example .env
+lenso console update
 lenso serve
 ```
 
 The package name defaults to the target directory name and can be overridden with
 `--name`. Pass `--force` to scaffold into a non-empty directory.
-Release builds of `lenso-cli` also copy the bundled Runtime Console into the
-new project, so the API serves it at `/console` without requiring Node.js or
-pnpm in the host application.
-
-Update the hosted console later by upgrading `lenso-cli` and running:
+Install or update the hosted Runtime Console with:
 
 ```sh
-lenso host update-console
+lenso console update
 ```
 
+The command downloads the latest `lenso-runtime-console` release artifact and
+installs it under `.lenso/console`, so the host API can serve `/console`
+without requiring Node.js or pnpm in the host application. For local builds,
+pass `--artifact <dir-or-tar.gz>`. For a pinned release, pass
+`--console-version vX.Y.Z`.
+
 After creating a password user, grant the first Runtime Console admin:
 
 ```sh
-lenso host bootstrap-admin --identifier admin@example.com
+lenso console bootstrap-admin --identifier admin@example.com
 # or
-lenso host bootstrap-admin --user-id usr_...
+lenso console bootstrap-admin --user-id usr_...
 ```
 
 `console.admin` is always added. Pass extra `--scope <name>` flags when the
@@ -67,7 +70,86 @@ workspace package:
 lenso module create billing --with-console
 ```
 
-For a standalone remote package:
+For a standalone service provider:
+
+```sh
+lenso service create support-suite-provider --lang ts --output-dir ../services
+lenso service create support-suite-provider --lang rust --output-dir ../services --port 4110
+```
+
+The generated provider includes a `lenso.service.json` manifest and a minimal
+service process. A service name ending in `-provider` or `-service` provides a
+module named without that suffix, so `support-suite-provider` provides
+`support-suite`.
+`service create` also updates `lenso.workspace.json` unless `--no-workspace` is
+set. That workspace file is the local service plane for development:
+
+```sh
+lenso service workspace list
+lenso service dev
+```
+
+`lenso service dev` starts workspace services first, then starts declared
+installed services from `.lenso/module-services.json`, then runs the host.
+Workspace reads prefer `lenso.workspace.json` and also accept the older
+`.lenso/services.json` path for compatibility.
+Generated TS and Rust services also support `--check-release` to print the
+development module release descriptor before packaging.
+Before handing a service to another app or deployment pipeline, package-check
+the project and then emit a local service artifact:
+
+```sh
+cd ../services/support-suite-provider
+lenso service package --check
+lenso service package --output-dir dist/lenso-service
+```
+
+The package artifact contains the canonical `lenso.service.json`,
+`lenso.service-package.json`, and one
+`modules/<module>/lenso.module.json` plus
+`modules/<module>/lenso.module-release.json` file for each provided module.
+The service package records the provider name, version, and provided module
+names; each module release is the business-module install entrypoint.
+Operators can install a provider directly. For a local package artifact, still
+pass the runtime service base URL:
+
+```sh
+lenso service install dist/lenso-service/support-suite-provider/lenso.service-package.json \
+  --base-url http://127.0.0.1:4100/lenso/service/v1
+```
+
+Install a packaged module release with the module command:
+
+```sh
+lenso module release inspect dist/lenso-service/support-suite-provider/modules/support-ticket/lenso.module-release.json
+lenso module release check dist/lenso-service/support-suite-provider/modules/support-ticket/lenso.module-release.json \
+  --base-url http://127.0.0.1:4100/lenso/service/v1
+lenso module install dist/lenso-service/support-suite-provider/modules/support-ticket/lenso.module-release.json \
+  --base-url http://127.0.0.1:4100/lenso/service/v1
+lenso module enable support-ticket
+lenso module disable support-ticket
+```
+
+`lenso.module-release.v1` is the module release channel. It records the module
+name, version, capabilities, source, and optional provider pointer. V11 keeps
+`lenso module install` as the unified business-capability entrypoint:
+
+- `source: service` resolves to a provider service package or service manifest.
+- `source: linked` enables linked Rust code in the host.
+- `source: bundled` enables a host-bundled module.
+
+`lenso service install` remains the lower-level provider/process command. It
+connects a service, but it does not mean every module inside that service is
+the user-facing install target.
+
+When this command runs from a framework checkout with sibling `lenso` and
+`lenso-runtime-console` repositories, the scaffold uses local path/file
+dependencies so `cargo check` or `pnpm install` can run before the packages are
+published. Outside that checkout it keeps the future-publish version
+dependencies and prints a note to replace them with local paths until
+`lenso-service` and `@lenso/service-kit` are published.
+
+The older standalone module package generator is still available as:
 
 ```sh
 lenso module create billing --remote --output-dir ../module-packages
@@ -76,14 +158,36 @@ lenso module create billing --remote --output-dir ../module-packages
 The Runtime Console package generator is available directly as:
 
 ```sh
-lenso console-package create billing
+lenso console package create billing
+```
+
+### Runtime Console package development
+
+Preview a console package while editing it:
+
+```sh
+lenso console dev --package packages/auth-console
+```
+
+From a module repository root, discover every local console package:
+
+```sh
+lenso module dev --console
 ```
 
+Both commands default to standalone mock mode. Add `--host` to proxy real Lenso
+host APIs while still loading the local package bundle:
+
+```sh
+lenso module dev --console --host http://localhost:3000
+```
+
+Set `LENSO_RUNTIME_CONSOLE_ROOT=/path/to/lenso-runtime-console` when the Runtime
+Console checkout is not a sibling of the current repository.
+
 ## Install a module
 
 ```sh
-lenso module install https://example.com/lenso/module/v1/manifest
-lenso module install ./lenso.module.json
 lenso module install auth
 lenso module install auth-password
 lenso module install auth-oidc
@@ -91,12 +195,42 @@ lenso module install auth-device
 ```
 
 `module install` reads `source` from the module descriptor when one is present.
-Remote modules update `REMOTE_MODULES`, copy declared Runtime Console bundles to
+When the reference is a module name, the CLI resolves it from the official
+catalog at `https://catalog.lenso.dev/v1/modules.json` unless `--catalog-url`
+points at another registry. For V5 service-backed modules, `module install
+<name>` is the business-capability entrypoint: the catalog resolves the provider
+service, installs it when needed, then enables the requested module.
+For module releases, `module install <module-release.json>` resolves the
+release by source, then records `moduleRelease` provenance in
+`.lenso/module-installs.json` where the source supports a receipt.
+
+Install a service directly when you have a workspace service name or manifest
+reference:
+
+```sh
+lenso service install support-suite-provider
+lenso service install https://example.com/lenso/service/v1/manifest
+lenso service install ./lenso.service.json --repo-root ../my-lenso-host
+```
+
+When the first argument matches a service in `lenso.workspace.json` or
+`.lenso/services.json`, the CLI resolves its manifest and infers `--base-url`
+from the service `readyUrl`. Local source manifests registered in the workspace
+also infer `--base-url`; package artifacts outside that workspace still need
+`--base-url` so the host records the runtime service endpoint rather than the
+file path.
+
+Service installs update `REMOTE_MODULES`, copy declared Runtime Console bundles to
 `.lenso/console/extensions`, update `.lenso/console/extensions/registry.json`,
 and record `.lenso/module-installs.json` in one step. Linked modules update the
 host `Cargo.toml`, `src/lib.rs`, `.env` toggle, and the same install receipt
 from the descriptor's `linked` section. `module add` remains a compatibility
-alias for remote installs.
+alias for service installs.
+
+Legacy `lenso module install <manifest-url>` still works for one compatibility
+window, but prints a deprecation warning. Use `lenso service install <manifest>`
+for process manifests and `lenso module install <module-name>` for business
+modules.
 
 Install descriptor profiles let a module expose optional setup without baking
 module-specific choices into the CLI. For Redis-backed auth sessions:
@@ -127,36 +261,97 @@ builtin module entry.
 Use `--no-console-extension` when you want to skip Runtime Console extension
 registration.
 
-Remote manifests may also declare `install.env` values and `install.commands`.
-Env values are written to `.env`; commands are run only when you pass:
+Service module manifests may also declare `install.env` values and
+`install.commands`. Env values are written to `.env`; commands are run only when
+you pass:
 
 ```sh
-lenso module install https://example.com/lenso/module/v1/manifest --run-install-commands
+lenso service install https://example.com/lenso/service/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
+For long-running service backends, declare `install.services`. These are
+stored in `.lenso/module-services.json` and started before the host loads
+service-provided 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:
+During local development, start declared service providers and then the host
+with:
+
+```sh
+lenso service dev
+lenso service dev --skip-db --skip-migrate
+lenso service dev --workspace-file lenso.workspace.json
+```
+
+After the service processes are running, check the workspace from another shell:
+
+```sh
+lenso service workspace check
+lenso service workspace check support-suite-provider --json
+lenso service verify
+lenso service verify support-suite-provider --json
+lenso service verify ./lenso.service.json --env-file .env --json
+```
+
+Use `lenso service dev --no-workspace` when only installed
+`.lenso/module-services.json` providers should start.
+
+`lenso service workspace check` verifies that each declared service directory
+exists, its manifest is reachable, and its `readyUrl` is responding before the
+host tries to load the provider.
+
+`lenso service verify` is the release-readiness entrypoint. With no argument it
+checks `./lenso.service.json`; with a provider name it reuses the installed
+service doctor checks. Pass `--env-file` to include required/missing service env
+in the verification report.
+
+Preview service upgrade impact before writing host-local state:
+
+```sh
+lenso service upgrade-plan billing ./lenso.service.json --json
+lenso service upgrade billing ./lenso.service.json --dry-run
+```
+
+Export workspace services into the host service-start state format when a script
+or deployment handoff should consume the same service declarations:
+
+```sh
+lenso service workspace export --output .lenso/module-services.json
+```
+
+Diagnose installed service state with:
+
+```sh
+lenso service doctor
+lenso service doctor billing
+lenso service doctor billing --json
+lenso service check billing --json
+```
+
+The doctor reads `REMOTE_MODULES`, `.lenso/module-installs.json`, and
+`.lenso/module-services.json`. It reports whether the service is
+installed, configured, whether an HTTP manifest is reachable, whether managed
+service `readyUrl` endpoints are ready, and which stale `.lock`/`.pid` files
+may be blocking a host-started service.
+
+Export declared service processes as a Compose fragment when handing the
+service to deployment tooling:
 
 ```sh
-lenso module doctor
-lenso module doctor billing
+lenso service export --module billing --format compose
 ```
 
-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.
+If a manifest declares incompatible `compatibility` metadata, install stops
+before writing host-local state. Use `--allow-incompatible` only when an
+operator deliberately accepts that override.
 
-Remove the local remote-module source, install receipt, service state, Runtime
+Remove the local service source, install receipt, service state, Runtime
 Console extension registry entry, and copied bundle files with:
 
 ```sh
-lenso module uninstall billing
+lenso service uninstall billing-service
 ```
 
 Use `--source linked` only when you need to force the loading source. Prefer

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenso/cli",
-  "version": "0.1.24",
+  "version": "0.1.27",
   "description": "Lenso command-line interface for scaffolding and operating Lenso backend projects.",
   "license": "MIT",
   "homepage": "https://github.com/LioRael/lenso-cli",