System Requirements Document for gemini-robot-computer

1. Introduction

gemini-robot-computer is a fundraising product built to raise money for a new idea: a Gemini robot — a robot whose face is a computer running Gemini. The product exists so that the idea can be presented publicly, its funding goal stated, and supporters given a way to contribute toward building it.

The audience is two-fold. The Campaign Creator (Jojo, 25, US) is the person behind the idea, who needs a place to describe the robot, set the funding goal, and watch whether the campaign is attracting support. The Supporter is an early adopter, AI-curious backer, or design/hardware enthusiast who reviews the idea, decides whether to contribute, and follows progress toward the goal.

The product is a crowdfunding surface for one speculative consumer robotics idea, not a general marketplace, not a store, and not a robot control application. Its job is to make the Gemini robot idea legible and credible, and to convert that credibility into contributions.

2. System Overview

The system is a web application with a public-facing campaign surface and a protected creator workspace.

Current delivery. A public Landing page introduces the fundraising product and the Gemini robot idea. A public Campaign page presents the idea, its funding goal, and live progress, and accepts supporter contributions. A protected Campaign Setup workspace lets the Campaign Creator write and maintain the campaign description and funding goal. Sign Up provides self-service enrollment for the Campaign Creator, and Login provides returning verification so the creator can resume campaign management.

Actors. The accepted active human personas are the Campaign Creator and the Supporter. Payment processing for contributions is handled by an external payment provider; the application does not own card data.

Accepted behavior. Raising money to fund the Gemini robot idea; presenting the idea and its funding goal so supporters can contribute; self-service enrollment for the creator; returning verification to resume campaign management; public campaign access for supporters to review the idea, contribute, and view funding progress.

Narrow exclusions. The product does not build, simulate, control, or ship the robot itself. It does not provide robot telemetry, firmware, or device management. It does not provide social networking, messaging between supporters, or creator payout accounting beyond the funding progress shown on the campaign.

2a. Product Interpretation and Delivery Boundary

The delivery boundary is a first-party web application. The application owns the campaign content, the funding goal, the contribution record, and the funding progress shown to supporters. The application owns identity for the Campaign Creator, because the creator must privately own and resume durable campaign state across sessions, and because contributions must remain bound to the correct campaign.

The Landing and Campaign pages are publicly reachable without identity. Sign Up and Login are anonymously reachable entry surfaces — a protected destination cannot own the interaction that establishes access to itself. Campaign Setup is protected and requires an established creator identity.

Payment authorization and capture for contributions are owned by an external payment provider. The application records the resulting contribution and reflects it in funding progress; it does not store card numbers.

Current horizon: the five pages above and the contribution lifecycle. Future horizon: nothing in this document is committed beyond the current horizon; any expansion of the robot idea into an actual product line, hardware pre-order fulfillment, or backer reward tiers is out of scope for this generation.

2b. Source Content Inventory

No reference directive in this project declares content_source. No source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous first impression. Explains the fundraising product and introduces the Gemini robot idea before any identity establishment or protected work. Shows the headline, a short statement of what the campaign is for, and the current funding position as a live funding arc.
• Primary actions. Navigate to the Campaign page to review the idea and contribute. Navigate to Sign Up to begin creating a campaign. Navigate to Login for returning creators.
• Supporting actions. Scroll through the narrative sections that introduce the idea.
• Domain entities. Campaign (public summary), funding goal, amount raised, backer count.
• Component responsibilities. Immersive hero holding the headline and the live funding arc with raised amount, goal, and a "Back this build" capsule CTA; narrative sections describing the idea; curved section boundaries and 12° diagonal flow lines; navigation to Campaign, Sign Up, and Login.
• States. Loading: hero and funding arc render in a composed first frame while campaign summary resolves. Empty: if no campaign has been published yet, the hero still renders and the funding arc shows a zero-raised state with the goal unset, and the Campaign link is presented as not yet available. Success: campaign summary and funding arc render at their current values. Error: if the campaign summary cannot be retrieved, the hero renders with a static layered composition and a retry affordance; navigation to Campaign, Sign Up, and Login remains usable. Recovery: retry re-requests the campaign summary without leaving the page.

