System Requirements Document for ayo-g-store

1. Introduction

Ayo G Store is a Nigerian multi-category marketplace and sourcing service delivered first as a web marketplace / Progressive Web App, with a later horizon of Android and iPhone applications. Its promise is stated in its own tagline: "Buy anything. Live easy." The product exists so that a customer in Nigeria can shop everyday categories (gadgets, fashion, food, accessories), ask the store to source something the catalog does not carry, pay in Naira through a Nigerian payment flow, and follow that purchase all the way to delivery — while sellers/vendors list and sell through the same marketplace and the owner/admin keeps the catalog, orders, requests, payments, vendors, and sales under control and measurable.

The audience is mobile-first, Naira-pricing, trust-seeking Nigerian shoppers and the vendors who serve them, plus the business owner operating the marketplace. The product's emotional register is a concierge you trust with your money and your errands — not a budget bazaar.

This document is the single source of truth for what the current release must do, who does it, where it happens, and how it looks and behaves.

2. System Overview

Ayo G Store is a first-party web marketplace/PWA with application-owned identity. Three accepted human roles act in it: Customer, Seller/Vendor, and Owner/Admin. The current release covers:

• Shopping across gadgets, fashion, food, accessories, and other catalog categories.
• Request Anything — a customer describes what they need and Ayo G Store sources it.
• Checkout & payments in\x20\xe2\x82\xa6 through a Nigerian payment flow.
• Delivery tracking for customer orders.
• eSIM & USA numbers, Gaming & subscriptions, and Creator services (PR, promotion, design, editing, social media) as purchasable offerings.
• Customer accounts and Seller/vendor accounts.
• Owner/Admin dashboard covering products, orders, customers, requests, payments, vendors, and sales.
• Business analytics.
• Order/status notifications.
• Customer support.

Backend execution is required for durable accounts, catalog, orders, requests, payments, delivery status, vendor records, notifications, support activity, and analytics. The platform starts as a web marketplace/PWA and is intended to later become Android/iPhone apps; native mobile apps are a future horizon, not part of the current release.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The current release is a first-party web marketplace delivered as a PWA. All browsing, requesting, checkout, tracking, account, vendor, and admin surfaces are owned and rendered by Ayo G Store itself. The Android/iPhone applications named in the brand direction are a stated future step and are excluded from the current release's acceptance criteria.

Identity and access. Ayo G Store owns its own identity. Because customers must privately own and resume their orders, requests, delivery status, and notifications; because vendors must privately own their listings and sales; and because the owner/admin must hold a protected operational workspace, the product establishes identity on first use and verifies returning users before protected work resumes. The Landing and Shop surfaces are reachable anonymously so a visitor can understand the store and browse the catalog before committing. Login is the shared returning-verification surface for all three roles; first-use enrollment for customers and sellers/vendors is offered self-service, while owner/admin access is provisioned or invited rather than self-created. Protected destinations — Requests, Checkout, Delivery, eSIM & USA Numbers, Gaming & Subscriptions, Creator Services, Customer Account, Notifications, Support, Vendor Account, Vendor Products, Admin Dashboard, Products, Orders, Customers, Admin Requests, Payments, Vendors, Sales, and Analytics — require an established identity, and each role only reaches the workspace its accepted work belongs to.

Current vs. future. Current: everything listed in Section 2 above, on web/PWA. Future: native Android and iPhone applications. Nothing in this document should be read as committing the current release to native app store delivery.

Exclusions. This document does not add capabilities beyond the accepted feature list — no loyalty program, no wallet, no affiliate system, no advertising platform, no logistics-provider-owned tracking surface, and no account-management features beyond establishing and verifying identity.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Wordmark "Ayo G Store" in gold caps with a hairline rule; three-line stacked display headline "BUY ANYTHING." / "LIVE EASY." / "SOURCED, TRACKED, DELIVERED."; tagline "Buy anything. Live easy."; a live order-count gauge; a category rail; three ruled micro-rows (eSIM • USA numbers, Gaming & Subs, Creator services).
• Primary actions: "Start shopping" (gold primary) → Shop; "Request anything" (ghost) → Requests.
• Supporting actions: Category rail tiles → Shop filtered by category; "Log in" → Login; "Create account" → first-use enrollment.
• Domain entities: Category (Gadgets, Fashion, Food, Accessories, eSIM & Numbers, Gaming & Subs, Creator Services), live order count.
• Component responsibilities: Hero panel (asymmetric 7/5 split, full-bleed macro product photograph bleeding off the right edge, topographic contour line at 8% opacity behind the headline); gauge arc with gold needle and tabular numeral; category rail (horizontal scroll on mobile, 6-up at 1280px); ruled micro-rows; header with wordmark and identity entry.
• States: Loading — hero headline rises 12px and fades in staggered 60ms apart; gauge needle sweeps 0→live count with tabular count-up. Empty — if the live count is unavailable, the gauge shows a muted track with a dash and the category rail still renders. Success — full hero, live count, all category tiles. Error — if the count fails to load, the gauge resolves to a muted "—" and the hero remains fully usable. Recovery — the count retries on next visit; no blocking state. Reduced motion — sweeps, counts, and parallax resolve instantly to final values.

Login

• Information/state: Shared returning-verification surface for Customer, Seller/Vendor, and Owner/Admin. Centered login card (the only centered element besides empty states). Fields for returning credentials; a distinct path to first-use enrollment.
• Primary actions: Verify and continue to the role's protected workspace.
• Supporting actions: "Create a customer account" → first-use enrollment; "Register as a seller/vendor" → vendor enrollment; "Forgot access?" → recovery path.
• Domain entities: Account, role (Customer / Seller/Vendor / Owner/Admin).
• Component responsibilities: Login card with 1px hairline border and gold rim on focus; role-aware post-login routing; error region.
• States: Loading — submit button shows an inline progress state. Empty — blank fields with labels. Success — redirect to the correct protected workspace for the verified role. Error — invalid credentials show an inline message and preserve entered values. Recovery — recovery path restores access without creating a duplicate account.

Shop

• Information/state: Anonymous-reachable catalog across gadgets, fashion, food, accessories, and other categories. Ruled instrument rows with left-aligned product labels and right-aligned tabular\x20\xe2\x82\xa6 prices; category filter; search.
• Primary actions: Open a product; add to cart; proceed to Checkout.
• Supporting actions: Filter by category; search; sort; "Request anything" for items not in the catalog.
• Domain entities: Product, Category, Price (\xe2\x82\xa6), Vendor (listing owner), Cart.
• Component responsibilities: Numbered left sidebar (01 Shop, 02 Requests, 03 Orders, 04 Payments, 05 Vendors, 06 Analytics) with gold 2px left rail on the active section; ruled product rows with a gold rule that slides in on hover; price numerals in tabular Saira Condensed; category filter chips.
• States: Loading — ruled skeleton rows. Empty — centered empty state with a "Request anything" prompt when a category has no products. Success — populated ruled rows with prices. Error — inline retry banner; previously loaded rows remain. Recovery — retry reloads the catalog without losing the active filter.

Requests

• Information/state: Request Anything — the customer describes what they need and Ayo G Store sources it. A description field, optional reference details, and the customer's list of past and open requests with status.
• Primary actions: Submit a sourcing request; revisit an existing request.
• Supporting actions: Add reference details; view request status; contact Support about a request.
• Domain entities: Sourcing Request (description, status, timestamps), Customer.
• Component responsibilities: Request composer; ruled request rows with right-aligned tabular status and timestamps; status chips that pulse a single 1.2s gold ring on change.
• States: Loading — skeleton rows. Empty — centered empty state inviting the first request. Success — request appears in the list with an open status and the customer is notified. Error — submission failure preserves the typed description and offers retry. Recovery — retry resubmits the same description without duplication.

