Spike: feature-gated inc/abilities.php (Abilities API)

[Schmandarine]

brmbh's agent layer runs outside WordPress, over SSH — the right architecture for building a site, the wrong one for operating one. An agent with no shell access cannot touch a brmbh site today.

The Abilities API is the missing inside-out half, and it is core, standardised and vendor-neutral — which is precisely the "no MCP tax, no lock-in" position the project already claims. One wp_register_ability() call fans out to REST, the MCP adapter, editor JS and WP-CLI with no extra code.

Two abilities are enough to prove it.

Needs WP 6.9+ at runtime against our declared 6.4+ floor, so it must self-disable rather than raise the floor:

// inc/abilities.php
if ( ! function_exists( 'wp_register_ability' ) ) {
    return;
}
add_action( 'wp_abilities_api_init', 'brmbh_register_abilities' );

• brmbh/health — doctor's class: ready|warn|blocked envelope is already an output schema, and this drops the SSH requirement entirely
• brmbh/scaffold-pages — already idempotent, already runs inside WordPress
• Set both public and show_in_rest in meta: the unified public flag is 7.1, but 6.9/7.0 sites only read the older key
• Out of scope: /deploy and /sync-db. Destructive and CANONICAL_ENV-guarded — exposing them to any authenticated agent inverts the guardrail
• Out of scope: the AI Client (wp_ai_client_prompt(), provider plugins). A starter theme shipping LLM calls inherits API-key management and per-provider failure modes for no benefit to building page sections. If ever, a separate brmbh/ai plugin

Worth noting: SCF itself added Abilities API integration in 6.8.4 — the ecosystem is moving this way.

Agent surface

Needs its own skill. An ability no agent can discover is not a capability. Plus doctor reporting Abilities presence → needs a @brmbh/cli release.

---

Context: vault .../Development/WP-7.1-Impact.md §3