Operator workspace

Openship's purpose-built dashboard is an operator workspace for user-owned order routing. The current application uses Next.js 16, Keystone 6, React 19, GraphQL, Prisma, and PostgreSQL. It is not a customer storefront or payment platform.

Current routes

• /dashboard/platform/orders — inspect imported orders, lines, match state, cart items, downstream purchases, and tracking;
• /dashboard/platform/shops — configure user-owned order sources and ShopPlatform handlers;
• /dashboard/platform/channels — configure fulfillment destinations and ChannelPlatform handlers;
• /dashboard/platform/matches — search both sides and map exact shop variants to channel variants;
• /dashboard/platform/api-keys — create and revoke machine credentials;
• /dashboard/[listKey] — generated administration for permitted schema records.

The first user is initialized at /dashboard/init, not /init or /platform. Current source has no product onboarding wizard or demo seed; shop/channel/link/match setup is manual.

Task workflow

1. Create the first operator and sign in.
2. Configure one synthetic shop against the compiled Shopify/Openfront handler or an isolated custom endpoint.
3. Configure one synthetic channel against a compiled handler or isolated endpoint.
4. Create the user-owned Link between those records.
5. Search source and destination catalogs and create an exact variant Match.
6. Import or select a synthetic shop order.
7. Use bounded match/cart/purchase commands to create the downstream purchase.
8. Authenticate tracking/cancellation events and reconcile all three systems.

The current custom GraphQL layer includes product/order searches, match operations, cart and placement commands, purchase/cancellation operations, and webhook management. Generated list CRUD is not a replacement for those transition paths.

Tenancy and credentials

Openship is scoped directly to the owning User; it does not have an organization/workspace tenant graph. Related shop, channel, order, link, match, and item IDs need explicit same-user validation in every custom resolver and HTTP handler.

API keys have hashed token material and stored scopes, but scope names and resolver coverage must be verified operation by operation. Shop and Channel access/refresh tokens are stored as model text fields in current source and need stronger field denial/encryption before real provider use.

Adapter boundary

Compiled shop and channel adapters currently cover Shopify and Openfront. Database-selected HTTP URLs or function paths can also be executed. No other provider name is built-in merely because a platform row or UI example can be created.

Before enabling configurable execution, add strict egress and import allowlists, credential isolation, bounded payload validation, signed callbacks, provider idempotency, durable attempts/retries, dead-letter visibility, and reconciliation. Current webhook handlers do not all share a durable delivery ledger.

Deployment shape

npm run dev and npm run build both deploy checked-in migrations before starting/building Next.js. Use a deliberate DATABASE_URL; split migration from immutable build if your deployment promotes the same artifact between environments. The checked-in lint script invokes the removed Next.js 16 next lint command, and the package has no test or typecheck script, so do not represent those gates as passing until the owning repository adds current commands.

Run Openship behind trusted HTTPS with managed session/provider secrets, restricted internal network access, backups and restore tests, request/body limits, centralized logs, and adapter monitoring. Exercise cross-user denial, malformed provider responses, duplicate order webhooks, duplicate purchases, partial channel failure, cancellation, and tracking reconciliation for the exact release.