Oleg Isonen
44f0956579
A Form-only POST action was falsely reported as running when a page renders. The security audit now uses the same resource-selection logic as page generation, while still warning when the POST is also used for page content. This PR also shows editors the actual Content-mode save rejection instead of a misleading build-permission message. Patch commits stop waiting after two minutes. A lost response leaves the result uncertain and refreshes project state without resending the patch; completed version conflicts retain the same-transaction confirmation retry. Staging publish jobs now include the complete hosted URL, so agents do not have to guess the publisher host. Screenshot capture reports page JavaScript errors without including the page's error text or script URL. SVG content edits now keep their image type and dimensions; the reported HTTP 500 in #6615 remains unverified. It does not change the shared-Slot rule that caused #6637. Closes #6622 Closes #6620 Ref #6615 Ref #6637 Ref #6648 Ref #6635 The SVG revision fix changes one production line and reuses the existing asset-type detector. Screenshot error detection stays tied to the active page frame during navigation, so an outgoing page or embedded frame cannot be blamed for the next capture. Script URLs are omitted because their paths can contain private data or point to a logging call instead of the fault. ## Tasks - [x] Make timeout/reset commit handling safe when the original server request may still be running; add a regression test. - [x] Remove untrustworthy screenshot source locations; update regression tests and PR claims. - [x] Re-run focused checks, review the final diff, and monitor required CI after the merge-safety fixes. All four required workflows passed on `9d79ce052b`. - [x] Reproduce the SVG revision type loss in #6615's workflow; preserve image metadata and verify the uploaded bytes. - [x] Keep the reported HTTP 500 open: the original asset was identified from production data, but the failed PUT status/request ID is unavailable, so this PR does not claim a fix. - [x] Keep the approved generic screenshot error wording for #6635; verify the focused test and required CI. - [x] Reproduce #6635's missing JavaScript source location with a CDP fixture, then remove path reporting after review found it could expose private page data. Keep #6635 open for a safe diagnostic design. - [x] Review documentation impact for the screenshot diagnostic. The authoritative MCP guide documents screenshot inputs, not this error output, so no docs change is needed. - [x] Re-run focused tests, typechecks, and CI after the screenshot change. All required CI workflows passed. - [x] Reproduce #6620's initial connection reset and deadline failures, then verify uncertain-commit handling without an unsafe resend. - [x] Return the correct hosted staging URL for #6648; verify the current origin against the reported project without republishing. - [x] Check the other reports against production records and code paths; keep unverified causes open rather than claim fixes. - [x] Reproduce #6622 with a regression test that failed before the fix and passed afterward. - [x] Reuse the page-resource selection logic in the audit; cover an independently rendered POST and a connected Content Block. - [x] Reproduce the misleading Content-mode message with a failing test, then preserve the specific reason after checking edit permission. - [x] Review the authoritative docs; correct the native Form action instructions and regenerate MCP docs. - [x] Triage recent reporter issues: close #6634 as a duplicate of #6636 and #6630 as untestable without a project ID; keep the other project/environment-specific reports open. - [x] Run focused tests, typechecks, lint, package-boundary and generated-doc checks. No fixture inputs or outputs changed. - [x] Monitor required CI checks and fix failures. All workflows pass; the visual test now hides its blinking editor caret. - [x] Review the final diff and review threads. No unrelated files or open review threads. - [x] Run the approved full Luna/low agent evaluations and record the failures below. ## Verification - #6615: the SVG revision test failed before the one-line fix because storage received `file` instead of `image`; it passes now with SVG bytes, image metadata, and the same asset ID. All 314 asset-uploader tests and its typecheck pass. Read-only production checks found the original 4,292-byte SVG and later 4,457-byte replacement; both parse as 581×140 images, and no failed-update revision was saved. The original HTTP 500 remains unreproduced, so #6615 stays open. No fixture inputs or generated fixture outputs changed. The existing asset docs already cover SVG editing; no docs change is needed. - Audit: 41 tests pass (new test failed before the fix). - SDK resource generation: 71 tests pass. - Builder patch authorization: 10 tests pass (changed test failed before the fix). - Project-build, SDK, CLI, and Builder typechecks pass; lint and package-boundary checks pass. - Generated MCP docs are clean. All required CI workflows pass. - #6620: the reset/deadline tests failed before the merge-safety fix and pass now without a resend. HTTP client tests (50) and focused project-session tests (55) pass, as do the Project Build, Vision, and CLI typechecks, lint, and package boundaries. The patch request abort is exercised with a simulated deadline; no production mutation was made. - #6635: the published home page returned HTTP 200, produced a full-page Chrome screenshot, and had no current page JavaScript error. A synthetic Chrome page confirmed that both thrown exceptions and `console.error` can yield a script URL, but the URL path is not safe or necessarily the fault location. The capture now omits that URL while retaining page-frame error detection. Focused Vision tests (60), CLI preview tests (50), typechecks, lint, and package-boundary checks pass. The reported page fault itself is not reproduced today, so the issue remains open. - #6626: the reported published route now returns HTTP 404; the current home page has no images and a full-page Chrome screenshot succeeds. This does not recreate the image-heavy local preview or its DevTools disconnect. - #6648: the project’s reported staging builds are marked published; its current `.wstd.io` origin returns HTTP 200, while `.wstd.work` returns 404. New staging URL tests failed before the change and pass after it, including already-qualified and custom-only domains. Domain tests (17), Builder API router tests (53), Domain and Builder typechecks, lint, and generated API checks pass. The API still does not verify DNS at publish time, so this issue remains open. - Full Luna/low agent suite after the #6635 change: 6 of 9 fixtures passed. Both Markdown blog fixtures again failed at screenshot verification with `ENOENT`. The managed-Form authoring agent missed template discovery, audit, and responsive evidence in this run; that fixture passed in the previous run. The MDX fixture passed. The suite is not claimed as green. Existing baselines use incompatible or missing model settings and were not updated. Connected MDX inside the same Form remains a conservative audit case: the audit cannot inspect that document's resource references from Builder state alone.
Webstudio CLI
The Webstudio CLI helps you to link, sync and build projects from Webstudio Cloud. This README will guide you through the process of setting up a Webstudio project on your local machine and continually sync it with the cloud.
Prerequisites: Installing Node.js
You need Node.js to use the Webstudio CLI. If Node.js is already installed in your system, you can skip ahead to the section on installing the Webstudio CLI.
To install Node.js using NVM, first install NVM by running:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
Once NVM is installed, you can install Node.js version 22 by running:
nvm install 22
Verify your Node.js installation by checking its version:
node --version
Installing the Webstudio CLI
To get started with the Webstudio CLI:
-
Download and install the CLI using the following command:
npm install -g webstudio@latest -
Confirm the installation by checking the CLI version:
webstudio --version -
To keep your CLI updated, use the same command used for installation whenever a new release is available.
Initiating a Webstudio Project
Now, you can run a Webstudio project on your local machine using this command:
webstudio
This will initiate the flow to connect your Webstudio Cloud project and build it in your local computer. The default flow will guide you through the steps. You can also perform all the operations individually using independent commands.
Commands
Here is the list of independent commands:
- version
- help
- link
- sync
- build
link
The link command stores access to a Webstudio Cloud project. MCP clients use that connection to read and edit the latest Builder build directly; the project does not need to be published or synchronized first.
Shell-capable agents can call MCP tools directly as CLI subcommands immediately after linking. This does not require MCP client configuration or a client restart:
webstudio meta.index
webstudio components.search '{"brief":"button"}'
webstudio insert-fragment --input-file .temp/insert-fragment.json --dry-run
.temp/insert-fragment.json:
{
"parentInstanceId": "<parent-id>",
"fragment": "<section />"
}
The explicit equivalent is webstudio mcp single-op-call <tool> '<json>'.
Use webstudio connect <client> only when you want persistent native MCP tools
inside Claude Code, Codex, Cursor, or VS Code. A persistent client may need to
reconnect after its configuration or cached tool catalog changes.
See the Webstudio MCP documentation for setup, discovery, editing, verification, and safety guidance.
You can link a project from Webstudio Cloud with the following command:
webstudio link
This command will prompt you to paste a link which you can create using the Share option in your project.
Make sure to provide Build access when generating the link in Webstudio Cloud.
sync
Once the project is linked, use the sync command to sync it with the cloud:
webstudio sync
Sync downloads the current saved Builder project and its asset files, then prepares the local content index. Publishing is not required.
Use the export with webstudio build or webstudio import --to "<target-share-link>". Sync is not required for MCP editing.
build
Now, you can build your project with the build command:
webstudio build
During this phase, the CLI establishes the necessary routes and pages, scaffolding the entire application using the default Remix template. Additionally, all assets, such as images and fonts are downloaded to the assets folder inside the public directory.
Once the project is scaffolded, you can run npm install and then npm run dev to run your app in development mode.
If you want to build a production version of the app, you can run npm run build.
Deployment
Vercel
Once you've built the project locally, you can use the Vercel CLI to deploy your project directly to Vercel:
vercel deploy
Follow the instructions here to install the vercel CLI. We plan to add more deployment targets in future.
Netlify
If you want to deploy to netlify, you can use Netlify CLI to deploy your project directly to Netlify:
netlify deploy
You can configure the project to support netlify serverless/edge-functions respectively, as deployment target at the time of initially setting up your project. Please check the initiating-a-webstudio-project section.
You can manually change it using the build command. For serverless functions:
webstudio build --template netlify
Important Notes
If you use vercel build before vercel deploy, make sure to clean your app folder in the project afterward.
Vercel injects a few files to support and deploy Remix using their CLI, but these files are not necessary for your project when you use it locally.