Track architecture vision: portable WordPress Playground coding-agent sandboxes

[chubes4]

Vision

Sandbox Runtime is the portable agent runner for WordPress Playground coding tasks.

It packages the isolated runtime so any WordPress control plane can safely offer coding-agent sandboxes:

Any WordPress control plane
  -> Sandbox Runtime
    -> disposable WordPress Playground site
      -> mounted agent stack
        -> Data Machine Code tools for file/workspace/GitHub operations
        -> scoped provider credentials
        -> coding task runs safely
      -> artifacts / patch proposal
  -> reviewed apply/export/discard

Control planes

Potential consumers include:

• WordPress.com
• Studio
• Extra Chill/self-hosted WordPress
• Frontend Agent Chat
• Homeboy Extensions Data Machine agent runner
• wp-gym/eval runners

Product unlocks

• Users can ask a WordPress agent to build a custom plugin without production mutation.
• Team members can get per-user isolated coding sandboxes.
• Hosted platforms can offer coding agents without exposing host shell or infrastructure access.
• Sandbox output is reviewed as artifacts/patches before apply-back.

Boundary

• Sandbox Runtime owns isolated agent execution and artifacts.
• DMC provides in-sandbox coding tools for file-editing tasks.
• Parent WordPress integrations own permissioning, sessions, and apply-back policy.

[chubes4]

Concrete consumer scenario: non-technical site owner ships changes via chat

Adding a use case to the vision that I think the architecture already supports, but is worth naming explicitly so the open issues get prioritized against a real product shape.

The user: A WordPress site owner with no GitHub account, no shell access, no PHP knowledge. They own the site, they pay for hosting, they cannot meaningfully edit code today without a developer in the loop.

The flow this vision unlocks:

Owner (in chat on their own site):
  "add a 'best dry rub wings' filter to the locations map"
        |
        v
Frontend agent calls wp-codebox/run-agent-task
        |
        v
Disposable Playground sandbox boots, repo mounted, agent edits files,
runs tests, produces patch.diff + preview + test output
        |
        v
Agent shows owner: human-readable summary + screenshot + "tests pass"
        |
        v
Owner clicks "approve" in chat
        |
        v
Apply-back opens a PR authored by a bot identity (e.g. homeboy bot or
GitHub App), CI runs, deploy lands the change

The owner never touches git, GitHub, a terminal, or a code editor. The bot identity owns the source-control side. Review happens in their own site's chat UI, not in a PR review tool.

Why this audience matters for the vision:

• It's a much larger population than "developers who want a sandbox." Every non-technical WordPress site owner with an agent is a candidate.
• It is the audience that cannot be served by giving broader access to a real environment. Sandbox + reviewed apply-back is the only safe path.
• It forces the apply-back contract (Add reviewed apply-back flow for approved sandbox artifacts #27), the review UX contract (Define frontend progress and review UX contract #32), and the task API (Replace low-level PHP code input with product task API #29) to be designed for someone who reads diffs visually, not textually.
• It justifies the "bot-authored PR" path explicitly in apply-back, separate from "operator with a GitHub identity opens a PR."

Concrete dogfooding target: I'm building Cluckin' Chuck (a chicken wing review site) for a non-technical site owner right now. He has no GitHub account. Today he asks me to make changes; I edit in a workspace monorepo, commit, push, and homeboy deploys. Replacing "asks me" with "asks the on-site agent" is exactly the flow above. I'd like to use this site as the first real product consumer driving #27/#32/#29 to completion, if that aligns with the direction.

Flagging this so the open issues get evaluated against "can a non-technical owner ship a real change end-to-end" as one of the acceptance scenarios, not just "can a developer get a sandbox."