Generate deterministic static registered-block source

[noeltock]

Problem

Block Runner currently produces post content. It has no artifact that WordPress can register as a reusable inserter block. Asking the model to write React, PHP, metadata, and CSS directly would recreate the invalid-markup problem at a larger and more dangerous source-code boundary.

Solution

Create a deterministic source compiler that consumes a confirmed AuthoringPlan and emits the standard static WordPress block files from owned, versioned templates.

Approach

• Add src/authoring/generate.ts and typed emitters for JSON, JS/JSX, CSS, and PHP.
• Own and version the output template contract. A pinned @wordpress/create-block plus local template is permitted only if it produces the same deterministic artifact; never invoke @latest.
• Emit API v3 block.json, index.js, edit.js, save.js, style.scss, and editor.scss.
• Register from metadata on the server and with registerBlockType on the client.
• Use style for shared editor/frontend CSS; omit view.js and render.php in the static 0.9 path.
• Parse/compile every generated source type before it can be written.
• Record every file path, kind, content hash, template version, and source-plan hash.
• Keep this subsystem separate from src/convert/finalize.ts, which finalizes post content rather than source packages.

Out of scope

• Dynamic PHP rendering.
• Frontend interaction generation.
• Model-authored executable source.
• Direct Figma or InDesign ingestion.

Acceptance criteria

• One plan produces byte-identical files across repeated runs.
• Generated metadata validates against the pinned target schema.
• Generated JS/CSS/PHP parses and the project builds from a clean install.
• WordPress registers the block on server and client.
• The saved static markup contains the planned native inner content.
• Output has no Block Runner or Tailwind runtime dependency.
• Unsupported executable behaviour blocks generation with a source-located reason.