System Requirements Document for event-hashtag

1. Introduction

event-hashtag is the public website for a wedding and event studio. Its purpose is twofold and equally weighted:

1. Showcase the studio's portfolio — present the studio's past wedding and event work as a browsable, art-directed body of evidence that lets prospective clients judge the studio's taste and point of view.
2. Make booking easier — let people who want a reservation submit a booking request for their own event through a clear, trustworthy, low-friction flow.

The audience is couples and event hosts (roughly 25–45) planning an emotionally loaded day, plus the studio owner/coordinator who must present the studio as an artist rather than a vendor and who must review incoming reservation requests. The site is a first-party, application-owned product with custom UI: a public-facing portfolio and reservation experience, and a studio-side workspace for maintaining portfolio content and handling reservations.

2. System Overview

event-hashtag is delivered as a custom web application with application-owned identity. It has two sides:

• Public / prospective-client side — an anonymous landing page, a publicly browsable portfolio, and a self-service enrollment and login path. Once enrolled and verified, a prospective client reaches a protected booking workspace where they submit a reservation request for their event.
• Studio side — a protected portfolio-management workspace and a protected reservations workspace, reachable by the studio owner/coordinator after returning verification.

The current delivery covers: portfolio presentation, prospective-client enrollment and returning verification, submission of reservation requests, studio-side portfolio maintenance, and studio-side review of incoming reservation requests. It does not cover payment processing, contract signing, calendar/scheduling integrations, messaging or chat, or any third-party marketplace behavior; those are outside the current scope.

2a. Product Interpretation and Delivery Boundary

The product is a first-party website owned and operated by the studio. All pages are application-owned custom pages; there is no provider-owned or external-only surface in the current scope, and no headless delivery.

Access ownership. The public entry (Landing) and the Portfolio are anonymously reachable — a prospective client can evaluate the studio without any account. The Booking workspace, Portfolio Management, and Reservations are protected. Because a prospective client must be able to submit a reservation request and later return to it, and because the studio owner/coordinator must reach protected studio work, the application owns identity: first-use enrollment happens on Sign Up, and returning verification happens on Login. Sign Up and Login are themselves anonymously reachable — a protected destination never owns the interaction that establishes access to itself.

Current vs. future. Everything described in this document is current. No future-horizon requirements were stated by the user; nothing in this document is deferred.

Narrow exclusions. The site does not process payments, does not execute or sign contracts, does not provide chat or messaging, and does not integrate external scheduling or calendar providers. Reservation requests are requests, not confirmed bookings, until the studio reviews them.

2b. Source Content Inventory

No reference directive with content_source authority was supplied. No source content inventory is included.

2c. Page Content and Component Coverage

The page inventory below is the supplied final page contract, preserved exactly and in order: Landing, Sign Up, Login, Portfolio, Booking, Portfolio Management, Reservations.

Landing

• Information / state: Anonymous public entry. Explains the wedding and event studio, who it serves, and how its portfolio and reservation process work. Presents the studio's point of view and the path into the portfolio and into a reservation.
• Primary actions: "Start a reservation" (routes an anonymous visitor toward enrollment/verification and then Booking); "See the portfolio" (routes to Portfolio).
• Supporting actions: Navigate to Login for returning users; navigate to Sign Up for first-time users.
• Domain entities: Studio (identity, service categories, established year, availability horizon); Portfolio project (as teaser); Reservation request (as described process, not yet created).
• Component responsibilities: Asymmetric poster hero with oversized display headline, one line overprinted in accent red with a hand-painted underline stroke; one line of body copy; two square buttons (solid ink and outlined); full-bleed hero photograph with a rotated rubber-stamp metadata rectangle; a full-width hairline ink rule carrying the studio's three service categories; a single marquee ticker of recent venues and event names along a section boundary.
• States: Loading — hero photograph and portfolio teaser resolve progressively; type renders immediately. Empty — if no portfolio projects exist yet, the teaser area shows a short studio statement instead of project imagery. Success — hero, service-category rule, and ticker render; both primary actions are reachable. Error — if the portfolio teaser fails to load, the hero and both primary actions remain fully usable and the teaser area is omitted. Recovery — the visitor can proceed directly to Sign Up, Login, or Portfolio without the teaser.

Sign Up

