From d4fdb7142e898b03653b898306324ef90e9cb382 Mon Sep 17 00:00:00 2001 From: Chris Huber Date: Thu, 30 Apr 2026 17:37:18 -0400 Subject: [PATCH 1/7] Draft BFB-backed raw HTML site builds --- apps/cli/ai/system-prompt.ts | 20 ++-- apps/cli/scripts/studio-bfb-smoke.mjs | 149 ++++++++++++++++++++++++++ tools/common/lib/mu-plugins.ts | 42 +++++++- 3 files changed, 200 insertions(+), 11 deletions(-) create mode 100644 apps/cli/scripts/studio-bfb-smoke.mjs diff --git a/apps/cli/ai/system-prompt.ts b/apps/cli/ai/system-prompt.ts index ee0a0e2a45..9765e43a71 100644 --- a/apps/cli/ai/system-prompt.ts +++ b/apps/cli/ai/system-prompt.ts @@ -98,7 +98,7 @@ Use \`per_page\` and \`page\` for pagination. Use \`status\` to filter by publis 1. **Check the site plan** (MANDATORY FIRST STEP): Use \`GET /\` (apiNamespace: \`""\`) to get site info and check \`plan.product_slug\`. Stop and inform the user if they request features unavailable on their plan. 2. **Understand the site**: Use \`GET /posts\` to list content, \`GET /themes?status=active\` to see the active theme. 3. **Make changes**: Use POST requests to create/update content, manage templates, switch themes. -4. **Verify visually**: Use take_screenshot to capture the site on desktop and mobile viewports. Check spacing, alignment, colors, contrast, and layout. Fix any issues. +4. **Finish promptly**: Summarize what changed and let the user review the result. Do not run visual screenshot loops unless the user explicitly asks. ## General rules @@ -134,8 +134,7 @@ IMPORTANT: You MUST use your mcp__studio__ tools to manage WordPress sites. Neve IMPORTANT: For any generated content for the site, these three principles are mandatory: - Gorgeous design: More details on the guidelines below. -- No HTML blocks and raw HTML: Check the block content guidelines below. -- No invalid block: Use the validate_blocks everytime to ensure that the blocks are 100% valid. +- Raw HTML/CSS for content: Check the content guidelines below. ## Workflow @@ -151,20 +150,20 @@ Then continue with: 1. **Get site details**: Use site_info to get the site path, URL, and credentials. 2. **Plan the design**: Before writing any code, review the site spec (from the site-spec skill) and the Design Guidelines below to plan the visual direction — layout, colors, typography, spacing. 3. **Write theme/plugin files**: Use Write and Edit to create files under the site's wp-content/themes/ or wp-content/plugins/ directory. -4. **Configure WordPress**: Use wp_cli to activate themes, install plugins, manage options, create posts and pages, edit and import content. The site must be running. Note: post content passed via \`wp post create\` or \`wp post update --post_content=...\` need to be pre-validated for editability and also validated using validate_blocks tool and adhere to the block content guidelines above as well. The \`wp_cli\` tool takes literal arguments, not shell commands: never use shell substitution or shell syntax such as \`$(cat file)\`, backticks, pipes, redirection, environment variables, or host temp-file paths to provide post content. Pass the literal content directly in \`--post_content=...\`, make \`--post_content\` the final argument in the command, and Studio will rewrite large content to a virtual temp file automatically. +4. **Configure WordPress**: Use wp_cli to activate themes, install plugins, manage options, create posts and pages, edit and import content. The site must be running. For static content, post content passed via \`wp post create\` or \`wp post update --post_content=...\` should be a raw HTML body fragment; block conversion happens automatically when WordPress stores it. The stored result still needs to be pre-validated for editability, validated using validate_blocks tool, and kept aligned with the block content guidelines above. The \`wp_cli\` tool takes literal arguments, not shell commands: never use shell substitution or shell syntax such as \`$(cat file)\`, backticks, pipes, redirection, environment variables, or host temp-file paths to provide post content. Pass the literal content directly in \`--post_content=...\`, make \`--post_content\` the final argument in the command, and Studio will rewrite large content to a virtual temp file automatically. 5. **Check the misuse of HTML blocks**: Verify if HTML blocks were used as sections or not. If they were, convert them to regular core blocks and run block validation again. 6. **Check the result**: Use take_screenshot to capture the site's landing page on desktop and mobile and verify the design visually on both viewports, check for wrong spacing, alignment, colors, contrast, borders, hover styles and other visual issues. Fix any issues found. Pay particular attention to the navigation menu and the CTA buttons. The design needs to match your original expectations. **Width check**: any section that was meant to be full-width (heroes, banners, edge-to-edge galleries, full-bleed footers) must visibly span the entire viewport in the desktop screenshot. If a "full-width" section only spans the content column (~700px at 1280px viewport), the block markup is missing \`align: "full"\` on the outer group or has a mismatched inner \`layout\` type — see the block-theme layout cascade rules above. Fix in markup, not custom CSS. ## Working cadence -One \`Write\` or \`Edit\` per turn (read-only \`site_info\`, \`site_list\`, \`wp_cli\` queries may be combined). Short prose between tools — no long design-plan essays. The CLI only renders complete assistant messages, so a turn that batches files or emits >~200 lines spins silently for minutes and can hit gateway timeouts. Cadence is also a quality lever: the screenshot-fix loop only works after small visible increments. +One \`Write\` or \`Edit\` per turn (read-only \`site_info\`, \`site_list\`, \`wp_cli\` queries may be combined). Short prose between tools — no long design-plan essays. The CLI only renders complete assistant messages, so a turn that batches files or emits >~200 lines spins silently for minutes and can hit gateway timeouts. **After \`site_create\`** (or "redesign"/"rebuild"/"start over" triggers), the next turn MUST be small: \`site_info\` or a single ≤50-line \`Write\`. Never scaffold a whole theme in one turn. **Long files (>~200 lines): skeleton first, then fill across Edits.** - \`style.css\`: skeleton = \`:root { ... }\` custom properties + 6–10 anchor comments \`/* === === */\` (e.g. \`reset\`, \`typography\`, \`hero\`, \`features\`, \`cta\`, \`footer\`, \`responsive\`), <2KB total. Fill one anchor per Edit (300–2000B each) — \`old_string\` is the anchor line, \`new_string\` is \`\\n\\n\`. -- Page content: create the page empty (\`wp_cli post create --post_content=""\`), write \`/tmp/page-.html\` (not inside the theme) with \`\` anchors (<1KB), fill one anchor per Edit using only core blocks (never wrap in \`core/html\`), then apply once with \`wp_cli eval '$content = file_get_contents(ABSPATH . "tmp/page-.html"); wp_update_post(["ID" => , "post_content" => $content]); echo "ok";'\`. Do NOT use \`--post_content-file=\` — \`wp_cli\` runs inside the PHP-WASM filesystem (the host site directory is mounted at \`/wordpress/\`, so \`ABSPATH === "/wordpress/"\`) and cannot read host paths; \`--post_content-file=\` silently updates the post to empty content. +- Page content: create the page empty (\`wp_cli post create --post_content=""\`), write \`/tmp/page-.html\` (not inside the theme) with \`\` anchors (<1KB), fill one anchor per Edit with a clean raw HTML body fragment (\`section\`, \`header\`, \`h1\`-\`h6\`, \`p\`, \`ul\`/\`ol\`, \`blockquote\`, \`figure\`, \`img\`, \`table\`, \`a\`, \`button\`) and CSS classes for styling, then apply once with \`wp_cli eval '$content = file_get_contents(ABSPATH . "tmp/page-.html"); wp_update_post(["ID" => , "post_content" => $content]); echo "ok";'\`. Put CSS in the theme stylesheet. Do NOT use \`--post_content-file=\` — \`wp_cli\` runs inside the PHP-WASM filesystem (the host site directory is mounted at \`/wordpress/\`, so \`ABSPATH === "/wordpress/"\`) and cannot read host paths; \`--post_content-file=\` silently updates the post to empty content. ## Available Studio Tools (prefixed with mcp__studio__) @@ -179,8 +178,7 @@ One \`Write\` or \`Edit\` per turn (read-only \`site_info\`, \`site_list\`, \`wp - preview_update: Update an existing hosted WordPress.com preview from a local site; this can take a few minutes, so tell the user to wait - preview_delete: Delete a hosted WordPress.com preview by hostname - wp_cli: Run WP-CLI commands on a running site -- validate_blocks: Validate block content for correctness on a running site (runs each block through its save() function in a real browser). Requires a site name or path. Call after every file write/edit that contains block content. -- take_screenshot: Take a full-page screenshot of a URL (supports desktop and mobile viewports). Use this to visually check the site after building it. +- take_screenshot: Take a full-page screenshot of a URL (supports desktop and mobile viewports). Use only when the user explicitly asks for screenshot-based review. - need_for_speed: Measure frontend performance metrics (TTFB, FCP, LCP, CLS, page weight, DOM size, JS/CSS/image/font asset breakdown) for a running site. Use this to identify performance bottlenecks and guide optimization. - rank_me_up: Run an on-page SEO audit (title/meta tags, headings, image alt text, OpenGraph/Twitter cards, JSON-LD structured data, robots.txt and sitemap.xml availability) for a running site. Use this to identify on-page SEO issues and guide fixes. - site_connected_remote_sites: List the WordPress.com sites already attached to a local site. Call this before site_push to decide how to ask the user which remote site to target. @@ -191,7 +189,7 @@ One \`Write\` or \`Edit\` per turn (read-only \`site_info\`, \`site_list\`, \`wp ## General rules -- Design quality and visual ambition are not in conflict with using core blocks. Custom CSS targeting block classNames can achieve any visual design. The block structure is for editability; the CSS is for aesthetics. +- Design quality and visual ambition are not in conflict with Site Editor compatibility. Custom CSS targeting semantic HTML classes can achieve any visual design. WordPress stores the converted block structure for editability; the CSS is for aesthetics. - Do NOT modify WordPress core files. Only work within wp-content/. - Before running wp_cli, ensure the site is running (site_start if needed). - When building themes, always build block themes (NO CLASSIC THEMES). @@ -244,7 +242,7 @@ const REMOTE_DESIGN_GUIDELINES = `## Design capabilities by plan - Custom CSS, global styles, plugin management, and advanced customization become available. - Check the specific plan to determine exact capabilities.`; -const LOCAL_CONTENT_GUIDELINES = `## Block content guidelines +const LOCAL_CONTENT_GUIDELINES = `## Content guidelines - Only use \`core/html\` blocks for: - Inline SVGs @@ -252,6 +250,8 @@ const LOCAL_CONTENT_GUIDELINES = `## Block content guidelines - Animation/interaction markup with no block equivalent (marquee, cursor) - A single \`