System Requirements Document for mobile-phone-specification

1. Introduction

Product intent. mobile-phone-specification is a complete website that covers mobile phone models across all brands and models, presenting each model's specification details together with real images of the device. The site exists so that anyone comparing hardware can find a model, read its exact specifications, and look at genuine photographs of the physical device — and so that the people who keep those records can maintain them accurately across the whole catalog.

Audience. Two accepted human roles use the product:

• Phone Shopper — a visitor who wants to compare mobile phone models and understand their specifications before deciding. They browse the model catalog, open a specific model to read its specification details and view real images of the device, and leave with a clear picture of which model fits their needs.
• Catalog Maintainer — the person responsible for keeping the site's phone model listings, specifications, and real device images accurate and complete across all models. They add and update model entries, their specification fields, and the associated real images so shoppers always see current, correct information.

The website is built for mobile phone use: the browsing, reading, and image-viewing experience is designed to work on a phone screen first, and the maintainer's editing surfaces are equally usable on a phone.

2. System Overview

mobile-phone-specification is a single first-party web application with a public, anonymously reachable catalog and a protected maintenance area.

Current delivery. The product is delivered as a custom first-party web application with its own user interface and its own backend integration. It owns:

• A public Landing entry that explains the catalog, its model specifications, and its real device images before any protected work.
• A public Phones catalog for browsing phone models across brands, built as a dense ruled index that works on a phone.
• A public Phone Details destination for reading one model's specification details.
• A public Phone Gallery destination for viewing real images of one model's device.
• A Login access entry that provides returning verification for the Catalog Maintainer and a truthful first-use enrollment path, because no provisioning boundary is established.
• A protected Catalog Management overview for maintaining phone model listings and returning to records that need updates.
• A protected Phone Editor focused workspace for adding and updating phone model entries, specifications, and real images.

Actors. Phone Shopper and Catalog Maintainer are the accepted active human personas. The application backend is a non-persona system actor that stores and serves catalog records, specification values, and image references.

Ownership. All accepted human-facing behavior is owned by first-party pages of this application. The public catalog and model-detail reading and image viewing are anonymously reachable. Catalog administration is protected and bound to the Catalog Maintainer's own identity so that durable catalog records remain attributable and resumable.

Narrow exclusions. This document does not add shopping, checkout, pricing, ordering, payment, shipping, reviews, ratings, user-generated content, social features, or any adjacent commerce capability; none is accepted by the source. It does not add account-management capabilities beyond the minimum identity establishment and returning verification needed for the Catalog Maintainer to administer durable catalog records. It does not add a separate administrator console, analytics surface, or notification system.

2a. Product Interpretation and Delivery Boundary

What the product is. A reference archive of mobile phone models. Its core value is exactness: for every model, the specification details and real photographs of the device. The product is not a storefront — it does not sell, price, or ship anything. It is a measurement and reference surface.

Delivery ownership. The whole experience is first-party custom UI delivered by this application. There is no provider-owned or external-only surface in the accepted scope, and no headless-only delivery. The application owns its own identity for the Catalog Maintainer, because durable catalog records must remain bound to the correct maintainer across sessions and must be resumable.

Access boundary. The Landing, Phones, Phone Details, and Phone Gallery destinations are anonymously reachable — a Phone Shopper never needs an account to browse models, read specifications, or view real device images. The Catalog Management and Phone Editor destinations are protected and require the Catalog Maintainer's verified identity. The Login destination is itself anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself; it carries both first-use enrollment and returning verification.

Current vs. future. Everything described in this document is current. No future-horizon requirements were accepted by the source.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Explains what the catalog is: mobile phone models across all brands, each with specification details and real images of the device. Presents one featured model as the hero subject with a live ruled spec strip (chipset / display / battery / camera) showing that model's real values. No protected state is exposed.
• Primary action. BROWSE THE CATALOG — a solid champagne block pinned at the base of the headline column, leading to Phones.
• Supporting actions. A discreet link to Login for the Catalog Maintainer; the featured model's name links to its Phone Details.
• Domain entities. Phone model (featured), specification values (chipset, display, battery, camera), device imagery.
• Component responsibilities. Full-bleed graphite hero stage; oversized condensed uppercase headline EVERY MODEL. EVERY SPEC. with a champagne hairline rule beneath it; hero device turntable; live ruled spec strip with count-up values; decorative teal gauge arc behind the device; topographic contour-line background texture.
• States. Loading: hero stage renders with the headline and rule immediately, spec strip shows placeholder rules until values resolve. Empty: if no featured model is available, the hero shows the headline, rule, and CTA with the device stage and spec strip omitted. Success: featured model, its real values, and its image render. Error: if the featured model fails to resolve, the hero degrades to headline + rule + CTA and a muted note that the featured model is unavailable. Recovery: the CTA to Phones remains fully usable in every state.

Login

• Information and state. Anonymous access entry. Carries two truthful paths: first-use enrollment for a Catalog Maintainer who has no account yet, and returning verification for one who does. States clearly that this entry is for catalog maintenance, not for browsing.
• Primary action. Submit credentials to establish or verify identity.
• Supporting actions. Switch between the enrollment path and the returning-verification path; return to the public catalog.
• Domain entities. Maintainer identity (email/identifier and secret), session.
• Component responsibilities. Squared 2px-radius form panel with hairline border; labeled fields with micro-label uppercase captions; inline validation messaging; primary champagne submit block; outline-only secondary action.
• States. Loading: submit control shows a precise in-progress state and is not double-submittable. Empty: fields empty with labels visible. Success: identity established or verified, then continuation to Catalog Management. Error: invalid credentials, already-registered identifier on the enrollment path, or unmet field requirements produce an inline message that names the problem without discarding entered values. Recovery: the user can correct and resubmit, or switch paths, without losing the page.