• Information / state: Anonymous first-use enrollment surface for a prospective client. Collects the minimum identity information needed to establish an application-owned account so a reservation request can be submitted and later revisited.
• Primary actions: Submit enrollment to create the prospective client's account.
• Supporting actions: Navigate to Login if the visitor already has an account; return to Landing.
• Domain entities: Prospective Client account (identity, credentials).
• Component responsibilities: Ruled, printed-card-style form with label above value and hairline rules between fields; one accent-filled submit block; inline validation messaging; link to Login.
• States: Loading — submit block shows an in-progress state and prevents duplicate submission. Empty — all fields blank with labels visible. Success — account is established and the prospective client continues to the protected Booking workspace. Error — invalid or incomplete input is reported inline against the specific field; an already-enrolled identity is reported with a direct route to Login. Recovery — the visitor corrects the field and resubmits, or switches to Login, without losing entered values.

Login

• Information / state: Anonymous returning-verification surface serving both accepted personas: a returning prospective client resuming booking continuity, and the studio owner/coordinator returning to protected portfolio and reservation work.
• Primary actions: Submit credentials to verify identity and continue to the correct protected destination.
• Supporting actions: Navigate to Sign Up for first-time visitors; return to Landing.
• Domain entities: Prospective Client account; Studio Owner/Coordinator account.
• Component responsibilities: Ruled form in the same printed-card language as Sign Up; one accent-filled submit block; inline error messaging; link to Sign Up.
• States: Loading — submit block shows an in-progress state and prevents duplicate submission. Empty — fields blank with labels visible. Success — identity verified; a prospective client continues to Booking, a studio owner/coordinator continues to Reservations or Portfolio Management. Error — unrecognized or incorrect credentials are reported inline without revealing which part was wrong. Recovery — the user retries, or routes to Sign Up if they have no account.

Portfolio

• Information / state: Publicly browsable collection of the studio's past wedding and event work, presented as a staggered two-column editorial run rather than a uniform card grid. Each project carries a full-bleed image and a type-set caption block with date, venue, and a one-line studio note.
• Primary actions: Browse the editorial run of projects; open a project's full presentation.
• Supporting actions: Proceed to "Start a reservation" from within the portfolio context; navigate to Landing or Login.
• Domain entities: Portfolio project (image, date, venue, studio note, ordering).
• Component responsibilities: Alternating left/right full-bleed image blocks; caption blocks with date, venue, and one-line studio note; hover crossfade on images with a 4px lift of the caption rule; rubber-stamp metadata motif overlaid on imagery; hard crops that may bleed off the viewport edge.
• States: Loading — images resolve progressively in editorial order; caption text renders immediately. Empty — when the studio has published no projects, the page shows a short studio statement and a route to start a reservation. Success — all published projects render in studio-defined order with complete captions. Error — an individual image that fails to load leaves its caption block intact and readable. Recovery — the visitor continues browsing remaining projects or proceeds to start a reservation.

Booking

• Information / state: Protected booking workspace where a verified prospective client submits a reservation request for their own event. Styled as a printed reservation card: single column, label above value, hairline rules between fields, one accent-filled submit block.
• Primary actions: Submit the reservation request for the event.
• Supporting actions: Review previously submitted requests and their status; return to Portfolio; sign out.
• Domain entities: Reservation request (event date, event type, venue or location, contact details, notes, submission timestamp, status).
• Component responsibilities: Ruled single-column form; field-level validation; accent-filled submit block; a live "request received" stamp that rotates in on successful submit; a list of the client's own submitted requests with status shown as a small stamp chip.
• States: Loading — the client's existing requests load before the form is interactive. Empty — no prior requests; the form is presented alone with a clear prompt. Success — the request is recorded, the rotating "request received" stamp appears, and the new request appears in the client's list with its status. Error — invalid or incomplete fields are reported inline against the specific field; a submission that fails to record is reported with a clear retry path and the entered values are preserved. Recovery — the client corrects and resubmits, or returns later to the same workspace to see the request's status.

Portfolio Management

