# First-Customer Acceptance

**Product:** International Press Zone
**Company/service:** Press.Zone
**Status:** executable acceptance contract
**Scope authority:** `FIRST-CUSTOMER-SCOPE.md`

## Purpose

This document is the executable acceptance script for the first customer. It does not expand product scope. Every step is evaluated against `FIRST-CUSTOMER-SCOPE.md` and must be backed by evidence from the actual customer environment.

For each executed step, record exactly one result:

- `PASS` — the expected result was observed and the required evidence was captured.
- `WAITING_EXTERNAL` — completion depends on an external service, commercial surface, credential, or operator action that is not available in the test environment. This is not a pass.
- `FAIL` — the expected result was not observed, the evidence is missing, or the step revealed an unsupported or unsafe state.

Do not convert missing evidence into `PASS`. Stripe checkout and customer-portal steps are explicitly `WAITING_EXTERNAL` until a real verified Stripe-backed flow is available.

## Acceptance record header

Complete this block before execution. Missing artifact identity, owner assignment, or customer target information is a `FAIL` for readiness to activate the first customer.

| Field | Required record |
|---|---|
| Customer/site identifier | Customer name or approved non-secret identifier and WordPress site URL |
| Acceptance operator | Named person executing this script |
| Customer approver | Named customer person authorized to approve activation and customer-visible rollback |
| Press.Zone intake owner | Named person responsible for the customer incident record and communications |
| Plugin release owner | Named person responsible for the International Press Zone plugin artifact |
| Backend service owner | Named person responsible for the Press.Zone backend deployment/tenant |
| Commercial owner | Named person responsible for billing/package/Stripe issues, when applicable |
| Support contact route | The actual customer-specific Press.Zone support/contact route supplied for this deployment; do not invent an address |
| WordPress version | Exact version |
| PHP version | Exact version |
| Theme | Twenty Twenty-Five for the gold-path acceptance unless an exception is explicitly recorded |
| Plugin version | Exact plugin header version |
| Plugin Git SHA | Exact source commit used to build the tested artifact |
| Plugin artifact | Exact ZIP filename |
| Plugin artifact SHA-256 | `sha256sum` of the exact tested ZIP |
| Backend environment | Exact environment/tenant used for acceptance |
| Backend deployment identity | Deployment ID and/or Git SHA provided by the backend owner |
| Execution start/end | Absolute timestamps including timezone |

The release artifact used here must be supplied by the release lane. This governance lane does not build the final release ZIP.

## Evidence rules

For every step, capture the minimum evidence listed below. Screenshots are useful for UI state, but do not replace logs, request IDs, artifact hashes, or database/API evidence when those are the relevant proof.

Redact site keys, bearer tokens, cookies, authorization headers, passwords, billing secrets, and customer content that is not necessary to diagnose the result. Follow `FIRST-CUSTOMER-SUPPORT.md` for diagnostic redaction.