Phones

• Information and state. Anonymous public catalog of phone models across brands. Dense ruled index: one row per model with columns aligned like a spec sheet (brand, model, display, chipset, camera, battery) under a sticky condensed uppercase header row. On mobile each row becomes a stacked label/value block with the model name in condensed caps above.
• Primary action. Open a model's Phone Details.
• Supporting actions. Filter or narrow the index by brand; open a model's Phone Gallery; move between result pages or continue loading further models.
• Domain entities. Phone model, brand, display specification, chipset, camera specification, battery specification, model thumbnail image.
• Component responsibilities. Sticky condensed header row; hairline chapter-ring dividers; aligned label/value columns; row left-edge rule that ignites to champagne on hover; per-row thumbnail; result count; empty and error messaging.
• States. Loading: header row and ruled skeleton rows render immediately so the index shape is visible. Empty: when no model matches the current narrowing, a ruled empty panel states that no models match and offers to clear the narrowing. Success: ruled rows render with real values and thumbnails. Error: if the catalog cannot be loaded, a ruled error panel states the failure and offers retry. Recovery: retry reloads the index; clearing the narrowing restores the full catalog.

Phone Details

• Information and state. Anonymous model-specific destination for reading one phone's specification details. Two-rail layout: a fixed left rail of circular gauges and a right rail of ruled specification tables grouped by Display / Performance / Camera / Battery / Build. The model name is set as an oversized condensed bezel engraving with a champagne hairline rule running the full viewport width beneath it.
• Primary action. Read the model's specification values.
• Supporting actions. Open the model's Phone Gallery; return to Phones; move to another model.
• Domain entities. Phone model, brand, specification groups (Display, Performance, Camera, Battery, Build), individual specification fields and values, gauge-backed numeric values (battery mAh, refresh rate, camera MP, weight).
• Component responsibilities. Oversized condensed model name; champagne rule; circular SVG spec gauges with champagne needle and teal fill arc that sweep and count up on scroll into view; ruled specification tables with topographic contour-line texture behind them; group headings; label/value rows.
• States. Loading: model name and rule render, gauges sit at zero, tables show ruled placeholders. Empty: if a specification group has no recorded values, that group renders a ruled note that the values are not yet recorded rather than blank rows. Success: all recorded specification values render, gauges sweep to their real values. Error: if the model cannot be loaded, a ruled error panel states the failure and offers retry or return to Phones. Recovery: retry reloads the model; return to Phones always works.

Phone Gallery

• Information and state. Anonymous model-specific destination for viewing real images of the device. Edge-to-edge macro image stage with a thumbnail strip. Images are real device photography: front and back plates on graphite grounds, angled three-quarter shots, extreme macro of the camera module and port edges.
• Primary action. View a real image of the device at full stage size.
• Supporting actions. Move between images via the thumbnail strip; move between images via keyboard arrow navigation; open the model's Phone Details.
• Domain entities. Phone model, device image, image caption or view label, image index.
• Component responsibilities. Edge-to-edge macro stage; thumbnail strip whose active thumb is marked by a champagne wipe and a teal index number; 200ms crossfade transitions; keyboard arrow handling; image counter.
• States. Loading: stage renders with a ruled placeholder frame while the first image resolves. Empty: if the model has no real images recorded, the stage shows a ruled note that no device images are available yet and links to Phone Details. Success: the selected image renders at stage size with its thumbnail marked active. Error: if an image fails to load, the stage shows a ruled failure frame for that image and the strip remains navigable to other images. Recovery: selecting another thumbnail or pressing an arrow key moves to a loadable image.

Catalog Management

• Information and state. Protected overview for maintaining phone model listings and returning to records that need updates. Lists catalog records with enough identifying and status information to choose what to work on next, and shows which records are incomplete or missing specification values or real images.
• Primary action. Open a record in Phone Editor.
• Supporting actions. Add a new phone model entry; narrow the list to records needing updates; return to the public catalog.
• Domain entities. Phone model record, brand, completeness status (missing specification values, missing real images), last-updated information, maintainer identity.
• Component responsibilities. Ruled record list with aligned columns; completeness indicators; add-new entry point; narrowing control; empty and error panels.
• States. Loading: ruled skeleton rows render while records resolve. Empty: when the catalog has no records yet, a ruled panel states that no models exist and offers to add the first model. Success: records render with their completeness indicators. Error: if records cannot be loaded, a ruled error panel states the failure and offers retry. Recovery: retry reloads the list; the add-new entry point remains available.

Phone Editor

