System Requirements Document for shvo-hotel-3d

1. Introduction

shvo-hotel-3d is a premium, immersive 3D website for the SHVO hotel. The product intent, taken directly from the requester's brief ("I want a 3D website, make a premium website for SHVO hotel"), is to present the SHVO hotel through a real-time three-dimensional, high-end brand experience that conveys exclusivity and architectural grandeur, and to let prospective guests take the next step toward a stay while giving hotel staff a quiet, legible surface to follow up on the interest that arrives.

The audience is twofold:

• Hotel Guest / Prospective Visitor — a design-literate, high-spending traveller who explores the hotel's premium 3D presentation, reviews its rooms, amenities and location, and decides whether to book or get in touch.
• Hotel Staff / Site Owner — the hotel-side role that holds the premium presentation accurate and follows up on guest booking and enquiry requests through a provisioned staff account.

The website must be a 3D website and must feel premium in presentation; both are hard constraints from the source brief and shape every section of this document.

2. System Overview

shvo-hotel-3d is delivered as a first-party web application with three runnable services:

• frontend — a React application that renders the public premium 3D experience (Landing, Hotel Details, Book & Enquire) and the staff-side surfaces (Staff Login, Enquiries).
• backend — a shared FastAPI process that exposes the application APIs and domain modules for hotel content, guest booking/enquiry submission, staff authentication, and staff enquiry review.
• database — MariaDB holding application-owned persistent data: hotel presentation content, guest booking/enquiry records, and provisioned staff accounts.

Actors. The active human personas are exactly two: Hotel Guest / Prospective Visitor and Hotel Staff / Site Owner. The 3D scene renderer, the backend API, and the database are non-persona system actors.

Accepted behavior. Visitors anonymously experience an immersive premium 3D presentation of the hotel, review rooms, amenities and location, and submit a booking or enquiry request. Hotel staff, whose accounts are provisioned by the site owner before first sign-in, verify identity at Staff Login and review and follow up on guest booking and enquiry requests in Enquiries.

Ownership. All five destinations are first-party application surfaces. Public presentation and request submission are anonymous; the staff Enquiries surface is role-restricted and reachable only after staff sign-in. Staff identity is provisioned, not self-enrolled.

Narrow exclusions. No self-service staff registration, no guest accounts, no online payment or card capture, no third-party booking-engine integration, and no presentation of planning documents, success criteria or specifications on the site.

Removed from scope

• Self-service staff registration (also: staff sign-up, self-enrolment)
• Guest accounts and guest sign-in
• Online payment and card capture
• Third-party booking-engine integration
• On-site presentation of planning documents, success criteria or specifications

2a. Product Interpretation and Delivery Boundary

The product is a premium 3D marketing and enquiry website, not a booking engine. Its public half is an immersive, cinematic presentation of the SHVO hotel — a real-time 3D architectural subject, editorial hotel content, and a single clear path to a booking or enquiry request. Its staff half is a deliberately calmer, tabular surface in the same charcoal-and-champagne palette where provisioned hotel staff read and follow up on the requests that arrive.

Delivery ownership. All five destinations are first-party and rendered by the React frontend against the shared FastAPI backend and MariaDB database. The 3D hero is rendered client-side in the browser (WebGL); no external 3D service is required.

Access ownership. The public surfaces — Landing, Hotel Details, Book & Enquire — are anonymous and require no identity. Staff Login is anonymously reachable and is the only place identity is established; Enquiries is role-restricted and reachable only by a signed-in staff member whose account was provisioned by the site owner. There is no self-service account creation for any persona.

Current vs. future. Everything described in this document is current. No future-horizon requirements are accepted at this time.

2c. Page Content and Component Coverage

Landing

• Information/state. Full-viewport charcoal WebGL stage with the parametric SHVO tower as the hero subject; the 'SHVO' wordmark; eyebrow label 'HOTEL · 3D ARCHITECTURE'; a single outlined gold CTA 'Enter the hotel'; a persistent bottom-left camera chip naming the current viewpoint (Exterior / Lobby / Suites / Rooftop).
• Primary action. 'Enter the hotel' — routes the visitor onward into the hotel presentation (Hotel Details).
• Supporting actions. Pointer parallax on the 3D tower; scroll-scrubbed camera dolly from exterior to lobby across the first 120vh; navigation to Hotel Details and Book & Enquire.
• Domain entities. Hotel presentation content (hero copy, eyebrow, CTA label, viewpoint labels).
• Component responsibilities. WebGL hero stage (R3F scene, orbit, parallax, scroll-scrub, floor reflection); wordmark and eyebrow typography block; primary CTA; camera chip; section-arc transitions into subsequent content.
• States. Loading: charcoal stage with the wordmark visible while the 3D scene initialises. Empty: not applicable (static presentation). Success: tower rendered, wordmark interlocked with the tower base, CTA reachable. Error: if WebGL is unavailable, a static architectural still replaces the scene and all copy and the CTA remain fully usable. Recovery: normal scroll always reaches all content; prefers-reduced-motion freezes the orbit, disables parallax and scroll-scrub, and swaps reveals for instant opacity.

