System Requirements Document for plasma-copper

1. Introduction

plasma-copper is the working project name for iMach, an intelligent wholesale buying and selling assistant. Its product intent is to connect wholesale buyers with suitable suppliers and to help sellers find relevant customers — going beyond a listing site or a seller directory by relating product information, buyer needs, prices, and supply terms so that users can find a better supplier, compare offers, and form more effective commercial relationships.

The audience spans small businesses through wholesalers, manufacturers, distributors, shops, trading companies, and organizational buyers. The product focus is wholesale trade. Some businesses are simultaneously buyer and seller, so a user may hold a different role across different goods.

This document is the current, source-bounded specification for the product. It preserves the accepted capabilities, the explicit exclusions of the initial model, and the internationalization direction, and it defines the information architecture, functional requirements, personas, flows, and design direction needed to build the current product.

2. System Overview

plasma-copper is a first-party web application with an application-owned identity layer. Anonymous visitors can reach the public entry surface and a public catalog; authenticated users reach the working surfaces for buying, selling, and both.

Current accepted behavior covers:

• Buyer-side purchase lists for needed and recurring goods, supplier catalog search and viewing, saving catalogs or following product prices, viewing and comparing up-to-date supplier prices, submitting quote requests for one or several goods, receiving and comparing seller offers, and finding new suppliers and contacting them directly.
• A supply board that shows the suppliers and supply terms for a good, letting the buyer examine several sellers' offers by price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms.
• Seller-side digital business catalogs with product management, structured product data (price, stock, brand, unit, packaging, minimum order, specifications), category-appropriate product entry, bulk Excel import and reference-catalog lookup, direct-link/WhatsApp/social/QR catalog sharing, visibility into customers and savers of catalogs or products, receipt of purchase requests relevant to offered goods, quoting price and sales terms in response to inquiries, promoting catalogs and products to new buyers, and marketing/advertising tools for visibility.
• A quote-request flow: buyer specifies one or several goods and required quantity, sends the request to selected suppliers or relevant sellers, sellers view the request and provide price and supply terms, the buyer reviews and compares offers, and the two parties then communicate directly and reach agreement.
• Two-way discovery: sellers can also find potential buyers and requests relevant to their goods.
• A growth model in which a seller receives promotional credit for introducing new users, usable for targeted advertising or featuring a catalog.
• Internationalization: multiple languages, currencies, units of measurement, country and city, and local product attributes; the public catalog is internationally shareable, while each country's supply and demand are shown from that market's real information.

Explicit exclusions in the initial model: plasma-copper is not required to manage payment, final order placement, warehousing, or shipping of goods. Its main purpose is to create commercial connection, not to manage every stage of a transaction. It must not necessarily become a comprehensive accounting, warehousing, or CRM software; its identity is helping find the right commercial counterparty, presenting products, comparing terms, and creating effective connection.

2a. Product Interpretation and Delivery Boundary

plasma-copper is delivered as a first-party application with its own identity and durable state. Buyers and sellers establish their own access through self-service enrollment and return through verification; the public entry and a shared public catalog remain reachable without access, while the working surfaces that hold a user's lists, catalogs, requests, offers, and conversations require an established identity so that this durable, actor-specific state stays bound to the correct participant.

The product deliberately stops at commercial connection. Payment handling, final order placement, warehousing, and shipping are outside the current delivery boundary and are not represented as product capabilities. Likewise, comprehensive accounting, inventory management, and CRM are not part of the product's identity.

Internationalization is a current product direction: language, currency, unit, country/city, and local product attributes are supported, and the public catalog is shareable internationally. However, the suppliers and demand shown for any country must reflect that market's real information.

Future-horizon items — intelligent matching suggestions based on product type, specifications, brand, required volume, price, minimum order, geographic location, delivery terms, and information freshness; and potential revenue models such as targeted advertising, featuring catalogs and products, customer-referral services, and seller marketing tools — are described in the future section and are not part of current page acceptance.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no verified factual inventory is reproduced.

2c. Page Content and Component Coverage

The following pages are the current information architecture. Each page is listed exactly once.

Landing

• Information/state: public product entry presenting iMach as an intelligent wholesale buying and selling assistant that connects buyers with suitable suppliers and helps sellers find relevant customers; the value of relating product information, buyer needs, prices, and supply terms rather than being a listing site or seller directory; the audience span from small businesses to wholesalers, manufacturers, distributors, shops, trading companies, and organizational buyers; the note that some businesses are both buyer and seller.
• Primary actions: enter the product as a buyer or seller (self-service enrollment), return to an existing account, open a shared public catalog.
• Supporting actions: read how the quote-request flow works; read the supply-board and catalog concepts.
• Domain entities: product positioning, audience segments, buyer/seller role duality.
• Component responsibilities: hero with the product proposition and a single primary call to action; role entry points for buyer and seller; explanatory sections for catalog, purchase list, supply board, and quote request; public-catalog entry.
• States: loading (hero and content placeholders); empty (not applicable — static public content); success (content rendered, entry actions available); error (content fetch failure with retry); recovery (retry restores the entry actions).

Login

• Information/state: returning-user verification surface; explains that signing in restores purchase lists, saved catalogs, quote requests, offers, and business data.
• Primary actions: submit credentials to verify identity and return to the account.
• Supporting actions: move to self-service enrollment; recover access when verification fails.
• Domain entities: account identity, session.
• Component responsibilities: credential form; submit control; link to enrollment; error messaging.
• States: loading (submitting); empty (not applicable); success (identity verified, continuation to the intended destination); error (invalid credentials, with a clear message and preserved input); recovery (retry or move to enrollment).

Sign Up

• Information/state: self-service enrollment for buyers, sellers, and dual-role users; explains that a user may act as buyer or seller across different goods; when the visitor arrived from a seller's catalog, states that the referring catalog will be saved by default.
• Primary actions: create an account and choose the initial role context (buyer, seller, or both).
• Supporting actions: accept the referring catalog association when arriving from a catalog link; move to login for existing users.
• Domain entities: account, role context, referring catalog association.
• Component responsibilities: enrollment form; role selection; referral context display; submit control; link to login.
• States: loading (submitting); empty (not applicable); success (account created, referring catalog saved by default when present, continuation into the product); error (validation or creation failure with preserved input); recovery (correct and resubmit, or switch to login).

Dashboard