Login

• Information and state. Anonymous identity access surface for returning verification. Single-column, centered on a pearl-on-charcoal plate with the curved boundary arcing behind the form.
• Primary actions. Submit credentials to verify identity and resume protected campaign management.
• Supporting actions. Navigate to Sign Up if the visitor does not yet have an identity. Return to Landing.
• Domain entities. Creator identity (email and credential).
• Component responsibilities. Credential form; submit control; inline validation messaging; link to Sign Up.
• States. Loading: submit control shows a pending state and the form is not double-submittable. Empty: form renders with empty fields and no error. Success: identity is verified and the creator is taken to Campaign Setup. Error: invalid credentials produce an inline message that does not disclose which field was wrong; the form remains filled except the credential. Recovery: the creator can correct and resubmit, or navigate to Sign Up.

Sign Up

• Information and state. Anonymous self-service enrollment for the Campaign Creator, who independently begins creating and managing the durable fundraising campaign. Single-column, centered on a pearl-on-charcoal plate with the curved boundary arcing behind the form.
• Primary actions. Submit enrollment details to establish a creator identity.
• Supporting actions. Navigate to Login if an identity already exists. Return to Landing.
• Domain entities. Creator identity (email and credential).
• Component responsibilities. Enrollment form; submit control; inline validation messaging; link to Login.
• States. Loading: submit control shows a pending state and the form is not double-submittable. Empty: form renders with empty fields and no error. Success: identity is established and the creator is taken to Campaign Setup to begin the campaign. Error: an already-enrolled email produces an inline message directing the creator to Login; other validation failures are shown inline. Recovery: the creator can correct and resubmit, or navigate to Login.

Campaign

• Information and state. Public campaign destination. Presents the Gemini robot idea and its funding goal, accepts supporter contributions, and shows progress toward the goal. Uses a two-column asymmetric layout: a narrow metadata rail on the left carrying goal, backers, days left, and a risk note, and a flowing narrative column on the right. On mobile the rail collapses to a horizontal scrollable strip.
• Primary actions. Contribute toward the funding goal. Review the idea and its funding goal.
• Supporting actions. Read the narrative; read the risk note; view the funding arc and its raised amount, goal, and backer count.
• Domain entities. Campaign (description, funding goal, amount raised, backer count, days left, risk note), Contribution (amount, contributor, timestamp, status).
• Component responsibilities. Sticky contribution panel on desktop reusing the metadata rail; sweeping gold funding arc replacing a horizontal progress bar; contribution amount entry; contribute control; contribution confirmation and receipt state; narrative sections; curved section boundaries and 12° diagonal flow lines.
• States. Loading: the funding arc renders at its final value and the narrative skeleton resolves. Empty: a campaign with no contributions shows a zero-raised arc, a zero backer count, and the contribute control available. Success: a completed contribution updates the raised amount, the funding arc, and the backer count, and the supporter sees a confirmation with the contributed amount and the new progress. Error: a declined or failed payment shows an inline message with the reason category and leaves the amount entered so the supporter can retry; a campaign that cannot be retrieved shows a retry affordance. Recovery: retry the contribution with the same or a corrected amount; retry loading the campaign.

Campaign Setup

• Information and state. Protected creator workspace for creating and maintaining the fundraising campaign description and funding goal. Single-column, centered on a pearl-on-charcoal plate with the curved boundary arcing behind the form. Shows the current campaign state, including whether it is published and its current raised amount and backer count.
• Primary actions. Create or update the campaign description and funding goal. Publish the campaign so it becomes publicly visible on Campaign and Landing.
• Supporting actions. Review current funding progress; return to the public Campaign view.
• Domain entities. Campaign (description, funding goal, published state, amount raised, backer count, days left, risk note).
• Component responsibilities. Description editor; funding goal input; risk note input; publish control; current progress summary; validation messaging.
• States. Loading: the workspace shows a pending state while the creator's campaign resolves. Empty: a creator with no campaign yet sees an empty setup form ready for the first description and funding goal. Success: saved changes are confirmed and reflected on the public Campaign page; publishing makes the campaign publicly visible. Error: validation failures (missing description, non-positive or missing funding goal) are shown inline and block publishing; a save failure preserves the entered content and offers retry. Recovery: correct the field and resubmit; retry the save without losing entered content.

