Reservations

Open Reserve, choose the venue, party details and a permitted date/time. Confirm the selection only when a real booking provider returns an accepted reservation identifier. The presentation may show a demo confirmation, which is not a live booking.

The presenter audit found hard-coded October 2026 dates; this is an open UX defect. A release must use current or provider-returned availability before presenting reservation slots as bookable.

A booking is not a screen transition

Reservations allow a customer to request an available date, time, party size and venue. A successful customer-facing booking must correspond to an accepted record from an approved reservation provider or the HSLG backend. A presenter dialog that says 'confirmed' is a simulation unless a real booking identifier and authoritative state are returned.

Expected customer journey

Choose the venue first. Open Reserve, select a date from current provider availability, choose party details and review applicable rules such as cancellation timing, accessibility and special requests. Submit once and wait for the server result. On success show a reference and the details accepted by the provider, not merely the values last typed on the phone. If no availability exists, provide an explicit alternative rather than silently substituting a different slot.

What must happen on failure

If the provider declines the requested slot, keep the form state and explain that another time must be chosen. If the request times out after transmission, preserve any idempotency/reference key and check status before creating a second booking. A customer might otherwise receive two reservations. If the device is offline, do not show a confirmed booking based on saved local input.

Current state and known design defect

The shared presenter demonstrates reservations but the native runtime currently rejects the operation because no approved reservation API is connected. Previous presenter QA also identified hard-coded October 2026 dates. That is not acceptable for a live booking interface. Current dates and availability must come from the provider or a reviewed scheduling model. No venue should receive a booking merely because a user entered a date in a browser demo.

Testing and support

Before live operation test timezone changes, booking in the past, fully occupied slots, overlapping requests, party-size limits, provider outage, cancelled requests and duplicate submissions. Record venue, slot, party size, provider reference and expected state when handling a fault. Never ask customers to post private booking contact details in a public report.