System Requirements Document for 3d-developer-portfolio

1. Introduction

This document specifies the requirements for 3d-developer-portfolio, a premium, highly interactive 3D developer portfolio website for Harsh Patel, a Full Stack Developer based in India. The product is not a conventional scrolling website: it is an explorable 3D environment built around a realistic modern PC/gaming workstation, where the objects on the desk act as the primary navigation points into the portfolio's content.

The product intent is to present Harsh Patel as a serious, capable Full Stack Developer through a workspace that a visitor can actually walk into and explore — "a developer's digital workspace that you can actually explore." The 3D workstation is the storytelling mechanism; the portfolio content (resume, projects, skills, contact, about, experience, and an optional personal section) is the substance. The experience must immediately communicate professional credibility while remaining usable, performant, and accessible to visitors who do not want to explore a 3D scene.

The audience is the Portfolio Visitor — recruiters, hiring managers, and peer developers evaluating Harsh Patel for developer roles — and the Portfolio Owner (Harsh Patel) himself, who maintains the portfolio and replaces placeholder content with real information through centralized data structures.

2. System Overview

The system is a single-page, full-bleed 3D web experience. On load, a premium loading screen displays HARSH PATEL and Initializing workspace... with an animated loading indicator while the 3D workstation and its assets load. Once ready, the experience transitions smoothly into the complete 3D workstation, presented from a cinematic camera view of the desk, with a minimal introduction ("Hi, I'm Harsh Patel", "Full Stack Developer", a short description, and the instruction "Explore the workspace to discover my portfolio.") and a small animated cursor/interaction indicator showing that objects are clickable.

The workstation contains a modern computer desk/table, desktop monitor, PC cabinet, keyboard, mouse, headphones, desk lamp, smartphone, notebook, coffee mug, speakers, gaming/controller elements, office chair, small decorative objects, and other subtle workspace details. The scene is rendered with high-quality 3D: realistic lighting, soft shadows, ambient lighting, reflections, depth of field, subtle bloom, realistic materials, smooth camera movement, natural object animations, and professional environment lighting — never a low-quality cartoon look.

Interactive objects act as navigation points. Clicking an object detects the click/hover, highlights the object, moves the camera smoothly toward it (never teleporting), and opens the corresponding portfolio section. A persistent "Back to Workspace" button returns the visitor to the main workspace. A simple navigation menu provides direct access to Home, About, Skills, Projects, Experience, Resume, and Contact for visitors who do not want to explore the 3D environment.

Actors. The accepted active-human catalog is closed to two personas: the Portfolio Visitor (recruiter, hiring manager, or peer developer) and the Portfolio Owner (Harsh Patel). No other human personas are introduced.

Ownership. All seven destinations (Home, About, Skills, Projects, Experience, Resume, Contact) are first-party application pages, publicly accessible with no access requirement. The 3D scene, UI, portfolio data, and navigation logic are separated in the architecture.

Narrow exclusions. The 3D environment must not be the only way to navigate the website. The camera must not instantly teleport. Portfolio content must not be hard-coded throughout individual components. Animations must not be overdone, and effects must not make the site feel like a gaming website. The 3D scene must not look like a low-quality cartoon. Usability must not be sacrificed on mobile to preserve the exact desktop experience. The resume must open without forcing the visitor to leave the portfolio. The "Behind the Code" coffee mug section is optional and must remain visually lightweight. Easter eggs must be optional and tasteful.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a first-party web application — a custom React-based front end rendering a Three.js/React Three Fiber 3D scene with a layered HTML/CSS UI. There is no provider-owned or external-only surface for the portfolio itself; the 3D workspace and all seven portfolio sections are owned and rendered by the application.

Access. All seven pages are public and require no identity, account, or sign-in. The Portfolio Visitor arrives anonymously and can immediately explore the workspace or use the visible navigation. No application-owned identity, session continuity, or account management is required or introduced, because no accepted journey requires a visitor to privately own, resume, or be bound to durable actor-specific state. The Portfolio Owner's maintenance work is performed by editing the centralized data structures in the codebase, not through an in-product authenticated surface.

Current vs. future. Everything specified in this document is current. No future-horizon requirements were accepted. The "Behind the Code" section is current but explicitly optional and visually lightweight; Easter eggs are current but explicitly optional and tasteful.

2b. Source Content Inventory

No reference directive with content_source authority was supplied. This section is intentionally omitted.

2c. Page Content and Component Coverage

The page inventory is the closed, ordered contract: Home, About, Skills, Projects, Experience, Resume, Contact. Each page is public with no access requirement.

Home

• Information/state: The full-bleed 3D workstation scene; the cinematic desk view; the introduction lockup ("Hi, I'm Harsh Patel", "Full Stack Developer", short description, "Explore the workspace to discover my portfolio."); the animated cursor/interaction indicator; the persistent "Back to Workspace" button; the visible navigation menu (Home, About, Skills, Projects, Experience, Resume, Contact); the loading screen state.
• Primary actions: Explore the workspace by hovering and clicking interactive objects; use the visible navigation menu to jump directly to any section; return to the workspace via "Back to Workspace".
• Supporting actions: Hover an object to see its highlight, lift, cursor change, and tooltip; trigger Easter eggs by exploring carefully.
• Domain entities: Workspace objects (desk, monitor, PC cabinet, keyboard, mouse, headphones, desk lamp, smartphone, notebook, coffee mug, speakers, gaming/controller elements, office chair, decorative objects); portfolio data (personal info, skills, projects, experience, education, social links, resume URL).
• Component responsibilities: 3D scene renderer and camera controller; object interaction/hover system; tooltip system; navigation menu; introduction overlay; loading screen; "Back to Workspace" control; Easter egg handlers.
• States: Loading — premium loading screen with "HARSH PATEL", Initializing workspace..., animated indicator. Empty — not applicable (scene is always populated). Success — scene loaded, introduction shown, objects interactive. Error/recovery — lightweight fallback/loading experience if 3D assets fail or the device cannot render the full scene; visible navigation remains usable.

