@wix/agent-skills 1.31.1 → 1.32.0

package/skills/wix-manage/references/app-installation/install-wix-apps.md

@@ -92,7 +92,7 @@ curl -X POST \
 
 Before installing, refer to the [Apps Created by Wix](https://dev.wix.com/docs/api-reference/articles/work-with-wix-apis/platform/about-apps-created-by-wix) documentation to find the correct `appDefId` for the app you want to install.
 
-Some common apps:
+Some common apps (`appDefId`; [List Installed Apps](list-installed-apps.md) shows which of them a site already has):
 | App | appDefId |
 |-----|----------|
 | Wix Stores | `215238eb-22a5-4c36-9e7b-e7c08025e04e` |
@@ -102,6 +102,10 @@ Some common apps:
 | Wix Multilingual | `14d84998-ae09-1abf-c6fc-3f3cace5bf19` |
 | Wix Pricing Plans | `1522827f-c56c-a5c9-2ac9-00f9e6ae12d3` |
 | Wix CMS | `e593b0bd-b783-45b8-97c2-873d42aacaf4` |
+| Wix Forms | `225dd912-7dea-4738-8688-4b8c6955ffc2` |
+| Wix Restaurants Menus | `b278a256-2757-4f19-9313-c05c783bec92` |
+| Wix Restaurants Orders (online ordering) | `9a5d83fd-8570-482e-81ab-cfa88942ee60` |
+| Wix Table Reservations | `f9c07de2-5341-40c6-b096-8eb39de391fb` |
 
 ### IMPORTANT NOTES:
 - NEVER guess the `appDefId`. For Wix-built apps, use the table above. For any other app, resolve the ID using Step 0 (Search Market Listings).

package/skills/wix-manage/references/app-installation/list-installed-apps.md

@@ -8,7 +8,10 @@ This recipe guides you through listing all installed apps on a Wix site using th
 
 ## Prerequisites
 
-- Site ID for the site you want to check
+- A token scoped to the site: the call takes no site parameter and answers for the site the token is
+  for. With the Wix CLI, `npx @wix/cli@latest token --site <siteId>`; through the Wix MCP, `ExecuteWixAPI`
+  with `scope: 'site'` and the `siteId`. An account token, with or without a `wix-site-id` header, answers
+  an empty list, which looks like a site with no apps.
 
 ## Required APIs
 
@@ -18,7 +21,10 @@ This recipe guides you through listing all installed apps on a Wix site using th
 
 ## Step 1: Query Installed Apps
 
-Use the Get Installed Apps endpoint to retrieve all apps installed on a site.
+Use the Get Installed Apps endpoint to retrieve all apps installed on a site. It returns every app
+instance, including the dozens of platform apps every site carries, as ids only: the response has no
+names; match them against the table in Step 2. [Read Account or Site Context](../sites/read-site-context.md)
+has the names, but its list can lag an install by many minutes; this call is immediate.
 
 **Endpoint**: `GET https://www.wixapis.com/apps-installer-service/v1/app-instances`
 
@@ -26,7 +32,7 @@ Use the Get Installed Apps endpoint to retrieve all apps installed on a site.
 ```bash
 curl -X GET \
   'https://www.wixapis.com/apps-installer-service/v1/app-instances' \
-  -H 'Authorization: <AUTH>' \
+  -H "Authorization: $(npx @wix/cli@latest token --site <SITE_ID>)" \
   -H 'Content-Type: application/json'
 ```
 
@@ -36,8 +42,7 @@ curl -X GET \
   "appInstances": [
     {
       "id": "instance-id-1",
-      "appDefId": "1380b703-ce81-ff05-f115-39571d94dfcd",
-      "version": "^0.0.0",
+      "appDefId": "215238eb-22a5-4c36-9e7b-e7c08025e04e",
       "enabled": true,
       "status": "UNKNOWN"
     },
@@ -61,12 +66,17 @@ Match the `appDefId` values from the response against known Wix app IDs.
 
 | App | appDefId |
 |-----|----------|
-| Wix Stores | `1380b703-ce81-ff05-f115-39571d94dfcd` |
+| Wix Stores | `215238eb-22a5-4c36-9e7b-e7c08025e04e` |
+| Wix Checkout & Orders (installed with Stores) | `1380b703-ce81-ff05-f115-39571d94dfcd` |
 | Wix Bookings | `13d21c63-b5ec-5912-8397-c3a5ddb27a97` |
 | Wix Blog | `14bcded7-0066-7c35-14d7-466cb3f09103` |
 | Wix Events | `140603ad-af8d-84a5-2c80-a0f60cb47351` |
 | Wix Pricing Plans | `1522827f-c56c-a5c9-2ac9-00f9e6ae12d3` |
-| Wix Restaurants | `13e8d036-5516-6f75-e025-2aca3b5d7930` |
+| Wix CMS (Wix Data) | `e593b0bd-b783-45b8-97c2-873d42aacaf4` |
+| Wix Forms | `225dd912-7dea-4738-8688-4b8c6955ffc2` |
+| Wix Restaurants Menus | `b278a256-2757-4f19-9313-c05c783bec92` |
+| Wix Restaurants Orders (online ordering) | `9a5d83fd-8570-482e-81ab-cfa88942ee60` |
+| Wix Table Reservations | `f9c07de2-5341-40c6-b096-8eb39de391fb` |
 
 For a complete list, see [Apps Created by Wix](https://dev.wix.com/docs/api-reference/articles/work-with-wix-apis/platform/about-apps-created-by-wix).
 
@@ -111,8 +121,8 @@ If you receive `401 Unauthorized` or `403 Forbidden` errors from Wix APIs:
 - Check that the token has `APP-MARKET.VIEW-INSTALLED-APP` permission
 
 ### Empty Response
-- The site may have no additional apps installed beyond core Wix functionality
-- This is normal for new or minimal sites
+- Every site carries dozens of platform app instances, so an empty list means the token was not scoped to
+  the site (an account token answers empty), not a site with no apps. Mint a site token and call again.
 
 ---
 

package/skills/wix-manage/references/automations/actions.md

@@ -0,0 +1,134 @@
+---
+name: "Automations Action Configuration"
+description: "Configure app-defined automation actions from their input schemas and preserve supported existing action mappings."
+---
+
+> **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).
+
+# App-Defined Actions — Discovery, Schemas, Input Mapping
+
+**TL;DR**
+
+- An action is `appId` + `actionKey`. Find real ones with **Resolve Actions** (site catalog), then read the version active on the site with **Get Runtime Action**. Never invent keys.
+- The configuration is `appDefinedInfo.inputMapping`: an object keyed ONLY by input-schema property names, with values of the schema's type — literals, or `{{…}}` formulas in fields the UI schema marks as dynamic.
+- Fields marked `updateSchemaOnChange: true` reveal more inputs once set → **Get Action Dynamic Input Schema**. Output that depends on configuration → **Get Action Dynamic Output Schema** after the mapping is final.
+- **Later stages only — email is outside stage 2:** **Send an email** (`triggered-emails`): initialize each NEW step with **Generate Action Input Mapping**, persist the returned mapping unchanged, then configure content with Get / Set Email Content (Automations Email Actions (not yet published)). Existing content-only edits do not initialize another email.
+- Entity-selector fields take **ids**, never display names (Automations Entity and Provider Configuration (not yet published)).
+- Before accepting any action, prove its side effect and its recipient (§6).
+
+---
+
+## 1. APIs used here
+
+Site-scoped (`wix-site-id` header), SDK module `actionCatalog`: Resolve Actions · Get Runtime Action (the version this site runs — use it) · Get Action Dynamic Input / Output Schema (+ bulk output). Paths and request shapes: [Automations API Catalog](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-api-catalog) §4.
+
+## 2. Finding the right action
+
+1. Resolve Actions with small pages (`{"query": {"paging": {"limit": 25}}}`); filter by `appId` when known, otherwise search locally over `displayName`, `description`, `actionKey` with a keyword ladder (phrase → domain verb/noun → synonyms).
+2. Read the `description`. A name like "Add a coupon" or "Get a …" can be a value-producing step that notifies nobody.
+3. Get Runtime Action for the 1–3 best candidates; build against that version's `inputSchema`, `outputSchema`, `interfaceConfiguration`.
+4. An action missing from Resolve Actions is not usable on this site. The builder shows such a step as "action not found" and blocks it.
+
+**Do not use** unsupported or deprecated actions — `send-mail` (→ `triggered-emails`), `send-coupon-action` (→ `wixcoupons-retrieve_coupon` + a delivery step that uses its code), `wix_automations-velo_action`, `wix_automations-data_manipulation_code` (code variable; public Create refuses it — §4 of Automations Delays Variables and Branches (not yet published)), `whatsapp-send-message` (WhatsApp), `forward-to-zapier` (Zapier), and site actions `wix_automations-wix_api_integration` (non-public). Match these by `actionKey` (+ `appId`), not by app or display name — other actions of the same app are fine. Reasons and replacements: §2 of Automations Feasibility and Planning (not yet published) (site actions: §1).
+
+### Selection rules
+
+- Prefer a normal built-in action over any AI action.
+- **Direct action beats communication**: "apply the change" is the change, not an email about it — unless messaging was asked for.
+- **Delivery beats retrieval**: "send the customer a coupon" needs a delivery step. A staging action alone is incomplete; its output must be consumed by a delivery step on the same path.
+- Replacing an unsupported external integration: keep the channel (chat stays chat-like).
+- AI ladder — first that fits: (1) **Delegate to Aria** `ai_assistants-delegate-to-assistant`: autonomous agent, output NOT used downstream (exposes only `summary`); (2) **Custom agent** `ai_custom_agent_bm-delegate_to_agent`: autonomous agent whose output IS used downstream; (3) **Generate or analyze text** `wix_automations-llm_call`: pure LLM over data already in the payload; no tools, no internet. "LLM step" → (3). When later steps need several structured fields, use (3) with an override output schema — not a single-string text action.
+- Ask the user to choose between overlapping actions only when the difference is user-facing and context doesn't decide it.
+
+## 3. Reading the action
+
+- `inputSchema` — JSON Schema of the mapping. `required` = must map. `oneOf`/`const` = enum. `format`, `wixCustomType`, `identityType` as in [Automations Trigger Configuration](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-trigger-configuration) §3.
+- `interfaceConfiguration.type` — `GENERIC` → the builder renders a form from `inputSchema` + `genericOptions.uiSchema` (rules in §5.2). `WIDGET_COMPONENT` → the app's own configuration widget, which you can't see (below).
+- `interfaceConfiguration.genericOptions.uiSchema` — per-field UI hints (below). It cannot add fields.
+- `outputSchema` — fields downstream steps read as `var("<namespace>.<field>")`. Empty and no dynamic output → later steps must not reference its namespace.
+- `implementedMethods` — `validateConfiguration` (the app validates your mapping on Validate Automation), `getQuotaInfo`. It does **not** tell you about dynamic schemas — decide by `updateSchemaOnChange` and by calling the dynamic-output API.
+
+**`WIDGET_COMPONENT` actions.** The widget owns the mapping; the builder's form rules don't apply to it. In these guides an *opaque widget* is a `WIDGET_COMPONENT` action whose `inputSchema` does not fully describe the requested configuration. If `inputSchema` fully describes what the user asked for (e.g. `addLabelsToContact`: `contactId` + `labelKeys`), hand-author it (§5.2) and tell the user to review the step; otherwise tell the user this step can’t be configured through the API here and that they can set it up in the automations builder. If the widget can't load (its app is uninstalled), the builder shows an "app not installed" state with a Replace button instead of the settings.
+
+Conditional fields (`if`/`then`/`dependencies`, e.g. a due date shown only when "add a due date" is true): set the toggle and the dependent field together, or leave both out.
+
+UI-schema keys that change what you may write:
+
+- `dynamicValuesOptions.enabled: true` → the field accepts `{{…}}` formulas. `strict: true` → the formula must return the field's exact type/format. **A field without it is static: literal only.**
+- `"ui:widget": "EntitySelector"` + `entitySelectorOptions` (`selectorId`/`tag`, `filters`, `dynamicFiltersMapping`) → entity picker; value = id or array of ids (§1 of Automations Entity and Provider Configuration (not yet published)). Same for input properties carrying `itemsSelectionConfiguration`.
+- `"ui:field": "AudienceSelector"` → an audience object owned by the app's picker; don't hand-author it — the user sets it in the builder.
+- `"ui:field": "TextSectionField"` → display-only text; never map it.
+- `"ui:widget": "hidden"`, `ui:readonly` → keep the schema `default`. Other `ui:*` keys are presentation only.
+
+## 4. Dynamic input and output schemas
+
+- **Input**: a property with `updateSchemaOnChange: true` (e.g. a template or form id) changes which inputs exist. Set it, then call Get Action Dynamic Input Schema with `{appId, actionKey, inputMapping}` (the mapping so far). The builder shows the static schema **merged** with the returned one (properties and `required` united), so keys from either are kept. Repeat if another controlling field is revealed. Never invent a field you expected but didn't get — it appears only after its controlling selection. The builder re-fetches this schema from your saved mapping every time the step is opened, so a dynamic key whose controlling value isn't in the mapping is dropped on the first edit.
+- **Output**: after the mapping is final, call Get Action Dynamic Output Schema (or the bulk variant) and use the returned `outputSchema` for downstream `var()` paths. A dynamic output is a _real_ schema — never replace it with an override (allowlist: §3 of Automations Schemas and Scheduling (not yet published)).
+
+## 5. Building the input mapping
+
+### 5.1 Provider-owned mappings — email and opaque widgets
+
+> **Later stages only:** email and other opaque-widget configuration is not available in stage 2; this section is published in stage 4.
+
+**In this stage:** never invent an opaque widget's mapping or its app-owned keys; tell the user which action to add in the builder and how it should be configured.
+
+### 5.2 Hand-authored mapping
+
+MUST (builder renderability — the `GENERIC` form drops, rewrites or flags anything else):
+
+- Keys: only properties of the current (merged dynamic) input schema. The form drops unknown keys on the first edit.
+- Values: the schema's type — string→string, number/integer→number, boolean→boolean, array→array, object→object field by field (e.g. MONEY `{"value": "…", "currency": "…"}`).
+- Every `required` field present. An action with visible fields and a missing/`null` `inputMapping` is flagged "missing required info" and its panel can't be applied.
+- An action with no input properties (or only hidden ones): send `"inputMapping": {}` — the builder writes `{}` itself on open otherwise.
+- Map fields the form would auto-fill, or opening the step silently changes the automation: fields with a schema `default` (write the default or your value), every `identityType` input (the form auto-maps it when exactly one matching payload path exists), required `date`/`date-time`/`time` strings (else filled with "now").
+- Enum fields (`oneOf` / `enum`): one of the listed constants.
+- Entity-selector fields: real ids of the right kind and shape (§1 of Automations Entity and Provider Configuration (not yet published)).
+- `{{…}}` only in fields with `dynamicValuesOptions.enabled` (or an `identityType` field), per [Automations Mapping Expressions](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-mapping-expressions) §4: number/boolean hold exactly one expression of that type; date-time a single date-time expression or ISO literal; strings may mix text and expressions. An **array-typed** `var()` in a string field is flagged as a format mismatch.
+- Don't copy volatile values: dates → `now()`/payload dates; ids → resolved at build time, never from examples.
+- Keep what the user describes for one field in that field. A subject described as "Order received, then the customer's first name" is one `subject` string mixing text and expressions (`"Order received {{var(…)}}"`); don't split its values into other fields, such as a message's `fields` rows.
+
+Value kinds:
+
+```json
+{
+  "subject": "Welcome, {{var(\"contact.name.first\")}}!",
+  "priority": "HIGH",
+  "notifyCustomer": true,
+  "amount": {
+    "value": "{{var(\"order.total.value\")}}",
+    "currency": "{{var(\"order.total.currency\")}}"
+  },
+  "contactId": "{{var(\"contactId\")}}",
+  "labelKeys": ["<label-key-1>"],
+  "note": "Order {{var(\"order_number\")}} from {{var(\"createTask-1.taskId\")}}"
+}
+```
+
+Trigger fields have no prefix; action outputs use the step's `namespace` (e.g. `createTask-1.taskId`); set-variables use `setVariable.<key>`.
+
+Optional inputs with no `default` (e.g. `isDueDate`, `onlyWhenAvailable`): omit them unless the request needs them. A deprecated defaulted input (e.g. `labelIds: []` on add-label) may be omitted.
+
+Process: (1) fetch the effective schema (§4) before you write a mapping or any script that saves one — never guess an action's field names → (2) classify required vs optional; map optional fields only with a real source → (3) source each required field from payload, upstream outputs or the user; ask for user-specific content (text, recipient, which entity) → (4) build → (5) self-check against the list above → (6) Validate Automation.
+
+### 5.3 Validation errors on actions
+
+Error shape, error type → fix, and how the builder shows each: [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. Must-know here: fix the field named by `configurationError.fieldKey` — never delete a field to silence it; `CRITICAL` blocks (status `INVALID`), `WARNING` doesn't but must be reported; a `var()` path that doesn't exist may NOT be reported — verify paths yourself.
+
+## 6. Side-effect and recipient review
+
+This section owns the semantic review (you, not code) required for every action before acceptance. Confirm from its catalog entry and effective schemas:
+
+- **Verb**: it performs what was asked (assign/add/send/create/update/delete). A read-only "get" action can't satisfy a mutation; sending a message about a change is not the change.
+- **Entity**: the affected entity has a matching input (e.g. a label picker for "add label").
+- **Identity input**: the id it acts on, with the right `identityType`.
+- **Recipient lineage** (email, chat, SMS, push): write down `{requestedAudience, resolvedAudienceKind (contact|visitor|owner|contributor|label|phone|device), resolvedIdentityPath}`. The trigger contact and a contact created upstream are different people even if both are `contactId`. Wording never proves the recipient.
+  - **Later stages only — email is outside stage 2:** Email: the audience fields decide — read `selectedAudience` / `contactId` exactly as in §3 of Automations Email Actions (not yet published) ("Recipient encoding"). A root `contactId` or `triggerContactExcluded` alone doesn't prove who receives it.
+  - Chat (`send-message`): only a schema-supported contact-id or visitor-id route; owner/team chat needs a different, proven component or a clarification.
+  - SMS / push: prove the schema-supported contact, audience, phone or device route.
+
+Under-required schemas: `send-message` requires only `contactId`/`visitorId` (anyOf), not the text. Always map the message too — a required-fields-only mapping ships an empty action.
+
+## 7. Common failure modes
+
+Missing required field or content-free required-only mapping · fabricated user values instead of asking · type/format mismatch, free text in an enum, a name in an id field · `var()` to a path absent from the aggregated schema (or from an unfetched dynamic schema) · formula in a static field or an unknown function · wrong verb or recipient · a single-value field filled from an array · unmapped defaults / identity fields / missing `{}` (the builder rewrites the step on first open).

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

@@ -1,52 +1,68 @@
 ---
 name: "Automations Activation Status"
-description: "Read an automation’s current ACTIVE or INACTIVE status and distinguish it from historical run outcomes."
+description: "Read an automation’s current ACTIVE or INACTIVE status, and activate or deactivate it when the user asks."
 ---
 
-# Inspect activation status
-
-An automation's current state is `configuration.status`: ACTIVE is eligible for new trigger
-events; INACTIVE is not. Neither value proves that a historical run succeeded or that a
-pending activation has stopped.
-
-1. Resolve the requested name with one Query Automations call filtered by that exact name
-   (below); don't page through other automations. If the ID is already supplied, go to Get.
-   If several match, open your answer by listing each match's full returned ID and asking
-   which one the user means; don't report a single status. If none match, say so and ask the
-   user to check the name or site; never guess an ID.
-2. Get the matching returned ID and read `configuration.status`.
-3. Answer briefly and completely in one reply. Start with the automation's exact name, its
-   returned ID and ACTIVE/INACTIVE from that response, then say what it means for new trigger
-   events. If the user asks whether the status says anything about past runs, answer it
-   directly in the next sentence: status does not show whether past runs succeeded; they are
-   visible in the automation's activity view in the site dashboard.
-4. If Get returns not found, do not state a status. Open with: the automation wasn't found on
-   this site, so its status can't be determined, and ask the user to confirm the site and the
-   automation ID. This question is required. Then give the possible causes below.
-
-Use an authorized site-scoped client with Set Up Automations permission. REST calls use
-`Authorization: <token>`. An API key also needs `wix-site-id: <metaSiteId>`; do not combine it
-with `wix-account-id`. Never print credentials.
-
-`POST https://www.wixapis.com/automations-service/v2/automations/query`
-
-```json
-{"query":{"filter":{"name":"<automation name>"},"cursorPaging":{"limit":25}}}
-```
-
-Read `automations[]` and `pagingMetadata.cursors.next`; continue pages if needed. Retain the
-returned `id` and exact name. Then:
-
-`GET https://www.wixapis.com/automations-service/v2/automations/<automationId>`
-
-Read `automation.configuration.status` from the Get response. Never infer status from the
-name or a previous mutation. Do not validate, change configuration, toggle status or test-run
-an automation to answer this read-only request.
-
-Not-found causes (step 4): unpublished builder drafts do not appear
-through this API, but a 404 can also mean deletion or a changed ID after overriding a
-preinstalled automation. When the user's history supports an unpublished builder draft as the
-cause, ask the owner to publish or discard it rather than reproducing its edits.
-
-Official contracts: [Query Automations](https://dev.wix.com/docs/api-reference/business-management/automations/automations/automations-v2/query-automations),
-[Get Automation](https://dev.wix.com/docs/api-reference/business-management/automations/automations/automations-v2/get-automation).
+> **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` —
+`ACTIVE` (eligible for new trigger events) or `INACTIVE` (not eligible for new trigger events).
+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;
+  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
+  so and ask the user to check the name or site; never guess an ID.
+- **Builder drafts are invisible to you**: if the user says "it doesn't show my latest changes",
+  tell them to publish (or discard) in the builder first — don't reproduce their edits.
+- **NOT_FOUND is ambiguous.** Open the answer by saying the status can't be determined and
+  asking the user to confirm the site and the automation ID; then give the possible causes. A never-published builder draft is absent
+  from Get/Query, but deletion and a replaced preinstalled id can also explain a 404. The first
+  update of a preinstalled automation can create an override with a new id; use the mutation's
+  returned id, or Query to find the current automation and confirm its identity. When the
+  user's history supports an unpublished builder draft as the cause, ask the owner to publish or
+  discard it rather than reproducing its edits.
+
+**Calls** (auth as in [Automations API Catalog](https://dev.wix.com/docs/api-reference/business-management/automations/skills/automations-api-catalog) §1). A status question needs only Query and Get — no catalogs, Validate or writes.
+
+- Find by name: `POST https://www.wixapis.com/automations-service/v2/automations/query` with
+  `{"query":{"filter":{"name":"<automation name>"},"cursorPaging":{"limit":25}}}` → `automations[]`
+  with each `id` and exact `name`. If the user supplied the ID, skip this.
+- Read: `GET https://www.wixapis.com/automations-service/v2/automations/<automationId>` → `automation.configuration.status`. Add
+  `?fields=OVERRIDE_SCHEMA` before activating or deactivating.
+- Activate / deactivate: `PATCH https://www.wixapis.com/automations-service/v2/automations/<automationId>` with
+  `{"automation": <the object exactly as fetched, with only configuration.status changed>}` — it
+  carries `id`, the current `revision`, `origin` and any `settings` the Get returned.
+
+**Activate** (only when the user asks):
+
+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)).
+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.
+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
+   its `revision`. Nothing else changes.
+6. Capture the returned id (a preinstalled override can change it), Get that id again with
+   override schemas, and confirm `configuration.status` is `ACTIVE` and all other requested
+   content is unchanged. Report "active" only then.
+
+**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
+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.
+
+**Revision conflicts** (someone published from the builder meanwhile): re-Get and retry once;
+if the fresh object differs in ways that matter, tell the user instead of overwriting.