• Information/state: summary and continuation paths for the current role context — buyer, seller, or both; recent purchase lists, saved catalogs, open quote requests, received offers, relevant purchase requests, and conversations.
• Primary actions: continue into the most relevant working surface for the current role.
• Supporting actions: switch between buyer and seller role context; jump to purchase lists, catalogs, supply board, quote requests, offers, messages, catalog manager, buyer requests, and quote responses.
• Domain entities: purchase list, saved catalog, quote request, offer, purchase request, conversation, role context.
• Component responsibilities: role-context switcher; summary cards per role; continuation links; empty-state guidance for new accounts.
• States: loading (summary placeholders); empty (new account with no lists, catalogs, requests, or offers, with guidance to begin); success (summaries and continuation links rendered); error (partial summary failure isolated per card with retry); recovery (retry the failed card without losing the rest).

Shopping Lists

• Information/state: the buyer's needed and recurring goods, with quantities and any captured requirements; each list item links to relevant suppliers and the supply board for that good.
• Primary actions: create a purchase list; add, edit, and remove goods; set quantity and recurring need.
• Supporting actions: open the supply board for a listed good; start a quote request from one or several listed goods; save a supplier catalog discovered from a list item.
• Domain entities: purchase list, list item, good, quantity, recurring flag.
• Component responsibilities: list collection; list editor; item editor; per-item supplier/supply-board entry; quote-request entry from selection.
• States: loading (list placeholders); empty (no lists yet, with a create prompt); success (lists and items rendered with actions); error (save or load failure with preserved edits); recovery (retry save, restore last consistent list state).

Catalogs

• Information/state: seller catalogs discoverable by search and browsing, with supplier identity and product coverage; indicates which catalogs the buyer has already saved.
• Primary actions: search and view seller catalogs; save a catalog; follow a product's price.
• Supporting actions: open a catalog's products; open the supply board for a product; open price comparison for a product.
• Domain entities: seller catalog, product, saved catalog, followed product.
• Component responsibilities: search and filters; catalog result list; catalog preview; save control; follow-price control.
• States: loading (result skeletons); empty (no results for the query, with query-adjustment guidance); success (results with save/follow state); error (search failure with retry); recovery (retry or broaden the query).

Price Comparison

• Information/state: up-to-date supplier prices for a good, with each price's confirmation status shown so unconfirmed price or stock is never presented as certain.
• Primary actions: compare prices across suppliers for a good.
• Supporting actions: open the supply board for the same good; save a supplier catalog; start a quote request.
• Domain entities: price, supplier, confirmation status, product.
• Component responsibilities: comparison table or list; confirmation-status indicator per price; supplier entry; action to move to supply board or quote request.
• States: loading (comparison placeholders); empty (no comparable prices for the good, with guidance to request quotes); success (prices with confirmation status); error (load failure with retry); recovery (retry, or fall back to the supply board).

Supply Board

• Information/state: the suppliers and supply terms for a good, comparable across price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms; explicitly conveys that a lower price is not always the best option and that seller credibility, quality, and delivery terms matter; shows confirmation status for price and stock.
• Primary actions: examine several sellers' offers for a good across the comparable dimensions.
• Supporting actions: select suppliers to include in a quote request; save a supplier catalog; open direct contact with a supplier; open price comparison.
• Domain entities: supply offer, supplier, price, brand, specifications, minimum order, stock, distance, shipping terms, payment terms, confirmation status, seller credibility.
• Component responsibilities: multi-dimension comparison view; per-offer detail; confirmation-status indicators; supplier selection for quote requests; direct-contact entry.
• States: loading (offer placeholders); empty (no offers for the good, with guidance to broaden the search or request quotes); success (offers rendered with all comparable dimensions and confirmation status); error (load failure with retry); recovery (retry or narrow/broaden the good).

Quote Requests

• Information/state: the buyer's quote requests, each specifying one or several goods and the required quantity, and the selected suppliers or relevant sellers it was sent to; shows request status.
• Primary actions: create a quote request for one or several goods with required quantity; send it to selected suppliers or relevant sellers.
• Supporting actions: start a request from a purchase list item or from the supply board; add or remove goods and quantities before sending; review the recipient set.
• Domain entities: quote request, request line (good, quantity), recipient supplier, request status.
• Component responsibilities: request composer; multi-good line editor; quantity input; recipient selection; send control; request list with status.
• States: loading (request list placeholders); empty (no requests yet, with a create prompt); success (request created and sent, status visible); error (send failure with preserved composition); recovery (retry send or adjust recipients).

Offers

• Information/state: offers received from sellers in response to the buyer's quote requests, comparable across price and supply terms, with confirmation status so unconfirmed price or stock is not shown as certain.
• Primary actions: review and compare received offers.
• Supporting actions: open direct communication with the seller of a chosen offer; return to the originating quote request.
• Domain entities: offer, price, supply terms, confirmation status, originating quote request, seller.
• Component responsibilities: offer list grouped by request; comparison view; confirmation-status indicators; direct-contact entry per offer.
• States: loading (offer placeholders); empty (no offers received yet, with guidance to wait or widen the recipient set); success (offers rendered and comparable); error (load failure with retry); recovery (retry, or return to the quote request to adjust recipients).

Messages

• Information/state: direct buyer–seller conversation following offers, with the context of the related request or offer.
• Primary actions: send and read direct messages with the counterparty.
• Supporting actions: open the related quote request or offer from the conversation; continue to agreement outside the product.
• Domain entities: conversation, message, counterparty, related request/offer.
• Component responsibilities: conversation list; message thread; composer; context link to the related request or offer.
• States: loading (thread placeholders); empty (no conversations yet, with guidance to contact a supplier or respond to a request); success (thread rendered and messages sendable); error (send or load failure with preserved draft); recovery (retry send, restore draft).

Catalog Manager

• Information/state: the seller's digital business catalog and its products, with each product's price, stock, brand, unit, packaging, minimum order, and specifications; shows catalog completeness and which products are offered.
• Primary actions: create and manage the business catalog; add, edit, and remove products.
• Supporting actions: open a product's structured details; open bulk import; open catalog sharing; open audience; open marketing.
• Domain entities: seller catalog, product, price, stock, brand, unit, packaging, minimum order, specifications.
• Component responsibilities: catalog overview; product list; product row actions; entry to product details, import, and sharing.
• States: loading (catalog and product placeholders); empty (no catalog yet, with a create prompt); success (catalog and products rendered with management actions); error (save or load failure with preserved edits); recovery (retry save, restore last consistent catalog state).

Product Details

