System Requirements Document for hotel-booking-saas

1. Introduction

StayNest is a hotel booking application for the hotel-booking-saas project. It is a simple app where users can browse rooms, check prices, and make bookings. The product serves leisure travellers who want to see what a stay will feel like before they commit, and hotel staff who keep room inventory and reservations accurate.

The audience is two-fold and lives inside one visual world:

• Guests — travellers who browse featured rooms and hotel highlights, filter available rooms, review photos, amenities, and pricing on a room detail view, then book by choosing dates and entering guest details. They return to My Bookings to view and cancel their bookings.
• Hotel Administrators — hotel staff who use the Admin Dashboard to manage rooms and bookings, keeping inventory and reservations accurate so guests can browse and book reliably.

The app is deliberately limited to six pages: Home, Rooms, Room Details, Booking, My Bookings, and Admin Dashboard. No additional pages, modules, or adjacent capabilities are in scope.

2. System Overview

StayNest is a web application with a custom first-party UI, a shared backend, and durable application-owned state. Guests can browse Home, Rooms, and Room Details anonymously. Booking and My Bookings require an established guest identity so that a reservation remains bound to the correct traveller and can be resumed, viewed, and cancelled. The Admin Dashboard requires an invited or provisioned Hotel Administrator identity.

Current delivery covers:

• Anonymous browsing of featured rooms, hotel highlights, available rooms with filters, and room detail content (photos, amenities, pricing).
• Guest self-service enrollment and returning verification as the prerequisite for Booking and My Bookings.
• Booking creation with date selection and guest details.
• Guest viewing and cancellation of their own bookings.
• Hotel Administrator invitation/provisioning and returning verification as the prerequisite for the Admin Dashboard.
• Hotel Administrator management of rooms and bookings.

Narrow exclusions: no pages beyond the six named; no payment processing, no loyalty program, no messaging, no reviews, no multi-property management, no dark mode, and no blue/indigo primary styling.

2a. Product Interpretation and Delivery Boundary

StayNest is delivered as a first-party web application. The application owns its identity: a guest establishes a StayNest identity on first use and verifies it on return; a Hotel Administrator is invited or provisioned by the hotel and verifies on return. Browsing Home, Rooms, and Room Details is anonymous and requires no identity. Booking and My Bookings are protected because a reservation is a durable commitment that must remain bound to the correct guest and be resumable. The Admin Dashboard is protected because room and booking management changes shared product state.

The anonymous entry interaction that establishes guest access is embedded in the Booking page's entry context: a guest who is not yet verified is asked to establish or verify identity before protected booking state becomes available. The Admin Dashboard's protected state remains unavailable until Hotel Administrator identity is established through invitation or provisioning.

Everything described in this document is current. No future-horizon features are accepted.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source.

2c. Page Content and Component Coverage

Home

