System Requirements Document for moon-real

1. Introduction

moon-real is a real-estate web product whose purpose is to present residential property as architecture worth desiring. The product serves two audiences at once: people looking for a home to live in, and the property listers or agents who bring that inventory to market. The defining intent from the authoritative requirement thread is twofold — build a real-estate project, and make its design creative and more attractive than a conventional listings site. That second requirement is not decoration; it is a first-class product commitment that shapes how properties are presented, browsed, and evaluated.

The product therefore treats every property as a sculpted object rather than a database row. Seekers browse a curated offering and evaluate individual residences through imagery and detail. Listers and agents enroll themselves, then create, edit, and manage durable listings that carry compelling visuals and descriptions. The visual language — a dark lunar ground, pearl-grey parametric line-work, and a single restrained gold accent — is the mechanism by which the "creative and more attractive" requirement is delivered.

This document specifies the current delivery: seven pages, two active human personas, application-owned identity for listers and agents, and a public, no-account browsing experience for seekers.

2. System Overview

moon-real is a first-party web application with a custom user interface and a backend that persists property listings and lister/agent identity. It delivers:

• A public, anonymously reachable entry and browsing experience for Property Seekers.
• Self-service enrollment and returning verification for Property Listers / Agents.
• A protected, revisitable management area where a lister or agent owns and maintains their own durable property listings.

Actors. Two active human personas are in scope: the Property Seeker and the Property Lister / Agent. The application itself owns identity, listing persistence, and authorization of listing management. No third-party identity provider, external marketplace, or outbound-only recipient is established by the source.

Ownership. The application owns all seven pages. Identity is application-owned: listers and agents establish it themselves through Sign Up and re-establish it through Login. Listing management is restricted to the authenticated lister or agent who owns the listing.

Narrow exclusions. No payment, transaction, escrow, mortgage, or offer-negotiation capability is established. No messaging or contact-brokerage capability between seeker and lister is established. No third-party listing syndication or external marketplace integration is established. No administrative, moderation, or multi-role permission hierarchy beyond "the owning lister or agent manages their own listings" is established. These are not implemented in the current delivery.

2a. Product Interpretation and Delivery Boundary

Delivery. moon-real is delivered as a first-party web application with custom UI and a backend service. The public surface — Landing, Properties, and Property Details — is reachable without an account. The management surface — Listings and Listing Editor — requires an established, verified identity.

Access ownership. Identity is owned by the application, not by an external provider. A property lister or agent establishes identity through self-service enrollment on Sign Up, because no invitation, provisioning, or deployment-bootstrap boundary is established by the source. A returning lister or agent re-establishes identity through Login. Sign Up and Login are themselves anonymously reachable — a protected destination cannot own the interaction that grants access to itself. Only Listings and Listing Editor are protected, because only they carry durable, actor-specific state that must remain bound to the correct owner.

Current vs. future. Everything specified in Sections 3 through 5 is current. No future-horizon capability was accepted by the source; Section 11 records the boundaries that were explicitly left out rather than deferred.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no verified factual inventory is carried into this document. All property content is authored by listers and agents through the Listing Editor.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract for this generation: Landing, Sign Up, Login, Properties, Property Details, Listings, Listing Editor. Each page appears exactly once.

Landing

• Information and state. Anonymous public entry. Presents the moon-real identity, the value proposition of curated residences, and a preview of the available property offering. No actor-specific state.
• Primary action. Navigate to Properties to begin browsing.
• Supporting actions. Navigate to Sign Up (enroll as a lister or agent); navigate to Login (return as a lister or agent); open a featured property's Property Details.
• Domain entities. Property (read-only preview), the moon-real brand identity.
• Component responsibilities.
  • Hero stage — full-viewport dark lunar ground; oversized light-weight display headline "Homes shaped like the moon"; uppercase gold eyebrow "MOON-REAL · CURATED RESIDENCES"; a single gold pill CTA "Explore properties"; a tall property photograph masked by an asymmetric S-curve bleeding off the right edge; a pearl-grey parametric arc that draws itself on scroll; a second smaller echo arc near the bottom-left.
  • Floating capsule navigation — full-width top bar that condenses into a floating capsule after 80px of scroll; carries the "moon-real" wordmark with the gold dot on the "o", links to Properties, Sign Up, and Login, and holds the single gold CTA.
  • Flow line — a continuous pearl-grey SVG that traces down the page and draws itself on scroll, connecting hero, property preview, and footer as one architectural gesture.
  • Featured property preview — a staggered two-column composition on desktop where every second card is offset 40px vertically; each card uses an asymmetric S-curve image mask with a faint echo arc behind it.
  • Footer — closing rule carrying the wordmark micro-motif.