• Information / state: Protected studio-side workspace for maintaining the portfolio content presented on the public Portfolio page.
• Primary actions: Add a portfolio project; edit an existing project's image, date, venue, and one-line studio note; reorder projects; remove a project from publication.
• Supporting actions: Preview how a project will appear in the public editorial run; navigate to Reservations; sign out.
• Domain entities: Portfolio project (image, date, venue, studio note, ordering, publication state).
• Component responsibilities: Ruled list of existing projects with tabular alignment; per-project edit surface using the same printed-card form language; image handling with hard-crop framing; publication toggle; ordering control.
• States: Loading — the existing project list loads before editing is enabled. Empty — no projects exist yet; the workspace prompts the studio to add the first project. Success — the change is saved and reflected in the list and on the public Portfolio page. Error — a save that fails is reported against the affected project and the unsaved values are preserved. Recovery — the studio retries the save or discards the change without affecting other projects.

Reservations

• Information / state: Protected studio-side workspace for reviewing incoming reservation and booking requests, presented as a dense ruled ledger — one row per request, tabular alignment, date column in ink black, status as a small stamp chip.
• Primary actions: Review each incoming reservation request and set its status.
• Supporting actions: Open a request's full detail; filter or scan the ledger by date and status; navigate to Portfolio Management; sign out.
• Domain entities: Reservation request (event date, event type, venue or location, contact details, notes, submission timestamp, status).
• Component responsibilities: Ruled ledger rows with tabular alignment; date column in ink black; status rendered as a small stamp chip; request detail view; status control.
• States: Loading — the ledger loads before rows are interactive. Empty — no requests have been received; the ledger shows an empty ruled frame with a short explanatory line. Success — all incoming requests are listed with their current status, and a status change is reflected immediately in the row. Error — a status change that fails to save is reported against that row and the previous status is restored. Recovery — the studio retries the status change; the request remains in the ledger regardless.

3. Functional Requirements

Each requirement is a distinct story point with provenance and observable acceptance.

FR-1 — Public studio website (explicit) As a visitor, I should be able to reach a public website for the wedding and event studio so that I can learn who the studio is and what it does.

• Trigger/input: the visitor opens the site.
• Observable result: the Landing page renders with the studio's identity, its service categories, and clear routes into the portfolio and into a reservation.
• Access state: anonymous, no account required.
• Failure/recovery: if supporting media fails to load, the studio's identity, service categories, and both primary routes remain fully usable.
• Continuation: the visitor proceeds to Portfolio, Sign Up, or Login.

FR-2 — Browse the studio portfolio publicly (explicit) As a prospective client, I should be able to browse the studio's portfolio so that I can judge whether the studio's work fits my wedding or event.

• Trigger/input: the prospective client opens Portfolio from Landing or directly.
• Observable result: the studio's published projects render as a staggered editorial run, each with a full-bleed image and a caption block carrying date, venue, and a one-line studio note.
• Access state: anonymous, no account required.
• Failure/recovery: an image that fails to load leaves its caption block intact and readable; the client continues browsing.
• Continuation: the client proceeds to start a reservation, or returns to Landing.

FR-3 — First-use enrollment for a prospective client (required_inference) As a prospective client, I should be able to establish my own account so that I can submit a reservation request and return to it later.

• Trigger/input: the prospective client chooses to start a reservation and has no account.
• Observable result: the client's account is established and the client continues to the protected Booking workspace.
• Access state: Sign Up is anonymously reachable; the account it establishes is application-owned.
• Failure/recovery: invalid or incomplete input is reported inline against the specific field; an already-enrolled identity is reported with a direct route to Login; entered values are preserved.
• Continuation: the client continues to Booking, or switches to Login.

FR-4 — Returning verification for both accepted personas (required_inference) As a returning prospective client or studio owner/coordinator, I should be able to verify my identity so that I can reach my protected work.

• Trigger/input: the user opens Login and submits credentials.
• Observable result: identity is verified and the user continues to the correct protected destination — Booking for a prospective client, Reservations or Portfolio Management for the studio owner/coordinator.
• Access state: Login is anonymously reachable; the destinations it unlocks are protected.
• Failure/recovery: unrecognized or incorrect credentials are reported inline without revealing which part was wrong; the user retries or routes to Sign Up.
• Continuation: the user reaches their protected workspace.

FR-5 — Submit a reservation request (explicit) As a prospective client, I should be able to submit a reservation request for my event so that the studio can consider booking my date.

