@happyvertical/smrt-support 0.57.34 → 0.57.35

package/dist/smrt-knowledge.json

@@ -3,13 +3,13 @@
   "sensitiveFieldsExcluded": true,
   "generatedAt": "1970-01-01T00:00:00.000Z",
   "packageName": "@happyvertical/smrt-support",
-  "packageVersion": "0.57.34",
+  "packageVersion": "0.57.35",
   "sourceManifestPath": "dist/manifest.json",
   "agentDocPath": "AGENTS.md",
   "sourceHashes": {
-    "manifest": "c4bd5bfb3889a4b3c9c99ef98d87dcd0569e3f8f12e5a392c376370651d73194",
-    "packageJson": "425838a87e6d7ddf645293e0359018bc3b4b25c90f993f2b80a0dc828205e3d9",
-    "agents": "2ad2109ce8b2880f6144b97076a94ed185c68e84dfcd468f368d6a571ece0ef7"
+    "manifest": "e35cfe9a024c2e34b76044faf4220a45245bc6482fa119a2534ec894adb6a0a0",
+    "packageJson": "1c6d77cd72f249e57b5347fe6ae0da3b04825b0d1454da477ac10e6e76d079a8",
+    "agents": "06c34c176f2e9fcb1b2b2efa900ea859e8fe61906a5345f8bac81cd2119a2998"
   },
   "exports": [
     ".",
@@ -1077,31 +1077,36 @@
           "name": "caseNumber",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "The reference number for this ticket."
         },
         {
           "name": "subject",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "A short summary of what the customer needs."
         },
         {
           "name": "description",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "What the customer asked for, in their words."
         },
         {
           "name": "status",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "Where the ticket stands, from new to resolved."
         },
         {
           "name": "priority",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "How soon it needs attention: low, normal, high or urgent."
         },
         {
           "name": "severity",
@@ -1132,7 +1137,8 @@
           "type": "crossPackageRef",
           "required": false,
           "related": "@happyvertical/smrt-profiles:Profile",
-          "columnType": "UUID"
+          "columnType": "UUID",
+          "description": "The customer who asked for help."
         },
         {
           "name": "openedByProfileId",
@@ -1178,7 +1184,8 @@
           "type": "foreignKey",
           "required": false,
           "related": "SupportSpecialist",
-          "columnType": "UUID"
+          "columnType": "UUID",
+          "description": "The team member handling this ticket."
         },
         {
           "name": "assignedAt",
@@ -2101,13 +2108,15 @@
           "type": "foreignKey",
           "required": true,
           "related": "SupportCase",
-          "columnType": "UUID"
+          "columnType": "UUID",
+          "description": "The ticket this message belongs to."
         },
         {
           "name": "direction",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "Whether the customer sent it or your team did."
         },
         {
           "name": "channelKind",
@@ -2132,13 +2141,15 @@
           "name": "occurredAt",
           "type": "datetime",
           "required": false,
-          "columnType": "TIMESTAMP"
+          "columnType": "TIMESTAMP",
+          "description": "When the message was sent."
         },
         {
           "name": "body",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "What the message says."
         },
         {
           "name": "sourceType",
@@ -4298,19 +4309,22 @@
           "type": "crossPackageRef",
           "required": true,
           "related": "@happyvertical/smrt-profiles:Profile",
-          "columnType": "UUID"
+          "columnType": "UUID",
+          "description": "The profile of the person on your team."
         },
         {
           "name": "displayName",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "The name your team and customers see."
         },
         {
           "name": "status",
           "type": "text",
           "required": false,
-          "columnType": "TEXT"
+          "columnType": "TEXT",
+          "description": "Whether this person is taking tickets right now."
         },
         {
           "name": "languages",
@@ -6016,7 +6030,266 @@
     "polymorphicAssociations": 0,
     "uuidColumns": 150
   },
