# GOLIVE — international-press-zone

**Scope:** WordPress plugin only. Backend implementation/deployment is tracked separately in the canonical `press-zone-core` project.

**Canonical baseline audited:** `origin/master` @ `feffca5bd8c00949b264a60adffaa0ab5afe8218`
**Plugin version audited:** `0.9.67`
**Audit date:** 2026-08-19
**Commercial target:** first paying customer / production sale

This file is the authoritative plugin go-live tracker. It supersedes `docs/launch/LAUNCH-CHECKLIST.md` for the question **“can we safely sell, onboard, translate, bill, update, and support a real customer now?”** The legacy launch checklist may still be used later for broad marketing or WordPress.org work, but it contains stale PayPal/license-key assumptions and generic launch tasks that are not release gates here.

## Status rules

- `[WORKS]` — current implementation or a current audit check provides concrete evidence.
- `[BROKEN]` — known incorrect behavior/state that must be fixed.
- `[MISSING]` — required behavior or release control is not yet on current master.
- `[UNVERIFIED]` — implementation exists, but the current release candidate has not passed the required real/runtime proof.
- `[WAITING_EXTERNAL]` — engineering work here is not the blocker; completion depends on an external approval/service becoming available.
- `[DEFERRED]` — explicitly outside the first-customer product promise; it must not be marketed or exposed as production-ready.

A checkbox is checked only after the criterion is verified against the **current release candidate**. Old branch receipts, stale plan status, code presence, mocks, or a historical deployment are not enough for final sign-off.

---

## P0 — first paying customer critical path

- [ ] PG-01 [WORKS] — The plugin uses the current Connect architecture rather than customer-visible license keys: PKCE connect flow, backend-minted per-site `site_id`/API key, and AES-256-GCM credential storage are present on current master. Final verify: connect a fresh site and confirm no credential is rendered, logged, or exposed to browser JavaScript.
- [ ] PG-02 [UNVERIFIED] — A fresh WordPress installation can complete real social sign-in through the production/staging Connect service and receive/store a usable site credential. verify: browser E2E from `#/onboarding` through provider authorization and `/oauth/token`, then `/connect/status` reports connected.
- [ ] PG-03 [WAITING_EXTERNAL] — Stripe production clearance is pending outside this repository. The checkout lane is WIP and expected to become testable in roughly 2–3 weeks; do not substitute PayPal or another payment path. Once clearance is available, verify one end-to-end purchase, webhook entitlement activation, and automatic transition to active subscription in the plugin.
- [ ] PG-04 [WORKS] — The real translation path is an existing, previously exercised capability and is regression-protected on current master (`real-translate.spec.js`, `SyncTranslationContractStandaloneTest.php`, payload/finalizer regressions). Treat any failure as a regression, not missing implementation. The concurrent production-completion lane owns the final release-candidate rerun against the current Worker.
- [ ] PG-05 [WORKS] — Async/bulk translation submit → poll → terminal result → WordPress finalization is an existing tested lifecycle with dedicated completion/finalizer/bulk regression coverage. Treat breakage as a regression. The concurrent production-completion lane owns the final current-Worker release rerun and receipt.
- [ ] PG-06 [UNVERIFIED] — Customer cancellation works end-to-end for a live async job and cannot cancel another site/account's job. verify: submit, cancel, poll terminal `cancelled`, then attempt out-of-scope cancellation and require fail-closed behavior.
- [ ] PG-07 [WAITING_EXTERNAL] — Post-purchase Stripe billing/portal proof cannot complete until Stripe clearance is available. The account/connect UI exists; once clearance lands, verify real plan/renewal/wallet state, Customer Portal, disconnect semantics, reconnect, and status convergence.
- [ ] PG-08 [UNVERIFIED] — Revoked/invalid credential behavior is safe and understandable. verify: backend revokes a site key; plugin receives 401, purges unusable connection state where appropriate, blocks translation, and presents a reconnect path without exposing the key.
- [ ] PG-09 [UNVERIFIED] — Entitlement/payment failure behavior is safe and understandable. verify: 402/inactive-subscription response blocks paid operations without content mutation and presents an actionable billing/plan state.
- [ ] PG-10 [UNVERIFIED] — Rate limiting does not lose work. verify: induce 429 on synchronous and bulk/job paths; Retry-After/backoff behavior completes or fails visibly and retryably, with no duplicate charge/job/content mutation.

