# First-customer compatibility fixture

This directory is preparation for PG-41/PG-42. It is not final release certification.

`customer-stack.json` deliberately contains unresolved values because no authorized first-customer stack inventory was found during preparation. Do not infer values from dev/test sites, DNS, deployment targets, screenshots, or historical documentation.

## Authorized inventory

Run only on an already-authorized staging clone or other site inventory target. This is read-only. Supply one representative published Page ID and one representative published Post ID from the customer site:

```bash
wp --path=/absolute/path/to/customer-staging eval-file \
  tests/compatibility/customer-stack/inventory.php \
  <representative-page-id> <representative-post-id> \
  > customer-stack.inventory.json
```

If the inventory helper is not present on that host, copy only `inventory.php` there or pipe its exact contents through the site's sanctioned administration channel; do not install or activate anything on a live customer site merely to collect inventory.

Accept the inventory only when `missing_inputs` is empty. Review it for WordPress, PHP, database server/version, multisite mode, permalink structure, front-page configuration, exact active theme/version, active and must-use plugins, registered block types, and block/template usage on the front page plus the representative page/post.

## Required owner input

PG-42 cannot be certified while the customer stack is unknown. Ask the customer/onboarding owner exactly: **“Which production-representative staging clone is authorized for non-destructive qualification, and what are the representative published front-page, Page, and Post IDs for the first customer’s site?”** The answer must identify a clone rather than a live customer site. Use that clone to collect the runtime/theme/plugin inventory above; do not guess values from another environment.

## Lock the fixture

After inventory review, replace the unresolved fields in `customer-stack.json` with the exact inventory values and set:

```json
{"state":"inventory-locked","source":"authorized-staging-inventory"}
```

Do not broaden, normalize, or silently upgrade versions. The final RC lane must build an isolated disposable WordPress fixture matching that lock as closely as sanctioned infrastructure permits. If an exact theme/plugin artifact is unavailable, record that as a PG-42 blocker rather than substituting another version.

## Customer-stack smoke contract

The disposable exact-stack fixture must prove, without real translation billing or customer writes:

1. International Press Zone activates with no PHP warning/fatal.
2. wp-admin plugin dashboard and International Press Zone dashboard load with no JS console/page errors.
3. Front page renders and retains its configured front-page mode and permalink behavior.
4. The representative Page and Post render their existing theme/template/block composition.
5. Menu/navigation and registered customer blocks needed by those three surfaces render without fatal/missing-block degradation.
6. ACF absent/present and Yoast absent/present behavior follows the locked customer inventory and the PG-39/PG-40 compatibility contract.
7. Cache behavior is checked using the customer's actual active cache layer if one is present in inventory; no cache plugin is invented when absent.
8. RTL is exercised only when the customer's actual active language/content requires RTL.

The final receipt must record the locked inventory hash, exact candidate commit/ZIP hash, exact runtime/theme/plugin versions, browser engines, discovered/executed/skipped counts, warnings/errors, and cleanup result.