@hotmeshio/long-tail 0.9.6 → 0.10.0

package/README.md

@@ -1,6 +1,12 @@
 # Long Tail
 
-Durable workflow for humans in the loop.
+**The queue durable systems forgot.**
+
+Durable platforms are built around determinism — that is their strength and their blind spot. They give you rich, first-class queues for deterministic work (retry, timeout, `backoffCoefficient`, exactly-once) and an `await condition()` to park a workflow until a signal arrives. All of it assumes the thing you are waiting on will, eventually, behave.
+
+Most of the work that decides an outcome behaves on its own schedule: an approval, a person, a shipment, a machine that needs service. You cannot set a `backoffCoefficient` on a person — retrying someone who has not answered just asks twice. This is why "human-in-the-loop" keeps getting bolted on as a feature: the platform perfected the deterministic queue and left the non-deterministic one for you to improvise.
+
+Long Tail makes it a primitive. The same `condition()` wait — except the act of waiting mints a row that is searchable, claimable, deadlined, and role-gated on a shared metadata surface. Machines answer some rows, people answer others; the workflow resumes either way, exactly where it paused.
 
 ```bash
 npm install @hotmeshio/long-tail
@@ -8,7 +14,7 @@ npm install @hotmeshio/long-tail
 
 ## How it works
 
-Route work to machines or people interchangeably with ease.
+One workflow, both queues: `proxyActivities` for the deterministic one, `condition()` for the one reality answers.
 
 ```typescript
 import { Durable } from '@hotmeshio/hotmesh';
