System Requirements Document for earthy-shadow

1. Introduction

earthy-shadow is an AI-assisted architectural plot-division tool for Egyptian architects and engineers. The product accepts the measured dimensions of a land parcel (قطعة أرض) and produces an impressive architectural subdivision (تقسيم معماري مبهر) that respects all architectural requirements under Egyptian building law and all architectural design standards necessary for the design.

The product's core deliverable is a generated AI prompt — a specification document that the architect submits to an AI design engine. The prompt is constructed from the plot dimensions the architect enters or uploads, and it encodes the Egyptian legal requirements and architectural standards that the resulting subdivision must satisfy. The product then produces and displays the proposed architectural division of the plot so the architect can review it against those requirements.

Audience: Practicing architects and engineers in Egypt who must produce a plot subdivision that will survive review by a municipality, a syndicate, and a client. The register of the product is technical, legal, and civic: the output is a document, and the emotional need is trust, legibility, and the feeling that a rule was applied — not a taste.

2. System Overview

earthy-shadow is a first-party web application with application-owned identity. The architectural designer establishes an account, enters or uploads plot dimensions, generates an AI prompt from those dimensions, and reviews the resulting architectural subdivision of the plot.

Current delivery: A custom web UI (six pages) backed by a server-side integration that constructs the AI prompt and produces the design result. Identity is application-owned: self-service enrollment and returning verification are required so that plot input, generated prompts, and design results remain bound to the correct architect and can be resumed.

Actors:

• مصمم/مهندس معماري (Architectural Designer) — the sole active human persona. Enters/uploads plot dimensions, generates the AI prompt, reviews the resulting subdivision.
• AI design engine — a non-persona system actor that consumes the generated prompt and returns the proposed architectural division.

Accepted behavior: plot dimension entry/upload; AI prompt generation from those dimensions; production of an impressive architectural subdivision; compliance with all Egyptian building-law architectural requirements; compliance with all necessary architectural design standards.

Narrow exclusions: No photography of people, no 3D architectural renders, no stock architecture imagery. No adjacent account-management capabilities beyond self-service enrollment and returning verification. No provider-owned or external-only delivery surface is established by the source.

2a. Product Interpretation and Delivery Boundary

The architect works inside a first-party application. The public entry surface (Landing) explains what the product does before any protected work. Because plot input, generated prompts, and design results are durable, architect-specific artifacts that must be resumed and revisited, the application owns identity: a new architect enrolls through self-service Sign Up, and a returning architect verifies through Login. The protected working surfaces — Plot Input, Prompt Generator, and Design Result — require that identity.

The AI design engine is a system actor, not a destination. The architect never leaves the application to reach it; the Prompt Generator constructs the prompt, and the Design Result surface presents what the engine returns. No future-horizon requirements are established by the source; everything in this document is current.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Public entry surface. Explains the AI architectural plot-division product, its audience (Egyptian architects and engineers), and what it does before any protected work. Presents the product as a drawing sheet: a measured plot plan rendered as colour-coded geometry with dimension lines and a north arrow, and a title-block panel listing the inputs as a table (المساحة، الواجهة، العمق، عرض الشارع، الاشتراطات المطبقة) with tabular numerals.
• Primary action: ابدأ التقسيم — a single solid red rectangular button with hard corners, leading to Sign Up (new architect) or Login (returning architect).
• Supporting actions: Navigate to Login; navigate to Sign Up.
• Domain entities: Plot plan diagram; input table (area, frontage, depth, street width, applied requirements); Egyptian code article ticker.
• Component responsibilities: Full-bleed drawing sheet split asymmetrically 7/5; headline قسّم أرضك بمسطرة القانون set flush-left in three stacked lines, overlaid on the plan's top-left and breaking out onto the paper ground; white title-block panel ruled with hairlines; 2px black rule running the full viewport width beneath both halves; thin uppercase ticker of Egyptian code article numbers on that rule.
• States: Loading — static document, no loading state required. Empty — not applicable. Success — static render. Error — not applicable. Recovery — not applicable.