Checkout

• Information/state: Order summary,\x20\xe2\x82\xa6 totals, delivery details, and the Nigerian payment flow. Ruled line items with right-aligned tabular values.
• Primary actions: Confirm the order and pay in\x20\xe2\x82\xa6.
• Supporting actions: Adjust quantities; return to Shop; apply delivery details.
• Domain entities: Order, Order line item, Payment,\x20\xe2\x82\xa6 total, Delivery details.
• Component responsibilities: Ruled order summary; total row in tabular Saira Condensed; payment step; confirmation panel.
• States: Loading — payment step shows an inline progress state. Empty — checkout with no items shows a centered empty state and a link back to Shop. Success — order confirmed, payment recorded, customer routed to Delivery and Notifications. Error — declined or failed payment shows an inline message, keeps the order intact, and offers retry. Recovery — retry re-attempts payment for the same order without creating a duplicate.

Delivery

• Information/state: Delivery tracking for the customer's orders, drawn as a topographic contour route line with a gold position dot and three ruled checkpoint rows — Sourced / In transit / Delivered — whose timestamps count in as they complete.
• Primary actions: Open an order's tracking view.
• Supporting actions: Contact Support about a delivery; view the related order.
• Domain entities: Order, Delivery status, Checkpoint (Sourced / In transit / Delivered), Timestamp.
• Component responsibilities: Contour route line with gold position dot; three ruled checkpoint rows with tabular timestamps; status chip with gold pulse on change.
• States: Loading — contour line renders with a muted track and checkpoints resolve as data arrives. Empty — no orders yet shows a centered empty state linking to Shop. Success — route line with gold dot at the current checkpoint and counted-in timestamps. Error — if status fails to load, the last known checkpoint remains visible with an inline retry. Recovery — retry refreshes status without losing the selected order.

eSIM & USA Numbers

• Information/state: Purchasable eSIM and USA number offerings with\x20\xe2\x82\xa6 pricing in ruled rows.
• Primary actions: Select an offering and proceed to Checkout.
• Supporting actions: Compare offerings; contact Support.
• Domain entities: eSIM offering, USA number offering, Price (\xe2\x82\xa6).
• Component responsibilities: Ruled offering rows with right-aligned tabular prices; selection control; checkout handoff.
• States: Loading — skeleton rows. Empty — centered empty state when no offerings are available. Success — selection carries into Checkout. Error — inline retry banner. Recovery — retry reloads offerings without losing the selection.

Gaming & Subscriptions

• Information/state: Purchasable gaming products and subscriptions with\x20\xe2\x82\xa6 pricing in ruled rows.
• Primary actions: Select an offering and proceed to Checkout.
• Supporting actions: Compare offerings; contact Support.
• Domain entities: Gaming product, Subscription, Price (\xe2\x82\xa6).
• Component responsibilities: Ruled offering rows with tabular prices; selection control; checkout handoff.
• States: Loading — skeleton rows. Empty — centered empty state when no offerings are available. Success — selection carries into Checkout. Error — inline retry banner. Recovery — retry reloads offerings without losing the selection.

Creator Services

• Information/state: Purchasable creator services — PR, promotion, design, editing, and social media — with\x20\xe2\x82\xa6 pricing in ruled rows.
• Primary actions: Select a service and proceed to Checkout.
• Supporting actions: Review what each service covers; contact Support.
• Domain entities: Creator service (PR, promotion, design, editing, social media), Price (\xe2\x82\xa6).
• Component responsibilities: Ruled service rows with tabular prices; selection control; checkout handoff.
• States: Loading — skeleton rows. Empty — centered empty state when no services are available. Success — selection carries into Checkout. Error — inline retry banner. Recovery — retry reloads services without losing the selection.

Customer Account

• Information/state: The customer's own account and personal store activity — profile details, orders, requests, and purchases across Shop, eSIM & USA Numbers, Gaming & Subscriptions, and Creator Services.
• Primary actions: Review and update account details; open an order or request.
• Supporting actions: Jump to Delivery, Notifications, or Support.
• Domain entities: Customer account, Order history, Request history.
• Component responsibilities: Numbered sidebar with gold active rail; ruled activity rows with tabular values; account detail panel with gold rim when active.
• States: Loading — skeleton rows. Empty — centered empty state for a new account with no activity. Success — populated activity and account details. Error — inline retry banner; account details remain readable. Recovery — retry reloads activity without losing edits in progress.

Notifications

• Information/state: Order and status notifications for the customer, as ruled rows with timestamps and status chips.
• Primary actions: Open the related order, request, or delivery.
• Supporting actions: Mark as read; contact Support.
• Domain entities: Notification (order/status), Timestamp, Read state.
• Component responsibilities: Ruled notification rows; status chips with a single 1.2s gold pulse on change; unread indicator.
• States: Loading — skeleton rows. Empty — centered empty state when there are no notifications. Success — populated rows with unread markers. Error — inline retry banner. Recovery — retry reloads notifications without losing read state.

Support

• Information/state: Customer support for help with store activity — a message composer and the customer's support history with status.
• Primary actions: Send a support message.
• Supporting actions: Attach a related order or request; view support history.
• Domain entities: Support conversation, Message, Related order/request.
• Component responsibilities: Message composer; ruled conversation rows with tabular timestamps; status chips.
• States: Loading — skeleton rows. Empty — centered empty state inviting the first message. Success — message appears in the conversation with a status. Error — send failure preserves the typed message and offers retry. Recovery — retry sends the same message without duplication.

Vendor Account

• Information/state: The seller/vendor's own account and workspace — vendor profile details and a summary of their listings and sales activity.
• Primary actions: Review and update vendor account details; open Vendor Products.
• Supporting actions: View sales activity; contact Support.
• Domain entities: Vendor account, Vendor profile, Sales summary.
• Component responsibilities: Numbered sidebar with gold active rail; ruled summary rows with right-aligned tabular values; account detail panel with gold rim when active.
• States: Loading — skeleton rows. Empty — centered empty state for a newly enrolled vendor with no listings yet. Success — populated profile and summary. Error — inline retry banner; profile remains readable. Recovery — retry reloads the summary without losing edits in progress.

Vendor Products

• Information/state: The seller/vendor's own product listings offered on the marketplace, as ruled rows with left-aligned product labels and right-aligned tabular\x20\xe2\x82\xa6 prices and status.
• Primary actions: Add a listing; edit a listing; set or update its\x20\xe2\x82\xa6 price and availability.
• Supporting actions: Filter listings; view a listing's sales.
• Domain entities: Product listing, Category, Price (\xe2\x82\xa6), Availability, Vendor.
• Component responsibilities: Ruled listing rows with a gold rule that slides in on hover; listing editor panel with gold rim when active; category selector.
• States: Loading — skeleton rows. Empty — centered empty state inviting the first listing. Success — listing appears in the vendor's rows and becomes available to customers in Shop. Error — save failure preserves the entered listing details and offers retry. Recovery — retry saves the same listing without creating a duplicate.

Admin Dashboard

• Information/state: The owner/admin's operational summary and routing surface across products, orders, customers, requests, payments, vendors, and sales. A 3-up gauge row over a wide ruled table.
• Primary actions: Route into Products, Orders, Customers, Admin Requests, Payments, Vendors, Sales, or Analytics.
• Supporting actions: Scan the gauge row for current totals; open a ruled row directly.
• Domain entities: Product, Order, Customer, Sourcing Request, Payment, Vendor, Sale.
• Component responsibilities: Numbered sidebar (01 Shop, 02 Requests, 03 Orders, 04 Payments, 05 Vendors, 06 Analytics) with gold 2px left rail on the active section and champagne numerals; gauge arcs with gold needles and tabular numerals; wide ruled table.
• States: Loading — gauges render with muted tracks and needles sweep once to their live values; table shows skeleton rows. Empty — centered empty state when the marketplace has no activity yet. Success — gauges and ruled table populated. Error — inline retry banner; gauges hold their last known values. Recovery — retry refreshes gauges and table together.

