Docs: DevTools, Performance, and Accessibility status

[AnuragVasanwala]

Quick summary

Area	v1.0.0	After v1.0.0
DevTools	None	Dev Monitor (extending QM 4), AI tool integration (PR #45)
Performance	XHProf (PR #42 merged)	CWV, Lighthouse-CI, regression tracker, migration perf diff
Accessibility	pa11y in CI and CD	axe-core overlay, pa11y in Dev Monitor

---

DevTools

What we have integrated

We have not merged anything for the core Dev Monitor stack yet. The first piece we are actively building is the AI tool integration, covered in What we are planning below.

What we are planning

We scoped the Dev Monitor across 5 issues in rtCamp/wp-framework:

Issue	What we planned
#17	7 collector interfaces (Collector, Profilable, Stoppable, Renderable, Issue_Provider, AI_Context_Provider, Timeline_Event_Provider)
#18	AI_Data_Sanitizer helper
#19	Dev_Loader (DEV_MODE-gated boot)
#20	14 collector implementations (parent epic)
#21	Workflow Panel, Visual Timeline, Console_Log_Collector

AI tool integration with DevTools

Aditya created a draft PR (wp-framework #45) showing tight integration between Claude Code, the project codebase, and live site analysis. We add a Telemetry module that exposes 4 abilities through the WordPress Abilities API and the MCP Adapter:

1. list-requests: recent captures with metrics
2. get-telemetry: full normalised data for one request (queries, HTTP, errors, assets, timings)
3. compare-requests: before / after diff
4. profile-url: capture a fresh sample by hitting a URL

When Claude Code connects to a project, it can read both the codebase (its built-in capability) and the live site telemetry (through these abilities). We expect this to give much better insights on issues and a path to auto-fixing them. Aditya is still building and testing this one.

Why delayed

I discussed this with Lovekesh and we found that what we had planned in our 5 Dev Monitor issues largely overlaps with what Query Monitor 4 already provides out of the box. From issue #40:

Our planned collector	Already in QM 4
Database queries	Full, with duplicate and slow flagging
Hooks and actions	Full
HTTP API calls	Full, with timings, errors, backtraces
Object cache stats	Full
Transients	Mostly covered
Asset (scripts + styles)	Full, with dependencies
Blocks	Full
REST API requests	Partial
Capabilities	Full (off by default)
Conditionals	Full
Rewrite rules	Full
Translation files	Full
Visual Timeline	Full, new in QM 4

About 11 of our 14 planned collectors and the Visual Timeline we had planned in issue #21 are already available in QM 4. Building them again would duplicate established work.

What we decided after that discussion:

• We added issue #40 to the project board as a Blocker
• We moved all 5 Dev Monitor issues (Add Dev Monitor — 7 collector interfaces #17 to Add Dev Monitor — Workflow Panel, Visual Timeline, Console_Log_Collector #21) behind it
• We agreed to extend Query Monitor 4 with our own additions (cross-request history, AI access through MCP, browser console capture, regression tracking, the parts QM does NOT cover) instead of duplicating what QM already does well

Release plan:

This work is NOT in v1.0.0. We will ship it as a separate release after v1.0.0 lands.

---

Performance

What we have integrated

• XHProf profiler: standalone PHP profiler (wp-framework PR #42, we merged today). Works with both classic xhprof and the modern tideways_xhprof extension. Silently skips when neither extension is loaded, so it is safe in CI and production.

What we are planning

We have not started any of these yet:

• Core Web Vitals (CWV): capture using the web-vitals JS library.
• Lighthouse-CI: a reusable workflow in wp-shared-workflows that runs Lighthouse on every PR.

Why delayed

For v1.0.0 we are focused on the framework foundation: Cache (with stampede prevention via stale-while-revalidate), AbstractPostType, AbstractTaxonomy, AbstractRESTController, AbstractCronJob, CLICommand interface, and the scaffold engine. We want that foundation in place before we layer performance instrumentation on top.

We are deferring CWV, Lighthouse-CI, regression tracker, and migration perf comparison to v1.1 or later.

XHProf is the exception. It is small, standalone, with no dependency on any other framework piece, which is why we are landing it in v1.0.0.

---

Accessibility

What we have integrated

We have all three pieces merged to release/v1.0.0:

1. pa11y setup scaffold in wp-tooling at scaffolds/setup/pa11y/: writes .pa11yci.json with WCAG2AA rules, adds pa11y-ci dev dep, adds test:a11y npm script.
2. pa11y CI scaffold in wp-tooling at scaffolds/ci/test-a11y/: writes the GitHub Actions caller file for any consuming project.
3. ci-test-a11y.yml reusable workflow in wp-shared-workflows: runs pa11y-ci against a wp-env environment with configurable inputs.

A plugin or theme team can install our two scaffolds and they get end-to-end pa11y coverage in CI and CD automatically.

What we are planning

We want to integrate pa11y with DevTools so developers see accessibility issues directly in the local dev panel, not only in CI. We are considering two paths:

Approach	What we get	What it depends on
axe-core live overlay	A lightweight JS overlay (about 50KB) that runs against the rendered page on every navigation while DEV_MODE is on. Surfaces issues inline in the admin bar. Instant feedback during development.	Nothing. We can land this independently.
pa11y as a Dev Monitor collector	Implements Issue_Provider so accessibility issues show up in the Dev Monitor's Issues Stream next to slow queries, PHP errors, and the rest.	Needs the Dev Monitor stack (issues #17 to #21) to land first.

Path 1 (axe-core overlay) is independent and we could land it sooner. Path 2 is tied to the Dev Monitor decision.

Neither path is in v1.0.0. Our CI coverage works today. In-panel feedback is a v1.1+ addition for us.