System Requirements Document for telor-kuno

1. Introduction

Telor Kuno is a small neighbourhood egg shop. Today, customers order by phone or in person. This project delivers a web application that lets customers order eggs from the Telor Kuno store online, and lets the store owner receive those orders so the shop can fulfil them.

The product intent is narrow and concrete: a customer browses the shop's available egg offerings, places an egg order through the web app, and the store receives that order. The store owner reviews incoming orders and acts on them. The web app is the shop's own storefront — it is not a marketplace, not a multi-vendor platform, and not an enterprise order-management suite.

The audience is twofold:

• Customers — everyday households and warung-adjacent buyers who currently order eggs by phone and want to place an order on the web instead.
• The Store Owner — the person who runs Telor Kuno, receives incoming orders, and fulfils them.

The store name is fixed: "Telor Kuno".

2. System Overview

Telor Kuno is delivered as a first-party web application with a customer-facing ordering surface and a store-owner-facing incoming-orders surface. The application owns its own identity: the store owner's access is provisioned or invited, and the owner verifies on return to reach the protected incoming-orders workflow. Customers browse and place orders without needing to establish an account.

Current delivery covers:

• An anonymous public entry that explains Telor Kuno and its web egg-ordering service.
• Browsing the shop's available egg offerings.
• Placing and submitting an egg order to the store.
• The store receiving submitted orders.
• The store owner verifying on return and reviewing incoming orders.

Actors:

• Customer (human, active) — browses offerings and places orders.
• Store Owner (human, active) — receives and reviews incoming orders; access is provisioned/invited and verified on return.
• Application backend (system) — persists offerings and orders, and delivers submitted orders into the store's incoming-orders workflow.

Narrow exclusions: no payment processing, no delivery tracking, no multi-store or marketplace behaviour, no customer account management, and no inventory-management or reporting suite are part of this delivery. These are not requested and are not built.

2a. Product Interpretation and Delivery Boundary

Telor Kuno is a single shop's own ordering web app. The customer side is open: a visitor can land on the shop's page, look at what eggs are available, and place an order without creating an account. The owner side is protected: the store owner's access is provisioned or invited ahead of time, and the owner verifies on return before reaching incoming orders. The application owns this identity — it is not delegated to an external provider.

Everything the customer and the owner do in this delivery is current. There is no future-horizon feature set carried in this document beyond the explicit exclusions above; anything not listed as current behaviour is out of scope for this delivery.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry for Telor Kuno. Presents the shop identity ("Telor Kuno"), a short statement of what the shop does (order fresh eggs from our shop — by the tray or the kilo), and a "Fresh today" badge. No protected state is shown.
• Primary action: "Order eggs" — leads the visitor into the ordering path.
• Supporting action: "See today's stock" — leads the visitor to the available egg offerings.
• Domain entities: Shop identity, egg offerings summary (as a teaser only, not the full browse surface).
• Component responsibilities: Full-bleed coral hero band; oversized "Telor Kuno" wordmark with hand-drawn yolk dot over the 'o'; secondary headline line; yolk-yellow pill CTA; ghost-outline secondary CTA; illustrated shopkeeper with egg tray bleeding off the right edge; yolk-yellow scalloped carton-ridge along the bottom of the band; cream "Fresh today" badge with yolk dot.
• States: Loading — hero band and illustration render immediately as static composition; no data-dependent content blocks the entry. Empty — not applicable (no collection on this page). Success — visitor sees the shop identity and both CTAs. Error — not applicable (no data fetch required for entry). Recovery — not applicable.

Login

• Information/state: Anonymous entry point for the store owner's returning verification. States that access is for the Telor Kuno store owner and that access is provisioned/invited. Does not expose incoming-orders content.
• Primary action: Submit verification credentials to establish the owner session.
• Supporting action: None required by source.
• Domain entities: Store Owner identity, provisioned/invited access record.
• Component responsibilities: Verification form (identifier and secret fields), submit control, inline error region, link back to the public entry.
• States: Loading — submit control shows in-progress state while verification is checked. Empty — form fields empty on first render. Success — owner session established; owner is taken to Incoming Orders. Error — invalid or unprovisioned credentials show an inline message and the form remains usable for retry. Recovery — owner can correct input and resubmit; owner can return to the public entry.

Browse