• Information/state: Featured rooms and hotel highlights. Anonymous, no identity required.
• Primary actions: Browse featured rooms; navigate to Rooms; navigate to Room Details from a featured card; navigate to My Bookings; sign in.
• Supporting actions: Scroll the featured row horizontally; use the capsule search bar (destination, dates, guests) to move toward Rooms.
• Domain entities: Room (featured subset), Hotel highlight.
• Component responsibilities:
  • Full-bleed candy hero with a large pink blob (#FF4D9D) filling the right two-thirds and bleeding off the right and bottom edges; border-radius deforms on scroll.
  • Wordmark "StayNest" top-left in Comfortaa 24px.
  • Lime capsule nav top-right: "Rooms · My Bookings · Sign in".
  • Headline "Sleep somewhere that feels like a holiday" in Comfortaa 700, clamp(44px, 9vw, 104px), left-aligned across the left 7 of 12 columns, overlapping the pink blob's edge by one line.
  • White capsule search bar at 60% width with destination, dates, guests, and one pink circular search button.
  • Glossy 3D lime sphere (~120px) resting on the blob's upper curve.
  • Featured rooms as a horizontally scrollable row of tall capsule cards (photo top 70%, white rounded footer with name and price), bleeding past the viewport edge.
  • Hotel highlights section.
• States:
  • Loading: glossy rounded primitives as skeleton placeholders for featured cards.
  • Empty: no featured rooms — a glossy blob empty state with a link to Rooms.
  • Success: featured cards render with photos, names, and prices.
  • Error: featured content fails to load — a rounded retry capsule.
  • Recovery: retry reloads featured content without losing the hero.

Rooms

• Information/state: Available rooms with filters. Anonymous, no identity required.
• Primary actions: Apply and clear filters; open a room's Room Details.
• Supporting actions: Scroll the pill filter row on mobile; scroll the asymmetric results grid.
• Domain entities: Room, Filter (pill), Availability.
• Component responsibilities:
  • Left rail of pill filters on desktop; collapses into a horizontally scrollable pill row on mobile.
  • Filter pills morph width and colour on selection (inflate on selection).
  • Results in a two-column asymmetric grid — every third card taller and offset.
  • Room cards as tall capsules with a specular highlight that slides across the surface on hover; hover lifts the card 6px.
• States:
  • Loading: glossy rounded skeleton cards in the asymmetric grid.
  • Empty: no rooms match the filters — a rounded empty state with a "clear filters" capsule.
  • Success: filtered room cards render with photos, names, and prices.
  • Error: room list fails to load — a rounded retry capsule.
  • Recovery: clearing filters or retrying restores the grid.

Room Details

• Information/state: Photos, amenities, and pricing for a selected room. Anonymous, no identity required.
• Primary actions: Proceed to Booking for this room.
• Supporting actions: Browse the photo stack; review amenities; read pricing.
• Domain entities: Room, Photo, Amenity, Price.
• Component responsibilities:
  • Photo stack at the top with overlapping rounded frames.
  • Amenities as a grid of circular icon chips (soft rounded pictograms, 3px stroke, rounded caps).
  • Sticky capsule price bar pinned to the bottom on mobile.
  • Price numerals in Comfortaa 700 so "€189" reads as an object.
• States:
  • Loading: rounded skeleton frames for photos and amenity chips.
  • Empty: room not found or no photos — a rounded empty state with a link back to Rooms.
  • Success: photos, amenities, and pricing render; the price bar is available.
  • Error: room detail fails to load — a rounded retry capsule.
  • Recovery: retry reloads the room detail; the guest can return to Rooms.

Booking

• Information/state: Date selection, guest details, and booking completion. Protected: requires an established and verified guest identity. A guest who is not yet verified is asked to establish or verify identity before protected booking state becomes available.
• Primary actions: Choose dates; enter guest details; confirm the booking.
• Supporting actions: Adjust the date range via the lozenge handles; review the growing summary capsule.
• Domain entities: Booking, Date range, Guest details, Room.
• Component responsibilities:
  • Single centred column of rounded panels — dates, guests, details.
  • Date-range picker as one continuous rounded lozenge with two circular handles; handles glide between days.
  • Progress indicator as a chain of overlapping circles that fill with lime as steps complete.
  • Sticky pink capsule summary at the bottom that grows in height as fields are filled.
  • Identity establishment/verification entry interaction for unverified guests, embedded in the Booking entry context.
• States:
  • Loading: rounded skeleton panels.
  • Empty: no dates or guest details yet — the summary capsule is at its minimum height.
  • Success: booking confirmed — a pink confirmation band; the booking appears in My Bookings.
  • Error: booking fails (for example, the room is no longer available for the chosen dates) — a rounded error panel with a retry capsule.
  • Recovery: the guest can adjust dates or details and retry without losing entered data.

My Bookings

• Information/state: The guest's own bookings. Protected: requires an established and verified guest identity.
• Primary actions: View bookings; cancel a booking.
• Supporting actions: Review booking status and details.
• Domain entities: Booking, Status, Room.
• Component responsibilities:
  • Each booking rendered as a capsule ticket with a notched left edge and a lime status dot.
  • Cancel as a quiet outline capsule — never a red danger button.
• States:
  • Loading: rounded skeleton tickets.
  • Empty: no bookings — a rounded empty state with a link to Rooms.
  • Success: booking tickets render with status dots.
  • Error: bookings fail to load — a rounded retry capsule.
  • Recovery: retry reloads the booking list; a cancelled booking shows its updated status.

Admin Dashboard

• Information/state: Room and booking management. Protected: requires an invited or provisioned Hotel Administrator identity.
• Primary actions: Manage rooms; manage bookings.
• Supporting actions: Toggle room availability; review stat chips; review booking status pills.
• Domain entities: Room, Booking, Status, Availability.
• Component responsibilities:
  • Capsule status pills and glossy stat chips in a 3-up row.
  • Rooms as compact rounded rows with a pink toggle.
  • Same candy grammar at higher density; same glossy primitives for empty states and loading.
  • Identity establishment/verification entry interaction for unverified administrators, embedded in the Admin Dashboard entry context.
• States:
  • Loading: glossy rounded skeleton rows and chips.
  • Empty: no rooms or no bookings — a glossy blob empty state.
  • Success: rooms and bookings render with status pills and toggles.
  • Error: management data fails to load — a rounded retry capsule.
  • Recovery: retry reloads the dashboard; a failed room or booking change can be retried.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Browse featured rooms and hotel highlights (Home) As a Guest, I should see featured rooms and hotel highlights on Home so that I can get a first impression of StayNest.

• Provenance: explicit.
• Trigger/input: the Guest opens Home.
• Observable result: featured room cards and hotel highlights render.
• Access state: anonymous, no identity required.
• Failure/recovery: if featured content fails to load, a rounded retry capsule is shown; retry reloads featured content without losing the hero.
• Continuation: the Guest can open a featured room's Room Details or navigate to Rooms.

FR-2 — Browse available rooms with filters (Rooms) As a Guest, I should see available rooms with filters on Rooms so that I can narrow down rooms that suit my stay.

• Provenance: explicit.
• Trigger/input: the Guest opens Rooms and applies or clears filter pills.
• Observable result: the results grid updates to the filtered set of available rooms.
• Access state: anonymous, no identity required.
• Failure/recovery: if the room list fails to load, a rounded retry capsule is shown; clearing filters or retrying restores the grid.
• Continuation: the Guest can open a room's Room Details.

FR-3 — Review photos, amenities, and pricing (Room Details) As a Guest, I should see photos, amenities, and pricing on Room Details so that I can decide whether the room is right for me.

• Provenance: explicit.
• Trigger/input: the Guest opens Room Details for a selected room.
• Observable result: the photo stack, amenity chips, and pricing render; the sticky capsule price bar is available on mobile.
• Access state: anonymous, no identity required.
• Failure/recovery: if the room detail fails to load, a rounded retry capsule is shown; the Guest can return to Rooms.
• Continuation: the Guest can proceed to Booking for this room.

FR-4 — Establish guest identity on first use As a Guest, I should be able to establish my StayNest identity on first use so that my booking remains bound to me and can be resumed.

• Provenance: required_inference.
• Trigger/input: an unverified Guest attempts to access Booking or My Bookings.
• Observable result: the Guest completes self-service enrollment and gains access to protected booking state.
• Access state: anonymous entry; protected state remains unavailable until identity is established.
• Failure/recovery: if enrollment fails, the Guest can retry without losing entered information.
• Continuation: the Guest proceeds to Booking or My Bookings.

FR-5 — Verify returning guest identity As a Guest, I should be able to verify my identity on return so that I can access my bookings.

• Provenance: required_inference.
• Trigger/input: a returning Guest attempts to access Booking or My Bookings.
• Observable result: the Guest verifies and gains access to protected booking state.
• Access state: anonymous entry; protected state remains unavailable until identity is verified.
• Failure/recovery: if verification fails, the Guest can retry.
• Continuation: the Guest proceeds to Booking or My Bookings.

FR-6 — Choose dates and enter guest details (Booking) As a Guest, I should be able to choose dates and enter guest details on Booking so that I can complete a reservation.

• Provenance: explicit.
• Trigger/input: the Guest selects a date range via the lozenge handles and enters guest details.
• Observable result: the progress circles fill with lime as steps complete; the sticky pink summary capsule grows as fields are filled.
• Access state: protected; requires an established and verified guest identity.
• Failure/recovery: if the booking fails (for example, the room is no longer available for the chosen dates), a rounded error panel with a retry capsule is shown; the Guest can adjust dates or details and retry without losing entered data.
• Continuation: on confirmation, the booking appears in My Bookings.

FR-7 — View bookings (My Bookings) As a Guest, I should be able to view my bookings on My Bookings so that I can see what I have reserved.

• Provenance: explicit.
• Trigger/input: the Guest opens My Bookings.
• Observable result: each booking renders as a capsule ticket with a notched left edge and a lime status dot.
• Access state: protected; requires an established and verified guest identity.
• Failure/recovery: if bookings fail to load, a rounded retry capsule is shown; retry reloads the booking list.
• Continuation: the Guest can cancel a booking.

FR-8 — Cancel a booking (My Bookings) As a Guest, I should be able to cancel a booking on My Bookings so that I am not committed to a stay I no longer want.

• Provenance: explicit.
• Trigger/input: the Guest activates the quiet outline cancel capsule on a booking ticket.
• Observable result: the booking's status updates and the ticket reflects the cancellation.
• Access state: protected; requires an established and verified guest identity.
• Failure/recovery: if cancellation fails, the Guest can retry; the booking remains visible.
• Continuation: the Guest can continue viewing remaining bookings.

FR-9 — Invite or provision a Hotel Administrator As a Hotel Administrator, I should be invited or provisioned before accessing the Admin Dashboard so that only hotel staff can manage rooms and bookings.

• Provenance: required_inference.
• Trigger/input: the hotel invites or provisions an administrator.
• Observable result: the administrator gains an identity that can access the Admin Dashboard.
• Access state: anonymous entry; protected state remains unavailable until identity is established.
• Failure/recovery: if provisioning fails, the administrator can retry.
• Continuation: the administrator verifies on return and accesses the Admin Dashboard.

FR-10 — Verify returning Hotel Administrator identity As a Hotel Administrator, I should be able to verify my identity on return so that I can access the Admin Dashboard.

• Provenance: required_inference.
• Trigger/input: a returning Hotel Administrator attempts to access the Admin Dashboard.
• Observable result: the administrator verifies and gains access to protected management state.
• Access state: anonymous entry; protected state remains unavailable until identity is verified.
• Failure/recovery: if verification fails, the administrator can retry.
• Continuation: the administrator proceeds to the Admin Dashboard.

FR-11 — Manage rooms (Admin Dashboard) As a Hotel Administrator, I should be able to manage rooms on the Admin Dashboard so that inventory stays accurate and guests can browse and book reliably.

• Provenance: explicit.
• Trigger/input: the administrator opens the Admin Dashboard and edits room rows or toggles availability.
• Observable result: rooms render as compact rounded rows with a pink toggle; changes are reflected in the dashboard.
• Access state: protected; requires an invited or provisioned Hotel Administrator identity.
• Failure/recovery: if a room change fails, the administrator can retry; the dashboard reloads on retry.
• Continuation: the administrator can continue managing rooms or move to bookings.

FR-12 — Manage bookings (Admin Dashboard) As a Hotel Administrator, I should be able to manage bookings on the Admin Dashboard so that reservations stay accurate.

• Provenance: explicit.
• Trigger/input: the administrator opens the Admin Dashboard and reviews or updates bookings.
• Observable result: bookings render with capsule status pills; changes are reflected in the dashboard.
• Access state: protected; requires an invited or provisioned Hotel Administrator identity.
• Failure/recovery: if a booking change fails, the administrator can retry; the dashboard reloads on retry.
• Continuation: the administrator can continue managing bookings or move to rooms.

4. User Personas

Guest

• Product context: A leisure traveller using StayNest on mobile, often at night, comparing photos and prices. The emotional register is anticipation and pleasure — the app should feel like the lobby of a design hotel, not a reservation terminal.
• Primary goal: Reserve a stay that feels like a holiday, and be able to manage it afterward.
• Distinct accepted responsibilities: Browse featured rooms and hotel highlights on Home; filter available rooms on Rooms; review photos, amenities, and pricing on Room Details; choose dates and enter guest details on Booking; view and cancel bookings on My Bookings.
• Relevant inputs or decisions: Which room to open; which filters to apply; which dates to choose; what guest details to enter; whether to confirm or cancel a booking.
• Interactions with other accepted participants: The Guest's booking becomes a reservation the Hotel Administrator manages on the Admin Dashboard. The Guest does not interact with the administrator directly.
• Observable success: A stay is reserved and manageable — the booking appears in My Bookings with a lime status dot, and can be cancelled via the quiet outline capsule.

Hotel Administrator

• Product context: A hotel staff member doing inventory work inside the same visual world as the guest experience. The language must survive density without going grey.
• Primary goal: Keep room inventory and reservations accurate so guests can browse and book reliably.
• Distinct accepted responsibilities: Manage rooms on the Admin Dashboard; manage bookings on the Admin Dashboard.
• Relevant inputs or decisions: Which rooms to edit; whether to toggle availability; which bookings to review or update.
• Interactions with other accepted participants: The administrator's management of rooms and bookings directly affects what Guests can browse and book. The administrator does not interact with guests directly.
• Observable success: Rooms and bookings render accurately with capsule status pills and pink toggles; changes are reflected in the dashboard.

5. Core User Flows

Journey 1 — Guest browses featured rooms and hotel highlights (Home)

1. The Guest opens Home anonymously.
2. The Guest sees the full-bleed candy hero with the pink blob, the wordmark "StayNest", the lime capsule nav, the headline "Sleep somewhere that feels like a holiday", the white capsule search bar, and the glossy 3D lime sphere.
3. The Guest scrolls; the hero blob's border-radius subtly deforms.
4. The Guest sees featured rooms as a horizontally scrollable row of tall capsule cards and hotel highlights.
5. The Guest can open a featured room's Room Details or navigate to Rooms.
6. If featured content fails to load, a rounded retry capsule is shown; retry reloads featured content without losing the hero.

Journey 2 — Guest filters available rooms (Rooms)

1. The Guest opens Rooms anonymously.
2. The Guest sees the left rail of pill filters on desktop (or the horizontally scrollable pill row on mobile) and the asymmetric results grid.
3. The Guest selects filter pills; pills morph width and colour on selection.
4. The results grid updates to the filtered set of available rooms.
5. If no rooms match, a rounded empty state with a "clear filters" capsule is shown.
6. If the room list fails to load, a rounded retry capsule is shown; clearing filters or retrying restores the grid.
7. The Guest opens a room's Room Details.

Journey 3 — Guest reviews photos, amenities, and pricing (Room Details)

1. The Guest opens Room Details for a selected room anonymously.
2. The Guest sees the photo stack at the top with overlapping rounded frames, the amenities grid of circular icon chips, and the pricing.
3. On mobile, the sticky capsule price bar is pinned to the bottom.
4. If the room detail fails to load, a rounded retry capsule is shown; the Guest can return to Rooms.
5. The Guest proceeds to Booking for this room.

Journey 4 — Guest establishes identity and completes a booking (Booking)

1. The Guest proceeds to Booking from Room Details.
2. If the Guest is not yet verified, the Guest is asked to establish or verify identity before protected booking state becomes available.
3. The Guest completes self-service enrollment (first use) or verifies (returning).
4. The Guest sees the single centred column of rounded panels — dates, guests, details.
5. The Guest selects a date range via the lozenge handles; handles glide between days.
6. The Guest enters guest details; the progress circles fill with lime as steps complete, and the sticky pink summary capsule grows in height as fields are filled.
7. The Guest confirms the booking.
8. On success, a pink confirmation band is shown and the booking appears in My Bookings.
9. If the booking fails (for example, the room is no longer available for the chosen dates), a rounded error panel with a retry capsule is shown; the Guest can adjust dates or details and retry without losing entered data.

Journey 5 — Guest views and cancels a booking (My Bookings)

1. The Guest opens My Bookings.
2. If the Guest is not yet verified, the Guest is asked to verify identity before protected booking state becomes available.
3. The Guest sees each booking rendered as a capsule ticket with a notched left edge and a lime status dot.
4. If there are no bookings, a rounded empty state with a link to Rooms is shown.
5. If bookings fail to load, a rounded retry capsule is shown; retry reloads the booking list.
6. The Guest activates the quiet outline cancel capsule on a booking ticket.
7. The booking's status updates and the ticket reflects the cancellation.
8. If cancellation fails, the Guest can retry; the booking remains visible.
9. The Guest continues viewing remaining bookings.

Journey 6 — Hotel Administrator is provisioned and manages rooms and bookings (Admin Dashboard)

1. The hotel invites or provisions a Hotel Administrator.
2. The administrator gains an identity that can access the Admin Dashboard.
3. On return, the administrator verifies identity before protected management state becomes available.
4. The administrator sees the Admin Dashboard with capsule status pills, glossy stat chips in a 3-up row, and rooms as compact rounded rows with a pink toggle.
5. The administrator manages rooms — editing room rows or toggling availability.
6. The administrator manages bookings — reviewing or updating bookings with capsule status pills.
7. If a room or booking change fails, the administrator can retry; the dashboard reloads on retry.
8. If there are no rooms or no bookings, a glossy blob empty state is shown.
9. The administrator continues managing rooms or moves to bookings.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Karim Rashid. Headline: Sensual pop minimalism — glossy candy curves for a hotel that feels like a holiday.

Palette (light mode)

Occasional full-bleed colour blocks: a lime band for the 'best rate' strip and a pink band for the booking confirmation, so the page is composed of colour fields, not just cards.

Typography

• Headings: Comfortaa — rounded geometric with soft terminals, 600–700 weight, tight-ish tracking (-0.01em), generous size. Sentence case, never all-caps. Display sizes must be big enough to show the rounded bowls.
• Body: Quicksand.
• Scale: 1.333 modular: 56/40/30/22/17/15.
• Display headline: clamp(44px, 9vw, 104px) on Home.
• Page titles: clamp(32px, 5.5vw, 56px).
• Section heads: 30px.
• Card titles: 22px.
• Body: 17px.
• Metadata: 15px.
• Line-height: 1.05 on display, 1.3 on headings, 1.6 on body.
• Numbers in prices: Comfortaa rounded digits at 700 so "€189" reads as an object, not data.

Shape language

Blobs and capsules everywhere. Cards have 28–36px radii with a 4px offset glossy highlight along the top edge (a soft white inner stroke, not a shadow). Buttons are full capsules; primary buttons carry a moving specular sheen on hover. Section boundaries are curved — a wave or single large arc — rather than straight rules. Filter chips are pills that inflate on selection. The date-range picker is one continuous rounded lozenge with two circular handles. Progress in the booking flow is a chain of overlapping circles, not a bar. Nothing in the UI has a 0px corner except the thin lime divider inside tables.

Layout

• Home: full-bleed candy hero with the headline set into a large pink blob shape that bleeds off the right edge; featured rooms below as a horizontally scrollable row of tall capsule cards (photo filling the top 70%, price and name in a white rounded footer) that deliberately run past the viewport edge.
• Rooms: a left rail of pill filters on desktop that collapses into a horizontally scrollable pill row on mobile, with results in a two-column asymmetric grid — every third card taller and offset, so the grid breathes instead of tiling.
• Room Details: photo stack at the top with overlapping rounded frames, amenities as a grid of circular icon chips, and a sticky capsule price bar pinned to the bottom on mobile.
• Booking: single centred column of rounded panels — dates, guests, details — with the summary living in a sticky pink capsule at the bottom that grows as fields fill.
• My Bookings: each booking is a capsule ticket with a notched left edge and a lime status dot; cancel is a quiet outline capsule, never a red danger button.
• Admin Dashboard: same candy grammar at higher density — capsule status pills, glossy stat chips in a 3-up row, rooms as compact rounded rows with a pink toggle.

Imagery

Glossy 3D blobs and rounded primitives in pink, lime and orange used as decorative anchors — a single large blob behind the hero headline, small glossy spheres as bullet markers, a capsule-shaped 3D pill as the 'available now' badge. Room photography is real but art-directed: bright, high-key interiors with rounded furniture, saturated textiles, generous crops that bleed off card edges. No stock-photo people shaking hands. Amenity icons are drawn as soft rounded pictograms with a single 3px stroke and rounded caps — a blob-shaped bathtub, a circular pillow, a wavy pool. The Admin Dashboard uses the same glossy primitives for empty states and loading.

Avoid

• Blue or indigo primary buttons on white — no #2563EB, #4F46E5 or #7C3AED anywhere.
• Gradient-blob SaaS heroes and centred headline-plus-subtext-plus-button stacks.
• A grid of identical hover-lift cards — the Rooms grid is asymmetric with every third card taller and offset.
• Straight-edged cards, 0px corners, or hairline grey dividers.
• Red danger styling for cancellation or admin destructive actions — use muted plum outlines instead.
• Stock photography of business people, hotel lobbies shot in cool grey light, or any image that reads as corporate.
• Inter, Roboto, Arial, Helvetica, Poppins, Open Sans, Lato or system-ui for headings or body — Comfortaa and Quicksand only.
• Dark mode — the muse's candy palette depends on a bright ground.

7. Signature Design Concept

The Candy Field Hero. Home's first screen is a full-bleed candy field, not a centred headline-plus-button. A large pink blob (#FF4D9D) fills the right two-thirds of the viewport and bleeds off the right and bottom edges, with its border-radius softly deforming as the page scrolls. The wordmark "StayNest" sits top-left as rounded Comfortaa at 24px, and a lime capsule nav ("Rooms · My Bookings · Sign in") floats top-right. The headline — "Sleep somewhere that feels like a holiday" — is set in Comfortaa 700 at clamp(44px, 9vw, 104px), left-aligned, occupying the left 7 of 12 columns, and it deliberately overlaps the pink blob's edge by one line so type and colour field collide. Beneath the headline, a single white capsule search bar (destination, dates, guests, one pink circular search button) sits at 60% width, not centred. A glossy 3D lime sphere about 120px across rests on the blob's upper curve as the only dimensional object. No gradient blob, no centred stack, no blue button anywhere.

This concept recomposes only accepted content, states, and controls: the hero, the wordmark, the nav, the search bar, the featured rooms row, and the hotel highlights. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the large pink blob (#FF4D9D) filling the right two-thirds of the viewport, with the glossy 3D lime sphere resting on its upper curve.
• Input → transformation → outcome thesis: as the Guest scrolls away from Home, the hero blob's border-radius subtly deforms; the headline stays whole and readable while the colour field shifts around it. The outcome is a hero that feels alive without ever moving readable text or controls.
• Motion vocabulary: liquid and soft. Cards scale in with a slight overshoot (cubic-bezier(0.34, 1.56, 0.64, 1), 320ms) as they enter the viewport, staggered 60ms. Hover on a room card lifts it 6px and slides the specular highlight across the surface. Filter pills morph width and colour on selection rather than snapping. The booking summary capsule grows in height as fields complete. Date picker handles glide between days. Scroll-linked: the hero blob's border-radius subtly deforms as you scroll away from Home. All of it is 200–360ms, never longer; nothing loops continuously.
• Composed first frame: the pink blob fills the right two-thirds and bleeds off the right and bottom edges; the wordmark sits top-left; the lime capsule nav floats top-right; the headline occupies the left 7 of 12 columns and overlaps the blob's edge by one line; the white capsule search bar sits at 60% width beneath the headline; the glossy 3D lime sphere rests on the blob's upper curve.
• Reduced-motion state: the hero blob holds a static border-radius; the featured rooms row wraps to a scrollable row so each item can be brought fully into view; card scale-in, specular slide, and pill morph are disabled; all content remains readable and every control remains whole.

9. Non-Functional Requirements

• NFR-1 — Durable state: The application must persist rooms, bookings, and guest identities durably so that bookings can be viewed and cancelled across sessions. Provenance: required_inference (durable_state_required). Rationale: a reservation is a durable commitment that must remain bound to the correct guest.
• NFR-2 — Identity continuity: The application must maintain guest and Hotel Administrator identity continuity so that protected destinations remain bound to the correct participant. Provenance: required_inference. Rationale: Booking, My Bookings, and Admin Dashboard all depend on correct participant binding.
• NFR-3 — Readable text and controls: Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Provenance: explicit (creative direction). Rationale: accessibility and legibility across viewports.
• NFR-4 — Reduced motion: With prefers-reduced-motion, the app must provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view. Provenance: explicit (creative direction). Rationale: accessibility.
• NFR-5 — No dark mode: The app must not provide a dark mode. Provenance: explicit (creative direction). Rationale: the muse's candy palette depends on a bright ground.
• NFR-6 — No blue/indigo primary styling: The app must not use blue or indigo primary buttons on white, and must not use #2563EB, #4F46E5, or #7C3AED anywhere. Provenance: explicit (creative direction). Rationale: the palette is pink, lime, and plum-black on a warm pink-white ground.

• NFR-7 — Font restriction: Headings and body must use Comfortaa and Quicksand only; Inter, Roboto, Arial, Helvetica, Poppins, Open Sans, Lato, and system-ui are forbidden for headings or body. Provenance: explicit (creative direction). Rationale: the rounded bowls are the signature.
• NFR-8 — No red danger styling: Cancellation and admin destructive actions must not use red danger styling; use muted plum outlines instead. Provenance: explicit (creative direction). Rationale: the app never punishes the guest.

10. Tech Stack

• Frontend: React (custom first-party UI). Provenance: required_inference from custom_ui: true and the accepted page contract. Rationale: the six pages require a custom UI with the specified candy grammar.
• Backend: Python/FastAPI. Provenance: required_inference from requires_backend_integration: true. Rationale: durable state, identity continuity, and room/booking management require server-side behavior.
• Storage: Appropriate durable storage for rooms, bookings, and identities. Provenance: required_inference from durable_state_required: true. Rationale: bookings must persist across sessions.
• Containerization: Docker/docker-compose. Provenance: required_inference. Rationale: the frontend and backend run as separate services.
• Kubernetes: Not required. Provenance: required_inference. Rationale: deployment does not require it for this scope.

11. Assumptions and Constraints

• A-1: The app is limited to the six named pages: Home, Rooms, Room Details, Booking, My Bookings, and Admin Dashboard. Provenance: explicit. This is a hard constraint.
• A-2: Six pages: 1. Home 2. Rooms 3. Room Details 4. Booking 5. My Bookings 6. Admin Dashboard. Provenance: explicit. This is a hard constraint.
• A-3: Guest self-service enrollment and returning verification are required to make the accepted Booking and My Bookings journeys executable. Provenance: required_inference.
• A-4: Hotel Administrator invitation or provisioning and returning verification are required to make the accepted Admin Dashboard journey executable. Provenance: required_inference.
• A-5: Home, Rooms, and Room Details are anonymous and require no identity. Provenance: explicit (access_requirement: none).
• A-6: Booking and My Bookings are protected and require an established and verified guest identity. Provenance: explicit (access_requirement: role_restricted).
• A-7: Admin Dashboard is protected and requires an invited or provisioned Hotel Administrator identity. Provenance: explicit (access_requirement: role_restricted).
• A-8: No payment processing, loyalty program, messaging, reviews, multi-property management, dark mode, or blue/indigo primary styling is in scope. Provenance: required_inference from the narrow exclusions in the source.
• A-9: The creative direction is authoritative for visuals, colors, theme, motion, and signature design. Provenance: explicit (creative direction).

12. Glossary

• Guest: A leisure traveller who browses rooms, checks prices, and makes bookings on StayNest.
• Hotel Administrator: A hotel staff member who manages rooms and bookings on the Admin Dashboard.
• Room: A bookable hotel room with photos, amenities, and pricing.
• Booking: A reservation created by a Guest for a room over a chosen date range, with guest details.
• Featured room: A room highlighted on Home.
• Hotel highlight: A non-room highlight of the hotel shown on Home.
• Filter pill: A capsule-shaped filter control on Rooms that inflates on selection.
• Capsule ticket: The My Bookings rendering of a booking — a capsule with a notched left edge and a lime status dot.
• Summary capsule: The sticky pink capsule at the bottom of Booking that grows in height as fields are filled.
• Progress circles: The chain of overlapping circles in Booking that fill with lime as steps complete.
• Specular highlight: The moving sheen on primary buttons and room cards on hover.
• Candy grammar: The shared visual language of blobs, capsules, glossy surfaces, and candy colours used across guest and admin surfaces.