Skip to content
Lenso
English
Esc
navigateopen⌘Jpreview
On this page

Examples

Run the Support Desk product acceptance through public Lenso entrypoints.

The Lenso examples repository contains the product-level Support Desk acceptance. It is the highest acceptance seam for the complete application model; lower framework, CLI, client, Console, browser, transport, and container tests support this scenario without replacing it.

Prerequisites

  • Node.js and pnpm;
  • Rust and Cargo. Cargo is always required because Console migration and service startup use it; LENSO_CLI_BIN only skips building the CLI;
  • PostgreSQL initdb, postgres, and pg_isready binaries;
  • a headless Chrome-compatible browser;
  • sibling checkouts named lenso, lenso-cli, and lenso-console next to lenso-examples.

The sibling paths can instead be set with LENSO_FRAMEWORK_ROOT, LENSO_CLI_ROOT, and LENSO_CONSOLE_ROOT.

Install

git clone https://github.com/LioRael/lenso-examples
cd lenso-examples
pnpm install --frozen-lockfile

Run the product acceptance

pnpm acceptance:support-desk

The runner builds the linked Service Kit, CLI when needed, Console Service, and Module artifacts, then drives only public developer, business, Console, and browser entrypoints. It starts a disposable PostgreSQL instance automatically. If LENSO_ACCEPTANCE_DATABASE_URL is supplied instead, its database name must contain acceptance. Set LENSO_ACCEPTANCE_KEEP_TEMP=1 only when you need to inspect the otherwise-cleaned temporary run.

The repository’s default pnpm check remains the fast static and component gate; run pnpm acceptance:support-desk explicitly for the cross-repository product acceptance.

What the scenario covers

Compose

The scenario materializes the exact lenso.app.json, then validates its revision, digests, dependency selections, and linked or service-backed Module bindings.

Run locally

The runner materializes the one Support Ticket Provider with an exact lenso.service.json, then uses public lenso service workspace init --force and lenso service workspace add support-ticket commands against support-desk/lenso.workspace.json. It starts the System with lenso system dev, the real Support Desk processes, and the Local Control Adapter. Cleanup stops only resources owned by that run.

Connect

It starts Console Service independently, submits the signed local Service Enrollment Offer and Receipt, and connects the exact System topology without an environment or deployment API. A real browser loads the receipt-bound Support Ticket and Story console_ui_esm Surfaces without manual enablement.

Status

The browser uses the Support Ticket generated client and Surface Gateway to list, create, update, and close real tickets. The scenario covers actor, tenant, deadline, idempotency, Surface Grant, Console actor, and target Module authorization behavior.

It verifies connected, unavailable, incompatible, and unmanaged across System connection projections, each with a direct reason. Separately, it completes one supported local Workload round trip and follows its asynchronous Operation Record to final state. An unavailable Adapter returns unknown Workload observation and rejects mutation without queueing or fallback.

Authority boundaries

  • Browser code receives neither Service nor Adapter credentials.
  • Business records are accessed only through the declared Business API.
  • Console does not select an environment or mutate releases, deployments, or production infrastructure.
  • The scenario does not query the database directly.
  • All Surfaces are bound to the exact Module Release, UI artifact, contract, and operation IDs in the connected app.

Use Host Quickstart to run the lifecycle manually, or Lenso Console to understand connection and status.

Last updated on August 13, 2026

Was this page helpful?