Hotel Details

• Information/state. The hotel's rooms, amenities and location presented within the premium presentation; staggered two-column offset room list; architectural stills and macro material imagery colour-graded to charcoal/pearl/gold.
• Primary action. Continue to Book & Enquire.
• Supporting actions. Scroll through rooms, amenities and location; return to Landing.
• Domain entities. Room entries (name, description, rate numerals in tabular Jost, room number in all-caps), amenity entries, location description, supporting imagery.
• Component responsibilities. Room cards as soft-cornered 24px slabs with one sheared corner and a gold hairline that draws left-to-right on scroll entry; amenities block; location block; asymmetric elliptical section arcs; camera chip continuing to name the current viewpoint.
• States. Loading: pearl panels reveal upward over charcoal as content arrives. Empty: if a content section has no entries, its arc and heading are omitted rather than shown blank. Success: all rooms, amenities and location readable and the path to Book & Enquire visible. Error: if content fails to load, a retry affordance is shown and the path to Book & Enquire remains available. Recovery: retry reloads the section; reduced-motion renders all content instantly.

Book & Enquire

• Information/state. A booking/enquiry form in a 7-column measure with a 4-column gold-ruled metadata rail beside it; the rail carries the hotel's contact and stay metadata.
• Primary action. Submit a booking or enquiry request.
• Supporting actions. Enter guest name, contact details, preferred dates, party size and message; return to Hotel Details.
• Domain entities. Booking/enquiry request (guest name, contact details, preferred dates, party size, message, submission timestamp, status).
• Component responsibilities. Form fields with inline validation; submit control in the outlined gold CTA style; metadata rail; confirmation panel on success.
• States. Loading: submit control shows a pending state and is not double-submittable. Empty: form fields empty with placeholders. Success: a confirmation panel acknowledges the request and states that the hotel will follow up. Error: field-level validation messages for missing or malformed input; a submission-failure message with a retry affordance if the backend is unreachable. Recovery: entered values are preserved on failure so the visitor can retry without re-entering.

Enquiries

• Information/state. A strict tabular 3-column layout with hairline rules on the charcoal ground, listing guest booking and enquiry requests with their details and status.
• Primary action. Open a request and record follow-up.
• Supporting actions. Scan the list; read a request's guest details, dates, party size and message; mark a request as followed up.
• Domain entities. Booking/enquiry request (as above) with status and follow-up record.
• Component responsibilities. Enquiries table with hairline rules; request detail panel; follow-up control; signed-in staff indicator and sign-out.
• States. Loading: table skeleton on the charcoal ground. Empty: a quiet message that no enquiries have arrived yet. Success: the list and detail render and a follow-up is recorded and reflected in the row's status. Error: a load-failure message with retry; a save-failure message that leaves the prior status intact. Recovery: retry reloads; a failed follow-up save can be retried without losing the open request.

Staff Login

• Information/state. A calm, legible sign-in surface in the same charcoal-and-champagne palette at lower drama; fields for staff credentials; a note that staff accounts are provisioned by the site owner.
• Primary action. Sign in with provisioned staff credentials.
• Supporting actions. Return to the public site.
• Domain entities. Staff account (provisioned by the site owner).
• Component responsibilities. Credential fields; sign-in control; error messaging; provisioned-account note.
• States. Loading: sign-in control pending during verification. Empty: fields empty. Success: the staff member is taken to Enquiries. Error: a clear message for incorrect credentials or an unprovisioned account, without revealing which accounts exist. Recovery: the staff member can correct credentials and retry; there is no self-service reset or registration path.

3. Functional Requirements

FR-1 — Premium 3D presentation of the SHVO hotel (explicit) As a Hotel Guest / Prospective Visitor, I should experience the SHVO hotel through an immersive, premium 3D website so that I form a high-end impression of the hotel.

