Command center operational closeout

This checklist defines the finite closeout for the implemented command center. It separates working application features from live configuration and evidence. It is not a claim that every possible enterprise feature exists.

Release checkpoint

Migrations037–040 were applied through Supabase MCP and verified for production revision71050149. See the case release receipt. Migrations041–044 subsequently passed exact-head CI and were applied through MCP; see the8 October release receipt. Growth/maintenance045–047 and financial preflight049 were released in PR317. Category attributes048, final-effect authority050 and listing review051 passed the final combined release checks, were applied through MCP and are live with backend/admin/storefront at b846b432f36f2255c1060cac08f6dcd4817d91ab (PR318). Owner-specific branding052 was already installed and verified. The core software release is complete; provider configuration and actual operational evidence below remain operator work. A migration file, local test, merged commit or deployed application does not establish that its matching database functions are installed. Require passing quality and native database checks for the exact release revision, matching backend/admin/ storefront deployments, database readiness and protected-route access checks. Record the final commit, CI run, deployment identifiers and hosted migration records. This document itself does not advance any release gate.

What the new workflows mean

Area	Implemented behavior	What remains a separate operational step
Refund exceptions037	Owned investigations, frozen evidence, reasons, exact revisions and independent decisions. Revoked owners can be replaced through an audited handover after pending proposals are rejected. Resolution requires a verified existing canonical wallet refund receipt.	Investigate historical, ambiguous or settled orders. A blocked case remains unresolved. This workflow does not issue provider refunds or create settled-order recovery credits. Preserve external evidence and use a separately authorized financial process when the supported wallet path cannot apply.
Privacy handling038	Independent review binds completed approved owned-data execution to a finite register of retained/shared/external systems. Unknown outcomes and stale identity, holds, authority or evidence block completion.	Inspect actual protected evidence and the applicable retention policy for every declared system. A completed request means reviewed documented handling of the declared register; it does not certify universal physical erasure, provider deletion, backup deletion or legal adequacy.
Recovery evidence039	Operators explicitly enter nullable recovery objectives, record evidence and obtain independent review. Checksums distinguish artifact integrity from operator reports. Unknown measurements or failed invariants block an objectives-met outcome.	Agree recovery objectives, establish backup availability and retention, and perform an independently reviewed isolated restoration of the real backup system. Synthetic native dump/restore evidence demonstrates its declared test scope only.
Authority locking040	Review commands lock current actor/role authority in a deterministic order to preserve live access checks under concurrent reviews and revocation.	Verify the exact released migration through native concurrency checks and authorized staff journeys. A successful unauthenticated denial alone does not exercise independent approval.

Required invitation configuration and evidence

Invitation sending requires backend STAFF_INVITATION_DELIVERY_KEY, STAFF_INVITATION_WORKER_SECRET, SUPABASE_URL and SUPABASE_SERVICE_ROLE_KEY. The invitation Edge Function needs matching delivery-key and worker-secret values, its Supabase settings, ADMIN_URL, SES_REGION, SES_ACCESS_KEY_ID, SES_SECRET_ACCESS_KEY and EMAIL_FROM. The delivery key is the canonical base64 encoding of 32 random bytes. These are secret configuration names, not values to put in a ticket, browser build or log. EMAIL_REPLY_TO and SES_CONFIGURATION_SET are optional.

Keep backend STAFF_INVITATION_DELIVERY_ENABLED unset or false until the matched worker and sender configuration is verified. Check unauthorized worker requests are refused. Then use one approved test mailbox and authorized staff accounts to verify queue receipt, provider acceptance, actual mailbox receipt, link acceptance, MFA/access requirements and revoked-link refusal. Preserve the receipt identifiers. queued proves stored work; provider_accepted proves SES acceptance and does not prove inbox delivery. An uncertain outcome retains the original intent and must be investigated before another send.

Selected messaging channels

Only channels selected for operational use require configuration. Native mobile push, web push and WhatsApp are optional capabilities; their absence does not invalidate verified inbox publication. Do not label a skipped or unknown external channel as delivered.

