System Requirements Document for el-bolsep

1. Introduction

el-bolsep is an Arabic-first e-commerce product composed of two inseparable halves: a public storefront where shoppers browse and buy, and a professional merchant control room (لوحة تحكم احترافية) from which the store owner runs the shop. The product is built for the Arabic right-to-left reading direction as its native composition, and its identity is carried by typography at poster scale rather than by illustration or stock imagery.

The product intent, derived from the authoritative requirement thread, is threefold:

1. Build an online store — a public storefront that presents products and lets a shopper complete a purchase.
2. Give the store a professional admin dashboard — a merchant-facing control room for managing products, orders, and day-to-day store operations.
3. Make the dashboard connectable to the ايكوتراك وش platform — the merchant can set up and review a link between the dashboard and the external ايكوتراك وش platform.

Audience. Two active human roles use this product: the متجر أونلاين (صاحب المتجر / مدير المتجر) — the merchant-owner who operates the store through the dashboard — and the متسوق (عميل المتجر) — the shopper who browses the storefront and completes a purchase. The storefront speaks to the shopper; the dashboard speaks to the merchant. Both are served by one institution with one visual system.

2. System Overview

el-bolsep is delivered as a first-party web application with custom UI. It has a public, anonymously reachable storefront surface and a protected merchant back office. The merchant establishes their own identity through self-service sign-up and returns through sign-in; the shopper browses and checks out without an account.

Actors

Accepted behavior in scope

• A public storefront presenting the store's products.
• A purchase flow that a shopper can complete from the storefront.
• Self-service identity establishment and returning verification for the merchant.
• A professional dashboard summarizing store operations and routing the merchant into administrative work.
• Product management: browsing the product list and creating/editing product data.
• Order management: browsing, following, and managing orders produced by purchases.
• Integration setup and review between the dashboard and the ايكوتراك وش platform.

Narrow exclusions

• No details of the ايكوتراك وش platform's own interfaces or connection mechanism are supplied by the source; the external platform's side of the integration remains provider-owned and is not specified here.
• No provisioning or invitation path is established by the source; merchant identity is self-service only.
• No multi-role permission model beyond the merchant's ownership of the protected back office is established by the source.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. el-bolsep is a first-party custom-UI web application. The storefront, the checkout, the identity surfaces, and the entire merchant dashboard are owned and rendered by the application itself. The ايكوتراك وش platform is an external system: el-bolsep owns the configuration and review surface for the connection, while the platform owns its own interfaces and behavior. The source supplies no interface details for ايكوتراك وش, so no behavior on the platform's side is specified or assumed.

Access ownership. The storefront and checkout are public and anonymously reachable — a shopper is never required to create an account to browse or buy. The merchant back office is protected: the merchant establishes their own identity through self-service sign-up, and returns through sign-in before reaching the dashboard and protected operational data. Because the source establishes no invitation or provisioning path, self-service registration is the only identity-establishment route. The sign-up and sign-in interactions are themselves anonymously reachable entry points; they are the means by which access to the protected back office is obtained, not destinations that require prior access.

Current vs. future. Everything described in this document is current. No future-horizon requirements were stated in the authoritative thread.

Boundary of the integration. "Connectable to ايكوتراك وش" is a current commitment: the merchant must be able to set up and review the link from the dashboard. The mechanics of the external platform are outside this document's scope and remain with that platform.

2b. Source Content Inventory

Not applicable. The reference directive for منصة ايكوتراك وش declares uses: ["feature_reference"] only, not content_source; it supplies no verified factual entities, collections, fields, values, dates, contacts, links, or media to inventory.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract for el-bolsep. Each page appears exactly once.

Store

• Information and state. The public storefront: the store's identity expressed as a full-bleed RTL poster hero, the product catalog presented as a dense poster grid, and the store's shipping/promotional messaging. No identity is required to view any of it.
• Primary actions. Browse the product catalog; open a product's detail; add a product to the cart; proceed to checkout.
• Supporting actions. Read the shipping/promo ticker; navigate between catalog sections.
• Domain entities. Product (name, image, price, availability), Cart, Cart line item.
• Component responsibilities.
  • Poster hero — Arabic wordmark set flush right at poster scale, overlapping a solid primary-red block that bleeds off the right viewport edge; a 4px ink rule runs full-bleed beneath the wordmark; a mono ticker line sits below the rule.
  • Ticker — RTL marquee carrying shipping/promo copy; stops and wraps into a static ruled row under reduced motion.
  • Catalog grid — 3-up poster grid of hard-bordered product cards with mono price tags; flat, no hover-lift.
  • Product card — product image (duotone-treated cutout on paper or a solid colour block), product name, mono price, add-to-cart control.
  • Cart summary — line items, quantities, running total, checkout entry.
  • Section rules — numbered 2px/4px full-bleed rules separating sections.
• States.
  • Loading — catalog grid shows ruled placeholder blocks in the poster grid.
  • Empty — no products published: a ruled panel stating the store has no products yet, with the catalog grid absent.
  • Success — catalog renders; a product added to the cart updates the cart summary immediately.
  • Error — catalog fails to load: a ruled error panel with a retry control; the hero and ticker remain intact.
  • Recovery — retry re-requests the catalog; the cart is preserved across the retry.

Login

• Information and state. The returning merchant's verification surface. Anonymously reachable. Collects the merchant's credentials and verifies them before granting access to the protected back office.
• Primary actions. Submit credentials to sign in; on success, proceed to the Dashboard.
• Supporting actions. Navigate to Sign Up if the merchant has no account yet.
• Domain entities. Merchant identity, Session.
• Component responsibilities.
  • Credential form — email and password fields with hard-edged 2px ink borders, no radius.
  • Submit control — rectangular ink CTA that inverts to solid ink on hover.
  • Error region — ruled inline error band for invalid credentials.
  • Sign-up link — routes to Sign Up.