• Trigger: the visitor opens the site.
• Observable result: a full-viewport charcoal WebGL stage renders a real-time parametric SHVO tower with a slow orbit, pointer parallax, and a scroll-scrubbed camera dolly from exterior to lobby across the first 120vh; the 'SHVO' wordmark interlocks with the tower's base.
• Access: anonymous.
• Failure/recovery: if WebGL is unavailable, a static architectural still replaces the scene and all copy and the CTA remain usable; prefers-reduced-motion freezes the orbit and disables parallax and scroll-scrub while keeping all content reachable by normal scroll.
• Continuation: the visitor proceeds via 'Enter the hotel' to Hotel Details.

FR-2 — Review the hotel's rooms, amenities and location (required_inference) As a Hotel Guest / Prospective Visitor, I should review the hotel's rooms, amenities and location within the premium presentation so that I can decide whether the hotel suits my stay.

• Trigger: the visitor navigates to Hotel Details.
• Observable result: rooms are shown as staggered sheared-corner slabs with tabular rate numerals and room numbers, alongside amenities and location, all colour-graded to charcoal/pearl/gold.
• Access: anonymous.
• Failure/recovery: if content fails to load, a retry affordance is shown and the path to Book & Enquire remains available.
• Continuation: the visitor proceeds to Book & Enquire.

FR-3 — Submit a booking or enquiry request (required_inference) As a Hotel Guest / Prospective Visitor, I should submit a booking or enquiry request so that I can take the next step toward a stay.

• Trigger: the visitor completes the form on Book & Enquire and submits.
• Input: guest name, contact details, preferred dates, party size, message.
• Observable result: a confirmation panel acknowledges the request and states that the hotel will follow up; the request is persisted and appears in the staff Enquiries list.
• Access: anonymous.
• Failure/recovery: field-level validation for missing or malformed input; on submission failure the entered values are preserved and a retry is offered.
• Continuation: the visitor may return to Hotel Details or the Landing page.

FR-4 — Provisioned staff sign-in (required_inference) As a Hotel Staff / Site Owner, I should sign in with an account provisioned by the site owner so that I can reach the guest enquiries I am responsible for.

• Trigger: the staff member opens Staff Login and submits credentials.
• Observable result: on success the staff member is taken to Enquiries; on failure a clear message is shown without revealing which accounts exist.
• Access: Staff Login is anonymously reachable; there is no self-service registration or reset.
• Failure/recovery: the staff member corrects credentials and retries.
• Continuation: the staff member lands on Enquiries.

FR-5 — Review and follow up on guest enquiries (required_inference) As a Hotel Staff / Site Owner, I should review incoming booking and enquiry requests and record follow-up so that guest interest is handled promptly.

• Trigger: the signed-in staff member opens Enquiries.
• Observable result: a tabular list of requests with guest details, dates, party size, message and status; opening a request and recording follow-up updates its status.
• Access: role-restricted to signed-in provisioned staff.
• Failure/recovery: a load-failure message with retry; a save-failure message that leaves the prior status intact and allows retry without losing the open request.
• Continuation: the staff member returns to the list and continues reviewing.

FR-6 — Maintain an accurate premium presentation (required_inference) As a Hotel Staff / Site Owner, I should keep the hotel's rooms, amenities and location content accurate so that the premium presentation reflects the hotel truthfully.

• Trigger: hotel content changes.
• Observable result: updated room, amenity and location content is reflected on Hotel Details.
• Access: hotel-side content ownership; no separate content-management destination is accepted in this scope, so content is held as application-owned hotel presentation data.
• Failure/recovery: content updates that fail leave the prior published content intact.
• Continuation: the public presentation continues to serve the last valid content.

4. User Personas

Hotel Guest / Prospective Visitor

• Product context. A design-literate, high-spending traveller who evaluates luxury stays as cultural statements. They arrive anonymously at the SHVO site expecting an architectural, cinematic first impression rather than a booking portal.
• Primary goal. Form a confident decision about the SHVO hotel and take the next step toward a stay.
• Distinct responsibilities. Experience the immersive 3D presentation; review rooms, amenities and location; submit a booking or enquiry request with their contact details, preferred dates, party size and message.
• Inputs and decisions. Their own travel intent, dates and party size; the decision of whether the hotel suits them and whether to book or get in touch.
• Interactions with other participants. Their submitted request becomes the object of the Hotel Staff / Site Owner's follow-up work; they expect a timely response from the hotel.
• Observable success. A confirmation that their request was received and that the hotel will follow up.

Hotel Staff / Site Owner