• States.
  • Loading: hero imagery and featured preview resolve progressively; the flow line renders fully drawn until scroll begins.
  • Empty: when no properties are published, the featured preview is replaced by a composed statement that the curated offering is being assembled, with the gold CTA still leading to Properties.
  • Success: hero, flow line, and featured preview render as a single composition.
  • Error: if the featured preview cannot be retrieved, the hero and navigation remain fully usable and the preview area shows a quiet retry affordance.
  • Recovery: retry re-requests the featured preview without reloading the page.

Sign Up

• Information and state. Anonymous identity-access surface. Collects the information needed to establish a lister or agent identity. No protected state is available here.
• Primary action. Submit enrollment to establish an application-owned identity.
• Supporting actions. Navigate to Login for an existing identity; return to Landing.
• Domain entities. Lister/Agent identity (created).
• Component responsibilities.
  • Enrollment form — the fields required to establish identity, presented as rounded panels with a 1px pearl-grey inner stroke.
  • Submit control — a gold pill capsule, the single gold accent on the view.
  • Cross-link — a muted link to Login.
• States.
  • Loading: submit control enters a pending state; the form is not double-submittable.
  • Empty: pristine form with no values entered.
  • Success: identity is established and the actor is taken into the protected management area to begin their first listing.
  • Error: validation failures are shown inline against the offending field; a submission failure preserves all entered values and offers retry.
  • Recovery: the actor can correct fields and resubmit without re-entering data.

Login

• Information and state. Anonymous identity-access surface for returning listers and agents. No protected state is available here.
• Primary action. Submit credentials to re-establish a previously created identity.
• Supporting actions. Navigate to Sign Up for a new identity; return to Landing.
• Domain entities. Lister/Agent identity (verified).
• Component responsibilities.
  • Verification form — credential fields in the same panel language as Sign Up.
  • Submit control — a gold pill capsule.
  • Cross-link — a muted link to Sign Up.
• States.
  • Loading: submit control enters a pending state.
  • Empty: pristine form.
  • Success: identity is verified and the actor lands in the protected management area.
  • Error: a failed verification shows a single non-revealing message that does not disclose which field was wrong; entered values are preserved.
  • Recovery: the actor can retry immediately or follow the link to Sign Up.

Properties

• Information and state. Anonymous public browse destination. Presents the available real-estate offering as a curated composition. No actor-specific state.
• Primary action. Open a property's Property Details.
• Supporting actions. Move through the offering; return to Landing; navigate to Sign Up or Login.
• Domain entities. Property (collection), property imagery, headline attributes used for scanning.
• Component responsibilities.
  • Property grid — two columns on desktop with staggered vertical offsets so the page reads as a composition rather than a spreadsheet; single column at 375px.
  • Property card — asymmetric S-curve image mask, faint echo arc behind the image, wordmark micro-motif, and the property's headline attributes.
  • Flow line — continues the page-spanning architectural gesture.
  • Capsule navigation — persistent entry back to Landing and to the identity surfaces.
• States.
  • Loading: cards resolve progressively in place; the grid skeleton preserves the staggered rhythm.
  • Empty: a composed statement that no properties are currently published, with a route back to Landing.
  • Success: the full offering renders as a staggered composition.
  • Error: a retrieval failure shows a quiet retry affordance while navigation remains usable.
  • Recovery: retry re-requests the offering without a full page reload.

Property Details

• Information and state. Anonymous focused destination for evaluating one property. Presents that property's imagery and details in full. No actor-specific state.
• Primary action. Evaluate the property through its visuals and details.
• Supporting actions. Return to Properties; navigate to Landing; navigate to Sign Up or Login.
• Domain entities. Property (single), property imagery, property descriptive details.
• Component responsibilities.
  • Detail hero — the property's lead image inside an organic curved mask on the lunar ground, with a pearl-grey echo arc tracing the building's silhouette behind it.
  • Image sequence — additional property imagery; on hover, images crossfade slowly (700ms) rather than snapping.
  • Detail panel — the property's descriptive details, laid out on the inverted grid (columns 5–12 on desktop) so the page reads as an editorial spread.
  • Flow line — continues the page-spanning gesture.
