Find Out Why a Webhook Failed with Webhook Actions and AI

My WordPress site uses Webhook Actions. [The webhook, for example the order sync to my CRM] isn't arriving. Find out why. Don't change anything without asking me.

1. Run discover_abilities with category webhook-actions. If no flowsystems-webhook-actions abilities are listed, stop and tell me to install or update the free Webhook Actions plugin (3.3.4 or newer; its abilities need WordPress 6.9 or newer). If probe-endpoint, update-webhook or test-dispatch is missing, AI write access is off: diagnose from the log only and say so.
2. Run flowsystems-webhook-actions/list-webhooks and find it. If several match, ask which one. If is_enabled is false, tell me it is switched off (new webhooks start off), so nothing is sent, and carry on with the read-only checks in steps 3 to 6 so we know it will work once it is on. At step 7, ask whether to turn it on; only on my yes run flowsystems-webhook-actions/enable-webhook with the id, enabled true and confirmed true.
3. Run flowsystems-webhook-actions/get-webhook with the id and tell me its triggers, endpoint, method, whether a credential is attached, and for each trigger its mapping and conditions.
4. Run flowsystems-webhook-actions/get-logs with the webhook_id and limit 20. Explain the latest entries: status success (delivered), pending (queued, not sent yet), retry (failed, tries again at next_attempt_at), permanently_failed (gave up: out of retries, or at once for a 4xx answer other than 429, a 3xx, or a setup error such as an invalid URL), error (an attempt just failed and is being processed), skipped (its conditions filtered the event out) or test (a test delivery); and for failures the http_code, error_message, response_body and attempt_history. An error_message of Invalid URL format means Webhook Actions refused the address itself: it delivers only to https URLs on public hosts with no port other than 443 or 8080, so a plain http URL fails this way even when the endpoint works.
5. If there are no entries since it was turned on, the trigger has not fired: tell me in plain words which event fires it. If entries are skipped, compare the trigger's conditions with the payload in original_payload, or request_payload when original_payload is empty, and tell me which rule filtered them out. If entries have been pending for more than a few minutes, tell me background deliveries wait for WP-Cron or Action Scheduler, which run on site visits unless a server cron job runs them.
6. If the webhook's method is GET, HEAD or POST, tell me a probe sends one empty request to the endpoint now (an empty JSON body for POST), which a live workflow may run on, and wait for my yes. Then run flowsystems-webhook-actions/probe-endpoint with the webhook_id and that method and tell me what the endpoint answers. The probe sends only the webhook's URL and vault credential, not its custom headers, legacy auth header or URL parameters, and it does not fill in double-brace placeholders in the URL, so if the webhook relies on any of those, judge by the http_code in the delivery log instead. Some endpoints answer 400 or 422 to an empty body even when they work. If the probe is refused as not allowed, that is Webhook Actions refusing a private address or a port other than 80, 443 or 8080, not the endpoint answering. A probe can succeed on a plain http URL that deliveries refuse. Otherwise skip the probe and say why. As a guide: 401 or 403 means a missing or wrong credential, 404 or 410 a wrong or removed URL, 429 rate limiting, 5xx a problem on the service's side or a body it rejected, and a transport error a DNS, SSL or network failure, or a timeout: Webhook Actions waits only 5 seconds for an answer, so a slow workflow can receive and run a delivery that is still logged as failed and retried.
7. Tell me the cause in one or two sentences and the fix. If the fix is a new URL, method or headers, ask me, and only on my yes run flowsystems-webhook-actions/update-webhook. If it needs a credential, tell me to add it in Webhook Actions, Credentials Vault, because credentials hold secrets.
8. After a fix, offer to probe again the same way. To resend a permanently_failed delivery, do not retry it from the delivery log: that reuses the settings stored with the failed job, and retries already queued use the old settings too. If the failures were timeouts, ask me to check my service's own history first, because it may already have run them. Instead tell me what the entry contains and wait for my yes, then run flowsystems-webhook-actions/test-dispatch with the webhook_id, the trigger, confirmed true and payload set to that entry's request_payload exactly. If request_payload contains [redacted] values, tell me those fields would arrive as the word [redacted] and ask before sending. If flowsystems-webhook-actions/list-snippets lists any snippets, tell me that a snippet attached to this webhook runs again: a pre-dispatch one on the resent payload, an after-response one once the resend succeeds (the abilities do not show which webhook a snippet is attached to). If any webhook in list-webhooks has a trigger starting with fswa_chain_link, run rest_api GET /fswa/v1/chains, and if a link's source_webhook_id is this webhook, tell me a successful resend also fires its target webhook (target_webhook_id). Show me each response code.