System Requirements Document for meet-chay-wala

1. Introduction

meet-chay-wala is an Android mobile application for a restaurant — a chai-and-food neighbourhood eatery. The product intent, derived from the authoritative requirement thread, is to give a local restaurant a first-party Android app through which a diner can browse the shop's menu, assemble an order, place it, and receive a confirmed order, while the shop's own staff receive and process those incoming orders through to completion.

The audience is two active human roles: the Restaurant Customer, who opens the app on a phone to see what the shop is serving and to order ahead, and the Restaurant Staff / Order Handler, who works the incoming order queue and moves each ticket through preparation to done. The app is mobile-first, single-column, thumb-reachable, and built to feel like the shop's own hand-painted signboard rather than a generic software template.

The product is delivered as an Android mobile application with a backend that persists durable orders, confirmations, and staff status updates.

2. System Overview

meet-chay-wala is a single Android application backed by a server-side service. The customer-facing surface covers an anonymous first impression, menu browsing, self-service enrollment, returning verification, an order workspace, and a post-order confirmation. The staff-facing surface covers a shared returning-verification entry and a role-restricted order queue with per-order detail and status updates.

Actors

• Restaurant Customer (active human persona) — browses the menu, assembles and places an order, and receives confirmation.
• Restaurant Staff / Order Handler (active human persona) — receives incoming orders and updates each order's status as it is prepared and completed.
• Backend service (non-persona system actor) — persists durable orders, confirmations, and staff status updates, and executes the order lifecycle.

Accepted behavior in scope

• Android mobile delivery of the restaurant application.
• Anonymous landing that explains the shop and directs customers to the menu.
• Menu browsing with item details and prices.
• Customer self-service enrollment and returning verification.
• Staff invitation acceptance and provisioning, with returning verification.
• Order assembly and review, order placement, and an order confirmation destination.
• Staff order queue and per-order status updates through preparation to completion.
• Backend persistence and execution for durable orders, confirmations, and staff status updates.

Narrow exclusions

• No web or desktop client is in scope; delivery is the Android mobile application.
• No payment processing, delivery logistics, table reservation, loyalty, or multi-branch management is accepted by the source and none is added here.
• No differentiated permission model beyond the customer/staff separation required by the accepted journeys.

2a. Product Interpretation and Delivery Boundary

The product is owned end-to-end by the application: the Android client carries every human interaction, and the application's own backend owns durable order state, confirmations, and staff status updates. There is no provider-owned or external-only surface in the accepted scope, and no headless delivery mode.

Access is split along the accepted journey boundaries. The Landing and Menu surfaces are anonymously reachable — a hungry passer-by can see what the shop serves before committing to anything. Sign Up is the customer's anonymous first-use path that establishes continuity for their orders. Login is the shared anonymous entry for returning verification, used by both the Restaurant Customer and the provisioned Restaurant Staff / Order Handler, and it also carries staff invitation acceptance. The Order Review, Order Confirmation, Orders, and Order Details surfaces are protected: they hold actor-specific durable state and must remain bound to the correct participant, so they are reachable only after identity is established.

Current horizon: everything described in this document. No future-horizon requirements were accepted by the source, so none are carried.

2b. Source Content Inventory