• Information and state. Protected focused workspace for adding and updating one phone model entry, its specification fields, and its real images. Mirrors the Phone Details page exactly so maintainers edit the same shapes shoppers read: the same oversized condensed model name, the same gauge rail, and the same ruled specification groups (Display / Performance / Camera / Battery / Build).
• Primary action. Save the model entry, its specification values, and its image associations.
• Supporting actions. Add or remove a real image for the model; edit individual specification fields; cancel and return to Catalog Management.
• Domain entities. Phone model, brand, specification fields and values within the Display / Performance / Camera / Battery / Build groups, gauge-backed numeric values, real device images and their order.
• Component responsibilities. Editable model name and brand; editable specification fields grouped as on Phone Details; circular SVG spec gauges that reflect the currently entered numeric values; image management area for adding, ordering, and removing real device images; primary champagne save block; outline-only cancel action; inline validation messaging.
• States. Loading: the editor renders its ruled structure with fields resolving. Empty: a new model entry starts with empty fields and no images, with group headings and field labels visible. Success: a save confirms the record was written and the entered values and images persist. Error: validation failures (for example a required identifying field missing, or a numeric specification that is not a valid value) are shown inline against the offending field without discarding other entered values; a save failure states the failure and keeps the entered values in place. Recovery: the maintainer corrects the offending field and saves again, or cancels back to Catalog Management; nothing entered is silently lost on a failed save.

3. Functional Requirements

FR-1 — Browse all phone models across brands (explicit) As a Phone Shopper, I should browse a catalog of mobile phone models covering all brands and models, so that I can find the models I want to compare.

• Trigger/input: the shopper opens Phones, optionally narrowing by brand.
• Observable result: a ruled index of phone models renders with brand, model, display, chipset, camera, and battery columns aligned under a sticky condensed header row.
• Access state: anonymously reachable; no account required.
• Failure/recovery: if the catalog cannot be loaded, a ruled error panel states the failure and offers retry; if no model matches the narrowing, a ruled empty panel offers to clear it.
• Continuation: the shopper opens a model's Phone Details.

FR-2 — Read a model's specification details (explicit) As a Phone Shopper, I should open a specific phone model and read its specification details, so that I can understand exactly what that model offers.

• Trigger/input: the shopper selects a model from Phones.
• Observable result: Phone Details renders the model name as an oversized condensed engraving with a champagne rule, a gauge rail, and ruled specification tables grouped by Display / Performance / Camera / Battery / Build.
• Access state: anonymously reachable; no account required.
• Failure/recovery: if the model cannot be loaded, a ruled error panel states the failure and offers retry or return to Phones; a specification group with no recorded values renders a ruled note rather than blank rows.
• Continuation: the shopper opens the model's Phone Gallery or returns to Phones.

FR-3 — View real images of a model's device (explicit) As a Phone Shopper, I should view real images of a phone model's device, so that I can see what the physical device actually looks like.

• Trigger/input: the shopper opens Phone Gallery for a model, or selects a thumbnail in the strip.
• Observable result: the selected real device image renders at edge-to-edge macro stage size, with the active thumbnail marked by a champagne wipe and a teal index number.
• Access state: anonymously reachable; no account required.
• Failure/recovery: if an image fails to load, the stage shows a ruled failure frame for that image and the strip stays navigable; if the model has no images recorded, a ruled note states this and links to Phone Details.
• Continuation: the shopper moves to another image, or opens Phone Details for the model.

FR-4 — Use the website on a mobile phone (explicit) As a Phone Shopper, I should be able to use the whole website on a mobile phone, so that I can compare models and read specifications from the device in my hand.

• Trigger/input: the shopper opens any page at a phone viewport width.
• Observable result: the catalog index becomes a stacked label/value block per model with the model name in condensed caps above; the details page rails stack; the gallery stage and thumbnail strip remain usable; headlines, labels, numbers, and controls stay entirely inside the viewport and their container.
• Access state: applies to both anonymous and protected pages.
• Failure/recovery: long values wrap rather than crop; horizontally scrollable rows remain scrollable so every item becomes fully readable.
• Continuation: the shopper continues browsing, reading, or viewing images.

FR-5 — Establish a Catalog Maintainer identity on first use (required_inference) As a Catalog Maintainer, I should be able to establish my own identity from the Login entry, so that the catalog records I maintain remain bound to me and I can return to them.

• Trigger/input: the maintainer opens Login and chooses the first-use enrollment path, supplying the required identity fields.
• Observable result: the identity is established and the maintainer continues into Catalog Management.
• Access state: Login is anonymously reachable; Catalog Management and Phone Editor remain unavailable until identity is established.
• Failure/recovery: an already-registered identifier or unmet field requirements produce an inline message naming the problem without discarding entered values; the maintainer can correct and resubmit or switch to returning verification.
• Continuation: the maintainer lands in Catalog Management.

FR-6 — Return and verify before protected catalog work (required_inference) As a Catalog Maintainer, I should verify my identity when I return, so that I can resume administering the catalog without exposing protected records.

• Trigger/input: the maintainer opens Login and submits credentials on the returning-verification path.
• Observable result: identity is verified and the maintainer continues into Catalog Management.
• Access state: Catalog Management and Phone Editor require verified identity; the public catalog pages remain anonymously reachable.
• Failure/recovery: invalid credentials produce an inline message without discarding entered values; the maintainer can retry or switch paths.
• Continuation: the maintainer lands in Catalog Management.

FR-7 — Maintain the catalog as the authorized role (required_inference) As a Catalog Maintainer, I should be the role permitted to manage phone catalog records, so that catalog accuracy is controlled and attributable.

