Pre-release Paid design-partner programme

Use case · Change investigation

Replace “the update made it slow” with a controlled comparison.

A slowdown noticed after a plugin, theme, core, configuration, or deployment change is correlated with that change, but correlation is not enough to name the cause. Environment drift and incompatible request samples can easily create a false conclusion.

Design-partner workflow, not a public capability promise

This guide describes the intended public-v1 workflow. During pre-release, captures are founder-guided and every conclusion remains limited by the trace’s reported capabilities, completeness, and supporting evidence.

Where WP Flame fits

Start with the request that still executes WordPress.

The investigation

Investigate a plugin-update regression

A slowdown noticed after a plugin, theme, core, configuration, or deployment change is correlated with that change, but correlation is not enough to name the cause. Environment drift and incompatible request samples can easily create a false conclusion.

Tool boundary

Use the right evidence source

A single before screenshot and a single after screenshot are not a verification workflow. WP Flame’s intended v1 comparison requires compatible route, request type, mode, capability set, score version, and relevant environment context before it labels an improvement verified.

Controlled capture plan

Make the workflow reproducible before reading the graph.

  1. Choose one deterministic workflow affected by the suspected regression.
  2. Capture a compatible baseline cohort before changing the environment when that is still possible.
  3. Record WordPress, PHP, plugin, theme, and relevant configuration versions.
  4. Change one variable and repeat the same bounded capture policy.
  5. Treat small or incompatible cohorts as directional evidence, not proof.

Useful output

Evidence should change the next action.

A graph is supporting detail. The useful outcome is a measured opportunity, the evidence behind it, a safe action, and a way to verify the result.

Environment snapshots

Versioned context that makes hidden plugin, theme, WordPress, PHP, or configuration drift visible.

Comparable distributions

Sample count, p50, and appropriate distribution evidence rather than a single convenient request.

Contributor movement

Which measured source, query, callback, HTTP call, or lifecycle phase changed between compatible cohorts.

Measurement boundaries

What this investigation cannot claim

  • The public comparison workflow is not release-ready until its roadmap acceptance gate passes.
  • A single baseline and after request must not be described as verified improvement.
  • Unobserved work remains unknown, and capability differences can invalidate a comparison.
  • WP Flame does not roll back updates or modify the site automatically.

Developer or client handoff

What to include

  • Exact versions and change timestamp.
  • Compatible baseline and after cohort definitions.
  • Measured contributor changes and confidence.
  • Rollback or remediation result, followed by a repeated verification capture.

Continue the investigation

Current route to release

Bring a real slow WordPress workflow.

The paid design-partner programme pairs controlled captures with founder-led review while the public release gates are completed.

See the programme