System Requirements Document for sky-icy

1. Introduction

sky-icy is the website for Mohamed Tafran's workshop in the Netherlands — a family-run business that performs air-conditioner maintenance, installation work, camera (CCTV) installation, and heater/stove services. The product intent is to give the shop a public, Arabic-first presence that explains what the shop does and who it serves, lets visitors browse the four trades and past work, and lets them book a service or get in touch — while giving the shop owner a protected place to receive those requests and manage how the services and past work are presented.

The audience is deliberately two-track. The first track is households — individual homeowners who need a technician to show up and fix, install, or mount something. The second track is companies — facility representatives who need a vendor they can schedule and request a quote from. The site must serve both from the same public surface without diluting either: household trust and corporate credibility are both first-class outcomes.

The site is Arabic-first and right-to-left. Its visual language is workwear trust — kraft paper, ink, denim and safety orange, stamped badges, ruled panels — not a generic software template.

2. System Overview

sky-icy is delivered as a custom web application with a public, anonymous-facing side and a protected owner side.

Public side (no account required). Anonymous visitors — household customers and company representatives — can reach the home page, browse the four services and past work, submit a service booking, and send a message or request a quote. No registration is required for any of this.

Protected side (owner only). The shop owner (Mohamed) creates his own account through self-service registration, verifies himself on return via sign-in, and then uses two protected working destinations: an orders dashboard for incoming booking requests and messages from both households and companies, and a content-management destination for how the four services and past work are presented.

Actors. The accepted active human personas are exactly three: the shop owner (Mohamed), the household customer, and the company customer. No other human personas exist in this generation.

Current scope. Four services (air-conditioner maintenance, installation, cameras, heaters), a public booking path, a public contact/quote path, owner self-service identity, an orders dashboard, and content management.

Explicitly out of current scope. Nothing in the source authorizes online payment, invoicing, inventory, technician dispatch scheduling, customer accounts, or a customer-facing order history. These are not built.

2a. Product Interpretation and Delivery Boundary

The shop's own website owns everything the customer touches: the public pages, the booking form, the contact/quote form, and the owner's protected working surfaces. Identity is application-owned and self-service — the owner registers himself; there is no invitation, provisioning, or deployment bootstrap, and no customer account of any kind.

Access is split cleanly. The home page, services, booking, and contact destinations are anonymous and require no sign-in. The orders dashboard and content management are protected and require the owner to be signed in; the sign-in and registration surfaces are themselves anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself.

The household/company split is a presentation and routing distinction, not a permission distinction. Both audiences use the same public destinations and the same booking and contact paths; the site simply speaks to each in its own register and routes corporate enquiries toward a quote request. There is no role-based visibility over shared product state.

Everything described in this document is current. No future-horizon features are specified by the source.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

The page inventory below is the final, ordered page contract. Each page appears exactly once.

الرئيسية

• Information / state: What sky-icy is (an air-conditioner maintenance, installation, camera, and heater workshop), who it serves (households and companies), and what it offers — all before any sign-in or protected action. Anonymous, no account state.
• Primary actions: «احجز خدمة» (solid ink button with hard 2px orange offset shadow) and «عرض للشركات» (ghost button outlined in ink).
• Supporting actions: Navigate to الخدمات, حجز خدمة, تواصل معنا; follow the service-code ticker as a contact strip.
• Domain entities: Service (four trades), Audience track (household / company), Service code (AC-01, IN-02, CAM-03, HT-04).
• Component responsibilities:
  • Ruled spec-plate hero — wordmark sky-icy in Alfa Slab One, stacked on two lines, anchored right (RTL start), spanning columns 1–8, with a full-width hard orange rule beneath it; four stacked ruled rows on the opposite side, one per trade, each with a thick-line stencil icon, an Arabic label in Cairo 700 caps, and a tabular code.
  • Oversized badge stamp — 420–560px double-ring circular stamp (ink outer ring, orange inner ring), «EST. SKY-ICY» curved around the top and «24/7 SERVICE» around the bottom, half-bled off the hero edge, static (no rotation).
  • Two-track household/company band — one band split by a hard vertical rule: denim-navy corporate panel with «اطلب عرض سعر» and a short bullets list of facility services; kraft household panel with «احجز زيارة» and the emergency-call line; each panel carries its own differently-coloured stamp.
  • Service-code ticker — 32px-tall kraft-and-ink band with a slow marquee of service codes and phone numbers, ~40s per loop, doubling as a contact strip.

• States: Loading — static content, no loading state required. Empty — not applicable. Success — page renders fully with all four trades and both audience tracks visible. Error — if a service or past-work item fails to load, the page still renders the hero, both audience panels, and the ticker; the affected panel shows a plain retry affordance. Recovery — retry reloads the affected panel only.

الخدمات