## A. Installation and activation

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| A1 | Start from the agreed clean WordPress acceptance site using Twenty Twenty-Five. Record the existing plugin state. | Baseline is known and no previous International Press Zone install can contaminate the result unless the test intentionally covers an update. | Site/version/theme record and pre-install plugin list. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| A2 | Install the exact audited `international-press-zone-<version>.zip`. | WordPress accepts the package and installs it under the `international-press-zone` plugin slug. | Artifact filename/SHA-256, WordPress install result, installed path/slug. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| A3 | Activate International Press Zone. | Activation completes without fatal PHP error and the plugin is identifiable as **International Press Zone**. | Activation result, plugin version, relevant PHP log excerpt with secrets/customer content redacted. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## B. First onboarding, site key, and connection

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| B1 | Open the International Press Zone onboarding/connection flow. | The UI identifies the product as International Press Zone and the service/company as Press.Zone where the company brand is shown. | Screenshot or equivalent UI capture. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| B2 | Complete the current Connect/social sign-in flow against the actual configured identity provider. | Sign-in returns to the plugin through the supported Connect flow and provisions/associates the site credential without exposing that credential to browser UI or evidence. If the provider/backend is unavailable, record the dependency rather than fake-passing it. | Redacted browser/network evidence, OAuth/Connect request or correlation ID when available, backend deployment identity. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| B3 | Complete the supported site-key/site-credential connection state for the first-customer site. | The site is connected using the current server-side credential contract; no separate customer-managed API credential promise is required. Secrets are not echoed into evidence. | Redacted UI evidence plus request/status identifier where available. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| B4 | Reload connection status against the actual Press.Zone backend/tenant. | The plugin reports the real connected/access state. Backend unavailability or missing tenancy/auth is not reclassified as a plugin pass. | Redacted connection state, HTTP status/request ID where available, backend deployment identity. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## C. Language setup and persistence

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| C1 | Open language configuration and select one or more target languages allowed by the current product/backend contract. | Allowed target languages can be selected without relying on a fixed marketing claim about language count. | UI capture and selected language codes/names. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| C2 | Save, leave the page, and return. | The selected target-language configuration persists. | Before/after UI evidence or persisted configuration evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## D. Preview translation

Use a normal source page made from handwritten/core WordPress blocks. Do not use third-party builders, imported Site Content, block templates, or synced patterns as the gold path.

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| D1 | Create or choose an eligible source page and record its post ID/URL. | Source content is known and remains intact through the test. | Source post ID/URL and minimal approved content fingerprint or screenshot. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| D2 | Request a translation preview for one configured target language. | The supported preview flow completes when backend/auth/service dependencies are available; failure is bounded and explicit otherwise. | UI state, request/job ID where available, relevant redacted logs/status. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| D3 | Review the preview before publication. | Preview is identifiable as the requested language/source and can be reviewed without claiming exact visual fidelity of the eventual outgoing page. | Preview capture and source/target identifiers. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## E. Publish translated page

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| E1 | Publish the reviewed translation through the supported flow. | Publish completes when required backend/auth/status dependencies are available. | UI result, target post/page identifier, request/job ID where available. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| E2 | Reload/revisit the translation status. | Published/terminal status remains consistent with the actual target state. | Reloaded status plus target identifier. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## F. Edit-source guardrails

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| F1 | Revisit the source page after publication. | The existing translation relationship/state remains visible and the operator is not silently pushed into unsupported automatic/continuous translation behavior. | Source-page UI capture and source/target IDs. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| F2 | Manually edit the translated content and save it; record the translated revision/state. | The manual edit is persisted and becomes the state that regeneration must protect when the manual-protection capability is in sold scope. | Before/after translated revision IDs and minimal approved content fingerprint/evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| F3 | Make a small approved source edit and save it. | The source save succeeds without losing the established translation intent/relationship. | Before/after source revision IDs and translation/status evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| F4 | Request regeneration/retranslation through the supported path. | **Conditional on the manual-protection lane being green:** the human-edited translation is not silently overwritten and the intended protection/unlock behavior is observable. If that lane is not green for the release candidate, this step cannot be called `PASS`; the capability remains conditional/deferred for the customer. | Before/after translated revision/content fingerprint, protection/review state, request/job ID, linked lane evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## G. Outgoing translated page

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| G1 | Open the customer-facing translated URL in a clean browser session. | A translated page is present at the expected target URL when publication succeeded. This is a presence check, not a promise of exact layout/template/thumbnail fidelity. | URL, HTTP/browser result, screenshot, target post/page identifier. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| G2 | Perform a manual publish-and-look check. | Customer-visible content is usable enough for the agreed first-customer gold path; any fidelity defect is recorded rather than waived. | Screenshot and defect references if applicable. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## H. Activation/status UX

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| H1 | Reload the relevant plugin dashboard/account/status surface after connection and one successful translation. | The UI reflects the real connection/access/translation state and does not require an invented package, price, trial, or SLA claim to establish acceptance. | UI capture plus supporting status/request identifier where available. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| H2 | Log out/in or open a fresh admin session and return to the plugin. | Persisted activation/connection state is represented consistently without exposing credentials. | UI capture; relevant redacted state evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## I. Negative-path checks

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| I1 | Exercise the supported invalid/missing site-key path using non-secret test input. | Failure is explicit and bounded; no credential is leaked into UI/log evidence. | UI/error result and redacted request/log evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| I2 | Exercise an agreed backend-unavailable or backend-error condition without damaging customer data. | The plugin reports failure/retry/status safely and does not corrupt the source page. | Error/status evidence, source revision/content check, request ID if available. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| I3 | Exercise a preview/publish failure path that the environment can safely reproduce. | Failure does not silently become success; source content remains intact and a retry/recovery path is visible where supported. | UI/status evidence and source integrity evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| I4 | Inspect the first-customer UI for deferred capabilities. | Deferred capabilities are not represented as first-customer promises. Any exposed claim for WPML migration/interoperability, imported Site Content, templates/synced patterns, automatic translation, advanced teams/workflow, analytics, broad WooCommerce/multi-currency, third-party builders, broad multisite, or unverified performance/SLA/package claims is a `FAIL` and gets an exact handoff. | Screenshots/route references and handoff IDs if any. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## J. External commercial/Stripe checks