Sign Up

• Information/state: Self-service enrollment for the architectural designer, who independently begins using the product with no invitation or provisioning boundary established. Ruled-rectangle inputs with labels sitting above the line in small caps.
• Primary action: Create the architect's account and enter the protected working surfaces.
• Supporting actions: Navigate to Login for an architect who already has an account.
• Domain entities: Architect identity (credentials).
• Component responsibilities: Ruled input fields; hard-cornered red submit button; hairline-ruled layout; persistent left drawing title-block column.
• States: Loading — submit in progress. Empty — initial blank form. Success — account established, architect proceeds to Plot Input. Error — invalid or incomplete input, or an account already exists for the supplied identity; the form retains entered values and states the failure. Recovery — architect corrects the input and resubmits, or navigates to Login.

Login

• Information/state: Returning verification for the architectural designer to access protected plot input, prompt generation, and design result work.
• Primary action: Verify the architect's identity and enter the protected working surfaces.
• Supporting actions: Navigate to Sign Up for an architect who has no account.
• Domain entities: Architect identity (credentials).
• Component responsibilities: Ruled input fields; hard-cornered red submit button; hairline-ruled layout; persistent left drawing title-block column.
• States: Loading — verification in progress. Empty — initial blank form. Success — identity verified, architect proceeds to Plot Input. Error — credentials not recognized; the form retains the entered identity and states the failure without revealing which element was wrong. Recovery — architect retries, or navigates to Sign Up.

Plot Input

• Information/state: Owns the accepted responsibility of entering or uploading plot dimensions as the design input. Composed as a sheet: drawing or plan on the left 7 columns, a tabular regulation ledger on the right 5 columns, both aligned to the same baseline grid. The persistent left title-block column carries plot ID, area, governorate, street width, and applied code article.
• Primary action: Submit the plot dimensions to proceed to prompt generation.
• Supporting actions: Enter dimensions directly into ruled rectangle inputs; upload a dimension file; review the regulation ledger alongside the plan.
• Domain entities: Plot dimensions (area, frontage, depth, street width); governorate; plot ID; applied code article; regulation ledger entries.
• Component responsibilities: Ruled rectangle dimension inputs with small-caps labels above the line; upload control; plot plan drawing area; regulation ledger table with hairline rules; colour-coded regulation legend (ارتداد، ارتفاع، نسبة البناء، الخدمات، الحركة) that saturates only the matching geometry in the plan on hover or tap and dims the rest.
• States: Loading — dimension file being read or plan being recalculated. Empty — no dimensions entered yet; the plan area shows the empty plot frame with the north arrow and scale bar. Success — dimensions accepted; the plan re-renders as colour-coded bands wiping in from the left in strict order (boundary → setback → envelope → circulation → green), 180ms each. Error — dimensions missing, non-numeric, or internally inconsistent; the offending ruled field is marked and the ledger states the failure. Recovery — architect corrects the dimensions and resubmits; entered values are retained.

Prompt Generator

• Information/state: Owns generating the AI prompt based on the entered plot dimensions for designing and dividing the plot. The generated prompt is presented as a monospaced document sheet with a line-number gutter, ruled page edges, and a red copy stamp block — a specification document, not a chat bubble.
• Primary action: Generate the AI prompt from the entered plot dimensions.
• Supporting actions: Copy the generated prompt; return to Plot Input to revise dimensions.
• Domain entities: Generated AI prompt text; source plot dimensions; applied Egyptian code articles; architectural standards encoded in the prompt.
• Component responsibilities: Monospaced prompt sheet with line-number gutter; red copy stamp block; persistent left title-block column carrying the running project metadata; 2px black section rules with numbered labels.
• States: Loading — prompt being constructed from the entered dimensions. Empty — no dimensions available yet; the architect is directed back to Plot Input. Success — prompt rendered in full on the document sheet. Error — prompt generation failed; the failure is stated on the sheet with a retry action. Recovery — architect retries generation, or returns to Plot Input to correct the dimensions.