• States.
  • Loading: the detail hero and panel resolve progressively.
  • Empty: not reachable without a selected property; if the requested property is unavailable, a composed not-found state routes back to Properties.
  • Success: imagery and details render as a single sculpted composition.
  • Error: a retrieval failure shows a quiet retry affordance with a route back to Properties.
  • Recovery: retry re-requests the property; the route back to Properties is always available.

Listings

• Information and state. Protected, revisitable management destination. Shows the authenticated lister's or agent's own durable listings and their current publication state. Access is restricted to the authenticated owner of those listings.
• Primary action. Review the actor's own listings.
• Supporting actions. Open a listing in the Listing Editor; begin a new listing in the Listing Editor.
• Domain entities. Property listing (owned collection), listing publication state.
• Component responsibilities.
  • Listing collection — the actor's own listings, each presented with the same sculpted card language used publicly, so management does not fall back to a spreadsheet look.
  • Publication state indicator — each listing's current state is legible at a glance.
  • Create control — a gold pill capsule leading into the Listing Editor for a new listing.
  • Capsule navigation — persistent entry back to the public surface.
• States.
  • Loading: the collection resolves progressively.
  • Empty: a composed first-use state inviting the actor to create their first listing, with the gold create control as the single accent.
  • Success: the actor's listings render with their publication states.
  • Error: a retrieval failure shows a quiet retry affordance; the create control remains available.
  • Recovery: retry re-requests the collection without losing the actor's place.
  • Access failure: an unauthenticated request is routed to Login; the actor's listings are never shown to another identity.

Listing Editor

• Information and state. Protected, focused creation and editing destination for a single property listing. Carries the listing's durable content — its imagery and descriptive details — and its publication state. Access is restricted to the authenticated owner of the listing being edited.
• Primary action. Save the listing so it becomes part of the published offering.
• Supporting actions. Edit an existing listing's imagery and details; return to Listings; return to the public surface.
• Domain entities. Property listing (single, owned), listing imagery, listing descriptive details, publication state.
• Component responsibilities.
  • Listing form — the fields that carry the listing's descriptive details, in the same rounded-panel language as the rest of the product.
  • Imagery control — where the listing's property imagery is attached and arranged, since imagery is the primary carrier of the "creative and more attractive" requirement.
  • Save control — a gold pill capsule, the single gold accent on the view.
  • Publication state control — the listing's state as it moves from draft to published.
  • Flow line — continues the page-spanning gesture even inside the management surface.
• States.
  • Loading: an existing listing's content resolves into the form.
  • Empty: a new listing begins as a pristine form with no content.
  • Success: the listing is saved and its state is reflected on Listings and, once published, in the public offering.
  • Error: validation failures are shown inline against the offending field; a save failure preserves all entered content and offers retry.
  • Recovery: the actor can correct fields and save again without re-entering content.
  • Access failure: an unauthenticated or non-owning request is routed to Login; the listing's content is never exposed to another identity.

3. Functional Requirements

Each requirement below is a distinct story point. Provenance is marked explicit (stated by the user), basic_default (accepted default), or required_inference (indispensable mechanics inferred to make an accepted journey executable).

FR-1 — Public entry to the real-estate offering (explicit) As a Property Seeker, I should arrive at a public Landing page that introduces moon-real and its curated residences, so that I can understand what the site offers and begin browsing.

• Trigger/input: the actor opens the site with no established identity.
• Observable result: the Landing page renders its hero, navigation, and featured property preview.
• Access state: anonymous; no identity required.
• Failure/recovery: if the featured preview cannot be retrieved, the hero and navigation remain usable and a quiet retry is offered.
• Continuation: the actor follows the gold CTA to Properties.

FR-2 — Browse the available property offering (explicit) As a Property Seeker, I should browse the available properties on a public Properties page, so that I can survey what is on offer.

• Trigger/input: the actor navigates to Properties from Landing or the capsule navigation.
• Observable result: the published properties render as a staggered, sculpted composition.
• Access state: anonymous; no identity required.
• Failure/recovery: a retrieval failure shows a quiet retry while navigation stays usable.
• Continuation: the actor opens a property's Property Details.

FR-3 — Evaluate an individual property (explicit) As a Property Seeker, I should open a property's Property Details page and evaluate it through its imagery and details, so that I can judge whether it matches my needs.

• Trigger/input: the actor selects a property from Properties or the Landing preview.
• Observable result: that property's imagery and descriptive details render as a focused composition.
• Access state: anonymous; no identity required.
• Failure/recovery: if the property is unavailable, a composed not-found state routes back to Properties; a retrieval failure offers retry.
• Continuation: the actor returns to Properties to continue browsing.

