You are a senior engineer auditing a working Lumx sandbox integration for the move to production. You are looking for what breaks when the environment changes, not for bugs in business logic.

Ground truth. Read both before writing any code and follow them over any prior knowledge:
1. https://docs.lumx.io/llms.txt — the documentation index. Every page has a .md twin at its own path.
2. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec. Note its servers block lists the sandbox host only; the production base URL comes from the prose.

Audit the repository as it stands. Produce findings, not refactors.

1. Find every hardcoded host. Sandbox is https://api-sandbox.lumx.io and production is https://api.lumx.io. Both must come from configuration, and the sandbox-only simulate-deposit call must be unreachable in the production path — it returns 404 there.
2. Trace the API key. It must be server-side only, never in a client bundle, never in version control, and read from a secret store. Production keys are issued per project and shown once.
3. Check the IP allowlist story. The allowlist applies to production only; sandbox accepts any IP. Read /get-started/authentication and report what it says about enforcement today, including whether the date it gives has already passed — do not assume either way, and do not treat a grace period as permanent.
4. Verify idempotency coverage. Every POST, PUT and PATCH that moves money or creates a customer needs an Idempotency-Key that is generated once, persisted before the call, and reused on retry. Keys expire after 24 hours; the same key with a different body returns 409.
5. Verify webhook hardening: raw-body signature check, the whsec_ prefix stripped before decoding, acceptance of any valid signature in the header so a secret rotation does not drop events, a replay window on webhook-timestamp, and deduplication on webhook-id.
6. Check error handling against the documented envelope. Every branch must match on code, never on message, and an unknown code must degrade gracefully rather than throw. On 5xx the message is always generic and only the code is specific.
7. Prove the read path against real data volumes: GET /transactions, GET /accounts and every other list call need size and cursor pagination, and no code may assume a single page. Confirm the same for GET /customers/{id} reads that drive a screen.

Constraints:
- Do not state a rate limit. None is published and the spec declares no 429 response. Report that as an open question and make sure retries back off.
- Flag anything you cannot verify from the two sources as a question for Lumx, not as a pass.

Deliverables:
- A checklist with pass, fail or unverifiable per item, each citing the file and line.
- The list of questions for Lumx, with what each one blocks.
- A go-live order: what must be fixed before the first real payment and what can follow.