Design Result

• Information/state: Owns producing and displaying the proposed architectural division of the plot while respecting Egyptian law requirements and architectural standards. Composed as a sheet: the plan on the left 7 columns, the tabular regulation ledger on the right 5 columns, both aligned to the same baseline grid.
• Primary action: Produce the architectural subdivision of the plot from the generated prompt and display it.
• Supporting actions: Read the plan against the regulation ledger; hover or tap a legend entry to saturate only that geometry and dim the rest; return to Plot Input or Prompt Generator to revise.
• Domain entities: Proposed architectural subdivision; building envelope; setback band; circulation; green/open space; service strip; regulation ledger entries; applied code article.
• Component responsibilities: Colour-coded plot plan (black boundary, yellow setback band, red building envelope, teal service strip, blue circulation); dimension lines with arrowheads; north arrow; scale bar; parking-bay pictograms; regulation pictograms (setback, height limit, building ratio, ventilation shaft); regulation ledger table; colour-coded legend that is also the interaction model.
• States: Loading — the plan re-renders as colour-coded bands wiping in from the left in strict order (boundary → setback → envelope → circulation → green), 180ms each, with a 120ms opacity cross-fade on recalculation. Empty — no design result yet; the architect is directed back to Prompt Generator. Success — the subdivision is displayed with its regulation ledger. Error — the design could not be produced; the failure is stated with a retry action. Recovery — architect retries, or returns to Prompt Generator or Plot Input to revise.

3. Functional Requirements

FR-1 — Generate an AI prompt for plot design and division As an architectural designer, I should generate an AI prompt that is used to design and divide a land plot, so that I have a specification document to submit to the AI design engine.

• Provenance: explicit
• Trigger/input: The architect requests prompt generation from the Prompt Generator after plot dimensions exist.
• Observable result: A complete AI prompt is rendered as a monospaced document sheet with a line-number gutter, ruled page edges, and a red copy stamp block.
• Access state: Requires verified identity (Login).
• Failure/recovery: If generation fails, the failure is stated on the sheet with a retry action; the architect may return to Plot Input to correct dimensions.
• Continuation: The architect copies the prompt or proceeds to the Design Result.

FR-2 — Enter or upload plot dimensions As an architectural designer, I should enter or upload the dimensions of the land plot into the system, so that the design is based on the actual measured parcel.

• Provenance: explicit
• Trigger/input: The architect enters dimensions into ruled rectangle inputs or uploads a dimension file on Plot Input.
• Observable result: The dimensions are accepted and the plan re-renders as colour-coded bands wiping in from the left in strict order (boundary → setback → envelope → circulation → green), 180ms each.
• Access state: Requires verified identity (Login).
• Failure/recovery: If dimensions are missing, non-numeric, or internally inconsistent, the offending ruled field is marked and the ledger states the failure; entered values are retained for correction.
• Continuation: The architect proceeds to the Prompt Generator.

FR-3 — Produce an impressive architectural subdivision of the plot As an architectural designer, I should receive an impressive architectural subdivision of the plot produced from the entered dimensions, so that I have a proposed division to review and present.

• Provenance: explicit
• Trigger/input: The generated AI prompt is submitted to the AI design engine.
• Observable result: The proposed architectural division of the plot is displayed on the Design Result sheet as colour-coded geometry with dimension lines, a north arrow, and a scale bar.
• Access state: Requires verified identity (Login).
• Failure/recovery: If the design cannot be produced, the failure is stated with a retry action; the architect may return to the Prompt Generator or Plot Input to revise.
• Continuation: The architect reads the plan against the regulation ledger and revises if needed.

FR-4 — Respect all architectural requirements under Egyptian law As an architectural designer, I should have the design respect all architectural requirements under Egyptian building law, so that the subdivision survives review by a municipality and a syndicate.