FR-4 — Creative and attractive presentation of properties (explicit) As a Property Seeker, I should experience the real-estate offering through a creative and more attractive design, so that evaluating properties feels like viewing architecture rather than reading a spreadsheet.

• Trigger/input: any public page render.
• Observable result: properties appear inside asymmetric S-curve image masks on a dark lunar ground, with pearl-grey parametric arcs, a scroll-drawn flow line, and a single restrained gold accent per viewport.
• Access state: applies to all public pages.
• Failure/recovery: under prefers-reduced-motion, parallax and float stop, images swap instantly, and the flow line renders fully drawn — the presentation remains complete without motion.
• Continuation: the actor continues browsing or evaluating.

FR-5 — Self-service enrollment as a lister or agent (required_inference) As a Property Lister / Agent, I should complete self-service enrollment on Sign Up, so that I can establish an identity that owns my listings.

• Trigger/input: the actor navigates to Sign Up from Landing or the capsule navigation and submits the enrollment form.
• Observable result: an application-owned identity is established and the actor enters the protected management area.
• Access state: Sign Up is anonymously reachable; no protected state is available on it.
• Failure/recovery: validation failures are shown inline; a submission failure preserves entered values and offers retry.
• Continuation: the actor proceeds to create their first listing in the Listing Editor.

FR-6 — Returning verification for listers and agents (required_inference) As a Property Lister / Agent, I should verify my identity on Login, so that I can regain access to my durable listing-management workflow.

• Trigger/input: the actor navigates to Login and submits credentials.
• Observable result: the identity is verified and the actor lands in the protected management area.
• Access state: Login is anonymously reachable; no protected state is available on it.
• Failure/recovery: a failed verification shows a single non-revealing message and preserves entered values; the actor can retry or follow the link to Sign Up.
• Continuation: the actor proceeds to Listings.

FR-7 — Review own durable listings (required_inference) As a Property Lister / Agent, I should review my own listings on the Listings page, so that I can see what I have published and what state each listing is in.

• Trigger/input: the authenticated actor navigates to Listings.
• Observable result: the actor's own listings render with their publication states.
• Access state: restricted to the authenticated owner of those listings.
• Failure/recovery: a retrieval failure shows a quiet retry while the create control stays available; an unauthenticated request routes to Login.
• Continuation: the actor opens a listing in the Listing Editor or begins a new one.

FR-8 — Create a property listing (required_inference) As a Property Lister / Agent, I should create a property listing in the Listing Editor, so that a new residence becomes part of the published offering.

• Trigger/input: the authenticated actor opens the Listing Editor for a new listing and submits the form.
• Observable result: the listing is saved and its state is reflected on Listings and, once published, in the public offering.
• Access state: restricted to the authenticated lister or agent.
• Failure/recovery: validation failures are shown inline; a save failure preserves all entered content and offers retry.
• Continuation: the actor returns to Listings or continues editing.

FR-9 — Edit an existing listing (required_inference) As a Property Lister / Agent, I should edit one of my own listings in the Listing Editor, so that its imagery and details stay accurate and compelling.

• Trigger/input: the authenticated actor opens an owned listing from Listings and submits changes.
• Observable result: the listing's updated content is saved and reflected on Listings and in the public offering.
• Access state: restricted to the authenticated owner of that listing.
• Failure/recovery: validation failures are shown inline; a save failure preserves all entered content and offers retry; a non-owning request routes to Login.
• Continuation: the actor returns to Listings.

FR-10 — Present listings with compelling, creative visuals and details (explicit) As a Property Lister / Agent, I should present my properties with compelling, creative visuals and details, so that seekers can evaluate them and my listings attract qualified interest.

• Trigger/input: the actor attaches and arranges property imagery and enters descriptive details in the Listing Editor.
• Observable result: the listing carries that imagery and detail into the public offering, where it renders inside the sculpted card and detail language.
• Access state: restricted to the authenticated owner of the listing.
• Failure/recovery: a save failure preserves all entered content and imagery and offers retry.
• Continuation: the actor reviews the result on Listings and in the public offering.

FR-11 — Ownership-bound listing management (required_inference) As a Property Lister / Agent, I should have my listings remain bound to my own identity, so that no other actor can view or change my listing content.

• Trigger/input: any request to Listings or the Listing Editor.
• Observable result: only the authenticated owner's listings are shown and only the owner's listing can be edited.
• Access state: Listings and Listing Editor are restricted; an unauthenticated or non-owning request routes to Login.
• Failure/recovery: the protected content is never exposed; the actor is routed to Login and can return after verifying.
• Continuation: after verification, the actor reaches their own Listings.

