@hotmeshio/long-tail 0.14.3 → 0.16.0

package/docs/api/http/escalations.md

@@ -156,6 +156,29 @@ GET /api/escalations/:id
 { "error": "Escalation not found" }
 ```
 
+## Get escalation lookups
+
+```
+GET /api/escalations/:id/lookups
+```
+
+Resolves the versioned knowledge lookups pinned on the row (`envelope.lookups`). The refs ARE the grant: any user who may read the escalation may fetch exactly the pinned editions it names — the general knowledge API stays a builder surface. See [lookups](../../hitl/lookups.md).
+
+**Scope:** Enforces the same read scope as `GET /api/escalations/:id`.
+
+**Response 200:**
+
+```json
+{
+  "lookups": [
+    { "domain": "catalog", "key": "materials", "version": 2, "data": { "items": ["aluminum", "steel"] } },
+    { "domain": "catalog", "key": "geo", "version": 9, "data": null, "missing": true }
+  ]
+}
+```
+
+A ref whose snapshot does not exist answers with `missing: true` — the batch never fails.
+
 ## Claim an escalation
 
 ```
@@ -279,7 +302,7 @@ Returned when the escalation has already been resolved or is otherwise not pendi
 
 ### Signal-based resolution (metadata.signal_id)
 
-When an escalation has `metadata.signal_id`, the resolve endpoint signals the running workflow instead of starting a new one. The workflow is still alive — it called `conditionLT(signalId)` and is paused.
+When an escalation has `metadata.signal_id`, the resolve endpoint signals the running workflow instead of starting a new one. The workflow is still alive — it called `conditional(signalId)` and is paused.
 
 The resolver payload is augmented with `$escalation_id` before signaling:
 
@@ -287,13 +310,13 @@ The resolver payload is augmented with `$escalation_id` before signaling:
 { "approved": true, "notes": "Looks good", "$escalation_id": "esc-a1b2c3d4-..." }
 ```
 
-The workflow is responsible for resolving the escalation. The `conditionLT()` helper handles this automatically — it strips `$escalation_id`, calls `ltResolveEscalation` as a durable activity, and returns the clean payload.
+The workflow is responsible for resolving the escalation. The `conditional()` helper handles this automatically — it strips `$escalation_id`, calls `ltResolveEscalation` as a durable activity, and returns the clean payload.
 
 If you use raw `Durable.workflow.condition()` instead, you must resolve the escalation yourself using the `$escalation_id` from the signal data.
 
 ### Signal-key resolution (efficient/atomic — `signal_key`)
 
-When an escalation was written atomically by `conditionLT(signalId, config)` (or `Durable.workflow.condition(signalId, config)`), the row carries a `signal_key` and no `signal_id`/`signal_routing` metadata. The resolve endpoint detects `signal_key` and resolves it through the SDK: the resolve marks the row resolved **and** delivers the signal to the waiting `condition()` in one transaction, so the original job resumes in place — no re-run, no separate resolve activity. `system.escalation.{role}.{id}.resolved` fires.
+When an escalation was written atomically by `conditional(signalId, config)` (or `Durable.workflow.condition(signalId, config)`), the row carries a `signal_key` and no `signal_id`/`signal_routing` metadata. The resolve endpoint detects `signal_key` and resolves it through the SDK: the resolve marks the row resolved **and** delivers the signal to the waiting `condition()` in one transaction, so the original job resumes in place — no re-run, no separate resolve activity. `system.escalation.{role}.{id}.resolved` fires.
 
 ```
 POST /api/escalations/resolve-by-signal-key