**P0 exit:** PG-01..PG-10 checked. No sale should be accepted before this path is proven on the release candidate and its matching backend deployment.

---

## P0 — content integrity / no customer-data surprises

- [x] PG-11 [WORKS] — Current-master Page creation/finalization now preserves the explicit structural fidelity allowlist: translated parent, `menu_order`, `comment_status`, `ping_status`, valid `_wp_page_template`, and valid `_thumbnail_id`, while ordinary non-Page translation remains unchanged. Focused regressions pass and the implementation is canonical in `01940a992`.
- [x] PG-12 [WORKS] — Page-parent fidelity regressions cover valid linked translated parents (including draft Pages), while source-language, missing, unmapped, non-Page, trashed, self, and cyclic candidates fail safe to parent `0`. Current architecture has no Page-specific review-reason contract, so none is invented.
- [x] PG-13 [WORKS] — Page refresh/regeneration preserves hierarchy/order/discussion fidelity, clears stale template/thumbnail state when the source no longer owns it, preserves unrelated target metadata, and uses snapshot-backed rollback so creation/refresh and later finalizer failures do not leave partial Page-fidelity mutations.
- [x] PG-14 [WORKS] — Manual-translation overwrite protection landed with this convergence commit: provenance/lock-override protection policy and service, Migration010 (columns/backfill/enums/duplicate recovery before unique index, idempotent, column-verified fail-closed before backfill — proven live 2026-08-21), auto-translation coordinator with mark_stale default. Evidence on this candidate: full factory gate green (unit 128/898, mixed runner 74 files, live-WP integration incl. Migration010 and a server-side `pre_http_request` zero-spend proof that mark_stale marks stale without any outbound HTTP); browser acceptance `pg14-manual-protection.spec.js` 14/14 Chromium+Firefox (settings + accessible tooltips, zero-trigger rejection, content/string modal protection persisting with unsaved input preserved, Protected status with disabled generation and zero translate calls, narrow/dark layout); two independent adversarial reviews (WPCS remediation diff and post-review deltas) passed with the sole blocker resolved by the zero-spend integration proof.
- [ ] PG-15 [UNVERIFIED] — ACF translation behavior is customer-safe on current master: mirrored/original fields, field policy, translated values, rollback, regeneration, and integration-absent behavior are all exercised against a real ACF installation.
- [ ] PG-16 [UNVERIFIED] — Yoast SEO translation behavior is customer-safe: SEO token partitioning is correct at every call site, SEO finalizer rollback is symmetric with ACF rollback, metadata survives/reverts correctly, and no Yoast UI/data path appears when Yoast is absent.
- [ ] PG-17 [UNVERIFIED] — Frontend multilingual routing is complete for the supported first-customer scope: language-root switching, canonical localized URLs, hreflang/locale behavior, and translated front-page/page routing work without false links or wrong-language content.
- [ ] PG-18 [UNVERIFIED] — Yoast robots/sitemap ownership for multilingual routes is verified for the supported release scope; no duplicate, missing, or cross-language sitemap/robots output is introduced.

**Content-integrity exit:** no known path can overwrite manual customer work, attach a page to the wrong parent, or publish the wrong language/SEO metadata.

---

## P1 — define the product we are actually selling