Products

• Information/state: The authoritative product catalog across gadgets, fashion, food, accessories, and other categories, as ruled rows with tabular\x20\xe2\x82\xa6 prices and vendor attribution.
• Primary actions: Add a product; edit a product; set or update its\x20\xe2\x82\xa6 price, category, and availability.
• Supporting actions: Filter by category or vendor; search; remove a product from the catalog.
• Domain entities: Product, Category, Price (\xe2\x82\xa6), Availability, Vendor.
• Component responsibilities: Ruled catalog rows; product editor panel with gold rim when active; category and vendor selectors.
• States: Loading — skeleton rows. Empty — centered empty state inviting the first product. Success — product appears in the catalog and in Shop. Error — save failure preserves entered details and offers retry. Recovery — retry saves the same product without duplication.

Orders

• Information/state: Operational orders across the marketplace, as ruled rows with tabular order numbers,\x20\xe2\x82\xa6 totals, customer, and status.
• Primary actions: Open an order; update its status.
• Supporting actions: Filter by status or customer; search by order number.
• Domain entities: Order, Order line item, Customer, Payment, Delivery status.
• Component responsibilities: Ruled order rows with tabular numerals; order detail panel with gold rim when active; status chips with a single 1.2s gold pulse on change.
• States: Loading — skeleton rows. Empty — centered empty state when there are no orders. Success — populated rows; a status change propagates to the customer's Delivery and Notifications. Error — status update failure preserves the prior status and offers retry. Recovery — retry applies the same status change once.

Customers

• Information/state: Customer records, as ruled rows with tabular identifiers and activity counts.
• Primary actions: Open a customer record.
• Supporting actions: Search; filter; view a customer's orders and requests.
• Domain entities: Customer, Order, Sourcing Request.
• Component responsibilities: Ruled customer rows; customer detail panel with gold rim when active.
• States: Loading — skeleton rows. Empty — centered empty state when there are no customers. Success — populated rows with linked activity. Error — inline retry banner. Recovery — retry reloads records without losing the active filter.

Admin Requests

• Information/state: Customer sourcing requests awaiting Ayo G Store action, as ruled rows with tabular timestamps and status.
• Primary actions: Open a request; source it and update its status.
• Supporting actions: Filter by status; contact the customer through Support.
• Domain entities: Sourcing Request, Customer, Status.
• Component responsibilities: Ruled request rows; request detail panel with gold rim when active; status chips with a single 1.2s gold pulse on change.
• States: Loading — skeleton rows. Empty — centered empty state when there are no requests. Success — status change propagates to the customer's Requests list and Notifications. Error — update failure preserves the prior status and offers retry. Recovery — retry applies the same status change once.

Payments

• Information/state: Payment records and payment status across the Nigerian payment flow, as ruled rows with tabular\x20\xe2\x82\xa6 amounts and status.
• Primary actions: Open a payment record; update its status.
• Supporting actions: Filter by status; reconcile against an order.
• Domain entities: Payment, Order,\x20\xe2\x82\xa6 amount, Payment status.
• Component responsibilities: Ruled payment rows with tabular numerals; payment detail panel with gold rim when active; status chips.
• States: Loading — skeleton rows. Empty — centered empty state when there are no payments. Success — populated rows linked to orders. Error — update failure preserves the prior status and offers retry. Recovery — retry applies the same status change once.

Vendors

• Information/state: Seller/vendor records, as ruled rows with tabular identifiers and listing/sales counts.
• Primary actions: Open a vendor record; update its status.
• Supporting actions: Search; filter; view a vendor's listings and sales.
• Domain entities: Vendor, Product listing, Sale.
• Component responsibilities: Ruled vendor rows; vendor detail panel with gold rim when active.
• States: Loading — skeleton rows. Empty — centered empty state when there are no vendors. Success — populated rows with linked listings and sales. Error — update failure preserves the prior status and offers retry. Recovery — retry applies the same status change once.

Sales

• Information/state: Sales activity across the marketplace, as ruled rows with tabular\x20\xe2\x82\xa6 values and dates.
• Primary actions: Review sales activity; open a sale's order.
• Supporting actions: Filter by date or vendor; search.
• Domain entities: Sale, Order, Vendor,\x20\xe2\x82\xa6 value, Date.
• Component responsibilities: Ruled sales rows with right-aligned tabular values; sale detail panel with gold rim when active.
• States: Loading — skeleton rows. Empty — centered empty state when there are no sales. Success — populated rows. Error — inline retry banner. Recovery — retry reloads sales without losing the active filter.

Analytics

• Information/state: Business analytics and performance, presented as a 3-up gauge row over a wide ruled table.
• Primary actions: Read performance gauges; open a ruled row for detail.
• Supporting actions: Change the reporting period; filter by category or vendor.
• Domain entities: Sale, Order, Sourcing Request, Vendor, Period.
• Component responsibilities: Gauge arcs with gold needles and tabular numerals inside the ring; wide ruled table with right-aligned tabular values; period selector.
• States: Loading — gauges render with muted tracks and needles sweep once to their live values. Empty — centered empty state when there is no data for the selected period. Success — gauges and table populated for the period. Error — inline retry banner; gauges hold their last known values. Recovery — retry refreshes gauges and table together for the same period.

3. Functional Requirements

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

FR-01 — Shop products across categories (explicit) As a Customer, I should browse and shop products across gadgets, fashion, food, accessories, and other catalog categories, so that I can buy what I need from one store.

• Trigger/input: The customer opens Shop and selects a category or searches.
• Observable result: Ruled product rows render with left-aligned labels and right-aligned tabular\x20\xe2\x82\xa6 prices; selecting a product adds it to the cart.
• Access state: Shop is reachable anonymously; adding to cart and proceeding to Checkout require an established customer identity.
• Failure/recovery: If the catalog fails to load, an inline retry banner appears and previously loaded rows remain; retry reloads without losing the active filter.
• Continuation: The customer proceeds to Checkout or submits a Request Anything request for an item not carried.

FR-02 — Request Anything sourcing (explicit) As a Customer, I should describe what I need and have Ayo G Store source it, so that I can obtain items the catalog does not carry.

• Trigger/input: The customer opens Requests and submits a description of the needed item.
• Observable result: The request appears in the customer's request list with an open status and a timestamp, and the customer is notified.
• Access state: Requires an established customer identity.
• Failure/recovery: If submission fails, the typed description is preserved and retry resubmits the same description without duplication.
• Continuation: The customer revisits the request to follow its status; the owner/admin acts on it in Admin Requests.

FR-03 — Owner/Admin sources customer requests (explicit) As an Owner/Admin, I should see and act on customer sourcing requests, so that Ayo G Store actually sources what customers ask for.

• Trigger/input: The owner/admin opens Admin Requests and selects a request.
• Observable result: The request's status changes and the change propagates to the customer's Requests list and Notifications.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If the status update fails, the prior status is preserved and retry applies the same change once.
• Continuation: The sourced item can be offered to the customer and the request closes when fulfilled.

FR-04 — Checkout and\x20\xe2\x82\xa6 payment (explicit) As a Customer, I should check out and pay in\x20\xe2\x82\xa6 through a Nigerian payment flow, so that I can complete my purchase in local currency.

• Trigger/input: The customer confirms the order at Checkout and completes the payment step.
• Observable result: The order is confirmed, the payment is recorded with a\x20\xe2\x82\xa6 amount and status, and the customer is routed to Delivery and Notifications.
• Access state: Requires an established customer identity.
• Failure/recovery: A declined or failed payment shows an inline message, keeps the order intact, and offers retry; retry re-attempts payment for the same order without creating a duplicate.
• Continuation: The confirmed order enters delivery tracking and appears in the owner/admin's Orders and Payments.