@@ -303,7 +326,7 @@ For callers that know the deterministic signal id (webhooks — e.g. `signal-sca
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
-| `signalKey` | `string` | yes | The signal id passed to `conditionLT(signalId, config)` |
+| `signalKey` | `string` | yes | The signal id passed to `conditional(signalId, config)` |
 | `resolverPayload` | `object` | yes | The decision payload delivered to the waiting workflow |
 | `metadata` | `object` | no | Outcome facets merged into the row's GIN-indexed metadata (see [Resolve an escalation](#resolve-an-escalation)) |
 
@@ -325,7 +348,7 @@ When a reviewer claims an escalation, the dashboard renders a typed form instead
 
 ### Option 1: Role `form_schema` (versioned)
 
-The escalation form is owned by the target **role** as a versioned `form_schema`, declared on the role (e.g. via `PATCH /api/roles/:role`). Every escalation targeting that role resolves against it. A workflow pins a specific version through `conditionLT`'s `schemaVersion`, which stamps `metadata.schema_version` on the escalation; unpinned escalations resolve against the role's latest `form_schema`. Fields may carry `x-lt-bind` to map a form value to a path in the resolver payload.
+The escalation form is owned by the target **role** as a versioned `form_schema`, declared on the role (e.g. via `PATCH /api/roles/:role`). Every escalation targeting that role resolves against it. A workflow pins a specific version through `conditional`'s `schemaVersion`, which stamps `metadata.schema_version` on the escalation; unpinned escalations resolve against the role's latest `form_schema`. Fields may carry `x-lt-bind` to map a form value to a path in the resolver payload.
 
 The deprecated workflow-config `resolver_schema` remains only as a legacy fallback when no role `form_schema` is available.
 
@@ -830,7 +853,7 @@ Returns all escalations linked to a specific workflow ID.
 POST /api/escalations/:id/cancel
 ```
 
-Permanently cancels a pending or claimed escalation. The workflow waiting on this escalation (via `conditionLT`) receives `null` as the condition result, allowing it to handle the cancellation gracefully.
+Permanently cancels a pending or claimed escalation. The workflow waiting on this escalation (via `conditional`) receives `null` as the condition result, allowing it to handle the cancellation gracefully.
 
 Terminal escalations (`resolved` or already `cancelled`) return 409.
 
@@ -1060,7 +1083,7 @@ POST /api/escalations/resolve-by-metadata
 
 Single atomic query finds the pending escalation by metadata, auto-claims if unclaimed, and resolves it. RBAC is enforced in the SQL WHERE clause. Write scope is honored here: a `member` with `write_scope=self` may resolve their own assigned item atomically, which is how a one-time user completes the form routed to them.
 
-**Signal guard:** If the escalation has `metadata.signal_id` (created by `conditionLT`), the SQL does NOT resolve it directly. Instead, the endpoint signals the running workflow — `conditionLT` receives the signal and resolves the escalation durably inside the workflow. This preserves the same transactional integrity as the standard resolve-by-ID path.
+**Signal guard:** If the escalation has `metadata.signal_id` (created by `conditional`), the SQL does NOT resolve it directly. Instead, the endpoint signals the running workflow — `conditional` receives the signal and resolves the escalation durably inside the workflow. This preserves the same transactional integrity as the standard resolve-by-ID path.
 
 **Body:**
 
@@ -1089,7 +1112,7 @@ Single atomic query finds the pending escalation by metadata, auto-claims if unc
 }
 ```
 
-**Response 200 (signal-backed):** Workflow signaled; `conditionLT` resolves the escalation durably.
+**Response 200 (signal-backed):** Workflow signaled; `conditional` resolves the escalation durably.
 
 ```json
 {

package/docs/api/http/knowledge.md

@@ -2,7 +2,7 @@
 
 CRUD operations for the knowledge store — a domain-scoped key-value store backed by PostgreSQL JSONB. Each entry has a domain, key, arbitrary JSON data, and optional tags.
 
-All endpoints require authentication.
+All endpoints require authentication and builder access (superadmin or a user holding the `engineer` role). Members reach knowledge content only through escalation lookup refs — see [lookups](../../hitl/lookups.md) and `GET /api/escalations/:id/lookups`.
 
 ## List domains
 
@@ -64,12 +64,13 @@ Returns entries within a domain, ordered by last updated.
 GET /api/knowledge/entry?domain=screenshot&key=google
 ```
 
-Returns a single knowledge entry by domain and key. Returns `{ found: false }` if not found.
+Returns a single knowledge entry by domain and key. Returns `{ found: false }` if not found. With `version`, returns that immutable edition from the version history instead of the live entry.
 
 | Parameter | Type | Required | Description |
 |-----------|------|----------|-------------|
 | `domain` | `string` | Yes | Domain |
 | `key` | `string` | Yes | Entry key |
+| `version` | `integer` | No | Fetch this immutable edition instead of the live entry |
 
 **Response 200:**
 
@@ -85,6 +86,27 @@ Returns a single knowledge entry by domain and key. Returns `{ found: false }` i
 }
 ```
 
+## List entry versions
+
+```
+GET /api/knowledge/entry/versions?domain=catalog&key=materials
+```
+
+Every data-changing write mints an immutable edition. Lists them newest first, with the current one marked.
+
+**Response 200:**
+
+```json
+{
+  "domain": "catalog",
+  "key": "materials",
+  "versions": [
+    { "version": 2, "change_summary": null, "created_at": "...", "is_current": true },
+    { "version": 1, "change_summary": null, "created_at": "...", "is_current": false }
+  ]
+}
+```
+
 ## Store entry
 
 ```

package/docs/api/http/roles.md

@@ -412,7 +412,7 @@ GET /api/roles/:role/schema
 GET /api/roles/:role/schema?version=3
 ```
 
-Fetch the role's `form_schema` + `metadata_schema` pair. Without `version`, returns the live (latest) schema along with the role's current version number. With `version`, returns that immutable snapshot from the version history — the snapshot an escalation pinned via `metadata.schema_version` (`conditionLT`'s `schemaVersion` field).
+Fetch the role's `form_schema` + `metadata_schema` pair. Without `version`, returns the live (latest) schema along with the role's current version number. With `version`, returns that immutable snapshot from the version history — the snapshot an escalation pinned via `metadata.schema_version` (`conditional`'s `schemaVersion` field).
 
 **Response 200:**
 

package/docs/api/mcp/admin.md

@@ -1547,7 +1547,7 @@ Return the numeric status semaphore for a workflow.
 
 ## Ortho Pipeline
 
-AI-operable tools for driving the orthotic manufacturing pipeline. Each order passes through eight sequential stages (design → review → print → grind → glue → finish → qa → ship). The pipeline is a HotMesh durable workflow; each stage suspends at a `conditionLT` checkpoint until an escalation is resolved.
+AI-operable tools for driving the orthotic manufacturing pipeline. Each order passes through eight sequential stages (design → review → print → grind → glue → finish → qa → ship). The pipeline is a HotMesh durable workflow; each stage suspends at a `conditional` checkpoint until an escalation is resolved.
 
 A Claude agent loop calls `ortho_submit` to start an order, polls `ortho_pending` to see what's waiting, drives each stage forward with `ortho_complete_stage`, and monitors progress with `ortho_status`.
 

package/docs/api/mcp/human-queue.md

@@ -49,6 +49,20 @@ Check the status of an escalation. Returns status and resolver payload if resolv
 |-------|------|----------|-------------|
 | escalation_id | string | Yes | The escalation ID to check |
 
+### get_escalation_lookups
+
+Resolve the versioned knowledge lookups pinned on an escalation (`envelope.lookups`). Each ref answers with its immutable edition; a ref whose snapshot does not exist answers with `missing: true`. Like the other tools on this server, the call carries no per-user identity — the MCP surface reads at service scope.
+
+| | |
+|---|---|
+| Read-safe | Yes |
+
+**Parameters:**
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| escalation_id | string | Yes | The escalation whose pinned knowledge lookups to resolve |
+
 ### get_available_work
 
 List available escalations for a role. Returns pending, unassigned escalations.

package/docs/api/mcp/knowledge.md

@@ -35,7 +35,23 @@ Store a value in a 3-level additive hierarchy: domain > key > field. Upserts by
 
 ### get_knowledge
 
-Retrieve a single knowledge entry by domain and key.
+Retrieve a single knowledge entry by domain and key. Pass `version` to fetch a pinned immutable edition.
+
+| | |
+|---|---|
+| Read-safe | Yes |
+
+**Parameters:**
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| domain | string | Yes | Knowledge domain |
+| key | string | Yes | Document key |
+| version | number | No | Fetch this immutable edition instead of the live entry |
+
+### list_knowledge_versions
+
+List every immutable edition of a knowledge entry, newest first, with the current one marked. Every data-changing write mints a new version.
 
 | | |
 |---|---|

package/docs/api/sdk/escalations.md

@@ -197,6 +197,27 @@ const result = await lt.escalations.get({ id: 'esc_123' });
 
 ---
 
+## getLookups
+
+Resolve the versioned knowledge lookups pinned on an escalation (`envelope.lookups`). Enforces the same read scope as `get`; the refs on the row grant exactly the pinned editions they name. See [lookups](../../hitl/lookups.md).
+
+```typescript
+const result = await lt.escalations.getLookups({ id: 'esc_123' });
+// result.data.lookups → [{ domain, key, version, as?, data, missing? }]
+```
+
+**Parameters:**
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `id` | `string` | Yes | Escalation UUID |
+
+**Returns:** `LTApiResult<{ lookups }>` -- each entry is `{ domain, key, version, as?, data, missing? }`.
+
+**Auth:** Required
+
+---
+
 ## getByWorkflowId
 
 List all escalations for a given workflow ID.
@@ -342,29 +363,31 @@ The in-process library takes the same patch as a third argument:
 
 ---
 
-## conditionLT (workflow helper)
+## conditional (workflow helper)
 
-Wait for a signal and automatically resolve the associated escalation. This is the counterpart to `executeLT` — where `executeLT` wraps `startChild` + `condition`, `conditionLT` wraps `condition` + escalation resolution.
+Wait for a signal and automatically resolve the associated escalation. This is the counterpart to `executeLT` — where `executeLT` wraps `startChild` + `condition`, `conditional` wraps `condition` + escalation resolution.
 
 ```typescript
-conditionLT<T>(signalId: string, escalation?: ConditionQueueConfig): Promise<T | false | null>
+conditional<T>(signalId: string, escalation?: ConditionQueueConfig): Promise<T | false | null>
 ```
 
+> `conditionLT` is a deprecated alias of `conditional`. Existing code continues to work.
+
 ### Two ways to pause on an escalation
 
 There are two ways to make a workflow pause as a claimable escalation, and they are not equivalent in cost:
 
 - **Native `condition(signalId, escalationConfig)` — the efficient primitive.** HotMesh's `condition` takes an optional escalation config as its second argument. The row is written inside the workflow's Leg1 checkpoint, with `signal_key = signalId`. Resolving it (`resolve` / `resolveBySignalKey`) marks the row resolved **and** delivers the signal in one guarded transaction, resuming the job in place. No create activity, no enrich step, and **no proxy-activity round-trip on the resume** — the resolve is the whole transaction. This is the path to prefer.
 
-- **`conditionLT(signalId, config?)` — long-tail sugar.** With a config it delegates to the native efficient `condition` above (same atomic behavior — use it freely). Without a config it also supports the older **two-step** pattern: an escalation created separately, where the resume injects `$escalation_id` and `conditionLT` resolves it through a durable `proxyActivity` (`ltResolveEscalation`). That extra activity round-trip is the cost of the two-step form; the efficient form (and native `condition`) avoid it.
+- **`conditional(signalId, config?)` — long-tail sugar.** With a config it delegates to the native efficient `condition` above (same atomic behavior — use it freely). Without a config it also supports the older **two-step** pattern: an escalation created separately, where the resume injects `$escalation_id` and `conditional` resolves it through a durable `proxyActivity` (`ltResolveEscalation`). That extra activity round-trip is the cost of the two-step form; the efficient form (and native `condition`) avoid it.
 
-Reach for native `condition(signalId, config)` when you want the leanest path; reach for `conditionLT` for the ergonomic wrapper or to support the legacy two-step flow. Both resume the same row, and both accept the resolve-time `metadata` patch (the efficient path merges it in the single guarded UPDATE; the two-step path forwards it through `ltResolveEscalation` into that same atomic resolve).
+Reach for native `condition(signalId, config)` when you want the leanest path; reach for `conditional` for the ergonomic wrapper or to support the legacy two-step flow. Both resume the same row, and both accept the resolve-time `metadata` patch (the efficient path merges it in the single guarded UPDATE; the two-step path forwards it through `ltResolveEscalation` into that same atomic resolve).
 
 ### Atomic form (recommended)
 
 Pass an escalation config as the second argument. The escalation row is written inside the workflow's Leg1 checkpoint — one commit, crash-safe: no separate `ltCreateEscalation` activity, no enrich step. `signal_key` is set to `signalId`, so the dashboard resolve endpoint (resolve-by-id → Path 0) and `POST /escalations/resolve-by-signal-key` resume *this* job in place, and `system.escalation.{role}.{id}.created` fires automatically.
 
-`conditionLT` returns `T | false | null`:
+`conditional` returns `T | false | null`:
 - `T` — the resolver's payload (normal resolution)
 - `false` — the SLA timer fired first (`config.timeout`); the row is now `status='expired'`
 - `null` — the escalation was cancelled (workflow terminated or explicit `POST /api/escalations/:id/cancel`)
@@ -372,13 +395,13 @@ Pass an escalation config as the second argument. The escalation row is written
 Always guard for `null` and `false` before accessing the payload:
 
 ```typescript
-import { conditionLT } from '@hotmeshio/long-tail';
+import { conditional } from '@hotmeshio/long-tail';
 
 export async function stationWorker(envelope: LTEnvelope) {
   const ctx = Durable.workflow.workflowInfo();
   const signalId = `station-done-${ctx.workflowId}`;
 
-  const decision = await conditionLT<{ approved: boolean }>(signalId, {
+  const decision = await conditional<{ approved: boolean }>(signalId, {
     role: 'qc-inspector',
     type: 'orderPipeline',
     subtype: 'qc',
@@ -418,7 +441,7 @@ UPDATE, so operators can never resolve into a workflow that already moved on.
 Create the escalation first (e.g. to enrich routing metadata), then wait:
 
 ```typescript
-import { conditionLT } from '@hotmeshio/long-tail';
+import { conditional } from '@hotmeshio/long-tail';
 
 export async function myWorkflow(envelope: LTEnvelope) {
   const signalId = `approval-${Durable.workflow.workflowId}`;
@@ -443,7 +466,7 @@ export async function myWorkflow(envelope: LTEnvelope) {
   });
 
   // Pause — dashboard signals on resolve
-  const decision = await conditionLT<{ approved: boolean; notes: string }>(signalId);
+  const decision = await conditional<{ approved: boolean; notes: string }>(signalId);
 
   if (!decision) {
     // null = cancelled, false = timeout
@@ -457,10 +480,10 @@ export async function myWorkflow(envelope: LTEnvelope) {
 **How it works:**
 
 1. The workflow creates an escalation with `metadata.signal_id` pointing to its own signal key
-2. The workflow calls `conditionLT(signalId)` and pauses
+2. The workflow calls `conditional(signalId)` and pauses
 3. A reviewer claims and resolves the escalation in the dashboard
 4. The resolve API injects `$escalation_id` into the payload and signals the workflow
-5. `conditionLT` receives the signal, strips `$escalation_id`, calls `ltResolveEscalation` as a durable activity, and returns the clean payload
+5. `conditional` receives the signal, strips `$escalation_id`, calls `ltResolveEscalation` as a durable activity, and returns the clean payload
 
 The escalation resolution happens inside the workflow as a durable activity — crash-safe and transactional within the workflow's execution context.
 
@@ -472,7 +495,7 @@ If you use raw `Durable.workflow.condition()` instead, the `$escalation_id` fiel
 
 When a reviewer claims an escalation in the dashboard, a typed form is rendered instead of a raw JSON editor — if a schema is available. There are two ways to provide one:
 
-**Option 1 — Role `form_schema` (versioned):** The escalation form is owned by the target role as a versioned `form_schema`. A workflow pins a version through `conditionLT`'s `schemaVersion`; unpinned escalations resolve against the role's latest. Fields may carry `x-lt-bind` to map a form value to a path in the resolver payload. The deprecated workflow-config `resolver_schema` remains only as a legacy fallback.
+**Option 1 — Role `form_schema` (versioned):** The escalation form is owned by the target role as a versioned `form_schema`. A workflow pins a version through `conditional`'s `schemaVersion`; unpinned escalations resolve against the role's latest. Fields may carry `x-lt-bind` to map a form value to a path in the resolver payload. The deprecated workflow-config `resolver_schema` remains only as a legacy fallback.
 
 **Option 2 — Escalation metadata (dynamic):** Pass `form_schema` inside `metadata` when creating an escalation. This overrides any role-level schema.
 
@@ -659,7 +682,7 @@ const result = await lt.escalations.bulkTriage({
 
 ## cancel
 
-Permanently cancel a pending or claimed escalation. The workflow waiting on `conditionLT` receives `null`.
+Permanently cancel a pending or claimed escalation. The workflow waiting on `conditional` receives `null`.
 
 ```typescript
 const result = await lt.escalations.cancel({ id: 'esc_123' });
@@ -769,7 +792,7 @@ const result = await lt.escalations.claimByMetadata({
 
 Find and resolve an escalation by metadata key-value pair. Single atomic query with signal guard.
 
-If the escalation has `metadata.signal_id` (created by `conditionLT`), the endpoint signals the running workflow instead of resolving directly in the DB. `conditionLT` receives the signal and resolves the escalation durably inside the workflow. This preserves the same transactional integrity as the standard resolve-by-ID path.
+If the escalation has `metadata.signal_id` (created by `conditional`), the endpoint signals the running workflow instead of resolving directly in the DB. `conditional` receives the signal and resolves the escalation durably inside the workflow. This preserves the same transactional integrity as the standard resolve-by-ID path.
 
 ```typescript
 // Non-signal escalation → resolved atomically

package/docs/api/sdk/knowledge.md

@@ -51,6 +51,33 @@ const result = await lt.knowledge.getEntry({
 
 **Returns:** `LTApiResult<KnowledgeEntry>` or `{ found: false }` if not found.
 
+## getEntryVersion
+
+Get an immutable edition from an entry's version history.
+
+```typescript
+const result = await lt.knowledge.getEntryVersion({
+  domain: 'catalog',
+  key: 'materials',
+  version: 2,
+});
+```
+
+**Returns:** `LTApiResult<{ domain, key, version, data, tags, created_at }>` — 404 when the edition does not exist.
+
+## listEntryVersions
+
+List every edition of an entry, newest first, with the current one marked.
+
+```typescript
+const result = await lt.knowledge.listEntryVersions({
+  domain: 'catalog',
+  key: 'materials',
+});
+```
+
+**Returns:** `LTApiResult<{ domain, key, versions: [{ version, change_summary, created_at, is_current }] }>`
+
 ## storeEntry
 
 Create or update a knowledge entry. Data is merged by default; set `replace: true` to fully overwrite.

package/docs/api/sdk/roles.md

@@ -291,7 +291,7 @@ When the update changes `form_schema` or `metadata_schema`, the new pair is snap
 
 ## getSchema
 
-Fetch a role's `form_schema` + `metadata_schema` pair. With `version`, reads that immutable snapshot from the version history (the one an escalation pins via `conditionLT`'s `schemaVersion`); without it, reads the live (latest) schema and its current version number. A missing version is a 404 — it never falls back to a different version.
+Fetch a role's `form_schema` + `metadata_schema` pair. With `version`, reads that immutable snapshot from the version history (the one an escalation pins via `conditional`'s `schemaVersion`); without it, reads the live (latest) schema and its current version number. A missing version is a 404 — it never falls back to a different version.
 
 ```typescript
 const latest = await lt.roles.getSchema({ role: 'reviewer' });

package/docs/compilation.md

@@ -141,7 +141,7 @@ The dynamic path remains for genuinely new problems. But the long tail gets shor
 
 The Pipeline Designer compiles from execution traces — the dynamic path. But there's a second entry point: compiling directly from source code.
 
-If you've written a durable workflow using the Temporal-like API (`proxyActivities`, `sleep`, `condition`, `startChild`), you can compile it to a YAML DAG without executing it first. The `ltc` CLI reads your TypeScript source, extracts the orchestration structure, and produces an equivalent DAG that runs without replay overhead.
+If you've written a durable workflow using the durable workflow API (`proxyActivities`, `sleep`, `condition`, `startChild`), you can compile it to a YAML DAG without executing it first. The `ltc` CLI reads your TypeScript source, extracts the orchestration structure, and produces an equivalent DAG that runs without replay overhead.
 
 ```bash
 ltc compile workflows/assembly-line.ts

package/docs/compiler.md

@@ -1,6 +1,6 @@
 # The Workflow Compiler
 
-You wrote a durable workflow. It works. `proxyActivities`, `sleep`, `condition` — the Temporal-like API is productive and familiar. But under the hood, the durable engine replays the entire workflow function on every wake-up. Sleep three times in a ten-step workflow? Steps 1–3 replay on wake one. Steps 1–6 replay on wake two. Steps 1–9 replay on wake three. The replay is deterministic — it skips completed activities — but the function still executes from the top every time.
+You wrote a durable workflow. It works. `proxyActivities`, `sleep`, `condition` — the durable API is productive and familiar. But under the hood, the durable engine replays the entire workflow function on every wake-up. Sleep three times in a ten-step workflow? Steps 1–3 replay on wake one. Steps 1–6 replay on wake two. Steps 1–9 replay on wake three. The replay is deterministic — it skips completed activities — but the function still executes from the top every time.
 
 The compiled YAML DAG does the same work without replay. Each step fires exactly once. State flows explicitly between activities through input mappings. No function re-execution, no replay loop, no wasted cycles.
 
@@ -161,7 +161,7 @@ ltc compile examples/workflows/ --dry-run
   ● basic-signal/index.ts
     Function: basicSignal  ·  HotMesh Durable
     Activities: ltCreateEscalation, processApproval
-    Control flow: conditionLT
+    Control flow: conditional
 
   ● kitchen-sink/index.ts
     Function: kitchenSink  ·  HotMesh Durable

package/docs/dashboard.md

@@ -267,7 +267,7 @@ Accessible at `/admin/roles/:role/schema`. The versioned form behind a role's es
 
 - **Editor** — form fields as JSON Schema in a full-width editor, with an optional change summary recorded on the version the save creates. **Save Version** writes only the schema: every save that changes it appends an immutable snapshot and advances the current version.
 - **Version rail** — the full history with the current version marked. Expand any version to view its snapshot or load it into the editor as the base for the next save.
-- **Pinning** — workflows pin a version via `schemaVersion` in the `conditionLT` config, so their resolver form keeps that exact shape for the life of the run. Escalations without a pin render the latest version.
+- **Pinning** — workflows pin a version via `schemaVersion` in the `conditional` config, so their resolver form keeps that exact shape for the life of the run. Escalations without a pin render the latest version.
 
 **API:** `GET /api/roles/:role/schema` fetches the latest or a pinned version. `GET /api/roles/:role/schema/versions` lists the history. `PATCH /api/roles/:role` with `form_schema` (+ optional `change_summary`) saves a new version.
 

package/docs/data.md

@@ -40,7 +40,7 @@ The graph edges that don't fit the line. `lt_roles.parent_role` places a role in
 
 ### lt_role_schemas
 
-Immutable version history of each role's schema pair. Every change to a role's `form_schema` or `metadata_schema` (via `PATCH /api/roles/:role`, the SDK, or the `update_role` MCP tool) appends the next `(role, version)` snapshot in the same atomic statement that updates `lt_roles`. Escalations pin a version via `metadata.schema_version` (`conditionLT`'s `schemaVersion` field) so the resolver form they render stays exactly what their author specified; unpinned escalations use the live columns on `lt_roles`.
+Immutable version history of each role's schema pair. Every change to a role's `form_schema` or `metadata_schema` (via `PATCH /api/roles/:role`, the SDK, or the `update_role` MCP tool) appends the next `(role, version)` snapshot in the same atomic statement that updates `lt_roles`. Escalations pin a version via `metadata.schema_version` (`conditional`'s `schemaVersion` field) so the resolver form they render stays exactly what their author specified; unpinned escalations use the live columns on `lt_roles`.
 
 | Column | Type | Default | Description |
 |--------|------|---------|-------------|
@@ -101,7 +101,7 @@ Tracks every workflow execution. Created by the LT interceptor when a workflow s
 
 Records human intervention requests. Created when a workflow returns
 `type: 'escalation'`, when `ltCreateEscalation` runs, or atomically when a
-workflow calls `condition(signalId, config)` / `conditionLT(signalId, config)`.
+workflow calls `condition(signalId, config)` / `conditional(signalId, config)`.
 Updated when claimed or resolved.
 
 The storage is the **shared HotMesh table `public.hmsh_escalations`**
@@ -112,7 +112,7 @@ Indexes are managed by the SDK on `hmsh_escalations` (see below).
 
 Role read/write scope does **not** add columns here. An escalation carries a `role`
 and an optional `assigned_to`; work-surface scope lives on the membership table
-(`lt_user_roles`) and is applied at read time. `condition()` / `conditionLT()` and
+(`lt_user_roles`) and is applied at read time. `condition()` / `conditional()` and
 the escalation engine are unaffected.
 
 The columns below are the `hmsh_escalations` table. The public API record

package/docs/hitl/escalation.md

@@ -1,17 +1,19 @@
 # Creating Escalations
 
-## `conditionLT` — Atomic Pattern
+## `conditional` — Atomic Pattern
 
-Pass an escalation config to `conditionLT`. The escalation row, its metadata, and the resume timer all commit inside the workflow's Leg1 checkpoint — one write, crash-safe. The `signal_key` on the row is the resume key: the dashboard resolve endpoint and `POST /api/escalations/resolve-by-signal-key` both resume this job in place, and the `system.escalation.{role}.{id}.created` event fires automatically.
+Pass an escalation config to `conditional`. The escalation row, its metadata, and the resume timer all commit inside the workflow's Leg1 checkpoint — one write, crash-safe. The `signal_key` on the row is the resume key: the dashboard resolve endpoint and `POST /api/escalations/resolve-by-signal-key` both resume this job in place, and the `system.escalation.{role}.{id}.created` event fires automatically.
+
+> `conditionLT` is a deprecated alias of `conditional`. Existing code continues to work.
 
 ```typescript
-import { conditionLT } from '@hotmeshio/long-tail';
+import { conditional } from '@hotmeshio/long-tail';
 
 export async function approvalWorkflow(envelope: LTEnvelope) {
   const ctx = Durable.workflow.workflowInfo();
   const signalId = `approval-${ctx.workflowId}`;
 
-  const decision = await conditionLT<{ approved: boolean; notes?: string }>(signalId, {
+  const decision = await conditional<{ approved: boolean; notes?: string }>(signalId, {
     role: 'finance-reviewer',
     type: 'approval',
     subtype: 'budget-request',
@@ -48,7 +50,7 @@ export async function approvalWorkflow(envelope: LTEnvelope) {
 }
 ```
 
-`conditionLT` returns `T | false | null`:
+`conditional` returns `T | false | null`:
 - `T` — the human's resolver payload
 - `false` — SLA timeout (omit `timeout` for an open-ended wait)
 - `null` — cancellation (workflow terminated or explicit cancel)
@@ -60,7 +62,7 @@ Interactive and webhook resolves deliver the resolver's identity alongside the p
 ```typescript
 import type { EscalationResolution } from '@hotmeshio/long-tail';
 
-const decision = await conditionLT<{
+const decision = await conditional<{
   approved: boolean;
   $resolution?: EscalationResolution;
 }>(signalId, { role: 'order-reviewer', metadata: { orderId } });
@@ -80,7 +82,7 @@ Every field of the config — including all `metadata` facets — commits inside
 
 ### Early-signal buffering
 
-A resolve that races ahead of the `conditionLT` registration (a fast webhook, or a payload deposited before the workflow starts) is held as a pending signal and delivered when the wait registers — 10 minutes by default; pass `expire` to `signal()` when signaling early on purpose. Fan-out (`Promise.all` over many waits) scales the same way.
+A resolve that races ahead of the `conditional` registration (a fast webhook, or a payload deposited before the workflow starts) is held as a pending signal and delivered when the wait registers — 10 minutes by default; pass `expire` to `signal()` when signaling early on purpose. Fan-out (`Promise.all` over many waits) scales the same way.
 
 ---
 
@@ -89,7 +91,7 @@ A resolve that races ahead of the `conditionLT` registration (a fast webhook, or
 Every role carries a versioned `form_schema`. Every save that changes it appends an immutable snapshot to `lt_role_schemas` and advances the role's current version. Escalations pin one with `schemaVersion`:
 
 ```typescript
-const decision = await conditionLT<{ approved: boolean; lotNumber: string }>(signalId, {
+const decision = await conditional<{ approved: boolean; lotNumber: string }>(signalId, {
   role: 'reviewer',
   description: instructions,
   schemaVersion: 3,   // renders role schema v3, always, regardless of later edits
@@ -130,12 +132,12 @@ The reference examples ship as fully runnable seeds:
 ### Simple approval
 
 ```typescript
-import { conditionLT } from '@hotmeshio/long-tail';
+import { conditional } from '@hotmeshio/long-tail';
 
 export async function approveSpendWorkflow(envelope: LTEnvelope) {
   const ctx = Durable.workflow.workflowInfo();
 
-  const decision = await conditionLT<{ approved: boolean; notes?: string }>(
+  const decision = await conditional<{ approved: boolean; notes?: string }>(
     `spend-approval-${ctx.workflowId}`,
     {
       role: 'finance-reviewer',
@@ -173,7 +175,7 @@ export async function approveSpendWorkflow(envelope: LTEnvelope) {
 Dynamic checklist where item labels come from the workflow's envelope, not the static schema. Item count and wording vary per escalation without touching the form schema.
 
 ```typescript
-import { conditionLT } from '@hotmeshio/long-tail';
+import { conditional } from '@hotmeshio/long-tail';
 
 export async function stationCheckWorkflow(envelope: LTEnvelope) {
   const ctx = Durable.workflow.workflowInfo();
@@ -184,7 +186,7 @@ export async function stationCheckWorkflow(envelope: LTEnvelope) {
     { id: 'step_2', label: 'Sign the dispensing log' },
   ];
 
-  const result = await conditionLT<{ checks: Record<string, boolean> }>(
+  const result = await conditional<{ checks: Record<string, boolean> }>(
     `station-check-${ctx.workflowId}`,
     {
       role: 'station-operator',

package/docs/hitl/form.md

@@ -32,6 +32,7 @@ Declare `title` on every field whose key isn't already a readable label — it i
 | `number` | Number input |
 | `string` | Text input (default) |
 | `string` + `enum` | Dropdown select |
+| `string`/`number` + `x-lt-options` | Dropdown select — options resolved from the escalation context (see [x-lt-validation.md](x-lt-validation.md#dynamic-select-options-x-lt-options)) |
 | `null` | Read-only "null" display |
 | `array` | Tag display (read-only) |
 | `object` | Nested section with recursive fields, or a widget (see [x-lt-widget.md](x-lt-widget.md)) |

package/docs/hitl/iframe.md

@@ -51,8 +51,8 @@ const WORKBENCH_FORM_SCHEMA = {
   },
 };
 
-// Workflow side — the wait is a normal conditionLT; the iframe submits the payload
-const design = await conditionLT<{ stl_url: string }>(signalId, {
+// Workflow side — the wait is a normal conditional; the iframe submits the payload
+const design = await conditional<{ stl_url: string }>(signalId, {
   role: 'cad-designer',
   description: 'Design the widget for this order.',
   escalation_payload: JSON.stringify({ workbenchId, companyId }),