@cxtms/cx-schema 1.9.242 → 1.9.244

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cxtms/cx-schema",
-  "version": "1.9.242",
+  "version": "1.9.244",
   "description": "Schema validation package for CXTMS YAML modules",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/cxtms-developer/ref-entity-dispatch-routing.md

@@ -98,6 +98,7 @@ Dispatch routing covers reusable weekly route templates, daily dispatch routes,
 |-------|------|-------|
 | `dispatchRouteStopId` | `int` | PK |
 | `dispatchRouteId` | `int` | Parent route |
+| `dispatchRoute` | `DispatchRoute?` | Expandable parent route; available in GraphQL and trigger payload mapping |
 | `stopContactId` | `int?` | Store/location contact (nullable; use with or without `contactAddressId`) |
 | `contactAddressId` | `int?` | Optional stop address |
 | `stopType` | `DispatchRouteType` | Defaults to route route type when omitted |
@@ -163,6 +164,11 @@ Vertical-specific routing details belong in `customValues`.
 | `customValues` | `Dictionary` | Location, event, appointment, and metric data |
 | `trackingEvents` | `[TrackingEvent]` | Leg-level milestones |
 
+Entity-trigger payloads load the status navigation before mapping when necessary. This
+means `OrderMoveLeg` trigger conditions can rely on the current leg status name after an
+FK-only change, and `DispatchRouteStop` trigger conditions can rely on the current stop
+status and parent route.
+
 `OrderMoveStatus` and `OrderMoveLegStatus` are organization-scoped status dictionaries with
 `statusName`, `statusDescription`, `statusStage`, `priority`, `color`, and `customValues`.
 Moves support `OrderMove/Create@1`, `OrderMove/Update@1`, and `OrderMove/Delete@1` workflow tasks.

package/skills/cxtms-developer/ref-entity-order.md

@@ -75,6 +75,7 @@ Order GraphQL quick search (`orders(search:)` and `orderGroupBy(search:)`) match
 | `dispatchRouteStopOrders` | `[DispatchRouteStopOrder]` | Stop membership links for this order; expand `dispatchRouteStop` to inspect route, stop status, or stop tracking events |
 | `allTags` | `[OrderAllTagsView]` | View: all tags including from commodities |
 | `allRelatedOrders` | `[OrderRelatedOrdersView]` | Orders sharing commodities |
+| `relatedOrdersV3` | `[OrderRelatedOrdersV3View]` | Filter/sort navigation backed by the non-recursive V3 view; use paths such as `relatedOrdersV3[relatedOrder.orderType:BookingOrder].relatedOrder.trackingNumber` |
 | `relatedDispatchRoutes` | `[DispatchRoute]` | Routes linked through dispatch route stop order attachments; supports `filter` and `orderBy`; draft orders return an empty list |
 | `attachmentsSummary` | `OrderAttachmentSummaryView?` | DB view: `.totalCount`, `.hasAny` (active attachments) |
 | `notesSummary` | `OrderNoteSummaryView?` | DB view: `.totalCount`, `.hasAny` (non-deleted notes) |
@@ -118,7 +119,7 @@ These are virtual fields that filter `orderEntities` by type:
 | `getModeOfTransportation(idPropertyName)` | `ModeOfTransportation` | |
 | `getCustomCode(idPropertyName)` | `CustomCode` | |
 | `getRelatedOrderByProperty(idPropertyName)` | `Order` | Resolve related order from `customValues[idPropertyName]` |
-| `relatedOrdersV3(filter?, orderBy?)` | `[Order]` | Related orders resolved through `fn_order_related_orders`; scoped to the current organization |
+| `relatedOrdersV3(filter?, orderBy?)` | `[Order]` | Related orders resolved through `fn_order_related_orders`; scoped to the current organization. Order-list filter/sort paths use the same-named entity navigation backed by `vw_order_related_orders_v3` (maximum three container levels). |
 | `relatedOrderV3(filter?, orderBy?)` | `Order` | First V3 related order after filtering and sorting |
 | `relatedDispatchRoutes(filter, orderBy)` | `[DispatchRoute]` | Routes linked through dispatch route stop order attachments; draft orders return an empty list |
 | `getCharge(chargeDescription)` | `Charge` | Single charge by description |

package/skills/cxtms-module-builder/ref-components-layout.md

@@ -426,6 +426,11 @@ props:
 
 Tabbed interface with MUI TabContext. Tab state stored in URL params.
 
+Tabs may contain a `slot` child as an extension point. The web renderer replaces that child
+in place with the registered extension layouts, ordered by `props.order`. Each extension
+layout must be a `tab`; the slot does not render as an empty tab. Template expressions in
+the slot name are resolved from component variables and store values before lookup.
+
 **Props:**
 | Prop | Type | Description |
 |------|------|-------------|