FR-05 — Delivery tracking (explicit) As a Customer, I should track the delivery of my orders, so that I know where my purchase is.

• Trigger/input: The customer opens Delivery and selects an order.
• Observable result: A contour route line with a gold position dot and three ruled checkpoint rows — Sourced / In transit / Delivered — shows timestamps that count in as they complete.
• Access state: Requires an established customer identity.
• Failure/recovery: If status fails to load, the last known checkpoint remains visible with an inline retry; retry refreshes without losing the selected order.
• Continuation: The customer is notified as checkpoints complete and can contact Support about the delivery.

FR-06 — eSIM & USA numbers (explicit) As a Customer, I should buy eSIM and USA number offerings, so that I can get connectivity and a US number through the store.

• Trigger/input: The customer opens eSIM & USA Numbers and selects an offering.
• Observable result: The selection carries into Checkout with its\x20\xe2\x82\xa6 price.
• Access state: Requires an established customer identity.
• Failure/recovery: If offerings fail to load, an inline retry banner appears; retry reloads without losing the selection.
• Continuation: The purchase completes through the same checkout and delivery flow.

FR-07 — Gaming & subscriptions (explicit) As a Customer, I should buy gaming products and subscriptions, so that I can top up and subscribe through the store.

• Trigger/input: The customer opens Gaming & Subscriptions and selects an offering.
• Observable result: The selection carries into Checkout with its\x20\xe2\x82\xa6 price.
• Access state: Requires an established customer identity.
• Failure/recovery: If offerings fail to load, an inline retry banner appears; retry reloads without losing the selection.
• Continuation: The purchase completes through the same checkout and delivery flow.

FR-08 — Creator services (explicit) As a Customer, I should buy creator services — PR, promotion, design, editing, and social media — so that I can get creative work done through the store.

• Trigger/input: The customer opens Creator Services and selects a service.
• Observable result: The selection carries into Checkout with its\x20\xe2\x82\xa6 price.
• Access state: Requires an established customer identity.
• Failure/recovery: If services fail to load, an inline retry banner appears; retry reloads without losing the selection.
• Continuation: The purchase completes through the same checkout and delivery flow.

FR-09 — Customer accounts (explicit) As a Customer, I should hold an account that keeps my personal store activity, so that my orders, requests, and purchases stay mine and are there when I return.

• Trigger/input: The customer establishes identity on first use and verifies on return.
• Observable result: Customer Account shows the customer's profile details and their orders, requests, and purchases across Shop, eSIM & USA Numbers, Gaming & Subscriptions, and Creator Services.
• Access state: Requires an established customer identity; the account is private to that customer.
• Failure/recovery: If activity fails to load, an inline retry banner appears and account details remain readable; retry reloads without losing edits in progress.
• Continuation: The customer returns to Shop, Delivery, Notifications, or Support from the account.

FR-10 — Seller/vendor accounts (explicit) As a Seller/Vendor, I should hold a seller/vendor account on the marketplace, so that I can offer products and run my selling activity.

• Trigger/input: The seller/vendor enrolls or is provisioned, then verifies on return.
• Observable result: Vendor Account shows the vendor profile and a summary of listings and sales activity.
• Access state: Requires an established seller/vendor identity; the workspace is private to that vendor.
• Failure/recovery: If the summary fails to load, an inline retry banner appears and the profile remains readable; retry reloads without losing edits in progress.
• Continuation: The vendor opens Vendor Products to manage listings.

FR-11 — Vendor product listings (explicit) As a Seller/Vendor, I should manage my own product listings, so that my products are offered to customers on the marketplace.

• Trigger/input: The vendor adds or edits a listing and sets its\x20\xe2\x82\xa6 price and availability.
• Observable result: The listing appears in the vendor's ruled rows and becomes available to customers in Shop.
• Access state: Requires an established seller/vendor identity; a vendor manages only their own listings.
• Failure/recovery: If saving fails, entered listing details are preserved and retry saves the same listing without creating a duplicate.
• Continuation: The listing's sales appear in the vendor's summary and in the owner/admin's Vendors and Sales.

FR-12 — Owner/Admin dashboard (explicit) As an Owner/Admin, I should run the marketplace from a dashboard covering products, orders, customers, requests, payments, vendors, and sales, so that the whole business stays under control.

• Trigger/input: The owner/admin opens Admin Dashboard and routes into a section.
• Observable result: A 3-up gauge row over a wide ruled table shows current totals, and each section — Products, Orders, Customers, Admin Requests, Payments, Vendors, Sales — opens with its own ruled rows.
• Access state: Requires an established owner/admin identity; access is provisioned or invited, not self-created.
• Failure/recovery: If data fails to load, an inline retry banner appears and gauges hold their last known values; retry refreshes gauges and table together.
• Continuation: The owner/admin acts on a record and the change propagates to the affected customer or vendor.

FR-13 — Product catalog management (explicit) As an Owner/Admin, I should manage the authoritative product catalog, so that what customers see in Shop is correct.

• Trigger/input: The owner/admin adds, edits, or removes a product and sets its\x20\xe2\x82\xa6 price, category, and availability.
• Observable result: The change appears in the catalog and in Shop.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If saving fails, entered details are preserved and retry saves the same product without duplication.
• Continuation: The product becomes purchasable through Checkout.

FR-14 — Order management (explicit) As an Owner/Admin, I should manage operational orders, so that every order moves to completion.

• Trigger/input: The owner/admin opens an order and updates its status.
• Observable result: The status change propagates to the customer's Delivery and Notifications.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If the status update fails, the prior status is preserved and retry applies the same change once.
• Continuation: The order proceeds through delivery checkpoints to Delivered.

FR-15 — Customer records (explicit) As an Owner/Admin, I should manage customer records, so that I can see who is buying and what they have asked for.

• Trigger/input: The owner/admin opens Customers and selects a record.
• Observable result: The customer's record opens with linked orders and requests.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If records fail to load, an inline retry banner appears; retry reloads without losing the active filter.
• Continuation: The owner/admin can act on the customer's orders or requests from the record.

FR-16 — Payment records (explicit) As an Owner/Admin, I should manage payment records and payment status, so that money taken through the Nigerian payment flow is accounted for.

• Trigger/input: The owner/admin opens Payments and selects a record.
• Observable result: The payment record opens with its\x20\xe2\x82\xa6 amount and status, linked to its order.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If a status update fails, the prior status is preserved and retry applies the same change once.
• Continuation: The reconciled payment supports the order's progression and the sales figures.

FR-17 — Vendor records (explicit) As an Owner/Admin, I should manage seller/vendor records, so that the vendors selling on the marketplace are known and controlled.

• Trigger/input: The owner/admin opens Vendors and selects a record.
• Observable result: The vendor record opens with linked listings and sales.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If a status update fails, the prior status is preserved and retry applies the same change once.
• Continuation: The owner/admin can review the vendor's listings and sales activity.

FR-18 — Sales activity (explicit) As an Owner/Admin, I should review and manage sales activity, so that I know what is selling and when.

• Trigger/input: The owner/admin opens Sales and filters by date or vendor.
• Observable result: Ruled sales rows render with right-aligned tabular\x20\xe2\x82\xa6 values and dates.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If sales fail to load, an inline retry banner appears; retry reloads without losing the active filter.
• Continuation: The owner/admin opens a sale's order or moves to Analytics.

FR-19 — Business analytics (explicit) As an Owner/Admin, I should view business analytics and performance, so that I can understand how the business is doing.

