# First-Customer Support and Incident Ownership

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

## Purpose

This document defines who owns first-customer incidents, who may roll back each system boundary, what diagnostic evidence may be collected, and how plugin, backend, mixed, and commercial failures are escalated.

It deliberately defines **no support SLA, response time, package entitlement, price, or trial**. Those commitments exist only if Press.Zone has separately approved and supplied them for the customer.

## Support contact requirement

Before first-customer activation, the acceptance record in `FIRST-CUSTOMER-ACCEPTANCE.md` must contain the **actual support/contact route supplied for that customer deployment** and a named Press.Zone intake owner.

The repository does not establish a generic support email address or a response-time promise. Do not invent `support@...`, a forum destination, an SLA, or a package-specific support entitlement to fill this field. If no real customer contact route has been assigned, first-customer support readiness is not complete.

## Required named owners

The following people must be named in the acceptance record before activation. A person may hold more than one role if Press.Zone intentionally assigns it, but each responsibility must remain explicit.

| Role | Owns | Does not silently own |
|---|---|---|
| **Press.Zone intake owner** | Customer communication, incident record, initial classification, evidence coordination, mixed-incident coordination, closure record | Plugin/backend/commercial changes without the responsible owner's authority |
| **Plugin release owner** | International Press Zone plugin source, build artifact, WordPress-side regression diagnosis, plugin release/rollback decision, plugin evidence | Press.Zone backend deployment or Stripe/catalog changes |
| **Backend service owner** | Press.Zone backend availability, tenant/auth/access, translation jobs/status APIs, backend deployment/config rollback | WordPress/plugin artifact changes or customer billing decisions |
| **Commercial owner** | Real package/catalog/entitlement data, Stripe checkout/portal, billing/commercial escalation | Hard-coding prices/packages into the plugin or redefining technical acceptance |
| **Customer approver** | Approval for customer-visible activation and planned content/site rollback; confirmation that the recovered site is acceptable | Press.Zone engineering changes |

If the symptom crosses boundaries, the **Press.Zone intake owner coordinates the incident** while the plugin and backend owners retain authority over their respective systems.

## Incident boundaries

### Plugin-owned

Primarily plugin-owned examples include activation/fatal failures attributable to the plugin, admin UI failure with a healthy backend, WordPress-side source/translation state defects, package/updater/PHP/JavaScript regressions, or behavior that changes between two known plugin artifacts against the same backend deployment. The plugin release owner leads diagnosis and decides whether to stop rollout or roll back the plugin artifact.

### Backend-owned

Primarily backend-owned examples include backend outage/unreachability, tenant/site-key auth/access failure caused by service state, translation job/status processing failure, backend deployment/configuration regression, or incorrect service-side entitlement state. The backend service owner leads diagnosis and decides whether to repair or roll back the backend deployment/configuration.

### Mixed plugin/backend

Treat a request/response contract mismatch, split plugin/backend status, partial publish/finalize, incorrect client persistence of otherwise-correct service state, or an unproved cross-release regression as mixed. The intake owner opens one incident record. Plugin and backend owners each capture their artifact/deployment identity and evidence before either side changes state. Do not change both systems simultaneously without preserving pre-change evidence when a one-boundary-at-a-time test is practical.

### Commercial/external

Package/catalog, Stripe checkout/portal, billing, payment, and commercial entitlement questions are commercial/external unless technical evidence proves a plugin/backend defect. The commercial owner supplies authoritative catalog/Stripe evidence. Plugin engineers must not resolve missing commercial data by inventing package names, prices, trials, limits, support levels, or checkout behavior.

## Impact classification without SLA promises

Use these labels to decide technical handling, not to promise response times:

- **Launch blocker / data-safety / security:** prevents the agreed gold path, risks source/customer data, exposes credentials, or creates a security concern. Stop activation or rollout until a responsible owner records a safe disposition.
- **Primary workflow degraded:** installation/connection/preview/publish/status/outgoing-page workflow is materially degraded but data is safe. Record the defect and owner; acceptance cannot pass if the affected step is launch-critical.
- **Deferred/non-gold-path:** affects a capability outside `FIRST-CUSTOMER-SCOPE.md`. Keep it deferred or create a separate product task; do not promote it into a launch commitment to close the incident.