• Information/state: The shop's available egg offerings, presented as product cards. Each card shows the offering name, its price chip, and its availability state.
• Primary action: Select an offering to order.
• Supporting action: Continue to Place Order with the current selection.
• Domain entities: Egg offering (name, price, availability), tray/kilo unit.
• Component responsibilities: Yolk-yellow marquee ticker reading "Fresh today · Free delivery over 2 trays · Telor Kuno"; 3-up product card row on desktop (2-up at 768px, 1-up at 375px); egg-carton-shaped cards with soft offset shadow and yolk-yellow price chip in the top-right corner; hover lift and 0.5deg tilt; in-stock/ready state in leaf green.
• States: Loading — card row shows placeholder cards while offerings load. Empty — a plain message that no eggs are listed right now, with a route back to the public entry. Success — offerings render as cards with price chips and availability. Error — a plain message that offerings could not be loaded, with a retry control. Recovery — retry reloads the offerings; the ticker continues to run (or wraps statically under reduced motion) throughout.

Place Order

• Information/state: The customer's current egg order: selected offering(s), quantity, unit (tray or kilo), and the running total. A sticky order-summary rail on desktop that collapses into a bottom bar on mobile.
• Primary action: Submit the egg order to Telor Kuno.
• Supporting action: Adjust quantity with the yolk-yellow quantity stepper; remove a line.
• Domain entities: Order, order line (offering, quantity, unit), order total, customer contact details required to fulfil the order.
• Component responsibilities: Eggshell-white order form panel; quantity steppers with 120ms number pop; tabular-figure totals in Sora 700; sticky summary rail (desktop) / bottom bar (mobile); submit control; inline validation and error region; confirmation state after submission.
• States: Loading — submit control shows in-progress state while the order is sent. Empty — no lines selected yet; the form prompts the customer to choose eggs from Browse. Success — the order is confirmed as received by the store, with a clear confirmation and the order's contents. Error — submission failure shows a plain message and preserves the customer's entered order so it can be retried. Recovery — the customer can correct details and resubmit without re-entering the whole order.

Incoming Orders

• Information/state: The egg orders customers have submitted through the web app, shown as a single-column stack of chunky paper order tickets. Each ticket carries a left colour stripe for status (coral = new, yolk = packing, green = done) and a big tabular-figure total. Protected: reachable only by a verified store owner.
• Primary action: Review an incoming order's contents.
• Supporting action: Move an order's status forward (new → packing → done).
• Domain entities: Incoming order, order line, order total, order status, customer contact details.
• Component responsibilities: Order ticket cards in the same chunky card language as the customer side; left status stripe; tabular-figure total; status control; empty and error regions.
• States: Loading — ticket stack shows placeholder tickets while orders load. Empty — a plain message that no orders have come in yet. Success — tickets render newest-first with their status stripe and total. Error — a plain message that orders could not be loaded, with a retry control. Recovery — retry reloads the ticket stack; the owner's session remains intact.

3. Functional Requirements

FR-1 — Customer places an egg order through the web app (explicit) As a Customer, I should place an egg order through the Telor Kuno web app so that the store receives my order and can fulfil it.

• Trigger/input: The customer selects egg offering(s) and quantities on Browse and Place Order, provides the contact details needed to fulfil the order, and submits.
• Observable result/state change: A new order exists in the store's incoming-orders workflow, containing the selected offerings, quantities, units, total, and the customer's contact details.
• Access state: Anonymous — no customer account is required to browse or place an order.
• Failure/recovery: If submission fails, the customer sees a plain failure message, the entered order is preserved, and the customer can correct details and resubmit.
• Continuation: On success, the customer sees a confirmation of the submitted order and its contents.

FR-2 — Customer browses available egg offerings (explicit) As a Customer, I should browse the eggs Telor Kuno has available so that I can decide what to order.

• Trigger/input: The customer opens Browse (directly, or via "See today's stock" on Landing).
• Observable result/state change: The shop's available egg offerings render as product cards with name, price chip, and availability state.
• Access state: Anonymous.
• Failure/recovery: If offerings cannot be loaded, the customer sees a plain message and a retry control; retry reloads the offerings.
• Continuation: The customer selects an offering and continues to Place Order.

FR-3 — Store receives orders placed through the web app (explicit) As a Store Owner, I should receive the egg orders customers place through the web app so that the shop can act on them.

• Trigger/input: A customer submits an order on Place Order.
• Observable result/state change: The order appears in the store's Incoming Orders as a ticket with its contents, total, and status stripe.
• Access state: Protected — visible only to a verified store owner.
• Failure/recovery: If orders cannot be loaded, the owner sees a plain message and a retry control; retry reloads the ticket stack.
• Continuation: The owner reviews the order and moves its status forward.

