| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
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:
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.
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:
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.
| Mode | Driver | Lifetime | Example |
|---|---|---|---|
| Co-located runtime | External agent CLI on the host | Long-lived install | wp-coding-agents on a VPS, a Studio site with a co-located coding agent |
| In-process flow | DM AI step inside a flow | Long-lived install | An Intelligence wiki maintenance flow calling workspace abilities; a webhook-triggered PR review flow |
| Ephemeral CI | DM flow inside Playground / GitHub Actions | One job | wc-site-generator static-site validation; the Stage 5 Playground proof |
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.
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.
# 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
# Workspace
wp datamachine-code workspace path
wp datamachine-code workspace path repo-name@fix-foo
wp datamachine-code workspace list
wp datamachine-code workspace clone https://github.com/org/repo.git
wp datamachine-code workspace show repo-name
# Worktrees — one per branch, parallel-safe
wp datamachine-code workspace worktree add repo-name fix/foo
wp datamachine-code workspace worktree list
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 <repo> (primary) or <repo>@<branch-slug> (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-fooThe workspace is worktree-native. Each branch lives in its own directory at <workspace>/<repo>@<branch-slug> (slashes in branch names become dashes). Multiple agent sessions — or multiple flows, or multiple CI jobs — can edit different branches of the same repo simultaneously without stepping on each other.
DMC discovers primary checkouts and worktrees by scanning the configured workspace root. Worktree lifecycle metadata supports cleanup and reconciliation; if that workspace path is not visible to PHP, DMC cannot see the checkouts.
SQLite is supported for DMC registries and lower-concurrency workspace use. For concurrent fleet cooking, use MySQL: SQLite permits one writer at a time. DMC retries short SQLite busy/locked registry writes with bounded backoff and returns a structured lock-contention error when that budget is exhausted; it does not make prolonged multi-writer contention equivalent to MySQL throughput.
Workspace and worktree commands are shell-backed and require a host where PHP can see the configured workspace root.
The primary checkout (bare <repo>) is read-only by default for mutating operations — pass --allow-primary-mutation to override. The default-deny is intentional: the primary tracks the deployed branch, and silent branch-switches on it are how parallel agents corrupt each other's work.
~/.datamachine/workspace/ ├── data-machine/ ← primary, hands-off by default ├── data-machine@fix-foo/ ← worktree for fix/foo └── data-machine@feat-bar/ ← worktree for feat/bar
Set your GitHub Personal Access Token and default repository in Data Machine settings:
DMC registers a Data Machine webhook verifier mode named github_pull_request for PR-review flows. Configure the flow's webhook auth verifier with that mode and the same secret configured in the GitHub repository webhook.
The verifier checks X-Hub-Signature-256 against the raw request body, requires X-GitHub-Event: pull_request, accepts only opened, reopened, synchronize, and ready_for_review actions by default, optionally restricts repository.full_name, and skips draft PRs unless allow_drafts is true.
Example verifier config:
array(
'mode' => 'github_pull_request',
'secrets' => array(
array(
'id' => 'github_webhook',
'value' => '<shared webhook secret>',
),
),
'repo' => 'Extra-Chill/data-machine-code',
'allowed_actions' => array( 'opened', 'reopened', 'synchronize', 'ready_for_review' ),
'allow_drafts' => false,
)Workspace git policies are configured via the datamachine_workspace_git_policies option for per-repo write/push controls.
The GitHub fetch handler (data_source: issues or pulls) supports both server-side and post-fetch label/keyword filters. Server-side labels is forwarded to GitHub's REST list issues / list pulls endpoints; the post-fetch filters run after the API call and trim the in-memory result set.
| Field | Tier | Semantics |
|---|---|---|
| labels | server-side | Comma-separated label names. Forwarded to the GitHub REST endpoint. ANY-match include. |
| exclude_labels | post-fetch | Comma-separated label names. ANY-match drop, case-insensitive. Empty/missing is a no-op. Applies to both issues and pulls. |
| exclude_keywords | post-fetch | Comma-separated terms matched against title + body. ANY-match drop. |
| search | post-fetch | Required-keyword filter against title + body. |
| timeframe_limit | post-fetch | Bounds items by created_at. |
GitHub's REST list issues endpoint does not support negative label syntax, so exclude_labels is implemented as a post-fetch array intersection — symmetric with exclude_keywords in the same handler. Combine labels (positive, server-side) with exclude_labels (negative, post-fetch) to express "match these AND NOT those" in flow JSON without an AI-step prompt guard. Dropped items are logged at debug with the offending label(s).
DMC registers bundled, agent-generic Data Machine pipeline templates for recurring workspace maintenance. They are discoverable through the normal pipeline surface:
wp datamachine pipeline list --search="DMC Workspace"Terminology:
Bundled templates:
The bundled records do not provision flows or schedules. Create flows from these pipelines when an agent/site has explicit maintenance policy, thresholds, and dry-run/apply settings.
┌──────────────────────────────────────────────────────────────────┐
│ Drivers — anything that pulls the trigger │
│ │
│ (a) External coding-agent runtime on the host │
│ any external coding agent CLI │
│ → reads AGENTS.md, calls back via WP-CLI / MCP / REST │
│ │
│ (b) In-process Data Machine flow on the site │
│ AI step → tool call → DMC ability │
│ → no external runtime, site codes on its own behalf │
│ │
│ (c) Ephemeral CI job (Playground + Actions) │
│ Boots WP with DMC + DM, runs a flow, posts to PR, dies │
└──────────────────────────────────────────────────────────────────┘
▲
│ uses the same capability surface
▼
┌──────────────────────────────────────────────────────────────────┐
│ data-machine-code (this plugin) │
│ - composes & owns AGENTS.md at the WP root │
│ - declares \DataMachineCode\Environment capabilities │
│ - hosts the workspace area (~/.datamachine/workspace/) │
│ - registers GitHub / workspace / git abilities │
└──────────────────────────────────────────────────────────────────┘
▲
│ built on
▼
┌──────────────────────────────────────────────────────────────────┐
│ data-machine (core) │
│ - AI engine, pipelines, jobs, agents │
│ - Memory system, MemoryFileRegistry, SectionRegistry │
│ - Abilities API plumbing, tool framework │
└──────────────────────────────────────────────────────────────────┘
▲
│ also extended by
▼
┌──────────────────────────────────────────────────────────────────┐
│ Handler-adding siblings — different role from DMC │
│ - data-machine-socials (social platforms) │
│ - data-machine-business (transforms) │
│ - ... │
└──────────────────────────────────────────────────────────────────┘
DMC extends core base classes (BaseTool, SystemTask, BaseCommand, FetchHandler) and registers its capabilities through standard Data Machine hooks (datamachine_tools, datamachine_tasks, MemoryFileRegistry, SectionRegistry, Abilities API). Its difference from the handler-adding siblings is what it changes about the install, not what API it uses to register things.
Memory and guideline disk projection follows the same boundary: Data Machine owns logical memory semantics and storage backends; DMC owns local runtime/file projection when explicit update events and writable disk are available. See Memory Disk Projection.
Other plugins should gate disk-side or shell-using behavior on explicit DMC capability checks rather than on platform sniffing:
if ( class_exists( '\DataMachineCode\Environment' ) ) {
// DMC is active. Register API-first integrations, then check
// narrower filesystem/shell capabilities before disk runtime hooks.
}
\DataMachineCode\Environment::has_shell(); // can we shell_exec?
\DataMachineCode\Environment::has_writable_fs(); // can we write outside /uploads?
This is intentionally simpler than detecting WP.com vs VIP vs self-hosted vs CI vs Studio. What matters is which DMC subsystem the caller needs: API-first GitHub, writable filesystem projection, or shell-backed workspace/git.
Mounted runtimes can self-configure DMC by passing a context through $GLOBALS['mounted_runtime_context'], $GLOBALS['wordpress_runtime_context'], MOUNTED_RUNTIME_CONTEXT, or MOUNTED_RUNTIME_WORKSPACE_ROOT.
When a runtime needs to pass a versioned contract, use the generic WordPress runtime schema:
{
"schema": "wordpress/runtime-context/v1",
"payload": {
"workspace_root": "/workspace",
"runtime_workspace": {
"root": "/workspace",
"mounts": [
{ "target": "/workspace/example", "sourceMode": "mounted" }
]
}
}
}DMC unwraps the versioned payload to the same internal context shape as the generic mounted-runtime contract, so existing workspace root and mount adoption behavior stays shared. runtime_workspace is the canonical workspace object; legacy runtime-specific workspace aliases should be translated by the runtime owner before DMC receives the context.
GPL v2 or later
| Back | FazBrowse Home | New Git URL |