@wix/agent-skills 1.32.0 → 1.33.1

package/skills/wix-manage/references/automations/activation-status.md

@@ -1,10 +1,8 @@
 ---
 name: "Automations Activation Status"
-description: "Read an automation’s current ACTIVE or INACTIVE status, and activate or deactivate it when the user asks."
+description: "Inspect or change active status with lock checks, revision handling and read-back, without requiring unrelated repairs before deactivation."
 ---
 
-> **Stage scope:** this stage covers only what [Build and Manage Wix Automations](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) lists; do not perform any workflow that needs a guide marked "not yet published". "Stage" and "not yet published" describe how this skill is being rolled out; never mention them to the user. Explain a limit in product terms: what can't be done through the API here and where the user can do it instead (for example, in the automations builder).
-
 # Activation status and lifecycle
 
 **What the public API can see.** An automation's live state is `configuration.status` —
@@ -12,8 +10,7 @@ description: "Read an automation’s current ACTIVE or INACTIVE status, and acti
 Status does not show whether past runs succeeded. There is no separate
 "published" flag and no public draft API:
 
-- **Status check** = Get Automation → read `configuration.status`. Report exactly that value, in a
-  short answer that starts with the automation's name and returned ID;
+- **Status check** = Query by name (if no ID) → Get the single matching ID → read that Get response’s `configuration.status`. Query is discovery only: never answer from its status projection, even if it includes one. Report the name, returned ID and status, explaining ACTIVE as eligible for new trigger events and INACTIVE as not eligible;
   never infer it from the name or from your own earlier writes. If several automations match the
   supplied name, list each one's returned ID and end with a direct question such as "Which one
   do you mean?"; don't report a single status. If no automation matches the supplied name, say
@@ -44,10 +41,10 @@ Status does not show whether past runs succeeded. There is no separate
 1. Get Automation with `fields: ["OVERRIDE_SCHEMA"]` → current `revision`, `origin`, `settings`.
    If `settings.disableStatusChange`
    or `settings.readonly` is true, stop and report the lock: the owning app doesn't allow it
-   (§4 of Automations Feasibility and Planning (not yet published)).
+   ([Automations Validation and Persistence — included update restrictions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence)).
 2. Already `ACTIVE` → report it and stop (idempotent; no write).
-3. Set only the candidate's status to `ACTIVE`, then apply the §4 checklist in [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) and full Validate — never activate
-   an automation that doesn't validate. Preserve existing supported configurations as the §4 checklist in [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) explains.
+3. Set only the candidate's status to `ACTIVE`, then apply the §4 checklist in [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) and full Validate — never activate
+   an automation that doesn't validate. Preserve existing supported configurations as the §4 checklist in [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) explains.
 4. Explicit activation instructions authorize this change; do not ask again. If the user only
    asked to build or inspect it, obtain authorization before making it eligible for real runs.
 5. Update Automation with the object exactly as fetched, `configuration.status: "ACTIVE"`, and
@@ -59,7 +56,7 @@ Status does not show whether past runs succeeded. There is no separate
 **Deactivate** (on explicit request): Get the complete object with override schemas; check
 `settings.disableStatusChange` and `settings.readonly`; already INACTIVE means no write.
 Otherwise change only `configuration.status` to `INACTIVE`, preserving origin, settings,
-revision, schemas and all nodes, then Update and read back the returned id. **Do not run the §4 checklist in [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) or
+revision, schemas and all nodes, then Update and read back the returned id. **Do not run the §4 checklist in [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) or
 Validate as a prerequisite**, and do not repair or remove unrelated invalid/legacy steps.
 An explicit request to turn it off is sufficient authorization. Deactivating prevents new
 triggered runs; it is not proof that every pending/running activation has stopped or will finish.

package/skills/wix-manage/references/automations/api-catalog.md

@@ -3,7 +3,7 @@ name: "Automations API Catalog"
 description: "Discover site-specific triggers and actions, authenticate public Automation API calls, and choose the API for validation, persistence or catalog lookups."
 ---
 
-> **Stage scope:** this stage covers only what [Build and Manage Wix Automations](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) lists; do not perform anything marked "Later stages only" or any workflow that needs a guide marked "not yet published". "Stage", "Later stages only" and "not yet published" describe how this skill is being rolled out; never mention them to the user. Explain a limit in product terms: what can't be done through the API here and where the user can do it instead (for example, in the automations builder).
+> **Stage scope:** this stage covers only what [Build and Manage Wix Automations](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) lists; do not perform anything marked "Later stages only", and follow the instruction attached to each guide marked "not yet published". "Stage", "Later stages only" and "not yet published" describe how this skill is being rolled out; never mention them to the user. Explain a limit in product terms: what can't be done through the API here and where the user can do it instead (for example, in the automations builder).
 
 # API Catalog — the public Wix Automations APIs
 
@@ -16,19 +16,19 @@ docs URL to get raw markdown. When a field name here and the docs disagree, the
 
 - Catalogs: Resolve Triggers / Resolve Actions. Oracle: **Validate Automation** — Create and
   Update do **not** validate.