• Information/state: structured product data whose fields are appropriate to the product's category, covering price, stock, brand, unit, packaging, minimum order, and specifications.
• Primary actions: enter and save category-appropriate product information.
• Supporting actions: look up a product in the reference catalog to prefill fields; return to the catalog manager.
• Domain entities: product, category, category-appropriate attribute set, price, stock, brand, unit, packaging, minimum order, specifications.
• Component responsibilities: category selector; category-driven attribute form; reference-catalog lookup; save control.
• States: loading (form and reference-lookup placeholders); empty (new product with category-driven empty fields); success (product saved with category-appropriate data); error (validation or save failure with preserved input); recovery (correct fields and resubmit, or re-run reference lookup).

Product Import

• Information/state: bulk product entry from Excel and addition of products from the reference catalog, with a preview of what will be imported and per-row validation results.
• Primary actions: upload an Excel file to import products in bulk; add products from the reference catalog.
• Supporting actions: review and correct rows flagged by validation before committing; map columns to product fields.
• Domain entities: import batch, import row, validation result, reference-catalog product.
• Component responsibilities: file upload; column mapping; validation preview; reference-catalog search and selection; commit control.
• States: loading (upload and validation in progress); empty (no file selected, with format guidance); success (rows imported and reflected in the catalog); error (invalid rows or file failure, with per-row reasons); recovery (correct flagged rows and re-commit, or re-upload).

Catalog Sharing

• Information/state: the shareable representation of the seller's catalog — direct link, QR code, and the paths for WhatsApp and social networks — with the public catalog address it resolves to.
• Primary actions: generate and share the catalog's direct link and QR code; share via WhatsApp and social networks.
• Supporting actions: copy the link; preview the public catalog as a visitor sees it.
• Domain entities: catalog share link, QR code, public catalog address, share channel.
• Component responsibilities: link generator; QR renderer; channel share controls; copy control; public preview entry.
• States: loading (link and QR generation in progress); empty (catalog not yet shareable, with guidance to complete the catalog); success (link and QR available and shareable); error (generation failure with retry); recovery (retry generation).

Public Catalog

• Information/state: the publicly reachable view of a seller's catalog and its products, shareable internationally; a visitor can open it and, to access information and up-to-date prices, save it; if the visitor enrolls through the seller's catalog, the referring catalog is saved for them by default.
• Primary actions: open and browse the catalog as a visitor; save the catalog (establishing access when needed to keep it).
• Supporting actions: enroll from the catalog, carrying the referring catalog association; view products and their up-to-date prices once saved.
• Domain entities: public catalog, product, saved catalog, referring catalog association.
• Component responsibilities: public catalog header and product list; save control; enrollment entry that carries the referral; price display with confirmation status.
• States: loading (catalog placeholders); empty (catalog has no published products, with a message); success (catalog rendered; save and enrollment available); error (catalog unavailable or link invalid, with guidance); recovery (retry, or return to the entry surface).

Audience

• Information/state: the customers and the people who have saved the seller's catalog or products, with what they saved.
• Primary actions: view customers and savers of the catalog or products.
• Supporting actions: open direct communication with a saver or customer; open the saved catalog or product they engaged with.
• Domain entities: customer, saver, saved catalog, saved product.
• Component responsibilities: audience list; per-person engagement detail; direct-contact entry.
• States: loading (audience placeholders); empty (no savers or customers yet, with guidance to share the catalog); success (audience rendered with engagement detail); error (load failure with retry); recovery (retry).

Buyer Requests

• Information/state: purchase requests relevant to the goods the seller can offer, with the requested goods, quantities, and requesting buyer context.
• Primary actions: find and receive purchase requests relevant to offered goods.
• Supporting actions: open a request's detail; respond with a quote; open direct communication with the requesting buyer.
• Domain entities: purchase request, requested good, quantity, requesting buyer, relevance to offered goods.
• Component responsibilities: relevant-request list; relevance indication; request detail; respond entry.
• States: loading (request placeholders); empty (no relevant requests yet, with guidance to complete the catalog so relevance can be determined); success (relevant requests rendered with respond actions); error (load failure with retry); recovery (retry).

Quote Responses

• Information/state: the seller's responses to buyer inquiries, each providing price and sales terms for the requested goods; shows which requests have been answered.
• Primary actions: provide price and sales terms in response to an inquiry.
• Supporting actions: open the originating request; revise a response before the buyer acts on it; open direct communication with the buyer.
• Domain entities: quote response, price, sales terms, originating request, response status.
• Component responsibilities: response composer; price and terms fields; request context; submit control; response list with status.
• States: loading (response list placeholders); empty (no inquiries to answer yet, with guidance to review buyer requests); success (response submitted and visible to the buyer); error (submit failure with preserved composition); recovery (retry submit).

Marketing

• Information/state: the seller's promotion of the catalog and products to new buyers and the tools for increasing visibility; shows current promotion activity.
• Primary actions: promote the catalog and products to new buyers; use marketing and advertising tools to increase visibility.
• Supporting actions: open catalog sharing; open promotion credits; open audience to see who engaged.
• Domain entities: promotion, promoted catalog/product, visibility tool, promotion activity.
• Component responsibilities: promotion setup; promoted-item selection; visibility tool list; activity summary.
• States: loading (activity placeholders); empty (no promotion activity yet, with guidance to start); success (promotion configured and activity shown); error (setup or load failure with preserved configuration); recovery (retry).

Buyer Discovery

• Information/state: potential buyers and demand relevant to the seller's goods, so that discovery is not one-directional.
• Primary actions: find potential buyers and requests relevant to the seller's goods.
• Supporting actions: open a potential buyer's context; open a relevant request; open direct communication.
• Domain entities: potential buyer, relevant demand, offered good, relevance basis.
• Component responsibilities: discovery list; relevance indication; buyer/request detail; contact entry.
• States: loading (discovery placeholders); empty (no relevant buyers found yet, with guidance to broaden criteria or complete the catalog); success (potential buyers and demand rendered); error (load failure with retry); recovery (retry or adjust criteria).

Promotion Credits

• Information/state: the promotional credit a seller has earned for introducing new users, and the uses it can be put to — targeted advertising or featuring the catalog.
• Primary actions: view earned promotional credit; apply credit to targeted advertising or to featuring the catalog.
• Supporting actions: open marketing to see promotion activity; open catalog sharing to introduce new users.
• Domain entities: promotional credit, credit-earning referral, credit use (targeted advertising, catalog featuring).
• Component responsibilities: credit balance; credit history; credit-use controls.
• States: loading (balance placeholders); empty (no credit earned yet, with guidance on how credit is earned); success (balance and uses rendered); error (load or apply failure with retry); recovery (retry, restore previous balance display).

