Memberistic 2.0.1

[Shubochandrosarker]

What this changes

The compatibility release, and the one that removes the init fatal from the published product.

Delivers P0-1 and P0-2 (up to the human release gate), and closes out M0.

Type

• Release/CI plumbing
• Documentation

Multi-edit checklist

• Version bumped in all its homes — plugin header, MEMBERISTIC_VERSION, readme.txt Stable tag:, plus the CHANGELOG.md entry the release gate greps for
• MEMBERISTIC_DB_VERSION unchanged at 1.11.0 — no schema change, nothing to migrate

Tested up to moved on evidence, not on the fact that it activates

Raised 6.8 → 7.0. Per §13 this only moves after the matrix passes. It has now passed, on main:

Run 31282492624 — 11/11 jobs green. Nine matrix jobs (WP 6.8 / 6.9 / 7.0.3 × PHP 8.2 / 8.3 / 8.4), the resolver, and a non-blocking trunk canary.

Verified from the job log rather than the summary badge, because a suite that finds no tests also exits 0:

Requested WordPress '7.0.3' → installing '7.0.3'
Using test library from wordpress-develop refs/tags/7.0.3
WordPress 7.0.3 installed at /tmp/wordpress/
  WP_RESOLVED_VERSION: 7.0.3
PHPUnit 9.6.35 by Sebastian Bergmann and contributors.

Activation
 ✔ Plugin bootstrapped
 ✔ Requirements gate did not bail
 ✔ Every table is created
 ✔ Db version option is recorded
 ✔ Administrator has every capability
 ✔ Plugin roles exist
 ✔ Operational roles do not receive pii capability
 ✔ Scheduled tasks are registered

Fresh Install
 ✔ Activation makes no outbound http request
 ✔ Fresh install seeds no plans
 ✔ Default plans filter defaults to empty
 ✔ Third party integrations default to disabled
 ✔ No integration is enabled that would call out
 ✔ Data retention on uninstall is the default

Load Deprecations
 ✔ Plugin load and activation are deprecation free
 ✔ Running wordpress matches the requested version

OK (16 tests, 77 assertions)

Real MySQL 8.0.46 service container; the PHPUnit 10.5 → 9.6.35 downgrade visibly resolved 21 packages. Not a hollow green.

readme.txt reads 7.0 because wordpress.org accepts only major.minor there, while the matrix names 7.0.3.

The trunk canary is green and that is not a support claim. It stays continue-on-error.

Invariants now covered by executing tests

Three of the eight stopped being prose in this release:

Invariant	Test
I5 — network-silent activation	Activation makes no outbound http request
I2 — safe fresh installs	Fresh install seeds no plans, Third party integrations default to disabled, No integration is enabled that would call out
—	Plugin load and activation are deprecation free, on every version in the matrix

What I ran

$ # the release workflow's version gate, replicated locally
  ok: plugin header Version: = 2.0.1
  ok: MEMBERISTIC_VERSION    = 2.0.1
  ok: readme.txt Stable tag: = 2.0.1
  ok: CHANGELOG.md mentions 2.0.1
  version gate exit=0

$ vendor/bin/phpunit -c phpunit.xml
  OK (51 tests, 847 assertions)

Plus, on main, the integration matrix quoted above.

⚠️ The handoff — this is where I stop

release.yml is tag-triggered, and tag pushes are blocked by the proxy in agent sessions (HTTP 403). Cutting the tag is a deliberate human step, and so is publishing, since the workflow drafts the Release rather than publishing it.

After merging this PR:

git checkout main && git pull
git tag -a v2.0.1 -m "Memberistic 2.0.1"
git push origin v2.0.1

That runs release.yml, which verifies the version against the tag, lints, builds from .distignore, asserts no dev or internal files leaked, computes SHA-256, and opens a draft Release with the zip and checksum attached.

Before publishing that draft, two P0-2 boxes remain and neither can be done from here:

• Zip smoke-installed on a clean WordPress
• Upgrade from 2.0.0 tested on a site with real data

Both are in docs/governance/RELEASE-PROCESS.md. I have deliberately left them unticked.

What I did NOT test

• The release workflow end to end. Still never executed — no tag has been pushed. Its version gate is replicated above, and its build/leak steps are the scripts CI runs on every PR, but the artifact upload and draft-Release steps are unexercised.
• Multisite. The matrix runs single-site only (Running as single site... in the log). Multisite activation, uninstall and privacy remain untested — that is still on P0-0's list.
• Everything behind P0-5 through P0-10 — REST authorization/IDOR, webhooks, rate limits, uploads, E2E. Untouched.
• Upgrade from 2.0.0 with real data. Not possible here; it is a release-gate item above.

Risk and rollback

• Blast radius: version strings, Tested up to, and documentation. No executable code changes in this PR — the fatal fix and the harness already landed in Fix the init-time fatal: require Booking_Adapter, and guard the whole manifest #4 and Add the WordPress integration harness and the compatibility matrix #5. The user-visible effect is that wordpress.org would list the plugin as tested to 7.0.
• Rollback: revert the commit; version returns to 2.0.0. If the tag was already pushed, delete it before re-cutting — a published Release should be superseded by 2.0.2 rather than retagged.
• Data migration to reverse? No. MEMBERISTIC_DB_VERSION is untouched.

---

Generated by Claude Code