• Product context. The hotel-side role that holds the premium presentation accurate and handles the guest interest that arrives through the site. Their account is provisioned by the site owner before first sign-in; they do not self-enrol.
• Primary goal. Keep the presentation accurate and follow up on guest booking and enquiry requests promptly.
• Distinct responsibilities. Sign in with provisioned credentials; review incoming requests with their guest details, dates, party size and message; record follow-up and update request status; keep room, amenity and location content accurate.
• Inputs and decisions. The stream of guest requests; decisions about how and when to follow up; content changes to the hotel's offering.
• Interactions with other participants. They respond to the Hotel Guest / Prospective Visitor's submitted requests and maintain the content that guest experiences.
• Observable success. Every request is reviewed and marked followed up, and the public presentation reflects current hotel content.

5. Core User Flows

Flow A — A prospective visitor experiences the hotel and submits an enquiry

1. The visitor opens the site anonymously and lands on Landing. The charcoal WebGL stage renders the parametric SHVO tower, the 'SHVO' wordmark interlocks with its base, and the camera chip reads Exterior.
2. The visitor moves the pointer; the tower responds with damped parallax. As they scroll, the camera dollies from exterior to lobby across the first 120vh and the camera chip updates to Lobby.
3. The visitor selects the outlined gold CTA 'Enter the hotel' and arrives at Hotel Details.
4. On Hotel Details the visitor scrolls the staggered room list, amenities and location. Room cards reveal upward with their gold hairlines drawing left-to-right; rates and room numbers read in tabular numerals.
5. The visitor continues to Book & Enquire.
6. On Book & Enquire the visitor completes the form — guest name, contact details, preferred dates, party size, message — with the gold-ruled metadata rail beside it.
7. The visitor submits. The submit control shows a pending state and is not double-submittable.
8. Success: a confirmation panel acknowledges the request and states that the hotel will follow up. The request is persisted and appears in the staff Enquiries list.
9. Failure/recovery: if a field is missing or malformed, an inline message appears beside it. If submission fails, the entered values are preserved and a retry is offered; the visitor retries without re-entering.
10. Continuation: the visitor may return to Hotel Details or the Landing page.

Flow B — A provisioned staff member signs in

1. The staff member opens Staff Login anonymously. The surface is calm and legible in the same charcoal-and-champagne palette, with a note that staff accounts are provisioned by the site owner.
2. The staff member enters their provisioned credentials and submits. The sign-in control shows a pending state.
3. Success: the staff member is taken to Enquiries.
4. Failure/recovery: a clear message is shown for incorrect credentials or an unprovisioned account, without revealing which accounts exist. The staff member corrects credentials and retries; there is no self-service reset or registration path.

Flow C — A staff member reviews and follows up on guest enquiries

1. The signed-in staff member arrives at Enquiries, which renders a strict tabular 3-column layout with hairline rules on the charcoal ground.
2. The staff member scans the list of booking and enquiry requests.
3. The staff member opens a request and reads the guest's name, contact details, preferred dates, party size and message.
4. The staff member records follow-up. On success the request's status updates and is reflected in the row.
5. Failure/recovery: if the list fails to load, a message with retry is shown. If the follow-up save fails, a message appears, the prior status is left intact, and the staff member retries without losing the open request.
6. Continuation: the staff member returns to the list and continues reviewing. If no requests have arrived, a quiet empty message is shown.

Flow D — A staff member keeps the presentation accurate

1. Hotel content for rooms, amenities and location changes.
2. The updated content is reflected on Hotel Details within the premium presentation.
3. Failure/recovery: if a content update fails, the prior published content remains intact and the public presentation continues to serve the last valid content.

6. Visuals Colors and Theme

Muse: Zaha Hadid — "Fluid parametric grandeur for SHVO." Sweeping continuous surfaces, pearl-and-charcoal materiality, motion frozen in form. The emotional register is awe, calm control and exclusivity; the staff surface carries the same brand gravity in a quieter, legible register.

Mode: dark.

Colour tokens (exact hex, by role):

Gold on charcoal passes contrast at body size; gold is never used for small text on gold.

Typography:

• Headings: Josefin Sans, Light 200–300, wide architectural tracking (+0.02em on display, +0.18em on uppercase micro-labels). Sentence case for headlines; all-caps only for eyebrow labels and room numbers.
• Body: Jost.
• Scale: 1.414 modular with a display outlier — clamp(52px, 9vw, 148px) for the hero wordmark, then 64 / 44 / 30 / 20 / 16 / 14.
• Line-height: 0.92 on display, 1.6 on body.
• Numerals: Jost tabular for rates and room counts.