• Provenance: explicit
• Trigger/input: The generated prompt encodes the applicable Egyptian code articles; the design result is evaluated against them.
• Observable result: The regulation ledger on Plot Input and Design Result lists the applied code article and the corresponding regulation entries, and the plan's coded geometry reflects them.
• Access state: Requires verified identity (Login).
• Failure/recovery: If a requirement cannot be satisfied by the entered dimensions, the ledger states the conflict and the architect revises the dimensions.
• Continuation: The architect revises dimensions or accepts the compliant result.

FR-5 — Respect all necessary architectural design standards As an architectural designer, I should have the design respect all architectural design standards necessary for the design, so that the subdivision is professionally sound beyond bare legal compliance.

• Provenance: explicit
• Trigger/input: The generated prompt encodes the architectural standards; the design result is evaluated against them.
• Observable result: The plan's coded geometry includes setback, building envelope, circulation, green/open space, and services, each readable through the colour-coded legend.
• Access state: Requires verified identity (Login).
• Failure/recovery: If a standard cannot be satisfied, the ledger states the conflict and the architect revises the dimensions.
• Continuation: The architect revises dimensions or accepts the compliant result.

FR-6 — Self-service enrollment for the architectural designer As an architectural designer, I should be able to enroll myself without an invitation or provisioning step, so that I can independently begin using the product.

• Provenance: required_inference
• Trigger/input: The architect selects ابدأ التقسيم on Landing and proceeds to Sign Up.
• Observable result: An account is established and the architect enters the protected working surfaces.
• Access state: Anonymous entry (Sign Up is publicly reachable).
• Failure/recovery: If the input is invalid or incomplete, or an account already exists, the form retains entered values and states the failure; the architect corrects and resubmits or navigates to Login.
• Continuation: The architect proceeds to Plot Input.

FR-7 — Returning verification for the architectural designer As an architectural designer, I should be able to verify my identity on return, so that my plot input, generated prompts, and design results remain bound to me and can be resumed.

• Provenance: required_inference
• Trigger/input: The architect submits credentials on Login.
• Observable result: Identity is verified and the architect enters the protected working surfaces.
• Access state: Anonymous entry (Login is publicly reachable).
• Failure/recovery: If credentials are not recognized, the form retains the entered identity and states the failure without revealing which element was wrong; the architect retries or navigates to Sign Up.
• Continuation: The architect proceeds to Plot Input.

FR-8 — Plot dimensions entered or uploaded before prompt generation As an architectural designer, I should have plot dimensions entered or uploaded before prompt generation, so that the generated prompt is grounded in the actual parcel.

• Provenance: required_inference
• Trigger/input: The architect attempts prompt generation.
• Observable result: Prompt generation is available only when dimensions exist; otherwise the architect is directed back to Plot Input.
• Access state: Requires verified identity (Login).
• Failure/recovery: If no dimensions exist, the Prompt Generator shows an empty state directing the architect to Plot Input.
• Continuation: The architect enters dimensions and returns to the Prompt Generator.

FR-9 — AI prompt generated from entered plot dimensions before design output As an architectural designer, I should have the AI prompt generated from the entered plot dimensions before any design output is produced, so that the design is derived from the prompt rather than from an unstated input.

• Provenance: required_inference
• Trigger/input: The architect requests design output.
• Observable result: The Design Result is produced from the generated prompt; if no prompt exists, the architect is directed back to the Prompt Generator.
• Access state: Requires verified identity (Login).
• Failure/recovery: If no prompt exists, the Design Result shows an empty state directing the architect to the Prompt Generator.
• Continuation: The architect generates the prompt and returns to the Design Result.

4. User Personas

مصمم/مهندس معماري (Architectural Designer)

Product context. A practicing architect or engineer in Egypt who must produce a subdivision of a measured land parcel that will be reviewed by a municipality, a syndicate, and a client. The work is technical, legal, and civic: every line in the output means a regulation, and the output must survive scrutiny rather than please a taste.