About

• Information/state: Short introduction; education; developer journey; interests; career goals. Presented with subtle animations rather than a large block of text.
• Primary actions: Read the About content; navigate away via the menu or "Back to Workspace".
• Supporting actions: Hover/scroll to reveal animated content blocks.
• Domain entities: Personal information; education entries; developer journey narrative; interests; career goals.
• Component responsibilities: Animated content blocks; section panel; navigation.
• States: Loading — panel content resolves from centralized data. Empty — placeholder content shown until the owner replaces it. Success — content displayed with subtle animations. Error/recovery — if data is missing, the section renders gracefully with placeholders and navigation remains available.

Skills

• Information/state: Technologies including JavaScript, React.js, Node.js, Express.js, MongoDB, HTML, CSS, Tailwind CSS, Git/GitHub, SQL, and other relevant technologies, displayed via interactive skill cards, floating 3D elements, or an animated technology wall.
• Primary actions: Browse and interact with skill cards/elements; navigate away.
• Supporting actions: Hover skill cards for emphasis; keyboard backlight ripple on Skills open.
• Domain entities: Skill entries (name, category, proficiency where applicable).
• Component responsibilities: Skill card grid / floating 3D elements / animated technology wall; section panel; navigation.
• States: Loading — skills resolve from centralized data. Empty — placeholder skills shown until replaced. Success — skills displayed interactively. Error/recovery — graceful placeholder rendering; navigation remains available.

Projects

• Information/state: Major projects as interactive cards. Each project card contains project name, description, technologies used, GitHub link, live demo link, and screenshots/preview. Example projects include Paver Manufacturing ERP, Internship Platform, Fitness Tracking Application, Learning Management System using Generative AI, and other relevant projects. Each project also carries a project image, project title, short description, full description, tech stack, features, GitHub button, and live demo button.
• Primary actions: Browse project cards; open a project's GitHub link; open a project's live demo link; view screenshots/preview; navigate away.
• Supporting actions: Hover project cards for interactive polish; PC RGB/fan lighting activates while the Projects interface is open.
• Domain entities: Project entries (image, title, short description, full description, tech stack, features, GitHub URL, live demo URL, screenshots).
• Component responsibilities: Project card grid; project detail view; external link buttons; section panel; navigation.
• States: Loading — projects resolve from centralized data. Empty — placeholder projects shown until replaced. Success — cards displayed and interactive. Error/recovery — if a link or image is missing, the card renders without it and navigation remains available.

Experience

• Information/state: Internship/company, role, duration, responsibilities, technologies used, and major work/projects, presented as an interactive timeline.
• Primary actions: Explore the timeline; expand timeline entries; navigate away.
• Supporting actions: Hover/scroll timeline interactions.
• Domain entities: Experience entries (company, role, duration, responsibilities, technologies, major work/projects).
• Component responsibilities: Interactive timeline; section panel; navigation.
• States: Loading — experience resolves from centralized data. Empty — placeholder experience shown until replaced. Success — timeline displayed and interactive. Error/recovery — graceful placeholder rendering; navigation remains available.

Resume

• Information/state: The resume/CV displayed in-portfolio, with interactive resume viewing and a Download Resume button. The resume opens without forcing the visitor to leave the portfolio.
• Primary actions: View the resume interactively; download the resume; navigate away.
• Supporting actions: Monitor boot animation (amber scanline reveal) when the Resume section is opened via the monitor.
• Domain entities: Resume URL; resume document.
• Component responsibilities: In-portfolio resume viewer; download button; section panel; navigation.
• States: Loading — resume document resolves from the centralized resume URL. Empty — placeholder resume shown until replaced. Success — resume displayed in-portfolio; download available. Error/recovery — if the resume fails to load, a clear message and the download option remain available; navigation remains available.

Contact

• Information/state: Email, LinkedIn, GitHub, phone/contact option, and a contact form, styled to look like an actual smartphone interface.
• Primary actions: Send a message via the contact form; open email; open LinkedIn; open GitHub; use the phone/contact option; navigate away.
• Supporting actions: Smartphone-interface interactions.
• Domain entities: Contact channels (email, LinkedIn, GitHub, phone); contact form fields.
• Component responsibilities: Smartphone-style UI shell; contact channel links; contact form; section panel; navigation.
• States: Loading — contact data resolves from centralized data. Empty — placeholder contact data shown until replaced. Success — form submitted confirmation; channel links open. Error/recovery — if the form submission fails, a clear error is shown and the visitor can retry; navigation remains available.

3. Functional Requirements

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

FR-1 — Explorable 3D workstation (explicit). As a Portfolio Visitor, I should land on a premium, highly interactive 3D developer portfolio website centered on a realistic modern PC/gaming workstation environment rather than a traditional website layout, so that I immediately experience the portfolio as an explorable space. Lifecycle: Trigger — page load. Observable result — the 3D workstation is presented. Failure/recovery — lightweight fallback/loading experience. Continuation — the visitor explores or uses navigation.

FR-2 — Complete workspace object set (explicit). As a Portfolio Visitor, I should see a 3D workspace containing a modern computer desk/table, desktop monitor, PC cabinet, keyboard, mouse, headphones, desk lamp, smartphone, notebook, coffee mug, speakers, gaming/controller elements, office chair, small decorative objects, and other subtle workspace details, so that the workspace feels complete and realistic. Lifecycle: Trigger — scene load. Observable result — all listed objects are present in the scene.

