Define in-sandbox DMC workspace and tool contract

[chubes4]

Gap

DMC can be mounted into the sandbox, but the workspace root, file edit policy, and tool exposure contract are not defined.

Goal

Make DMC the mounted coding-tools component for file-editing agent sandboxes, with a clear sandbox-only workspace boundary.

Acceptance direction

• Define where sandbox workspaces live inside Playground.
• Configure DMC to expose file/workspace/GitHub tools against sandbox-mounted paths only.
• Prevent edits to parent host paths except through explicit mounts.
• Capture changed files and workspace metadata as artifacts.
• Support repo-backed and site-backed task modes.
• Document which DMC abilities are safe for sandbox agents versus parent-site operators.

Notes

DMC is required for file-editing coding sandboxes. It should provide tools inside the sandbox, while Sandbox Runtime owns lifecycle/control-plane outside the sandbox.

[chubes4]

Use case: monorepo-mounted coding tasks for non-technical-owner sites

Adding a concrete shape this contract has to handle: a real site whose plugins and theme live together in a monorepo, mounted into the sandbox as one workspace.

Cluckin' Chuck (see #35) is structured this way:

github.com/chubes4/cluckin-chuck/
├── cluckin-chuck/               (theme)
├── wing-location-details/        (plugin)
├── wing-map-display/             (plugin)
├── wing-review/                  (plugin)
├── wing-review-submit/           (plugin)
├── cluckin-chuck-cli/            (plugin)
├── cluckin-chuck-api/            (plugin)
└── cluckin-chuck-agent-kit/      (plugin)

When an owner asks for "add a Dry Rub filter to the map," the agent needs to read across the theme, the map block plugin, and possibly the review plugin to do it right. So the contract needs to accommodate multi-component mounts where edits span components in a single coherent change.

Specific things I'd want pinned down:

• Workspace root inside Playground is stable and documented. /workspace or /wp-codebox-workspace — something predictable that DMC tools and any other mounted component can both reference. Not arbitrary per-run.
• Mount layout preserves the repo structure when a repo is mounted. Files at wing-map-display/blocks/map/render.php in the repo are at <workspace>/wing-map-display/blocks/map/render.php in the sandbox. This matters because in-sandbox tooling (like running tests, building blocks) often expects relative paths.
• wp-content mounts can coexist with workspace mounts. The same plugin can live in wp-content/plugins/wing-map-display for WordPress to load it and be editable via the workspace path. Either symlinked or the same physical path. Without this, the agent can't edit a plugin and then probe it via wp-admin in the same sandbox.
• Repo-backed vs site-backed modes are explicit (already in acceptance, +1). Repo-backed = workspace is a git checkout, edits produce a patch against HEAD. Site-backed = workspace is a snapshot of a running site's wp-content, edits produce a changed-files bundle. The patch artifact (Standardize patch, package, and artifact outputs for sandbox coding tasks #26) shape changes per mode.
• DMC's GitHub tools should be restricted by default in sandbox mode. The in-sandbox agent shouldn't be pushing branches or opening PRs from inside the sandbox — that's apply-back's job (Add reviewed apply-back flow for approved sandbox artifacts #27), on the parent side, with reviewed permission. Sandbox-side GitHub tools, if exposed at all, should be read-only (clone, read PR comments) and explicitly opt-in per task.
• Workspace metadata as artifact: git ref the workspace started from, list of mounts and their sources, any .gitignore exclusions applied. This is what makes Standardize patch, package, and artifact outputs for sandbox coding tasks #26 provenance real.
• Document which DMC abilities are sandbox-safe vs parent-only, as the acceptance says — explicit allow-list, not "everything except." Parent-side DMC abilities like "deploy to live site" should be statically unreachable from a sandbox-mounted DMC. Probably enforced by separate ability registrations rather than runtime checks.

Edge case to call out: what happens when a task touches multiple plugins in a monorepo? The patch needs to cleanly reference all changed files, the changed-files manifest needs to flag which component each file belongs to, and apply-back (#27) needs to handle "PR contains changes to 3 plugins in one repo" without splitting them. Worth confirming the contract supports this, since it's the normal case for any non-toy WordPress project.

Context for the non-technical-owner angle: #35.