openfront-dealership-custom-storefront

Start by inspecting the built-in storefront in features/storefront, which defines routes, data loaders, sessions, and UI composition. Then decide whether to adapt the built-in client or build a separately deployed client, verifying every GraphQL operation against schema.graphql before changing code.

Adapt the built-in client when you can reuse existing sessions, transport, design tokens, and named server operations while keeping route files thin. Build a separate client when you need independent deployment, but pin the schema, use checked named operations, and never expose an arbitrary GraphQL proxy.

No, you must not borrow Ecommerce GraphQL roots or rename products and orders into the dealership vertical without validation. Each operation must be verified against this product's schema.graphql, model access rules, and custom resolvers to confirm it exists and is authorized.

Enumerate the actual app routes, trace screen components and their data loaders, list GraphQL operations used, and read schema.graphql plus access rules. Record actor, tenant scope, inputs, outputs, idempotency, and error states, then produce a capability matrix before proposing changes.

A schema-valid document only proves the query parses, not that the actor is authorized or the workflow is safe. Generated CRUD, HTTP 200 responses, or attractive empty states do not prove the storefront workflow is operational; access rules and lifecycle authority must be verified.