• Trigger/input: The owner/admin opens Analytics and selects a reporting period.
• Observable result: A 3-up gauge row with gold needles and tabular numerals over a wide ruled table shows performance for the period.
• Access state: Requires an established owner/admin identity.
• Failure/recovery: If data fails to load, an inline retry banner appears and gauges hold their last known values; retry refreshes gauges and table together for the same period.
• Continuation: The owner/admin returns to the relevant operational section to act on what the analytics show.

FR-20 — Order/status notifications (explicit) As a Customer, I should receive order and status notifications, so that I know when something about my purchase changes.

• Trigger/input: An order, request, payment, or delivery status changes.
• Observable result: A ruled notification row appears with a timestamp and status chip, and the chip pulses a single 1.2s gold ring on change.
• Access state: Requires an established customer identity.
• Failure/recovery: If notifications fail to load, an inline retry banner appears; retry reloads without losing read state.
• Continuation: The customer opens the related order, request, or delivery from the notification.

FR-21 — Customer support (explicit) As a Customer, I should reach customer support for help with my store activity, so that I can get a problem resolved.

• Trigger/input: The customer opens Support and sends a message, optionally attaching a related order or request.
• Observable result: The message appears in the conversation with a status and timestamp.
• Access state: Requires an established customer identity.
• Failure/recovery: If sending fails, the typed message is preserved and retry sends the same message without duplication.
• Continuation: The customer follows the conversation and the owner/admin responds through the same support activity.

FR-22 — Customer first-use enrollment (required_inference) As a Customer, I should establish my identity on first use, so that my orders, requests, and purchases are bound to me and can be resumed.

• Trigger/input: A visitor chooses to create a customer account from Landing or Login.
• Observable result: A customer identity is established and the customer reaches their protected workspace.
• Access state: The entry interaction is anonymous; protected customer destinations remain unavailable until identity is established.
• Failure/recovery: If enrollment fails, entered details are preserved and retry completes the same enrollment without creating a duplicate account.
• Continuation: The customer proceeds to Shop, Requests, or Checkout.

FR-23 — Seller/Vendor enrollment or provisioning (required_inference) As a Seller/Vendor, I should enroll or be provisioned before protected vendor activity, so that my listings and sales are bound to my vendor account.

• Trigger/input: A visitor registers as a seller/vendor from Login, or is provisioned by the owner/admin.
• Observable result: A vendor identity is established and the vendor reaches Vendor Account.
• Access state: The entry interaction is anonymous; protected vendor destinations remain unavailable until identity is established.
• Failure/recovery: If enrollment fails, entered details are preserved and retry completes the same enrollment without creating a duplicate account.
• Continuation: The vendor opens Vendor Products to add a listing.

FR-24 — Owner/Admin invitation or provisioning (required_inference) As an Owner/Admin, I should be invited or provisioned before administrative activity, so that administrative control is not self-granted.

• Trigger/input: An owner/admin invitation or provisioning is issued and accepted.
• Observable result: An owner/admin identity is established and the owner/admin reaches Admin Dashboard.
• Access state: The entry interaction is anonymous; protected administrative destinations remain unavailable until identity is established.
• Failure/recovery: If acceptance fails, the invitation remains valid and retry completes the same provisioning without creating a duplicate identity.
• Continuation: The owner/admin routes into Products, Orders, Customers, Admin Requests, Payments, Vendors, Sales, or Analytics.

FR-25 — Returning verification (required_inference) As a Customer, Seller/Vendor, or Owner/Admin, I should verify on return, so that my protected work resumes where it belongs.

• Trigger/input: A returning user submits credentials at Login.
• Observable result: The user is routed to the protected workspace matching their role.
• Access state: Login is reachable anonymously; protected destinations remain unavailable until verification succeeds.
• Failure/recovery: Invalid credentials show an inline message and preserve entered values; the recovery path restores access without creating a duplicate account.
• Continuation: The user resumes their work in the correct workspace.

FR-26 — Durable backend execution (required_inference) As the Ayo G Store system, I should durably hold accounts, catalog, orders, requests, payments, delivery status, vendor records, notifications, support activity, and analytics, so that every accepted journey survives across sessions.

• Trigger/input: Any accepted human action that creates or changes state.
• Observable result: The state is persisted and readable on the next visit by the correct participant.
• Access state: Reads and writes are scoped to the participant the state belongs to.
• Failure/recovery: A failed write surfaces as an inline error on the originating surface with retry, and no partial duplicate is created.
• Continuation: The participant resumes from the persisted state.

4. User Personas

Customer

Product context. The Customer is the reason Ayo G Store exists. They are mobile-first and Naira-pricing, shopping across gadgets, fashion, food, and accessories, and they also arrive with needs the catalog does not carry. They want the store to feel like a concierge they trust with their money and their errands.

Primary goal. Receive the requested product or service with clear order status and support when needed.

Distinct accepted responsibilities. The Customer shops the catalog across categories; describes an item they need through Request Anything so the store sources it; checks out with\x20\xe2\x82\xa6 pricing through the Nigerian payment flow; tracks delivery; buys eSIM/USA numbers, gaming and subscriptions, and creator services; and relies on order/status notifications and customer support. They also hold a customer account that keeps their personal store activity.

Relevant inputs and decisions. What to buy and in which category; whether to buy from the catalog or submit a sourcing request; whether to proceed with payment in\x20\xe2\x82\xa6; which delivery checkpoint to check; whether to open a support conversation.

Interactions with other accepted participants. The Customer's sourcing requests are acted on by the Owner/Admin in Admin Requests, and the resulting status change reaches the Customer's Requests list and Notifications. The Customer's orders and payments appear in the Owner/Admin's Orders and Payments. The Customer buys listings that the Seller/Vendor manages in Vendor Products. The Customer's support messages are answered through the same support activity.

Observable success. The order is confirmed with a\x20\xe2\x82\xa6 payment recorded, the delivery route line advances through Sourced / In transit / Delivered with counted-in timestamps, notifications arrive on each status change, and support resolves any problem.

Seller/Vendor

Product context. The Seller/Vendor operates a seller/vendor account on the marketplace to offer products to customers. Their work is different from the Customer's: they are not buying, they are supplying, and their success depends on their listings being visible and their orders being handled inside the marketplace flow.

Primary goal. Sell through Ayo G Store with their products and orders handled in the marketplace flow.

Distinct accepted responsibilities. The Seller/Vendor enrolls or is provisioned into a vendor account; manages their own product listings with\x20\xe2\x82\xa6 prices and availability; and reviews their own sales activity. Their vendor records, orders, and sales are visible to the Owner/Admin.

Relevant inputs and decisions. What to list and in which category; what\x20\xe2\x82\xa6 price to set; whether a listing stays available; which listing's sales to review.

Interactions with other accepted participants. The Seller/Vendor's listings become the products the Customer buys in Shop. Their vendor record, listings, and sales appear in the Owner/Admin's Vendors and Sales. Their account and listings are private to them.

Observable success. A listing appears in the vendor's ruled rows and in Shop, sells through the marketplace flow, and shows up in their sales summary and in the Owner/Admin's vendor and sales views.

Owner/Admin

Product context. The Owner/Admin runs the Ayo G Store business through the owner/admin dashboard. Their work is operational and cross-cutting: they see the whole marketplace rather than one side of a transaction.

Primary goal. Keep the marketplace catalog, orders, sourcing requests, payments, and vendor activity under control and see how the business is performing.

Distinct accepted responsibilities. The Owner/Admin is invited or provisioned into administrative access; manages the authoritative product catalog; manages operational orders and their statuses; manages customer records; acts on customer sourcing requests; manages payment records and payment status; manages seller/vendor records; reviews and manages sales activity; and reviews business analytics. They also respond to customer support activity.

