Requesting product support

This file describes how to prepare a safe, reproducible source-product support request. It does not create a support entitlement, response target, contact address, or service beyond the buyer's approved Order and the applicable support policy in docs/commercial/support.md.

The product is pre-release. Until an approved Order publishes a real contact and release channel, this repository alone does not open a support channel. Do not guess or publish an email address.

Before requesting support

1. Confirm the exact current tagged product release and update/support entitlement.
2. Follow the relevant setup, provider, troubleshooting, or golden-path document.
3. Reproduce the failure in an unmodified custom-scope/custom-brand reference generated from the same tag when practical.
4. Reduce the failure to the smallest command, request, migration, or UI path.
5. Redact the evidence and inspect it manually before sending.

Request template

Order or entitlement reference:
Product release tag and commit:
Operating system:
Node / Bun / pnpm / Vite+ / Postgres / browser versions:
Document and exact step followed:
Expected behavior:
Actual behavior:
Failing command and exit code:
Smallest safe reproduction:
Material modifications near the boundary:
Does it reproduce in an unmodified generated reference?
Redacted logs/tests attached:
Business impact:

Send the request only through the private contact or release channel identified in the approved Order. A merchant-of-record receipt or checkout support thread may identify the purchase, but it is not permission to expose source, credentials, customer data, or vulnerabilities publicly.

Never send

• passwords, session cookies, auth/reset/magic links, OAuth secrets, or Better Auth secrets;
• provider API keys, webhook secrets, signed URLs, private repository tokens, or deployment tokens;
• .env files, database dumps, payment details, or real customer records;
• proprietary application source unrelated to the smallest reproduction;
• unreviewed coding-agent transcripts or logs that may contain any of the above;
• an unpatched vulnerability in a public issue or community channel.

Use key names, redacted identifiers, safe synthetic data, error codes, hashes, and minimal excerpts. Rotate a credential immediately if it was exposed.

Supported boundary

The strongest defect report reproduces on the current tagged, unmodified release with its pinned toolchain and supported Railway/Vercel, Dokploy/Vercel, and provider paths. Product modifications, arbitrary dependency combinations, provider-account operations, custom deployment, data recovery, incident response, and feature implementation are not automatically included support.

The maintainer may respond with a documentation correction, configuration finding, reproduction, workaround, tracked defect, security coordination, or future release. Support does not promise that every request becomes custom code.