• Trigger/input: a verified maintainer opens Catalog Management or Phone Editor.
• Observable result: the protected maintenance surfaces are available to the verified maintainer and are not available to anonymous visitors.
• Access state: role-restricted to the Catalog Maintainer; the public catalog, details, and gallery pages are unaffected.
• Failure/recovery: an unverified visitor reaching a protected destination is directed to Login rather than shown protected records.
• Continuation: the maintainer proceeds with catalog work.

FR-8 — Review catalog records and find what needs updating (required_inference) As a Catalog Maintainer, I should see the catalog records and which ones need updates, so that I can keep every model's listings, specifications, and real images accurate and complete.

• Trigger/input: the maintainer opens Catalog Management, optionally narrowing to records needing updates.
• Observable result: a ruled record list renders with identifying information and completeness indicators showing which records are missing specification values or real images.
• Access state: role-restricted to the verified Catalog Maintainer.
• Failure/recovery: if records cannot be loaded, a ruled error panel states the failure and offers retry; if no records exist, a ruled panel offers to add the first model.
• Continuation: the maintainer opens a record in Phone Editor.

FR-9 — Add a new phone model entry (required_inference) As a Catalog Maintainer, I should add a new phone model entry, so that the catalog covers all models.

• Trigger/input: the maintainer starts a new entry from Catalog Management and supplies the model's identifying fields.
• Observable result: a new model entry exists in the catalog and is reachable from Phones and Catalog Management.
• Access state: role-restricted to the verified Catalog Maintainer.
• Failure/recovery: a missing required identifying field is reported inline against that field without discarding other entered values; a save failure keeps the entered values in place.
• Continuation: the maintainer continues editing the entry's specifications and images in Phone Editor.

FR-10 — Update a model's specification fields (explicit) As a Catalog Maintainer, I should add and update a model's specification fields, so that shoppers always see current, correct specification details.

• Trigger/input: the maintainer opens a record in Phone Editor and edits fields within the Display / Performance / Camera / Battery / Build groups.
• Observable result: the edited specification values are saved and appear on that model's Phone Details page; gauge-backed numeric values reflect the entered values.
• Access state: role-restricted to the verified Catalog Maintainer.
• Failure/recovery: an invalid numeric specification is reported inline against the offending field without discarding other entered values; a save failure states the failure and keeps the entered values in place.
• Continuation: the maintainer saves and returns to Catalog Management, or continues editing.

FR-11 — Add and update a model's real images (explicit) As a Catalog Maintainer, I should add and update the real images associated with a model, so that shoppers see genuine photographs of the device.

• Trigger/input: the maintainer adds, orders, or removes real device images for a model in Phone Editor.
• Observable result: the model's Phone Gallery shows the saved real images in the maintained order.
• Access state: role-restricted to the verified Catalog Maintainer.
• Failure/recovery: if an image cannot be saved, the failure is stated and the rest of the entry's values remain in place; the maintainer can retry or remove the offending image.
• Continuation: the maintainer saves and returns to Catalog Management, or continues editing.

FR-12 — Understand the catalog before browsing (required_inference) As a Phone Shopper, I should understand what the catalog contains before I start browsing, so that I know it covers all models with specifications and real images.

• Trigger/input: the shopper opens Landing.
• Observable result: the hero presents the headline, a champagne rule, a live ruled spec strip of a featured model's real values, and the BROWSE THE CATALOG action.
• Access state: anonymously reachable; no account required.
• Failure/recovery: if the featured model cannot be resolved, the hero degrades to headline, rule, and CTA with a muted note; the CTA remains fully usable.
• Continuation: the shopper enters Phones.

4. User Personas

Phone Shopper

Product context. The Phone Shopper arrives at a reference archive of mobile phone models, usually on a phone, usually while comparing hardware. They are not shopping in the transactional sense — nothing on this site is bought, priced, or ordered. Their work is reading and comparing: finding a model, reading its exact specification values, and looking at genuine photographs of the physical device.

Primary goal. Leave with a clear picture of which model fits their needs, based on exact specification details and real images of the device.

Distinct accepted responsibilities.

• Browse the model catalog across all brands and models (FR-1).
• Open a specific model and read its specification details (FR-2).
• View real images of a model's device (FR-3).
• Do all of this on a mobile phone (FR-4).
• Understand what the catalog contains before browsing (FR-12).

Relevant inputs and decisions. The shopper supplies a brand narrowing or a model selection. Their decisions are which model to open, which specification groups matter to them, and which images to examine. They make no commitment, transfer no value, and create no durable record.

Interactions with other accepted participants. The Phone Shopper is the reader of records the Catalog Maintainer writes. The shopper never interacts with the maintainer directly; the relationship is mediated entirely by the accuracy and completeness of the catalog records. A shopper's experience is directly degraded when a record is missing specification values or real images, which is exactly what the maintainer's completeness indicators exist to prevent.

Observable success. The shopper has opened a model, read its specification values grouped by Display / Performance / Camera / Battery / Build, viewed real images of the device at stage size, and can move to another model or another image without losing their place.

Constraints carried from source. The shopper's experience must work on a mobile phone; the catalog, details, and gallery are anonymously reachable and require no account.

Catalog Maintainer

Product context. The Catalog Maintainer is accountable for the whole catalog's accuracy: every model's listing, every specification value, and every real device image. Their work is editorial and corrective — they are not a shopper, and their surfaces are not the shopper's surfaces, even though the Phone Editor deliberately mirrors the Phone Details layout so that what they edit is exactly what shoppers will read.