No reference directive in this request declares a content_source, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous first impression of the shop. Carries the shop badge emblem, the wordmark, the shop's offering line, and the primary route into the menu. No actor-specific state is held here.
• Primary actions: Proceed to the Menu. Secondary route to call the shop.
• Supporting actions: Reach Sign Up or Login from the entry surface.
• Domain entities: Restaurant identity, offering summary.
• Component responsibilities: Hero ruled panel with the circular chai-cup badge emblem and stacked wordmark; full-width brick-red rule beneath the wordmark; Oswald-caps offering line; primary brick-red pill CTA into the Menu; secondary mustard-outlined pill to call the shop; halftone-dot band bleeding off the panel edge; sticky top bar carrying the badge wordmark; bottom tab bar.
• States: Loading (badge and wordmark render immediately; no blocking fetch). Empty (not applicable — static entry content). Success (customer taps through to the Menu). Error (if the shop's offering summary cannot be fetched, the static wordmark, badge, and Menu CTA remain usable and the offering line is omitted). Recovery (retry the offering summary fetch without leaving the surface).

Menu

• Information and state: The shop's offerings as ruled ledger rows — item name and price on one baseline, description beneath. Anonymous and readable without identity.
• Primary actions: Add an item to the order.
• Supporting actions: Read item details and prices; move to Order Review.
• Domain entities: Menu item (name, description, price), order draft.
• Component responsibilities: Ruled menu rows with stamp-shaped ADD buttons; price set in Oswald all-caps on the ruled baseline; section openers with the full-width brick-red rule; bottom tab bar with the Menu tab active.
• States: Loading (ruled row skeletons in the menu band). Empty (no items available — a ruled panel stating the menu is not available right now, with a retry). Success (rows render with names, descriptions, and prices; ADD stamps the item into the order draft). Error (menu fetch fails — ruled error panel with retry, previously loaded rows remain readable). Recovery (retry fetch; items already added to the order draft are preserved).

Sign Up

• Information and state: Anonymous first-use identity establishment for the Restaurant Customer. Collects the customer's identifying details and establishes the account that will own their orders.
• Primary actions: Create the customer account.
• Supporting actions: Move to Login if the customer already has an account.
• Domain entities: Customer account.
• Component responsibilities: Ruled form panel with ink-bordered fields; all-caps Oswald field labels; brick-red submit pill; link to Login.
• States: Loading (submit pill in a depressed, disabled state while the account is created). Empty (blank form with labels). Success (account created and the customer continues into protected ordering). Error (validation failure marks the offending field with an ink rule and message; duplicate or rejected account shows a ruled error panel). Recovery (correct the field and resubmit; the entered values are retained).

Login

• Information and state: Shared anonymous returning-verification surface for the Restaurant Customer and the provisioned Restaurant Staff / Order Handler. Also carries staff invitation acceptance.
• Primary actions: Verify returning identity and continue to the correct protected destination for the actor's role.
• Supporting actions: Accept a staff invitation; move to Sign Up as a customer.
• Domain entities: Account credentials, staff invitation.
• Component responsibilities: Ruled credential panel; all-caps Oswald labels; brick-red submit pill; invitation-acceptance panel for provisioned staff; link to Sign Up.
• States: Loading (submit pill depressed and disabled during verification). Empty (blank credential fields). Success (customer continues to Order Review; staff continues to Orders). Error (invalid credentials show a ruled error panel without clearing the entered identifier; an expired or already-used invitation shows its own ruled error). Recovery (re-enter credentials and resubmit; request a fresh invitation path when the invitation is no longer valid).

Order Review

• Information and state: The customer's protected order workspace. Holds the assembled order draft with quantities, item names, and prices on ruled lines, and the order total in a solid brick-red block. Reads like a paper receipt.
• Primary actions: Confirm and place the order.
• Supporting actions: Adjust item quantities; remove an item; return to the Menu to add more.
• Domain entities: Order draft, order line (item, quantity, unit price, line total), order total.
• Component responsibilities: Receipt-panel layout with monospace-aligned quantities and prices on ruled lines; brick-red total block; quantity steppers; remove controls; brick-red place-order pill; bottom tab bar with the Order tab active.
• States: Loading (receipt panel renders the draft; totals recompute as lines change). Empty (no items in the draft — a ruled panel directing the customer back to the Menu). Success (order placed and the customer moves to Order Confirmation). Error (placement fails — a ruled error panel states the order was not placed, the draft is preserved intact, and the place-order pill returns to its ready state). Recovery (retry placement with the same draft; adjust the draft and place again).

Order Confirmation

• Information and state: Protected confirmation destination shown after a customer places an order. Displays the confirmed order with its line items, total, and the order's current status stamp.
• Primary actions: View the confirmed order's status.
• Supporting actions: Return to the Menu to start another order.
• Domain entities: Placed order, order status.
• Component responsibilities: Confirmed-order receipt panel; circular chai-cup badge stamped onto the confirmed order; status stamp graphic (RECEIVED / IN THE KITCHEN / READY) that snaps on with the 90ms stamp motion; brick-red total block; route back to the Menu.
• States: Loading (confirmation panel renders the placed order). Empty (not applicable — this surface only exists for a placed order). Success (order details and current status stamp are shown). Error (the placed order cannot be retrieved — a ruled panel states the order was placed but details are unavailable, with a retry). Recovery (retry retrieval; the order remains durable on the backend regardless of this surface's fetch).

Orders

• Information and state: Protected staff destination for receiving and reviewing incoming customer orders. A ruled ledger of order tickets, each carrying its status stamp.
• Primary actions: Open an order ticket to work it.
• Supporting actions: Scan the queue by status.
• Domain entities: Incoming order, order status, order ticket.
• Component responsibilities: Ruled ledger rows of order tickets; status stamps (RECEIVED / IN THE KITCHEN / READY) with the forest-green stamp reserved for READY; full-width brick-red rule under the section opener; bottom tab bar with the Order tab active.
• States: Loading (ruled ticket skeletons in the ledger). Empty (no incoming orders — a ruled panel stating the queue is clear). Success (tickets render with their current status stamps). Error (queue fetch fails — ruled error panel with retry; previously loaded tickets remain readable). Recovery (retry fetch; the queue refreshes as new orders arrive).

Order Details

• Information and state: Protected staff destination for a single order. Shows the order's line items, quantities, total, and current status, and is where the order is moved through preparation to completion.
• Primary actions: Advance the order's status (RECEIVED → IN THE KITCHEN → READY).
• Supporting actions: Review the order's line items and total before advancing.
• Domain entities: Order, order line, order status.
• Component responsibilities: Order ticket panel with ruled line items; brick-red total block; status stamp graphic that flips like a rubber stamp hitting paper on each change; status-advance control; back route to the Orders ledger.
• States: Loading (ticket panel renders the order). Empty (not applicable — this surface only exists for an existing order). Success (status advances and the new stamp snaps onto the ticket; the change is persisted and reflected in the Orders ledger and on the customer's Order Confirmation). Error (status update fails — a ruled error panel states the update did not save, the previous status stamp remains, and the advance control returns to its ready state). Recovery (retry the status update; the order remains in its last persisted status until the update succeeds).

3. Functional Requirements

FR-1 — Android mobile delivery (explicit) As a Restaurant Customer, I should use meet-chay-wala as an Android mobile application, so that I can browse and order from the shop on my phone.

• Trigger/input: The customer launches the installed Android application.
• Observable result: The application opens on the Landing surface with the shop badge, wordmark, and offering line rendered.
• Access state: Anonymous.
• Failure/recovery: If the app cannot reach the backend, the Landing surface still renders its static content and the Menu route remains available.
• Continuation: The customer proceeds to the Menu.

FR-2 — Anonymous first impression and route to the menu (required_inference) As a Restaurant Customer, I should see an anonymous Landing surface that explains the shop and directs me to the menu, so that I can decide whether to order before I commit to anything.

• Trigger/input: The customer opens the app without an established identity.
• Observable result: The Landing surface shows the shop badge emblem, the wordmark, the offering line, and a primary CTA into the Menu.
• Access state: Anonymous; no identity required.
• Failure/recovery: If the offering summary cannot be fetched, the static wordmark, badge, and Menu CTA remain usable and the offering line is omitted; the fetch can be retried in place.
• Continuation: The customer taps the primary CTA and lands on the Menu.

FR-3 — Menu browsing with item details and prices (required_inference) As a Restaurant Customer, I should browse the restaurant's menu with item details and prices, so that I can choose what to order.

• Trigger/input: The customer opens the Menu from the Landing surface or the bottom tab bar.
• Observable result: The menu renders as ruled ledger rows, each with the item name and price on one baseline and the description beneath.
• Access state: Anonymous; readable without identity.
• Failure/recovery: If the menu fetch fails, a ruled error panel with a retry is shown and any previously loaded rows remain readable; items already added to the order draft are preserved.
• Continuation: The customer adds items or moves to Order Review.

FR-4 — Add an item to the order (required_inference) As a Restaurant Customer, I should add a menu item to my order from the menu row, so that I can build the order I want.

• Trigger/input: The customer taps the stamp-shaped ADD button on a menu row.
• Observable result: The item is added to the order draft and the ADD control registers the addition with the 2px depress motion.
• Access state: Anonymous browsing; the draft is carried forward into the protected Order Review once identity is established.
• Failure/recovery: If the addition cannot be recorded, the row returns to its ready state and the draft is unchanged.
• Continuation: The customer continues adding items or moves to Order Review.

FR-5 — Customer self-service enrollment (required_inference) As a Restaurant Customer, I should create my own account before protected ordering continuity, so that my orders stay bound to me and I can return to them.

• Trigger/input: The customer chooses to create an account from the anonymous Sign Up surface.
• Observable result: The customer's account is created and the customer continues into protected ordering.
• Access state: Anonymous entry on Sign Up; the resulting account owns the customer's durable order state.
• Failure/recovery: Validation failures mark the offending field with an ink rule and message; a rejected or duplicate account shows a ruled error panel. The customer corrects the field and resubmits with entered values retained.
• Continuation: The customer proceeds to Order Review with the order draft intact.

FR-6 — Returning verification for the customer (required_inference) As a Restaurant Customer, I should verify my returning identity before protected work, so that I can resume my own orders.

• Trigger/input: The customer submits their credentials on the Login surface.
• Observable result: The customer is verified and continues to Order Review.
• Access state: Anonymous entry on Login; protected destinations become reachable only after verification.
• Failure/recovery: Invalid credentials show a ruled error panel without clearing the entered identifier; the customer re-enters credentials and resubmits.
• Continuation: The customer continues to Order Review.

FR-7 — Staff invitation acceptance and provisioning (required_inference) As a Restaurant Staff / Order Handler, I should accept my invitation and be provisioned before I can access incoming orders, so that only the shop's own staff work the order queue.

• Trigger/input: The invited staff member opens the invitation and accepts it on the Login surface.
• Observable result: The staff account is provisioned and the staff member continues to the Orders queue.
• Access state: Anonymous entry on Login; the Orders and Order Details destinations are role-restricted to provisioned staff.
• Failure/recovery: An expired or already-used invitation shows its own ruled error panel; the staff member requests a fresh invitation path.
• Continuation: The staff member continues to the Orders queue.

FR-8 — Returning verification for staff (required_inference) As a Restaurant Staff / Order Handler, I should verify my returning identity before protected work, so that I can resume handling orders.

• Trigger/input: The staff member submits their credentials on the Login surface.
• Observable result: The staff member is verified and continues to the Orders queue.
• Access state: Anonymous entry on Login; Orders and Order Details remain role-restricted.
• Failure/recovery: Invalid credentials show a ruled error panel without clearing the entered identifier; the staff member re-enters credentials and resubmits.
• Continuation: The staff member continues to the Orders queue.

FR-9 — Order review before confirmation (required_inference) As a Restaurant Customer, I should review my assembled order with quantities, prices, and total before confirming, so that I know exactly what I am ordering.

• Trigger/input: The customer opens Order Review with items in the order draft.
• Observable result: The order renders as a receipt panel with monospace-aligned quantities and prices on ruled lines and the total in a solid brick-red block.
• Access state: Protected; requires established customer identity.
• Failure/recovery: If the draft cannot be read, a ruled error panel is shown with a retry; the draft is not discarded.
• Continuation: The customer adjusts the draft or places the order.

FR-10 — Adjust or remove order lines (required_inference) As a Restaurant Customer, I should adjust quantities and remove items in Order Review, so that the order matches what I actually want.

• Trigger/input: The customer uses the quantity steppers or remove controls on an order line.
• Observable result: The line and the order total recompute immediately on the ruled receipt panel.
• Access state: Protected; requires established customer identity.
• Failure/recovery: If a change cannot be recorded, the line reverts to its last persisted value and the total recomputes accordingly.
• Continuation: The customer continues reviewing or places the order.

FR-11 — Place the order (required_inference) As a Restaurant Customer, I should confirm and place my order, so that the shop receives it and starts preparing it.

• Trigger/input: The customer taps the place-order pill on Order Review.
• Observable result: The order is placed, persisted durably by the backend, and the customer is taken to Order Confirmation.
• Access state: Protected; requires established customer identity.
• Failure/recovery: If placement fails, a ruled error panel states the order was not placed, the draft is preserved intact, and the place-order pill returns to its ready state; the customer retries with the same draft.
• Continuation: The customer lands on Order Confirmation.

FR-12 — Order confirmation with status (required_inference) As a Restaurant Customer, I should see a confirmation of my placed order with its current status, so that I know the shop has it and where it is in preparation.

• Trigger/input: The customer arrives on Order Confirmation after placing an order.
• Observable result: The confirmed order renders with its line items, total, the chai-cup badge stamped onto it, and its current status stamp (RECEIVED / IN THE KITCHEN / READY).
• Access state: Protected; requires established customer identity, and the confirmation remains bound to the customer who placed the order.
• Failure/recovery: If the placed order cannot be retrieved, a ruled panel states the order was placed but details are unavailable, with a retry; the order remains durable on the backend regardless.
• Continuation: The customer views the status as it advances, or returns to the Menu to start another order.

FR-13 — Staff receive and review incoming orders (required_inference) As a Restaurant Staff / Order Handler, I should receive and review incoming customer orders in a queue, so that I can see what needs to be made.

• Trigger/input: The staff member opens the Orders destination after verification.
• Observable result: Incoming orders render as a ruled ledger of order tickets, each carrying its current status stamp.
• Access state: Protected and role-restricted to provisioned staff.
• Failure/recovery: If the queue fetch fails, a ruled error panel with a retry is shown and previously loaded tickets remain readable; the queue refreshes as new orders arrive.
• Continuation: The staff member opens an order ticket.

FR-14 — Staff update an order as it is prepared and completed (required_inference) As a Restaurant Staff / Order Handler, I should update each order's status as it is prepared and completed, so that every order is handled accurately and marked done.

• Trigger/input: The staff member advances the status on Order Details (RECEIVED → IN THE KITCHEN → READY).
• Observable result: The new status stamp snaps onto the order ticket with the 90ms stamp motion, the change is persisted, and it is reflected in the Orders ledger and on the customer's Order Confirmation.
• Access state: Protected and role-restricted to provisioned staff.
• Failure/recovery: If the status update fails, a ruled error panel states the update did not save, the previous status stamp remains, and the advance control returns to its ready state; the staff member retries and the order stays in its last persisted status until the update succeeds.
• Continuation: The staff member returns to the Orders ledger and works the next ticket.

FR-15 — Backend persistence and execution (required_inference) As the application, I should persist and execute durable orders, confirmations, and staff status updates on the backend, so that order state survives across sessions and stays bound to the correct participant.

• Trigger/input: Order placement, order-line changes, and staff status updates from the client.
• Observable result: Orders, confirmations, and status changes are durably stored and served back to the owning customer and to staff.
• Access state: Backend execution supporting protected client surfaces; no human interacts with this capability directly.
• Failure/recovery: Failed writes surface as the client-side error states in FR-11 and FR-14; the last persisted state remains authoritative.
• Continuation: The owning customer and staff see the persisted state on their respective surfaces.

4. User Personas

Restaurant Customer

Product context. The Restaurant Customer is the primary active human role for meet-chay-wala: a diner who opens the app on an Android phone — standing in line, sitting at a plastic stool, or on the way over — to see what the chai-and-food shop is serving and to order ahead. They arrive anonymous and often in a hurry, so the first thing they meet must explain the shop and put the menu one tap away.

Primary goal. Get the correct food with minimal friction: see the menu, build the order they actually want, place it, and know the shop has it and where it is in preparation.

Distinct accepted responsibilities. Browsing the menu with item details and prices; adding items to an order draft; creating their own account so their orders stay bound to them; verifying their returning identity; reviewing the assembled order with quantities, prices, and total; adjusting or removing order lines; placing the order; and reading the confirmation with its current status.

Relevant inputs and decisions. Which items to add and in what quantity; whether to adjust or remove a line before committing; whether to place the order now or keep browsing; whether to start another order after confirmation.

Interactions with other accepted participants. The customer's placed order is the input to the Restaurant Staff / Order Handler's queue. The customer's confirmation reflects the status the staff member sets, so the customer's observable outcome depends on the staff member's action on the same order.

Observable success. The order is placed and confirmed, the confirmation shows the correct line items and total, and the status stamp advances from RECEIVED to IN THE KITCHEN to READY as the shop works the ticket.

Restaurant Staff / Order Handler

Product context. The Restaurant Staff / Order Handler is the in-product role that receives and processes incoming customer orders so the customer outcome is actually fulfilled. They work the app from inside the shop, on a phone, while the kitchen is moving — so the queue must be scannable at a glance and each ticket must be workable in a couple of taps.

Primary goal. Every order handled accurately and marked done: no ticket missed, no ticket left in the wrong status.

Distinct accepted responsibilities. Accepting an invitation and being provisioned before access to incoming orders; verifying their returning identity; receiving and reviewing incoming orders in a ruled ledger; opening an order ticket; and advancing each order's status as it is prepared and completed.

Relevant inputs and decisions. Which ticket to work next; when an order has actually moved from received to in the kitchen to ready; whether a status update saved before moving on.

Interactions with other accepted participants. The staff member's queue is populated by the Restaurant Customer's placed orders, and each status the staff member sets is what the customer sees on their Order Confirmation. The staff member's work is the fulfillment side of the customer's order.

Observable success. The Orders ledger shows every incoming ticket with its current status stamp, and each ticket reaches READY with the forest-green stamp, persisted and visible to the customer.

5. Core User Flows

Flow A — Restaurant Customer browses the menu anonymously

1. The customer launches meet-chay-wala on their Android phone with no established identity.
2. The Landing surface renders the shop badge emblem, the wordmark, the offering line, and the primary CTA into the Menu.
3. The customer taps the primary CTA and lands on the Menu.
4. The Menu renders ruled ledger rows, each with the item name and price on one baseline and the description beneath.
5. If the menu fetch fails, a ruled error panel with a retry is shown and any previously loaded rows remain readable; the customer retries in place.
6. Next step: the customer adds an item, or moves on to build an order.

Flow B — Restaurant Customer builds an order and places it

1. On the Menu, the customer taps the stamp-shaped ADD button on a menu row.
2. The item is added to the order draft and the ADD control registers the addition with the 2px depress motion.
3. The customer continues adding items, then opens Order Review.
4. Because Order Review is protected, the customer first establishes identity: a new customer creates an account on Sign Up; a returning customer verifies on Login. In both cases the order draft is carried forward intact.
5. On Order Review, the order renders as a receipt panel with monospace-aligned quantities and prices on ruled lines and the total in a solid brick-red block.
6. The customer adjusts quantities or removes a line; the line and the total recompute immediately.
7. The customer taps the place-order pill.
8. The order is placed and persisted durably by the backend, and the customer is taken to Order Confirmation.
9. If placement fails, a ruled error panel states the order was not placed, the draft is preserved intact, and the place-order pill returns to its ready state; the customer retries with the same draft.
10. Next step: the customer reads the confirmation and its status.

Flow C — Restaurant Customer reads the confirmation and follows the status

1. On Order Confirmation, the confirmed order renders with its line items, total, the chai-cup badge stamped onto it, and its current status stamp.
2. The status stamp reads RECEIVED, and advances to IN THE KITCHEN and then READY as the shop works the ticket, each change snapping on with the 90ms stamp motion.
3. If the placed order cannot be retrieved, a ruled panel states the order was placed but details are unavailable, with a retry; the order remains durable on the backend regardless.
4. Next step: the customer returns to the Menu to start another order, or closes the app knowing the shop has the order.

Flow D — Restaurant Customer creates an account

1. The customer, having built an order draft, reaches the protected boundary and opens Sign Up.
2. The customer fills the ruled form panel with their identifying details.
3. The customer submits; the brick-red submit pill sits depressed and disabled while the account is created.
4. On success, the account is created and the customer continues into protected ordering with the order draft intact.
5. If a field fails validation, it is marked with an ink rule and message; if the account is rejected or already exists, a ruled error panel is shown. The customer corrects the field and resubmits with entered values retained.
6. Next step: the customer continues to Order Review.

Flow E — Restaurant Customer verifies a returning identity

1. The customer opens Login from the anonymous entry.
2. The customer enters their credentials in the ruled credential panel and submits; the submit pill sits depressed and disabled during verification.
3. On success, the customer is verified and continues to Order Review.
4. If the credentials are invalid, a ruled error panel is shown without clearing the entered identifier; the customer re-enters credentials and resubmits.
5. Next step: the customer reviews and places their order.

Flow F — Restaurant Staff / Order Handler accepts an invitation and is provisioned

1. The invited staff member opens the invitation and lands on Login.
2. The staff member accepts the invitation in the invitation-acceptance panel.
3. On success, the staff account is provisioned and the staff member continues to the Orders queue.
4. If the invitation is expired or already used, its own ruled error panel is shown and the staff member requests a fresh invitation path.
5. Next step: the staff member works the order queue.

Flow G — Restaurant Staff / Order Handler verifies a returning identity

1. The staff member opens Login from the anonymous entry.
2. The staff member enters their credentials and submits; the submit pill sits depressed and disabled during verification.
3. On success, the staff member is verified and continues to the Orders queue.
4. If the credentials are invalid, a ruled error panel is shown without clearing the entered identifier; the staff member re-enters credentials and resubmits.
5. Next step: the staff member works the order queue.

Flow H — Restaurant Staff / Order Handler receives and works an order to completion

1. The staff member opens the Orders destination after verification.
2. Incoming orders render as a ruled ledger of order tickets, each carrying its current status stamp.
3. If the queue fetch fails, a ruled error panel with a retry is shown and previously loaded tickets remain readable; the queue refreshes as new orders arrive.
4. The staff member opens an order ticket and lands on Order Details, which shows the order's line items, quantities, total, and current status.
5. The staff member reviews the line items and total, then advances the status from RECEIVED to IN THE KITCHEN.
6. The new status stamp snaps onto the order ticket with the 90ms stamp motion, the change is persisted, and it is reflected in the Orders ledger and on the customer's Order Confirmation.
7. When the order is prepared, the staff member advances the status to READY; the forest-green READY stamp snaps onto the ticket.
8. If a status update fails, a ruled error panel states the update did not save, the previous status stamp remains, and the advance control returns to its ready state; the staff member retries and the order stays in its last persisted status until the update succeeds.
9. Next step: the staff member returns to the Orders ledger and works the next ticket.

6. Visuals Colors and Theme

The visual direction is Bold, honest, hand-built — a roadside chai counter after Aaron Draplin. The headline read: hand-painted signboard energy, thick marker strokes, badge logos, workwear colours, all-caps labels and ruled panels — sturdy, honest, unmistakably not a template, and legible for a phone held in one hand.

Colour tokens — light mode

Proportion: ~70% cream ground, ~20% ink text and black rules, ~7% brick red, ~3% mustard.

Typography

• Headings: Alfa Slab One, single heavy weight, all-caps for the wordmark and section openers, tight tracking (-0.01em), allowed to run large and slightly overlap ruled panels.
• Labels, tab bar, prices, status stamps: Oswald 500/600, all-caps, 13px with 0.08em tracking.
• Body: Oswald 400, 16px on mobile and 18px at 768px+, with generous line-height so a menu item description is readable on a phone.
• Scale: 1.25 modular — 13 / 16 / 20 / 25 / 40 / 56 / 72. Hero display uses clamp(44px, 12vw, 72px). Section openers use clamp(28px, 7vw, 40px).

Shape language. Chunky and hand-built: 2px and 3px solid ink borders on every card, badge, and button; small consistent radii (4px on cards, 999px on pill actions); thick 6px ruled section dividers; circular and shield-shaped badge and stamp motifs for order status; halftone-dot texture in the hero and footer bands. No soft shadows, no glass, no gradients — depth comes from hard offset blocks (a solid ink or brick-red block shifted 4px behind a card).

Layout. Poster-like vertical stack: full-bleed ruled bands alternating cream and ink, a sticky top bar carrying the badge wordmark, and a bottom tab bar with three chunky Oswald-caps tabs (Menu, Order, Account) separated by 2px ink rules. Menu items are ruled rows — name and price on one baseline, description beneath, a stamp-shaped ADD button at the right — not a grid of identical cards. Order Review uses a receipt-panel layout with monospace-aligned quantities and prices on ruled lines and totals in a brick-red block. The staff Orders screen is a ruled ledger of order tickets with status stamps. Everything is single-column and thumb-reachable at 375px; at 768px the menu splits into two ruled columns; at 1280px a three-column ruled board with the hero spanning full width.

Imagery. Thick-line vector icons drawn as if with a 6px marker — a cup with steam, a samosa triangle, a paratha circle, a delivery scooter, a chili — plus halftone-treated photography of food on kraft paper, cropped tight and bled off the edge of ruled panels. Badge logos and stamp graphics are the hero imagery; the chai cup badge is the app's recurring mark. No stock people, no 3D renders, no gradient blobs.

Explicitly avoided. Blue–indigo primary or accent on a white ground (no #0057FF, #2563EB, #6366F1 family); Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body; gradient-blob heroes, glassmorphism, frosted panels, or soft drop shadows; a grid of identical hover-lift cards for the menu; a centred headline + subtext + blue button hero composition; rounded-cartoon illustration or pastel character art; full-bleed 3D product renders or WebGL scenes; decorative motion such as bounce, parallax, or particle fields.

Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls 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 covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The public entry is a full-bleed cream ruled panel, not a centred SaaS stack — the shop's signboard, rendered as the app's first frame.

The dominant element is the shop badge: a circular hand-drawn chai-cup emblem with a 3px ink ring, sitting left-aligned at roughly 40% of the viewport width on mobile and 260px on desktop. To its right, the wordmark MEET CHAY WALA is set in Alfa Slab One at clamp(44px, 12vw, 72px), stacked in two lines, with the second line indented and overlapping the badge's edge by 12px. Beneath the wordmark a 6px brick-red rule runs the full viewport width, and under it a single Oswald-caps line: CHAI · SNACKS · TANDOOR — ORDER AHEAD.

The primary CTA is a solid brick-red pill labelled SEE THE MENU, pinned bottom-left of the panel, with a secondary mustard-outlined pill CALL THE SHOP beside it. A halftone-dot band bleeds off the right edge behind the badge. At 375px the badge and wordmark stack vertically with the badge centred; at 1280px they sit side by side with generous cream space to the right.

The concept recomposes only accepted content and controls: the shop identity, the offering line, the route into the Menu, and the route to call the shop. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The circular hand-drawn chai-cup badge emblem with its 3px ink ring, paired with the stacked Alfa Slab One wordmark and the full-width brick-red rule beneath it.
• Input → transformation → outcome thesis: The customer opens the app → the hero panel composes itself in a 120–180ms snap-in with a 2px overshoot, the chai-steam squiggle above the wordmark drifting upward and fading on its 4s loop → the customer reads the shop's identity and offering line and taps SEE THE MENU to enter the Menu.
• Motion vocabulary: Sturdy and mechanical, never bouncy. 120–180ms snap-in transitions with a 2px overshoot; buttons depress 2px like a physical stamp; status changes flip like a rubber stamp hitting paper (a 90ms scale-down then scale-up with the stamp graphic). One purposeful loop: the chai-steam squiggle above the hero wordmark drifts upward and fades every 4s. No parallax, no particles, no hover-lift.
• Composed first frame: The cream ruled panel at rest, badge left-aligned, wordmark stacked to its right with the second line overlapping the badge edge, the 6px brick-red rule running full width beneath, the Oswald-caps offering line under it, the brick-red SEE THE MENU pill bottom-left with the mustard-outlined CALL THE SHOP pill beside it, and the halftone-dot band bleeding off the right edge behind the badge.
• Reduced-motion state: With prefers-reduced-motion, the chai-steam loop stops and the hero holds its composed first frame; the snap-in transitions resolve immediately to their final positions, and the 2px button depress and 90ms stamp flip are suppressed in favor of instant state changes. All readable text and controls remain whole and fully visible.

9. Non-Functional Requirements

NFR-1 — Android mobile delivery (explicit) The product must be delivered as an Android mobile application. Rationale: this is an explicit hard constraint in the authoritative user evidence.

NFR-2 — Mobile-first legibility and thumb reach (required_inference) Every surface must be single-column and thumb-reachable at 375px, with the menu splitting into two ruled columns at 768px and a three-column ruled board at 1280px. Rationale: the accepted audience orders on a phone, often one-handed, and the creative direction fixes these breakpoints.

NFR-3 — Readable text and controls stay whole (explicit) 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 to fit, with no other element covering any part of them. Rationale: explicit creative-direction constraint that takes precedence over cropping gestures.

NFR-4 — Durable order state (required_inference) Placed orders, confirmations, and staff status updates must be persisted durably on the backend so that order state survives across sessions and stays bound to the correct participant. Rationale: required to make the accepted customer and staff journeys executable.

NFR-5 — Access separation (required_inference) Landing, Menu, Sign Up, and Login must be anonymously reachable; Order Review, Order Confirmation, Orders, and Order Details must be reachable only after identity is established, with Orders and Order Details role-restricted to provisioned staff. Rationale: required to keep durable actor-specific state bound to the correct participant.

NFR-6 — Motion restraint (explicit) Motion must be sturdy and mechanical: 120–180ms snap-in transitions with a 2px overshoot, 2px button depress, a 90ms stamp flip for status changes, and one 4s chai-steam loop. No parallax, particles, or hover-lift. Rationale: explicit creative-direction constraint.

NFR-7 — Reduced-motion support (explicit) With prefers-reduced-motion, the chai-steam loop must stop and the hero must hold its composed first frame, with transitions resolving immediately. Rationale: explicit creative-direction constraint.

NFR-8 — Palette and typography fidelity (explicit) The specified palette, fonts, surfaces, tone, and layout must be preserved; the generic indigo/blue-on-white SaaS template is forbidden for this project. Rationale: explicit user design constraint and creative direction.

10. Tech Stack

• Client: React Native for the Android mobile application. (Default — not specified by user; the source requires an Android mobile application and does not name a client framework.)
• Backend: Python with FastAPI, providing the persistence and execution for durable orders, confirmations, and staff status updates. (Default — not specified by user; the source requires backend persistence and execution and does not name a framework.)
• Storage: A relational database for durable orders, order lines, order status, customer accounts, and staff accounts. (Default — not specified by user.)
• Packaging and local orchestration: Docker and docker-compose for the backend service and its storage. (Default — not specified by user.)
• Deployment: Kubernetes is not required by the accepted scope and is therefore not included. (Default — not specified by user.)

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference) — The Restaurant Customer establishes identity through self-service enrollment on Sign Up, and the Restaurant Staff / Order Handler is provisioned through an invitation accepted on Login. Both are journey prerequisites for the protected ordering and order-handling work, not separate account-management capabilities.
• A-2 (required_inference) — The order draft survives the transition from anonymous menu browsing into protected Order Review, so a customer does not lose their selection when they establish identity.
• A-3 (required_inference) — Order status is a three-step progression: RECEIVED → IN THE KITCHEN → READY, with the forest-green stamp reserved for READY.
• A-4 (required_inference) — The customer's Order Confirmation reflects the status the staff member sets on the same order, so the two surfaces read the same durable order state.
• A-5 (Default — not specified by user) — The client is built with React Native and the backend with Python/FastAPI, since the source names neither.

Constraints

• C-1 (explicit) — The product must be an Android mobile application.
• C-2 (explicit) — The requested palette, fonts, surfaces, tone, and layout must be preserved; the catalogue fills unspecified details only.
• C-3 (explicit) — The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-4 (explicit) — Readable text and controls stay whole at every viewport; where a direction asks readable text or a control to be cropped, clipped, covered, or run off an edge, the gesture is carried by imagery or decoration instead.
• C-5 (explicit) — No web or desktop client, payment processing, delivery logistics, table reservation, loyalty, or multi-branch management is in scope; none is added.

12. Glossary

• meet-chay-wala — The Android mobile application for the restaurant, and the shop's own name.
• Restaurant Customer — The active human persona who browses the menu, assembles and places an order, and receives confirmation.
• Restaurant Staff / Order Handler — The active human persona who receives incoming orders and updates each order's status as it is prepared and completed.
• Order draft — The customer's in-progress selection of menu items and quantities before the order is placed.
• Order line — A single item in an order, with its quantity, unit price, and line total.
• Order ticket — The staff-facing representation of a placed order in the Orders ledger.
• Status stamp — The rubber-stamp graphic rendering an order's status: RECEIVED, IN THE KITCHEN, or READY, with the forest-green stamp reserved for READY.
• Chai-cup badge — The circular hand-drawn chai-cup emblem that is the app's recurring mark, used in the top bar, as the hero emblem, and stamped on confirmed orders.
• Ruled panel / ruled row — The hand-built layout motif of 2px and 3px solid ink borders, 6px ruled section dividers, and ledger-style rows with name and price on one baseline.
• Stamp-shaped ADD button — The stamp-shaped control at the right of each menu row that adds the item to the order draft.
• Receipt panel — The Order Review layout with monospace-aligned quantities and prices on ruled lines and the total in a solid brick-red block.