• States.
  • Loading — submit control shows a pending state; fields are held.
  • Empty — pristine form with no errors.
  • Success — session established; the merchant is routed to the Dashboard.
  • Error — invalid credentials: a ruled error band states the credentials were not accepted; the password field is cleared and the email is retained.
  • Recovery — the merchant may correct and resubmit; repeated failures keep the same ruled error treatment without locking the form.

Checkout

• Information and state. The purchase-completion surface reached from the Store. Anonymously reachable. Presents the cart contents, the shopper's contact and delivery details, and the order total.
• Primary actions. Enter contact and delivery details; confirm the order; complete the purchase.
• Supporting actions. Return to the Store to continue shopping; adjust cart quantities before confirming.
• Domain entities. Cart, Cart line item, Order, Order line item, Shopper contact details, Delivery details, Order total.
• Component responsibilities.
  • Order summary — ruled rows of line items with tabular mono quantities and totals.
  • Details form — contact and delivery fields with hard-edged 2px ink borders.
  • Confirm control — rectangular primary-red CTA.
  • Confirmation panel — post-purchase ruled panel showing the order reference in tabular mono.
• States.
  • Loading — summary rows render as ruled placeholders while the cart is resolved.
  • Empty — cart is empty: a ruled panel stating there is nothing to check out, with a return-to-store control; the confirm control is unavailable.
  • Success — order is created and persisted; a confirmation panel shows the order reference and the cart is cleared.
  • Error — order submission fails: a ruled error band states the order was not placed, the entered details are retained, and the confirm control is re-enabled.
  • Recovery — the shopper may resubmit without re-entering details; a partially completed order is never presented as placed.

Sign Up

• Information and state. The merchant's self-service identity-establishment surface. Anonymously reachable. Collects the details needed to create the merchant's account and store ownership.
• Primary actions. Submit registration details to create the account; on success, proceed to the Dashboard.
• Supporting actions. Navigate to Login if the merchant already has an account.
• Domain entities. Merchant identity, Store ownership, Session.
• Component responsibilities.
  • Registration form — email, password, and store-identifying fields with hard-edged 2px ink borders.
  • Submit control — rectangular ink CTA.
  • Error region — ruled inline error band for validation and duplicate-account failures.
  • Sign-in link — routes to Login.
• States.
  • Loading — submit control shows a pending state; fields are held.
  • Empty — pristine form with no errors.
  • Success — account created, store ownership bound to the merchant, session established, and the merchant is routed to the Dashboard.
  • Error — validation failure or an email already in use: a ruled error band names the offending field; entered values are retained.
  • Recovery — the merchant corrects the field and resubmits; if the email is already in use, the sign-in link is offered.

Dashboard

• Information and state. The professional control room and the merchant's landing surface after sign-in. Protected. Summarizes store operations and routes the merchant into administrative work.
• Primary actions. Read the KPI band; enter Products; enter Orders; enter Integrations.
• Supporting actions. Read the status bands on summary rows; sign out.
• Domain entities. Store, Product, Order, Integration connection, KPI values.
• Component responsibilities.
  • RTL rail navigation — fixed right-side rail (Arabic reads right-to-left) linking Dashboard, Products, Orders, and Integrations.
  • KPI band — ruled band across the top with tabular mono numerals at 28/20/14.
  • Status rows — summary rows carrying a full-width 6px colour band on the right edge: red = needs attention, teal = healthy, ink = neutral.
  • Numbered section rules — 2px/4px full-bleed rules with mono section numbers in the rule gaps.
• States.
  • Loading — KPI band and status rows render as ruled placeholders.
  • Empty — a newly created store with no products and no orders: ruled panels state that no products and no orders exist yet, each with a control routing to Products or Orders respectively.
  • Success — KPIs and status rows render with their colour bands.
  • Error — a summary source fails: the affected band shows a ruled error row with a retry control; unaffected bands still render.
  • Recovery — retry re-requests only the failed band.

Products

• Information and state. The merchant's product list within the dashboard. Protected. Shows the store's products with the data needed to identify and manage them.
• Primary actions. Browse the product list; open a product in the Product Editor; start creating a new product.
• Supporting actions. Filter or scan the list by product identity; read price and availability per row.
• Domain entities. Product (name, image, price, availability, SKU).
• Component responsibilities.
  • Product table — ruled rows with tabular mono SKUs and prices; hard borders, no hover-lift.
  • Row status band — 6px right-edge colour band per row.
  • Create control — rectangular ink CTA routing to the Product Editor in create mode.
  • Row action — opens the Product Editor for that product.
• States.
  • Loading — ruled placeholder rows in the table.
  • Empty — no products: a ruled panel stating the store has no products yet, with the create control as the primary action.
  • Success — rows render with SKU, price, and availability.
  • Error — the list fails to load: a ruled error panel with a retry control.
  • Recovery — retry re-requests the list; the create control remains available.

Product Editor

• Information and state. The create/edit surface for a single product. Protected. In create mode it starts from empty fields; in edit mode it is populated with the selected product's current data.
• Primary actions. Enter or change product data; save the product.
• Supporting actions. Cancel and return to Products without saving.
• Domain entities. Product (name, image, price, availability, SKU, description).
• Component responsibilities.
  • Product form — hard-edged 2px ink bordered fields for name, image, price, availability, SKU, and description.
  • Save control — rectangular primary-red CTA.
  • Cancel control — rectangular ink-bordered control returning to Products.
  • Error region — ruled inline error band naming the offending field.