3. Functional Requirements

FR-1 — Raise money to fund the Gemini robot idea. (explicit) As a Campaign Creator, I should be able to raise money to fund a new idea — a Gemini robot capable of living in a robot with the face as a computer running Gemini — so that the idea can be built.

• Trigger/input: the creator has an idea and a funding target.
• Observable result: a published campaign exists with a stated funding goal and accumulating contributions.
• Access state: requires an established creator identity; the campaign is publicly visible once published.
• Failure/recovery: if the campaign cannot be published, the creator retains the entered content and can retry.
• Continuation: the creator monitors funding progress and updates the campaign as needed.

FR-2 — Present the Gemini robot idea and its funding goal so supporters can contribute. (explicit) As a Campaign Creator, I should be able to present the Gemini robot idea and its funding goal publicly so that supporters can contribute toward it.

• Trigger/input: the creator writes the campaign description and sets the funding goal.
• Observable result: the Campaign page shows the idea, the funding goal, and live progress; the Landing page introduces the idea.
• Access state: public, no identity required to view.
• Failure/recovery: if the campaign content cannot be retrieved, the public surface shows a retry affordance.
• Continuation: supporters proceed to contribute.

FR-3 — Self-service enrollment for the Campaign Creator before protected campaign setup. (required_inference) As a Campaign Creator, I should be able to enroll myself so that I can begin creating and managing my campaign.

• Trigger/input: the creator arrives at Sign Up without an identity.
• Observable result: a creator identity is established and the creator reaches Campaign Setup.
• Access state: Sign Up is anonymously reachable; protected state remains unavailable until identity is established.
• Failure/recovery: an already-enrolled email directs the creator to Login; other validation failures are shown inline and the form can be resubmitted.
• Continuation: the creator begins the campaign.

FR-4 — Returning verification for the Campaign Creator to resume campaign management. (required_inference) As a Campaign Creator, I should be able to verify my identity on return so that I can resume managing my campaign.

• Trigger/input: the creator arrives at Login with existing credentials.
• Observable result: identity is verified and the creator reaches Campaign Setup with their campaign state intact.
• Access state: Login is anonymously reachable; Campaign Setup requires the verified identity.
• Failure/recovery: invalid credentials produce an inline message without disclosing which field was wrong; the creator can correct and resubmit or navigate to Sign Up.
• Continuation: the creator resumes campaign management.

FR-5 — Public campaign access for supporters to review the idea, contribute, and view funding progress. (required_inference) As a Supporter, I should be able to review the Gemini robot idea, contribute toward its funding goal, and view funding progress, so that I can decide whether and how much to give.

• Trigger/input: the supporter opens the Campaign page and enters a contribution amount.
• Observable result: the contribution is recorded, the raised amount and funding arc update, and the backer count increases; the supporter sees a confirmation with the contributed amount and the new progress.
• Access state: public, no identity required to view or contribute.
• Failure/recovery: a declined or failed payment shows an inline message with the reason category and preserves the entered amount for retry.
• Continuation: the supporter can view the updated progress and contribute again.

FR-6 — Create and maintain the campaign description and funding goal. (required_inference) As a Campaign Creator, I should be able to create and maintain my campaign description and funding goal in a protected workspace so that the public campaign reflects my current intent.

• Trigger/input: the creator edits the description, funding goal, or risk note in Campaign Setup.
• Observable result: saved changes are confirmed and reflected on the public Campaign page.
• Access state: Campaign Setup is protected and requires an established creator identity.
• Failure/recovery: validation failures (missing description, non-positive or missing funding goal) are shown inline and block publishing; a save failure preserves entered content and offers retry.
• Continuation: the creator publishes or continues editing.

FR-7 — Publish the campaign so it becomes publicly visible. (required_inference) As a Campaign Creator, I should be able to publish my campaign so that supporters can find it and contribute.

• Trigger/input: the creator publishes from Campaign Setup once the description and funding goal are valid.
• Observable result: the campaign appears on Campaign and is introduced on Landing.
• Access state: requires an established creator identity.
• Failure/recovery: publishing is blocked with inline validation until the description and funding goal are valid.
• Continuation: the creator monitors funding progress.