@@ -54,6 +60,19 @@ export async function analyzeContent(content: string) {
 }
 ```
 
+## What the primitive buys
+
+The non-deterministic queue has qualities the deterministic one never needed:
+
+- **RBAC is intrinsic.** The queue is a role; permission lives in the queue itself. Any member answers — a person in the dashboard, a service account through the API — and the workflow is indifferent to which.
+- **The form is data.** A versioned JSON Schema on the role renders the resolver's UI — fields, validation, conditionals, layout — with zero frontend code. Assign an escalation to one named user with self scope and you have a just-in-time form: one person, one item, one auditable edition.
+- **Claims are locks.** A claim is a TTL window with an extend prompt before it lapses and a resolve guard behind it — the platform rejects a submission against an expired claim atomically, in the same statement that settles the row. Stale work cannot land.
+- **Cancel is home.** Cancellation is a first-class settlement, not an exception. When the pressure no longer applies, the waiting flow sees `null` and reconciles to a modeled resting state. Handled is broader than resolved — timeout, cancel, and hop-onward are all endings the loop was built to reach.
+- **One shared surface.** Every actor that touches an item writes to the same metadata-keyed row. The contact point is shared by construction, so there is one place to search, one place to claim, one place to audit.
+- **History accretes.** The surface only ever adds: intent at creation, outcome at settlement, every crossing in between. The object's whole history sits there to replay — frames the queue kept for you.
+- **Objects get lifecycles.** Give an object this queue and a `while` loop and it lives — a digital twin: it advertises when free, asks when it needs service, waits for reality's answer, reconciles when reality gives one. An order, a document only compliance may edit, a machine on a line — all the same shape, an object looping at a role.
+- **What repeats, stops needing people.** Every settled row is a worked example. Recurring patterns become deterministic tools — problems that once required a person, then required AI reasoning, eventually require neither.
+
 ## Start
 
 Point at Postgres. Everything else is optional.
@@ -69,31 +88,9 @@ const lt = await start({
 
 Dashboard at [http://localhost:3000](http://localhost:3000). The [boilerplate](https://github.com/hotmeshio/long-tail-boilerplate) has a working project with workflows, MCP servers, and MinIO.
 
-## The pattern
-
-Four moves, from a plan you write to a plan that keeps up with reality.
-
-**Step 1 — Author a durable workflow.** Your function checkpoints to Postgres. It can sleep, branch, call child workflows, wait for signals. Standard durable execution.
-
-**Step 2 — Certify it.** Promotion to certified adds interceptor guarantees: failures escalate instead of throwing, escalation chains route through RBAC-scoped roles, and every error is either handled or surfaced. It cannot silently fail.
-
-```bash
-curl -X PUT http://localhost:3000/api/workflows/reviewContent/config \
-  -H "Authorization: Bearer $TOKEN" \
-  -d '{ "invocable": true, "task_queue": "default", "default_role": "reviewer" }'
-```
-
-**Step 3 — React to events.** Signals are reality reporting back. Workflows publish topics; agents subscribe. When `activity.failed` fires, an automation can re-run the step, notify a team, or trigger a different workflow. The choreography is dynamic — add subscribers through the dashboard without changing code.
-
-**Step 4 — Compile what repeats.** The same workflow has two forms. What you wrote in Step 1 is the *procedural* form — readable, Temporal-like, emulated atop the graph: cheap to maintain, heavier to run. The Designer compiles a working execution into the *graph* form — the same durable workflow as a deterministic DAG: no LLM at runtime, no replay overhead, typed in and out, roughly 3x faster. Every procedural pattern has a graph equivalent and the reverse; you pick readability or speed without giving up durability, escalation, or transactional guarantees. It deploys as a reusable tool that any workflow or API call can invoke.
-
-Over time, the system accumulates compiled tools. Problems that once required a human, then required AI reasoning, eventually require neither.
-
-These four steps map to how the dashboard is organized. **React** is the reactive side (Step 3) — topics, subscriptions, automations. **Orchestrate** is the orchestrated side (Steps 1 and 4) — procedural and graph flows side by side, both durable and pull-based under the hood. **Design** is the optional bridge: with an `ANTHROPIC_API_KEY` it turns a description or a tool run into a graph flow; without one, choreography and orchestration stand on their own, no tradeoff.
-
 ## Register MCP tools
 
-Long Tail connects to any MCP server. Registered tools become durable activities and are available to the Pipeline Designer.
+Long Tail connects to any MCP server. Registered tools become durable activities.
 
 **Existing package — no code:**
 
@@ -147,72 +144,6 @@ const lt = await start({
 
 All three paths produce the same outcome: tools callable as durable activities. See the [MCP guide](https://github.com/hotmeshio/long-tail/blob/main/docs/mcp.md).
 
-## Compile workflows
-
-The `ltc` compiler scans TypeScript workflow files and compiles them to YAML DAGs — like `tsc` for workflows.
-
-```bash
-export ANTHROPIC_API_KEY=sk-ant-...
-npx ltc compile workflows/
-```
-
-The source is the spec. The compiled YAML is the optimized execution. Both live in the repo. See the [Compiler Guide](https://github.com/hotmeshio/long-tail/blob/main/docs/compiler.md).
-
-## Register a graph flow by hand
-
-`graphWorkflows` is the graph-form peer of `workers`: hand-author the HotMesh YAML and it's created, deployed, and activated at startup. The same human surface is declarative here — a `hook` with an `escalation:` block. When the flow reaches it, the workflow suspends and writes the escalation row; a person resolves it and the flow continues:
-
-```typescript
-const lt = await start({
-  database: { connectionString: process.env.DATABASE_URL },
-  graphWorkflows: [{
-    name: 'order_approval',
-    namespace: 'graph',
-    inputSchema: { type: 'object', properties: { orderId: { type: 'string' }, region: { type: 'string' } }, required: ['orderId'] },
-    yaml: `
-app:
-  id: graph
-  version: '1'
-  graphs:
-    - subscribes: order_approval
-      publishes: order_approval.done
-      input:  { schema: { type: object, properties: { orderId: { type: string }, region: { type: string } } } }
-      output: { schema: { type: object, properties: { approved: { type: boolean } } } }
-      activities:
-        trigger:
-          type: trigger
-        review:
-          type: hook
-          escalation:
-            role: approver
-            type: order-approval
-            priority: 2
-            description: Approve order for dispatch
-            metadata:
-              orderId: '{trigger.output.data.orderId}'
-              region: '{trigger.output.data.region}'
-            envelope:
-              instructions: Review and approve or reject
-          job:
-            maps:
-              approved: '{review.hook.data.approved}'
-      transitions:
-        trigger:
-          - to: review
-      hooks:
-        order_approval.approve:
-          - to: review
-            conditions:
-              match:
-                - expected: '{$job.metadata.jid}'
-                  actual: '{$self.hook.data.id}'
-`,
-  }],
-});
-```
-
-It appears under **Orchestrate › Graph** and routes to a person exactly like the procedural `condition()` above — the same claim-and-resolve surface, declared in YAML. The `metadata` expressions resolve against the live job at suspension time, so the row carries the real order values.
-
 ## Full configuration
 
 ```typescript