• Trigger/input: a verified prospective client completes the ruled reservation form on Booking with their event details and submits it.
• Observable result: the request is recorded against the client's account, a "request received" stamp appears, and the request appears in the client's own list with a status.
• Access state: protected; requires verified prospective-client identity.
• Failure/recovery: invalid or incomplete fields are reported inline against the specific field; a submission that fails to record is reported with a clear retry path and the entered values are preserved.
• Continuation: the client returns later to Booking to see the request's status.

FR-6 — Review my own submitted requests (required_inference) As a prospective client, I should be able to see the reservation requests I have submitted and their current status so that I know where my request stands.

• Trigger/input: the verified client opens Booking.
• Observable result: the client's own submitted requests are listed with their current status shown as a small stamp chip.
• Access state: protected; the client sees only their own requests.
• Failure/recovery: if the list fails to load, the form remains usable and the failure is reported with a retry path.
• Continuation: the client submits a new request or returns later.

FR-7 — Maintain the portfolio content (required_inference) As a studio owner/coordinator, I should be able to maintain the portfolio content presented on the public site so that the portfolio keeps representing the studio's current work.

• Trigger/input: the studio owner/coordinator opens Portfolio Management and adds, edits, reorders, or removes a project.
• Observable result: the change is saved and reflected in the workspace list and on the public Portfolio page.
• Access state: protected; requires verified studio owner/coordinator identity.
• Failure/recovery: a save that fails is reported against the affected project and the unsaved values are preserved; other projects are unaffected.
• Continuation: the studio continues editing or moves to Reservations.

FR-8 — Review incoming reservation requests (required_inference) As a studio owner/coordinator, I should be able to review incoming reservation and booking requests so that prospective clients can be confirmed.

• Trigger/input: the studio owner/coordinator opens Reservations.
• Observable result: incoming requests are listed as a dense ruled ledger — one row per request, tabular alignment, date column in ink black, status as a small stamp chip — and each request's status can be set.
• Access state: protected; requires verified studio owner/coordinator identity.
• Failure/recovery: a status change that fails to save is reported against that row and the previous status is restored; the request remains in the ledger.
• Continuation: the studio continues reviewing or moves to Portfolio Management.

FR-9 — Studio owner/coordinator access provisioning (required_inference) As a studio owner/coordinator, I should be provisioned or invited with studio-management permissions before accessing portfolio management and reservation review, so that studio-side work is bound to the correct person.

• Trigger/input: the studio owner/coordinator is provisioned or invited.
• Observable result: the studio owner/coordinator can verify identity on Login and reach Portfolio Management and Reservations.
• Access state: provisioning precedes protected access; Login remains anonymously reachable.
• Failure/recovery: an unprovisioned identity cannot reach studio-side workspaces and is routed to Login.
• Continuation: the studio owner/coordinator performs portfolio or reservation work.

4. User Personas

Prospective Client

Product context. A person planning a wedding or event who is evaluating studios. They arrive without an account, usually from a search or a referral, and their first job is judgment: does this studio's taste match the day I am imagining?

Primary goal. See the studio's past work and reserve the studio for their own date.

Distinct accepted responsibilities. Browsing the portfolio to judge fit; establishing their own account on first use; submitting a reservation request for their event; returning to see the status of the requests they submitted. This role's work is evaluative and initiating — they consume the studio's presentation and create a request. They never see other clients' requests and never touch portfolio content.

Relevant inputs or decisions. Which projects they look at; whether the studio fits; their event date, event type, venue or location, contact details, and notes; whether to submit now or return later.

Interactions with other accepted participants. The prospective client's submitted request becomes the object the Studio Owner/Coordinator reviews on Reservations. The client's own observable outcome is the recorded request and its status; the studio's review is what moves that status.

Observable success. The client's reservation request is recorded against their account, appears in their own list with a status, and remains reachable when they return.

Studio Owner/Coordinator

Product context. The studio-side person responsible for how the studio is presented and for handling the requests that come in. They need the site to read as an artist's body of work, not a vendor listing, and they need incoming requests to be reviewable without friction.

Primary goal. Keep the portfolio representing the studio's current work and review incoming reservation requests so prospective clients can be confirmed.

Distinct accepted responsibilities. Maintaining portfolio content — adding, editing, reordering, and removing projects with their image, date, venue, and one-line studio note; reviewing incoming reservation requests in a dense ledger; setting each request's status. This role's work is curatorial and responsive — they shape what the public sees and act on what the public sends. They do not submit reservation requests as clients.