These labels imply no acknowledgement or resolution time.

## Rollout and rollback authority

### Plugin artifact

The **plugin release owner** may stop rollout and select a previously verified plugin artifact when a plugin regression is established. Record the customer/site identifier; bad and rollback plugin versions, Git SHAs, filenames, and SHA-256 hashes; WordPress/PHP/theme versions; backend deployment identity; relevant source/translated-page IDs/status; authorizer/time; and post-rollback verification.

A customer-visible content restore or destructive site-state change requires the customer approver unless immediate containment is necessary to stop ongoing corruption. In that emergency case, preserve backups/evidence first where feasible, perform the minimum containment action, and document the decision and resulting state.

### Backend deployment/configuration

The **backend service owner** may stop rollout and roll back the Press.Zone backend deployment/configuration. Record previous and replacement deployment IDs/Git SHAs/config revision identifiers, affected tenant/site, authorizer/time, and post-rollback service evidence. The plugin release owner does not independently mutate backend production state.

### Commercial/Stripe state

The **commercial owner** controls package/catalog/Stripe corrections. Neither technical owner may substitute hard-coded commercial facts merely to make acceptance pass.

### Mixed incident

The intake owner coordinates order of operations. Change one boundary at a time where practical, preserving artifact/deployment identity and evidence after each change so causality is not lost.

## Diagnostic collection and redaction

Record only what is necessary: absolute timestamp/timezone; customer/site identifier; affected URL/path; WordPress/PHP/theme versions; plugin version/Git SHA/ZIP filename/SHA-256; backend environment/tenant/deployment ID or SHA; source/target post IDs and translated URL when relevant; request method/path/status/request or job ID; concise reproduction; relevant browser/PHP/WordPress logs; and screenshots that establish UI state.

Never place these unredacted in tickets, chat, screenshots, pasted logs, or acceptance artifacts:

- site keys, bearer/API tokens, `Authorization` headers, cookies/session values;
- WordPress passwords, private keys/signing secrets, database credentials;
- Stripe secrets or full payment details;
- unrelated customer content or personally identifying data.

Use `[REDACTED]` while preserving useful non-secret structure. Prefer request IDs, hashes, IDs, lengths, status codes, and timestamps over secret payloads. If a minimal customer-content excerpt is genuinely necessary, include only the smallest relevant excerpt and obtain customer approval where appropriate. Do not publish diagnostic bundles publicly without a customer-data/secrets review.

## Artifact and deployment identification

Never diagnose or declare a rollback using only a marketing version label. Identify the exact plugin release with all available values:

```sh
wp plugin get international-press-zone --field=version
sha256sum international-press-zone-<version>.zip
git rev-parse <source-commit>
```

The ZIP hash must refer to the exact customer artifact, not a later rebuild with the same version string.

For the backend, record the deployment ID and/or Git SHA supplied by the backend owner plus the environment/tenant. If the runtime cannot expose an authoritative deployment identity, that is an operational handoff to the backend owner; do not infer it from a local checkout.

## Plugin update preservation procedure

1. Record the installed plugin version/artifact/SHA and backend deployment identity.
2. Record selected target languages and connection state **without recording the site key**.
3. Record a representative source post ID/revision, target post/page ID/URL, and current translation/publish status.
4. Preserve the customer/site backup or rollback mechanism appropriate to the change.
5. Install the exact candidate artifact and record its filename/SHA/source commit.
6. Repeat relevant installation, connection, preview, publish, source-revisit, status, and outgoing-page checks from `FIRST-CUSTOMER-ACCEPTANCE.md`.
7. If a launch-critical regression appears, stop rollout and use the rollback authority above. Do not overwrite evidence with repeated speculative changes.
8. After recovery, record the final installed artifact and customer-visible result.

## Escalation paths