@@ -221,10 +152,8 @@ const lt = await start({
   workers: [{ taskQueue: 'default', workflow: reviewContent }],
 
   // Everything below is optional
-  graphWorkflows: [{ name: 'hello_world', namespace: 'graph', yaml: helloWorldYaml }],
   seed: { admin: { externalId: 'admin', password: process.env.ADMIN_PASSWORD } },
   mcp: { server: { enabled: true }, serverFactories: { 'my-tools': createMyToolsServer } },
-  escalation: { strategy: 'mcp' },
   auth: { secret: process.env.JWT_SECRET },
   telemetry: { honeycomb: { apiKey: process.env.HNY } },
   logging: { pino: { level: 'info' } },

package/build/api/escalations/helpers.d.ts

@@ -59,6 +59,33 @@ export declare function assertWriteAccess(userId: string, escalation: {
     status: number;
     error: string;
 } | null>;
+/**
+ * Claim-liveness gate for resolve, aligned with `isEffectivelyClaimed`: a
+ * claim is a work LOCK that exists only while a TTL window (`assigned_until`)
+ * is active. Blocks exactly two states:
+ * - another principal holds a live window (the lock is theirs), and
+ * - the caller's own window has lapsed (stale work — re-claim to resolve).
+ *
+ * Everything else passes: unclaimed rows (system resolvers act on them by
+ * design), durable pre-assignments (`assigned_to` with no window — the
+ * one-time-user JIT-form shape), and rows whose window lapsed under a
+ * different assignee (the lock is gone; the row is back in the pool).
+ *
+ * Applies to every principal, including global access — the claim is a work
+ * lock, not an authorization scope, so superadmins are equally bound by it.
+ *
+ * Advisory (read-then-check): the signal-key and notification resolve paths
+ * re-assert the same predicate atomically inside the SDK's guarded resolve
+ * UPDATE (`assertClaim`); this pre-check exists so the signal/triage/re-run
+ * paths reject BEFORE their side effects fire.
+ */
+export declare function assertLiveClaimant(userId: string, escalation: {
+    assigned_to?: string | null;
+    assigned_until?: Date | string | null;
+}): {
+    status: number;
+    error: string;
+} | null;
 /**
  * Require write_scope='all' (or global) for a queue-management verb — release and
  * escalate move an item out of the user's hands, so self-scope owners (who only

package/build/api/escalations/helpers.js

@@ -39,6 +39,7 @@ exports.validateIds = validateIds;
 exports.getEscalationWriteScope = getEscalationWriteScope;
 exports.assertReadAccess = assertReadAccess;
 exports.assertWriteAccess = assertWriteAccess;
+exports.assertLiveClaimant = assertLiveClaimant;
 exports.assertQueueManageAccess = assertQueueManageAccess;
 exports.checkBulkPermission = checkBulkPermission;
 exports.resolveAssignee = resolveAssignee;
@@ -130,6 +131,39 @@ async function assertWriteAccess(userId, escalation) {
     }
     return { status: 403, error: `You do not have write access to the "${escalation.role}" role` };
 }
+/**
+ * Claim-liveness gate for resolve, aligned with `isEffectivelyClaimed`: a
+ * claim is a work LOCK that exists only while a TTL window (`assigned_until`)
+ * is active. Blocks exactly two states:
+ * - another principal holds a live window (the lock is theirs), and
+ * - the caller's own window has lapsed (stale work — re-claim to resolve).
+ *
+ * Everything else passes: unclaimed rows (system resolvers act on them by
+ * design), durable pre-assignments (`assigned_to` with no window — the
+ * one-time-user JIT-form shape), and rows whose window lapsed under a
+ * different assignee (the lock is gone; the row is back in the pool).
+ *
+ * Applies to every principal, including global access — the claim is a work
+ * lock, not an authorization scope, so superadmins are equally bound by it.
+ *
+ * Advisory (read-then-check): the signal-key and notification resolve paths
+ * re-assert the same predicate atomically inside the SDK's guarded resolve
+ * UPDATE (`assertClaim`); this pre-check exists so the signal/triage/re-run
+ * paths reject BEFORE their side effects fire.
+ */
+function assertLiveClaimant(userId, escalation) {
+    if (!escalation.assigned_to || !escalation.assigned_until)
+        return null;
+    const live = new Date(escalation.assigned_until).getTime() > Date.now();
+    const mine = escalation.assigned_to === userId;
+    if (live && !mine) {
+        return { status: 409, error: 'Escalation is claimed by another user' };
+    }
+    if (!live && mine) {
+        return { status: 409, error: 'Your claim has expired — re-claim this escalation to resolve it' };
+    }
+    return null;
+}
 /**
  * Require write_scope='all' (or global) for a queue-management verb — release and
  * escalate move an item out of the user's hands, so self-scope owners (who only

package/build/api/escalations/list.d.ts

@@ -8,6 +8,8 @@ export interface FacetInput {
     range?: FacetRange[];
     exists?: string[];
     available?: boolean;
+    /** Only rows past their role's priority threshold — see FacetQuery.jeopardy. */
+    jeopardy?: boolean;
     orderBy?: FacetOrder[];
 }
 /**

package/build/api/escalations/list.js

@@ -49,7 +49,8 @@ function hasFacetQuery(i) {
         i.exists?.length ||
         i.orderBy?.length ||
         i.roles?.length ||
-        i.available != null);
+        i.available != null ||
+        i.jeopardy === true);
 }
 /**
  * List escalations with optional filters.
@@ -94,6 +95,7 @@ async function listEscalations(input, auth) {
                     block: input.block,
                     range: input.range,
                     exists: input.exists,
+                    jeopardy: input.jeopardy,
                     orderBy: input.orderBy,
                 },
                 type: input.type,
@@ -168,6 +170,7 @@ async function listAvailableEscalations(input, auth) {
                     block: input.block,
                     range: input.range,
                     exists: input.exists,
+                    jeopardy: input.jeopardy,
                     orderBy: input.orderBy,
                 },
                 type: input.type,
@@ -273,11 +276,18 @@ async function getEscalationStats(input, auth) {
 }
 async function getStationMetrics(input, auth) {
     try {
+        // Station metrics are aggregate queue-SHAPE counts (pending/claimed/resolved
+        // + jeopardy) per role — the depth of a lane, not the disclosure of any one
+        // item. Membership in a role entitles you to see its shape, so this view
+        // spans every role the user belongs to, including read_scope='self' roles
+        // (whose per-item lists stay narrowed elsewhere). Without the selfRoles
+        // union, a self-scoped operator would see an empty board on their own lanes.
         const scope = await (0, helpers_1.getEscalationReadScope)(auth.userId);
-        if (!scope.global && scope.allRoles.length === 0) {
+        const memberRoles = [...scope.allRoles, ...scope.selfRoles];
+        if (!scope.global && memberRoles.length === 0) {
             return { status: 200, data: { stations: [] } };
         }
-        const stations = await escalationService.getStationMetrics(scope.global ? undefined : scope.allRoles, input.period);
+        const stations = await escalationService.getStationMetrics(scope.global ? undefined : memberRoles, input.period);
         return { status: 200, data: { stations } };
     }
     catch (err) {

package/build/api/escalations/resolve.js

@@ -83,6 +83,13 @@ async function resolveEscalation(input, auth) {
         const denied = await (0, helpers_1.assertWriteAccess)(auth.userId, escalation);
         if (denied)
             return denied;
+        // Claim-liveness gate: a claim-tracked row resolves only under a live claim
+        // held by the caller. Advisory here (rejects the signal/triage/re-run paths
+        // before their side effects); the signal-key and notification paths below
+        // re-assert the same predicate atomically inside the guarded resolve UPDATE.
+        const stale = (0, helpers_1.assertLiveClaimant)(auth.userId, escalation);
+        if (stale)
+            return stale;
         // The resolver payload is stored exactly as submitted — its shape is the
         // workflow's contract, formed by the caller (the React app maps the form to
         // the payload via x-lt-bind before submitting). No server-side transform.
@@ -106,7 +113,7 @@ async function resolveEscalation(input, auth) {
         // `condition(signalId, config)`. The SDK's resolve marks it resolved AND
         // delivers the signal to `signal_key`, resuming THIS job — no re-run.
         if (escalation.signal_key) {
-            return resolveViaSignalKey(escalation, resolverPayload, metadata);
+            return resolveViaSignalKey(escalation, resolverPayload, metadata, auth.userId);
         }
         // Path C: escalation strategy may redirect to triage
         const envelope = await reconstructEnvelope(escalation);
@@ -119,7 +126,10 @@ async function resolveEscalation(input, auth) {
         }
         // Path D: notification-only — no workflow to restart. One atomic resolve.
         if (!escalation.workflow_type || !escalation.task_queue) {
-            await escalationService.resolveEscalation(escalation.id, resolverPayload, metadata);
+            const resolved = await escalationService.resolveEscalation(escalation.id, resolverPayload, metadata, auth.userId);
+            if (!resolved) {
+                return { status: 409, error: 'Escalation not available for resolution' };
+            }
             return { status: 200, data: { acknowledged: true, escalationId: escalation.id } };
         }
         // Path E: standard re-run
@@ -323,11 +333,13 @@ async function resolveViaConditionSignal(escalation, resolverPayload, metadata)
  * transaction, so the original job resumes in place (no re-run, no separate
  * resolve activity). Password fields are redacted before they enter the signal.
  */
-async function resolveViaSignalKey(escalation, resolverPayload, metadata) {
+async function resolveViaSignalKey(escalation, resolverPayload, metadata, assertClaim) {
     const signalPayload = await redactPasswords(resolverPayload, escalation.metadata?.form_schema);
     // One atomic call: status→resolved, signal delivered, and the outcome patch merged
     // into the GIN-indexed metadata — all inside the single WHERE-guarded UPDATE.
-    const resolved = await escalationService.resolveEscalation(escalation.id, signalPayload, metadata);
+    // `assertClaim` (interactive path only) makes the claim-liveness gate part of
+    // that same UPDATE; the webhook path (resolveBySignalKey) stays claim-agnostic.
+    const resolved = await escalationService.resolveEscalation(escalation.id, signalPayload, metadata, assertClaim);
     if (!resolved) {
         return { status: 409, error: 'Escalation not available for resolution' };
     }

package/build/routes/escalations/list.js

@@ -107,6 +107,7 @@ function registerListRoutes(router) {
             exists: jsonParam(req.query.exists),
             orderBy: jsonParam(req.query.orderBy),
             available: req.query.available != null ? req.query.available === 'true' : undefined,
+            jeopardy: req.query.jeopardy === '1' || req.query.jeopardy === 'true' || undefined,
         }, req.auth);
         res.status(result.status).json(result.data ?? { error: result.error });
     });
@@ -133,6 +134,7 @@ function registerListRoutes(router) {
             range: jsonParam(req.query.range),
             exists: jsonParam(req.query.exists),
             orderBy: jsonParam(req.query.orderBy),
+            jeopardy: req.query.jeopardy === '1' || req.query.jeopardy === 'true' || undefined,
         }, req.auth);
         res.status(result.status).json(result.data ?? { error: result.error });
     });

