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
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
- Provider spike: package or load the Playground Kandelo POC behind an experimental WP Codebox backend provider without changing existing default behavior.
- Contract harness: run a bounded representative WP Codebox recipe suite against both engines and emit a machine-readable compatibility report.
- Capability closure: file and link owning-layer Kandelo or Playground issues for each unsupported or divergent contract; keep unsupported results explicit.
- Evidence parity: prove existing host Playwright and artifact collection are engine-neutral.
- 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.
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
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
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:
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:
Compatibility matrix
Run the same WP Codebox recipes and evidence assertions against PHP.wasm and Kandelo. Record supported, unsupported, divergent, and failed behavior for:
runPHP,writeFile,installPlugin, activation, options, and login;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
Acceptance criteria
Non-goals
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.