Production checklist

Errorcore is production-ready only when every P0 item below has current evidence from the release candidate in staging. A successful build, a locally rendered console, or a demo-data walkthrough is not production approval.

Billing runs through the backend Polar integration. BILLING_PROVIDER must be set consistently on the console, API, and worker in production: none ships the core-ingestion profile with billing actions failing closed and no billing credentials or egress anywhere, and polar requires POLAR_ENVIRONMENT, POLAR_ACCESS_TOKEN, POLAR_WEBHOOK_SECRET, POLAR_STARTER_PRODUCT_ID, and POLAR_PRO_PRODUCT_ID; a partial configuration is a startup failure, never a silent degrade. The console holds no provider credentials in either mode; checkout and portal sessions are always server-created by the API.

The backend owns one product ID -> plan key allowlist. Checkout derives the inverse selection from that same allowlist, writes the authenticated Clerk organization ID to Polar metadata as reference_id, and also uses it as the Polar customer external ID. Signed webhooks are the only mechanism that can activate or change an entitlement; the checkout success page only reports that activation is pending.

Sandbox and production are separate deployment configurations and must each supply the product IDs created in that Polar environment. Product IDs are the only provider mapping the backend accepts; they must be complete and distinct, and an unknown or mismatched product never resolves to an entitlement. Price identifiers are never configured — setting any POLAR_PRICE_*_ID fails configuration parsing and stops the process at startup. The monthly amount is authoritative in the catalog served by GET /v1/plans, and checkout rejects any provider amount or currency that does not match it. The provider prices and allowances must match the live pricing page, with trials disabled. Free remains a one-time organization evaluation governed by the live catalog.

Automatic no-go conditions

• Production can select a mock data adapter or enable demo authentication.
• Any query, search, subscription, or mutation lacks authenticated organization, project, and environment scope.
• Cross-tenant identifier substitution is not proven to fail without leaking resource existence.
• A visible mutation is simulated, non-idempotent, or does not persist.
• Encrypted payloads can be parsed or decrypted before authenticity, tenant binding, object key, and key ID are verified.
• Required identity, backend, KMS, logging, telemetry, or enabled-provider configuration is missing or unvalidated.
• The release artifact differs from the immutable artifact tested in staging.
• A required migration has no compatibility proof or tested rollback/roll-forward path.
• A serious security, accessibility, dependency-policy, secret-scan, or browser-test failure is open.
• Readiness, alert routing, operational ownership, or rollback evidence is missing.

Identity and tenant boundary

• Anonymous console, React Server Component, server-action, and API requests fail closed.
• Organization membership and role are checked again in every server handler; client state is never trusted for authorization.
• Organization, project, and environment scope reaches every backend operation.
• Cross-organization and cross-project positive and negative tests pass against staging.
• Clerk configuration and organization-selection behavior are verified, including provider degradation.
• CSP, HSTS, frame restrictions, MIME sniffing protection, referrer/permissions policy, and sensitive-route cache policy are asserted by tests.

Data plane and ingestion security

• The production adapter uses the real backend, validates response DTOs, applies deadlines/cancellation, and maps safe error categories.
• Search executes server-side with tenant scope, result caps, debouncing, and cancellation.
• API-key, case-status, DLQ, project, and team operations persist and are idempotent where retries are possible.
• MAC/AEAD verification precedes decompression, parsing, metadata extraction, and decryption.
• Organization, project, environment, event, schema version, purpose, object key, key ID, and authorization are bound before storage or KMS access.
• Body, decompression ratio/size, recursion, and processing-time limits fail closed in security tests.
• Retention, deletion, redaction, and audited break-glass behavior are verified.

Credentials, billing, and administration

• Credentials are generated with a CSPRNG, shown once, absent from logs/caches, and stored only as an approved keyed hash or encrypted secret.
• Create, rotate, and revoke require an authenticated organization admin, re-authentication where destructive, and audit records.
• Rotation grace behavior and immediate revocation are tested.
• BILLING_PROVIDER=none deployments keep Starter and Pro visible with disabled Billing verification pending controls, reject direct billing actions, and inject no billing credentials or egress.
• The production Polar organization reports status=active and capabilities.checkout_payments=true; merchant review is complete before paid checkout is enabled.
• Starter and Pro checkouts each send metadata.reference_id; Polar SDK verification, delivery-ID idempotency, and webhook-only entitlement activation are proven independently.
• BILLING_PROVIDER=polar deployments prove authenticated, organization-bound, server-created checkout and portal sessions; checkout sends one mapped product and allow_trial: false; the returned product and price match; a verified sandbox checkout → webhook → entitlement cycle completes; and reconciliation recovers a missed webhook.
• Invitations normalize email, handle duplicates idempotently, paginate, throttle by admin/organization, enforce policy, and audit outcomes.

Release and runtime evidence

• Dependencies and runtime versions are pinned; two isolated npm ci builds produce the reviewed result.
• Console, API, worker, and migration run from the same attested image digest as separate least-privilege workloads.
• The released SDK passes the checked-in envelope-v2 cross-repo fixtures and retry/idempotency behavior against the staging API.
• Unit, type, production-build, adapter-contract, staging-integration, browser, accessibility, security-header, secret, and dependency-policy checks pass.
• Chromium, Firefox, WebKit, mobile, keyboard-only, and 200% zoom critical journeys pass without hydration or console errors.
• Liveness reflects process health; readiness reflects required dependencies and fails accurately during a dependency drill.
• Logs and traces correlate request, organization, project, and trace identifiers without secrets or payloads.
• Alerts for 5xx, latency, authorization failures, worker staleness, dependency failure, queue depth, and DLQ growth reach the documented responder.
• Deploy, promotion, migration, dependency outage, DLQ, credential, key-incident, and rollback runbooks have been exercised by a second operator.

Approval record

Record artifact digest, source revision, CI run, staging results, migration assessment, dependency/security reports, dashboard snapshots, alert tests, rollback drill, open risks with expiry, approvers, and the UTC go/no-go decision in the controlled release-evidence store. Never attach secrets, customer payloads, or authenticated portal links.

The internal operator handbook under docs/operations defines evidence requirements, ownership, incident severity, escalation, and step-by-step runbooks.