---
title: Examples
description: Run the Support Desk product acceptance through public Lenso entrypoints.
---

The [Lenso examples repository](https://github.com/LioRael/lenso-examples)
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

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

## Run the product acceptance

```sh
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](/docs/quickstart) to run the lifecycle manually, or
[Lenso Console](/docs/runtime-console) to understand connection and status.