Abilities API: add execution lifecycle filters to WP_Ability methods

[gziolo]

Summary

Adds four new filters to WP_Ability to give plugins hook points across the execution
lifecycle. Today the only execution-phase hooks are observation-only actions
(wp_before_execute_ability, wp_after_execute_ability); plugins that need to
transform input, modify output, override permission decisions, or short-circuit
execution have no place to do that in core, and have built parallel hook systems
on top.

This PR closes that gap by introducing four filters that live inside their
owning WP_Ability methods (so they apply consistently across execute() and
direct callers, including REST permission checks), plus one orchestration-level
filter at the top of execute() for short-circuiting.

Filters added

Filter	Where	Purpose
wp_pre_execute_ability	top of execute()	Short-circuit. Returning a value other than the received default bypasses the entire pipeline. Uses an stdClass sentinel as the default so null is a valid short-circuit result.
wp_ability_normalize_input	inside normalize_input()	Transform input — prompt enrichment, parameter defaulting beyond JSON Schema, caller metadata injection. Returning WP_Error halts execution.
wp_ability_permission_result	inside check_permissions()	Override the registered permission_callback result. Applies consistently across execute() and direct check_permissions() callers.
wp_ability_execute_result	inside do_execute()	Transform the result before output validation. Can also recover from execute callback failures by returning a successful value in place of WP_Error.

Pipeline ordering inside execute()

wp_pre_execute_ability  (filter, can short-circuit)
  → normalize_input()   → wp_ability_normalize_input  (filter)
  → validate_input()
  → check_permissions() → wp_ability_permission_result (filter)
  → wp_before_execute_ability  (existing action)
  → do_execute()        → wp_ability_execute_result   (filter)
  → validate_output()
  → wp_after_execute_ability   (existing action)
  → return

Schema validation remains the final integrity gate: wp_ability_normalize_input
fires before validate_input(), and wp_ability_execute_result fires before
validate_output(). Filters cannot bypass schema validation except by
short-circuiting via wp_pre_execute_ability, where the caller takes
responsibility for the returned value's shape.

REST behavior

WP_REST_Abilities_V1_Run_Controller::check_ability_permissions() now propagates
WP_Error results from normalize_input() directly instead of feeding them into
validate_input(). When the filter does not set its own status, the controller
defaults to 400; filter-set statuses (e.g., 422, 429) are preserved.

Commits

1. wp_ability_normalize_input filter
2. wp_ability_permission_result filter
3. wp_pre_execute_ability filter
4. wp_ability_execute_result filter
5. REST status default for normalization filter errors (preserves filter-set statuses)
6. stdClass sentinel for wp_pre_execute_ability so null is a valid short-circuit result

Test plan

• npm run env:composer -- format — clean
• npm run env:composer -- lint — clean
• npm run env:composer -- compat — clean
• npm run typecheck:php — 0 errors
• PHPUnit Abilities suite — 1138 tests passing

New tests cover:

• Each filter's transformation contract (input rewrite, permission grant/deny override, WP_Error recovery, result transform), with filter args verified via args-as-guards on the transformed value rather than side-effect captures.
• Short-circuit semantics for wp_pre_execute_ability: pipeline configured to fail (permission denial) so the short-circuit value coming through cleanly proves the bypass.
• null short-circuit preserved by the sentinel pattern.
• Ordering: wp_ability_execute_result runs before output validation and before wp_after_execute_ability.
• WP_Error propagation from wp_ability_normalize_input halts execution.
• wp_ability_permission_result firing when check_permissions() is called directly.
• REST: normalization filter errors default to status 400 and preserve filter-set statuses.

Trac ticket

https://core.trac.wordpress.org/ticket/64989

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code, Codex
Model(s): Claude Opus 4.7 (1M context)
Used for: Planning, implementation, unit tests, code review, commit messages, and PR description.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props gziolo, migueluy.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[lezama]

This is super useful for any substrate that mediates ability execution on behalf of agents. Sharing four concrete use cases from that perspective so the filter shapes can be validated against them:

Filter	Use case in an agent runtime
wp_pre_execute_ability	Approval boundary: an agent runtime that ships a pending-action approval gate can hook here to short-circuit with an "approval required" envelope when a sensitive ability is invoked, instead of running. Also useful for contract tests: a recording harness can short-circuit with canned tool results so non-conversation behavior (provider call → tool call → provider call) gets locked into baselines without real execution.
wp_ability_normalize_input	Agent context injection: the runtime can inject the current execution principal (calling agent ID, user, workspace, caller-chain context) into the ability's input. Abilities that need agent context don't have to receive it as an explicit parameter — it's normalized in by the substrate layer.
wp_ability_permission_result	Tool access policy: an agent-level access policy (e.g. "this agent's bearer token doesn't authorize destructive abilities") can override the ability's registered permission_callback without modifying the ability itself. Cleaner than wrapping every ability with a delegating permission_callback.
wp_ability_execute_result	Transcript / observability: tool calls + results get captured into the agent's transcript or routed to a telemetry sink without each ability having to opt in. The fact that this fires before validate_output() is exactly right — it preserves the integrity gate.

The "schema validation remains the final integrity gate" framing matches what a substrate wants downstream: filters can transform but can't bypass the contract.

One small thing I'd double-check: when the agent runtime hooks wp_pre_execute_ability and short-circuits with an approval envelope, the caller (an AgentConversationLoop or similar) needs to be able to distinguish "approval pending" from "ability returned a value" in the response shape. A typed sentinel value object would be clearest there, but with the current mixed return + sentinel approach the runtime can wrap with a typed value object on its side — the filter API doesn't need to bake that in.

cc / FYI: this would be consumed by Automattic/agents-api once it lands in core.