Data Machine Code

Data Machine Code gives a WordPress site code-adjacent GitHub and workspace abilities — API-first GitHub operations and shell-backed workspaces for installs that can run a local coding runtime. Built on Data Machine, powered by the Abilities API.

Who pulls the trigger is up to you. DMC has three driver modes, and each mode uses only the capabilities the host actually supports:

• An external coding-agent runtime on your machine pointed at the site — interactive, human-in-the-loop; requires shell/git/workspace access.
• The site itself, via a Data Machine flow — scheduled or webhook-triggered; can use API-first GitHub abilities without a shell, or workspace abilities when the host supports them.
• An ephemeral CI job that boots a WordPress instance with DMC loaded for a single check (Playground + GitHub Actions). The site exists for one job, codes for one PR, dies.

Managed-host support depends on the subsystem. GitHub API abilities use wp_remote_request() and are designed to work on managed hosts. Workspace, worktree, shell-git, AGENTS.md projection, and co-located runtime features require a host where PHP can see and mutate the configured workspace and, for git operations, execute shell commands.

What It Is

DMC's activation is the declarative answer to "does this WordPress site have code-adjacent capabilities?" When DMC is loaded, the install gains GitHub API abilities and shell-backed workspace/git abilities when the environment supports them. The \DataMachineCode\Environment surface lets other plugins gate disk-side behavior without guessing which host they are running on.

That framing reshapes what every other plugin can assume:

