# DTF staging and production input checklist

Status: input worksheet only. Nothing in this document authorizes a real
integration, production deployment, or use of production credentials.

Do not put passwords, tokens, webhook secrets, private keys, customer data, or
provider recovery codes in this repository. Record only the credential owner and
the approved secret-injection location. Test every provider in an isolated staging
or sandbox environment before production activation.

## Decisions required before staging implementation

| Area | Required decision or evidence | Owner | Status/date |
|---|---|---|---|
| Artwork acceptance | Decide whether customer-entered length and quality grade are accepted directly, manually approved, or verified by another defined process. Name the commercial authority and rejection/correction flow. |  |  |
| Checkout | Approve the exact transition from quote to payment, including quote expiry, customer confirmation, cancellation, refund, and correction rules. |  |  |
| Infrastructure | Confirm VPS capacity, operating system, domain/subdomain, DNS owner, TLS termination, Portainer access, Gitea Actions path, and deployment/rollback owner. |  |  |
| Cloudflare R2 | Provide a staging bucket and endpoint, CORS policy, retention/lifecycle rules, narrowly scoped credential owner, storage budget, and restore/rollback acceptance test. |  |  |
| PostgreSQL | Define the managed/self-hosted choice, encryption and access policy, backup destination, schedule, retention, restore objective, and named restore-test owner. |  |  |
| Malware signatures | Approve how ClamAV signatures are refreshed without unrestricted scanner egress, plus stale-signature and scanner-outage response. |  |  |
| Freight | Select the source-of-truth platform, staging access, origin address/postal code, services/carriers, packaging weight/dimensions by DTF length, pickup rules, and pass-through/subsidy/free-shipping policy. |  |  |
| Mercado Pago | Provide sandbox account ownership, webhook administration, approved event/status mapping, refund/cancellation policy, reconciliation owner, and secret-injection location. |  |  |
| Tiny/Olist | Confirm API version/endpoints, staging access, order/product/customer mappings, tag/marker behavior, idempotency key, rate limits, retry rules, and reconciliation owner. |  |  |
| WhatsApp | Select the provider, sending number owner, opt-in/legal basis, approved templates for the four agreed events, staging access, retry/delivery-failure policy, and support owner. |  |  |
| Customer accounts | Select email verification and password-recovery provider/flow, session policy, privacy/contact requirements, and customer-support ownership. |  |  |
| Operators | Define named operator provisioning/removal, roles, MFA expectation, emergency access, and periodic access review. Shared production credentials are not acceptable. |  |  |
| Monitoring | Name alert recipients and escalation windows for authentication abuse, malware detections, stale signatures, queue failures, provider failures, backup failures, capacity, and downtime. |  |  |
| Security findings | Record remediation or explicit risk acceptance for the current MinIO, PostgreSQL, Nginx, Debian, and PDF.js findings before a production-readiness review. |  |  |

## Evidence required before production activation

- A separate staging composition/deployment with no production secrets and no
  route from local fake integrations to real provider accounts.
- Server-authoritative pricing regression results, including all four product
  modes, discounts, assembly charges, minimum length, rounding, and freight.
- Direct multipart R2 tests for resume, exact part sizes, private access, CORS,
  expiry, abort, malware quarantine, secure download, and retention.
- Signed and idempotent Mercado Pago webhook tests, including duplicate, delayed,
  invalid, cancelled, and refunded events. No payment may be created before freight
  is final.
- Idempotent Tiny/Olist and WhatsApp outbox tests covering retry, duplicate delivery,
  rate limiting, permanent failure, and operator reconciliation.
- Account verification/recovery, operator access, TLS, cookie, Host/origin, audit,
  alert, and incident-response checks in the target architecture.
- A scheduled, encrypted, offsite PostgreSQL/object backup and a documented restore
  rehearsal. The verified localhost bundle is useful evidence, not this production
  control.
- A recorded go/no-go review signed by the business owner, operations owner, and
  technical owner, with rollback contacts and a support window.

## Safe implementation order after inputs are approved

1. Complete the non-secret metadata and pass the network-disabled readiness gate.
2. Create the actual separate staging composition and external secret-injection path.
3. Validate private R2 multipart storage, malware release gates, downloads,
   retention, backup, and restore.
4. Add freight quotation because its final value is required before payment.
5. Add Mercado Pago sandbox checkout and authenticated idempotent webhooks.
6. Add Tiny/Olist through the existing outbox/idempotency boundary.
7. Add only the four agreed WhatsApp notification events.
8. Run the complete functional, security, dependency, image, recovery, and manual
   acceptance suite in staging before any production activation.