-- Persist: Create `INACTIVE` → Get read-back; activate only when asked.
-  Procedures (create, activate, read-back
-  — builder drafts are invisible publicly): [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) §3.
-- **Later stages only — not in stage 2:** **Test Automation runs actions for real** — only with explicit user authorization.
+- Persist: Create `INACTIVE` → Get read-back; activate only when asked. Updates need the current
+  `revision` and are **live** on an active automation. Procedures (create, update, activate, read-back
+  — builder drafts are invisible publicly): [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §3.
+- **Test Automation runs actions for real** — only with explicit user authorization.
 - Resolve responses are large: page small, filter by exact keys, never paste a raw catalog.
 
 ## 1. Authentication and transport
 
 - **Permission scope**: **Set Up Automations** (`SCOPE.CRM.SETUP-AUTOMATIONS`) for every
-  Automations method below. Generate Action Input Mapping and Get / Set Email Content (Automation Email Action API) need **Manage
-  Email Marketing** (`SCOPE.DC-PROMOTE.EMAIL-MARKETING`) — a 403 there means that scope is missing.
+  Automations method below. Email steps are added in the automations builder, so no **Manage
+  Email Marketing** (`SCOPE.DC-PROMOTE.EMAIL-MARKETING`) scope is needed here.
   Entity lookups in other verticals need that vertical's read scope
-  (Automations Entity and Provider Configuration (not yet published)).
+  (Automations Entity and Provider Configuration (topic guide not yet published; consult the [Automations API reference](https://dev.wix.com/docs/api-reference/business-management/automations))).
 - **Token**: `Authorization: <token>` header — an OAuth app access token (`client_credentials` via
   Create Access Token) or an account API key the site owner generated with the needed scopes.
 - **Site context**: with an **API key**, send `wix-site-id: <metaSiteId>` on every call (all calls
@@ -44,17 +44,15 @@ docs URL to get raw markdown. When a field name here and the docs disagree, the
   confirmed. If anything points at another site, stop.
 - **Errors**: 401 = token expired/invalid (refresh, don't retry blindly). 403 = missing scope, app
   not installed, or — on Create/Update of an automation that validated — a step the public API
-  can't create (e.g. the code-variable step, §4 of Automations Delays Variables and Branches (not yet published)). A timeout or 5xx is
+  can't create (e.g. the code-variable step, [Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §4). A timeout or 5xx is
   **unknown**, not a verdict — retry read-only calls (Get, Query, Resolve, Validate) a bounded
   number of times. Never blindly retry Create or Update: Query or Get first to see whether the
-  write landed ([Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) §3, Reporting rules).
+  write landed ([Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §3, Reporting rules).
 
 ## 2. Automations V2 (`automationsV2`) — base `/automations-service/v2/automations`
 
-> Stage 2 supports Query, Get, Validate, inactive Create, and Update only to activate or deactivate ([Automations Activation Status](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-activation-status)). Configuration updates, Delete and Test Automation below are future-stage reference material; do not call them in this stage.
-
-| Purpose  | REST                                                        | SDK                                       |
-| -------- | ----------------------------------------------------------- | ----------------------------------------- |
+| Purpose  | REST                                                                               | SDK                                       |
+| -------- | ---------------------------------------------------------------------------------- | ----------------------------------------- |
 | Validate | `POST https://www.wixapis.com/automations-service/v2/automations/validate`         | `validateAutomation(automation, options)` |
 | Create   | `POST https://www.wixapis.com/automations-service/v2/automations`                  | `createAutomation(automation)`            |
 | Get      | `GET https://www.wixapis.com/automations-service/v2/automations/{automationId}`    | `getAutomation(automationId)`             |
@@ -65,7 +63,7 @@ docs URL to get raw markdown. When a field name here and the docs disagree, the
 - **Validate** (unsaved or saved): `{automation, validationSettings?{actionIds[],
 skipProviderValidations}}` → `{status: VALID|VALID_WITH_WARNINGS|INVALID,
 triggerValidationErrors[], actionValidationErrors[]}`. The main oracle; send the full object.
-  Reading errors: [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) §2.
+  Reading errors: [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §2.
 - **Create**: `{automation}` with `name`, `origin: "USER"`, `configuration{status, trigger{appId,
 triggerKey}, rootActionIds, actions}` → created `automation` (has `id`, `revision`). Does NOT
   validate. Always `status: "INACTIVE"`; don't send `settings`.
@@ -74,8 +72,16 @@ triggerKey}, rootActionIds, actions}` → created `automation` (has `id`, `revis
   request them: `fields: ["OVERRIDE_SCHEMA"]` (REST `?fields=OVERRIDE_SCHEMA`). Without it their
   absence is not data loss (Create's response omits them too).
   Request overrides before complete-object updates and status changes too, not just creation read-back.
-- **Update**: in this stage, only to change `configuration.status` (activate / deactivate) as [Automations Activation Status](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-activation-status) describes. Send `{automation}` exactly as fetched with `fields: ["OVERRIDE_SCHEMA"]` — `id`, current `revision`, `name`, `configuration`, plus `origin` and `settings` — with only the status changed. Without `origin` and `settings` it fails `INVALID_ORIGIN_TYPE`; a stale `revision` is rejected. Capture the returned id: a preinstalled automation's site override can change it. Configuration updates are published in stage 3.
-- **Later stages only — not in stage 2:** **Delete** — published in stage 3.
+- **Update**: `{automation}` incl. `id` and current `revision` → updated `automation` (revision
+  +1). Does NOT validate. Send the complete merged `name` + `configuration`, **plus `origin` and
+  `settings` exactly as fetched** — an Update without them fails `INVALID_ORIGIN_TYPE`. A
+  `fieldMask` (if your client exposes one) only selects what changes — set it to
+  `configuration,name` (what the builder sends); it doesn't exempt you from sending `origin` /
+  `settings`. A stale `revision` is rejected. Changes are LIVE when `status` is `ACTIVE`. A success
+  response and a revision bump do **not** prove the change landed — merge, conflict handling and
+  read-back comparison: [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §3.
+  Capture the returned id: creating a site override of a preinstalled automation can change it.
+- **Delete**: → `{}`. Irreversible; only on explicit user request.
 - **Query**: `{query{filter, sort, cursorPaging{limit ≤ 500, cursor}}}` → `automations[]`,
   `pagingMetadata.cursors.next`. Returns only automations of apps installed on the site (incl.
   overridden preinstalled ones), and never unpublished builder drafts. Full objects are large —
@@ -85,12 +91,12 @@ triggerKey}, rootActionIds, actions}` → created `automation` (has `id`, `revis
 Automation object fields and limits (`name` ≤ 100 for the builder, `description` ≤ 2000,
 `origin`, `settings`, `configuration`): [Automations Graph and Data Model](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-graph-and-data-model) §1.
 Create/Update accept `configuration.trigger.automationConfigMapping` for scheduled/custom/webhook
-configuration even where the docs omit it; use [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) / Automations Schemas and Scheduling (not yet published).
+configuration even where the docs omit it; use [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) / [Automations Schemas and Scheduling](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-schemas-and-scheduling).
 
 ## 3. Trigger Catalog (`triggerCatalog`)
 
-| Purpose                | REST                                              | SDK                                             |
-| ---------------------- | ------------------------------------------------- | ----------------------------------------------- |
+| Purpose                | REST                                                                     | SDK                                             |
+| ---------------------- | ------------------------------------------------------------------------ | ----------------------------------------------- |
 | Triggers on this site  | `POST https://www.wixapis.com/v1/triggers/resolve`                       | `resolveTriggers(options)`                      |
 | Global catalog         | `POST https://www.wixapis.com/v1/triggers/query`                         | `queryTriggers(query)`                          |
 | One trigger            | `GET https://www.wixapis.com/v1/triggers/apps/{appId}/keys/{triggerKey}` | `getTriggerByAppIdAndKey(identifiers, options)` |
@@ -117,8 +123,8 @@ payload schema ([Automations Trigger Configuration](https://dev.wix.com/docs/api
 
 ## 4. Action Catalog (`actionCatalog`)
 
-| Purpose                    | REST                                                   | SDK                                            |
-| -------------------------- | ------------------------------------------------------ | ---------------------------------------------- |
+| Purpose                    | REST                                                                          | SDK                                            |
+| -------------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------- |
 | Actions on this site       | `POST https://www.wixapis.com/v1/actions/resolve`                             | `resolveActions(options)`                      |
 | Global catalog             | `POST https://www.wixapis.com/v1/actions/query` (and `/query-latest`)         | `queryActions(query)`, `queryLatestActions`    |
 | Version active on the site | `GET https://www.wixapis.com/v1/actions/apps/{appId}/keys/{actionKey}`        | `getRuntimeAction(identifiers)`                |
@@ -138,13 +144,12 @@ payload schema ([Automations Trigger Configuration](https://dev.wix.com/docs/api
 - **Dynamic output**: `{appId, actionKey, inputMapping}` → `outputSchema`; bulk
   (`bulkGetActionDynamicOutputSchemas`, POST `/v1/actions/bulk/dynamic-output-schema`, ≤ 20 items) →
   `results[]{itemMetadata{success, error}, outputSchema}`. Only after that action's mapping is
-  final. Safe for any action you place upstream of a step that reads its output (no public flag
-  says which are dynamic); an error means "no dynamic output" — keep the static `outputSchema`.
+  final. For `wix_automations-llm_call` fields defined by your output configuration, declare an override directly ([Automations Schemas and Scheduling](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-schemas-and-scheduling) §3); do not call this SPI to discover fields you chose yourself. For other upstream actions whose configured output is needed, this is a read-only discovery call (no public flag says which are dynamic); an error does not establish additional fields — keep the static `outputSchema`.
   Merge into the static schema. A failed bulk item = unknown schema, not empty.
 - **Generate Input Mapping From Intent** (`POST https://www.wixapis.com/v1/actions/generate-input-mapping-from-intent`)
   is AI-backed — don't call it. For actions you can't map from their schema, tell the user they can't be configured through the API here and can be set up in the automations builder.
-- **Later stages only — email is outside stage 2:** **Email content of an existing Send an email step** — Get / Set Email Content; procedure in Automations Email Actions (not yet published).
-- **Later stages only — email is outside stage 2:** **New Send an email step** — Generate Action Input Mapping; procedure in Automations Email Actions (not yet published).
+- **Later stages only — email is outside stage 3:** **Email content of an existing Send an email step** — Get / Set Email Content; procedure in Automations Email Actions (not yet published; email configuration is outside stage 3).
+- **Later stages only — email is outside stage 3:** **New Send an email step** — Generate Action Input Mapping; procedure in Automations Email Actions (not yet published; email configuration is outside stage 3).
 
 Action objects: `appId`, `actionKey`, `displayName`, `description`, `inputSchema`, `outputSchema`,
 `interfaceConfiguration{type: GENERIC\|WIDGET_COMPONENT, genericOptions.uiSchema}`,
@@ -153,8 +158,12 @@ Action objects: `appId`, `actionKey`, `displayName`, `description`, `inputSchema
 
 ## 5. Activations (`activations`)
 
-- **Later stages only — not in stage 2:** **Test Automation** — runs every action for real; published in stage 3.
-- **Later stages only — not in stage 2:** **Run Automation / Report Event / Rerun Activation** — for the app that owns a trigger; never
+- **Test Automation** — `POST https://www.wixapis.com/automations/v1/events/test-automation`,
+  `testAutomation(identifierType, options)`: `{identifierType: "AUTOMATION",
+automationIdentifier{automationId}, payload}` → `activationId`. **Runs every action for real**
+  (skips delays, works on INACTIVE) — explicit user authorization only; payload, consent and
+  reporting: [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §5.
+- **Run Automation / Report Event / Rerun Activation** — for the app that owns a trigger; never
   use them to build or "test".
 
 ## 6. Catalog discovery without flooding your context
@@ -188,13 +197,13 @@ Discovery hints:
 - Search by concept with a keyword ladder ("chat" → "message"). Common aliases: send a chat
   message to the contact = `send-message` (not `inbox-send-message`); a note about a contact in
   the site owner's Inbox, nothing sent to the contact = `inbox-send-message` ("Show in Inbox");
-  email to anyone, incl. the site
+  email (added by the user in the automations builder here) to anyone, incl. the site
   owner = `triggered-emails` (never the deprecated `send-mail` / "Get an email"); task =
   `createTask`; labels = `addLabelsToContact` / `remove_labels_to_contact`; create a contact =
   `contacts-create_contact` (for triggers whose payload has no contact, e.g. webhooks).
 - Near-duplicates exist (`booking_canceled` vs `bookings_canceled`; new Wix Forms app vs legacy
   "Form submitted"). Compare payload schemas and filters; prefer the one whose entities you can
-  actually find on the site (Automations Entity and Provider Configuration (not yet published)).
+  actually find on the site (Automations Entity and Provider Configuration (topic guide not yet published; consult the [Automations API reference](https://dev.wix.com/docs/api-reference/business-management/automations))).
 - Enum-like fields often list legal values only in the field `description` (e.g. paymentStatus
   NOT_PAID / PAID). Read descriptions before mapping user words; never invent enum values.
 
@@ -205,9 +214,16 @@ variables + identity enrichment. Recipe and fetch order: [Automations Graph and
 
 ## 8. Selector options and APIs with limitations
 
-> **Later stages only:** not available in stage 2; this section is published in stage 3.
+**Entity ids** (forms, labels, services, pipeline stages…): resolve them with the owning vertical's public API, following that vertical's API reference, or ask the user for the exact entity. Never save a display name, invent an id or guess an endpoint.
+
+**Not public or not available through the general Automations API:**
 
-**In this stage:** a "draft" is an automation created `INACTIVE` (builder drafts are invisible to the public API). To validate a saved automation, Get it and Validate the returned object. Check expressions locally, then with Validate Automation.
+- **Draft automations** → create `INACTIVE`; the user activates. Builder drafts are invisible.
+- **Site-action generation** → §3 of Automations Entity and Provider Configuration (topic guide not yet published; consult the [Automations API reference](https://dev.wix.com/docs/api-reference/business-management/automations)).
+- **Send an email steps** → not configurable through the API here; the user adds them in the automations builder.
+- **Expression parsing/evaluation, code runner** → local checks ([Automations Mapping Expressions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-mapping-expressions),
+  [Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions)), then Validate Automation.
+- **Validate by id** → Get Automation, then Validate the returned object.
 
 ## Related API references
 

package/skills/wix-manage/references/automations/automation-model.md

@@ -3,8 +3,6 @@ name: "Automations Graph and Data Model"
 description: "Assemble builder-editable automation graphs with valid node relationships, namespaces and ancestor data access."
 ---
 
-> **Stage scope:** this stage covers only what [Build and Manage Wix Automations](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) lists; do not perform anything marked "Later stages only" or any workflow that needs a guide marked "not yet published". "Stage", "Later stages only" and "not yet published" describe how this skill is being rolled out; never mention them to the user. Explain a limit in product terms: what can't be done through the API here and where the user can do it instead (for example, in the automations builder).
-
 # Automation Model — Object, Graph Rules, Payload Scope
 
 **TL;DR**
@@ -19,14 +17,12 @@ description: "Assemble builder-editable automation graphs with valid node relati
 
 ## 1. The Automation object (public API)
 
-> In this stage you create only APP_DEFINED steps. The other step types below are documented so you can read and preserve existing automations, not to author them here.
-
 | Field                         | Rules                                                                                                                                            |
 | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `id`, `revision`              | Read-only. `revision` MUST be sent back on Update Automation (§6).                                                                               |
 | `name`                        | Required, 1–100 chars (API allows 500; the builder holds 100); the business outcome ("Send welcome email to new subscribers").                   |
 | `description`                 | Optional, ≤2000 chars.                                                                                                                           |
-| `origin`                      | Required on create, immutable. `USER` for anything you create. `APPLICATION`/`PREINSTALLED` carry update locks (§4 of Automations Feasibility and Planning (not yet published)). |
+| `origin`                      | Required on create, immutable. `USER` for anything you create. `APPLICATION`/`PREINSTALLED` carry update locks ([Automations Validation and Persistence — included update restrictions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence)). |
 | `settings`                    | Locks for APPLICATION/PREINSTALLED (`readonly`, `actionSettings`, …). Never set it on create; on Update send it back exactly as fetched.         |
 | `configuration.status`        | Required, `ACTIVE` \| `INACTIVE`. Create `INACTIVE`; activate only on request.                                                                   |
 | `configuration.trigger`       | `{appId, triggerKey, filters[], scheduledEventOffset?, overrideSchema?, automationConfigMapping?}` — [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration).                                |
@@ -36,9 +32,9 @@ description: "Assemble builder-editable automation graphs with valid node relati
 Action (common fields):
 
 - `id` — uuid v4, equal to its map key.
-- `type` — `APP_DEFINED`, `CONDITION`, `CODE_CONDITION`, `DELAY`, `RATE_LIMIT`, `SET_VARIABLES`, `SPLIT` (the last two are not yet in the public API docs, but the builder supports them — Automations Delays Variables and Branches (not yet published)). NEVER `UNKNOWN_ACTION_TYPE`, NEVER `MERGE`.
+- `type` — `APP_DEFINED`, `CONDITION`, `CODE_CONDITION`, `DELAY`, `RATE_LIMIT`, `SET_VARIABLES`, `SPLIT` (the last two are not yet in the public API docs, but the builder supports them — [Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches)). NEVER `UNKNOWN_ACTION_TYPE`, NEVER `MERGE`.
 - `namespace` — 1–100 chars, unique except the shared `setVariable` namespace (§3). Outputs of this step appear under it.
-- `displayName` — optional but always set it: 1–60 chars, sentence case, purpose-specific (§7 of Automations Delays Variables and Branches (not yet published)). Absent → the canvas shows the catalog name.
+- `displayName` — optional but always set it: 1–60 chars, sentence case, purpose-specific ([Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §7). Absent → the canvas shows the catalog name.
 - `skipActionExpression` — absent (runs) or exactly `"{{true}}"` (skipped), the only value the builder writes. A skipped step adds NO outputs downstream (§4).
 - exactly one `*Info` matching `type`: `appDefinedInfo`, `conditionInfo`, `codeConditionInfo`, `delayInfo`, `rateLimitInfo`, `setVariablesInfo`, `splitInfo`.
 
@@ -50,7 +46,7 @@ Action (common fields):
 4. **No orphans.** An action unreachable from the root is deleted by the builder on the next save.
 5. **No cycles.** Forward only.
 6. **Empty array = the path ends** there. Use `[]`, never omit the field.
-7. **Parallel fan-out only via SPLIT** (§5 of Automations Delays Variables and Branches (not yet published)). Never two root ids, never two ids in one field.
+7. **Parallel fan-out only via SPLIT** ([Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §5). Never two root ids, never two ids in one field.
 8. **No MERGE.** The API has a `MERGE` type and `conditionInfo.mergeActionId`, but the canvas cannot draw them (MERGE nodes never finish loading). Never create either; when you read an automation that has them, preserve them untouched and don't add more.
 
 ### Builder rendering MUSTs (graph level)
@@ -59,20 +55,31 @@ Action (common fields):
 - MUST: `actions[k].id === k` for every entry.
 - MUST: ids are unique across ALL of: action ids, SPLIT path ids, the `triggerKey` string (it is the trigger node's id), and the builder's synthetic ids `<id>true`, `<id>false`, `<id>-end`, `<id>true-end`. Duplicates crash the layout. Generate every id as a fresh uuid v4 in code; never reuse ids from these references.
 - MUST: each action carries ONLY its own type's `*Info`. The canvas ignores `type` when finding children and takes the first present of `appDefinedInfo → delayInfo → rateLimitInfo → setVariablesInfo → condition` — even an empty leftover `appDefinedInfo: {postActionIds: []}` on a CONDITION hides both branches.
-- MUST: at most one RATE_LIMIT, and only as the root (§2 of Automations Delays Variables and Branches (not yet published)). A non-root RATE_LIMIT node spins forever.
+- MUST: at most one RATE_LIMIT, and only as the root ([Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §2). A non-root RATE_LIMIT node spins forever.
 - MUST: APP_DEFINED `appId` + `actionKey` match the site's action catalog, else the node shows "Action not available".
 
 ### Designing within the tree
 
-> **Later stages only:** not available in stage 2; this section is published in stage 3.
+- **Several independent actions** ("send an email and post a chat message") → chain them A → B → C, most time-sensitive first. Use SPLIT only when the user wants them to run at the same time. Never claim parallel execution is impossible.
+- **Branch, then continue** ("if A, also do A2; after 6h send Y to everyone") → DUPLICATE every later stage into BOTH branches with fresh ids and namespaces (variable steps keep `setVariable`, with fresh variable keys and updated downstream references). A **Send an email** in a duplicated stage is added by the user in each branch — never copy an existing step's `messageId` / `templateId` / `uniqueRuleId`: both steps would share one email, so editing one changes both and deleting one can delete the shared email. Never point both branches at the same action. Never use a "gate" where the TRUE branch does its side-action and stops while the timeline should continue.
+
+```text
+initial > Check A?
+  true  > doA > Delay(A) > finalStep(A)
+  false >       Delay(B) > finalStep(B)     // Delay/finalStep duplicated, never shared
+```
 
-**In this stage:** put independent actions ("create a task and add a label") in one linear chain A → B → C, most time-sensitive first.
+- **Delay arithmetic when duplicating**: branches that share an absolute deadline anchored at the trigger must each sum to it. "Chat now; if price>100 wait 2h then email; at 24h remind everyone" ⇒ true: 2h delay > email > **22h** delay > reminder; false: 24h delay > reminder. Compute residuals explicitly — copying 24h into both branches double-delays the true branch.
+- **Repeated logic** after different conditions = separate actions with identical configuration but new ids and namespaces.
 
 ### Only model what the user asked for
 
-> **Later stages only:** not available in stage 2; this section is published in stage 3.
+Add a condition/delay ONLY for explicit flow control ("if X, do a DIFFERENT step Y", "after 2 days"). Audience/copy framing is CONTENT, not a condition:
 
-**In this stage:** add only the steps the user asked for. Audience or copy framing ("a VIP follow-up for high-value customers") is content inside one action, not a condition.
+- "a VIP follow-up email for high-value customers" → one email, VIP copy, no condition.
+- "if order > $200 mention priority packing" → email copy detail, no branch.
+- "if order > $200 ALSO create a task" → real flow control → condition.
+  Test: does a DIFFERENT step run based on the check? Yes → condition; no → one plain action.
 
 ## 3. Namespaces
 
@@ -83,7 +90,7 @@ Use the builder's own convention (it derives new indexes from the trailing numbe
 | APP_DEFINED                                      | `<actionKey>-<N>` (e.g. `triggered-emails-3`)            |
 | CONDITION and CODE_CONDITION                     | `CONDITION-<N>`                                          |
 | DELAY / SPLIT / RATE_LIMIT                       | `<TYPE>-<N>` (e.g. `DELAY-2`, `SPLIT-5`, `RATE_LIMIT-1`) |
-| SET_VARIABLES (and existing code-variable steps) | always the literal `setVariable` (§4 of Automations Delays Variables and Branches (not yet published)) |
+| SET_VARIABLES (and existing code-variable steps) | always the literal `setVariable` ([Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §4) |
 
 `N` = 1 + the largest number after the last `-` among **all** the automation's namespaces (one counter shared across every step type — e.g. `DELAY-1` then `createTask-2`). A namespace with no trailing number (`setVariable`) doesn't count: if it is the only one, the next `N` is 1. A CODE_CONDITION keeps `CONDITION-<N>`. The builder never rewrites an existing namespace — on update keep every existing one as is. Variable and existing code-variable steps intentionally share `setVariable`; their distinct property keys are merged. For other output-producing actions, never reuse a namespace — the later output overwrites the earlier one.
 
@@ -91,16 +98,16 @@ Use the builder's own convention (it derives new indexes from the trailing numbe
 
 This section owns the rule. Build one JSON Schema object per node, in code, from the root down its own branch, from public schema APIs (calls: [Automations API Catalog](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-api-catalog) §3–§4).
 
-1. **Trigger payload** — the trigger's `payloadDataSchema` (custom/webhook triggers: `trigger.overrideSchema` instead, §3 of Automations Schemas and Scheduling (not yet published)). If the trigger implements dynamic schema, call Get Trigger Dynamic Schema with the SELECTED (saved) filter options and MERGE its `properties` over the static ones ([Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) §5); before filters are chosen, dynamic fields are UNKNOWN, not absent. Trigger fields are un-prefixed: `var("orderId")`.
+1. **Trigger payload** — the trigger's `payloadDataSchema` (custom/webhook triggers: `trigger.overrideSchema` instead, [Automations Schemas and Scheduling](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-schemas-and-scheduling) §3). If the trigger implements dynamic schema, call Get Trigger Dynamic Schema with the SELECTED (saved) filter options and MERGE its `properties` over the static ones ([Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) §5); before filters are chosen, dynamic fields are UNKNOWN, not absent. Trigger fields are un-prefixed: `var("orderId")`.
 2. **Identity enrichment** — for every trigger-payload field (any object depth, not inside arrays) annotated `identityType: "contact"` or `"member"`, a root-level object is added, keyed by that field's `namespace` annotation when it has one, else its (deprecated) `name` annotation, else the identity type (`contact` / `member`). Shape: Get Identities Schema (`identitiesSchema.properties.contact` / `.member`). Both stay valid: `var("contactId")` and `var("contact.name.first")`; also e.g. `var("contact.email")`, `var("member.profile.nickname")`. A field annotated `name: "post_author_member"` (some Blog / File Share triggers) is enriched as `var("post_author_member.profile.nickname")` — two member ids on one trigger give two objects; use the key the field declares (`member.*` does not exist there). Other identity types (e.g. `visitor`) add no object; webhook/custom triggers (override schema) get none. The builder does not enrich identity fields of action outputs — don't read `contact.*` that only an action output would provide.
-3. **Ancestor action outputs** — for each non-skipped APP_DEFINED step ABOVE this node on its own path, under `properties[<namespace>]`: catalog `outputSchema`, with `overrideOutputSchema.properties` merged over it, and — when the action implements dynamic output — Get Action Dynamic Output Schema (called with that step's final `inputMapping`) merged over that: `var("triggered-emails-3.messageId")`.
-4. **Variables** — titled outputs (`outputSchema`) of non-skipped ancestor SET_VARIABLES / code-variable (`namespace: "setVariable"`) steps, merged under `setVariable`: `var("setVariable.<key>")` (§4 of Automations Delays Variables and Branches (not yet published)).
+3. **Ancestor action outputs** — for each non-skipped APP_DEFINED step ABOVE this node on its own path, under `properties[<namespace>]`: catalog `outputSchema`, with `overrideOutputSchema.properties` merged over it, and — for provider-controlled dynamic outputs — Get Action Dynamic Output Schema (called with that step's final `inputMapping`) merged over that. For `wix_automations-llm_call`, declare user-defined result fields directly in `overrideOutputSchema`; do not call dynamic output discovery for those fields ([Automations Action Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-action-configuration) §4). Example ancestor path: `var("triggered-emails-3.messageId")`.
+4. **Variables** — titled outputs (`outputSchema`) of non-skipped ancestor SET_VARIABLES / code-variable (`namespace: "setVariable"`) steps, merged under `setVariable`: `var("setVariable.<key>")` ([Automations Delays Variables and Branches](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-delays-variables-and-branches) §4).
 
 Scope rules:
 
 - Only ANCESTORS. A node never sees later steps or a sibling branch (true path can't read the false path; SPLIT paths can't read each other).
 - A skipped step (`skipActionExpression: "{{true}}"`) contributes nothing; never skip a step whose outputs a later step reads.
-- Resolution order — finalize an upstream node before computing a descendant's schema: trigger filters → the trigger's dynamic schema → for each step top-down: its dynamic input schema (if any) → its final `inputMapping` → its dynamic output schema (if any) → add it to its children's schema.
+- Resolution order — finalize an upstream node before computing a descendant's schema: trigger filters → the trigger's dynamic schema → for each step top-down: its dynamic input schema (if any) → its final `inputMapping` → its provider-controlled dynamic output schema (if any; user-defined `wix_automations-llm_call` fields come from `overrideOutputSchema` without a dynamic-output call) → add it to its children's schema.
 - Every `var()` path MUST exist in this node's aggregated schema with a compatible type — never reason from a raw trigger or action schema alone, and never invent a field. Copy keys from the schema (titles/labels are not keys); arrays cannot be traversed by path ([Automations Mapping Expressions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-mapping-expressions) §5).
 - Preferred-language messages: map `var("contact.locale")` into the email's dynamic content; no separate "language" field is needed.
 
@@ -171,17 +178,85 @@ every `var()` path is in that node's aggregated schema; status is INACTIVE.
 
 ### 5.2 Branching (trigger → condition → two branches)
 
-> **Later stages only:** not available in stage 2; this section is published in stage 3.
+All ids are placeholders; generate real uuid v4s. Resolve `appId`/`triggerKey`/`actionKey`/input keys from the catalogs.
+
+```json
+{
+  "automation": {
+    "name": "Thank big spenders, follow up with others",
+    "origin": "USER",
+    "configuration": {
+      "status": "INACTIVE",
+      "trigger": {
+        "appId": "<trigger-app-id>",
+        "triggerKey": "<trigger-key>",
+        "filters": []
+      },
+      "rootActionIds": ["<uuid-1>"],
+      "actions": {
+        "<uuid-1>": {
+          "id": "<uuid-1>",
+          "type": "CONDITION",
+          "namespace": "CONDITION-1",
+          "displayName": "Check if order is over 100",
+          "conditionInfo": {
+            "orExpressionGroups": [
+              {
+                "operator": "AND",
+                "booleanExpressions": [
+                  "{{numberGt(var(\"totals.total\");100)}}"
+                ]
+              }
+            ],
+            "truePostActionIds": ["<uuid-2>"],
+            "falsePostActionIds": ["<uuid-3>"]
+          }
+        },
+        "<uuid-2>": {
+          "id": "<uuid-2>",
+          "type": "APP_DEFINED",
+          "namespace": "<action-key-a>-2",
+          "displayName": "Send thank-you email",
+          "appDefinedInfo": {
+            "appId": "<action-app-id-a>",
+            "actionKey": "<action-key-a>",
+            "inputMapping": {
+              "<input-key>": "{{var(\"contact.name.first\")}}"
+            },
+            "postActionIds": []
+          }
+        },
+        "<uuid-3>": {
+          "id": "<uuid-3>",
+          "type": "APP_DEFINED",
+          "namespace": "<action-key-b>-3",
+          "displayName": "Create follow-up task",
+          "appDefinedInfo": {
+            "appId": "<action-app-id-b>",
+            "actionKey": "<action-key-b>",
+            "inputMapping": {
+              "<input-key>": "Follow up on order {{var(\"number\")}}"
+            },
+            "postActionIds": []
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+Why it's valid: one parentless root; ≤1 id per connection; one parent each; ids = keys, unique; own `*Info` only; namespaces per §3; one renderable condition group ([Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions)); inputMapping keys from the input schema ([Automations Action Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-action-configuration)); every `var()` path in that node's aggregated schema.
 
 ## 6. Persistence & update lifecycle
 
-Create `INACTIVE` (your "draft"); activate only on request. Create procedure and read-back: [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) §3; calls: [Automations API Catalog](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-api-catalog) §2.
+Create `INACTIVE` (your "draft"); activate only on request. Create procedure and read-back: [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §3; calls: [Automations API Catalog](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-api-catalog) §2.
 
-**Later stages only — not in stage 2:** **Update:** Get → change only what was asked, keep every other node byte-for-byte → Validate → Update with the full merged object + `revision`, `origin` and `settings` as fetched; on an ACTIVE automation the change is live — confirm first. Locks: §4 of Automations Feasibility and Planning (not yet published).
+**Update:** Get → change only what was asked, keep every other node byte-for-byte → Validate → Update with the full merged object + `revision`, `origin` and `settings` as fetched; on an ACTIVE automation the change is live — confirm first. Locks: [Automations Validation and Persistence — included update restrictions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence).
 
 ## 7. Pre-validate self-check (do in code)
 
-Script the graph/id/namespace/`var()` items of [Build and Manage Wix Automations — included validation procedure](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) §4 (items 1–4 and 11 — the rules of §2–§4 above: one parentless root, RATE_LIMIT only as that root, ≤1 id per connection, one parent each, no cycles/orphans/MERGE/`mergeActionId`/`UNKNOWN_ACTION_TYPE`, keys = ids, globally unique uuid v4s incl. SPLIT path ids, `triggerKey` and `<id>true/false/-end`, own `*Info` only, §3 namespaces unique except `setVariable`, every `var()` in THAT node's aggregated schema). Also check that only user-requested conditions/delays exist; then Validate Automation must return no trigger or action errors.
+Script the graph/id/namespace/`var()` items of [Automations Validation and Persistence](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-validation-and-persistence) §4 (items 1–4 and 11 — the rules of §2–§4 above: one parentless root, RATE_LIMIT only as that root, ≤1 id per connection, one parent each, no cycles/orphans/MERGE/`mergeActionId`/`UNKNOWN_ACTION_TYPE`, keys = ids, globally unique uuid v4s incl. SPLIT path ids, `triggerKey` and `<id>true/false/-end`, own `*Info` only, §3 namespaces unique except `setVariable`, every `var()` in THAT node's aggregated schema). Also check that only user-requested conditions/delays exist; then Validate Automation must return no trigger or action errors.
 
 ## 8. Anti-patterns (all wrong)
 

package/skills/wix-manage/references/automations/bracket-expressions.md

@@ -3,14 +3,12 @@ name: "Automations Mapping Expressions"
 description: "Write builder-compatible automation mapping expressions, literals and data references."
 ---
 
-> **Stage scope:** this stage covers only what [Build and Manage Wix Automations](https://dev.wix.com/docs/api-reference/business-management/automations/skills/build-and-manage-wix-automations) lists; do not perform any workflow that needs a guide marked "not yet published". "Stage" and "not yet published" describe how this skill is being rolled out; never mention them to the user. Explain a limit in product terms: what can't be done through the API here and where the user can do it instead (for example, in the automations builder).
-
 # Bracket Expressions (Formulas) — `{{…}}`
 
 **TL;DR**
 
 - `{{expression}}`; fields via `var("dotted.path")` (double quotes, one argument); arguments separated by `;`; string literals in double quotes and URI-encoded.
-- In formula fields (action inputs, set-variable values, delay due dates) use ONLY the builder function list in §2. Conditions and trigger filters have their own, stricter vocabularies — Automations Conditions (not yet published), [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) §4.2.
+- In formula fields (action inputs, set-variable values, delay due dates) use ONLY the builder function list in §2. Conditions and trigger filters have their own, stricter vocabularies — [Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions), [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) §4.2.
 - The builder type-checks every argument and the arity (§2): `eq`/`gt`/`gte`/`lt`/`lte` take NUMBERS only (strings → `stringEq`, dates → `date*`); `if()`'s first argument is boolean. There are no operators.
 - No array element access in any form. Project with `arrayMap(array;"path")`, aggregate with `array*`. A single-value field can never be filled from an array — ask the user which item.
 - Only data from the step's aggregated schema (trigger + ancestors) is in scope ([Automations Graph and Data Model](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-graph-and-data-model) §4).
@@ -46,6 +44,8 @@ Prefix rules: trigger fields have no prefix; action outputs `"<namespace>.<field
 - **Format**: `toString(v)` → string · `toNumber(v)` → number
 - **Logic**: `if(bool;then;else)` · `and(b;b;…)` · `or(b;b;…)` · `not(b)` · `isEmpty(v)` (any value, incl. arrays) → boolean (`if` → its branches' value)
 
+`isEmpty(v)` is true for a missing value, `null`, `""`, `[]` or `{}`; it is false for a non-empty string, whitespace-only string, `0` or `false`. It alone covers missing/null/empty-string fallbacks; adding `isEmptyString(v)` with `or` is valid but redundant.
+
 Arity (write exactly these counts; the builder flags missing and extra arguments for fixed-arity functions): `var`, `not`, `toString`, `toNumber`, `upper`, `lower`, `stringLen`, `abs`, `isEmptyString`, `isEmpty`, every `array*` aggregate = 1 · comparisons, `round`, `subtract`/`divide`/`mod`, `arrayMap` = 2 · `if`, `substring` = 3 (always pass the length) · `addToDate`/`subtractFromDate` = 4 · `now` = 0 · `and`/`or`/`concat`/`sum`/`multiply` ≥ 2 · `min`/`max`/`average`/`median` ≥ 1.
 
 Argument types the builder enforces (convert with `toString()`/`toNumber()`):
@@ -59,12 +59,12 @@ Argument types the builder enforces (convert with `toString()`/`toNumber()`):
 | date-time (`hour`, `minute`, `dateTimeEq/Before/After`)                       | a var with `format: date-time`, a function, or an ISO date-time literal — a `format: date` var or plain-string var is rejected                                    |
 | array (`array*` functions, `isEmpty`)                                         | array var or `arrayMap(…)`; no other function takes an array argument                                                                                             |
 
-An encoded date-time literal (`"2026-12-25T10%3A00%3A00Z"`) is not recognized as a date in a formula field — pass a `"YYYY-MM-DD"` literal or a function, or make the whole field a plain ISO value (§4). This exception is for formula fields only: in a CONDITION the panel itself writes date-time literals encoded and reads both forms (§2 of Automations Conditions (not yet published)).
+An encoded date-time literal (`"2026-12-25T10%3A00%3A00Z"`) is not recognized as a date in a formula field — pass a `"YYYY-MM-DD"` literal or a function, or make the whole field a plain ISO value (§4). This exception is for formula fields only: in a CONDITION the panel itself writes date-time literals encoded and reads both forms ([Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions) §2).
 
 Semantics: `stringEq` and `stringHasSubString` are case-insensitive (normalize with `lower()` if it matters). Booleans: use the value directly (`if(var("isVip");…)`, `not(var("isVip"))`), never `eq(var("isVip");true)`.
 
 **Never use in a formula field** (the builder flags them as unknown functions):
-`toEpoch`, `arrayFilter`, `hasSubstring`, `textWithExpressions`, `contains`, `arraySome`, `arrayEvery`, `arrayIncludesAnyOf/AllOf/Only`, `stringContains`, `numberContains`, `boolEq`, `numberEq/numberGt/numberGte/numberLt/numberLte`. (Several of these ARE the condition vocabulary — §2 of Automations Conditions (not yet published) — and `contains`/`arraySome` the trigger-filter vocabulary.)
+`toEpoch`, `arrayFilter`, `hasSubstring`, `textWithExpressions`, `contains`, `arraySome`, `arrayEvery`, `arrayIncludesAnyOf/AllOf/Only`, `stringContains`, `numberContains`, `boolEq`, `numberEq/numberGt/numberGte/numberLt/numberLte`. (Several of these ARE the condition vocabulary — [Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions) §2 — and `contains`/`arraySome` the trigger-filter vocabulary.)
 
 **Do not exist** (never guess): `replace`, `replaceAll`, `trim`, `split`, `join`, `indexOf`, regex/`match`, `ceil`, `floor`, `parseInt`, `parseFloat`, `random`, `filter`, `reduce`, `sort`, `switch`, loops, `try/catch`, `coalesce`, `formatDate`, `formatNumber`, `formatCurrency`, `titleCase`, `add`, `addDays`, `equals`.
 
@@ -98,13 +98,13 @@ A `strict` dynamic field requires the exact return type/format. `skipActionExpre
 - **No lists as text**: no `join`; an `arrayMap` result can't go into `concat` or a string field.
 - **Single-value field from an array → impossible.** Ask the user which item or use a user-given value; don't retry array-shaped variants.
 - Empty arrays make `arraySum/arrayMin/arrayMax/arrayMedian/arrayMultiply` fail at runtime.
-- Membership tests (`does the order contain X`) belong in a condition (§3 of Automations Conditions (not yet published)) or, for complex logic, a code condition.
+- Membership tests (`does the order contain X`) belong in a condition ([Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions) §3) or, for complex logic, a code condition.
 
 ## 6. Dates
 
 - `date*` compare calendar dates, `dateTime*` instants (argument formats: §2). `addToDate`/`subtractFromDate` offset by whole years/months/days.
 - "Within N days before X": `{{dateAfter(var("d");subtractFromDate(var("x");0;0;7))}}`. Day differences can't be computed renderably (no `toEpoch`) — use a DELAY, such a comparison, or a code condition.
-- **Annual dates (birthdays)**: never `dateEq(var("birthdate");now())`. Compare month and day: `{{and(eq(month(var("contact.birthdate"));month(now()));eq(day(var("contact.birthdate"));day(now())))}}` — in a formula field; as a condition use code or a boolean set-variable (§4 of Automations Conditions (not yet published)).
+- **Annual dates (birthdays)**: never `dateEq(var("birthdate");now())`. Compare month and day: `{{and(eq(month(var("contact.birthdate"));month(now()));eq(day(var("contact.birthdate"));day(now())))}}` — in a formula field; as a condition use code or a boolean set-variable ([Automations Conditions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-conditions) §4).
 - **Never hardcode a year**; derive it: `{{dateAfter(var("order_date");concat(toString(year(var("order_date")));"-10-31"))}}`. Use `year(now())` only when the rule is about the current calendar year.
 - Windows crossing New Year (Dec 26 – Jan 4): `{{or(and(eq(month(var("d"));12);gt(day(var("d"));25));and(eq(month(var("d"));1);lt(day(var("d"));5)))}}`; pick `gt`/`gte` from the user's wording.
 - Formatting: `{{toString(month(var("d")))}}/{{toString(day(var("d")))}}/{{toString(year(var("d")))}}` in a string field.