Market Settings

• Information/state: the user's market configuration — language, currency, unit of measurement, country and city, and local product attributes — with the rule that each country's supply and demand are shown from that market's real information.
• Primary actions: set language, currency, unit, country/city, and local product attributes.
• Supporting actions: review how the selected market affects displayed supply and demand.
• Domain entities: language, currency, unit of measurement, country, city, local product attribute.
• Component responsibilities: language selector; currency selector; unit selector; country/city selector; local-attribute configuration; save control.
• States: loading (settings placeholders); empty (not applicable — defaults are shown); success (settings saved and applied); error (save failure with preserved selection); recovery (retry save).

Trust Signals

• Information/state: the basis of scores and the confirmation status of price and stock, so that any score or label such as "suitable suggestion" has a clear basis and unconfirmed price or stock is never presented as certain.
• Primary actions: inspect the basis of a score or label and the confirmation status of a price or stock value.
• Supporting actions: open the related supplier, offer, or product; open the supply board or price comparison for the same good.
• Domain entities: score, score basis, confirmation status, price, stock, supplier.
• Component responsibilities: score-basis explanation; confirmation-status legend and indicators; links to the related supplier, offer, or product.
• States: loading (signal placeholders); empty (no signals available for the item, with an explicit statement rather than a fabricated score); success (basis and confirmation status rendered); error (load failure with retry); recovery (retry).

3. Functional Requirements

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

FR-1 — Wholesale connection assistant (explicit). As a wholesale market participant, I should use a product that connects buyers with suitable suppliers and sellers with relevant customers, relating product information, buyer needs, prices, and supply terms rather than acting as a listing site or seller directory, so that I can find a better supplier, compare offers, and form a more effective commercial relationship. Acceptance: the product presents related product, need, price, and supply-term information together; it is not limited to listings or a seller directory.

FR-2 — Purchase lists (explicit). As a wholesale buyer, I should create and manage purchase lists of needed and recurring goods, so that my requirements persist and can be acted on. Acceptance: I can create a list, add/edit/remove goods, record quantity and recurring need, and see the list again on return.

FR-3 — Catalog search and saving (explicit). As a wholesale buyer, I should search and view seller catalogs and save a catalog or follow a product's price, so that I can keep track of relevant suppliers and goods. Acceptance: search returns seller catalogs; saving a catalog and following a product persist and are visible on return.

FR-4 — Up-to-date price viewing and comparison (explicit). As a wholesale buyer, I should view and compare up-to-date supplier prices, so that I can judge current market terms. Acceptance: prices for a good are shown across suppliers with their confirmation status, and unconfirmed price is not presented as certain.

FR-5 — Quote request submission (explicit). As a wholesale buyer, I should submit a quote request for one or several goods, so that selected or relevant sellers can respond. Acceptance: I can specify one or several goods with required quantity, choose selected suppliers or relevant sellers, and send the request; the request and its status are visible afterward.

FR-6 — Offer receipt and comparison (explicit). As a wholesale buyer, I should receive and compare sellers' offers, so that I can evaluate price and supply terms side by side. Acceptance: offers are listed against the originating request and comparable across price and supply terms, with confirmation status shown.

FR-7 — Finding new suppliers and direct contact (explicit). As a wholesale buyer, I should find new suppliers and contact them directly, so that I can pursue a commercial relationship. Acceptance: I can discover suppliers I have not previously engaged and open direct communication with them.

FR-8 — Supply board (explicit). As a wholesale buyer, I should use a supply board that shows the suppliers and supply terms for a good, so that I can examine several sellers' offers by price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms. Acceptance: the supply board presents all listed dimensions per offer; it conveys that a lower price is not always the best option and that seller credibility, quality, and delivery terms matter.

FR-9 — Seller digital catalog (explicit). As a seller/supplier, I should build a digital business catalog and manage its products, so that my offering is presentable and maintainable. Acceptance: I can create a catalog, add/edit/remove products, and see the catalog and its products on return.

FR-10 — Structured product data (explicit). As a seller/supplier, I should record price, stock, brand, unit, packaging, minimum order, and product specifications, so that buyers can evaluate my offering. Acceptance: all listed fields are captured per product and displayed to buyers.

FR-11 — Category-appropriate product entry (explicit). As a seller/supplier, I should enter product information appropriate to the product's category, so that the recorded attributes match the good. Acceptance: the product form adapts its fields to the selected category.

FR-12 — Bulk import and reference catalog (explicit). As a seller/supplier, I should import products in bulk from Excel and add products by searching a reference catalog, so that managing many products is easier. Acceptance: an Excel upload imports products with per-row validation results; reference-catalog search adds a product with prefilled fields.

FR-13 — Catalog sharing (explicit). As a seller/supplier, I should share my catalog by direct link and through WhatsApp, social networks, or QR, so that I can present it to customers. Acceptance: a direct link and QR code are generated, and share paths for WhatsApp and social networks are available.

FR-14 — Public catalog opening and saving (explicit). As a customer, I should open the catalog and save it to access information and up-to-date prices, so that I can keep the supplier's current offering. Acceptance: the catalog is publicly openable; saving it persists the catalog for me and grants access to up-to-date information and prices.

FR-15 — Referring catalog on enrollment (explicit). As a customer who enrolls through a seller's catalog, I should have the referring catalog saved for me by default, so that the supplier I came from is retained. Acceptance: enrollment initiated from a catalog results in that catalog being saved for the new account by default.

FR-16 — Seller visibility into customers and savers (explicit). As a seller/supplier, I should see the customers and the people who saved my catalog or products, so that I know who engaged with my offering. Acceptance: the audience view lists customers and savers with what they saved.

FR-17 — Receiving relevant purchase requests (explicit). As a seller/supplier, I should receive purchase requests relevant to the goods I can offer, so that I can respond to real demand. Acceptance: requests relevant to my offered goods are surfaced with the requested goods and quantities.

FR-18 — Quoting in response to inquiries (explicit). As a seller/supplier, I should provide price and sales terms in response to inquiries, so that the buyer can evaluate my offer. Acceptance: a response with price and sales terms is submitted against the originating request and becomes visible to the buyer.

FR-19 — Promoting catalog and products (explicit). As a seller/supplier, I should promote my catalog and products to new buyers and use marketing and advertising tools to increase visibility, so that I reach more relevant customers. Acceptance: promotion of catalog/products can be configured and marketing/advertising tools are available, with current activity shown.