Primary goal. Keep the site's phone model listings, specifications, and real device images accurate and complete across all models, so shoppers always see current, correct information.

Distinct accepted responsibilities.

• Establish their own identity on first use and verify it on return (FR-5, FR-6).
• Hold the role permitted to manage phone catalog records (FR-7).
• Review catalog records and identify which need updates (FR-8).
• Add new phone model entries so the catalog covers all models (FR-9).
• Add and update a model's specification fields (FR-10).
• Add and update a model's real images (FR-11).

Relevant inputs and decisions. The maintainer supplies model identifying fields, specification values within the Display / Performance / Camera / Battery / Build groups, and real device images with their order. Their decisions are which record to work on next, which values are correct, and which images genuinely represent the device.

Interactions with other accepted participants. The maintainer is the author of the records the Phone Shopper reads. Their completeness decisions — whether a record has all its specification values and real images — directly determine whether a shopper can complete a comparison. The maintainer's identity is bound to the records they write so that durable catalog state remains attributable and resumable across sessions.

Observable success. A saved record shows its specification values on Phone Details and its real images in Phone Gallery, and Catalog Management no longer flags that record as needing updates.

Constraints carried from source. The maintainer's editing surfaces must be usable on a mobile phone, and the protected surfaces require verified identity as the role permitted to manage catalog records.

5. Core User Flows

Flow A — Phone Shopper: understand the catalog and enter it

1. The Phone Shopper opens the site and lands on Landing (anonymous; no account).
2. The hero renders the oversized condensed headline EVERY MODEL. EVERY SPEC. with a champagne hairline rule beneath it, a featured model on the graphite stage, and a live ruled spec strip whose values count up to the featured model's real chipset, display, battery, and camera values.
3. The shopper reads the strip and understands the catalog's shape: all models, with specifications and real images.
4. The shopper activates BROWSE THE CATALOG, the solid champagne block at the base of the headline column.
5. Result: the shopper is in Phones.
6. Failure/recovery: if the featured model cannot be resolved, the hero degrades to headline, rule, and CTA with a muted note; the CTA remains fully usable, so the shopper still reaches Phones.
7. Continuation: Flow B.

Flow B — Phone Shopper: browse models across brands

1. The shopper is in Phones (anonymous).
2. The ruled instrument index renders: a sticky condensed uppercase header row, then one row per model with brand, model, display, chipset, camera, and battery columns aligned exactly, separated by hairline chapter-ring dividers.
3. The shopper optionally narrows the index by brand.
4. The shopper scans the aligned columns to compare models at a glance.
5. Result: the shopper has a shortlist of models worth opening.
6. Failure/recovery: if the catalog cannot be loaded, a ruled error panel states the failure and offers retry. If the narrowing matches no model, a ruled empty panel states this and offers to clear the narrowing; clearing restores the full catalog.
7. Continuation: the shopper opens a model, entering Flow C.

Flow C — Phone Shopper: read a model's specification details

1. The shopper selects a model row in Phones.
2. Phone Details opens (anonymous). The model name renders as an oversized condensed bezel engraving with a champagne hairline rule running the full viewport width beneath it.
3. The left rail shows circular SVG spec gauges for battery, refresh rate, camera MP, and weight; as they scroll into view they sweep from zero to their real values over 600ms with a precise ease-out, and the numbers count up in tabular figures.
4. The right rail shows ruled specification tables grouped by Display / Performance / Camera / Battery / Build, with topographic contour-line texture behind them.
5. The shopper reads the values that matter to them.
6. Result: the shopper knows the model's exact specification details.
7. Failure/recovery: if the model cannot be loaded, a ruled error panel states the failure and offers retry or return to Phones. If a specification group has no recorded values, that group renders a ruled note that the values are not yet recorded rather than blank rows — the shopper is never misled into thinking a value is zero.
8. Continuation: the shopper opens the model's Phone Gallery (Flow D) or returns to Phones (Flow B).

Flow D — Phone Shopper: view real images of the device

1. From Phone Details, the shopper opens Phone Gallery for that model (anonymous).
2. The edge-to-edge macro stage renders a real photograph of the device — front or back plate on a graphite ground, an angled three-quarter shot with a single raking light revealing the titanium frame or glass back, or an extreme macro of the camera module or port edge.
3. The thumbnail strip below shows the model's real images; the active thumb is marked by a champagne wipe and a teal index number.
4. The shopper selects another thumbnail, or presses an arrow key, to move between images. Transitions are 200ms crossfades.
5. Result: the shopper has seen genuine photographs of the physical device.
6. Failure/recovery: if an image fails to load, the stage shows a ruled failure frame for that image and the strip stays navigable; selecting another thumbnail or pressing an arrow key moves to a loadable image. If the model has no real images recorded, the stage shows a ruled note stating this and links to Phone Details.
7. Continuation: the shopper moves to another image, returns to Phone Details (Flow C), or returns to Phones (Flow B) to compare another model.

Flow E — Phone Shopper: compare on a mobile phone

