System Requirements Document for delivery-algerian-market

1. Introduction

delivery-algerian-market is a hyper-local, on-demand buy-and-deliver service for the Algerian market. Its principal purpose is delivery: a person in demand requests goods, and a nearby courier — travelling on foot, by bicycle, or by trottinette (scooter) — buys those goods and brings them to the requester's location.

The product is deliberately bounded by distance and price:

• 0–1.5 km: delivery may be performed à pied, by bicycle, or by trottinette.
• 2–5 km: delivery may be performed by bicycle or trottinette only (no walking).
• Delivery price: from 100 DA to a maximum of 400 DA, depending on the delivery.
• Service zones: no larger than 5 km.
• Prohibited goods: alcohol, smoking/tobacco products, and drugs may not be bought.

The audience is young, mobile-first, price-sharp and street-smart users in Algerian cities (Algiers, Oran, Constantine, Sétif) who want everyday goods bought and carried to them quickly inside their neighbourhood zone, and the couriers — walkers, cyclists and trottinette riders — who fulfil those requests. The experience must feel fast, joyful, trustworthy and unmistakably local, and must visibly refuse alcohol, tobacco and drugs.

2. System Overview

delivery-algerian-market is a first-party application with application-owned identity and custom UI. Two active human roles participate: the Requester (Customer), who asks for goods to be bought and delivered, and the Courier, who accepts a request in their zone, buys the permitted goods, transfers the delivery fee, and delivers while sharing live location.

Current delivery covers:

• Anonymous public entry that explains the service, the covered participants, the distance limits, and the prohibited goods before identity is established.
• Self-service enrollment and returning verification for both roles, with role-aware authorization distinguishing requester and courier responsibilities.
• Request creation with permitted goods and a delivery destination, with prohibited-goods validation before submission.
• Delivery location and distance validation, and service-zone validation, before a request is accepted.
• Delivery-fee calculation and display within the required 100–400 DA range.
• A revisitable courier list of available requests and a focused acceptance workflow.
• Transport-mode validation against the 0–1.5 km and 2–5 km distance rules before courier fulfilment.
• Focused courier shopping for the permitted requested goods after acceptance.
• Completion of the courier's required 100–400 DA delivery-fee transfer.
• Real-time map tracking of the active delivery with live courier location for both requester and courier.

Narrow exclusions: the service does not buy alcohol, smoking/tobacco products, or drugs; it does not operate outside zones larger than 5 km; it does not offer walking delivery beyond 1.5 km; and it does not price a delivery below 100 DA or above 400 DA.

2a. Product Interpretation and Delivery Boundary

The product is a first-party application delivered as custom UI with application-owned identity. Because a requester's request, a courier's accepted work, the agreed delivery fee, and the live delivery state must remain bound to the correct participant and be resumable, the application owns identity: first-use enrollment is self-service on the Sign Up page, and returning verification happens on the Login page. Both entry surfaces are anonymously reachable; the protected working surfaces (Request, Pricing, Courier Requests, Shopping, Settlement, Live Tracking, Delivery Rules, Zone Check) require an established identity, and the courier-only surfaces additionally require the courier role.

The public entry (Landing) is anonymous and explains the Algerian buy-and-deliver service, the covered participants, the distance limits, and the prohibited goods before identity establishment. It does not itself establish access to protected state.

Current horizon: everything described in Sections 2c, 3 and 5. No future-horizon capabilities are currently accepted; anything not listed above is out of scope for this generation.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains the Algerian buy-and-deliver service, the covered participants (requesters and couriers on foot, bicycle, or trottinette), the distance limits (0–1.5 km on foot/bicycle/trottinette; 2–5 km bicycle/trottinette only), the 100–400 DA price range, the ≤5 km zone limit, and the prohibited goods (alcohol, smoking/tobacco, drugs).
• Primary actions: Proceed to Sign Up; proceed to Login.
• Supporting actions: Read the transport-mode and distance rules; read the prohibited-goods rule.
• Domain entities: Service zone (≤5 km), transport mode (à pied / vélo / trottinette), price range (100–400 DA), prohibited-goods rule.
• Component responsibilities: Hero type block; transport-mode pills (à pied 0–1,5 km / vélo 2–5 km / trottinette 2–5 km); prohibited-goods poster band with slashed-circle stamp; live-map sticker card with courier trace and price chip; entry CTAs.
• States: Loading (initial asset/type load); empty (not applicable — static explanatory content); success (entry CTAs available); error (asset load failure with readable fallback text); recovery (retry load or proceed via text-only entry).

