openfront-convenience-custom-dashboard

Start by inspecting the actual source: `features/dashboard` holds the generic Keystone admin shell and `features/platform` holds the Convenience-specific screens and server actions. Then decide whether to adapt the built-in client or build a separate one, and verify every GraphQL operation against `schema.graphql` before implementing.

Adapt the built-in client when you can reuse the existing session, transport, design tokens, and named server operations. Build a separate client when you need independent deployment, but then pin the schema, use checked named operations, and keep privileged credentials server-side behind a BFF.

No, not without validation. The skill explicitly forbids borrowing Ecommerce roots or renaming products and orders into this vertical; every operation must be verified to exist and be authorized in the Convenience schema and access rules.

The skill marks it in the capability matrix as needing a backend contract or blocked, and shows the feature as unavailable. It never treats a generated schema, HTTP 200, or attractive empty state as proof the workflow is operational.

Use a trusted environment-pinned endpoint with checked named operations, never expose an arbitrary GraphQL proxy, and reject browser-selected fields, operations, or endpoint URLs. Test anonymous, wrong-tenant, duplicate, timeout, and provider-failure behavior against disposable data.