System Requirements Document for indigo-4

1. Introduction

دليل اليمن (project code: indigo-4) is a comprehensive Arabic-language application for searching and reaching the best professional and craft services across all governorates of Yemen. In one touch, a user searches for a service, compares options, and requests what they need immediately.

The product intent is relief and trustworthy order: a household in Sana'a whose refrigerator, wiring, or water pipe has failed opens the app on a modest phone, often on a weak connection, and needs calm legibility, verified providers, and the sense that the app knows the neighbourhood by name. The app serves two audiences:

• باحث عن خدمة (مستخدم التطبيق) — the service seeker who searches, browses categories, compares verified and rated nearby providers, calls a provider directly or submits a quick service request to receive offers, tracks past and current requests, saves favourite providers, and manages profile data.
• مزود خدمة مهنية/حرفية — the professional/craft service provider who appears in the nearby-services listing with centre name, verification mark, user rating, availability status, and exact service type and location; receives quick service requests from seekers in the area, submits offers on them, and receives direct calls through the call button.

The interface is deliberately quiet: unbleached paper ground, hairline rules instead of boxes, one amber instrument accent for the urgent order action, and a functional green reserved solely for the call action.

2. System Overview

دليل اليمن is delivered as a first-party application with custom UI and application-owned identity. The current delivery covers:

• A public entry surface (الرئيسية) that presents the wordmark, the central keyword search bar, the quick service request action (+ اطلب خدمة الآن), the main category grid, the خدمات قريبة section, and the آخر تحديث data-sync indicator.
• Keyword search across service name (e.g. "صيانة"), activity type (e.g. "ورشة سيارات"), and area name (e.g. "حدة، صنعاء").
• A quick service request flow that submits an urgent request and receives offers from available providers in the requester's area.
• Eight main service categories with clear icons: صيانة، جوالات، كمبيوتر، طاقة شمسية، كهرباء، سباكة، تكييف وتبريد، نقل.
• A خدمات قريبة section that automatically shows the best verified providers geographically near the user, each with provider name, verification mark (✓ موثق), user star rating, availability status (مفتوح الآن), service type and exact location, and a green اتصال button for direct contact.
• A bottom navigation bar with four destinations: الرئيسية، الطلبات، المفضلة، الحساب.
• Request tracking for previous and current service requests, favourite provider saving, and profile data management.
• Coverage of the various Yemeni governorates and cities (such as Sana'a).

Actors are the two accepted human personas above; the external services API that supplies provider data is a non-persona system actor owned outside the product.

2a. Product Interpretation and Delivery Boundary

Current delivery. Everything described in this document is current: the public entry surface, keyword search, quick service request with provider offers, the eight categories, the nearby verified-provider listing with its full detail set and direct call action, the last-sync indicator, the four-destination bottom navigation, request tracking, favourites, and profile management.

Access ownership. The application owns identity. The public entry surface, keyword search, category browsing, and the nearby-provider listing are reachable without signing in, because a person with a broken appliance must be able to find and call a provider immediately. The destinations that carry durable, actor-specific state — submitting a service request, receiving and submitting offers, tracking requests, favourites, and profile data — require the user to be signed in, and the identity established at first use is what binds a request, an offer, a favourite, or a profile to the correct participant. First use is self-service registration; returning use is verification of the same identity. No invitation, provisioning, or deployment bootstrap is specified, and none is added.

Role distinction. The system distinguishes the identity of the request owner from the identity of the service provider so that requests and offers are attributed to the correct side. This is an attribution boundary required by the accepted request-and-offer lifecycle, not a general permission system over shared product state.

Boundaries and exclusions. The provider data set is synchronized through an external API; the product displays the last synchronization time rather than owning the upstream data. No payment, no in-app messaging, no provider-side profile editing surface, no review-writing surface, and no map view are specified by the source and none are added. The app is presented as a mobile application with a bottom navigation bar; the desktop presentation is a single centered reading column of the same content.

2b. Source Content Inventory

The authoritative source supplies the following concrete interface facts, preserved exactly:

• Live example provider in the خدمات قريبة section: مركز الأمان للصيانة in صنعاء - التحرير.
• Example verification mark: ✓ موثق.
• Example user rating: 4.8 نجمة.
• Example availability status: مفتوح الآن.
• Example service type and location detail: صيانة and صنعاء - التحرير.
• Example search terms: "صيانة" (service name), "ورشة سيارات" (activity type), "حدة، صنعاء" (area name).
• The eight category entries with their icons and descriptions: -\x20\xf0\x9f\x94\xa7 صيانة: صيانة منزلية وعامة. -\x20\xf0\x9f\x93\xb1 جوالات: مراكز بيع وصيانة الهواتف الذكية. -\x20\xf0\x9f\x92\xbb كمبيوتر: صيانة ومستلزمات الحواسيب. -\x20\xe2\x98\x80️ طاقة شمسية: متخصصون في أنظمة الطاقة المتجددة. -\x20\xe2\x9a\xa1 كهرباء: فنيو كهرباء معتمدون. -\x20\xf0\x9f\x94\xa7 سباكة: خدمات سباكة وتمديدات مائية. -\x20\xe2\x9d\x84️ تكييف وتبريد: تركيب وصيانة مكيفات وثلاجات. -\x20\xf0\x9f\x9a\x9a نقل: خدمات نقل العفش والبضائع.
• The four bottom-navigation destinations with their icons:\x20\xf0\x9f\x8f\xa0 الرئيسية،\x20\xf0\x9f\x93\x8b الطلبات،\x20\xe2\x9d\xa4️ المفضلة،\x20\xf0\x9f\x91\xa4 الحساب.
• The quick request action label: + اطلب خدمة الآن.
• The direct contact action:\x20\xf0\x9f\x9f\xa2 اتصال.
• The data freshness indicator: آخر تحديث.

2c. Page Content and Component Coverage

الرئيسية

• Information and state: the Arabic wordmark دليل اليمن; one sentence of muted body copy naming the promise (البحث عن الخدمات المهنية والحرفية في جميع محافظات اليمن); the central keyword search bar; the quick request action + اطلب خدمة الآن; the eight-tile category grid; the خدمات قريبة section; the آخر تحديث indicator showing the last time data was synchronized through the API.
• Primary actions: type a keyword into the search bar and submit; tap + اطلب خدمة الآن; tap a category tile; tap a provider row; tap the green اتصال button on a provider row.
• Supporting actions: scroll to reveal sections; tap a bottom-navigation destination.
• Domain entities: service category (name, icon, description), provider (centre name, verification mark, star rating, availability status, service type, exact location, phone number), data-sync timestamp.
• Component responsibilities: wordmark band with a continuous hairline rule running edge-to-edge and bleeding off the right side; search field rendered as a full-width ruled line with a thin magnifier pictogram at the right and the placeholder ابحث عن خدمة، نشاط، أو منطقة…; amber solid block action for + اطلب خدمة الآن; square pictogram category plates with hairline borders and 12px tracked labels beneath; ruled provider ledger rows for خدمات قريبة; hairline-topped bottom navigation bar of four labeled pictograms.
• States: loading — the nearby-provider ledger shows ruled placeholder rows while the API sync is in flight; empty — when no verified provider is near the user, the section states that plainly and offers the search bar and category grid as the next step; success — provider rows render with name, ✓ موثق stamp, mono rating numeral, availability dot, area, and green اتصال button; error — when the API sync fails, the آخر تحديث indicator shows the last successful sync time and the section offers a retry; recovery — retry re-requests the provider data and restores the ledger.

Login

• Information and state: the returning-user verification surface; the identity being verified is the same identity established at first use.
• Primary actions: enter credentials and submit; move to Sign Up if no identity exists yet.
• Supporting actions: return to الرئيسية without signing in.
• Domain entities: account identity, session.
• Component responsibilities: ruled input lines in the same paper language as the entry surface; a single ink submit block; a hairline link to Sign Up.
• States: loading — submit block shows an in-progress state; empty — fields blank with placeholders; success — the user lands on the destination they were seeking (الطلبات، المفضلة، الحساب، طلب خدمة، or العروض); error — incorrect credentials are stated plainly without revealing which field was wrong; recovery — the user may retry or move to Sign Up.

Sign Up

• Information and state: the self-service first-use identity establishment surface for both the service seeker and the service provider; the chosen role determines which protected destinations the identity can reach.
• Primary actions: enter the required identity details, choose the role (باحث عن خدمة / مزود خدمة), and submit.
• Supporting actions: move to Login if an identity already exists.
• Domain entities: account identity, role (seeker or provider), profile data.
• Component responsibilities: ruled input lines; a role selection control; a single ink submit block; a hairline link to Login.
• States: loading — submit block shows an in-progress state; empty — fields blank with placeholders; success — the identity is established and the user continues to the destination that required it; error — missing or invalid required details are stated inline; recovery — the user corrects the fields and resubmits.

البحث

• Information and state: the keyword query and the matching results; the query may be a service name (e.g. "صيانة"), an activity type (e.g. "ورشة سيارات"), or an area name (e.g. "حدة، صنعاء").
• Primary actions: enter or refine the keyword; open a matching provider's details; tap the green اتصال button.
• Supporting actions: clear the query; return to الرئيسية.
• Domain entities: search query, provider, service category, area.
• Component responsibilities: the same ruled search line as the entry surface; results presented as ruled ledger rows carrying provider name, ✓ موثق stamp, mono rating numeral, availability dot, service type, and area.
• States: loading — ruled placeholder rows while results are fetched; empty — a plain statement that no provider matches the keyword, with the query preserved for editing; success — matching rows render; error — a failed search is stated plainly with a retry; recovery — retry or edit the query.

الفئات

• Information and state: the eight main categories with their icons and descriptions —\x20\xf0\x9f\x94\xa7 صيانة (صيانة منزلية وعامة)،\x20\xf0\x9f\x93\xb1 جوالات (مراكز بيع وصيانة الهواتف الذكية)،\x20\xf0\x9f\x92\xbb كمبيوتر (صيانة ومستلزمات الحواسيب)،\x20\xe2\x98\x80️ طاقة شمسية (متخصصون في أنظمة الطاقة المتجددة)،\x20\xe2\x9a\xa1 كهرباء (فنيو كهرباء معتمدون)،\x20\xf0\x9f\x94\xa7 سباكة (خدمات سباكة وتمديدات مائية)،\x20\xe2\x9d\x84️ تكييف وتبريد (تركيب وصيانة مكيفات وثلاجات)،\x20\xf0\x9f\x9a\x9a نقل (خدمات نقل العفش والبضائع).
• Primary actions: select a category to see its providers.
• Supporting actions: return to الرئيسية.
• Domain entities: service category (name, icon, description), provider.
• Component responsibilities: square pictogram plates with hairline borders, label beneath in 12px tracked caps, plate inverting to ink with the glyph knocked out in paper-white on hover; the selected category's providers rendered as ruled ledger rows.
• States: loading — placeholder plates or rows while the category's providers load; empty — a category with no current provider states that plainly; success — the category's verified providers render with the full detail set; error — a failed load is stated plainly with a retry; recovery — retry restores the list.

الخدمات القريبة

• Information and state: the automatically assembled list of the best verified providers geographically near the user, each row carrying provider name (e.g. مركز الأمان للصيانة), verification mark (✓ موثق), user star rating (e.g. 4.8 نجمة), availability status (e.g. مفتوح الآن), service type (e.g. صيانة), exact location (e.g. صنعاء - التحرير), and the آخر تحديث indicator.
• Primary actions: tap the green اتصال button to call the provider directly; open a provider's full details.
• Supporting actions: save a provider to المفضلة; submit a quick request from this context.
• Domain entities: provider, verification mark, star rating, availability status, service type, exact location, phone number, data-sync timestamp.
• Component responsibilities: ruled ledger rows on one baseline — name + stamp + mono rating numeral + availability dot + area — with the green اتصال button pinned to the right edge of the row, separated by hairlines only; the square ink stamp with a thin double border reading ✓ موثق rotated 3 degrees beside the provider name; the availability dot breathing on a 3s cycle; the آخر تحديث timestamp crossfading when it updates.
• States: loading — ruled placeholder rows while the API sync is in flight; empty — no verified provider is near the user, stated plainly with the search bar and category grid offered as the next step; success — rows render with the complete detail set; error — the API sync failed, the last successful sync time remains visible, and a retry is offered; recovery — retry re-requests the provider data.

طلب خدمة

• Information and state: the quick service request being composed — the service needed, the area, and the requester's contact details — and, after submission, the offers received from available providers in the requester's area.
• Primary actions: submit the quick request; review a received offer; accept an offer.
• Supporting actions: return to الرئيسية; open الطلبات to follow the request.
• Domain entities: service request (service needed, area, contact details, status), offer (provider, terms, status).
• Component responsibilities: ruled input lines for the request details; a single ink submit block; received offers rendered as ruled ledger rows carrying provider name, ✓ موثق stamp, mono rating numeral, availability dot, and area.
• States: loading — submit block shows an in-progress state and the offers area shows ruled placeholders; empty — before submission the form is blank; after submission with no offers yet, the page states that offers have not yet arrived; success — the request is submitted and attributed to the requester's identity, and arriving offers render; error — a failed submission is stated plainly with the entered details preserved; recovery — resubmit, or wait and refresh the offers area.

العروض

• Information and state: the service provider's view of available quick service requests in the provider's area, and the offers the provider has submitted on them.
• Primary actions: open an available request; submit an offer on it.
• Supporting actions: review the provider's own submitted offers and their status.
• Domain entities: service request (service needed, area, status), offer (provider, terms, status).
• Component responsibilities: ruled ledger rows for available requests carrying service type, area, and request status; ruled input lines for composing an offer; a single ink submit block.
• States: loading — ruled placeholder rows while available requests load; empty — no available request in the provider's area is stated plainly; success — the offer is submitted and attributed to the provider's identity, and the request appears in the provider's submitted-offers list; error — a failed offer submission is stated plainly with the entered terms preserved; recovery — resubmit the offer.

الطلبات

• Information and state: the previous and current service requests with their statuses, for the signed-in identity — the seeker's own requests and the provider's own submitted offers and their outcomes.
• Primary actions: open a request to see its current status and its offers; accept an offer on the seeker's own request.
• Supporting actions: return to الرئيسية; open طلب خدمة to create a new request.
• Domain entities: service request (service needed, area, status, timestamp), offer (provider, terms, status).
• Component responsibilities: ruled ledger rows carrying request service type, area, status, and timestamp; each row expandable to its offers.
• States: loading — ruled placeholder rows while requests load; empty — no previous or current request is stated plainly with the quick request action offered as the next step; success — requests render with their current statuses; error — a failed load is stated plainly with a retry; recovery — retry restores the list.

المفضلة

• Information and state: the providers the signed-in seeker has saved for future access, each with the full provider detail set.
• Primary actions: open a saved provider; tap the green اتصال button; remove a provider from favourites.
• Supporting actions: return to الرئيسية; open الخدمات القريبة to find more providers.
• Domain entities: favourite (seeker identity, provider), provider (centre name, verification mark, star rating, availability status, service type, exact location, phone number).
• Component responsibilities: ruled ledger rows identical in language to خدمات قريبة, with the green اتصال button pinned right and a hairline removal control.
• States: loading — ruled placeholder rows while favourites load; empty — no saved provider is stated plainly with the nearby listing offered as the next step; success — saved providers render with the full detail set; error — a failed load is stated plainly with a retry; recovery — retry restores the list.

الحساب

• Information and state: the signed-in user's profile data — the identity details entered at first use and the role (باحث عن خدمة / مزود خدمة) that determines which protected destinations the identity reaches.
• Primary actions: edit profile data and save.
• Supporting actions: sign out; return to الرئيسية.
• Domain entities: account identity, role, profile data.
• Component responsibilities: ruled input lines for each profile field; a single ink save block; a hairline sign-out control.
• States: loading — fields show ruled placeholders while profile data loads; empty — a field with no stored value shows its placeholder; success — the saved profile data is shown and confirmed; error — a failed save is stated plainly with the entered values preserved; recovery — correct and resave.

3. Functional Requirements

FR-1 — Comprehensive service directory across Yemeni governorates (explicit) As a باحث عن خدمة, I should use دليل اليمن to search and reach the best professional and craft services across all governorates of Yemen, so that I can find what I need wherever I am.

• Trigger/input: opening the application.
• Observable result: the entry surface presents the wordmark, the search bar, the quick request action, the category grid, and the nearby-provider section.
• Access state: reachable without signing in.
• Failure/recovery: if the provider data cannot be synchronized, the last successful sync time remains visible and a retry is offered.
• Continuation: the user searches, browses a category, or opens the nearby listing.

FR-2 — Central keyword search (explicit) As a باحث عن خدمة, I should type a keyword into the central search bar and search by service name (e.g. "صيانة"), activity type (e.g. "ورشة سيارات"), or area name (e.g. "حدة، صنعاء"), so that I reach the right provider without knowing its name.

• Trigger/input: a keyword typed into the search bar and submitted.
• Observable result: matching providers are listed as ruled ledger rows with name, ✓ موثق stamp, rating numeral, availability dot, service type, and area.
• Access state: reachable without signing in.
• Failure/recovery: a failed search is stated plainly with a retry; a query with no match is stated plainly with the query preserved for editing.
• Continuation: the user opens a provider, calls it, or refines the query.

FR-3 — Quick service request (explicit) As a باحث عن خدمة, I should tap the clear + اطلب خدمة الآن action to submit a quick request for urgent services, so that I receive offers from service providers available in my area.

• Trigger/input: tapping + اطلب خدمة الآن and submitting the request details (service needed, area, contact details).
• Observable result: the request is submitted and attributed to the requester's identity, and offers from available providers in the area arrive on the request.
• Access state: requires the requester to be signed in; an unsigned user is taken to Login or Sign Up first.
• Failure/recovery: a failed submission is stated plainly with the entered details preserved for resubmission.
• Continuation: the user reviews arriving offers and accepts one, or follows the request in الطلبات.

FR-4 — Main category grid (explicit) As a باحث عن خدمة, I should browse an organized grid of the most-requested service icons, so that I can reach a service type without typing anything.

• Trigger/input: tapping a category tile.
• Observable result: the category's providers are listed with the full provider detail set.
• Access state: reachable without signing in.
• Failure/recovery: a failed category load is stated plainly with a retry.
• Continuation: the user opens a provider, calls it, or returns to the grid.

FR-5 — The eight defined categories (explicit) As a باحث عن خدمة, I should see exactly these eight categories with their clear icons and descriptions:\x20\xf0\x9f\x94\xa7 صيانة (صيانة منزلية وعامة)،\x20\xf0\x9f\x93\xb1 جوالات (مراكز بيع وصيانة الهواتف الذكية)،\x20\xf0\x9f\x92\xbb كمبيوتر (صيانة ومستلزمات الحواسيب)،\x20\xe2\x98\x80️ طاقة شمسية (متخصصون في أنظمة الطاقة المتجددة)،\x20\xe2\x9a\xa1 كهرباء (فنيو كهرباء معتمدون)،\x20\xf0\x9f\x94\xa7 سباكة (خدمات سباكة وتمديدات مائية)،\x20\xe2\x9d\x84️ تكييف وتبريد (تركيب وصيانة مكيفات وثلاجات)،\x20\xf0\x9f\x9a\x9a نقل (خدمات نقل العفش والبضائع), so that I recognize the service I need at a glance.

• Trigger/input: viewing the category grid.
• Observable result: all eight categories are present with their icons and descriptions.
• Access state: reachable without signing in.
• Failure/recovery: if the grid cannot load, a plain statement with a retry is shown.
• Continuation: the user selects a category.

FR-6 — Nearby verified providers (explicit) As a باحث عن خدمة, I should see a خدمات قريبة section that automatically shows the best verified providers geographically near me, so that I get the fastest response.

• Trigger/input: opening the entry surface or the nearby listing.
• Observable result: the best verified providers near the user are listed, ordered by proximity and verification.
• Access state: reachable without signing in.
• Failure/recovery: if the provider data cannot be synchronized, the last successful sync time remains visible and a retry is offered.
• Continuation: the user opens a provider, calls it, saves it, or submits a quick request.

FR-7 — Full provider detail set (explicit) As a باحث عن خدمة, I should see on every provider entry in خدمات قريبة: the centre/provider name (e.g. مركز الأمان للصيانة), the verification mark (✓ موثق), the user star rating (e.g. 4.8 نجمة), the availability status (e.g. مفتوح الآن), and the service type and exact location (e.g. صيانة — صنعاء - التحرير), so that I can judge quality, credibility, and whether I can reach the provider right now.

• Trigger/input: viewing a provider row.
• Observable result: all five detail elements are present on the row.
• Access state: reachable without signing in.
• Failure/recovery: a provider row missing synchronized data shows the available fields and marks the rest as unavailable rather than showing stale values.
• Continuation: the user calls the provider, opens its details, or saves it.

FR-8 — Direct call action (explicit) As a باحث عن خدمة, I should tap the green اتصال button to call the service provider directly, so that I can speak to them immediately.

• Trigger/input: tapping the green اتصال button on a provider row.
• Observable result: the device places a call to the provider's number.
• Access state: reachable without signing in.
• Failure/recovery: if the device cannot place the call, the provider's number remains visible so the user can dial it another way.
• Continuation: the user returns to the listing or opens another provider.

FR-9 — Last-sync indicator (explicit) As a باحث عن خدمة, I should see an آخر تحديث indicator showing the last time data was synchronized through the API, so that I can trust that the information and availability are accurate.

• Trigger/input: viewing the entry surface or the nearby listing.
• Observable result: the timestamp of the last successful API synchronization is displayed and crossfades when it updates.
• Access state: reachable without signing in.
• Failure/recovery: when synchronization fails, the last successful timestamp remains displayed rather than being cleared or replaced with a false current time.
• Continuation: the user retries the sync or proceeds with the displayed information.

FR-10 — Bottom navigation (explicit) As a باحث عن خدمة, I should navigate between the main sections through a smooth bottom navigation bar with\x20\xf0\x9f\x8f\xa0 الرئيسية،\x20\xf0\x9f\x93\x8b الطلبات،\x20\xe2\x9d\xa4️ المفضلة، and\x20\xf0\x9f\x91\xa4 الحساب, so that I move between the app's areas in one touch.

• Trigger/input: tapping a bottom-navigation destination.
• Observable result: the selected destination is shown and its tab is marked active in the amber accent.
• Access state: the bar is visible throughout; الطلبات، المفضلة، and الحساب require the user to be signed in.
• Failure/recovery: an unsigned user tapping a protected destination is taken to Login or Sign Up and returned to that destination after signing in.
• Continuation: the user continues in the selected destination.

FR-11 — Request tracking (explicit) As a باحث عن خدمة, I should follow the status of my previous and current service requests from the الطلبات section, so that I always know where each request stands.

• Trigger/input: opening الطلبات.
• Observable result: the signed-in user's previous and current requests are listed with their current statuses.
• Access state: requires the user to be signed in.
• Failure/recovery: a failed load is stated plainly with a retry; an empty history is stated plainly with the quick request action offered as the next step.
• Continuation: the user opens a request to see its offers and accepts one, or creates a new request.

FR-12 — Favourites (explicit) As a باحث عن خدمة, I should save the providers I liked dealing with into المفضلة, so that I can reach them again in the future.

• Trigger/input: saving a provider from the nearby listing, a category, or a search result.
• Observable result: the provider appears in المفضلة with its full detail set and remains there for the signed-in identity.
• Access state: requires the user to be signed in.
• Failure/recovery: a failed save is stated plainly and the provider is not shown as saved; a failed load of the list is stated plainly with a retry.
• Continuation: the user opens a saved provider, calls it, or removes it from the list.

FR-13 — Profile management (explicit) As a باحث عن خدمة, I should manage my profile data from the الحساب section, so that my details stay correct.

• Trigger/input: editing profile fields and saving.
• Observable result: the updated profile data is stored against the signed-in identity and shown back.
• Access state: requires the user to be signed in.
• Failure/recovery: a failed save is stated plainly with the entered values preserved.
• Continuation: the user returns to the app or signs out.

FR-14 — Provider presence in the nearby listing (explicit) As a مزود خدمة مهنية/حرفية, I should appear in خدمات قريبة with my centre name, verification mark, user rating, availability status (مفتوح الآن), and exact service type and location, so that seekers near me can find and judge my service.

• Trigger/input: the provider's synchronized record being present in the provider data set.
• Observable result: the provider's row renders with the full detail set in the nearby listing.
• Access state: the listing is reachable without signing in.
• Failure/recovery: if the provider's record cannot be synchronized, the row is not shown with stale values; the last successful sync time remains visible.
• Continuation: the seeker calls the provider or submits a request the provider can answer.

FR-15 — Receiving and answering quick requests (explicit) As a مزود خدمة مهنية/حرفية, I should receive the quick service requests submitted by seekers in my area and submit my offers on them, so that I can win the work.

• Trigger/input: opening العروض and opening an available request in the provider's area.
• Observable result: the provider's offer is submitted and attributed to the provider's identity, and the request appears in the provider's submitted-offers list with its status.
• Access state: requires the provider to be signed in.
• Failure/recovery: a failed offer submission is stated plainly with the entered terms preserved for resubmission; no available request in the area is stated plainly.
• Continuation: the provider follows the offer's status in الطلبات.

FR-16 — Receiving direct calls (explicit) As a مزود خدمة مهنية/حرفية, I should receive direct calls from seekers through the green اتصال button, so that I can respond immediately to urgent needs.

• Trigger/input: a seeker tapping the green اتصال button on the provider's row.
• Observable result: the provider receives the call on the number published in the listing.
• Access state: the provider's published number is reachable without the seeker signing in.
• Failure/recovery: if the call cannot be completed, the seeker retains the visible number to dial another way.
• Continuation: the provider and seeker agree on the work directly.

FR-17 — Self-service registration (required_inference) As a باحث عن خدمة or a مزود خدمة مهنية/حرفية, I should establish my identity through self-service registration before using the protected functions, so that my requests, offers, favourites, and profile are bound to me.

• Trigger/input: reaching a protected destination without an established identity, then completing registration with the required details and the role (باحث عن خدمة / مزود خدمة).
• Observable result: the identity is established and the user continues to the destination that required it.
• Access state: the registration surface itself is reachable without signing in.
• Failure/recovery: missing or invalid required details are stated inline and the user corrects and resubmits.
• Continuation: the user proceeds to the protected destination.

FR-18 — Returning verification (required_inference) As a باحث عن خدمة or a مزود خدمة مهنية/حرفية, I should verify my identity when I return, so that I regain access to my requests, offers, favourites, and account data.

• Trigger/input: opening a protected destination while signed out, then submitting credentials.
• Observable result: the session is restored and the user reaches the destination they were seeking.
• Access state: the verification surface itself is reachable without signing in.
• Failure/recovery: incorrect credentials are stated plainly without revealing which field was wrong, and the user may retry or move to Sign Up.
• Continuation: the user continues in the destination they were seeking.

FR-19 — Request and offer attribution (required_inference) As a باحث عن خدمة or a مزود خدمة مهنية/حرفية, I should have my identity recorded as the owner of a request or the author of an offer, so that each side sees and acts on its own side of the request-and-offer lifecycle.

• Trigger/input: submitting a service request or submitting an offer.
• Observable result: the request is bound to the requesting seeker's identity and the offer is bound to the offering provider's identity; each side sees its own requests and offers in الطلبات.
• Access state: requires the relevant identity to be signed in.
• Failure/recovery: if attribution cannot be recorded, the submission is not reported as successful.
• Continuation: the seeker reviews offers on their own request and the provider follows their own offer's status.

4. User Personas

باحث عن خدمة (مستخدم التطبيق)

Product context. This person opens دليل اليمن because something in the household has failed — a refrigerator, a wire, a water pipe — or because they need something moved or installed. They are often on a modest phone and sometimes on a weak connection, and they need calm legibility rather than a busy interface. They may be anywhere across the Yemeni governorates and cities, such as Sana'a.

Primary goal. Reach the right, trustworthy provider as fast as possible — by searching, by browsing a category, or by looking at who is verified and near them — and then either call that provider directly or submit a quick request and let available providers in their area come to them with offers.

Distinct accepted responsibilities.

• Search by keyword across service name (e.g. "صيانة"), activity type (e.g. "ورشة سيارات"), and area name (e.g. "حدة، صنعاء").
• Browse the eight main categories and select the service type needed.
• Read the خدمات قريبة listing and compare providers on name, ✓ موثق verification, star rating, availability status, service type, and exact location.
• Check the آخر تحديث indicator to judge whether the information and availability are current.
• Call a provider directly through the green اتصال button.
• Submit a quick service request through + اطلب خدمة الآن and review the offers that arrive from available providers in their area.
• Follow previous and current requests in الطلبات.
• Save providers they liked into المفضلة and return to them later.
• Manage their own profile data in الحساب.

Relevant inputs and decisions. The keyword they type; the category they pick; whether a provider's verification, rating, and availability justify a call; whether to call directly or submit a request and wait for offers; which offer to accept; which providers to keep.

Interactions with other accepted participants. The seeker's request is received by the مزود خدمة, whose offer comes back to the seeker to review and accept. The seeker's call reaches the provider directly. The seeker's saved favourites and profile belong to the seeker's own identity.

Observable success. The seeker reaches a provider whose details they can trust, either by completing a call or by receiving and accepting an offer on their submitted request, and can find that provider again later.

مزود خدمة مهنية/حرفية

Product context. This person runs a professional or craft service — home and general maintenance, phone sales and repair, computer maintenance and supplies, renewable-energy systems, certified electrical work, plumbing and water piping, air-conditioning and refrigeration installation and repair, or furniture and goods transport. Their work is local: they are found because they are near the person who needs them, and their credibility is carried by their verification mark, their user rating, and whether they are open right now.

Primary goal. Be found by seekers in their area and win the work — either by receiving a direct call or by answering a quick service request with an offer.

Distinct accepted responsibilities.

• Appear in خدمات قريبة with the centre name, the ✓ موثق verification mark, the user star rating, the availability status (مفتوح الآن), and the exact service type and location.
• Receive direct calls from seekers through the green اتصال button.
• Receive the quick service requests submitted by seekers in their area and submit offers on them.
• Follow the status of their own submitted offers.

Relevant inputs and decisions. The provider's own availability status and location accuracy; which available requests in their area are worth an offer; the terms of the offer they submit.

Interactions with other accepted participants. The provider's listing row is what the باحث عن خدمة reads and calls. The provider's offer goes back to the seeker who submitted the request, and the seeker decides whether to accept it.

Observable success. The provider receives a direct call or has an offer accepted on a request from their area, and their listing continues to present them accurately as verified, rated, and open.

5. Core User Flows

Flow 1 — Search by keyword and reach a provider (باحث عن خدمة)

1. The seeker opens الرئيسية without signing in. The wordmark دليل اليمن, the promise line, the ruled search field, the amber + اطلب خدمة الآن block, the eight category tiles, and the خدمات قريبة ledger are visible.
2. The seeker types a keyword into the search field — a service name such as "صيانة", an activity type such as "ورشة سيارات", or an area such as "حدة، صنعاء" — and submits.
3. البحث shows matching providers as ruled ledger rows, each carrying the provider name, the ✓ موثق stamp, the mono rating numeral, the availability dot, the service type, and the area.
4. The seeker compares rows on verification, rating, availability, and location.
5. The seeker taps the green اتصال button on the chosen row. The device places the call to the provider's number.
6. Failure/recovery: if the search returns nothing, the page states that plainly and keeps the query for editing; if the search request fails, a retry is offered. If the device cannot place the call, the provider's number stays visible so the seeker can dial it another way.
7. Continuation: the seeker returns to the results, opens another provider, or saves this one to المفضلة after signing in.

Flow 2 — Browse a category and reach a provider (باحث عن خدمة)

1. The seeker opens الرئيسية and looks at the eight-tile category grid:\x20\xf0\x9f\x94\xa7 صيانة،\x20\xf0\x9f\x93\xb1 جوالات،\x20\xf0\x9f\x92\xbb كمبيوتر،\x20\xe2\x98\x80️ طاقة شمسية،\x20\xe2\x9a\xa1 كهرباء،\x20\xf0\x9f\x94\xa7 سباكة،\x20\xe2\x9d\x84️ تكييف وتبريد،\x20\xf0\x9f\x9a\x9a نقل.
2. The seeker taps the tile for the service needed — for example\x20\xe2\x9d\x84️ تكييف وتبريد (تركيب وصيانة مكيفات وثلاجات).
3. الفئات shows that category's providers as ruled ledger rows with the full detail set.
4. The seeker compares the rows and taps the green اتصال button on the chosen provider.
5. Failure/recovery: if the category has no current provider, that is stated plainly; if the load fails, a retry is offered.
6. Continuation: the seeker returns to the grid, opens another provider, or submits a quick request instead.

Flow 3 — Compare nearby verified providers (باحث عن خدمة)

1. The seeker opens الرئيسية and reads the خدمات قريبة section, which automatically shows the best verified providers geographically near them.
2. Each row presents, on one baseline: the provider name (for example مركز الأمان للصيانة), the ✓ موثق stamp, the star rating numeral (for example 4.8), the availability dot with its status (for example مفتوح الآن), and the area (for example صنعاء - التحرير), with the green اتصال button pinned to the right edge.
3. The seeker checks the آخر تحديث indicator to confirm how recently the data was synchronized through the API.
4. The seeker decides between providers on verification, rating, availability, and proximity.
5. Failure/recovery: if the API sync fails, the last successful sync time remains visible and a retry is offered; if no verified provider is near, that is stated plainly with the search field and category grid offered as the next step.
6. Continuation: the seeker calls a provider, opens its details, or saves it to المفضلة.

Flow 4 — Submit a quick service request and receive offers (باحث عن خدمة)

1. The seeker taps + اطلب خدمة الآن on الرئيسية.
2. Because the request must be bound to the seeker's identity, an unsigned seeker is taken to Login or Sign Up first. At Sign Up the seeker establishes an identity with the required details and the role باحث عن خدمة; at Login a returning seeker verifies the same identity.
3. The seeker lands on طلب خدمة and enters the request details — the service needed, the area, and contact details.
4. The seeker submits the request. The request is recorded and attributed to the seeker's identity, and it becomes available to service providers in that area.
5. Offers from available providers in the area arrive on the request and render as ruled ledger rows carrying provider name, ✓ موثق stamp, rating numeral, availability dot, and area.
6. The seeker reviews the offers and accepts one.
7. Failure/recovery: if the submission fails, the entered details are preserved and the seeker resubmits; if no offer has arrived yet, the page states that plainly and the seeker can refresh.
8. Continuation: the seeker follows the request in الطلبات.

Flow 5 — Follow previous and current requests (باحث عن خدمة)

1. The seeker taps\x20\xf0\x9f\x93\x8b الطلبات in the bottom navigation.
2. If unsigned, the seeker verifies identity at Login and is returned to الطلبات.
3. الطلبات lists the seeker's previous and current requests with their current statuses.
4. The seeker opens a request to see its status and its offers, and accepts an offer if one is suitable.
5. Failure/recovery: if the list fails to load, a retry is offered; if there is no previous or current request, that is stated plainly with the quick request action offered as the next step.
6. Continuation: the seeker creates a new request or returns to الرئيسية.

Flow 6 — Save a provider to favourites and return later (باحث عن خدمة)

1. From خدمات قريبة، البحث، or الفئات, the seeker saves a provider they liked dealing with.
2. If unsigned, the seeker verifies identity at Login or establishes it at Sign Up, and the save is bound to that identity.
3. The seeker taps\x20\xe2\x9d\xa4️ المفضلة in the bottom navigation and sees the saved provider with its full detail set.
4. Later, the seeker returns to المفضلة and taps the green اتصال button on the saved provider.
5. Failure/recovery: if the save fails, it is stated plainly and the provider is not shown as saved; if the list fails to load, a retry is offered; if nothing is saved, that is stated plainly with the nearby listing offered as the next step.
6. Continuation: the seeker calls the provider or removes it from the list.

Flow 7 — Manage profile data (باحث عن خدمة)

1. The seeker taps\x20\xf0\x9f\x91\xa4 الحساب in the bottom navigation.
2. If unsigned, the seeker verifies identity at Login and is returned to الحساب.
3. الحساب shows the profile data stored against the seeker's identity.
4. The seeker edits the fields and saves. The updated data is stored and shown back.
5. Failure/recovery: if the save fails, it is stated plainly with the entered values preserved, and the seeker corrects and resaves.
6. Continuation: the seeker returns to the app or signs out.

Flow 8 — Provider receives a direct call (مزود خدمة مهنية/حرفية)

1. The provider's record is present in the synchronized provider data set, so the provider appears in خدمات قريبة with the centre name, the ✓ موثق mark, the user rating, the availability status (مفتوح الآن), and the exact service type and location.
2. A seeker near the provider reads that row and taps the green اتصال button.
3. The provider receives the call on the number published in the listing and responds.
4. Failure/recovery: if the call cannot be completed, the seeker retains the visible number to dial another way.
5. Continuation: the provider and seeker agree on the work directly.

Flow 9 — Provider answers a quick request with an offer (مزود خدمة مهنية/حرفية)

1. The provider taps\x20\xf0\x9f\x93\x8b الطلبات or opens العروض.
2. If unsigned, the provider verifies identity at Login or establishes it at Sign Up with the role مزود خدمة, and is returned to the destination.
3. العروض lists the quick service requests available in the provider's area, each row carrying the service type, the area, and the request status.
4. The provider opens a request and composes an offer with its terms.
5. The provider submits the offer. The offer is recorded and attributed to the provider's identity, and the request appears in the provider's submitted-offers list with its status.
6. The provider follows the offer's status in الطلبات.
7. Failure/recovery: if the offer submission fails, the entered terms are preserved and the provider resubmits; if no request is available in the area, that is stated plainly.
8. Continuation: the provider continues to answer other requests or waits for the seeker's decision.

6. Visuals Colors and Theme

Muse and headline. Kenya Hara — Emptiness as the directory: calm, paper-white wayfinding. The emotional register is relief, not hype. Trust here is quiet: verification reads like a stamp on paper, not a badge on a billboard.

Colour tokens — light mode (authoritative, from the creative direction):

No gradients. No shadows beyond a 1px hairline and a single soft 0 1px 2px rgba(35,33,30,0.04).

Typography.

• Headings: IBM Plex Sans Arabic, Light-to-Regular weights (300/400) at very large sizes, tracking +0.01em, line-height 1.15, sentence-case Arabic, never bold by default. Weight is earned: موثق and numbers go Medium (500), never heavier.
• Body: IBM Plex Sans Arabic.
• Latin numerals: IBM Plex Mono for tabular alignment (4.8، 09:42).
• Scale: 1.25 modular with a wide display step — mobile display 40 / 56 / 96px; body 15px; labels 12px with +0.08em tracking; provider name 20px; rating numeral 34px mono. clamp() on every display size, e.g. clamp(40px, 9vw, 96px) for the hero wordmark.

Shape language. Square and near-square. Cards are plain rectangles with 2px radius — just enough to feel cut, not rounded. No pills, no blobs, no offset shadows. The only circular forms are the verification stamp, the availability dot, and the call button's ring. Rules are 1px hairlines in #E3DED3, used horizontally like a printed ledger. Category icons are thin 1.25px line glyphs inside a square 1:1 tile with a hairline border — pictograms, not illustrations.

Layout. A single centered column of 640px maximum measure on desktop, with the surrounding paper left empty — the emptiness is the layout. On mobile the column is the viewport minus 24px gutters. Order down the page: wordmark band, search field as a full-width ruled line (not a boxed input), the amber order action as a solid ink block, the category grid as an 8-tile ledger (4×2 at 375px, 8×1 at 768px+), then خدمات قريبة as ruled rows. The bottom navigation is a hairline-topped bar of four labeled pictograms, not a floating pill. Whitespace between sections is 72px mobile / 128px desktop.

Imagery. No photography of people and no stock scenes. Imagery is the interface itself plus a small set of thin-line pictograms (wrench, phone, laptop, sun panel, bolt, pipe, snowflake, truck) drawn at 1.25px in ink on paper. Where a section needs weight, a single square of flat colour (ink, or the amber) with one pictogram knocked out in paper-white — a printed mark, not an illustration. A faint paper grain (SVG noise at 3% opacity) sits over the background at all sizes.

Readable-text integrity. Headlines, the wordmark, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling with clamp() to fit; no other element covers any part of them.

7. Signature Design Concept

The printed ledger of the neighbourhood.

The public entry is a paper-white field, empty except for a stacked left-aligned composition occupying the left 9 columns at 1280px and the full width at 375px. The dominant element is the Arabic wordmark دليل اليمن set in IBM Plex Sans Arabic Light at clamp(40px, 9vw, 96px), ink on paper, with a single hairline rule running the full viewport width beneath it and continuing past the right edge — a printed ledger line, not a divider inside a container. Below the rule, one sentence of muted body copy names the promise: البحث عن الخدمات المهنية والحرفية في جميع محافظات اليمن.

The search field is not a box: it is a full-width ruled line with a thin magnifier pictogram at the right and the placeholder ابحث عن خدمة، نشاط، أو منطقة… in muted. Directly under it, the amber action + اطلب خدمة الآن sits as a solid #C2410C block, 56px tall, square-cornered, ink-white text, left-aligned to the same 9-column measure — no centering, no gradient, no floating card, no illustration. The remaining right third of the desktop viewport stays empty paper.

The same continuous hairline rule that underlines the wordmark is shared by every section heading and bleeds off the right side of the viewport. The خدمات قريبة list is a ruled ledger: each row is name + stamp + mono rating numeral + availability dot + area on one baseline, with the green اتصال button pinned to the right edge of the row, separated by hairlines only — no card, no shadow, no radius. The verification mark is a square ink stamp with a thin double border reading ✓ موثق rotated 3 degrees, sitting beside the provider name, replacing the usual rounded green badge. Category tiles are square pictogram plates with a hairline border and the label set beneath in 12px tracked caps; on hover the plate inverts to ink with the glyph knocked out in paper-white.

Nothing overlaps the wordmark, the copy, the field, or the button at any breakpoint.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the Arabic wordmark دليل اليمن on an empty paper field, with the hairline ledger rule running edge-to-edge beneath it and bleeding off the right side.
• Input → transformation → outcome thesis: as the entry surface first paints, the wordmark, the promise line, the ruled search field, and the amber + اطلب خدمة الآن block settle into place with a single 400ms fade and a 24px rise; the outcome is a composed first frame that reads as the first page of a printed catalogue, with the search field and the order action immediately available.
• Motion vocabulary: almost none, and that is the statement. Section content fades in over 400ms with a 24px rise, once, on first scroll. The availability dot breathes on a 3s cycle. The آخر تحديث timestamp crossfades when it updates. Hover on a provider row reveals a hairline underline that draws left-to-right in 180ms.
• Composed first frame: paper ground #F4F1EA with the faint 3% paper grain; the wordmark in ink at the top of the left 9-column measure; the hairline rule beneath it running past the right edge; the muted promise line; the ruled search field with the magnifier pictogram at the right; the solid amber order block below it; the right third of the desktop viewport empty.
• Reduced-motion state: prefers-reduced-motion removes the rise and the breath, leaving instant states — the first frame is fully composed with no entrance animation, the availability dot is a static dot, and the timestamp updates without a crossfade.

9. Non-Functional Requirements

• NFR-1 — Arabic-first, right-to-left interface (explicit): all interface text, labels, and content are Arabic, laid out right-to-left, with Latin numerals set in IBM Plex Mono for tabular alignment. Rationale: the product serves Yemeni users in Arabic.
• NFR-2 — Readability on modest phones and weak connections (explicit): the interface is simple and direct, designed to suit everyone, and remains legible on small screens; the visual language uses no decorative motion that would fight a slow network. Rationale: the source states ease of use as a reason to choose the app and the creative direction names modest phones and weak connections.
• NFR-3 — Data freshness transparency (explicit): the آخر تحديث indicator shows the last time data was synchronized through the API, so that information and availability accuracy can be judged. Rationale: the source requires the indicator for accuracy and availability confidence.
• NFR-4 — Trust signals on every provider entry (explicit): verification mark, user rating, availability status, service type, and exact location are present on every provider entry in خدمات قريبة. Rationale: the source states these details build trust and credibility.
• NFR-5 — Geographic coverage (explicit): the directory covers the various Yemeni governorates and cities, such as Sana'a. Rationale: the source states wide coverage as a reason to choose the app.
• NFR-6 — Service diversity (explicit): the directory covers household, professional, and technical needs through the eight defined categories. Rationale: the source states service diversity as a reason to choose the app.
• NFR-7 — Identity continuity for durable state (required_inference): requests, offers, favourites, and profile data are bound to the identity that created them, and returning users verify that identity to regain access. Rationale: without this, a request, an offer, a favourite, or a profile could not be reliably attributed to the correct participant.
• NFR-8 — Readable text and controls stay whole (explicit, from the creative direction): headlines, the wordmark, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Rationale: the direction makes this rule take precedence over any cropping gesture.
• NFR-9 — Reduced-motion support (explicit, from the creative direction): prefers-reduced-motion removes the entrance rise and the availability-dot breath, leaving instant states. Rationale: the direction specifies this behaviour.

10. Tech Stack

• Frontend: React (custom UI, Arabic RTL, mobile-first with a bottom navigation bar and a single centered desktop reading column). (Default — not specified by user; the source specifies a mobile application with a bottom navigation bar and custom interface, and React is the appropriate default for the custom UI.)
• Backend: Python / FastAPI, providing the search, category, nearby-provider, request, offer, favourites, profile, and identity endpoints, and performing the provider-data synchronization through the external services API. (Default — not specified by user; required by the accepted backend integration and the API synchronization the source names.)
• Storage: a relational database for accounts, roles, providers, categories, requests, offers, favourites, and profile data, plus the stored last-sync timestamp. (Default — not specified by user; required by the durable state the accepted lifecycles create.)
• Containerization: Docker / docker-compose for local and single-host deployment. (Default — not specified by user.)
• Orchestration: Kubernetes only if the deployment requires it. (Default — not specified by user.)

The external services API that supplies provider data is owned outside the product; the product consumes it and displays the last synchronization time.

11. Assumptions and Constraints

• A-1 (assumption): The provider data set — provider names, verification marks, ratings, availability statuses, service types, exact locations, and phone numbers — is supplied by the external services API named in the source; the product displays it and does not own it upstream.
• A-2 (assumption): The آخر تحديث indicator reflects the last successful synchronization through that API; when synchronization fails, the last successful time remains displayed rather than a false current time.
• A-3 (assumption): The green اتصال button places a call through the device's telephony capability; the product does not carry the call itself.
• A-4 (assumption): The eight categories listed in the source are the complete current category set; no additional category is added.
• A-5 (assumption): The bottom navigation carries exactly the four destinations named in the source: الرئيسية، الطلبات، المفضلة، الحساب.
• A-6 (constraint): The public entry surface, keyword search, category browsing, and the nearby-provider listing are reachable without signing in, because a person with an urgent need must be able to find and call a provider immediately.
• A-7 (constraint): Submitting a service request, receiving and submitting offers, tracking requests, favourites, and profile data require the user to be signed in, because those are the destinations that carry durable, actor-specific state.
• A-8 (constraint): Identity is established by self-service registration at first use and verified on return; no invitation, provisioning, or deployment bootstrap is specified and none is added.
• A-9 (constraint): The system distinguishes the identity of the request owner from the identity of the service provider so that requests and offers are attributed to the correct side; this is an attribution boundary required by the accepted request-and-offer lifecycle, not a general permission system over shared product state.
• A-10 (constraint): No payment, no in-app messaging, no provider-side profile editing surface, no review-writing surface, and no map view are specified by the source and none are added.
• A-11 (constraint): The generic indigo/blue-on-white SaaS template is forbidden for this project; the palette, typography, shape language, and layout in Section 6 are authoritative.
• A-12 (constraint): The interface is Arabic and right-to-left throughout.

12. Glossary

• دليل اليمن — the product: a comprehensive directory for searching and reaching professional and craft services across all governorates of Yemen.
• باحث عن خدمة (مستخدم التطبيق) — the service seeker: the accepted persona who searches, browses, compares, calls, requests, tracks, saves, and manages profile data.
• مزود خدمة مهنية/حرفية — the professional/craft service provider: the accepted persona who is listed, receives calls, and answers quick requests with offers.
• خدمات قريبة — the section that automatically shows the best verified providers geographically near the user.
• ✓ موثق — the verification mark shown on a provider entry to signal quality and credibility.
• مفتوح الآن — the availability status shown on a provider entry, indicating the provider can be contacted immediately.
• آخر تحديث — the indicator showing the last time data was synchronized through the API.
• + اطلب خدمة الآن — the quick service request action for urgent requests, which receives offers from available providers in the requester's area.
• اتصال — the green direct-call action on a provider entry.
• الطلبات — the section for following the status of previous and current service requests.
• المفضلة — the section for saving providers the user liked dealing with, for future access.
• الحساب — the section for managing profile data.
• الفئات — the eight main service categories: صيانة، جوالات، كمبيوتر، طاقة شمسية، كهرباء، سباكة، تكييف وتبريد، نقل.
• عرض (offer) — a provider's response to a submitted quick service request, carrying the provider's terms and status.
• طلب خدمة — a quick service request submitted by a seeker, bound to the seeker's identity and answered by providers in the area.