Add generic WordPress runtime inspection tools for agents

[chubes4]

Problem

Agents that run inside WordPress can inspect GitHub repositories and DMC workspaces, but they do not have a first-class, policy-gated way to inspect their own live WordPress runtime.

That leaves agent bundles and prompts carrying too much preloaded context. It also pushes us toward bespoke skills or memory files for facts the agent should be able to discover directly: installed plugins, active theme, mu-plugins, drop-ins, WordPress/PHP versions, and source files under safe WordPress roots.

Skills are the wrong abstraction for this. Runtime inspection is perception, not a recipe. Agents should be able to inspect their body, decide what matters, and write durable memory deliberately.

Proposed shape

Add generic, non-mutating AI tools and abilities for WordPress runtime inspection.

Suggested tools:

• wordpress_runtime_inventory
  • Return WP version, PHP version, active theme/template/stylesheet, installed themes, installed plugins with active/network-active status, mu-plugins, drop-ins, relevant non-secret constants, and readable root metadata.
• wordpress_runtime_ls
  • List files/directories under allowlisted runtime roots such as wp-content/plugins, wp-content/themes, wp-includes, and optionally wp-admin.
• wordpress_runtime_read
  • Read text files under allowlisted runtime roots with max-size limits, line offsets/limits, binary detection, and path traversal protection.
• Optional later: wordpress_runtime_search
  • Search allowlisted runtime source files by pattern with output limits.

Security boundary

Do not expose arbitrary filesystem reads. Default deny sensitive paths and roots, including:

• wp-config.php
• .env and secret/config files
• uploads by default
• logs/cache directories
• SQLite/MySQL database files
• private Data Machine memory files unless explicitly routed through the memory system

All tools should be read-only, bounded, and policy-gated for chat/pipeline contexts like the existing DMC tools.

Why DMC

DMC already owns code/workspace/GitHub surfaces for agents. This fills the missing local-runtime perception layer so WordPress-hosted agents can reason about the installed code they are actually running against.

Acceptance criteria

• Agents can list installed plugins/themes and active status from the live WordPress runtime.
• Agents can list/read allowlisted WordPress source files with traversal and size protections.
• Tools are available to chat and pipeline contexts through the existing tool registration/policy path.
• Tests cover inventory output, allowlisted reads, denied sensitive paths, path traversal rejection, and oversized/binary file behavior.
• Documentation describes the security model and intended use: perception first, memory only when the agent intentionally records a durable fact.