Runtime Stories

Follow one business flow through the receipt-bound Story Module Surface.

A Runtime Story is the operator-readable record of one correlated business flow. In the current product model, Stories are contributed by the exact lenso/platform-story Module Release and rendered by its console_ui_esm Surface inside Console.

Stories are not a top-level Console workspace, an application-wide score, or a browser shortcut to Host administration routes.

Composition ownership

The Support Desk product acceptance selects lenso/platform-story through its checked-in capability pack. The runner builds the matching Console artifact, then puts the exact Module Release digest, UI artifact digest, contract digest, and Surface Grant in the connected lenso.system.v2 topology.

Console loads the Story Surface only when those identities agree with the connected app receipt. Changing a UI build, Module Release, or Business API contract requires a newly matching composition and connection.

Browser boundary

The Story Surface uses the injected typed Host API and a generated client through same-origin Surface Gateway:

Story console_ui_esm Surface
  -> generated client
  -> Console Surface Gateway
  -> declared Story Business API

For every request, Console Service rechecks:

the authenticated Console actor;
the exact connected System;
Module and Module Release identity;
UI artifact and contract digests;
the allowed operation ID in the Surface Grant;
target Module authorization.

Service bearer tokens stay on the server. The browser receives neither Service credentials nor a generic endpoint for arbitrary records.

What a Story shows

A Story groups records by stable correlation and causation identities. The Surface can present:

a business title and direct status;
the initiating actor and tenant context allowed by policy;
related Module, Service, event, function, and workflow nodes;
causal edges and a time-ordered activity list;
direct failure details without inventing a second app-wide health score.

Technical logs and traces remain owned by their runtime. A Story links the business flow without replacing those tools or redefining Service ownership.

Authoring guidance

Module authors should:

keep business operation IDs and capability names stable;
give user-facing operations clear display names;
propagate actor, tenant, correlation, causation, deadline, and trace context;
use declared events, functions, or workflows for follow-up work;
keep secrets, tokens, and sensitive payloads out of Story records.

The Provider tier remains Host-owned and can be Rust or TypeScript. An Autonomous Service owns its Rust runtime and Store; it propagates the same bounded context over direct HTTP/gRPC, Event Contracts, or Durable Workflows. See Service Capability Tiers.

Connection and operational state

The Story Module and Surface have connection projections such as connected, unavailable, incompatible, or unmanaged, each with a direct reason. Workload operational state is separate.

If Console or the Story Surface is unavailable, the view is unavailable; established business execution continues in its owning Host or Autonomous Service. Console does not become a data plane dependency.

Product acceptance

Run the product-level black-box path from lenso-examples:

pnpm acceptance:support-desk

The real browser loads both Support Ticket and Story Surfaces without manual enablement, exercises ticket operations through Surface Gateway, and verifies that the exact receipt, actor, tenant, contract, and operation identities stay bound throughout the flow.

Continue with Lenso Console for System connection and Surface loading, or Module Console UI for artifact authoring.