1. The shopper opens the site at a phone viewport width (375px).
2. On Landing, the hero device moves above the headline, the headline wraps to three lines, and the spec strip becomes a horizontally scrollable ruled row whose items each become fully readable as they pass.
3. In Phones, each model row becomes a stacked label/value block with the model name in condensed caps above it.
4. In Phone Details, the rails stack; the model name, gauge values, group headings, and label/value rows all stay entirely inside the viewport and their container, wrapping rather than cropping.
5. In Phone Gallery, the macro stage and thumbnail strip remain usable and the strip remains scrollable.
6. Result: the shopper completes the same comparison work on a phone as on a desktop.
7. Failure/recovery: long values wrap rather than crop; scrollable rows remain scrollable so no item is permanently unreachable.
8. Continuation: the shopper continues browsing, reading, or viewing images.

Flow F — Catalog Maintainer: establish identity on first use

1. The Catalog Maintainer opens Login (anonymous; the protected destinations cannot own the interaction that grants access to themselves).
2. The maintainer chooses the first-use enrollment path and supplies the required identity fields.
3. The maintainer submits.
4. Result: the identity is established and the maintainer continues into Catalog Management.
5. Failure/recovery: if the identifier is already registered, or a required field is unmet, an inline message names the problem without discarding entered values; the maintainer corrects and resubmits, or switches to the returning-verification path.
6. Continuation: Flow H.

Flow G — Catalog Maintainer: return and verify

1. The Catalog Maintainer opens Login.
2. The maintainer submits credentials on the returning-verification path.
3. Result: identity is verified and the maintainer continues into Catalog Management.
4. Failure/recovery: invalid credentials produce an inline message without discarding entered values; the maintainer retries or switches paths. An unverified visitor reaching a protected destination is directed to Login rather than shown protected records.
5. Continuation: Flow H.

Flow H — Catalog Maintainer: review records and find what needs updating

1. The verified Catalog Maintainer is in Catalog Management (role-restricted).
2. A ruled record list renders with identifying information and completeness indicators showing which records are missing specification values or real images.
3. The maintainer optionally narrows the list to records needing updates.
4. The maintainer chooses the record to work on next.
5. Result: the maintainer knows exactly which records are incomplete and has selected one.
6. Failure/recovery: if records cannot be loaded, a ruled error panel states the failure and offers retry. If the catalog has no records yet, a ruled panel states this and offers to add the first model.
7. Continuation: the maintainer opens the record in Phone Editor (Flow I), or starts a new entry (Flow J).

Flow I — Catalog Maintainer: update a model's specifications and real images

1. The maintainer opens a record from Catalog Management into Phone Editor (role-restricted).
2. The editor mirrors Phone Details exactly: the same oversized condensed model name, the same gauge rail, and the same ruled specification groups (Display / Performance / Camera / Battery / Build).
3. The maintainer edits specification fields within the groups. The circular gauges reflect the currently entered numeric values as they change.
4. The maintainer adds, orders, or removes real device images for the model in the image management area.
5. The maintainer activates the primary champagne save block.
6. Result: the record is written. The edited specification values appear on that model's Phone Details page, and the saved real images appear in that model's Phone Gallery in the maintained order. Catalog Management no longer flags the record as needing those updates.
7. Failure/recovery: an invalid numeric specification is reported inline against the offending field without discarding other entered values. A save failure states the failure and keeps the entered values in place. If an image cannot be saved, the failure is stated and the rest of the entry's values remain in place; the maintainer retries or removes the offending image. Nothing entered is silently lost on a failed save.
8. Continuation: the maintainer returns to Catalog Management (Flow H) to pick the next record, or continues editing.

Flow J — Catalog Maintainer: add a new phone model entry

1. From Catalog Management, the maintainer starts a new entry.
2. Phone Editor opens with empty fields and no images, with group headings and field labels visible.
3. The maintainer supplies the model's identifying fields (brand and model name).
4. The maintainer fills specification values within the Display / Performance / Camera / Battery / Build groups and adds the model's real device images.
5. The maintainer saves.
6. Result: a new model entry exists in the catalog, is reachable from Phones, and its specification details and real images render on Phone Details and Phone Gallery.
7. Failure/recovery: a missing required identifying field is reported inline against that field without discarding other entered values; a save failure keeps the entered values in place so the maintainer can correct and save again.
8. Continuation: the maintainer returns to Catalog Management (Flow H) or continues editing the new entry.

6. Visuals Colors and Theme

Muse and headline. MARQ by Garmin — precision instrument luxury for a phone specification archive. The product must feel like a machined instrument, not a storefront: dark titanium grounds, ruled data rows, dial-like gauges, macro material detail on devices, one instrument accent.

Colour tokens (dark mode).

Rule: never more than one accent colour visible per panel.

Typography.

• Headings: Saira Condensed, weight 600–700, uppercase, letter-spacing 0.02em, numbers in tabular figures at large scale. Model names set enormous and tight-leading (0.92) so GALAXY S24 ULTRA reads as a bezel engraving.
• Body: Archivo 400 at 16–17px with 1.6 leading — humanist enough to read long spec paragraphs without feeling like a datasheet.
• Scale: 1.25 modular with a display jump — 44px mobile → 104px desktop display; 28 / 20 / 17 / 15 / 13 for headings, labels, body, metadata, micro-labels. Micro-labels uppercase 11px, tracking 0.14em. All display sizes use clamp() so nothing crops at 375px.

Shape language. Machined geometry: 2px radii on data panels (never soft cards), 1px hairline borders in #2A2F35, ruled horizontal data rows like a watch dial's chapter ring, circular gauge rings for numeric specs (battery mAh, refresh rate, camera MP) drawn as SVG arcs with a champagne needle and a teal fill arc. Buttons are squared with a 2px radius and a 1px metal edge highlight; the primary action is a solid champagne block, secondary actions are outline-only.