• Information / state: The four services — صيانة مكيفات, تركيب, كاميرات, مدافئ — each as a ruled panel with badge number 01–04, plus past work. Anonymous, no account state.
• Primary actions: Open a service panel's detail; proceed to حجز خدمة for a chosen service.
• Supporting actions: Return to الرئيسية; reach تواصل معنا.
• Domain entities: Service (name, badge number, code, description), Past work item (image, short description).
• Component responsibilities:
  • Four ruled panels — 2×2 on desktop, single stacked column on mobile; each with a 3px solid ink border, 0–4px radius, a badge number 01–04, and a 96px reuse of the double-ring stamp as section marker.
  • Past-work gallery — halftone-duotone work photography (ink + orange), thick-line iconography, no stock people.
  • Service-code ticker — same contact strip as on الرئيسية.
• States: Loading — panels render as ruled skeletons with the badge numbers already in place. Empty — if no past work exists yet, the gallery area shows a plain ruled placeholder stating that work will be published soon; the four service panels still render. Success — all four panels and the gallery render. Error — a failed panel shows its badge number and a retry control; the other panels remain usable. Recovery — retry reloads the failed panel.

حجز خدمة

• Information / state: A booking form capturing the service type, contact details, and the requested appointment. Anonymous — no account required.
• Primary actions: Submit the booking.
• Supporting actions: Change the selected service; return to الخدمات; reach تواصل معنا instead.
• Domain entities: Booking request (service type, contact details, requested appointment, submission timestamp, status).
• Component responsibilities:
  • Service selector — the four trades, presented as ruled options with their codes.
  • Contact-details fields — name, phone, and any additional contact detail the customer supplies.
  • Requested-appointment field — the date/time the customer wants.
  • Submit control — stamped rectangular button with the 2px offset orange shadow that collapses on press.
  • Confirmation panel — replaces the form on success, restating the service, contact details, and requested appointment.
• States: Loading — submit control shows an in-progress state and is not double-submittable. Empty — the form starts empty with the service selector unselected. Success — a confirmation panel appears restating exactly what was submitted, and the request is visible to the owner in لوحة الطلبات. Error — validation errors appear inline against the offending field; a submission failure keeps every entered value and offers retry. Recovery — retry resubmits the preserved values.

تواصل معنا

• Information / state: How to reach the shop by phone, and a message form. Also serves the company quote request. Anonymous — no account required.
• Primary actions: Send a message; place a call.
• Supporting actions: Request a quote (company path); return to الرئيسية or الخدمات.
• Domain entities: Contact message (sender name, contact details, message body, whether it is a company quote request, submission timestamp, status).
• Component responsibilities:
  • Call block — the shop's phone number, presented as a stamped contact plate.
  • Message form — sender name, contact details, message body, and a company-quote indicator.
  • Submit control — stamped rectangular button, same press behaviour as elsewhere.
  • Confirmation panel — confirms the message was received.
  • Service-code ticker — same contact strip.
• States: Loading — submit control shows an in-progress state and is not double-submittable. Empty — the form starts empty. Success — confirmation appears and the message is visible to the owner in لوحة الطلبات. Error — inline validation errors; a submission failure preserves the typed message and offers retry. Recovery — retry resubmits the preserved message.

تسجيل الدخول

• Information / state: The owner's returning-verification surface. Anonymously reachable by design — it is the entry to protected state, not protected state itself.
• Primary actions: Sign in.
• Supporting actions: Go to إنشاء حساب if no account exists yet.
• Domain entities: Owner credential (identifier, secret).
• Component responsibilities:
  • Credential fields — identifier and secret.
  • Submit control — stamped rectangular button.
  • Error region — a single plain message for invalid credentials, without revealing which field was wrong.
• States: Loading — submit control shows an in-progress state. Empty — fields start empty. Success — the owner lands on لوحة الطلبات. Error — invalid credentials show a plain message and preserve the entered identifier. Recovery — the owner can retry immediately or move to إنشاء حساب.

إنشاء حساب

• Information / state: Self-service registration for the shop owner. No invitation and no pre-provisioning. Anonymously reachable by design.
• Primary actions: Create the account.
• Supporting actions: Go to تسجيل الدخول if an account already exists.
• Domain entities: Owner account (identifier, secret, creation timestamp).
• Component responsibilities:
  • Registration fields — the identifier and secret the owner chooses.
  • Submit control — stamped rectangular button.
  • Error region — inline messages for a taken identifier or an unusable secret.
• States: Loading — submit control shows an in-progress state. Empty — fields start empty. Success — the account is created and the owner proceeds to the protected working surfaces. Error — inline validation; a failure preserves entered values. Recovery — retry, or switch to تسجيل الدخول.

لوحة الطلبات