FR-3 — Professional, modern, minimal, slightly futuristic look (explicit). As a Portfolio Visitor, I should see a workspace that looks professional, modern, minimal, and slightly futuristic, suitable for a Full Stack / Software Developer portfolio, so that the environment communicates seriousness and craft.

FR-4 — Object interaction as navigation (explicit). As a Portfolio Visitor, I should be able to explore the workspace and interact with individual objects, with every important object serving a meaningful portfolio purpose as an interactive navigation point, so that exploration is purposeful.

FR-5 — Monitor → Resume (explicit). As a Portfolio Visitor, when I click the monitor, I should see a smooth camera transition toward the monitor, the monitor screen turn on, my resume/CV displayed inside the monitor, the ability to view and download the resume, and a clear "Back to Workspace" interaction. Lifecycle: Trigger — click on monitor. Observable result — camera moves smoothly, screen turns on, resume displayed in-monitor; download available; "Back to Workspace" available. Failure/recovery — if the resume fails to load, a clear message and download option remain. Continuation — return to workspace or navigate elsewhere.

FR-6 — PC cabinet → Projects (explicit). As a Portfolio Visitor, when I click the PC cabinet, I should see the camera move smoothly toward the PC, RGB/fan lighting activate, and a Projects interface open displaying major projects as interactive cards. Lifecycle: Trigger — click on PC cabinet. Observable result — camera moves, RGB/fan lighting activates, Projects interface opens. Continuation — browse projects or return to workspace.

FR-7 — Project card contents (explicit). As a Portfolio Visitor, I should see each project card contain project name, description, technologies used, GitHub link, live demo link, and screenshots/preview, so that I can evaluate each project fully.

FR-8 — Keyboard → Skills (explicit). As a Portfolio Visitor, when I click the keyboard, I should see the Skills section open, displaying technologies including JavaScript, React.js, Node.js, Express.js, MongoDB, HTML, CSS, Tailwind CSS, Git/GitHub, SQL, and other relevant technologies using interactive skill cards, floating 3D elements, or an animated technology wall. Lifecycle: Trigger — click on keyboard. Observable result — Skills section opens with the listed technologies displayed interactively. Continuation — browse skills or return to workspace.

FR-9 — Smartphone → Contact (explicit). As a Portfolio Visitor, when I click the smartphone, I should see the Contact Me section open with email, LinkedIn, GitHub, phone/contact option, and a contact form, styled to look like an actual smartphone interface. Lifecycle: Trigger — click on smartphone. Observable result — Contact section opens in a smartphone-style UI. Failure/recovery — if form submission fails, a clear error is shown and retry is possible. Continuation — send a message or return to workspace.

FR-10 — Headphones → About Me (explicit). As a Portfolio Visitor, when I click the headphones, I should see an About Me section showing a short introduction, education, developer journey, interests, and career goals, using subtle animations rather than a large block of text. Lifecycle: Trigger — click on headphones. Observable result — About section opens with animated content. Continuation — read or return to workspace.

FR-11 — Notebook → Experience (explicit). As a Portfolio Visitor, when I click the notebook, I should see the Experience / Internship section displaying internship/company, role, duration, responsibilities, technologies used, and major work/projects, presented as an interactive timeline. Lifecycle: Trigger — click on notebook. Observable result — Experience section opens as an interactive timeline. Continuation — explore timeline or return to workspace.

FR-12 — Coffee mug → Behind the Code (explicit, optional). As a Portfolio Visitor, when I click the coffee mug, I may see a small "Behind the Code" section containing developer philosophy, interests, fun facts, and coding habits; this section is optional and visually lightweight. Lifecycle: Trigger — click on coffee mug. Observable result — optional lightweight section opens. Continuation — read or return to workspace.

FR-13 — Landing experience (explicit). As a Portfolio Visitor, on initial load I should see the complete 3D workstation with a cinematic camera view of the desk and a minimal introduction: "Hi, I'm Harsh Patel", "Full Stack Developer", a short description, and the instruction "Explore the workspace to discover my portfolio.", plus a small animated cursor/interaction indicator showing that objects are clickable. Lifecycle: Trigger — initial load. Observable result — cinematic desk view, introduction lockup, and interaction indicator are shown.

FR-14 — High-quality 3D rendering (explicit). As a Portfolio Visitor, I should experience high-quality 3D rendering with realistic lighting, soft shadows, ambient lighting, reflections, depth of field, subtle bloom, realistic materials, smooth camera movement, natural object animations, and professional environment lighting, and the scene should not look like a low-quality cartoon.

FR-15 — Smooth cinematic camera transitions (explicit). As a Portfolio Visitor, when I select an object, the system should detect the click/hover, highlight the object, move the camera smoothly toward it, open the corresponding portfolio section, and allow me to return to the main workspace; the camera must not instantly teleport, and must use smooth easing and subtle animation. Lifecycle: Trigger — object selection. Observable result — highlight, smooth camera move, section opens. Continuation — return to workspace.

FR-16 — Persistent "Back to Workspace" button (explicit). As a Portfolio Visitor, I should have a persistent "Back to Workspace" button so that I can always return to the main workspace.

FR-17 — Direct navigation menu (explicit). As a Portfolio Visitor, I should have a simple navigation menu allowing me to directly access Home, About, Skills, Projects, Experience, Resume, and Contact without exploring the 3D environment.

FR-18 — Object hover effects (explicit). As a Portfolio Visitor, every interactive object should respond to hover with effects such as slight glow, outline/highlight, small floating animation, cursor change, and a tooltip showing what the object does (e.g., Monitor "View Resume →", PC "Explore Projects →", Keyboard "View Skills →"), without overdoing the animations.

FR-19 — Clean modern layered UI (explicit). As a Portfolio Visitor, I should see a clean modern UI layered over the 3D environment with a dark theme, black/charcoal background, subtle glassmorphism, minimal white typography, a small accent color, thin borders, soft shadows, and premium spacing, complementing rather than covering the 3D environment.

