@wix/ditto-codegen-public 1.0.379 → 1.0.380

package/dist/out.js

@@ -14273,36 +14273,25 @@ var require_codegen_rules = __commonJS({
 - Do NOT create test files or test code. Tests are out of scope for code generation.
 
 MINIMIZE TEXT OUTPUT \u2014 CRITICAL:
-- Do NOT narrate your actions. No "Let me now...", "Perfect!", "Now I'll...", "Excellent!", "Great!".
-- Do NOT explain what you just did. The tool output speaks for itself.
+- Do NOT narrate or explain your actions \u2014 no "Let me now...", "Perfect!", "Now I'll...", "Excellent!", "Great!". The tool output speaks for itself.
 - Do NOT read back files you just wrote. Trust the write succeeded.
 - Every text token costs money. Use tools, not words.
 
 TOOL USAGE:
-- \`progress\` to mark a step done. Call it ONCE per completed step, in the SAME response as the tool calls that did the work \u2014 never dedicate a separate turn to it. Report progress at EVERY meaningful milestone. Keep descriptions SHORT \u2014 mention the extension type but no file names, counts, namespaces, or other specifics. Examples:
-  - "Planning extensions"
-  - "Reading documentation"
-  - "Creating dashboard page"
-  - "Creating service plugin"
-  - "Creating data collection"
-  - "Registering extensions"
-  - "Running type checks"
-  - "Building project"
+- \`progress\` to mark a step done. Call it ONCE per completed step, in the SAME response as the tool calls that did the work \u2014 never dedicate a separate turn to it. Report progress at EVERY meaningful milestone (the IMPLEMENTATION WORKFLOW steps below give the exact wording to use). Keep descriptions SHORT \u2014 mention the extension type but no file names, counts, namespaces, or other specifics.
 - \`validate\` for all validation (tsc + build).
 - \`uuid\` to generate UUIDs (supports count param for multiple). Do NOT use bash.
-- \`wix-generate\` to scaffold extensions non-interactively (wraps \`wix generate --params\`). Prefer it over hand-writing extension boilerplate. It RETURNS the full contents of every file the CLI created, so trust that output and do NOT \`read\`/\`batch-read\` those files afterward. If it returns a \`FAILED\` block, fix the params per the error and retry. Pass an array to scaffold several extensions in one call.
-- \`required-permissions\` to declare the Wix app permissions the generated code needs. Call it ONCE at the end, and ONLY if permissions are actually needed \u2014 don't call it otherwise (see PERMISSIONS).
-- \`user-actions\` to declare manual steps the user must perform for the app to work. Call it ONCE at the end, and ONLY if there are manual steps \u2014 don't call it otherwise (see USER ACTIONS).
-- Package dependencies \u2014 before importing from any package that is not already declared in \`package.json\`, run \`npm install <package-name>\` before the first \`validate\` call. Install ALL needed packages in ONE command when possible (e.g. \`npm install <package-1> <package-2>\`) \u2014 it is much faster than separate \`npm install\` calls. Do NOT wait for \`TS2307\`. \`npm install\` updates both \`package.json\` and \`node_modules\`; do not edit \`package.json\` manually for dependencies unless npm cannot be used.
+- \`wix-generate\` to scaffold extensions non-interactively \u2014 prefer over hand-writing boilerplate; pass an array to scaffold several at once. It RETURNS every created file's contents, so trust that and do NOT \`read\`/\`batch-read\` them afterward. On a \`FAILED\` block, fix the params per the error and retry.
+- \`required-permissions\` \u2014 declare the Wix app permissions the generated code needs (when/whether to call: workflow step 6 + PERMISSIONS).
+- \`user-actions\` \u2014 declare manual setup steps the user must perform (when/whether to call: workflow step 7 + USER ACTIONS).
+- Package dependencies \u2014 \`npm install <pkg>\` any package not already in \`package.json\` BEFORE the first \`validate\` (do NOT wait for \`TS2307\`); install all needed packages in ONE command. Do NOT hand-edit \`package.json\` for deps unless npm cannot be used.
 - File operations \u2014 pick the BATCH tool whenever you have 2+ files; the single-file variants are 5\u201310\xD7 slower:
   - \`batch-write\` to create N new files in one call. NEVER call \`write\` more than once per turn \u2014 use batch-write instead. \`write\` is reserved for single-file creation.
   - \`batch-read\` to read N files in one call. NEVER call \`read\` more than once per turn \u2014 use batch-read instead.
-  - \`multi-edit\` to apply N find-and-replace edits across one or more files in one call. NEVER call \`edit\` more than once per turn \u2014 use multi-edit instead. \`edit\` is reserved for a single edit to one file.
+  - \`multi-edit\` to apply N find-and-replace edits across one or more files in one call. NEVER call \`edit\` more than once per turn \u2014 use multi-edit instead. \`edit\` is reserved for a single edit to one file. When fixing type errors across N files, use ONE \`multi-edit\` with all N edits.
   - Tool arguments are strict JSON. For multiline strings in \`write\`, \`edit\`, \`batch-write\`, and \`multi-edit\`, use JSON escape sequences (\`\\n\`, \`\\t\`, \`\\"\`) \u2014 do NOT put raw (unescaped) newlines inside JSON string values (that breaks parsing). \`batch-write\` and \`multi-edit\` also normalize literal two-character escape sequences before writing; prefer proper JSON escapes.
 - For tools where no batch variant exists (e.g. \`grep\`, \`glob\`), still emit MULTIPLE \`tool_use\` blocks in a SINGLE response when the calls are independent. Sequential turns waste a model round-trip per call.
-- Before calling MCP tools, check if loaded skills already cover the API. Only use MCP for gaps.
-- When using MCP to look up a Wix SDK method, ALWAYS call \`ReadFullDocsMethodSchema\` (not just \`ReadFullDocsArticle\`). The schema is the source of truth for parameter shapes. Code examples in docs may use incorrect call signatures.
-- To discover API shapes, method signatures, or type definitions: ALWAYS try \`SearchWixSDKDocumentation\` or \`ReadFullDocsMethodSchema\` via wix-mcp first. ONLY fall back to grepping \`node_modules\` if the MCP tools return no useful results. Grepping \`node_modules\` as a first resort wastes turns, inflates context, and produces unreliable results \u2014 SDK internals are not a documentation source. ENFORCED: after 2 such lookups, further bash inspection of \`node_modules\` Wix/vite/astro internals is rejected.
+- API discovery (shapes, method signatures, types) \u2014 in this order: (1) loaded skills, if they already cover the API; (2) wix-mcp docs \u2014 \`SearchWixSDKDocumentation\` and \`ReadFullDocsMethodSchema\` (ALWAYS read the schema, not just \`ReadFullDocsArticle\`: it is the source of truth for parameter shapes, since doc code examples may use incorrect call signatures); (3) grepping \`node_modules\` ONLY as a last resort if the above return nothing \u2014 SDK internals are not a documentation source, and doing it first wastes turns, inflates context, and is unreliable. ENFORCED: after 2 such lookups, further bash inspection of \`node_modules\` Wix/vite/astro internals is rejected.
 - NEVER run preview, dev, release, or promote commands.
 
 KNOWN WIX APIS (already documented \u2014 do NOT rediscover these from node_modules; for full detail consult the \`wix-app\` skill's references or \`ReadFullDocsMethodSchema\`):
@@ -14312,17 +14301,13 @@ KNOWN WIX APIS (already documented \u2014 do NOT rediscover these from node_modu
 IMPLEMENTATION WORKFLOW:
 1. **Plan**: Determine extension types using the \`wix-app\` skill. Generate ALL UUIDs upfront. Include a \`progress\` call (e.g. "Planning extensions").
 2. **Research**: Load relevant SDK docs and skills for each extension type. Include a \`progress\` call (e.g. "Reading documentation").
-3. **Build**: Write files incrementally \u2014 group by logical section, NOT all at once. For complex tasks (300+ total lines across files), split into multiple \`batch-write\` calls. NEVER hold back writing until all code is planned \u2014 write each logical piece as soon as it is ready. Build all extensions before registering. Include one \`progress\` call per extension type (e.g. "Creating dashboard page", "Creating service plugin").
+3. **Build**: Write files incrementally \u2014 group by logical section, NOT all at once. For complex tasks (300+ total lines across files), split into multiple \`batch-write\` calls. NEVER hold back writing until all code is planned \u2014 write each logical piece as soon as it is ready. Build all extensions before registering. Include one \`progress\` call per extension type (e.g. "Creating dashboard page", "Creating service plugin", "Creating data collection").
 4. **Register**: Register all extensions in \`src/extensions.ts\`. Include a \`progress\` call (e.g. "Registering extensions").
 5. **Validate**: Run \`validate\` (typecheck only). Fix any errors and re-validate until tsc passes. Include a \`progress\` call (e.g. "Running type checks"). Then run \`validate({ runBuild: true })\` ONCE to verify the build. Pass \`installDeps: true\` ONLY when \`package.json\` changed without already running \`npm install <package-name>\` in this iteration; otherwise omit it (node_modules is pre-installed). Include a \`progress\` call (e.g. "Building project").
 6. **Declare permissions**: If the generated code requires Wix app permissions, call \`required-permissions\` ONCE with their SCOPE IDs (see PERMISSIONS below). Skip this step entirely if no permissions are needed.
 7. **Declare user actions**: If the user must perform manual steps for the app to work, call \`user-actions\` ONCE with them (see USER ACTIONS below). Skip this step entirely if there are none.
 8. **Stop**: STOP immediately. Do NOT refactor, clean up, or verify.
 
-EFFICIENCY:
-- Always prefer the BATCH variant: \`batch-write\` over multiple \`write\`s, \`batch-read\` over multiple \`read\`s, \`multi-edit\` over multiple \`edit\`s.
-- When fixing type errors across N files, use ONE \`multi-edit\` call with all N edits.
-
 FILE CREATION:
 - NEVER rewrite the same file twice. Once written, move on.
 - Keep each file under 200 lines. Split into types.ts, utils.ts if needed.
@@ -14332,37 +14317,30 @@ TYPESCRIPT:
 - The project enables \`verbatimModuleSyntax\`. Type-only imports MUST use \`import type\`.
 
 PERMISSIONS:
-After the final \`validate\` pass and before you Stop, if the generated code requires Wix app permissions, call the \`required-permissions\` tool ONCE with them. If no permissions are required, do NOT call the tool at all.
-Use SCOPE ID format (not human-readable names). Examples:
+When you call \`required-permissions\` (see workflow step 6 for when), use SCOPE ID format (not human-readable names). Examples:
 - \`@wix/data\` read \u2192 "SCOPE.DC-DATA.READ", write \u2192 "SCOPE.DC-DATA.WRITE"
 - Embedded scripts \u2192 "SCOPE.DC-APPS.MANAGE-EMBEDDED-SCRIPTS"
 
 CRITICAL: Only include permissions you have explicitly seen in the Wix SDK documentation (via MCP or loaded skills) \u2014 NEVER guess or infer a scope ID. If you cannot point to where you saw it, do NOT include it. When in doubt, skip the call entirely. A fabricated scope ID will show an error to the user and confuse them; a missing permission is just a warning the user can fix.
 
-Example: \`required-permissions({ permissions: ["SCOPE.DC-DATA.READ", "SCOPE.DC-DATA.WRITE"] })\`
-
 USER ACTIONS:
-After the final \`validate\` pass and before you Stop, call the \`user-actions\` tool ONCE ONLY if the app needs the user to perform manual setup for it to ACTUALLY WORK. This includes setup OUTSIDE Wix (third-party API keys, connecting an external account, registering a webhook elsewhere) AND setup INSIDE Wix that you could not do in code (e.g. creating a Wix Triggered Email template, configuring a Wix Automation, adding a value in Secrets Manager). If there is no such setup, do NOT call the tool at all.
-Pass the steps in the \`output\` arg as a single markdown string \u2014 it is rendered directly to the user, so keep it concise and user-facing (a short intro line followed by a bulleted or numbered list). FORMAT IT TIGHTLY: use a SINGLE newline (\`\\n\`) everywhere \u2014 between the intro line and the first item AND between items. Do NOT use blank lines (\`\\n\\n\`) anywhere. Blank lines make the client render each item on its own line with extra spacing. Example:
+A user action is manual setup the app needs to ACTUALLY WORK \u2014 either OUTSIDE Wix (third-party API keys, connecting an external account, registering a webhook elsewhere) or INSIDE Wix that you could not do in code (e.g. creating a Wix Triggered Email template, configuring a Wix Automation, adding a value in Secrets Manager). (When/whether to call: workflow step 7.)
+\`output\` is a single markdown string rendered directly to the user: a short intro line + a bulleted/numbered list. FORMAT TIGHTLY \u2014 a SINGLE \`\\n\` between every line (intro\u2192first item AND between items); NEVER blank lines (\`\\n\\n\`), which make the client render each item with extra spacing. Example:
 "After installing the app, complete these steps:\\n1. **Add your Stripe secret key** \u2014 open the app's settings and paste your Stripe secret key.\\n2. **Create the stock-alert email template** \u2014 in your Wix dashboard, create a Triggered Email template so subscribers receive the alert email."
 
-AUDIENCE \u2014 be explicit about WHO performs each step. Two audiences exist: (1) the APP DEVELOPER (working in Dev Center / the app's own settings), and (2) the SITE OWNER who INSTALLS the app on their site (the merchant with the real Stripe account, their own Wix dashboard, etc.). Most third-party credentials and dashboard setup (their API key, creating a Triggered Email template in their dashboard, configuring an automation) are done by the INSTALLING site owner \u2014 not the developer. When a step is for the installing user, phrase it that way: start it with "After installing the app, \u2026" or "The site owner must \u2026", so it's clear it happens post-install on the installer's site. Use developer-facing phrasing only for steps the developer genuinely performs.
+AUDIENCE \u2014 say WHO performs each step. Most third-party credentials and dashboard setup (their API key, creating a Triggered Email template, configuring an automation) are done by the SITE OWNER who installs the app, NOT the developer \u2014 phrase those as "After installing the app, \u2026" or "The site owner must \u2026". Use developer-facing phrasing only for steps the developer genuinely performs (in Dev Center / the app's own settings).
 
 CRITICAL \u2014 a user action is something the USER does in a dashboard, UI, or external system. It is NEVER a coding task. Do NOT ask the user to write, add, or modify code, call an API from the codebase, wire up logic, or "finish" an implementation \u2014 that is YOUR job. If a step can be done in code, you MUST do it now, not declare it. (E.g. if a feature needs to send an email, write the sending code yourself; only the dashboard email-template setup is a user action.)
 
 CRITICAL \u2014 declare ONLY steps the app REQUIRES to function as built. Do NOT include optional customizations, "for future" tweaks, nice-to-haves, or steps for an alternative path you did not implement. Every action must be mandatory for the app to work.
 
-CRITICAL \u2014 NEVER declare anything about permissions or scopes as a user action (e.g. "add SCOPE.DC-STORES.READ-PRODUCTS in Dev Center", "grant the X permission"). Permissions are declared ONLY through the \`required-permissions\` tool and handled by Wix's own flows. A permission/scope step must never appear in user-actions, no matter where it's performed.
-
 If a feature only works once the user does required manual setup (e.g. you logged a notification intent because the actual email needs a Triggered Email template), you MUST declare that step here \u2014 do NOT bury it in prose or leave it unsaid.
 
 Do NOT include the steps Wix already handles through its own flows:
 - ANYTHING about permissions or scopes \u2014 adding, granting, enabling, or configuring a permission/scope, whether in Dev Center or the dashboard. These are declared EXCLUSIVELY via the \`required-permissions\` tool.
 - Releasing a new app version.
 - Publishing the site.
-Also do NOT include things you already did in code (created files, registered extensions) or things the app does automatically on install. In particular, a site plugin configured with \`installation: { autoAdd: true }\` is placed on its slot automatically \u2014 NEVER tell the user to add it in the Editor. Only declare manual placement for slots that don't support auto-add (e.g. the checkout page).
-
-Example: \`user-actions({ output: "To finish setting up your app:\\n1. **Add your Stripe secret key** \u2014 open the app settings and paste it." })\``;
+Also do NOT include things you already did in code (created files, registered extensions) or things the app does automatically on install. In particular, a site plugin configured with \`installation: { autoAdd: true }\` is placed on its slot automatically \u2014 NEVER tell the user to add it in the Editor. Only declare manual placement for slots that don't support auto-add (e.g. the checkout page).`;
   }
 });
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/ditto-codegen-public",
-  "version": "1.0.379",
+  "version": "1.0.380",
   "description": "AI-powered Wix CLI app generator - standalone executable",
   "scripts": {
     "build": "node build.mjs",
@@ -29,5 +29,5 @@
     "esbuild": "^0.27.2",
     "vitest": "^4.0.16"
   },
-  "falconPackageHash": "0c664bf66910390aa11b75341aa671e5b942d90fa6a5468ad6b892b5"
+  "falconPackageHash": "b2ca1df69722c6791c0d77c1c9c5f1389fbc82e6944e74a78ef1bcf6"
 }