System Requirements Document for nova-maps

1. Introduction

nova-maps is the production-ready website for a local premium Dhaba / Indian food delivery brand operating in Ghaziabad, Uttar Pradesh, India. The product's intent is to convert hungry local visitors into direct delivery orders: the site must make visitors hungry, immediately communicate what the restaurant is known for, make the menu extremely easy to understand, make ordering extremely easy, push customers toward direct ordering, build trust that this is a genuine established local food brand, make the restaurant feel premium, hygienic, authentic, and reliable, and convert visitors into orders without unnecessary complexity.

The primary business model is direct food delivery. The site competes for attention in Ghaziabad against large QSR and delivery brands, and must communicate the strategic direction of "big-brand convenience, local-dhaba soul, better food, direct delivery" without copying that wording verbatim unless it fits the final brand copy.

The audience is hungry local families and young professionals in Ghaziabad who order on mobile, compare the brand against Swiggy, Zomato, and QSR chains, and want the feeling of a real kitchen with big-brand convenience. The customer should understand the website within 3–5 seconds, and the homepage must immediately answer: what do you serve, why should I trust you, where do you deliver, and how do I order.

The website must establish its own strong visual identity. It must not look like a generic restaurant template and must not look like a copy of KFC, McDonald's, Pizza Hut, Domino's, Haldiram's, Swiggy, or Zomato.

2. System Overview

nova-maps is a first-party, mobile-first restaurant website with a custom front end and a supporting order-submission backend. Its current delivery shape is custom UI owned by the application, with all accepted destinations publicly reachable and no account requirement.

The current product consists of an anonymous public entry surface (Landing) that presents the restaurant, its food offering, supported trust information, delivery context, and the direct-order path; a MENU destination for browsing dishes with available images, descriptions, and prices; a BESTSELLERS destination for supported crowd-favourite products and qualifying labels; an ABOUT destination carrying the supported kitchen story and why-choose-us information; a CONTACT destination for calling or messaging only when actual contact details are available; a VIEW MENU menu-entry destination exposed as the hero's secondary call to action; a Delivery Check destination for entering a location and checking supported delivery coverage; a CART destination for reviewing and managing selected dishes; an ORDER NOW destination for completing a direct food-delivery order; and a mobile ORDER destination corresponding to the mobile header order action.

Accepted behavior covers: the specified homepage hierarchy (header, hero, signature food section, bestsellers, direct order section, why choose us, food quality / kitchen story, delivery area); the desktop header navigation LOGO | MENU | BESTSELLERS | ABOUT | CONTACT | ORDER NOW; the mobile header navigation LOGO | CART | ORDER; a visually dominant ORDER NOW primary CTA; a single-photograph hero with the eyebrow "AUTHENTIC FLAVOURS • GHAZIABAD", a short headline, a short conversion-focused supporting line, ORDER NOW and VIEW MENU CTAs, and a subtle "DELIVERY AVAILABLE" indicator; a "WHAT WE'RE KNOWN FOR" signature section of 4–6 compact dish cards; a "THE CROWD FAVOURITES" bestseller section with labels only where supported; an "ORDER DIRECT. GET YOUR FOOD WITHOUT THE FUSS." direct-order section; a maximum-four-card why-choose-us section; a "FROM OUR KITCHEN TO YOUR DOOR" kitchen story; and a "DELIVERING ACROSS GHAZIABAD" delivery area with a location check when specific zones are unavailable.

Narrow exclusions that remain binding: no generic restaurant template look; no copying of the named competitor brands; no more than 10 navigation items; no generic restaurant interiors as the hero image; no invented restaurant-specific dishes; no fabricated ratings or sales numbers; no invented phone numbers, WhatsApp numbers, URLs, delivery promises, discounts, or offers; no unsupported claims such as "100% organic", "chemical free", "zero preservatives", or "healthiest food" unless explicitly provided; bestseller labels only where supported by actual menu/business information; CALL TO ORDER and WHATSAPP ORDER only when actual contact details are available; why-choose-us limited to 4 cards maximum; signature food section limited to 4–6 dishes; no invented locality names when actual delivery zones are unavailable; one primary and one secondary accent only; no excessive cursive or decorative Indian fonts or difficult-to-read typography; no overdone cultural decoration; and no overcrowded, flashy, cheap-looking, too-colorful, excessively animated, overly luxurious, corporate, generic SaaS, generic food-template, cluttered, or unnecessary-section design.

2a. Product Interpretation and Delivery Boundary

The product is a direct-ordering restaurant website, not a marketplace or aggregator. Every ordering path on the site leads to the restaurant's own direct order flow; the site does not route customers through third-party delivery apps. The ORDER NOW call to action is the dominant conversion element and is repeatedly accessible across the experience.

Delivery and access ownership: all accepted destinations are first-party application surfaces with no access requirement. The site is publicly browsable and anonymous; no account, login, or identity establishment is required or accepted for browsing, cart management, delivery checking, or order completion. The Google Maps link supplied by the user is treated as supplemental location context only; no place, business, or route details are confirmed or claimed from it, and it does not create a page, capability, or data source.

Current versus future boundary: everything specified in this document is current. No future-horizon requirements were accepted in the authoritative thread. Content integrity is a current hard boundary: menu, dish, pricing, contact, and business details may only come from verified, project-supplied facts, and where such facts are absent the corresponding UI must present a truthful empty or prompt state rather than invented content.

2b. Source Content Inventory