FR-8 — View funding progress toward the goal. (required_inference) As a Supporter, I should be able to view funding progress toward the goal so that I can judge how close the campaign is to being funded.

• Trigger/input: the supporter opens Campaign or Landing.
• Observable result: the funding arc, raised amount, goal, backer count, and days left are shown.
• Access state: public.
• Failure/recovery: if progress cannot be retrieved, the arc renders at its last known or zero value with a retry affordance.
• Continuation: the supporter decides whether to contribute.

FR-9 — Track whether the campaign is attracting support toward the funding target. (required_inference) As a Campaign Creator, I should be able to track whether my campaign is attracting support toward the funding target so that I can judge whether the idea is gaining traction.

• Trigger/input: the creator opens Campaign Setup or the public Campaign page.
• Observable result: the creator sees the current raised amount, backer count, and progress toward the goal.
• Access state: the creator's own progress summary is behind the protected workspace; the public progress is visible on Campaign.
• Failure/recovery: if progress cannot be retrieved, the summary shows a retry affordance.
• Continuation: the creator updates the campaign description or goal if needed.

4. User Personas

Campaign Creator

Product context. The Campaign Creator is the person behind the Gemini robot idea — a robot capable of living in a robot body with the face as a computer running Gemini. They arrive with an idea and a funding target, and they need a place to state both credibly.

Primary goal. Raise money to fund the Gemini robot idea by presenting it publicly and converting interest into contributions.

Distinct accepted responsibilities. The creator is the only actor who writes the campaign description, sets the funding goal, sets the risk note, and publishes the campaign. The creator is also the only actor who tracks whether the campaign is attracting support toward the funding target from the protected workspace. This is authorship and stewardship work — it is not the same as reviewing or contributing.

Relevant inputs and decisions. The description of the Gemini robot idea; the funding goal amount; the risk note; the decision to publish; the decision to revise the description or goal as support accumulates.

Interactions with other accepted participants. The creator's published campaign is what the Supporter reviews and contributes to. The creator's progress summary reflects the Supporter's contributions. The creator does not interact with supporters directly in this product.

Observable success. A published campaign with a stated funding goal, a rising raised amount and backer count, and a funding arc that visibly approaches the goal.

Constraints. The creator must establish an identity before reaching the protected workspace, and must verify that identity on return to resume campaign management.

Supporter

Product context. The Supporter is an early adopter, AI-curious backer, or design and hardware enthusiast who encounters the Gemini robot idea on the public campaign surface. They are evaluating a speculative future object, not buying a finished product.

Primary goal. Decide whether to contribute toward funding the Gemini robot idea, and see how close the campaign is to its goal.

Distinct accepted responsibilities. The Supporter reviews the idea and its funding goal, decides on a contribution amount, completes the contribution, and views funding progress. The Supporter does not author or edit campaign content and does not have access to the protected workspace.

Relevant inputs and decisions. The campaign description, the funding goal, the current raised amount, the backer count, the days left, the risk note, and the contribution amount the supporter chooses to enter.

Interactions with other accepted participants. The Supporter's contribution is what moves the Campaign Creator's funding progress. The Supporter sees the aggregate result of other supporters' contributions through the raised amount and backer count.

Observable success. A confirmed contribution with the contributed amount and the updated progress toward the goal.

Constraints. No identity is required to review the idea, contribute, or view funding progress.

5. Core User Flows

Flow A — Campaign Creator enrolls and publishes the Gemini robot campaign

1. The Campaign Creator arrives at Landing without an identity and reads the introduction to the fundraising product and the Gemini robot idea.
2. The creator selects the path to begin a campaign and lands on Sign Up.
3. On Sign Up, the creator enters enrollment details and submits. The submit control shows a pending state and is not double-submittable.
4. If the email is already enrolled, the creator sees an inline message directing them to Login and follows it. Otherwise, a creator identity is established.
5. The creator arrives at Campaign Setup, which is protected and now reachable because identity is established. The workspace shows an empty setup form.
6. The creator writes the campaign description for the Gemini robot idea, sets the funding goal, and sets the risk note.
7. The creator submits. If the description is missing or the funding goal is non-positive or missing, inline validation blocks the save and the creator corrects the field and resubmits. If the save fails, the entered content is preserved and the creator retries.
8. On success, the saved changes are confirmed.
9. The creator publishes the campaign. Publishing makes the campaign publicly visible on Campaign and introduces it on Landing.
10. The creator continues to Flow C to track whether the campaign is attracting support.