FR-4 — Store Owner access is provisioned or invited (required_inference) As a Store Owner, I should have my access provisioned or invited before I use the protected incoming-orders workflow so that only the shop's owner can see customer orders.

• Trigger/input: Access for the owner role is provisioned or invited ahead of first use.
• Observable result/state change: The owner's identity is recognised by the application as the Telor Kuno store owner.
• Access state: Anonymous entry at Login; protected state (Incoming Orders) remains unavailable until verification succeeds.
• Failure/recovery: An unprovisioned attempt at Login shows an inline message and the form remains usable.
• Continuation: The owner proceeds to returning verification.

FR-5 — Store Owner returning verification (required_inference) As a Store Owner, I should verify on return so that I can continue accessing incoming orders.

• Trigger/input: The owner opens Login and submits verification credentials.
• Observable result/state change: An owner session is established and Incoming Orders becomes reachable.
• Access state: Login is anonymously reachable; Incoming Orders is protected and reachable only after verification.
• Failure/recovery: Invalid credentials show an inline error; the owner can correct input and resubmit, or return to the public entry.
• Continuation: On success, the owner lands on Incoming Orders.

FR-6 — Store Owner reviews and progresses incoming orders (required_inference) As a Store Owner, I should review each incoming order and move it forward so that the shop can fulfil it.

• Trigger/input: The owner opens Incoming Orders and selects a ticket.
• Observable result/state change: The order's contents and total are shown; the order's status stripe moves through new → packing → done.
• Access state: Protected — verified store owner only.
• Failure/recovery: If the status change cannot be saved, the ticket keeps its previous status and the owner can retry.
• Continuation: The owner continues to the next ticket.

FR-7 — Public entry explains Telor Kuno and its web ordering service (required_inference) As a Customer, I should understand what Telor Kuno is and that I can order eggs on the web so that I can start an order.

• Trigger/input: The visitor opens Landing.
• Observable result/state change: The shop identity, a short statement of the ordering service, and the "Order eggs" and "See today's stock" actions are presented.
• Access state: Anonymous.
• Failure/recovery: Not applicable — the entry is a static composition with no data dependency.
• Continuation: The visitor proceeds to Browse or Place Order.

4. User Personas

Customer

Product context. A shopper who wants to order eggs from the store "Telor Kuno" through the web app. Today they order by phone; the web app is meant to replace that call with a few taps.

Primary goal. Get fresh eggs from Telor Kuno ordered and on their way, without a phone call and without creating an account.

Distinct accepted responsibilities. The Customer browses the shop's available egg offerings, decides what and how much to order (by the tray or the kilo), provides the contact details needed to fulfil the order, submits the order, and sees it confirmed as received by the store. The Customer does not manage the shop's stock, does not see other customers' orders, and does not need an account.

Relevant inputs or decisions. Which egg offering to order; how many trays or kilos; the contact details needed for the shop to fulfil the order; whether to submit or keep adjusting.

Interactions with other accepted participants. The Customer's submitted order is the input to the Store Owner's incoming-orders workflow. The Customer's observable success is the confirmation that the store received the order; the Store Owner's observable success is that the order appears as a ticket the shop can act on.

Observable success. The Customer sees a confirmation of the submitted order and its contents, and the order exists in the store's incoming-orders workflow.

Store Owner

Product context. The owner of Telor Kuno, the person who runs the shop and fulfils its orders. They currently take orders by phone; the web app is meant to collect those orders in one place.

Primary goal. See the egg orders customers have placed through the web app so the shop can act on them.

Distinct accepted responsibilities. The Store Owner's access is provisioned or invited ahead of use; the owner verifies on return to reach the protected incoming-orders workflow; the owner reviews each incoming order's contents and total, and moves each order's status forward through new → packing → done. The owner does not browse or place orders as a customer, and does not manage customer accounts.

Relevant inputs or decisions. Verification credentials at Login; which ticket to open; whether an order is new, being packed, or done.

Interactions with other accepted participants. The Store Owner receives the orders Customers submit. The owner's observable result — a ticket appearing with the order's contents and total — is the other side of the Customer's submission.

Observable success. Incoming orders appear as tickets the owner can review and progress, and the owner's session persists across return visits after verification.

5. Core User Flows

Flow A — Customer browses the shop's eggs

