[wp-trac] [WordPress Trac] #65232: Abilities API: Add a fast site health summary to `core/get-environment-info`
WordPress Trac
noreply at wordpress.org
Wed May 13 08:57:27 UTC 2026
#65232: Abilities API: Add a fast site health summary to `core/get-environment-
info`
---------------------------+--------------------
Reporter: gziolo | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1
Component: Abilities API | Version: 6.9
Severity: normal | Keywords:
Focuses: |
---------------------------+--------------------
Extend `core/get-environment-info` with two additive changes:
1. An optional `fields` input parameter that filters the response
(mirroring `core/get-site-info`).
2. A new `site_health` output field returning a high-level, LLM-friendly
Site Health overview — "is everything working, what to improve, what is
broken" — populated entirely from cached data.
== Background ==
`core/get-environment-info` shipped in 6.9 as part of the orientation
layer for AI agents. Adding a cached Site Health summary lets agents
answer "is anything on fire?" in the same call they already make for
runtime context, without paying for a synchronous test run.
Related discussion: [https://github.com/WordPress/ai/issues/40
WordPress/ai#40].
== Proposed shape ==
{{{#!json
{
"environment": "production",
"php_version": "8.2.10",
"db_server_info": "mysql 8.0.35",
"wp_version": "7.1.0",
"site_health": {
"status": "recommended",
"counts": { "good": 12, "recommended": 3, "critical": 0 },
"issues": [
{
"label": "Background updates are not working as expected.",
"severity": "recommended",
"recommendation": "Contact your hosting provider to ensure WP-Cron
can run."
}
],
"truncated": false
}
}
}}}
== Behavioral rules ==
* '''Read cache only.''' Populate `site_health` from WordPress's cached
Site Health results — the same cache the admin dashboard widget reads.
Never trigger a synchronous test run from this ability.
* '''Unknown when uncached.''' If no cached results exist, return
`status: "unknown"` with empty `counts` and `issues`, so the agent can
distinguish "no data" from "clean bill of health".
* '''Only actionable issues listed.''' `counts` covers all severities;
`issues` includes only `recommended` and `critical` entries.
* '''Bounded payload.''' Cap the `issues` list at 10 entries with
`truncated: true` when exceeded.
* '''Included by default.''' Omitting `fields` returns all properties
including `site_health`, matching `core/get-site-info`. Passing `fields:
["php_version"]` filters down to just that property.
Capability check unchanged: the existing `manage_options` gate on `core
/get-environment-info` covers Site Health access.
== Open question ==
`core/get-environment-info` declares `idempotent: true`. The `site_health`
field can vary across calls as the cache refreshes. The annotation remains
accurate in the "no state change" sense but the response is not byte-
stable. Worth documenting in the field description so adapters can
communicate the nuance.
== Acceptance criteria ==
* `core/get-environment-info` accepts an optional `fields` input
parameter that filters the response.
* When `fields` is omitted, the response includes all properties — the
existing 6.9 fields plus `site_health`.
* `site_health` reads cached Site Health results only; no synchronous
test execution under any input.
* JSON Schema documents the new field with `title` and `description` on
each sub-property so adapters can surface them to agents.
* Unit tests cover: `fields` filtering, `site_health` with cached
results, `site_health` with no cache, bounded `issues` list with
`truncated: true`, and confirmation that no synchronous evaluation is
triggered.
* Documentation updated on the Abilities API reference pages (separate
task).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/65232>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list