v0.5.4

The reports name what ran, how it was entered and what they are — and the security events carry their evidence.

New: the three axes on every report

The console's 2026-09 release replaced its mixed type field (http, cli, js, 404, security) with three closed vocabularies it groups and filters by: runtime (what ran the code), entry (how it was entered) and kind (what the event is). Every report from this plugin now names them: runtime: php; entry: web, or cli under WP-CLI and cron; kind: error, not_found for the 404 reports, security for the refusals and audit lines.

What you see in the console: command-line errors wear a PHP·CLI badge, a web request and a cron hitting the same bug are one issue instead of two, and the TYPE filter groups by runtime, entry and kind. The old type field is still sent, so a console that has not updated yet keeps working exactly as before; it will be dropped in a later release once the consoles this plugin talks to have moved.

New: evidence on the security events

The console's event rules can ask failures >= N and action = X — and its seeded defaults page on a login that succeeded after three or more failures and on a save through the theme/plugin file editor. The plugin now sends what those rules read:

• auth_success carries failures — the number of recent failures the success followed (the larger of the per-account and per-address counts).
• every privileged_action names its sub-kind as action: admin_created, user_created, role_change, file_edit, app_password, plugin_activated, upgrade_plugin / upgrade_theme / upgrade_core, option_change.

Changed: the log-level gate judges only errors

The client-side log_level setting is a severity filter. The 404 and security reports are kinds, not severities — they ride the INFO band by design — so they now pass the gate regardless of the setting, as the console's own gates already treated them.

The bundled console-client.js is unchanged in this release.