Add an experimental Kandelo-backed Playground runtime

首先阅读 issue #974 中 WP Codebox runtime backend 的 factory seam，以及现有的 runtime、recipe 和 evidence contract。针对基于 PHP.wasm 和 Kandelo 的 provider 运行代表性 recipe 和 host-side Playwright suite，然后比较机器可读的 compatibility report。完成的标准是：显式 engine 选择能够正常工作且不改变默认值，不支持的 capability 能够明确失败，并且所需的 evidence 和 artifact contract 仍保持兼容。

Goal

Run WP Codebox's existing WordPress runtime, recipe, Playwright, and evidence contracts against WordPress Playground backed by Kandelo, while preserving Playground as the WordPress compatibility boundary and Kandelo as the runtime owner.

This should provide a concrete downstream proving ground for Kandelo and a compatibility path toward Playground eventually selecting Kandelo by default.

Existing upstream work

• Kandelo roadmap and Playground integration direction: https://github.com/Automattic/kandelo/issues/382
• Playground CLI proof of concept: https://github.com/WordPress/wordpress-playground/pull/3634
• Playground Web proof of concept: https://github.com/WordPress/wordpress-playground/pull/3635
• WP Codebox runtime backend factory seam: https://github.com/Automattic/wp-codebox/issues/974

The Playground proof-of-concept branches already run nginx and PHP-FPM on Kandelo and preserve substantial portions of the Playground CLI, client, worker-endpoint, and Blueprint interfaces. They remain experimental and document current capability gaps.

Ownership boundaries

• WP Codebox owns runtime selection, lifecycle, mounts, snapshots, recipes, host-side Playwright automation, browser evidence, policy, artifacts, replay, and compatibility reporting.
• WordPress Playground owns the WordPress-facing runtime API, Blueprint behavior, client/worker endpoint compatibility, and engine selection integration.
• Kandelo owns the POSIX kernel, nginx/PHP-FPM runtime, VFS, process/network behavior, binaries, and runtime defects.
• Homeboy and Homeboy Extensions consume WP Codebox's generic contracts unchanged. They should not acquire Kandelo-specific paths, environment names, or behavior.

Downstream recipes should remain engine-neutral. Kandelo or Playground deficiencies discovered by the matrix should be linked upstream rather than hidden with WP Codebox-specific compensating behavior.

Proposed shape

Start with an explicit experimental backend/provider so capability differences remain honest, for example:

wordpress-playground
wordpress-playground-kandelo

Once Playground exposes a stable engine selector with compatible behavior, converge toward a single Playground backend with explicit engine configuration:

{
  "backend": "wordpress-playground",
  "runtime": {
    "engine": "kandelo"
  }
}

When Playground makes Kandelo the default and compatibility is proven, callers should no longer need to select an engine.

Playwright remains host-side in every topology:

WP Codebox
  -> host Playwright / Chromium
  -> WordPress Playground contract
  -> PHP.wasm or Kandelo
  -> WordPress

Compatibility matrix

Run the same WP Codebox recipes and evidence assertions against PHP.wasm and Kandelo. Record supported, unsupported, divergent, and failed behavior for:

• runtime creation, readiness, teardown, cancellation, and resource bounds;
• WordPress and PHP version selection;
• host mounts, readonly mounts, staged files, and generated artifacts;
• Blueprint steps used by WP Codebox, including runPHP, writeFile, installPlugin, activation, options, and login;
• WordPress HTTP, PHP, WP-CLI, PHPUnit, and ability execution;
• checkpoints, snapshots, restore, and replayable bundles;
• browser preview routing, authentication, cookies, mapped domains, and multisite;
• Playwright browser probes, actions, scenarios, screenshots, traces, console/errors, network, WebSockets, visual comparison, and adaptive exploration;
• SQLite and declared external-service/database behavior;
• runtime overlays, PHP extensions, and dependency projection;
• deterministic artifact schemas, provenance, diagnostics, and cleanup evidence.

Compatibility proof must cover existing response and artifact schemas, observability identifiers, timing/retry behavior, mixed engine selection, and failure classification, not only successful new workflows.

Delivery slices

1. Provider spike: package or load the Playground Kandelo POC behind an experimental WP Codebox backend provider without changing existing default behavior.
2. Contract harness: run a bounded representative WP Codebox recipe suite against both engines and emit a machine-readable compatibility report.
3. Capability closure: file and link owning-layer Kandelo or Playground issues for each unsupported or divergent contract; keep unsupported results explicit.
4. Evidence parity: prove existing host Playwright and artifact collection are engine-neutral.
5. Promotion gate: define the subset required for supported experimental use, then the complete parity gate required before default selection or backend convergence.

Acceptance criteria

• WP Codebox can select Kandelo explicitly without changing the existing PHP.wasm default.
• At least one real mounted WordPress plugin runs through the same recipe on both engines.
• The same host Playwright command captures browser assertions, screenshot, console/error, network, and trace evidence from both engines.
• A machine-readable compatibility report identifies every exercised contract dimension and links known gaps to owning upstream trackers.
• Existing WP Codebox recipe, runtime, response, artifact, provenance, retry, and cleanup contracts remain compatible.
• Unsupported Kandelo capabilities fail explicitly with stable diagnostics rather than silently falling back to PHP.wasm.
• Kandelo selection does not introduce Kandelo-specific concepts into Homeboy or Homeboy Extensions.
• A documented promotion gate defines when Kandelo can be treated as equivalent and when the explicit engine distinction can be removed.

Non-goals

• Running Chromium or Playwright inside Kandelo.
• Reimplementing Playground's Kandelo adapter in WP Codebox.
• Forking WP Codebox browser evidence for Kandelo-specific behavior.
• Making Kandelo the default before Playground integration and compatibility evidence support that decision.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode was used to inspect the current Kandelo, Playground, and WP Codebox runtime boundaries; identify the canonical ownership model; and draft this tracker. Chris Huber reviewed and remains responsible for the issue.