• Information / state: Incoming booking requests and messages from both households and companies, each with its service type or quote flag, contact details, requested appointment where applicable, and submission time. Protected — requires the owner to be signed in.
• Primary actions: Open a request; review its details.
• Supporting actions: Distinguish household bookings from company quote requests; move between لوحة الطلبات and إدارة المحتوى; sign out.
• Domain entities: Booking request, Contact message, Request status.
• Component responsibilities:
  • Request list — ruled rows, newest first, each showing service code or quote flag, sender, and time.
  • Request detail — the full submitted content, including the requested appointment for bookings.
  • Status control — the owner's own marking of where a request stands.
  • Empty state — a plain ruled panel stating that no requests have arrived yet.
• States: Loading — ruled skeleton rows. Empty — the empty panel described above. Success — requests render newest first and open into detail. Error — a failed load shows a retry control; a failed status change reverts the row and reports it. Recovery — retry reloads the list; the owner can re-apply the status change.

إدارة المحتوى

• Information / state: The current presentation of the four services and the past-work items. Protected — requires the owner to be signed in.
• Primary actions: Edit a service's presentation; add, edit, or remove a past-work item.
• Supporting actions: Move between إدارة المحتوى and لوحة الطلبات; sign out.
• Domain entities: Service (name, badge number, code, description), Past work item (image, short description).
• Component responsibilities:
  • Service editor — one ruled block per trade, preserving badge numbers 01–04 and codes AC-01 / IN-02 / CAM-03 / HT-04.
  • Past-work editor — add, edit, and remove items with their image and short description.
  • Save control — stamped rectangular button per block.
  • Empty state — a plain ruled panel when no past work exists yet.
• States: Loading — ruled skeletons per block. Empty — the empty panel described above; the four service blocks always render. Success — the saved change is reflected on الخدمات and الرئيسية. Error — a failed save keeps the edited values in place and reports the failure. Recovery — retry the save without re-entering the content.

3. Functional Requirements

Public discovery

FR-1 — Understand what the shop is and who it serves (explicit) As a household customer or a company customer, I should land on الرئيسية and immediately understand that sky-icy is an air-conditioner maintenance, installation, camera, and heater workshop serving both households and companies, so that I can decide whether this shop is relevant to me.

• Trigger/input: Anonymous visit to الرئيسية.
• Observable result: The wordmark, the four-trade spec plate, and the two-track household/company band are all visible without scrolling past the hero.
• Access state: Anonymous; no account required.
• Failure/recovery: If a dynamic panel fails to load, the hero, both audience panels, and the ticker still render; the failed panel offers retry.
• Continuation: The visitor chooses «احجز خدمة» or «عرض للشركات».

FR-2 — Browse the four services and past work (explicit) As a household customer or a company customer, I should browse الخدمات and see the four services — صيانة مكيفات, تركيب, كاميرات, مدافئ — each as its own ruled panel with a badge number 01–04, alongside past work, so that I can judge the shop's range and quality before committing.

• Trigger/input: Anonymous visit to الخدمات.
• Observable result: Four ruled panels render 2×2 on desktop and stacked on mobile, each with its badge number and code; the past-work gallery renders beneath.
• Access state: Anonymous; no account required.
• Failure/recovery: A failed panel shows its badge number and a retry control while the others stay usable; if no past work exists yet, a plain ruled placeholder states that work will be published soon.
• Continuation: The visitor proceeds to حجز خدمة for a chosen service, or to تواصل معنا.

FR-3 — Reach the shop by phone (explicit) As a household customer or a company customer, I should find the shop's phone number presented as a stamped contact plate on تواصل معنا and in the ticker, so that I can call directly instead of filling a form.

• Trigger/input: Anonymous visit to تواصل معنا, or reading the ticker on any page.
• Observable result: The phone number is fully readable and actionable.
• Access state: Anonymous; no account required.
• Failure/recovery: Not applicable — static contact content.
• Continuation: The visitor calls, or continues to the message form.

Booking and contact

FR-4 — Book a service (explicit) As a household customer or a company customer, I should submit a booking on حجز خدمة by choosing the service type, entering my contact details, and stating the appointment I want, so that the shop can schedule a visit.

• Trigger/input: The visitor selects one of the four trades, enters contact details, and states a requested appointment.
• Observable result: A confirmation panel restates the service, the contact details, and the requested appointment, and the request becomes visible to the owner in لوحة الطلبات.
• Access state: Anonymous; no account required.
• Failure/recovery: Inline validation errors appear against the offending field; a submission failure preserves every entered value and offers retry.
• Continuation: The visitor returns to الخدمات or الرئيسية, or sends a message on تواصل معنا.

FR-5 — Send a message to the shop (explicit) As a household customer or a company customer, I should send a message on تواصل معنا with my name, contact details, and message body, so that I can ask something the booking form does not cover.