1. The Customer opens the Telor Kuno web app and lands on Landing.
2. The Customer reads the shop identity and the statement that eggs can be ordered from the shop by the tray or the kilo, and sees the "Fresh today" badge.
3. The Customer chooses "See today's stock" and arrives at Browse.
4. Browse loads the shop's available egg offerings as egg-carton-shaped product cards, each with its name, a yolk-yellow price chip, and its availability state; the yolk-yellow ticker runs across the top.
5. If offerings cannot be loaded, the Customer sees a plain message and a retry control, and retries.
6. The Customer selects an offering and continues to Place Order.

Flow B — Customer places an egg order

1. The Customer arrives at Place Order with a selected offering (or arrives empty and is prompted to choose eggs from Browse).
2. The Customer sets the quantity with the yolk-yellow quantity stepper and confirms the unit (tray or kilo); the running total updates in tabular figures.
3. The Customer provides the contact details the shop needs to fulfil the order.
4. The Customer reviews the sticky order-summary rail (desktop) or the bottom bar (mobile) and submits the order.
5. Observable result: the order is confirmed as received by the store, showing the order's contents and total.
6. Failure/recovery: if submission fails, the Customer sees a plain failure message, the entered order is preserved, and the Customer corrects details and resubmits without re-entering the whole order.
7. Continuation: the Customer can return to Browse to order more.

Flow C — Store Owner verifies on return

1. The Store Owner opens Login (anonymously reachable).
2. The Store Owner submits their verification credentials for the provisioned/invited owner access.
3. Observable result: an owner session is established and Incoming Orders becomes reachable.
4. Failure/recovery: invalid or unprovisioned credentials show an inline message; the owner corrects input and resubmits, or returns to the public entry.
5. Continuation: on success, the owner lands on Incoming Orders.

Flow D — Store Owner reviews and progresses incoming orders

1. The Store Owner arrives at Incoming Orders with a verified session.
2. Incoming Orders loads the egg orders customers have submitted as a single-column stack of chunky paper order tickets, each with a left colour stripe (coral = new, yolk = packing, green = done) and a big tabular-figure total.
3. If no orders have come in yet, the owner sees a plain message that no orders have arrived.
4. If orders cannot be loaded, the owner sees a plain message and a retry control, and retries; the session remains intact.
5. The Store Owner opens a ticket and reviews the order's contents, quantities, units, total, and the customer's contact details.
6. The Store Owner moves the order's status forward through new → packing → done; the ticket's left stripe updates accordingly.
7. Failure/recovery: if the status change cannot be saved, the ticket keeps its previous status and the owner retries.
8. Continuation: the owner continues to the next ticket.

6. Visuals Colors and Theme

Muse and headline. Haraldur Thorleifsson — big-hearted boldness for a neighbourhood egg shop. The register is warm, human, slightly playful and utterly un-corporate: a shop run by a person, not a platform. The product is humble and physical, so the surface must feel generous, appetising and trustworthy enough to place a food order — never cold, never enterprise, never a dashboard template.

Colour tokens (light mode).

Ratio roughly 55% cream, 25% eggshell surfaces, 12% coral, 8% yolk/green.

Typography.

• Headings: Sora at 700–800, tight tracking (−0.02em to −0.03em), sentence case rather than all-caps.
• Body: Outfit.
• Numbers (prices, quantities, tray counts): Sora 700 with tabular figures so order rows align.
• Scale: 1.25 modular with a display tier — mobile 40 / 32 / 24 / 18 / 16; desktop 88 / 56 / 32 / 20 / 17. Hero headline clamp(40px, 8vw, 88px); section headlines clamp(28px, 4.5vw, 56px); card titles 20–24px; body 17px with 1.6 line-height; labels 13px uppercase with 0.08em tracking.

Shape language. Chunky and rounded, but not childish: 28px radius on hero cards, 20px on product cards, 999px pills for buttons, chips and steppers. Cards sit on soft offset shadows (0 6px 0 rgba(30,27,22,0.08)) so they look like stacked egg cartons rather than floating glass. Section boundaries are hard-edged colour blocks with occasional 3px solid #1E1B16 outlines; a repeating scalloped carton-ridge motif separates major bands. Illustration characters have thick 3px outlines and flat fills — no gradients, no glass, no blur.

Spacing rhythm. 12-column grid with generous 24px gutters and 32px mobile padding; the hero deliberately breaks the grid — headline occupies columns 1–8, the egg illustration bleeds off the right edge. Product browsing is 3-up on desktop, 2-up at 768px, 1-up at 375px, with a sticky order-summary rail on Place Order that collapses into a bottom bar on mobile.

