cxtms 1.9.16 → 1.9.22

package/dist/workflowValidator.d.ts

@@ -1,5 +1,5 @@
 /**
- * Workflow validator for CargoXplorer YAML workflow files
+ * Workflow validator for CXTMS YAML workflow files
  */
 import { ValidationResult, WorkflowValidatorOptions } from './types';
 export declare class WorkflowValidator {

package/dist/workflowValidator.js

@@ -1,6 +1,6 @@
 "use strict";
 /**
- * Workflow validator for CargoXplorer YAML workflow files
+ * Workflow validator for CXTMS YAML workflow files
  */
 var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
     if (k2 === undefined) k2 = k;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "cxtms",
-  "version": "1.9.16",
-  "description": "Schema validation package for CargoXplorer YAML modules",
+  "version": "1.9.22",
+  "description": "Schema validation package for CXTMS YAML modules",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "bin": {
@@ -19,10 +19,10 @@
     "validation",
     "yaml",
     "tms",
-    "cargoxplorer",
+    "cxtms",
     "module"
   ],
-  "author": "CargoXplorer",
+  "author": "CXTMS",
   "license": "MIT",
   "repository": {
     "type": "git",

package/schemas/components/README.md

@@ -1,6 +1,6 @@
 # Component Schemas
 
-This directory contains individual JSON schema files for each CargoXplorer component type. Breaking down component schemas into separate files improves maintainability, organization, and reusability.
+This directory contains individual JSON schema files for each CXTMS component type. Breaking down component schemas into separate files improves maintainability, organization, and reusability.
 
 ## Directory Structure
 

package/schemas/components/appComponent.json

@@ -1,8 +1,8 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Generic CargoXplorer App Component",
+  "title": "Generic CXTMS App Component",
   "type": "object",
-  "description": "Base schema for any CargoXplorer component that can be used within the application",
+  "description": "Base schema for any CXTMS component that can be used within the application",
   "properties": {
     "name": {
       "type": "string",

package/schemas/components/index.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
   "title": "Component Schemas Index",
-  "description": "Index of all available CargoXplorer component schemas",
+  "description": "Index of all available CXTMS component schemas",
   "type": "object",
   "definitions": {
     "appComponent": {

package/schemas/fields/README.md

@@ -1,6 +1,6 @@
 # Field Type Schemas
 
-This directory contains separate JSON schema files for each field type supported by the CargoXplorer TMS system.
+This directory contains separate JSON schema files for each field type supported by CXTMS.
 
 ## Available Field Types
 
@@ -39,7 +39,7 @@ Each field type schema includes:
 - Field-specific properties and validation
 - Event handlers (onChange, onBlur, onFocus, onSelectValue)
 - Transformation configurations
-- Real-world examples from the CargoXplorer modules
+- Real-world examples from the CXTMS modules
 - Complete type safety and validation rules
 
 ## Usage
@@ -63,4 +63,4 @@ The field schemas integrate with:
 
 ## Examples
 
-Each schema includes comprehensive examples derived from real usage patterns in the CargoXplorer TMS modules, ensuring practical applicability and correct implementation.
+Each schema includes comprehensive examples derived from real usage patterns in the CXTMS modules, ensuring practical applicability and correct implementation.

package/schemas/fields/index.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
   "title": "Field Types Index",
-  "description": "Index of all available field types for CargoXplorer TMS",
+  "description": "Index of all available field types for CXTMS",
   "definitions": {
     "fieldType": {
       "oneOf": [

package/schemas/schemas.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "CargoXplorer Module and Component Schemas",
+  "title": "CXTMS Module and Component Schemas",
   "type": "object",
   "definitions": {
     "templateExpression": {
@@ -45,7 +45,7 @@
 
     "component": {
       "type": "object",
-      "description": "Generic component structure for CargoXplorer",
+      "description": "Generic component structure for CXTMS",
       "properties": {
         "component": {
           "type": "string",
@@ -404,7 +404,7 @@
 
     "entity": {
       "type": "object",
-      "description": "CargoXplorer entity definition",
+      "description": "CXTMS entity definition",
       "properties": {
         "name": { "type": "string" },
         "entityKind": {

package/schemas/workflows/workflow.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "CargoXplorer Workflow",
-  "description": "Schema for CargoXplorer workflow YAML files. Supports standard task-based workflows and Flow (state machine) workflows.",
+  "title": "CXTMS Workflow",
+  "description": "Schema for CXTMS workflow YAML files. Supports standard task-based workflows and Flow (state machine) workflows.",
   "type": "object",
   "properties": {
     "workflow": {

package/scripts/postinstall.js

@@ -115,9 +115,9 @@ const CX_CLAUDE_MARKER = '<!-- cx-schema-instructions -->';
 
 function generateClaudeMdContent() {
   return `${CX_CLAUDE_MARKER}
-## CargoXplorer Project
+## CXTMS Project
 
-This is a CargoXplorer (CX) application. Modules and workflows are defined as YAML files validated against JSON schemas provided by \`@cxtms/cx-schema\`.
+This is a CXTMS (CX) application. Modules and workflows are defined as YAML files validated against JSON schemas provided by \`@cxtms/cx-schema\`.
 
 ### Project Structure
 

package/skills/cxtms-developer/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: cxtms-developer
 description: >
-  Shared CargoXplorer domain reference — entity fields, enums, customValues, GraphQL queries, and CLI auth.
+  Shared CXTMS domain reference — entity fields, enums, customValues, GraphQL queries, and CLI auth.
   Use when the user asks about CX entity fields, enums, customValues, entity relationships, or needs domain reference for Orders, Contacts, Commodities, Jobs, Charges, or other CX entities.
   Also use when the user wants to look up, check, or query specific orders, parcel shipments, commodities, tracking events, workflow logs, or any CX data.
 argument-hint: <entity name or question about fields>
 ---
 
-Shared domain reference for CargoXplorer entities. Used by `cxtms-workflow-builder` and `cxtms-module-builder` skills for entity field names, types, navigation properties, enums, and customValues extension patterns.
+Shared domain reference for CXTMS entities. Used by `cxtms-workflow-builder` and `cxtms-module-builder` skills for entity field names, types, navigation properties, enums, and customValues extension patterns.
 
 ## Feature File Layout
 

package/skills/cxtms-developer/ref-cli-auth.md

@@ -5,7 +5,7 @@
 - PAT Tokens (CI/CD alternative to OAuth)
 - Organization Management
 - Session Resolution
-- Publish (push modules and workflows to server)
+- Deploy All (push modules and workflows to server)
 
 ## Authentication
 
@@ -70,22 +70,24 @@ Server commands resolve the target session in this order:
 2. `~/.cxtms/<project-dir>/.session.json` → project-scoped OAuth session
 3. Not logged in → error
 
-## Publish
+## Deploy All
 
 ```bash
-# Publish all modules and workflows from current project
-npx cxtms publish
+# Deploy all modules and workflows from current project to the CX server
+npx cxtms deploy-all
 
-# Publish only a specific feature directory
-npx cxtms publish --feature billing
-npx cxtms publish billing
+# Deploy only a specific feature directory
+npx cxtms deploy-all --feature billing
+npx cxtms deploy-all billing
 
-# Publish with explicit org ID
-npx cxtms publish --org 42
+# Deploy with explicit org ID
+npx cxtms deploy-all --org 42
 ```
 
 Validates all YAML files first, then pushes modules and workflows to the server. Skips files with validation errors and reports results.
 
+> Note: `deploy-all` pushes local YAML files to the CX server (per-file `updateWorkflow` / `updateAppModule` mutations). It does **not** touch git or create a PR. Use `app release` to open a git PR from the server's pending changes.
+
 ## App Manifest Management
 
 Server-side app manifest operations — install from git, release changes to git, and list installed apps.
@@ -100,21 +102,21 @@ npx cxtms app install --force
 # Install from a specific branch
 npx cxtms app install --branch develop
 
-# Install but skip modules that have unpublished local changes
+# Install but skip modules that have unreleased local changes
 npx cxtms app install --skip-changed
 
 # Release server changes to git (creates a PR) — message is required
 npx cxtms app release -m "Add new shipping module"
 
 # Force release all modules and workflows (not just changed ones)
-npx cxtms app release -m "Full republish" --force
+npx cxtms app release -m "Full re-release" --force
 
 # List installed app manifests on the server
 npx cxtms app list
 ```
 
-**`app install`** reads `repository` and `branch` from `app.yaml`, downloads the repo on the server side, and installs/updates all modules and workflows. Use `--force` to reinstall even if the version hasn't changed. Use `--skip-changed` to preserve modules with unpublished changes.
+**`app install`** reads `repository` and `branch` from `app.yaml`, downloads the repo on the server side, and installs/updates all modules and workflows. Use `--force` to reinstall even if the version hasn't changed. Use `--skip-changed` to preserve modules with unreleased changes.
 
 **`app release`** takes the current server state and releases it to git by creating a PR. Requires a `-m` message describing the changes (like a git commit message). The server increments the version, creates a release branch, commits all module/workflow YAML files, and opens a pull request to the target branch.
 
-**`app list`** shows all installed app manifests with their version, status flags (disabled, unpublished changes, update available), and repository info.
+**`app list`** shows all installed app manifests with their version, status flags (disabled, unreleased changes, update available), and repository info.

package/skills/cxtms-module-builder/SKILL.md

@@ -7,7 +7,7 @@ description: >
 argument-hint: <description of what to build>
 ---
 
-You are a CargoXplorer module YAML builder. You generate schema-valid YAML for CX app modules — UI screens, forms, data grids, routes, and components. All output must conform to the JSON schemas in `.cx-schema/`.
+You are a CXTMS module YAML builder. You generate schema-valid YAML for CX app modules — UI screens, forms, data grids, routes, and components. All output must conform to the JSON schemas in `.cx-schema/`.
 
 **IMPORTANT — use `cxtms` for all module operations:**
 - **Scaffold**: `npx cxtms create module <name> --template <template>` — generates a schema-valid YAML file. ALWAYS run this first, then read the generated file, then customize. Do NOT write YAML from scratch or copy templates manually.
@@ -20,7 +20,7 @@ You are a CargoXplorer module YAML builder. You generate schema-valid YAML for C
 - **Feature folder**: `npx cxtms create module <name> --template <template> --feature <feature-name>`
 - **Deploy to server**: `npx cxtms appmodule deploy <file.yaml> --org <id>` — creates or updates module on the CX server
 - **Undeploy from server**: `npx cxtms appmodule undeploy <appModuleId> --org <id>` — removes a module by UUID
-- **Publish all**: `npx cxtms publish [--feature <name>] --org <id>` — deploy all modules and workflows to the server
+- **Deploy all**: `npx cxtms deploy-all [--feature <name>] --org <id>` — push all modules and workflows from the project to the CX server
 
 ## Generation Workflow
 
@@ -211,7 +211,7 @@ module:
     en-US: "Human Readable Name"
   description:
     en-US: "Module description"
-  application: "CargoXplorer"             # Required
+  application: "CXTMS"             # Required
   filePath: "modules/<name>-module.yaml"  # File path in repo
 
 entities:
@@ -416,15 +416,15 @@ Deploy, undeploy, and release commands are listed in the CLI section at the top
 Use `app release` to release modified modules and workflows from the CX server to a GitHub repository. This creates a branch and pull request — it does NOT push directly to the target branch.
 
 ```bash
-# Release all unpublished changes to GitHub (creates a PR) — message is required
+# Release all unreleased changes to GitHub (creates a PR) — message is required
 npx cxtms app release -m "Add warehouse locations module"
 
 # Release specific modules and/or workflows by YAML file
 npx cxtms app release -m "Fix country module" modules/my-module.yaml
 npx cxtms app release -m "Update billing" modules/a.yaml workflows/b.yaml
 
-# Force release all modules and workflows (not just unpublished ones)
-npx cxtms app release -m "Full republish" --force
+# Force release all modules and workflows (not just unreleased ones)
+npx cxtms app release -m "Full re-release" --force
 
 # Release with explicit org
 npx cxtms app release -m "Add warehouse locations module" --org 42

package/skills/cxtms-workflow-builder/SKILL.md

@@ -7,7 +7,7 @@ description: >
 argument-hint: <description of what to build>
 ---
 
-You are a CargoXplorer workflow YAML builder. You generate schema-valid YAML for CX workflows — both standard process workflows (activities, steps, triggers) and Flow state machine workflows (entity lifecycle, states, transitions). All output must conform to the JSON schemas in `.cx-schema/`.
+You are a CXTMS workflow YAML builder. You generate schema-valid YAML for CX workflows — both standard process workflows (activities, steps, triggers) and Flow state machine workflows (entity lifecycle, states, transitions). All output must conform to the JSON schemas in `.cx-schema/`.
 
 **IMPORTANT — use `cxtms` for all workflow operations:**
 - **Scaffold**: `npx cxtms create workflow <name> --template <template>` — generates a schema-valid YAML file. ALWAYS run this first, then read the generated file, then customize. Do NOT write YAML from scratch or copy templates manually.
@@ -21,7 +21,7 @@ You are a CargoXplorer workflow YAML builder. You generate schema-valid YAML for
 - **Execute**: `npx cxtms workflow execute <workflowId|file.yaml> --org <id> [--vars '<json>'] [--file varName=path]` — trigger a workflow execution (--file uploads a local file and passes the URL as a variable)
 - **List logs**: `npx cxtms workflow logs <workflowId|file.yaml> --org <id> [--from YYYY-MM-DD] [--to YYYY-MM-DD]` — list executions with log availability
 - **Download log**: `npx cxtms workflow log <executionId> --org <id> [--json] [--console] [--output <file>]` — download execution log
-- **Publish all**: `npx cxtms publish [--feature <name>] --org <id>` — deploy all modules and workflows to the server
+- **Deploy all**: `npx cxtms deploy-all [--feature <name>] --org <id>` — push all modules and workflows from the project to the CX server
 
 ## Generation Workflow
 
@@ -326,15 +326,15 @@ Deploy, undeploy, and release commands are listed in the CLI section at the top
 Use `app release` to release modified workflows and modules from the CX server to a GitHub repository. This creates a branch and pull request — it does NOT push directly to the target branch.
 
 ```bash
-# Release all unpublished changes to GitHub (creates a PR) — message is required
+# Release all unreleased changes to GitHub (creates a PR) — message is required
 npx cxtms app release -m "Add order notification workflow"
 
 # Release specific workflows and/or modules by YAML file
 npx cxtms app release -m "Fix tracking workflow" workflows/my-workflow.yaml
 npx cxtms app release -m "Update shipping" workflows/a.yaml modules/b.yaml
 
-# Force release all workflows and modules (not just unpublished ones)
-npx cxtms app release -m "Full republish" --force
+# Force release all workflows and modules (not just unreleased ones)
+npx cxtms app release -m "Full re-release" --force
 
 # Release with explicit org
 npx cxtms app release -m "Add order notification workflow" --org 42

package/skills/cxtms-workflow-builder/ref-expressions-ncalc.md

@@ -4,8 +4,8 @@
 - NCalc expression syntax `[variable]` (in conditions and expression directives)
 - Operators (comparison, logical, arithmetic, ternary, membership)
 - Iterator variables (`[each.*]` and `[item.*]`)
-- Collection functions (any, all, count, sum, first, last, distinct, groupBy, join, etc.)
-- String functions (isNullOrEmpty, length, lower, upper, replace, format, base64, etc.)
+- Collection functions (any, all, count, sum, first, last, distinct, select, zip, groupBy, join, etc.)
+- String functions (isNullOrEmpty, length, lower, upper, replace, format, base64, coalesce, etc.)
 - Date functions (now, parseDate, addDays, formatDate, dateFromUnix, etc.)
 - Math functions (Abs, Ceiling, Floor, Round, Min, Max, etc.)
 - Domain functions (convertWeight, convertDimension)
@@ -28,6 +28,7 @@ conditions:
 - Numeric strings are auto-converted to `decimal` when needed (e.g., `[price] > 100` works even if price is the string `"150"`)
 - Dot paths resolve deep: `[Activity.Step.output.nested.field]`
 - Optional suffix `?` prevents errors: `[order.customer?.name?]`
+- Wildcard traversal continues through POCOs, dictionaries, and `JObject` values, for example `[items[*].customValues.chapter_en?]`
 
 ### Operators
 
@@ -42,14 +43,14 @@ conditions:
 ### Iterator Variables
 
 Functions use two iterator variable names:
-- **`[each.*]`** -- used by: `any`, `all`, `sum`, `join` (3-arg)
+- **`[each.*]`** -- used by: `any`, `all`, `sum`, `select`, `join` (3-arg), and projections over `zip(...)` output
 - **`[item.*]`** -- used by: `first`, `last`, `groupBy`
 
 ### Collection Functions
 
 | Function | Description |
 |----------|-------------|
-| `any([items], [each.prop] = 'val')` | True if any item matches expression. Without expression: checks if collection contains the value |
+| `any([items], [each.prop] = 'val')` | True if any item matches expression. Without expression: checks if collection contains the value. Returns `false` for empty collections |
 | `all([items], [each.prop] > 0)` | True if all items match. Returns `false` for null/empty collections |
 | `count([items])` | Count items in list or JToken. Returns `0` for non-collections |
 | `sum([items], [each.amount])` | Sum values as `decimal`. Optional `[each.*]` accessor. Skips nulls |
@@ -63,6 +64,8 @@ Functions use two iterator variable names:
 | `groupBy([items], [item.cat])` | Group by one or more key expressions. Returns `[{key, items}]`. Multi-key: keys joined with `\|` |
 | `join([items], [each.name], ',')` | Join collection with `[each.*]` accessor and separator (3-arg) |
 | `join([items], ',')` | Join collection directly with separator (2-arg) |
+| `select([items], [each.field])` | Project each item via `[each.*]` accessor. Returns flat `List<object>` of projected values. Empty input → empty list |
+| `zip([a], [b])` | Pair elements from two or more lists into `[{item1, item2}, ...]`. Custom keys: `zip([a], [b], 'name', 'code')`. Variadic: accepts N lists. Truncates to shortest list. Returns empty list if any input is empty/null. Falls back to `item1`, `item2`, ... when custom key count does not match list count |
 | `split([str], ' ')` | Split string by first character of separator. Returns `List<string>` |
 | `elementAt([items], 0)` | Get element at index (zero-based) from list |
 
@@ -82,6 +85,8 @@ Functions use two iterator variable names:
 | `bool([value])` | Convert to boolean: null->`false`, empty string->`false`, "true"/"false"->parsed, non-zero number->`true`, any object->`true` |
 | `transliterate([value])` | Unicode to ASCII (Unidecode). Returns `""` for null |
 | `transliterateUa([value])` | Ukrainian-specific transliteration. Returns `""` for null |
+| `coalesce([a], [b], 'default')` | First non-null, non-empty/whitespace argument. Variadic. `0` and `false` are kept (not skipped). Returns `null` if all args are null/empty |
+| `prop([obj], 'path.to.field')` | Drill into an object by a runtime-computed string path. Supports dotted paths and `?` optional suffix, same as `[obj.path]` but the path is a string argument |
 | `parseAddress([address])` | Parse address -> `{StreetNumber, StreetName}`. Handles US and EU formats |
 
 ### Date Functions

package/skills/cxtms-workflow-builder/ref-expressions-template.md

@@ -152,6 +152,7 @@ Used in `collection:` (foreach), `mapping:` (outputs), and variable resolution.
 | `list[0]` | Array index | `items[0]` |
 | `list[^1]` | Index from end (last item) | `items[^1]` |
 | `list[*]` | Flatten/wildcard (all items) | `containers[*].commodities` |
+| `list[*].dictKey` | Wildcard traversal into Dictionary/JObject keys | `items[*].customValues.chapter_en` |
 | `list[**]` | Recursive flatten (all depths) | `containerCommodities[**]` |
 | `list[-1]` | Depth filter (leaves only) | `tree[**][-1]` |
 | `list[condition]` | Filter by condition | `items[status=Active]` |
@@ -159,3 +160,7 @@ Used in `collection:` (foreach), `mapping:` (outputs), and variable resolution.
 | `list[*].{f1 f2}` | Field selector (projection) | `items[*].{name description}` |
 | `list[*].{alias:source}` | Field selector with alias | `items[*].{id:commodityId}` |
 | `list[*].{alias:_.parent}` | Field selector referencing parent | `items[*].{parentId:_.orderId}` |
+
+**Wildcard traversal into Dictionary/JObject**: After `[*]`, subsequent path segments drill into Dictionary keys and JObject properties on each item. Dictionary-like values are preserved intact (not flattened) so multi-hop paths work: `items[*].customValues.chapter_en` extracts the `chapter_en` key from each item's `customValues` dictionary. This also works with nested dictionaries (`items[*].meta.locale.name`) and JObject items from JSON payloads.
+
+**JArray primitive unwrapping**: When `GetPropertyValue` encounters a JArray where every element is a JValue (primitive), it automatically unwraps the array into a `List<object>` of plain .NET values. This ensures downstream iteration (e.g., `select()`, `zip()`, `foreach`) works with primitives rather than JValue wrappers.