• States.
  • Loading — in edit mode, fields render as ruled placeholders while the product is resolved.
  • Empty — in create mode, all fields are empty and the save control is available.
  • Success — the product is persisted; the merchant is returned to Products with the row reflecting the saved data.
  • Error — validation failure or a save failure: a ruled error band names the field or states the save did not complete; entered values are retained.
  • Recovery — the merchant corrects and resaves; a failed save never leaves the product in a partially updated state.

Orders

• Information and state. The merchant's order list within the dashboard. Protected. Shows orders produced by shopper purchases, with the data needed to follow and manage them.
• Primary actions. Browse orders; open an order to follow and manage it; change an order's status.
• Supporting actions. Scan by order reference and total; read the status band per row.
• Domain entities. Order (order reference, line items, total, status, shopper contact and delivery details).
• Component responsibilities.
  • Order table — ruled rows with tabular mono order IDs and totals.
  • Row status band — 6px right-edge colour band: red = needs attention, teal = healthy, ink = neutral.
  • Order detail — ruled panel showing line items, totals, and shopper contact and delivery details.
  • Status control — changes the order's status; the change flips colour instantly with no animation.
• States.
  • Loading — ruled placeholder rows in the table.
  • Empty — no orders: a ruled panel stating no orders have been placed yet.
  • Success — rows render with order reference, total, and status band; a status change is reflected immediately.
  • Error — the list fails to load, or a status change fails: a ruled error band with a retry control; the previous status is retained on failure.
  • Recovery — retry re-requests the list or re-applies the status change.

Integrations

• Information and state. The connection surface between the dashboard and the ايكوتراك وش platform. Protected. Presents the connection as a painted route map on paper — nodes, routes, and Arabic labels — with the live connection state shown as a filled ink node when linked.
• Primary actions. Set up the connection to ايكوتراك وش; review the current connection state.
• Supporting actions. Read the connection state band; re-check the connection.
• Domain entities. Integration connection (connection state, connection configuration).
• Component responsibilities.
  • Painted route map — Scher-style diagrammatic map of ايكوتراك وش ↔ el-bolsep with nodes, routes, and Arabic labels.
  • Connection state node — filled ink node when linked; unfilled when not.
  • Connection form — the configuration fields required to establish the link, with hard-edged 2px ink borders.
  • State band — 6px right-edge colour band: red = needs attention, teal = synced, ink = neutral.
• States.
  • Loading — the map renders with ruled placeholders while the connection state is resolved.
  • Empty — no connection configured: the map shows the el-bolsep node only, with the connection form as the primary action.
  • Success — connection established: the state node is filled ink and the state band reads teal (synced).
  • Error — the connection cannot be established or the state cannot be read: a ruled error band states the failure and the state band reads red (needs attention); entered configuration is retained.
  • Recovery — the merchant may correct the configuration and retry, or re-check the connection state.

3. Functional Requirements

Storefront and Purchase

FR-1 — Browse the store's products (explicit) As a متسوق (عميل المتجر), I should browse the store's products on the public Store page so that I can see what the store sells before deciding to buy.

• Trigger/input: The shopper opens the Store page.
• Observable result: The catalog grid renders the store's published products as hard-bordered poster cards with names and mono prices.
• Access state: Public; no identity required.
• Failure/recovery: If the catalog fails to load, a ruled error panel with a retry control appears; the hero and ticker remain intact and retry re-requests the catalog.
• Continuation: The shopper opens a product or adds it to the cart.

FR-2 — Add a product to the cart (explicit) As a متسوق (عميل المتجر), I should add a product to my cart from the Store page so that I can assemble a purchase.

• Trigger/input: The shopper activates the add-to-cart control on a product card.
• Observable result: The cart summary updates immediately with the line item and the running total.
• Access state: Public; no identity required.
• Failure/recovery: If the add fails, the cart summary is unchanged and a ruled error band states the item was not added.
• Continuation: The shopper continues browsing or proceeds to Checkout.

FR-3 — Complete a purchase (explicit) As a متسوق (عميل المتجر), I should complete my purchase on the Checkout page so that I receive the goods I selected.

• Trigger/input: The shopper proceeds from the Store to Checkout, enters contact and delivery details, and confirms the order.
• Observable result: An order is created and persisted; a confirmation panel shows the order reference in tabular mono and the cart is cleared.
• Access state: Public; no identity required.
• Failure/recovery: If submission fails, a ruled error band states the order was not placed, the entered details are retained, and the confirm control is re-enabled for resubmission. A partially completed order is never presented as placed.
• Continuation: The shopper returns to the Store; the order becomes visible to the merchant in Orders.

FR-4 — See an empty storefront truthfully (required_inference) As a متسوق (عميل المتجر), I should see a truthful state when the store has no products so that I am not shown a broken or misleading catalog.

• Trigger/input: The shopper opens the Store page while no products are published.
• Observable result: A ruled panel states the store has no products yet; the catalog grid is absent.
• Access state: Public; no identity required.
• Failure/recovery: Not applicable; this is the terminal state for an empty catalog.
• Continuation: The shopper may leave or return later.

Merchant Identity

FR-5 — Establish merchant identity by self-service (required_inference) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should create my account on the Sign Up page so that I can begin operating my store.

• Trigger/input: The merchant opens Sign Up and submits registration details.
• Observable result: The account is created, store ownership is bound to the merchant, a session is established, and the merchant is routed to the Dashboard.
• Access state: Sign Up is anonymously reachable; it is the means of obtaining access to the protected back office, not a destination that requires prior access.
• Failure/recovery: Validation failure or an email already in use produces a ruled error band naming the offending field with entered values retained; if the email is already in use, the sign-in link is offered.
• Continuation: The merchant lands on the Dashboard.

