@wix/ditto-codegen-public 1.0.78 → 1.0.80

package/dist/out.js

@@ -116553,321 +116553,6 @@ ${JSON.stringify(todoExample, null, 2)}
   }
 });
 
-// dist/system-prompts/planner/data.js
-var require_data = __commonJS({
-  "dist/system-prompts/planner/data.js"(exports2) {
-    "use strict";
-    Object.defineProperty(exports2, "__esModule", { value: true });
-    exports2.cmsPlannerPrompt = void 0;
-    var handlingFeesExample = {
-      id: "handling-fees-rules",
-      displayName: "Handling Fees Rules",
-      displayField: "productId",
-      fields: [
-        {
-          key: "productId",
-          displayName: "Product",
-          type: "REFERENCE",
-          typeMetadata: {
-            reference: {
-              referencedCollectionId: "Stores/Products"
-            }
-          }
-        },
-        { key: "oversizedFee", displayName: "Oversized Fee", type: "NUMBER" },
-        { key: "fragileFee", displayName: "Fragile Fee", type: "NUMBER" }
-      ],
-      dataPermissions: {
-        itemRead: "ADMIN",
-        itemInsert: "ADMIN",
-        itemUpdate: "ADMIN",
-        itemRemove: "ADMIN"
-      }
-    };
-    var cmsPlannerPrompt = () => `
-<CMS_PLANNER_SYSTEM_PROMPT>
-
-<role>
-You are a Wix CMS planning expert. Given a blueprint describing an app (name, summary, and extensions), you must produce a concrete CMS plan consisting of one or more valid Wix Data collection objects.
-
-Your output must be strictly JSON that conforms to the provided schema (no markdown). Use only supported field and role enums listed below.
-</role>
-
-<constraints>
-- Field definitions must use supported FieldType enums exactly as strings: TEXT, NUMBER, DATE, DATETIME, IMAGE, BOOLEAN, DOCUMENT, URL, RICH_TEXT, VIDEO, ANY, ARRAY_STRING, ARRAY_DOCUMENT, AUDIO, TIME, LANGUAGE, RICH_CONTENT, MEDIA_GALLERY, ADDRESS, PAGE_LINK, REFERENCE, MULTI_REFERENCE, OBJECT, ARRAY.
-- ALWAYS use REFERENCE fields when creating relationships between different CMS collections. ALL related fields must use REFERENCE type.
-- ALWAYS use REFERENCE fields when the blueprint indicates relationships to Stores entities (products, categories, orders). Use TEXT fields for all other relationships.
-- MANDATORY REFERENCE scenarios (you MUST use REFERENCE type):
-  - productId, product \u2192 REFERENCE to "Stores/Products"
-  - categoryId, category \u2192 REFERENCE to "Stores/Collections"
-  - orderId, order \u2192 REFERENCE to "Stores/Orders"
-- When using REFERENCE/MULTI_REFERENCE fields, they MUST include a "typeMetadata" object.
-- Permissions must use Role enums exactly as strings: ADMIN, SITE_MEMBER_AUTHOR, SITE_MEMBER, ANYONE. Prefer read: ANYONE, insert/update/remove: ADMIN unless the blueprint implies otherwise.
-- Permissions: For each collection, specify the permissions for each operation (insert, update, remove, read) using one of the following roles:
-  - ADMIN: Only site admins.
-  - SITE_MEMBER_AUTHOR: Each member manages their own items.
-  - SITE_MEMBER: Any logged-in member.
-  - ANYONE: All site visitors, including anonymous.
-- Choose minimal but meaningful fields that fit the blueprint's domain. Do not add system fields like _id, _createdDate, etc.; they are created automatically.
-- Ensure field keys are lowerCamelCase and ASCII. displayName values are human-readable.
-- Do NOT create fields that can be inferred or aggregated from other existing fields (e.g., don't create an "averageRating" field if you already have individual "rating" fields - calculate it dynamically).
-- Do NOT create audit, transaction, log, history, or analytics collections unless the blueprint explicitly requests them.
-- If the blueprint does not request persistent data, do not create any collections.
-- For static or hardcoded behaviors, at most create one minimal read-only configuration collection only when strictly necessary.
-- NEVER create CMS collections to store embedded script configuration parameters. Embedded script parameters (colors, messages, positions, display settings, etc.) are ALREADY persisted via the embeddedScripts API and are managed through embeddedScriptParameters. Creating duplicate CMS collections for this data is redundant and incorrect.
-</constraints>
-
-<typing_rules>
-- TEXT -> string
-- NUMBER -> number
-- BOOLEAN -> boolean
-- DATE -> string in YYYY-MM-DD
-- DATETIME -> ISO 8601 string or omit when not needed
-- IMAGE/VIDEO/DOCUMENT/URL -> string URL
-- ARRAY_STRING -> string[]
-- ARRAY_DOCUMENT -> string[] (URLs)
-- OBJECT -> JSON object
-- ARRAY -> JSON array
-</typing_rules>
-
-<example>
-Blueprint indicates a handling fees system for products.
-
-For the collections field, return:
-\`\`\`
-${JSON.stringify(handlingFeesExample, null, 2)}
-\`\`\`
-</example>
-
-<approach>
-1) Read the blueprint name and summary to infer the domain nouns and essential attributes.
-2) Propose collections only when the blueprint clearly requires persistent data. Define only the fields that are strictly required to fulfill the blueprint's functionality.
-3) For any field that references products, categories, or orders: ALWAYS use REFERENCE type with proper typeMetadata.
-4) Pick clear collection ids derived from the domain, lower-kebab or lower_underscore; avoid spaces.
-5) Avoid Duplicate Data Storage:
-   - Embedded script parameters (defined in embeddedScriptParameters) are ALREADY saved and persisted via the embeddedScripts API
-   - NEVER create CMS collections that duplicate these parameters (colors, messages, positions, display settings, etc.)
-   - CMS collections should ONLY be created for additional business data that is NOT covered by embeddedScriptParameters
-   - Only create CMS collections if there's genuinely new data needed beyond what's in embeddedScriptParameters (e.g., user-generated content, analytics, logs if explicitly requested)
-</approach>
-
-</CMS_PLANNER_SYSTEM_PROMPT>
-`;
-    exports2.cmsPlannerPrompt = cmsPlannerPrompt;
-  }
-});
-
-// dist/system-prompts/planner/dynamicParameters.js
-var require_dynamicParameters = __commonJS({
-  "dist/system-prompts/planner/dynamicParameters.js"(exports2) {
-    "use strict";
-    Object.defineProperty(exports2, "__esModule", { value: true });
-    exports2.dynamicParametersPrompt = void 0;
-    var dynamicParametersPrompt = () => `
-<DYNAMIC_PARAMETERS_PLANNER_SYSTEM_PROMPT>
-
-<role>
-You are a Wix CLI planner expert specialized in determining dynamic parameters for embedded scripts. Given a blueprint with EMBEDDED_SCRIPT extensions, you must decide if the embedded script needs dynamic parameters that can be configured via the dashboard, and if so, define them.
-</role>
-
-<description>
-Dynamic parameters allow embedded scripts to be configurable through a dashboard interface. They are template variables ({{variableName}}) that get replaced with actual values set by the site owner in the dashboard.
-
-Common use cases:
-- Configuration values (API keys, script settings, display options)
-- Content that changes (headlines, messages, display text)
-- Visual customization (colors, sizes, images)
-- Timing and scheduling (dates, durations, intervals)
-- Feature toggles (enable/disable functionality)
-</description>
-
-<when_to_use_dynamic_parameters>
-Use dynamic parameters when:
-- The embedded script needs configurable values that site owners should be able to change
-- The script's behavior or appearance should be customizable without code changes
-- Different instances or configurations are needed for different sites
-- Content, styling, or functionality needs to be adjusted through a UI
-
-IMPORTANT: If an embedded script extension exists but doesn't need specific dynamic parameters, you should ALWAYS add at least one dynamic parameter: an enable/disable toggle. This allows site owners to control whether the embedded script is active without removing it entirely.
-
-Example of minimum enable/disable parameter:
-{
-  "key": "enabled",
-  "displayName": "Enable",
-  "type": "BOOLEAN",
-  "description": "Enable or disable this feature",
-  "required": true,
-  "defaultValue": "true"
-}
-</when_to_use_dynamic_parameters>
-
-<output_structure>
-
-Each embedded script parameter object contains:
-- extensionId (string): The name of the embedded script extension these parameters belong to (use the extension.name field)
-- parameters (array): Array of dynamic parameter definitions
-
-Each dynamic parameter must include:
-- key (string, lowerCamelCase): The template variable name used as {{key}} in the embedded script
-- displayName (string): Human-readable label for the dashboard UI
-- type (ParameterType): The data type of the parameter
-- description (string, optional): Help text explaining the parameter's purpose
-- required (boolean): Whether the parameter must have a value
-- defaultValue (string, optional): Default value if not set by the user
-- options (array of strings, optional): For SELECT type parameters, the available options
-
-Example output structures:
-
-
-With embedded script extensions:
-  [
-    {
-      "extensionId": "site-popup",
-      "parameters": [
-        { "key": "headline", "displayName": "Headline", "type": "TEXT", "required": true },
-        { "key": "text", "displayName": "Text", "type": "TEXT", "required": true }
-      ]
-    }
-  ]
-
-Supported parameter types:
-- TEXT: text input
-- NUMBER: Numeric input
-- BOOLEAN: Checkbox or toggle
-- IMAGE: Image picker
-- DATE: Date picker
-- DATETIME: Date and time picker
-- URL: URL input with validation
-- SELECT: Dropdown with predefined options (must include options array)
-- COLOR: Color picker
-</output_structure>
-
-<examples>
-
-Example 1 - Site Popup (dynamic parameters needed):
-Blueprint: A popup that appears on the site with configurable message and timing
-Extension Name: "site-popup"
-Output:
-  [
-    {
-      "extensionId": "site-popup",
-      "parameters": [
-        {
-          "key": "headline",
-          "displayName": "Headline",
-          "type": "TEXT",
-          "description": "The main headline shown in the popup",
-          "required": true,
-          "defaultValue": "Sale 20% Off"
-        },
-        {
-          "key": "text",
-          "displayName": "Text",
-          "type": "TEXT",
-          "description": "The message content of the popup",
-          "required": true,
-          "defaultValue": "Sign up and get 20% off on our Winter Sale"
-        },
-        {
-          "key": "imageUrl",
-          "displayName": "Image",
-          "type": "IMAGE",
-          "description": "The image displayed in the popup",
-          "required": false
-        },
-        {
-          "key": "imageTitle",
-          "displayName": "Image Title",
-          "type": "TEXT",
-          "description": "Alt text for the popup image",
-          "required": false
-        },
-        {
-          "key": "activationMode",
-          "displayName": "Activation Mode",
-          "type": "SELECT",
-          "description": "When the popup should be active",
-          "required": true,
-          "defaultValue": "active",
-          "options": ["active", "timed", "disabled"]
-        },
-        {
-          "key": "startDate",
-          "displayName": "Start Date",
-          "type": "DATE",
-          "description": "Start date for timed activation",
-          "required": false
-        },
-        {
-          "key": "endDate",
-          "displayName": "End Date",
-          "type": "DATE",
-          "description": "End date for timed activation",
-          "required": false
-        }
-      ]
-    }
-  ]
-
-Example 2 - Static Pixel (minimal dynamic parameters):
-Blueprint: Add a Facebook Pixel with a hardcoded pixel ID
-Extension Name: "facebook-pixel"
-Output:
-{
-  "key": "enabled",
-  "displayName": "Enable",
-  "type": "BOOLEAN",
-  "description": "Enable or disable this feature",
-  "required": true,
-  "defaultValue": "true"
-}
-
-</examples>
-
-<guidelines>
-- If there are EMBEDDED_SCRIPT extensions, you MUST always include at least one parameter per extension
-- At minimum, every embedded script should have an enable/disable parameter to allow site owners to control activation
-- The extensionId MUST match the exact name of the embedded script extension from the blueprint
-- Define additional parameters only if they truly need to be configurable by the site owner
-- Keep parameter keys descriptive and in lowerCamelCase
-- Provide clear displayName and description for each parameter
-- Set appropriate required flags based on functionality needs
-- Choose the most appropriate type for the data
-- For SELECT types, MUST include the options array with all possible values
-- Consider grouping related parameters (e.g., activation settings, appearance settings)
-- Default values should be sensible and demonstrate the expected format
-</guidelines>
-
-</DYNAMIC_PARAMETERS_PLANNER_SYSTEM_PROMPT>
-`;
-    exports2.dynamicParametersPrompt = dynamicParametersPrompt;
-  }
-});
-
-// dist/system-prompts/planner/planner.js
-var require_planner = __commonJS({
-  "dist/system-prompts/planner/planner.js"(exports2) {
-    "use strict";
-    Object.defineProperty(exports2, "__esModule", { value: true });
-    exports2.plannerPrompt = void 0;
-    var apiSpec_1 = require_apiSpec();
-    var data_1 = require_data();
-    var dynamicParameters_1 = require_dynamicParameters();
-    var plannerPrompt = (hasEmbeddedScriptExtensions, hasBackendApiExtensions) => {
-      return `
-<WIXCLI_PLANNER_SYSTEM_PROMPT>
-${(0, data_1.cmsPlannerPrompt)()}
-
-${hasBackendApiExtensions ? (0, apiSpec_1.apiSpecPrompt)() : "No backend API extensions in the blueprint, don't return anything for apiSpec"}
-
-${hasEmbeddedScriptExtensions ? (0, dynamicParameters_1.dynamicParametersPrompt)() : 'No embeddedScriptParameters needed, no embedded scripts in the blueprint, return an empty array: "embeddedScriptParameters": []'}
-</WIXCLI_PLANNER_SYSTEM_PROMPT>
-`;
-    };
-    exports2.plannerPrompt = plannerPrompt;
-  }
-});
-
 // ../../node_modules/@wix/ambassador-data-v2-data-collection/build/cjs/types.impl.js
 var require_types_impl2 = __commonJS({
   "../../node_modules/@wix/ambassador-data-v2-data-collection/build/cjs/types.impl.js"(exports2) {
@@ -117069,62 +116754,371 @@ var require_types_impl2 = __commonJS({
   }
 });
 
-// dist/cms/CMSSchema.js
-var require_CMSSchema = __commonJS({
-  "dist/cms/CMSSchema.js"(exports2) {
+// dist/cms/CMSSchema.js
+var require_CMSSchema = __commonJS({
+  "dist/cms/CMSSchema.js"(exports2) {
+    "use strict";
+    Object.defineProperty(exports2, "__esModule", { value: true });
+    exports2.CmsCollectionSchema = void 0;
+    var types_1 = require_types_impl2();
+    var zod_1 = require_zod();
+    var FieldTypeEnum = zod_1.z.enum(Object.values(types_1.FieldType));
+    var AccessLevelEnum = zod_1.z.enum(Object.values(types_1.AccessLevel));
+    var ReferenceSchema = zod_1.z.object({
+      referencedCollectionId: zod_1.z.string().optional()
+    });
+    var MultiReferenceSchema = zod_1.z.object({
+      referencedCollectionId: zod_1.z.string().optional(),
+      referencingFieldKey: zod_1.z.string().optional()
+    });
+    var ObjectFieldSchema = zod_1.z.object({
+      key: zod_1.z.string().optional()
+    });
+    var ObjectSchema = zod_1.z.object({
+      fields: zod_1.z.array(ObjectFieldSchema).optional()
+    });
+    var ArraySchema = zod_1.z.object({
+      elementType: FieldTypeEnum.optional(),
+      typeMetadata: zod_1.z.any().optional()
+      // Recursive, simplified for now
+    });
+    var TypeMetadataSchema = zod_1.z.object({
+      reference: ReferenceSchema.optional(),
+      multiReference: MultiReferenceSchema.optional(),
+      object: ObjectSchema.optional(),
+      array: ArraySchema.optional()
+    }).optional();
+    var FieldSchema = zod_1.z.object({
+      key: zod_1.z.string().optional(),
+      displayName: zod_1.z.string().nullable().optional(),
+      type: FieldTypeEnum.optional(),
+      typeMetadata: TypeMetadataSchema,
+      encrypted: zod_1.z.boolean().optional(),
+      description: zod_1.z.string().nullable().optional()
+    });
+    var DataPermissionsSchema = zod_1.z.object({
+      itemRead: AccessLevelEnum.optional(),
+      itemInsert: AccessLevelEnum.optional(),
+      itemUpdate: AccessLevelEnum.optional(),
+      itemRemove: AccessLevelEnum.optional()
+    });
+    exports2.CmsCollectionSchema = zod_1.z.object({
+      id: zod_1.z.string().optional(),
+      displayName: zod_1.z.string().nullable().optional(),
+      displayField: zod_1.z.string().nullable().optional(),
+      fields: zod_1.z.array(FieldSchema).optional(),
+      dataPermissions: DataPermissionsSchema.optional(),
+      initialData: zod_1.z.array(zod_1.z.record(zod_1.z.string(), zod_1.z.any())).optional()
+    });
+  }
+});
+
+// dist/system-prompts/planner/data.js
+var require_data = __commonJS({
+  "dist/system-prompts/planner/data.js"(exports2) {
+    "use strict";
+    Object.defineProperty(exports2, "__esModule", { value: true });
+    exports2.cmsPlannerPrompt = void 0;
+    var zod_1 = require_zod();
+    var CMSSchema_1 = require_CMSSchema();
+    var types_impl_1 = require_types_impl2();
+    var CollectionsArraySchema = zod_1.z.array(CMSSchema_1.CmsCollectionSchema);
+    var handlingFeesExample = [
+      {
+        id: "handling-fees-rules",
+        displayName: "Handling Fees Rules",
+        displayField: "productId",
+        fields: [
+          {
+            key: "productId",
+            displayName: "Product",
+            type: "REFERENCE",
+            typeMetadata: {
+              reference: {
+                referencedCollectionId: "Stores/Products"
+              }
+            }
+          },
+          { key: "oversizedFee", displayName: "Oversized Fee", type: "NUMBER" },
+          { key: "fragileFee", displayName: "Fragile Fee", type: "NUMBER" }
+        ],
+        dataPermissions: {
+          itemRead: types_impl_1.AccessLevel.ANYONE,
+          itemInsert: types_impl_1.AccessLevel.PRIVILEGED,
+          itemUpdate: types_impl_1.AccessLevel.PRIVILEGED,
+          itemRemove: types_impl_1.AccessLevel.PRIVILEGED
+        }
+      }
+    ];
+    var cmsPlannerPrompt = () => `
+<CMS_PLANNER_SYSTEM_PROMPT>
+
+<role>
+You are a Wix CMS planning expert. Given a blueprint describing an app (name, summary, and extensions), you must produce a concrete CMS plan consisting of one or more valid Wix Data collection objects.
+
+Your output must be strictly JSON that conforms to the provided schema (no markdown). Use only supported field and role enums listed below.
+</role>
+
+<constraints>
+- Field definitions must use supported FieldType enums exactly as strings: TEXT, NUMBER, DATE, DATETIME, IMAGE, BOOLEAN, DOCUMENT, URL, RICH_TEXT, VIDEO, ANY, ARRAY_STRING, ARRAY_DOCUMENT, AUDIO, TIME, LANGUAGE, RICH_CONTENT, MEDIA_GALLERY, ADDRESS, PAGE_LINK, REFERENCE, MULTI_REFERENCE, OBJECT, ARRAY.
+- ALWAYS use REFERENCE fields when creating relationships between different CMS collections. ALL related fields must use REFERENCE type.
+- ALWAYS use REFERENCE fields when the blueprint indicates relationships to Stores entities (products, categories, orders). Use TEXT fields for all other relationships.
+- MANDATORY REFERENCE scenarios (you MUST use REFERENCE type):
+  - productId, product \u2192 REFERENCE to "Stores/Products"
+  - categoryId, category \u2192 REFERENCE to "Stores/Collections"
+  - orderId, order \u2192 REFERENCE to "Stores/Orders"
+- When using REFERENCE/MULTI_REFERENCE fields, they MUST include a "typeMetadata" object.
+- Permissions must use AccessLevel enums exactly as strings: UNDEFINED, ANYONE, SITE_MEMBER, SITE_MEMBER_AUTHOR, CMS_EDITOR, PRIVILEGED. Prefer read: ANYONE, insert/update/remove: PRIVILEGED unless the blueprint implies otherwise.
+- Permissions: For each collection, specify the permissions for each operation (insert, update, remove, read) using one of the following access levels:
+  - UNDEFINED: Not set.
+  - ANYONE: Any subject, including visitors.
+  - SITE_MEMBER: Any signed-in user (both site members and collaborators).
+  - SITE_MEMBER_AUTHOR: Any signed-in user, but site members only have access to own items.
+  - CMS_EDITOR: Site collaborator that has a role with CMS Access permission.
+  - PRIVILEGED: CMS administrators and users or roles granted with special access.
+- Ensure field keys are lowerCamelCase and ASCII. displayName values are human-readable.
+- Do NOT create fields that can be inferred or aggregated from other existing fields (e.g., don't create an "averageRating" field if you already have individual "rating" fields - calculate it dynamically).
+- Do NOT create audit, transaction, log, history, or analytics collections unless the blueprint explicitly requests them.
+- If the blueprint does not request persistent data, do not create any collections.
+- For static or hardcoded behaviors, at most create one minimal read-only configuration collection only when strictly necessary.
+- NEVER create CMS collections to store embedded script configuration parameters. Embedded script parameters (colors, messages, positions, display settings, etc.) are ALREADY persisted via the embeddedScripts API and are managed through embeddedScriptParameters. Creating duplicate CMS collections for this data is redundant and incorrect.
+</constraints>
+
+<example>
+Blueprint indicates a handling fees system for products.
+
+For the collections field, return:
+\`\`\`
+${JSON.stringify(handlingFeesExample, null, 2)}
+\`\`\`
+</example>
+
+<approach>
+1) Read the blueprint name and summary to infer the domain nouns and essential attributes.
+2) Propose collections only when the blueprint clearly requires persistent data. Define only the fields that are strictly required to fulfill the blueprint's functionality.
+3) For any field that references products, categories, or orders: ALWAYS use REFERENCE type with proper typeMetadata.
+4) Pick clear collection ids derived from the domain, lower-kebab or lower_underscore; avoid spaces.
+5) Avoid Duplicate Data Storage:
+   - Embedded script parameters (defined in embeddedScriptParameters) are ALREADY saved and persisted via the embeddedScripts API
+   - NEVER create CMS collections that duplicate these parameters (colors, messages, positions, display settings, etc.)
+   - CMS collections should ONLY be created for additional business data that is NOT covered by embeddedScriptParameters
+   - Only create CMS collections if there's genuinely new data needed beyond what's in embeddedScriptParameters (e.g., user-generated content, analytics, logs if explicitly requested)
+</approach>
+
+</CMS_PLANNER_SYSTEM_PROMPT>
+`;
+    exports2.cmsPlannerPrompt = cmsPlannerPrompt;
+  }
+});
+
+// dist/system-prompts/planner/dynamicParameters.js
+var require_dynamicParameters = __commonJS({
+  "dist/system-prompts/planner/dynamicParameters.js"(exports2) {
+    "use strict";
+    Object.defineProperty(exports2, "__esModule", { value: true });
+    exports2.dynamicParametersPrompt = void 0;
+    var dynamicParametersPrompt = () => `
+<DYNAMIC_PARAMETERS_PLANNER_SYSTEM_PROMPT>
+
+<role>
+You are a Wix CLI planner expert specialized in determining dynamic parameters for embedded scripts. Given a blueprint with EMBEDDED_SCRIPT extensions, you must decide if the embedded script needs dynamic parameters that can be configured via the dashboard, and if so, define them.
+</role>
+
+<description>
+Dynamic parameters allow embedded scripts to be configurable through a dashboard interface. They are template variables ({{variableName}}) that get replaced with actual values set by the site owner in the dashboard.
+
+Common use cases:
+- Configuration values (API keys, script settings, display options)
+- Content that changes (headlines, messages, display text)
+- Visual customization (colors, sizes, images)
+- Timing and scheduling (dates, durations, intervals)
+- Feature toggles (enable/disable functionality)
+</description>
+
+<when_to_use_dynamic_parameters>
+Use dynamic parameters when:
+- The embedded script needs configurable values that site owners should be able to change
+- The script's behavior or appearance should be customizable without code changes
+- Different instances or configurations are needed for different sites
+- Content, styling, or functionality needs to be adjusted through a UI
+
+IMPORTANT: If an embedded script extension exists but doesn't need specific dynamic parameters, you should ALWAYS add at least one dynamic parameter: an enable/disable toggle. This allows site owners to control whether the embedded script is active without removing it entirely.
+
+Example of minimum enable/disable parameter:
+{
+  "key": "enabled",
+  "displayName": "Enable",
+  "type": "BOOLEAN",
+  "description": "Enable or disable this feature",
+  "required": true,
+  "defaultValue": "true"
+}
+</when_to_use_dynamic_parameters>
+
+<output_structure>
+
+Each embedded script parameter object contains:
+- extensionId (string): The name of the embedded script extension these parameters belong to (use the extension.name field)
+- parameters (array): Array of dynamic parameter definitions
+
+Each dynamic parameter must include:
+- key (string, lowerCamelCase): The template variable name used as {{key}} in the embedded script
+- displayName (string): Human-readable label for the dashboard UI
+- type (ParameterType): The data type of the parameter
+- description (string, optional): Help text explaining the parameter's purpose
+- required (boolean): Whether the parameter must have a value
+- defaultValue (string, optional): Default value if not set by the user
+- options (array of strings, optional): For SELECT type parameters, the available options
+
+Example output structures:
+
+
+With embedded script extensions:
+  [
+    {
+      "extensionId": "site-popup",
+      "parameters": [
+        { "key": "headline", "displayName": "Headline", "type": "TEXT", "required": true },
+        { "key": "text", "displayName": "Text", "type": "TEXT", "required": true }
+      ]
+    }
+  ]
+
+Supported parameter types:
+- TEXT: text input
+- NUMBER: Numeric input
+- BOOLEAN: Checkbox or toggle
+- IMAGE: Image picker
+- DATE: Date picker
+- DATETIME: Date and time picker
+- URL: URL input with validation
+- SELECT: Dropdown with predefined options (must include options array)
+- COLOR: Color picker
+</output_structure>
+
+<examples>
+
+Example 1 - Site Popup (dynamic parameters needed):
+Blueprint: A popup that appears on the site with configurable message and timing
+Extension Name: "site-popup"
+Output:
+  [
+    {
+      "extensionId": "site-popup",
+      "parameters": [
+        {
+          "key": "headline",
+          "displayName": "Headline",
+          "type": "TEXT",
+          "description": "The main headline shown in the popup",
+          "required": true,
+          "defaultValue": "Sale 20% Off"
+        },
+        {
+          "key": "text",
+          "displayName": "Text",
+          "type": "TEXT",
+          "description": "The message content of the popup",
+          "required": true,
+          "defaultValue": "Sign up and get 20% off on our Winter Sale"
+        },
+        {
+          "key": "imageUrl",
+          "displayName": "Image",
+          "type": "IMAGE",
+          "description": "The image displayed in the popup",
+          "required": false
+        },
+        {
+          "key": "imageTitle",
+          "displayName": "Image Title",
+          "type": "TEXT",
+          "description": "Alt text for the popup image",
+          "required": false
+        },
+        {
+          "key": "activationMode",
+          "displayName": "Activation Mode",
+          "type": "SELECT",
+          "description": "When the popup should be active",
+          "required": true,
+          "defaultValue": "active",
+          "options": ["active", "timed", "disabled"]
+        },
+        {
+          "key": "startDate",
+          "displayName": "Start Date",
+          "type": "DATE",
+          "description": "Start date for timed activation",
+          "required": false
+        },
+        {
+          "key": "endDate",
+          "displayName": "End Date",
+          "type": "DATE",
+          "description": "End date for timed activation",
+          "required": false
+        }
+      ]
+    }
+  ]
+
+Example 2 - Static Pixel (minimal dynamic parameters):
+Blueprint: Add a Facebook Pixel with a hardcoded pixel ID
+Extension Name: "facebook-pixel"
+Output:
+{
+  "key": "enabled",
+  "displayName": "Enable",
+  "type": "BOOLEAN",
+  "description": "Enable or disable this feature",
+  "required": true,
+  "defaultValue": "true"
+}
+
+</examples>
+
+<guidelines>
+- If there are EMBEDDED_SCRIPT extensions, you MUST always include at least one parameter per extension
+- At minimum, every embedded script should have an enable/disable parameter to allow site owners to control activation
+- The extensionId MUST match the exact name of the embedded script extension from the blueprint
+- Define additional parameters only if they truly need to be configurable by the site owner
+- Keep parameter keys descriptive and in lowerCamelCase
+- Provide clear displayName and description for each parameter
+- Set appropriate required flags based on functionality needs
+- Choose the most appropriate type for the data
+- For SELECT types, MUST include the options array with all possible values
+- Consider grouping related parameters (e.g., activation settings, appearance settings)
+- Default values should be sensible and demonstrate the expected format
+</guidelines>
+
+</DYNAMIC_PARAMETERS_PLANNER_SYSTEM_PROMPT>
+`;
+    exports2.dynamicParametersPrompt = dynamicParametersPrompt;
+  }
+});
+
+// dist/system-prompts/planner/planner.js
+var require_planner = __commonJS({
+  "dist/system-prompts/planner/planner.js"(exports2) {
     "use strict";
     Object.defineProperty(exports2, "__esModule", { value: true });
-    exports2.CmsCollectionSchema = void 0;
-    var types_1 = require_types_impl2();
-    var zod_1 = require_zod();
-    var FieldTypeEnum = zod_1.z.enum(Object.values(types_1.FieldType));
-    var AccessLevelEnum = zod_1.z.enum(Object.values(types_1.AccessLevel));
-    var ReferenceSchema = zod_1.z.object({
-      referencedCollectionId: zod_1.z.string().optional()
-    });
-    var MultiReferenceSchema = zod_1.z.object({
-      referencedCollectionId: zod_1.z.string().optional(),
-      referencingFieldKey: zod_1.z.string().optional()
-    });
-    var ObjectFieldSchema = zod_1.z.object({
-      key: zod_1.z.string().optional()
-    });
-    var ObjectSchema = zod_1.z.object({
-      fields: zod_1.z.array(ObjectFieldSchema).optional()
-    });
-    var ArraySchema = zod_1.z.object({
-      elementType: FieldTypeEnum.optional(),
-      typeMetadata: zod_1.z.any().optional()
-      // Recursive, simplified for now
-    });
-    var TypeMetadataSchema = zod_1.z.object({
-      reference: ReferenceSchema.optional(),
-      multiReference: MultiReferenceSchema.optional(),
-      object: ObjectSchema.optional(),
-      array: ArraySchema.optional()
-    }).optional();
-    var FieldSchema = zod_1.z.object({
-      key: zod_1.z.string().optional(),
-      displayName: zod_1.z.string().nullable().optional(),
-      type: FieldTypeEnum.optional(),
-      typeMetadata: TypeMetadataSchema,
-      encrypted: zod_1.z.boolean().optional(),
-      description: zod_1.z.string().nullable().optional()
-    });
-    var DataPermissionsSchema = zod_1.z.object({
-      itemRead: AccessLevelEnum.optional(),
-      itemInsert: AccessLevelEnum.optional(),
-      itemUpdate: AccessLevelEnum.optional(),
-      itemRemove: AccessLevelEnum.optional()
-    });
-    exports2.CmsCollectionSchema = zod_1.z.object({
-      id: zod_1.z.string().optional(),
-      displayName: zod_1.z.string().nullable().optional(),
-      displayField: zod_1.z.string().nullable().optional(),
-      fields: zod_1.z.array(FieldSchema).optional(),
-      dataPermissions: DataPermissionsSchema.optional(),
-      initialData: zod_1.z.array(zod_1.z.record(zod_1.z.string(), zod_1.z.any())).optional()
-    });
+    exports2.plannerPrompt = void 0;
+    var apiSpec_1 = require_apiSpec();
+    var data_1 = require_data();
+    var dynamicParameters_1 = require_dynamicParameters();
+    var plannerPrompt = (hasEmbeddedScriptExtensions, hasBackendApiExtensions) => {
+      return `
+<WIXCLI_PLANNER_SYSTEM_PROMPT>
+${(0, data_1.cmsPlannerPrompt)()}
+
+${hasBackendApiExtensions ? (0, apiSpec_1.apiSpecPrompt)() : "No backend API extensions in the blueprint, don't return anything for apiSpec"}
+
+${hasEmbeddedScriptExtensions ? (0, dynamicParameters_1.dynamicParametersPrompt)() : 'No embeddedScriptParameters needed, no embedded scripts in the blueprint, return an empty array: "embeddedScriptParameters": []'}
+</WIXCLI_PLANNER_SYSTEM_PROMPT>
+`;
+    };
+    exports2.plannerPrompt = plannerPrompt;
   }
 });
 
@@ -136488,7 +136482,9 @@ var require_codegen_flow_helpers = __commonJS({
       return outputDir.startsWith("/") ? outputDir : path_1.default.join(process.cwd(), outputDir);
     }
     async function getRequiredPermissions(extensions) {
-      const httpClient = (0, http_client_1.createHttpClient)();
+      const httpClient = (0, http_client_1.createHttpClient)({
+        baseURL: "https://manage.wix.com/_api"
+      });
       return httpClient.request((0, http_1.getRequiredPermissions)({
         relatedApis: getRelatedApis(extensions ?? []),
         extensionTypes: getExtensionTypes(extensions ?? [])

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/ditto-codegen-public",
-  "version": "1.0.78",
+  "version": "1.0.80",
   "description": "AI-powered Wix CLI app generator - standalone executable",
   "scripts": {
     "build": "node build.mjs",
@@ -24,5 +24,5 @@
     "@wix/ditto-codegen": "1.0.0",
     "esbuild": "^0.25.9"
   },
-  "falconPackageHash": "8f8c40afa8d04806f1ea16ba9c6df14022bcb3b5b6cce1ee0e8bf71e"
+  "falconPackageHash": "855ad6b5d6b3c026aea6354041ed19744bcde718437d1b74209efc72"
 }