Layout. A 12-column instrument grid at 1280px with an 8px baseline; 6 columns at 768px; a single column with 20px gutters at 375px. The Phones catalog is a dense ruled index — one row per model, columns aligned like a spec sheet (brand, model, display, chipset, camera, battery) with a sticky condensed header row; on mobile each row becomes a stacked label/value block with the model name in condensed caps above. Phone Details is a two-rail layout: a fixed left rail of circular gauges and a right rail of ruled specification tables grouped by Display / Performance / Camera / Battery / Build. Phone Gallery is an edge-to-edge macro image stage with a thumbnail strip. Phone Editor mirrors the details page exactly so maintainers edit the same shapes shoppers read.

Imagery style. Real device photography treated as product macro: front and back plates on graphite grounds, angled three-quarter shots with a single raking light to reveal material (titanium frame, glass back, camera island), extreme macro of the camera module and port edges. Images are cut out on #0B0D0F or bled to the viewport edge in the gallery. Topographic contour lines and dial chapter-ring graphics are used as background texture behind spec tables. No stock people, no lifestyle scenes, no clip art.

Forbidden. Blue or indigo primary/accent on white; soft rounded cards with hover-lift shadows; gradient-blob heroes, glassmorphism panels, or floating translucent tiles; Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body; centred headline + subtext + button hero composition; lifestyle stock photography of people holding phones; bouncy or springy easing; more than one accent colour visible in a single panel. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text 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 direction asks, as long as it covers no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. With prefers-reduced-motion it stops and shows whole items: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.

7. Signature Design Concept

