Problem
The browser-agent runner currently spans multiple execution contexts: generated PHP runner code, browser JS, Playground client.run(), request-handler execution, runtime tool callbacks, and artifact capture. Recent live evals showed that helper functions and request APIs can be available in one context but missing or differently shaped in another.
Observed failures from live eval work include:
- Generated PHP fatal:
Call to undefined function wp_codebox_browser_artifact_environment() in /internal/eval.php.
- Browser request execution failure:
TypeError: Cannot read properties of undefined (reading 'request') from the Playground worker endpoint.
These failures happen before provider/tool-loop diagnostics in some runs, which means the runtime execution contract itself is not stable enough.
Goal
Make browser recipe runner execution use one explicit, tested execution contract across Playground client variants.
Scope
- Identify the supported Playground client APIs for PHP execution, file writing, directory creation, and request handling.
- Normalize those API calls behind a small browser-runtime helper layer.
- Ensure generated runner helper functions are available in the same PHP execution context that invokes runtime tools and captures artifacts.
- Prefer a single reliable execution path for browser recipe PHP over opportunistic switching between
client.run() and file-request execution unless both paths are contract-tested.
- Emit structured runtime failure details instead of generic
Generation failed where possible.
Acceptance criteria
- Browser recipe execution works against the current Playground client shape used by Studio Web live evals.
- Helper functions required for artifact capture are available in the capture context.
- Failures identify a stable phase/code/message instead of only surfacing a browser console stack trace.
- Existing
node --check packages/wordpress-plugin/assets/browser-runtime.js passes.
- Existing
php tests/smoke-wordpress-plugin.php remains green.
Related context
Problem
The browser-agent runner currently spans multiple execution contexts: generated PHP runner code, browser JS, Playground
client.run(), request-handler execution, runtime tool callbacks, and artifact capture. Recent live evals showed that helper functions and request APIs can be available in one context but missing or differently shaped in another.Observed failures from live eval work include:
Call to undefined function wp_codebox_browser_artifact_environment()in/internal/eval.php.TypeError: Cannot read properties of undefined (reading 'request')from the Playground worker endpoint.These failures happen before provider/tool-loop diagnostics in some runs, which means the runtime execution contract itself is not stable enough.
Goal
Make browser recipe runner execution use one explicit, tested execution contract across Playground client variants.
Scope
client.run()and file-request execution unless both paths are contract-tested.Generation failedwhere possible.Acceptance criteria
node --check packages/wordpress-plugin/assets/browser-runtime.jspasses.php tests/smoke-wordpress-plugin.phpremains green.Related context