Relevant inputs and decisions. Which product to add, edit, price, or remove; which order status to set; which sourcing request to act on; which payment to reconcile; which vendor record to review; which reporting period to analyze.

Interactions with other accepted participants. The Owner/Admin's status changes on orders and requests propagate to the Customer's Delivery, Requests, and Notifications. Their catalog changes determine what the Customer sees in Shop and what the Seller/Vendor's listings compete with. Their vendor record management governs the Seller/Vendor's standing on the marketplace.

Observable success. The catalog, orders, requests, payments, and vendor activity stay under control, and the analytics gauges and ruled tables show how the business is performing.

5. Core User Flows

Flow 1 — Customer shops the catalog and checks out in\x20\xe2\x82\xa6

1. Starting context: A visitor arrives at Landing anonymously. The hero shows the wordmark, the stacked headline, the live order-count gauge, and the category rail.
2. The visitor selects "Start shopping" and lands on Shop, which is reachable anonymously.
3. On Shop, the visitor filters by category — Gadgets, Fashion, Food, or Accessories — or searches. Ruled product rows render with left-aligned labels and right-aligned tabular\x20\xe2\x82\xa6 prices.
4. The visitor opens a product and adds it to the cart. Because the cart must be bound to a person who will pay, the visitor is taken to Login to establish identity on first use (FR-22) or verify on return (FR-25).
5. Observable result: The visitor is now an established Customer and returns to Shop with the cart intact.
6. The Customer proceeds to Checkout. The ruled order summary shows line items and a\x20\xe2\x82\xa6 total in tabular Saira Condensed.
7. The Customer confirms the order and completes the Nigerian payment flow.
8. Observable result: The order is confirmed, the payment is recorded with a\x20\xe2\x82\xa6 amount and status, and the Customer is routed to Delivery and Notifications.
9. Failure/recovery: If payment is declined or fails, an inline message appears, the order stays intact, and retry re-attempts payment for the same order without creating a duplicate.
10. Continuation: The confirmed order appears in the Owner/Admin's Orders and Payments, and the Customer follows it in Delivery.

Flow 2 — Customer requests anything and Ayo G Store sources it

1. Starting context: An established Customer is on Shop and cannot find what they need.
2. The Customer selects "Request anything" and lands on Requests.
3. The Customer describes what they need in the request composer and submits.
4. Observable result: The request appears in the Customer's ruled request list with an open status and a timestamp, and a notification is created.
5. Failure/recovery: If submission fails, the typed description is preserved and retry resubmits the same description without duplication.
6. Participant handoff: The request appears in the Owner/Admin's Admin Requests.
7. The Owner/Admin opens the request, sources it, and updates its status.
8. Observable result: The status change propagates to the Customer's Requests list and Notifications, where the status chip pulses a single 1.2s gold ring.
9. Continuation: The Customer revisits the request to follow it, and the sourced item can be purchased through Checkout.

Flow 3 — Customer tracks delivery

1. Starting context: An established Customer has a confirmed order.
2. The Customer opens Delivery and selects the order.
3. Observable result: A contour route line with a gold position dot renders, with three ruled checkpoint rows — Sourced / In transit / Delivered — whose timestamps count in as they complete.
4. Failure/recovery: If status fails to load, the last known checkpoint remains visible with an inline retry; retry refreshes without losing the selected order.
5. Continuation: As the Owner/Admin advances the order status in Orders, the Customer's route line advances and a notification arrives in Notifications. If something goes wrong, the Customer opens Support and sends a message with the order attached.

Flow 4 — Customer buys eSIM & USA numbers, gaming & subscriptions, or creator services

1. Starting context: An established Customer wants connectivity, a subscription, or creative work.
2. The Customer opens eSIM & USA Numbers, Gaming & Subscriptions, or Creator Services and reviews the ruled offering rows with tabular\x20\xe2\x82\xa6 prices.
3. The Customer selects an offering.
4. Observable result: The selection carries into Checkout with its\x20\xe2\x82\xa6 price.
5. Failure/recovery: If offerings fail to load, an inline retry banner appears; retry reloads without losing the selection.
6. Continuation: The purchase completes through the same checkout, payment, and delivery flow, and appears in Customer Account.

Flow 5 — Customer reviews account, notifications, and support

1. Starting context: An established Customer returns to Ayo G Store.
2. The Customer verifies at Login and is routed to their protected workspace.
3. The Customer opens Customer Account and reviews profile details and their orders, requests, and purchases across Shop, eSIM & USA Numbers, Gaming & Subscriptions, and Creator Services.
4. Failure/recovery: If activity fails to load, an inline retry banner appears and account details remain readable; retry reloads without losing edits in progress.
5. The Customer opens Notifications and sees ruled notification rows with timestamps and status chips, then opens the related order, request, or delivery.
6. Failure/recovery: If notifications fail to load, an inline retry banner appears; retry reloads without losing read state.
7. The Customer opens Support, sends a message with a related order or request attached, and sees it appear in the conversation with a status.
8. Failure/recovery: If sending fails, the typed message is preserved and retry sends the same message without duplication.
9. Continuation: The Customer returns to Shop or Delivery from the account.

Flow 6 — Seller/Vendor enrolls and lists products

1. Starting context: A visitor wants to sell on Ayo G Store.
2. The visitor selects "Register as a seller/vendor" from Login and completes enrollment (FR-23), or is provisioned by the Owner/Admin.
3. Observable result: A vendor identity is established and the Seller/Vendor reaches Vendor Account, which shows the vendor profile and a summary of listings and sales activity.
4. Failure/recovery: If enrollment fails, entered details are preserved and retry completes the same enrollment without creating a duplicate account.
5. The Seller/Vendor opens Vendor Products and adds a listing, setting its category,\x20\xe2\x82\xa6 price, and availability.
6. Observable result: The listing appears in the vendor's ruled rows and becomes available to customers in Shop.
7. Failure/recovery: If saving fails, entered listing details are preserved and retry saves the same listing without creating a duplicate.
8. Continuation: The listing sells through the marketplace flow, and its sales appear in the vendor's summary and in the Owner/Admin's Vendors and Sales.

Flow 7 — Seller/Vendor reviews sales activity

1. Starting context: An established Seller/Vendor returns and verifies at Login.
2. The Seller/Vendor opens Vendor Account and reviews the summary of listings and sales activity.
3. Failure/recovery: If the summary fails to load, an inline retry banner appears and the profile remains readable; retry reloads without losing edits in progress.
4. The Seller/Vendor opens Vendor Products to filter listings and review a listing's sales.
5. Continuation: The Seller/Vendor edits a listing's\x20\xe2\x82\xa6 price or availability, and the change is reflected in Shop.

Flow 8 — Owner/Admin is provisioned and runs the marketplace

1. Starting context: An owner/admin invitation or provisioning is issued.
2. The invitee accepts and establishes an owner/admin identity (FR-24), then verifies at Login on return (FR-25).
3. Observable result: The Owner/Admin reaches Admin Dashboard, which shows a 3-up gauge row over a wide ruled table across products, orders, customers, requests, payments, vendors, and sales.
4. Failure/recovery: If data fails to load, an inline retry banner appears and gauges hold their last known values; retry refreshes gauges and table together.
5. The Owner/Admin routes into Products and adds, edits, or removes a product, setting its\x20\xe2\x82\xa6 price, category, and availability.
6. Observable result: The change appears in the catalog and in Shop.
7. Failure/recovery: If saving fails, entered details are preserved and retry saves the same product without duplication.
8. The Owner/Admin routes into Orders, opens an order, and updates its status.
9. Observable result: The status change propagates to the Customer's Delivery and Notifications.
10. Failure/recovery: If the status update fails, the prior status is preserved and retry applies the same change once.
11. Continuation: The Owner/Admin moves to Payments to reconcile the order's payment, or to Customers to review the buyer's record.

