Captured
The requested capability registered and produced supported evidence.
Current status: no public compatibility matrix has passed the release gate
Named hosts, plugins, PHP versions, and database stacks must not be marketed as supported until their expected, degraded, and unavailable capabilities have current test evidence.
Compatibility model
A site can work while some evidence remains unavailable.
Every eligible trace should record a status for early lifecycle, database, callbacks, HTTP, GraphQL, cache counters, and other requested capabilities.
Not requested
The selected mode deliberately excluded the capability; absence is expected.
Unavailable
The environment could not support the requested strategy. The product should remain safe and explain the limitation.
Failed
An instrumentor error reduced trace completeness. The failure must be visible and must not silently improve a conclusion.
Planned public-v1 matrix
Evidence still required
| Environment | What must be verified | Current public status |
|---|---|---|
| WordPress lower bound and current release | Install, capture, schema, UI, privacy, deactivate, and uninstall behavior. | Awaiting published matrix |
| PHP versions | Decide whether 7.4 remains supported; test 8.1, 8.3, 8.4, and 8.5 release paths. | Awaiting product decision and matrix |
| MySQL and MariaDB | Schema, migrations, query capture, storage, retention, and failure behavior. | Awaiting published matrix |
| Managed host without early mu-plugin | Safe degraded lifecycle, visible start gap, and no false full-request claim. | Expected degraded path; evidence pending |
| Custom database layer | Leave unsupported layers untouched; show database capability unavailable. | Strategy defined; evidence pending |
| Persistent object-cache drop-ins | Ownership, cache evidence, uncertainty, and safe operation. | Awaiting published matrix |
| Multisite | Bounded activation, upgrade, storage, prune, deactivate, and uninstall. | Awaiting published matrix |
| WooCommerce | Frontend, checkout, admin, AJAX, cron, and Action Scheduler fixtures. | Priority design-partner target; compatibility not yet claimed |
| Elementor and other builders | Known ownership fixtures, lifecycle behavior, and overhead evidence. | Representative benchmark planned; named support not yet claimed |
| WPGraphQL | Current end-to-end operation and resolver fixtures. | Do not advertise until gate passes |
Known product boundaries
Expected limitations
- Requests served entirely by a page cache or CDN do not execute PHP and cannot be traced.
- Observed duration begins at the earliest WP Flame bootstrap point available.
- Standard database capture depends on a compatible strategy.
- Deep mode observes supported WordPress callbacks, not arbitrary PHP functions.
- WordPress HTTP instrumentation does not represent every possible network call.
- Browser rendering, network quality, Core Web Vitals, and infrastructure metrics are outside scope.
Safe degradation contract
What should happen
- Unsupported database layers remain untouched.
- Unavailable telemetry is labelled unknown.
- Early-loading gaps are disclosed on the trace.
- Instrumentor failures reduce confidence and become visible health issues.
- Dropped, trimmed, or auto-closed spans are counted and disclosed.
- WP Flame failure should not take down the monitored application response.
Design-partner compatibility report
What to send when an environment degrades
- WordPress, PHP, database, host type, multisite, object-cache, and relevant plugin/theme versions.
- The capture mode and complete capability report.
- Health warnings, incomplete reasons, and exact reproduction steps.
- A redacted diagnostic bundle; never include credentials or unreviewed raw trace data.
- Whether disabling WP Flame immediately restores the original behavior.