Sign Up

• Information/state: First-use enrollment for both self-starting roles. Collects the identity details needed to create a durable requester or courier account and the role selection that distinguishes requester and courier responsibilities.
• Primary actions: Submit enrollment; select role (Requester or Courier).
• Supporting actions: Switch to Login if already enrolled.
• Domain entities: Account identity, role (Requester / Courier).
• Component responsibilities: Role selector; enrollment fields; submit control; validation messaging; link to Login.
• States: Loading (submitting); empty (no fields completed); success (account created and role established, continuing to the role's working surface); error (invalid or incomplete details, or role not selected); recovery (correct the flagged fields and resubmit, or switch to Login).

Login

• Information/state: Returning verification for both personas accessing their delivery responsibilities and shared active delivery state.
• Primary actions: Submit credentials to verify identity.
• Supporting actions: Switch to Sign Up if not yet enrolled.
• Domain entities: Account identity, role (Requester / Courier).
• Component responsibilities: Credential fields; submit control; validation messaging; link to Sign Up.
• States: Loading (verifying); empty (no credentials entered); success (verified, continuing to the role's working surface); error (credentials not recognized); recovery (re-enter credentials, or switch to Sign Up).

Request

• Information/state: Requester specifies the permitted goods to be bought and the delivery destination. Prohibited-goods validation runs before submission; delivery location and distance validation runs before request acceptance.
• Primary actions: Enter requested goods; set delivery destination; submit the request.
• Supporting actions: Review the prohibited-goods rule; review the applicable transport-mode rule for the entered distance.
• Domain entities: Request, requested goods, delivery destination, distance, transport mode, prohibited-goods rule.
• Component responsibilities: Goods entry; destination entry; prohibited-goods validation feedback; distance/location validation feedback; submit control.
• States: Loading (validating location and distance); empty (no goods or destination entered); success (request accepted and passed to pricing); error (prohibited goods detected, or destination outside a ≤5 km zone, or location/distance not resolvable); recovery (remove prohibited items or correct the destination and resubmit).

Pricing

• Information/state: Shows the delivery fee calculated within the required 100–400 DA range for the accepted request.
• Primary actions: Confirm the delivery fee and continue.
• Supporting actions: Review how the fee relates to the delivery.
• Domain entities: Delivery fee (100–400 DA), request, distance.
• Component responsibilities: Fee display within range; range context (100–400 DA); confirm control.
• States: Loading (calculating fee); empty (no accepted request to price); success (fee shown within 100–400 DA and confirmed); error (fee cannot be computed within range for the request); recovery (return to Request to adjust the destination or goods).

Courier Requests

• Information/state: Revisitable list of available requests in the courier's zone, with the focused acceptance workflow.
• Primary actions: Open a request; accept a request.
• Supporting actions: Refresh the list; review request details (goods, destination, distance, fee).
• Domain entities: Available request, zone, distance, delivery fee, transport mode.
• Component responsibilities: Request list; request detail; accept control; empty-list messaging.
• States: Loading (fetching available requests); empty (no available requests in zone); success (request accepted, continuing to transport-mode validation and Shopping); error (list or acceptance failed); recovery (refresh the list and retry acceptance).

Shopping

• Information/state: Supports the courier's focused work of purchasing the permitted requested goods after acceptance.
• Primary actions: Mark goods as purchased; record purchase progress.
• Supporting actions: Review the accepted request's goods list.
• Domain entities: Accepted request, requested goods, purchase progress.
• Component responsibilities: Goods checklist; purchase-progress control; prohibited-goods reminder.
• States: Loading (loading accepted request); empty (no accepted request); success (all permitted goods purchased, continuing to Settlement); error (goods unavailable or purchase not recorded); recovery (update the goods state and retry, or return to Courier Requests).

Settlement

• Information/state: Supports completion of the courier's required 100–400 DA delivery-fee transfer. Delivery-fee transfer completion is required before delivery closure.
• Primary actions: Complete the delivery-fee transfer; confirm transfer completion.
• Supporting actions: Review the agreed fee within the 100–400 DA range.
• Domain entities: Delivery fee (100–400 DA), transfer, delivery closure.
• Component responsibilities: Fee amount display; transfer control; completion confirmation; closure gate.
• States: Loading (processing transfer); empty (no fee to settle); success (transfer completed, delivery eligible for closure); error (transfer not completed); recovery (retry the transfer; delivery cannot close until completion).

Live Tracking

• Information/state: Provides the active delivery's real-time map and courier location for requester and courier continuity. Courier live location sharing continues during an active delivery, subject to live location permission.
• Primary actions: View the live courier position on the map; follow the delivery to arrival.
• Supporting actions: Review delivery status and destination.
• Domain entities: Active delivery, courier live location, map, destination, delivery status.
• Component responsibilities: Real-time map; courier position marker; route/trace; status indicator; permission prompt when location sharing is not granted.
• States: Loading (establishing map and location stream); empty (no active delivery); success (live position updating until arrival); error (location permission denied or stream interrupted); recovery (grant permission or reconnect the stream; the delivery continues and the last known state remains visible).

Delivery Rules

• Information/state: Validates permitted transport modes against the 0–1.5 km and 2–5 km distance rules before courier fulfilment.
• Primary actions: Select the transport mode for the accepted delivery; confirm the mode.
• Supporting actions: Review the distance-tier rule.
• Domain entities: Distance tier (0–1.5 km / 2–5 km), transport mode (à pied / vélo / trottinette).
• Component responsibilities: Transport-mode selector; distance-tier display; rule validation; disabled-state messaging for walking beyond 1.5 km.
• States: Loading (resolving distance); empty (no accepted delivery to validate); success (a permitted mode is selected and confirmed); error (selected mode not permitted for the distance); recovery (choose a permitted mode — bicycle or trottinette for 2–5 km).

Zone Check

• Information/state: Validates that each delivery remains within a service zone no larger than 5 km.
• Primary actions: Check the delivery location against the service zone.
• Supporting actions: Review the zone boundary and the ≤5 km limit.
• Domain entities: Service zone (≤5 km), delivery location, distance.
• Component responsibilities: Zone boundary display; location check; result indicator; out-of-zone messaging.
• States: Loading (resolving location and zone); empty (no location to check); success (location inside a ≤5 km zone); error (location outside the service zone or zone exceeds 5 km); recovery (adjust the delivery location to a covered zone and re-check).

3. Functional Requirements

FR-1 — Buy-and-deliver service for the Algerian market (explicit) As a Requester (Customer), I should request goods that a courier buys for me and delivers to me, so that I receive everyday items without going out myself.

• Trigger/input: I submit a request naming the goods and my delivery destination.
• Observable result: my request exists with its goods and destination, and a courier can accept it.
• Access state: requires an established requester identity.
• Failure/recovery: if the request cannot be created, I correct the flagged input and resubmit.
• Continuation: the request proceeds to pricing and courier acceptance.

FR-2 — Courier travel modes (explicit) As a Courier, I should fulfil deliveries on foot, by bicycle, or by trottinette, so that I can serve requests with the transport I actually have.

• Trigger/input: I accept a request and select my transport mode.
• Observable result: my selected mode is recorded for the delivery.
• Access state: requires an established courier identity.
• Failure/recovery: if my mode is not permitted for the distance, I select a permitted one.
• Continuation: the delivery proceeds under the validated mode.

FR-3 — Distance-based transport rules (explicit) As a Courier, I should be restricted to permitted transport modes by distance — on foot, bicycle, or trottinette for 0–1.5 km, and bicycle or trottinette only for 2–5 km — so that deliveries match the service's distance rules.

• Trigger/input: the accepted delivery's distance is resolved.
• Observable result: only permitted modes are selectable; walking is not selectable beyond 1.5 km.
• Access state: requires an established courier identity.
• Failure/recovery: if I selected a non-permitted mode, I choose bicycle or trottinette for 2–5 km.
• Continuation: fulfilment proceeds once a permitted mode is confirmed.

FR-4 — Delivery price range (explicit) As a Requester (Customer), I should see a delivery price between 100 DA and a maximum of 400 DA depending on the delivery, so that I know the cost before committing.

• Trigger/input: my request is accepted and priced.
• Observable result: a delivery fee within 100–400 DA is displayed.
• Access state: requires an established identity.
• Failure/recovery: if no fee within range can be computed, I adjust the destination or goods and return to the request.
• Continuation: I confirm the fee and the request becomes available to couriers.

FR-5 — Delivery fee transferred by the courier (explicit) As a Courier, I should transfer the delivery fee of 100–400 DA, so that the delivery's payment obligation is completed.

• Trigger/input: I have purchased the requested goods and reach settlement.
• Observable result: the delivery-fee transfer is completed and recorded.
• Access state: requires an established courier identity.
• Failure/recovery: if the transfer does not complete, I retry; the delivery cannot close until completion.
• Continuation: the delivery becomes eligible for closure.

FR-6 — Prohibited goods restriction (explicit) As a Requester (Customer), I should be prevented from requesting alcohol, smoking/tobacco products, or drugs, so that the service never buys prohibited goods.

• Trigger/input: I enter goods and submit the request.
• Observable result: prohibited goods are rejected before submission and cannot be purchased.
• Access state: requires an established requester identity.
• Failure/recovery: I remove the prohibited items and resubmit.
• Continuation: the corrected request proceeds to pricing.

FR-7 — Real-time map tracking (explicit) As a Requester (Customer), I should follow the courier's live position on a real-time map, so that I know when my goods will arrive.

• Trigger/input: an active delivery exists and the courier shares live location.
• Observable result: the courier's position updates on the map until arrival.
• Access state: requires an established identity with access to the active delivery.
• Failure/recovery: if the location stream is interrupted, the last known state remains visible and the stream reconnects.
• Continuation: tracking continues to arrival.

FR-8 — Modern design for the Algerian market (explicit) As a Requester (Customer) and as a Courier, I should use a modern interface suited to the Algerian market, so that the service feels local, fast and trustworthy.

• Trigger/input: I open any surface of the application.
• Observable result: the interface presents the service's local context, distance tiers, price range and prohibited-goods rule clearly.
• Access state: applies to anonymous and established states alike.
• Failure/recovery: if content fails to load, readable fallback text remains.
• Continuation: I proceed with my task.

FR-9 — Service zones no larger than 5 km (explicit) As a Requester (Customer), I should have my delivery validated against a service zone no larger than 5 km, so that deliveries stay inside the covered area.

• Trigger/input: I set my delivery destination.
• Observable result: the location is confirmed inside a ≤5 km zone, or rejected as out of zone.
• Access state: requires an established identity.
• Failure/recovery: if my location is outside the zone, I adjust it to a covered zone and re-check.
• Continuation: the validated request proceeds.

FR-10 — Requester self-service enrollment and returning verification (required_inference) As a Requester (Customer), I should create my own account and later verify myself on return, so that my requests and their state remain mine across sessions.

• Trigger/input: I enroll on first use, or verify on return.
• Observable result: my requester identity is established and my requests are bound to it.
• Access state: enrollment and verification are anonymously reachable entry interactions; protected requester state becomes available only after identity is established.
• Failure/recovery: if enrollment or verification fails, I correct the flagged details or switch between Sign Up and Login.
• Continuation: I reach my requester working surfaces.

FR-11 — Courier self-service enrollment and returning verification (required_inference) As a Courier, I should create my own account and later verify myself on return, so that my accepted deliveries and their state remain mine across sessions.

• Trigger/input: I enroll on first use, or verify on return.
• Observable result: my courier identity is established and my accepted deliveries are bound to it.
• Access state: enrollment and verification are anonymously reachable entry interactions; protected courier state becomes available only after identity is established.
• Failure/recovery: if enrollment or verification fails, I correct the flagged details or switch between Sign Up and Login.
• Continuation: I reach my courier working surfaces.

FR-12 — Role selection and role-aware authorization (required_inference) As a Requester (Customer) or a Courier, I should have my role distinguish my responsibilities, so that I only reach the work that belongs to my role.

• Trigger/input: I select my role during enrollment, or my established role is resolved on verification.
• Observable result: requester responsibilities and courier responsibilities are separated; courier-only surfaces are not reachable as a requester.
• Access state: role is established with identity; courier-only surfaces require the courier role.
• Failure/recovery: if my role is not established, I complete role selection before continuing.
• Continuation: I reach the surfaces for my role.

FR-13 — Delivery location and distance validation before request acceptance (required_inference) As a Requester (Customer), I should have my delivery location and distance validated before my request is accepted, so that only deliverable requests enter the system.

• Trigger/input: I submit my request with a destination.
• Observable result: the request is accepted only when the location and distance resolve within the service rules.
• Access state: requires an established requester identity.
• Failure/recovery: if the location or distance cannot be resolved, I correct the destination and resubmit.
• Continuation: the accepted request proceeds to pricing.

FR-14 — Transport-mode validation before courier fulfilment (required_inference) As a Courier, I should have my transport mode validated against the delivery distance before I fulfil it, so that I never deliver by a mode the distance rules forbid.

• Trigger/input: I accept a delivery and select a mode.
• Observable result: fulfilment proceeds only with a permitted mode for the resolved distance.
• Access state: requires an established courier identity.
• Failure/recovery: if my mode is not permitted, I select bicycle or trottinette for 2–5 km.
• Continuation: I proceed to purchase the goods.

FR-15 — Prohibited-goods validation before request submission and purchase (required_inference) As a Requester (Customer) and as a Courier, I should have prohibited goods blocked before submission and before purchase, so that alcohol, smoking/tobacco products and drugs are never bought.

• Trigger/input: the requester submits goods; the courier reviews the goods list before purchasing.
• Observable result: prohibited items are rejected at submission and are absent from the courier's purchase list.
• Access state: requires an established identity for the acting role.
• Failure/recovery: the requester removes the prohibited items and resubmits; the courier does not purchase prohibited items.
• Continuation: only permitted goods proceed.

FR-16 — Live location permission and ongoing courier location sharing (required_inference) As a Courier, I should grant live location permission and share my location during an active delivery, so that the requester can track the delivery in real time.

• Trigger/input: I have an active delivery and location sharing is requested.
• Observable result: my live location is shared for the duration of the active delivery.
• Access state: requires an established courier identity with an active delivery.
• Failure/recovery: if permission is denied or the stream drops, tracking shows the last known state and sharing resumes when permission or connection returns.
• Continuation: sharing continues until the delivery closes.

FR-17 — Delivery-fee transfer completion before delivery closure (required_inference) As a Courier, I should complete the delivery-fee transfer before the delivery can close, so that the 100–400 DA obligation is settled.

• Trigger/input: I reach settlement after purchasing the goods.
• Observable result: the delivery closes only after the transfer is completed.
• Access state: requires an established courier identity.
• Failure/recovery: if the transfer is incomplete, the delivery remains open and I retry.
• Continuation: the delivery closes and the requester's tracking ends at arrival.

4. User Personas

Requester (Customer)

• Product context: A person in a covered zone (≤5 km) in an Algerian city who needs everyday goods bought and brought to them. They are mobile-first, price-aware, and expect to see exactly what the delivery costs before committing.
• Primary goal: Get the goods they asked for delivered to their location at a known price between 100 DA and 400 DA, and know when it will arrive.
• Distinct accepted responsibilities: Specifying the permitted goods to be bought; setting the delivery destination; submitting the request; seeing and confirming the delivery fee within 100–400 DA; following the courier's live position on the real-time map until the goods arrive.
• Relevant inputs or decisions: What to buy (never alcohol, smoking/tobacco, or drugs); where to deliver (inside a ≤5 km zone); whether to accept the shown fee.
• Interactions with other accepted participants: The courier buys the goods and delivers them; the requester observes the courier's live position and receives the goods. The requester's request is the work the courier accepts.
• Observable success: The request is accepted, priced within range, tracked live, and the goods arrive at the stated destination.

Courier (on foot, bicycle, or scooter)

• Product context: A delivery person working inside a ≤5 km zone who moves by walking, bicycle, or trottinette depending on the distance of the job. They need to see available requests in their zone, accept one, buy the goods, settle the fee, and be tracked while delivering.
• Primary goal: Complete accepted deliveries correctly — permitted goods only, permitted transport mode for the distance, fee transferred — and be visible to the requester in real time.
• Distinct accepted responsibilities: Browsing and accepting available requests; selecting a transport mode permitted for the distance (à pied, vélo, or trottinette for 0–1.5 km; vélo or trottinette only for 2–5 km); purchasing the permitted requested goods; transferring the 100–400 DA delivery fee; sharing live location during the active delivery.
• Relevant inputs or decisions: Which request to accept; which permitted transport mode to use; whether the goods are permitted; when the purchase is complete; when the transfer is complete.
• Interactions with other accepted participants: The requester's request defines the goods and destination; the courier's live location is what the requester follows; the courier's fee transfer closes the delivery.
• Observable success: The delivery is fulfilled under a permitted mode, the fee transfer is completed, and the delivery closes with the requester having tracked it to arrival.

5. Core User Flows

Flow A — Requester: request goods and follow the delivery

1. Starting context: The Requester opens the application for the first time and lands on Landing (anonymous).
2. On Landing, they read what the service does, the covered participants, the distance limits (0–1.5 km on foot/bicycle/trottinette; 2–5 km bicycle/trottinette only), the 100–400 DA price range, the ≤5 km zone limit, and the prohibited-goods rule (alcohol, smoking/tobacco, drugs).
3. They choose Sign Up and enroll, selecting the Requester role. Their requester identity is established and their future requests are bound to it. (If they already have an account, they choose Login and verify instead.)
4. On Request, they enter the goods they want bought and their delivery destination.
5. Prohibited-goods validation runs before submission: if they entered alcohol, smoking/tobacco products, or drugs, the request is rejected and they remove those items. (Failure/recovery.)
6. Delivery location and distance validation runs before acceptance, and Zone Check confirms the destination is inside a service zone no larger than 5 km. If the destination is outside the zone, they adjust it and re-check. (Failure/recovery.)
7. On Pricing, the delivery fee is shown within the required 100–400 DA range. They confirm it.
8. Observable result: the request is accepted, priced within range, and available to couriers in the zone.
9. Continuation: on Live Tracking, they watch the courier's live position on the real-time map. If the location stream is interrupted, the last known state remains visible and the stream reconnects. (Failure/recovery.)
10. Completion: the courier arrives with the goods; tracking ends at arrival.

Flow B — Courier: accept, buy, settle, and deliver

1. Starting context: The Courier opens the application and lands on Landing (anonymous).
2. On Landing, they read the service rules, including the distance tiers, the 100–400 DA range, and the prohibited-goods rule.
3. They choose Sign Up and enroll, selecting the Courier role. Their courier identity is established and their accepted deliveries are bound to it. (If they already have an account, they choose Login and verify instead.)
4. On Courier Requests, they see the revisitable list of available requests in their zone and open one to review its goods, destination, distance, and fee.
5. They accept the request.
6. On Delivery Rules, the delivery distance is resolved and they select a transport mode. For 0–1.5 km they may choose à pied, vélo, or trottinette; for 2–5 km only vélo or trottinette are permitted, and walking is not selectable. If they selected a non-permitted mode, they choose a permitted one. (Failure/recovery.)
7. On Shopping, they purchase the permitted requested goods and record purchase progress. Prohibited goods are never purchased. If goods are unavailable or progress cannot be recorded, they update the goods state and retry. (Failure/recovery.)
8. On Settlement, they complete the delivery-fee transfer of 100–400 DA and confirm completion. If the transfer does not complete, they retry; the delivery cannot close until it is completed. (Failure/recovery.)
9. Observable result: the fee transfer is completed and the delivery is eligible for closure.
10. Continuation: on Live Tracking, they grant live location permission and share their location for the duration of the active delivery, so the requester can follow them in real time. If permission is denied or the stream drops, tracking shows the last known state and sharing resumes when permission or connection returns. (Failure/recovery.)
11. Completion: they deliver the goods to the requester's destination and the delivery closes.

Flow C — Requester: returning to an active delivery

1. Starting context: The Requester returns to the application after their request was accepted.
2. On Login, they verify their identity; their requester role and their active delivery state are restored.
3. On Live Tracking, they resume following the courier's live position on the real-time map.
4. Observable result: the delivery's current state and the courier's live position are visible again.
5. Continuation: tracking continues to arrival.

Flow D — Courier: returning to accepted work

1. Starting context: The Courier returns to the application with an accepted delivery in progress.
2. On Login, they verify their identity; their courier role and their accepted delivery are restored.
3. They continue from the correct stage — Shopping, Settlement, or Live Tracking — depending on what remains.
4. Observable result: their accepted delivery and its current stage are visible again.
5. Continuation: they complete the remaining stages and the delivery closes.

6. Visuals Colors and Theme

Muse: Jessica Walsh. Headline direction: Saturated street energy for a 5 km Algerian delivery grid.

The visual language is colour-blocked, hard-edged and poster-like: warm cream grounds, tangerine washes, hot-pink action colour, emerald trust signals, and thick ink outlines with offset solid shadows. No white-first ground, no glass, no gradients, no soft blurred shadows.

Colour tokens (light mode):

Proportion: cream 55%, tangerine 20%, pink 15%, emerald 7%, ink/others 3%. Lime appears only as a hover/highlight flick, never as a ground.

Typography:

• Headings: Archivo Black, uppercase, tracking -0.02em, leading 0.86, set as solid blocks of type filling their column edge to edge.
• Body and UI: Outfit 400/600 at 17–18px with 1.6 leading.
• Label chips: Outfit 700 uppercase 12px / 0.16em tracking (e.g. 0–1,5 KM, 100–400 DA, SANS ALCOOL).
• Scale: 1.5 modular display, 1.25 UI — hero clamp(44px, 11vw, 132px) / section clamp(30px, 5.5vw, 64px) / card title 24px / body 18px / label 12px.
• Arabic and Latin numerals are both set in Outfit for tabular price alignment.

Shape language: Hard-edged colour blocks; 28–40px radii on interactive pills only. Sticker and tag shapes: rotated −4° to +6° cards, chunky 3px ink outlines, offset solid shadows (6px 6px 0 #141014) instead of blur. Zone bands are full-bleed diagonal stripes. No soft drop shadows, no glass, no gradients.

Layout: Asymmetric editorial grid on a 12-column base — hero type block in columns 1–8 with a rotated product sticker bleeding off the right edge; zone cards stagger left/right rather than sitting in a uniform row; the real-time map panel is a full-bleed tangerine block with an ink-outlined HUD, not a floating white card. Sections are separated by a 6px ink rule or a diagonal colour band. At 375px everything stacks to one column with type scaled by clamp and stickers reduced to inline chips.

Imagery: Art-directed, colour-saturated photography and 3D props — a bicycle courier's crate overflowing with baguettes, watermelons, phone chargers and pharmacy bags, shot against flat pink and tangerine backdrops; a trottinette wheel macro; a hand holding a paper bag stamped with the prohibited-goods icon. Cut-out subjects with hard ink outlines pasted onto colour fields, plus sticker-style vector icons for transport modes (walking shoe, bicycle, trottinette) and a big red-circle-slash stamp for alcohol/tobacco/drugs. No stock office people, no gradient blobs, no glass panels.

7. Signature Design Concept

Public entry — Landing: "ON ACHÈTE. ON LIVRE."

A full-bleed cream ground (#FFF3E4). The left 8 columns carry the headline ON ACHÈTE. ON LIVRE. set in Archivo Black at clamp(44px, 11vw, 132px), stacked in three lines that span the column, with a hot-pink (#FF2E88) band behind the middle line and a 12px ink rule under the block. Directly beneath sit three transport pills in a row — à pied 0–1,5 km, vélo 2–5 km, trottinette 2–5 km — and one emerald (#00B86B) CTA, Demander une course.

On the right, a rotated −5° sticker card bleeds off the viewport edge: it shows the live courier trace on a tangerine map tile with a pulsing pink dot and a 100–400 DA chip. In the bottom-left corner, a small emerald stamp reads ALCOOL · TABAC · DROGUES — INTERDIT with the slashed-circle icon.

The composition is deliberately asymmetric — no centred headline, no subtext-and-button stack, no gradient. The prohibited-goods rule is rendered as a poster, not a legal footnote: a full-width diagonal-striped band with a giant slashed-circle stamp over ALCOOL · TABAC · DROGUES. Every readable headline, label, number and control stays whole inside the viewport and its container at 375px, 768px and 1280px; the sticker card and its map tile may bleed off the edge as decoration.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the rotated sticker card carrying the live courier trace on a tangerine map tile, with the pulsing pink courier dot and the 100–400 DA chip — the product's defining state, a delivery moving inside the zone.
• Input → transformation → outcome thesis: as the visitor scrolls into the hero, the pink marquee ticker of live zone names runs along the top of the map band; the courier dot pulses and its trail draws on the map tile; the price chip counts 100 → 400 DA on scroll into view. The outcome is a first frame that already shows a delivery in motion, without adding any behaviour the product does not have.
• Motion vocabulary: marquee ticker, drawn-on trail, pulsing dot, counting price chip, colour-field flips on transport pills and zone cards (tangerine → pink on hover), and the walking pill visibly disabling once distance passes 1.5 km.
• Composed first frame: cream ground; headline block left with the pink band behind the middle line and the 12px ink rule beneath; three transport pills beneath the headline; emerald CTA; rotated sticker card bleeding off the right edge with the map tile, pulsing dot and price chip; emerald prohibited-goods stamp bottom-left.
• Reduced-motion state: all loops stop. The marquee items wrap into static rows, the trail and dot render in their final drawn state, the price chip shows its settled value, and the transport pills and zone cards show their resting colour fields. Nothing moves, and every item remains fully readable.

9. Non-Functional Requirements

• NFR-1 — Real-time tracking latency (explicit, from "Real Time maps follow up"): courier position updates must reach the requester's map promptly enough to be experienced as live tracking during an active delivery. Rationale: the requester's core outcome is following the courier in real time.
• NFR-2 — Live location permission handling (required_inference): the application must request and respect live location permission, and must degrade to the last known state when permission is denied or the stream drops, without ending the delivery. Rationale: tracking must remain truthful and recoverable.
• NFR-3 — Price-range enforcement (explicit): no delivery fee may be presented or settled below 100 DA or above 400 DA. Rationale: explicit hard constraint.
• NFR-4 — Zone-size enforcement (explicit): no service zone may exceed 5 km. Rationale: explicit hard constraint.
• NFR-5 — Distance-tier enforcement (explicit): walking must not be selectable for deliveries beyond 1.5 km. Rationale: explicit hard constraint.
• NFR-6 — Prohibited-goods enforcement (explicit): alcohol, smoking/tobacco products, and drugs must be rejected at request submission and must never appear as purchasable items for the courier. Rationale: explicit hard constraint.
• NFR-7 — Algerian market fit (explicit): the interface must present the service in a modern design suited to the Algerian market, with Arabic and Latin numerals both set in Outfit for tabular price alignment. Rationale: explicit requirement.
• NFR-8 — Readable text and controls at every viewport (from the creative direction): headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, and must not be covered by any other element. Rationale: legibility and control integrity.
• NFR-9 — Reduced-motion support (from the creative direction): all motion loops must stop under prefers-reduced-motion, with marquee items wrapping into static rows and every item fully readable. Rationale: accessibility.
• NFR-10 — Identity continuity (required_inference): requester and courier state must remain bound to the correct participant across sessions, so that requests, accepted deliveries, and fee obligations are not lost or misattributed. Rationale: durable participant-bound state is indispensable to the accepted journeys.

10. Tech Stack

• Frontend: React (custom UI, mobile-first, responsive at 375px / 768px / 1280px).
• Backend: Python / FastAPI, with backend integration for requests, courier acceptance, pricing, settlement, and live tracking.
• Storage: appropriate persistent storage for accounts, roles, requests, accepted deliveries, delivery fees, and delivery state.
• Real-time map and live location: a real-time map surface with live courier location streaming for the active delivery.
• Containerization: Docker / docker-compose for local and deployment packaging.
• Orchestration: Kubernetes only if deployment requires it.

No other technology choices are specified by the user; the above are the minimum needed to deliver the accepted behavior.

11. Assumptions and Constraints

Constraints (binding):

• Alcohol, smoking/tobacco products, and drugs may not be bought.
• Delivery price must be between 100 DA and a maximum of 400 DA.
• 0–1.5 km: on foot, bicycle, or trottinette allowed.
• 2–5 km: bicycle or trottinette only (no walking).
• Service zones must not exceed 5 km.
• Target market: Algeria.

Assumptions (narrow, labeled):

• [Assumption] Application-owned identity is used because requester requests, courier accepted work, the agreed delivery fee, and live delivery state must remain bound to the correct participant and be resumable across sessions.
• [Assumption] Enrollment is self-service for both roles, with role selection at enrollment distinguishing requester and courier responsibilities.
• [Assumption] The delivery fee is transferred by the courier, and delivery closure is gated on that transfer completing.
• [Assumption] Live location sharing is scoped to the duration of an active delivery.
• [Assumption] The prohibited-goods rule applies to what is bought through the service; it is not a statement about any other activity.
• [Default — not specified by user] The application is delivered as a responsive web application with custom UI; no native mobile packaging is specified.
• [Default — not specified by user] Map tiles, geocoding, and location streaming are provided by an external map/location provider; the application owns the tracking experience, not the map data itself.

12. Glossary

• Requester (Customer): the person in a covered zone who requests goods to be bought and delivered.
• Courier: the delivery person who accepts requests and fulfils them on foot, by bicycle, or by trottinette.
• À pied: on foot; permitted only for deliveries of 0–1.5 km.
• Vélo: bicycle; permitted for 0–1.5 km and 2–5 km deliveries.
• Trottinette: scooter; permitted for 0–1.5 km and 2–5 km deliveries.
• Distance tier: the 0–1.5 km tier (on foot, bicycle, or trottinette) or the 2–5 km tier (bicycle or trottinette only).
• Delivery fee: the amount transferred by the courier, from 100 DA to a maximum of 400 DA, depending on the delivery.
• Service zone: a delivery area no larger than 5 km.
• Prohibited goods: alcohol, smoking/tobacco products, and drugs, which may not be bought.
• Live tracking: the real-time map view of the active delivery showing the courier's live position.
• Settlement: the stage at which the courier completes the 100–400 DA delivery-fee transfer, required before delivery closure.
• Delivery closure: the end state of a delivery, reachable only after the delivery-fee transfer is completed.