Relevant inputs or decisions. Which projects to publish and in what order; each project's date, venue, and studio note; which incoming requests to act on and what status to assign.

Interactions with other accepted participants. The studio owner/coordinator acts on requests created by Prospective Clients; their portfolio decisions determine what Prospective Clients see on Portfolio.

Observable success. Portfolio changes appear on the public Portfolio page, and incoming requests are listed with current statuses that the studio can change.

5. Core User Flows

Flow A — Prospective Client evaluates the studio and submits a reservation request

1. Starting context: The prospective client is anonymous and has no account. They open the site and land on Landing.
2. On Landing they read the studio's statement, see the service categories on the full-width rule, and see the hero photograph with its rubber-stamp metadata.
3. They choose "See the portfolio" and arrive at Portfolio.
4. On Portfolio they browse the staggered editorial run. Each project shows a full-bleed image and a caption block with date, venue, and a one-line studio note. Hovering an image crossfades it and lifts the caption rule 4px.
5. Decision: They judge the studio's fit. If it does not fit, they return to Landing and leave — no account is created. If it fits, they choose "Start a reservation".
6. Because they are not yet verified, they are routed to Sign Up. They complete the ruled enrollment form and submit.
7. Observable result: Their account is established and they continue to the protected Booking workspace.
8. On Booking they complete the printed-reservation-card form — event date, event type, venue or location, contact details, and notes — and submit.
9. Observable result: The request is recorded against their account, the "request received" stamp rotates in, and the request appears in their own list with a status shown as a small stamp chip.
10. Failure/recovery: If a field is invalid, it is reported inline against that field and their entered values are preserved. If the submission fails to record, they are told clearly and can retry without re-entering everything.
11. Continuation: They leave and return later.

Flow B — Prospective Client returns to check a request

1. Starting context: The prospective client has an account and at least one submitted request. They open Login.
2. They submit their credentials.
3. Observable result: Their identity is verified and they continue to Booking.
4. On Booking they see their previously submitted requests listed with their current statuses as stamp chips.
5. Failure/recovery: If their credentials are not recognized, the error is reported inline without revealing which part was wrong; they retry or route to Sign Up.
6. Continuation: They submit an additional request, or leave and return again later.

Flow C — Studio Owner/Coordinator maintains the portfolio

1. Starting context: The studio owner/coordinator has been provisioned or invited with studio-management permissions. They open Login.
2. They submit their credentials and are verified.
3. Observable result: They continue to the protected studio side and open Portfolio Management.
4. They add a new project, or edit an existing project's image, date, venue, and one-line studio note, or reorder projects, or remove a project from publication.
5. Observable result: The change is saved and reflected in the workspace list and on the public Portfolio page, where prospective clients will see it in the editorial run.
6. Failure/recovery: If a save fails, the failure is reported against that project and the unsaved values are preserved; other projects are unaffected. They retry or discard the change.
7. Continuation: They continue editing or move to Reservations.

Flow D — Studio Owner/Coordinator reviews incoming reservation requests

1. Starting context: The studio owner/coordinator is verified and opens Reservations.
2. Observable result: Incoming requests appear as a dense ruled ledger — one row per request, tabular alignment, the date column in ink black, and status as a small stamp chip.
3. They scan or filter the ledger by date and status, and open a request's full detail to read the client's event date, event type, venue or location, contact details, and notes.
4. Decision: They set the request's status.
5. Observable result: The status change is reflected immediately in that row's stamp chip, and the prospective client sees the updated status the next time they open Booking.
6. Failure/recovery: If a status change fails to save, the failure is reported against that row and the previous status is restored; the request remains in the ledger.
7. Continuation: They continue reviewing remaining requests or move to Portfolio Management.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Stefan Sagmeister — handmade provocation, type built from real things, warmth with an edge. Headline idea: the studio's taste is the product, so the site must argue for it rather than neutralize it.

Color tokens (light mode):

