Expose generic WordPress host process capabilities to consumers

[chubes4]

Problem

A WordPress Studio runtime intentionally disables child-process spawning. A consumer that supports both fanout and synchronous execution had no canonical host capability to inspect, so the site needed an ad hoc MU plugin to null its fanout callback and force one worker.

Function-existence checks are insufficient: proc_open may exist while policy denies execution, and each plugin should not rediscover host restrictions independently. The missing contract encourages product-specific patches and failed spawn attempts.

Expected simplification

wp-coding-agents projects one generic, filterable host-execution capability contract through WordPress. Consumers select their supported execution mode from that declaration. Intelligence and individual products remain free of platform names and probing logic.

Acceptance criteria

• Define generic capabilities for child-process execution and writable local process workspace.
• Fail closed when the host does not declare support.
• Provide a WordPress filter/ability surface consumers can inspect without depending on wp-coding-agents classes.
• Studio/local/VPS profiles declare capabilities in their owning integration layer.
• Replace repeated function_exists(proc_open) assumptions in wp-coding-agents-owned adapters with the capability.
• Include tests for available, intentionally unavailable, and undeclared hosts.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode traced an import orchestration workaround back to the missing generic host contract, inspected existing wp-coding-agents capability surfaces, deduplicated current trackers, and drafted this issue. Chris Huber clarified that Studio intentionally disallows proc_open and directed a generic simplification.