Shape language: Sweeping continuous curves — section boundaries are single asymmetric arcs (border-radius: 0 0 50% 0 / elliptical clip-path), never symmetric pills. Cards are soft-cornered 24px slabs with one sheared corner. Thin 1px champagne rules curve with the section arcs. No drop shadows; depth comes from the 3D scene and from layering pearl panels over charcoal.

Layout: Asymmetric editorial grid on a 12-column base. The hero 3D canvas bleeds full-viewport; the room list is a staggered two-column offset with the right column dropped 96px; the enquiry form sits in a 7-column measure with a 4-column gold-ruled metadata rail beside it. Staff enquiries use the same charcoal ground with a strict tabular 3-column layout and hairline rules. Vertical rhythm: 120px desktop, 56px mobile; everything collapses to a single column at 375px with arcs flattening to 16px radii.

Imagery: One crafted real-time 3D subject — a low-poly-but-smooth parametric SHVO tower with flowing floor plates in matte pearl and dark glass with a warm gold rim light on a charcoal void with a soft floor reflection. Supporting imagery: architectural stills of curved interiors, macro material shots (travertine, brushed brass, dark stone) and one dusk exterior, all colour-graded to charcoal/pearl/gold. Never stock people, never flat clip art.

Forbidden: blue/indigo/violet accents; white-ground SaaS heroes; rounded pill buttons; soft drop-shadow cards; hover-lift grids; sci-fi HUD overlays, glowing cyan data streams or particle fields; playful bouncy easing; toy colours; cartoon illustration; gradient-blob backgrounds; glassmorphism panels; stock photography of smiling people in the hero; presenting or linking to any planning document, success criteria or spec on the site; clipping the wordmark, headlines, labels or CTA against the 3D scene at any breakpoint.