Imagery style. Custom flat character illustration as the hero subject: a cheerful shopkeeper figure in an apron holding a tray of eggs, thick outlines, coral/yolk/green fills, standing beside an oversized stylised egg with a yolk-dot face. Supporting spot illustrations: a hen, a delivery scooter with an egg crate, a carton, a hand-drawn yolk sun. Photography is allowed only as small square product thumbnails on plain cream ground with a hard 3px outline frame. No stock people, no glassy 3D renders, no gradient meshes, no icon-font clip art.

Avoid. Blue–indigo primary or accent of any kind; white-first pages; glassmorphism, frosted panels, blur, gradient blobs or gradient-mesh heroes; Inter, Roboto, Poppins, Arial, Helvetica or system-ui for headings or body; a grid of identical hover-lift cards with no colour or shape differentiation; centred headline + subtext + button SaaS hero composition; stock photography of people, glossy 3D product renders, or emoji as iconography; making the owner's orders screen look like a separate enterprise dashboard.

7. Signature Design Concept

The shop you'd recognise from across the street.

The public entry is a full-bleed coral (#F4572A) band — not white. On the left 60%, the headline "Telor Kuno" is set in Sora 800 at clamp(40px, 8vw, 88px) in cream, with a second line beneath at clamp(24px, 4vw, 44px) reading "Order fresh eggs from our shop — by the tray or the kilo". Directly under the type sits a yolk-yellow pill CTA "Order eggs" at 48px tall, paired with a ghost-outline secondary "See today's stock". A small cream badge top-left of the headline reads "Fresh today" with a yolk dot.

On the right 40%, the oversized illustrated shopkeeper holds a tray of eggs, cropped so the tray and one arm run off the right viewport edge. A yolk-yellow scalloped carton ridge sits along the bottom of the band, so the page reads as stacked egg cartons.

The wordmark's signature is a hand-drawn yolk dot over the 'o' — the shop's face, not a logo lockup. Nothing is centred, there is no subtext-under-button stack, and no gradient anywhere: the drama is the colour block, the scale of the type, and the character bleeding off the edge.

This concept recomposes only accepted content and controls: the shop identity, the ordering statement, the "Order eggs" action, the "See today's stock" action, and the "Fresh today" badge. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The illustrated shopkeeper in an apron holding a tray of eggs, standing beside the oversized stylised egg with a yolk-dot face, cropped so the tray and one arm run off the right viewport edge.
• Input → transformation → outcome thesis: On load, the coral band is already composed; the headline and wordmark rise 16px and fade in, then the yolk-yellow pill CTA and ghost-outline secondary settle into place, then the shopkeeper illustration and the scalloped carton ridge complete the frame. The visitor's input — pressing "Order eggs" or "See today's stock" — compresses the control to 0.96 and moves them into the ordering path. No accepted behaviour is added; the motion only stages the entry.
• Motion vocabulary: 320–420ms cubic-bezier(0.22, 1, 0.36, 1) entrances; cards rise 16px and fade in staggered by 60ms; buttons compress to 0.96 on press; quantity steppers pop the number with a 120ms scale; one continuous element — the yolk-yellow ticker on Browse reading "Fresh today · Free delivery over 2 trays · Telor Kuno" — loops slowly and pauses on hover; add-to-cart triggers a small egg that arcs into the cart badge. No parallax, no blur, no scroll-jacking.
• Composed first frame: Full-bleed coral band; cream "Fresh today" badge with yolk dot top-left; oversized "Telor Kuno" wordmark with hand-drawn yolk dot over the 'o' occupying columns 1–8; secondary line beneath; yolk-yellow pill CTA and ghost-outline secondary pinned under the type; illustrated shopkeeper with egg tray bleeding off the right edge; yolk-yellow scalloped carton ridge along the bottom of the band.
• Reduced-motion state: All entrances resolve immediately to their final positions; the ticker stops entirely and its items wrap into a static row; the add-to-cart egg arc is replaced by an immediate badge update; button press compression is removed. Every readable text and control remains whole and inside its container at 375px, 768px and 1280px.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport (explicit — creative direction) 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 creative direction asks, as long as it covers no readable text or control. Where the direction asks readable text or a control to be cropped, clipped, covered or run off an edge, the text or control is kept whole and the gesture is carried with imagery or decoration instead. Rationale: the direction's bleeding illustration and oversized type must not cost legibility or reachability.

NFR-2 — Moving and scrollable content remains fully readable (explicit — creative direction) Marquees, tickers, carousels and horizontally scrollable rows may cross the viewport or container edge by design; every item must become fully readable as it passes. Under prefers-reduced-motion, motion stops and whole items are shown — wrapped into rows, or in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling. Rationale: the Browse ticker is a signature move and must not hide its message.

NFR-3 — Protected incoming orders are reachable only by a verified store owner (required_inference) Incoming Orders is protected; the anonymous entry interaction that establishes access lives at Login, which is anonymously reachable. Protected state remains unavailable until verification succeeds. Rationale: customer orders and contact details must remain bound to the correct participant.

NFR-4 — Customer ordering requires no account (explicit) Browsing and placing an order are anonymous; no customer account, sign-up, or profile is required. Rationale: the source describes ordering eggs from the shop, not customer account management.

NFR-5 — Order submission is durable and recoverable (required_inference) A submitted order persists into the store's incoming-orders workflow, and a failed submission preserves the customer's entered order for retry. Rationale: the accepted outcome — the store receives the order — depends on the order surviving submission.

NFR-6 — Owner session continuity (required_inference) A verified owner session persists so the owner can return to Incoming Orders without re-establishing access on every visit. Rationale: the accepted returning-verification requirement implies continuity across return visits.

NFR-7 — No differentiated permissions beyond the owner/customer boundary (explicit — scope) The only access distinction in this delivery is between the anonymous customer side and the protected store-owner side. No additional roles, role-based visibility, or permission controls over shared product state are introduced. Rationale: the source establishes no other differentiated control.

10. Tech Stack

• Frontend: React — a first-party web application with the customer-facing ordering surface and the store-owner incoming-orders surface. [Default — not specified by user]
• Backend: Python / FastAPI — serves the egg offerings, accepts submitted orders, and delivers them into the store's incoming-orders workflow. [Default — not specified by user]
• Storage: A relational database for egg offerings, orders, order lines, and store-owner access records. [Default — not specified by user]
• Containerisation: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required for this delivery's deployment shape. [Default — not specified by user]

No source-specified technology choices exist for this project; the above are labeled defaults and do not alter product behaviour.

11. Assumptions and Constraints

Constraints

• The store name is "Telor Kuno" and is used as the shop's identity throughout. (explicit)
• The application owns its identity: the store owner's access is provisioned or invited, and the owner verifies on return. (required_inference)
• Incoming Orders is protected; Landing, Login, Browse, and Place Order are anonymously reachable. (required_inference)
• The creative direction is authoritative for palette, typography, shape language, layout, imagery, and motion. (explicit)
• The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit)

