webstudio

0 Fork 0

mirror of https://github.com/webstudio-is/webstudio.git synced 2026-10-24 20:17:07 +09:00

Author	SHA1	Message	Date
Oleg Isonen	dd99d27e5e	fix: Stop returning unqueryable unpublish jobs (#6588 ) Unpublish finishes in the request, but it returned a job ID that `get-publish-job` could never find. It now returns the domains it unpublished. A missing publish job also stays a normal not-found error instead of suggesting a CLI update. Closes #6578 ## Changes - Keep filename-based E2E shard discovery. Rebalance the files across ten shards using measured CI times; each shard keeps its own test environment and the same 12-minute safety timeout. - Remove the fabricated unpublish job ID. `get-publish-job` remains for publish jobs. - Remove publish-only flags from the unpublish CLI and clarify CLI/MCP guidance. - Keep legacy optional server inputs for compatibility. The API input contract does not change; clients that read the old `jobId` result need to use `unpublishedDomains` instead. - No database migration. Existing domain-removal behavior is unchanged, including retention of other published domains. ## Checklist - [x] Reproduced both reported failures with tests before the fix. - [x] Reviewed the change for compatibility, redundant code, and retained-domain behavior. - [x] Updated the authoritative MCP docs and regenerated the CLI/MCP docs. - [x] Ran focused Builder, CLI, domain, and build tests; workspace typecheck, lint, package-boundary, generated API, and generated-doc checks. - [x] Restore filename-based shard discovery and rebalance the files across ten shards. - [x] Verify every Chromium workflow test runs in exactly one shard and update the E2E contributor docs. All 141 tests are assigned once across the ten shards. - [x] Verify parallel-safe long E2E files and the two-submission legacy form test in CI. - [x] Let independent slow E2E files run their tests concurrently; all ten shard jobs passed. - [ ] Confirm all E2E jobs finish in under five minutes. Eight did; shard 1 took 5:10 and shard 4 took 6:32. Move the long Content-mode page and shared-project bridge files to separate shards, then remeasure. - [x] Required CI checks pass. No live unpublish was run because it would change a published site. Agent evaluations were not run; they require separate approval.	2026-10-23 18:59:44 +02:00
Oleg Isonen	6f8bd02432	fix: Serve custom sitemap pages in preview (#6586 ) Closes #6582 ## Change Incremental prebuild replaced an authored `/sitemap.xml` route with the default sitemap wrapper. Generate the default wrapper only when no generated page owns that path. The built-in static sitemap resource remains available to custom XML pages. This changes 4 net non-test lines in route generation. The default route still appears when no custom page exists. ## Verification - The incremental custom-route regression failed before the fix and passes afterward. A separate assertion checks the default route when no custom page exists. - All 141 CLI prebuild tests passed after building the package's required content-runtime bundle. CLI typecheck, focused lint, and formatting passed. - `pnpm fixtures` passed. Its only file changes came from unrelated remote fixture content (`/acme-test` → `/olegs-test`), which was excluded. - The existing XML Node documentation says a custom `/sitemap.xml` overrides the default; no documentation update is needed. - The follow-up path cleanup passed three focused prebuild tests, CLI typecheck, lint, and formatting. Earlier required CI passed after retrying a browser shard whose database port was already in use. - After merging current `main`, shard 2's 38 E2E tests passed, but the job exceeded its 12 minute limit during cleanup. The CI timeout now gives shard 2 the same 18 minute allowance as shard 5. Workflow YAML parsing and diff checks passed. Required CI passed on the new head, including all six E2E shards. ## Checklist - [x] Reproduce incremental route replacement and add a failing regression. - [x] Preserve the default sitemap when no custom page exists. - [x] Run CLI prebuild tests, typecheck, lint, formatting, and fixtures. - [x] Review Builder `docs/` and fixture impact. - [x] Use one generated sitemap module path for imports and output, then rerun focused checks. - [x] Review the diff and commit only issue files. - [x] Verify required PR CI checks after the cleanup. - [x] Allow the expanded Builder E2E shard 2 to finish and verify CI on the latest head.	2026-10-23 17:25:15 +02:00
Oleg Isonen	59d4f00ce7	feat: new Form component, all features and improvements you dreamed of (#6485 ) ## User-facing features and how to test them In Components → Forms, insert Form (Beta). The existing Webhook Form remains a separate component. - Insert a ready-to-use contact Form. In Components → Forms, insert Form (Beta). It starts with accessible Name, Email, Subject, Message, and optional Attachment fields; sends submitted field values and uploaded files to the account holder; sends a customizable confirmation to the visitor without attaching the submitted file; and includes success and error feedback. The two Actions are named Email to owner and Email to visitor. (#3023, #5499) - Use the contact Subject in both email subjects. Owner and visitor subjects bind the submitted Subject input; the visitor subject also identifies the sender. Template and SDK tests pass. - Format submitted Form data readably in Email bindings. `formData.toString()` now renders labeled lines, nested values, and uploaded filenames in any Email Resource expression, while excluding passwords and internal Form fields. SDK and independent-bundle tests pass. Published staging delivery is verified in Batch 7. - Choose Form actions. Select the Form and open Properties & Attributes → Action. Add up to ten visible HTTP, GraphQL, or Email Resources; reorder, disable, or remove them. Submit and confirm enabled actions run together. (#5499) - Send submitted fields and files. Submit repeated fields and a file input to an HTTP Resource. Check the received multipart fields, order, filename, type, and bytes. Email Resources attach submitted files by default; turn off Attach submitted files to omit them. (#3023, #5432) - Make the visitor confirmation friendly and signed. Inherited content gets the approved friendly message and resolved sender name; custom text remains intact. Email Request preview and delivery use the same resolver. SDK and Builder preview tests cover defaults, custom overrides, blank content, sender identity, and preview parity. Suggested body: > Thank you for your message. > > We received it and will respond as soon as possible. > > Webstudio Team - Identify the sender in the visitor confirmation. The resolved sender name appears in the visitor subject and body. Focused tests pass. - Include source page context in the owner email. `browserInfo.pageUrl` is included in the owner message and the Email Request preview. Focused SDK and Builder tests pass. - Use Form and visitor data. In a Resource defined on the Form, bind `formData` and `browserInfo` in its URL, headers, or body. Local MCP Preview tests verify submitted fields, browser, and language. (#5428) - Use page and query values. On a dynamic page with query parameters, bind `system.params` and `system.search` in a Form Resource, then navigate and submit. A query key with one value is a string; repeated values are an ordered array. Confirm the current route values are available after navigation. Text bindings render repeated values as comma-joined strings. (#5512, #3891) - Use Navigation mode for search and filters. Remove every Resource from the new Form’s Action list. Its action becomes `?__webstudio__=navigate`, and submitting named fields updates the URL query and page Resources without a full page reload. Reconnect a Resource to return to Resource submission mode (`?__webstudio__=resources`). A plain Element with tag `form` keeps native browser behavior. - Customize notification email. In Project Settings → Emails, set recipients, sender, and Reply to. In each Email Resource, choose project recipients, custom addresses, or a visitor email input, and configure its Reply to, subject, body, and attachment setting. Verify a per-Resource override does not change another Form’s settings. (#4414, #4385, #5658) - Choose Resource types from one ordered list. In Variables → Type, find REST resource, GraphQL resource, Assets resource, Email resource, Sitemap resource, and Current date resource in that order. Confirm the labels and order in the Type dropdown. - Inspect Resource requests and responses. Open Variables → a Resource → Edit variable. Use Load data on Request when no request is shown; inspect HTTP request, response, and diagnostics. For Email, load the request preview and confirm it does not send an email. After submission, inspect saved HTTP and GraphQL exchanges without triggering another request. (#4093 related; new Form Resource inspector) - Explain the Email Response before a submission. Refresh builds the local request preview without sending an email; the Response tab tells users to submit the Form in Preview to see the Email Service response. Focused inspector test passes. - Use action results in the Form. Bind `formState`, `results`, and `errors` in the success and error content. Submit successful and failing actions and verify each result or error includes its action’s response details in configured order. (#5499) - See submission feedback. Submit a Form whose success or error message is outside the viewport and confirm that message scrolls into view. Repeat with feedback already visible, reduced motion, partial failure, and a configured success redirect; visible feedback should not move, and redirect should happen without scrolling first. (#6487) - Redirect after success. Set Success redirect and submit both successful and failing Forms. Only success follows the redirect. (#3530) - Keep separate email threads. Retries preserve a submission reference, while separate submissions appear in separate Gmail conversations; Batch 7 verifies both. (#5018) - Keep existing Webhook Forms. Insert the existing Webhook Form and verify its configured behavior remains intact. For its documented query-binding fixes, verify route params and repeated search values after navigation. (#5512, #3891; #4093 and #5432 remain related legacy issues) - Keep native Form props out of the new Form editor: The new Form metadata hides generated rendered-tag HTML props such as `method`, `encType`, `target`, and ARIA attributes, while its own Action, Success redirect, and visibility controls remain. The legacy Webhook Form behavior is unchanged. A Builder property-selector regression test verifies this. - Allow up to 10 Form Actions: The shared validator and Action picker now allow up to 10 Resource actions, and the Form control description reflects the limit. SDK tests accept 10 and reject 11; the generated CLI prebuild rejection coverage passes (130 tests). SDK and SDK Components typechecks, formatting, and diff checks pass. - Make the default Form ready to use without edits: The inserted contact Form has required Name, Email, Subject, and Message fields; its project Email Action resolves the current project contact address or account holder dynamically, with no personal data in the template; its visitor Email Action has a confirmation subject and message; success and error states give actionable feedback. `core-templates.test.tsx` verifies fields, routing, and copy; focused registry tests and typecheck pass. - Make the default Form usable as a contact form: Its Email Actions are named “Email to owner” and “Email to visitor.” The owner body binds the complete submitted `formData` object rather than manually listing fields, and an optional Attachment input sends its file only to the owner. Email Resource expressions render `formData.toString()` as readable labeled lines. The visitor receives a confirmation without submitted files. Registry/template tests and MCP E2E verify the inserted Form, owner message and attachment, visitor message, and Request preview. - Format Form action errors clearly: The default Form shows each action error as a spaced bullet inside a red-tinted alert panel. Registry template tests verify the alert and list structure; 8 template tests pass. - Deprecate the existing Webhook Form before its next-PR removal: The component metadata and compatibility exports in the React, React Router, and Remix packages are marked deprecated, and the guide says removal is planned. Keep form submission helpers still used by NativeForm active; remove legacy-only wrappers and template in the follow-up PR. ## MCP feature parity test plan Run these cases through Webstudio MCP on a disposable project. Create and configure the Form with MCP, save and read back the configuration, then test its generated Preview. Use only a controlled test mailbox for real email delivery. This plan mirrors the user-facing UI cases above. - Discover Form (Beta), inspect its schema, insert the default contact Form, and read back its fields, Actions, success/error content, and absence of personal data. - Change the submitted Subject and Name. Verify owner and visitor subjects, visitor sender identity, friendly confirmation text, and the owner page URL. - Bind the complete `formData` object. Verify readable lines, nested values, filenames, and exclusion of password/internal fields. - Add HTTP, GraphQL, and Email Actions; reorder, disable, and remove them. Verify concurrent dispatch, result order, partial failure, and the 10/11 Action limit. - Submit repeated fields and one or multiple files to HTTP. Verify multipart order, filename, MIME type, and exact bytes. Verify Email attachments default on, then turn them off for the visitor Action and confirm the visitor receives no file. - Configure project email settings and Resource overrides. Save/reload each recipient mode, Sender, Reply to, subject, body, and attachment setting; verify overrides do not leak between Forms. - Bind `formData` and `browserInfo` from a Form-scoped Resource. Verify page URL, browser, language, and hosting-provided IP/referrer where the test environment supplies them. - Test dynamic route params and single/repeated query values before and after navigation. Verify Navigation mode updates the URL and bound page Resources without a full reload; reconnect an Action and verify Resource mode. Check native `form` Element behavior separately. - Verify Resource discovery order and method labels, then exercise HTTP/GraphQL Request, Response, Diagnostics, load/refresh, and saved exchange inspection. For Email, verify request preview sends nothing and the Response appears after actual submission. - Bind `formState`, `results`, and `errors`. Submit success, validation failure, partial Action failure, and full failure. Verify feedback content, visible/off-screen scrolling, reduced motion, and success-only redirect behavior. - Submit twice and verify separate email threads and stable retry identity, with no duplicate delivery after an ambiguous send. - Verify the existing Webhook Form remains editable and its route/query behavior remains intact, while new Form discovery/creation and native Form prop exposure match the documented component contract. ### Execution status and MCP limitation The `mcp-` suite authors through a current-source MCP server and submits generated Preview Forms through `preview.submit-form`. Playwright covers Builder UI, navigation/rendering, and viewport assertions. The separate `forms.simulate-submission` operation submits synthetic values from the saved canvas Form directly to the shared SDK server Form engine, without starting Preview or a browser. Both paths use the same saved-draft preparation and SDK submission handler. Most automated email tests use a loopback receiver. The controlled branch-source MCP test below separately verifies delivery to a real test mailbox; it does not test the user’s connected MCP release. On 2026-10-14, the branch-source MCP was tested against a running local Builder and a copied disposable project. No npm package publish or connected-MCP release was needed for this local verification. - [x] Add a bounded `preview.submit-form` MCP operation for session-owned generated Preview Forms. It uses native form controls and validation, supports repeated values and bounded file uploads, returns state/results/errors/exchanges, and never replays an ambiguous send. The MCP-client E2E verifies one owner Email delivery and one HTTP delivery with ordered results against local receivers. Focused Vision, Project Build, CLI, and Builder E2E tests pass. - [x] Migrate browser Preview Form runtime cases to `preview.submit-form`; retain Playwright for Builder UI, navigation/rendering, and viewport assertions. The 52 MCP-named Builder E2E cases passed across the full 2-worker run (50/52) and a focused rerun of its two timed-out Email cases (2/2), including MCP submission and local receiver assertions. - [x] Add `forms.simulate-submission` to the current-source CLI MCP session. It reads the saved canvas Form, calls the Builder server route, and reuses the Preview Form engine and SDK submission handler. The older local CLI adapter rejected Email; the current server route supports it. Static Checkbox and multiple Select array names come from saved controls; dynamic array names may be supplied explicitly. Focused tests and independent Astra Medium review pass. - [x] Run the Luna Low `managed-form-runtime-v1` scenario against `forms.simulate-submission` through a real MCP client on the current source. `gpt-5.6-luna` at low reasoning passed 10/10 checks in 55 seconds. Three simulation calls produced success, an explicit 503 failure, and recovery against the controlled local HTTP receiver in the expected sequence. The agent used no Preview/browser submission or Email action. One `templates.get` MCP error was recovered before submission. - [x] Verify `forms.simulate-submission` from branch-source MCP against the local Builder server and a disposable saved Form. The supported local database was started, and `EMAIL_SERVICE_URL` plus `TRPC_SERVER_API_TOKEN` were supplied from the staging Infisical environment without printing values. Luna Low used MCP discovery, Form/resource inspection, `update-resource`, and simulation. Both Email Resources resolved only to `testing@webstudio.is`; simulation returned success, HTTP 200, two Email results with status 200, and no errors. Gmail independently confirmed both owner and visitor messages delivered to that controlled inbox at 15:46:51 UTC on 2026-10-14. The shared server route and CLI transport received independent Astra Medium review; focused CLI (164) and HTTP-client (45) tests, package typechecks, formatting, and diff checks pass. No npm release or production deployment was involved. - [x] Rename the new Form component label to Form (Beta)* in the component picker and MCP discovery. Component IDs stay unchanged; focused registry, Builder, MCP, and CLI tests pass; Astra Medium reviewed the change. Pushed `592589ccfe`. ## MCP end-to-end verification ### Verified against this branch These checks use the current-source MCP session server to author disposable local Builder projects and `preview.submit-form` to submit generated-site Forms to local test receivers. Playwright verifies Builder UI, navigation/rendering, and viewport behavior. They verify this branch's code, not the connected MCP release, staging services, or real mailbox delivery. Current branch rechecks (2026-10-14): Project Build MCP tests 142/142, CLI MCP/evaluation harness tests 60/60, Vision CDP/Form tests 48/48, and the React Router Navigation browser test 4/4 pass. Builder, CLI, Project Build, Vision, and both React Router fixture typechecks pass; scoped lint, formatting, and diff checks pass. The earlier head passed PR CI; checks on commit `7438692ef5` are running. The separate full CLI prebuild suite now passes 131/131 after adding the required `statusText` to its private Email binding fixture. The main-merge CI failures in Project Build expression expectations, CLI Preview config import, formatting, and the SSG fixture size cap were fixed in `0272768260`; checks on that commit are pending. - [x] Verify all 52 MCP-named Builder E2E cases on the current head. The complete 2-worker run passed 50/52; two complex Email cases exceeded Playwright's 120-second per-test limit under concurrency, then both passed in a focused one-worker rerun (44.4s and 31.0s; 2/2). A serial full rerun reached 43/52 without assertion failures before the wrapper's 900-second command limit. An earlier full run passed 52/52 before the final Preview readiness fix. Coverage includes contact Forms, Email delivery and partial updates, attachments, readable `formData`, HTTP and GraphQL Actions, navigation and repeated query values, legacy Form editing, Resource inspectors, Form properties and type choices, feedback, and redirects. Full-run command: `E2E_TEST_COMMAND_TIMEOUT_SECONDS=1800 E2E_SKIP_BUILDER_BUILD=true E2E_INSTALL_PLAYWRIGHT=false pnpm --filter @webstudio-is/builder e2e -- 'mcp-' --project=chromium --workers=2`. - [x] Run the Builder Preview Form E2E suite serially: 5/5 passed, including authenticated Builder Preview submission, error rendering, redirects, submitted browser `FormData`, off-screen feedback scrolling, and Navigation mode without a Resource POST or canvas reload. - [x] Verify the local Email inspector server path. The route integration suite calls the real local `/rest/preview-form` handler and passes a controlled Email Service binding response through it; 28/28 tests pass. The Email Service boundary is stubbed, so this does not claim a staging Worker run. - [x] Verify the Form Action picker browser tests: 2/2 pass for add, disable, reorder, remove, the ten-Action limit, and rejection of an eleventh Action. The MCP runtime E2E separately verified ten deliveries and ordered results. - [x] Verify local Preview request context across two pages: scoped `formData`, `browserInfo.pageUrl`, trusted IP, user-agent, and language all remain associated with the correct Form Resource. - [x] Verify partial Email body updates through MCP. Custom and explicitly blank bodies preserve the other recipient, sender, and attachment settings; local Preview uses the requested body. Focused E2E passes 2/2. - [x] Verify the default Form template has no hardcoded email address, sender, or recipient, and the error Collection renders each message as a separated bullet in a red-tinted alert. Registry tests pass 11/11. - [x] Verify the Action picker UI adds, disables, reorders, and removes HTTP, GraphQL, and Email Resources; accepts 10 and blocks 11. Component browser tests pass 2/2. Runtime MCP E2Es separately verify Action order and concurrent dispatch; the picker test does not claim ten live deliveries. - [x] Verify the Luna Low managed-Form authoring evaluation: 20/20 checks pass. Validator tests pass 83/83. - [x] Verify the legacy Webhook Form is excluded from new MCP creation/copy paths while saved instances remain editable. Source tests and the existing 139 MCP checks pass; this does not mean the published MCP catalog has been refreshed. - [x] Formatting, `git diff --check`, and Builder, CLI, and SDK Components Registry typechecks pass. ## Runtime correctness - [x] Prevent automatic retry of an Email Action when the Email Service send may already have succeeded; report an ambiguous response without sending the same email again, and verify one Form submission cannot produce duplicate delivery. Pushed `07627e44fa`: Email Actions never automatically replay; HTTP retries remain. RPC and Preview accept legacy `{id}` and canonical replies, including successful canonical replies with an empty provider ID. Regression tests cover one dispatch after failures, timeouts, and malformed replies, response compatibility, and HTTP retry. All 143 focused SDK tests, SDK typecheck, scoped lint, diff checks, and independent Astra review pass. - [x] Keep ambiguous Email Action outcomes non-retriable in Builder so a possibly successful send is never replayed; preserve compatibility with both deployed legacy `{id}` and canonical `{ok, status, statusText, data}` Worker replies. Pushed `578a1a99`: canonical delivery IDs must be nonblank, while legacy replies remain supported. SDK regressions cover one dispatch after ambiguous RPC/Preview failures, timeouts, malformed replies, and empty IDs. ## New Form navigation mode and MCP E2E (2026-10-11) - [x] Give the new Form two submission modes using its valid action URL: `?__webstudio__=resources` when one or more Resources are connected and `?__webstudio__=navigate` when none are connected. Removing the last Resource switches to Navigation mode. Keep a plain `form` Element native and leave the legacy Webhook Form available but marked deprecated until the next release. Runtime tests cover both action markers; the MCP-authored browser E2E verifies navigation query updates and Resource revalidation. Legacy Webhook Form metadata, compatibility exports, component code, and docs now state its deprecation and support window. - [x] In the new Form’s Action control, when no Resources are connected, show centered “Navigation mode” with an info tooltip: “Submits the form fields as URL query parameters and navigates without a full page reload. Use this for search and filters that update page Resources from the URL.” - [x] Add MCP-authored end-to-end coverage for both modes and their distinctions. Luna/low authored Resource and Navigation Forms plus a native `form` Element through MCP, with separate registry searches for Form (Beta), Webhook Form, and Element; the final project passes the corrected structured evaluator. The MCP-authored Playwright E2E removes all Form Actions and verifies repeated and single query values update the URL and page Resource without a document reload or Resource POST. Existing local MCP Preview coverage verifies Resource submission, native GET behavior, legacy Webhook Form compatibility, and component discovery. ## Ports from the earlier implementation - [x] Resource selection and scoped `formData`/`browserInfo` access, parallel dispatch, protected egress, server destination limits, and bot-field validation are already in the new Form. - [x] Resource editor URL autofocus and known header/value suggestions are already reused. - [x] Centralize the `formData` and `browserInfo` parameter names for Builder, generator, and runtime checks. - [x] Default HTTP body forwarding and automatic multipart for uploads are now ported to the new Resource graph. - [x] Success/error state slots and success redirect are now ported into the new Form and Router/Remix adapters. - [x] Add response `results`/`errors` bindings and one retry per failed or timed-out destination. - [x] Port feedback scrolling to the new Form in Router and Remix adapters, with browser regression coverage. - [x] Adapt the existing bot-field protection for the new Form; saved Webhook Forms keep their prior bot-field behavior. The narrowly scoped route/query fixes for #5512 and #3891 are tracked separately below. - [x] Local new-Form bot checks: one fresh hidden value per submission, five-minute expiration, malformed/missing rejection before dispatch, Brave handling, and stripping internal form ID/bot fields before Resource delivery. Evidence: `packages/sdk/src/managed-form-submission.ts`, `managed-form-submission.test.ts`, `packages/sdk-components-react/src/form-submission.browser.test.ts`, and managed generated-route cases in `packages/cli/src/prebuild.test.ts`. ## Batch 1 — New Form foundation - [x] Make the existing Forms-section Form tile insert the new Form component while retaining the existing Webhook Form tile and behavior. - [x] Make the new Form a managed Resource submission component. With no destination, it shows a configuration error and cannot dispatch or navigate. Use Element with `tag=form` for ordinary browser form behavior. - [x] Exclude unrelated legacy-only runtime work from this feature. Existing component metadata is deprecated; the new Form has no legacy compatibility or migration contract. The targeted #5512/#3891 route/query fixes are tracked separately in Batch 2a. - [x] Verify the Resource-only component with focused render tests, package typecheck, and component story generation. - [x] Verify the Batch 1 new Form acceptance criteria in the Builder and browser. ### Acceptance criteria - Inserting the new Form creates the default contact Form with named inputs, a submit button, and two selected Email Resource Actions: one for project recipients and one for the visitor email field. If all destinations are removed, it shows a configuration error and cannot dispatch or navigate until a destination is configured. - Element with `tag=form` retains browser validation, method, encoding, action, and navigation. - Acceptance covers the new Form only. Apart from the explicitly tracked #5512/#3891 route/query binding fixes in Batch 2a, legacy compatibility, old native-mode settings, and old-component migration are outside the feature contract. Verification: Builder catalog and insertion tests; Chromium empty-Resource blocking test; generated Element `tag=form` Playwright test with a local receiver (`packages/sdk-components-react/src/element-form.test.tsx`, `40c6f972c8`, focused 1/1) proves invalid input sends nothing and valid native multipart POST navigates using the configured action, method, and encoding; generated published output for the new Form; relevant typechecks and lint. The user confirmed the test inbox received the test email attachment. Staging Builder Preview verified Email and Webhook delivery. The user confirmed the published staging route is live; the route returns HTTP 200 and includes a file input. Published delivery to both Webhooks and final Form-state behavior are verified in Batch 7 below. Live Production Form submissions are outside this PR’s verification scope. ## Batch 2 — Resource-only submission, scoped data, and Resource selection - [x] Give the new Form one submission path with one to ten selected Resource destinations. Keep Actions and Success redirect as its Form controls; plain HTML forms use Element with `tag=form`. An empty selection reports an error without dispatch or navigation; tests cover this path. - [x] Expose one submission-only `formData` object, keyed by HTML name. Repeated names are ordered lists; a known unchecked checkbox group is an empty list. Preserve files and hidden inputs. - [x] Expose safe `browserInfo`: trusted IP, user agent, language, and referrer. Never expose raw request headers, cookies, or authorization. - [x] Make explicit Resource expression bindings to a Form's `formData` and `browserInfo` available only to Resources defined within that Form; a selected HTTP Action with an unset or empty body implicitly receives submitted Form data regardless of Resource scope. - [x] Resource variables are created in Variables at their normal scope. The Actions selector lists only action-capable Resource variables visible in the Form's variable scope: defined on the Form or one of its ancestors. Exclude sibling, descendant, and unrelated scopes. Resources defined on the Form can bind its `formData` and `browserInfo`; ancestor Resources cannot bind values from a descendant Form. Carry forward URL autofocus and known header/value autocomplete. Enforce up to ten Actions per Form in the Builder and server. - [x] Keep Actions as a control inside Properties & Attributes, with a plus menu and selected Resource rows. The plus menu offers only existing action-capable HTTP, Email, and GraphQL Resource variables visible in the Form's current variable scope (defined on the Form or an ancestor); exclude System data variables and resources from sibling, descendant, or unrelated scopes. Resource variables are created in Variables at their normal scope; Actions only selects existing variables. Disable already-selected Resources in the menu. Selected rows expose enable, disable, and remove controls. A simple click on the Action name opens the existing Resource editor through selection/open state, leaves its Variables row visibly selected, and scrolls it into view, while preserving page and canvas selection; drag, enable/disable, and remove controls must not open it. The eye toggles enabled state; the minus removes the Action from this Form only. Preserve explicit selection, ordering, and the ten-Action limit. Published-site submission checks are recorded in Batch 7. - [x] Cover scope, expressions, repeated names, renames, files, copying, deletion, save/reload, and unavailable bindings with focused tests. - [x] Ensure `mapResourceExpressionsMutable` remaps Email `senderExpression` and `recipientsExpression` data-source IDs; `fragment.test.tsx` verifies copy/paste/fragment rebinding (focused regression 1/1, full file 34/34). Project-build typecheck and `git diff --check` pass. - [x] Add focused fragment coverage for Email `senderExpression` and `recipientsExpression` bound to variables inside a copied Form, asserting references remap to the cloned variable IDs (not only restoration of external parent bindings by name). `fragment.test.tsx` passes 34/34 and combined project-build data+fragment tests pass 165/165; assertions verify both expressions remap to cloned variable IDs distinct from the source IDs. - [x] Implement and locally test Batch 2a current-page parameters and repeated query values in managed and legacy Form Resource bindings (#5512, #3891). - [x] Add generated published-route loader integration coverage for a native GET Form with repeated query keys; repeated `system.search` values reach an expression-bound Resource in both `defaults` and `react-router` templates. Focused prebuild tests pass 2/2. - Issue scope: #5512 is fixed for legacy generated HTML Form actions and the new Form path; generated-route tests cover both route templates. #3891 exposes repeated values as ordered arrays through `system.search` while preserving strings for single values; SDK, Builder Preview, generated action, and generated native-GET loader regressions cover the behavior. - [x] Local #5512/#3891 implementation and regression: the new Form's generated action uses current `system.params` and `system.search`, where repeated values are ordered arrays; SDK search tests and the Builder native GET preview test preserve repeated values (`packages/cli/src/prebuild.test.ts`, `packages/sdk/src/system-search.test.ts`, `apps/builder/app/canvas/interceptor.test.ts`). - [x] Locally verify #5428: bind trusted `browserInfo` values into `X-Forwarded-For`, `User-Agent`, and `Accept-Language` Resource headers, inspect the generated action’s outbound request, and document the setup and trusted client-IP source for each hosting adapter without forwarding cookies or authorization. - [x] Local generated-route verification (`e9d5209882`): Remix and React Router send the three configured headers to a test destination; Cloudflare context uses `CF-Connecting-IP`, Node omits unavailable IP, and arbitrary forwarding, cookie, and authorization headers are not forwarded. Setup and hosting sources are documented. ### Form property inventory - [x] Expose only the Actions control and Success redirect as Form controls. The generic HTML attribute picker and native `id`, `class`, `action`, `method`, `target`, and `encType` controls are unavailable for this component. - [x] Rename the Form control label from Actions to singular Action. Staging verification for the Form property panel is recorded in Batch 7. ### Acceptance criteria - Action and Success redirect are the only Form controls. The component label `Form` is system metadata and is not editable as an HTML attribute; the Form has no `id`, `class`, `action`, `method`, `target`, or `encType` controls. - Action is a control inside Properties & Attributes. Its plus menu offers only existing action-capable HTTP, Email, and GraphQL Resource variables visible in the Form's current variable scope (defined on the Form or one of its ancestors). It excludes System data variables and Resources in sibling, descendant, or unrelated scopes. Resource variables are created in Variables at their normal scope; Actions only selects existing variables. Already-selected Resources are disabled in the menu. Selected Resources appear as rows with enable, disable, and remove controls, and can be reordered. Clicking an Action name opens the corresponding Resource’s existing Edit variable dialog and highlights its Variables row by setting the existing selection/open state directly, without synthetic clicks; preserve the current page and canvas selection. Drag, enable/disable, and remove controls do not open the editor. The ten-Action limit is enforced. Resources defined on the Form can bind that Form's `formData` and `browserInfo`; ancestor Resources are visible but cannot bind values from the descendant Form. An empty selection shows no canvas warning before submit; attempting to submit shows the configuration error, dispatches nothing, and does not navigate. The Form has no native or direct-URL submission mode. - The new Form supports Resource Actions only; do not add a legacy/native-mode compatibility path or migration requirement. - A Resource defined on the Form can bind that Form's `formData` and safe `browserInfo`; a visible ancestor Resource cannot access values from its descendant Form. Resource variables are created in Variables at their normal scope. The plus menu lists only existing action-capable Resources from the Form and ancestor scopes, excluding sibling, descendant, unrelated scopes, and System variables. Forms explicitly select each action; none are auto-added. Already-selected Resources are disabled in the menu. Bindings survive editing and save/reload. - On a `/products/:slug` page visited as `/products/chair?source=newsletter`, a submitted Resource can use `system.params.slug` as `chair` and `system.search.source` as `newsletter` in its URL, headers, or body. Values come from the current submission's page, including after navigation; missing parameters remain absent. - Repeated names retain form order, unchecked checkbox groups resolve to empty lists, and files stay file values. The Resource editor focuses URL and suggests known header names and values. ## Batch 2a — Keep page parameters and every selected query value (#5512, #3891) New Form Resource bindings must receive the current page's parameters, and a multiple-select GET form must not lose selections when a binding reads the URL. - [x] Extend #5512 route/query propagation to legacy native Form actions: generated routes pass route params and ordered query values while preserving the managed Form path. The regenerated runtime contract and 26 fixture routes are pushed in `8c4bda7791`; `check:generated-api`, fixture builds, and generated-route regressions pass. - [x] Implement route/query propagation in both managed and legacy Form Actions: populate `system.params` from the current route, preserve single-value `system.search` strings and expose repeated query values as ordered arrays through the same binding. Generated action and loader regressions cover both templates; the consolidated CLI prebuild suite and focused native-GET loader tests pass. - [x] Verify #5512 with the new Form's Resource bindings using `system.params` and `system.search`. Cover URL, header, and body bindings, dynamic pages, missing values, and submission after navigation in React Router and Remix. - [x] Reproduce #3891 with a native GET form and a multiple-select input. Keep the browser's standard repeated query keys; do not join values with commas or rewrite the submitted URL. - [x] Use `URLSearchParams` to preserve every value in order, including empty values, repeated identical values, and values containing commas or encoded characters. Keep an object-based binding interface so property autocomplete still works. - [x] Inspect existing `system.search` consumers and record the compatibility choice here. Keep existing single-value bindings working, expose all repeated values to bindings, and make any changed behavior for existing repeated-key bindings explicit. Do not silently discard values or break existing expressions. - [x] Apply the agreed representation consistently in the Builder, published page data, client navigation, and new Form action path. Update affected types, binding suggestions, generated code, and fixtures. - [x] Add passing SDK, Builder, and generated-route regressions for current page parameters and repeated query values in new Form bindings; document single-value and ordered multi-value query bindings with working examples. - [x] Local new-Form generated-route regressions cover current page parameters and repeated query values in URL, headers, and body after navigation. A red-before/green-after test proves configured body bindings survive alongside submitted fields; CLI binding examples document single and repeated query values. - [x] Record regression coverage for #5512/#3891 on new Form bindings: generated-route and Builder tests cover current-page parameters and ordered repeated, empty, comma, and encoded query values, with SDK coverage for scalar compatibility. Compatibility choice: `system.search[name]` is a string when the query key occurs once and an ordered string array when it occurs more than once. Existing single-value expressions are unchanged; text bindings stringify arrays as comma-separated values. The relevant consumers in Builder system/preview and generated page/action templates were reviewed. Focused SDK, Builder, and generated-route tests cover the behavior. ### Acceptance criteria - On a `/products/chair?source=newsletter` page, a new Form Resource can bind `system.params.slug` as `chair` and `system.search.source` as `newsletter` after navigation. Existing Webhook Form behavior is unchanged except for the explicitly tracked #5512/#3891 route/query binding fixes in Batch 2a. - Selecting two options in a native GET form leaves both values in the URL and makes both available to bindings in their original order. Single-value access still works, and property autocomplete remains available. - Empty values, identical repeated values, commas, encoded characters, reloads, and client navigation do not drop or corrupt query values. - Verify current-page and repeated-query bindings for the new Form and ordinary Element `tag=form` browser behavior. Legacy Webhook Form changes are limited to the explicitly tracked #5512/#3891 route/query fixes in Batch 2a; other legacy compatibility is not a closure condition. ## Batch 3 — HTTP Resource submission - [x] POST to each selected HTTP Resource. A selected Action whose Resource body is unset or empty implicitly receives all submitted fields regardless of Resource scope; an edited body can omit, rename, add, or compute fields. Explicit `formData` expression bindings remain limited to Resources defined within that Form. - [x] Use JSON for text-only data and switch to multipart when the resolved body contains a file. Set JSON content type unless configured otherwise; preserve repeated fields and file bytes, and remove stale `Content-Type` so fetch writes the multipart boundary. - [x] Add an explicit `auto`/JSON/multipart choice. Reject an incompatible body before that destination's fetch; dependency-free requests are preflighted before any destination dispatch. - [x] Resolve bindings and validate final outbound URLs and redirects before sending. Block internal and private destinations; keep credentials and sensitive request configuration off the public page. - [x] Add generated-site and server tests for JSON, multipart, mapping, files, repeated fields, invalid configuration, and destination safety. - [x] New Form route proof: compiled Remix and React Router managed actions forward repeated same-name text values and uploaded files as separate multipart entries, preserving order, duplicate values, filenames, MIME types, and bytes (`3c5b72a`; focused CLI tests passed 2/2). Existing Webhook Form behavior remains at its pre-PR baseline; migration is out of scope. - [x] Make file inputs easy to configure in the Builder: choose the file input type and set its field name, required state, accepted file types (`accept`), and multiple-file selection (`multiple`). Keep these settings after saving, reopening, and publishing. Verified on `d7f67307f9` with Builder insert/save/reopen, generated page, Chromium required/optional/multiple upload, SDK template, typecheck, lint, and format checks. ### Acceptance criteria - Every selected HTTP destination receives POST. A Resource with an unset or empty body receives all Form data implicitly, regardless of where the Resource is defined. Explicit `formData` expression bindings remain limited to Resources defined within that Form. Text-only bodies arrive as JSON; bodies with uploads arrive as multipart with field names, filenames, MIME types, file bytes, and repeated values. - A site creator can add and configure a file input using the Builder without custom code. Published forms support one or multiple selected files, block submission when a required upload is empty, and submit normally when an optional upload is empty. The `accept` setting guides the file picker; it is not server-side file validation. - An edited body can rename, omit, add, or compute fields. A Resource outside the Form sends only its own configured data. - An incompatible explicit body format fails before its destination fetch. Dependency-free requests are validated before any dispatch; a body that depends on another Resource is validated once that dependency resolves, before its own destination fetch. Resolved destinations and each redirect reject private or internal addresses, and secrets stay off the public page. ## Batch 4 — Project Emails settings and Resource editor - [x] Add Project Settings → Emails. Move the current Contact email list without changing its stored value. - [x] Configure site-wide defaults for Sender (name and email, or email alone), recipients, owner subject, and plain-text owner body. Published sites receive project default changes after republishing. - [x] Add the Email Resource as a normal Resource, creatable inside or outside a Form. It can inherit, override, and reset project defaults. Only a Form-scoped Email Resource can bind that Form's data. Surface an unavailable Form-only binding clearly; never send incomplete template text silently. - [x] Resolve team recipients from the project list or owner fallback, support a custom comma-separated override, and default Sender to the owner with a per-Resource override. Form data cannot choose team recipients. - [x] Configure the subject, plain-text owner body, and whether submitted files should be attached. With no project body or Resource body, any selected non-Visitor Email Resource uses readable submitted fields and optional `browserInfo` interpolation, regardless of Resource scope. Automatic owner-email text includes hidden fields while excluding passwords and internal bot fields. - [x] Test project settings storage, inheritance/override/reset, recipient fallback, Form scope, expression validation, and preservation of the existing Contact email setting. A complete project owner body containing `${...}`, backslashes, or backticks renders as literal text; an empty project body retains the automatic `formData` and `browserInfo` interpolations. ### Acceptance criteria - Existing Contact recipients appear in Project Settings → Emails without data loss. Existing legacy forms retain their pre-PR behavior except for the explicitly tracked #5512/#3891 current-page route and repeated-query bindings. - New Email Resources inherit published project defaults until overridden; reset restores inheritance, and settings edits affect live sites only after republishing. - Team recipients use the project list or fall back to the owner. A custom comma-separated recipient list and Sender override work; submitted values cannot choose recipients or From. - With no project owner body or Resource body, a selected non-Visitor Email Resource uses readable submitted-field and `browserInfo` content regardless of whether it is defined on the Form, an ancestor, or globally. Explicit expressions can bind Form-only values only from Resources defined within that Form. A nonempty project body is the complete literal owner message, inherited until a Resource body expression overrides it; reset restores inheritance. Automatic text includes hidden form fields but excludes passwords and internal bot fields. ## Batch 4a — Sender and recipient email format (#4414, #5658) Use one Sender field that accepts either `Acme Support <support@example.com>` or `support@example.com`, using the same address format as recipients. The optional name becomes the displayed sender name, and the entered email receives replies. Webstudio's authenticated From address stays fixed. - [x] Add the Sender field in Project Settings → Emails, with inheritance, override, and reset in each Email Resource. Default it to the project owner's email. This single field supplies the display name and Reply-To; do not add separate sender-name and Reply-To inputs. - [x] Parse Sender as exactly one mailbox and retain its optional name and reply address; a plain email has no custom display name. - [x] Use the site owner profile username as the default visible From name when Sender has no explicit name; explicit Sender names take precedence, and missing usernames fall back to “Site Owner”. Keep the authenticated From address fixed. - [x] Accept plain and named mailboxes in the Contact email list, project recipients, and Email Resource recipient overrides. - [x] Verify existing project address-count limits remain enforced through both Builder and server updates; the separate five-team-delivery runtime cap is tracked in Batch 5. - [x] Use `Acme Support <support@example.com>` as the Sender placeholder and `Acme Support <support@example.com>, team@example.com` in email-list inputs. - [x] Use an established email-address parser in Builder and server validation. Handle quoted names containing commas, such as `"Example, Alexs" <support@example.com>`, reject malformed addresses and header-injection input, and count parsed recipient mailboxes including duplicates for the runtime delivery cap. - [x] Preserve parsed display names in generated Email Resource requests and keep existing plain-address settings readable. - [x] Test both Sender formats, mixed recipient parsing, inheritance/reset, generated request values, and the five-team-delivery runtime cap. - [x] Local Builder E2E verifies Project Emails Sender and named recipients save to persisted project settings and remain after reopening (`b9ebf21fee`; `apps/builder/e2e/tests/project-settings-runtime.[shard-2].[shard-5].[shard-6].e2e.ts`; focused run 2/2). - [x] Document the Sender/recipient input format, reply behavior, inheritance, republishing, visitor Email Resource delivery, and the current Cloud-unavailable delivery status without claiming that saving settings sends email. - [x] Local generated-graph verification (`1730840feb`): a translated project body is the entire literal request body, a Resource body expression overrides it, reset restores inheritance, and an empty project body retains automatic `formData`/`browserInfo` text. Project Emails help and docs explain plain-text behavior. ### Acceptance criteria - Entering `Acme Support <support@example.com>` in Sender displays “Acme Support” as the sender and directs replies to `support@example.com`, while From uses Webstudio's sending address. - Entering only `support@example.com` works without a separate name field and directs replies to that address. - With a plain Sender address, the visible From name uses the site owner profile username, or “Site Owner” if unavailable; a named Sender overrides it. The From address remains Webstudio’s fixed sending address. - Plain and named recipients can be mixed in a list; a quoted comma inside a name does not create another recipient. - Names and addresses survive saving, publishing, and delivery, and existing plain-address settings continue working. - The project owner confirmed that the email customization already planned in Batches 4 and 4a is sufficient to close #4414 and #5658. Sender supplies the display name and reply address; Webstudio remains the authenticated sender. Do not add custom From addresses, sending-domain verification, or a separate follow-up requirement to close these issues. Do not describe Reply-To as a custom From address. - Site creators can edit the notification subject, plain-text template, content, and language, with project defaults and per-Resource overrides. Together with Batch 4, this covers the email customization requested in #4414. ## Batch 5 — Email delivery and visitor confirmation - [x] Implement the Cloud-only `EMAIL_SERVICE` adapter for new Email Resources. Attach every submitted file by default; preflight the 5 MiB encoded-message and 32-attachment limits and return explicit service errors. Staging published-Form Email delivery is verified in Batch 7. - [x] Implement visitor confirmation as an ordinary Email Resource selected in Actions, addressed through a submitted visitor email field and dispatched alongside other Actions. Its optional body starts empty and uses the existing Resource editor and expression bindings. Email Service prepends a mandatory confirmation preamble with the site URL. Remove the Form-level confirmation toggle and email-field selector; SDK and generated-route tests cover delivery. - [x] A failed visitor-addressed Email Resource appears in `errors` and does not change aggregate Form success; SDK tests cover this. - [x] Before any destination runs, count team-recipient deliveries across all reachable Email Resources, counting duplicates and shared dependencies once. Reject the whole submission above five at runtime; permit at most one visitor-addressed receipt separately. No cross-Resource Builder or publish-time cap substitutes for this preflight. - [x] Local subject validation (`1fa8e66d9d`): resolved Email Resource subjects must be strings without CR/LF. Validate after expressions are evaluated and before any selected destination dispatch. SDK tests cover CR/LF from direct `formData` and `browserInfo` subject bindings and zero provider or selected fetches (`managed-form-resources-generator.test.ts`, `managed-form-submission.test.ts`, `resource-loader.test.ts`; focused tests 88/88 passed). Dependency-bound Email is rejected after any required lookup and before selected destination dispatch. - [x] Verify resolved owner and visitor-confirmation subjects in the generated server path with provider fakes. Owner subject preflight covers CR/LF from visitor-derived bindings before any selected destination or provider send; confirmation subject preflight likewise sends no HTTP or email request. Published staging delivery is verified in Batch 7. - [x] Test the local private-service envelope and response path with a provider fake: recipients, Reply-To, optional Sender display name, plain text, attachments, recipient and size/count preflight, privacy, confirmation ordering, partial failure, quota error, and zero sends on failed preflight. Compiled Remix and React Router action tests cover confirmation with an HTTP sibling and Node's explicit unsupported response. ### Cloudflare Email Sending integration plan Companion SaaS PR: [webstudio-is/webstudio-saas#666](https://github.com/webstudio-is/webstudio-saas/pull/666). The Email Service contract uses the canonical Worker `webstudio-email-service`, Cloudflare's native per-location Rate Limiting binding, and the private `EMAIL_SERVICE` service binding for published-site sends to `https://email-service.internal/v1/send`. Builder Preview uses the authenticated shared Email Service endpoint `https://apps.webstudio.is/v1/preview-send` with server-side `TRPC_SERVER_API_TOKEN`. The shared Email Service Worker remains deployed at version `8769175b-15d2-4c09-a312-b78dc93fd2f3`; this PR did not deploy or change it. The named staging Preview was deleted and its former URL returns 404; staging published-site Workers use the canonical Worker through the private service binding. An authenticated malformed production Preview request returned `400 invalid_request` / `Invalid email fields` before send. This proves only authentication and validation, not successful submission or delivery. Staging published-Form delivery is verified in Batch 7; limiter verification is tracked in companion SaaS PR #666. A separate direct Email Service test delivery was confirmed received; no email was sent by the malformed-request preflight. - [x] Enforce Cloudflare's 5 MiB total encoded message limit and 32-attachment cap for ordinary outbound email, accounting for base64 expansion; report provider quota, suppression, sender, size, and count errors without claiming delivery. These email limits are separate from the Form's 25 MiB incoming upload limit and Webstudio's five team-delivery preflight. Local Builder preflight/provider-fake tests and the companion SaaS Worker tests cover the limits and stable error mapping; staging published-Form delivery is verified in Batch 7. - [x] Test the local generated-site private-service contract with provider fakes for recipients, Reply-To, optional Sender display name, body, attachments, confirmation timing, partial failures, quota/limit errors, and zero sends for failed preflight (`packages/sdk/src/managed-form-email.test.ts`, `packages/cli/src/prebuild.test.ts`; `7507c3fbf7`, `ab04be99d4`, `7c950eecec`). #### Acceptance criteria - Staging verification must prove the selected private call path works for a Workers for Platforms published site; the central Worker alone owns `send_email`, and a submitted Form never receives provider credentials or direct sending capability. - A Cloud published Form delivers owner mail and the optional confirmation with the configured envelope and content; 5 MiB/32-attachment violations and provider failures produce clear `errors`. HTTP siblings retain the existing partial-failure semantics. - The Email Service contract is for the new Form only. Existing Webhook Forms do not use this Email Service as part of this feature; no legacy Email Service compatibility or migration is included. ### Acceptance criteria - A Cloud Email Resource sends the configured plain-text subject and body from Webstudio's sending address with the configured display name, with every submitted file attached under its original filename and MIME type, or returns an explicit size/count error. - More than five total team-recipient deliveries across Email Resources rejects the whole submission before any destination runs; duplicate addresses count again. - A visitor receipt is a normal Email Resource explicitly selected in Actions and addressed to the submitted visitor email field. It runs in parallel with the other selected Actions, with no separate Form-level toggle or email-field selector. Its Resource body is empty by default; the Email Service always prepends the fixed platform receipt and published site URL before the Resource body. The Resource body uses the normal editor and full existing expression/binding support. A failed visitor Email Resource appears in `errors` but is nonfatal to the aggregate Form result. - Resolved owner and confirmation subjects are strings without CR or LF. An invalid subject, including one produced from visitor data, is rejected before the email provider is called; the provider fake records no send. - Provider integration checks exercise the central Email Worker request/response contract. Mocked Builder delivery alone does not satisfy this gate. - Confirmation failure appears in `errors` while the aggregate submission remains successful; environments without Cloud email do not silently claim delivery. ## Batch 5a — Keep separate submissions in separate email threads (#5018) Site owners should see each form submission as a separate email conversation, including when several visitors submit the same form close together. - [x] Append a short, unique submission reference to each new Form owner-notification subject, keeping the configured subject text. Generate it once per submission and reuse it for that submission's delivery retries; submissions in the same second get different references. At `52fcec3640`, SDK tests cover default/custom subjects, two submissions at one mocked time, retry stability, empty/overlong preflight with zero HTTP/email sends, and the 979-character boundary; Form and Project Emails docs describe the suffix. Batch 7 verifies that separate submissions create separate Gmail conversations. - [x] Apply per-submission subject references to new Form owner notifications (`52fcec3640`). - [x] Add local regressions for new Form default/custom subjects, same-time identical submissions, stable retry references, and subject-length preflight (`managed-form-email.test.ts`). Document the suffix in the new Form and Project Emails docs. ### Acceptance criteria - Two separate submissions of the same form appear as separate conversations in Gmail with conversation view enabled. - Both default and custom subjects keep their configured text and include a different reference for each submission. - Retrying delivery within one submission keeps its reference. This does not add delivery deduplication or submission storage. - This submission-reference behavior applies to new Form owner notifications only; it does not add delivery deduplication or submission storage. ## Batch 6 — Parallel delivery and Form feedback - [x] Resolve dependency Resources needed for bindings, preflight every selected primary destination’s body format and deterministic URL parse/protocol/credentials/denied-hostname policy before dispatching any selected primary destination, then start selected primary destinations in parallel. Dependency Resources may make outbound requests during resolution. DNS/public-IP pinning and redirect checks remain in protected transport at each request hop; other transport failures can occur after a sibling dispatches. Overall success requires all primary destinations to succeed. - [x] Local deterministic group preflight (`e9b72d5d78`, `8bf4f4c8bf`): red-before generated actions in Remix and React Router prove a dependent JSON+File body or a denied selected URL blocks all selected POSTs; SDK policy tests cover allowed URLs and denied scheme, credentials, and host cases. Nonselected dependencies may run once to resolve bindings. Provider and ingress behavior are covered by service tests; staging verification is recorded in Batch 7 below. - [x] Until Cloud email delivery is integrated, reject any selected Email Resource or reachable Email dependency before dispatching an HTTP sibling. Return an explicit unsupported-delivery error without claiming success. - [x] Retry only a failed or timed-out destination once within that submission, including non-2xx responses. Never resend a known success within the same submission. A new browser submission starts over; keep no delivery history or cross-submission deduplication. - [x] Keep aggregate HTTP status as transport metadata only; expose no `status` variable. Bind each Resource's final status code and response body through ordered `results` and `errors` arrays. Expose no response headers. - [x] Redirect only after overall success when configured. Render the initial, success, and error states in the inserted Form template. - [x] Fix #6487 feedback auto-scroll regression: success and error feedback now scrolls into the viewport only when needed, uses instant behavior for reduced motion, and success redirect skips scrolling. MCP-authored generated-Preview tests assert actual viewport position for off-screen feedback, no movement for visible feedback, partial failure scrolling, and no scroll before redirect; the full serial MCP E2E suite passes (36/36 including setup). - [x] Copy the existing Webhook Form spam protection into the new Form's managed submission path: generate the hidden browser field, validate it on the server before delivery, preserve the Brave handling, and remove internal fields before sending to Resources or email. Email Service rate-limit checkpoint: The pushed SaaS code uses Cloudflare's native Rate Limiting binding only on email sends: 50 recipient checks per project UUID per Cloudflare location per 60 seconds. Each recipient consumes a check; over-limit sends return 429 before provider delivery. Preview and published sends carry the trusted project UUID. This is approximate per location, with no Durable Object, SQL storage, or account-wide quota. The 60-attempt direct Worker diagnostic and isolated non-production check are tracked in companion SaaS PR #666; no live-user Form submission is part of this Builder PR. - [x] Locally test concurrent starts, retries, timeouts, partial success, results and errors bindings, redirect, and feedback scrolling in both generated adapters and browser components. - [x] Local new-Form behavior: generated Router and Remix adapters test concurrent selected starts, one retry after non-2xx/network/timeout failure, final partial-success `results`/`errors`, and no replay of successful siblings or dependencies (`packages/cli/src/prebuild.test.ts`). Builder insertion tests verify `results` and `errors` bindings and confirm aggregate `status` is not exposed as a variable (`apps/builder/app/shared/instance-utils/insert.test.tsx`); browser tests cover success-only redirect and visible/offscreen feedback for the new Form. ### Acceptance criteria - Primary destinations begin in parallel. Each failed or timed-out destination gets one retry within the same submission; known successes are not resent, and overall success requires every primary destination. - Ordered `results` and `errors` expose each Action Resource's `resourceId` and `resourceName`, final status code, and response body to bindings, without response headers. Both arrays preserve configured Action order even when responses finish out of order. Aggregate HTTP status remains transport metadata and is not exposed as a Form variable. - Redirect occurs only after overall success, without scrolling to inline feedback first. Otherwise the correct feedback state renders and scrolls into view only when outside the viewport. Already-visible feedback does not move the page, and animated scrolling respects reduced motion. This applies to the new Form. - New Form submissions use the adapted hidden browser check: valid browser and Brave submissions pass; missing, malformed, or expired evidence stops delivery before any destination runs; internal bot fields never reach Resources or email. - The Email Service code returns 429 for recipient checks over the native per-project-UUID, per-location 50-per-60-second limit before provider delivery. HTTP/Webhook Actions and webhook-only Forms are not throttled by it. The 60-request direct Worker diagnostic and webhook control are tracked in companion SaaS PR #666; no production Form submission is part of this Builder PR. ## Batch 6a — Legacy-only work excluded from this feature ### Acceptance criteria - The new Form accepts a fresh valid submission after an earlier failed attempt without stale bot data. - No legacy compatibility path is added to the SaaS Email Service. ## Batch 6b — Shared submission runtime for the new Form (related to #4093) Use shared new-Form submission behavior across supported hosting runtimes while keeping page data current after a submission. This batch does not complete #4093's remaining legacy Webhook Form work. - [x] Move new Form submission, pending/error/success handling, and response handling into shared code that does not require Remix or React Router hooks or their form components. Generated hosting adapters call the shared managed-Form handler; existing Webhook Forms keep their original behavior. - [x] Local new-Form lifecycle: router-free Form submission uses shared `submitFormData`; generated Router and Remix adapters supply the server request and page-data refresh behavior. Legacy compatibility adapters and lifecycle changes are not included. - [x] Submit through a normal HTTP endpoint with a defined JSON response and small Router/Remix request and page-data-refresh adapters. Keep current HTTP Resource credentials, validation, bot checks, and destination protection on the server. - [x] Local managed-Form route: generated same-origin `/__ws-form` POST returns structured JSON for new Form submissions in compiled Remix and React Router handlers; route coverage includes root, nested, and dynamic pages, repeated multipart fields/files, bot rejection, and Resource results. Staging Cloud email delivery is verified in Batch 7; the Email Service rate-limit verification is tracked in companion SaaS PR #666. - [x] Integrate the Cloud `EMAIL_SERVICE` adapter for new Email Resources into the generated server action, with provider-fake response and preflight tests. The Email Service per-site rate limit is tracked separately below. - [x] Replace the automatic page-data refresh currently supplied by Remix. After a successful submission changes data, refresh the current page's Resources without a full-page reload. Handle navigation during submission and refresh failures without resending a completed submission. - [x] Test the new Form's shared component without router context against a test HTTP endpoint, then test both hosting adapters. Cover response bindings, page-data refresh, files, redirects, errors, and retries. - [x] Local browser and generated-route matrix: router-free Form tests cover pending/results, files, and HTTP/network failures; generated Router and Remix adapter tests cover retries, redirects, loader refresh, navigation, and refresh failure without replaying POST. Compiled-handler tests cover both adapters; release/staging verification is complete in Batch 7. - [x] Real router-free HTTP test (`679eb8e0c275`, `packages/sdk-components-react/src/native-form-http.test.tsx`): the shared new Form runs without a router provider in Chromium and sends multipart POST to a local same-origin JSON endpoint without mocking `fetch`. It reports pending while the response is held, then success with `results` and a later error with `errors`, without native navigation. Release/staging verification is complete in Batch 7. - [x] Page-data-refresh red-before/green-after proof: with the exact `native-form-refresh.browser.test.tsx` files from `20989a2d64` placed temporarily in detached pre-fix `41580dbe9c`, React Router and Remix each failed 3/5 tests: successful submissions left displayed data at `before`, and the refresh-failure path never ran its second loader call. On PR head `679eb8e0c275`, both adapters pass 5/5. The temporary checkout was restored cleanly; the red/green regression evidence is recorded here. - [x] Local new-Form regression tests cover pending/results, errors, redirect behavior, selected destinations, retries, and page-data refresh. Remove legacy Webhook-specific retry, feedback, lifecycle, and converter claims; they are outside the PR scope. - [x] Update the hosting and Form docs to explain the generated server endpoint, dynamic hosting requirement, and static-export limitation. The generated Cloud action calls the private `EMAIL_SERVICE` binding when present. Staging published-Form delivery is verified in Batch 7. ### Acceptance criteria - The shared submission component works without a Remix or React Router provider; supported hosting adapters connect it to server delivery and page-data refresh. - A successful data-changing submission refreshes the displayed data without reloading the whole page or sending the submission again. - Resource response values remain available through the bindings from Batch 6, with consistent success/error behavior across supported runtimes. - The generated new-Form submission path uses the shared handler; existing CLI conversion and legacy submission behavior remain at their pre-PR baseline except for the #5512/#3891 route/query binding fixes in Batch 2a. - Server protections and secret handling remain intact. Static exports do not silently claim managed submission support. ## Batch 7 — New-Form integration, docs, and release gate - [x] Mark only the legacy `Form` and `RemixForm` component metadata deprecated and keep `NativeForm` as the sole Forms insert tile. Preserve the old component IDs, registrations, templates, and supported settings for saved instances (`820aed68ed`; `apps/builder/app/shared/nano-states/components.test.tsx`, focused Chromium 2/2). - [x] Local file-input and HTTP upload segments: Builder insertion/save/reopen retains name, required, accept, and multiple settings (`apps/builder/app/shared/instance-utils/insert.test.tsx`); browser tests cover required, optional, and multiple files (`packages/sdk-components-react/src/native-form.browser.test.tsx`); compiled Remix/React Router generated actions preserve repeated multipart fields and original file names, MIME types, and bytes (`packages/cli/src/prebuild.test.ts`, `3c5b72a`). - [x] Partial published-site staging check: one controlled `/copy-1` submission with unique test value `Staging E2E 2026-10-05` entered the managed Form success state for the selected project-owner Email Resource configured with subject `New form submission`. The exact wire HTTP response and owner inbox receipt are not independently verified; the user is checking that inbox. This does not close the full multi-destination, file, confirmation, coverage. - [x] Update Form, Resource, Project Emails, and hosting docs for File Input settings, HTTP uploads and limits, visitor-addressed Email Resource with mandatory confirmation preamble/site URL and optional body, and plain HTML forms using Element with `tag=form`. - [x] Document the current managed Form's combined 25 MiB upload-request limit, multiple-file failure guidance, and separate HTTP Resource body limit (`33b2c7eab9`); Email provider attachment limits are documented in the Email Service README, and published staging delivery is verified in Batch 7. - [x] Document local Resource selection/scope and Auto/JSON/multipart upload behavior, plus Project Emails Sender, recipient, owner-body, inheritance, and visitor Email Resource settings (`b9dbb6ee55`, `7507c3fbf7`). Form, Project Emails, and self-hosting docs now describe conditional Cloud `EMAIL_SERVICE` delivery, explicit missing-service failure, and self-hosted integration requirements (`61fcf3f3d5`); published staging behavior remains unverified. - [x] Document Cloud Email attachment count and encoded content/request limits in Form docs (`61fcf3f3d5`). - [x] Document provider/quota errors and the Cloud email hosting requirement. Builder Form, Project Emails, and self-hosting docs cover new-Form visitor behavior and hosting limits. Sending-domain setup and companion SaaS deployment are tracked in the companion SaaS PR. - [x] Refresh the current bundle-version metadata in all eight static project fixtures and synced user metadata in seven; `packages/protocol/src/fixtures.test.ts` passes 17/17 locally and Linux/Windows fixture CI both pass on head `70a2091c69`. - [x] Complete relevant local checks on current PR work. Focused tests, typecheck, lint, formatting, and diff checks pass locally; full GitHub CI passes on `84f24e8d12`. - [x] Reviewed each new-Form issue row against current code/tests; no additional legacy compatibility beyond the explicitly tracked #5512/#3891 route/query fixes is a closure condition. Evidence: #3023 file and attachment checks in `packages/sdk/src/managed-form-email.test.ts` and `packages/cli/src/prebuild.test.ts`; #5512 and #3891 page parameters and all query values in `packages/cli/src/prebuild.test.ts`; #5432 repeated multipart values/files in the same generated-route suite; #5499 parallel destinations and five-recipient preflight in `packages/sdk/src/managed-form-handler.test.ts`, `managed-form-resources-generator.test.ts`, and `managed-form-submission.test.ts`; #3530 redirect behavior in `packages/sdk-components-react/src/native-form.browser.test.tsx`; #5428 trusted browser info headers in `packages/cli/src/prebuild.test.ts`; #5658 sender/reply-to validation in `packages/sdk/src/managed-form-email.test.ts` and the companion SaaS Worker tests; #6487 feedback scrolling in `packages/sdk-components-react/src/form-feedback-scroll.browser.test.tsx`; #4414 and #4385 project defaults, overrides, and recipient isolation in `packages/sdk/src/email-resource.test.ts` and `apps/builder/app/builder/features/settings-panel/resource-panel.test.ts`; #5018 unique submission references and retry behavior in `packages/sdk/src/managed-form-submission.ts` and `managed-form-email.test.ts`. These are merge-time issue mappings, not production delivery evidence. ### Acceptance criteria - The insert menu offers one new Form. Deprecated old components and their migration are outside acceptance; no legacy compatibility path is added. - Staging end-to-end coverage exercises an empty Form blocked from navigation and a configured Form submitting to its Resource destinations, plus two HTTP Resources, two Email Resources, files, confirmation, and partial failure through Builder → publish → submit. - Form, Resource, Project Emails, and hosting docs match the released behavior, including the Cloud email requirement. Generated contracts, focused checks, full CI, and staging tests pass before the PR is ready. ## Batch 8 — Submit current-draft Forms from Builder Preview - [x] Add an authenticated Builder server endpoint for Preview submissions. It checks the Builder session and exact project build permission before effects; route tests cover authorized and rejected requests. - [x] Load current draft Form configuration and invoke the shared SDK runtime handler without a prior publish or draft/published contract comparison; Preview route and graph tests cover changed drafts. - [x] Build the draft Resource graph with publish-equivalent scope, dependency, and defaults rules. Reuse the existing `evaluateExpressionSync` implementation for supported expressions; do not add QuickJS, WASM, AST, or another expression engine. Focused graph and expression tests cover parity. - [x] Reuse the shared SDK managed-form handler in Builder Preview and generated published-site routes. Their request, auth, and configuration entry points remain runtime-specific; SDK and generated-route tests cover both paths. - [x] Execute HTTP Resource Actions from the Builder server in Preview, and from the published-site Worker after publish. The Email Service handles email only; Preview route tests assert the outbound HTTP boundary. - [x] Route Preview Email Resources server-to-server through the Email Service with a server-only credential; published-site Workers use the private `EMAIL_SERVICE` binding. Builder checks user and project permission first; tests cover the Email Service call contract and rejected auth. - [x] Removed the unapproved Preview warning that submissions send real emails and webhook requests; new user-facing warning copy requires explicit approval. - [x] Node tests execute the shared handler locally with a stubbed Email Service boundary, without Cloudflare infrastructure. Staging published-Form Email delivery is verified in Batch 7; the production Worker limiter check is tracked in companion SaaS PR #666. - [x] Keep a permanent Builder Preview transport Playwright E2E that submits a current draft through the Preview backend and verifies the response without publishing or triggering email/webhook side effects (`apps/builder/e2e/tests/preview-managed-form.[shard-2].e2e.ts`; focused 2/2). - [x] Preview converts rejected `onManagedSubmit` callbacks into a structured 500 failure, clears stale result and pending state, and shows the current error. Browser regression covers a prior structured failure followed by a rejected callback (`packages/sdk-components-react/src/native-form.browser.test.tsx`). The new Form also cancels native submission when its `onSubmit` callback throws; a Chromium browser regression clicks a submitter with `formAction`/`formMethod` overrides and verifies cancellation, no Resource dispatch, and visible failure (`28f7a93eed`). ### Acceptance criteria - A Form in an unpublished project can be submitted from Builder Preview without publishing first. - The Preview endpoint rejects unauthenticated users and users without edit access to that project before any HTTP request or email send occurs. - Preview uses the current draft. Changes to controls, Actions, Resource dependencies, effective email settings, visitor-addressed Email Resources, or redirects can be tested immediately without republishing or a published-contract comparison. - Draft expression results match published Resource evaluation for supported syntax using the existing `evaluateExpressionSync` implementation; no second expression engine is introduced. - HTTP Resource requests go directly from the Builder server to their configured destinations. Email Resource requests go through the central Email Service Worker, which rejects requests without the server credential; that credential never appears in browser traffic. - Results, errors, uploads, response bindings, feedback, and redirects match published submission behavior while keeping the Builder open. - The generated published-site Worker continues to use the same shared handler and public visitor submission path, and calls Email Service through `EMAIL_SERVICE`. - Local Node E2E tests exercise the shared handler and Builder Preview authorization without Cloudflare; a separate integration check verifies the real Email Service contract. ## Production release boundary The production Email Service Worker was deployed at version `8769175b-15d2-4c09-a312-b78dc93fd2f3` under the user's explicit request to update the code and Worker to use `TRPC_SERVER_API_TOKEN`. An authenticated malformed validation request returned `400 invalid_request` before send; that request sent no email. This Builder PR makes no deployment to the live site; live-user Form submissions are outside its verification scope. ## Boundaries and known tradeoffs - No old-component migration, submission storage or history, account-wide email quota feature, CC/BCC, custom From address or customer sending-domain verification, HTML email, preview text, or separate branding editor. Builder Preview submission is included in Batch 8 and runs against the current draft without requiring publication; it is a real submission, not a separate email test-send feature. Cloudflare account sending quotas still govern delivery; migrating Plunk authentication or other Plunk operations is separate follow-up work. - The Discord requests for an explicit CAPTCHA challenge, direct Google Sheets connection, multi-thumb/vertical slider, and an exact submission copy to an unverified visitor are not covered here. A visitor-addressed Email Resource always gets the fixed platform preamble and site URL; its optional builder-configured body may use normal Resource bindings. - A timeout retry can duplicate a delivery that succeeded remotely. A visitor-addressed Email Resource can send to an unverified submitted address; the native Email Service limit of 50 recipient checks per project UUID per Cloudflare location per minute can reject legitimate local bursts; it is approximate and not a global cap. - The five team-delivery cap is a server preflight across the whole Form; it is intentionally not calculated across independent Resources in the Builder. - Project defaults apply site-wide. Form-only expressions resolve only in Resources scoped inside that Form. ## Additional Builder and Resource behavior ### Builder UI - [x] Add the `formState` bullet to the Action tooltip after the exact user-facing description is approved; verify it with the focused tooltip test. The exact wording was approved; covered by focused Action tooltip tests. > Sends each form submission to all selected destinations at the same time. > - formData — submitted fields from this Form. > - browserInfo — visitor details. > - formState — current Form state: initial, success, or error. > - results — each action’s response, in order. > - errors — failed actions and their messages. - [x] In the Variables list and Edit variable preview, show server-provided `browserInfo` after an authenticated Builder Preview submission when available. Use only trusted `cf-connecting-ip`, ignore spoofed `x-forwarded-for`, and sanitize Referer by removing query and fragment before exposing it. Keep `previewBrowserInfo` private to Builder memory and strip it before Canvas pubsub. Route, bridge, Variables list, and Edit variable preview tests cover these paths; focused preview tests pass (2/2) and bridge tests pass (7/7). Published Form behavior stays unchanged. - [x] Recognize supported Chromium browsers without requiring `window.chrome`; user-agent detection and unsupported-browser regression coverage are committed. - [x] Add the approved “Clear all” button below multiple visible toasts and dismiss the stack; shared toast implementation and browser regression are committed. - [x] Remove the background from the maximize button in code and expression editors; keep the icon button transparent, consistent with other editor controls. `code-editor-base.browser.test.tsx` verifies transparent hover styling. - [x] Implement separate tooltips for the Form variables `formData`, `browserInfo`, `formState`, `results`, and `errors`; exact wording was approved on 2026-10-08, and `variables-section.test.tsx` verifies the displayed descriptions. - [x] Add a description to the Action label tooltip and show a yellow warning triangle with “Add at least one action” when the Action list is empty. The warning disappears once an Action is added; covered by the Form Action control browser test. - [x] Reset the Form Preview runtime state to `initial` when leaving Preview, so the Builder returns from success/error feedback to the editable Form state without changing saved bindings or published behavior. Add regression tests. - [x] Route every managed Form submission error through the user-styled Error Message instance. Make its message dynamic from the submission error result, remove static fallback text and raw React alerts, and cover validation, partial Action failure, and service errors. - [x] When a Form, Form content, Success Message, or Error Message instance is selected on the canvas, show that selected instance in Builder regardless of its bound `show` value. This is an editor selection override only; preserve the saved binding and runtime behavior. Add regression tests for each state. - [x] Add the approved description “Sends each form submission to all selected destinations at the same time” and a multiline list for `formData`, `browserInfo`, `formState`, `results`, and `errors` to the Action label tooltip; use lowercase “action” in descriptions. Remove the aggregate `status` variable; Form state remains `initial`/`success`/`error`, and each Action’s HTTP status stays in its result/error entry. Retain the approved “Add at least one action” warning when no Action is selected. The Action reset button says “Reset.” Focused insertion and Action UI tests cover these behaviors. - [x] The Action plus-button tooltip says “Add a resource to submit this Form”; the focused Form Action control browser test covers it. - [x] Rename the Form’s component prop from `submission` to `action`, matching the singular Action control. Store selected Actions as an ordered array of Resource references with enabled state. Execute enabled requests in parallel while preserving Action order in `results` and `errors`. Update generated metadata, runtime handling, and tests; do not add legacy compatibility. - [x] Add Delete, Copy, and Paste to each variable row menu and its right-click context menu. Within Variables, right-click anywhere allows Paste; target-specific commands are disabled without a variable row. Remove the Variables section header menu. The Edit variable dialog menu has Delete, Copy, and Refresh only; remove its redundant quick-copy button and do not offer Paste there. Serialize definitions as versioned, namespaced JSON; omit internal IDs, create fresh IDs on paste, preserve and remap expression references, and report unresolved references. Base menu and transfer tests pass. - [x] Rename user-facing Builder UI section and control labels from `Data variables` to `Variables`; retain `CSS variables` for clarity. Update UI tests. - [x] Give variable labels a tooltip that shows defining scope, type/value-kind details, and Delete with its shortcut. Option-click deletes the local variable; deleting a shadow reveals its ancestor. UI tests cover the tooltip and Option-click deletion. - [x] Clicking the rendered “Value comes from” source label navigates to and focuses its defining instance. `variables-section.test.tsx` exercises the real ancestor “Body” source label and Global root label; the full focused file passes 9/9. - [x] Label a Global Root user variable source as “Global root,” not “System,” and keep the source label clickable to navigate to and focus its definition. `variables-section.test.tsx` verifies the “Global root” label, absence of “System,” and source navigation. - [x] Fix the verified source-label behavior defect: clicking “Value comes from” must reliably focus its defining Variables row after ancestor or Global root navigation. Regression tests pass both standalone and in-suite: `variables-section.test.tsx` passes 12/12, and isolated ancestor/Global root navigation-focus cases pass 3/3 each. - [x] Prevent deletion of the managed Form’s required `formState`, `results`, and `errors` variables by stable identity in the Builder UI, including after renaming, through Variables row menus, the Edit variable menu, right-click context menus, and Option-click; ordinary user variables remain deletable. `variable-menu.test.tsx` covers the menu paths and ordinary deletion; focused suite passes 21/21. The required-variable rule is enforced in both the Variables UI and the mutation/domain layer. - [x] Show a yellow warning triangle only when a variable name matches an ancestor; allow the child-scope name. Tests cover an existing shadow and an ancestor rename. - [x] Keep the variable row highlighted while its Edit variable dialog is open; use the shared list-row open state and cover it with a regression test. - [x] Use the shared warning color token for variable-shadow triangles in both the Variables list and Edit variable dialog; the Builder UI test verifies the token. - [x] Reject duplicate Resource variable names on the same instance while allowing a nested scope to shadow a parent name; add validation and regression tests. - [x] Use sentence case for the Form setting label: `Success redirect`. - [x] Expose Form-scoped runtime values as inspectable JSON in Builder Preview. `formData` reflects the current named controls and values before submission, including empty values; `browserInfo` shows its safe context values. Add focused UI and runtime tests. - [x] Add `resourceName` alongside `resourceId` in each ordered result/error and relevant inspection entry; verify naming, partial failure, retries, and bindings without exposing secrets. - [x] Independently rechecked #3891 against the implemented contract: `system.search` returns a string for one value and an ordered array for repeated query values. `packages/sdk/src/system-search.ts` and its regressions cover repeated, empty, comma-containing, and encoded values; Batch 2a retains the generated-route and documentation evidence. - [x] Verify that a selected Email Resource defined on the Form, an ancestor, or global scope uses the existing generated submitted-fields default body when both its Resource body and Project Emails body are unset. Preserve explicit Resource/Project body overrides, including an explicitly empty Resource body, Visitor receipt behavior, and rejection of explicit out-of-scope `formData` bindings. Draft and published graph tests cover all three scopes and both override types in `managed-form-resources-generator.test.ts` and `managed-form-draft-graph.test.ts`; focused SDK tests pass (73 tests). ### Resource editor - [x] In Project Settings → Emails, show all long explanations in the existing info tooltips beside their related controls, preserving the exact existing copy. Specifically verify the Recipients and Owner plain-text body explanations; `section-emails.test.tsx` currently covers tooltip content and keyboard access. - [x] Restore the approved attachment behavior sentence in the Project Settings → Emails documentation, in the Visitor email paragraph only: “When a Form includes file inputs, submitted files are attached to the outgoing Email Resource message by default. Turn off ‘Attach submitted files’ to omit them.” Do not add this text to the settings UI. Added in `c96fb7c409`; `pnpm check:generated-docs` and `git diff --check` pass. - [x] Replace the outdated Visitor attachment statement in the Form guide with the same approved sentence used in Project Settings documentation: “When a Form includes file inputs, submitted files are attached to the outgoing Email Resource message by default. Turn off ‘Attach submitted files’ to omit them.” Added in `40dd8c4af3`; `pnpm check:generated-docs` and `git diff --check` pass. - [x] Email Resource Type description: The exact description was approved, and `variable-popover-type.test.tsx` asserts the Email option displays “Send a plain-text email through Webstudio Cloud when a Form is submitted.” Focused type-selector suite passes 7/7; Builder typecheck passes. - [x] Method dropdown copy approval: Exact copy is approved and tested: GET “Read data from a server.”; POST “Send data to create or process something.”; PUT “Replace data on a server.”; DELETE “Delete data from a server.” Keep the existing Form-submission note with POST; focused Resource editor tests verify all four descriptions and the POST note. - [x] Keep Email Resource field labels as `Sender`, `Recipients`, `Subject`, and `Body`; use the existing binding control and Expression Editor for supported values, and show validation errors in the standard input tooltip rather than below the field. `resource-panel.test.ts` asserts each label appears exactly once, covers the binding controls and Sender/Custom recipient Expression Editor save/unmount/remount/reopen, and verifies validation errors appear in standard input tooltips; the focused suite passes 30/30. - [x] Give Email Resource recipient controls programmatic accessible names by associating the existing visible “Recipients” label with its selector and using existing text for the Custom recipient input and Visitor email selector. Keep visible copy unchanged. `resource-panel.test.ts` passes 32/32; Builder typecheck, changed-file `oxlint --deny-warnings`, and `oxfmt --check` pass. - [x] Remove the separate Project default reset button; switching away from Custom recipients clears its value. Show the custom address input directly below the mode selector and the Visitor field selector without redundant field labels. `resource-panel.test.ts` covers literal and bound recipient clearing when switching to Project and Visitor modes, mode-specific controls, and no duplicate Recipients label; the focused suite passes 30/30, including Sender and Custom recipient bindings through the Expression Editor and save/unmount/remount/reopen. - [x] Verify and test the REST and GraphQL type-option descriptions against the approved wording: “A REST resource is a configuration for secure data fetching.” and “A GraphQL resource is a configuration for secure data fetching with GraphQL.” Preserve the existing “You can safely use secrets in any field.” note. `variable-popover-type.test.tsx` covers both descriptions. - [x] Visitor email field info tooltip: Approved exact copy for the info tooltip beside the Visitor email field selector: “Adds a note with this site’s URL to help recipients identify where the message came from and discourage spam.” Keep it visible only when Visitor email field is selected; verify the text opens on hover and keyboard focus and closes on blur in `resource-panel.test.ts`. - [x] Match the Edit variable dialog menu trigger icon size to the other header controls and make the menu’s minimum width about twice its current width; `variable-menu.test.tsx` covers the header icon and 360px minimum width. - [x] Simplify Builder Email Resource preflight: remove duplicated Worker-authoritative mailbox and attachment metadata policy checks; retain a small pre-Base64 attachment size guard, subject safety, and aggregate recipient protections. Tests verify early size rejection, valid attachment delivery, and Worker rejection propagation. - [x] Replace the superficial Headers and Search params label info-tooltip descriptions with clear technical explanations of their purpose; propose and obtain approval for exact user-facing copy before implementation. The approved label info icons explain these sections; no additional plus-button tooltips are needed. Exact wording approved; covered by focused Resource editor tests. - [x] Recipient selector descriptions: Add the approved descriptions exactly: Project recipients — “Send to the addresses in Project Settings, or to the account holder if none are set.”; Custom recipients — “Send to the addresses entered below.”; Visitor email field — “Choose a Form input to use as the recipient’s email address.” Verify copy and visibility in `resource-panel.test.ts`. - [x] Move Visitor email guidance into its recipient option description: Removed the extra info icon next to the selected Visitor email field input. The Recipients dropdown option now explains that the confirmation email goes to the selected Form input address. `resource-panel.test.ts` passes (41/41); formatting, lint, and diff checks pass. Pushed as `a85c77308f`. - [x] Put the Form POST-method note in Method dropdown option descriptions instead of inline copy; keyboard and pointer behavior are covered by the Resource editor tests. - [x] Format option descriptions: Approved exact copy: label `Format`; help below the control “Choose how to send the body.”; `auto` — “Uses text/plain for text values, application/json for other values, and multipart/form-data when files are included.”; `application/json` — “Sends an object or array as JSON.”; `multipart/form-data` — “Sends fields as form data, including files.” `resource-panel.test.ts` verifies the descriptions, below-control help, standalone GET hiding, Form Action GET visibility, and Body editor; the focused suite passes 34/34. - [x] Headers and Search params add-button tooltips: Superseded by the user's clarification: the approved info icons beside the Headers and Search params labels explain those sections, so no additional tooltips on the plus buttons are needed. The existing info-icon descriptions remain covered by the focused Resource editor tests. - [x] Project Settings → Emails helper-text placement: Move the long inline explanations (including Recipients and Owner plain-text body help) into adjacent info tooltips so the settings stay compact. Do not add or rewrite user-facing copy without explicit approval; preserve approved behavior and cover tooltip placement with focused tests. - [x] Shadowing warning tooltip copy: Reverted the unapproved proposed wording and retained the existing tooltip. `variables-section.test.tsx` verifies the parent-scope shadow condition, including an existing shadow and an ancestor rename; a unique name removes the warning. - [x] Add an info tooltip beside Cache max age explaining the response cache lifetime in seconds. A focused Resource editor test verifies it. - [x] Use the approved info icons beside the Headers and Search params labels to explain those sections; no additional plus-button tooltips are needed. Use Minus icons to remove individual rows. Focused Resource editor tests cover the label info tooltips and row removal. - [x] Keep the Body label and remove the Body content type selector. Infer text/plain for string bodies and application/json for objects, arrays, numbers, and booleans; preserve automatic multipart handling for files, explicit request-format validation, and useful editor/error behavior. - [x] Label the body-format dropdown Format and show the approved help “Choose how to send the body.” below it. Use the effective method: hide Body and Format for a standalone GET Resource; a GET-configured Resource selected as a Form Action is effectively POST and keeps both controls visible. Focused editor tests verify the help placement, visibility, and selected body format. - [x] Show Response, Request, and Diagnostics tabs for HTTP Resources, with Response first and selected by default. Capture the actual outgoing method, URL, headers, and body plus response status/status text, headers, final URL when available, and body from the latest Form Preview submission, including retry attempts. `request-inspector.test.tsx` verifies the order and default selection, including the captured numeric response status and actual response body for both HTTP and Email exchanges (focused suite 7/7); route and inspector tests verify captured exchange data, no replay or substitution from current config, and authenticated Preview-only, no-store, ephemeral, bounded, redacted capture. Files show metadata instead of bytes. Email inspection shows the captured transport request and actual HTTP response, with credentials and encoded attachment bytes redacted; the logical delivery outcome remains separate for Form failure handling. Published staging submission and attachment delivery are verified in Batch 7. - [x] Classify Email inspection exchanges by Resource kind, never URL alone; focused sanitizer and inspector tests verify that an ordinary HTTP Resource targeting the Email Service URL keeps normal request-body redaction. - [x] Preserve actual Email Service response headers in the Email inspection Response view; `resource-loader.test.ts` verifies transport capture and `preview-form-inspection.server.test.ts` verifies safe headers reach the inspection view. - [x] Preserve the actual Email Service HTTP response body/status separately from the logical Email delivery result, so provider-level failures remain Form failures even when HTTP returns 200. Read the response body once so inspection and delivery validation share the same parse; keep captured data bounded. Add regressions for malformed success and non-JSON error responses. Single response read, bounded inspection snapshot, provider body and logical outcome regressions; SDK tests pass. - [x] Keep the Variables panel context menu scoped to the panel: right-clicking a variable row targets that row, blank panel space allows Paste, and right-clicking inside the Edit variable dialog does not open the panel menu. The dialog menu offers Delete, Copy, and Refresh only; `variable-menu.test.tsx` covers row, blank-space, and dialog context-menu behavior. - [x] Keep Email Resource attachments enabled by default. The default contact Form’s owner Action keeps attachments enabled, while its visitor confirmation explicitly opts out because it does not include the submitted file. `managed-form-email.test.ts`, `resource-panel.test.ts`, and the default contact Form E2E cover defaults and opt-out. - [x] Support bindings for Email Resource Sender and Custom recipients using the existing binding/Expression Editor pattern; evaluate and validate resolved mailbox values before dispatch. `resource-panel.test.ts` verifies Sender and Custom recipient bindings through the Expression Editor and save/unmount/remount/reopen (30/30). `email-resource.test.ts` verifies resolution and rejects empty, non-string, and invalid values; `managed-form-handler.test.ts` verifies invalid bound values are rejected before Resource fetch or email send (35/35 combined SDK tests). - [x] Memoize Email Resource recipient expression scope inputs (`recipientScope` and aliases) so editing a recipient value does not restart asynchronous expression evaluation on every render; add focused regression coverage. Unrelated Resource edit regression passes; `resource-panel.test.ts` 34/34. - [x] Make all Email binding tests use CodeMirror’s platform-aware Mod shortcut (Meta on macOS, Control elsewhere), including Sender/Custom recipient round-trip and Project-mode bound-recipient clearing, so they pass Ubuntu CI. `resource-panel.test.ts` contains no hard-coded Meta/Control keyboard chords and passes the full focused suite (30/30). - [x] Ensure generated server modules import Email binding helpers only once when both regular Resources and managed Forms use Sender or Custom recipients bindings; generated-site resource-only and combined-module tests in `packages/cli/src/prebuild.test.ts` assert one helper import (2/2), and the CLI typecheck passes. - [x] Ensure generated modules for generic (non-managed) Email Resources using `senderExpression` or `recipientsExpression` import the runtime resolver helpers. `packages/cli/src/prebuild.test.ts` verifies one helper import and typechecks a mixed generated site with page-level and managed-Form Email bindings, plus a page-level-only site; both focused cases pass (2/2). - [x] Enforce the five-recipient total before dispatch for Email Resources with Sender or Custom recipients bindings. Count known/literal recipients even when the Email Resource depends on another Resource; reject recipient expressions whose count depends on a Resource output before any send. Preserve Form-variable bindings. `managed-form-handler.test.ts` covers a resolved six-mailbox binding and verifies rejection before HTTP fetch or email send; existing dependency tests cover Resource-output counts. - [x] Prevent or support Email recipient expressions that depend on another Resource. The editor currently accepts these expressions, but managed-submission preflight rejects them; align editor validation and runtime behavior, with focused regressions. Editor binding scope now excludes Resource outputs; server preflight remains fail-closed; focused tests and Builder typecheck pass. - [x] Disallow Email recipient bindings that depend on another Resource in the Builder editor, while keeping server preflight fail-closed. Resolving dependencies before the recipient-limit check could trigger arbitrary requests; add focused editor and preflight regressions. Editor binding scope now excludes Resource outputs; server preflight remains fail-closed; focused tests and Builder typecheck pass. - [x] Fix Type and Recipients dropdowns in a narrow sidebar so each dropdown panel matches its input trigger width, using Name as the reference; focused tests cover Type, Recipients, and Method. Flattening removes the separate Resource dropdown. - [x] Flatten System resources into the single Type list: remove the separate “System resource” category/dropdown and list Sitemap, Current date, Assets, and Email alongside the other Type choices. When editing an existing System Resource, changing between categories (Sitemap/Current date/Assets ↔ Email) persists the selected type. Preserve existing Assets Resources whose URL expressions use valid non-JSON string-literal syntax; add a reopen regression in `variable-popover-type.test.tsx`. Assets non-JSON URL expression reopen regression passes; Builder popover tests pass. - [x] Fix the Builder typecheck failures in `resource-panel.test.ts` binding tests caused by nullable queried-button assertions, then rerun and pass the Builder typecheck. Builder typecheck passes and `resource-panel.test.ts` passes 30/30. - [x] Add a generated published-route regression proving that an unset/default Form Action body with an uploaded File selects multipart automatically and preserves filename, MIME type, and bytes. `packages/cli/src/prebuild.test.ts` runs the generated endpoint for both defaults and React Router adapters; the focused test passes 2/2. - [x] Add regression coverage that an ordinary Project/Custom Email Resource with `includeAttachments` absent resolves default-on through the Email Service payload. `packages/sdk/src/managed-form-email.test.ts` covers both recipient modes and asserts attachment payloads; the focused suite passes 29/29, and `pnpm oxfmt --check packages/sdk/src/managed-form-email.test.ts` passes. - [x] Resolve current changed-file lint findings (two `no-explicit-any` findings in changed tests and one `react-hooks/exhaustive-deps` finding in `variable-popover.tsx`), then rerun scoped lint. Changed-file `oxlint --deny-warnings` passes on 50 TypeScript files; `oxfmt --check` passes on all 48 matched changed files; Builder typecheck passes; focused settings/variables suites pass 47/47. - [x] Simplify `handleManagedFormSubmission` by removing the redundant one-Visitor-Email validation and relying on the shared `validateManagedFormRecipientLimit` check; add or retain focused preflight regression coverage. Handler and submission suites pass 48 tests, and SDK typecheck passes. ## Additional Form and Builder behavior - [x] Use the existing upload icon for the File input component: The shared `UploadIcon` is used in the File Input template and asserted by `core-templates.test.tsx`. - [x] Verify Success redirect in Builder Preview: On successful submission, keep navigation inside Preview for internal routes, resolve relative URLs against the previewed page, and navigate the preview frame for external URLs. Add end-to-end coverage for a matched internal route, an unmatched route (which currently silently does nothing), and hash navigation (which currently updates the hash without scrolling). Preserve error feedback and never redirect after a failed action. Matched internal, unmatched internal, and delayed hash target cases pass in Preview E2E; failed actions retain error feedback and do not redirect. - [x] Finish Email diagnostics loading: The Email Resource Diagnostics tab no longer remains pending without a request key; focused regression coverage verifies the settled empty state. - [x] Separate variable editors by type: The dialog composes focused modules for HTTP, GraphQL, Email, Assets, Parameter, and scalar types; shared controls remain neutral. Focused Builder tests and typecheck pass. ## Issue checklist Eleven issues below are intended to close when this PR merges; #5432 and #4093 are related but remain open. Each closure row must be implemented and verified first; keep remaining work unchecked. \| Issue \| Required result before merge \| Batch \| \| --- \| --- \| --- \| \| #3023 \| Configure file inputs in the Builder; deliver single/multiple files to HTTP destinations and Cloud email within documented limits. \| 3, 5, 7 \| \| #5512 \| Current-page parameters work in new and legacy Form Resource bindings, including after navigation. \| 2a \| \| #4093 \| Related issue for the legacy Webhook Form; this PR implements Resource Actions and response bindings in the new Form but does not change legacy submission beyond the explicitly tracked #5512/#3891 route/query binding fixes, shared lifecycle, or CLI conversion behavior. Keep #4093 open. \| 2, 3, 6, 6b \| \| #5432 \| The new Form sends repeated field values as standard multipart entries without losing selections. Legacy Webhook Form behavior remains unchanged except for the separately tracked #5512/#3891 route/query binding fixes; this PR does not close the original issue, and migration is separate. \| 2, 3 \| \| #5499 \| One submission can deliver to email and multiple HTTP destinations together; document the ten-destination and five-team-delivery limits. \| 2, 5, 6 \| \| #3530 \| A successful submission follows the configured redirect; failure does not redirect. \| 6 \| \| #5428 \| A destination receives the trusted visitor IP, user agent, and language through configured Resource headers, with setup documented. \| 2, 7 \| \| #5658 \| Custom subject and Sender work as agreed, with provider-level tests for From and Reply-To. \| 4, 4a \| \| #6487 \| New Forms reveal off-screen feedback, leave visible feedback alone, respect reduced motion, and do not scroll before redirecting. \| 6 \| \| #4414 \| Editable name/reply address, subject, plain-text template, and translated content work with project defaults and per-Resource overrides. Webstudio remains the sender, as agreed. \| 4, 4a, 5 \| \| #4385 \| Two forms in the same project can send to different configured recipients without changing each other's delivery. \| 4, 5 \| \| #5018 \| Separate new-Form submissions produce separate Gmail conversations; retries retain the same submission reference. \| 5a \| \| #3891 \| Every selected query value is available in new and legacy Form Resource bindings through `system.search`, with a single value remaining a string and repeated values becoming an ordered array. \| 2a \| - [x] After PR #6530 merged (`a49a6769bd`), verified the new Form needs no port: React Router and Remix use the same Form submit path, which creates fresh `FormData` and calls `set` once for the bot field on each request. `generates one fresh bot field for each managed submission` passes (shared browser suite 7/7); Router managed Form tests pass 2/2, Router refresh tests 7/7, and Remix refresh tests 5/5. # Related issues Closes #3023 Closes #5512 Related #4093 Related #5432 Closes #5499 Closes #3530 Closes #5428 Closes #5658 Closes #6487 Closes #4414 Closes #4385 Closes #5018 Closes #3891 Related #6520 — [Multi-step Forms with resumable local drafts](https://github.com/webstudio-is/webstudio/issues/6520) The existing Webhook Form bug #6437 and prior legacy-form fix #6436 are outside this new-Form feature and are not claimed as closed here. The old email planning PR #6486 is superseded by this description. - [x] Use the canonical server token for Preview email: The user confirmed the canonical `TRPC_SERVER_API_TOKEN` is supplied from Infisical in Preview and Production. Builder Preview now sends this token to Email Service `/v1/preview-send`; the redundant `EMAIL_SERVICE_PREVIEW_TOKEN` wiring is removed. Focused route tests verify authorization, missing-token behavior, webhook-only behavior, and redaction. - [x] Defer validation for a new Resource URL: Untouched blank URLs are not marked invalid until save; edited invalid values validate on blur. Regression tests pass. - [x] Handle safe public Resource redirects: Public GET/HEAD redirects are revalidated and allowed without forwarding credentials; unsafe destinations and cross-origin body requests remain blocked. Protected-fetch tests pass. ## Form component identity correction (2026-10-11) - [x] Keep component picker labels and compatibility behavior clear: show the new component as Form (Beta), and keep the existing Webhook Form available in its current Data category through the next release. Update the guide for the 10-Action limit and Navigation mode when Actions are empty. Builder component-list and registry template tests pass. - [x] Use one canonical managed component identity, `Form`, for Resource submission and Navigation mode. Keep `WebhookForm` only as the legacy component through the next release, and keep generic `Element` with tag `form` for native browser behavior. Update exports, metadata, templates, adapters, migrations, docs, CLI/MCP discovery, and E2E identifiers; verify saved projects migrate without changing legacy Webhook Forms. Project migration tests pass (25/25), and the CLI prebuild suite verifies saved bundles are migrated before rendering and endpoint generation. ## Framework-neutral Form core (2026-10-11) - [x] Move managed Form contracts, browser submission behavior, and server delivery into SDK Form entries. Keep React hooks/rendering in the React adapter and router refresh timing in the router adapter; preserve compatibility exports. Builder and CLI consume the dedicated server entry. StrictMode, cancellation, redirect fallback, and refresh-failure behavior have regression tests. SDK build and published types, SDK/React/router/CLI/Builder typechecks, focused SDK/React/router/CLI tests, generated route tests, and the browser bundle boundary check pass. Astra Medium reviewed the architecture and final diff; no remaining findings. ## SDK package boundaries (2026-10-11) - [x] Document each SDK package’s architectural role and dependency constraints. Added root READMEs for `sdk`, `sdk-cli`, and `sdk-components-registry`; clarified the existing React SDK, React component, Radix, Router, Remix, and animation package READMEs. Formatting and diff checks pass. ## Form submission lifecycle - [x] Handle rejected submissions when the controller refuses them: Consume abort-aware submission promises when a duplicate or disposed Form submission is refused. Regression tests cover both paths; four lifecycle tests, SDK typecheck, and diff checks pass. ## Unified Canvas selection reveal (2026-10-12) - [x] Reduce selection reveal metadata and resolver ceremony while preserving occurrence validation, owner/source boundaries, and focused coverage. Replaced ten one-element rule arrays with one optional rule each, removed the unused fallback field and redundant source union, combined selector validation with path construction, and bounded the source search. The optimization removes 24 production lines and 10 test lines (net), with the shared resolver and derived override layer intact. Focused Builder tests pass 66/66, Radix 20/20, registry 1/1; SDK, Radix, registry, and Builder typechecks, scoped lint, formatting, and diff checks pass. The nested Radix portal check uses a rendered harness rather than the full Canvas. Independent Astra Medium re-review found no correctness findings. Pushed commit `5bc392d3788ef004f9a35c9a12d82dab6087053a`; `builder-pr/whr.staging` SHA verified. - [x] Replace duplicated Radix Navigator selection handlers with declarative component metadata and one Builder-owned, occurrence-aware selection override resolver. Native Select, HeadSlot, and AnimateChildren hooks remain for their separate editor behavior. - [x] Reveal selected `ws:show=false` instances and ancestors through resolved prop overrides, including Form success/error feedback, while preserving normal published rendering. - [x] Resolve fixed `open` and effective item/tab `value` rules for Dialog, Popover, Tooltip, Select, Collapsible, Tabs, Accordion, and Navigation Menu. DialogOverlay retains its existing reveal behavior. Preserve unrelated memory props and Preview behavior. - [x] Verify resolver, lifecycle, nested Dialog portal mounting, Collection occurrence isolation, authored expression updates, and Canvas prop behavior. Local focused Builder suites pass 66/66; Radix 20/20; registry 2/2. SDK, Radix, registry, and Builder typechecks, scoped lint, formatting, and diff checks pass. Independent Astra Medium review findings were fixed and rechecked. Pushed commit `f8bb1078195e17704ed856c4334683584e983485`; `builder-pr/whr.staging` SHA verified. These are local automated checks, not live UI verification. ### Remaining Navigator hook migration - [x] Migrated every remaining Navigator hook consumer: native Option/Select and tagged `ws:element` use effective option values and HTML text fallback; HeadSlot uses a fixed self override; AnimateChildren uses a fixed override only for its exact selection. - [x] Removed Navigator hook implementations, `Hook`/`HookContext`/`InstanceData`/`InstancePath` and `getClosestInstance`, hook subscriptions and store, library registration, package hook entrypoints/build inputs, and the stale catalog hook capability field. - [x] Added behavior coverage for evaluated/bound native values, empty/zero values, HTML whitespace/NBSP fallback, repeated occurrences, nearest owner, stale selection, HeadSlot rendering, exact animation selection, Preview, deselection, and no saved-prop/memory mutation. Existing Radix runtime index behavior remains covered. - [x] Completed Astra Medium self-review and independent Astra High review. Fixed the High review finding: native fallback values must preserve non-ASCII whitespace. - [x] Final repository search found no remaining Navigator hook consumers or registrations. Validation: - `pnpm --filter @webstudio-is/builder exec vitest run app/shared/nano-states/selection-reveal.test.ts app/shared/nano-states/selection-reveal-render.browser.test.tsx app/shared/nano-states/components.test.tsx app/shared/nano-states/props.test.ts app/shared/nano-states/instance-selection.test.ts app/canvas/instance-selection-events.test.ts app/canvas/selected-instance-effects.test.ts` — 7 files, 84 tests passed; the final resolver rerun passed 14 tests after adding one additional authored-expression regression (85 tests across the same files). - `pnpm --filter @webstudio-is/project-build exec vitest run src/runtime/component-catalog.test.ts src/runtime/component-templates.test.ts` — 16 tests passed. - `pnpm --filter @webstudio-is/sdk-components-react-radix test` — 20 tests passed. - `pnpm --filter @webstudio-is/builder exec tsc --noEmit` — passed. - `pnpm --filter @webstudio-is/sdk --filter @webstudio-is/react-sdk --filter @webstudio-is/sdk-components-react --filter @webstudio-is/sdk-components-animation --filter @webstudio-is/sdk-components-registry --filter @webstudio-is/project-build typecheck` — all 6 packages passed. - `pnpm exec oxlint --deny-warnings` on all changed TypeScript files, `pnpm exec oxfmt --check` on all changed files, and `git diff --check` — passed. Native HTML options use the browser's effective value semantics (authored value or text); their runtime has no numeric index default. Radix items continue using their existing runtime index fallback. All three consumers migrated; no hook mechanism remains.	2026-10-14 20:03:07 +02:00
Oleg Isonen	2c51bc9928	fix: Restore Cloudflare publishing with Wrangler 4 (#6350 ) Publishing fails because Wrangler 3 cannot parse the JSON import attributes used by `html-tags@4`. Upgrade the CLI and Cloudflare template to Wrangler 4.130.0 and regenerate the fixture and lockfile used to package the publish artifact. Wrangler 4 also rejects Worker deployment when it finds the Pages configuration. Add a SaaS-only `wrangler.jsonc` that takes precedence over the Pages template's TOML configuration. Publish commands still supply the Worker name and compatibility date. Fix the staging smoke check's compatibility-date scope and shell expansion. - [x] Upgrade Wrangler and regenerate the publish fixture and lockfile. - [x] Reproduce the original parser failure and verify it passes with Wrangler 4. - [x] Build the packaged artifact and pass the staging smoke check and both SaaS publish dry runs, including dispatch-namespace arguments. - [x] Pass 383 existing template tests, CLI and fixture typechecks, repository lint, and all fixture generation from checked-in data. - [x] Review documentation impact: no user-facing documentation changes are required; the existing Node 22.12+ requirement remains sufficient. - [ ] Complete staging CI and manually test publishing. [Publish artifact build](https://github.com/webstudio-is/webstudio/actions/runs/34400149252) is running; [staging deployment](https://github.com/webstudio-is/webstudio/actions/runs/34400149301) is queued. Remix 2 still declares a Wrangler 3 peer dependency; the packaged production build and both publish dry runs passed with v4. Agent evaluations were not run.	2026-09-09 22:28:38 +02:00
Oleg Isonen	cb1a17dc9b	fix: Allow approved fork workflow checkouts (#6335 ) Approved fork workflows currently fail before tests start. GitHub rejects the fork-head checkout in the trusted `pull_request_target` context even after the `safe-to-deploy` label is applied. ## Implementation - Opt into the fork checkout for every reusable Main workflow job only when the event is a `safe-to-deploy` label approval. - Apply the same guard to the nested fixture workflow. - Keep normal pushes and regular pull request checkouts unchanged. ## Todo - [x] Guard all Main workflow checkouts. - [x] Guard the nested fixture workflow checkout. - [x] Verify the opt-in remains false for normal pushes and pull requests. - [x] Review documentation impact: no product documentation is affected. - [x] Review fixture impact: no fixture inputs or generated outputs are affected. - [ ] Merge this change into `main`, then reapply `safe-to-deploy` to the affected fork PR. ## Verification - [x] Prettier check for both changed workflows. - [x] `git diff --check`. - [x] Confirmed all seven Main checkouts and the fixture checkout use the guarded opt-in. ## Known limitation GitHub loads `pull_request_target` workflow definitions from the default branch. The repaired approved-fork run can only be verified after this change reaches `main`. Ref #6332 Ref #6329	2026-09-04 15:36:47 +02:00
Oleg Isonen	e33a269802	fix: show unsupported browser warning in a dialog (#6332 ) The unsupported-browser warning now uses the Builder’s regular modal dialog. Users can acknowledge it and continue, while the small-window state remains a blocking alert. Closes #6331 ## Implementation - Render the existing browser guidance and links inside the design-system `Dialog`. - Set the dialog to modal and keep close, Escape, outside-click, and Continue dismissal behavior. - Keep unsupported-browser detection, preview-mode suppression, and Builder-ready timing unchanged. - Keep the small-window alert blocking and remove its now-unused dismissible-alert path. - Add a focused Storybook state and browser regression test. - Increase Main and Visual Regression workflow job timeouts from five to seven minutes after otherwise healthy jobs were cancelled during slow dependency setup. - Run failed E2E diagnostics and service teardown through the backend shell script so cleanup does not depend on pnpm remaining on `PATH` after cancellation. - Route `safe-to-deploy` label events through one reusable gate that starts both Main and Vercel workflows. - Remove revision-specific deployment and visual approval labels in one synchronization-only cleanup job. - Reduce expected skipped jobs from 6 to 1 on a normal branch update and from 17 to 3 on a visual approval label event. No migrations or compatibility changes are required. ## Todo - [x] Replace the unsupported-browser alert with a modal dialog. - [x] Preserve the small-window blocking alert. - [x] Add regression coverage. - [x] Give CI enough time for slower dependency setup. - [x] Keep E2E cleanup available after runner cancellation. - [x] Simplify label-triggered Main and Vercel workflows. - [x] Consolidate revision-specific approval cleanup. - [x] Review documentation impact: no product documentation changes are needed for this presentation-only warning update. - [x] Review fixture impact: no fixture inputs or generated fixture outputs are affected. ## Verification - [x] Focused browser regression test - [x] Builder typecheck - [x] Oxlint on changed files - [x] Oxfmt and `git diff --check` - [x] Workflow YAML parsing and backend shell syntax checks - [x] Workflow trigger, nesting, permissions, and reusable-job contract assertions - [x] Prettier checks for changed workflows - [ ] Storybook screenshot review was not run locally because explicit visual-test approval was not available. ## Known limitations - The visual state was not screenshot-tested locally. - The reduced `pull_request_target` fan-out takes effect after these workflow files reach the default branch, because GitHub loads those workflow definitions from that branch.	2026-09-04 15:06:34 +02:00
Oleg Isonen	4273b7001f	refactor: Organize Builder development and test tooling (#6285 ) ## Outcome Builder development, backend, E2E, and CI tooling now share one ownership model: Builder defines named commands and backend modes, while CI only schedules those commands. ## Technical choices - Group shared Compose files, PostgreSQL initialization, and backend helpers under `apps/builder/backend`. - Resolve `compose.<mode>.yaml` by convention instead of maintaining Compose filename lists in scripts and workflows. - Keep persistent development and disposable test Compose projects separate by default, while allowing the standard `COMPOSE_PROJECT_NAME` override. - Make schema snapshots invalidate from discovered migration sources and backend files. - Move E2E behavior recipes into named Builder commands; retain concise root proxies for developer entry points. - Let Vitest allocate available browser ports instead of maintaining a cross-package port registry. - Keep test-suite scheduling explicit in `main.yml`, but move executable test commands to root package scripts. - Move fixture-size enforcement from inline GitHub JavaScript into a locally runnable repository script. ## Todo - [x] Consolidate Builder backend and Compose ownership. - [x] Add named development, E2E, schema-cache, Supabase, and CI-shard commands. - [x] Remove Compose topology and behavior flags from CI. - [x] Remove the static Vitest browser-port registry. - [x] Extract fixture-size checking from the workflow. - [x] Verify migration bootstrap, snapshot-backed E2E, tests, builds, types, formatting, lint, generated contracts, and workflow syntax. - [x] Review documentation impact: updated the E2E developer guide; no user-facing `docs/` content is affected. ## Verification - Full package, CLI, Builder core, and Builder app test suites - Full workspace typecheck - Builder production build - Schema-cache generation through the complete migration history - Supabase migration compatibility - Snapshot-backed Playwright animation workflow - Backend regression tests, including demonstrated fail/pass coverage - All four Compose mode configurations - `oxfmt`, `oxlint`, package boundaries, generated API, and generated docs checks - `actionlint` and Bash syntax checks The fixture-size checker preserves the existing Linux `du` thresholds. Its three inputs build locally; macOS allocation sizes are not directly comparable to the Linux CI thresholds, so CI remains the authoritative size result.	2026-08-31 21:09:54 +02:00
Oleg Isonen	8718feb465	test: simplify browser testing infrastructure (#6271 ) ## Summary Unifies frontend testing around three intentional boundaries: - Vitest Node projects for pure and server tests - Vitest Browser Mode with Playwright/Chromium for DOM and component tests - Playwright Test for Builder end-to-end workflows The Builder no longer uses jsdom. Ordinary E2E workflows use an automatically managed isolated `page` fixture; explicit contexts remain only for simultaneous identities and suite-scoped setup. ## Technical choices - Split Builder tests into one Node project and independent browser projects so each Chromium/Vite process has a bounded workload. - Added shared Browser Mode configuration for the affected SDK React packages. - Preserve the Builder's production top-window bridge ownership; Browser Mode uses explicit test-only installation seams. - Centralized Playwright context options and kept action/navigation timeouts bounded. - Validate Playwright filters before Docker, migrations, browser installation, or Builder builds start. - Preserve the first failed E2E attempt's report, traces, screenshots, and videos when CI retries a shard. - Split static checks, typechecks, CLI tests, core package tests, browser package tests, and Builder projects into parallel CI jobs with five-minute hard ceilings. - Distribute Builder E2E tests across ten isolated shards with two workers; parallel suites create unique per-worker setup data. - Reuse color contrast DOM/canvas samples so the exhaustive theme sweep takes about four seconds instead of timing out at 30 seconds. - The removed cost is jsdom behavior drift, oversized serial check jobs, and unnecessary E2E startup for empty selections. Real browser startup and E2E environment setup remain. ## Todo - [x] Split Builder pure/server tests from browser/component tests. - [x] Migrate Builder DOM tests from jsdom to Vitest Browser Mode. - [x] Migrate affected SDK React DOM tests to the shared Browser Mode setup. - [x] Remove jsdom annotations, dependencies, and compatibility setup. - [x] Replace ordinary manual E2E contexts with the isolated `page` fixture. - [x] Keep explicit contexts only for concurrent identities and `beforeAll` setup. - [x] Preserve setup authentication isolation from workflow pages. - [x] Add bounded Playwright action and navigation timeouts. - [x] Preserve first-attempt E2E failure evidence across CI retry. - [x] Reject empty E2E selections before expensive environment setup. - [x] Parallelize repository checks into bounded CI shards. - [x] Isolate parallel E2E setup data across workers. - [x] Remove the color contrast sweep bottleneck. - [x] Update E2E contributor documentation. - [x] Review product documentation impact; no user-facing product docs are affected. - [x] Run the full repository tests and typechecks. - [x] Run formatting, lint, package-boundary, generated-file, and fixture checks. - [x] Complete final correctness and simplification review. ## Verification - `pnpm --filter @webstudio-is/builder test` - `pnpm -r typecheck` - `pnpm lint` - `pnpm check:package-boundaries` - `pnpm check:generated-api` - `pnpm check:generated-docs` - `pnpm fixtures` - Design-system: 222 tests pass locally. - Builder: all seven Vitest projects pass locally. - The formerly slow E2E shard passes locally in 1m55s. - Full database-backed Builder E2E execution passes in CI. - All CI jobs pass; the slowest completed in 4m58s. - No fixture inputs/outputs or generated files changed. Ref #6270	2026-08-31 17:17:28 +02:00
Oleg Isonen	f6c524572d	feat: add Builder dark theme and rebuild colors ## Summary Rebuilds Webstudio’s color system, migrates the entire Builder to it, and introduces a complete dark theme. A small set of theme colors and contrast controls now drives the interface through relative CSS colors: ```text Theme colors and contrast ↓ Light/dark derivation bounds ↓ Derived color families ↓ Reusable semantic colors ↓ Component composition ↓ Builder interface ``` CSS is the runtime source of truth. Light and dark modes share the same theme inputs, so changing a theme color automatically updates its surfaces, content, borders, states, and component presentation. The refactor turns dark mode into a first-class Builder theme rather than a separately maintained palette. This is an atomic migration. Legacy color names and compatibility aliases will not remain after all consumers have moved. ## Scope - The color source, derivation model, semantic vocabulary, validation, typing, and Storybook overview. - Every design-system component. - Builder, dashboard, authentication, shared UI, Query Builder, stories, and tests that consume the legacy color scale. - Removal of the legacy Stitches color scale after its final consumer is migrated. - A complete dark theme across application UI while keeping authored canvas content independent. - Complete light and dark visual verification. - Unified browser-test infrastructure: Vitest Browser Mode for Design System browser contracts and standard Playwright Test for all Builder E2E workflows. Literal colors remain only where color is the actual content or belongs to a deliberately separate system, such as user-authored values, external previews, brand artwork, data visualization, functional canvas overlays, and source assets. Every remaining exception must have an explicit owner. ## Architecture decisions - Theme authors control six color families and three bounded contrast controls. - Relative CSS colors derive the rest of the system. - Dark mode changes derivation bounds instead of maintaining a second independent palette. - Components consume a small reusable semantic vocabulary. - Component states and exceptional presentation are composed inside components. - Builder-specific categorical meaning uses focused composite recipes, not intent semantics or a larger global vocabulary. - TypeScript validates public semantic CSS-variable names but does not generate runtime colors. - No token-manager dependency, compatibility aliases, or component-specific public color tokens. - A new semantic or theme variable is added only when existing semantics and local composition cannot represent a reusable cross-feature decision. ## Todo ### Color-system foundation - [x] Establish direct CSS as the runtime source of truth. - [x] Define bounded theme colors and contrast controls. - [x] Derive light and dark modes from the same theme inputs. - [x] Reduce the semantic inventory to reusable decisions and explicit accessibility pairs. - [x] Generate only TypeScript names for public semantic CSS variables. - [x] Validate layers, references, cycles, consumption, naming, generated types, and browser-computed contrast. - [x] Add the Storybook color-system overview and theme controls. - [x] Document the architecture and its relationship to the public Craft specification. ### Design-system migration - [x] Replace every active legacy color consumer in design-system components and Storybook chrome. - [x] Compose component states locally without component-specific public tokens. - [x] Preserve intentional preview and sample-content colors. - [x] Add complete positive, negative, warning, informative, and accent accessibility pairings. - [x] Validate light and dark scheme-bound references independently. - [x] Verify the design-system package with typecheck, lint, formatting, Storybook, and 222 tests. ### Inventory and contract - [x] Inventory all 319 legacy references across 107 Builder, Query Builder, story, test, and design-system files. - [x] Classify every reference as a direct semantic replacement, local composite recipe, documented literal exception, or removable code. - [x] Record the intentional authored-content, external-preview, functional-preview, data-visualization, brand, and source-asset exceptions. - [x] Treat the public semantic vocabulary as closed by default and justify any proposed addition by cross-feature reuse and accessibility need. - [x] Keep Builder code limited to typed public variables accepted by `cssVar()`. ### Theme infrastructure - [x] Add `system` (default), `light`, and `dark` application preferences. - [x] Persist the preference in existing client settings and resolve `system` through `matchMedia`. - [x] Apply the resolved scheme before paint and respond to operating-system changes. - [x] Expose the persisted theme control under View → Color scheme. - [x] Keep authored canvas documents independent from the application theme. - [x] Ensure portals, overlays, embedded surfaces, and third-party controls receive the correct interface scheme. ### Generic interface migration - [x] Migrate shared dialogs, project settings, notifications, controls, and Query Builder. - [x] Migrate dashboard, authentication, publishing, and shared application UI. - [x] Migrate the Builder loading state, topbar, sidebars, navigator, workspace, footer, settings, pages, alerts, and menus. - [x] Replace fixed interface literals alongside their owning surfaces. - [x] Remove the old scrollbar variable and hardcoded loading color. ### Style panel and style-source recipes - [x] Migrate ordinary style-panel inputs, labels, layouts, spacing, alignment, menus, property states, and value editors. - [x] Model style-source provenance, kind, interaction, and error as separate axes. - [x] Compose categorical style-source colors from neutral and accent-relative colors. - [x] Use negative semantics only for actual errors, not overwritten provenance. - [x] Reuse one feature-owned recipe across style-source controls, badges, menus, and values without adding global tokens. ### Canvas and editors - [x] Migrate canvas selection, reusable outlines, grid guides, resize handles, labels, badges, and overlays. - [x] Keep collaborator colors as data visualization while guaranteeing readable labels. - [x] Prevent Builder theme values from leaking into authored content. - [x] Migrate editor surfaces, selections, autocomplete, lint states, and tooltips. - [x] Derive syntax visualization from neutral and accent-relative colors; reserve intent colors for diagnostics. ### Explicit color domains - [x] Isolate external search and social previews from the application scheme. - [x] Preserve user-authored CSS values, functional color previews, and checkerboards. - [x] Review brand surfaces independently in both schemes. - [x] Document every retained literal in the exception ledger. ### Stories, tests, and legacy removal - [x] Migrate all affected Builder stories and tests. - [x] Replace the design-system test that intentionally references the legacy scale. - [x] Add theme-preference and scheme-resolution behavior tests. - [x] Remove the legacy `design-tokens.color` registry. - [x] Remove the Stitches `colors` scale and `rawTheme.colors`. - [x] Remove color-name conversion code that exists only for the legacy scale. - [x] Add a focused repository check that rejects legacy references. - [x] Confirm no compatibility mappings or deprecated aliases remain. ### Browser-test infrastructure - [x] Run pure Design System tests in Node and browser-dependent tests in Vitest Browser Mode with Playwright Chromium. - [x] Migrate all 79 Builder E2E workflows from the custom harness to standard Playwright Test. - [x] Replace filename-based shard discovery with standard Playwright sharding. - [x] Preserve clean-backend shard retries and upload Playwright failure artifacts in CI. - [x] Remove the custom runner, registry, and timeout infrastructure. ### Verification and documentation - [x] Compare light-mode visual regressions directly with `main`; review every difference rather than accepting snapshots wholesale. - [x] Add representative dark coverage for dashboard, Builder shell, style panel, dialogs, editors, canvas tools, and status states. - [x] Test default and extreme custom-theme presets. - [x] Verify semantic and categorical-recipe contrast. - [x] Test first paint, persistence, system changes, portals, and canvas isolation. - [x] Run affected tests, typechecks, lint, formatting, and Storybook checks. - [x] Review fixture impact; no fixture inputs or generated outputs are affected. - [x] Review authoritative `docs/` content and update it where needed. - [x] Review the final diff and make this checklist reflect delivered scope. ## Current verification - Design-system typecheck and generated-type freshness: passed. - Design-system tests: 222 passed, including the full theme-parameter contrast sweep and browser component coverage. - Builder typecheck and production build: passed. - Theme preference and scheme-resolution tests: 10 passed. - Scoped Oxlint, formatting, and diff checks: passed. - Design-system Storybook build and representative light/dark visual review: passed. - Builder E2E: 80/80 Playwright entries passed (setup plus 79 workflows). Ref #3818 Closes #6267	2026-08-30 03:24:56 +01:00
Oleg Isonen	58eaf8c7c9	fix: Publish docs independently of release smoke (#6120 ) ## Summary - finish the `publish` job after npm publication and exact registry-artifact verification - run packaged CLI verification in a separate `release-smoke` job - keep `publish-docs` dependent on successful release creation and package publication, but independent of post-publish smoke results - verify the Codex registration command through `webstudio connect codex --print` in CI instead of requiring an installed Codex client ## Root cause The release workflow ran post-publish CLI smoke verification inside the `publish` job. GitHub therefore marked package publication as failed whenever the smoke failed, even though npm publication had already completed. Because `publish-docs` declared `needs: [release, publish]`, GitHub skipped documentation publication. The recurring failure was the smoke invoking `webstudio connect codex` on a runner without the `codex` executable. ## Technical choices and tradeoffs Package publication remains strict: npm publication and exact registry visibility must both succeed before downstream jobs run. Post-publish smoke verification remains a red, visible release job and still uploads its diagnostic artifact, but it no longer changes the truthful outcome of publication or blocks docs. The Codex package smoke now validates the generated registration command without mutating a real Codex installation. The command subprocess boundary remains covered by the existing focused connect-command tests. No migrations or compatibility changes are involved. ## Todo - [x] Separate post-publish CLI smoke from package publication. - [x] Keep docs gated on successful release and registry publication. - [x] Make Codex connection verification deterministic in CI. - [x] Manually advance the `docs` branch to release 0.290.0. - [x] Review documentation impact: no product documentation update is required because this changes release automation only. - [x] Verify formatting, workflow syntax and topology, CLI tests, lint, and typechecking. - [x] Run the non-model release smoke and record the remaining unrelated failure. ## Verification - `pnpm exec oxfmt --check .github/workflows/release.yml packages/cli/scripts/release-smoke.ts` - parsed `.github/workflows/release.yml` with Ruby Psych - asserted the parsed workflow job graph with the repository's `yaml` dependency - `pnpm --filter webstudio exec vitest run scripts/release-smoke-registry.test.ts src/commands/connect.test.ts` — 22 tests passed - `pnpm --filter webstudio typecheck` - `pnpm exec oxlint packages/cli/scripts/release-smoke.ts` - `pnpm --filter webstudio test:release-smoke` — the corrected Codex path passed; the smoke later reached `preview.start` and failed on an unrelated current-main fixture error: `Project session is missing preview data: assetFolders` Fixture review: this change does not modify fixture inputs or generated fixture outputs. Closes #6119	2026-08-12 22:50:41 +02:00
Oleg Isonen	87968f40ff	fix: Improve MCP authoring and preview reliability (#6105 ) ## Summary Fix MCP reliability failures reported in ten issues against CLI 0.288.0 and 0.289.0: - keep every advertised array input schema client-valid, including compact and tuple schemas - report a text asset update as successful when its persisted revision and bytes confirm that the server committed despite a failed response - preserve standard package import resolution in generated React Router previews - upload variable WOFF2 fonts when callers provide the documented static font metadata shape - explain unmatched JSX as a stateless fragment syntax error - distinguish the `animation` component namespace from value helpers and reject unsupported CSS at-rules with an actionable validation error - forward optional session tools such as `download-asset` through top-level CLI shortcuts - isolate published generated-preview dependencies from parent workspaces - return structured screenshot failures when React Router production builds fail Sensitive visual regression checks also run automatically for organization-authored fork PRs. External fork PRs remain gated by `safe-to-deploy`. ## Root causes and implementation The MCP handshake compactor retained an array's type but discarded its `items` schema. Unconstrained and tuple arrays could also be advertised without `items`. Schema normalization now adds `items: {}` whenever an array omits it, while focused discovery retains complete constraints. Catalog coverage rejects every missing array item, including tuple schemas, and the handshake remains below its 200 KB budget. Asset content updates previously treated any failed response as a failed mutation, even when the server had already swapped the revision. Recovery now reads the current revision, compares the persisted bytes, and confirms the revision remains stable across the read. It returns the updated asset only when all evidence agrees. Otherwise it returns `ASSET_UPDATE_COMMIT_UNCERTAIN` with guidance not to retry blindly. Definitive 4xx responses retain their original errors. The generated React Router Vite config replaced the client and SSR resolver condition lists without explicitly retaining the standard `import` condition. Both lists now preserve `import`. The regression test generates a dynamic route, stages the built React Router SDK as a published dependency without the local `webstudio` source condition, and runs the generated build. Variable fonts are detected with `variationAxes`. Merging the documented static `style` and `weight` upload metadata into that detected variable shape made validation fail after the binary was read. Font override validation and shape-aware merging now live in `@webstudio-is/fonts`. The SDK delegates to that domain function, which validates the complete override before applying compatible fields, retains the detected static-or-variable shape, and keeps the detected format. Fragment parsing is stateless. Unmatched opening and closing tags now explain that every opening element must use the same closing tag or be self-closing, and that refreshing the session cannot repair malformed JSX. The `animation` binding is a component namespace, not a callable helper. Tool schema text, evaluation errors, and the MCP manual now separate component namespaces from value helpers. The MCP JSX `css` binding parses the final interpolated CSS with CSS-tree and recursively rejects selectors and unsupported at-rules such as `@keyframes`, while preserving supported declarations and case-insensitive `@media` rules. Keeping this validation at the external binding avoids changing internal component templates. CLI shortcut discovery previously omitted optional session tools even though the runtime registered their handlers. Shortcut discovery now includes the same optional tool categories as the CLI MCP host, while real top-level CLI commands keep precedence. Published generated previews could reuse a stale `node_modules` symlink into a parent source workspace. Only development manifests containing the local placeholder version may now reuse the CLI dependency tree. Published manifests replace symlinks with a local install and disable npm workspace discovery. React Router could report a bundler failure while its build command exited successfully outside CI, allowing screenshot startup to terminate without a structured result. Managed production builds now set `CI=1`, so the existing MCP error boundary receives the nonzero build failure and prints structured JSON. Visual regression authorization now distinguishes repository members from external contributors. Organization members' fork PRs run on open, synchronize, and reopen events; external fork code runs only from a `safe-to-deploy` label event, and a later commit does not reuse that approval. ## Implementation checklist - [x] Preserve valid array item schemas in compact MCP discovery - [x] Normalize tuple input schemas with an `items` fallback - [x] Keep the MCP handshake below its 200 KB size budget - [x] Cover the real `update-props` schema and oversized array compaction - [x] Reconcile failed asset-update responses against stable persisted content - [x] Reject recovery when a concurrent asset revision is detected - [x] Preserve `import` resolution in generated React Router client and SSR builds - [x] Build a generated dynamic route against a staged published SDK package - [x] Regenerate and verify affected React Router fixtures - [x] Preserve detected variable-font axes with documented upload metadata - [x] Add actionable unmatched-tag and unsupported-CSS validation - [x] Correct animation namespace guidance in tool discovery and errors - [x] Forward optional session tools through top-level CLI shortcuts - [x] Replace parent-workspace dependency links for published previews - [x] Disable npm workspace discovery for isolated preview installs - [x] Make React Router build failures return nonzero in managed previews - [x] Run visual regression automatically for organization-authored PRs - [x] Verify each regression test fails without its corresponding fix - [x] Review documentation impact and update the authoritative MCP manual plus generated outputs - [x] Confirm no database migration or compatibility migration is required - [ ] Run `pnpm evaluations` after explicit approval; not run because repository policy requires approval before agent evaluations ## Verification - `packages/cli/src/prebuild.test.ts`: 57 tests passed - `packages/cli/src/commands/schema.test.ts` and `mcp.test.ts`: 51 tests passed - `packages/project-build/src/runtime/components.test.ts` and `mcp.test.ts`: 194 tests passed - `packages/asset-uploader`: 196 tests passed - focused font schema, SDK asset schema, CSS parser, and template CSS tests passed - `packages/http-client/src/index.test.ts`: 38 tests passed - relevant CLI, project-build, asset-uploader, fonts, SDK, CSS data, template, HTTP client, and React Router SDK typechecks passed - MCP documentation tests, typecheck, generation, and Markdown source tests passed - React Router SDK package build passed - full fixture link, sync, and generation pipeline passed - affected Docker and Vercel fixture typechecks and locally bootstrapped production builds passed - complete CLI suite: 61 test files and 966 tests passed - CLI typecheck passed - preserved nested-workspace dynamic preview installed local `0.289.0` dependencies and completed its production build - visual-regression workflow YAML parsing and authorization truth table passed - repository lint passed with warnings denied - formatting and `git diff --check` passed ## Tradeoffs and limitations Deferred array schemas advertise unconstrained `items` in the compact handshake to remain client-valid without duplicating detailed constraints. Agents can retrieve the complete item schema through focused `meta.get-more-tools` discovery. Asset reconciliation performs three read requests only after an uncertain 5xx, malformed response, or transport failure. This keeps the normal successful path unchanged and avoids claiming success if the revision changes during recovery. For variable fonts, detected axes define the metadata shape. Static `style` and `weight` hints are ignored because they cannot be represented alongside `variationAxes`; compatible fields such as `family` still override detection. Native CSS keyframe authoring remains unsupported in fragment `css` templates. The tool now rejects it before rendering and directs callers to editable Webstudio Animation components instead of advertising a nonexistent callable helper. Published previews perform one isolated npm install when no valid local dependency tree is cached. Local source development keeps the fast workspace symlink path for placeholder-version manifests. Closes #6104 Closes #6099 Closes #6098 Closes #6106 Closes #6107 Closes #6108 Closes #6114 Closes #6115 Closes #6116 Closes #6117	2026-08-12 21:23:35 +02:00
Oleg Isonen	db2d092268	ci: replace Lost Pixel with self-hosted visual regression (#6086 ) ## Summary Replace the defunct Lost Pixel service and the interim Chromatic workflow with a fast, self-hosted visual comparison pipeline. The workflow indexes the existing CSF stories without building Storybook, builds and serves a lightweight browser app with Vite, renders the merge base and current revision through Webstudio's shared browser tooling, and compares screenshots with Webstudio's pixel-diff and OCR engine. It uses GitHub Actions cache and artifacts only—no R2 bucket or external visual-testing service. Closes #6064 ## Implementation - [x] Remove the Lost Pixel workflow, configuration, acknowledgement, and global two-second wait. - [x] Remove the interim Chromatic workflow and settings. - [x] Extract source-agnostic capture, diff, OCR, audit, cache, and report tooling into `@webstudio-is/vision`; rename the Webstudio-specific preview boundary to `@webstudio-is/project-build/preview`. - [x] Expose the reusable browser capture session through the shared vision boundary. - [x] Make OCR and diff-artifact generation conditional on detected pixel changes. - [x] Render existing CSF stories through a typed, lightweight browser harness built with Vite. - [x] Replace the embedded HTML and handwritten HTTP/MIME server with a real HTML entry, Vite production build, and Vite preview server; isolate declarative build configuration in `story-build.ts`. - [x] Apply Storybook preview annotations, decorators, global CSS, backgrounds, and story metadata. - [x] Store story scopes as shared data and load each revision's own configuration. - [x] Discover changed, added, and removed stories from both revisions. - [x] Populate private story sources symmetrically in the baseline worktree. - [x] Isolate every story with a fresh React root and deterministic time, randomness, intervals, focus, animation, and layout readiness. - [x] Preserve story-owned visual options for masking, settling, and interval control. - [x] Reuse Vite preview servers, one Chromium process, grouped browser pages, production bundles, and a bounded CPU worker pool for image comparison. - [x] Recheck initial pixel differences with serial captures, then recapture persistent baseline/current pairs on the same browser page so renderer variance cannot create false failures. - [x] Report individual story render failures without discarding successful captures. - [x] Enforce a 0.1 per-pixel threshold and 0.001% total mismatch tolerance. - [x] Run OCR only for changed comparisons and include text-change evidence. - [x] Move the generic report model, writer, static viewer, and opener into the shared Vision package for reuse by CI and future CLI comparisons. - [x] Bundle report HTML, styling, and browser behavior as static Vision assets without runtime source-file lookups. - [x] Copy external screenshot inputs into self-contained report artifacts for CLI reuse. - [x] Handle cached removed-only comparisons without rendering the removed story on the current server. - [x] Support focused local reproduction and opening the report with one command. - [x] Pin CI to the lockfile's Playwright Chromium, cache complete revision screenshots with matching restore/save paths and automatically derived runtime invalidation, and render both revisions on a miss. - [x] Keep cache archives bounded to one revision instead of accumulating the cache history. - [x] Run the complete visual suite in one CI job and upload one report as a 14-day artifact. - [x] Fail PR checks on visual differences, empty runs, missing screenshots, missing or empty report artifacts, and infrastructure failures. - [x] Rerun fork checks when `safe-to-deploy` is added. - [x] Allow reviewed visual-only differences through `visual-change-approved` and invalidate approval after new commits. - [x] Keep capture, pixel diff, OCR, and report generation source-agnostic for future draft-versus-published project comparisons. - [x] Use Vite for the complete story HTML, module, asset, production-build, and preview-server lifecycle; inline the selected stories and skip ineffective tree-shaking to keep the cached run under one minute. - [x] Review Builder product documentation impact: no user-facing Builder documentation is affected; contributor usage is documented in `scripts/visual-regression/README.md`. - [x] Review fixture impact: no fixture inputs or generated fixture outputs are affected. ## Verification - [x] Project-build Vision tests, including the reusable report test, and entrypoint contract tests pass. - [x] CLI screenshot, preview, and browser-session tests pass. - [x] Project-build, CLI, Builder, design-system, and visual-runner typechecks pass. - [x] Visual runner tests pass (10), and the complete Vision package passes (79), including demonstrated fail-before/pass-after coverage. - [x] Full Storybook production build passes. - [x] Full local Vite run completes all 238 stories in 69.9s cold and 50.3s with a cached baseline plus two same-page serial verifications, with zero differences; identical-image comparison remains sub-second. - [x] The report writer passes a bundled-output smoke test and materializes external screenshot assets. - [x] The generated report validates all 238 entries and referenced images. - [x] Hosted cached-baseline comparison completes all 238 stories in 52.9s with zero differences; the cache-miss fallback completes in 101.3s. - [x] Cache-miss fallback renders both Git revisions on demand. - [x] Visual differences produce baseline, current, diff, OCR, JSON, and HTML evidence and fail without approval. - [x] Hosted single-job visual workflow restores both the pinned browser and baseline cache, validates all 238 public and private stories with zero differences, and uploads the report. - [x] The final Vite production build renders all 238 stories without dependency invalidation or duplicate React runtimes, and restores `NODE_ENV` so cached serial fallback installs the baseline's dev dependencies. - [x] Root lint, package-boundary validation, and relevant formatting checks pass. - [x] Workflow YAML parses successfully. - [x] `git diff --check`, staged-diff review, and final worktree review pass. ## Usage Run the complete local comparison and open the visual report: ```sh pnpm visual-regression:ui ``` Focus one component while iterating: ```sh pnpm visual-regression:ui -- --grep "Design system/Button" ``` Reopen the latest report without rerunning: ```sh pnpm visual-regression:report ``` The CI report is available as the `visual-regression-report` artifact. ## Tradeoffs - Baseline screenshots are a disposable acceleration cache, not source of truth. A missing or invalid cache renders the merge base directly from Git. - GitHub artifact storage provides downloadable one-click reports; permanently hosted browser links would require another hosting surface. - OCR runs after pixel triage because invoking Tesseract for every unchanged story would make the common path unnecessarily slow. - Vite production builds add Rollup's module graph and HTML/asset pipeline. The runner emits one bundle because every selected story is rendered, and skips tree-shaking because it removed little while increasing build time. - The verified local path is 50.3s cached and 69.9s cold. The hosted path is 52.9s cached and 101.3s cold. A new browser/runtime cache must render its baseline once; the pinned browser keeps later runners on the reusable path. - The complete suite stays in one Actions job; browser-page concurrency is internal and bounded.	2026-08-12 10:55:52 +02:00
Oleg Isonen	93fa799cb8	fix: Preserve SSG exports with Assets queries (#6102 ) ## What changed - Preserve the SSG asset-resource template as a package-relative file URL in the bundled CLI. - Ignore Assets queries that do not bind any parameters from the current dynamic SSG route, while retaining the error for partial or split multi-parameter bindings. - Recognize the persisted `$ws$system.params.*` expression form when enumerating dynamic SSG paths. - Add a required package smoke test that deploys the release-shaped SSG package, runs the packaged CLI, runs Vite and Vike, and verifies rendered Assets data. ## Why Two gaps caused the staging export failures: 1. Vite inlined the template URL as a `data:` URL, which Node could not pass to `readFile`. 2. Dynamic-route validation treated an unrelated Assets query as an incomplete route enumerator. The initial smoke test only checked that an HTML file existed and could pass while resource loading logged a `400`. The replacement test verifies the rendered query result and fails on resource-loading errors. ## Technical choices - The package smoke uses `createPublishedProjectBundleFixture`, so fixture data stays checked against the published bundle contract. - Persisted expressions use `encodeDataSourceVariable`; the generated query now receives the real route parameter instead of compiling to `undefined`. - Temporary deployment, cleanup, subprocess execution, and assertions live in `test:ssg-package`. The workflow invokes one repository command. - Asset downloads are disabled to keep the smoke deterministic. It still covers CLI packaging, the embedded Assets index, dynamic path enumeration, generated resource execution, Vite compilation, and Vike prerender. - The test asserts the queried title in `/posts/hello-world`, rejects any resource-load error, and verifies that an unrelated query does not invent a dynamic path. ## Todo - [x] Reproduce the invalid URL scheme through a bundled template reader. - [x] Preserve the package-relative template URL in the production CLI bundle. - [x] Ignore Assets queries unrelated to the current dynamic route. - [x] Preserve rejection of incomplete multi-parameter route queries. - [x] Support persisted system-variable expressions during route enumeration. - [x] Add a production-shaped packaged CLI and Vike smoke test. - [x] Make the packaged SSG smoke test required on `main`. - [x] Run CLI tests, typecheck, lint, build, and the packaged smoke test. - [x] Rerun the previously failing `WEBSTUDIO-LANDING` SaaS SSG workflow. - [x] Review documentation impact; no user-facing documentation changes are needed. - [x] Review fixture impact; synced fixture inputs and generated outputs are unaffected because smoke data exists only in a temporary deployment. ## Verification - `pnpm --filter webstudio test` — 61 files, 977 tests passed before the final test addition - `pnpm --filter webstudio test -- prebuild.test.ts ssg-asset-resource-fetch-template.test.ts` — 57 tests passed - `pnpm --filter webstudio test:ssg-package` - `pnpm --filter webstudio typecheck` - `pnpm lint` - `pnpm --filter webstudio build` - Package regression proof: the smoke failed on the original unrelated-query implementation with `Dynamic SSG route parameters must be completely enumerated by one Assets query`, then passed with the fix restored. - Persisted-expression regression proof: the focused test returned no prerender path before encoded-system support, then passed with the support restored. - Template regression proof: the focused bundle test failed with `ERR_INVALID_URL_SCHEME` before the fix and passed after it. - Exact SaaS E2E rerun passed: project sync, CLI build, Vike build, archive upload, and database update ([run 31519515809](https://github.com/webstudio-is/webstudio-saas/actions/runs/31519515809)). Closes #6100 Supersedes #6101 after moving the change to the staging branch.	2026-08-11 20:56:12 +02:00
Oleg Isonen	50958a68b3	ci: Restore safe-to-deploy workflows (#6054 ) ## Summary Restore CI, visual testing, and Vercel preview workflows for reviewed fork pull requests after `actions/checkout` began refusing fork code in `pull_request_target` jobs by default. The affected workflows now also use Node 24-compatible action releases, and the shared Builder E2E artifact is retained long enough for delayed failed-job reruns. Closes #6053 ## Root cause Applying `safe-to-deploy` still triggered the intended workflows, but each job stopped at checkout with: > Refusing to check out fork pull request code from a `pull_request_target` workflow. The label is the repository's explicit human-review gate for trusted fork code, but the checkout steps did not pass the action's new explicit opt-in. A later failed-job rerun also could not download `builder-e2e-build` because its one-day retention period had elapsed. The affected JavaScript actions additionally targeted the deprecated Node 20 action runtime. ## Implementation - Opt into fork checkout only when the event is `pull_request_target` and the applied label is exactly `safe-to-deploy`. - Apply the opt-in to Main, Chromatic, Visual Regression Tests, and Vercel staging checkout steps. - Gate `check-size` with the same push, regular PR, or reviewed-fork condition as the other Main workflow jobs. - Gate `deployment-host` so synchronize events only remove the approval label and do not check out fork code. - Upgrade the affected Checkout, Setup Node, pnpm setup, Cache, artifact, GitHub Script, and Chromatic actions to Node 24-compatible majors. - Retain `builder-e2e-build` for seven days so delayed failed-job reruns can download it. - Preserve existing push and normal `pull_request` paths. ## Security tradeoff `pull_request_target` jobs have base-repository credentials and secrets. This change deliberately permits fork checkout only after a maintainer applies `safe-to-deploy`; no other label or synchronize event receives the opt-in. ## Todo - [x] Reproduce and inspect the checkout failure on fork PR #6041. - [x] Add explicit checkout opt-in behind the trusted label. - [x] Gate previously unconditional jobs before enabling fork checkout. - [x] Upgrade affected JavaScript actions to Node 24-compatible releases. - [x] Keep Builder E2E prerequisites available for delayed reruns. - [x] Review documentation impact; no product documentation is affected. - [x] Verify fixture inputs and outputs are unaffected. - [ ] Verify the labeled fork path after this workflow version reaches `main`. ## Verification - `git diff --check` - Parsed all changed workflow and composite-action YAML files with Ruby's YAML parser. - Verified each upgraded action manifest declares the Node 24 runtime. - Verified `actions/checkout@v5` retains the `allow-unsafe-pr-checkout` input. - Audited every `actions/checkout` step in the affected `pull_request_target` workflows for the exact label guard. - PR checks passed for Main, Chromatic, Vercel staging, submodules, and PR title validation; Lost Pixel remains excluded from this fix. The live labeled-fork execution cannot be proven from this PR itself because `pull_request_target` loads workflow definitions from the base branch. It should be verified with a fork PR after this change reaches `main`.	2026-08-10 16:15:19 +02:00
Oleg Isonen	2ec78c183d	feat: Add single-result modes to Assets queries (#6040 ) ## Summary - Add `many`, `one`, `first`, and `last` result modes to Assets queries while keeping `many` as the backward-compatible default. - Return direct items for single-result modes, validate deterministic ordering, and report duplicate `one` matches as a structured `MULTIPLE_RESULTS` error. - Update Builder controls, preview/published runtime handling, SDK resource encoding, MCP/CLI guidance, generated contracts, and fixtures. ## Implementation TODOs - [x] Add result-mode schemas and core execution behavior. - [x] Select single results before content hydration and preserve deterministic ID tie-breaking. - [x] Add structured duplicate-match transport errors. - [x] Update Builder controls and hide/reset pagination for single-result modes. - [x] Keep existing settings first, then Output and Result, without a duplicate Return label. - [x] Preserve legacy saved resources with an implicit `many` default. - [x] Update preview, published runtime, SDK, protocol, MCP, and CLI behavior. - [x] Regenerate runtime contracts, server metadata, CLI docs, and fixtures. - [x] Review documentation impact and update the authoritative MCP/CLI guidance. - [x] Add regression coverage and verify the new tests fail without the implementation. - [ ] Run the agent evaluation suite (not run; requires explicit user approval). ## Compatibility and behavior - Existing queries without `result` continue to behave as `many` and retain the ID-keyed collection shape. - `one` returns an item or `null`, but fails when more than one asset matches. - `first` and `last` require explicit sorting; the existing asset-ID tie-breaker makes equal sort values deterministic. - Single-result modes ignore and do not persist pagination controls. Materialized collection queries remain collection-only; single-result queries execute dynamically. ## Verification - Content engine typecheck and full test suite (291 tests). - Query builder, query-builder React, SDK, protocol, asset uploader, project build, Builder, and CLI targeted typechecks/tests. - Root lint. - MCP documentation tests, typecheck, sync check, and generated-doc checks. - Generated API contract checks. - Fixture generation pipeline. - Final focused content-engine regression run (53 tests). - Final DRY review: affected typechecks, focused tests, lint, package boundaries, generated checks, and fixtures. Closes #6039	2026-08-07 19:13:19 +02:00
Oleg Isonen	1f4095cf9a	fix: Improve generated MCP documentation (#5991 ) ## Summary - render the generated MCP version as visible body content immediately below the page heading - keep the GitBook navigation label stable as `MCP` - stamp only the CLI version placeholder during release publication, leaving Markdown content owned by the template - remove empty `{}` blocks from the rendered MCP argument examples while preserving meaningful examples and complete structured JSON data ## Root cause GitBook uses the `SUMMARY.md` link label as the published page heading and suppresses the Markdown H1 from the document body. The generated version was therefore present in source but absent from the rendered page. The release workflow also coupled version stamping to the complete rendered Markdown line. It now replaces and verifies only the standard `0.0.0-webstudio-version` placeholder. ## Verification - live page structure inspected: published H1 is `MCP` - MCP manual regression test demonstrated failing before empty argument blocks were filtered, then passing after the fix - release placeholder stamping simulated against the generated page - `pnpm --filter webstudio exec vitest run src/commands/man.test.ts` - `pnpm --filter @webstudio-is/project-build typecheck` - `pnpm --filter webstudio typecheck` - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check packages/project-build/src/mcp.ts packages/cli/src/commands/man.ts packages/cli/src/commands/man.test.ts` - `git diff --check` Fixture inputs and outputs are unaffected. ## Todo - [x] Generate the release version as visible GitBook body content. - [x] Decouple release stamping from the rendered Markdown content. - [x] Remove empty MCP argument example blocks. - [x] Validate generated output and regression coverage. - [ ] Merge this pull request. - [ ] Publish the latest released revision to the `docs` branch. - [ ] Verify the version on the live GitBook page. Ref #5986	2026-08-03 20:21:35 +02:00
Oleg Isonen	e6a29b5d36	fix: Show released CLI version in MCP docs (#5990 ) ## Summary - make the MCP page generator render the CLI package version directly in the page title - publish `Webstudio MCP v<release>` from the exact generated page in each successful release - merge each successful release tag into the publication-only `docs` branch - serialize publication and ignore reruns or older release tags already contained in `docs` ## Root cause The first publication design advanced `docs` to the release commit without putting the CLI package version into the generated page. The repository uses `0.0.0-webstudio-version` until release time, so the release workflow now replaces that existing version placeholder with the successful tag version before publishing. ## Todo - [x] Generate the CLI version in the MCP page title. - [x] Publish the generated page from the exact release revision. - [x] Make publication idempotent and prevent version downgrades. - [x] Validate generation, formatting, linting, and release-branch behavior. - [ ] Merge this pull request. - [ ] Publish `0.285.0` as the initial version on the existing `docs` branch. ## Verification - `pnpm docs:mcp:test` - `pnpm docs:mcp:typecheck` - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check` - `git diff --check` - isolated Git simulation for release merge, exact generated-page selection, version replacement, and rerun detection - regression tests demonstrated failing without version rendering and validation, then passing after restoration Ref #5986	2026-08-03 18:32:59 +02:00
Oleg Isonen	99371187dc	docs: Move product documentation into Builder (#5987 ) ## Summary - move the complete GitBook documentation tree and assets into Builder under `/docs` - generate the exhaustive MCP page from the local CLI source in the same change - publish GitBook from a release-gated `docs` branch containing the exact successfully released revision - run MCP documentation tests, typechecking, and stale-output checks with the existing generated-docs check - remove links to the Community Discussions repository ## Technical choices - Import the current documentation as a linear snapshot so the branch satisfies Builder's required-linear-history protection. - Keep the Markdown wrapper separate from the TypeScript generator at `scripts/docs/mcp-page.md`. - Generate through `packages/cli/local.js` so CLI guidance and its documentation are reviewed together. - Let `check:generated-docs` reject CLI changes that leave the committed MCP page stale. - After both GitHub release creation and package publication succeed, fast-forward the read-only `docs` branch to the immutable release tag commit. A divergent update fails instead of publishing a different revision. - Configure GitBook to publish `/docs` from the `docs` branch, not directly from `main`. - Exclude `/docs` from the repository-wide `oxfmt` scan so imported GitBook Markdown retains its established formatting; generator tests and stale-output checks still validate the MCP page. - Exclude `transcripts/` and GitHub Discussions from the migration. ## Todo - [x] Import documentation, navigation, includes, and assets under `/docs`. - [x] Generate the MCP page from the local CLI source. - [x] Move MCP generation and validation into Builder. - [x] Require MCP documentation updates alongside CLI changes. - [x] Publish released revisions through a read-only `docs` branch. - [x] Remove Community repository links from Builder and the migrated docs. - [x] Preserve and verify a final Community Git bundle locally. - [ ] Merge this pull request. - [ ] Let the next successful release create or advance the `docs` branch. - [ ] Repoint GitBook Git Sync to `webstudio-is/webstudio`, branch `docs`, root directory `/docs`. - [ ] Verify `docs.webstudio.is`, navigation, assets, anchors, and the MCP page in production. - [ ] Delete `webstudio-is/webstudio-community`. ## Verification - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check` - `git diff --check origin/main...HEAD` - generator regression test demonstrated failing when the GitBook wrapper behavior was removed, then passing after restoration - no fixture inputs or outputs are affected ## Known limitation All documentation merged after the previous release waits for the next successful release before GitBook publishes it. This deliberately keeps the public MCP reference aligned with an installable CLI revision. Ref #5986	2026-08-03 17:55:50 +02:00
Oleg Isonen	efbc3098c4	feat: add queryable Assets resources (#5946 ) Closes #5919 Ref #5920 ## Outcome Extend the existing Assets system resource with optional queries for Markdown, JSON, and standard file metadata. Unconfigured Assets resources retain the existing fetch-all behavior and activate none of the content-query infrastructure. Files are the authoring model. A standalone content engine converts an immutable snapshot of only the files required by configured queries into one bounded, deterministic runtime database. Builder preview, SSR, and SSG use the same query semantics without requiring a database service for a published site. ## Final architecture ```text Markdown / JSON files │ ▼ ContentSource adapter (FS or Webstudio Assets) │ immutable snapshot ▼ ContentCompilationPlan (union of configured query requirements) │ ▼ ContentCompiler (parse, normalize, discover fields, enforce budget) │ ▼ ContentArtifact (bounded, deterministic, immutable JSON) │ ▼ ContentDatabase (filter, OR groups, sort, paginate, project, read content) │ ├── Builder preview ├── SSR runtime └── SSG build only ``` The authoring/storage layer owns mutable files. The content engine consumes immutable snapshots and produces immutable, disposable artifacts. Query authoring is a separate OpenAPI-driven path: ```text Assets REST OpenAPI operation + standard request JSON Schema + dynamic field paths │ ▼ Generic OpenAPI adapter │ resolved schemas, controls, paths, and transport mapping ▼ Generic query-builder core and React renderer │ arbitrary provider-defined value ▼ Assets REST request adapter │ ▼ { query: value } ``` The selected standard OpenAPI operation is the only source of query UI semantics. Request parameters and JSON Schema describe the editable data; the generic renderer derives controls and owns layout. ### Activation and compilation - The compiler does not index every asset. It combines all reachable configured Assets-resource queries into one `ContentCompilationPlan`. - Static constraints such as folder, path, and file type select candidate files. Dynamic values such as a route-bound slug cannot reduce the build-time candidate set. - The plan contains the union of fields used by filtering, sorting, routing, projection, excerpts, and requested full content. - Documents shared by multiple resources are stored once in one deployment-wide runtime database. - Markdown/frontmatter, JSON properties, excerpts, and full bodies are prepared only when required. - No configured content query means no parsing, artifact, or shipped runtime dependency. Fresh generated apps need no content-runtime cleanup; incremental generation removes stale integration if a previously configured query is deleted. ### Runtime database limit - `CONTENT_DATABASE_MAX_BYTES` limits the complete serialized runtime database, not source files, images, or unrelated assets. - The default is `500 * 1024` bytes and is presented as 500 KiB. - Counted data includes indexed metadata, frontmatter/JSON properties, excerpts, the field catalog, serialization overhead, and full Markdown bodies only when requested. - Prepublish validation builds and serializes the exact database that will be attached to the immutable build, so it knows the unbounded size, bounded size, included documents, omitted documents, and affected resources. - Overflow never stores partial documents. Candidates are ordered by `createdAt` descending, canonical path ascending, and stable document ID ascending. Missing dates follow dated documents. A document that does not fit is skipped while smaller later documents are still considered. - Exceeding the limit warns but does not block publishing. - Builder preview can report exact bounded versus unbounded results when dynamic expressions have concrete preview values. Prepublish warnings remain conservative for future route values. ### Snapshot consistency The source contract guarantees a consistent compilation, while adapters provide the mechanism: - Webstudio Assets captures asset metadata and immutable content references. - Filesystem sources capture file identity and verify files did not change before accepting the artifact. - A changed source retries once, then fails clearly instead of producing a mixed-revision database. - This requires no universal snapshot service, source-tree copy, or new versioned-asset infrastructure. ### Package ownership - `@webstudio-is/content-engine`: runtime artifact schema, query execution, field catalog, compact runtime statistics. - `@webstudio-is/content-engine/compiler`: source snapshots, compilation plans, Markdown/JSON parsing, deterministic compilation, byte accounting, and compiler diagnostics. This entry exists to keep Remark/YAML/future MDX dependencies out of runtime bundles. - `@webstudio-is/query-builder`: resolves standard OpenAPI operation schemas into an internal provider-neutral editor model, validation, mutations, and source serialization. It owns no Assets, provider-authored UI contract, or fixed REST-query semantics. - `@webstudio-is/query-builder/react`: container-neutral schema renderer whose layout is renderer policy. It remains separate from the content engine. - SDK: Webstudio Assets/Resource domain models and mapping Webstudio expressions into generic content requirements. - Protocol: external Assets REST/OpenAPI transport contracts. - Asset uploader/repository: asset and folder mutations, generic metadata, immutable byte references, and storage access. Its hosted adapter supplies Webstudio Assets snapshots and parsed-metadata cache persistence to the content engine; parsing, artifact creation, and query semantics remain engine-owned. - Builder and generated-app integrations decide when to compile, cache, embed, load, or discard a database. ### Runtime lifecycle - Builder caches immutable `ContentDatabase` instances by source revision plus compilation-plan hash and coalesces concurrent compilation. Matching operations reuse the same instance; field discovery uses a dedicated minimal all-properties plan that excludes excerpts and bodies. - SSR attaches the validated bounded database to the build and includes the small runtime only when required. - SSG uses the database only while generating pages and omits it and the runtime from final output unless a future runtime-query feature requires them. - Local development compiles from the filesystem and uses identical query semantics. - Published pages query their local artifact; they do not call Builder REST endpoints. - Published artifacts need no external index store, invalidation, garbage collection, SaaS content proxy, new bucket, or new environment variable. ## Implemented foundation These existing parts remain useful and should be moved behind the final ownership boundaries rather than reimplemented. - [x] Upgrade the existing Assets system resource in place and preserve unconfigured fetch-all behavior. - [x] Implement typed filtering, nested boolean groups, deterministic sorting, pagination, projections, dynamic values, and content hydration. - [x] Add Markdown frontmatter, excerpt, JSON-property, and field-catalog extraction. - [x] Add reusable query-control implementations and a separately imported React UI as a foundation for the final OpenAPI-driven contract. - [x] Add Assets query authoring and dynamic field discovery as existing behavior to migrate into the Assets OpenAPI operation. - [x] Add synchronized visual and editable expression authoring. - [x] Unify Assets REST operations under `/rest/assets/*`. - [x] Define authenticated collection, item, content, upload, folder, query, field-catalog, and OpenAPI operations. - [x] Support Builder cookie authentication and public API token authentication. - [x] Add Builder preview, MCP/CLI operations, SSR execution, SSG path generation, and conditional activation. - [x] Add revision-keyed parsed metadata persistence for the hosted Builder. - [x] Add focused query, API, authorization, Builder, CLI, SSR, SSG, migration, and fixture coverage. ## Remaining implementation plan ### 1. Establish the content engine - [x] Rename the generic `@webstudio-is/asset-resource` implementation to `@webstudio-is/content-engine`. - [x] Move existing behavior instead of creating a parallel implementation. - [x] Keep the primary entry runtime-only and add only the compiler entry needed for bundle separation. - [x] Remove the old package after all consumers migrate. - [x] Ensure the engine has no Builder, SDK, asset-uploader, PostgreSQL, R2, or deployment-target dependency. ### 2. Define source snapshots and compilation plans - [x] Introduce `ContentSource.openSnapshot()` and a revision-bearing `ContentSourceSnapshot`. - [x] Include canonical path, stable document ID, content type, immutable content reference, size, and optional `createdAt`. - [x] Implement Webstudio Assets and filesystem snapshot guarantees using their adapter-specific mechanisms. - [x] Introduce `ContentCompilationPlan` for the union of reachable configured resource requirements. - [x] Separate statically selectable candidates from dynamic runtime predicates. - [x] Add mutation-during-compilation tests for replacement, deletion, folder movement, and filesystem changes. ### 3. Separate storage from content processing - [x] Keep upload, replacement, folders, byte storage, revisions, and generic metadata in the Assets repository/uploader. - [x] Move parsing, excerpts, field discovery, query execution, and artifact creation into the content engine. - [x] Remove content-index coordination from asset mutation business logic. - [x] Preserve original source `createdAt` across content replacement and expose it as optional queryable metadata. - [x] Keep hosted parsed-document persistence behind the content compiler's optional cache interface. ### 4. Build deterministic compilation - [x] Move the existing Markdown, frontmatter, JSON, canonicalization, hashing, document-building, and tests into the compiler. - [x] Keep frontmatter behind a dedicated module and continue using the existing Remark/Micromark pipeline. - [x] Parse only candidate files and only the tiers required by the compilation plan. - [x] Deduplicate documents and fields required by multiple resources. - [x] Define a versioned, deterministic `ContentArtifact` with integrity information. - [x] Keep verbose parse and omission diagnostics outside the runtime artifact. - [x] Reject incompatible artifact versions cleanly. ### 5. Enforce the deployment-wide database budget - [x] Replace the old asset-index limit with `CONTENT_DATABASE_MAX_BYTES`, defaulting to 500 KiB. - [x] Have applications read configuration and pass the byte limit into the compiler. - [x] Measure the exact serialized database, including selected bodies and overhead. - [x] Implement deterministic skip-and-continue packing of complete documents. - [x] Return compiler diagnostics with unbounded/bounded bytes, included/omitted counts, omitted identities, largest contributors, and affected resources. - [x] Expose only compact artifact statistics at runtime through `ContentDatabase.getStats()`. - [x] Add exact boundary, deterministic ordering, deduplication, and oversized-document tests. ### 6. Finalize the runtime database - [x] Define `ContentDatabase` over an immutable artifact. - [x] Preserve filtering, nested AND/OR groups, sorting, offset/limit, projection, field references, and content retrieval. - [x] Expose `getFieldCatalog()` and compact `getStats()`. - [x] Keep Markdown/YAML/compiler dependencies out of the runtime entry. - [x] Add execution guards and maximum-size runtime benchmarks. ### 7. Make query authoring OpenAPI-driven The selected standard OpenAPI operation is the complete query-authoring contract. The query builder resolves parameters and request-body JSON Schema, derives its internal editor model, and applies renderer-owned layout policy. It must not embed or fetch a second capabilities/UI language through `x-webstudio-query` or another side channel. - [x] Remove `x-webstudio-query` and all vendor query-definition metadata from the Assets OpenAPI operation. - [x] Resolve local OpenAPI references and derive the editable request value, defaults, validation, labels, choices, arrays, objects, and unions solely from standard operation parameters and request-body JSON Schema. - [x] Represent dynamic Assets field paths with standard JSON Schema vocabulary in the `queryAssets` request schema. - [x] Keep the normalized editor representation internal to query-builder; do not expose another provider-authored capabilities contract. - [x] Remove provider-controlled layout metadata such as `group`; make compact scalar packing and all other layout renderer policy. - [x] Keep Webstudio expression binding as a consumer/editor concern layered over schema values, not part of the OpenAPI contract. - [x] Preserve the existing Assets filter, sort, output selection, full-content/range selection, limit/offset, editable source, and configured-field behavior. - [x] Keep the Assets resource adapter responsible for serializing the edited query into its request body. - [x] Remove the obsolete Assets query-capabilities endpoint, URL, and UI-side capability parsing. - [x] Add a non-Assets OpenAPI proof with differently named parameters and no vendor metadata. - [x] Verify the generic packages contain no Assets imports, fixed Assets property contract, or provider-authored layout model. - [x] Update focused core, React, SDK, protocol/OpenAPI, Builder, and source round-trip tests. ### 8. Manage ContentDatabase lifecycle in Builder - [x] Cache databases by source revision plus normalized compilation-plan hash. - [x] Coalesce concurrent compilation requests. - [x] Reuse cached database instances across field discovery, autocomplete, query preview, and response preview when their normalized compilation plans match. - [x] Replace it when source revision or query requirements change. - [x] Preserve the optional revision-keyed hosted parsed-document cache without making it a source of truth. - [x] Show exact preview warnings when concrete values reveal missing bounded results. ### 9. Materialize and verify immutable builds - [x] Compile and serialize the exact deployment-wide database during prepublish validation. - [x] Attach that validated bounded database to the immutable build without rebuilding it from later asset state. - [x] Show non-blocking prepublish warnings with database bytes, omissions, and potentially affected resources. - [x] Avoid claiming exact future route matches when dynamic values are unknown. - [x] Include the database/runtime only when a reachable configured query requires them. - [x] Ensure detail resources requesting Markdown content include all statically eligible bodies needed by dynamic routes. ### 10. Integrate all targets - [x] SSR: load the build's bounded database and conditionally include the small runtime. - [x] SSG: query the same database during generation, then omit database/runtime output when no runtime query is needed. - [x] Local/CLI: compile from the filesystem source with the same semantics. - [x] Preserve overview pagination, alternative route fields, draft-as-user-data behavior, and full article rendering. - [x] Verify ordinary Assets and fresh query-free sites perform no parser, artifact, content-runtime dependency install, or cleanup work. ### 11. Correct API and package ownership - [x] Move external Assets REST/OpenAPI contracts to `@webstudio-is/protocol`. - [x] Keep Webstudio domain models and Assets system-resource configuration in the SDK. - [x] Keep both cookie and token authentication behavior on the unified Assets REST surface. - [x] Remove pass-through route wrappers/reexports that add no transport behavior. - [x] Keep published runtime queries local to the artifact rather than routing them through Builder REST. ### 12. Remove superseded deployment infrastructure - [x] Remove external deployment-index upload, fetch, invalidation, cleanup, and garbage-collection code. - [x] Remove the SaaS asset-origin adapter requirement; close webstudio-is/webstudio-saas#652 as superseded because it has no independent purpose. - [x] Remove index-bucket compatibility configuration and avoid adding Infisical variables. - [x] Remove obsolete external-index paths, package dependencies, routes, scripts, and tests. - [x] Consolidate unreleased intermediate migrations where safe and retain only schema required by the final hosted cache/API design. ### 13. Verification and release readiness - [x] Move and preserve existing tests while changing ownership; add new tests only for changed contracts and behavior. - [x] Run content-engine compiler/runtime tests, query-builder tests, SDK/protocol/API tests, Builder tests, CLI tests, and affected typechecks. - [x] Run formatting, generated-file idempotence, fixtures, clean Supabase-compatible migrations, E2E shards, and complete agent evaluations. - [x] Verify SSR and SSG conditional inclusion and query-free generated package manifests. - [x] Run the five-article MCP blog workflow: authoring, field discovery, overview, dynamic detail routes, full Markdown rendering, publishing, and published-site verification. - [x] Run a maximum-budget database test and a mutation-during-compilation test. - [x] Perform a final architecture, security, API compatibility, migration, bundle, correctness, and DRY review. - [x] Reconcile every checkbox and replace the verification section with results from the final architecture before release. ## Future MDX work MDX is intentionally separate from this release. - The compiler contract should allow a future build-only MDX parser. - MDX compilation must not enter the published runtime. - Embedded JSX must use an explicit compiled representation rather than runtime source evaluation. - Webstudio components, tokens, styles, and component allowlists remain Webstudio integration concerns. - The future MDX work should reuse `ContentArtifact` and `ContentDatabase` where practical. ## Superseded design The following earlier design choices are no longer the target architecture: - GROQ or GraphQL as the Assets query language. - One external or long-lived index object per resource/query. - A deployment index fetched by the Worker from SaaS/CDN infrastructure. - Lazy production reads of source Markdown bodies. - A separate index bucket, asset origin, invalidation service, or garbage collector. - A 4 MiB published index limit. - Rebuilding an old build's database from the current mutable asset set. - Bundling query infrastructure into projects without a configured content query. ## Verification baseline The embedded runtime-database architecture previously passed the checks below. The OpenAPI-driven query-authoring change additionally passed: - Query-builder core: 4 files / 19 tests. - Query-builder React: 1 file / 7 tests. - SDK Assets source/config: 1 file / 7 tests. - Protocol Assets OpenAPI: 1 file / 9 tests, including independent OpenAPI validation. - Builder Assets OpenAPI description: 1 file / 5 tests. - Query-builder, React, SDK, protocol, and Builder typechecks. - Package-boundary validation and formatting of every affected file. Local verification baseline: - Content engine: 15 files / 104 tests. - Asset uploader: 24 files / 175 tests. - Builder: 204 files / 2,423 tests. - CLI: 54 files / 866 tests. - Complete workspace typecheck, formatting, lint, package boundaries, generated fixtures, and fixture builds. - The complete migration history applied successfully to a fresh Supabase-compatible database, including every migration after the consolidated Assets migration. - Builder production build and full local E2E suite passed. - Complete agent evaluations passed: authenticated page (170,859 ms), design input (207,101 ms), and font assets (67,050 ms). - Final review additionally verified correct REST edit/view/build permits, cookie and public-token read paths, immutable snapshot retries, exact database budgeting, query-free dependency omission, and SSR/SSG conditional runtime inclusion. Final staging verification passed against the embedded runtime-database architecture: MCP uploaded and updated five Markdown articles, discovered dynamic frontmatter fields, previewed a five-item sorted overview and one full-body slug query, updated both Assets resources, found zero binding issues, rendered `/blog` and `/blog/dynamic-routes` at HTTP 200, published build version 266, and verified both published routes at HTTP 200 with the expected article metadata and Markdown body. The workflow also found and fixed offset-form asset timestamps failing canonical datetime validation and made MCP `preview.start({ port: 0 })` correctly select an available local port. ## Release constraints - No new SaaS content service, bucket, or environment variable. - No published-site database dependency. - No parser/compiler dependency in query-free sites or runtime-only bundles. - The validated content database is immutable build output. - Publishing warnings do not block deployment. - The selected standard OpenAPI operation and its request JSON Schema are the only source of query UI semantics.	2026-07-31 00:17:46 +02:00
Oleg Isonen	0070fa66a1	ci: deduplicate builder E2E setup (#5917 ) ## What changed - reuse the shared CI setup action in both Builder E2E jobs - use one build command for CI and local E2E runs - centralize shard filename parsing and suite-name formatting - remove redundant suite-level shard filtering - parse each E2E filename's shard metadata once ## Why The merged image-asset PR introduced multiple owners for Builder E2E setup, build dependencies, and shard filename semantics. Consolidating them prevents CI and local behavior from drifting as the shard layout evolves. ## Validation - `pnpm --filter=@webstudio-is/builder test -- e2e/test-modules.test.ts` - `pnpm --filter=@webstudio-is/builder typecheck` - `pnpm lint` - `pnpm e2e:builder:build` - shell syntax and YAML parsing - shard discovery returned shards 1–6	2026-07-18 10:43:56 +02:00
Oleg Isonen	ef94d85ccf	feat: drag image assets onto canvas (#5912 ) ## Summary - allow dragging a single image asset from the Assets panel onto the canvas - insert an Image component with its source bound to the dragged asset in one undoable mutation - preserve asset-folder drops and canceled drags - build the Builder once in CI and reuse the compact build artifact across all E2E shards ## E2E timing Recent CI showed shard test runtimes of roughly 101–145 seconds, while every shard also repeated a roughly two-minute Builder build. The four shards are already reasonably balanced, so a fifth shard would not address the primary bottleneck. The shared artifact is about 30 MB uncompressed and roughly 5 MB compressed because checked-out public assets are excluded. This should return individual shard jobs to the 2–3 minute range. ## Validation - 45 focused unit tests - image asset to canvas E2E using the prebuilt-artifact path - image asset to folder regression E2E - Builder typecheck - lint - package-boundary validation - workflow YAML validation - shell syntax validation	2026-07-18 09:15:02 +02:00
Oleg Isonen	7d7c23d30a	fix: Center empty asset folder drop state (#5911 ) ## Summary - center the reusable “Drop files here” state against the full empty-folder area - keep the Back thumbnail independently positioned and interactive - add regression coverage for empty folders with additional content - add a fourth builder E2E shard and split the serial asset-folder workflows using measured CI durations ## Root cause The Back thumbnail participated in the same column flow as the drop state, reducing the drop state’s available height and shifting its center downward. The asset-folder E2E module also accumulated ten serial workflows and became shard 1’s 214-second bottleneck. ## User impact Empty folders now align the drop message consistently with the root empty state and full-panel drag overlay. The E2E split reduces shard 1’s measured workload from about 230 seconds to a projected 113 seconds, with shard 4 at about 100 seconds. ## Validation - focused asset tests: 62 passed - E2E shard discovery test - shard 1 and shard 4 module loading - builder typecheck - workspace typechecks - lint - package boundaries - generated API and docs checks - fixtures - full workspace tests; three CLI subprocess tests initially timed out under concurrent load and passed when rerun in isolation	2026-07-18 02:45:21 +02:00
Oleg Isonen	878d6f1de1	feat: Add asset folders to asset manager and improve asset manager UX (#5892 ) Closes https://github.com/webstudio-is/webstudio/issues/5877 Closes https://github.com/webstudio-is/webstudio/issues/4775 - Organize assets into nested folders. - Navigate folders with breadcrumbs and Back controls. - Select and manage multiple assets and folders at once. - Drag, copy, cut, paste, duplicate, move, and delete items. - Use context menus and familiar keyboard shortcuts for common actions. - Search and sort assets and folders, with folders grouped first. - Upload files directly into the active folder. - Manage folder placement from asset and folder settings. - Automate asset and folder management through MCP.	2026-07-17 23:39:14 +02:00
Oleg Isonen	12ad74584a	feat: Improve MCP authoring, auditing, and verification (#5886 ) ## Summary This improves how coding agents discover, author, verify, and audit Webstudio projects through the CLI and MCP. The work focuses on making agents more reliable with less context, while keeping edits semantic and Builder-editable. ## What changes for users - Agents can verify dynamic bindings after authoring and receive actionable diagnostics when expressions, resources, scopes, or component props do not line up. - Agents can create complete resource-backed runtime UI through a semantic operation instead of coordinating fragile low-level edits. - MCP discovery and command output are compact by default, with pagination and focused verbose detail when an agent needs more context. - Asset, style, token, font, page, and component inspection provides stronger usage context so agents can preserve the existing design system. - Rendered audits provide better evidence for responsive behavior, geometry, contrast, generated-build size, and large-project runs. - Cross-project MCP workflows can run from a manifest with explicit mutation approval, isolated failures, resumable progress, and persistent checkpoints. - Project-specific agent onboarding is clearer and does not add telemetry. - Packaged CLI releases gain stronger smoke verification for install, MCP startup, authoring, preview, screenshots, and audits. ## Reliability and architecture - Runtime operation output schemas are generated from the runtime registry and remain client-compatible. - Project-build exports are consolidated around architectural boundaries instead of feature-by-feature convenience entry points. - HTTP, preview, screenshot, and project-session paths are hardened for longer autonomous workflows. - Craft compatibility work is read-only and provenance-aware; it does not silently opt ordinary projects into Craft behavior. - A minimal-context evaluation harness exercises key workflows with a weaker model and stores bounded, privacy-safe evidence. ## Validation - Rebased on the latest `origin/main`. - `pnpm lint` - Repository-wide `oxfmt --check` - CLI typecheck and full test suite: 773 tests passed. - Project-build typecheck and full test suite: 1,866 tests passed. - Protocol typecheck and full test suite: 83 tests passed. - HTTP client tests: 23 passed. - CSS data tests: 3,620 passed, 1 skipped. - Focused Builder tests: 67 passed. - Package-boundary, generated API, and generated documentation checks passed. - Minimal-context agent evaluations passed for authenticated resource-backed UI and design-system-aware responsive authoring.	2026-07-16 17:53:16 +02:00
Oleg IsonenandClaude Fable 5	de23e2a888	chore: migrate toolchain to oxc (oxfmt, oxlint, rolldown-vite) and typeScript 7 (#5868 ) ## prettier -> oxfmt (0.58.0) - .oxfmtrc.json generated with `oxfmt --migrate=prettier`: trailingComma es5, printWidth 80 (oxfmt defaults to 100), sortPackageJson disabled, .prettierignore patterns folded in (file deleted). - ignorePatterns additionally exclude yml/yaml/toml/jsonc and packages/cli/templates/** so oxfmt covers exactly the file set prettier used to format (ts,tsx,js,json,css,md) and never touches user-facing scaffolding artifacts. - root `format` script, nano-staged pre-commit hook and the CI check (`pnpm oxfmt --check`, replacing `prettier --cache --check` and its actions/cache step — oxfmt checks the whole repo in ~0.7s) now run oxfmt. - every generator script that ran `prettier --write` on __generated__ output now runs `oxfmt` (css-data, icons, html-data, postgrest, sdk, sdk-components-*, apps/builder tailwind preflight). - the four scripts that used prettier's JS `format()` API write raw source instead and their package.json scripts pipe the generated file through the oxfmt CLI: project-build generate-docs + generate-runtime-operation-contracts, cli generate-docs, apps/builder generate-server-only-api-metadata. oxfmt rejects paths containing "..", so cross-package generated files are formatted via a subshell cd into the owning package. - one-time reformat: oxfmt's canonical output differs from prettier on 8 repo source files (binary-operator continuation indent, import() call wrapping, sub-pixel spacing of empty for-clauses); oxfmt honors existing `// prettier-ignore` comments so intentional layouts are kept. - prettier remains ONLY as a cli devDependency for the prettier/standalone HTML normalizer inside html-to-jsx.test.ts, and inside fixtures/ + packages/cli/templates/ (ships to scaffolded user projects; out of scope here). - editor config switched from esbenp.prettier-vscode to oxc.oxc-vscode (devcontainer extension list, .vscode editor.defaultFormatter). ## oxlint 1.56 -> 1.73 - oxlint 1.73 rules-of-hooks special-cases hooks NAMED useEffectEvent: their results may only be called from effects. Our app/shared/hook-utils/effect-event.ts is a stable-callback helper (useEvent pattern), intentionally called from event handlers and passed as props. The rule is disabled via .oxlintrc.json overrides for the five files doing this (product code untouched); note those files lose hook-order linting entirely until the rule becomes configurable. ## TypeScript 5.8.2 -> 7.0.2 (native compiler) - `tsc` is now the Go-based native binary; all `tsgo` script usages (workspace packages and fixtures) renamed back to `tsc` and @typescript/native-preview removed (the package is being phased out). - fixes for TS7 changed defaults and stricter checks: - `types` now defaults to [] -> base tsconfig sets "types": ["node"] (restores the implicit-@types/node behavior of TS5). - `rootDir` now defaults to ./ -> every tsconfig.dts.json sets "rootDir": "./src" (TS5011 otherwise). - import assertions removed -> cli/src/cli.ts uses `with { type: "json" }` (TS2880). - stricter isolatedDeclarations inference -> explicit annotations in css-data bin/property-filter.ts (TS9010) and image image-dev.stories.tsx (TS9013). - declaration serialization limit -> project-build builder-runtime.ts runtimeOperationContracts gets an explicit type (TS7056); the annotation preserves the narrow RuntimeOperationId union. - TS7 ships no stable programmatic API: - react-sdk (component-generator tests drive the compiler API) aliases its typescript devDependency to @typescript/typescript6@^6.0.2; its bin is `tsc6`, so the package's typecheck still runs native TS7 tsc from the workspace root. - generate-arg-types keeps typescript 5.8.2 for react-docgen-typescript. - fixtures/ and packages/cli/templates/ keep typescript 5.8.2 (user-facing); fixture scripts still work because plain `tsc` resolves to their local dependency. ## vite -> rolldown-vite 7.3.1 (oxc bundler) - global pnpm override `"vite": "npm:rolldown-vite@^7.3.1"`: the builder app (remix v2 vite plugin works unmodified), every package vite build and the storybook build now bundle on rolldown/oxc. - vitest is scoped BACK to vanilla vite via `vitest>vite`, `vite-node>vite` and `@vitest/mocker>vite` overrides because vitest 3.1's runner does not understand rolldown's SSR transform (__vite_ssr_exportName__ ReferenceError in every suite). - those overrides pin vite EXACTLY to 6.3.4: letting ^6.3.4 float to 6.4.3 breaks cli prebuild tests (dynamic import of a generated app/routes/$.tsx fails to resolve under 6.4.3's loader). ## unrelated cleanup requested during review - apps/builder commands.ts imports duplicate-tokens-group statically instead of via dynamic import. The circular dependency the dynamic import guarded against only exists through the command-panel barrel (command-panel.tsx > groups/index.ts > commands-group.tsx > commands.ts); importing the group module directly is cycle-free (verified with madge), matching the neighboring wrap-group and convert-group imports. ## verification - pnpm lint, oxfmt --check: clean. - pnpm -r typecheck (TS7 native) and pnpm dts: clean. - pnpm -r test: all suites pass (builder 2093 tests, cli 630, react-sdk 45, project-build 11, ...). - builder app build, full workspace build, cli build and storybook build all succeed on rolldown-vite. ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-12 01:03:36 +02:00
Oleg Isonen	da13e301c9	chore: Post merge fixes (#5860 )	2026-07-10 12:55:20 +02:00
Oleg Isonen	d291e4b671	feat: Builder api runtime contracts guardrails for MCP (#5857 ) This PR expands Webstudio MCP and CLI into a more complete agent authoring interface. Agents can discover project capabilities, edit real Webstudio content, use data/resources, verify visual output, and report useful issues when workflows fail. ## MCP User Capabilities - Create, update, duplicate, reorder, and delete pages. - Create pages from templates and manage reusable page templates. - Inspect project pages, instances, props, styles, assets, variables, resources, and metadata. - Insert Webstudio components and authored JSX fragments into pages. - Edit text, props, styles, breakpoints, design tokens, and CSS variables. - Update page metadata, SEO fields, redirects, marketplace metadata, and project settings. - Create and use static data variables. - Create and use dynamic resources fetched over HTTP. - Use REST, GraphQL, and built-in system resources in authored pages. - Bind data variables and resources to visible page content. - Create resource-backed pages such as sitemap XML, structured SEO data, and API-driven content sections. - Preview current project state without requiring a publish step. - Capture screenshots for visual verification. - Verify responsive designs across desktop, tablet, and mobile breakpoints. - Use screenshot diff and OCR-style checks to inspect rendered output. - Reset and refresh local MCP project state when needed. - Discover available CLI/MCP commands from generated manuals. - Use clearer examples for resources, data variables, JSX authoring, previewing, and visual checks. - Read marketplace product metadata without requiring a full project snapshot. - Get safer guidance when using low-level patch tools. - Get a ready-to-copy Discord report template when MCP/CLI behavior is confusing or broken.	2026-07-10 02:13:22 +02:00
Oleg Isonen	a515a4fcbf	chore: Change the local setup to use docker only for supabase (#5851 ) It was disappearing after played on builder	2026-07-02 21:53:47 +02:00
Oleg Isonen	db78ae4dcc	feat: Bring back blue token color on style source and remove Figma token sync pipeline (#5812 ) Originally we made the token color purple to make it more distinct from local style source, but now local style source is visually different and having both blue makes sense because when its blue, active style values are matching the blue color and it makes it more clear what that blue color on values means.	2026-06-12 12:43:14 +02:00
Oleg Isonen	392c9089be	fix: content mode permissions (#5795 ) Summary Fixes content-mode edit permissions so editor-only users can perform allowed content workflows without backend “build permission” failures. Changes - Added shared content-mode permission validation used by backend authorization. - Aligned content-mode capabilities around editable props, editable instances, content roots, pages, assets, and template insertion. - Allowed content-safe instance/text/page/template/style changes while keeping design/data/resource changes build-only. - Updated template insertion to preserve content-safe local styles and reuse tokens by id. - Added accessible `SyncStatusDot` for e2e-visible sync state without replacing the existing sync status UI. - Added builder e2e setup with Postgres/PostgREST and a first content-mode browser test: - edit existing text as an editor-only user - wait for saved state via the sync status dot - reload and verify persistence Verification - `pnpm --filter=@webstudio-is/builder test -- sync-status.test.tsx` - `pnpm --filter=@webstudio-is/builder typecheck` - `git diff --check` - `pnpm e2e:builder`	2026-06-09 01:48:23 +02:00
Oleg Isonen	6b09e91324	build: Release 29 04 26.staging (#5742 )	2026-04-29 19:31:17 +02:00
Oleg Isonen	9ea5f70a73	chore: Pages.staging (#5736 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2026-04-28 19:43:21 +02:00
Oleg Isonen	678da389dd	fix: Fix ssg export (#5668 )	2026-03-28 11:11:29 +01:00
Oleg Isonen	7a68357334	chore: rename fixtures/ssg to ssg-cloudflare-pages to prevent concurrent build race condition (#5662 )	2026-03-26 01:30:24 +01:00
Oleg Isonen	df90970c0d	chore: Remove release author, its in pr (#5656 )	2026-03-23 18:42:01 +01:00
Oleg Isonen	4276aeb8e8	chore: upgrade Node.js from 20 to 22 in CI/CD workflows (#5651 ) Update node-version from 20 to 22 in: - .devcontainer/Dockerfile - .github/actions/ci-setup/action.yml - .github/actions/vercel/action.yaml - .github/workflows/cli-r2-static.yaml - .github/workflows/cli-r2.yaml - .github/workflows/migrate.yaml ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2026-03-22 15:20:58 +01:00
Oleg Isonen	6c17a0ec19	chore: Oxlint (#5650 )	2026-03-20 21:09:47 +01:00
Oleg Isonen	f7bd67e533	chore: enable fork PR deployments via safe-to-deploy label (#5605 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2026-02-05 14:07:10 +01:00
Oleg Isonen	2bf52cf0c1	chore: upgrade to Node 22 (#5603 ) - Update engines.node in all package.json files - Update .nvmrc to 22 - Update GitHub Actions workflows to node-version: 22	2026-02-05 10:25:17 +01:00
Oleg Isonen	d1de1bb8fd	chore: Revert "chore: add workflow_dispatch trigger to CLI R2 workflow (#5593 )" (#5594 ) This reverts commit `2fca1de379`. ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2026-01-29 14:44:40 +01:00
Oleg Isonen	2fca1de379	chore: add workflow_dispatch trigger to CLI R2 workflow (#5593 ) Allow manual triggering of the CLI R2 workflow to rebuild the cloudflare-template artifact. This is needed for the republish script to rebuild main.tar.zst when republishing accidentally unpublished sites. Changes: - Add workflow_dispatch trigger with optional ref input (defaults to 'main') - Upload artifact as main.tar.zst when building main branch - Fix checks job to use correct artifact path for workflow_dispatch - Skip delete-github-deployments for workflow_dispatch (no branch to clean up) - Remove local mounts from devcontainer.json	2026-01-29 13:51:37 +01:00
Oleg Isonen	33f720fb9f	fix: Fix asset resource on published sites (#5565 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2026-01-15 18:26:32 +01:00
Oleg Isonen	1412d868ba	chore: make migrations idempotent (#5476 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2025-12-04 12:28:57 +01:00
Bogdan Chadkin	021c62e7a2	feat: support animations in static export (#5411 ) This enables building private animation library with static websites and user clicks download button.	2025-09-27 10:57:25 +03:00
Bogdan Chadkin	c2bf7d4af2	feat: support self-hosting animations (#5341 ) While animations source code is still private here enabled publishing minified version of it so users who self-hosting websites could deploy. them with working animations.	2025-08-03 19:51:35 +02:00
Bogdan Chadkin	63c54fcad6	refactor: upgrade remix and react-router (#5177 ) This should fix a few vulnerabilities we get from react-router and vite	2025-05-02 00:35:20 +04:00
Ivan Starkov	a068bc9ab4	experimental: Error support on components level (#5136 ) ## Description Error toasts in components instead of failing ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2025-04-18 11:04:59 +04:00
Ivan Starkov	acbb03827c	experimental: Various Animation fixes (#5122 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2025-04-14 16:45:52 +03:00
Ivan Starkov	b0e7bfda56	experimental: Animations, disable BFCache in Chrome 134 and FF (#5111 ) ## Description 1. What is this PR about (link the issue and add a short description) ## Steps for reproduction 1. click button 2. expect xyz ## Code Review - [ ] hi @kof, I need you to do - conceptual review (architecture, feature-correctness) - detailed review (read every line) - test it on preview ## Before requesting a review - [ ] made a self-review - [ ] added inline comments where things may be not obvious (the "why", not "what") ## Before merging - [ ] tested locally and on preview environment (preview dev login: 0000) - [ ] updated [test cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md) document - [ ] added tests - [ ] if any new env variables are added, added them to `.env` file	2025-04-09 20:28:05 +03:00
Bogdan Chadkin	1dc7af7621	refactor: add tag property control (#5080 ) https://github.com/webstudio-is/webstudio/issues/3632 Here added dedicated tag property control which will automatically migrate Box, Text and Heading components to instance.tag internally and will be used for ws:element component. Later will extend tag control with tag descriptions and auto inferring matching tags. <img width="428" alt="Screenshot 2025-04-02 at 15 56 46" src="https://github.com/user-attachments/assets/fa8d24ba-b9e8-4221-b47a-a9e923475bb6" />	2025-04-03 11:07:43 +07:00

1 2 3 4 5