Readable text and controls stay whole at 375px, 768px and 1280px — headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container, wrapping or scaling to fit, and no other element covers any part of them. Imagery, decoration and motion may be cropped, bled, rotated, overlapped or cut as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The building is the navigation landmark. The public entry is a full-viewport charcoal (#0E0F12) WebGL stage. A single flowing parametric SHVO tower floats slightly right of centre at roughly 60% viewport height on desktop, lit pearl-white with a champagne rim, its reflection fading into the ground plane. The wordmark 'SHVO' is set in Josefin Sans Light at clamp(72px, 16vw, 220px), flush-left, sitting in the lower-left third and overlapping the tower's base line so type and architecture interlock on one plane. A hairline champagne rule runs from the wordmark to a small uppercase eyebrow 'HOTEL · 3D ARCHITECTURE' and a single outlined gold CTA 'Enter the hotel'. On mobile the tower centres behind a 52px wordmark stacked above the CTA; nothing is covered by the scene.

The concept recomposes only accepted content and controls: the hotel's identity, the eyebrow label, the single entry CTA, and the 3D architectural subject. It introduces no new behaviour or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject. The parametric SHVO tower — a low-poly-but-smooth architectural form with flowing floor plates, matte pearl and dark glass, warm gold rim light, on a charcoal void with a soft floor reflection.
• Input → transformation → outcome thesis. Pointer movement and scroll are the only inputs. Pointer movement drives a damped (0.6) parallax offset on the tower; scroll scrubs a camera dolly from exterior to lobby across the first 120vh. The outcome is that the visitor's own motion reveals the building's depth and interior, and the persistent bottom-left camera chip names the current viewpoint (Exterior / Lobby / Suites / Rooftop) as the camera moves through the building.
• Motion vocabulary. A slow 40-second orbit of the tower; damped pointer parallax; scroll-scrubbed camera dolly; 700ms cubic-bezier(0.22,1,0.36,1) upward reveals of pearl panels over charcoal; word-by-word type fade on the hero only; gold hairlines drawing left-to-right on scroll entry; single asymmetric elliptical arcs as section transitions.
• Composed first frame. Charcoal ground; tower floating slightly right of centre at ~60% viewport height with its reflection fading below; 'SHVO' wordmark flush-left in the lower-left third overlapping the tower's base; hairline champagne rule to the eyebrow 'HOTEL · 3D ARCHITECTURE'; outlined gold CTA 'Enter the hotel'; camera chip reading Exterior at bottom-left.
• Reduced-motion state. prefers-reduced-motion freezes the orbit to a still frame, disables parallax and scroll-scrub, and swaps reveals for instant opacity. All content remains reachable by normal scroll, and the camera chip shows a single static viewpoint label.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

One crafted real-time object: a parametric SHVO tower with flowing floor plates, rendered in matte pearl and dark glass with a warm gold rim light, on a charcoal void with a soft floor reflection. The scene shows the product's defining state — the hotel as an architectural commission — and is the hero subject, not a background. It orbits on a 40-second cycle, responds to pointer parallax with 0.6 damping, and its camera dollies from exterior to lobby across the first 120vh of scroll. Under prefers-reduced-motion the scene renders a single still frame.

9. Non-Functional Requirements

• 3D constraint (explicit). The website must be a 3D website; the hero is a real-time WebGL/R3F scene, not a background image. Rationale: hard constraint from the source brief.
• Premium presentation (explicit). The website must feel premium in presentation, carried by the charcoal/pearl/champagne palette, Josefin Sans and Jost typography, asymmetric arcs and generous rhythm. Rationale: hard constraint from the source brief.
• Readable text and controls (explicit, from creative direction). Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit; no other element covers any part of them. Rationale: accessibility and brand integrity.
• Reduced motion (explicit, from creative direction). prefers-reduced-motion freezes the orbit, disables parallax and scroll-scrub, and swaps reveals for instant opacity; all content remains reachable by normal scroll. Rationale: accessibility.
• Contrast (explicit, from creative direction). Gold on charcoal passes contrast at body size; gold is never used for small text on gold. Rationale: legibility.
• Graceful WebGL fallback (required_inference). If WebGL is unavailable, a static architectural still replaces the scene and all copy and the CTA remain usable. Rationale: the public entry must remain usable on unsupported devices.
• Staff surface legibility (explicit, from creative direction). The staff Enquiries surface uses the same charcoal ground in a strict tabular 3-column layout with hairline rules, at lower drama than the public surfaces. Rationale: staff need a quiet, legible register.

• Data integrity (required_inference). Submitted booking/enquiry requests are persisted and are not lost on submission failure; a failed follow-up save leaves the prior status intact. Rationale: guest interest must not be silently dropped.
• No on-site planning artifacts (explicit, from creative direction). The site never presents or links to any planning document, success criteria or spec. Rationale: brand integrity.

10. Tech Stack

• Frontend: React application UI, with a real-time WebGL hero built on React Three Fiber (R3F) and Drei for the parametric SHVO tower scene.
• Backend: shared FastAPI process exposing application APIs and domain modules for hotel content, guest booking/enquiry submission, staff authentication, and staff enquiry review.
• Database: MariaDB for application-owned persistent data — hotel presentation content, guest booking/enquiry records, and provisioned staff accounts.
• Orchestration: docker-compose with the three services frontend, backend, and database. No additional infrastructure is required for the accepted workflows.

11. Assumptions and Constraints

• Assumption (required_inference). Staff accounts are provisioned by the site owner before first sign-in; there is no self-service staff registration or password reset in this scope.
• Assumption (required_inference). Guest booking/enquiry requests are anonymous; guests do not create accounts.
• Assumption (required_inference). Hotel presentation content (rooms, amenities, location) is application-owned data maintained by the hotel side; no separate content-management destination is accepted in this scope.
• Constraint (explicit). The website must be a 3D website.
• Constraint (explicit). The website must feel premium in presentation.
• Constraint (explicit, from creative direction). The generic indigo/blue-on-white SaaS template is forbidden for this project.
• Constraint (explicit, from creative direction). Readable text and controls stay whole at every viewport; imagery and decoration may be cropped but never cover readable text or controls.
• Constraint (explicit, from creative direction). No planning documents, success criteria or specs are presented or linked on the site.
• Default — not specified by user. No online payment, card capture, or third-party booking-engine integration is included; the booking/enquiry request is the accepted next step toward a stay.

12. Glossary

• SHVO — the hotel brand presented by this website.
• Parametric tower — the real-time 3D architectural subject that serves as the hero of the Landing page.
• Camera chip — the persistent bottom-left label naming the current viewpoint (Exterior / Lobby / Suites / Rooftop).
• Booking/enquiry request — a guest's submitted request containing name, contact details, preferred dates, party size and message.
• Provisioned staff account — a staff account created by the site owner before first sign-in; staff do not self-enrol.
• Follow-up — the staff action of recording that a guest request has been handled, updating its status.
• Section arc — the single asymmetric elliptical boundary between sections, per the creative direction.
• Reduced motion — the prefers-reduced-motion state in which the orbit freezes, parallax and scroll-scrub are disabled, and reveals become instant.