FR-20 — Quote-request flow (explicit). As a buyer and a seller together, we should complete the inquiry flow — buyer specifies one or several goods and required quantity, sends the request to selected suppliers or relevant sellers, sellers view the request and provide price and supply terms, the buyer reviews and compares offers, and the two parties then communicate directly and reach agreement — so that a commercial connection is formed. Acceptance: each step is observable in the product, and the final direct communication and agreement occur between the two parties.

FR-21 — Initial-model exclusions (explicit). As the product owner, I should keep the initial model free of payment management, final order placement, warehousing, and shipping, so that the product's purpose remains creating commercial connection rather than managing every stage of a transaction. Acceptance: no current page or flow performs payment management, final order placement, warehousing, or shipping.

FR-22 — Two-way discovery (explicit). As a seller/supplier, I should find potential buyers and requests relevant to my goods, so that discovery is not one-directional. Acceptance: a seller can surface potential buyers and relevant demand from their own goods.

FR-23 — Truthful suggestions and scores (explicit). As any user, I should see suggestions based on real information, with unconfirmed price or stock never presented as certain and every score or label such as "suitable suggestion" having a clear basis, so that I can trust what the product shows. Acceptance: confirmation status is visible wherever price or stock is shown; any score or label exposes its basis.

FR-24 — Promotional credit for referrals (explicit). As a seller/supplier, I should receive promotional credit for introducing new users, usable for targeted advertising or featuring my catalog, so that growth is rewarded. Acceptance: earned credit is visible and can be applied to targeted advertising or catalog featuring.

FR-25 — Internationalization (explicit). As a user in any market, I should use the product with multiple languages, currencies, units of measurement, country and city, and local product attributes, so that the product fits my market. Acceptance: language, currency, unit, country/city, and local product attributes can be set and are applied.

FR-26 — International catalog sharing with real market data (explicit). As a user, I should share the public catalog internationally while seeing each country's supply and demand based on that market's real information, so that cross-border sharing does not fabricate local supply or demand. Acceptance: the public catalog is shareable across markets; displayed supply and demand for a country reflect that market's real information.

FR-27 — Role duality (explicit). As a business that is both buyer and seller, I should hold a different role across different goods, so that I can buy some goods and sell others. Acceptance: the same account can act as buyer for some goods and seller for others, and can move between the two role contexts.

FR-28 — Self-service enrollment (required_inference). As a buyer, seller, or dual-role user, I should be able to begin using the product independently without an invitation or prior provisioning, so that an accepted journey is executable. Acceptance: an anonymous visitor can create an account and choose an initial role context; when arriving from a catalog, the referring catalog is saved by default.

FR-29 — Returning verification (required_inference). As a returning user, I should verify my identity to regain access to my durable data and communications, so that my lists, catalogs, requests, offers, and conversations remain bound to me. Acceptance: a returning user can verify identity and reach their previously created state.

FR-30 — Role and access matching before counterparty data (required_inference). As a user, I should have my role context and access matched before counterparty data is displayed or changed, so that each side sees and acts on its own side of a lifecycle. Acceptance: buyer-side and seller-side surfaces present the correct side's data and actions for the current role context.

FR-31 — Backend persistence of marketplace state (required_inference). As the product, I should persist catalogs, purchase lists, prices, requests, offers, and referral relationships, so that accepted journeys have durable state. Acceptance: created lists, catalogs, requests, offers, and referral associations survive and are retrievable.

FR-32 — Referring-catalog attribution (required_inference). As the product, I should attribute the referring catalog to an enrollment that came through a catalog, so that the default save and referral credit are correct. Acceptance: an enrollment from a catalog records the referring catalog, saves it for the new user, and is attributable for referral credit.

FR-33 — Confirmation-status and score-basis display (required_inference). As a user, I should see confirmation status and the basis of a suggestion before any price, stock, or score is treated as certain, so that the product never overstates unverified data. Acceptance: confirmation status appears with price and stock; score or label basis is inspectable.

4. User Personas

خریدار عمده (Wholesale Buyer)

Product context. A wholesale buyer — a small business, shop, trading company, or organizational buyer — who needs to source goods in wholesale quantities. Today this work is done through phone calls, WhatsApp, personal contacts, and internet search, and comparing sellers is time-consuming while price and stock information is not always current.

Primary goal. Find the right supplier for needed goods, compare price and supply terms, and obtain quotes from suitable sellers.

Distinct accepted responsibilities. Maintaining purchase lists of needed and recurring goods; searching and viewing seller catalogs; saving catalogs and following product prices; viewing and comparing up-to-date supplier prices; submitting quote requests for one or several goods; receiving and comparing seller offers; finding new suppliers and contacting them directly; using the supply board to examine several sellers' offers across price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms.

Relevant inputs and decisions. Which goods and quantities are needed; which suppliers to include in a request; how to weigh price against seller credibility, quality, and delivery terms, since a lower price is not always the best option; which offer to pursue.

Interactions with other accepted participants. The buyer sends requests to selected or relevant sellers, receives their offers, and then communicates directly with the chosen seller to reach agreement. The buyer also interacts with sellers' public catalogs as a visitor before saving them.

Observable success. The buyer has a maintained purchase list, has compared suppliers on the supply board, has received and compared offers, and has opened a direct conversation with a chosen seller.

فروشنده / تأمینکننده (Seller / Supplier)

Product context. A manufacturer, wholesaler, distributor, or trading company that needs effective, low-cost tools to present products, attract new customers, find wholesale buyers, receive purchase requests, and retain customers.

Primary goal. Present products through a digital catalog, be discovered by relevant buyers, and respond to real demand with price and sales terms.

Distinct accepted responsibilities. Building a digital business catalog and managing products; recording price, stock, brand, unit, packaging, minimum order, and specifications; entering product data appropriate to the category; importing products in bulk from Excel and adding products from a reference catalog; sharing the catalog by direct link, WhatsApp, social networks, or QR; seeing customers and savers of the catalog or products; receiving purchase requests relevant to offered goods; providing price and sales terms in response to inquiries; promoting the catalog and products and using marketing and advertising tools; finding potential buyers and relevant demand; earning and applying promotional credit for introducing new users.

Relevant inputs and decisions. Which products to publish and at what price, stock, and minimum order; which categories and attributes apply; which requests to answer and on what terms; how to spend promotional credit; how to present the catalog for sharing.

Interactions with other accepted participants. The seller receives requests from buyers, responds with price and sales terms, and then communicates directly with the buyer to reach agreement. The seller also sees the buyers and savers who engaged with the catalog, and can reach out to potential buyers.