Flow B — Supporter reviews the idea and contributes

1. The Supporter arrives at Landing or directly at Campaign. No identity is required.
2. On Campaign, the supporter reads the narrative describing the Gemini robot idea and reads the metadata rail: goal, backers, days left, and the risk note.
3. The supporter views the funding arc showing the raised amount against the goal. If progress cannot be retrieved, the arc renders at its last known or zero value with a retry affordance, and the supporter retries.
4. The supporter decides on a contribution amount and enters it in the sticky contribution panel on desktop, or in the collapsed horizontal rail on mobile.
5. The supporter selects the contribute control. The contribution is submitted to the external payment provider for authorization.
6. If the payment is declined or fails, the supporter sees an inline message with the reason category, the entered amount is preserved, and the supporter retries with the same or a corrected amount.
7. On success, the contribution is recorded, the raised amount and funding arc update, and the backer count increases.
8. The supporter sees a confirmation with the contributed amount and the new progress toward the goal.
9. The supporter can continue viewing the updated progress and contribute again.

Flow C — Campaign Creator tracks support toward the funding target

1. The Campaign Creator returns to the product and lands on Login.
2. The creator submits credentials. If they are invalid, an inline message appears that does not disclose which field was wrong, and the creator corrects and resubmits or navigates to Sign Up.
3. On success, identity is verified and the creator reaches Campaign Setup with their campaign state intact.
4. The workspace shows the current campaign state: whether it is published, the current raised amount, and the backer count.
5. The creator reviews progress toward the funding target. If progress cannot be retrieved, the summary shows a retry affordance and the creator retries.
6. If the creator judges the description or goal needs revision, they edit the description, funding goal, or risk note and save. Validation failures are shown inline and block publishing; a save failure preserves entered content and offers retry.
7. Saved changes are confirmed and reflected on the public Campaign page.
8. The creator returns to the public Campaign view to see the campaign as supporters see it.

Flow D — Supporter views funding progress without contributing

1. The Supporter arrives at Landing and reads the introduction to the Gemini robot idea and the current funding position shown in the live funding arc.
2. The supporter navigates to Campaign.
3. The supporter reads the narrative and the metadata rail, and views the funding arc, raised amount, goal, backer count, and days left.
4. If the campaign has no contributions yet, the supporter sees a zero-raised arc and a zero backer count, with the contribute control available.
5. The supporter leaves without contributing. No identity was required at any point.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Zaha Hadid, and the headline idea is fluid parametric grandeur for a machine that dreams — sweeping continuous surfaces, pearl-white shells, and frozen motion, so that the body and the screen read as one continuous form.

Mode. Dark mode.

Colour tokens by role.

Colour proportion. Roughly 70% charcoal, 20% pearl/silver, 8% surface panel, 2% gold. Body text sits on charcoal or on surface #161A1F, never on gold.

Typography.

• Headings: Jost, weights 200–300 at display sizes. Uppercase with 0.14em tracking for section eyebrows; sentence case for the giant hero line. Tight leading of 0.92 so the headline reads as a sculpted block. Weight contrast does the hierarchy work: 200 for the oversized hero, 500 for labels and numbers.
• Body: Manrope.
• Type scale: 1.5 modular — 128 / 88 / 64 / 42 / 28 / 18 / 16 desktop, clamping down to 48 / 40 / 32 / 24 / 18 / 16 / 15 at 375px.
• Hero headline: clamp(48px, 9vw, 128px).
• Funding figure: clamp(40px, 6vw, 88px) with tabular numerals.