Primary goal. Obtain an impressive architectural subdivision of a land plot that respects all architectural requirements under Egyptian building law and all architectural design standards necessary for the design.

Distinct accepted responsibilities.

• Enter or upload the dimensions of the land plot as the design input.
• Generate the AI prompt from those dimensions.
• Review the proposed architectural subdivision against the Egyptian legal requirements and architectural standards.
• Revise the input when a requirement or standard cannot be satisfied.

Relevant inputs or decisions. Plot dimensions (area, frontage, depth, street width), governorate, and the applicable code article. The architect decides whether the entered dimensions are correct, whether the generated prompt is complete, and whether the resulting subdivision is acceptable.

Interactions with other accepted participants. The architect is the sole active human persona. The AI design engine is a system actor that consumes the generated prompt and returns the proposed division; the architect does not interact with it directly, only through the Prompt Generator and Design Result surfaces.

Observable success. A displayed subdivision whose regulation ledger lists the applied code article and whose coded geometry — boundary, setback, building envelope, circulation, green, services — is readable at a glance through the legend.

What makes this role's work different. The architect is not a consumer browsing a gallery; the architect is producing a compliance document. The role's value is in the legibility of the rule application, not in the delight of the interface.

5. Core User Flows

Flow A — New architect enrolls and produces a plot subdivision

1. The architect arrives at Landing (anonymous). The page presents the product as a drawing sheet: a measured plot plan in colour-coded geometry with dimension lines and a north arrow, and a white title-block panel listing the inputs as a table (المساحة، الواجهة، العمق، عرض الشارع، الاشتراطات المطبقة) with tabular numerals.
2. The architect reads the headline قسّم أرضك بمسطرة القانون and selects the single solid red rectangular button ابدأ التقسيم.
3. The architect lands on Sign Up (anonymous). The architect supplies the required identity information into ruled rectangle inputs whose labels sit above the line in small caps.
4. The architect submits. On success, an account is established and the architect enters the protected working surfaces. On failure — invalid or incomplete input, or an account already exists — the form retains the entered values and states the failure; the architect corrects and resubmits, or navigates to Login.
5. The architect arrives at Plot Input (verified). The persistent left title-block column shows plot ID, area, governorate, street width, and applied code article. The sheet is composed with the drawing on the left 7 columns and the tabular regulation ledger on the right 5 columns.
6. The architect enters the plot dimensions into the ruled rectangle inputs, or uploads a dimension file. The plan re-renders as colour-coded bands wiping in from the left in strict order (boundary → setback → envelope → circulation → green), 180ms each.
7. The architect hovers or taps a legend entry (ارتداد، ارتفاع، نسبة البناء، الخدمات، الحركة). Only that geometry in the plan saturates; the rest dims.
8. If dimensions are missing, non-numeric, or internally inconsistent, the offending ruled field is marked and the ledger states the failure; entered values are retained. The architect corrects and resubmits.

9. The architect proceeds to Prompt Generator (verified). The generated AI prompt is rendered as a monospaced document sheet with a line-number gutter, ruled page edges, and a red copy stamp block.
10. The architect copies the prompt, or proceeds to the Design Result.
11. The architect arrives at Design Result (verified). The proposed architectural subdivision is displayed as colour-coded geometry — black boundary, yellow setback band, red building envelope, teal service strip, blue circulation — with dimension lines, a north arrow, a scale bar, and parking-bay pictograms. The regulation ledger on the right 5 columns lists the applied code article and the corresponding regulation entries.
12. The architect reads the plan against the ledger. If a requirement or standard cannot be satisfied, the ledger states the conflict and the architect returns to Plot Input or Prompt Generator to revise the dimensions.
13. The architect accepts the compliant result.

Flow B — Returning architect resumes and revises a subdivision