• Trigger/input: The visitor fills the message form and submits.
• Observable result: A confirmation panel appears and the message becomes visible to the owner in لوحة الطلبات.
• Access state: Anonymous; no account required.
• Failure/recovery: Inline validation errors; a submission failure preserves the typed message and offers retry.
• Continuation: The visitor returns to الرئيسية or الخدمات.

FR-6 — Request a quote as a company (explicit) As a company customer, I should request a quote from the corporate track — via «اطلب عرض سعر» on الرئيسية or the company-quote indicator on تواصل معنا — so that my facility's needs are handled as a vendor enquiry rather than a single household visit.

• Trigger/input: The representative uses the denim corporate panel's «اطلب عرض سعر» or marks the message form as a company quote request.
• Observable result: The enquiry reaches the owner in لوحة الطلبات flagged as a company quote request, distinguishable from household bookings.
• Access state: Anonymous; no account required.
• Failure/recovery: Same as FR-5 — inline validation and preserved input on failure.
• Continuation: The representative waits for the shop's response through the contact details supplied.

Owner identity

FR-7 — Register the shop owner's account (required_inference) As the shop owner (Mohamed), I should create my own account on إنشاء حساب without an invitation or pre-provisioning, so that I can reach the protected working surfaces.

• Trigger/input: The owner supplies an identifier and a secret of his choosing.
• Observable result: The account is created and the owner proceeds to the protected working surfaces.
• Access state: إنشاء حساب is anonymously reachable by design; the protected destinations it leads to are not.
• Failure/recovery: Inline messages for a taken identifier or an unusable secret; entered values are preserved on failure.
• Continuation: The owner proceeds to لوحة الطلبات, or switches to تسجيل الدخول.

FR-8 — Verify on return (required_inference) As the shop owner (Mohamed), I should sign in on تسجيل الدخول when I come back, so that my requests and content stay bound to me and are not exposed to anyone else.

• Trigger/input: The owner supplies his identifier and secret.
• Observable result: The owner lands on لوحة الطلبات with his own requests and content.
• Access state: تسجيل الدخول is anonymously reachable by design; لوحة الطلبات and إدارة المحتوى require sign-in.
• Failure/recovery: Invalid credentials show a single plain message without revealing which field was wrong, and preserve the entered identifier.
• Continuation: The owner works in لوحة الطلبات or إدارة المحتوى, or moves to إنشاء حساب.

Owner work

FR-9 — Review incoming requests (required_inference) As the shop owner (Mohamed), I should review booking requests and messages from both households and companies in لوحة الطلبات, so that I can act on every enquiry that arrives.

• Trigger/input: The owner opens لوحة الطلبات while signed in.
• Observable result: Requests render newest first as ruled rows showing service code or quote flag, sender, and time; opening a row shows the full submitted content including the requested appointment for bookings.
• Access state: Protected — requires sign-in.
• Failure/recovery: A failed load shows a retry control; a failed status change reverts the row and reports it.
• Continuation: The owner marks the request's status, or moves to إدارة المحتوى.

FR-10 — Mark where a request stands (required_inference) As the shop owner (Mohamed), I should mark the status of each request in لوحة الطلبات, so that I can tell which enquiries I have already handled.

• Trigger/input: The owner changes the status control on a request.
• Observable result: The request's status is updated and reflected in the list.
• Access state: Protected — requires sign-in.
• Failure/recovery: A failed status change reverts the row and reports the failure; the owner can re-apply it.
• Continuation: The owner continues through the remaining requests.

FR-11 — Manage how the four services are presented (required_inference) As the shop owner (Mohamed), I should edit each service's presentation in إدارة المحتوى while preserving badge numbers 01–04 and codes AC-01 / IN-02 / CAM-03 / HT-04, so that what customers read on الخدمات and الرئيسية stays accurate.

• Trigger/input: The owner edits a service block and saves.
• Observable result: The saved change is reflected on الخدمات and الرئيسية.
• Access state: Protected — requires sign-in.
• Failure/recovery: A failed save keeps the edited values in place and reports the failure; retry does not require re-entering the content.
• Continuation: The owner continues to the next service block or to past work.

FR-12 — Manage past work (required_inference) As the shop owner (Mohamed), I should add, edit, and remove past-work items in إدارة المحتوى, so that the gallery on الخدمات shows real completed work.

• Trigger/input: The owner adds, edits, or removes a past-work item with its image and short description.
• Observable result: The gallery on الخدمات reflects the change; when no items exist, a plain ruled placeholder states that work will be published soon.
• Access state: Protected — requires sign-in.
• Failure/recovery: A failed save keeps the edited values in place and reports the failure.
• Continuation: The owner returns to لوحة الطلبات or signs out.

4. User Personas

صاحب المحل (محمد) — shop owner

Product context. Mohamed owns and runs a workshop that performs air-conditioner maintenance, installation work, camera installation, and heater services. He is the only person with a protected working surface on the site, and the only person who creates an account.

