Flag HTML block misuse during validation

[youknowriad]

Adds a content-policy pass to block validation so section-sized core/html blocks are reported as invalid and corrected during the agent validation loop.

Proposed Changes

• Add a small HTML block content policy helper that allows inline SVG, form/input markup, interaction markup with no block equivalent, and single script blocks.
• Apply that policy inside validate_blocks so editable layout and text markup inside core/html fails validation with remediation guidance.
• Update the validate_blocks tool description and add unit coverage for allowed and disallowed HTML block uses.

Testing Instructions

• Ask Studio Code to build a one-page site with a logo/client section and verify generated page sections use editable core blocks instead of wrapping text/layout content in core/html.
• Validate content containing <!-- wp:html --><section><h1>Auran</h1><p>Precision furniture.</p></section><!-- /wp:html --> and confirm validate_blocks reports a policy issue.
• Validate content containing a single inline SVG or script HTML block and confirm it remains allowed.

Automated Checks

• npx eslint --fix apps/cli/ai/block-content-policy.ts apps/cli/ai/block-validator.ts apps/cli/ai/tools.ts apps/cli/ai/tests/block-content-policy.test.ts
• npm run typecheck
• npm test -- apps/cli/ai/tests/block-content-policy.test.ts
• npm run cli:build
• node apps/cli/dist/cli/main.mjs --help

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 33fc200 vs trunk

app-size

Metric	trunk	33fc200	Diff	Change
App Size (Mac)	1454.05 MB	1453.95 MB	0.10 MB	⚪ 0.0%

site-editor

Metric	trunk	33fc200	Diff	Change
load	1798 ms	1744 ms	54 ms	🟢 -3.0%

site-startup

Metric	trunk	33fc200	Diff	Change
siteCreation	8074 ms	8119 ms	+45 ms	⚪ 0.0%
siteStartup	4946 ms	4943 ms	3 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[youknowriad]

I've tried this on 3 different sites now. The HTML block validation is working properly and the end result doesn't have html blocks in it. The tradeoff is that there's a few more turns when building the site but I think it's an acceptable tradeoff for now given the consistency of the results.

[youknowriad]

I also like the simplicity of this approach.

[epeicher]

Adding some comments for reference after testing with my testing prompt:

• The quality of the result doesn't seem to be impacted, I see similar results to previous attempts. I identified a double border on one of the buttons , maybe this could be further refined. On previous testing, I avoided that by refining the prompt, although maybe there are more robust approaches.
• I tested twice, and in the second one it reached the maximum limits of attempts, but in the first attempt it didn't, so I don't think if it's related to these changes, as the validation phase completed in not many attempts. The multiple iterations happened in the Take screenshots phase
• The site took ~31 minutes to complete, logs here: 3c105637582f019a85d57890bedc066a-logstash
• Most of the blocks (I think all of the editable ones) were converted successfully ✅

All in all, I think this is a step forward, as we’re avoiding custom HTML blocks and the quality doesn’t seem to be impacted.

[youknowriad]

I do think this creates more turns but we should try to reduce that number in other ways. Also maybe we should disable that max turns entirely now.