1. The architect arrives at Landing (anonymous) and selects ابدأ التقسيم.
2. The architect lands on Login (anonymous) and submits credentials.
3. On success, identity is verified and the architect enters the protected working surfaces. On failure, the form retains the entered identity and states the failure without revealing which element was wrong; the architect retries or navigates to Sign Up.
4. The architect arrives at Plot Input (verified) with the previously entered plot dimensions and the running project metadata in the left title-block column.
5. The architect revises the dimensions. The plan re-renders as colour-coded bands wiping in from the left in strict order, 180ms each, with a 120ms opacity cross-fade on recalculation.
6. The architect proceeds to Prompt Generator (verified) and regenerates the AI prompt from the revised dimensions.
7. The architect proceeds to Design Result (verified) and reviews the revised subdivision against the regulation ledger.
8. The architect accepts the compliant result.

Flow C — Architect attempts prompt generation without dimensions

1. The architect is on Prompt Generator (verified) with no plot dimensions recorded.
2. The page shows an empty state directing the architect back to Plot Input.
3. The architect returns to Plot Input, enters the dimensions, and returns to the Prompt Generator.
4. The prompt is generated and rendered on the document sheet.

Flow D — Architect attempts design output without a generated prompt

1. The architect is on Design Result (verified) with no generated prompt.
2. The page shows an empty state directing the architect back to the Prompt Generator.
3. The architect returns to Prompt Generator, generates the prompt, and returns to the Design Result.
4. The subdivision is produced and displayed with its regulation ledger.

6. Visuals Colors and Theme

Muse: Massimo Vignelli. Headline direction: Systematic clarity — a plot becomes a coded diagram.

Colour tokens (light mode):

No tints, no gradients, no translucency anywhere. Every band is flat and full-strength.

Typography:

• Headings: Archivo, weight 600–700, flush-left ragged-right, tracking −0.02em at display sizes and +0.14em uppercase for micro-labels. No centred type, no italics, no decorative ligatures.
• Arabic headings: IBM Plex Sans Arabic, weight 600, same flush-left rhythm, line-height 1.25.
• Body: IBM Plex Sans Arabic.
• Scale: 1.333 modular — 112/84/56/42/28/21/17/15. Display clamp(56px, 9vw, 112px) for the hero statement; section headings clamp(32px, 4vw, 56px); body 17px/1.55 desktop, 16px/1.6 mobile; captions and units 15px uppercase tracking +0.14em.
• Numerals always tabular (font-feature-settings: 'tnum'); dimensions always written as 24.00 m with two decimals so columns align.

Shape language: Hard edges only — 0px radius on every surface, button, input, and image. Structure is expressed with rules, not shadows: 1px black hairlines for internal division, 2px black for section boundaries, 4px black for the plot frame. Colour-coded horizontal bands (red/yellow/teal/blue) act as wayfinding. Inputs are ruled rectangles with the label sitting above the line in small caps. The only circle permitted is the north arrow and the area-scale dial in the drawing legend.

Layout: A visible 12-column grid with 24px gutters, max content width 1440px, and a persistent left column (3 of 12) holding the running project metadata — plot ID, area, governorate, street width, applied code article — like a drawing title block. The right 9 columns hold content. Sections are separated by full-bleed 2px black rules that run edge to edge, and each section opens with a numbered label (01, 02, 03) in the left column. Plot Input and Design Result are composed as a sheet: drawing or plan on the left 7 columns, tabular regulation ledger on the right 5 columns, both aligned to the same baseline grid. Nothing floats; everything is anchored to a column edge.

Imagery: No photography of people, no 3D renders, no stock architecture. The imagery IS the diagram: vector plot plans, dimension lines with arrowheads, hatched setback zones, north arrows, scale bars, parking-bay pictograms, section-cut diagrams, and a small library of regulation pictograms (setback, height limit, building ratio, ventilation shaft) drawn in 2px black strokes. Screenshots of the generated prompt appear as a monospaced document sheet with a visible line-number gutter. If a site photo is ever needed, it is a flat, high-contrast, desaturated aerial of the parcel cropped to the grid with the boundary drawn over it in red.