package/build/services/escalation/crud.d.ts

@@ -20,7 +20,7 @@ export declare function claimEscalation(id: string, userId: string, durationMinu
  * ("what was intended"). Distinct from `resolverPayload`, which is delivered to
  * the waiting workflow as `condition()`'s return value and is not GIN-indexed.
  */
-export declare function resolveEscalation(id: string, resolverPayload: Record<string, any>, metadata?: Record<string, any>): Promise<LTEscalationRecord | null>;
+export declare function resolveEscalation(id: string, resolverPayload: Record<string, any>, metadata?: Record<string, any>, assertClaim?: string): Promise<LTEscalationRecord | null>;
 /**
  * Resolve a SET of escalations by id in ONE guarded statement
  * (`UPDATE … WHERE id = ANY($ids) AND status='pending'`). Returns the rows that

package/build/services/escalation/crud.js

@@ -115,9 +115,13 @@ async function claimEscalation(id, userId, durationMinutes = 30) {
  * ("what was intended"). Distinct from `resolverPayload`, which is delivered to
  * the waiting workflow as `condition()`'s return value and is not GIN-indexed.
  */
-async function resolveEscalation(id, resolverPayload, metadata) {
+async function resolveEscalation(id, resolverPayload, metadata, assertClaim) {
     const client = await (0, client_1.escalations)();
-    const result = await client.resolve({ id, resolverPayload, metadata });
+    // `assertClaim` rides the SDK's guarded UPDATE: no active claim lock may
+    // stand against this assignee, or the resolve blocks (claim-expired /
+    // claimed-by-other). The API layer's advisory pre-check (assertLiveClaimant)
+    // rejects early; this assertion is the atomic arbiter.
+    const result = await client.resolve({ id, resolverPayload, metadata, assertClaim });
     if (!result.ok)
         return null;
     const escalation = (0, map_1.toEscalationRecord)(result.entry);

package/build/services/escalation/facet-sql.d.ts

@@ -4,8 +4,15 @@ export declare const FACET_KEY: RegExp;
  * Build the WHERE clause for a faceted query, pushing bound params into `params`.
  * Every value is parameterized; only validated column names / metadata keys and
  * a fixed operator set are interpolated. Returns `TRUE` when empty.
+ *
+ * `opts.tableRef` names the outer table for correlated clauses (the jeopardy
+ * predicate joins lt_roles, whose own `role` column would otherwise shadow the
+ * outer row's). Callers querying `public.hmsh_escalations` pass its name; the
+ * default matches the `public.lt_escalations` view the list paths read.
  */
-export declare function buildFacetWhere(q: FacetQuery, params: unknown[]): string;
+export declare function buildFacetWhere(q: FacetQuery, params: unknown[], opts?: {
+    tableRef?: string;
+}): string;
 /** Build an injection-safe ORDER BY mixing top-level columns and metadata facets. */
 export declare function buildFacetOrder(orderBy?: FacetOrder[]): string;
 /**

package/build/services/escalation/facet-sql.js

@@ -26,8 +26,14 @@ function metaExpr(key, numeric = false) {
  * Build the WHERE clause for a faceted query, pushing bound params into `params`.
  * Every value is parameterized; only validated column names / metadata keys and
  * a fixed operator set are interpolated. Returns `TRUE` when empty.
+ *
+ * `opts.tableRef` names the outer table for correlated clauses (the jeopardy
+ * predicate joins lt_roles, whose own `role` column would otherwise shadow the
+ * outer row's). Callers querying `public.hmsh_escalations` pass its name; the
+ * default matches the `public.lt_escalations` view the list paths read.
  */
-function buildFacetWhere(q, params) {
+function buildFacetWhere(q, params, opts = {}) {
+    const ref = opts.tableRef ?? 'lt_escalations';
     const clauses = [];
     if (q.role) {
         params.push(q.role);
@@ -66,6 +72,28 @@ function buildFacetWhere(q, params) {
     else if (q.available === false) {
         clauses.push(`(assigned_to IS NOT NULL AND assigned_until > NOW())`);
     }
+    // Jeopardy: the row is past its role's priority threshold — the SAME
+    // expression the Pace Board's priority_count uses (services/escalation/
+    // sql.ts live_counts), so a jeopardy list's total always equals the pill.
+    // Age origin: the role's priority_facet metadata timestamp (created_at when
+    // unset), guarded by pg_input_is_valid so malformed values never throw.
+    // Threshold: priority_threshold_minutes, falling back to sla_minutes. A role
+    // with neither configured (or a missing lt_roles row) yields NULL → false →
+    // contributes no rows, matching a pill that never rendered. Purely the age
+    // predicate — compose `available: true` for the unclaimed pool the pill
+    // counts. The per-row scalar subquery is a PK lookup on the small, cached
+    // lt_roles table (same cost shape as the count query); if a fixed-facet
+    // deployment ever needs more, an expression index on the cast is the
+    // escape hatch.
+    if (q.jeopardy === true) {
+        clauses.push(`(SELECT CASE
+          WHEN rt.priority_facet IS NULL THEN ${ref}.created_at
+          WHEN pg_input_is_valid(${ref}.metadata->>rt.priority_facet, 'timestamptz')
+            THEN (${ref}.metadata->>rt.priority_facet)::timestamptz
+          ELSE NULL
+        END < NOW() - (COALESCE(rt.priority_threshold_minutes, rt.sla_minutes) * INTERVAL '1 minute')
+        FROM lt_roles rt WHERE rt.role = ${ref}.role)`);
+    }
     return clauses.length ? clauses.join('\n  AND ') : 'TRUE';
 }
 const DEFAULT_ORDER = 'priority ASC, created_at ASC';

package/build/types/facets.d.ts

@@ -33,6 +33,15 @@ export interface FacetQuery {
     status?: string;
     /** true = only available (unclaimed/expired); false = only held now. */
     available?: boolean;
+    /**
+     * true = only rows past their role's priority threshold — the same predicate
+     * that produces the Pace Board's priority_count, so a jeopardy list's total
+     * always equals the pill's count. Age is measured from the role's
+     * priority_facet metadata timestamp (created_at when unset) against
+     * priority_threshold_minutes (sla_minutes when unset); roles with no
+     * threshold configured contribute no rows.
+     */
+    jeopardy?: boolean;
     orderBy?: FacetOrder[];
     limit?: number;
     offset?: number;

package/dashboard/dist/assets/{AdminDashboard-DXFIKXO3.js → AdminDashboard-DQS74RL0.js}

@@ -1,2 +1,2 @@
-import{j as o}from"./vendor-query-B2UbickB.js";import{c as n}from"./tasks-DEaDdyBh.js";import{j as m}from"./index-DcQiD6OF.js";import{f as c}from"./useEventHooks-oXjfKrbI.js";import{u}from"./mcp-BEsMr678.js";import{P as d}from"./PageHeaderWithStats-_zOnWAhq.js";import"./vendor-react-CXumBFUA.js";import"./vendor-icons-DPmIjhZB.js";function S(){var a;c();const{data:s}=n({limit:1}),{data:e}=m({status:"pending",limit:1}),{data:t}=u(),r=((a=t==null?void 0:t.servers)==null?void 0:a.filter(i=>i.status==="connected").length)??0,l=t?`${r}/${t.total}`:"—";return o.jsx("div",{children:o.jsx(d,{title:"Admin",stats:[{label:"Tasks",value:(s==null?void 0:s.total)??"—"},{label:"Pending Escalations",value:(e==null?void 0:e.total)??"—",dotClass:"bg-status-pending"},{label:"MCP Servers",value:l},{label:"System",value:"Healthy",dotClass:"bg-status-success"}]})})}export{S as AdminDashboard};
-//# sourceMappingURL=AdminDashboard-DXFIKXO3.js.map
+import{j as o}from"./vendor-query-B2UbickB.js";import{c as n}from"./tasks-qwh8q5q7.js";import{k as m}from"./index-YPLTjeli.js";import{f as c}from"./useEventHooks-B8uNFB-l.js";import{u}from"./mcp-C1-iXkg7.js";import{P as d}from"./PageHeaderWithStats-TUyglVW0.js";import"./vendor-react-CXumBFUA.js";import"./vendor-icons-Qk9qLjF_.js";function j(){var a;c();const{data:s}=n({limit:1}),{data:e}=m({status:"pending",limit:1}),{data:t}=u(),r=((a=t==null?void 0:t.servers)==null?void 0:a.filter(i=>i.status==="connected").length)??0,l=t?`${r}/${t.total}`:"—";return o.jsx("div",{children:o.jsx(d,{title:"Admin",stats:[{label:"Tasks",value:(s==null?void 0:s.total)??"—"},{label:"Pending Escalations",value:(e==null?void 0:e.total)??"—",dotClass:"bg-status-pending"},{label:"MCP Servers",value:l},{label:"System",value:"Healthy",dotClass:"bg-status-success"}]})})}export{j as AdminDashboard};
+//# sourceMappingURL=AdminDashboard-DQS74RL0.js.map

package/dashboard/dist/assets/{AdminDashboard-DXFIKXO3.js.map → AdminDashboard-DQS74RL0.js.map}

@@ -1 +1 @@
-{"version":3,"file":"AdminDashboard-DXFIKXO3.js","sources":["../../src/pages/admin/AdminDashboard.tsx"],"sourcesContent":["import { useTasks } from '../../api/tasks';\nimport { useEscalations } from '../../api/escalations';\nimport { useEscalationListEvents } from '../../hooks/useEventHooks';\nimport { useMcpServers } from '../../api/mcp';\nimport { PageHeaderWithStats } from '../../components/common/layout/PageHeaderWithStats';\n\nexport function AdminDashboard() {\n  useEscalationListEvents();\n  const { data: taskData } = useTasks({ limit: 1 });\n  const { data: pendingEsc } = useEscalations({ status: 'pending', limit: 1 });\n  const { data: mcpData } = useMcpServers();\n\n  const connectedServers =\n    mcpData?.servers?.filter((s) => s.status === 'connected').length ?? 0;\n  const mcpLabel = mcpData ? `${connectedServers}/${mcpData.total}` : '—';\n\n  return (\n    <div>\n      <PageHeaderWithStats\n        title=\"Admin\"\n        stats={[\n          { label: 'Tasks', value: taskData?.total ?? '—' },\n          { label: 'Pending Escalations', value: pendingEsc?.total ?? '—', dotClass: 'bg-status-pending' },\n          { label: 'MCP Servers', value: mcpLabel },\n          { label: 'System', value: 'Healthy', dotClass: 'bg-status-success' },\n        ]}\n      />\n    </div>\n  );\n}\n"],"names":["AdminDashboard","useEscalationListEvents","taskData","useTasks","pendingEsc","useEscalations","mcpData","useMcpServers","connectedServers","_a","s","mcpLabel","jsx","PageHeaderWithStats"],"mappings":"4UAMO,SAASA,GAAiB,OAC/BC,EAAA,EACA,KAAM,CAAE,KAAMC,CAAA,EAAaC,EAAS,CAAE,MAAO,EAAG,EAC1C,CAAE,KAAMC,CAAA,EAAeC,EAAe,CAAE,OAAQ,UAAW,MAAO,EAAG,EACrE,CAAE,KAAMC,CAAA,EAAYC,EAAA,EAEpBC,IACJC,EAAAH,GAAA,YAAAA,EAAS,UAAT,YAAAG,EAAkB,OAAQC,GAAMA,EAAE,SAAW,aAAa,SAAU,EAChEC,EAAWL,EAAU,GAAGE,CAAgB,IAAIF,EAAQ,KAAK,GAAK,IAEpE,aACG,MAAA,CACC,SAAAM,EAAAA,IAACC,EAAA,CACC,MAAM,QACN,MAAO,CACL,CAAE,MAAO,QAAS,OAAOX,GAAA,YAAAA,EAAU,QAAS,GAAA,EAC5C,CAAE,MAAO,sBAAuB,OAAOE,GAAA,YAAAA,EAAY,QAAS,IAAK,SAAU,mBAAA,EAC3E,CAAE,MAAO,cAAe,MAAOO,CAAA,EAC/B,CAAE,MAAO,SAAU,MAAO,UAAW,SAAU,mBAAA,CAAoB,CACrE,CAAA,EAEJ,CAEJ"}
+{"version":3,"file":"AdminDashboard-DQS74RL0.js","sources":["../../src/pages/admin/AdminDashboard.tsx"],"sourcesContent":["import { useTasks } from '../../api/tasks';\nimport { useEscalations } from '../../api/escalations';\nimport { useEscalationListEvents } from '../../hooks/useEventHooks';\nimport { useMcpServers } from '../../api/mcp';\nimport { PageHeaderWithStats } from '../../components/common/layout/PageHeaderWithStats';\n\nexport function AdminDashboard() {\n  useEscalationListEvents();\n  const { data: taskData } = useTasks({ limit: 1 });\n  const { data: pendingEsc } = useEscalations({ status: 'pending', limit: 1 });\n  const { data: mcpData } = useMcpServers();\n\n  const connectedServers =\n    mcpData?.servers?.filter((s) => s.status === 'connected').length ?? 0;\n  const mcpLabel = mcpData ? `${connectedServers}/${mcpData.total}` : '—';\n\n  return (\n    <div>\n      <PageHeaderWithStats\n        title=\"Admin\"\n        stats={[\n          { label: 'Tasks', value: taskData?.total ?? '—' },\n          { label: 'Pending Escalations', value: pendingEsc?.total ?? '—', dotClass: 'bg-status-pending' },\n          { label: 'MCP Servers', value: mcpLabel },\n          { label: 'System', value: 'Healthy', dotClass: 'bg-status-success' },\n        ]}\n      />\n    </div>\n  );\n}\n"],"names":["AdminDashboard","useEscalationListEvents","taskData","useTasks","pendingEsc","useEscalations","mcpData","useMcpServers","connectedServers","_a","s","mcpLabel","jsx","PageHeaderWithStats"],"mappings":"4UAMO,SAASA,GAAiB,OAC/BC,EAAA,EACA,KAAM,CAAE,KAAMC,CAAA,EAAaC,EAAS,CAAE,MAAO,EAAG,EAC1C,CAAE,KAAMC,CAAA,EAAeC,EAAe,CAAE,OAAQ,UAAW,MAAO,EAAG,EACrE,CAAE,KAAMC,CAAA,EAAYC,EAAA,EAEpBC,IACJC,EAAAH,GAAA,YAAAA,EAAS,UAAT,YAAAG,EAAkB,OAAQC,GAAMA,EAAE,SAAW,aAAa,SAAU,EAChEC,EAAWL,EAAU,GAAGE,CAAgB,IAAIF,EAAQ,KAAK,GAAK,IAEpE,aACG,MAAA,CACC,SAAAM,EAAAA,IAACC,EAAA,CACC,MAAM,QACN,MAAO,CACL,CAAE,MAAO,QAAS,OAAOX,GAAA,YAAAA,EAAU,QAAS,GAAA,EAC5C,CAAE,MAAO,sBAAuB,OAAOE,GAAA,YAAAA,EAAY,QAAS,IAAK,SAAU,mBAAA,EAC3E,CAAE,MAAO,cAAe,MAAOO,CAAA,EAC/B,CAAE,MAAO,SAAU,MAAO,UAAW,SAAU,mBAAA,CAAoB,CACrE,CAAA,EAEJ,CAEJ"}