4. User Personas

Property Seeker

Product context. The Property Seeker arrives at moon-real without an account and without a commitment. They are in an exploratory, comparative frame of mind: they want to see what exists, form an impression of quality, and narrow toward something that matches their needs. They may arrive from the Landing page's featured preview or go straight to the full offering.

Primary goal. Find a property that matches their needs and take the next step toward it.

Distinct accepted responsibilities. The Seeker is the sole actor on the public surface. They survey the offering on Properties, open individual residences on Property Details, and evaluate them through imagery and detail. They are the audience for whom the "creative and more attractive" requirement exists — the presentation is what lets them imagine living inside a sculpted space rather than reading a row of attributes.

Relevant inputs and decisions. The Seeker decides which properties to open and which to dwell on. Their inputs are the property imagery, the descriptive details, and the composition of the offering itself. They make no commitment inside the product; their decision is which property to pursue.

Interactions with other participants. The Seeker is the counterparty whose evaluation the Property Lister / Agent is trying to earn. The Seeker never interacts with the Lister directly inside the product — no messaging or contact capability is established — but the Lister's authored imagery and details are precisely what the Seeker evaluates.

Observable success. The Seeker has surveyed the offering, opened the properties that interested them, and identified a property that matches their needs.

Property Lister / Agent

Product context. The Property Lister / Agent is the party responsible for the real-estate inventory. They arrive with properties to present and a professional interest in how those properties read. They are not browsing for themselves; they are curating a gallery of residences and want each listing to feel like a piece rather than a row.

Primary goal. Publish listings that are compelling and attract qualified interest.

Distinct accepted responsibilities. The Lister is the only actor who establishes an identity. They enroll themselves on Sign Up, verify on Login when returning, review their own listings on Listings, and create and edit listing content — imagery and descriptive details — in the Listing Editor. They own the durable state of their listings and are the only actor authorized to change it.

Relevant inputs and decisions. The Lister's inputs are the property imagery they attach and arrange and the descriptive details they enter. Their decisions are what to include, how to present it, and when a listing is ready to be published. Their work is judged by whether the resulting listing reads as a sculpted object in the public offering.

Interactions with other participants. The Lister's authored content is what the Property Seeker evaluates. The Lister does not interact with the Seeker directly inside the product; their influence on the Seeker is entirely through the quality of the listing they publish.

Observable success. Their listings are published, render attractively in the public offering, and attract qualified interest.

5. Core User Flows

Flow A — A Property Seeker surveys the offering and evaluates a residence

1. Starting context. The Seeker has no account and no established identity. They open moon-real.
2. Landing. The Landing page renders its full-viewport dark lunar stage: the oversized light headline "Homes shaped like the moon", the gold eyebrow "MOON-REAL · CURATED RESIDENCES", and the single gold pill CTA "Explore properties". A tall property photograph masked by an asymmetric S-curve bleeds off the right edge, and a pearl-grey parametric arc draws itself as the Seeker scrolls. The floating capsule navigation condenses from the top bar after 80px of scroll.
3. Actor action. The Seeker follows the gold CTA to Properties.
4. Properties. The published offering renders as a staggered two-column composition on desktop, every second card offset 40px vertically, each card inside an asymmetric S-curve image mask with a faint echo arc behind it. The flow line continues down the page. If no properties are published, a composed empty statement appears with a route back to Landing.
5. Actor decision. The Seeker selects a property that interests them.
6. Property Details. That property's detail hero renders inside an organic curved mask on the lunar ground, with a pearl-grey echo arc tracing the building's silhouette behind it. The detail panel lays out the property's descriptive details on the inverted grid. On hover, additional property images crossfade slowly (700ms) rather than snapping.
7. Observable result. The Seeker has evaluated the property through its imagery and details.
8. Failure and recovery. If the property is unavailable, a composed not-found state routes back to Properties. If retrieval fails, a quiet retry is offered and the route back to Properties is always available.
9. Continuation. The Seeker returns to Properties and continues surveying, repeating steps 5 through 8 until they have identified a property that matches their needs.
10. Reduced-motion variant. Under prefers-reduced-motion, parallax and float stop, images swap instantly, and the flow line renders fully drawn. The Seeker's journey is unchanged.

Flow B — A Property Lister / Agent enrolls and publishes a first listing