The instrument stage. The public entry is a full-bleed graphite stage (#0B0D0F) where one phone — the featured model — sits off-centre right as a large cut-out macro render on a slow turntable, lit by a single raking highlight along its titanium edge. On the left, a 9-column condensed uppercase headline spans the viewport at clamp(44px, 9vw, 104px) reading EVERY MODEL. EVERY SPEC., with a champagne hairline rule beneath it. Beneath the rule, a live ruled spec strip (chipset / display / battery / camera) counts up to the featured model's real values in tabular figures. The CTA BROWSE THE CATALOG is a solid champagne block pinned at the base of the headline column, not centred. A thin teal gauge arc sweeps behind the phone as a decorative dial.

The concept recomposes only accepted content and controls: the featured model's real specification values, its real device image, the headline, and the single CTA into Phones. It introduces no new behaviour, page, or destination.

Signature moves carried through the product.

• Circular SVG spec gauges with a champagne needle and teal fill arc that sweep and count up when scrolled into view — used for battery, refresh rate, camera MP, and weight on both Phone Details and Phone Editor.
• The Phones catalog as a ruled instrument index: sticky condensed uppercase header row, hairline chapter-ring dividers, label/value columns aligned exactly, and the hovered row's left rule igniting to champagne.
• An oversized condensed model name set as a bezel engraving — uppercase, 0.92 leading, clamp(44px, 9vw, 104px), with a champagne hairline rule running the full viewport width beneath it.
• The Phone Gallery as an edge-to-edge macro image stage with a thumbnail strip whose active thumb is marked by a champagne wipe and a teal index number, with keyboard arrow navigation.
• A topographic contour-line texture behind grouped specification tables, drawn in #1E2226 at 3% opacity so the data panels read as engineered surfaces rather than flat cards.

Mobile recomposition (375px). The phone moves above the headline, the headline wraps to three lines, and the spec strip becomes a horizontally scrollable ruled row.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: the featured phone model as a large cut-out macro render on a graphite stage, off-centre right, lit by a single raking highlight along its titanium edge.
• Input → transformation → outcome thesis: as the visitor arrives and scrolls, the hero device turntable rotates slowly and continuously; the live ruled spec strip counts up in tabular figures to the featured model's real chipset, display, battery, and camera values; the decorative teal gauge arc sweeps behind the phone. The outcome is a visitor who has read the catalog's defining facts — real models, real specifications, real images — and reaches the BROWSE THE CATALOG block already oriented.
• Motion vocabulary: instrument motion only — gauges sweep from zero to value on scroll into view over 600ms with a precise ease-out (no bounce); numbers count up in tabular figures; the hero device turntable rotates slowly and continuously; gallery transitions are 200ms crossfades with a champagne wipe on the active thumbnail; hover on a catalog row raises its left edge rule to champagne in 120ms.
• Composed first frame: graphite stage, headline EVERY MODEL. EVERY SPEC. at full display size with the champagne rule beneath it, the phone held at a three-quarter angle with its raking edge highlight, the spec strip at zero before its count-up, and the champagne CTA pinned at the base of the headline column.
• Reduced-motion state: all motion collapses to a static value display — the turntable holds a fixed three-quarter frame, gauges show their final values without sweeping, numbers show final values without counting, and the spec strip is fully readable without scrolling motion.

9. Non-Functional Requirements

NFR-1 — Mobile usability (explicit) The website must be built for mobile phone use. Every page — Landing, Login, Phones, Phone Details, Phone Gallery, Catalog Management, and Phone Editor — must be fully usable at a 375px viewport, with headlines, labels, numbers, and controls staying entirely inside the viewport and their container, wrapping or scaling rather than cropping. Rationale: the source states the website must be usable on mobile phones, and the Phone Shopper's primary context is a phone in hand.

NFR-2 — Real device imagery (explicit) Images presented for a phone model must be real images of the device, not illustrations, placeholders, or lifestyle scenes. Rationale: the source requires real images of the device for each model.

NFR-3 — Catalog completeness across all models (explicit) The catalog must be able to cover mobile phone models across all brands and models, and each model must be able to carry both specification details and real images. Rationale: the source requires a complete website covering all models with specifications and real images.

NFR-4 — Protected catalog integrity (required_inference) Catalog Management and Phone Editor must be reachable only by a verified Catalog Maintainer, and saved catalog records must remain bound to the maintainer identity that wrote them. Rationale: durable catalog records must remain attributable and resumable, and protected state must not be exposed to anonymous visitors.

NFR-5 — Readable contrast (required_inference) Body text #EDEFF2 on background #0B0D0F maintains approximately 15:1 contrast; muted labels #8A9099 and champagne #C9A66B on dark grounds must remain legible at their specified sizes. Rationale: the specification archive is a reading product; specification values must be readable at every viewport.

NFR-6 — Motion accessibility (required_inference) All motion — gauge sweeps, count-ups, the hero turntable, gallery crossfades, and row hover transitions — must collapse to a static value display under prefers-reduced-motion, with all values and items fully readable. Rationale: the direction specifies this collapse, and no accepted content may become unreachable when motion is disabled.

NFR-7 — Backend integration (required_inference) The application requires backend integration to store and serve catalog records, specification values, and image references, and to verify maintainer identity. Rationale: durable catalog records and maintainer-bound identity cannot be delivered by a static site.

10. Tech Stack

• Frontend: React, delivered as a responsive web application. The catalog index, two-rail details layout, gallery stage, and editor mirror are all built as React surfaces. [Default — not specified by user]
• Backend: Python with FastAPI, serving catalog records, specification values, image references, and maintainer identity verification. [Default — not specified by user]
• Storage: A relational database for phone model records, specification fields grouped by Display / Performance / Camera / Battery / Build, image references and their order, and maintainer identities. Object storage for the real device image files. [Default — not specified by user]
• Containerization: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Kubernetes: Not required by the source; omitted. [Default — not specified by user]

No source-specified technology choices were provided beyond the requirement that the site be a complete website usable on mobile phones; the above are labeled defaults.

11. Assumptions and Constraints

Constraints (binding).

• The website must be built for mobile phone use. (explicit)
• Each phone model must have its specification details presented. (explicit)
• Each phone model must have real images of the device presented. (explicit)
• The website must cover mobile phone models across all brands and models. (explicit)
• The public catalog, Phone Details, and Phone Gallery are anonymously reachable; Catalog Management and Phone Editor are role-restricted to the verified Catalog Maintainer. (from the page and access contract)
• No shopping, checkout, pricing, ordering, payment, shipping, reviews, ratings, user-generated content, or social features are in scope. (narrow exclusion — not accepted by the source)

Assumptions (narrow, labeled).

• A-1 (required_inference) — The Catalog Maintainer establishes identity through the Login entry, because no provisioning or invitation boundary is established by the source. Login is anonymously reachable so that it can own the interaction that grants access to the protected destinations.
• A-2 (required_inference) — Catalog Management and Phone Editor are protected because durable catalog records must remain bound to the correct maintainer and resumable across sessions. This protection does not extend to the public catalog, details, or gallery pages.
• A-3 (required_inference) — The specification groups Display / Performance / Camera / Battery / Build, and the gauge-backed numeric values (battery mAh, refresh rate, camera MP, weight), are the concrete shape of "specification details" used consistently across Phone Details and Phone Editor. They are the same shapes on both pages by design.
• A-4 (required_inference) — The featured model on Landing is drawn from the existing catalog; if none is available, the hero degrades gracefully without blocking the CTA.
• A-5 (required_inference) — Real device images are stored and served by the application, and their maintained order determines the Phone Gallery thumbnail order.
• A-6 (Default — not specified by user) — The tech stack in Section 10 is a labeled default; no source-specified technology was provided.

12. Glossary

• Phone model — A single mobile phone model record in the catalog, identified by brand and model name, carrying specification values and real device images.
• Specification details — The recorded values for a phone model, grouped as Display / Performance / Camera / Battery / Build, including gauge-backed numeric values such as battery mAh, refresh rate, camera MP, and weight.
• Real images — Genuine photographs of the physical device (front and back plates, angled three-quarter shots, macro detail of the camera module and port edges), as opposed to illustrations, placeholders, or lifestyle scenes.
• Catalog — The complete collection of phone model records across all brands and models.
• Ruled index — The Phones catalog presentation: one row per model with aligned label/value columns under a sticky condensed uppercase header row, separated by hairline chapter-ring dividers.
• Spec gauge — A circular SVG arc with a champagne needle and teal fill arc that sweeps from zero to a numeric specification value when scrolled into view.
• Phone Shopper — The accepted persona who browses the catalog, reads a model's specification details, and views real images of the device.
• Catalog Maintainer — The accepted persona responsible for keeping phone model listings, specifications, and real device images accurate and complete across all models.
• Completeness indicator — The Catalog Management signal showing which records are missing specification values or real images.
• Bezel engraving — The oversized condensed uppercase model name treatment with 0.92 leading and a champagne hairline rule running the full viewport width beneath it.