fix: stop the browser runtime from hardcoding consumer component names (#633)#636
Merged
Conversation
The browser runtime component registry shipped agents-api / data-machine / data-machine-code as built-in defaults — including pinned Extra-Chill release zip URLs — and the required-component set was hardcoded to the same trio. A generic sandbox substrate must not name the downstream plugins that consume it nor where to fetch them; doing so means adding a runtime consumer requires editing the substrate. Make both seams config-driven: - browser_runtime_component_registry() now defaults to an empty map and is populated solely via the existing wp_codebox_browser_runtime_component_registry filter. - The required-component set is now supplied via a new wp_codebox_browser_runtime_required_components filter, defaulting to empty, instead of a hardcoded array. Consumers register their own agent-stack components + release sources through these filters (the integration layer owns those names). Update the WordPress plugin smoke to register the canonical components via the filters at setup, mirroring real consumer wiring; full suite passes (419 assertions). Refs the layer-purity audit: trait-wp-codebox-abilities-browser-runtime.php is now clean of consumer names; the remaining data-machine references in the agent-runner / execution / pending-actions paths are tracked separately.
chubes4
added a commit
to Extra-Chill/extrachill-roadie
that referenced
this pull request
Jun 5, 2026
…ime (#45) WP Codebox is dropping its hardcoded browser-runtime component defaults (Automattic/wp-codebox#636) so the generic substrate stops naming the plugins that consume it. Roadie is the integration layer that legitimately knows both the Extra Chill agent stack and wp-codebox — its recipe builder already mounts that stack — so it is the correct place to declare the runtime's required components and their release sources. Register agents-api / data-machine / data-machine-code via the new wp_codebox_browser_runtime_required_components and wp_codebox_browser_runtime_component_registry filters. These mirror the on-disk stack roadie mounts via wp_codebox_component_paths; the registry provides the release-zip fallback wp-codebox uses when a component is not already on disk. Refs Automattic/wp-codebox#633.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the layer-purity leak in #633's primary location: the browser runtime hardcoded the names of downstream consumers (
agents-api,data-machine,data-machine-code) — including pinnedExtra-Chill/GitHub release-zip URLs — and hardcoded the required-component set to the same trio. A generic sandbox substrate must not name the plugins that consume it, nor where to fetch them.The fix (config, not code)
trait-wp-codebox-abilities-browser-runtime.php:browser_runtime_component_registry()now defaults to an empty map. The registry is supplied entirely via the existingwp_codebox_browser_runtime_component_registryfilter.wp_codebox_browser_runtime_required_componentsfilter (default empty), replacing the hardcodedarray( 'agents-api', 'data-machine', 'data-machine-code' ).Consumers register their own agent-stack components + release sources through these filters — the integration layer owns those names. (For the Extra Chill platform, that registration lives in the integration plugin; a companion PR wires it there.)
After this change:
Tests
Updated
tests/smoke-wordpress-plugin.phpto register the canonical components via the two filters at setup — mirroring real consumer wiring rather than relying on hardcoded substrate defaults. The full WordPress plugin smoke passes:Scope note (honest)
This PR fixes the registry + required-slugs seam — the cleanest, most clearly config-able part of #633. The remaining
data-machinereferences in the agent-runner / execution / pending-actions paths (trait-wp-codebox-abilities-browser-runner.php,trait-wp-codebox-abilities-execution.php,class-wp-codebox-agent-sandbox-runner.php,class-wp-codebox-data-machine-pending-actions.php— notably the\DataMachine\Engine\AI\LoopEventSinkInterfacecoupling anddata_machineresult-metadata keys) are more entangled and are left as tracked follow-ups under #633 rather than bundled here.Refs #633.