# International Press Zone compatibility matrix

Status: **release-candidate preparation; PG-38..PG-42 are not signed off here**.

Preparation baseline: `origin/master` at `feffca5bd8c00949b264a60adffaa0ab5afe8218` on 2026-08-19. Final acceptance must be rerun from the exact release candidate after all product lanes land.

This document deliberately separates four different claims that must not be collapsed into one another.

## 1. Minimum accepted runtime

These are runtime admission/support boundaries, not proof that every combination has been exercised.

| Component | Minimum / policy | Basis | Status |
|---|---|---|---|
| WordPress | 6.0 | plugin header + readme `Requires at least` | declared, final floor smoke required |
| PHP | 8.0 | plugin header/readme | declared, final floor smoke required |
| Database | WordPress-compatible SQL runtime; first-release qualification targets MySQL 8.0+ and MariaDB 10.6+ only | deliberately narrow launch policy; plugin has no independent DB-version header | provisional until final matrix rerun |
| Browser | Chromium and Firefox engines exercised by the pinned RC Playwright toolchain | sanctioned E2E contract requires both | exact engine revisions recorded at RC |

Do not interpret this as broad support for every WordPress/PHP/database permutation above the floor. Only rows explicitly accepted in the final RC receipt become first-release compatibility evidence.

## 2. Actually tested runtime

The sanctioned remote snapshot contract currently fixes this baseline:

| Identity | Exact preparation fixture |
|---|---|
| WordPress | `wordpress:6.6-php8.2-apache` |
| PHP | 8.2 image line |
| Database | `mariadb:11` |
| ACF | 6.3.5 |
| Fixture schema | `acf-fields-v1` |
| Snapshot fingerprint | `4367747ddb71d2d6d883129f8496782e5b34c4fe6876e6e9f9de0c606ac560d2` |
| E2E hosts | sanctioned `debian1`, `debian2`, `debian3` fleet via `e2e-remote` |

The snapshot identity is evidence of the fixture configuration, not by itself a PG-38/39/40 pass. Partial preparation evidence is recorded in `docs/launch/compatibility/PREPARATION-RECEIPT.md`; no integration row becomes a compatibility pass claim until the dedicated smoke succeeds in both Chromium and Firefox on the final RC.

The repository readme says `Tested up to: 6.6`, matching the WordPress version in the sanctioned preparation fixture. This is a preparation receipt only: the final RC agent must exercise WordPress 6.6 on the exact RC before release, or remove/correct the advertised ceiling.

## 3. Final RC qualification rows

These are required rerun rows, not current pass claims:

| Row | WordPress | PHP | Database | Purpose |
|---|---:|---:|---|---|
| RC-FLOOR-MARIA | 6.0 | 8.0 | MariaDB 10.6+ pinned exact patch | declared runtime floor on MariaDB |
| RC-FLOOR-MYSQL | 6.0 | 8.0 | MySQL 8.0+ pinned exact patch | declared runtime floor on MySQL |
| RC-SANCTIONED | 6.6 | 8.2 | MariaDB 11 pinned exact image | continuity with current sanctioned browser fixture |
| RC-ADVERTISED-WP | 6.6 | 8.2 | MariaDB 11 pinned exact image | justify or correct current `Tested up to: 6.6` metadata |
| RC-CUSTOMER | exact inventory | exact inventory | exact inventory | first-customer supported stack; mandatory once inventory is available |

If the release owner intentionally changes any boundary, change this table and the product metadata together and rerun the affected rows. Do not silently substitute a newer runtime and call the floor tested.

### Integration dimensions

Each applicable RC runtime row must keep International Press Zone active while checking:

- ACF absent;
- ACF present at the pinned supported version;
- Yoast absent;
- Yoast present at the pinned supported version;
- ACF + Yoast together when both are in the first-customer inventory.

PG-39/PG-40 final sign-off remains blocked on the owning ACF/Yoast reconciliation lane plus the exact final-RC rerun. This preparation lane may only publish provisional receipts or defect handoffs.

## 4. First-customer supported stack

**Inventory state: unresolved.** No authorized record in the project/repository identifies the waiting customer's exact WordPress, PHP, database, theme, active-plugin, MU-plugin, permalink, front-page, template, or block stack. Existing safety policy forbids using deployment/client WordPress as a diagnostic target, so no values are inferred from `dev1`, DNS, historical deployment notes, or unrelated fixtures.

Use `tests/compatibility/customer-stack/inventory.php` on an already-authorized staging clone with representative Page/Post IDs, then lock the exact result into `tests/compatibility/customer-stack/customer-stack.json`. Until that happens, PG-41 and PG-42 stay explicitly open.

For the first customer, supported means the exact locked inventory, not the ecosystem generally. The customer fixture must cover front page, representative Page, representative Post, menu/navigation, actual blocks/templates, permalink behavior, actual cache layer if present, and RTL only when the customer content requires it.

## 5. Broad ecosystem compatibility — out of scope

This launch task does **not** claim arbitrary theme compatibility, arbitrary block-library compatibility, every WordPress/PHP/database combination, multisite, every cache/CDN plugin, every SEO plugin, every ACF add-on, WebKit/Safari, or third-party multilingual-plugin coexistence. Those are separate post-launch qualification programs unless the first-customer inventory makes one of them mandatory.

## Provisional receipt location

Preparation receipts and any defect handoffs belong in `docs/launch/compatibility/`. Final PG-38..PG-42 acceptance belongs to the final RC certification lane and must cite the exact RC commit/ZIP plus final matrix/customer-stack receipts.