• AGENTS.md is composed and written to the WP root for external runtimes that discover it on session start, when the filesystem permits it. DMC owns the file, contributes core sections, and lets other plugins register more via Data Machine's SectionRegistry. In-process and CI drivers don't use AGENTS.md — they get context through Data Machine's normal channels (system prompts, memory files, flow user messages). AGENTS.md is a co-located-runtime feature, not the universal interface.
• The site gains GitHub, workspace, and git abilities through the Abilities API. API-first abilities are host-portable; workspace/git abilities are still gated by filesystem and shell capability.
• A worktree-native workspace area at ~/.datamachine/workspace/ lets shell-capable installs clone repos, edit files in isolated branches, and push changes — all gated by per-repo policies. Same workspace whether the editor is an external runtime, an in-process AI step, or a CI job.
• \DataMachineCode\Environment is a capability surface plugins can read to ask "is DMC active?", "can we shell out?", "is the filesystem writable outside /uploads?". Other DM plugins use it to gate disk-side hooks (e.g. Intelligence's SKILL.md sync).

The important seam is not self-hosted versus managed; it is API-first versus shell-backed. Managed sites can use the API-first pieces when installed and configured. Shell-backed coding-runtime features remain intentionally limited to hosts that expose shell/git/workspace access.

Driver Modes

The registered surface is broad, but callers should select abilities that match the host. For example, a managed-host flow can use GitHub API abilities, while a co-located runtime can additionally use workspace and shell-git abilities.

How It Differs From Other Data Machine Extensions

Sibling extensions like data-machine-socials and data-machine-business are handler-adding — they extend DM's pipeline machinery with new sources, destinations, or transforms. DMC is runtime-altering — its presence changes what kind of system this is. That's why DMC owns AGENTS.md, declares environment capabilities, and gates the existence of an entire class of disk-side functionality. Same plugin chassis, fundamentally different role.

Features

GitHub Integration

• List, view, update, close, and comment on issues
• List pull requests and repositories
• Create issues (async via Action Scheduler)
• GitHub fetch handler for pipeline workflows
• GitHub pull request webhook validation mode for review-flow triggers
• PR review flow scaffold for webhook-triggered review automation with bounded context gathering and managed comment upsert

Workspace Management

• Clone and manage git repositories in a secure workspace directory
• Read, write, and edit files within workspace repos
• List directory contents with file metadata
• Bundled Data Machine pipeline templates for workspace inventory, metadata repair, artifact cleanup, retention cleanup, and emergency cleanup Requires a host where PHP can read and write the configured workspace path.

Git Operations

• Status, log, diff (read-only)
• Pull, add, commit, push (policy-controlled)
• Per-repo write/push policies with path allowlists and branch restrictions Requires shell execution and a local git binary.

AI Agent Tools

• GitHub and workspace chat tools for read-only context gathering plus managed PR review comments
• WordPress runtime inspection tools for read-only perception of live versions, plugins/themes, drop-ins, and allowlisted source files
• Async GitHub issue creation via system tasks
• All tools register through Data Machine's tool system, which means they're equally available to external runtimes (via MCP/REST/WP-CLI) and to in-process / CI drivers (via direct AI-step tool calls)

WP-CLI

# GitHub
wp datamachine-code github issues --repo=owner/repo
wp datamachine-code github view 123 --repo=owner/repo
wp datamachine-code github close 123 --repo=owner/repo
wp datamachine-code github comment 123 "Fixed." --repo=owner/repo
wp datamachine-code github pulls --repo=owner/repo
wp datamachine-code github repos owner
wp datamachine-code github review-flow create --repo=owner/repo --agent=code-reviewer
wp datamachine-code github status

# Managed release drift (the configured distribution channel owns updates)
wp datamachine-code runtime release --format=json
wp datamachine-code runtime release --apply --format=json

# Runtime/source drift (read-only unless --apply is explicit)
wp datamachine-code runtime doctor
wp datamachine-code runtime doctor --apply

Configure the authoritative checkout and optional command contract with the
`datamachine_code_runtime_source_doctor_config` filter. Its `source_path` and
`release_ref` values resolve only an `origin/<branch>` tracking ref or an immutable
tag; the doctor reports stale or diverged local branch refs without fetching or
mutating Git state. `command_contract` may provide a
`command` and `flag` so the doctor can report a source-supported flag that the
active WP-CLI registration rejects. The doctor never reconciles unless
`--apply` is explicit. Copied and Git runtimes may register `external_reconciler`
with an `owner`, typed `action`, and explicit `reconcile` callback. The callback
receives runtime/source/release identities, and its result is accepted only after
the active runtime is re-inspected. Official packages may include immutable
`Package-Version`, `Package-Source-Tag`, `Package-Source-Commit`, and
`Package-Digest` headers in `data-machine-code.php`; matching headers verify
package provenance without requiring a source-tree file-set match. Headers are
package metadata, not trust roots: configure an independently obtained
`trusted_release_provenance` record with the same version, tag, commit, and
digest or the doctor reports the package as untrusted. Package assemblers inject
the headers with:

```bash
php bin/dmc-package-provenance --package-dir=/path/to/package --version=1.2.3 --source-tag=v1.2.3 --source-commit=<40-char-commit>

Persist the command's JSON result with the release record and supply it through the runtime configuration filter. The package digest excludes only the digest header value itself, allowing the independently persisted digest to detect every other package/header change.

add_filter('datamachine_code_runtime_source_doctor_config', static function (array $config): array {
    $config['external_reconciler'] = array(
        'owner' => 'deployment integration',
        'action' => array(
            'type' => 'command',
            'command' => 'owner deploy command',
            'authorize_callback' => static fn(): bool => current_user_can('update_plugins'),
        ),
        'reconcile' => static function (array $identity): array {
            // The owning integration updates $identity['runtime']['path'].
            return array( 'success' => true, 'changed' => true, 'message' => 'Deployment completed.' );
        },
    );
    $config['trusted_release_provenance'] = array(
        'version' => '1.2.3',
        'source_tag' => 'v1.2.3',
        'source_commit' => '<40-char-commit>',
        'package_digest' => '<64-char-sha256-from-release-record>',
    );
    return $config;
});

Workspace

wp datamachine-code workspace path wp datamachine-code workspace path repo-name@fix-foo wp datamachine-code workspace list

The default is a lightweight 50-row page. Request its cursor in the JSON envelope.

wp datamachine-code workspace list --format=json --envelope

Continue with --cursor=, or explicitly expand all rows and Git status probes when needed.

wp datamachine-code workspace list --all --include-status --format=json wp datamachine-code workspace clone https://github.com/org/repo.git wp datamachine-code workspace show repo-name

Default freshness compares cached tracking refs and is reported as local_tracking_current.

Opt into a bounded network fetch for remote_verified_current evidence.

wp datamachine-code workspace show repo-name --refresh

Worktrees — one per branch, parallel-safe

wp datamachine-code workspace worktree add repo-name fix/foo

The table default is a summary-first, lightweight 50-row page. Legacy JSON,

CSV, and YAML streams remain exhaustive; use JSON --envelope for a cursor.

wp datamachine-code workspace worktree list wp datamachine-code workspace worktree list --format=json --envelope wp datamachine-code workspace worktree list --all --full --format=json wp datamachine-code workspace worktree remove repo-name fix/foo wp datamachine-code workspace worktree prune

Daily workspace cleanup — task-backed, inspectable by run_id

wp datamachine-code workspace cleanup run --mode=retention wp datamachine-code workspace cleanup status cleanup-run-123 wp datamachine-code workspace cleanup evidence cleanup-run-123 --format=json

All read/write/git ops accept either (primary) or @ (worktree)

wp datamachine-code workspace read repo-name@fix-foo src/main.php wp datamachine-code workspace ls repo-name@fix-foo src/ wp datamachine-code workspace write repo-name@fix-foo path/to/file.txt @content.txt wp datamachine-code workspace edit repo-name@fix-foo path/to/file.txt --old="foo" --new="bar" wp datamachine-code workspace remove repo-name wp datamachine-code workspace git status repo-name@fix-foo wp datamachine-code workspace git pull repo-name@fix-foo wp datamachine-code workspace git add repo-name@fix-foo --rel=src/file.php wp datamachine-code workspace git commit repo-name@fix-foo "fix: something" wp datamachine-code workspace git push repo-name@fix-foo wp datamachine-code workspace git log repo-name@fix-foo wp datamachine-code workspace git diff repo-name@fix-foo

### Managed Release Channels

The runtime inventory and `runtime release` command query the owning distribution
through `datamachine_code_managed_release_channel`; they never infer availability
from WordPress.org metadata. A managed distributor supplies an `id`,
`latest_version`, one `action` (`command` or `handoff`), and may supply in-process
`converge`, `read_installed_version`, and `verify` callbacks. DMC invokes a
converger only when its command action sets `authorize_callback: true`; handoffs
are never invoked. The callback result is not installation evidence: DMC reads
the installed version again through `read_installed_version`, then calls `verify`
with that observed version. `verify` returns `state: verified` and any contract
evidence, such as `cli_contract_present`.

```php
add_filter('datamachine_code_managed_release_channel', static function (array $channel): array {
    return array(
        'id'             => 'managed-distributor',
        'latest_version' => '0.57.4',
        'action'         => array('type' => 'command', 'command' => 'managed-plugin update data-machine-code', 'authorize_callback' => true),
        'converge'       => static fn(): array => array('success' => true),
        'read_installed_version' => static fn(): string => '0.57.4',
        'verify'         => static fn(string $version): array => array('state' => 'verified', 'cli_contract_present' => '0.57.4' === $version),
    );
});