Not applicable. The single reference directive (https://maps.app.goo.gl/GwSC3U4kp6RD6YW8A) declares uses: ["domain_context"] with supplemental authority and is not a content_source; it could not be opened or previewed and the user did not confirm what it points to. No verified factual entities, collections, fields, values, dates, contacts, links, or media references are supplied by it, and none are invented here.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry surface. Presents the restaurant, its food offering, supported trust information, delivery context, and the direct-order path before any transactional work. Homepage hierarchy in order: header, hero, signature food section, bestsellers, direct order section, why choose us, food quality / kitchen story, delivery area.
• Header component: Desktop bar with LOGO | MENU | BESTSELLERS | ABOUT | CONTACT | ORDER NOW; mobile bar with LOGO | CART | ORDER. Clean single bar with a hairline bottom rule; on mobile it collapses to logo + cart count + a full-width red ORDER bar pinned under it. ORDER NOW is visually dominant. Navigation must not exceed 10 items.
• Hero component: One strong food photograph (close-up tandoor food, signature biryani, butter chicken, kebab, naan, thali, or signature dish) — never a generic restaurant interior. Eyebrow "AUTHENTIC FLAVOURS • GHAZIABAD"; a short main headline; a short conversion-focused supporting line; primary CTA ORDER NOW; secondary CTA VIEW MENU; subtle "DELIVERY AVAILABLE" indicator. Full-bleed split hero: left type panel, right edge-to-edge photograph bleeding off the top and right of the viewport. On mobile the photograph becomes a 52vh full-bleed band above the text panel.
• Signature food component: Heading "WHAT WE'RE KNOWN FOR"; 4–6 signature dish cards, each with image, dish name, short description, price, and add/order button. Compact and easy to scan, not huge cards.
• Bestsellers component: Heading "THE CROWD FAVOURITES"; bestselling products with subtle labels (BESTSELLER, CHEF'S PICK, MUST TRY, POPULAR) only where supported by actual menu/business information. Horizontal rail that scrolls continuously and pauses on hover; with reduced motion it wraps into two rows.
• Direct order component: "ORDER DIRECT. GET YOUR FOOD WITHOUT THE FUSS." with a dominant ORDER NOW CTA. Optional secondary CALL TO ORDER and WHATSAPP ORDER only when actual contact details are available. One full-bleed chilli-red panel with the headline and the ORDER NOW pill as the only other element.
• Why choose us component: Maximum 4 simple cards with clean icons and no giant paragraphs, using only claims supported by business information.
• Kitchen story component: Image plus heading "FROM OUR KITCHEN TO YOUR DOOR" and a short 2–4 line paragraph covering preparation, ingredients, cooking philosophy, freshness, and authenticity. No unsupported health claims.
• Delivery area component: Heading "DELIVERING ACROSS GHAZIABAD" with a simple visual/map-style section. When actual delivery zones are unavailable, presents "Enter your location to check delivery availability." and routes to Delivery Check. No invented locality names.
• Domain entities: Dish (name, description, price, image, optional supported label), signature dish selection, bestseller selection, supported business claim, delivery availability prompt.
• States: Loading — skeleton panels for dish rails and bestseller rail while menu data resolves. Empty — signature and bestseller rails show a truthful empty state when no verified menu data exists; delivery area shows the location prompt when no zones exist. Success — hero, sections, and CTAs render with verified content. Error — if menu data fails to load, rails show a retry affordance and the ORDER NOW path remains available. Recovery — retry reloads the affected section without losing page position.

MENU

• Information and state: Anonymous destination for browsing signature dishes and menu items with available images, descriptions, and prices. Menu is a two-column ruled list — dish name in the display serif, dotted leader, tabular price right-aligned — not a card wall. Category chips cross-fade their list.
• Primary actions: Browse dishes by category; open a dish's detail; add a dish to the cart; proceed to CART or ORDER NOW.
• Supporting actions: Navigate to BESTSELLERS, ABOUT, CONTACT; return to Landing.
• Domain entities: Dish (name, description, price, image), menu category, cart line item.
• Component responsibilities: Category chip row; ruled dish list; per-dish add control; price numerals in the primary accent with tabular figures.
• States: Loading — list skeleton per category. Empty — truthful empty state when no verified menu data exists for a category. Success — dishes render with verified name, description, price, and image where available. Error — category load failure shows a retry control. Recovery — retry reloads the category list.

BESTSELLERS

• Information and state: Anonymous destination for supported crowd-favourite products and qualifying bestseller labels. Heading "THE CROWD FAVOURITES".
• Primary actions: Browse bestseller products; add a bestseller to the cart; proceed to CART or ORDER NOW.
• Supporting actions: Navigate to MENU, ABOUT, CONTACT; return to Landing.
• Domain entities: Dish, supported label (BESTSELLER, CHEF'S PICK, MUST TRY, POPULAR), cart line item.
• Component responsibilities: Bestseller rail or grid; brass-outlined label chips rendered only where the label is supported by real menu data; per-item add control.
• States: Loading — rail skeleton. Empty — truthful empty state when no supported bestseller data exists; no fabricated labels or sales numbers. Success — supported bestsellers render with their qualifying labels. Error — load failure shows a retry control. Recovery — retry reloads the rail.

ABOUT

• Information and state: Anonymous destination containing the supported kitchen story and why-choose-us information. Carries the "FROM OUR KITCHEN TO YOUR DOOR" narrative and the maximum-four supported claim cards.
• Primary actions: Read the kitchen story; read supported claims; proceed to MENU or ORDER NOW.
• Supporting actions: Navigate to BESTSELLERS, CONTACT; return to Landing.
• Domain entities: Supported business claim, kitchen story content, kitchen/preparation image.
• Component responsibilities: Story panel with image; claim card set (maximum 4) with clean icons and no giant paragraphs.
• States: Loading — panel skeleton. Empty — claims and story render only from supported business information; unsupported claims are omitted rather than filled. Success — supported story and claims render. Error — image or content load failure degrades to text-only panel. Recovery — retry reloads the affected panel.

CONTACT

• Information and state: Anonymous contact destination for calling or messaging only when actual contact details are available. No invented phone numbers, WhatsApp numbers, or URLs.
• Primary actions: Call to order or message to order when verified contact details exist; otherwise present the direct-order path.
• Supporting actions: Navigate to MENU, BESTSELLERS, ABOUT; return to Landing.
• Domain entities: Verified contact detail (phone, WhatsApp), direct-order entry point.
• Component responsibilities: Contact detail block; call and message actions rendered only when the corresponding verified detail exists; fallback direct-order CTA.
• States: Loading — contact block skeleton. Empty — when no verified contact details exist, the destination presents the direct-order path instead of placeholder contact data. Success — verified contact actions render. Error — failed action surfaces a non-blocking notice. Recovery — the direct-order path remains available regardless of contact action outcome.

VIEW MENU

• Information and state: Anonymous menu-entry destination exposed as the hero's secondary call to action. Entry context is the hero's "VIEW MENU" affordance.
• Primary actions: Enter the menu browsing experience; select a category; proceed to MENU content.
• Supporting actions: Return to Landing; proceed to ORDER NOW.
• Domain entities: Menu category, dish.
• Component responsibilities: Menu entry presentation and hand-off into the MENU browsing context.
• States: Loading — entry skeleton. Empty — truthful empty state when no verified menu data exists. Success — entry renders and hands off to MENU. Error — load failure shows a retry control. Recovery — retry re-enters the menu context.

Delivery Check

• Information and state: Anonymous focused destination for entering a location and checking supported delivery coverage when specific delivery zones are unavailable. Presents "Enter your location to check delivery availability."
• Primary actions: Enter a location; submit the check; read the coverage result.
• Supporting actions: Proceed to MENU or ORDER NOW after a positive result; return to Landing.
• Domain entities: Entered location, supported delivery-zone data, coverage result.
• Component responsibilities: Location input; submit control; result panel distinguishing covered, not covered, and unknown outcomes.
• States: Loading — result panel pending state during the check. Empty — no location entered yet; prompt stands alone. Success — a clear answer on whether delivery reaches the entered location. Error — check failure shows a retry control and does not assert coverage. Recovery — retry re-runs the check; unknown results are stated as unknown rather than guessed. No locality names are invented.

CART

• Information and state: Anonymous destination for reviewing and managing selected dishes before direct ordering. Reachable from the mobile header CART action and from dish add controls.
• Primary actions: Review selected dishes; adjust quantity; remove a dish; proceed to ORDER NOW.
• Supporting actions: Return to MENU or BESTSELLERS to add more; return to Landing.
• Domain entities: Cart line item (dish, quantity, price), cart total.
• Component responsibilities: Line-item list with quantity controls and remove actions; price column with tabular figures; order-proceed control.
• States: Loading — cart skeleton while selections resolve. Empty — truthful empty cart state with a path back to MENU. Success — line items and total render correctly. Error — quantity or removal failure surfaces a non-blocking notice and preserves the prior cart state. Recovery — the customer can retry the action or continue to ORDER NOW with the last consistent cart state.

ORDER NOW

• Information and state: Anonymous primary destination for completing a direct food-delivery order. Ordering flow is minimal — no unnecessary fields or friction. No fabricated offers, time guarantees, or contact details.
• Primary actions: Confirm order contents; provide the delivery details required to complete the order; submit the order; receive order confirmation.
• Supporting actions: Return to CART to adjust; return to MENU to add more; use verified call or WhatsApp ordering when available.
• Domain entities: Order (line items, delivery details, total), order confirmation.
• Component responsibilities: Order summary; minimal delivery-detail form; submit control; confirmation panel; failure and retry handling.
• States: Loading — submission pending state with the submit control disabled against duplicate submission. Empty — no items to order; directs back to MENU. Success — order confirmation with the submitted order details. Error — submission failure preserves entered details and offers retry. Recovery — retry resubmits the same order without re-entry; the customer is never left without a next step.

ORDER

• Information and state: Anonymous mobile ordering destination corresponding to the mobile header order action. Entry context is the mobile header ORDER action.
• Primary actions: Enter the direct ordering flow; review the current cart; proceed to order completion.
• Supporting actions: Return to Landing; open CART; open MENU.
• Domain entities: Cart line item, order.
• Component responsibilities: Mobile ordering entry that hands off into the CART and ORDER NOW flow without duplicating their state.
• States: Loading — entry skeleton. Empty — no items selected; directs to MENU. Success — hands off into the ordering flow with current cart state intact. Error — load failure shows a retry control. Recovery — retry re-enters the ordering flow.

3. Functional Requirements

FR-1 — Direct-delivery restaurant website. As a Hungry Local Customer, I should land on a production-ready restaurant website for a local premium Dhaba / Indian food delivery brand in Ghaziabad, Uttar Pradesh, India, so that I can evaluate and order from a genuine local brand. Provenance: explicit. Lifecycle: initiator — visitor; trigger — opening the site; observable result — the Landing surface renders the restaurant, its food offering, trust information, delivery context, and the direct-order path; access — none; failure/recovery — if content fails to load, the page presents a retry affordance and the ORDER NOW path remains available; continuation — the visitor proceeds to MENU, BESTSELLERS, Delivery Check, or ORDER NOW.

FR-2 — Direct ordering as the primary conversion. As a Hungry Local Customer, I should see direct ordering pushed as the primary conversion throughout the site, so that I order directly from the restaurant rather than through an intermediary. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any page; observable result — ORDER NOW is visually dominant and repeatedly accessible; access — none; failure/recovery — if an ordering entry point fails, an alternative direct-order entry remains reachable; continuation — the visitor enters the ordering flow.

FR-3 — Distinctive visual identity. As a Hungry Local Customer, I should experience a site with its own strong visual identity that does not look like a generic restaurant template or a copy of KFC, McDonald's, Pizza Hut, Domino's, Haldiram's, Swiggy, or Zomato, so that I perceive a distinctive local brand. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any page; observable result — the visual language follows the Modern Indian Dhaba direction and shares no brand cues with the named chains; access — none; failure/recovery — not applicable to a static identity constraint; continuation — the visitor continues browsing.

FR-4 — Homepage answers four questions immediately. As a Hungry Local Customer, I should understand within 3–5 seconds what the restaurant serves, why I should trust it, where it delivers, and how to order, so that I can decide without effort. Provenance: explicit. Lifecycle: initiator — visitor; trigger — landing on the homepage; observable result — the four answers are present in the homepage hierarchy; access — none; failure/recovery — if a section is unavailable, the remaining answers still render; continuation — the visitor acts on the answer that matters to them.

FR-5 — Homepage hierarchy. As a Hungry Local Customer, I should encounter the homepage in the order header, hero, signature food section, bestsellers, direct order section, why choose us, food quality / kitchen story, delivery area, so that the page reads as a deliberate sequence. Provenance: explicit. Lifecycle: initiator — visitor; trigger — scrolling the homepage; observable result — sections appear in the specified order; access — none; failure/recovery — a failed section does not reorder or remove the others; continuation — the visitor reaches the delivery area and the ordering path.

FR-6 — Desktop header navigation. As a Hungry Local Customer on desktop, I should see LOGO | MENU | BESTSELLERS | ABOUT | CONTACT | ORDER NOW in the header, so that I can reach every essential path. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing the header on desktop; observable result — the six specified items render in order; access — none; failure/recovery — if a destination is unavailable, the remaining items stay usable; continuation — the visitor navigates to the chosen destination.

FR-7 — Mobile header navigation. As a Hungry Local Customer on mobile, I should see LOGO | CART | ORDER in the header, so that the mobile header is extremely usable. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing the header on mobile; observable result — logo, cart, and order actions render and remain reachable; access — none; failure/recovery — if the cart is empty, the CART action still opens the truthful empty cart state; continuation — the visitor opens the cart or enters ordering.

FR-8 — Dominant ORDER NOW CTA and navigation limit. As a Hungry Local Customer, I should see ORDER NOW as the visually dominant primary CTA, with no more than 10 navigation items, so that the ordering path is unmistakable. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing the header or any CTA region; observable result — ORDER NOW is the most prominent control and navigation stays within the item limit; access — none; failure/recovery — not applicable; continuation — the visitor activates ORDER NOW.

FR-9 — Hero photograph. As a Hungry Local Customer, I should see one strong food photograph — close-up tandoor food, signature biryani, butter chicken, kebab, naan, thali, or the signature dish — and never a generic restaurant interior, so that the hero makes me hungry. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing the hero; observable result — a single food photograph renders as the hero image; access — none; failure/recovery — if the photograph fails to load, the hero text and CTAs remain fully usable; continuation — the visitor reads the headline and acts on a CTA.

FR-10 — Hero content. As a Hungry Local Customer, I should see the eyebrow "AUTHENTIC FLAVOURS • GHAZIABAD", a short main headline, a short conversion-focused supporting line, primary CTA ORDER NOW, secondary CTA VIEW MENU, and a subtle "DELIVERY AVAILABLE" indicator, so that the hero immediately communicates delivery. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing the hero; observable result — all six hero elements render; access — none; failure/recovery — if the supporting line or indicator fails to render, the headline and CTAs remain; continuation — the visitor activates ORDER NOW or VIEW MENU.

FR-11 — Signature food section. As a Hungry Local Customer, I should see the heading "WHAT WE'RE KNOWN FOR" with 4–6 signature dishes as compact, highly visual, easy-to-scan cards each showing image, dish name, short description, price, and an add/order button, so that I can quickly see what the restaurant is known for. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the signature section; observable result — 4–6 compact dish cards render with all five elements; access — none; failure/recovery — if menu data is unavailable, the section shows a truthful empty state rather than invented dishes; continuation — the visitor adds a dish or opens the menu.

FR-12 — Bestsellers section. As a Hungry Local Customer, I should see "THE CROWD FAVOURITES" displaying bestselling products with subtle labels (BESTSELLER, CHEF'S PICK, MUST TRY, POPULAR) only where supported by actual menu/business information, so that I can trust the labels I see. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the bestsellers section; observable result — supported bestsellers render with only their qualifying labels; access — none; failure/recovery — if no supported bestseller data exists, the section shows a truthful empty state and no fabricated ratings or sales numbers; continuation — the visitor adds a bestseller or opens BESTSELLERS.

FR-13 — Direct order section. As a Hungry Local Customer, I should see the visually strong section "ORDER DIRECT. GET YOUR FOOD WITHOUT THE FUSS." with a dominant ORDER NOW CTA, so that direct ordering is the obvious conversion. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the direct order section; observable result — the section renders with its headline and dominant CTA; access — none; failure/recovery — if the section fails to render, ORDER NOW remains reachable from the header; continuation — the visitor activates ORDER NOW.

FR-14 — Optional call and WhatsApp ordering. As a Hungry Local Customer, I should see CALL TO ORDER and WHATSAPP ORDER only when actual contact details are available, so that I am never given a fabricated contact path. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the direct order or contact surface; observable result — call and WhatsApp actions render only when the corresponding verified detail exists; access — none; failure/recovery — if a contact action fails, the direct-order path remains available; continuation — the visitor calls, messages, or orders directly.

FR-15 — Why choose us section. As a Hungry Local Customer, I should see a maximum of 4 simple cards with clean icons and no giant paragraphs, using only claims supported by business information, so that I can absorb the reasons quickly. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the why-choose-us section; observable result — at most 4 supported claim cards render; access — none; failure/recovery — unsupported claims are omitted rather than filled; continuation — the visitor continues to the kitchen story or ordering.

FR-16 — Kitchen story section. As a Hungry Local Customer, I should see an image, the heading "FROM OUR KITCHEN TO YOUR DOOR", and a short 2–4 line paragraph covering preparation, ingredients, cooking philosophy, freshness, and authenticity, so that I trust the kitchen. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the kitchen story; observable result — the image, heading, and short paragraph render; access — none; failure/recovery — if the image fails, the text remains; unsupported claims such as "100% organic", "chemical free", "zero preservatives", or "healthiest food" are never made unless explicitly provided; continuation — the visitor continues to the delivery area or ordering.

FR-17 — Delivery area section. As a Delivery Availability Checker, I should see "DELIVERING ACROSS GHAZIABAD" with a simple visual/map-style section showing Ghaziabad, nearby areas, and delivery availability, so that I understand the delivery footprint. Provenance: explicit. Lifecycle: initiator — visitor; trigger — reaching the delivery area; observable result — the heading and simple visual render; access — none; failure/recovery — if the visual fails, the heading and location prompt remain; continuation — the visitor checks their location or proceeds to order.

FR-18 — Location check when zones are unavailable. As a Delivery Availability Checker, I should be given "Enter your location to check delivery availability." instead of invented locality names when actual delivery zones are unavailable, so that I get a truthful answer about my area. Provenance: explicit. Lifecycle: initiator — visitor; participant response — the Delivery Check surface returns a coverage result to the visitor; trigger — entering a location and submitting; observable result — a clear answer on whether delivery reaches the entered location; access — none; failure/recovery — a failed check shows a retry control and never asserts coverage; unknown results are stated as unknown; continuation — the visitor proceeds to order on a positive result or stops on a negative one.

FR-19 — Use actual menu data and images. As a Hungry Local Customer, I should see actual food images and menu data from the source project where available, with no invented restaurant-specific dishes, so that everything I see is real. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any dish surface; observable result — dish names, descriptions, prices, and images come only from verified project data; access — none; failure/recovery — where verified data is absent, the surface shows a truthful empty state; continuation — the visitor browses or orders from verified items.

FR-20 — No fabricated ratings or sales numbers. As a Hungry Local Customer, I should never be shown fabricated ratings or sales numbers, so that the trust signals I see are genuine. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any trust or bestseller surface; observable result — no invented rating or sales figure appears; access — none; failure/recovery — absent data results in omission, not fabrication; continuation — the visitor relies on supported information only.

FR-21 — No invented contact details, URLs, promises, discounts, or offers. As a Hungry Local Customer, I should never be shown invented phone numbers, WhatsApp numbers, URLs, delivery promises, discounts, or offers, so that I am not misled. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any contact, delivery, or promotional surface; observable result — only verified contact details, URLs, and commitments appear; access — none; failure/recovery — absent details result in omission or a truthful prompt; continuation — the visitor uses only verified paths.

FR-22 — No unsupported health claims. As a Hungry Local Customer, I should never see unsupported claims such as "100% organic", "chemical free", "zero preservatives", or "healthiest food" unless explicitly provided, so that the brand's claims remain honest. Provenance: explicit. Lifecycle: initiator — visitor; trigger — viewing any claim surface; observable result — only supported claims render; access — none; failure/recovery — unsupported claims are omitted; continuation — the visitor continues browsing.

FR-23 — Menu browsing. As a Hungry Local Customer, I should browse signature dishes and menu items with available images, descriptions, and prices on MENU, so that I can decide what to order. Provenance: explicit. Lifecycle: initiator — visitor; trigger — opening MENU or VIEW MENU; observable result — dishes render with their available details; access — none; failure/recovery — a category load failure shows a retry control; continuation — the visitor adds a dish to the cart or proceeds to order.

FR-24 — Cart review and management. As a Hungry Local Customer, I should review and manage selected dishes in CART before ordering, so that I can confirm my order. Provenance: explicit. Lifecycle: initiator — visitor; trigger — opening CART from the mobile header or after adding a dish; observable result — line items, quantities, and total render; access — none; failure/recovery — a quantity or removal failure surfaces a non-blocking notice and preserves the prior cart state; continuation — the visitor proceeds to ORDER NOW or returns to the menu.

FR-25 — Direct order completion. As a Hungry Local Customer, I should complete a direct food-delivery order through ORDER NOW with a minimal flow and no unnecessary fields or friction, so that ordering is extremely easy. Provenance: explicit. Lifecycle: initiator — visitor; participant response — the order is submitted and the customer receives an order confirmation; trigger — activating ORDER NOW with items in the cart; observable result — the order is submitted and a confirmation with the submitted order details is shown; access — none; failure/recovery — a submission failure preserves entered details and offers retry without re-entry; continuation — the customer has a confirmed order or a clear retry path.

FR-26 — Mobile ordering entry. As a Hungry Local Customer on mobile, I should enter the direct ordering flow from the mobile header ORDER action, so that ordering is reachable in one tap. Provenance: explicit. Lifecycle: initiator — visitor; trigger — activating ORDER in the mobile header; observable result — the ordering flow opens with the current cart state intact; access — none; failure/recovery — a load failure shows a retry control; continuation — the visitor reviews the cart and completes the order.

FR-27 — Verified menu data prerequisite. As a Hungry Local Customer, I should see dish names, descriptions, prices, images, and bestseller labels only when verified menu data is available, so that no dish or label is invented. Provenance: required_inference. Lifecycle: initiator — visitor; trigger — any dish or label surface rendering; observable result — content renders only from verified data, otherwise a truthful empty state; access — none; failure/recovery — missing data produces an empty state, never fabricated content; continuation — the visitor browses available verified items.

FR-28 — Direct ordering implementation and order-submission backend. As a Hungry Local Customer, I should have a working direct ordering implementation and order-submission backend behind ORDER NOW and the ORDER flows, so that my order actually reaches the restaurant. Provenance: required_inference. Lifecycle: initiator — visitor; participant response — the restaurant receives the submitted order; trigger — order submission; observable result — the order is accepted and confirmed to the customer; access — none; failure/recovery — backend failure surfaces a retry path that preserves the order details; continuation — the customer's order is placed or retried.

FR-29 — Delivery availability data or location-check mechanism. As a Delivery Availability Checker, I should have supported delivery-zone data or a location-checking mechanism behind the delivery area, so that coverage answers are real and no locality coverage is invented. Provenance: required_inference. Lifecycle: initiator — visitor; participant response — the check returns a coverage result; trigger — submitting a location; observable result — a covered, not-covered, or unknown answer; access — none; failure/recovery — check failure shows a retry control and never asserts coverage; continuation — the visitor orders or stops based on the answer.

FR-30 — Verified contact details prerequisite. As a Hungry Local Customer, I should have verified phone or WhatsApp contact details in place before call-to-order or WhatsApp-order actions are enabled, so that those actions never point to invented numbers. Provenance: required_inference. Lifecycle: initiator — visitor; trigger — the contact surface rendering; observable result — call and WhatsApp actions appear only with verified details; access — none; failure/recovery — absent details mean the actions are not shown and the direct-order path is offered instead; continuation — the visitor orders directly.

4. User Personas

Hungry Local Customer

A Ghaziabad resident deciding what to eat who lands on the site, quickly grasps what the dhaba serves, browses signature dishes and bestsellers with prices, and places a direct delivery order via the ORDER NOW flow. Their recurring responsibility is choosing dishes and completing an order without friction, and their success is receiving hot, freshly prepared North Indian food delivered to their location.

Product context: They arrive hungry, usually on a mobile device, and compare the brand against Swiggy, Zomato, and large QSR chains. They decide fast and abandon anything that feels cluttered, slow, or generic.

Primary goal: Understand what the restaurant serves and place a direct delivery order with minimal effort.

Distinct accepted responsibilities: Reading the hero to learn what the restaurant is known for and that delivery is available; scanning the signature food section and bestsellers to choose dishes; adding dishes to the cart; reviewing the cart; completing the order through ORDER NOW; optionally using verified call or WhatsApp ordering when those details exist.

Relevant inputs or decisions: Which dishes to order; whether the price and description are clear enough to commit; whether to order directly rather than through an aggregator; whether to add more items before submitting.

Interactions with other accepted participants: Hands off to the restaurant's order-submission backend when the order is placed, and receives an order confirmation in return. Shares the delivery-area answer with the Delivery Availability Checker's concern when their own locality is uncertain.

Observable success: A confirmed direct order containing the dishes they chose, with the order details they submitted.

What makes this role's work different: This persona carries the full conversion responsibility — from first impression through dish selection to order submission — and is the only persona whose success depends on the complete ordering lifecycle.

Repeat Direct-Order Regular

An existing customer who already trusts the brand and returns to reorder favourites, checking the menu and bestsellers and using the cart and direct ordering path rather than a third-party app. Their recurring responsibility is fast reordering and confirming delivery availability for their area, and their success is a quick repeat order with the same reliable quality.

Product context: They already know the food and skip the persuasion. They want the shortest path from arrival to a placed order and will not tolerate re-reading marketing content or re-entering unnecessary information.

Primary goal: Reorder known favourites quickly and confirm delivery still reaches their area.

Distinct accepted responsibilities: Going straight to MENU or BESTSELLERS; re-adding known dishes; confirming delivery availability for their locality; completing the order through ORDER NOW or the mobile ORDER action.

Relevant inputs or decisions: Which favourites to reorder; whether delivery coverage still applies to their address; whether to adjust quantities before submitting.

Interactions with other accepted participants: Hands off to the restaurant's order-submission backend on submission and receives confirmation. Uses the same delivery-coverage answer the Delivery Availability Checker relies on.

Observable success: A repeat order placed in far fewer steps than a first-time order, with the same dishes as before.

What makes this role's work different: This persona's work is speed and continuity of a known order rather than discovery; their value comes from the site not forcing them back through the first-time journey.

Delivery Availability Checker

A visitor who is unsure whether the dhaba delivers to their locality and uses the delivery area section to check availability by entering their location before committing to order. Their recurring responsibility is verifying coverage for their address, and their success is a clear answer on whether delivery reaches them so they can proceed to order or not.

Product context: They are interested but blocked by uncertainty about coverage. They will not place an order they believe may not arrive, and they will not accept a vague or invented answer.

Primary goal: Get a clear, truthful answer on whether delivery reaches their location.

Distinct accepted responsibilities: Reading the "DELIVERING ACROSS GHAZIABAD" section; entering their location; submitting the check; interpreting a covered, not-covered, or unknown result; proceeding to order or stopping.

Relevant inputs or decisions: Their own location; whether the returned answer is definitive; whether to proceed to ordering or leave.

Interactions with other accepted participants: Their check result determines whether the Hungry Local Customer and Repeat Direct-Order Regular journeys can proceed for that address; the check itself is answered by the delivery-availability mechanism.

Observable success: A definitive answer about their location, with no invented locality names presented as fact.

What makes this role's work different: This persona's work ends at a coverage decision rather than an order; their success is measured by the clarity and honesty of the answer, not by a transaction.

5. Core User Flows

Flow 1 — First-time visitor discovers the restaurant and orders directly (Hungry Local Customer)

1. The customer opens the site on a mobile device and lands on Landing.
2. The hero renders one strong food photograph, the eyebrow "AUTHENTIC FLAVOURS • GHAZIABAD", a short headline, a short conversion-focused supporting line, the ORDER NOW and VIEW MENU CTAs, and the subtle "DELIVERY AVAILABLE" indicator. Within 3–5 seconds the customer knows what is served, that delivery is available, and how to order.
3. The customer scrolls through the homepage in order: signature food section ("WHAT WE'RE KNOWN FOR"), bestsellers ("THE CROWD FAVOURITES"), direct order section ("ORDER DIRECT. GET YOUR FOOD WITHOUT THE FUSS."), why choose us, kitchen story ("FROM OUR KITCHEN TO YOUR DOOR"), and delivery area ("DELIVERING ACROSS GHAZIABAD").
4. In the signature food section the customer scans 4–6 compact dish cards, each showing image, dish name, short description, price, and an add/order button, and adds a dish to the cart.
5. The customer continues to the bestsellers section and adds a labelled crowd favourite, seeing only labels supported by actual menu data.
6. The customer opens CART from the mobile header and reviews line items, quantities, and the total.
7. The customer activates ORDER NOW and reaches ORDER NOW, where the order summary and a minimal delivery-detail form appear with no unnecessary fields.
8. The customer submits the order. The order-submission backend accepts it and the customer receives an order confirmation showing the submitted order details.
9. Failure and recovery: if submission fails, the entered details are preserved and a retry control is offered; retry resubmits the same order without re-entry.
10. Continuation: the customer has a confirmed direct order, or a clear retry path, and can return to MENU to add more.

Flow 2 — Returning customer reorders favourites (Repeat Direct-Order Regular)

1. The customer returns to the site and goes directly to MENU or BESTSELLERS without re-reading the homepage.
2. On MENU the customer browses the ruled two-column dish list with dotted leaders and right-aligned tabular prices, and re-adds known favourites.
3. On BESTSELLERS the customer confirms a supported crowd favourite and adds it.
4. The customer opens CART and adjusts quantities or removes an item.
5. The customer activates ORDER NOW from the header or the direct order section and reaches ORDER NOW.
6. The customer submits the order; the order-submission backend accepts it and confirmation is shown.
7. Failure and recovery: if a quantity change or removal fails, a non-blocking notice appears and the prior cart state is preserved so the customer can retry or continue.
8. Continuation: the customer completes the repeat order in far fewer steps than a first-time order.

Flow 3 — Mobile one-tap ordering entry (Hungry Local Customer / Repeat Direct-Order Regular)

1. The customer on mobile sees the header LOGO | CART | ORDER with the full-width red ORDER bar pinned beneath it.
2. The customer activates ORDER and reaches ORDER.
3. The ordering flow opens with the current cart state intact; if the cart is empty, the customer is directed to MENU.
4. The customer reviews the cart and proceeds into ORDER NOW to complete the order.
5. Failure and recovery: if the ordering entry fails to load, a retry control is shown and the header ORDER action remains available.
6. Continuation: the customer completes the order or returns to MENU to add items.

Flow 4 — Checking delivery availability before ordering (Delivery Availability Checker)

1. The customer reaches the delivery area section on Landing with the heading "DELIVERING ACROSS GHAZIABAD" and a simple visual/map-style section.
2. Because specific delivery zones are unavailable, the section presents "Enter your location to check delivery availability." and no locality names are invented.
3. The customer opens Delivery Check and enters their location.
4. The customer submits the check. The delivery-availability mechanism returns a covered, not-covered, or unknown result.
5. Failure and recovery: if the check fails, a retry control appears and no coverage is asserted; an unknown result is stated as unknown rather than guessed.
6. Continuation: on a covered result the customer proceeds to MENU or ORDER NOW; on a not-covered or unknown result the customer stops or seeks another path, and the direct-order path remains available.

Flow 5 — Contacting the restaurant to order (Hungry Local Customer)

1. The customer opens CONTACT from the desktop header.
2. If verified phone or WhatsApp contact details exist, CALL TO ORDER and WHATSAPP ORDER actions render; if they do not exist, the destination presents the direct-order path instead of placeholder contact data.
3. The customer activates a verified contact action, or proceeds to ORDER NOW.
4. Failure and recovery: if a contact action fails, a non-blocking notice appears and the direct-order path remains available.
5. Continuation: the customer places the order by phone, by message, or directly through ORDER NOW.

Flow 6 — Learning why to trust the restaurant (Hungry Local Customer)

1. The customer opens ABOUT from the desktop header.
2. The customer reads the "FROM OUR KITCHEN TO YOUR DOOR" story — a short 2–4 line paragraph covering preparation, ingredients, cooking philosophy, freshness, and authenticity — alongside a kitchen or preparation image.
3. The customer reads at most 4 why-choose-us cards with clean icons and no giant paragraphs, containing only claims supported by business information.
4. Failure and recovery: if the image fails to load, the text panel remains readable; unsupported claims are omitted rather than filled.
5. Continuation: the customer proceeds to MENU or ORDER NOW.

Flow 7 — Entering the menu from the hero (Hungry Local Customer)

1. The customer on Landing activates the hero's secondary CTA VIEW MENU.
2. The customer reaches VIEW MENU, the menu-entry destination, and selects a category.
3. The menu browsing context opens with the selected category's dishes.
4. Failure and recovery: if menu data is unavailable, a truthful empty state is shown with a retry control rather than invented dishes.
5. Continuation: the customer adds a dish to the cart and proceeds to CART or ORDER NOW.

6. Visuals Colors and Theme

The creative direction is authoritative for this section: Warm mid-century modernism for a dhaba with a world-class digital face, with Charles & Ray Eames as the muse. The headline idea is joyful colour held inside strict order — honest materials and mid-century harmonies (walnut, cream, mustard, teal, tomato) that read as warm Indian spice tones without becoming kitsch, arranged as a gallery-like sequence of panels that keeps a very long homepage calm. This gives the site an identity no QSR chain owns.

Colour tokens — light mode

Ratio target: 70% cream/ivory, 18% ink, 8% red, 4% brass/teal/mustard. One primary accent (chilli red) and one secondary accent (muted brass/saffron) only; deep teal and mustard appear only as small coded chips, never as large fields.

Typography

• Headings: Fraunces, at high optical size with the SOFT and WONK axes pushed slightly on — a warm, slightly inked editorial serif with visible thick/thin contrast, like a hand-set restaurant sign. Weights 600–700 for display, 500 for section headings; tracking −0.02em on display, 0 on subheads. Sentence case for headlines, never all-caps display, with the occasional italic word in chilli red for emphasis.
• Body: Karla.
• Eyebrow labels: Karla 700, uppercase, 0.16em tracking, brass.
• Type scale: 1.333 modular, mobile → desktop via clamp: display 44px → 104px, section heading 30px → 56px, dish name 19px → 24px, lead 18px → 22px, body 16px → 17px, eyebrow/label 12px → 13px, price numerals 20px → 28px with tabular figures.

Shape language: Organic-modern — generous 18–24px radii on cards and panels, pill CTAs, and one recurring "leaf-and-grain" arc motif drawn as a 1.5px brass hairline that curves under section headings and reappears as the top edge of the order panel. Hard edges are kept for full-bleed colour blocks and the horizontal rules that separate menu rows, so the page reads as panels on a table rather than a grid of rounded boxes. No blobs, no glass, no neon.

Layout and spacing rhythm: Gallery-like vertical sequence of wide panels on a cream ground. A 12-column grid with a 1120px max measure and 24px gutters; asymmetric splits (7/5, 5/7) alternate down the page so no two consecutive sections share a skeleton. The menu is a two-column ruled list — dish name in Fraunces, dotted leader, tabular price right-aligned — not a card wall. Cards appear only in the signature and bestseller rails and are compact (image 4:3 on top, three lines of text, price and ADD on one baseline). The header is a single 72px bar with a hairline bottom rule; on mobile it collapses to logo + cart count + a full-width red ORDER bar pinned under it.

Imagery style: Warm, natural-light food photography on cream or dark walnut surfaces — a single hero frame of tandoor food pulled hot from the oven with visible char and steam; macro details of spices in brass bowls, dough being slapped, a hand tearing naan. Photographs are cropped hard and bled off the panel edge on one side, never floated inside a rounded box with a drop shadow. A small set of hand-drawn 1.5px brass line motifs — a wheat stalk, a chilli, a rolling pin, a tandoor arc — used as section punctuation, never as wallpaper. No stock people, no interiors as the hero, no gradient blobs.

Explicitly avoided: centred headline + subtext + blue button + gradient blob hero; a grid of identical hover-lift product cards for the full menu; Swiggy/Zomato-style red-on-white app chrome or KFC/Domino's brand cues; glassmorphism, neon glows, or gradient meshes; overdone Indian decoration such as paisley wallpaper, mandala borders, cursive scripts, or Devanagari used as ornament; stock photography of restaurant interiors, smiling models, or generic butter chicken on white; fabricated ratings, delivery times, phone numbers, WhatsApp links, discounts, or locality names; Inter, Roboto, Poppins, system-ui, or any blue-indigo accent on a white ground. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The split tandoor hero. The public entry opens as a full-bleed split, not a centred stack. The left 58% is a deep walnut-to-cream type panel: the eyebrow "AUTHENTIC FLAVOURS • GHAZIABAD" set in brass caps, then a Fraunces display headline at clamp(44px, 8vw, 104px) with tight leading — "Straight from the tandoor, still smoking at your door." — where the words "still smoking" are set in chilli-red italic. Beneath it a one-line Karla lead and two CTAs on the same baseline: a solid chilli-red pill ORDER NOW and a brass-outlined VIEW MENU. Under the CTAs, a hairline rule with a small pulsing brass dot and "DELIVERY AVAILABLE ACROSS GHAZIABAD". The right 42% is one tall, edge-to-edge photograph of tandoor food, cropped so the frame bleeds off the top and right of the viewport, with a thin brass hairline arcing across its lower third as the only decoration. On mobile the photograph becomes a 52vh full-bleed band above the text panel, and the headline drops to 44px.

The concept recomposes only accepted content and controls: the hero photograph, the eyebrow, the headline, the supporting line, the ORDER NOW and VIEW MENU CTAs, and the delivery indicator. It introduces no new behaviour, page, or destination. The CTA is pinned to the type panel's baseline rather than centred, which is what makes the entry read as a printed dhaba sign rather than a template hero.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: One tall, edge-to-edge photograph of tandoor food pulled hot from the oven, with visible char and steam, cropped so the frame bleeds off the top and right of the viewport.
• Input → transformation → outcome thesis: On load, the hero photograph performs a slow 6s scale from 1.04 to 1.00 while the type panel's eyebrow, headline, lead, and CTAs settle into place; the outcome is a hero that feels like a hot dish being set down in front of the visitor, with the ORDER NOW pill resting as the calmest, most solid element on the panel.
• Motion vocabulary: Restrained, film-like. Section panels rise 16px and fade over 420ms with an ease-out-quart curve as they enter the viewport, one panel at a time, never staggered more than 80ms. Menu category chips cross-fade their list with a 180ms opacity swap. Hover on a dish card lifts it 2px and swaps the image to a closer crop. The bestseller rail scrolls continuously and pauses on hover. The brass dot beside "DELIVERY AVAILABLE ACROSS GHAZIABAD" pulses slowly.
• Composed first frame: The split hero at rest — walnut-to-cream type panel on the left with the brass eyebrow, the Fraunces headline with "still smoking" in chilli-red italic, the lead line, the red ORDER NOW pill and brass-outlined VIEW MENU on one baseline, the hairline rule and pulsing brass dot beneath; the tandoor photograph filling the right 42% and bleeding off the top and right edges, with the brass arc crossing its lower third.
• Reduced-motion state: With prefers-reduced-motion, all of this resolves to static — the hero photograph holds at scale 1.00, panels appear without rise or fade, the brass dot stops pulsing, and the horizontal bestseller rail wraps into two rows or becomes a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.

9. Non-Functional Requirements

NFR-1 — Visual comprehension in 3–5 seconds. The homepage must communicate what is served, why to trust the brand, where it delivers, and how to order within 3–5 seconds of arrival. Provenance: explicit. Rationale: the brief states the customer should understand the website within 3–5 seconds and that the homepage must answer these four questions immediately.

NFR-2 — Mobile-first usability. The mobile header must be extremely usable, collapsing to logo + cart count + a full-width red ORDER bar pinned beneath it, and the hero photograph must become a 52vh full-bleed band above the text panel with the headline at 44px. Provenance: explicit. Rationale: the brief requires an extremely usable mobile header and specifies the mobile hero behaviour.

NFR-3 — Navigation restraint. Navigation must not exceed 10 items, and the desktop header is limited to LOGO | MENU | BESTSELLERS | ABOUT | CONTACT | ORDER NOW while the mobile header is limited to LOGO | CART | ORDER. Provenance: explicit. Rationale: the brief forbids 10+ navigation items and fixes both header compositions.

NFR-4 — Content integrity. Menu, dish, pricing, contact, and business details must come only from verified, project-supplied facts; no menu, dish, pricing, contact, or business details may be invented. Provenance: explicit. Rationale: the brief's content-integrity constraint and the prohibition on inventing restaurant-specific dishes, contact details, URLs, promises, discounts, and offers.

NFR-5 — No fabricated trust signals. Ratings, sales numbers, and bestseller labels must never be fabricated; labels appear only where supported by actual menu/business information. Provenance: explicit. Rationale: the brief forbids fabricated ratings and sales numbers and restricts labels to supported cases.

NFR-6 — Claim honesty. Unsupported claims such as "100% organic", "chemical free", "zero preservatives", or "healthiest food" must not appear unless explicitly provided. Provenance: explicit. Rationale: the brief's kitchen-story constraint.

NFR-7 — Delivery-area honesty. When actual delivery zones are unavailable, no locality names may be invented; the section must present "Enter your location to check delivery availability." Provenance: explicit. Rationale: the brief's delivery-area constraint.

NFR-8 — Restrained motion. Motion must be restrained and film-like, never excessive; with prefers-reduced-motion all motion resolves to static and horizontal rails wrap into rows or become horizontally scrollable. Provenance: explicit. Rationale: the brief forbids excessive animation and the creative direction specifies the reduced-motion resolution.

NFR-9 — Readable text and controls stay whole. 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. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. Provenance: explicit. Rationale: the creative direction's readability rule, which takes precedence where a direction asks readable text or a control to be cropped.

NFR-10 — Minimal ordering friction. The ordering flow must be minimal, with no unnecessary fields or friction, and must not present fabricated offers or time guarantees. Provenance: explicit. Rationale: the brief's ordering-UX constraint.

NFR-11 — Order-submission reliability. The order-submission backend must accept submitted orders and return a confirmation; on failure it must preserve entered details and offer retry without re-entry. Provenance: required_inference. Rationale: required to make the accepted direct-ordering journey executable and recoverable.

NFR-12 — Delivery-check truthfulness. The delivery-availability mechanism must return a covered, not-covered, or unknown result and must never assert coverage it cannot support. Provenance: required_inference. Rationale: required to make the accepted delivery-check journey truthful and executable.

10. Tech Stack

• Frontend: React, built as a mobile-first responsive web application. The visual system uses Fraunces and Karla as specified in the creative direction, with clamp()-based fluid type and CSS custom properties for the colour tokens.
• Backend: Python with FastAPI, providing the direct ordering implementation and order-submission endpoint behind ORDER NOW and the ORDER flows, and the delivery-availability check behind Delivery Check.
• Storage: A persistent store for menu data (dishes, descriptions, prices, images, supported labels), supported business claims, verified contact details, supported delivery-zone data, and submitted orders. The specific engine is not specified by the user and should be chosen to fit the deployment; a relational store is appropriate for the menu, zone, and order records.
• Containerization: Docker and docker-compose for local development and deployment packaging.
• Kubernetes: Not required by the source. Include only if the chosen deployment environment requires orchestration.

No source-specified technology choices were overridden; the stack above preserves the user's stated product context and adds only what the accepted direct-ordering and delivery-check journeys require.

11. Assumptions and Constraints

Assumptions

• A-1: Verified menu data (dish names, descriptions, prices, images) will be supplied by the project before dish content is displayed. Until then, dish surfaces show truthful empty states. Label: required inference.
• A-2: A direct ordering implementation and order-submission backend will be available to serve the ORDER NOW and ORDER flows. Label: required inference.
• A-3: Supported delivery-zone data or a location-checking mechanism will be available for the delivery area; where it is not, the location prompt is shown and no locality names are invented. Label: required inference.
• A-4: Verified phone or WhatsApp contact details will be supplied before CALL TO ORDER or WHATSAPP ORDER is enabled; until then those actions are not shown. Label: required inference.
• A-5: The Google Maps link supplied by the user remains supplemental location context only; no place, business, or route details are derived from it. Label: explicit source boundary.
• A-6: The restaurant's brand name, logo, and final brand copy will be supplied; the strategic line "Big-brand convenience. Local-dhaba soul. Better food. Direct delivery." is direction only and is not used verbatim unless it fits the final brand copy. Label: explicit source boundary.

Constraints

• C-1: The website must not look like a generic restaurant template and must not copy KFC, McDonald's, Pizza Hut, Domino's, Haldiram's, Swiggy, or Zomato.
• C-2: Do not create 10+ navigation items.
• C-3: Do not use generic restaurant interiors as the hero image.
• C-4: Do not invent restaurant-specific dishes; use actual menu data from the source project if it exists.
• C-5: Do not fabricate ratings or sales numbers.
• C-6: Never invent phone numbers, WhatsApp numbers, URLs, delivery promises, discounts, or offers.
• C-7: Do not make unsupported claims such as "100% organic", "chemical free", "zero preservatives", or "healthiest food" unless explicitly provided.
• C-8: Only use bestseller labels when supported by actual menu/business information.
• C-9: Only implement CALL TO ORDER and WHATSAPP ORDER if actual contact details are available.
• C-10: The why-choose-us section is limited to 4 cards maximum.
• C-11: The signature food section shows 4–6 signature dishes.
• C-12: If actual delivery zones are unavailable, do not invent locality names; instead provide "Enter your location to check delivery availability."
• C-13: Use one primary accent and one secondary accent; do not use all colors everywhere.
• C-14: Avoid excessive cursive fonts, decorative Indian fonts, and difficult-to-read typography.
• C-15: Do not overdo cultural decoration; modern first, Indian soul second.
• C-16: The design must not be overcrowded, flashy, cheap-looking, too colorful, excessively animated, overly luxurious, corporate, generic SaaS, generic food-template, cluttered, or full of unnecessary sections.
• C-17: The generic indigo/blue-on-white SaaS template is forbidden for this project.

Presentation and technology defaults (not specified by the user)

• [Default — not specified by user] The specific database engine, hosting provider, and deployment topology beyond Docker/docker-compose.
• [Default — not specified by user] The exact image asset pipeline and CDN for food photography.
• [Default — not specified by user] The specific analytics or conversion-tracking tooling.

12. Glossary

• Direct ordering: Placing a food order through the restaurant's own website and order-submission backend, rather than through a third-party delivery aggregator.
• Dhaba: A local Indian roadside-style eatery; here, a premium local North Indian food brand in Ghaziabad with a direct-delivery business model.
• Signature dish: One of the 4–6 dishes the restaurant is known for, shown in the "WHAT WE'RE KNOWN FOR" section with image, name, short description, price, and an add/order button.
• Bestseller: A crowd-favourite product shown in "THE CROWD FAVOURITES", carrying a label (BESTSELLER, CHEF'S PICK, MUST TRY, POPULAR) only where supported by actual menu/business information.
• Supported label: A bestseller label that is backed by real menu or business data; unsupported labels are never shown.
• Supported claim: A why-choose-us or kitchen-story statement backed by verified business information; unsupported claims are omitted.
• Delivery zone: A locality or area the restaurant actually delivers to; where zones are unavailable, no locality names are invented and a location check is offered instead.
• Delivery Check: The destination where a visitor enters a location and receives a covered, not-covered, or unknown delivery-coverage result.
• ORDER NOW: The primary, visually dominant call to action and the destination where a direct food-delivery order is completed.
• ORDER: The mobile header ordering action and its corresponding destination, which hands off into the cart and order-completion flow.
• CART: The destination for reviewing and managing selected dishes before direct ordering.
• VIEW MENU: The hero's secondary call to action and its corresponding menu-entry destination.
• Landing: The anonymous public entry surface presenting the restaurant, its food offering, supported trust information, delivery context, and the direct-order path.
• Modern Indian Dhaba: The project's visual language — warm mid-century modernism with subtle Indian references, modern first and Indian soul second.
• Leaf-and-grain arc: The recurring 1.5px brass hairline motif that curves under section headings and returns as the top edge of the order panel.
• Reduced motion: The prefers-reduced-motion state in which all motion resolves to static and horizontal rails wrap into rows or become horizontally scrollable.