FR-6 — Return to the protected back office (required_inference) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should verify my identity on the Login page so that I can reach the dashboard and my protected operational data.

• Trigger/input: The merchant opens Login and submits credentials.
• Observable result: A session is established and the merchant is routed to the Dashboard.
• Access state: Login is anonymously reachable; the Dashboard, Products, Product Editor, Orders, and Integrations are protected and unavailable until identity is verified.
• Failure/recovery: Invalid credentials produce a ruled error band; the password field is cleared, the email is retained, and the merchant may correct and resubmit without the form locking.
• Continuation: The merchant proceeds to the Dashboard.

Dashboard

FR-7 — Read the store's operational summary (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should read the KPI band and status rows on the Dashboard so that I know the state of my store at a glance.

• Trigger/input: The merchant reaches the Dashboard after sign-in or sign-up.
• Observable result: The KPI band renders with tabular mono numerals, and summary rows render with 6px right-edge colour bands (red = needs attention, teal = healthy, ink = neutral).
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: If a summary source fails, only the affected band shows a ruled error row with a retry control; unaffected bands still render, and retry re-requests only the failed band.
• Continuation: The merchant enters Products, Orders, or Integrations from the RTL rail navigation.

FR-8 — See a truthful empty dashboard (required_inference) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should see a truthful state on a newly created store so that I know what to do first.

• Trigger/input: The merchant reaches the Dashboard for a store with no products and no orders.
• Observable result: Ruled panels state that no products and no orders exist yet, each with a control routing to Products or Orders respectively.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: Not applicable; this is the terminal state for an empty store.
• Continuation: The merchant follows a panel control into Products or Orders.

Product Management