FR-20 — Centralized data structures (explicit). As a Portfolio Owner, I should have centralized data structures for personal information, skills, projects, experience, education, social links, and resume URL, with placeholder content initially, so that I can easily replace it with my actual information without hard-coding portfolio content throughout individual components.

FR-21 — Premium project showcase (explicit). As a Portfolio Visitor, I should see a premium project showcase where each project has a project image, project title, short description, full description, tech stack, features, GitHub button, and live demo button, with interactive and visually polished project cards.

FR-22 — Example projects (explicit). As a Portfolio Visitor, I should see example projects including Paver Manufacturing ERP, Internship Platform, Fitness Tracking Application, Learning Management System using Generative AI, and other relevant projects.

FR-23 — Resume viewing and download (explicit). As a Portfolio Visitor, I should have both interactive resume viewing and a Download Resume button, with the resume opening without forcing me to leave the portfolio.

FR-24 — Responsiveness (explicit). As a Portfolio Visitor, the website should work properly on desktop, laptop, tablet, and mobile; on mobile devices the 3D environment may be simplified for performance, but usability must not be sacrificed to preserve the exact desktop experience.

FR-25 — Performance optimization (explicit). As a Portfolio Visitor, the website should be heavily optimized: lazy-load 3D assets, compress textures, optimize models, avoid unnecessary high-poly objects, use efficient lighting, prevent excessive animations, maintain smooth scrolling and interaction, and provide a lightweight fallback/loading experience, targeting a smooth experience rather than simply adding visual effects.

FR-26 — Premium loading screen (explicit). As a Portfolio Visitor, I should see a premium loading screen while the 3D scene loads, showing "HARSH PATEL" and Initializing workspace... with an animated loading indicator, then transition smoothly into the workspace once everything is ready. Lifecycle: Trigger — initial load. Observable result — loading screen shown, then smooth transition into the workspace. Failure/recovery — lightweight fallback/loading experience if assets fail.

FR-27 — Subtle professional microinteractions (explicit). As a Portfolio Visitor, I should experience subtle professional microinteractions: button hover animations, smooth page transitions, object hover effects, camera easing, screen animations, PC RGB animation, keyboard lighting, monitor boot animation, subtle particle effects, and ambient workspace movement, without excessive effects that make the website feel like a gaming website.

FR-28 — Subtle Easter eggs (explicit, optional). As a Portfolio Visitor, I should be able to discover a few subtle, optional, tasteful Easter eggs for users who explore carefully, such as clicking a hidden object to reveal a developer joke, clicking the PC multiple times to trigger a small animation, and keyboard interaction triggering a typing animation.

FR-29 — Modern stack and clean architecture (explicit). As a Portfolio Owner, I should have the project built with a modern stack such as React, Three.js, React Three Fiber, Drei, GSAP or Framer Motion, and Tailwind CSS, with reusable components and clean architecture using a structure like components/3d/, components/ui/, components/sections/, data/, assets/, and hooks/, keeping the 3D scene, UI, portfolio data, and navigation logic separated.

FR-30 — 3D is not the only navigation (explicit). As a Portfolio Visitor, the 3D environment must not be the only way to navigate the website: I should have visible navigation, tooltips, hover states, clear interaction hints, keyboard-accessible navigation, and mobile-friendly navigation, so the site feels like an interactive experience rather than a gimmick.

FR-31 — Overall goal (explicit). As a Portfolio Visitor, the final result should feel like "A developer's digital workspace that you can actually explore", immediately communicating that the owner is a serious developer, and be polished enough to use as an actual professional portfolio for developer job applications.

FR-32 — Prioritization (explicit). As a Portfolio Owner, the product should prioritize premium design, usability, performance, and meaningful interactions over simply adding more 3D effects.

FR-33 — Asset load gating (required_inference). As a Portfolio Visitor, the 3D workstation and its assets must load before the interactive workspace is presented, so that the accepted journey is executable. Lifecycle: Trigger — initial load. Observable result — loading screen until assets are ready, then workspace. Failure/recovery — lightweight fallback/loading experience.

FR-34 — Non-3D navigation path (required_inference). As a Portfolio Visitor, I must be able to use visible navigation, keyboard-accessible controls, and mobile-friendly controls without relying exclusively on 3D object discovery, so that the accepted journey is executable for visitors who do not understand that objects are clickable.

FR-35 — Owner content replacement (required_inference). As a Portfolio Owner, portfolio content must be supplied through centralized data structures so that I can replace placeholder information without editing individual components, so that the accepted maintenance journey is executable.

4. User Personas

Portfolio Visitor

Product context. A recruiter, hiring manager, or peer developer who lands on the site to evaluate Harsh Patel as a Full Stack Developer. They may arrive from a job application, a link, or a referral, and they may be on a desktop, laptop, tablet, or mobile device. They have limited time and may or may not be interested in exploring a 3D environment.

Primary goal. Understand Harsh Patel's skills, projects, experience, and contact options quickly and confidently, without being forced to rely on the 3D environment.

Distinct accepted responsibilities. The Portfolio Visitor explores the 3D workstation by hovering and clicking objects (monitor, PC cabinet, keyboard, smartphone, headphones, notebook, coffee mug) or uses the visible navigation menu to reach Home, About, Skills, Projects, Experience, Resume, and Contact, then returns to the workspace via the persistent "Back to Workspace" button. They evaluate project cards (name, description, technologies, GitHub link, live demo link, screenshots/preview), read the resume in-portfolio and download it, review the interactive experience timeline, read the animated About content, browse the Skills display, use the smartphone-style Contact interface and contact form, and optionally discover the lightweight "Behind the Code" section and subtle Easter eggs.