• The notification Edge Function requires SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY and PUSH_WEBHOOK_SECRET, with the notification webhook using the matching secret. APP_URL and ADMIN_URL identify the intended HTTPS application origins.
• Email notification delivery uses SES_REGION, SES_ACCESS_KEY_ID, SES_SECRET_ACCESS_KEY and EMAIL_FROM in the notification Edge Function. Its configuration is separate from backend invitation-worker configuration.
• WhatsApp support dispatch needs backend WHATSAPP_ACCESS_TOKEN, WHATSAPP_PHONE_ID and an explicitly approved WHATSAPP_GRAPH_API_VERSION. Selected notification WhatsApp delivery needs those names in the notification Edge Function too. Signed status callbacks use backend META_APP_SECRET; webhook setup uses WHATSAPP_WEBHOOK_VERIFY_TOKEN.
• Optional web push uses VAPID_PUBLIC_KEY, VAPID_PRIVATE_KEY and VAPID_SUBJECT. Optional Android push uses FCM_SERVICE_ACCOUNT. Optional Apple push uses APNS_KEY_ID, APNS_TEAM_ID, APNS_PRIVATE_KEY, APNS_BUNDLE_ID and the selected APNS_ENVIRONMENT.

For each selected channel, run an authorized controlled recipient journey and inspect its persisted receipt. Confirm consent, cancellation, expiry, current authority and messaging-pause gates; preserve the existing attempt on uncertain outcomes. Provider acceptance and actual delivery are different evidence. Campaign inbox publication is implemented; live external campaign delivery remains unverified until channel-specific evidence exists. Do not configure credentials or send live messages merely to make a dashboard indicator green.

Privacy closeout evidence

For each erasure case, finish the exact independently approved owned execution and any exact-version storage work first. Verify identity, current ownership, case revision and legal holds. Review the seven remaining declared domains: financial history; immutable audit/approval/privacy evidence; shared support/ dispute/message/moderation records; profile/auth/provider identities; notification workers/external delivery; backups/external systems; and unclassified storage.

Each domain needs its explicit system scope, protected policy and evidence references, evidence digest and documented outcome. Retained data needs a future retention review deadline. Unknown handling blocks completion. References and hashes alone do not prove deletion; the independent reviewer must inspect the underlying evidence. Preserve the distinction between reviewed handling and physical erasure in all communications.

Recovery closeout evidence

Agree RPO (acceptable recovery-point gap) and RTO (acceptable restoration time) with the responsible operator. Do not import illustrative BCP targets as live settings. Blank objectives and unknown observations remain unknown.

Record backup identity, backup time, retention/access arrangements, isolated destination, actual restoration duration and observed recovery-point gap. Independently compare restored authorization/permissions, wallet/escrow/ledger, audit history, storage and queued work. Check uncertain queued financial or notification operations remain fenced against duplicate dispatch. Storage SQL metadata equality does not establish restoration of object bytes; retain separate byte/version evidence where that scope is required.

The native synthetic runner performs a real local PostgreSQL archive restore into a second disposable database. Preserve its exact source hashes, archive identity, measured duration, comparisons and CI artifact. Its SHA256 envelope is an integrity check, not a digital signature or execution attestation. It does not verify a hosted customer backup, provider delivery or production recovery. An objectives-met register outcome applies only to its explicitly reviewed local evidence and agreed objectives.

Finite acceptance

Close this release when the exact application/database revision passes its checks, is deployed with hosted migration readback, and authorized operator journeys exercise the new workflows. Close operational enablement when invitation sending and each selected external channel have configured, controlled evidence; privacy handling has inspected system evidence; and recovery has agreed objectives and independently reviewed restoration evidence. Keep unsupported financial recoveries, unknown external outcomes and missing recovery evidence explicitly blocked rather than marking them complete.

See the release runbook, refund investigations, privacy handling and recovery evidence for the exact workflows.