FR-9 — Browse the product list (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should browse my products on the Products page so that I can see and manage what the store sells.

• Trigger/input: The merchant enters Products from the dashboard rail.
• Observable result: A ruled product table renders with tabular mono SKUs and prices and a 6px right-edge status band per row.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: If the list fails to load, a ruled error panel with a retry control appears; the create control remains available.
• Continuation: The merchant opens a product in the Product Editor or starts creating a new one.

FR-10 — Create a product (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should create a product in the Product Editor so that it becomes available in my store.

• Trigger/input: The merchant activates the create control on Products and submits product data.
• Observable result: The product is persisted and the merchant returns to Products with the new row reflecting the saved data.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: Validation failure or a save failure produces a ruled error band naming the field or stating the save did not complete; entered values are retained and the merchant may correct and resave. A failed save never leaves the product partially created.
• Continuation: The merchant continues managing products or returns to the Dashboard.

FR-11 — Edit a product (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should edit an existing product's data in the Product Editor so that the store's catalog stays accurate.

• Trigger/input: The merchant opens a product row from Products and changes its data.
• Observable result: The product is persisted and the Products row reflects the saved data.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: Validation failure or a save failure produces a ruled error band; entered values are retained and the merchant may correct and resave. A failed save never leaves the product in a partially updated state.
• Continuation: The merchant returns to Products.

Order Management

FR-12 — Browse and follow orders (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should browse and follow my orders on the Orders page so that I can see what my shoppers have bought.

• Trigger/input: The merchant enters Orders from the dashboard rail.
• Observable result: A ruled order table renders with tabular mono order IDs and totals and a 6px right-edge status band per row; opening an order shows its line items, totals, and shopper contact and delivery details.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: If the list fails to load, a ruled error band with a retry control appears.
• Continuation: The merchant manages an order's status.

FR-13 — Manage an order's status (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should change an order's status on the Orders page so that I can manage fulfillment.

• Trigger/input: The merchant activates the status control on an order.
• Observable result: The order's status changes and its colour band flips instantly with no animation.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: If the status change fails, a ruled error band states the failure and the previous status is retained.
• Continuation: The merchant continues through the order list.

FR-14 — See a truthful empty order list (required_inference) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should see a truthful state when no orders exist so that I am not shown a broken list.

• Trigger/input: The merchant opens Orders while no orders have been placed.
• Observable result: A ruled panel states no orders have been placed yet.
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: Not applicable; this is the terminal state for an empty order list.
• Continuation: The merchant returns to the Dashboard or Products.

ايكوتراك وش Integration

FR-15 — Set up the ايكوتراك وش connection (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should set up the connection between my dashboard and the ايكوتراك وش platform on the Integrations page so that my store is linked to that platform.

• Trigger/input: The merchant enters Integrations from the dashboard rail and submits the connection configuration.
• Observable result: The connection is established; the painted route map's state node becomes a filled ink node and the state band reads teal (synced).
• Access state: Protected; requires a verified merchant session. The ايكوتراك وش platform owns its own side of the connection; el-bolsep owns the configuration and review surface.
• Failure/recovery: If the connection cannot be established, a ruled error band states the failure, the state band reads red (needs attention), and entered configuration is retained for correction and retry.
• Continuation: The merchant reviews the connection state or returns to the Dashboard.

FR-16 — Review the ايكوتراك وش connection state (explicit) As a متجر أونلاين (صاحب المتجر / مدير المتجر), I should review the current connection state on the Integrations page so that I know whether my store is linked.

• Trigger/input: The merchant opens Integrations or re-checks the connection.
• Observable result: The painted route map shows the connection state as a filled ink node when linked, and the state band reads teal (synced) or red (needs attention).
• Access state: Protected; requires a verified merchant session.
• Failure/recovery: If the state cannot be read, a ruled error band states the failure and the state band reads red (needs attention); the merchant may re-check.
• Continuation: The merchant corrects the configuration or returns to the Dashboard.

Persistence and Backend Execution

FR-17 — Persist store state durably (required_inference) As the el-bolsep application, I should persist products, orders, merchant identity, and the integration configuration durably so that every accepted human-facing lifecycle has a stable state to read and resume.

• Trigger/input: Any accepted write — product create/edit, order creation, status change, identity creation, or connection configuration.
• Observable result: The written state is durable and is what the corresponding page reads back on the next visit.
• Access state: Backend execution; no direct human interaction.
• Failure/recovery: A failed write surfaces as the corresponding page's error state and never as a partially applied change.
• Continuation: The affected page's success state renders from the persisted state.

4. User Personas

متجر أونلاين (صاحب المتجر / مدير المتجر)

Product context. The merchant-owner is the person who runs the store. They are the reason the dashboard exists: the requirement thread asks for a professional control room that can be connected to the ايكوتراك وش platform. They work inside the protected back office, not on the public storefront, and their work is operational and continuous rather than a single transaction.

Primary goal. To run a successful store: keep the catalog accurate, follow and manage the orders that come in, and keep the store linked to ايكوتراك وش.

Distinct accepted responsibilities.

• Establishing their own access to the back office through self-service sign-up, and returning through sign-in.
• Reading the dashboard's KPI band and status rows to know the store's state at a glance.
• Browsing the product list and creating or editing product data.
• Browsing, following, and managing orders produced by shopper purchases.
• Setting up and reviewing the connection between the dashboard and the ايكوتراك وش platform.

Relevant inputs and decisions. Product data (name, image, price, availability, SKU, description); order status decisions; the connection configuration for ايكوتراك وش. The merchant decides what the store sells, how orders progress, and whether the store is linked to the external platform.

Interactions with other accepted participants. The merchant is the counterparty to the shopper: every order the shopper places appears in the merchant's Orders page, and every product the merchant publishes appears in the shopper's Store page. The merchant also interacts with the ايكوتراك وش platform through the Integrations page, though the platform's own side of that interaction is owned by the platform.

Observable success. The merchant can sign in and land on a dashboard that reflects the store's real state; a product they save appears in the storefront catalog; an order a shopper places appears in Orders with a status the merchant can change; and the Integrations page shows the ايكوتراك وش connection as linked.

What makes this role distinct. The merchant is the only actor with a durable, protected, store-scoped relationship to the product. Their work is stateful and revisitable — they return to the same store, the same catalog, and the same order history — whereas the shopper's work is a single anonymous visit. The merchant's decisions change what the shopper sees.

متسوق (عميل المتجر)

Product context. The shopper is the customer the storefront serves. They arrive at the public Store page without an account and without any prior relationship to the store. Their entire interaction is anonymous and self-contained.

Primary goal. To complete a purchase from the store.

Distinct accepted responsibilities.

• Browsing the store's products on the public Store page.
• Adding products to a cart.
• Completing a purchase on the Checkout page by entering contact and delivery details and confirming the order.

Relevant inputs and decisions. Which products to buy and in what quantity; their own contact and delivery details; whether to confirm the order.

Interactions with other accepted participants. The shopper is the counterparty to the merchant: the products they browse are the merchant's published catalog, and the order they place becomes a row the merchant follows and manages in Orders. The shopper never interacts with the merchant directly inside the product.

Observable success. The shopper sees the store's products, adds what they want to a cart, confirms the order, and receives a confirmation showing the order reference.

What makes this role distinct. The shopper's work is anonymous, single-visit, and terminal at the confirmation. They hold no account, no store ownership, and no revisitable operational state. Their success is measured by one completed order, not by an ongoing relationship with the store's data.

5. Core User Flows

Flow A — The shopper browses and completes a purchase

1. Starting context. The shopper arrives at the public Store page with no account and no prior session.
2. On Store, the shopper reads the poster hero and the shipping/promo ticker, then scans the catalog grid of hard-bordered product cards with mono prices.
3. The shopper opens a product to see its details.
4. The shopper activates the add-to-cart control. Observable result: the cart summary updates immediately with the line item and the running total.
5. The shopper proceeds to Checkout. Observable result: the order summary renders as ruled rows with tabular mono quantities and totals.
6. On Checkout, the shopper enters contact and delivery details into the hard-edged form.
7. The shopper activates the primary-red confirm control. Observable result: the order is created and persisted, a confirmation panel shows the order reference in tabular mono, and the cart is cleared.
8. Failure/recovery. If submission fails, a ruled error band states the order was not placed, the entered details are retained, and the confirm control is re-enabled. The shopper resubmits without re-entering details. A partially completed order is never presented as placed.
9. Continuation. The shopper returns to Store. The order is now visible to the merchant in Orders.

Flow B — The shopper encounters an empty store

1. Starting context. The shopper arrives at the public Store page while no products are published.
2. Observable result. A ruled panel states the store has no products yet; the catalog grid is absent.
3. Continuation. The shopper may leave or return later. No checkout is possible from an empty cart, and Checkout shows a ruled panel stating there is nothing to check out with a return-to-store control.

Flow C — The merchant establishes access and lands on the dashboard

1. Starting context. A new merchant arrives at the anonymously reachable Sign Up page with no account.
2. On Sign Up, the merchant enters registration details into the hard-edged form and activates the ink submit control.
3. Observable result. The account is created, store ownership is bound to the merchant, a session is established, and the merchant is routed to Dashboard.
4. Failure/recovery. If validation fails or the email is already in use, a ruled error band names the offending field and entered values are retained. If the email is already in use, the sign-in link is offered and the merchant proceeds to Login instead.
5. On Dashboard, the merchant reads the KPI band with tabular mono numerals and the status rows with their 6px right-edge colour bands.
6. Continuation. The merchant enters Products, Orders, or Integrations from the RTL rail navigation.

Flow D — The returning merchant signs in

1. Starting context. A merchant with an existing account arrives at the anonymously reachable Login page.
2. On Login, the merchant enters credentials and activates the ink submit control.
3. Observable result. A session is established and the merchant is routed to Dashboard.
4. Failure/recovery. If the credentials are not accepted, a ruled error band states so, the password field is cleared, and the email is retained. The merchant corrects and resubmits without the form locking.
5. Continuation. The merchant proceeds to Dashboard.

Flow E — The merchant creates a product

1. Starting context. The merchant is signed in and on Dashboard.
2. The merchant enters Products from the RTL rail navigation. Observable result: the ruled product table renders with tabular mono SKUs and prices and a 6px right-edge status band per row.
3. The merchant activates the create control. Observable result: the Product Editor opens in create mode with empty fields.
4. The merchant enters the product's name, image, price, availability, SKU, and description.
5. The merchant activates the primary-red save control. Observable result: the product is persisted and the merchant returns to Products with the new row reflecting the saved data.
6. Failure/recovery. If validation fails or the save fails, a ruled error band names the field or states the save did not complete; entered values are retained and the merchant corrects and resaves. A failed save never leaves the product partially created.
7. Continuation. The product is now visible to shoppers on the public Store page.

Flow F — The merchant edits an existing product

1. Starting context. The merchant is signed in and on Products.
2. The merchant opens a product row. Observable result: the Product Editor opens in edit mode populated with the product's current data.
3. The merchant changes the product's data and activates the save control. Observable result: the product is persisted and the Products row reflects the saved data.
4. Failure/recovery. If validation fails or the save fails, a ruled error band appears, entered values are retained, and the merchant corrects and resaves. A failed save never leaves the product in a partially updated state.
5. Continuation. The merchant returns to Products or to Dashboard.

Flow G — The merchant follows and manages an order

1. Starting context. A shopper has completed Flow A, so an order exists. The merchant is signed in and on Dashboard.
2. The merchant enters Orders from the RTL rail navigation. Observable result: the ruled order table renders with tabular mono order IDs and totals and a 6px right-edge status band per row.
3. The merchant opens an order. Observable result: a ruled detail panel shows the order's line items, totals, and the shopper's contact and delivery details.
4. The merchant activates the status control to change the order's status. Observable result: the status changes and the row's colour band flips instantly with no animation.
5. Failure/recovery. If the status change fails, a ruled error band states the failure and the previous status is retained; the merchant may retry.
6. Continuation. The merchant continues through the order list or returns to Dashboard.

Flow H — The merchant connects the dashboard to ايكوتراك وش

1. Starting context. The merchant is signed in and on Dashboard.
2. The merchant enters Integrations from the RTL rail navigation. Observable result: the painted route map renders showing ايكوتراك وش ↔ el-bolsep as nodes, routes, and Arabic labels; with no connection configured, only the el-bolsep node is shown and the connection form is the primary action.
3. The merchant enters the connection configuration into the hard-edged form and submits it.
4. Observable result. The connection is established; the map's state node becomes a filled ink node and the state band reads teal (synced).
5. Failure/recovery. If the connection cannot be established, a ruled error band states the failure, the state band reads red (needs attention), and the entered configuration is retained. The merchant corrects the configuration and retries.
6. Continuation. The merchant reviews the connection state on a later visit, or returns to Dashboard.

Flow I — The merchant reviews the connection state

1. Starting context. The merchant is signed in and on Dashboard.
2. The merchant enters Integrations. Observable result: the painted route map shows the current connection state as a filled ink node when linked, and the state band reads teal (synced) or red (needs attention).
3. Failure/recovery. If the state cannot be read, a ruled error band states the failure and the state band reads red (needs attention); the merchant may re-check.
4. Continuation. The merchant corrects the configuration or returns to Dashboard.

Flow J — The merchant encounters an empty store

1. Starting context. The merchant has just created a store and lands on Dashboard with no products and no orders.
2. Observable result. Ruled panels state that no products and no orders exist yet, each with a control routing to Products or Orders respectively.
3. Continuation. The merchant follows a panel control into Products to create the first product (Flow E), or into Orders to see the empty order list.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Paula Scher: type-as-image, where words become architecture and colour blocks become wayfinding. The headline idea is "the storefront IS the poster" — the shop's identity is carried by Arabic display type at poster scale, and the dashboard inherits the same systematic poster logic so the admin feels like the same institution as the shop.

Colour tokens

Light mode (the only mode specified by the direction):

Forbidden: any blue or indigo accent (#0057FF, #2563EB, #4F46E5, #7C3AED and neighbours). No blue anywhere in the product.

Typography

Type scale: 1.414 modular, RTL-native — 128 / 72 / 44 / 28 / 20 / 16 / 14. Mobile display 56px → desktop 128px via clamp(3.5rem, 11vw, 8rem).

Forbidden for headings or body: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui.

Shape language

• Hard edges only — zero border-radius on type blocks, colour fields, cards, and buttons.
• Rules are 2px and 4px, always full-bleed to the container edge.
• Buttons are rectangles with 2px ink borders that invert to solid ink on hover.
• Diagonal bands (6° skew) cut across section boundaries.
• No pills, no soft shadows, no gradient blobs. Depth comes from overlapping flat planes and offset colour blocks.

Layout

• A visible 12-column poster grid with thick 2px rule lines printed on the page.
• Storefront hero is a full-bleed type composition: Arabic wordmark stacked over a solid red block that bleeds off the right edge (RTL bleed).
• Product listings are a dense poster grid of 3-up cards with hard borders and mono price tags, never hover-lift.
• Dashboard is the same grid, quieter: a fixed right-side RTL rail nav (Arabic reads right-to-left, so the nav sits on the right), a ruled KPI band across the top with tabular numerals, and colour-coded status rows (red = attention, teal = healthy, ink = neutral).
• Every section is separated by a numbered rule, like a Scher poster's section breaks.

Imagery

Typography is the image. Where photography appears, it is high-contrast, duotone-treated (ink + red) product cutouts on paper or on solid colour blocks, cropped hard to the grid, often bleeding off an edge. The Integrations page carries hand-painted-map energy: a diagrammatic map of ايكوتراك وش ↔ el-bolsep as a painted Scher-style map with routes, nodes, and Arabic labels. Icons are thick-line, single-colour pictograms. No stock people, no 3D, no gradient mesh.

7. Signature Design Concept

The RTL poster hero. The public entry to el-bolsep is a full-bleed poster, not a SaaS hero. The Arabic wordmark 'البُلص' is set in Cairo 900 at clamp(3.5rem, 12vw, 9rem), stacked in two lines and flush to the right edge of the viewport so it reads first in RTL. Behind the wordmark, a solid #D62311 block occupies the right 55% of the viewport and bleeds off the right edge. The left 45% is paper #F2EBDD carrying a short merchant-facing line in IBM Plex Sans Arabic 500 and a rectangular ink CTA 'ابدأ البيع' with a 2px border. A 4px ink rule runs horizontally across the whole hero just under the wordmark, and a mono ticker line — 'ايكوتراك وش · ربط فوري · متجر جاهز' — sits below it in an RTL marquee.

The composition is unmistakably a Scher poster: no centred headline, no subtext stack, no blue button, no gradient. The hero recomposes only accepted content — the store's identity, the merchant-facing entry into the store, and the store's shipping/promo messaging — and introduces no new behavior, page, or destination.

Signature moves carried through the product:

1. RTL poster hero — the Arabic wordmark at poster scale, flush right, overlapping a solid red block that bleeds off the right viewport edge. Type is the hero; no illustration.
2. Printed grid — 2px and 4px ink rules run full-bleed across every section at 12-column positions, visible as part of the design, with small mono section numbers (01 / 02 / 03) in the rule gaps.
3. Colour-block wipe transitions — moving between storefront sections and dashboard views, a solid red or teal plane sweeps across the viewport edge and reveals the next section: a Scher poster cut, not a fade.
4. Status bands in the dashboard — orders and integrations rows are colour-coded by a full-width 6px band on the right edge of each row (red = needs attention, teal = synced, ink = neutral), with tabular IBM Plex Mono numerals for order IDs and totals.
5. Integrations as a painted map — the ايكوتراك وش connection is drawn as a Scher-style painted route map on paper: nodes, hand-painted-looking routes, Arabic labels, with a live connection state shown as a filled ink node when linked.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The Arabic wordmark 'البُلص' set in Cairo 900 at poster scale, flush right, overlapping the solid #D62311 block that bleeds off the right viewport edge.
• Input → transformation → outcome thesis. On load, the wordmark's red underline sweeps right-to-left once (600ms, cubic-bezier(0.2,0.8,0.2,1)), drawing the eye along the RTL reading direction and settling the composition into its final poster state. The motion reveals the store's identity; it does not perform a product action.
• Motion vocabulary. Restrained and typographic. One purposeful loop on the storefront. Section transitions use a colour-block wipe — a solid red or teal plane slides across the viewport edge and reveals the next section behind it. The mono ticker line runs as an RTL marquee beneath the 4px ink rule.
• Composed first frame. Before motion begins, the hero is already a complete Scher poster: wordmark flush right, red block bleeding off the right edge, paper ground on the left with the merchant-facing line and the ink CTA, the 4px ink rule under the wordmark, and the ticker line below it. The first frame is legible and whole with no motion applied.
• Reduced-motion state. Under prefers-reduced-motion, the underline sweep does not run and the hero renders in its settled state. The ticker stops and wraps into a static ruled row, with every item whole and readable.

Dashboard motion. Dashboard interactions are instant (120ms) with no flourish; state changes flip colour, they do not animate. This is a deliberate contrast with the storefront: the control room is instrument-grade and quiet, the shop is loud.

Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. The moving ticker may cross the viewport edge by design; it is judged by whether it actually moves and whether every item becomes fully readable as it passes. Under prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.

9. Non-Functional Requirements

NFR-1 — Arabic RTL is the native reading direction (explicit, from creative direction) The composition must be built for right-to-left flow from the first mark. The dashboard's rail navigation sits on the right; the hero wordmark is flush right; the ticker runs RTL. Rationale: the product is Arabic-first and its audience reads RTL natively.

NFR-2 — Readable text and controls stay whole at every viewport (explicit, from 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 to fit, with no other element covering any part of them. Where a direction, requirement, or brief asks readable text or a control to be cropped, clipped, covered, or run off an edge, it is kept whole and the gesture is carried by imagery or decoration instead. Rationale: legibility and operability are non-negotiable at every supported width.

NFR-3 — Reduced-motion support (explicit, from creative direction) Under prefers-reduced-motion, the hero underline sweep does not run, the ticker stops and wraps into a static ruled row with whole items, and moving/scrollable content becomes statically readable. Rationale: motion must never be a barrier to reading the store or operating the dashboard.

NFR-4 — No blue or indigo anywhere (explicit, from creative direction) The palette is red/teal/ink on paper only. #0057FF, #2563EB, #4F46E5, #7C3AED and neighbours are forbidden. Rationale: the direction explicitly rejects the generic indigo/blue-on-white SaaS template.

NFR-5 — Hard edges only (explicit, from creative direction) Zero border-radius on cards, buttons, inputs, and type blocks. No soft drop shadows, glassmorphism, frosted panels, or gradient meshes. Rationale: the Scher language is flat, high-contrast, and hard-edged.

NFR-6 — Protected back office (required_inference) The Dashboard, Products, Product Editor, Orders, and Integrations are reachable only with a verified merchant session. Rationale: the merchant's operational data and store ownership must remain bound to the correct participant.

NFR-7 — Durable persistence of store state (required_inference) Products, orders, merchant identity, and the integration configuration are persisted durably so that every accepted lifecycle can be read back and resumed. Rationale: the accepted journeys require state that survives across visits and across participants.

NFR-8 — Instant dashboard state changes (explicit, from creative direction) Dashboard interactions complete in 120ms with no decorative animation; state changes flip colour rather than animate. Rationale: the control room must feel instrument-grade.

NFR-9 — External platform boundary (explicit, from source) The ايكوتراك وش platform owns its own interfaces and connection mechanism. el-bolsep owns only the configuration and review surface for the connection. Rationale: the source supplies no interface details for the platform and does not transfer its responsibilities to el-bolsep.

10. Tech Stack

The authoritative source specifies no technology choices. The following are coherent defaults for the accepted behavior and are labeled as such.

• Frontend: React with a custom UI implementation. [Default — not specified by user]
• Backend: Python / FastAPI, providing the persistence and backend execution required by FR-17 and the protected back-office operations. [Default — not specified by user]
• Storage: A relational database for products, orders, merchant identity, and integration configuration. [Default — not specified by user]
• Containerization: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any accepted requirement and is therefore not included. [Default — not specified by user]

The ايكوتراك وش platform is an external system and its technology is not specified by the source and is not chosen here.

11. Assumptions and Constraints

Assumptions

• A-1. The store is a single store owned by a single merchant-owner. The source establishes no multi-store or multi-tenant structure. (narrow assumption)
• A-2. Merchant identity is self-service only. The source establishes no invitation or provisioning path, so Sign Up is the sole identity-establishment route. (required_inference)
• A-3. The shopper completes a purchase without creating an account. The source establishes no shopper account requirement, and the Store and Checkout surfaces are public. (required_inference)
• A-4. The ايكوتراك وش platform exposes some means of connection, but its interfaces and mechanism are not specified by the source and are treated as provider-owned. (narrow assumption)
• A-5. Product data includes at minimum name, image, price, availability, SKU, and description, as these are the fields the accepted product-management lifecycle requires to be usable. (required_inference)
• A-6. Order data includes at minimum an order reference, line items, a total, a status, and the shopper's contact and delivery details, as these are the fields the accepted order-management lifecycle requires to be usable. (required_inference)

Constraints

• C-1. The product is Arabic-first and RTL-native. (explicit)
• C-2. No blue or indigo accent may appear anywhere in the product. (explicit)
• C-3. All surfaces are hard-edged with zero border-radius; no soft shadows, glassmorphism, or gradient meshes. (explicit)
• C-4. The dashboard must be connectable to the ايكوتراك وش platform. (explicit)
• C-5. The dashboard is a professional control room for the merchant, not a shopper-facing surface. (explicit)
• C-6. The ايكوتراك وش platform's own interfaces and behavior remain with that platform and are not implemented by el-bolsep. (explicit)
• C-7. No provisioning or invitation path exists for merchant identity; self-service registration is the only route. (explicit boundary)

12. Glossary

• el-bolsep (البُلص) — The product: an Arabic-first e-commerce store with a professional merchant dashboard that can be connected to the ايكوتراك وش platform.
• المتجر (Store) — The public storefront surface where shoppers browse products and begin a purchase.
• لوحة التحكم (Dashboard) — The protected merchant control room that summarizes store operations and routes the merchant into administrative work.
• صاحب المتجر / مدير المتجر (متجر أونلاين) — The merchant-owner persona who operates the store through the dashboard.
• متسوق (عميل المتجر) — The shopper persona who browses the storefront and completes a purchase.
• ايكوتراك وش — The external platform the dashboard can be connected to. It owns its own interfaces and connection mechanism.
• الربط (Integration connection) — The configured link between the el-bolsep dashboard and the ايكوتراك وش platform, set up and reviewed on the Integrations page.
• حالة الربط (Connection state) — Whether the ايكوتراك وش connection is established; shown as a filled ink node on the painted route map and as a teal (synced) or red (needs attention) state band.
• شريط الحالة (Status band) — The full-width 6px colour band on the right edge of a dashboard row: red = needs attention, teal = healthy/synced, ink = neutral.
• KPI band — The ruled band across the top of the Dashboard carrying tabular mono numerals.
• RTL rail navigation — The fixed right-side navigation rail in the dashboard, placed on the right because Arabic reads right-to-left.
• Poster hero — The full-bleed RTL type composition at the public entry, in which the Arabic wordmark is the hero and no illustration is used.
• Painted route map — The Scher-style diagrammatic map on the Integrations page showing ايكوتراك وش ↔ el-bolsep as nodes, routes, and Arabic labels.
• Tabular mono — IBM Plex Mono numerals set in fixed-width columns for order IDs, SKUs, prices, and totals.
• Colour-block wipe — The section transition in which a solid red or teal plane sweeps across the viewport edge and reveals the next section.