- [ ] PG-19 [WORKS] — Customer-facing `readme.txt`/`README.md` now use International Press Zone, match the enforced WordPress/PHP requirements, remove hard-coded pricing/trial/SLA/performance claims, document commercial ZIP installation, and defer mutable commercial terms to Press.Zone.
- [ ] PG-20 [WORKS] — `docs/launch/FIRST-CUSTOMER-SCOPE.md` freezes the first-sale support contract as SUPPORTED, CONDITIONAL, DEFERRED, or WAITING_EXTERNAL so historical code/plans cannot silently expand the commercial promise.
- [ ] PG-21 [BROKEN] — Static/customer documentation is reconciled to `docs/launch/FIRST-CUSTOMER-SCOPE.md` and the tracked fabricated marketing claims are removed, but customer-facing runtime still exposes deferred WPML migration, Team/Workflow/My Assignments, and Auto-translate on Publish. Exact no-race handoffs are recorded as H-PG21-01..03 in `docs/launch/LAUNCH-GOVERNANCE-AUDIT.md`; the owning site-entry/settings lanes must hide/gate or deliberately promote them with evidence before this criterion can be checked.
- [ ] PG-22 [WORKS] — `docs/plans/INDEX.md` and current production-completion guidance now mark the retired onboarding/licensing designs superseded and identify Connect/social auth + Stripe + backend-issued site credentials as the current architecture.
- [ ] PG-23 [BROKEN] — Core package identity is coherent (International Press Zone, `international-press-zone`, version `0.9.67`, archive convention `international-press-zone-<version>.zip`), but the visible admin eyebrow still says `Press Zone`, the top-level WordPress menu says `International`, and the canonical product/license URLs currently return 404 after redirect. Production catalog labels/support route are not verifiable from the current public backend and are not invented. H-PG23-01..05 in `docs/launch/LAUNCH-GOVERNANCE-AUDIT.md` are the exact owner handoffs.
- [ ] PG-24 [UNVERIFIED] — The `legal/` files are now architecture-aligned internal drafts: stale product/payment/license/pricing/SLA claims are removed and current Connect/translation/Stripe-wait data flows are documented at a high level. Final business/legal/privacy approval against the live product and production data flow is still required before customer publication.

---

## P1 — test and release gates

- [ ] PG-25 [WORKS] — Remote E2E safety infrastructure is healthy. Audit 2026-08-19: `tests/e2e/remote-stack.sh --self-test` passed; 17/17 base-url, authorization-readiness, login-readiness, and target-safety Node contracts passed.
- [ ] PG-26 [UNVERIFIED] — The full current-master factory gate passes on a sanctioned environment with locked dependencies installed: PHP syntax, PHPUnit/standalone/integration runner, PHPCS baseline gate, PHPStan, admin lint, production build, UI inventory and UI gate. Audit note: current PHP syntax phase ran clean, but the full fresh audit could not complete because remote dispatch reported `remote-command-missing` and local fallback lacked `phpunit`; this is not a product pass.
- [x] PG-27 [WORKS] — `tests/known-failing.txt` has zero active entries. `BlockSegmentCodecTest.php` passes 23/23 tests (66 assertions) in the standalone `--no-configuration` runner, while AutoPublish, settings idempotency, and ContentManager are routed through the sanctioned live-WordPress integration gate; the final Debian2 run passed AutoPublish 4/4 and ContentManager 10/10 tests (95 assertions).
- [ ] PG-28 [UNVERIFIED] — All first-customer browser journeys pass on the final release candidate in at least Chromium and Firefox using the sanctioned remote browser flow. Required set includes onboarding/account, languages, post/page translation, string translation, bulk job, cancel, settings/exceptions, frontend language switch, and update flow.
- [ ] PG-29 [UNVERIFIED] — No PHP fatal/warning or JavaScript console error occurs through the supported customer journey with `WP_DEBUG`/logging enabled on a production-like fixture.
- [ ] PG-30 [UNVERIFIED] — Security review is current for the sellable surface: REST capability/nonce checks, PKCE state, credential secrecy, site/job authorization, stored XSS/escaping, CSRF, unsafe URL handling, and package/update verification have no open P0/P1 findings.

