63 lines
5.2 KiB
Markdown
63 lines
5.2 KiB
Markdown
# 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.
|