Assumptions

• The shop's available egg offerings are maintained by the store and are readable by the application; the source does not specify how they are entered. (assumption)
• The contact details a customer provides at Place Order are those the shop needs to fulfil the order; the source does not enumerate them. (assumption)
• Order status values are exactly new, packing, and done, matching the direction's coral/yolk/green stripes. (assumption)
• The store owner is a single provisioned/invited role; no additional staff roles are assumed. (assumption)

Out of scope for this delivery

• Payment processing, delivery tracking, multi-store or marketplace behaviour, customer account management, and inventory-management or reporting suites. (explicit — not requested)

12. Glossary

• Telor Kuno — the name of the egg shop; "telor" is the Javanese/Indonesian word for egg.
• Customer — a shopper who browses the shop's egg offerings and places an order through the web app.
• Store Owner — the owner of Telor Kuno, whose access is provisioned or invited and who reviews incoming orders.
• Offering — an egg product the shop has available, presented as a product card with a name, price chip, and availability state.
• Tray / kilo — the units in which eggs are ordered from the shop.
• Order — a customer's submitted request for eggs, containing order lines, quantities, units, a total, and the customer's contact details.
• Order line — one offering within an order, with its quantity and unit.
• Incoming Orders — the protected store-owner surface where submitted orders appear as tickets.
• Order ticket — the chunky card representing one incoming order, with a left status stripe and a tabular-figure total.
• Status stripe — the left colour stripe on an order ticket: coral = new, yolk = packing, green = done.
• Carton ridge — the repeating scalloped half-circle motif that separates major colour bands.
• Yolk dot — the hand-drawn dot over the 'o' in the "Telor Kuno" wordmark.