feat(system-task): DispatchMessageTask wrapping agents/dispatch-message

[chubes4]

Summary

Add a new system_task — DispatchMessageTask — that wraps the agents/dispatch-message ability (agents-api v0.107.0+) for use inside Data Machine flows. This is the DM-side adapter that lets a scheduled flow trigger an outbound message through whatever channel runtime is registered (e.g. the CLI transport in Extra-Chill/data-machine-code#412, which is now live).

Why

agents/dispatch-message is the canonical primitive for "send this message through a registered channel transport." It exists in agents-api and is consumed by DMC's CLI transport runtime. What's missing is the bridge from a DM pipeline flow tick to that ability — i.e. a system_task. Without it, flows can call agent_call (raw HTTP webhook) but cannot dispatch through the agents-api channel substrate.

This task is to agents/dispatch-message what AgentCallTask (inc/Engine/AI/System/Tasks/AgentCallTask.php) is to datamachine/agent-call — a thin system_task wrapper.

Contract

handler_config shape

```json
{
"task": "dispatch_message",
"params": {
"channel": "kimaki",
"recipient": "1476075959806590989",
"message": "Agent Ping: Update PROGRESS.md ...",
"conversation_id": null,
"attachments": [],
"client_context": {},
"metadata": {}
}
}
```

Required: channel, recipient, message. The rest are optional and pass through to the ability.

Behavior

1. Resolve wp_get_ability( 'agents/dispatch-message' ). If null, fail the job with a clear error (the substrate isn't loaded — agents-api missing or too old).
2. Pass params through to $ability->execute( $params ).
3. On WP_Error, fail the job with the error code + message.
4. On canonical output ({ sent, channel, recipient, message_id, metadata }), succeed the job and surface the output in the result envelope per the SystemTask base contract.

The task does NOT know about kimaki, Discord, or any specific transport. The channel resolution happens entirely inside the ability + its registered handler (DMC's CLI transport, etc.).

Files

• inc/Engine/AI/System/Tasks/DispatchMessageTask.php (new) — extends SystemTask, returns 'dispatch_message' from getTaskId(), implements execute(...) per SystemTask base.
• inc/Engine/AI/System/SystemAgentServiceProvider.php — register the new task class (look for the $tasks['agent_call'] = AgentCallTask::class; line and add the sibling).
• tests/dispatch-message-task-smoke.php (new) — smoke test that:
  • Confirms the task is registered for task id dispatch_message.
  • Confirms it fails cleanly when the ability is missing.
  • Confirms it forwards params correctly when the ability is present (use a test handler registered via wp_agent_dispatch_message_handler filter that returns canonical output).
  • Confirms WP_Error from the ability propagates as a job failure.

Out of scope

• A UI / form-builder integration for configuring the task in the admin. Flow config is set via JSON / WP-CLI for now. UI can come in a follow-up.
• Migrating existing agent_call flows to dispatch_message. That's an operational task per-site, not a code change in this repo.

Acceptance criteria

• task: dispatch_message is a recognized system_task type.
• Pipeline runs with this task type call agents/dispatch-message once per execution.
• Task fails gracefully (clear log message, job marked failed, no fatal) when agents-api or the ability is missing.
• No knowledge of any specific transport in the task code — channel routing is the ability's job, not the task's.
• Smoke test covers all four paths (registered, ability-missing, handler success, handler WP_Error).
• Conventional commit messages. No CHANGELOG edits. No version bumps.

Related

• agents-api: agents/dispatch-message ability + wp_agent_dispatch_message_handler filter (v0.107.0+).
• feat(channels): generic CLI transport runtime for agents/dispatch-message data-machine-code#412 (merged, shipped in DMC v0.44.0): generic CLI transport runtime that registers as a handler.
• feat(bridges): register CLI-channel config for agents/dispatch-message; retire legacy agent-ping webhook wp-coding-agents#129 (merged, shipped in wp-coding-agents v1.0.0): registers the kimaki channel config consumed by the CLI runtime.

This task closes the loop — once it ships, DM flows can dispatch messages through any registered channel without any HTTP webhook, sidecar process, or transport-specific code in DM.