7. Signature Design Concept

The first screen is a full-bleed drawing sheet, not a centred SaaS hero.

On the warm paper ground (#F4F1EA), the Landing page is split asymmetrically 7/5. The left seven columns hold an actual measured plot plan rendered as colour-coded geometry — black boundary, yellow setback band inset from the line, red building envelope, teal service strip, blue circulation — with dimension lines and a north arrow, occupying the full height of the viewport and bleeding off the left and bottom edges. Overlaid on the plan's top-left, the headline قسّم أرضك بمسطرة القانون is set in Archivo at clamp(56px, 9vw, 112px), flush-left, three stacked lines, breaking out of the plan onto the paper ground.

The right five columns hold a white title-block panel, ruled with hairlines, listing the inputs as a table (المساحة، الواجهة، العمق، عرض الشارع، الاشتراطات المطبقة) with tabular numerals, ending in a single solid red rectangular button ابدأ التقسيم with hard corners.

A 2px black rule runs the full viewport width beneath both halves, and a thin uppercase ticker of Egyptian code article numbers sits on that rule. Nothing is centred; nothing floats; the plan is the hero and the type sits on top of it.

Signature moves carried across the product:

• A persistent left-hand drawing title-block column on every page carrying the running project metadata in 15px uppercase tabular type, separated from content by a 1px black rule — it never scrolls away on desktop and collapses to a single ruled strip under the header at 375px.
• A colour-coded regulation legend that is also the interaction model: hovering or tapping a legend entry (ارتداد، ارتفاع، نسبة البناء، الخدمات، الحركة) saturates only that geometry in the plan and dims the rest, so the drawing is read the way a subway map is read.
• Full-bleed 2px black horizontal rules that run edge to edge between every section, each with a numbered label (01 / 02 / 03) and an uppercase section name sitting on the rule in the left column — the page reads as a set of stacked sheets, not as cards.
• The generated AI prompt is presented as a monospaced document sheet with a line-number gutter, ruled page edges, and a red copy stamp block, so it looks like a specification document rather than a chat bubble.
• Zero-radius everything: ruled rectangle inputs, hard-cornered red buttons, and hairline-ruled tables — no shadows, no rounded cards, no hover-lift anywhere in the product.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The measured plot plan — black boundary, yellow setback band, red building envelope, teal service strip, blue circulation — with dimension lines and a north arrow, bleeding off the left and bottom edges of the viewport.
• Input → transformation → outcome thesis: The architect's measured parcel (input) is rendered as a coded diagram whose every line means a regulation (transformation), so the architect reads compliance at a glance before any protected work (outcome). The hero uses only accepted behavior: the plan is the product's defining state.
• Motion vocabulary: Almost none, and never decorative. State changes are instant (0ms) with a 120ms opacity cross-fade only when a plan is recalculated. On plot submission, the drawing re-renders as a sequence of colour-coded bands wiping in from the left in strict order (boundary → setback → envelope → circulation → green), 180ms each, no easing theatrics. Hover on a legend entry highlights its geometry in the plan by switching that band to full saturation — a functional link, not a flourish. Scroll reveals nothing; the page is a document.
• Composed first frame: The full-bleed drawing sheet at rest — plan on the left seven columns, white title-block panel on the right five, headline قسّم أرضك بمسطرة القانون stacked flush-left over the plan's top-left, 2px black rule and code-article ticker beneath both halves.
• Reduced-motion state: Under prefers-reduced-motion, the band wipe becomes a single instant swap. The composed first frame is unchanged; the legend hover still switches the band to full saturation, since that is a functional link rather than a decorative animation.

9. Non-Functional Requirements

NFR-1 — Egyptian legal compliance is a hard constraint The design must respect all architectural requirements under Egyptian building law. Provenance: explicit. Rationale: the source states this as a hard constraint; the output must survive review by a municipality and a syndicate.

NFR-2 — Architectural design standards are a hard constraint The design must respect all architectural design standards necessary for the design. Provenance: explicit. Rationale: the source states this as a hard constraint; legal compliance alone is not sufficient.

NFR-3 — Readable text and controls stay whole at every viewport Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the creative direction asks, as long as it covers no readable text or control. Provenance: explicit (creative direction).

NFR-4 — Reduced-motion support Under prefers-reduced-motion, the band wipe becomes a single instant swap, and any moving or scrollable content provides a usable static arrangement. Provenance: explicit (creative direction).

NFR-5 — Tabular numerals and fixed dimension formatting Numerals are always tabular (font-feature-settings: 'tnum'), and dimensions are always written as 24.00 m with two decimals so columns align. Provenance: explicit (creative direction).

NFR-6 — Identity continuity for durable architect artifacts Plot input, generated prompts, and design results are durable, architect-specific artifacts; identity must remain bound to the correct architect so the work can be resumed and revisited. Provenance: required_inference. Rationale: required to make the accepted journey executable without adding a product capability.

10. Tech Stack

• Frontend: React (custom web UI, six pages).
• Backend: Python / FastAPI — a single shared backend process extending the existing service with routes and modules for plot input, prompt generation, and design result retrieval.
• Storage: A relational store for architect identity, plot dimensions, generated prompts, and design results.
• AI design engine: An external system actor consumed by the backend; the generated prompt is submitted to it and the proposed architectural division is returned.
• Deployment: Docker / docker-compose for the frontend, backend, and storage services. Kubernetes is not required by the source.

11. Assumptions and Constraints

Assumptions

• The architect has access to the measured dimensions of the land parcel (area, frontage, depth, street width) and the applicable governorate and code article.
• The AI design engine is reachable from the backend and accepts the generated prompt as its input.
• The applicable Egyptian code articles are encoded in the generated prompt by the backend; the source does not specify a separate regulation database.

Constraints

• The design must respect all architectural requirements under Egyptian building law. (explicit)
• The design must respect all architectural design standards necessary for the design. (explicit)
• No photography of people, no 3D architectural renders, and no stock architecture imagery. (explicit, creative direction)
• No rounded-corner cards, soft drop shadows, hover-lift tiles, gradient blobs, glassmorphism, frosted panels, or translucent overlays. (explicit, creative direction)
• Blue–indigo (#2563EB, #4F46E5, #6366F1) is forbidden as a UI accent; blue exists only as the circulation code inside the drawing legend. (explicit, creative direction)
• Inter, Roboto, Arial, Helvetica, Poppins, and system-ui are forbidden for headings and body copy. (explicit, creative direction)
• The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit, creative direction)
• No adjacent account-management capabilities beyond self-service enrollment and returning verification. (required_inference boundary)

12. Glossary

• قطعة أرض (Land plot / parcel): The measured piece of land whose dimensions the architect enters or uploads.
• تقسيم معماري (Architectural subdivision): The proposed division of the plot into coded zones — boundary, setback, building envelope, circulation, green/open space, services.
• AI prompt: The specification document generated from the entered plot dimensions and submitted to the AI design engine.
• الاشتراطات المعمارية (Architectural requirements): The requirements imposed by Egyptian building law on the design of the plot.
• المعايير المعمارية (Architectural standards): The professional design standards necessary for the design, beyond bare legal compliance.
• ارتداد (Setback): The band inset from the plot boundary within which building is restricted.
• نسبة البناء (Building ratio): The permitted proportion of the plot that may be built upon.
• الخدمات (Services): The service strip within the plot, coded teal in the drawing legend.
• الحركة (Circulation): The movement and access zone within the plot, coded blue in the drawing legend.
• Regulation ledger: The tabular list of applied code articles and corresponding regulation entries displayed alongside the plan.
• Title block: The persistent left-hand column carrying the running project metadata — plot ID, area, governorate, street width, applied code article.