first commit

PRODUCTION_INPUTS.md

@@ -0,0 +1,62 @@
+# 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.