Observable success. The catalog is published and shareable, relevant requests have been answered with price and terms, the audience of savers and customers is visible, and earned promotional credit is available for use.

کاربر دو-نقشی (کسبوکار همزمان خریدار و فروشنده)

Product context. A business that is simultaneously a buyer and a seller, holding a different role across different goods — for example, buying raw materials while selling finished goods.

Primary goal. Operate both sides of the marketplace from one account without confusing which role applies to which good.

Distinct accepted responsibilities. Maintaining purchase lists and submitting quote requests for the goods it buys; maintaining a catalog and answering purchase requests for the goods it sells; moving between the two role contexts; using the supply board and offers on the buying side and buyer requests and quote responses on the selling side.

Relevant inputs and decisions. Which goods belong to which role; when to switch context; how to keep buying and selling activity distinct.

Interactions with other accepted participants. As a buyer, it interacts with suppliers; as a seller, it interacts with buyers. It may in principle encounter the same counterparty on either side, and its role context determines which side of the lifecycle it sees.

Observable success. Both the buying and selling responsibilities are usable from one account, and the current role context is clear at all times.

5. Core User Flows

Flow A — Buyer builds a purchase list and sources a good

1. The buyer opens Landing and enters the product as a buyer.
2. If new, the buyer completes Sign Up and chooses the buyer role context; if returning, the buyer completes Login.
3. On Dashboard, the buyer sees the buyer-side summary and opens Shopping Lists.
4. The buyer creates a purchase list and adds the needed and recurring goods with quantities.
5. From a list item, the buyer opens the Supply Board for that good and examines several sellers' offers across price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms, noting that a lower price is not always the best option and that seller credibility, quality, and delivery terms matter.
6. The buyer opens Price Comparison for the same good to compare up-to-date supplier prices, checking each price's confirmation status so unconfirmed price or stock is not treated as certain.
7. The buyer opens Catalogs, searches seller catalogs, and saves the relevant ones or follows a product's price.
8. Result and continuation: the purchase list, saved catalogs, and followed products persist; the buyer can proceed to request quotes (Flow B) or contact a supplier directly (Flow D).
9. Failure/recovery: if a list save fails, the buyer's edits are preserved and the save can be retried; if no offers exist for the good, the buyer is guided to broaden the search or request quotes.

Flow B — Buyer requests quotes and compares offers

1. From Shopping Lists or the Supply Board, the buyer opens Quote Requests.
2. The buyer specifies one or several goods and the required quantity.
3. The buyer selects the suppliers to send the request to, or the relevant sellers, and sends the request.
4. Result: the request is created with a visible status, and the selected sellers can see it.
5. The buyer opens Offers as responses arrive and compares the received offers across price and supply terms, checking confirmation status.
6. Failure/recovery: if sending fails, the composed request is preserved and can be retried or its recipients adjusted; if no offers arrive, the buyer is guided to widen the recipient set or return to the request.
7. Continuation: the buyer selects an offer and proceeds to direct communication (Flow D).

Flow C — Seller publishes a catalog and answers demand

1. The seller opens Landing and enters the product as a seller.
2. If new, the seller completes Sign Up and chooses the seller role context; if returning, the seller completes Login.
3. On Dashboard, the seller sees the seller-side summary and opens Catalog Manager.
4. The seller creates the digital business catalog and adds products.
5. For each product, the seller opens Product Details and records price, stock, brand, unit, packaging, minimum order, and specifications, with the form adapting to the product's category.
6. For many products, the seller opens Product Import, uploads an Excel file, reviews per-row validation results, corrects flagged rows, and commits; alternatively the seller searches the reference catalog and adds products with prefilled fields.
7. The seller opens Catalog Sharing, generates the direct link and QR code, and shares via WhatsApp or social networks.
8. Result and continuation: the catalog is published and publicly reachable; the seller can now receive relevant demand.
9. Failure/recovery: if a product save fails, the entered data is preserved and can be retried; if import rows are invalid, per-row reasons are shown and the corrected rows can be re-committed.

Flow D — Buyer and seller communicate directly and reach agreement

1. From Offers, the buyer selects an offer and opens Messages with that seller; alternatively the seller opens Messages from a Quote Responses entry or from Audience.
2. The buyer and seller exchange direct messages with the related request or offer in context.
3. The two parties discuss and reach agreement on the deal directly.
4. Result: the commercial connection is formed; the product does not manage payment, final order placement, warehousing, or shipping.
5. Failure/recovery: if a message fails to send, the draft is preserved and can be retried.

Flow E — Seller discovers and answers relevant demand

1. On Dashboard, the seller opens Buyer Requests.
2. The seller reviews purchase requests relevant to the goods they can offer, with the requested goods and quantities.
3. The seller opens a request and proceeds to Quote Responses.
4. The seller provides price and sales terms in response to the inquiry and submits.
5. Result: the response is visible to the buyer against the originating request.
6. Failure/recovery: if submission fails, the composed response is preserved and can be retried; if no relevant requests exist, the seller is guided to complete the catalog so relevance can be determined.
7. Continuation: the seller opens Messages to communicate directly with the buyer.

Flow F — Seller finds potential buyers

1. On Dashboard, the seller opens Buyer Discovery.
2. The seller reviews potential buyers and demand relevant to their goods.
3. The seller opens a potential buyer's context or a relevant request and opens direct communication.
4. Result: the seller has surfaced demand beyond inbound requests.
5. Failure/recovery: if no relevant buyers are found, the seller is guided to broaden criteria or complete the catalog.

Flow G — Customer opens a shared catalog and saves it

1. The seller shares the catalog link or QR from Catalog Sharing via WhatsApp, social networks, or direct link.
2. The customer opens the Public Catalog as a visitor and browses the catalog and its products.
3. To access information and up-to-date prices, the customer saves the catalog.
4. If the customer is not yet enrolled, they complete Sign Up from the catalog; the referring catalog is saved for them by default.
5. Result: the catalog is saved for the customer and up-to-date information and prices are accessible.
6. Failure/recovery: if the catalog link is invalid or the catalog is unavailable, the customer is given guidance and can return to the entry surface; if enrollment fails, input is preserved and can be retried.
7. Continuation: the customer can open Catalogs to see the saved catalog alongside others, and proceed to the supply board or a quote request.

Flow H — Seller sees who engaged and promotes the catalog