| Symptom/evidence | Primary owner | Escalate to | Required handoff evidence |
|---|---|---|---|
| Plugin activation/PHP/JS/package/updater regression | Plugin release owner | Intake owner; backend owner only if service interaction is implicated | Plugin artifact/SHA, WP/PHP version, redacted logs, reproduction |
| Backend unavailable, tenant/auth/access, job/status service failure | Backend service owner | Intake owner; plugin owner if client handling is suspect | Backend deployment ID/SHA, tenant/site ID, request/job IDs, status codes |
| Client/service contract mismatch or split state | Intake owner coordinates plugin + backend owners | Both technical owners until boundary is proved | Both artifact identities, same request/job IDs/timestamps, before/after state |
| Package/catalog/Stripe/checkout/portal/billing | Commercial owner | Backend owner for entitlement API defect; plugin owner for rendering/client defect | Real commercial/catalog/Stripe evidence in redacted form; no invented values |
| Credential exposure, suspected vulnerability, or customer-data corruption | Intake owner coordinates responsible technical owner(s) | Plugin/backend owner as applicable; customer approver for containment/recovery | Minimum redacted evidence, artifact/deployment IDs, containment actions |
| Deferred feature request | Intake/product owner | Appropriate product lane | Link to `FIRST-CUSTOMER-SCOPE.md`; do not present it as included support |


## Known-good artifact retention

Before the customer is activated, the plugin release owner must retain the exact known-good rollback artifact identified by filename, plugin version, source Git SHA, and SHA-256. Retention must be in the release-controlled artifact location used by the team, not merely a developer worktree or an unverified rebuild. The acceptance record points to that retained artifact without embedding credentials.

If no verified rollback artifact can be identified and retrieved, plugin rollback readiness is incomplete.

## External dependency escalation

The plugin/backend boundary does not make external providers invisible. Classify and route these dependencies explicitly:

- **`api.press.zone` / Press.Zone backend unavailable or wrong contract:** backend service owner leads; plugin owner verifies client handling and preserves the plugin artifact identity.
- **Social/OAuth identity provider unavailable or callback flow rejected:** backend service owner owns the Connect/provider integration; plugin owner owns browser/client state handling. Intake owner coordinates if the failing boundary is not yet proved.
- **Translation/model provider unavailable, throttled, or returning invalid results:** backend service owner owns provider integration, retry/translation-job service behavior, and provider escalation. Plugin owner verifies that WordPress reports the service failure safely and does not corrupt content.
- **Stripe checkout/portal/webhook dependency:** commercial owner and backend service owner coordinate. Stripe remains external to plugin acceptance until the real commercial flow is cleared; plugin code must not invent a substitute payment path.

For every external dependency, record the Press.Zone-side request/correlation identifier available to the operator. Do not paste third-party credentials or full provider payloads into the customer incident record.

## Customer communication checklist

The Press.Zone intake owner keeps customer communication factual and tied to observed state. For each launch-blocking incident or rollback:

1. identify the affected site and visible symptom without exposing secrets;
2. state whether the incident is currently classified plugin, backend, mixed, commercial/external, or still under boundary investigation;
3. identify the exact plugin version/artifact and backend deployment involved when known;
4. state the containment action already taken (for example: rollout stopped, operation disabled, plugin rollback performed, backend rollback performed) without promising an unapproved recovery time;
5. tell the customer whether they should avoid a specific action while the incident is open;
6. record any customer approval required for a content/site rollback;
7. after recovery, report the verified customer-visible state and which acceptance steps were rerun;
8. link remaining follow-up separately from the recovered customer state.

Do not communicate an ETA, response-time guarantee, uptime promise, credit/refund, or package entitlement unless the responsible commercial/support owner has an actual approved commitment for that customer.

## Incident record and closure

Every launch-blocking or first-customer incident has one durable record with the customer/site identifier, owner(s), boundary classification, exact plugin artifact/SHA, backend deployment identity, redacted evidence/reproduction, containment/rollback actions and authorizers, current customer-visible state, follow-up handoffs, and final verification against relevant acceptance steps.

An incident is technically closed only when the responsible owner records final state and evidence. Customer acceptance remains governed by `FIRST-CUSTOMER-ACCEPTANCE.md`; closing an incident does not itself turn a failed acceptance step into `PASS`.