These checks are deliberately outside the core plugin gold-path acceptance until the external commerce surface is available and verified. Their initial status is not negotiable.

| ID | Action | Required evidence to ever change status | Status |
|---|---|---|---|
| J1 | Complete a real first-customer Stripe checkout from the actual supported commercial flow. | Real checkout session/customer/subscription identifiers recorded in redacted form; resulting entitlement observed in the backend/plugin. | `WAITING_EXTERNAL` |
| J2 | Open and use the real Stripe-backed customer portal from the supported flow. | Real portal session evidence and resulting customer/account state, redacted. | `WAITING_EXTERNAL` |
| J3 | Verify a real package/catalog label shown to the customer matches the backend/commercial catalog. | Backend/commercial catalog evidence from the responsible owner. Do not create a package name, price, trial, limit, or entitlement in this document. | `WAITING_EXTERNAL` |

A real external flow may later be recorded as `PASS` only after the listed evidence exists. A mock, local stub, static screenshot, or inferred backend capability is insufficient.


## K. String translation

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| K1 | Run the supported string scan on the acceptance site. | The supported string surface returns translatable strings without requiring a deferred integration. | String-scan UI/API evidence and a non-secret string identifier. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| K2 | Edit or generate one test string translation for a configured target language and save it. | The translated string persists and is associated with the intended language/source. Connected generation is conditional on backend availability. | Before/after string value or approved fingerprint, language identifier, request ID when generated through Press.Zone. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## L. Localized route and language switcher