Flow 9 — Owner/Admin acts on sourcing requests

1. Starting context: A Customer has submitted a Request Anything request.
2. The Owner/Admin opens Admin Requests and sees the request as a ruled row with a tabular timestamp and status.
3. The Owner/Admin opens the request, sources it, and updates its status.
4. Observable result: The status change propagates to the Customer's Requests list and Notifications.
5. Failure/recovery: If the update fails, the prior status is preserved and retry applies the same status change once.
6. Continuation: The Owner/Admin contacts the Customer through Support if clarification is needed, and the request closes when fulfilled.

Flow 10 — Owner/Admin manages payments, vendors, and sales

1. Starting context: An established Owner/Admin is in Admin Dashboard.
2. The Owner/Admin opens Payments, selects a record, and reviews its\x20\xe2\x82\xa6 amount and status linked to its order.
3. Failure/recovery: If a status update fails, the prior status is preserved and retry applies the same change once.
4. The Owner/Admin opens Vendors, selects a record, and reviews the vendor's linked listings and sales.
5. Failure/recovery: If a status update fails, the prior status is preserved and retry applies the same change once.
6. The Owner/Admin opens Sales, filters by date or vendor, and reviews ruled sales rows with right-aligned tabular\x20\xe2\x82\xa6 values and dates.
7. Failure/recovery: If sales fail to load, an inline retry banner appears; retry reloads without losing the active filter.
8. Continuation: The Owner/Admin opens a sale's order or moves to Analytics.

Flow 11 — Owner/Admin reviews business analytics

1. Starting context: An established Owner/Admin wants to understand performance.
2. The Owner/Admin opens Analytics and selects a reporting period.
3. Observable result: A 3-up gauge row with gold needles and tabular numerals inside the rings sits over a wide ruled table showing performance for the period.
4. Failure/recovery: If data fails to load, an inline retry banner appears and gauges hold their last known values; retry refreshes gauges and table together for the same period.
5. Continuation: The Owner/Admin returns to the relevant operational section — Products, Orders, Payments, Vendors, or Sales — to act on what the analytics show.

6. Visuals Colors and Theme

Muse and headline. The visual language is a precision luxury instrument — MARQ by Garmin's luxury-instrument aesthetic translated into a Nigerian multi-category marketplace and sourcing service. The headline idea: status and numbers are the content, and instruments are how status is shown. The store should read as engineered reliability with gold as the reward signal — a concierge you trust with your money and your errands, not a noisy market stall.

Colour tokens (dark mode, authoritative).

Proportion. ~80% black/graphite, ~12% off-white type, ~6% gold, ~2% champagne. Gold is a material, never a background flood — it appears as hairlines, filled small controls, numerals, and one primary button per screen. All body text sits on background or surface, never on gold.

Typography. Headings: Saira Condensed — condensed technical sans for display and data, uppercase for section titles and micro-labels with 0.08em tracking, sentence case for hero lines at 600–700 weight, tight 0.95 line-height on display sizes so stacked lines read as one instrument face. Prices and order numbers use Saira Condensed tabular numerals. Body copy: Saira 400/500 at 16–18px with 1.6 line-height; small caps reserved for table headers and status chips. Scale: 1.333 modular, mobile-first 44/33/25/19/16/14px; desktop 72/54/40/28/18/16px. Display hero uses clamp(44px, 9vw, 88px) on Landing; section headers clamp(28px, 4.5vw, 40px). Numerals are always tabular and never below 14px.

Shape language. Instrument geometry: circular gauge rings, bezel rims, and ruled data rows. Corners are machined, not soft — 2px on buttons and chips, 4px on cards and panels, 999px only for status dots and avatar rings. Every panel can carry a 1px hairline border in #2A2D33; the active panel gets a 1px gold rim instead of a shadow. Gauges are SVG arcs with a gold needle and a muted track; the same arc motif repeats as progress meters, delivery status, and analytics dials. Buttons are capsule-free rectangles with a 1px inner light line at the top edge to read as brushed metal.

Spacing rhythm. A 12-column instrument grid on a 24px gutter (16px at 375px), max content width 1280px. Ruled rows use consistent vertical rhythm so lists read as measurement scales.

Imagery style. Macro product photography on graphite and concrete grounds — a phone, a sneaker, a food pack, a watch — each shot as an instrument detail with one warm rim light, cropped edge-to-edge and bled off the panel. Secondary imagery is engineered texture: topographic contour lines, brushed metal, dial markings, ruled measurement lines, used as section dividers and background fields. No stock people, no gradient blobs, no clip art. Category tiles use thick-line gold pictograms on dark. Delivery tracking uses a route line drawn as a topographic contour with a gold position dot.

