Pre-release Paid design-partner programme

Changelog

A release history that distinguishes plans, evidence, and shipped artifacts.

WP Flame has not reached public v1. This log records documented project-level changes and the release discipline intended for future immutable builds. It is not a substitute for versioned plugin release notes.

Apply as a design partner Explore the sample trace
No general-availability release

The current source metadata and historical tag do not yet form a synchronized, immutable public release. Public artifacts must come from a clean tagged commit with complete gates and a published checksum.

Documented project updates

Pre-release record

10 July 2026 · Product and commercial handoff

Public-v1 roadmap and commercial strategy aligned

  • Positioned WP Flame as a WordPress-native performance monitoring and diagnosis product.
  • Established the measurement contract, capability-aware trace direction, and M0–M8 release sequence.
  • Selected paid design partners as the current route to market.
  • Made Community/Pro boundaries and pricing explicit hypotheses rather than public commitments.
  • Required benchmark, compatibility, privacy, limitations, support, refund, and case-study evidence before public v1.

Pre-release baseline · 10 July 2026

Existing architecture documented; release gaps preserved

The roadmap records existing collector, span, trace, instrumentor, storage, scoring, insight, admin, settings, privacy, CLI, and release-build patterns. It also records unresolved integration, audit, compatibility, versioning, and dirty-worktree conditions. Existing code is not treated as validated public capability.

Earlier prototype phase · March 2026

Marketing-site prototype assembled

The initial Astro site established the visual brand, campaign landing pages, sample flame-graph presentation, comparison and pricing prototypes, and placeholder launch infrastructure. The July product strategy supersedes unsupported feature, price, proof, and compatibility claims from that prototype.

Future release-note contract

Every public version should be auditable.

Version identity

Synchronize plugin header, constants, mu-plugin version, schema version, stable tag, changelog, and archive name.

Evidence and limitations

Link benchmark, compatibility, privacy, known-limitations, support, and migration behavior relevant to the release.

Immutable artifact

Build from a clean tag, validate exact package contents, publish a SHA-256 checksum, and retain provenance.

Release entry template

What a real release note must contain

Required release-note fields
FieldPurpose
Version and dateIdentify the immutable artifact and when it became available.
StatusAlpha, design-partner RC, Community, Pro, or another explicit channel.
Added / changed / fixedDescribe observable behavior without translating roadmap work into unsupported claims.
Migration and rollbackExplain schema, upgrade, downgrade-compatible reads, deactivation, and uninstall impact.
Known limitationsState degraded environments, capability gaps, and unresolved accepted risks.
EvidenceLink tests, benchmarks, compatibility rows, security review, checksum, and provenance.
Current product contractBenchmark evidence statusCompatibility evidence statusSupport and disclosure

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