1. On Dashboard, the seller opens Audience.
2. The seller views the customers and the people who saved the catalog or products, with what they saved.
3. The seller opens Marketing and promotes the catalog and products to new buyers, using the marketing and advertising tools to increase visibility.
4. The seller opens Promotion Credits to see the promotional credit earned for introducing new users.
5. The seller applies credit to targeted advertising or to featuring the catalog.
6. Result: promotion activity and credit use are visible.
7. Failure/recovery: if promotion setup or credit application fails, the configuration is preserved and can be retried.

Flow I — Dual-role user switches between buying and selling

1. The dual-role user signs in and lands on Dashboard.
2. The user switches the role context between buyer and seller.
3. In the buyer context, the user works with Shopping Lists, Supply Board, Quote Requests, and Offers for the goods they buy.
4. In the seller context, the user works with Catalog Manager, Buyer Requests, and Quote Responses for the goods they sell.
5. Result: both sides of the business are operated from one account, with the current role context clear.
6. Continuation: the user can move between contexts at any point without losing either side's state.

Flow J — User configures the market and checks trust signals

1. The user opens Market Settings and sets language, currency, unit of measurement, country/city, and local product attributes.
2. Result: the settings are applied, and displayed supply and demand for a country reflect that market's real information.
3. The user opens Trust Signals to inspect the basis of a score or label and the confirmation status of a price or stock value.
4. Result: any score or label such as "suitable suggestion" shows a clear basis, and unconfirmed price or stock is not presented as certain.
5. Failure/recovery: if settings fail to save, the selection is preserved and can be retried; if no signals are available for an item, the product states this explicitly rather than fabricating a score.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Zaha Hadid, and the headline is "Fluid parametric grandeur for a B2B supply network." The direction translates into the following concrete tokens.

Mode. Dark mode as the primary and only required mode.

Colour tokens by role.

Proportions. 70% dark ground, 20% silver/charcoal surfaces, 8% champagne-gold, 2% teal accent.

Typography. Headings use Josefin Sans in light-to-regular weights with wide tracking at large sizes; title case for editorial headlines and all-caps for micro-labels. Headlines are set at 56px mobile to 128px desktop with tight leading and generous letter-spacing, feeling architectural rather than loud. Body uses Jost. The scale is a 1.25 modular scale: 128 / 80 / 48 / 28 / 18 / 16. Micro-labels use 12px all-caps with 0.12em tracking. Body text uses Jost 400 at 16–18px for readable Persian and Latin copy.

Shape language. Sweeping continuous curves; soft capsule and lens-like containers; curved section boundaries that flow into one another. Cards use asymmetric rounded corners (for example 32px top-left, 8px bottom-right) to suggest motion frozen in form. No hard 90-degree boxes; every container has at least one flowing edge. Thin luminous strokes (1px teal or champagne) trace connection lines between supplier and buyer nodes.

Layout. Asymmetric editorial grid with a dominant curved hero that bleeds off the right edge. Sections are separated by diagonal or curved flow lines rather than straight rules. The catalog and supply board use a modular but fluid grid where supplier cards are staggered in height, not a uniform grid of identical cards. Navigation is a slim vertical rail on desktop that curves into a bottom bar on mobile, with the active section highlighted by a champagne-gold arc.

Imagery style. Abstract 3D forms derived from the product's own data: curved ribbons representing supply chains, luminous node clusters for suppliers, and flowing particle fields for price movement. No stock photography of people shaking hands. Macro renders of engineered surfaces (brushed metal, glass, topographic lines) appear as section dividers. The catalog uses clean product silhouettes on dark grounds with a single champagne rim light.

Forbidden. Centered headline with subtext and a blue gradient button; uniform grid of identical hover-lift cards; blue-indigo primary colors on white or near-white backgrounds; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body; gradient-blob hero or abstract soft blobs without structure; stock photography of handshakes or generic office scenes; flat 2D illustration that ignores the muse's dimensional language; excessive bounce or playful springy motion that undermines commercial seriousness. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Readable-content rule. 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 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. With prefers-reduced-motion, a usable static arrangement is provided: items wrap into rows or allow horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

The public entry is a full-bleed dark scene where a large 3D parametric ribbon sweeps from the lower-left to the upper-right, built from thin champagne and teal lines that connect glowing supplier nodes. The ribbon is the product's own metaphor made visible: a supply network in continuous motion rather than a static directory.

The headline — the product proposition that iMach connects wholesale buyers with suitable suppliers and helps sellers find relevant customers — is set in Josefin Sans light at 56px mobile to 128px desktop, placed asymmetrically in the upper-left quadrant, overlapping the ribbon's negative space. A single champagne-gold call-to-action button sits below the headline, pinned to the left edge of the type block, offering the accepted entry actions: begin as a buyer or seller, or return to an existing account. The background is a deep charcoal gradient from #0B0E12 to #151A21, with the 3D ribbon rendered in WebGL.

The concept recomposes only accepted content, states, and controls: the product proposition, the buyer/seller entry actions, the return action, and the public-catalog entry. It introduces no new behavior, page, or destination. There is no centered headline, no gradient blob, and no blue button.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

Focal subject. A large 3D parametric ribbon sweeping from the lower-left to the upper-right, made of thin champagne and teal lines connecting glowing supplier nodes — the product's supply network rendered as a real-time object.

Input → transformation → outcome thesis. As the visitor arrives and scrolls, the ribbon's slow continuous orbit and the scroll-linked parallax between foreground supplier cards and background flow lines transform a static proposition into a sensed living network; the outcome is that the visitor perceives iMach as connected commercial infrastructure and reaches the accepted entry actions — begin as buyer or seller, or return.

Motion vocabulary. Slow continuous orbit of the 3D supply-network sculpture; scroll-linked parallax moving foreground supplier cards at a different rate than the background flow lines; price ticks counting up with a needle-sweep easing; hover on a supplier card gently arcing a connection line toward the buyer's list panel; section transitions using a diagonal flow line that sweeps across the viewport as the user scrolls, revealing the next section from behind it.

Composed first frame. The ribbon enters from the lower-left, its champagne and teal lines already connecting several glowing nodes; the headline sits in the upper-left quadrant overlapping the ribbon's negative space; the champagne-gold call-to-action is pinned to the left edge of the type block; the background is the deep charcoal gradient from #0B0E12 to #151A21.

