recipe runtime.backend: "wordpress" is accepted by the schema, then silently runs wordpress-playground

[chubes4]

The workspace recipe schema advertises two runtimes:

"backend": { "enum": ["wordpress-playground", "wordpress"] }

A recipe declaring "backend": "wordpress" validates clean, and then runs on Playground anyway:

$ wp-codebox recipe validate --recipe ./native.json --json
  "valid": true

$ wp-codebox recipe-run --recipe ./native.json
WP Codebox recipe
Runtime: wordpress-playground      <-- not what the recipe declared

Minimal recipe that reproduces it:

{
  "schema": "wp-codebox/workspace-recipe/v1",
  "runtime": { "backend": "wordpress", "name": "native-probe", "wp": "7.0", "blueprint": { "steps": [] } },
  "workflow": { "steps": [ { "command": "wordpress.run-php", "args": ["code=echo \"NATIVE_OK\";"] } ] },
  "artifacts": { "directory": "artifacts/native-probe" }
}

Shipped packages are cli, runtime-core, runtime-playground, runtime-cloudflare — there is no native runtime, so the fallback looks intentional. The problem is that it is silent.

Why this is worth fixing

A declared runtime that quietly becomes a different runtime is hard to reason about from the outside. I spent a long stretch attributing failures to the Playground/WASM runtime while believing I had opted out of it, because both validation and the run reported success paths that never mentioned the substitution.

Suggested options

1. Reject "backend": "wordpress" at validation time while no native runtime is installed, with a blocker naming the available backends, or
2. Keep accepting it and emit a structured observation on the run ("declared backend wordpress resolved to wordpress-playground"), or
3. Drop the value from the enum until a native runtime ships.

Any of the three is better than a silent substitution.

---

AI assistance: GPT-6 Astra via OpenCode found this while trying to run a large WordPress source tree outside WASM, and confirmed the fallback with the minimal recipe above.