Primary goal. Receive new booking and contact requests from both households and companies, and keep the public presentation of his four services and his past work accurate.

Distinct accepted responsibilities. Mohamed's work is the only work on the site that is recurring and stateful. He registers himself on إنشاء حساب, verifies himself on return on تسجيل الدخول, reviews incoming requests in لوحة الطلبات, marks where each request stands, edits the four service blocks in إدارة المحتوى while preserving badge numbers 01–04 and codes AC-01 / IN-02 / CAM-03 / HT-04, and manages past-work items. No other persona has any of this.

Relevant inputs or decisions. He decides what each service says publicly, which past work to show, and how far along each request is. He supplies his own identifier and secret at registration.

Interactions with other accepted participants. Mohamed never interacts with customers inside the product. His relationship with them is one-directional and asynchronous: household customers and company representatives submit bookings and messages, and those submissions appear in his dashboard. He responds outside the product, through the contact details they supplied.

Observable success. New booking and contact requests from both the household and the company track arrive in لوحة الطلبات, and the public pages reflect the services and past work he has published.

عميل منزلي (أفراد بيوت) — household customer

Product context. A homeowner who needs one of the four trades done at their own home — an air conditioner serviced, something installed, cameras mounted, or a heater attended to. They arrive without an account and without any prior relationship with the shop.

Primary goal. Get a trustworthy technician to show up, with as little friction as possible.

Distinct accepted responsibilities. The household customer browses الخدمات to judge range and quality, then either books a visit on حجز خدمة by choosing the service, giving contact details, and stating the wanted appointment, or calls the number on تواصل معنا. Their defining concern is trust in who shows up — which is why the past-work gallery and the plain-spoken tone matter to them specifically.

Relevant inputs or decisions. Which of the four trades they need, their contact details, and the appointment they want. They decide between booking a visit and simply calling.

Interactions with other accepted participants. They hand their request to Mohamed through the booking or message form and then wait for him to reach them on the contact details they gave. They never see his dashboard.

Observable success. A confirmation panel restating their service, contact details, and requested appointment — and the shop reaching them to arrange the visit.

عميل شركات — company customer

Product context. A representative of a company or facility who needs a vendor for maintenance, installation, cameras, or heating across a site rather than a single home visit. They arrive anonymously, like the household customer, but they are evaluating the shop as a supplier.

Primary goal. Get a quote and arrange service for their company.

Distinct accepted responsibilities. The company representative browses the same الخدمات page but reads it as a capability statement, then takes the corporate track: «اطلب عرض سعر» on the denim panel of الرئيسية, or the company-quote indicator on تواصل معنا. Their defining concern is credibility and schedulability — whether this shop can be a vendor, not just a one-off technician.

Relevant inputs or decisions. The scope of services their facility needs, their contact details, and whether to request a quote or send a general message. They decide whether the shop's range is broad enough to be worth a vendor conversation.

Interactions with other accepted participants. Like the household customer, they hand their enquiry to Mohamed and wait for a response outside the product. Their enquiry arrives in لوحة الطلبات flagged as a company quote request, distinguishable from household bookings.

Observable success. Their quote request reaches the shop flagged as corporate, and Mohamed responds with a quote or an arrangement.

5. Core User Flows

Flow A — Household customer books a service

1. The household customer arrives at الرئيسية anonymously, with no account and no prior relationship with the shop.
2. They read the ruled spec-plate hero: the sky-icy wordmark, the four stacked trade rows with their codes (AC-01, IN-02, CAM-03, HT-04), and the two-track band that tells them this shop serves households as well as companies.
3. They choose «احجز خدمة» under the orange rule, or navigate to الخدمات first to judge range and quality.
4. On الخدمات, they see the four ruled panels — صيانة مكيفات, تركيب, كاميرات, مدافئ — each with its badge number 01–04, and the past-work gallery of duotone work photography. This is where their trust in who shows up is earned or lost.
5. They proceed to حجز خدمة and select the trade they need.
6. They enter their contact details and state the appointment they want.
7. They submit. The stamped button presses down onto its shadow.
8. Observable result: a confirmation panel restates the service, their contact details, and the requested appointment. The request is now visible to Mohamed in لوحة الطلبات.
9. Failure/recovery: if a field is invalid, an inline error appears against it; if submission fails, every entered value is preserved and they can retry without retyping.
10. Continuation: they return to الرئيسية or الخدمات, or — if they would rather talk — go to تواصل معنا and call the number on the stamped contact plate.

Flow B — Household customer calls instead of booking

1. The household customer arrives at الرئيسية anonymously.
2. They read the ticker along the bottom edge, which carries the service codes and the shop's phone number as a contact strip.
3. They navigate to تواصل معنا.
4. They read the phone number on the stamped contact plate and place the call.
5. Observable result: the call connects them to the shop directly; no form is submitted and no state changes in the product.
6. Continuation: if the call does not resolve their need, they can still send a message on the same page or book on حجز خدمة.

