--- name: openfront-hotel-custom-dashboard description: Plan and build a custom Openfront Hotel operator dashboard by explaining the source architecture, interviewing the user, inspecting the current product code and contract, then adapting the built-in client or creating a safe separate client. --- # Openfront Hotel custom operator dashboard Use this skill to adapt the built-in Hotel operator dashboard or create a separately deployed client. Start from this product's current source—not E-commerce conventions, screenshots, or another vertical's schema. ## Source orientation to explain first Before asking implementation questions, briefly tell the user where the current behavior lives: - Repository: - Generic Keystone dashboard shell, list/item screens, authentication helpers, and admin client: `features/dashboard`. - Hotel-specific operator navigation, screens, server actions, projections, and workflows mounted into that shell: `features/platform`. - Thin route entry points: `app/dashboard`, especially `app/dashboard/(admin)/platform/**`. Each route file only re-exports a screen from `features/platform//screens` (approvals, guest governance, and security screens live in `features/platform/guest-governance`). Navigation and per-page permissions are in `features/platform/lib/navigation.ts`. - Current platform routes: front-desk, reservations, housekeeping, analytics, property, rooms, rate-plans, messages, guests and `guests/[id]`, payments, payouts, receivables, disputes, cashier, approvals, guest-governance, folios, channels, groups, maintenance, payment-providers, outbox, security. Shortcuts `/dashboard/reservations`, `/dashboard/housekeeping`, and `/dashboard/guests/[id]` render the same screens. Other lists use the generic `/dashboard/[listKey]` pages. - Auth pages outside the admin layout: `/dashboard/init`, `/dashboard/signin`, `/dashboard/signin/mfa`, `/dashboard/reset`, `/dashboard/signup`, `/dashboard/no-access`. Onboarding: `features/platform/onboarding` and the `runHotelOnboarding` mutation. - Server contract: `features/keystone/models/**` (40 lists registered in `models/index.ts`), `features/keystone/access.ts`, `features/keystone/mutations/index.ts` (custom schema), staff projections in `features/keystone/queries/hotelOperations.ts`, business commands in `features/keystone/{bookings,cashier,channels,folios,groups,guest-governance,operations,payments,rates,receivables,refunds,security}`, and `schema.graphql`. - Staff operations are named `hotel*` queries (for example `hotelFrontDesk`, `hotelReservationCalendar`, `hotelFolioOperations`, `hotelCashierOperations`, `hotelReceivableOperationsPage`) and commands such as `createStaffBooking`, `amendStaffBooking`, `assignRoomToBooking`, `updateBookingStatus`, `postFolioEntry`, `reverseFolioEntry`, `recordBookingPayment`, `runHotelNightAudit`, `manageHotelCashier`, `manageHotelReceivable`, `manageHotelPayout`, `updateHotelApproval`, and `configureHotelPaymentProvider`. Most take an `idempotencyKey`. - `Booking`, `ReservationLineItem`, and `FolioEntry` deny create, update, and delete through generated CRUD; changes go through named commands. Cashier shifts, receivables, approvals, stay services, outages, relocations, the stay register, and governance requests are stored as `HotelAuditEvent` rows, not their own lists. - One property per database: `HotelSettings` is a singleton and roles are global. There is no organization or property tenancy model. - The MCP transport at `/api/mcp-transport/[transport]` returns HTTP 410, so the dashboard AI chat at `/api/completion` cannot load its tools. Explain that `features/dashboard` is the reusable Keystone administration layer and `features/platform` is the product-specific operator experience. These directories show how the dashboard works and which server operations it calls. The current product focus is rooms/rates, reservations, front desk, guests, folios/payments, cashier, receivables, payouts, disputes, approvals, guest governance, housekeeping, maintenance, channels, groups, outbox, and night audit. This list is orientation, not proof that every flow is safe or complete. ## Then interview the user After the source orientation, ask one concise set of questions and skip anything already answered: 1. Where is the exact Hotel source checkout, and which revision/deployment is the target? 2. Do they want to adapt the built-in dashboard or create an independently deployed client? 3. What do they dislike about the current experience, what must stay, and what should change? 4. Which operator jobs, screens, actions, roles, approvals, and scope are required? 5. What visual references, interaction direction, responsive targets, and deployment constraints matter? 6. Which non-production host, schema export, test data, and test identities are available? Restate the brief, inspect the supplied source, identify presentation-only changes versus backend-contract work, and ask for confirmation before broad implementation. ## Required source inspection Before proposing code: 1. Enumerate the actual app routes for this product. 2. Trace the built-in screen components and every data loader/server action they call. 3. Enumerate GraphQL documents and operation names used by those call sites. 4. Read `schema.graphql`, model access, field access, and custom query/mutation resolvers. 5. Record actor, tenant/store/organization scope, inputs, outputs, lifecycle authority, idempotency, and error states for each required operation. 6. Inspect provider adapters, webhooks, workers, uploads, cookies/tokens, and runtime configuration touched by the requested flow. 7. Produce a capability matrix: verified, presentation-only, needs backend contract, blocked, or absent. Do not claim the skill already knows a deployed contract. It knows where and how to discover the exact calls. Generated CRUD or a schema-valid document is not proof of safe access. ## Built-in versus separate client ### Adapt the built-in client - Keep route files thin. - Put product UI and orchestration in the existing feature slice. - Reuse current session, transport, design tokens, loading/error states, and named server operations where they are safe. - Do not duplicate price, availability, lifecycle, payment, clinical/legal, or authorization decisions in components. ### Build a separate client - Use a trusted, environment-pinned endpoint and checked named operations. - Keep privileged credentials and opaque capabilities server-side behind a BFF when needed. - Never expose an arbitrary GraphQL proxy or accept browser-selected fields, operations, relationships, provider IDs, or endpoint URLs. - Pin the exact schema, generate strict types, runtime-validate JSON/custom scalars, and fail closed when a required contract is absent. - Test anonymous, wrong-user, wrong-tenant/store/organization, stale, duplicate, timeout, and provider-failure behavior against disposable data. ## Product-specific boundary Design around rooms/rates, reservations, front desk, guests, folios/payments, housekeeping, maintenance, channels, groups, and night audit. Preserve the product's real workflow nouns and authority boundaries. Never rename E-commerce products/orders into this vertical or borrow E-commerce GraphQL roots without validating that they exist and are authorized here. For consequential actions, require one bounded server projection or command that validates actor, scope, related-record ownership, state transition, transaction/concurrency, idempotency, provider behavior, and audit evidence. If it does not exist, request the backend contract and show the feature as unavailable. ## Handoff Report: - built-in or separate mode; - source path/repository and revision inspected; - routes and built-in screens reviewed; - schema hash and named operations used; - requested changes and what was preserved; - capability matrix and backend blockers; - implemented files and tests; - responsive/accessibility evidence; - auth, scope, secret, provider, migration, deployment, and rollback notes. Never present a source path, generated schema, HTTP 200, or attractive empty state as proof that the operator dashboard workflow is operational.