docs: move the engineering documents into docs/

Thirteen files at the repository root, seven of them documents. Only README.md
earns a place there; the rest are now in docs/ beside the meeting notes, the
client roadmap and the historical material.

The compose files stay. docker-compose.yml is the path the dtf-cloud Portainer
stack reads, so moving it would break deployment, and Docker resolves a compose
file's relative build contexts against its own directory, so moving the other
two would silently break every build. Both reasons are now written down where
someone would otherwise try it.

Correcting references turned up a live fault: the Portainer stack creation
instructions still named deploy/stack.yaml as the compose path. That file was
removed, so anyone recreating the stack from these instructions would have
failed. It names docker-compose.yml now, with the reason it stays at the root.

ROADMAP.md keeps the paths its closed findings were written with, and says so at
the top. Those entries record where a fault was when it was found; rewriting
them to match a later layout would make the record less true, not more.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/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.