WordPress 6.9 Abilities API provides standardized capability discovery and execution for Data Machine operations. All REST API, CLI, and Chat tool operations delegate to registered abilities.

The Abilities API in inc/Abilities/ provides a unified interface for Data Machine operations. Each ability implements execute_callback with permission_callback for consistent access control across REST API, CLI commands, and Chat tools.

Total registered abilities: 167

All abilities support agent_id and user_id parameters for multi-agent scoping. The PermissionHelper class resolves scoped agent and user IDs, enforces ownership checks via owns_resource() and owns_agent_resource(), and controls access grants via can_access_agent().

Internal abilities for the pipeline execution engine.

Extensions: datamachine/check-duplicate runs extension strategies before core's generic matching via the datamachine_duplicate_strategies filter. See Duplicate Detection Filters for the strategy contract and registration example.

Data Machine registers multiple ability categories via wp_register_ability_category() on the wp_abilities_api_categories_init hook. Category slugs use the datamachine-{domain} format (e.g. datamachine-content, datamachine-flow, datamachine-pipeline):

wp_register_ability_category(
    'datamachine-flow',
    array(
        'label' => 'Flow',
        'description' => 'Flow CRUD, scheduling, queue management, and webhook triggers.',
    )
);

See AbilityCategories.php for the full list of registered categories.

All abilities support both WordPress admin and WP-CLI contexts via the shared PermissionHelper:

// Standard permission check
PermissionHelper::can_manage(); // WP-CLI always returns true; web requires manage_options

// Multi-agent scoped permission check
PermissionHelper::can_access_agent($agent_id);
PermissionHelper::owns_resource($resource_user_id);
PermissionHelper::resolve_scoped_agent_id($params);
PermissionHelper::resolve_scoped_user_id($params);

REST API endpoints, CLI commands, and Chat tools delegate to abilities for business logic. Abilities are the canonical, public-facing primitive; service classes are considered an internal implementation detail and are being phased out as abilities become fully self-contained.

REST API Endpoint → Ability → (Service layer used during migration) → Database
CLI Command → Ability → (Service layer used during migration) → Database
Chat Tool → Ability → (Service layer used during migration) → Database

Note: many ability implementations are already self-contained and do not call service managers. Where services remain, they are transitional and will be migrated into abilities per the migration plan.

Several top-level ability classes serve as facades that instantiate sub-ability classes from subdirectories:

• ChatAbilities.php → Chat/CreateChatSessionAbility.php, etc.
• EngineAbilities.php → Engine/RunFlowAbility.php, etc.
• FlowAbilities.php → Flow/QueueAbility.php, Flow/WebhookTriggerAbility.php, etc.

Each abilities class registers abilities on the wp_abilities_api_init hook:

public function register(): void {
    add_action( 'wp_abilities_api_init', array( $this, 'register_abilities' ) );
}

Unit tests in tests/Unit/Abilities/ verify ability registration, schema validation, permission checks, and execution logic:

• AuthAbilitiesTest.php - Authentication abilities
• FileAbilitiesTest.php - File management abilities
• FlowAbilitiesTest.php - Flow CRUD abilities
• FlowStepAbilitiesTest.php - Flow step abilities
• JobAbilitiesTest.php - Job execution abilities
• LogAbilitiesTest.php - Logging abilities
• PipelineAbilitiesTest.php - Pipeline CRUD abilities
• PipelineStepAbilitiesTest.php - Pipeline step abilities
• PostQueryAbilitiesTest.php - Post query abilities
• ProcessedItemsAbilitiesTest.php - Processed items abilities
• SettingsAbilitiesTest.php - Settings abilities

CLI commands execute abilities directly. See individual command files in inc/Cli/Commands/ for available commands.

The PostTracking class in inc/Core/WordPress/PostTracking.php provides post tracking functionality for handlers creating WordPress posts.

Meta Keys:

• _datamachine_post_handler: Handler slug that created the post
• _datamachine_post_flow_id: Flow ID associated with the post
• _datamachine_post_pipeline_id: Pipeline ID associated with the post

Usage:

use DataMachine\Core\WordPress\PostTracking;

// After creating a post
$this->storePostTrackingMeta($post_id, $handler_config);