1. Starting context. The Lister has properties to present and no established identity on moon-real.
2. Landing. The Lister arrives at Landing and uses the capsule navigation to reach Sign Up.
3. Sign Up. The Lister completes the enrollment form — rounded panels with a 1px pearl-grey inner stroke, a single gold pill submit control. Sign Up is anonymously reachable and exposes no protected state.
4. Observable result. An application-owned identity is established and the Lister enters the protected management area.
5. Failure and recovery. If validation fails, errors appear inline against the offending field. If submission fails, all entered values are preserved and the Lister can retry without re-entering data.
6. Listings — first use. The Lister's Listings page renders its composed first-use empty state, inviting them to create their first listing, with the gold create control as the single accent.
7. Actor action. The Lister follows the create control into the Listing Editor.
8. Listing Editor — creation. The Lister enters the listing's descriptive details in the rounded-panel form and attaches and arranges the property imagery — the primary carrier of the "creative and more attractive" requirement.
9. Actor decision. The Lister decides the listing is ready and submits the save control.
10. Observable result. The listing is saved and its state is reflected on Listings. Once published, it appears in the public offering, rendering inside the sculpted card and detail language.
11. Failure and recovery. If validation fails, errors appear inline. If the save fails, all entered content and imagery are preserved and the Lister can retry.
12. Continuation. The Lister returns to Listings, where the new listing appears with its publication state.

Flow C — A returning Property Lister / Agent verifies and edits a listing

1. Starting context. The Lister has previously established an identity and has at least one durable listing.
2. Login. The Lister navigates to Login from the capsule navigation and submits their credentials. Login is anonymously reachable and exposes no protected state.
3. Observable result. The identity is verified and the Lister lands in the protected management area.
4. Failure and recovery. If verification fails, a single non-revealing message appears that does not disclose which field was wrong, entered values are preserved, and the Lister can retry immediately or follow the link to Sign Up.
5. Listings. The Lister's own listings render with their publication states. Only the Lister's own listings are shown.
6. Actor action. The Lister opens one of their listings in the Listing Editor.
7. Listing Editor — editing. The existing listing's content resolves into the form. The Lister updates its imagery and descriptive details.
8. Actor decision. The Lister submits the save control.
9. Observable result. The updated content is saved and reflected on Listings and in the public offering.
10. Failure and recovery. If validation fails, errors appear inline. If the save fails, all entered content is preserved and the Lister can retry.
11. Continuation. The Lister returns to Listings.

Flow D — Ownership protection on the management surface

1. Starting context. An actor requests Listings or the Listing Editor without an established identity, or requests a listing they do not own.
2. Observable result. The protected content is never exposed.
3. Actor action. The actor is routed to Login.
4. Continuation. After verifying, the actor reaches their own Listings. A non-owning actor never reaches another lister's listing content.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. It names Zaha Hadid as the muse and "Fluid parametric grandeur — moon-real as a lunar-lit architectural object" as the headline. The direction is translated below into concrete tokens.

Mode. Dark mode is the product's native mode. There is no light-ground variant; the lunar void ground is what makes each property image glow.

Colour tokens by role.

Accent discipline. No more than one gold accent element per viewport. The accent must stay rare.

Forbidden. No blue, no indigo, no white-ground SaaS look. #0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED and neighbours are excluded, as is the generic indigo/blue-on-white template.

Typography.

• Headings: Josefin Sans, Light weight (300) — a wide geometric display with generous letter-spacing at large sizes. Uppercase for section eyebrows, title-case for hero lines. Tight leading (0.95–1.05) so stacked headlines read as a single sculpted mass.
• Body: Jost.
• Scale: 1.333 modular — 112 / 84 / 63 / 47 / 35 / 26 / 20 / 16 / 14.
• Hero display: clamp(40px, 9vw, 112px).
• Section display: clamp(28px, 5vw, 56px).
• Body: 17px with 1.7 line-height.
• Micro-labels: 12px uppercase, 0.18em tracking.
• Forbidden: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body.

Shape language. Parametric curves everywhere; no right angles in decorative elements. Section boundaries are SVG arcs that flow between blocks. Cards are rounded-rectangle panels with a 28–40px radius and a 1px pearl-grey inner stroke that catches light like a curved edge. Buttons are pill capsules with a subtle inner highlight on the top edge. Image masks use asymmetric organic curves — a soft S-curve on one side — so property photos feel carved rather than cropped. One recurring motif: a thin continuous flow line that traces the page as the user scrolls, connecting sections like a single architectural gesture.