Accent covers under 8% of any screen. Portfolio photography supplies the rest of the color; no additional UI hues. Blue, indigo, and violet are excluded entirely, and pure white (#FFFFFF) grounds are excluded.

Typography:

• Headings: Archivo Black, set very large with tight tracking (−0.02em to −0.035em) and tight leading (0.88–0.94), sentence case with occasional all-caps lines for stamp-like labels. Display sizes are deliberately oversized and allowed to run edge-to-edge; short two- to four-word statements, never long sentences.
• Second display voice: hand-lettered-style caps from Rubik Mono One, or letter-spaced Oswald, reserved for stamp and tag elements.
• Body: Karla.
• Scale: 1.5 modular, clamp-based — display 56px mobile → 128px desktop; section head 34 → 68; subhead 22 → 30; body 17 → 19; label 12 → 13 uppercase tracked +0.14em. Body line-height 1.6, max measure 62ch.
• Inter, Roboto, Arial, Helvetica, Poppins, Lato, Open Sans, and system-ui are excluded for headings and body.

Shape language: Hard edges and honest materials — square corners everywhere (0–2px radius, never pills), thick 2px ink rules, chunky outlined panels, and a rubber-stamp motif: a rotated, semi-transparent ink rectangle or circle sitting over imagery. Buttons are solid ink blocks or solid accent blocks with square corners and a 3px hard offset shadow (no blur). Photographic frames are full-bleed with hard crops; text blocks are the only soft elements, via generous leading.

Spacing rhythm: Poster grid on a 12-column layout that the composition visibly breaks. Headlines span 9–12 columns and bleed to the viewport edge; images sit in 5- or 7-column blocks that intentionally overlap type by 8–24px at desktop and stack cleanly at mobile. Generous leading is the only softness.

Imagery style: Art-directed real photography, warm and slightly grainy — tables set at golden hour, hands, flowers out of focus in the foreground, a venue shot wide and dark, one portrait of the studio team. Crops are hard and full-bleed, allowed to bleed off the left or right edge and to sit behind type blocks. One hero image is treated as a physical artefact: a printed photograph with a visible paper edge and a hard drop shadow. No stock-smiling-couple clichés, no gradient blobs, no 3D renders, no illustration for its own sake.

Readable-text rule: Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. Imagery, decoration, and motion may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control. Moving and scrollable content may cross the viewport edge by design and is judged by whether it actually moves and whether every item becomes fully readable as it passes.

7. Signature Design Concept

The printed reservation card, on a poster.

The public entry is an asymmetric poster on warm paper ground (#F2EDE4). The left 7 columns carry a four-line Archivo Black headline at clamp(56px, 9vw, 128px) reading like a statement — "WE MAKE THE / ROOM WHERE / IT HAPPENS" — in ink black (#171512) with tight leading, the second line overprinted in accent red (#E2452A), and a hand-painted red underline stroke beneath the final word. Beneath it sits one line of Karla body copy and two square buttons: solid ink "Start a reservation" and outlined "See the portfolio". The right 5 columns hold a full-bleed golden-hour table photograph that bleeds off the right viewport edge and sits behind the headline's last line by 20px, with a rotated rubber-stamp rectangle reading "EST. 2014 · AVAILABLE 2026" in accent red at 14% opacity over its lower-left corner. A hairline ink rule carrying the studio's three service categories runs across the full viewport width under the hero. Nothing is centred; nothing floats on a gradient.

The concept carries through the whole product as one gesture: the reservation flow is set as a printed reservation card — square corners, 2px ink rules between label/value pairs, one accent-filled submit block — and the moment a request is submitted, a live "request received" stamp rotates in. The same stamp motif becomes the status chip on the client's own request list and on the studio's reservation ledger, so the public promise and the studio's back office speak the same visual language.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the full-bleed golden-hour table photograph bleeding off the right viewport edge, sitting behind the headline's final line, with the rotated rubber-stamp metadata rectangle over its lower-left corner.
• Input → transformation → outcome thesis: on load, the poster composes itself — the Archivo Black headline reveals word by word in 60ms steps, the accent-red overprint and hand-painted underline stroke resolve into place, and the photograph settles into its hard crop behind the type. The outcome is a composed first frame that reads as a printed poster, not a loading sequence. This uses only accepted content and controls; nothing new is introduced.
• Motion vocabulary: tactile and frame-based, not smooth. Entrance reveals snap in 120–180ms with a hard ease-out cubic-bezier(0.2, 0.9, 0.1, 1); no bounce, no float. Portfolio images swap on hover with a 200ms crossfade plus a 4px lift of the caption rule. Type reveals stagger by word in 60ms steps on the landing hero only, once, on load. A single marquee ticker of studio names and venues runs along one section boundary.
• Composed first frame: warm paper ground, oversized ink headline with one line in accent red and a hand-painted underline, one line of Karla body copy, two square buttons, the bleeding photograph with its stamp, and the hairline service-category rule — all resolved, nothing centred, nothing floating on a gradient.
• Reduced-motion state: under prefers-reduced-motion everything resolves instantly to its final state; the word stagger and the rotating stamp animation are removed, and the marquee ticker becomes a wrapped static row of whole items.

9. Non-Functional Requirements

• NFR-1 — Public reachability of the portfolio (explicit): Landing and Portfolio must be reachable without an account, so a prospective client can evaluate the studio before any commitment. Rationale: the portfolio's purpose is evaluation by people who have not yet enrolled.
• NFR-2 — Protected booking and studio work (required_inference): Booking, Portfolio Management, and Reservations must require verified identity, and a prospective client must see only their own submitted requests. Rationale: reservation requests are durable, person-bound commitments, and studio-side work must remain bound to the correct participant.
• NFR-3 — Anonymous access entry (required_inference): Sign Up and Login must be reachable without an existing session, since a protected destination cannot own the interaction that establishes access to itself.
• NFR-4 — Readable text and controls at every viewport (explicit, from the creative direction): 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, with no other element covering any part of them.
• NFR-5 — Reduced-motion support (explicit, from the creative direction): under prefers-reduced-motion, all motion resolves instantly to its final state and the marquee ticker becomes a wrapped static row of whole items.
• NFR-6 — Accent restraint (explicit, from the creative direction): accent red covers under 8% of any screen; no blue, indigo, or violet appears anywhere in the UI; no pure white grounds.
• NFR-7 — Backend integration (required_inference): the site requires backend integration to persist accounts, portfolio projects, and reservation requests, and to serve them consistently to both the public and studio sides.

10. Tech Stack

• Frontend: React — custom UI, single-page application with the page contract rendered as routes.
• Backend: Python / FastAPI — serves portfolio content, handles enrollment and verification, records reservation requests, and exposes studio-side portfolio and reservation operations.
• Storage: a relational database for accounts, portfolio projects, and reservation requests, with object storage for portfolio imagery.
• Containerization: Docker and docker-compose for local and single-host deployment.
• Kubernetes: not required by any stated constraint; omitted.

No source-specified technology was overridden; the stack above fills only what the user left unspecified.

11. Assumptions and Constraints

• A-1 (assumption): The studio's three service categories shown on the Landing rule are studio-authored content, maintained alongside the portfolio.
• A-2 (assumption): A reservation request is a request, not a confirmed booking; confirmation happens through the studio's review on Reservations.
• A-3 (assumption): The studio owner/coordinator is provisioned or invited rather than self-enrolling, since studio-management permissions must be bound to the correct person.
• A-4 (assumption): Portfolio imagery is supplied by the studio; the site does not generate or source photography.
• C-1 (constraint): The page inventory is fixed to Landing, Sign Up, Login, Portfolio, Booking, Portfolio Management, and Reservations, in that order, with the access states stated in section 2c.
• C-2 (constraint): The creative direction is authoritative for color, typography, shape, layout, imagery, and motion; the generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-3 (constraint): Payment processing, contract signing, chat or messaging, and external scheduling or calendar integrations are outside the current scope.
• C-4 (constraint): No future-horizon requirements were stated; nothing in this document is deferred.

12. Glossary

• Studio — the wedding and event studio that owns and operates this website.
• Portfolio project — one published piece of the studio's past work, carrying an image, a date, a venue, and a one-line studio note.
• Reservation request — a prospective client's submitted request to book the studio for their event, carrying event date, event type, venue or location, contact details, notes, submission timestamp, and status.
• Prospective Client — a person planning a wedding or event who browses the portfolio and submits a reservation request.
• Studio Owner/Coordinator — the studio-side person who maintains portfolio content and reviews incoming reservation requests.
• Stamp chip — the small rotated status marker used on reservation rows and on a client's own request list.
• Editorial run — the staggered two-column portfolio presentation with alternating full-bleed images and type-set caption blocks.