Forbidden. Any blue or indigo primary/accent (no #2563EB, #6366F1, #7C3AED family) on white or near-white. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body. Centered hero headline with subtext and a gradient blob. Grids of identical hover-lift cards with soft shadows. Flooding gold as a background or large fill. Rounded-pill buttons, bouncy spring easing, confetti, emoji as decorative art, or playful character illustration. Photography of people or stock lifestyle scenes in the hero.

7. Signature Design Concept

The Instrument Panel. The public entry — Landing — is a full-bleed black titanium panel, not a centered SaaS hero. It opens as an asymmetric 7/5 split.

Left 7 columns. The wordmark "Ayo G Store" set small in gold caps with a hairline rule beneath it. Then a three-line stacked display headline in Saira Condensed at clamp(44px, 9vw, 88px):

BUY ANYTHING. LIVE EASY. SOURCED, TRACKED, DELIVERED.

The first two lines are #F2EFE9 on #0B0C0E; the final line is muted #8A8F98. Beneath the headline sit exactly two controls, pinned left, not centered: a single gold primary button "Start shopping" and a ghost button "Request anything". A thin topographic contour line runs behind the headline at 8% opacity.

Right 5 columns. A full-bleed macro product photograph bleeding off the right viewport edge, overlaid with a circular gauge arc whose gold needle points at "12,480 orders" in tabular numerals, plus three ruled micro-rows in muted caps: eSIM • USA numbers, Gaming & Subs, Creator services.

Below the fold. A horizontal category rail of six ruled tiles — Gadgets, Fashion, Food, Accessories, eSIM & Numbers, Gaming & Subs, Creator Services — that scrolls horizontally on mobile and becomes a 6-up row at 1280px. Each tile uses a thick-line gold pictogram on dark.

Signature moves carried through the product. Gauge-arc numerals render every count that matters — order total, delivery progress, monthly sales, request turnaround — as an SVG arc with a gold needle and a muted track, with the number in tabular Saira Condensed inside the ring, replacing the usual stat card. Ruled instrument rows are the primary list pattern for products, orders, requests, and vendors: 1px-hairline rows with left-aligned labels and right-aligned tabular values, and a gold rule that slides in on hover — no hover-lift cards anywhere. Numbered sidebar navigation (01 Shop, 02 Requests, 03 Orders, 04 Payments, 05 Vendors, 06 Analytics) persists across shop, account, vendor, and admin, with the active section marked by a gold 2px left rail and the numeral in champagne. Delivery status is drawn as a topographic contour with a gold position dot and three ruled checkpoint rows. Buttons carry a 1px inner light line along the top edge, and the active panel gets a 1px gold rim, so interactive surfaces read as machined parts rather than flat fills.

Responsive behavior. At 375px the image moves below the headline at full width, the gauge becomes a 96px inline meter, and the headline wraps to four lines with the same clamp floor so nothing is clipped. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no element covers any part of them.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The macro product photograph bleeding off the right viewport edge, overlaid with the circular gauge arc and its gold needle — the instrument reading the store's live order count.
• Input → transformation → outcome thesis: On load, the hero headline lines rise 12px and fade in staggered 60ms apart; the gauge needle sweeps once from 0 to the live order count while the number counts up in tabular numerals. The input is the page load; the transformation is the instrument coming to life; the outcome is a first frame that reads as a calibrated device reporting real store activity — using only the accepted live order count and category rail, never a new behavior.
• Motion vocabulary: Precise instrument motion, never playful. Hover on a product row slides a 1px gold rule under it and lifts the price by 1px — no scale, no shadow bloom. Status chips pulse a single 1.2s gold ring on change. Scroll-linked parallax on the hero product macro is limited to 6% vertical drift. Page transitions are 180ms opacity crossfades.
• Composed first frame: Black titanium ground; wordmark in gold caps with hairline rule; three stacked headline lines at their final positions with the third in muted grey; two left-pinned buttons; the macro photograph bleeding off the right edge with the gauge arc and its needle at rest at 0; the topographic contour line faint behind the headline; the category rail below.
• Reduced-motion state: With prefers-reduced-motion, all sweeps, counts, and pulses resolve instantly to their final value and parallax is removed. The gauge shows its final number immediately, the headline is fully visible with no rise, and the category rail wraps into rows or sits in a horizontally scrollable row (overflow-x: auto) with every item fully readable.

9. Non-Functional Requirements

NFR-01 — Platform delivery (explicit) The product must start as a web marketplace / Progressive Web App. Native Android and iPhone applications are a future horizon and must not be treated as current acceptance criteria.

NFR-02 — Currency and payment locality (explicit) All pricing must be displayed in\x20\xe2\x82\xa6 (Nigerian Naira) and checkout must run through a Nigerian payment flow.

NFR-03 — Brand identity (explicit) The brand name is Ayo G Store; the tagline is "Buy anything. Live easy."; the brand style is black + gold. These are fixed and must not be substituted.

NFR-04 — Readable text and controls at every viewport (explicit, from the creative direction) 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. 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.

NFR-05 — Reduced motion (explicit, from the creative direction) With prefers-reduced-motion, all sweeps, counts, and pulses must resolve instantly to their final value and parallax must be removed. Moving and scrollable content must stop and show whole items — wrapping into rows or sitting in a horizontally scrollable row whose further items are reached by scrolling.

NFR-06 — Numerals legibility (explicit, from the creative direction) Prices and order numbers must use tabular numerals and must never render below 14px.

NFR-07 — Durable state and identity continuity (required_inference) Accounts, catalog, orders, requests, payments, delivery status, vendor records, notifications, support activity, and analytics must persist durably so that each participant can resume their own work across sessions, and each participant's state must remain bound to the correct participant.

NFR-08 — Failure recovery without duplication (required_inference) Every accepted write path must surface a material failure inline on the originating surface, preserve the participant's input, and allow retry that does not create a duplicate record.

10. Tech Stack

• Frontend: React, delivered as a web marketplace / Progressive Web App. (Preserves the explicit platform constraint: start as web/PWA, then Android/iPhone apps later.)
• Backend: Python / FastAPI, providing durable execution for accounts, catalog, orders, requests, payments, delivery status, vendor records, notifications, support activity, and analytics. (Required by the accepted backend integration requirement.)
• Storage: A persistent database appropriate to the durable entities above (accounts, catalog, orders, requests, payments, delivery status, vendor records, notifications, support activity, analytics).
• Containerization: Docker / docker-compose for local and deployment packaging.
• Kubernetes: Not required by any source-stated constraint; omit unless deployment scale later demands it.
• Payments: A Nigerian payment flow for\x20\xe2\x82\xa6 checkout. (Explicit constraint; the specific provider is not named by the user and must not be invented here.)
• Future: Native Android and iPhone applications. (Explicit future horizon; not part of the current release.)

11. Assumptions and Constraints

Constraints (explicit, binding).

1. The platform starts as a web marketplace / PWA, then turns into Android/iPhone apps. Native apps are future, not current.
2. Pricing is in\x20\xe2\x82\xa6 (Nigerian Naira) with a Nigerian payment flow.
3. Brand style is black + gold.
4. Brand name is Ayo G Store; tagline is "Buy anything. Live easy."
5. The creative direction's palette, typography, shape language, layout, motion, and imagery rules are authoritative for Section 6, 7, and 8, and its readability and reduced-motion rules are binding non-functional requirements.
6. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Assumptions (narrow, labeled).

1. [Assumption] Ayo G Store owns its own identity, because customers must privately own and resume orders, requests, delivery status, and notifications; vendors must privately own their listings and sales; and the owner/admin must hold a protected operational workspace. This is a required_inference from the accepted journeys, not a source-stated account-management feature set.
2. [Assumption] Customer and Seller/Vendor identity is established self-service on first use; Owner/Admin access is provisioned or invited rather than self-created. This follows from the accepted role separation and the protected administrative workspace.
3. [Assumption] Landing and Shop are reachable anonymously so a visitor can understand the store and browse before committing; all other destinations require an established identity.
4. [Assumption] The specific Nigerian payment provider is not named by the user and is left unspecified rather than invented.
5. [Assumption] The live order count shown in the Landing gauge is derived from the store's own order data; if it is unavailable, the gauge degrades to a muted placeholder rather than blocking the page.
6. [Assumption] The numbered sidebar sections (01 Shop, 02 Requests, 03 Orders, 04 Payments, 05 Vendors, 06 Analytics) are the direction's navigation pattern and are rendered per role according to the destinations that role may reach.

Exclusions.

1. Native Android and iPhone applications are excluded from the current release.
2. No capabilities beyond the accepted feature list are added — no loyalty program, wallet, affiliate system, advertising platform, or logistics-provider-owned tracking surface.
3. No account-management capabilities beyond establishing and verifying identity are added.
4. Application identity and session continuity do not establish differentiated permissions beyond the accepted role separation between Customer, Seller/Vendor, and Owner/Admin workspaces.

12. Glossary

• Ayo G Store — The Nigerian multi-category marketplace and sourcing service defined by this document. Tagline: "Buy anything. Live easy."
• PWA (Progressive Web App) — The current delivery form of Ayo G Store: a web marketplace installable and usable as an app-like experience.
• Customer — The accepted human role that shops the catalog, submits Request Anything requests, checks out in\x20\xe2\x82\xa6, tracks delivery, buys eSIM/USA numbers, gaming and subscriptions, and creator services, and uses notifications and support.
• Seller/Vendor — The accepted human role that operates a seller/vendor account, manages its own product listings, and reviews its own sales activity on the marketplace.
• Owner/Admin — The accepted human role that runs the business through the owner/admin dashboard across products, orders, customers, requests, payments, vendors, and sales, and reviews business analytics.
• Request Anything — The sourcing capability where a customer describes what they need and Ayo G Store sources it.
• Sourcing Request — The durable record of a Request Anything submission, with a description, status, and timestamps.
• \xe2\x82\xa6 (Nigerian Naira) — The currency in which all pricing and payment are expressed.
• Nigerian payment flow — The checkout payment path used to pay in\x20\xe2\x82\xa6.
• Delivery checkpoint — One of the three tracked delivery states: Sourced, In transit, Delivered.
• Gauge arc — The signature visual component: an SVG arc with a gold needle and a muted track, with the value set in tabular Saira Condensed inside the ring.
• Ruled instrument row — The primary list pattern: a 1px-hairline row with a left-aligned label and a right-aligned tabular value, with a gold rule that slides in on hover.
• Tabular numerals — Numerals of equal width used for prices, order numbers, timestamps, and gauge values so figures align as a measurement scale.
• Black titanium ground — The #0B0C0E near-black background that carries every page.
• Instrument gold — The #C9A227 primary colour used as a material accent for prices, active states, the single CTA, and gauge needles.