Flow C — Household customer sends a message

1. The household customer arrives at تواصل معنا anonymously.
2. They fill the message form: name, contact details, and message body.
3. They submit. The stamped button presses down onto its shadow.
4. Observable result: a confirmation panel appears, and the message becomes visible to Mohamed in لوحة الطلبات.
5. Failure/recovery: inline validation errors appear against offending fields; a submission failure preserves the typed message and offers retry.
6. Continuation: they return to الرئيسية or الخدمات.

Flow D — Company representative requests a quote

1. The company representative arrives at الرئيسية anonymously, evaluating the shop as a potential vendor.
2. They read the two-track band and find the denim-navy corporate panel, split from the kraft household panel by a hard vertical rule.
3. They read the short bullets list of facility services and choose «اطلب عرض سعر».
4. They land on تواصل معنا with the company-quote indicator set, or they may instead browse الخدمات first to read the four trades as a capability statement.
5. They enter their name, contact details, and the scope of what their facility needs.
6. They submit.
7. Observable result: a confirmation panel appears, and the enquiry reaches Mohamed in لوحة الطلبات flagged as a company quote request — distinguishable from household bookings.
8. Failure/recovery: inline validation errors; a submission failure preserves the typed enquiry and offers retry.
9. Continuation: the representative waits for Mohamed to respond through the contact details supplied.

Flow E — Shop owner registers and reaches his working surfaces

1. Mohamed arrives at إنشاء حساب, which is anonymously reachable by design — a protected destination cannot own the interaction that establishes access to itself.
2. He supplies an identifier and a secret of his own choosing. No invitation and no pre-provisioning are involved.
3. He submits.
4. Observable result: the account is created and he proceeds to the protected working surfaces.
5. Failure/recovery: if the identifier is taken or the secret unusable, an inline message appears and his entered values are preserved; he can retry or switch to تسجيل الدخول.
6. Continuation: he lands on لوحة الطلبات.

Flow F — Shop owner verifies on return

1. Mohamed returns to the site and goes to تسجيل الدخول, which is anonymously reachable by design.
2. He supplies his identifier and secret.
3. Observable result: he lands on لوحة الطلبات with his own requests and content.
4. Failure/recovery: invalid credentials show a single plain message that does not reveal which field was wrong, and his entered identifier is preserved. He can retry immediately or move to إنشاء حساب.
5. Continuation: he works in لوحة الطلبات or إدارة المحتوى.

Flow G — Shop owner reviews and marks incoming requests

1. Mohamed is signed in and opens لوحة الطلبات.
2. He sees requests from both households and companies, newest first, as ruled rows showing service code or quote flag, sender, and time.
3. He opens a row and reads the full submitted content — including the requested appointment for bookings.
4. He marks where the request stands using the status control.
5. Observable result: the request's status is updated and reflected in the list.
6. Failure/recovery: if the list fails to load, a retry control appears; if a status change fails, the row reverts and the failure is reported, and he can re-apply it.
7. Continuation: he continues through the remaining requests, or moves to إدارة المحتوى.
8. Empty state: if no requests have arrived yet, a plain ruled panel states so.

Flow H — Shop owner manages services and past work

1. Mohamed is signed in and opens إدارة المحتوى.
2. He edits a service block, preserving its badge number (01–04) and code (AC-01 / IN-02 / CAM-03 / HT-04), and saves.
3. Observable result: the saved change is reflected on الخدمات and الرئيسية.
4. He adds, edits, or removes a past-work item with its image and short description.
5. Observable result: the gallery on الخدمات reflects the change; if no items exist, a plain ruled placeholder states that work will be published soon.
6. Failure/recovery: a failed save keeps his edited values in place and reports the failure; retry does not require re-entering the content.
7. Continuation: he returns to لوحة الطلبات or signs out.

6. Visuals, Colors and Theme

Muse and headline. Aaron Draplin — badges and honest talk for a trades shop that never phones it in. The register is workwear trust: hand-built, plain-spoken, sturdy, slightly proud of its own grit. The name sky-icy carries the hot/cold duality of the trade, and the palette is built around it.

Colour tokens (light mode).

Proportion: ~65% kraft/bone, 25% ink, 8% denim, 2% orange. Orange is never used for body text and never as a large fill behind small type.

Typography.

• Headings: Alfa Slab One — wordmark, section titles, badge numbers. All-caps or near-caps, letter-spacing 0.02em, tight leading 0.95–1.05.
• Arabic display: Cairo 900, letter-spacing 0, expanded leading 1.15, so the slab weight reads as a stencil without breaking the joins.
• Labels and stamps: Cairo 700 uppercase, tracking 0.16em.
• Body: Cairo 400/500 at 17–18px with 1.75 line-height for Arabic legibility.
• Scale: 1.25 modular — 64 / 48 / 36 / 28 / 20 / 18 / 15 / 13. Display headline clamps 44px mobile → 104px desktop; section titles 28px → 44px; badge numerals 40px → 72px.