Relevant inputs or decisions. Which object to click or which navigation item to choose; whether to view or download the resume; whether to open a project's GitHub or live demo link; whether to submit the contact form; whether to explore further or leave.

Interactions with other accepted participants. The Portfolio Visitor interacts with the Portfolio Owner's content (personal information, skills, projects, experience, education, social links, resume) but does not interact with the owner directly in-product. The contact form is the visitor's channel to the owner.

Observable success. The visitor understands the developer's skills, projects, experience, and contact options, and can act on them (download the resume, open project links, send a message) without being blocked by the 3D environment.

What makes this role different. The visitor is a time-constrained evaluator, not a maintainer. Their work is discovery and judgment under uncertainty about how the interface behaves; the product must make the 3D exploration optional and the content immediately reachable.

Portfolio Owner (Harsh Patel)

Product context. The developer who owns and maintains the portfolio. He is a Full Stack Developer based in India, presenting himself for developer job applications. He works in the codebase, not through an authenticated in-product surface.

Primary goal. Maintain a polished, professional portfolio he can use in job applications and keep current by updating centralized data.

Distinct accepted responsibilities. The owner replaces placeholder content with real personal information, skills, projects, experience, education, social links, and resume URL through centralized data structures rather than editing individual components. He curates the example projects (Paver Manufacturing ERP, Internship Platform, Fitness Tracking Application, Learning Management System using Generative AI, and other relevant projects) and keeps the resume URL current.

Relevant inputs or decisions. What content to publish; which projects to feature; which social links and resume URL to use; when to update the data.

Interactions with other accepted participants. The owner supplies the content that the Portfolio Visitor consumes. The contact form delivers visitor messages to the owner's contact channels.

Observable success. A polished, professional portfolio that stands out during developer job applications and can be kept current by editing the centralized data.

What makes this role different. The owner's work is authoring and maintenance, not consumption. His success is measured by the portfolio's professional impact and its maintainability, not by navigating the 3D scene.

5. Core User Flows

Flow 1 — Portfolio Visitor: First arrival and cinematic landing

1. The Portfolio Visitor opens the site on a desktop, laptop, tablet, or mobile device.
2. The premium loading screen appears, showing HARSH PATEL and Initializing workspace... with an animated loading indicator while the 3D workstation and its assets load (FR-26, FR-33).
3. Once everything is ready, the experience transitions smoothly into the workspace.
4. The complete 3D workstation is shown from a cinematic camera view of the desk, with the minimal introduction "Hi, I'm Harsh Patel", "Full Stack Developer", a short description, and the instruction "Explore the workspace to discover my portfolio.", plus a small animated cursor/interaction indicator showing that objects are clickable (FR-13).
5. Failure/recovery: if the 3D assets fail to load or the device cannot render the full scene, a lightweight fallback/loading experience is shown and the visible navigation remains usable (FR-25, FR-30).
6. Continuation: the visitor explores the workspace (Flow 2) or uses the navigation menu (Flow 3).

Flow 2 — Portfolio Visitor: Exploring the workspace by object

1. From the workspace, the Portfolio Visitor moves the cursor over an interactive object.
2. The object responds to hover with a slight glow, outline/highlight, small floating animation, cursor change, and a tooltip showing what the object does (e.g., Monitor "View Resume →", PC "Explore Projects →", Keyboard "View Skills →"), without overdoing the animations (FR-18).
3. The visitor clicks the object.
4. The system detects the click, highlights the object, and moves the camera smoothly toward it — never instantly teleporting, using smooth easing and subtle animation (FR-15).
5. The corresponding portfolio section opens (see Flows 4–10).
6. Continuation: the visitor returns to the workspace via the persistent "Back to Workspace" button (FR-16) or navigates elsewhere via the menu.

Flow 3 — Portfolio Visitor: Direct navigation without 3D exploration

1. The Portfolio Visitor decides not to explore the 3D environment, or does not understand that objects are clickable.
2. The visitor uses the simple navigation menu to directly access Home, About, Skills, Projects, Experience, Resume, or Contact (FR-17, FR-30, FR-34).
3. The selected section opens.
4. Continuation: the visitor reads the content, uses the section's actions, and returns to the workspace via "Back to Workspace" or navigates to another section.

Flow 4 — Portfolio Visitor: Monitor → Resume

1. The Portfolio Visitor clicks the monitor.
2. The camera transitions smoothly toward the monitor; the monitor screen turns on (with the monitor boot animation).
3. The resume/CV is displayed inside the monitor.
4. The visitor views the resume interactively and can download it via the Download Resume button; the resume opens without forcing the visitor to leave the portfolio (FR-5, FR-23).
5. Failure/recovery: if the resume fails to load, a clear message and the download option remain available.
6. Continuation: the visitor uses the clear "Back to Workspace" interaction to return.

Flow 5 — Portfolio Visitor: PC cabinet → Projects

1. The Portfolio Visitor clicks the PC cabinet.
2. The camera moves smoothly toward the PC; the RGB/fan lighting activates.
3. The Projects interface opens, displaying major projects as interactive cards (FR-6).
4. Each project card shows project name, description, technologies used, GitHub link, live demo link, and screenshots/preview; each project also carries a project image, project title, short description, full description, tech stack, features, GitHub button, and live demo button (FR-7, FR-21).
5. The visitor browses the example projects — Paver Manufacturing ERP, Internship Platform, Fitness Tracking Application, Learning Management System using Generative AI, and other relevant projects — and opens GitHub or live demo links (FR-22).
6. Failure/recovery: if a link or image is missing, the card renders without it and navigation remains available.
7. Continuation: the visitor returns to the workspace via "Back to Workspace".

Flow 6 — Portfolio Visitor: Keyboard → Skills

