Route Plugin Check through public WordPress workloads

[chubes4]

Problem

WP Codebox exposes wordpress.plugin-check in the runtime command catalog and implements it in the Playground runtime, but the canonical wp-codebox/run-wordpress-workload path does not route the command. A valid declarative workload returns wp_codebox_wordpress_workload_step_unsupported instead of running Plugin Check.

Reproduction

Run a wp-codebox/wordpress-workload-run/v1 request with a mounted plugin and this step:

{
  "command": "wordpress.plugin-check",
  "args": ["plugin-slug=data-machine"]
}

Observed result: the safe WordPress workload runner marks the step skipped with wp_codebox_wordpress_workload_step_unsupported.

Expected behavior

The public workload interface should route the catalogued wordpress.plugin-check recipe command through the disposable Playground implementation, install the official Plugin Check plugin, validate the mounted target, and return normalized wp-codebox/plugin-check/v1 artifacts.

Acceptance criteria

• wp codebox run-wordpress-workload accepts wordpress.plugin-check.
• The command runs only through the contained Playground runtime and preserves existing command policy enforcement.
• Raw and normalized Plugin Check artifacts are returned through the public workload result.
• Deterministic coverage proves a mounted plugin can be checked through the public CLI/ability path.

AI assistance

• Model: GPT-5.6 Sol
• Tool: OpenCode
• Used for: Reproducing the public/runtime routing mismatch, inspecting the owning command implementations, and drafting this issue. Chris Huber remains responsible for the report and resulting change.

[chubes4]

Verified boundary

The contained Node CLI path already works end-to-end: wp-codebox run-wordpress-workload executed wordpress.plugin-check against a readonly mounted Data Machine v0.174.0 release package in disposable WordPress 7.0 and emitted normalized wp-codebox/plugin-check/v1 artifacts.

The defect is specifically the WordPress plugin facade exposed as wp codebox run-wordpress-workload. Its in-process safe runner rejects wordpress.plugin-check, and repository-wide inspection found no production registration for the wp_codebox_wordpress_workload_runners filter that could hand the request to the existing Node/Playground runtime. Merely making the safe runner yield changes the failure to runner-unavailable; a mock provider test does not prove the public WordPress path.

The owning fix therefore needs a real production bridge from the WordPress ability/CLI facade to the contained runtime provider, with end-to-end coverage that does not inject a test-only runner.

Artifact evidence from the successful contained run: runtime runtime-msw0dgxn-9tr53l; Plugin Check returned 253 findings (19 errors, 234 warnings) against the exact v0.174.0 release ZIP.

AI assistance

• Model: GPT-5.6 Sol
• Tool: OpenCode and Homeboy
• Used for: Runtime reproduction, candidate review, and identification of the missing production provider bridge. Chris Huber remains responsible for the analysis.