---

## P1 — packaging, install and updates

- [ ] PG-31 [WORKS] — A restrictive distribution builder exists (`tools/build-distribution.mjs` + `tools/distribution-manifest.json`) and allowlists runtime trees while excluding tests, docs, vendor, secrets, source/build artifacts and unsafe filenames.
- [ ] PG-32 [UNVERIFIED] — Build the exact release-candidate ZIP and verify its inventory/hash. No `.env`, credentials, auth state, tests, local paths, source-only files, maps, logs, archives, or machine-specific artifacts may be present.
- [ ] PG-33 [UNVERIFIED] — Clean-install proof passes from the ZIP, not the source checkout: upload → activate → migrations/bootstrap → onboarding page → no fatal/error → uninstall/reinstall behavior as intended.
- [ ] PG-34 [UNVERIFIED] — Upgrade proof passes from the currently deployed/previous supported version to the release candidate without losing languages, translations, settings, connection metadata, or customer-edited content.
- [ ] PG-35 [UNVERIFIED] — Signed/private update delivery works against the canonical backend: update check finds the intended version, authenticated package access succeeds, package verification succeeds, tampered package fails closed, WordPress installs it, and installed version/hash matches the release artifact.
- [ ] PG-36 [UNVERIFIED] — A rollback artifact and procedure exist for the exact launch version; a failed rollout can restore the last known-good plugin without corrupting schema/content.
- [ ] PG-37 [UNVERIFIED] — Final release metadata is coherent: plugin header, `IPZ_VERSION`, `readme.txt` stable tag/changelog, distribution filename, Git tag and backend update catalog all identify the same version.

---

## P1 — supported environment / compatibility

- [ ] PG-38 [UNVERIFIED] — Final supported WordPress/PHP/database matrix is declared and exercised. Update `Tested up to` to the actually tested WordPress release; do not claim PHP 8.3 in body copy while metadata/runtime allows PHP 8.0 unless that distinction is intentional and tested.
- [ ] PG-39 [UNVERIFIED] — ACF compatibility is tested both installed+active and absent; activation/admin/translation must remain clean in both cases.
- [ ] PG-40 [UNVERIFIED] — Yoast compatibility is tested both installed+active and absent; activation/admin/frontend SEO must remain clean in both cases.
- [ ] PG-41 [UNVERIFIED] — Theme/block-editor coverage passes for the first customer's actual stack, including front page, regular page, post, menus/navigation, relevant blocks/templates, RTL if the customer needs it, and cache/permalink refresh behavior.
- [ ] PG-42 [UNVERIFIED] — First customer's actual WordPress/PHP/theme/plugin combination is run as a dedicated acceptance fixture before their production install. Compatibility outside that matrix is not silently promised.

---

## P1 — first-customer acceptance and support

- [x] PG-43 [WORKS] — `docs/launch/FIRST-CUSTOMER-ACCEPTANCE.md` defines the executable first-customer script and required evidence for exact ZIP/version/Git SHA/SHA-256/backend deployment identity. It covers install/activate, Connect/social sign-in, language setup, Page + string translation, conditional route/switcher and manual-protection proof, async/bulk + cancel, disconnect/reconnect, authenticated plugin update, negative paths, and rollback decision. Stripe checkout/portal/catalog rows are explicitly `WAITING_EXTERNAL`; running this script on the customer-like final release candidate remains PG-44.
- [ ] PG-44 [UNVERIFIED] — Run PG-43 on a clean staging clone representative of the waiting customer's site and record screenshots/logs/artifact SHA/backend deployment SHA. No manual database repair may be required.
- [x] PG-45 [WORKS] — `docs/launch/FIRST-CUSTOMER-SUPPORT.md` defines required named intake/plugin/backend/commercial/customer owners, impact classification, plugin/backend/mixed/commercial boundaries, rollback authority, known-good artifact retention, exact SHA/version identification, provider escalation, customer communications, and diagnostic redaction. It invents no support address, response time or SLA; the real contact route and named people must be bound in the customer acceptance record before activation.
- [ ] PG-46 [UNVERIFIED] — Production `https://api.press.zone` exposes the exact plugin-required Connect, package, translation/job, status, portal, heartbeat/exceptions, and update/package endpoints for the backend release paired with this plugin. Backend implementation/deployment details belong in `press-zone-core/GOLIVE.md`; this criterion records only the plugin dependency proof.