Spacing rhythm. Generous vertical rhythm: 96–160px section gaps on desktop, 56–88px on mobile.

Layout. Asymmetric editorial architecture on a 12-column grid. Heroes occupy columns 1–8 with a floating image arc bleeding off the right edge; detail pages invert to columns 5–12. Navigation is a top bar that condenses into a floating capsule after scroll, with a single gold CTA. The property grid uses two columns on desktop with staggered vertical offsets — one card raised 40px — so the page reads as a composition, not a spreadsheet. At 375px everything collapses to a single column, arcs become simple rounded corners, and the flow line hides.

Imagery style. Architectural photography treated as sculpture: wide-angle exterior shots at dusk with warm interior light, macro details of staircases, curves, glass and stone, and monochrome-to-colour hover reveals. Every property image sits inside an organic curved mask on a #0E1014 ground, with a faint pearl-grey arc echoing the building's silhouette behind it. No stock people shaking hands, no flat clip art, no gradient blobs, no generic city skylines.

Readable-text integrity. Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Imagery and decoration may be cropped, bled, rotated, or overlapped as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The lunar stage and the drawn line.

The public entry is composed as a single architectural gesture rather than a stack of blocks. The first screen is a full-viewport dark lunar stage on #0E1014. On the left, a nine-column stack of oversized Josefin Sans Light headline — "Homes shaped like the moon" — clamps from 40px on mobile to 112px on desktop, with tight leading so the lines read as one sculpted mass. Above it sits a small uppercase eyebrow, "MOON-REAL · CURATED RESIDENCES", in #C9A227. Beneath the headline, pinned, is a single gold pill CTA, "Explore properties".

On the right, a tall property photograph is masked by an asymmetric S-curve and bleeds off the right edge of the viewport, overlapping a thin pearl-grey parametric arc that draws itself on scroll. A second, smaller arc echoes the first near the bottom-left. The top-right of the hero holds the compact floating capsule navigation, carrying the "moon-real" wordmark with its gold dot on the "o".

The dominant element is the curved architectural image and the silver flow line; the headline is the second mass. There is no centred headline, no blue button, and no gradient blob. As the visitor scrolls, the flow line continues down the page and draws itself, connecting hero, property preview, and footer as one continuous architectural gesture — the same line that reappears inside the management surface, so the product reads as one building rather than two applications.

This concept recomposes only accepted content, states, and controls: the headline, the eyebrow, the CTA, the navigation, the property imagery, and the flow line. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The tall property photograph masked by an asymmetric S-curve, bleeding off the right edge of the viewport, and the pearl-grey parametric arc that overlaps it.
• Input → transformation → outcome thesis. As the visitor scrolls, the pearl-grey parametric arc draws itself along its path, the flow line extends downward to connect the hero to the property preview and footer, and the floating panels drift gently. The outcome is that the page reads as one continuous architectural gesture rather than a sequence of separate blocks — the visitor's scroll literally traces the building.
• Motion vocabulary. Scroll-linked parallax on the hero's curved silver line-work; slow 700ms crossfades between property images on hover; a gentle 8–12px float on floating panels; a quick radial wipe from the accent dot on page transitions. No bounce, no particles, no springy or playful motion.
• Composed first frame. The hero at rest: headline mass on the left, gold eyebrow above it, gold pill CTA beneath it, the S-curve-masked photograph bleeding off the right edge, the parametric arc at its starting point, the echo arc near the bottom-left, and the capsule navigation at the top-right. The flow line is visible but not yet extended.
• Reduced-motion state. Under prefers-reduced-motion, all parallax and float stop, images swap instantly rather than crossfading, and the flow line renders fully drawn. The composition is complete and legible without any motion.

9. Non-Functional Requirements

NFR-1 — Creative and attractive presentation (explicit) The design must be creative and more attractive than a conventional listings site. This is a stated product requirement, not a preference. Rationale: the user explicitly required it, and it is the product's differentiating commitment.

NFR-2 — Readable text and controls stay whole (explicit, from the creative direction) At 375px, 768px and 1280px, headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container, wrapping or scaling to fit, and no other element covers any part of them. Imagery and decoration may be cropped, bled, rotated, or overlapped. Moving and scrollable content may cross the viewport edge by design, judged by whether it actually moves and whether every item becomes fully readable as it passes. Under prefers-reduced-motion, moving content stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row. Where any instruction asks readable text or a control to be cropped, clipped, covered, or run off an edge, this rule takes precedence and the gesture is carried by imagery or decoration instead.

