Eligible workflow
A dynamic request that executes WordPress: wp-admin, checkout, logged-in page, REST, AJAX, cron, CLI, or another agreed route.
Do not install an unreviewed pre-release build on a client production site without written authorization. Design-partner participation, production-site permission, trace review, research use, testimonial use, and case-study use are separate decisions.
Before onboarding
Bring a specific incident.
“The site is slow” is not yet a capture plan. Choose one reproducible request and one person who can act on the result.
Safe environment
Prefer staging or a controlled test account. Use synthetic data for checkout and sensitive user workflows wherever practical.
Action owner
A developer, agency, vendor, or capable operator who can evaluate the evidence and implement or delegate the next action.
Guided capture
The intended design-partner flow
- Define the workflow. Record the URL or operation, user role, inputs, expected result, affected environment, and how the slowdown appears.
- Confirm permission and sensitivity. Obtain production-site authorization and decide which data fields must remain excluded or redacted.
- Run health and capability checks. Confirm storage, early bootstrap, database strategy, retention, and the available capture modes before collecting evidence.
- Choose the least detailed useful mode. Begin with Standard when compatible. Use Safe when database capture is unsuitable and one-shot Deep only when callback detail is needed.
- Bound the capture. Set the route or workflow, requested count, expiry, and phase. Do not enable broad indefinite production capture.
- Reproduce the exact action. Keep account, route, data scale, cache state, and environmental conditions as consistent as practical.
- Read the capture report first. Check mode, capabilities, start stage, dropped spans, truncation, auto-closed spans, and incomplete reasons before interpreting findings.
- Choose one next action. Review the largest supported measured opportunity, its evidence, confidence, owner, and whether specialist help is required.
- Verify cautiously. Repeat compatible samples after one change. A single before and after request is directional, not a verified improvement.
- Stop and clean up. Confirm the capture expired, review retained data, export only a redacted report, and remove data according to the agreed retention plan.
Read before interpreting
Capability status changes what the trace can support.
Captured
The requested instrumentor registered and produced supported evidence. This still does not mean every internal operation was observed.
Not requested
The selected mode intentionally excluded that capability. Safe mode, for example, should not be judged as having zero database activity.
Unavailable
The environment could not provide the requested capture path. Treat the missing area as unknown and disclose the limitation.
Failed
The instrumentor encountered an error. Reduce confidence and investigate the capture failure before making a strong conclusion.
Baseline checklist
Keep comparison cohorts compatible
- Same normalized route and request type.
- Same mode and capability set.
- Same score and trace schema version.
- Relevant WordPress, PHP, plugin, theme, and configuration context recorded.
- Sufficient samples and uncertainty disclosed.
Never include by default
Sensitive trace material
- Authentication secrets, cookies, nonces, or authorization headers.
- Payment information or real checkout/customer data.
- Unredacted full URLs, SQL values, IP addresses, user agents, or identity fields.
- Raw exports in support tickets unless explicitly requested through an approved secure channel.
Stop the capture if the site behaves differently.
Unexpected errors, request interference, storage growth, queue pressure, or material performance change are reasons to stop, preserve evidence, and contact the design-partner support channel. Pre-release investigation never outranks site safety.