Repository navigation
Block Runner 0.9.11: whole sites, native blocks
0.9.11 brings whole sites into Block Runner: native block themes, page content, shared headers and footers, patterns and media. Quite a lot hiding behind a patch number.
Your agent supplies the site structure. Block Runner compiles it locally, checks the blocks and theme references, and gives you a bundle you can inspect before it touches WordPress.
Build the page content from native headings, images, buttons, tables, code and FAQs, so people can keep editing it in WordPress. Templates and shared parts give the pages a proper theme structure, whilst declared assets and synced-pattern bindings travel with the site.
A complete site workflow. Compile the source, plan against an explicit WordPress target, then confirm the exact changes you want to apply. Apply tracks the records Block Runner owns and preserves other page fields, including author, excerpt and dates. Every mutation has a journal entry. Uncertain outcomes stop the run.
The editor gets a return path. Inspect drift, preview saved template and part edits, then pull selected changes back into your local theme files. To check save behaviour, proof --theme exercises mounted files in the Site Editor. proof --site covers controlled site fixtures.
Existing themes get the same checks. Point validate at a theme folder to check its block markup, WordPress 7.1 theme.json schema and local template-part, pattern and preset references. fix --write repairs eligible markup in place, with strict checks honoured before writing.
There's plenty under the bonnet too:
- Attribute order now follows WordPress 7.1's server-side definitions, and native Accordion icons land in the right place.
- Unknown-block warnings go to stderr, keeping markup stdout usable in a pipeline.
- First-install images in synced patterns work, and both canonical source identity and macOS output paths are fixed. Draft dates survive edits, whilst publishing a floating draft uses WordPress's publication time.
- Apply does less repeated source scanning, snapshot transport and pattern compilation. Duplicate tests were removed; benchmark and evidence tooling run separately with their CI and release checks retained.
- Wesper is updated to 0.5.0.
We ran the release through 881 product tests (four existing skips), 43 separate tooling tests, packed consumers, skill installation and the full generated-plugin WordPress 7.1 release matrix. CI passed Node 22.13/24, package-boundary and WordPress acceptance; the publishing workflow repeated the release matrix before npm publication. Fresh installs and npm signatures/provenance were checked too.
After publication, we also exercised native pages and complete block themes on a local WordPress 7.1 site: real editor edits, saves, reopening and full desktop comparisons. Save persistence and visual fidelity remain separate checks. Existing scoped editor accessibility exceptions remain, and this is local proof rather than broad theme or production acceptance. The optional model benchmark remains unscored.
Upgrading: use Node 22.13+ on 22.x, or 24+; Node 20, 21 and 23 are unsupported. Theme deployment and activation are still separate from site apply. Pre-release bundles using retired site identity/ownership formats need fresh compilation and planning; interrupted apply still requires guarded manual lock reconciliation, and held locks are never stolen.
Refresh the agent skill:
npx block-runner@0.9.11 skill --installThe theme and site guide has the input format, commands and proof boundaries. Install from npm.