---

## Deferred unless included in the first sale

The following are **not automatic blockers** if they are explicitly excluded from the sold scope and any production-looking UI/marketing promise is removed or clearly marked unavailable:

- [ ] PG-47 [DEFERRED] — Full Site Content translation (block templates, navigation, synced patterns) beyond what the waiting customer needs.
- [ ] PG-48 [DEFERRED] — WPML migration unless the waiting customer is migrating from WPML.
- [ ] PG-49 [DEFERRED] — Team workflow/assignment/analytics features unless included in the purchased package.
- [ ] PG-50 [DEFERRED] — Broad third-party compatibility matrix beyond the customer's actual stack.
- [ ] PG-51 [DEFERRED] — WordPress.org submission, launch marketing campaign, videos, large knowledge base, case studies and mass-market launch work.

---

## Current audit scoreboard — 2026-08-20

This is **not** a percent-complete calculation; the remaining items are concentrated in high-risk integration and content-integrity seams.

- **WORKS:** 15 criteria (`PG-01`, `PG-04`, `PG-05`, `PG-11`–`PG-14`, `PG-19`, `PG-20`, `PG-22`, `PG-25`, `PG-27`, `PG-31`, `PG-43`, `PG-45`) — PG-14 closed 2026-08-21
- **BROKEN:** 2 criteria (`PG-21`, `PG-23`) — both have exact governance handoffs in `docs/launch/LAUNCH-GOVERNANCE-AUDIT.md`
- **MISSING:** 0 criteria
- **UNVERIFIED:** 27 criteria — implementation exists for many, but current-release runtime proof is absent
- **WAITING_EXTERNAL:** 2 criteria (`PG-03`, `PG-07`) — Stripe clearance/proof, not replacement engineering
- **DEFERRED:** 5 scope-controlled items (`PG-47`–`PG-51`)

### Go-live status

**NOT READY TO SELL YET.**

The plugin is structurally late-stage, but sale readiness is blocked by a small number of high-impact items rather than a large amount of greenfield development:

1. complete the already-WIP Connect/site-credential proof; Stripe checkout/billing then waits on external clearance rather than new payment engineering;
2. rerun the existing sync/async translation lifecycle as a release regression check; do not rebuild it;
3. finish manual-translation overwrite protection in the concurrent production-completion lane;
4. close/verify ACF + Yoast behavior for the supported customer stack in that same concurrent lane;
5. make the final factory/browser/release-ZIP/update gates green;
6. resolve the exact PG-21/23 runtime/web identity handoffs in `docs/launch/LAUNCH-GOVERNANCE-AUDIT.md`; static marketing/user-guide claims are already reconciled;
7. run the defined first-customer acceptance script on the customer's actual stack; Stripe purchase/portal rows remain `WAITING_EXTERNAL` until real clearance/evidence exists.

The remaining work is tracked by explicit criteria rather than a subjective completion percentage. Stripe is an external wait; the translation lifecycle is an existing regression-protected capability; concurrent feature lanes and release evidence determine the remaining engineering closure.

## Release sign-off

- Release candidate commit: `____________________________`
- Plugin version: `____________________________`
- Distribution SHA-256: `____________________________`
- Matching backend deployment/commit: `____________________________`
- First-customer acceptance receipt: `____________________________`
- Rollback artifact/version: `____________________________`
- Engineering sign-off: `____________________________`
- Commercial go-live authorization: `____________________________`