# Final release-candidate certification

Status: WAITING_FOR_FEATURE_FREEZE — DO NOT EXECUTE FINAL EVIDENCE YET

## Purpose

Own the one final, cross-lane release certification after all production feature lanes have landed. This plan consumes their receipts and closes PG-26, PG-29, PG-30, PG-32..PG-42 final evidence, PG-44, and the plugin side of PG-46.

Running this plan early is waste: any later production-code change invalidates factory/browser/security/package/install/upgrade/update/compatibility evidence.

## Start gate

Do not begin final certification until current `origin/master` contains the accepted outputs of every required first-customer feature lane:

- Worker Connect/credential + real translation E2E;
- E2E remediation recovery;
- Page fidelity PG-11..PG-13;
- manual-translation protection PG-14;
- ACF/Yoast reconciliation required by customer scope;
- language-root / robots-sitemap work required by customer scope;
- launch governance readiness PG-21/23/43/45;
- compatibility preparation matrix/fixture;
- any backend deployment required for plugin API/update proof.

Stripe PG-03/PG-07 may still be `WAITING_EXTERNAL`; certification can prepare everything else but commercial GO remains impossible until Stripe clearance/proof if purchase is required.

## Tasks

### RCERT-01 — Freeze exact candidate

Fetch current `origin/master`, create fresh release worktree, record plugin source SHA, backend deployment SHA, version, and all active go-live lane receipts. No feature implementation is allowed in this lane except a defect fix discovered by certification; any such fix invalidates prior evidence and requires rerun from the appropriate checkpoint.

### RCERT-02 — PG-26 full factory gate

Run canonical full factory gate in a sanctioned environment with locked dependencies. No missing dependency, dispatcher failure, stale known-failing entry, warning, or skipped release-relevant test counts as pass.

### RCERT-03 — PG-29 runtime warning/console cleanliness

Execute the complete supported browser/customer journey with WordPress/PHP debugging enabled. Capture and review PHP logs plus Chromium/Firefox console/network errors. Distinguish expected authorization failures from product warnings/errors.

### RCERT-04 — PG-30 adversarial release-surface security review

Review current exact candidate for:

- REST capability/nonce enforcement;
- OAuth/PKCE state and redirect handling;
- site credential secrecy;
- site/job authorization and IDOR;
- 401/402/429 failure semantics;
- stored/reflected XSS/escaping;
- CSRF;
- unsafe URL/open-redirect handling;
- update/package verification and downgrade/tamper resistance;
- diagnostic/log secret leakage.

Fix P0/P1 findings, then restart affected certification evidence.

### RCERT-05 — PG-32 exact ZIP

Use existing `tools/build-distribution.mjs`; do not create another builder. Record archive filename, byte size, SHA-256, runtime content digest, file count and exact source commit. Verify inventory excludes secrets/tests/docs/source-only/machine artifacts.

### RCERT-06 — PG-33 clean install

Install/activate the exact ZIP using existing `verify-local.mjs --zip` and required browser/runtime checks. Verify migrations/bootstrap/onboarding and no fatal errors.

### RCERT-07 — PG-34 upgrade

Upgrade from the immediately previous supported deployed release to the exact RC through the customer-realistic mechanism. Verify languages, translation relationships/content, settings/exceptions, Connect metadata/credential usability, and manual customer edits survive.

### RCERT-08 — PG-35 authenticated/signed update delivery

Against canonical backend:

- update check returns intended release;
- package access is authorized without credential leakage;
- exact package verifies;
- tampered/unknown package fails closed;
- WordPress update installs successfully;
- installed version/runtime identity matches approved ZIP.

### RCERT-09 — PG-36 rollback

Retain exact last-known-good artifact and prove documented restore procedure. Verify rollback does not corrupt customer data/schema and installed identity is observable afterward.

### RCERT-10 — PG-37 metadata identity

Require exact coherence among plugin header, `IPZ_VERSION`, stable tag/changelog, archive filename, Git tag, backend catalog and installed WordPress version.

### RCERT-11 — PG-38..PG-42 final compatibility rerun

Consume `COMPATIBILITY-MATRIX.md` and customer fixture from compatibility lane. Re-run the final RC across the declared matrix and actual customer stack. This is where PG-38..PG-42 receive final release evidence.

### RCERT-12 — PG-44 customer-like staging acceptance

Run `FIRST-CUSTOMER-ACCEPTANCE.md` on clean staging representative of the customer. Record screenshots/logs/plugin SHA/backend SHA/archive SHA. No manual DB repair is permitted.

Stripe-dependent steps remain pending until clearance; once clearance arrives, rerun/complete them on the same release line before GO.

### RCERT-13 — PG-46 plugin/backend dependency proof

Verify the paired production `api.press.zone` backend exposes every plugin-required current `/api/*` endpoint and error contract: Connect, status/account, translation/job/cancel, heartbeat/exceptions, package/update and portal where applicable. Backend implementation itself remains owned by `press-zone-core/GOLIVE.md`.

### RCERT-14 — Final GOLIVE reconciliation

Populate `docs/launch/RELEASE-EVIDENCE.md`, update every criterion from exact evidence, record GO or NO-GO, and do not use subjective percentage-complete estimates.

## Definition of done

One immutable plugin RC and matching backend release have complete deterministic, browser, security, package, install, upgrade, update, rollback, compatibility and customer-staging evidence. The only remaining NO-GO may be an explicitly external Stripe clearance if still pending.