These are **CONDITIONAL** capabilities in `FIRST-CUSTOMER-SCOPE.md`. They may be accepted only when the site-entry/routing lane is green for the release candidate and the customer's stack.

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| L1 | Open the published translated page through the localized frontend route. | When the routing condition is satisfied, the localized URL resolves to the intended language/content without a wrong-language or false target. | Exact URL, browser/HTTP result, source/target IDs, linked site-entry acceptance evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| L2 | Use the WordPress language-switcher widget/control on the verified route. | When the switcher condition is satisfied, the control points to the real corresponding language target and does not fabricate unavailable translations. | UI capture and before/after URLs/language IDs. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## M. Async/bulk translation and cancel

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| M1 | Submit a supported bulk/asynchronous translation job for acceptance content. | One job is created for the correct site/account and target language. | Submit response/job ID, source IDs, target language, redacted request evidence. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| M2 | Poll through completion and allow WordPress finalization. | The job reaches a real terminal success state and the intended WordPress target state is finalized once, without duplicate mutation. | Poll/status sequence, terminal payload fingerprint, target IDs/status. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| M3 | Submit a second safe async job and cancel it through the supported flow. | The job reaches terminal `cancelled` (or the canonical cancelled state) and does not finalize translated content after cancellation. | Job ID, cancel response/status sequence, content-integrity check. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| M4 | Attempt the defined out-of-scope cancellation authorization check using a sanctioned fixture. | A job outside the current site/account cannot be cancelled; failure is closed and no foreign data is exposed. | Redacted request/status evidence and both non-secret job/site identifiers. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## N. Disconnect and reconnect

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| N1 | Disconnect the acceptance site through the supported account flow. | The site becomes disconnected/revoked as designed; the credential is not exposed; paid/connected operations no longer pretend to be connected. | UI/status capture, redacted backend status/request ID. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| N2 | Re-run the current Connect/social sign-in and reconnect the same site. | A usable connection is re-established through the supported flow and status converges without manual database repair. | Redacted Connect evidence, new/current site status, request ID, backend deployment identity. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## O. Authenticated plugin update

Use only an update pair intentionally selected by the release owner; do not manufacture a fake update feed.

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| O1 | From the approved previous/installed version, run the authenticated update check. | The update mechanism identifies the intended candidate version only for an authorized site. | Installed version/artifact identity, update-check response in redacted form, target version. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| O2 | Install the authenticated update package through WordPress. | Package access/verification succeeds for the valid artifact and WordPress installs the exact intended candidate. | Pre/post plugin versions, downloaded/package SHA-256, source Git SHA, WordPress update result. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| O3 | Verify preserved state after update. | Languages, source/target relationship, connection metadata (excluding secret), settings needed by the gold path, and customer-edited content remain intact. | Before/after state record plus representative preview/publish/status check. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## P. Rollback decision path

| ID | Action | Expected result | Required evidence | Result |
|---|---|---|---|---|
| P1 | Before activation, identify the known-good rollback artifact and authority from `FIRST-CUSTOMER-SUPPORT.md`. | Exact known-good filename/version/Git SHA/SHA-256 and named plugin release owner/customer approver are recorded. | Acceptance header/support record plus retained artifact location. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |
| P2 | Walk through a blocking-defect decision using the actual acceptance result or a non-destructive tabletop scenario. | The incident is classified plugin/backend/mixed/commercial; the correct owner has authority; rollback does not require guessed credentials, package values, or destructive improvisation. | Decision record, owner names, chosen containment/rollback path. | `PASS` / `WAITING_EXTERNAL` / `FAIL` |

## Acceptance decision

First-customer plugin acceptance is **accepted** only when all of the following are true:

1. Every applicable launch-critical non-commerce step in sections A–I and K–P is recorded as `PASS`; no launch-critical step is `FAIL`. A capability marked CONDITIONAL in `FIRST-CUSTOMER-SCOPE.md` is accepted only when its named release condition is green and linked in the evidence.
2. `WAITING_EXTERNAL` is used only for a genuinely external dependency and the dependency is named. A required gold-path backend dependency that is unavailable remains visible as a launch blocker rather than being waived.
3. J1–J3 remain explicitly `WAITING_EXTERNAL` until real Stripe/catalog evidence exists; they are never fake-passed.
4. The exact plugin artifact filename, version, Git SHA, and SHA-256 are recorded, together with the backend deployment identity.
5. The named support/incident owners and actual support contact route are recorded as required by `FIRST-CUSTOMER-SUPPORT.md`.
6. Any customer-facing claim outside `FIRST-CUSTOMER-SCOPE.md` is removed, gated/deferred, or linked to an exact owner handoff before activation.
7. The customer approver signs off the tested site/artifact pair.

Record the final decision as `ACCEPTED` or `NOT_ACCEPTED`, with the acceptance evidence location and the customer approver's name/date. Do not use this document to declare general availability.