1. The Portfolio Visitor clicks the keyboard.
2. The Skills section opens, with the keyboard backlight ripple on Skills open.
3. Technologies are displayed in a visually impressive way — interactive skill cards, floating 3D elements, or an animated technology wall — including JavaScript, React.js, Node.js, Express.js, MongoDB, HTML, CSS, Tailwind CSS, Git/GitHub, SQL, and other relevant technologies (FR-8).
4. Continuation: the visitor browses skills and returns to the workspace via "Back to Workspace".

Flow 7 — Portfolio Visitor: Smartphone → Contact

1. The Portfolio Visitor clicks the smartphone.
2. The Contact Me section opens, styled to look like an actual smartphone interface.
3. The visitor sees email, LinkedIn, GitHub, phone/contact option, and a contact form (FR-9).
4. The visitor sends a message via the contact form or opens a contact channel.
5. Failure/recovery: if the form submission fails, a clear error is shown and the visitor can retry.
6. Continuation: the visitor returns to the workspace via "Back to Workspace".

Flow 8 — Portfolio Visitor: Headphones → About Me

1. The Portfolio Visitor clicks the headphones.
2. The About Me section opens.
3. The visitor sees a short introduction, education, developer journey, interests, and career goals, presented with subtle animations rather than a large block of text (FR-10).
4. Continuation: the visitor reads the content and returns to the workspace via "Back to Workspace".

Flow 9 — Portfolio Visitor: Notebook → Experience

1. The Portfolio Visitor clicks the notebook.
2. The Experience / Internship section opens.
3. The visitor sees internship/company, role, duration, responsibilities, technologies used, and major work/projects, presented as an interactive timeline (FR-11).
4. Continuation: the visitor explores the timeline and returns to the workspace via "Back to Workspace".

Flow 10 — Portfolio Visitor: Coffee mug → Behind the Code (optional)

1. The Portfolio Visitor clicks the coffee mug.
2. The optional, visually lightweight "Behind the Code" section opens, containing developer philosophy, interests, fun facts, and coding habits (FR-12).
3. Continuation: the visitor reads the section and returns to the workspace via "Back to Workspace".

Flow 11 — Portfolio Visitor: Discovering Easter eggs (optional)

1. While exploring the workspace carefully, the Portfolio Visitor triggers a subtle Easter egg — clicking a hidden object reveals a developer joke, clicking the PC multiple times triggers a small animation, or keyboard interaction triggers a typing animation (FR-28).
2. The Easter egg is optional and tasteful and does not disrupt the experience.
3. Continuation: the visitor continues exploring or returns to the workspace.

Flow 12 — Portfolio Owner: Replacing placeholder content

1. The Portfolio Owner opens the codebase.
2. He locates the centralized data structures for personal information, skills, projects, experience, education, social links, and resume URL (FR-20, FR-35).
3. He replaces the placeholder content with his actual information — including his real projects and resume URL — without editing individual components.
4. The portfolio reflects the updated content across the relevant sections.
5. Continuation: the owner uses the polished portfolio in developer job applications and keeps it current by updating the centralized data.

6. Visuals, Colors, and Theme

The authoritative CREATIVE DIRECTION is "Parametric grandeur for a workspace you can walk into", with Zaha Hadid as the muse. The industry read is a developer portfolio aimed at hiring managers and technical leads, but the emotional register is not "hire me" — it is "step into my world". The feeling is cinematic discovery, not dashboard utility. The palette stays dark and architectural, satisfying the explicit dark-theme/glassmorphism instruction, while a single amber instrument accent keeps the UI readable and non-generic.

Color tokens (dark mode):

Ratio: 78% dark ground, 18% silver structure, 4% amber — the amber must feel like a lamp in a dark room.

Typography:

• Headings: Jost — Light 300–400 weight, wide tracking (0.02em–0.08em), mixed case for hero display and uppercase micro-labels at 11px with 0.18em tracking. Headlines are architectural: generous size, tight leading (0.95), never bold-heavy. The contrast between a 96px light Jost headline and an 11px uppercase silver label is the whole voice.
• Body: Work Sans.
• Monospace data: JetBrains Mono at 13px for specs, coordinates, and project stack chips.
• Scale: 1.25 modular — 96/72/48/32/20/16/14/11. Hero display clamp(48px, 9vw, 128px); section titles clamp(32px, 5vw, 56px); body 16px/1.6; micro-labels 11px uppercase 0.18em.

Shape language: Parametric continuous curves — rounded-rectangle glass panels with 20–28px radii, hairline 1px silver borders at 12% opacity, sweeping diagonal section dividers cut from the same curve family as the desk edge. No sharp 90° corners on UI; the 3D scene itself uses flowing bevels on the desk, monitor stand, and PC cabinet. Buttons are capsule-shaped, not square. Focus rings are 2px amber at 40% offset.

Layout: Full-bleed 3D canvas as the ground layer at every viewport. A fixed top bar (56px) holds the wordmark "HARSH PATEL" left and the 7-item nav right, on a blurred #0A0B0D/70 glass strip with a hairline bottom rule. Section panels enter as asymmetric floating glass cards anchored to the object they belong to — never a centered modal. On desktop the panel sits right-of-center with the object visible left; on mobile the panel becomes a bottom sheet with a drag handle, and the 3D scene simplifies to a static hero render with tap targets. A persistent bottom-left "Back to Workspace" capsule and a bottom-right interaction hint ("Click objects to explore") frame the canvas. 8pt spacing scale, 24/40/64px section gutters.

Imagery: The 3D scene is the imagery — a desk built from dark walnut and matte graphite, a monitor with a pearl-white bezel, a tempered-glass PC cabinet with visible fans, a coiled headphone cable, a ceramic mug with a steam plane. Textures are procedural where possible (brushed metal, matte plastic, fabric chair weave) and compressed to 1K KTX2. Project previews are rendered as 16:9 screenshots pinned to the monitor surface and reused as card thumbnails. No stock photography, no flat illustration.