NFR-3 — Reduced-motion support (explicit, from the creative direction) prefers-reduced-motion must stop all parallax and float, swap images instantly, and render the flow line fully drawn.

NFR-4 — Accent restraint (explicit, from the creative direction) No more than one gold accent element per viewport; the accent stays under roughly 5% of any view.

NFR-5 — Palette and typography fidelity (explicit, from the creative direction) The specified hex values and the Josefin Sans / Jost pairing must be used as given. Blue, indigo, and white-ground SaaS treatments are excluded, as are the named forbidden typefaces.

NFR-6 — Durable listing persistence (required_inference) Listings must persist durably and remain bound to the identity that created them, because the accepted journey requires a lister or agent to return, review, and edit their own listings across sessions. Rationale: without durable, ownership-bound persistence, FR-7, FR-9, and FR-11 are not executable.

NFR-7 — Protected-surface access control (required_inference) Listings and the Listing Editor must be reachable only by the authenticated owner of the listings they expose. Rationale: the accepted journey requires that a lister's durable listing state remain bound to the correct participant.

NFR-8 — Backend integration (required_inference) The product requires a backend that serves the public offering and persists identity and listings. Rationale: the accepted journeys cannot complete without it.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults, labeled as such.

• Frontend: React — [Default — not specified by user]. Chosen because the product is a custom-UI web application with a rich, motion-driven public surface and a protected management surface.
• Backend: Python with FastAPI — [Default — not specified by user]. Chosen because the product requires a backend serving the public offering and persisting identity and listings.
• Storage: A relational database appropriate to durable, ownership-bound listing records — [Default — not specified by user].
• Containerization: Docker and docker-compose — [Default — not specified by user].
• Orchestration: Kubernetes is not required for the current delivery — [Default — not specified by user].

11. Assumptions and Constraints

Assumptions.

• A-1 (narrow). Property imagery is supplied by the lister or agent through the Listing Editor. No external image source or syndication feed is established by the source.
• A-2 (narrow). The public offering contains only listings that have been published. Draft listings remain visible only to their owner on Listings.
• A-3 (narrow). Identity is application-owned and established by self-service enrollment, because no invitation, provisioning, or deployment-bootstrap boundary is established by the source.
• A-4 (narrow). The two personas in Section 4 are the complete active human set for this generation.

Constraints.

• C-1. The design must be creative and more attractive than a conventional listings site — an explicit user requirement.
• C-2. The palette, typography, shape language, layout, motion, and imagery rules in Section 6 are binding.
• C-3. The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-4. Readable text and controls stay whole at 375px, 768px and 1280px; this rule takes precedence over any instruction to crop, clip, cover, or bleed readable text or a control.
• C-5. No more than one gold accent element per viewport.
• C-6. Listings and the Listing Editor are restricted to the authenticated owner of the listings they expose.

Explicitly out of scope for the current delivery.

• No payment, transaction, escrow, mortgage, or offer-negotiation capability.
• No messaging or contact-brokerage capability between a Property Seeker and a Property Lister / Agent.
• No third-party listing syndication or external marketplace integration.
• No administrative, moderation, or multi-role permission hierarchy beyond ownership of one's own listings.
• No future-horizon capability was accepted by the source; nothing is deferred into a future section.

12. Glossary

• Property Seeker — The anonymous visitor who browses the public offering and evaluates individual residences. Holds no account.
• Property Lister / Agent — The party responsible for the real-estate inventory. Establishes an application-owned identity, owns durable listings, and creates and edits their content.
• Listing — A durable, ownership-bound record of a property, carrying imagery, descriptive details, and a publication state.
• Published listing — A listing whose state makes it part of the public offering visible on Properties and Property Details.
• Draft listing — A listing not yet published; visible only to its owner on Listings.
• Public surface — Landing, Properties, and Property Details; reachable without an account.
• Management surface — Listings and the Listing Editor; restricted to the authenticated owner of the listings they expose.
• Flow line — The continuous pearl-grey SVG that traces down the page and draws itself on scroll, connecting sections as one architectural gesture.
• Parametric arc — A thin pearl-grey curved line echoing a building's silhouette, used as a recurring decorative motif.
• S-curve mask — The asymmetric organic image mask applied to property imagery so photographs read as carved rather than cropped.
• Capsule navigation — The top bar that condenses into a floating capsule after 80px of scroll, carrying the wordmark and a single gold CTA.
• Gold accent — The single restrained #C9A227 element permitted per viewport.