Reduced-motion state. With prefers-reduced-motion, the orbit freezes and a static network diagram is shown; parallax and needle-sweep counting are disabled and values are shown at rest; the headline, call-to-action, and all readable text and controls remain whole and fully visible.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The hero dimensionality is webgl, so a real-time 3D hero is expected. The scene is one crafted object: a parametric ribbon of thin champagne and teal lines connecting a compact cluster of glowing supplier nodes, slowly orbiting in a deep charcoal space. The scene shows the product's defining state — a supply network connecting suppliers and buyers — and is built from the product's own data metaphor rather than a generic shape. It must not cover any readable text or control; the headline and call-to-action remain whole and unobstructed at 375px, 768px, and 1280px.

9. Non-Functional Requirements

NFR-1 — Durable marketplace state (required_inference). Catalogs, purchase lists, prices, quote requests, offers, referral relationships, and conversations must persist so that accepted journeys have durable state. Rationale: accepted journeys create durable actor-specific state that must survive return visits.

NFR-2 — Truthful data presentation (explicit). Wherever price or stock is shown, its confirmation status must be visible, and no unconfirmed price or stock may be presented as certain; any score or label such as "suitable suggestion" must expose a clear basis. Rationale: explicit source constraint.

NFR-3 — Real market data per country (explicit). Displayed supply and demand for a country must reflect that market's real information. Rationale: explicit source constraint.

NFR-4 — Internationalization support (explicit). The product must support multiple languages, currencies, units of measurement, country and city, and local product attributes, and the public catalog must be internationally shareable. Rationale: explicit source constraint.

NFR-5 — Category-driven product schema (explicit). Product information entry must adapt to the product's category. Rationale: explicit source constraint.

NFR-6 — Access continuity (required_inference). Durable actor-specific state must remain bound to the correct participant, requiring identity establishment on first use and verification on return. Rationale: indispensable for the accepted durable-state journeys.

NFR-7 — Readable content at all viewports (direction). Headlines, labels, numbers, card text, and controls must remain whole and unobstructed at 375px, 768px, and 1280px, and a usable static arrangement must be provided under prefers-reduced-motion. Rationale: creative direction requirement.

NFR-8 — Motion accessibility (direction). All motion must respect prefers-reduced-motion by freezing the orbit and showing a static network diagram. Rationale: creative direction requirement.

10. Tech Stack

• Frontend: React web application with a WebGL/R3F hero for the public entry, per the creative direction's webgl hero dimensionality.
• Backend: Python / FastAPI service hosting the marketplace APIs for catalogs, purchase lists, prices, quote requests, offers, conversations, referral attribution, and market settings.
• Storage: a persistent database for durable marketplace state (accounts, catalogs, products, lists, requests, offers, messages, referral relationships, market settings).
• Cache/queue: Redis for session/continuity support and for background work such as import validation and price/stock freshness tracking.
• Packaging and deployment: Docker and docker-compose for the application services.

No source-specified technology was overridden; the stack above reflects the accepted delivery shape (first-party custom UI, application-owned identity, backend integration, durable state, Redis).

11. Assumptions and Constraints

Assumptions.

• A1 [Assumption — required_inference] Buyers and sellers establish their own access through self-service enrollment and return through verification, because accepted journeys create durable actor-specific state that must remain bound to the correct participant.
• A2 [Assumption — required_inference] The public entry and the public catalog are reachable without access, while working surfaces holding a user's lists, catalogs, requests, offers, and conversations require an established identity.
• A3 [Assumption — required_inference] A user's role context (buyer, seller, or both) determines which side of a lifecycle is presented; this is role-context matching, not differentiated permission over shared state.
• A4 [Assumption — required_inference] An enrollment initiated from a catalog records the referring catalog, saves it for the new user by default, and is attributable for referral credit.
• A5 [Assumption — required_inference] Confirmation status and score basis are stored and displayed with price, stock, and any score or label.

Constraints.

• C1 (explicit) In the initial model, plasma-copper is not required to manage payment, final order placement, warehousing, or shipping; its main purpose is creating commercial connection, not managing every stage of a transaction.
• C2 (explicit) plasma-copper must not necessarily become a comprehensive accounting, warehousing, or CRM software; its identity is helping find the right commercial counterparty, presenting products, comparing terms, and creating effective connection.
• C3 (explicit) Suggestions must be based on real information; if price or stock is unconfirmed, the system must not present it as certain, and any score or label such as "suitable suggestion" must have a clear basis.
• C4 (explicit) Each country's suppliers and demand must be displayed based on that market's real information.
• C5 (explicit) The current product architecture, section names, and implementation approach are not necessarily final decisions, and proposing alternative solutions is permitted.
• C6 (direction) The generic indigo/blue-on-white SaaS template is forbidden for this project.

Future horizon (not current acceptance).

• F1 In the future, the system can suggest suitable connections based on product type, specifications, brand, required volume, price, minimum order, geographic location, delivery terms, and information freshness.
• F2 Potential future revenue models include targeted advertising, featuring catalogs and products, customer-referral services, and marketing tools for sellers.
• F3 The initial focus is user growth, creating real commercial connections, and increasing continuous use; the goal is a globally extensible product with gradually forming active buying and selling networks in different countries.

12. Glossary

• iMach / plasma-copper: the intelligent wholesale buying and selling assistant specified in this document; plasma-copper is the working project name.
• Wholesale buyer: a business or organizational buyer sourcing goods in wholesale quantities.
• Seller / supplier: a manufacturer, wholesaler, distributor, or trading company offering goods.
• Dual-role user: a business that is simultaneously buyer and seller, holding a different role across different goods.
• Purchase list: a buyer's maintained collection of needed and recurring goods with quantities.
• Catalog: a seller's digital business catalog of products with structured data.
• Public catalog: the publicly reachable, internationally shareable view of a seller's catalog.
• Saved catalog: a catalog a customer has saved to access information and up-to-date prices.
• Followed product: a product whose price a buyer tracks.
• Supply board: the view showing the suppliers and supply terms for a good, comparable across price, brand, specifications, minimum order, stock, distance, shipping terms, and payment terms.
• Quote request: a buyer's request for one or several goods with required quantity, sent to selected suppliers or relevant sellers.
• Offer: a seller's response to a quote request, providing price and supply terms.
• Quote response: the seller-side act of providing price and sales terms in response to an inquiry.

• Purchase request: a buyer's stated demand surfaced to sellers whose offered goods are relevant.
• Confirmation status: the indication of whether a price or stock value has been confirmed, so unconfirmed data is not presented as certain.
• Score basis: the explicit basis for any score or label such as "suitable suggestion."
• Promotional credit: credit a seller earns for introducing new users, usable for targeted advertising or featuring a catalog.
• Reference catalog: a catalog used to look up and prefill product information.
• Market settings: the user's language, currency, unit of measurement, country/city, and local product attributes.