@hotmeshio/long-tail 0.8.4 → 0.9.0

package/docs/api/sdk/escalations.md

@@ -387,7 +387,7 @@ export async function stationWorker(envelope: LTEnvelope) {
     workflowType: 'stationWorker',
     metadata: { orderId: envelope.data.orderId, station: 'qc' },
     envelope: { instructions: 'Review and approve or reject' },
-    timeout: '24h',   // SLA for this worklist row (hotmesh 0.25.1+)
+    timeout: '24h',   // SLA for this worklist row
   });
 
   if (decision === false) {
@@ -405,7 +405,7 @@ export async function stationWorker(envelope: LTEnvelope) {
 
 ### SLA-gated waits (`timeout`)
 
-`ConditionQueueConfig.timeout` (hotmesh 0.25.1+) arms the same resume timer as
+`ConditionQueueConfig.timeout` arms the same resume timer as
 `condition(signalId, '24h')` **in the same single Leg1 write** that creates the
 escalation row. The race is resolved atomically on both sides: a signal that
 arrives first resolves the row normally and the timer is inert; a timer that
@@ -823,6 +823,41 @@ const result = await lt.escalations.resolveByIds({
 
 **Returns:** `LTApiResult<{ resolved: number; escalationIds: string[] }>` — only still-`pending` rows are resolved.
 
+## resolveAllOrNone
+
+Atomic bulk resolve with per-row payloads: every listed escalation resolves with its own `resolverPayload` in one SQL statement, or nothing resolves. Rows backing a live `condition()` waiter are first-class — each waiter's wake commits with its resolve, delivering that row's payload as the condition's return value (the same wake contract as `resolve`). Use it for gang handoffs where each member must receive a distinct mandate and a partial batch is unacceptable.
+
+RBAC matches `resolveByIds`: per-item write scope, and any missing or out-of-scope id returns 404 with nothing resolved. `requireClaimed` additionally asserts — inside the same guarded statement — that every row is currently assigned to the caller, closing the window where another principal re-claims a member between the caller's claim and the resolve.
+
+```typescript
+const result = await lt.escalations.resolveAllOrNone({
+  items: [
+    { id: 'esc_left', resolverPayload: { gcodeRef: 'gcode-left', unit: 'left' } },
+    { id: 'esc_right', resolverPayload: { gcodeRef: 'gcode-right', unit: 'right' } },
+  ],
+  metadata: { outcome: 'gang-dispatched' },
+  requireClaimed: true,
+});
+
+if (result.status === 409) {
+  // nothing resolved — result.data.failed names exactly the blocking rows
+  // (not-found | already-resolved | already-cancelled | already-expired |
+  //  assignee-mismatch | unsupported-resolution-path); re-gang around them
+}
+```
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `items` | `Array<{ id, resolverPayload }>` | Yes | The batch — each row resolves with its own payload. Ids must be unique; max 100 items (`LT_ESCALATION_BULK_RESOLVE_MAX`) |
+| `metadata` | `Record<string, any>` | No | Shared outcome patch merged into every row's GIN-indexed metadata |
+| `requireClaimed` | `boolean` | No | Assert every row is currently assigned to the caller, inside the atomic statement |
+
+**Returns:** `LTApiResult<{ resolved: number; escalationIds: string[] }>` on success. On 409 the data carries `{ error, failedIds, failed: [{ id, reason }] }` — only the rows that blocked the batch are listed; resolvable members stay pending, untouched.
+
+Rows that resolve through legacy signal routing (`metadata.signal_id` / `metadata.signal_routing`) require the single `resolve` path, which delivers their workflow signal; including one blocks the batch with reason `unsupported-resolution-path`. Password-format fields are redacted per row against that row's own `form_schema` before the payload enters the signal store.
+
+**Auth:** Required
+
 ## resolveBySignalKey
 
 Resolve an efficient (atomic) escalation directly by its `signal_key` and resume the waiting workflow in place. For callers that know the deterministic signal id and want to skip the id lookup. RBAC-scoped to the escalation's role.

package/docs/dashboard.md

@@ -6,7 +6,7 @@ The Long Tail dashboard is a React single-page application for managing procedur
 
 The sidebar organizes pages into six groups.
 
-### React
+### Monitor
 
 The reactive, event-driven surface — where operations watch the floor and builders configure choreography.
 
@@ -196,7 +196,9 @@ Lists all procedural workflow runs across the system.
 
 - **Tier filter** (top) — switch between All, Certified, and Durable to focus on specific workflow types.
 - **Columns:** Workflow name, workflow ID, status (running/completed/failed), start time, and duration.
-- **Click any row** to see the full execution detail: task record with milestones, activity checkpoints, resolver payloads, and any associated escalations.
+- **Click any row** to see the full execution detail: the swimlane timeline and events fill the main column, and a full-height side panel carries the record's facts. The main header stays quiet — just the title and a panel toggle; status, the refresh/copy toolbar, and the **Actions** menu (a small caret anchor at the right of the panel's icon row) all live in the panel. The panel and main column share the width as a flex set — the main column narrows as the panel expands.
+  - **Details** — status, workflow identity (type, ID, parent), task queue, start/end times, duration, history size, and activity counts.
+  - **Escalations** — every escalation the workflow raised, each a row with type, role, age, and status badge, so multiple escalations across the run's lifecycle read as a table rather than running on; related child tasks list the same way below.
 - **Duration** is computed from start to completion — useful for identifying slow workflows or comparing performance across versions.
 
 **API:** `GET /api/workflows/executions` lists runs with tier, status, and pagination filters.
@@ -265,6 +267,15 @@ Accessible at `/admin/roles/:role/schema`. The versioned form behind a role's es
 
 **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.
 
+### Escalations List Schema
+
+Accessible at `/admin/roles/:role/list-schema`. The versioned rich view for the role's escalation **list** page — the list-page analog of the resolve form. Opt-in: when a role owns a `list_schema`, its list page renders a role-authored view (the live item as a card plus a load-on-demand history) instead of the engineer table, scoped to that one role. See the [HITL guide](hitl-guide.md#escalations-list-schema) for the `x-lt-layout` / `x-lt-active` / `x-lt-history` vocabulary.
+
+- **Editor + version rail** — same shape as the Escalation Schema editor, but on its own **independent** version timeline: editing the list view never advances the resolve form's version.
+- The list always renders the latest version — no pinning (a display template, not a payload contract).
+
+**API:** `GET /api/roles/:role/list-schema` (latest or `?version=`), `GET /api/roles/:role/list-schema/versions`, and `PATCH /api/roles/:role` with `list_schema` (+ optional `change_summary`).
+
 ### DB Maintenance
 
 Database housekeeping tools for keeping PostgreSQL healthy under sustained workflow load.
@@ -294,7 +305,7 @@ Browse individual stream messages from the Postgres engine and worker stream tab
 
 - **Namespace & Source** — required filters. Engine streams carry internal orchestration messages; worker streams carry task messages with workflow metadata (job ID, activity, message type).
 - **Filters** — narrow by status (pending, claimed, processed, dead-lettered) and stream name (partial match).
-- **Message detail** — click any row to open the inspector panel. Shows timestamps, retry info, worker metadata, and the full JSON payload with expandable tree view.
+- **Message detail** — click any row to slide open the inspector panel: a full-height column beside the table with its own scroll, like the left nav. The table narrows to make room, so no cells are covered. Shows timestamps, retry info, worker metadata, and the full JSON payload with expandable tree view.
 - **Pagination & sorting** — standard controls. Sort by created time, stream name, or priority.
 
 Messages are read-only. Status is derived from timestamps: pending (no timestamps set), claimed (reserved), processed (expired), or dead-lettered.
@@ -307,9 +318,11 @@ The central queue for all escalation activity across every workflow.
 
 - **Filter bar** — filter by status (pending/claimed/resolved), role, workflow type, priority, and time window.
 - **Columns:** Escalation ID, workflow type, role, status, priority, created time, and claimed-by user.
+- **Rich list view** — when the list is scoped to exactly one role (`?role=<role>`) and that role owns a [list schema](#escalations-list-schema), a role-authored view renders in place of the table (the live item as a card, plus a load-on-demand history), with a **Table view** toggle back to the columns.
 - **Claim** — click the claim action to lock an escalation to your user. Only users with matching roles see pending escalations. The queue list and aggregate stats reflect `read_all` memberships — a member scoped to `read_self` lands directly on their own assigned item in user mode rather than browsing the full queue.
 - **Resolve** — after claiming, submit a resolver payload. The form is pre-filled from the role's versioned `form_schema` field defaults and from the workflow's seeded `envelope.formDefaults` (reverse-mapped through each field's `x-lt-bind`). The dashboard maps the flat form to the nested payload via `x-lt-bind` and the submitted payload is stored as-is. Resolution triggers a workflow re-run with the resolver data injected. A `member` whose `write_scope` is `self` can resolve only items already assigned to them; `write_scope=none` is read-only.
 - **Escalate** — forward a claimed escalation to a higher-tier role via the escalation chain.
+- **Side panel** — a slide-in beside the resolve form with switchable views, selected by the icon set at its top: **Help** (the form's `x-lt-help` markdown, `{{domain.path}}`-interpolated against the live record, or a state-aware hint such as "Claim this escalation to enable the form"), **Details** (status, role, priority, claim provenance, timestamps, and — for builders — identifier links), **AI Analysis** (what triage diagnosed and corrected — shown when AI is enabled and triage data is present), **Metadata** (the row's metadata values), **Context** (input envelope, escalation context, resolver payload), and **Record** (the raw escalation JSON, builders only). The panel and form share the width as a flex set — the form column narrows as the panel expands. It opens expanded on Help when the form carries `x-lt-help`, stays hidden otherwise, and the page-header panel button toggles it either way.
 
 **API:** `GET /api/escalations` lists with filters. `POST /api/escalations/:id/claim` claims. `POST /api/escalations/:id/resolve` resolves.
 

package/docs/data.md

@@ -104,7 +104,7 @@ Records human intervention requests. Created when a workflow returns
 workflow calls `condition(signalId, config)` / `conditionLT(signalId, config)`.
 Updated when claimed or resolved.
 
-Since v0.5.3 the storage is the **shared HotMesh table `public.hmsh_escalations`**
+The storage is the **shared HotMesh table `public.hmsh_escalations`**
 (written by both long-tail and the HotMesh SDK). `lt_escalations` remains as a
 backward-compatible **view** over it — `SELECT *` plus a computed `available`
 column — so existing read queries and the public API are unchanged. Indexes are

package/docs/hitl-guide.md

@@ -83,9 +83,24 @@ export async function approvalWorkflow(envelope: LTEnvelope) {
 }
 ```
 
-The `timeout` field (hotmesh 0.25.1+) makes the wait SLA-gated in the same
-single Leg1 write: one `conditionLT` call yields the worklist row AND the
-resume timer. Omit it for an open-ended wait.
+The `timeout` field makes the wait SLA-gated in the same single Leg1 write:
+one `conditionLT` call yields the worklist row AND the resume timer. Omit it
+for an open-ended wait.
+
+Two engine contracts worth building on:
+
+- **The row is complete from its first visible moment.** Every field of the
+  config — including `metadata` facets — commits inside the Leg1 checkpoint.
+  A claim-by-metadata router or a version-pinned facet (e.g. a
+  `schema_version` the resolver UI renders) can trust every row it reads;
+  there is no window where a row is visible but its metadata is still en route.
+- **Early signals are buffered.** A resolve that races ahead of the
+  `condition()` registration (a fast webhook, 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()` (e.g. `'1h'`)
+  when signaling early on purpose. Fan-out (`Promise.all` over many waits)
+  scales the same way: buffering covers every signal that outruns its
+  registration.
 
 #### Two-step form
 
@@ -209,12 +224,48 @@ await lt.escalations.resolve({
 
 The patch is distinct from the resolver payload: the payload resumes the paused workflow and is not indexed; the metadata patch is the durable, queryable record on the row. Use it for the audit trail and analytics — disposition, reviewer, time-to-resolve — so the escalation table answers *what was asked, what was decided, and how long it took* without a parallel log.
 
+### Resolving a set atomically
+
+When one decision settles a SET of waits — each with its own payload — use
+`lt.escalations.resolveAllOrNone({ items })` (`POST /api/escalations/resolve-all-or-none`).
+Every listed row resolves with its own `resolverPayload` in one SQL statement,
+waking each parked workflow with its own value, or nothing resolves and the
+409 body names exactly the rows that blocked (`failedIds` + reasons). Pass
+`requireClaimed: true` in claim-then-resolve flows to assert, inside the same
+statement, that every row is still assigned to the caller. See the
+[SDK reference](./api/sdk/escalations.md#resolveallornone) for the full contract.
+
 ---
 
 ## JSON Schema Form Authoring
 
 The dashboard renders forms automatically from JSON Schema. No frontend code needed.
 
+The full custom vocabulary at a glance — every `x-lt-*` keyword and extension key the renderer honors:
+
+| Keyword | Level | Purpose |
+|---------|-------|---------|
+| `x-lt-widget` | field | Rich control: `file-upload`, `code-editor`, `signature`, `rich-text`, `markdown` |
+| `x-lt-language` | field | Syntax hint shown by the `code-editor` widget |
+| `accept` | field | File-type filter for the `file-upload` widget (e.g. `".pdf,.png"`) |
+| `x-lt-bind` | field | Path this field's value occupies in the resolver payload (e.g. `"customer.email"`) |
+| `x-lt-span` | field | Column span in a `two-column` layout (`2` = full width) |
+| `x-lt-order` | schema | Field render sequence |
+| `x-lt-layout` | schema | `"two-column"` grid layout |
+| `x-lt-help` | schema | Markdown guidance for the side panel's Help view; `{{domain.path}}` tokens interpolate live record values |
+| `x-lt-context` | schema | Plain-text fallback for the Help view when `x-lt-help` is absent |
+| `x-lt-viewport` | schema | Replace the generated form with a custom iframe UI |
+| `format` | field | Input specialization: `password`, `date`, `date-time`, `email`, `uri`, `textarea` |
+| `readOnly` | field | Static display (or a rendered content block with the `markdown` widget) |
+| `required` | schema | Fields that must be filled before submit |
+| `title` / `description` | both | Section header / helper text |
+
+The working reference is `examples/workflows/rich-form/` — the `intake-reviewer` role's
+versioned `form_schema` (seeded by `examples/seed-rich-form.ts`) exercises the whole
+vocabulary in one form: side-panel help (`x-lt-help` with a checklist, table, tokens,
+and a relative link), two-column layout, ordering, date and email formats, enum, file
+upload, spans, required fields, and `x-lt-bind` mapping into a nested payload.
+
 ### Supported Field Types
 
 | JSON Type | Renders As |
@@ -260,6 +311,7 @@ For rich inputs beyond standard HTML types:
 | `"code-editor"` | Monospace textarea with tab-key support. Use `x-lt-language` for syntax hint. |
 | `"signature"` | HTML5 Canvas drawing pad. Outputs PNG data URL. |
 | `"rich-text"` | Tall textarea for formatted text input. |
+| `"markdown"` | Markdown source, rendered with the same engine as the docs drawer (headings, tables, lists, code blocks, callouts). Editable fields get a Write/Preview toggle; with `readOnly: true` the field is a pure content block — see below. |
 
 ```json
 {
@@ -285,6 +337,101 @@ For rich inputs beyond standard HTML types:
 }
 ```
 
+#### Markdown content blocks
+
+`readOnly: true` + `x-lt-widget: "markdown"` turns a field into a rendered content
+block: the markdown in its `default` displays as HTML inside the form — headings,
+tables, checklists, callouts. The versioned schema carries the page source itself,
+so review instructions and SOPs version with the form they belong to, and the
+source rides along in the resolver payload like any read-only field.
+
+```json
+{
+  "properties": {
+    "review_guide": {
+      "type": "string",
+      "readOnly": true,
+      "x-lt-widget": "markdown",
+      "x-lt-span": 2,
+      "default": "### Review checklist\n\n1. Confirm the **legal name** matches.\n2. Send a test message before approving.\n\n> Escalate non-standard contract language to legal."
+    }
+  }
+}
+```
+
+Without `readOnly`, the field is a markdown *editor* — the resolver writes source in
+a Write/Preview toggle and the submitted value is the markdown text.
+
+### Help Panel (`x-lt-help`)
+
+Schema-level `x-lt-help` carries the form's guidance — checklists, tier tables,
+callouts, links — as markdown. The dashboard renders it in the side panel beside the
+form, so the form itself stays a clean title and fields while the SOP sits one glance
+to the right. The help versions with the form: it lives in the same `form_schema`
+snapshot in `lt_role_schemas`.
+
+```json
+{
+  "title": "Customer Intake",
+  "x-lt-help": "### Review checklist\n\n1. Confirm the **legal name** matches.\n2. Send a test message before approving.\n\nThis escalation is **{{escalation.status}}** in the **{{escalation.role}}** queue.\n\n[Back to the queue](/escalations/queue?role=intake-reviewer)",
+  "properties": { ... }
+}
+```
+
+`{{domain.path}}` tokens interpolate live values from the escalation surface using the
+`x-lt-bind` path syntax (dot keys, optional `[n]` indices). Five domains are available:
+
+| Domain | Resolves against |
+|--------|------------------|
+| `escalation` | The escalation row (`{{escalation.role}}`, `{{escalation.status}}`) |
+| `metadata` | The row's metadata dict (`{{metadata.schema_version}}`) |
+| `envelope` | The workflow-sent input envelope (`{{envelope.formDefaults.customer.name}}`) |
+| `payload` | The escalation context payload (`{{payload.category}}`) |
+| `resolver` | The submitted resolver payload (`{{resolver.notes}}`) |
+
+A missing value renders as an em dash. Links whose href starts with `/` navigate
+inside the dashboard.
+
+The Help view falls back in order: `x-lt-help` → `x-lt-context` (plain text) → a
+state-aware hint ("Claim this escalation to enable the form", "Fill out the form and
+submit to resolve it", and so on), so the panel always tells the resolver what the
+page expects of them. The panel's other views surface the record itself: **Metadata**
+(the row's metadata values), **Context** (input envelope, escalation context, resolver
+payload), and **Record** (the raw escalation JSON, builders only).
+
+### Payload Binding (`x-lt-bind`)
+
+The form is flat; the payload the workflow consumes rarely is. A field may declare
+`x-lt-bind` — the path its value occupies in the resolver payload (dot keys, optional
+`[n]` indices). The dashboard maps the flat form through the binds on submit, and
+reverse-maps workflow-seeded `envelope.formDefaults` through them to prefill. A field
+with no bind lands at its own name at the payload root (1:1).
+
+```json
+{
+  "properties": {
+    "customer_name": { "type": "string", "x-lt-bind": "customer.name" },
+    "contact_email": { "type": "string", "format": "email", "x-lt-bind": "customer.email" },
+    "tier": { "type": "string", "enum": ["starter", "professional"], "x-lt-bind": "contract.tier" },
+    "notes": { "type": "string", "format": "textarea" }
+  }
+}
+```
+
+Submitting `{ customer_name, contact_email, tier, notes }` stores:
+
+```json
+{
+  "customer": { "name": "…", "email": "…" },
+  "contract": { "tier": "…" },
+  "notes": "…"
+}
+```
+
+Only the FORM is versioned on the role — the payload shape is the workflow's own
+contract, produced by the binds. Evolve the form and its binds together, and the
+workflow's resolver type in the same commit.
+
 ### Layout Options (`x-lt-layout`)
 
 Control how fields are arranged:
@@ -349,8 +496,9 @@ Fields with `readOnly: true` display as static text. Useful for showing context
 ### Schema Title and Description
 
 The `title` and `description` at the schema root are used in the UI:
-- **`title`**: Shown as the section header (replaces "Submit Your Resolution" in user mode)
-- **`description`** or **`x-lt-context`**: In user mode, displayed as a context panel alongside the form in a two-panel layout
+- **`title`**: Shown as the form's section header
+- **`description`**: Shown as helper text beneath the title — keep it to a short phrase; longer guidance belongs in `x-lt-help`
+- **`x-lt-help`**: Rendered as markdown in the side panel beside the form
 
 ```json
 {
@@ -469,27 +617,36 @@ Communication happens via `window.postMessage`.
 
 ---
 
-## Dev Mode vs User Mode
+## The Escalation Detail Page
 
-The escalation detail page has two viewing modes:
+The escalation detail page has one view, built for the person resolving the item: the
+escalation's description is the page title, the form starts directly beneath it, and
+the action bar closes the page. The lifecycle sparkline (waiting / claimed / resolved
+ratios) sits as a short persistent row above the side panel. Everything else lives in
+the side panel, ordered by specificity:
 
-| Aspect | Dev Mode | User Mode |
-|--------|----------|-----------|
-| **Default for** | Admins, superadmins, engineers | All other roles |
-| **Shows** | Everything | Title, description, form, action bar |
-| **Hides** | Nothing | Technical IDs, raw JSON, envelope data, AI triage, raw JSON editor |
-| **Persistence** | sessionStorage (per browser session) | sessionStorage |
+| View | Shows | Available to |
+|------|-------|--------------|
+| **Help** | The form's `x-lt-help` markdown, or a state-aware hint | Everyone |
+| **Details** | Status, role, priority, claim provenance, timestamps; identifier links below a divider | Everyone (identifiers: builders) |
+| **AI Analysis** | What triage diagnosed and corrected | When AI is enabled and triage data is present |
+| **Metadata** | The row's metadata values | Everyone |
+| **Context** | Input envelope, escalation context, resolver payload | Everyone |
+| **Record** | The raw escalation JSON | Builders (admins, superadmins, engineers) |
 
-**Key principle**: User mode only hides technical debugging information. All HITL workflow actions (claim, submit, escalate, release) are always visible in both modes.
+The page is two fixed-height columns beneath the global toolbar — the form column and
+the panel each scroll independently, so the panel stays pinned like the left nav while
+long forms or long panel content scroll. The form column narrows as the panel expands
+(the panel is capped at half the page). When the form carries `x-lt-help`, the panel
+opens expanded on the Help view; otherwise it stays hidden until the page-header panel
+button summons it.
 
-Privileged users can toggle between modes via the switch in the page header.
+### Designing the Form
 
-### Designing for User Mode
-
-To create a polished user mode experience:
+To create a polished resolve experience:
 
 1. Set `title` on your schema — it replaces the section header
-2. Set `description` or `x-lt-context` — it appears as a context panel in a two-panel layout
+2. Set `x-lt-help` — checklists, tables, and links render as markdown in the side panel, with `{{domain.path}}` tokens for live record values; keep `description` to a short subtitle
 3. Use `readOnly` fields for context the human needs to see but shouldn't edit
 4. Use `x-lt-order` to put the most important fields first
 5. Use `required` to guide users on what must be filled
@@ -497,6 +654,68 @@ To create a polished user mode experience:
 
 ---
 
+## Escalations List Schema
+
+The form schema formats one escalation on the detail page. A role can also own a
+`list_schema` that formats its whole **list** page — the list-page analog of the
+resolve form. It is opt-in and applies only when the list is scoped to exactly one
+role (`/escalations/available?role=<role>`). Absent, the list renders the standard
+engineer table; present, a rich role-authored view renders with a "Table view" toggle
+one click away. It is versioned **independently** of the form schema (its own timeline;
+a list edit never bumps the form version) and edited on its own page,
+`/admin/roles/:role/list-schema`. The list always renders the latest version.
+
+This is what turns a queue like a `policy-document` role — where a looped workflow
+keeps exactly one escalation live and each resolved one is a revision — into a document
+with a history, instead of a one-row table.
+
+### Vocabulary
+
+Every string is a markdown/text template run through the same `{{domain.path}}` token
+binding as `x-lt-help` (domains `escalation | metadata | envelope | payload | resolver`,
+evaluated against each row); `body` strings render through the markdown renderer.
+
+| Key | Level | Purpose |
+|-----|-------|---------|
+| `x-lt-layout` | schema | `"active-history"` (two columns), `"active"` (card only), or `"table"` (fallback) |
+| `x-lt-help` | schema | Optional markdown header, interpolated with the active row |
+| `x-lt-active` | schema | The live item card: `{ title, subtitle?, body?, fields?: [{label, value}] }` |
+| `x-lt-history` | schema | History column: `{ row: { title, subtitle?, meta? }, limit?, status? }` |
+
+The **active** item is the first non-terminal escalation. The **history** column is not
+auto-loaded — a "Load full history" link fetches resolved items on demand (`status`
+defaults to `resolved`, `limit` to 25). Unknown/absent `x-lt-layout` is a safe no-op
+that falls back to the table.
+
+### Example — a policy-document role
+
+```json
+{
+  "x-lt-layout": "active-history",
+  "x-lt-help": "# {{metadata.title}}\nThe authoritative policy. One revision is live at a time.",
+  "x-lt-active": {
+    "title": "{{metadata.title}}",
+    "subtitle": "Revision {{metadata.revision}} · effective {{metadata.effective_date}}",
+    "body": "{{metadata.document_markdown}}",
+    "fields": [
+      { "label": "Owner", "value": "{{metadata.owner}}" },
+      { "label": "Claimed by", "value": "{{escalation.assigned_to}}" }
+    ]
+  },
+  "x-lt-history": {
+    "row": { "title": "{{metadata.title}} — revision {{metadata.revision}}" },
+    "limit": 25
+  }
+}
+```
+
+The working reference is `examples/workflows/policy-document/` (role seeded by
+`examples/seed-policy-document.ts`): a looped workflow opens one policy-review
+escalation, parks on it, and folds each resolution into the next revision — so the
+policy facts ride the row's metadata and the list view reads them with `{{metadata.*}}`.
+
+---
+
 ## Role-Based Routing
 
 Escalations are routed by role. Users only see escalations for roles they hold.
@@ -782,10 +1001,10 @@ When you author a HITL-backed workflow, the platform handles:
 - **Claim/release** — soft-lock with TTL, prevents duplicate work
 - **Real-time updates** — NATS/Socket.IO events push changes to the dashboard instantly
 - **Form rendering** — JSON Schema to rich form controls, no frontend code needed
-- **Dev/user mode** — technical vs clean views, per-session preference
+- **Side panel** — help, AI analysis, metadata, context, and raw-record views beside the form
 - **Section state persistence** — collapsed sections remembered across navigation
 - **Escalation chains** — users can re-route work to other roles
-- **AI triage** — optional auto-resolution for common patterns (dev mode)
+- **AI triage** — optional auto-resolution for common patterns
 - **Signal routing** — 5 resolution paths (conditionLT, waitFor, triage, re-run, notification-only)
 - **Credential security** — password fields use ephemeral tokens, never stored in plain text
 - **Telemetry** — trace IDs link escalations to OpenTelemetry traces

package/docs/maintenance.md

@@ -28,6 +28,7 @@ await start({
       { target: 'jobs',    olderThan: '14 days',  action: 'delete', hasEntity: false },
       { target: 'jobs',    olderThan: '14 days',  action: 'prune',  hasEntity: true },
       { target: 'jobs',    olderThan: '180 days', action: 'delete', pruned: true },
+      { target: 'escalations', olderThan: '180 days', action: 'delete' },
     ],
   },
 });
@@ -42,14 +43,15 @@ await start({
 
 ## What gets cleaned
 
-Four categories of data are subject to maintenance:
+Five categories of data are subject to maintenance:
 
 | Category | Description |
 |---|---|
-| **Streams** | Redis-style stream messages used internally by HotMesh to coordinate activities. These are pure infrastructure; no user-facing data resides here. |
+| **Streams** | Stream messages used internally by HotMesh to coordinate activities. These are pure infrastructure; no user-facing data resides here. |
 | **Transient jobs** | Job rows where the `entity` column is `NULL`. These represent activity executions, signal deliveries, and other bookkeeping that is not tied to a named workflow entity. They serve no purpose after execution completes. |
 | **Entity jobs** | Job rows where `entity` is set. These represent actual workflow instances -- the rows that back `Durable.Client.workflow.search()` calls and execution exports. Deleting them removes the workflow record entirely. |
 | **Pruned jobs** | Entity jobs that have already had their execution artifacts stripped (the `pruned_at` column is not `NULL`). These retain core data but no longer carry execution scaffolding. They can be hard-deleted after a longer retention window. |
+| **Terminal escalations** | Escalation rows in a terminal status (`resolved`, `cancelled`, `expired`). Terminal rows are inert audit records -- every engine state transition guards on `status = 'pending'`, so aging them out is safe for live waiters, claims, and signal delivery. The engine-owned prune deletes in atomic batches until the retention horizon is drained. Pending rows are never touched. |
 
 ## Prune vs. delete
 
@@ -93,11 +95,12 @@ Defined in `types/maintenance.ts`. Each rule describes a single cleanup operatio
 
 | Field | Type | Required | Description |
 |---|---|---|---|
-| `target` | `'streams' \| 'jobs'` | Yes | The resource type to act on. |
+| `target` | `'streams' \| 'jobs' \| 'escalations'` | Yes | The resource type to act on. |
 | `action` | `'delete' \| 'prune'` | Yes | Whether to remove entirely or strip execution artifacts. |
 | `olderThan` | `string` | Yes | A PostgreSQL interval expression: `'7 days'`, `'24 hours'`, `'90 days'`. |
 | `hasEntity` | `boolean` | No | When `target` is `'jobs'`: `true` selects entity jobs, `false` selects transient jobs (where `entity IS NULL`). |
 | `pruned` | `boolean` | No | When `true`, only targets jobs where `pruned_at IS NOT NULL` -- jobs that have already been pruned. |
+| `statuses` | `Array<'resolved' \| 'cancelled' \| 'expired'>` | No | When `target` is `'escalations'`: which terminal statuses to age out. Defaults to all three. |
 
 ### `LTMaintenanceConfig`
 

package/docs/oauth-and-delegation.md

@@ -143,7 +143,7 @@ if (ctx) {
 }
 ```
 
-The MCP client (`callServerTool`) also reads `ToolContext` automatically. When no explicit `authContext` is passed, it derives `_auth` from the ambient context. This closes the identity gap for YAML workflow workers, which previously had no auth propagation.
+The MCP client (`callServerTool`) also reads `ToolContext` automatically. When no explicit `authContext` is passed, it derives `_auth` from the ambient context — YAML workflow workers get auth propagation this way without any explicit wiring.
 
 ## Delegation Tokens
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hotmeshio/long-tail",
-  "version": "0.8.4",
+  "version": "0.9.0",
   "description": "Long Tail Workflows — Durable AI workflows with human-in-the-loop escalation. Powered by PostgreSQL.",
   "main": "./build/index.js",
   "types": "./build/index.d.ts",
@@ -25,7 +25,7 @@
     "build": "tsc --build tsconfig.json && cp -r lib/db/schemas build/lib/db/schemas",
     "clean-build": "npm run clean && npm run build",
     "start": "ts-node index.ts",
-    "start:dev": "ts-node-dev --respawn index.ts",
+    "start:dev": "ts-node-dev --respawn --transpile-only index.ts",
     "migrate": "ts-node lib/db/migrate.ts",
     "lint": "eslint . --ext .ts",
     "lint:fix": "eslint . --fix --ext .ts",
@@ -72,7 +72,7 @@
     "@anthropic-ai/sdk": "^0.92.0",
     "@aws-sdk/client-s3": "^3.1017.0",
     "@aws-sdk/s3-request-presigner": "^3.1045.0",
-    "@hotmeshio/hotmesh": "^0.25.6",
+    "@hotmeshio/hotmesh": "^0.26.1",
     "@modelcontextprotocol/sdk": "^1.27.1",
     "@opentelemetry/exporter-trace-otlp-proto": "^0.215.0",
     "@opentelemetry/resources": "^2.5.1",

package/dashboard/dist/assets/AvailableEscalationsPage-DDwAgklw.js

@@ -1,2 +0,0 @@
-import{j as e,a as p}from"./vendor-query-B2UbickB.js";import{c as Ie,f as $e,a as De}from"./vendor-react-CXumBFUA.js";import{u as Ue,j as He,k as Je,g as qe,l as Ge,m as Qe,n as Ve,o as Ye,p as Ke,q as Xe,r as We,s as Ze,t as et,v as tt}from"./index-DwWP-Z_c.js";import{f as st}from"./useEventHooks-Dn_vN2xE.js";import{u as te,C as fe,a as at}from"./CustomDurationPicker-OKlwH5a_.js";import{u as nt}from"./roles-D4Wn7kE9.js";import{u as lt}from"./useFilterParams-x-Dg0Vgz.js";import{u as pe}from"./useDebouncedValue-BA5S7V54.js";import{b as it}from"./api-path-u2Jf9QXS.js";import{D as rt}from"./DataTable-ZWgVQg7F.js";import{S as ot}from"./StickyPagination-CqT9Q1I6.js";import{P as ct}from"./PageHeader-DJo7yMUR.js";import{P as dt}from"./constants-BHkpVaqx.js";import{M as se}from"./Modal-CSrxpXeM.js";import{u as ut}from"./users-DngGIiC_.js";import{E as xt,a as mt}from"./escalation-columns-Dyrf6Tdp.js";import{R as ht,a as gt}from"./RowActions-BA9L9djf.js";import{L as ft}from"./ListToolbar-Dz2_neVF.js";import{a4 as pt,S as bt,X as yt}from"./vendor-icons-DOIDKgo6.js";import"./EmptyState-BcsfPq9T.js";import"./FilterBar-B4Mk2PvT.js";import"./PriorityBadge-B4ykBH7f.js";import"./RolePill-DHWixsQR.js";import"./WorkflowPill-BtNBSplz.js";import"./escalation-CK8ElYzD.js";const F=t=>{if(t)try{return JSON.parse(t)}catch{return}},A=t=>t==null||Array.isArray(t)&&t.length===0||typeof t=="object"&&!Array.isArray(t)&&Object.keys(t).length===0;function vt(t){const s={},o=F(t.get("facets"));A(o)||(s.facets=o);const c=F(t.get("block"));A(c)||(s.block=c);const x=F(t.get("range"));A(x)||(s.range=x);const f=F(t.get("exists"));A(f)||(s.exists=f);const h=F(t.get("roles"));A(h)||(s.roles=h);const l=F(t.get("orderBy"));return A(l)||(s.orderBy=l),t.get("available")!=null&&(s.available=t.get("available")==="true"),s}function jt(t,s){const o=(c,x)=>A(x)?t.delete(c):t.set(c,JSON.stringify(x));o("facets",s.facets),o("block",s.block),o("range",s.range),o("exists",s.exists),o("roles",s.roles),o("orderBy",s.orderBy),s.available==null?t.delete("available"):t.set("available",String(s.available))}function Ct(t){var s,o,c,x;return Object.keys(t.facets??{}).length+(((s=t.block)==null?void 0:s.length)??0)+(((o=t.range)==null?void 0:o.length)??0)+(((c=t.exists)==null?void 0:c.length)??0)+(((x=t.orderBy)==null?void 0:x.length)??0)+(t.available!=null?1:0)}const kt=["<","<=",">",">=","="],Nt=["priority","created_at","updated_at","status","role"],P="h-7 rounded border border-surface-border bg-surface px-2 text-xs text-text-primary focus:border-accent focus:outline-none",H="text-text-tertiary hover:text-text-primary transition-colors";function ge(t){return t==="true"?!0:t==="false"?!1:t.trim()!==""&&!Number.isNaN(Number(t))?Number(t):t}const St=t=>Object.entries(t??{}).map(([s,o])=>({key:s,value:String(o)})),Pt=t=>(t??[]).map(s=>{const[o,c]=Object.entries(s)[0]??["",""];return{key:o,value:String(c)}});function T({title:t,hint:s,children:o}){return e.jsxs("div",{className:"border-t border-surface-border/50 py-3 first:border-t-0 first:pt-1",children:[e.jsxs("div",{className:"mb-1.5 flex items-baseline justify-between",children:[e.jsx("span",{className:"text-[11px] font-medium uppercase tracking-wide text-text-tertiary",children:t}),s&&e.jsx("span",{className:"text-[10px] font-mono text-text-tertiary/70",children:s})]}),o]})}function J({value:t,onChange:s,placeholder:o}){return e.jsx("input",{list:"lt-facet-keys",className:`${P} w-40`,placeholder:o,value:t,onChange:c=>s(c.target.value)})}function wt({value:t,onChange:s,facetKeys:o=[],search:c="",onSearchChange:x}){const f=St(t.facets),h=Pt(t.block),l=t.range??[],u=t.exists??[],b=t.orderBy??[],v=a=>{const i={};for(const n of a)n.key&&(i[n.key]=ge(n.value));s({...t,facets:Object.keys(i).length?i:void 0})},N=a=>{const i=a.filter(n=>n.key).map(n=>({[n.key]:ge(n.value)}));s({...t,block:i.length?i:void 0})},k=a=>s({...t,range:a.length?a:void 0}),S=a=>s({...t,exists:a.length?a:void 0}),C=a=>s({...t,orderBy:a.length?a:void 0});return e.jsxs("div",{className:"text-xs",children:[e.jsx("datalist",{id:"lt-facet-keys",children:o.map(a=>e.jsx("option",{value:a},a))}),e.jsxs("datalist",{id:"lt-sort-fields",children:[Nt.map(a=>e.jsx("option",{value:a},a)),o.map(a=>e.jsx("option",{value:`metadata.${a}`},a))]}),x&&e.jsx(T,{title:"Match id",hint:"id · workflow · origin",children:e.jsx("input",{className:`${P} w-full`,placeholder:"Exact escalation, workflow, or origin id…",value:c,onChange:a=>x(a.target.value)})}),e.jsx(T,{title:"Has facet",hint:"metadata @>",children:[...f,{key:"",value:""}].map((a,i)=>e.jsxs("div",{className:"mb-1 flex items-center gap-1",children:[e.jsx(J,{value:a.key,placeholder:"key",onChange:n=>{const r=[...f];r[i]={...a,key:n},v(r)}}),e.jsx("span",{className:"text-text-tertiary",children:"="}),e.jsx("input",{className:`${P} w-40`,placeholder:"value",value:a.value,onChange:n=>{const r=[...f];r[i]={...a,value:n.target.value},v(r)}}),i<f.length&&e.jsx("button",{className:H,onClick:()=>v(f.filter((n,r)=>r!==i)),children:"×"})]},i))}),e.jsx(T,{title:"Range",hint:"numeric",children:[...l,{facet:"",op:"<=",value:0}].map((a,i)=>e.jsxs("div",{className:"mb-1 flex items-center gap-1",children:[e.jsx(J,{value:a.facet,placeholder:"numeric facet",onChange:n=>{const r=[...l];r[i]={...a,facet:n},k(r.filter(y=>y.facet))}}),e.jsx("select",{className:P,value:a.op,onChange:n=>{const r=[...l];r[i]={...a,op:n.target.value},k(r.filter(y=>y.facet))},children:kt.map(n=>e.jsx("option",{value:n,children:n},n))}),e.jsx("input",{type:"number",className:`${P} w-24`,value:a.value,onChange:n=>{const r=[...l];r[i]={...a,value:Number(n.target.value)},k(r.filter(y=>y.facet))}}),i<l.length&&e.jsx("button",{className:H,onClick:()=>k(l.filter((n,r)=>r!==i)),children:"×"})]},i))}),e.jsx(T,{title:"Has key",hint:"metadata ? key",children:e.jsxs("div",{className:"flex flex-wrap items-center gap-1",children:[u.map(a=>e.jsxs("span",{className:"flex items-center gap-1 rounded bg-accent/15 px-1.5 py-0.5 text-accent",children:[a,e.jsx("button",{className:"text-accent/70 hover:text-accent",onClick:()=>S(u.filter(i=>i!==a)),children:"×"})]},a)),e.jsx(J,{value:"",placeholder:"+ key",onChange:a=>{a&&!u.includes(a)&&S([...u,a])}})]})}),e.jsx(T,{title:"Exclude",hint:"NOT @>",children:[...h,{key:"",value:""}].map((a,i)=>e.jsxs("div",{className:"mb-1 flex items-center gap-1",children:[e.jsx(J,{value:a.key,placeholder:"key",onChange:n=>{const r=[...h];r[i]={...a,key:n},N(r)}}),e.jsx("span",{className:"text-text-tertiary",children:"="}),e.jsx("input",{className:`${P} w-40`,placeholder:"value",value:a.value,onChange:n=>{const r=[...h];r[i]={...a,value:n.target.value},N(r)}}),i<h.length&&e.jsx("button",{className:H,onClick:()=>N(h.filter((n,r)=>r!==i)),children:"×"})]},i))}),e.jsx(T,{title:"Sort by",children:[...b,{field:"",direction:"asc"}].map((a,i)=>e.jsxs("div",{className:"mb-1 flex items-center gap-1",children:[e.jsx("input",{list:"lt-sort-fields",className:`${P} w-44`,placeholder:"column or metadata.key",value:a.field,onChange:n=>{const r=[...b];r[i]={...a,field:n.target.value},C(r.filter(y=>y.field))}}),e.jsxs("select",{className:P,value:a.direction??"asc",onChange:n=>{const r=[...b];r[i]={...a,direction:n.target.value},C(r.filter(y=>y.field))},children:[e.jsx("option",{value:"asc",children:"asc"}),e.jsx("option",{value:"desc",children:"desc"})]}),e.jsxs("label",{className:"flex items-center gap-1 text-text-tertiary",children:[e.jsx("input",{type:"checkbox",checked:!!a.numeric,onChange:n=>{const r=[...b];r[i]={...a,numeric:n.target.checked},C(r.filter(y=>y.field))}}),"num"]}),i<b.length&&e.jsx("button",{className:H,onClick:()=>C(b.filter((n,r)=>r!==i)),children:"×"})]},i))})]})}const At=t=>t.isPriorityPending||t.isClaimPending||t.isAssignPending||t.isEscalatePending||t.isTriagePending||t.isCancelPending,ee="inline-flex items-center h-7 px-2.5 text-[11px] font-medium text-text-secondary bg-surface border border-surface-border rounded-[4px] hover:border-accent/50 hover:text-text-primary transition-colors disabled:opacity-50 disabled:hover:border-surface-border",Z=`${ee} appearance-none cursor-pointer`,Bt="inline-flex items-center h-7 px-2.5 text-[11px] font-medium text-status-error bg-surface border border-status-error/30 rounded-[4px] hover:border-status-error hover:bg-status-error/5 transition-colors disabled:opacity-50";function Et(t){var h;const s=At(t),o=te(),{data:c}=Ue(),x=((h=c==null?void 0:c.ai)==null?void 0:h.enabled)===!0,f=t.selectedCount>0;return e.jsx("div",{className:`grid transition-all duration-200 ease-in-out ${f?"grid-rows-[1fr] opacity-100":"grid-rows-[0fr] opacity-0 pointer-events-none"}`,children:e.jsx("div",{className:"overflow-hidden",children:e.jsxs("div",{className:"flex flex-wrap items-center gap-2 py-2.5 pl-3 pr-2 mt-4 mb-3 bg-surface-sunken/60 border-l-2 border-l-accent",children:[e.jsxs("span",{className:"text-[11px] font-semibold uppercase tracking-wider text-accent tabular-nums",children:[t.selectedCount," selected"]}),e.jsx("div",{className:"mx-1 h-4 w-px bg-surface-border"}),e.jsxs("select",{onChange:l=>{l.target.value&&(t.onSetPriority(parseInt(l.target.value)),l.target.value="")},disabled:s,className:Z,defaultValue:"",children:[e.jsx("option",{value:"",disabled:!0,children:"Priority…"}),dt.map(l=>e.jsx("option",{value:l.value,children:l.label},l.value))]}),e.jsxs("select",{onChange:l=>{l.target.value&&(t.onClaim(parseInt(l.target.value)),l.target.value="")},disabled:s,className:Z,defaultValue:"",children:[e.jsx("option",{value:"",disabled:!0,children:"Claim for…"}),o.map(l=>e.jsx("option",{value:l.value,children:l.label},l.value))]}),e.jsx("button",{onClick:t.onAssign,disabled:s,className:ee,children:t.isAssignPending?"Assigning…":"Assign to…"}),t.availableRoles.length>0&&e.jsxs("select",{onChange:l=>{l.target.value&&(t.onEscalate(l.target.value),l.target.value="")},disabled:s,className:Z,defaultValue:"",children:[e.jsx("option",{value:"",disabled:!0,children:"Escalate to…"}),t.availableRoles.map(l=>e.jsx("option",{value:l,children:l},l))]}),x&&e.jsx("button",{onClick:t.onTriage,disabled:s,className:ee,children:t.isTriagePending?"Triaging…":"Triage"}),e.jsx("button",{onClick:t.onCancel,disabled:s,className:Bt,children:t.isCancelPending?"Cancelling…":"Cancel"}),e.jsx("div",{className:"flex-1"}),s&&e.jsx("span",{className:"text-[11px] text-text-tertiary animate-pulse",children:"Processing…"}),e.jsx("button",{onClick:t.onClearSelection,className:"px-1 text-[11px] font-medium text-text-tertiary hover:text-text-primary transition-colors",children:"Clear"})]})})})}function Ot({open:t,onClose:s,selectedCount:o,selectedRoles:c,onSubmit:x,isPending:f}){const{isSuperAdmin:h}=He(),l=te(),[u,b]=p.useState("user"),[v,N]=p.useState(null),[k,S]=p.useState(""),[C,a]=p.useState("30"),[i,n]=p.useState(0),r=p.useCallback(m=>n(m),[]),y=!h&&c.length===1?c[0]:void 0,$=pe(k,250),{data:g,isLoading:_}=ut({role:y,status:"active",search:$.trim()||void 0,limit:200}),B=(g==null?void 0:g.users)??[],E=()=>{b("user"),N(null),S(""),a("30"),n(0),s()},q=m=>{N(m),b("duration")},z=()=>{b("user")},G=()=>{if(!v)return;const m=C==="custom"?i:parseInt(C);!m||m<=0||x(v.id,m)};return e.jsx(se,{open:t,onClose:E,title:"Assign Escalations",children:e.jsxs("div",{className:"space-y-4",children:[u==="user"&&e.jsxs(e.Fragment,{children:[e.jsxs("p",{className:"text-sm text-text-secondary",children:["Select a user to assign"," ",e.jsx("span",{className:"font-medium text-text-primary",children:o})," ","escalation(s) to:"]}),e.jsx("input",{type:"text",value:k,onChange:m=>S(m.target.value),placeholder:"Search by name or email...",className:"input text-xs w-full",autoFocus:!0}),e.jsxs("div",{className:"max-h-60 overflow-y-auto border border-surface-border rounded-lg divide-y divide-surface-border",children:[_&&e.jsx("p",{className:"text-xs text-text-tertiary p-3",children:"Loading users..."}),!_&&B.length===0&&e.jsx("p",{className:"text-xs text-text-tertiary p-3",children:"No users found"}),B.map(m=>e.jsxs("button",{onClick:()=>q(m),className:"w-full text-left px-3 py-2 hover:bg-surface-hover transition-colors",children:[e.jsx("p",{className:"text-xs font-medium text-text-primary",children:m.display_name||m.external_id}),m.email&&e.jsx("p",{className:"text-[10px] text-text-tertiary",children:m.email})]},m.id))]}),e.jsx("div",{className:"flex justify-end pt-2",children:e.jsx("button",{onClick:E,className:"btn-secondary text-xs",children:"Cancel"})})]}),u==="duration"&&v&&e.jsxs(e.Fragment,{children:[e.jsxs("p",{className:"text-sm text-text-secondary",children:["Assign to"," ",e.jsx("span",{className:"font-medium text-text-primary",children:v.display_name||v.external_id})," ","for:"]}),e.jsxs("select",{value:C,onChange:m=>{a(m.target.value),n(0)},className:"select w-full text-sm",children:[l.map(m=>e.jsx("option",{value:m.value,children:m.label},m.value)),e.jsx("option",{value:"custom",children:"Other..."})]}),C==="custom"&&e.jsx(fe,{onChange:r,autoFocus:!0}),e.jsxs("div",{className:"flex justify-end gap-3 pt-2",children:[e.jsx("button",{onClick:z,className:"btn-secondary text-xs",children:"Back"}),e.jsx("button",{onClick:G,disabled:f,className:"btn-primary text-xs",children:f?"Assigning...":"Assign"})]})]})]})})}function Mt({open:t,onClose:s,selectedCount:o,onSubmit:c,isPending:x}){const[f,h]=p.useState(""),l=()=>{c(f||void 0)};return e.jsx(se,{open:t,onClose:s,title:"Submit for AI Triage",children:e.jsxs("div",{className:"space-y-4",children:[e.jsxs("p",{className:"text-sm text-text-secondary",children:["Submit ",e.jsx("span",{className:"font-medium text-text-primary",children:o})," escalation(s) for AI triage? The triage orchestrator will take over resolution."]}),e.jsxs("div",{children:[e.jsxs("label",{className:"text-xs font-medium text-text-secondary block mb-1",children:["Triage hint ",e.jsx("span",{className:"text-text-tertiary",children:"(optional)"})]}),e.jsx("input",{type:"text",value:f,onChange:u=>h(u.target.value),placeholder:"e.g., image_orientation",className:"input text-xs font-mono w-full"}),e.jsx("p",{className:"text-[10px] text-text-tertiary mt-1",children:"Guides the triage workflow on what remediation to apply"})]}),e.jsxs("div",{className:"flex justify-end gap-3 pt-2",children:[e.jsx("button",{onClick:s,className:"btn-secondary text-xs",children:"Cancel"}),e.jsx("button",{onClick:l,disabled:x,className:"btn-primary text-xs",children:x?"Submitting...":"Submit for Triage"})]})]})})}function R(t,s,o){return c=>{t.mutate(c,{onSuccess:()=>{s(),o==null||o()}})}}function Ft(t){const s=()=>[...t.selectedIds];return{handleSetPriority:u=>{R(t.setPriority,t.clearSelection)({ids:s(),priority:u})},handleBulkClaim:u=>{R(t.bulkClaim,t.clearSelection)({ids:s(),durationMinutes:u})},handleBulkEscalate:u=>{R(t.bulkEscalate,t.clearSelection)({ids:s(),targetRole:u})},handleBulkTriage:u=>{R(t.bulkTriage,t.clearSelection,t.closeTriageModal)({ids:s(),hint:u})},handleBulkAssign:(u,b)=>{R(t.bulkAssign,t.clearSelection,t.closeAssignModal)({ids:s(),targetUserId:u,durationMinutes:b})},handleBulkCancel:()=>{R(t.bulkCancel,t.clearSelection,t.closeCancelModal)({ids:s()})}}}function Tt({claimTarget:t,onClose:s,claimDuration:o,onDurationChange:c,claimDurations:x,onCustomClaimChange:f,onClaim:h,isPending:l}){return e.jsx(se,{open:!!t,onClose:s,title:"Claim Escalation",children:e.jsxs("div",{className:"space-y-4",children:[e.jsxs("p",{className:"text-sm text-text-secondary",children:["Claim ",e.jsx("span",{className:"font-medium text-text-primary",children:t==null?void 0:t.type})," for:"]}),e.jsxs("select",{value:o,onChange:u=>{c(u.target.value)},className:"select w-full text-sm",children:[x.map(u=>e.jsx("option",{value:u.value,children:u.label},u.value)),e.jsx("option",{value:"custom",children:"Other..."})]}),o==="custom"&&e.jsx(fe,{onChange:f,autoFocus:!0}),e.jsxs("div",{className:"flex justify-end gap-3 pt-2",children:[e.jsx("button",{onClick:s,className:"btn-secondary text-xs",children:"Cancel"}),e.jsx("button",{onClick:h,className:"btn-primary text-xs",disabled:l,children:l?"Claiming...":"Claim"})]})]})})}function is(){var de,ue,xe,me,he;st();const t=Ie(),{filters:s,setFilter:o,pagination:c,sort:x,setSort:f}=lt({filters:{role:"",type:"",priority:"",status:"available",search:""}}),h=pe(s.search,300),l=te(),[u,b]=p.useState(null),[v,N]=p.useState("30"),[k,S]=p.useState(0),C=p.useCallback(d=>S(d),[]),[a,i]=p.useState(new Set),[n,r]=p.useState(!1),[y,$]=$e(),g=p.useMemo(()=>vt(y),[y]),_=p.useCallback(d=>{$(j=>{const W=new URLSearchParams(j);return jt(W,d),W.delete("page"),W},{replace:!0})},[$]),{data:B}=Je(n),E=Ct(g)+(s.search?1:0),[q,z]=p.useState(!1),[G,m]=p.useState(!1),[be,Q]=p.useState(!1),ae=qe(),ne=Ge(),le=Qe(),V=Ve(),ie=Ye(),Y=Ke(),D=Xe(),{data:O}=nt(),{data:K}=We();p.useEffect(()=>{i(new Set)},[s.role,s.type,s.priority,s.status,h,c.page,c.pageSize]);const L=s.status||"",I=L==="available",X=L==="claimed",re=X?"pending":L==="resolved"?"resolved":L==="cancelled"?"cancelled":L==="expired"?"expired":void 0,oe={role:s.role||void 0,type:s.type||void 0,priority:s.priority?parseInt(s.priority):void 0,limit:c.pageSize,offset:c.offset,sort_by:x.sort_by||"created_at",order:x.order||"desc",search:h||void 0,...g},ye=Ze({...oe,enabled:I}),ve=et({status:re,claimed:X||void 0,...oe,enabled:!I}),je=I?ye:ve,{data:M,isLoading:Ce,error:U,refetch:ke,isFetching:Ne}=je,Se=it(`/escalations${I?"/available":""}`,{status:re,claimed:X||void 0,role:s.role||void 0,type:s.type||void 0,priority:s.priority||void 0,search:h||void 0,sort_by:x.sort_by||"created_at",order:x.order||"desc",limit:c.pageSize,offset:c.offset,facets:g.facets&&Object.keys(g.facets).length?JSON.stringify(g.facets):void 0,block:(de=g.block)!=null&&de.length?JSON.stringify(g.block):void 0,range:(ue=g.range)!=null&&ue.length?JSON.stringify(g.range):void 0,exists:(xe=g.exists)!=null&&xe.length?JSON.stringify(g.exists):void 0,roles:(me=g.roles)!=null&&me.length?JSON.stringify(g.roles):void 0,orderBy:(he=g.orderBy)!=null&&he.length?JSON.stringify(g.orderBy):void 0,available:g.available!=null?String(g.available):void 0}),w=(M==null?void 0:M.escalations)??[],ce=(M==null?void 0:M.total)??0,{canBulk:Pe}=tt(),we=p.useMemo(()=>{const d=new Set;for(const j of w)a.has(j.id)&&d.add(j.role);return[...d]},[w,a]),Ae=p.useCallback(()=>i(new Set),[]),Be=()=>{if(!u)return;const d=v==="custom"?k:parseInt(v);!d||d<=0||ae.mutate({id:u.id,durationMinutes:d},{onSuccess:()=>{b(null),t(`/escalations/detail/${u.id}`)}})},{handleSetPriority:Ee,handleBulkClaim:Oe,handleBulkEscalate:Me,handleBulkTriage:Fe,handleBulkAssign:Te,handleBulkCancel:Re}=Ft({selectedIds:a,clearSelection:Ae,setPriority:ne,bulkClaim:le,bulkEscalate:ie,bulkTriage:Y,bulkAssign:V,bulkCancel:D,closeTriageModal:()=>z(!1),closeAssignModal:()=>m(!1),closeCancelModal:()=>Q(!1)}),_e=d=>{const j=new Set(a);j.has(d)?j.delete(d):j.add(d),i(j)},ze=()=>{a.size===w.length?i(new Set):i(new Set(w.map(d=>d.id)))},Le=[Pe?{key:"select",label:e.jsx("input",{type:"checkbox",checked:w.length>0&&a.size===w.length,onChange:ze,className:"rounded"}),render:d=>e.jsx("input",{type:"checkbox",checked:a.has(d.id),onChange:j=>{j.stopPropagation(),_e(d.id)},onClick:j=>j.stopPropagation(),className:"rounded"}),className:"w-10"}:{key:"spacer",label:"",render:()=>null,className:"w-10"},...xt,{key:"actions",label:"",render:d=>e.jsx(ht,{children:e.jsx(gt,{icon:pt,title:"Claim escalation",onClick:()=>b(d),colorClass:"text-accent/75 hover:text-accent",size:"sm"})}),className:"w-10 text-right"}];return e.jsxs("div",{children:[e.jsx(ct,{title:"All Escalations",docsHash:"#docs:dashboard.md:all-escalations"}),e.jsx(mt,{filters:s,setFilter:o,roles:(O==null?void 0:O.roles)??[],types:(K==null?void 0:K.types)??[],showStatus:!0,showSearch:!1,actions:e.jsxs(e.Fragment,{children:[e.jsx(ft,{onRefresh:()=>ke(),isFetching:Ne,apiPath:Se}),e.jsxs("button",{onClick:()=>r(d=>!d),className:"relative ml-2 inline-flex h-7 w-7 items-center justify-center rounded text-text-tertiary hover:bg-surface-hover hover:text-text-primary transition-colors",title:"Faceted query",children:[e.jsx(bt,{className:"w-4 h-4"}),E>0&&e.jsx("span",{className:"absolute -right-1 -top-1 flex h-3.5 min-w-[14px] items-center justify-center rounded-full bg-accent px-0.5 text-[9px] font-medium text-white",children:E})]})]})}),De.createPortal(e.jsxs("div",{className:`fixed right-0 bottom-0 w-[420px] z-40 border-l border-surface-border bg-surface overflow-y-auto shadow-lg transition-transform duration-200 ease-out ${n?"translate-x-0":"pointer-events-none translate-x-full"}`,style:{top:"3.5rem"},"aria-hidden":!n,children:[e.jsxs("div",{className:"sticky top-0 z-10 flex items-center justify-between px-4 py-3 bg-surface border-b border-surface-border/50",children:[e.jsx("span",{className:"text-xs font-medium text-text-primary",children:"Faceted query"}),e.jsxs("div",{className:"flex items-center gap-2",children:[E>0&&e.jsx("button",{onClick:()=>{_({}),o("search","")},className:"text-[11px] text-text-tertiary hover:text-text-primary transition-colors",children:"Clear"}),e.jsx("button",{onClick:()=>r(!1),className:"p-1 rounded hover:bg-surface-hover text-text-tertiary hover:text-text-primary transition-colors",title:"Close",children:e.jsx(yt,{className:"w-4 h-4"})})]})]}),e.jsxs("div",{className:"px-4 py-2",children:[e.jsxs("p",{className:"mb-2 text-[11px] leading-snug text-text-tertiary",children:["Precise metadata facets plus exact correlation-id lookup — they compose in one SQL query. Facet keys are the ones that actually exist in your visible escalations. Set status to ",e.jsx("span",{className:"font-medium",children:"All"})," to find an order across every status; the whole query is shareable via the URL."]}),e.jsx(wt,{value:g,onChange:_,facetKeys:(B==null?void 0:B.keys)??[],search:s.search??"",onSearchChange:d=>o("search",d)})]})]}),document.body),e.jsx(Et,{selectedCount:a.size,onClearSelection:()=>i(new Set),onSetPriority:Ee,onClaim:Oe,onAssign:()=>m(!0),onEscalate:Me,onTriage:()=>z(!0),onCancel:()=>Q(!0),isPriorityPending:ne.isPending,isClaimPending:le.isPending,isAssignPending:V.isPending,isEscalatePending:ie.isPending,isTriagePending:Y.isPending,isCancelPending:D.isPending,availableRoles:(O==null?void 0:O.roles)??[]}),U&&e.jsx("div",{className:"mb-4 px-4 py-3 rounded-md bg-status-error/10 border border-status-error/20 text-xs text-status-error",children:U.message==="Session expired"?"Your session has expired. Please log in again.":`Failed to load escalations: ${U.message}`}),e.jsx(rt,{columns:Le,data:w,keyFn:d=>d.id,onRowClick:d=>t(`/escalations/detail/${d.id}`,{state:{from:"/escalations/available"}}),isLoading:Ce,emptyMessage:U?"Unable to load data":"No escalations",sort:x,onSort:f}),e.jsx(ot,{page:c.page,totalPages:c.totalPages(ce),onPageChange:c.setPage,total:ce,pageSize:c.pageSize,onPageSizeChange:c.setPageSize}),e.jsx(Tt,{claimTarget:u,onClose:()=>b(null),claimDuration:v,onDurationChange:d=>{N(d),S(0)},claimDurations:l,customClaimMinutes:k,onCustomClaimChange:C,onClaim:Be,isPending:ae.isPending}),e.jsx(Mt,{open:q,onClose:()=>z(!1),selectedCount:a.size,onSubmit:Fe,isPending:Y.isPending}),e.jsx(Ot,{open:G,onClose:()=>m(!1),selectedCount:a.size,selectedRoles:we,onSubmit:Te,isPending:V.isPending}),e.jsx(at,{open:be,onClose:()=>Q(!1),onConfirm:Re,selectedCount:a.size,isPending:D.isPending,error:D.error})]})}export{is as AvailableEscalationsPage};
-//# sourceMappingURL=AvailableEscalationsPage-DDwAgklw.js.map