Shape language. Continuous curvature everywhere. Section boundaries are elliptical arcs rather than straight rules. Cards have one large 48px radius and one small 8px radius on opposite corners, so no panel is a plain rectangle. The progress meter is a sweeping gold arc rather than a bar. Buttons are capsule or single-corner-cut shapes, never plain rounded rectangles. Diagonal flow lines at 12° cross section seams. No hard 90° corner anywhere except the thin 1px data rules.

Spacing rhythm. Generous negative space — 96px+ vertical rhythm on desktop, 56px on mobile. Nothing sits in a grid of identical cards.

Imagery style. One crafted real-time 3D subject: a pearl-white parametric robot head whose face is a curved emissive screen, rendered in Three.js / React Three Fiber with a soft studio environment and a subtle gold rim light. Supporting imagery is macro detail of the shell seam, a topographic line field derived from the robot's face curvature, and a single screen-glow close-up. No stock people, no flat clip art, no gradient blobs.

Forbidden. Blue or indigo primary buttons on white; gradient-blob heroes; floating glass cards; identical hover-lift card grids; Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body; straight 90° section rules and plain rectangular cards; bouncy or springy easing; stock photography of people, flat vector clip art, or cartoon robot illustrations; centred headline + subtext + CTA stacked in the middle of the hero; any second accent colour competing with the gold. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The gallery object. The public entry — Landing — opens as a full-bleed immersive hero. The pearl-white parametric robot head occupies the right 55% of the viewport, cropped by the bottom edge so it reads as an object in a gallery rather than an illustration. It rotates slowly on a 2° axis under a pearl-to-charcoal rim light with a subtle gold rim.

The left 45% holds a stacked, left-aligned headline set in Jost 200 at clamp(48px, 9vw, 128px) reading "A COMPUTER FOR A FACE. A ROBOT FOR A MIND." A single gold underline sweeps beneath the second line, animating in on first paint.

Beneath the headline, pinned left, sits the live funding arc — gold on charcoal — with the raised amount, the goal, and a pearl capsule "Back this build" CTA. A thin pearl rule arcs across the whole viewport at 12°, separating the hero from the next section.

The concept recomposes only accepted content and controls: the headline states the accepted idea, the funding arc states the accepted funding goal and progress, and the CTA leads to the accepted Campaign page. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Parallax Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

Focal subject. The pearl-white parametric robot head whose face is a curved emissive screen, occupying the right 55% of the viewport and cropped by the bottom edge.

Input → transformation → outcome thesis. As the visitor scrolls, the hero's curved seam slides upward while the funding arc fills toward its current value — the same continuous surface that defines the robot's shell also carries the campaign's progress. The outcome is that the visitor reads the idea and the funding position as one architectural object.

Motion vocabulary. One slow 40-second parallax drift of the hero shell layers; a scroll-linked morph where the hero's curved seam slides upward as the funding arc fills; 400ms cubic-bezier(0.22, 1, 0.36, 1) reveals for each section. No bounce, no particles, no cursor-chasing.

Composed first frame. The robot head is already present at its resting rotation, the headline is set and legible, the gold underline has swept in beneath the second line, and the funding arc renders at its current value with the raised amount, goal, and "Back this build" capsule CTA pinned left.

Reduced-motion state. Under prefers-reduced-motion, all parallax and morph stop. The hero becomes a static layered composition and the funding arc renders at its final value. The headline, funding figures, and CTA remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time object: a pearl-white parametric robot head whose face is a curved emissive screen, built in Three.js / React Three Fiber. The scene uses a soft studio environment with a subtle gold rim light. The head rotates slowly on a 2° axis and is cropped by the viewport edge. The defining state it shows is the product's core idea — a computer for a face, a robot for a mind — rendered as a real object rather than an illustration. Under reduced motion the object holds its resting rotation and the scene renders as a static layered composition.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport. (explicit, 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 (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control.

NFR-2 — Moving and scrollable content remains fully readable. (explicit, creative direction) Marquees, tickers, carousels, and horizontally scrollable rows may cross the viewport or container edge by design. Every item must become fully readable as it passes. Under prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view. The Campaign metadata rail's mobile horizontal scrollable strip follows this rule.

NFR-3 — Reduced-motion support. (explicit, creative direction) Under prefers-reduced-motion, all parallax and morph stop; the hero becomes a static layered composition and the funding arc renders at its final value.