Shape language. Hard-edged everything: 0–4px radii, 3px solid ink borders on cards and buttons, chunky ruled dividers, circular badge stamps with a double ring (ink outer, orange inner). Buttons are rectangular with a 2px offset hard shadow — no blur — so they read as stamped, not floated. No pills, no soft shadows, no glass.

Layout. A poster grid: 12-column base with visible 1px kraft rules between major bands; asymmetric section headers where the title sits flush-left in columns 1–7 and the meta block (service code, price band, availability) sits flush-right in columns 9–12. Services are four ruled panels in a 2×2 on desktop and a single stacked column on mobile, each with a badge number 01–04. The household/company split is a two-track band: denim panel on one side, kraft panel on the other, meeting at a hard vertical rule. RTL-first: everything mirrors so the wordmark anchors right and the meta block anchors left.

Imagery. No stock people, no 3D renders. Thick 3–4px line-art icons of the four trades — a condenser unit, a wall bracket, a dome camera, a stove — drawn as if cut from stencil. Halftone-duotone photography of real work (a technician's hands on a unit, a roof bracket, a camera mounted on a shop wall) treated in ink + orange duotone so no image competes with the palette. Occasional map and schematic linework as texture, plus kraft-paper grain over the whole page.

Readable-text rule. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g. font-size: clamp(...) with its mobile size) to fit. No element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks — as long as they cover no readable text or control. The ticker may cross the viewport edge by design; every item becomes fully readable as it passes.

7. Signature Design Concept

The printed workshop poster. The public entry is a full-bleed kraft-paper hero built as a printed workshop poster, not a SaaS banner.

On the right (RTL start), the wordmark sky-icy is set in Alfa Slab One at clamp(44px, 9vw, 104px), stacked on two lines, spanning columns 1–8, with a hard orange rule running the full width beneath it. On the left, four stacked ruled rows — one per trade — each carrying a thick-line stencil icon, an Arabic label in Cairo 700 caps, and a code in tabular numerals: AC-01, IN-02, CAM-03, HT-04. The whole block reads like a machine's nameplate.

Behind everything, a large circular badge stamp — double ring, ink outer and orange inner, «EST. SKY-ICY» curved around the top and «24/7 SERVICE» around the bottom — sits oversized at 420–560px and half-bled off the left edge. It does not rotate; it is simply stamped.

Two CTAs sit directly under the orange rule: a solid ink «احجز خدمة» button with its hard 2px orange offset shadow, and a ghost «عرض للشركات» button outlined in ink. A thin kraft band runs along the bottom edge with the ticker of service codes.

No gradient, no blob, no centred stack. The hero is asymmetric, ruled, and RTL-mirrored throughout.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: the ruled spec-plate hero — the sky-icy wordmark over its full-width orange rule, the four trade rows with their codes, and the oversized half-bled badge stamp.
• Input → transformation → outcome thesis: as the visitor arrives, the section bands wipe in from the reading edge with a hard-edged clip — not a fade-through-blur — so the poster assembles itself like a printed sheet being laid down, and the visitor's eye lands on the wordmark and the four codes. No accepted behaviour is added; only the accepted content is revealed.
• Motion vocabulary: reveals are 180ms opacity + 2px translate, never springy. Badge hover presses the button down onto its shadow (translate 2px, shadow collapses to 0) so it feels physically stamped. Section bands wipe in from the reading edge with a hard-edged clip. A single slow marquee ticker of service codes runs along one band at ~40s per loop and is the only continuous motion.
• Composed first frame: the kraft ground, the wordmark anchored right over the orange rule, the four ruled trade rows flush against it, the badge stamp half-bled off the left edge, both CTAs beneath the rule, and the ticker band along the bottom — all fully composed before any motion begins.
• Reduced-motion state: with prefers-reduced-motion, the reveals and the press animation are removed and the ticker becomes a static arrangement — its items wrap into rows or become a horizontally scrollable strip so each service code and phone number can be brought fully into view. The poster composition is unchanged.

No parallax drift, no scroll-linked 3D, no bounces.

9. Non-Functional Requirements

NFR-1 — RTL-first layout (explicit) Every page mirrors to right-to-left. The wordmark anchors right; the meta block anchors left. This is a hard requirement of the creative direction, not a locale option.

NFR-2 — Arabic-first typography (explicit) Arabic display uses Cairo 900 with letter-spacing 0 and leading 1.15; body copy uses Cairo 400/500 at 17–18px with 1.75 line-height. Latin display uses Alfa Slab One. Inter, Roboto, Poppins, DM Sans, and any neutral geometric sans are excluded as the display voice.