Explicitly avoided: Blue-indigo primary on white (no #2563EB, #6366F1, #7C3AED anywhere); Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body; a centered hero with headline + subtext + blue button + gradient blob; a grid of identical hover-lift cards with the same radius and shadow; pure #FFFFFF text on #000000 background (use #F2F0EC on #0A0B0D); neon cyan/magenta RGB that reads as a gaming brand rather than a designed instrument; modals that fully cover the 3D scene — panels must always leave the object visible; bouncy or springy easing on camera moves — camera motion is architectural, not playful. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

"The Instrument in the Void." The public entry (Home) is a full-bleed 3D workstation seen from a low three-quarter angle, the desk edge sweeping diagonally across the frame from bottom-left to right, the monitor glowing faintly at center-right. The camera begins a slow 6-second dolly-in from 6m to 3.5m with a subtle 2° roll, then settles. The workstation reads as a single designed instrument floating in a dark architectural void — the #0A0B0D background is the void, the charcoal-to-pearl monochrome carries the scene, and the amber #E8A33D accent is the only hot signal, like a lamp in a dark room.

Over the scene, bottom-left: a stacked lockup — "Hi, I'm" in 20px silver Work Sans above "HARSH PATEL" in clamp(48px, 9vw, 128px) light Jost, pearl #F2F0EC, leading 0.95 — and beneath it a single amber hairline rule with "Full Stack Developer" in 11px uppercase 0.18em tracking. Bottom-right: a small animated cursor glyph pulsing toward the monitor with the line "Explore the workspace to discover my portfolio." A blurred glass nav strip runs the top edge. No centered headline, no gradient blob, no blue button.

The signature moves that carry the concept through the whole product:

• Camera-as-navigation: clicking any object eases the camera along a curved GSAP path to a framing that keeps the object in the left third while its glass panel slides in from the right — the workspace is never hidden.
• Amber tracer outline: on hover, a 2px amber line draws itself around the object's silhouette in 180ms (SVG-on-3D technique via a second render pass), then fades; the object lifts 2px and a tooltip capsule appears with an arrow, e.g. "Monitor — View Resume →".
• Monitor boot sequence: the screen starts black, a single amber scanline sweeps top-to-bottom over 900ms, then the resume renders inside the 3D screen plane as a real readable HTML overlay pinned to the monitor's UV, with a download capsule in the bottom-right of the screen.
• PC cabinet as a light source: opening Projects ignites the tempered-glass side panel and three fan rings in amber at 15% intensity, breathing on a 4s loop, casting real colored light onto the desk and chair — the only saturated color in the scene.
• Bottom-sheet panel system on mobile: every section becomes a draggable glass sheet over a simplified static hero, with the 7-item nav collapsed into a horizontal scrollable pill bar that never wraps and always keeps each label fully readable.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the full-bleed 3D workstation — the desk edge sweeping diagonally across the frame from bottom-left to right, the monitor glowing faintly at center-right, the PC cabinet and its fans visible, the chair and decorative objects completing the scene.
• Input → transformation → outcome thesis: on load, the camera begins a slow 6-second dolly-in from 6m to 3.5m with a subtle 2° roll, then settles; the introduction lockup and the animated cursor glyph fade in over the settled scene, communicating that the workspace is explorable. The transformation is purely cinematic framing of accepted content — no new behavior is introduced.
• Motion vocabulary: cinematic but disciplined — camera eases along a curved path (GSAP with expo.inOut over 1.4s) from workspace to object, never teleporting; hover on an object lifts it 2px and draws an amber outline that traces the geometry over 180ms; monitor boot is a 900ms scanline reveal; PC fan RGB breathes on a 4s loop only while the Projects panel is open; keyboard backlight ripples once per Skills open; panels fade+slide 24px over 320ms; particles are limited to a slow dust field in the light cone of the desk lamp.
• Composed first frame: the low three-quarter desk view with the diagonal desk edge, the faintly glowing monitor at center-right, the bottom-left stacked lockup ("Hi, I'm" / "HARSH PATEL" / amber hairline / "Full Stack Developer"), the bottom-right animated cursor glyph and "Explore the workspace to discover my portfolio.", and the blurred glass nav strip along the top edge.
• Reduced-motion state: with prefers-reduced-motion, camera cuts instantly, panels fade only, and all looping glows become static. The scene remains fully usable and the visible navigation remains available.

9. Non-Functional Requirements

NFR-1 — Performance optimization (explicit). The website must be heavily optimized: lazy-load 3D assets, compress textures, optimize models, avoid unnecessary high-poly objects, use efficient lighting, prevent excessive animations, maintain smooth scrolling and interaction, and provide a lightweight fallback/loading experience. Rationale: the target is a smooth experience rather than simply adding visual effects.

NFR-2 — Responsiveness (explicit). The website must work properly on desktop, laptop, tablet, and mobile. On mobile devices, the 3D environment may be simplified for performance, but usability must not be sacrificed to preserve the exact desktop experience.

NFR-3 — Accessibility and non-3D navigation (explicit). The 3D environment must not be the only way to navigate the website. Visible navigation, tooltips, hover states, clear interaction hints, keyboard-accessible navigation, and mobile-friendly navigation must be provided.

NFR-4 — Camera motion constraint (explicit). The camera must not instantly teleport; smooth easing and subtle animation must be used for camera transitions.

NFR-5 — Content centralization (explicit). Portfolio content must not be hard-coded throughout individual components; centralized data structures must be used for personal information, skills, projects, experience, education, social links, and resume URL.

NFR-6 — Animation restraint (explicit). Animations must not be overdone, and excessive effects that make the website feel like a gaming website must be avoided.

NFR-7 — Visual quality floor (explicit). The 3D scene must not look like a low-quality cartoon; it must use realistic lighting, soft shadows, ambient lighting, reflections, depth of field, subtle bloom, realistic materials, smooth camera movement, natural object animations, and professional environment lighting.

NFR-8 — In-portfolio resume (explicit). The resume must open without forcing the visitor to leave the portfolio.

NFR-9 — Optional lightweight section (explicit). The "Behind the Code" coffee mug section is optional and must remain visually lightweight.

NFR-10 — Optional tasteful Easter eggs (explicit). Easter eggs must be optional and tasteful.

NFR-11 — Prioritization (explicit). Premium design, usability, performance, and meaningful interactions must be prioritized over simply adding more 3D effects.

NFR-12 — Placeholder content (explicit). Placeholder content must be used initially, structured so the owner can easily replace it with actual information.

NFR-13 — Readable text and controls (direction-derived). Headlines, wordmarks, labels, numbers, cards' text, and controls must 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 may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the creative direction asks, as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design; every item must become fully readable as it passes. With prefers-reduced-motion, a usable static arrangement must be provided.

10. Tech Stack

The following stack is preserved from the explicit user requirements:

• React — front-end framework.
• Three.js — 3D rendering.
• React Three Fiber — React renderer for Three.js.
• Drei — React Three Fiber helpers.
• GSAP or Framer Motion — animation and camera easing.
• Tailwind CSS — styling.

Architecture: reusable components and clean architecture using a structure like components/3d/, components/ui/, components/sections/, data/, assets/, and hooks/, keeping the 3D scene, UI, portfolio data, and navigation logic separated.

Fonts (from the authoritative creative direction): Jost (headings), Work Sans (body), JetBrains Mono (monospace data).

No backend, database, or deployment infrastructure was specified by the user; none is introduced. The product is a static front-end web application whose content is supplied through centralized data structures.

11. Assumptions and Constraints

Assumptions (narrow and labeled):

• A-1 [Assumption — not specified by user]: The portfolio is a static front-end web application; no server-side backend or database is required, because all content is supplied through centralized data structures and no accepted journey requires server-side state.
• A-2 [Assumption — not specified by user]: The contact form delivers messages through a client-side mechanism (e.g., a mailto link or a third-party form endpoint) since no backend was specified; the exact delivery mechanism is left to implementation.
• A-3 [Assumption — not specified by user]: Placeholder content is used for all portfolio data until the Portfolio Owner replaces it, as explicitly required.
• A-4 [Assumption — not specified by user]: The 3D assets (models, textures) are authored or sourced by the Portfolio Owner and placed in the assets/ directory; the SRD does not specify their provenance.

Constraints (explicit, binding):

• C-1: The 3D environment must NOT be the only way to navigate the website; visible navigation, tooltips, hover states, clear interaction hints, keyboard-accessible navigation, and mobile-friendly navigation must be provided.
• C-2: Do not instantly teleport the camera; use smooth easing and subtle animation for camera transitions.
• C-3: Do not hard-code portfolio content throughout individual components; use centralized data structures for personal information, skills, projects, experience, education, social links, and resume URL.
• C-4: Do not overdo the animations, and avoid excessive effects that make the website feel like a gaming website.
• C-5: Avoid making the 3D scene look like a low-quality cartoon.
• C-6: Do not sacrifice usability just to preserve the exact desktop experience on mobile devices.
• C-7: The resume must open without forcing the user to leave the portfolio.
• C-8: The "Behind the Code" coffee mug section is optional and must remain visually lightweight.
• C-9: Easter eggs must be optional and tasteful.
• C-10: Prioritize premium design, usability, performance, and meaningful interactions over simply adding more 3D effects.
• C-11: Use placeholder content initially, structured so the owner can easily replace it with actual information.
• C-12: The generic indigo/blue-on-white SaaS template is forbidden for this project.

12. Glossary

• 3D workstation / workspace: The realistic modern PC/gaming workstation environment that forms the core of the portfolio, containing the desk, monitor, PC cabinet, keyboard, mouse, headphones, desk lamp, smartphone, notebook, coffee mug, speakers, gaming/controller elements, office chair, small decorative objects, and other subtle workspace details.
• Interactive object: A workspace object that responds to hover and click and acts as a navigation point into a portfolio section.
• Camera transition: The smooth, eased camera movement toward a selected object; never an instant teleport.
• Back to Workspace: The persistent control that returns the visitor from a portfolio section to the main 3D workspace.
• Portfolio section: One of the seven content destinations — Home, About, Skills, Projects, Experience, Resume, Contact.
• Centralized data structures: The single-source data modules (personal information, skills, projects, experience, education, social links, resume URL) from which all portfolio content is rendered, so content is not hard-coded in individual components.
• Behind the Code: The optional, visually lightweight personal/fun section opened by the coffee mug, containing developer philosophy, interests, fun facts, and coding habits.
• Easter egg: A subtle, optional, tasteful hidden interaction for visitors who explore carefully.
• Microinteraction: A subtle professional interaction such as button hover animation, smooth page transition, object hover effect, camera easing, screen animation, PC RGB animation, keyboard lighting, monitor boot animation, subtle particle effect, or ambient workspace movement.
• Monitor boot animation: The 900ms amber scanline reveal that plays when the monitor screen turns on to display the resume.
• PC RGB animation: The amber fan-ring lighting that activates and breathes on a 4s loop while the Projects interface is open.
• Portfolio Visitor: The accepted persona who evaluates Harsh Patel as a Full Stack Developer.
• Portfolio Owner (Harsh Patel): The accepted persona who owns and maintains the portfolio and replaces placeholder content through centralized data structures.