NFR-4 — Durable campaign and contribution state. (required_inference) Campaign content, funding goal, published state, and recorded contributions persist across sessions so that the Campaign Creator can resume management and supporters see consistent progress.

NFR-5 — Identity continuity for the Campaign Creator. (required_inference) Creator identity is application-owned and persists across sessions so that the creator can resume campaign management and so that contributions remain bound to the correct campaign.

NFR-6 — Payment data is not stored by the application. (required_inference) Contribution authorization and capture are handled by an external payment provider. The application records the resulting contribution and reflects it in funding progress; it does not store card numbers.

NFR-7 — Public surfaces are reachable without identity. (explicit, planning scope) Landing and Campaign are reachable without identity. Sign Up and Login are anonymously reachable entry surfaces. Campaign Setup requires an established creator identity.

NFR-8 — No differentiated permissions beyond creator ownership. (required_inference) The only access distinction in this product is between public surfaces and the creator's own protected campaign workspace. No role-based visibility or permission controls over shared product state are established by the source.

10. Tech Stack

• Frontend: React, with React Three Fiber and Three.js for the real-time WebGL hero subject.
• Backend: Python / FastAPI, extending a single shared backend process for campaign, contribution, and identity routes.
• Storage: a relational database for creator identities, campaigns, and contributions.
• Payment: an external payment provider for contribution authorization and capture.
• Deployment: Docker and docker-compose for the application services.

11. Assumptions and Constraints

Assumptions.

• A1 (required_inference): The Campaign Creator is a single person raising funds for one campaign. Multi-campaign creator accounts are not established by the source.
• A2 (required_inference): Contributions are one-time amounts toward the funding goal. Recurring or tiered contributions are not established by the source.
• A3 (required_inference): The funding goal is a single monetary target. Stretch goals and milestone goals are not established by the source.
• A4 (required_inference): The risk note shown in the metadata rail is authored by the Campaign Creator as part of campaign setup.
• A5 (required_inference): "Days left" is derived from a campaign duration; the source does not specify how the duration is set, so it is treated as part of campaign setup.

Constraints.

• C1 (explicit): The product exists to raise money to fund a new idea — a Gemini robot capable of living in a robot with the face as a computer running Gemini.
• C2 (explicit): The product must present the Gemini robot idea and its funding goal so supporters can contribute toward it.
• C3 (explicit, creative direction): The palette, typography, shape language, layout, motion, and imagery in Section 6 are binding. The generic indigo/blue-on-white SaaS template is forbidden.
• C4 (explicit, creative direction): Readable text and controls stay whole at every viewport; imagery and decoration carry any cropping gesture.
• C5 (explicit, planning scope): The page contract is Landing, Login, Sign Up, Campaign, Campaign Setup — exactly these five, in this order, with these access surfaces.
• C6 (explicit, planning scope): The active human personas are exactly Campaign Creator and Supporter.
• C7 (explicit): The product does not build, simulate, control, or ship the robot itself, and does not provide robot telemetry, firmware, or device management.

12. Glossary

• Gemini robot — the speculative consumer robotics product being funded: a robot capable of living in a robot body whose face is a computer running Gemini.
• Campaign — the fundraising effort for the Gemini robot idea, comprising a description, a funding goal, a risk note, a published state, and accumulated contributions.
• Campaign Creator — the accepted persona who authors, publishes, and tracks the campaign.
• Supporter — the accepted persona who reviews the idea, contributes, and views funding progress.
• Funding goal — the monetary target the campaign is raising toward.
• Funding arc — the sweeping gold arc that replaces a horizontal progress bar and shows raised amount against the funding goal.
• Contribution — a one-time monetary amount given by a Supporter toward the funding goal, authorized and captured by the external payment provider and recorded by the application.
• Metadata rail — the narrow charcoal column on the Campaign page carrying goal, backers, days left, and the risk note; sticky on desktop, collapsing to a horizontal scrollable strip on mobile.
• Risk note — the creator-authored statement of risk shown in the metadata rail.
• Backer — a Supporter who has completed a contribution; counted in the backer count.
• Protected workspace — Campaign Setup, reachable only with an established creator identity.