NFR-3 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px. Where the direction asks readable text to be cropped or run off an edge, the gesture is carried by imagery or decoration instead.

NFR-4 — Reduced-motion support (explicit) With prefers-reduced-motion, the interface provides a usable static arrangement: the ticker's items wrap into rows or become horizontally scrollable so each item can be brought fully into view.

NFR-5 — Palette discipline (explicit) The palette stays kraft, ink, denim, and safety orange only. No blue–indigo primary or accent. No soft drop shadows, glass panels, gradient blobs, or 12px+ corner radii. The generic indigo/blue-on-white SaaS template is forbidden.

NFR-6 — Protected state stays protected (required_inference) لوحة الطلبات and إدارة المحتوى are reachable only by a signed-in owner. Requests and content remain bound to the owner who submitted or created them.

NFR-7 — Anonymous public access (explicit) الرئيسية, الخدمات, حجز خدمة, and تواصل معنا require no account. تسجيل الدخول and إنشاء حساب are anonymously reachable by design, because a protected destination cannot own the interaction that establishes access to itself.

NFR-8 — Durable request state (required_inference) Submitted bookings and messages persist and remain visible to the owner across sessions, so that no enquiry is lost between visits.

10. Tech Stack

• Frontend: React, RTL-first, with the poster-grid layout and the Alfa Slab One / Cairo type system.
• Backend: Python / FastAPI, serving the public read endpoints, the booking and contact submission endpoints, owner authentication, the requests API, and the content-management API from a single shared backend process.
• Storage: a relational database for owner accounts, booking requests, contact messages, services, and past-work items.
• Deployment: Docker / docker-compose, with the frontend, the backend, and the database as the runnable services.

No separate worker, queue, or additional ingress route is required by any accepted workflow. Kubernetes is not required.

11. Assumptions and Constraints

Assumptions.

• A-1 (required_inference) — The owner is the only person who creates an account. No customer account exists, and none is needed, because no accepted customer journey requires durable customer-specific state.
• A-2 (required_inference) — The household/company split is a presentation and routing distinction, not a permission distinction. Both audiences use the same public destinations.
• A-3 (required_inference) — The owner responds to requests outside the product, through the contact details the customer supplied. No in-product reply thread is specified.
• A-4 (required_inference) — The four service codes AC-01, IN-02, CAM-03, and HT-04 and the badge numbers 01–04 are fixed identifiers of the four trades and are preserved wherever services are presented or edited.

Constraints.

• C-1 (explicit) — The site is Arabic-first and RTL-mirrored on every page.
• C-2 (explicit) — The palette is kraft, ink, denim, and safety orange only; no blue–indigo primary or accent.
• C-3 (explicit) — No soft drop shadows, glass panels, gradient blobs, or 12px+ corner radii.
• C-4 (explicit) — No stock photography of smiling people in offices; imagery is duotone work photography and thick-line icons only.
• C-5 (explicit) — No decorative motion: no bounces, no parallax drift, no scroll-linked 3D.
• C-6 (explicit) — The hero must not be a centred headline + subtext + single button; it stays a ruled, asymmetric poster.
• C-7 (explicit) — The four services are ruled panels with distinct badge numbers and codes, not a grid of identical hover-lift cards.
• C-8 (explicit) — The generic indigo/blue-on-white SaaS template is forbidden for this project.

Out of current scope. Online payment, invoicing, inventory, technician dispatch scheduling, customer accounts, and customer-facing order history are not authorized by the source and are not built.

12. Glossary

• sky-icy — The project and the shop's wordmark.
• الرئيسية — The public entry page; anonymous.
• الخدمات — The public services and past-work page; anonymous.
• حجز خدمة — The public booking page; anonymous.
• تواصل معنا — The public contact and company-quote page; anonymous.
• تسجيل الدخول — The owner's returning-verification page; anonymously reachable by design.
• إنشاء حساب — The owner's self-service registration page; anonymously reachable by design.
• لوحة الطلبات — The owner's protected requests dashboard.
• إدارة المحتوى — The owner's protected content-management destination.
• Service code — The fixed identifier of a trade: AC-01 (صيانة مكيفات), IN-02 (تركيب), CAM-03 (كاميرات), HT-04 (مدافئ).
• Badge number — The 01–04 numeral stamped on each service panel.
• Two-track band — The denim/kraft split band on الرئيسية that addresses companies and households separately.
• Ticker — The 32px kraft-and-ink band carrying a slow marquee of service codes and phone numbers, doubling as a contact strip.
• Stamped button — A hard-edged rectangular button with a 2px offset orange shadow that collapses on press and hover.
• Badge stamp — The double-ring circular stamp (ink outer, orange inner) used oversized in the hero and at 96px as a section marker.
• Household customer — An individual homeowner needing one of the four trades.
• Company customer — A representative of a company or facility evaluating the shop as a vendor.