-  "agentDoc": "# @happyvertical/smrt-support\n\nAI-first Support Cases for the SMRT framework (epic #1934). Every inbound\nsupport interaction — chat message or email — creates or joins one canonical,\ntenant-scoped **Support Case**; channels stay transports, never separate\nsystems of record. The package owns the case lifecycle, channel intake, the\nAutomated Support Response workflow with lossless **Human Handoff**,\nProject-qualified routing, **Service Target** clocks with timed escalation,\nand auditable **Service Time Entries** whose client charges and provider\ncompensation stay separate. Since #3288 the shared `ServiceTimeEntry` class\nis owned by `smrt-timesheets` (smrt-projects re-exports it); this package's\nsubtype extends it directly, adds `caseId` / `specialistId` (frozen on\napproval via `frozenFieldNames()`), and restates the shared fields for\nisolated manifest scanning. Every import uses the unchanged\n`service_time_entries` table, so no data is duplicated. Keep the subtype a\ndirect child of the timesheets entry: a third same-named level on the table\nbreaks single-table-family resolution.\n\n**Boundary (FR-29a):** Support owns tickets, interactions, routing, and\nservice targets. Delivery Operations owns repository work — a **Delivery\nHandoff** links a case to a Development Work Item (e.g.\n`@happyvertical/smrt-projects:Issue`) via a `SupportWorkLink` without ever\ndriving its execution; the delivery side reports status echoes back.\n\n## Models\n\nCase-side models are **internal**: generated API/CLI/MCP surfaces are\nread-only (`list`/`get`) and every write goes through the service facades\n(the `smrt-chat` `ChatService` idiom). Operational configuration models\n(bindings, policies, specialists, qualifications, availability) expose full\ngenerated CRUD; **commercial terms** (`SupportPlan`,\n`SupportCompensationPlan`) are read-only too — their writes flow through the\n`support.manage-plans`-gated `SupportPlanAdminService`.\n\n### Case core (#1926)\n\n- **SupportCase** (`support_cases`) — canonical ticket: `caseNumber`,\n  `subject`, `status` (`new → triaged → assigned → in_progress →\n  waiting_on_client|escalated → resolved → closed`, guarded at save time via\n  the WeakMap + authoritative-DB-read idiom from S5 #1390), `priority`,\n  `severity` (plan-defined key), `category`, `sensitive`, `channelKind`,\n  `clientProfileId`/`openedByProfileId` (crossPackageRef → Profile),\n  `projectId` (app-defined string — deliberately not an FK), `bindingId`,\n  `threadKey` (create-or-join dedup key), `planId` + `planSnapshot` (terms\n  frozen at apply time), assignment fields, response stamps\n  (`acknowledgedAt`, `firstRespondedAt`), `humanRequestedAt`, resolution\n  fields, `reopenCount`/`lastReopenedAt`, `aiEnabled`.\n- **SupportInteraction** (`support_interactions`,\n  `conflictColumns: ['source_key']`) — channel-neutral transport record:\n  `direction` (`inbound`/`outbound`/`internal`), `channelKind`, `actorKind`\n  (`client`/`specialist`/`agent`/`system`), denormalized `body`, and the\n  qualified `sourceType`/`sourceId` + globally unique `sourceKey`\n  (`chat:<messageId>`, `email:<emailId>`, `manual:<uuid>`) that makes\n  re-ingestion idempotent.\n- **SupportCaseEvent** (`support_case_events`) — append-only audit trail\n  (transitions, assignments, AI runs, handoffs, escalations, target state,\n  work links, reopens). Together with interactions this is the complete\n  context a Human Handoff transfers.\n- **SupportChannelBinding** (`support_channel_bindings`,\n  `conflictColumns: ['target_type','target_id']`) — marks a container as a\n  support intake channel: `bindingKind` (`chat_room`/`email_account`),\n  qualified `targetType` + `targetId`, default client/project/plan,\n  `selfAddresses` (email direction heuristic). Unbound containers are never\n  touched.\n- **SupportWorkLink** (`support_work_links`) — Support/Development Work Item\n  links with a read-only `status` echo.\n\n### AI workflow (#1928)\n\n- **SupportPolicy** (`support_policies`) — what the AI may do without a\n  human: `autoAcknowledge`/`autoClassify`/`autoAnswer` (on by default),\n  `autoTroubleshoot`/`autoResolve` (off by default),\n  `autoResolveMaxSeverity`, `confidenceThreshold`, `maxAutoAttempts`,\n  `sensitiveCategories`, `allowedTools`, `autoSendEmailReplies` (off —\n  email replies are drafted, not sent). Resolution is most-specific-wins on\n  `(planId, projectId)`; no row → `DEFAULT_SUPPORT_POLICY` (conservative).\n- **SupportAiRun** (`support_ai_runs`) — append-only audit of each phase\n  (`acknowledge`/`classify`/`answer`/`troubleshoot`/`resolve`) with\n  `confidence`, classification output, knowledge refs, tool calls, outcome\n  (`completed`/`skipped`/`failed`/`handed_off`), and `correlationId`.\n\n### Routing, targets, escalation (#1929)\n\n- **SupportSpecialist** (`support_specialists`) — specialist role record on a\n  Profile (the commerce `Customer` role-record idiom): `languages`,\n  `timezone`, `maxConcurrentCases`, `onCallPriority`, status.\n- **SupportQualification** (`support_qualifications`) — effective-dated\n  Project Support Qualification (`trainee`/`qualified`/`expert`).\n- **SupportAvailability** (`support_availability_windows`) — weekly windows\n  plus `on_call`/`time_off` spans.\n- **SupportPlan** (`support_plans`, `conflictColumns:\n  ['tenant_id','plan_key']`) — the Managed Support Plan: coverage calendar +\n  holidays + timezone, channels, severity definitions, per-severity\n  acknowledgement/response/update/resolution target minutes, `pauseStatuses`\n  (clocks pause only when the plan says so), escalation policy steps,\n  availability fee, `includedMinutes`, `overageHourlyRate`,\n  `onCallHourlyRate`, time-approval policy, optional\n  `subscriptionPlanKey` binding (string, not a dependency).\n  `snapshotTerms()` feeds `SupportCase.planSnapshot`.\n- **SupportServiceTarget** (`support_service_targets`,\n  `conflictColumns: ['case_id','target_type','cycle']`) — one clock per\n  target type (update clocks recur via `cycle`), with pause accounting and\n  `escalationJobId` (the one-shot `_smrt_jobs` row scheduled at `dueAt`,\n  cancelled on satisfy).\n- **SupportEscalation** (`support_escalations`) — the audit record of one\n  escalation firing.\n- **SupportCompensationPlan** (`support_compensation_plans`) —\n  effective-dated Support Specialist earning terms; specialist-specific plan\n  wins over the tenant default at the work instant. Deliberately separate\n  from `SupportPlan` (client pricing) so margin stays measurable.\n\n### Service time (#1930)\n\n- **ServiceTimeEntry** (`service_time_entries`) — auditable Professional\n  Service duration: work-context-generic (`caseId` and/or polymorphic\n  `workRefType`/`workRefId`), delivering Participant (`participantKind`\n  `human`/`agent` + `participantProfileId`/`agentRef`), `source`\n  (`timer`/`manual`/`import`/`agent` — one shared validation/audit\n  contract), evidence JSON, and lifecycle `draft → submitted →\n  approved|rejected`, `approved → corrected` only. **Approved entries are\n  immutable**: the work-defining fields are frozen at save time (the\n  `LicenseSale` WeakMap-freeze idiom, backed by an authoritative DB-row\n  comparison); disputes create explicit corrections via `correctionOfId`.\n- **SupportCharge** / **SupportCompensation** (`support_charges` /\n  `support_compensations`, one per time entry) — derived commercial\n  snapshots: client amount from the Managed Support Plan (included-time\n  consumption then metered overage) vs provider amount from the Support\n  Compensation Plan, each with a frozen `rateSnapshot`. Margin = charge −\n  compensation, computed by readers; settlement/invoicing composes at the\n  app/accounting boundary (#1925) and is out of scope here.\n\n## Services\n\n- **SupportCaseService** — the closed write facade: `openCase`,\n  `recordInteraction` (idempotent on `sourceKey`; stamps\n  `acknowledgedAt`/`firstRespondedAt`; inbound un-parks\n  `waiting_on_client`), `transition`, `assign`, `resolve`, `close`,\n  `reopen` (preserves prior resolution in the reopen event), `requestHuman`,\n  `linkWork`/`recordWorkStatus` (Delivery Handoff), `recordEvent`,\n  `getTimeline` (merged interactions + events).\n- **SupportIntakeService** — create-or-join intake for both channels:\n  `ingestChatMessage` (bound `ChatRoom`; `chat:<roomId>[:<threadId>]` thread\n  keys; only `role: 'user'` messages), `ingestEmail` (bound `EmailAccount`;\n  RFC-thread joins via `inReplyTo`; `selfAddresses` skip; unresolved senders\n  park the case with `metadata.unresolvedClient`), plus\n  `registerSupportIntake()` — an opt-in `GlobalInterceptors.afterSave`\n  observer keyed on the `ChatMessage`/`Email` class names that never throws\n  into the source package's save path. Join semantics: open case → join;\n  resolved → reopen; closed → new case.\n- **SupportAiWorkflow** — the Automated Support Response (FR-28a):\n  `processIntake`/`processCase` run acknowledge → classify → answer →\n  resolve under the resolved `SupportPolicy` (conservative defaults), each\n  phase writing a `SupportAiRun` + `ai_run` case event. AI calls go through\n  the injected `SupportAiBoundary` (default uses `supportCase.do()` with\n  defensive JSON parsing that fails toward the human); knowledge comes from\n  the pluggable `SupportKnowledgeProvider` (default no-op). Classification\n  never overwrites human triage; email answers are drafted\n  (`metadata.draft`) unless the policy allows sending. Handoff triggers —\n  `client_request`, `low_confidence`, `high_severity`, `sensitive`,\n  `failed_resolution`, `policy` (attempt budget) — are always active.\n- **HumanHandoffService** — the lossless Human Handoff (FR-28b):\n  `handoff` assembles the full context package (case state + compact\n  timeline + AI runs) into the `handoff` event, stamps\n  `metadata.activeHandoff` for the no-repeat guarantee (repeat triggers are\n  deduped events), routes through the injected `assignSpecialist` seam\n  (#1929's routing service plugs in; default queues `new` cases to\n  `triaged`), and `releaseHandoff` clears the flag.\n- **ServiceTargetEngine** — Service Target clocks (FR-30/31):\n  `startTargetsForCase` derives per-severity clocks from the case's\n  `planSnapshot` (live plan fallback) with due times computed in covered\n  time (`coverage-calendar.ts`: timezone-aware weekly windows + holidays;\n  empty coverage = 24×7) and schedules one-shot `_smrt_jobs` escalation jobs\n  at `dueAt`; `onInteractionRecorded` satisfies acknowledgement/response and\n  recurs `update` cycles; `onCaseTransition` pauses/resumes clocks only when\n  the plan's `pauseStatuses` say so (recomputing remaining covered minutes)\n  and settles targets on resolve. Breach → `SupportServiceTarget.\n  checkAndEscalate` (background-eligible, at-least-once-safe) marks the\n  breach and escalates through the plan's policy steps (notify/reassign,\n  delayed follow-up levels), transitioning the case to `escalated`.\n- **SupportPlanAdminService** — the permission-gated write surface for\n  commercial terms: create/update/archive for Managed Support Plans and\n  Support Compensation Plans, every act behind `support.manage-plans` with\n  cross-tenant writes refused (generated CRUD on both models is read-only).\n- **SupportRoutingService** — explainable ranked routing (FR-30):\n  `rankSpecialists` hard-filters on active status, effective Project\n  Support Qualification, workload cap, and availability windows (specialist\n  timezone), then scores preferred-specialist, qualification level, on-call,\n  workload headroom, and language (weights in `ROUTING_WEIGHTS`; every\n  factor recorded so ineligible specialists show why); `autoAssign` writes\n  the assignment with its rationale; `reassign` is gated by\n  `support.reassign-case` and refuses cross-tenant principals.\n- **ServiceTimeEntryService** — the ONE recording contract for all four\n  entry sources (FR-40): `record` validates duration (explicit or derived\n  from the period; `timer` needs both bounds), participant coherence\n  (`human` → `participantProfileId`, `agent` → `agentRef`), and the work\n  context (case and/or work ref; case entries copy the tenant and append a\n  `time_recorded` event); `submit` stamps the submitter.\n- **TimeEntryApprovalService** — the approval gate and only writer of the\n  commercial snapshots (FR-36): `approve` resolves the governing terms (case\n  `planSnapshot` first, live plan fallback, zero-rate default), gates by\n  policy path (`automatic`/`threshold`/`operator`/`client`; operator paths\n  behind `support.approve-time-entry`; cross-tenant principals refused), then\n  derives the `SupportCharge` (included time first, then overage/on-call) and\n  `SupportCompensation` (effective-dated plan) rows; `reject` and `correct`\n  (supersede + linked fresh draft via `correctionOfId`) round out the\n  lifecycle. Case events carry the charge amount only — compensation never\n  leaks case-side.\n\n## Permissions\n\nContributed to the runtime catalog on import (the\n`personas.activate-directive` pattern): `support.reassign-case`,\n`support.approve-time-entry`, `support.manage-plans`. Privileged service\noperations take a `SupportPrincipal` (`can(slug)`), built from explicit slugs\nor a `PermissionResolver`.\n\n## Svelte UI\n\n`@happyvertical/smrt-support/svelte` ships presentational Svelte 5 surfaces:\n`CaseQueue` (priority/status/assignment/channel at a glance, `onselect`),\n`CaseDetail` (header, meta, linked work, merged timeline), `TargetList`\n(Service Target clocks with due/paused/satisfied/breached badges),\n`RoutingRationale` (ranked specialists with eligibility + factor chips and\nan optional reassign action), and `TimeEntryApprovalQueue`\n(date/hours/description/worker/status/amount with\napprove/reject-with-reason actions on submitted rows; owned by\nsmrt-timesheets since #3288 and re-exported here). Hosts adapt models\nwith `toSupportCaseView` / `toCaseTimelineItemView` / `toServiceTargetView`\n/ `toSupportTimeEntryView` — the time-entry view's first eight fields\ndeliberately match the presentation `TimeEntry` contract, and\n`SupportTimeEntryView` extends smrt-timesheets' `TimeEntryApprovalView`.\nComponents use `smrt-ui` primitives (`smrtRawPrimitives: \"strict\"`).\n\n## Dependencies\n\nPackage dependencies: `smrt-core`, `smrt-tenancy`, `smrt-projects`,\n`smrt-timesheets`, `smrt-chat`, `smrt-messages`, `smrt-jobs`, `smrt-users`,\n`smrt-ui`,\n`@happyvertical/logger`, `@happyvertical/sql`. Profile and subscriptions\nreferences are `@crossPackageRef` string ids or plain string\nkeys. `smrt-projects` is the intentional shared delivery edge added by #1955;\n`smrt-timesheets` owns the shared time-entry evidence (#3288). No inter-`smrt-*` `peerDependencies`.\n\n## Validation\n\n```sh\npnpm --filter @happyvertical/smrt-support test\npnpm --filter @happyvertical/smrt-support test:postgres\npnpm --filter @happyvertical/smrt-support typecheck\npnpm --filter @happyvertical/smrt-support build\n```\n\n`test:postgres` is the lane that holds the money/rate line — SQLite's type\naffinity stores a REAL in an INTEGER column without complaint, so a money field\nthat reverted to DECIMAL passes every SQLite suite.\n\n## Money and rates\n\n- **Money is integer minor units** (cents) — `$19.99` is `1999`.\n  `SupportPlan.availabilityFeeAmount`, `SupportCharge.amount` and\n  `SupportCompensation.amount` initialize `= 0`, never `= 0.0`: the integer\n  literal is what maps them to INTEGER columns (BIGINT on fresh PostgreSQL/DuckDB databases; #2401, #2373).\n- **Rates stay DECIMAL but their unit changed.**\n  `SupportPlan.overageHourlyRate` / `onCallHourlyRate` and\n  `SupportCompensationPlan.hourlyRate` are **minor units per hour**, so\n  `hours * rate` yields minor units. INTEGER would truncate a sub-unit rate to\n  zero, which is why they keep a decimal initializer.\n- **`roundMoney()` is the single rate↔money boundary.** It rounds\n  `(seconds / 3600) * hourlyRate` to a whole minor unit, which is what lets the\n  `thresholdAmount` comparison in `determinePath()` be an exact `>` with no\n  tolerance. `TimeApprovalPolicy.thresholdAmount` is in the same unit as\n  `SupportCharge.amount`.\n- **Migrating an existing database**: `preflightSupportMoneyMinorUnits(db)`\n  reports which columns still hold major units and which rows would be rounded\n  or exceed JavaScript's safe-integer range; `migrateSupportMoneyToMinorUnits(db)` converts them\n  (idempotent via `_smrt_backfills`). The **rate columns are not in that list**\n  — their type does not change, but their stored values must still be\n  multiplied by the same scale in the same deploy step. Frozen `rateSnapshot`\n  JSON on settled charges is history and is left alone. On SQLite the values\n  are rescaled but the declared type needs the table-rebuild path (#2370).\n  Fresh PostgreSQL/DuckDB INTEGER columns are BIGINT and hydration rejects\n  values outside JavaScript's safe-integer range; existing PostgreSQL `int4`\n  columns require #2424.\n\n## Gotchas\n\n- **Writes go through the facades** — the case-side generated routes are\n  read-only on purpose; `create`/`update` on them is not a bug to \"fix\".\n- **`projectId` is an app-defined string** — the consuming app owns the\n  Project concept; don't turn it into an FK or a crossPackageRef to\n  `smrt-projects:Project` (that class is a provider board, not a client\n  initiative).\n- **`SupportCase.threadKey` + `SupportInteraction.sourceKey` carry intake\n  correctness** — `sourceKey` is globally unique (`conflictColumns`), so\n  replayed transport rows are no-ops; new manual interactions must use a\n  fresh `manual:<uuid>` key.\n- **High-volume models avoid the inherited `name` field** (`subject`,\n  `displayName`, …) so the default `(slug, context, _meta_type)` unique index\n  falls back to id-derived slugs; named config models carry\n  `conflictColumns` instead (which replaces that index).\n- **Approved time entries never change** — corrections are new rows linked\n  by `correctionOfId`; the original flips to `corrected` with its snapshot\n  intact.\n- **Plan edits never rewrite history** — cases keep `planSnapshot`, charges\n  and compensation keep `rateSnapshot`.\n- **Create-or-join and included-time consumption serialize in-process** —\n  `SupportIntakeService` (per conversation key) and\n  `TimeEntryApprovalService` (per case) use a `KeyedMutex`, which covers the\n  single-app-process deployment these paths run in. Multi-replica\n  deployments must serialize at the app layer (route a conversation's\n  intake / a case's approvals through one worker, or add an app-level\n  claim) — the framework exposes no cross-adapter transaction primitive at\n  this seam. Escalation is additionally idempotent per `(target, level)`,\n  so at-least-once job redelivery never stacks duplicate escalations.\n",
+  "agentDoc": "# @happyvertical/smrt-support\n\nAI-first Support Cases for the SMRT framework (epic #1934). Every inbound\nsupport interaction — chat message or email — creates or joins one canonical,\ntenant-scoped **Support Case**; channels stay transports, never separate\nsystems of record. The package owns the case lifecycle, channel intake, the\nAutomated Support Response workflow with lossless **Human Handoff**,\nProject-qualified routing, **Service Target** clocks with timed escalation,\nand auditable **Service Time Entries** whose client charges and provider\ncompensation stay separate. Since #3288 the shared `ServiceTimeEntry` class\nis owned by `smrt-timesheets` (smrt-projects re-exports it); this package's\nsubtype extends it directly, adds `caseId` / `specialistId` (frozen on\napproval via `frozenFieldNames()`), and restates the shared fields for\nisolated manifest scanning. Every import uses the unchanged\n`service_time_entries` table, so no data is duplicated. Keep the subtype a\ndirect child of the timesheets entry: a third same-named level on the table\nbreaks single-table-family resolution.\n\n**Boundary (FR-29a):** Support owns tickets, interactions, routing, and\nservice targets. Delivery Operations owns repository work — a **Delivery\nHandoff** links a case to a Development Work Item (e.g.\n`@happyvertical/smrt-projects:Issue`) via a `SupportWorkLink` without ever\ndriving its execution; the delivery side reports status echoes back.\n\n## Models\n\nCase-side models are **internal**: generated API/CLI/MCP surfaces are\nread-only (`list`/`get`) and every write goes through the service facades\n(the `smrt-chat` `ChatService` idiom). Operational configuration models\n(bindings, policies, specialists, qualifications, availability) expose full\ngenerated CRUD; **commercial terms** (`SupportPlan`,\n`SupportCompensationPlan`) are read-only too — their writes flow through the\n`support.manage-plans`-gated `SupportPlanAdminService`.\n\n### Case core (#1926)\n\n- **SupportCase** (`support_cases`) — canonical ticket: `caseNumber`,\n  `subject`, `status` (`new → triaged → assigned → in_progress →\n  waiting_on_client|escalated → resolved → closed`, guarded at save time via\n  the WeakMap + authoritative-DB-read idiom from S5 #1390), `priority`,\n  `severity` (plan-defined key), `category`, `sensitive`, `channelKind`,\n  `clientProfileId`/`openedByProfileId` (crossPackageRef → Profile),\n  `projectId` (app-defined string — deliberately not an FK), `bindingId`,\n  `threadKey` (create-or-join dedup key), `planId` + `planSnapshot` (terms\n  frozen at apply time), assignment fields, response stamps\n  (`acknowledgedAt`, `firstRespondedAt`), `humanRequestedAt`, resolution\n  fields, `reopenCount`/`lastReopenedAt`, `aiEnabled`.\n- **SupportInteraction** (`support_interactions`,\n  `conflictColumns: ['source_key']`) — channel-neutral transport record:\n  `direction` (`inbound`/`outbound`/`internal`), `channelKind`, `actorKind`\n  (`client`/`specialist`/`agent`/`system`), denormalized `body`, and the\n  qualified `sourceType`/`sourceId` + globally unique `sourceKey`\n  (`chat:<messageId>`, `email:<emailId>`, `manual:<uuid>`) that makes\n  re-ingestion idempotent.\n- **SupportCaseEvent** (`support_case_events`) — append-only audit trail\n  (transitions, assignments, AI runs, handoffs, escalations, target state,\n  work links, reopens). Together with interactions this is the complete\n  context a Human Handoff transfers.\n- **SupportChannelBinding** (`support_channel_bindings`,\n  `conflictColumns: ['target_type','target_id']`) — marks a container as a\n  support intake channel: `bindingKind` (`chat_room`/`email_account`),\n  qualified `targetType` + `targetId`, default client/project/plan,\n  `selfAddresses` (email direction heuristic). Unbound containers are never\n  touched.\n- **SupportWorkLink** (`support_work_links`) — Support/Development Work Item\n  links with a read-only `status` echo.\n\n### AI workflow (#1928)\n\n- **SupportPolicy** (`support_policies`) — what the AI may do without a\n  human: `autoAcknowledge`/`autoClassify`/`autoAnswer` (on by default),\n  `autoTroubleshoot`/`autoResolve` (off by default),\n  `autoResolveMaxSeverity`, `confidenceThreshold`, `maxAutoAttempts`,\n  `sensitiveCategories`, `allowedTools`, `autoSendEmailReplies` (off —\n  email replies are drafted, not sent). Resolution is most-specific-wins on\n  `(planId, projectId)`; no row → `DEFAULT_SUPPORT_POLICY` (conservative).\n- **SupportAiRun** (`support_ai_runs`) — append-only audit of each phase\n  (`acknowledge`/`classify`/`answer`/`troubleshoot`/`resolve`) with\n  `confidence`, classification output, knowledge refs, tool calls, outcome\n  (`completed`/`skipped`/`failed`/`handed_off`), and `correlationId`.\n\n### Routing, targets, escalation (#1929)\n\n- **SupportSpecialist** (`support_specialists`) — specialist role record on a\n  Profile (the commerce `Customer` role-record idiom): `languages`,\n  `timezone`, `maxConcurrentCases`, `onCallPriority`, status.\n- **SupportQualification** (`support_qualifications`) — effective-dated\n  Project Support Qualification (`trainee`/`qualified`/`expert`).\n- **SupportAvailability** (`support_availability_windows`) — weekly windows\n  plus `on_call`/`time_off` spans.\n- **SupportPlan** (`support_plans`, `conflictColumns:\n  ['tenant_id','plan_key']`) — the Managed Support Plan: coverage calendar +\n  holidays + timezone, channels, severity definitions, per-severity\n  acknowledgement/response/update/resolution target minutes, `pauseStatuses`\n  (clocks pause only when the plan says so), escalation policy steps,\n  availability fee, `includedMinutes`, `overageHourlyRate`,\n  `onCallHourlyRate`, time-approval policy, optional\n  `subscriptionPlanKey` binding (string, not a dependency).\n  `snapshotTerms()` feeds `SupportCase.planSnapshot`.\n- **SupportServiceTarget** (`support_service_targets`,\n  `conflictColumns: ['case_id','target_type','cycle']`) — one clock per\n  target type (update clocks recur via `cycle`), with pause accounting and\n  `escalationJobId` (the one-shot `_smrt_jobs` row scheduled at `dueAt`,\n  cancelled on satisfy).\n- **SupportEscalation** (`support_escalations`) — the audit record of one\n  escalation firing.\n- **SupportCompensationPlan** (`support_compensation_plans`) —\n  effective-dated Support Specialist earning terms; specialist-specific plan\n  wins over the tenant default at the work instant. Deliberately separate\n  from `SupportPlan` (client pricing) so margin stays measurable.\n\n### Service time (#1930)\n\n- **ServiceTimeEntry** (`service_time_entries`) — auditable Professional\n  Service duration: work-context-generic (`caseId` and/or polymorphic\n  `workRefType`/`workRefId`), delivering Participant (`participantKind`\n  `human`/`agent` + `participantProfileId`/`agentRef`), `source`\n  (`timer`/`manual`/`import`/`agent` — one shared validation/audit\n  contract), evidence JSON, and lifecycle `draft → submitted →\n  approved|rejected`, `approved → corrected` only. **Approved entries are\n  immutable**: the work-defining fields are frozen at save time (the\n  `LicenseSale` WeakMap-freeze idiom, backed by an authoritative DB-row\n  comparison); disputes create explicit corrections via `correctionOfId`.\n- **SupportCharge** / **SupportCompensation** (`support_charges` /\n  `support_compensations`, one per time entry) — derived commercial\n  snapshots: client amount from the Managed Support Plan (included-time\n  consumption then metered overage) vs provider amount from the Support\n  Compensation Plan, each with a frozen `rateSnapshot`. Margin = charge −\n  compensation, computed by readers; settlement/invoicing composes at the\n  app/accounting boundary (#1925) and is out of scope here.\n\n## Services\n\n- **SupportCaseService** — the closed write facade: `openCase`,\n  `recordInteraction` (idempotent on `sourceKey`; stamps\n  `acknowledgedAt`/`firstRespondedAt`; inbound un-parks\n  `waiting_on_client`), `transition`, `assign`, `resolve`, `close`,\n  `reopen` (preserves prior resolution in the reopen event), `requestHuman`,\n  `linkWork`/`recordWorkStatus` (Delivery Handoff), `recordEvent`,\n  `getTimeline` (merged interactions + events).\n- **SupportIntakeService** — create-or-join intake for both channels:\n  `ingestChatMessage` (bound `ChatRoom`; `chat:<roomId>[:<threadId>]` thread\n  keys; only `role: 'user'` messages), `ingestEmail` (bound `EmailAccount`;\n  RFC-thread joins via `inReplyTo`; `selfAddresses` skip; unresolved senders\n  park the case with `metadata.unresolvedClient`), plus\n  `registerSupportIntake()` — an opt-in `GlobalInterceptors.afterSave`\n  observer keyed on the `ChatMessage`/`Email` class names that never throws\n  into the source package's save path. Join semantics: open case → join;\n  resolved → reopen; closed → new case.\n- **SupportAiWorkflow** — the Automated Support Response (FR-28a):\n  `processIntake`/`processCase` run acknowledge → classify → answer →\n  resolve under the resolved `SupportPolicy` (conservative defaults), each\n  phase writing a `SupportAiRun` + `ai_run` case event. AI calls go through\n  the injected `SupportAiBoundary` (default uses `supportCase.do()` with\n  defensive JSON parsing that fails toward the human); knowledge comes from\n  the pluggable `SupportKnowledgeProvider` (default no-op). Classification\n  never overwrites human triage; email answers are drafted\n  (`metadata.draft`) unless the policy allows sending. Handoff triggers —\n  `client_request`, `low_confidence`, `high_severity`, `sensitive`,\n  `failed_resolution`, `policy` (attempt budget) — are always active.\n- **HumanHandoffService** — the lossless Human Handoff (FR-28b):\n  `handoff` assembles the full context package (case state + compact\n  timeline + AI runs) into the `handoff` event, stamps\n  `metadata.activeHandoff` for the no-repeat guarantee (repeat triggers are\n  deduped events), routes through the injected `assignSpecialist` seam\n  (#1929's routing service plugs in; default queues `new` cases to\n  `triaged`), and `releaseHandoff` clears the flag.\n- **ServiceTargetEngine** — Service Target clocks (FR-30/31):\n  `startTargetsForCase` derives per-severity clocks from the case's\n  `planSnapshot` (live plan fallback) with due times computed in covered\n  time (`coverage-calendar.ts`: timezone-aware weekly windows + holidays;\n  empty coverage = 24×7) and schedules one-shot `_smrt_jobs` escalation jobs\n  at `dueAt`; `onInteractionRecorded` satisfies acknowledgement/response and\n  recurs `update` cycles; `onCaseTransition` pauses/resumes clocks only when\n  the plan's `pauseStatuses` say so (recomputing remaining covered minutes)\n  and settles targets on resolve. Breach → `SupportServiceTarget.\n  checkAndEscalate` (background-eligible, at-least-once-safe) marks the\n  breach and escalates through the plan's policy steps (notify/reassign,\n  delayed follow-up levels), transitioning the case to `escalated`.\n- **SupportPlanAdminService** — the permission-gated write surface for\n  commercial terms: create/update/archive for Managed Support Plans and\n  Support Compensation Plans, every act behind `support.manage-plans` with\n  cross-tenant writes refused (generated CRUD on both models is read-only).\n- **SupportRoutingService** — explainable ranked routing (FR-30):\n  `rankSpecialists` hard-filters on active status, effective Project\n  Support Qualification, workload cap, and availability windows (specialist\n  timezone), then scores preferred-specialist, qualification level, on-call,\n  workload headroom, and language (weights in `ROUTING_WEIGHTS`; every\n  factor recorded so ineligible specialists show why); `autoAssign` writes\n  the assignment with its rationale; `reassign` is gated by\n  `support.reassign-case` and refuses cross-tenant principals.\n- **ServiceTimeEntryService** — the ONE recording contract for all four\n  entry sources (FR-40): `record` validates duration (explicit or derived\n  from the period; `timer` needs both bounds), participant coherence\n  (`human` → `participantProfileId`, `agent` → `agentRef`), and the work\n  context (case and/or work ref; case entries copy the tenant and append a\n  `time_recorded` event); `submit` stamps the submitter.\n- **TimeEntryApprovalService** — the approval gate and only writer of the\n  commercial snapshots (FR-36): `approve` resolves the governing terms (case\n  `planSnapshot` first, live plan fallback, zero-rate default), gates by\n  policy path (`automatic`/`threshold`/`operator`/`client`; operator paths\n  behind `support.approve-time-entry`; cross-tenant principals refused), then\n  derives the `SupportCharge` (included time first, then overage/on-call) and\n  `SupportCompensation` (effective-dated plan) rows; `reject` and `correct`\n  (supersede + linked fresh draft via `correctionOfId`) round out the\n  lifecycle. Case events carry the charge amount only — compensation never\n  leaks case-side.\n\n## Permissions\n\nContributed to the runtime catalog on import (the\n`personas.activate-directive` pattern): `support.reassign-case`,\n`support.approve-time-entry`, `support.manage-plans`. Privileged service\noperations take a `SupportPrincipal` (`can(slug)`), built from explicit slugs\nor a `PermissionResolver`.\n\n## Svelte UI\n\n`@happyvertical/smrt-support/svelte` ships presentational Svelte 5 surfaces:\n`CaseQueue` (priority/status/assignment/channel at a glance, `onselect`),\n`CaseDetail` (header, meta, linked work, merged timeline), `TargetList`\n(Service Target clocks with due/paused/satisfied/breached badges),\n`RoutingRationale` (ranked specialists with eligibility + factor chips and\nan optional reassign action), and `TimeEntryApprovalQueue`\n(date/hours/description/worker/status/amount with\napprove/reject-with-reason actions on submitted rows; owned by\nsmrt-timesheets since #3288 and re-exported here). Hosts adapt models\nwith `toSupportCaseView` / `toCaseTimelineItemView` / `toServiceTargetView`\n/ `toSupportTimeEntryView` — the time-entry view's first eight fields\ndeliberately match the presentation `TimeEntry` contract, and\n`SupportTimeEntryView` extends smrt-timesheets' `TimeEntryApprovalView`.\nComponents use `smrt-ui` primitives (`smrtRawPrimitives: \"strict\"`).\n\n## Dependencies\n\nPackage dependencies: `smrt-core`, `smrt-tenancy`, `smrt-projects`,\n`smrt-timesheets`, `smrt-chat`, `smrt-messages`, `smrt-jobs`, `smrt-users`,\n`smrt-ui`,\n`@happyvertical/logger`, `@happyvertical/sql`. Profile and subscriptions\nreferences are `@crossPackageRef` string ids or plain string\nkeys. `smrt-projects` is the intentional shared delivery edge added by #1955;\n`smrt-timesheets` owns the shared time-entry evidence (#3288). No inter-`smrt-*` `peerDependencies`.\n\n## Validation\n\n```sh\npnpm --filter @happyvertical/smrt-support test\npnpm --filter @happyvertical/smrt-support test:postgres\npnpm --filter @happyvertical/smrt-support typecheck\npnpm --filter @happyvertical/smrt-support build\n```\n\n`test:postgres` is the lane that holds the money/rate line — SQLite's type\naffinity stores a REAL in an INTEGER column without complaint, so a money field\nthat reverted to DECIMAL passes every SQLite suite.\n\n## Money and rates\n\n- **Money is integer minor units** (cents) — `$19.99` is `1999`.\n  `SupportPlan.availabilityFeeAmount`, `SupportCharge.amount` and\n  `SupportCompensation.amount` initialize `= 0`, never `= 0.0`: the integer\n  literal is what maps them to INTEGER columns (BIGINT on fresh PostgreSQL/DuckDB databases; #2401, #2373).\n- **Rates stay DECIMAL but their unit changed.**\n  `SupportPlan.overageHourlyRate` / `onCallHourlyRate` and\n  `SupportCompensationPlan.hourlyRate` are **minor units per hour**, so\n  `hours * rate` yields minor units. INTEGER would truncate a sub-unit rate to\n  zero, which is why they keep a decimal initializer.\n- **`roundMoney()` is the single rate↔money boundary.** It rounds\n  `(seconds / 3600) * hourlyRate` to a whole minor unit, which is what lets the\n  `thresholdAmount` comparison in `determinePath()` be an exact `>` with no\n  tolerance. `TimeApprovalPolicy.thresholdAmount` is in the same unit as\n  `SupportCharge.amount`.\n- **Migrating an existing database**: `preflightSupportMoneyMinorUnits(db)`\n  reports which columns still hold major units and which rows would be rounded\n  or exceed JavaScript's safe-integer range; `migrateSupportMoneyToMinorUnits(db)` converts them\n  (idempotent via `_smrt_backfills`). The **rate columns are not in that list**\n  — their type does not change, but their stored values must still be\n  multiplied by the same scale in the same deploy step. Frozen `rateSnapshot`\n  JSON on settled charges is history and is left alone. On SQLite the values\n  are rescaled but the declared type needs the table-rebuild path (#2370).\n  Fresh PostgreSQL/DuckDB INTEGER columns are BIGINT and hydration rejects\n  values outside JavaScript's safe-integer range; existing PostgreSQL `int4`\n  columns require #2424.\n\n## Gotchas\n\n- **Writes go through the facades** — the case-side generated routes are\n  read-only on purpose; `create`/`update` on them is not a bug to \"fix\".\n- **`projectId` is an app-defined string** — the consuming app owns the\n  Project concept; don't turn it into an FK or a crossPackageRef to\n  `smrt-projects:Project` (that class is a provider board, not a client\n  initiative).\n- **`SupportCase.threadKey` + `SupportInteraction.sourceKey` carry intake\n  correctness** — `sourceKey` is globally unique (`conflictColumns`), so\n  replayed transport rows are no-ops; new manual interactions must use a\n  fresh `manual:<uuid>` key.\n- **High-volume models avoid the inherited `name` field** (`subject`,\n  `displayName`, …) so the default `(slug, context, _meta_type)` unique index\n  falls back to id-derived slugs; named config models carry\n  `conflictColumns` instead (which replaces that index).\n- **Approved time entries never change** — corrections are new rows linked\n  by `correctionOfId`; the original flips to `corrected` with its snapshot\n  intact.\n- **Plan edits never rewrite history** — cases keep `planSnapshot`, charges\n  and compensation keep `rateSnapshot`.\n- **Create-or-join and included-time consumption serialize in-process** —\n  `SupportIntakeService` (per conversation key) and\n  `TimeEntryApprovalService` (per case) use a `KeyedMutex`, which covers the\n  single-app-process deployment these paths run in. Multi-replica\n  deployments must serialize at the app layer (route a conversation's\n  intake / a case's approvals through one worker, or add an app-level\n  claim) — the framework exposes no cross-adapter transaction primitive at\n  this seam. Escalation is additionally idempotent per `(target, level)`,\n  so at-least-once job redelivery never stacks duplicate escalations.\n\n- **Recipe `support.tickets`** (`src/recipes.ts`, help in `src/tickets.recipe.md`): lists tickets, messages and the support team for the planner and other catalog hosts. Fields it shows carry `@field({ description })` in plain words; keep them when editing the models.\n",
+  "recipes": [
+    {
+      "id": "support.tickets",
+      "className": "SupportTicketsRecipe",
+      "label": "Support",
+      "summary": "Keep every customer request for help in one place until it is solved.",
+      "synonyms": [
+        "support tickets",
+        "tickets",
+        "helpdesk",
+        "help desk",
+        "customer support",
+        "cases"
+      ],
+      "models": [
+        "@happyvertical/smrt-support:SupportCase",
+        "@happyvertical/smrt-support:SupportInteraction",
+        "@happyvertical/smrt-support:SupportSpecialist"
+      ],
+      "nav": [
+        {
+          "label": "Tickets",
+          "model": "@happyvertical/smrt-support:SupportCase",
+          "icon": "fileText",
+          "description": "Every request for help, who is handling it and where it stands.",
+          "noun": "ticket"
+        },
+        {
+          "label": "Messages",
+          "model": "@happyvertical/smrt-support:SupportInteraction",
+          "icon": "book",
+          "description": "What was said on each ticket, by the customer or your team.",
+          "noun": "message"
+        },
+        {
+          "label": "Support team",
+          "model": "@happyvertical/smrt-support:SupportSpecialist",
+          "icon": "users",
+          "description": "The people who answer tickets and when they are available.",
+          "noun": "team member"
+        }
+      ],
+      "requires": [],
+      "section": {
+        "id": "support",
+        "label": "Support",
+        "icon": "users",
+        "description": "Help your customers and keep track of every request."
+      },
+      "options": {
+        "@happyvertical/smrt-support:SupportCase": {
+          "fields": {
+            "caseNumber": {
+              "label": "Ticket number",
+              "order": 1
+            },
+            "subject": {
+              "order": 2
+            },
+            "description": {
+              "order": 3
+            },
+            "status": {
+              "order": 4
+            },
+            "priority": {
+              "order": 5
+            },
+            "clientProfileId": {
+              "label": "Customer",
+              "order": 6
+            },
+            "assignedSpecialistId": {
+              "label": "Assigned to",
+              "order": 7
+            },
+            "tenantId": {
+              "visibility": "hidden"
+            },
+            "assignedAt": {
+              "visibility": "hidden"
+            },
+            "escalatedAt": {
+              "visibility": "hidden"
+            },
+            "acknowledgedAt": {
+              "visibility": "hidden"
+            },
+            "firstRespondedAt": {
+              "visibility": "hidden"
+            },
+            "humanRequestedAt": {
+              "visibility": "hidden"
+            },
+            "resolvedAt": {
+              "visibility": "hidden"
+            },
+            "closedAt": {
+              "visibility": "hidden"
+            },
+            "lastReopenedAt": {
+              "visibility": "hidden"
+            },
+            "severity": {
+              "visibility": "advanced"
+            },
+            "category": {
+              "visibility": "advanced"
+            },
+            "sensitive": {
+              "visibility": "advanced"
+            },
+            "channelKind": {
+              "visibility": "advanced"
+            },
+            "openedByProfileId": {
+              "visibility": "advanced"
+            },
+            "resolutionSummary": {
+              "visibility": "advanced"
+            },
+            "projectId": {
+              "visibility": "hidden"
+            },
+            "bindingId": {
+              "visibility": "hidden"
+            },
+            "threadKey": {
+              "visibility": "hidden"
+            },
+            "planId": {
+              "visibility": "hidden"
+            },
+            "planSnapshot": {
+              "visibility": "hidden"
+            },
+            "preferredSpecialistId": {
+              "visibility": "hidden"
+            },
+            "escalationLevel": {
+              "visibility": "hidden"
+            },
+            "resolvedByProfileId": {
+              "visibility": "hidden"
+            },
+            "resolutionKind": {
+              "visibility": "hidden"
+            },
+            "reopenCount": {
+              "visibility": "hidden"
+            },
+            "aiEnabled": {
+              "visibility": "hidden"
+            },
+            "metadata": {
+              "visibility": "hidden"
+            }
+          }
+        },
+        "@happyvertical/smrt-support:SupportInteraction": {
+          "fields": {
+            "body": {
+              "label": "Message",
+              "order": 1
+            },
+            "caseId": {
+              "label": "Ticket",
+              "order": 2
+            },
+            "direction": {
+              "order": 3
+            },
+            "tenantId": {
+              "visibility": "hidden"
+            },
+            "channelKind": {
+              "visibility": "advanced"
+            },
+            "actorKind": {
+              "visibility": "advanced"
+            },
+            "authorProfileId": {
+              "visibility": "advanced"
+            },
+            "sourceType": {
+              "visibility": "hidden"
+            },
+            "sourceId": {
+              "visibility": "hidden"
+            },
+            "sourceKey": {
+              "visibility": "hidden"
+            },
+            "rfcMessageId": {
+              "visibility": "hidden"
+            },
+            "metadata": {
+              "visibility": "hidden"
+            }
+          }
+        },
+        "@happyvertical/smrt-support:SupportSpecialist": {
+          "fields": {
+            "displayName": {
+              "label": "Name",
+              "order": 1
+            },
+            "status": {
+              "order": 2
+            },
+            "tenantId": {
+              "visibility": "hidden"
+            },
+            "profileId": {
+              "visibility": "advanced"
+            },
+            "languages": {
+              "visibility": "advanced"
+            },
+            "timezone": {
+              "visibility": "advanced"
+            },
+            "maxConcurrentCases": {
+              "label": "Most tickets at once",
+              "visibility": "advanced"
+            },
+            "onCallPriority": {
+              "visibility": "hidden"
+            },
+            "notes": {
+              "visibility": "advanced"
+            },
+            "metadata": {
+              "visibility": "hidden"
+            }
+          }
+        }
+      },
+      "help": {
+        "markdown": "## Overview\n\nSupport keeps every request for help from a customer in one place. Each request\nis a ticket with a number, a subject, who asked, who is handling it and where\nit stands, from new to resolved. Messages back and forth stay on the ticket, so\nanyone on the team can pick it up and see what was said.\n\n## Tasks\n\nTickets and their messages are created by your support channels (email, chat\nand the like) and by the support service, not by hand in the app. Here you\nread them and see where each one stands.\n\n### Find a ticket\n\n1. Open the list of tickets.\n2. Look at the **{field:SupportCase.subject}**, the **{field:SupportCase.status}** and the **{field:SupportCase.priority}** to see what needs attention.\n3. Open a ticket to see who it is **{field:SupportCase.assignedSpecialistId}** and the **{field:SupportCase.description}**.\n\n### Read the history of a ticket\n\n1. Open the list of messages.\n2. Find the **{field:SupportInteraction.caseId}** you are interested in.\n3. Read the **{field:SupportInteraction.body}** of each message, oldest first.\n\n### Add someone to the support team\n\n1. Open the support team and choose **New**.\n2. Type the person's **{field:SupportSpecialist.displayName}**.\n3. Save. They can now be given tickets by the support service.\n",
+        "fieldRefs": [
+          "SupportCase.assignedSpecialistId",
+          "SupportCase.description",
+          "SupportCase.priority",
+          "SupportCase.status",
+          "SupportCase.subject",
+          "SupportInteraction.body",
+          "SupportInteraction.caseId",
+          "SupportSpecialist.displayName"
+        ]
+      },
+      "demo": {
+        "mode": "server",
+        "reasons": [
+          "Needs a server because its package does not build for a browser: core migrations (node:os); and its package depends on @happyvertical/smrt-agents, @happyvertical/smrt-chat, @happyvertical/smrt-images, @happyvertical/smrt-jobs, @happyvertical/smrt-profiles, @happyvertical/smrt-projects, @happyvertical/smrt-reports, @happyvertical/smrt-secrets, @happyvertical/smrt-subscriptions, @happyvertical/smrt-tenancy, @happyvertical/smrt-timesheets, @happyvertical/smrt-users, which do not build for a browser (#3615, #3617, #3624, #3625, #3626, #3627, #3628)."
+        ]
+      }
+    }
+  ],
   "browser": {
     "status": "server-only",
     "issues": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@happyvertical/smrt-support",
-  "version": "0.57.34",
+  "version": "0.57.35",
   "smrtJsdoc": "strict",
   "description": "AI-first Support Cases: channel-neutral intake, lifecycle, routing, service targets, and service time for the SMRT framework",
   "type": "module",
@@ -27,15 +27,15 @@
   },
   "dependencies": {
     "@happyvertical/logger": "^0.108.0",
-    "@happyvertical/smrt-chat": "0.57.34",
-    "@happyvertical/smrt-core": "0.57.34",
-    "@happyvertical/smrt-jobs": "0.57.34",
-    "@happyvertical/smrt-messages": "0.57.34",
-    "@happyvertical/smrt-projects": "0.57.34",
-    "@happyvertical/smrt-tenancy": "0.57.34",
-    "@happyvertical/smrt-timesheets": "0.57.34",
-    "@happyvertical/smrt-ui": "0.57.34",
-    "@happyvertical/smrt-users": "0.57.34",
+    "@happyvertical/smrt-chat": "0.57.35",
+    "@happyvertical/smrt-core": "0.57.35",
+    "@happyvertical/smrt-jobs": "0.57.35",
+    "@happyvertical/smrt-messages": "0.57.35",
+    "@happyvertical/smrt-projects": "0.57.35",
+    "@happyvertical/smrt-tenancy": "0.57.35",
+    "@happyvertical/smrt-timesheets": "0.57.35",
+    "@happyvertical/smrt-ui": "0.57.35",
+    "@happyvertical/smrt-users": "0.57.35",
     "@happyvertical/sql": "^0.108.0"
   },
   "peerDependencies": {
@@ -47,7 +47,7 @@
     }
   },
   "devDependencies": {
-    "@happyvertical/smrt-vitest": "0.57.34",
+    "@happyvertical/smrt-vitest": "0.57.35",
     "@sveltejs/package": "^2.5.8",
     "@sveltejs/vite-plugin-svelte": "^7.3.0",
     "@types/node": "24.13.6",