System Requirements Document for deepakportfolio

1. Introduction

deepakportfolio is the foundation build of a premium personal portfolio website for a Business Systems Architect / Digital Transformation & MIS professional. The site's core message is "I design the systems businesses run on." and its purpose is to make a visitor conclude: "This person understands how businesses actually operate and can design the systems that run them."

The audience is business-side visitors — business owners, operations leads, prospective clients, and prospective employers — who evaluate whether the owner genuinely designs and builds the systems businesses run on (ERP, MIS platforms, inventory systems, workflow automation, HRMS, sales & purchase systems, follow-up/calling systems, ticketing tools, import management systems, operational dashboards, internal business software, and AI-powered business system tools), rather than merely building websites.

This first build deliberately prioritizes, in order: (1) visual design, (2) overall architecture, (3) reusable components, (4) navigation, (5) project data system, (6) project template, (7) responsiveness, and (8) animation foundation. Detailed project content and long-form biography are explicitly deferred; the structure must allow sections and case studies to be populated later without redesigning the site.

2. System Overview

deepakportfolio is a dark, near-black, highly technical portfolio delivered as a first-party web application with six primary destinations — Home, Projects, Experience, About, Resume, Contact — plus a reusable project-detail route family for individual case studies (/projects/business-erp, /projects/inventory-management, /projects/timesheet-system, /projects/hrms, /projects/follow-up-system, /projects/import-management, /projects/ai-business-system-builder).

The public experience is anonymous and open: a visitor lands on Home, reads the hero claim and the live architecture diagram, browses the Projects grid and filters by category, opens individual project case-study pages rendered from one centralized project data source through one reusable template, reviews the Experience timeline, About disciplines, Resume, and Capabilities, and continues to Contact or the LinkedIn / GitHub / Email placeholders.

A single content-maintenance lifecycle exists for the site owner: the professional whose portfolio this is signs in through a dedicated Login destination and maintains the centralized project data source and portfolio content. No public enrollment, no differentiated roles, and no permission tiers are established.

Actors. Two accepted human personas: the Portfolio Visitor / Prospective Client or Employer (anonymous public reader) and the Site Owner / Systems Architect (content maintainer) (authenticated maintainer). No other human actors are in scope.

Narrow exclusions. The site must never mention Formative; must never present the owner as a founder; must present projects simply as systems or projects personally designed or developed; must not invent job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, unconfirmed technologies, or business impact percentages; must not imply direct employment by Royal Enfield, NovaCare, Finviz, or other associated organizations; must not copy any website directly; and must avoid generic developer portfolio templates, skill percentage bars, excessive neon, gaming aesthetics, unnecessary glassmorphism, random animations, and cliché coding illustrations.

2a. Product Interpretation and Delivery Boundary

The portfolio is a first-party product surface, not a hosted profile or third-party template. All six primary destinations and all seven project-detail routes are owned and rendered by the application itself, and the visual language is the product: dark graphite ground, hairline-ruled data rows, tabular numerals, hand-built SVG architecture and workflow diagrams, and one tangerine signal colour.

Public reading is anonymous — no account is required to browse Home, Projects, any project case-study page, Experience, About, Resume, or Contact. The only identity boundary in the current build is the owner's content-maintenance lifecycle: because the centralized project data source and portfolio content are durable, owner-specific state that must remain bound to the correct person, the owner establishes access by invitation or provisioning and returns through verification at the Login destination. Login is the anonymous entry boundary for that lifecycle; the protected maintenance state is unavailable until identity is established. No public sign-up, no social login, no role management, and no permission tiers are part of this build.

Current scope is the foundation: design system, page architecture, reusable components, routing, responsiveness, navigation, project data system, project template, and animation foundation. Deferred to later work — and therefore out of current acceptance — are fully populated project case studies, long-form biography, exact Excel Sathi title and dates, and any metrics, testimonials, dates, certifications, or impact figures.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source; all supplied references are inspiration_only visual references and supply no product facts, copy, or capabilities.

2c. Page Content and Component Coverage

Home

• Information / state: Anonymous public entry. Hero micro-label BUSINESS SYSTEMS ARCHITECT · MIS · AUTOMATION; primary headline "I design the systems businesses run on."; one line of supporting copy naming ERP systems, MIS platforms, workflow automation, and internal business software; three CTAs (primary "Explore My Work", secondary "View Projects", text-link "View Resume"); a hairline row of LinkedIn / GitHub / Email placeholders; the live hero architecture diagram; a plain-text context strip of associated brands (Royal Enfield, NovaCare, Finviz, and others) presented without employer implication; the "How I Build Systems" eight-step process section; a Projects preview grid; the About disciplines schematic; the Experience timeline; the Contact CTA; the footer.
• Primary actions: Read the hero claim; activate "Explore My Work"; activate "View Projects"; activate "View Resume"; open LinkedIn / GitHub / Email placeholders; scroll through the process rail; open a project card; open Contact.
• Supporting actions: Open the\x20\xe2\x8c\x98K / Ctrl+K command palette; jump to a section from the sticky nav; hover a project card; hover the architecture diagram nodes.
• Domain entities: Hero claim, supporting message, CTA set, social placeholders, architecture diagram (six input nodes → Business System Architecture → five output nodes), process steps 01–08, project card summaries, discipline set (Business Analysis, System Architecture, MIS, Automation, Software Development), experience entry, contact CTA.
• Component responsibilities: Navbar (sticky, 56px, hairline bottom border, wordmark left, six section links centre,\x20\xe2\x8c\x98K keycap right); Hero (headline, supporting copy, CTA row, social row, diagram slot); ArchitectureDiagram (six-in / one-core / five-out node graph with animated orthogonal connectors); WorkflowDiagram (shared node grammar for process and before/after schematics); ProjectGrid + ProjectCard (preview grid); ExperienceTimeline (foundation entry); CapabilityCard (discipline schematic); ContactCTA; Footer.
• States: Loading — hero copy and nav render immediately; the diagram mounts as a static, fully legible SVG first frame before its loop begins. Empty — if the project data source has no entries, the preview grid shows a hairline-ruled empty state with a neutral label and no fabricated cards. Success — headline, CTAs, diagram, process rail, and preview grid all render; the diagram loop runs once continuously. Error — if the diagram asset fails, the hero falls back to the static node list rendered as ruled label/value rows so the claim remains legible. Recovery — reload or scroll re-triggers the single 12px reveal; the diagram restarts its loop.

Login

• Information / state: Anonymous entry boundary for the owner's content-maintenance lifecycle. Identity-establishment and returning-verification fields; no public enrollment, no role selection, no permission display.
• Primary actions: Establish first-use access via invitation or provisioning; return and verify identity; continue to protected maintenance state.
• Supporting actions: Recover from a failed verification attempt; return to the public site.
• Domain entities: Owner identity, invitation/provisioning credential, verification attempt, session continuity.
• Component responsibilities: Navbar (reduced, public links only); identity form component; error/notice region; Footer.
• States: Loading — form renders with disabled submit until required fields are present. Empty — first-use state presents the invitation/provisioning path rather than a public sign-up. Success — verification succeeds and the owner continues to protected maintenance state. Error — invalid or expired credential shows a specific, non-enumerating message and preserves entered context. Recovery — the owner can retry verification or return to the public site without losing the public session.

Projects

• Information / state: Anonymous public catalog. Premium project grid; category filter set (ERP, MIS, Inventory, HR, Automation, AI, Operations); project cards carrying title, short description, category, role, technologies, thumbnail, status, and case-study link.
• Primary actions: Browse the grid; select a category filter; open a project card's case-study link.
• Supporting actions: Clear the active filter; open the command palette and jump directly to a project slug; hover a card.
• Domain entities: Project records from the centralized data source; category taxonomy; status values; thumbnail diagram tiles.
• Component responsibilities: ProjectGrid (layout, filter state, result count); ProjectCard (title, description, category, role, technologies, thumbnail, status, case-study link); filter control group; Footer.
• States: Loading — grid renders skeleton hairline rows while project data resolves. Empty — a filter with no matches shows a ruled empty state naming the active category and offering a clear-filter action. Success — all eight placeholder projects render as cards with their diagram thumbnails. Error — if the data source fails to load, the grid shows a ruled error state with a retry action and no fabricated cards. Recovery — retry reloads the data source; clearing the filter restores the full grid.

Experience

• Information / state: Anonymous public timeline. Modern experience timeline component with an initial entry for Excel Sathi, role Senior MIS / Digital Transformation / Systems Architecture; exact title and dates explicitly deferred and shown as an unfilled placeholder rather than invented values.
• Primary actions: Read the timeline; expand an entry's detail region.
• Supporting actions: Navigate to Contact; open the command palette.
• Domain entities: Experience entries (organization, role, deferred title/date placeholders, description).
• Component responsibilities: ExperienceTimeline (vertical rail, tabular step markers, ruled label/value rows); Footer.
• States: Loading — timeline rail renders with placeholder rows. Empty — if no entries exist, a ruled empty state explains that roles will be added. Success — the Excel Sathi entry renders with its role and explicit deferred-field placeholders. Error — a failed entry render degrades to a plain ruled row without breaking the rail. Recovery — reload restores the timeline; the component accepts additional entries without layout change.

About

• Information / state: Anonymous public positioning. A concise statement that the work exists between Business Analysis, System Architecture, MIS, Automation, and Software Development, plus a visual representation of these five disciplines. No long biography.
• Primary actions: Read the positioning statement; read the discipline schematic.
• Supporting actions: Continue to Projects, Experience, Resume, or Contact.
• Domain entities: Five-discipline set; concise positioning copy.
• Component responsibilities: CapabilityCard (discipline schematic); discipline diagram using the shared node grammar; Footer.
• States: Loading — schematic renders as a static first frame. Empty — not applicable; the five disciplines are fixed content. Success — statement and schematic render together. Error — if the schematic fails, the five disciplines render as a ruled label list. Recovery — reload restores the schematic.

Resume

• Information / state: Anonymous public destination linked from the hero ("View Resume") and the sticky navigation. Presents the resume surface and its download/view affordance; no invented dates, education, or certifications.
• Primary actions: View the resume; download or open it.
• Supporting actions: Return to Experience or Contact.
• Domain entities: Resume document reference; deferred content placeholders.
• Component responsibilities: Resume view/download component; Footer.
• States: Loading — a ruled placeholder holds the layout while the document resolves. Empty — if no document is attached yet, a ruled notice states that the resume will be added. Success — the resume renders or downloads. Error — a failed fetch shows a retry action. Recovery — retry re-requests the document.

Contact

• Information / state: Anonymous public destination for the Contact CTA and outreach continuation. Contact affordances plus the LinkedIn / GitHub / Email placeholders carried from the hero.
• Primary actions: Initiate contact through the available channel; open LinkedIn, GitHub, or Email.
• Supporting actions: Return to Projects or Home.
• Domain entities: Contact channels; social placeholders.
• Component responsibilities: ContactCTA; channel list; Footer.
• States: Loading — channel list renders immediately from static configuration. Empty — if a channel is not yet configured, its row shows a neutral placeholder rather than a broken link. Success — the visitor reaches a working channel. Error — a failed submission or unavailable channel shows a specific message and preserves the visitor's input. Recovery — the visitor can retry or choose another channel.

/projects/business-erp

• Information / state: Anonymous public case-study route rendered by the reusable ProjectCaseStudy template from the centralized project data source. Supports the twelve template sections: 1. Project Hero, 2. Business Problem, 3. Before vs After Workflow, 4. System Architecture, 5. Modules, 6. Key Features, 7. Product Screens, 8. Automation Flow, 9. Technology Stack, 10. Business Impact, 11. What I Learned, 12. Next Project. Content is not fully populated in this build; unpopulated sections render as explicit placeholders rather than fabricated content.
• Primary actions: Read the case study; navigate the sticky left rail of twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Project record fields — slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, status.
• Component responsibilities: ProjectCaseStudy (section orchestration); ArchitectureDiagram; WorkflowDiagram (before/after); section anchor rail; Footer.
• States: Loading — template shell and anchor rail render while the project record resolves. Empty — sections without data render a ruled "to be added" placeholder, never invented content. Success — populated sections render with their diagrams. Error — an unknown slug shows a ruled not-found state with a link back to Projects. Recovery — the visitor returns to Projects or uses the command palette to reach another project.

/projects/inventory-management

• Information / state: Anonymous public case-study route rendered by the same reusable ProjectCaseStudy template and the same twelve sections, reading the Inventory & Order Management record from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

/projects/timesheet-system

• Information / state: Anonymous public case-study route for the Employee Timesheet System, rendered by the same reusable template and twelve sections from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

/projects/hrms

• Information / state: Anonymous public case-study route for the HRMS project, rendered by the same reusable template and twelve sections from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

/projects/follow-up-system

• Information / state: Anonymous public case-study route for the Calling / Follow-Up System, rendered by the same reusable template and twelve sections from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

/projects/import-management

• Information / state: Anonymous public case-study route for the Import Management System, rendered by the same reusable template and twelve sections from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

/projects/ai-business-system-builder

• Information / state: Anonymous public case-study route for the AI Business System Builder, rendered by the same reusable template and twelve sections from the centralized data source. Content deferred; placeholders only.
• Primary actions: Read the case study; navigate the twelve section anchors; continue to the Next Project.
• Supporting actions: Return to Projects; open the command palette.
• Domain entities: Same project record field set as above.
• Component responsibilities: ProjectCaseStudy; ArchitectureDiagram; WorkflowDiagram; section anchor rail; Footer.
• States: Loading — template shell renders. Empty — unpopulated sections show ruled placeholders. Success — populated sections render. Error — unknown slug shows a ruled not-found state. Recovery — return to Projects or use the command palette.

3. Functional Requirements

FR-01 — Premium portfolio foundation (explicit) As the Site Owner, I should have a premium personal portfolio website foundation built with the design system, page architecture, reusable components, routing, responsiveness, and overall visual experience prioritized first, so that individual sections can be expanded later without redesigning the whole site.

• Trigger/input: the foundation build.
• Observable result: the six primary destinations and the seven project-detail routes exist and render with the design system applied.
• Access state: public destinations anonymous; owner maintenance behind Login.
• Failure/recovery: a missing route or component falls back to a ruled placeholder rather than a broken layout.
• Continuation: later content population reuses the same structure.

FR-02 — Core message (explicit) As the Site Owner, I should have the site communicate "I design the systems businesses run on." so that the visitor immediately understands the positioning.

• Trigger/input: visitor lands on Home.
• Observable result: the exact headline renders in the hero.
• Access state: anonymous.
• Failure/recovery: if the hero diagram fails, the headline and supporting copy remain fully legible.
• Continuation: the visitor scrolls into the process and projects sections.

FR-03 — Professional value combination (explicit) As the Site Owner, I should have the site communicate that my professional value combines Business Analysis + System Architecture + MIS + Automation + Software Development, so that the visitor sees a systems architect rather than a website builder.

• Trigger/input: visitor reads the hero supporting copy and the About section.
• Observable result: the five disciplines appear as a stated combination and as a visual representation.
• Access state: anonymous.
• Failure/recovery: if the discipline schematic fails, the five disciplines render as a ruled label list.
• Continuation: the visitor continues to Projects or Experience.

FR-04 — Business-understanding narrative (explicit) As the Site Owner, I should have the visitor understand that I study how a business operates, understand its workflows, identify problems, design the data structure, build the system, automate repetitive work, and create management reporting, so that the site does not read as "just websites."

• Trigger/input: visitor reads the "How I Build Systems" section and the About positioning.
• Observable result: the eight-step process and the five-discipline schematic are visible.
• Access state: anonymous.
• Failure/recovery: the process rail degrades to a numbered ruled list if its diagram fails.
• Continuation: the visitor opens a project case study.

FR-05 — Primary site architecture (explicit) As the Site Owner, I should have the primary sections/pages Home, Projects, Experience, About, Resume, and Contact, so that the site has a complete navigable architecture.

• Trigger/input: navigation from the sticky nav or direct URL.
• Observable result: each destination renders its own content.
• Access state: all six are anonymous public destinations.
• Failure/recovery: an unknown route shows a ruled not-found state with a link back to Home.
• Continuation: the visitor moves between destinations via the sticky nav.

FR-06 — Project-detail routing architecture (explicit) As the Site Owner, I should have routing/architecture prepared for individual project pages at /projects/business-erp, /projects/inventory-management, /projects/timesheet-system, /projects/hrms, /projects/follow-up-system, /projects/import-management, and /projects/ai-business-system-builder, so that case studies can be added later without redesigning the site.

• Trigger/input: a case-study link from a project card, the command palette, or a direct URL.
• Observable result: the matching route renders through the reusable template.
• Access state: anonymous.
• Failure/recovery: an unknown slug shows a ruled not-found state with a link back to Projects.
• Continuation: the visitor continues to the Next Project.

FR-07 — Homepage hero (explicit) As the Site Owner, I should have a strong hero section with the primary headline "I design the systems businesses run on.", a supporting message communicating that I build ERP systems, MIS platforms, workflow automation, and internal business software, a primary CTA "Explore My Work", a secondary CTA "View Projects", a "View Resume" link, and placeholders for LinkedIn, GitHub, and Email, so that the first impression states the claim and offers immediate next steps.

• Trigger/input: visitor lands on Home.
• Observable result: headline, supporting copy, three CTAs, and the social placeholder row all render.
• Access state: anonymous.
• Failure/recovery: a failed social link renders as a neutral placeholder rather than a broken link.
• Continuation: "Explore My Work" continues into the process/projects content; "View Projects" continues to Projects; "View Resume" continues to Resume.

FR-08 — Premium hero visual (explicit) As the Site Owner, I should have a premium hero visual in which Sales, Inventory, Production, HR, Finance, and Operations flow into a "Business System Architecture" node that produces Automation, Dashboards, Approvals, Reports, and ERP, with animation that visually communicates that I connect business functions together.

• Trigger/input: Home renders.
• Observable result: the six input nodes, the central architecture node, and the five output nodes render as one diagram with animated connectors.
• Access state: anonymous.
• Failure/recovery: under prefers-reduced-motion the diagram renders static and fully legible; if the asset fails, the node lists render as ruled rows.
• Continuation: the visitor scrolls on; the diagram loop continues.

FR-09 — About section foundation (explicit) As the Site Owner, I should have a concise About section explaining that my work exists between Business Analysis, System Architecture, MIS, Automation, and Software Development, with a visual representation of these disciplines and no long biography yet.

• Trigger/input: visitor opens About.
• Observable result: the concise statement and the discipline visual render.
• Access state: anonymous.
• Failure/recovery: the discipline visual degrades to a ruled label list.
• Continuation: the visitor continues to Experience or Projects.

FR-10 — Experience timeline foundation (explicit) As the Site Owner, I should have a modern experience timeline/component containing an initial entry for Excel Sathi with the role Senior MIS / Digital Transformation / Systems Architecture, with the exact title and dates added later, built so more roles can easily be added.

• Trigger/input: visitor opens Experience.
• Observable result: the Excel Sathi entry renders with its role and explicit deferred-field placeholders.
• Access state: anonymous.
• Failure/recovery: a failed entry render degrades to a plain ruled row without breaking the rail.
• Continuation: additional entries can be appended without layout change.

FR-11 — Premium project grid (explicit) As the Site Owner, I should have a premium project grid whose cards support project title, short description, category, role, technologies, thumbnail, status, and case-study link.

• Trigger/input: visitor opens Projects.
• Observable result: each card renders all supported fields, with unpopulated fields shown as placeholders rather than invented values.
• Access state: anonymous.
• Failure/recovery: a failed data load shows a ruled error state with retry.
• Continuation: the visitor opens a case study.

FR-12 — Initial project placeholders (explicit) As the Site Owner, I should have initial project placeholders for Business ERP, Inventory & Order Management, Employee Timesheet System, Business Operations / Mini ERP, HRMS, Calling / Follow-Up System, Import Management System, and AI Business System Builder, without fabricating detailed content.

• Trigger/input: Projects renders.
• Observable result: eight placeholder projects appear in the grid.
• Access state: anonymous.
• Failure/recovery: missing detail fields render as ruled placeholders.
• Continuation: each placeholder links to its case-study route.

FR-13 — Project filtering categories (explicit) As the Site Owner, I should have filtering categories ERP, MIS, Inventory, HR, Automation, AI, and Operations on the project grid.

• Trigger/input: visitor selects a category.
• Observable result: the grid filters to matching projects and shows the active category.
• Access state: anonymous.
• Failure/recovery: a category with no matches shows a ruled empty state with a clear-filter action.
• Continuation: clearing the filter restores the full grid.

FR-14 — Reusable project case-study template (explicit) As the Site Owner, I should have one reusable project-detail template supporting the twelve sections Project Hero, Business Problem, Before vs After Workflow, System Architecture, Modules, Key Features, Product Screens, Automation Flow, Technology Stack, Business Impact, What I Learned, and Next Project, so that project pages can later be populated from project data.

• Trigger/input: a project-detail route renders.
• Observable result: the twelve sections render in order, with unpopulated sections shown as explicit placeholders.
• Access state: anonymous.
• Failure/recovery: an unknown slug shows a ruled not-found state.
• Continuation: the visitor continues to the Next Project.

FR-38 — Mobile Modules heading integrity (explicit) As the Site Owner, I should have the Modules heading in the reusable project case-study template render on mobile as a single, non-fragmented element, so that the section title never breaks into stacked fragments at narrow viewports.

• Trigger/input: a project-detail route renders at a mobile viewport (for example 375px).
• Observable result: the Modules heading renders as one whole, legible heading inside its container, wrapping or scaling to fit rather than splitting into stacked fragments.
• Access state: anonymous.
• Failure/recovery: if the heading would fragment, it wraps or scales to fit; readable text stays whole and inside the viewport and its container.
• Continuation: the visitor reads the Modules section and continues through the remaining template sections.

FR-39 — Foundation completion reward (explicit) As the Site Owner, I should have the portfolio site carried through first-page and full-page generation as the foundation kickoff, with the 0.016 free-credit A reward claimed for that completion, so that the foundation build is recognized as delivered.

• Trigger/input: the foundation build completes first-page and full-page generation.
• Observable result: the 0.016 free-credit A reward is claimed for the foundation kickoff and generation run.
• Access state: owner-side reward claim; no public surface change.
• Failure/recovery: if the reward claim is unavailable, the foundation build remains unaffected and the claim is retried.
• Continuation: later content population reuses the same structure.

FR-15 — "How I Build Systems" process section (explicit) As the Site Owner, I should have a visual process section with 01 Understand the Business, 02 Map the Workflow, 03 Identify Bottlenecks, 04 Design the Data Architecture, 05 Build the System, 06 Automate Repetitive Processes, 07 Create MIS & Reporting, and 08 Deploy and Improve, so that the site reinforces that I solve business problems, not just coding problems.

• Trigger/input: visitor scrolls the Home process rail.
• Observable result: the eight numbered steps render with tabular numerals and the active step marked.
• Access state: anonymous.
• Failure/recovery: the rail degrades to a numbered ruled list if its diagram fails.
• Continuation: the visitor continues to Projects.

FR-16 — Grouped capability cards (explicit) As the Site Owner, I should have grouped capability cards instead of percentage bars, in the groups Business Systems, Development, Automation, Data & MIS, AI, and Deployment, with placeholders for ERP Architecture, Workflow Design, Google Apps Script, Google Sheets, JavaScript, HTML, CSS, API Integration, MIS, Dashboards, Automation, Gemini API, GitHub, and CLASP.

• Trigger/input: visitor reads the capabilities area.
• Observable result: six groups render as cards containing their skill placeholders; no percentage bars appear.
• Access state: anonymous.
• Failure/recovery: an unassigned skill renders as a neutral placeholder.
• Continuation: the visitor continues to Contact.

FR-17 — Premium sticky navigation (explicit) As the Site Owner, I should have a premium sticky navigation with the sections Home, Projects, Experience, About, Resume, and Contact.

• Trigger/input: any page renders.
• Observable result: the sticky bar persists with the six section links and marks the active section.
• Access state: anonymous.
• Failure/recovery: on narrow viewports the links collapse into an accessible menu without losing any destination.
• Continuation: the visitor navigates between destinations.

FR-18 — Command palette (explicit) As the Site Owner, I should have a command palette opened with CMD + K or CTRL + K that allows quick navigation to projects and sections.

• Trigger/input: the visitor presses CMD + K or CTRL + K, or activates the keycap trigger.
• Observable result: the palette opens and lists sections and all eight project slugs with their route hints.
• Access state: anonymous.
• Failure/recovery: pressing Escape closes the palette and returns focus to the trigger.
• Continuation: selecting an entry navigates to that section or project.

FR-19 — Premium microinteractions (explicit) As the Site Owner, I should have premium microinteractions — scroll reveals, smooth section transitions, card hover effects, architecture flow animations, subtle mouse-responsive effects, animated lines between system modules, button interactions, and project transitions — that remain lightweight and professional and respect prefers-reduced-motion.

• Trigger/input: scroll, hover, pointer movement, or navigation.
• Observable result: the specified interactions play within their restrained timing.
• Access state: anonymous.
• Failure/recovery: under prefers-reduced-motion every animation is disabled, leaving static, fully legible diagrams.
• Continuation: the visitor continues browsing without interruption.

FR-20 — Full responsiveness (explicit) As the Site Owner, I should have the website fully responsive for desktop, laptop, tablet, and mobile, with mobile feeling intentionally designed.

• Trigger/input: viewport resize or device load.
• Observable result: layout, typography, and controls adapt at each breakpoint; at 375px the hero diagram moves below the copy, scales to full width, and drops to a simplified 3-in / 3-out version, the headline wraps to a 44px stack, and all CTAs remain whole and stacked full-width.
• Access state: anonymous.
• Failure/recovery: readable text and controls stay whole and inside the viewport at 375px, 768px, and 1280px.
• Continuation: the visitor continues on any device.

FR-21 — Reusable component structure (explicit) As the Site Owner, I should have reusable components including Navbar, Hero, ProjectCard, ProjectGrid, ExperienceTimeline, ArchitectureDiagram, WorkflowDiagram, CapabilityCard, ContactCTA, Footer, and ProjectCaseStudy, without duplicating content unnecessarily.

• Trigger/input: any page renders.
• Observable result: pages compose from the shared components; the same node grammar repeats across hero, thumbnails, and case-study diagrams.
• Access state: anonymous.
• Failure/recovery: a component failure degrades to a ruled fallback rather than breaking the page.
• Continuation: new sections reuse the same components.

FR-22 — Centralized project data source (explicit) As the Site Owner, I should have a centralized project data source (for example projects.js or projects.json) whose entries support the fields slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, and status, with project pages reading from this data wherever possible.

• Trigger/input: Projects or a project-detail route renders.
• Observable result: cards and case-study sections are populated from the single data source.
• Access state: public read; owner-maintained.
• Failure/recovery: a failed load shows a ruled error state with retry.
• Continuation: adding a record adds a card and a route without redesign.

FR-23 — Quality requirements (explicit) As the Site Owner, I should have the website be responsive, fast, accessible, SEO-friendly, cleanly structured, easy to maintain, visually impressive, and production-quality.

• Trigger/input: any page load.
• Observable result: the site meets these qualities across destinations.
• Access state: anonymous.
• Failure/recovery: regressions surface as visible layout or accessibility failures rather than silent degradation.
• Continuation: the foundation supports later content population.

FR-24 — Semantic HTML and metadata (explicit) As the Site Owner, I should have semantic HTML plus basic page titles, meta descriptions, OpenGraph structure, accessibility labels, keyboard navigation, and focus states.

• Trigger/input: any page renders or is crawled.
• Observable result: each destination exposes a title, meta description, and OpenGraph structure; interactive elements are labelled, keyboard reachable, and show focus states.
• Access state: anonymous.
• Failure/recovery: a missing label or focus state is treated as a defect, not a fallback.
• Continuation: new pages inherit the same metadata pattern.

FR-25 — Design direction (explicit) As the Site Owner, I should have a premium, modern, highly technical portfolio that feels sophisticated, futuristic, minimal, premium, technical, and business-focused, using a dark or near-black theme, strong typography, subtle gradients, soft borders, animated background details, smooth scrolling, premium hover states, subtle parallax, clean cards, architecture diagrams, workflow visualizations, and polished page transitions, so that the portfolio itself feels like a technology product.

• Trigger/input: any page renders.
• Observable result: the visual system applies consistently across all destinations.
• Access state: anonymous.
• Failure/recovery: any element that breaks the direction is corrected rather than shipped.
• Continuation: the direction governs later content population.

FR-26 — Visual inspiration boundary (explicit) As the Site Owner, I should have visual inspiration drawn from Linear, Vercel, Stripe, Raycast, Framer, modern AI SaaS products, and Apple-style product storytelling, without copying any website directly.

• Trigger/input: design and build.
• Observable result: the site's own visual language is distinct and no source site is reproduced.
• Access state: anonymous.
• Failure/recovery: any direct copy is treated as a defect.
• Continuation: the direction continues to govern later work.

FR-27 — Design exclusions (explicit) As the Site Owner, I should have the site avoid generic developer portfolio templates, skill percentage bars, excessive neon, gaming aesthetics, unnecessary glassmorphism, random animations, and cliché coding illustrations.

• Trigger/input: design and build.
• Observable result: none of the excluded patterns appear.
• Access state: anonymous.
• Failure/recovery: an excluded pattern is removed rather than tolerated.
• Continuation: the exclusions remain binding for later content.

FR-28 — Project presentation rule (explicit) As the Site Owner, I should have projects presented simply as systems or projects I have personally designed or developed, so that no founder framing or employer implication is created.

• Trigger/input: any project surface renders.
• Observable result: project copy uses the systems/projects framing only.
• Access state: anonymous.
• Failure/recovery: any founder or employer framing is removed.
• Continuation: later case-study content follows the same rule.

FR-29 — No-fabrication rule (explicit) As the Site Owner, I should have the site avoid inventing job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, technologies not confirmed, or business impact percentages, with accurate content added later.

• Trigger/input: any content renders.
• Observable result: unpopulated fields show explicit placeholders rather than invented values.
• Access state: anonymous.
• Failure/recovery: invented content is removed and replaced with a placeholder.
• Continuation: accurate content is added later through the owner's maintenance lifecycle.

FR-30 — Associated-brands context (explicit) As the Site Owner, I should be able to reference projects associated with organizations/brands such as Royal Enfield, NovaCare, Finviz, and others without implying that I was directly employed by those organizations.

• Trigger/input: the context strip or project copy renders.
• Observable result: brands appear as plain text context only, never as employer branding or logos.
• Access state: anonymous.
• Failure/recovery: any employment implication is removed.
• Continuation: later project content follows the same rule.

FR-31 — Current professional context (explicit) As the Site Owner, I should have the site reflect that I currently work at Excel Sathi in a senior MIS / digital transformation / systems architecture role, and that my work involves understanding real business processes and converting them into structured digital systems.

• Trigger/input: the Experience section renders.
• Observable result: the Excel Sathi entry states the organization and role, with exact title and dates deferred.
• Access state: anonymous.
• Failure/recovery: deferred fields render as placeholders.
• Continuation: the exact title and dates are added later.

FR-32 — Systems portfolio scope (explicit) As the Site Owner, I should have the site represent the systems I design and build — ERP systems, MIS platforms, inventory systems, workflow automation, HRMS, sales & purchase systems, follow-up/calling systems, ticketing tools, import management systems, operational dashboards, internal business software, and AI-powered business system tools — so that the visitor sees the full range of my systems work.

• Trigger/input: the visitor reads the hero supporting copy, About, and Projects.
• Observable result: the systems range is represented across the site's content.
• Access state: anonymous.
• Failure/recovery: unpopulated systems render as placeholders rather than invented case studies.
• Continuation: the visitor opens a related project.

FR-33 — Final objective (explicit) As the Site Owner, I should have the website make someone think "This person understands how businesses actually operate and can design the systems that run them."

• Trigger/input: the visitor completes a browse of the site.
• Observable result: the claim, process, projects, and positioning together produce that conclusion.
• Access state: anonymous.
• Failure/recovery: any element that contradicts the conclusion is corrected.
• Continuation: the visitor reaches out through Contact.

FR-34 — Owner first-use access (required_inference) As the Site Owner, I should be able to establish first-use access to the content-maintenance lifecycle by invitation or provisioning, so that the durable project data and portfolio content remain bound to the correct person.

• Trigger/input: the owner arrives at Login for the first time.
• Observable result: the invitation/provisioning path is presented; no public enrollment is offered.
• Access state: anonymous entry boundary; protected state unavailable until identity is established.
• Failure/recovery: an invalid or expired credential shows a specific, non-enumerating message and preserves entered context.
• Continuation: the owner proceeds to returning verification.

FR-35 — Owner returning verification (required_inference) As the Site Owner, I should be able to verify my identity on return before changing centralized project data and portfolio content.

• Trigger/input: the owner returns to Login.
• Observable result: verification succeeds and the owner continues to the protected maintenance state.
• Access state: protected state remains unavailable until verification succeeds.
• Failure/recovery: a failed attempt shows a specific message and allows retry without losing the public session.
• Continuation: the owner maintains project data and content.

FR-36 — Project routes depend on the data source and template (required_inference) As the Site Owner, I should have project-detail routes resolve from the centralized project data source through the reusable case-study template, so that adding a project record produces its page without redesign.

• Trigger/input: a project-detail route is requested.
• Observable result: the matching record renders through the twelve-section template.
• Access state: anonymous.
• Failure/recovery: an unknown slug shows a ruled not-found state with a link back to Projects.
• Continuation: the visitor continues to the Next Project.

FR-37 — Anonymous Home entry precedes protected maintenance (required_inference) As a Portfolio Visitor, I should be able to reach the anonymous Home entry before any protected maintenance workflow exists in my path, so that public reading never requires identity.

• Trigger/input: the visitor lands on the site.
• Observable result: Home renders fully without any authentication prompt.
• Access state: anonymous.
• Failure/recovery: if a protected route is requested directly, the visitor is routed to Login without exposing protected state.
• Continuation: the visitor browses the public destinations.

4. User Personas

Portfolio Visitor / Prospective Client or Employer

Product context. A business-side reader — a business owner, operations lead, prospective client, or prospective employer — who evaluates systems people for a living and reads ERP screens, dashboards, and spreadsheets daily. They arrive from a link, a search, or a referral, with limited patience and a strong instinct for whether a portfolio is a template or a tool.

Primary goal. Decide quickly whether this person understands how businesses actually operate and can design the systems that run them.

Distinct accepted responsibilities. Browse the Home hero and absorb the core message; scan the "How I Build Systems" process; browse the Projects grid and filter by category (ERP, MIS, Inventory, HR, Automation, AI, Operations); open individual project case-study pages and read the twelve template sections; review the Experience timeline; read the About disciplines; view the Resume; read the Capabilities groups; use the command palette to jump directly to a project or section; and continue to Contact or the LinkedIn / GitHub / Email placeholders.

Relevant inputs or decisions. Which project to open; which category filter to apply; whether the case study's problem/architecture/automation sections read as real systems work; whether to reach out.

Interactions with other accepted participants. The visitor is the sole reader of the owner's published content; they never interact with the owner inside the product, and their only handoff is the outbound Contact or social channel.

Observable success. The visitor concludes the owner is a systems architect rather than a website builder, and either opens a case study, views the resume, or initiates contact.

Site Owner / Systems Architect (content maintainer)

Product context. The professional whose portfolio this is — a Business Systems Architect / Digital Transformation & MIS professional who designs and builds ERP systems, MIS platforms, inventory systems, workflow automation, HRMS, sales & purchase systems, follow-up/calling systems, ticketing tools, import management systems, operational dashboards, internal business software, and AI-powered business system tools. He currently works at Excel Sathi in a senior MIS / digital transformation / systems architecture role, understanding real business processes and converting them into structured digital systems.

Primary goal. Present his systems work credibly and keep the portfolio's centralized project data and content accurate and expandable without redesigning the site.

Distinct accepted responsibilities. Establish first-use access by invitation or provisioning; return and verify identity; maintain the centralized project data source (projects.js / projects.json) across the fields slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, and status; populate the reusable case-study template and section placeholders with accurate content later; add further experience entries; and keep the no-fabrication and branding rules intact.

Relevant inputs or decisions. Which project records to add or update; which fields are ready versus deferred; whether a value is confirmed or must remain a placeholder; the exact Excel Sathi title and dates, which are explicitly deferred.

Interactions with other accepted participants. The owner publishes for the visitor; the visitor's reading is the outcome the owner's maintenance serves. The owner does not interact with visitors inside the product.

Observable success. New projects and sections can be added without redesigning the site, and no invented date, metric, testimonial, certification, company relationship, revenue figure, unconfirmed technology, or impact percentage ever reaches the published surface.

5. Core User Flows

Flow A — Visitor evaluates the owner from the Home entry (Portfolio Visitor)

1. The visitor lands on Home anonymously; no identity is requested.
2. The hero renders the micro-label BUSINESS SYSTEMS ARCHITECT · MIS · AUTOMATION, the headline "I design the systems businesses run on.", and the supporting line naming ERP systems, MIS platforms, workflow automation, and internal business software.
3. The visitor reads the live architecture diagram: Sales, Inventory, Production, HR, Finance, and Operations feed the "Business System Architecture" node, which fans out to Automation, Dashboards, Approvals, Reports, and ERP. The loop communicates that the owner connects business functions together.
4. The visitor chooses a CTA: Explore My Work (continues into the process and projects content), View Projects (continues to Projects), or View Resume (continues to Resume).
5. The visitor scrolls the "How I Build Systems" rail, reading 01 Understand the Business through 08 Deploy and Improve, and concludes the owner solves business problems rather than only coding problems.
6. Failure/recovery: if the hero diagram fails to load, the node lists render as ruled label/value rows and the headline and CTAs remain fully legible; under prefers-reduced-motion the diagram is static and fully legible.
7. Continuation: the visitor continues to Projects, Experience, About, Resume, or Contact.

Flow B — Visitor browses and filters the project catalog (Portfolio Visitor)

1. The visitor opens Projects from the sticky nav, a hero CTA, or the command palette.
2. The grid renders the eight placeholder projects — Business ERP, Inventory & Order Management, Employee Timesheet System, Business Operations / Mini ERP, HRMS, Calling / Follow-Up System, Import Management System, and AI Business System Builder — each card showing title, short description, category, role, technologies, thumbnail, status, and case-study link.
3. The visitor selects a category filter from ERP, MIS, Inventory, HR, Automation, AI, or Operations.
4. The grid filters to matching projects and shows the active category.
5. Failure/recovery: if a category has no matches, a ruled empty state names the active category and offers a clear-filter action; if the data source fails to load, a ruled error state offers retry and no fabricated cards appear.
6. Continuation: the visitor opens a project card's case-study link.

Flow C — Visitor reads a project case study (Portfolio Visitor)

1. The visitor opens a project-detail route, for example /projects/business-erp, from a card, the command palette, or a direct URL.
2. The reusable ProjectCaseStudy template renders the twelve sections in order: 1. Project Hero, 2. Business Problem, 3. Before vs After Workflow, 4. System Architecture, 5. Modules, 6. Key Features, 7. Product Screens, 8. Automation Flow, 9. Technology Stack, 10. Business Impact, 11. What I Learned, 12. Next Project.
3. Sections that are not yet populated render explicit ruled "to be added" placeholders; no invented content appears.
4. The visitor navigates the sticky left rail of twelve section anchors to move between sections.
5. Failure/recovery: an unknown slug shows a ruled not-found state with a link back to Projects.
6. Continuation: the visitor continues to the Next Project section, which leads to another case study.

Flow D — Visitor reviews experience, positioning, resume, and capabilities (Portfolio Visitor)

1. The visitor opens Experience and reads the timeline's initial entry: Excel Sathi, role Senior MIS / Digital Transformation / Systems Architecture, with the exact title and dates shown as explicit deferred placeholders.
2. The visitor opens About and reads the concise statement that the work exists between Business Analysis, System Architecture, MIS, Automation, and Software Development, with the visual representation of those five disciplines.
3. The visitor opens Resume from the hero link or the sticky nav and views or downloads the resume; if no document is attached yet, a ruled notice states that it will be added.
4. The visitor reads the grouped capability cards — Business Systems, Development, Automation, Data & MIS, AI, Deployment — containing the skill placeholders ERP Architecture, Workflow Design, Google Apps Script, Google Sheets, JavaScript, HTML, CSS, API Integration, MIS, Dashboards, Automation, Gemini API, GitHub, and CLASP. No percentage bars appear.
5. Failure/recovery: if the discipline schematic fails, the five disciplines render as a ruled label list; if the resume fetch fails, a retry action is offered.
6. Continuation: the visitor continues to Contact.

Flow E — Visitor uses the command palette for quick navigation (Portfolio Visitor)

1. From any page, the visitor presses CMD + K or CTRL + K, or activates the bordered keycap trigger in the sticky nav.
2. The palette opens and lists the sections and all eight project slugs with their route hints (for example /projects/business-erp).
3. The visitor types to narrow the list and selects an entry.
4. The site navigates to that section or project.
5. Failure/recovery: pressing Escape closes the palette and returns focus to the trigger.
6. Continuation: the visitor continues reading at the destination.

Flow F — Visitor reaches out (Portfolio Visitor)

1. The visitor opens Contact from the Contact CTA, the sticky nav, or the command palette.
2. The page presents the contact affordances and the LinkedIn / GitHub / Email placeholders carried from the hero.
3. The visitor initiates contact through an available channel.
4. Failure/recovery: if a channel is not yet configured, its row shows a neutral placeholder rather than a broken link; if a submission fails, a specific message appears and the visitor's input is preserved.
5. Continuation: the visitor can retry or choose another channel.

Flow G — Owner establishes first-use access (Site Owner)

1. The owner arrives at Login, the anonymous entry boundary for the content-maintenance lifecycle.
2. The page presents the invitation/provisioning path; no public enrollment is offered.
3. The owner completes the invitation or provisioning step.
4. Failure/recovery: an invalid or expired credential shows a specific, non-enumerating message and preserves the entered context.
5. Continuation: the owner proceeds to returning verification.

Flow H — Owner returns and maintains project data and content (Site Owner)

1. The owner returns to Login and verifies identity.
2. Protected maintenance state becomes available; it was unavailable before verification.
3. The owner maintains the centralized project data source across the fields slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, and status.
4. The owner populates the reusable case-study template sections and section placeholders with accurate content, leaving anything unconfirmed as an explicit placeholder.
5. The owner adds further experience entries to the timeline, which accepts them without layout change.
6. Failure/recovery: a failed verification attempt shows a specific message and allows retry without losing the public session.
7. Continuation: the published Projects grid and project-detail routes reflect the updated records without redesign.

6. Visuals Colors and Theme

Muse: Rasmus Andersson. Headline: "Systems craft with an opinion — graphite ground, tabular numerals, one tangerine signal."

The direction is authoritative for this section. The register is systematic product craft with a point of view: dark, keyboard-first, numeric, with one non-blue accent so the site never reads as bootstrap SaaS. The audience reads ERP screens and dashboards all day and trusts surfaces that are precise, dense, and unornamented.

Colour tokens — dark mode (primary mode):

Accent rationing. Tangerine #FF6B2C is the single signal colour and appears only as: the active nav underline, the CTA fill, the live dot on the hero architecture diagram, focus rings, and one numeral per section. Status green #7FD1A8 appears only as "Shipped / Live" project status dots and diagram output nodes — never as a section colour. No blue, indigo, or violet anywhere, including links and chart lines; links and diagram strokes stay in warm neutrals, tangerine, or the rare status green.

Typography. Headings: Space Grotesk 500/600, tight tracking (−0.02em to −0.03em), sentence case, never all-caps for headlines. Body: Inter Tight. Micro-labels: 11px uppercase Inter Tight 600 with +0.14em tracking. Numerals: Inter Tight 500 with font-variant-numeric: tabular-nums, used at display sizes (32–56px) as ornament in stats and step markers. Scale: 1.333 modular on a 4/8-pt base. Hero display clamp(44px, 9vw, 104px). Section headings clamp(30px, 4.2vw, 52px). Sub-head clamp(20px, 2vw, 24px). Body 17px/1.65. Small 15px. Micro-label 11px uppercase +0.14em. Inter and Roboto are never the shipped heading or body font, and there is never a plain white ground.

Shape language. Rectilinear and hairline-driven: 1px borders, 10px radii on cards and 6px on controls, no pills, no blobs, no glass. Architecture and workflow diagrams are drawn as nodes (rounded 8px rectangles) joined by 1px orthogonal connectors with 2px arrowheads and small square junction dots; the same node grammar repeats at every scale so a diagram reads as the system's own UI. Density is the aesthetic: label/value rows, ruled data tables, and numerals given room to breathe.

Spacing rhythm. 4/8-pt base scale; 12-column grid, max-width 1200px, 24px gutters; asymmetric section rhythm (7/5 and 8/4 splits) rather than centred stacks; sticky top nav is a 56px bar with a hairline bottom border.

Imagery style. No photography, no stock people, no 3D renders. The imagery is the interface itself: hand-built SVG architecture diagrams, before/after workflow schematics, data-table crops, and code/Apps Script samples on the same graphite ground. Project thumbnails are generated diagram tiles — each project's own node graph drawn in the accent/muted pair — so the grid reads as a set of systems rather than a gallery of screenshots. Associated brands (Royal Enfield, NovaCare, Finviz) appear only as plain text in a hairline-ruled context strip, never as logos implying employment.

7. Signature Design Concept

The hero is a running system, not an illustration.

The public entry is a full-bleed graphite canvas (#121316) with no gradient blob. The left 5 columns carry an 11px uppercase micro-label BUSINESS SYSTEMS ARCHITECT · MIS · AUTOMATION, then the headline "I design the systems businesses run on." set in Space Grotesk 500 at clamp(44px, 9vw, 104px) with −0.03em tracking, broken across four lines so it fills the column edge to edge. Beneath it sits one 17px line of supporting copy naming ERP, MIS platforms, workflow automation, and internal business software, then a row of three CTAs — solid tangerine "Explore My Work", hairline-outlined "View Projects", text-link "View Resume" — and a hairline row of LinkedIn / GitHub / Email placeholders.

The right 7 columns, vertically centred and bleeding off the right viewport edge by roughly 40px, hold the live architecture diagram: six labelled input nodes (Sales, Inventory, Production, HR, Finance, Operations) stacked in a column, feeding through orthogonal connectors into a wide "Business System Architecture" node, which fans out to five output nodes (Automation, Dashboards, Approvals, Reports, ERP). The diagram animates as one slow loop; the headline never animates in more than a single 12px rise.

The concept is implementable entirely from accepted content and states: it recomposes the exact six inputs, the exact architecture node, and the exact five outputs the brief specifies, using the shared node grammar (8px-radius rects, 1px orthogonal connectors, square junction dots) that also draws the project thumbnails and the case-study diagrams. At 375px the diagram moves below the copy, scales to full width, and drops to a simplified 3-in / 3-out version; the headline wraps to a 44px stack and all CTAs remain whole and stacked full-width.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the live architecture diagram — six business-function nodes feeding the "Business System Architecture" node, which fans into five output nodes.
• Input → transformation → outcome thesis: the six business functions (Sales, Inventory, Production, HR, Finance, Operations) enter the architecture node and are transformed into connected outputs (Automation, Dashboards, Approvals, Reports, ERP) — the site's core claim shown as a running system rather than a stock illustration.
• Motion vocabulary: restrained and functional. 120–200ms cubic-bezier(0.2, 0.7, 0.2, 1) transitions only. The hero diagram runs one continuous, slow loop: dashed connectors draw their stroke-dashoffset over 6s, junction dots pulse at 2s intervals, and the six input nodes light in sequence — no particles, no glow, no bounce. Scroll reveals are a single 12px rise with opacity, staggered 40ms per item, once. Project cards lift 2px and raise their border to rgba(237,235,230,0.22) on hover, and the thumbnail's diagram strokes brighten. The command palette opens in 150ms with a scale from 0.98.
• Composed first frame: the static, fully legible diagram — all six input nodes, the architecture node, and all five output nodes drawn with their connectors and junction dots — with the headline and CTAs already in place.
• Reduced-motion state: every animation is disabled under prefers-reduced-motion, leaving static, fully legible diagrams; the hero shows the composed first frame with no loop, no reveals, and no hover lift.

9. Non-Functional Requirements

NFR-01 — Responsiveness (explicit) The website must be fully responsive for desktop, laptop, tablet, and mobile, with mobile feeling intentionally designed. Rationale: the brief names all four form factors and requires mobile to be deliberate rather than a degraded desktop. Readable text and controls stay whole and inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering them.

NFR-02 — Performance (explicit) The website must be fast, and animations must remain lightweight and professional. Rationale: the brief lists "fast" among quality requirements and constrains animation weight; the restrained 120–200ms timing and single-loop diagram follow from this.

NFR-03 — Accessibility (explicit) The website must be accessible, using semantic HTML with accessibility labels, keyboard navigation, and focus states, and must respect prefers-reduced-motion. Rationale: the brief requires accessibility labels, keyboard navigation, focus states, and reduced-motion support; the command palette is keyboard-first by design.

NFR-04 — SEO (explicit) The website must be SEO-friendly, with basic page titles, meta descriptions, and OpenGraph structure. Rationale: the brief names SEO-friendliness and these three metadata elements explicitly.

NFR-05 — Maintainability and structure (explicit) The website must be cleanly structured and easy to maintain, using reusable components (Navbar, Hero, ProjectCard, ProjectGrid, ExperienceTimeline, ArchitectureDiagram, WorkflowDiagram, CapabilityCard, ContactCTA, Footer, ProjectCaseStudy) without duplicating content unnecessarily, and reading project pages from the centralized project data source wherever possible. Rationale: the brief requires reusable components, a centralized data source, and no unnecessary duplication.

NFR-06 — Production quality (explicit) The website must be visually impressive and production-quality. Rationale: the brief lists both among quality requirements and states the portfolio itself should feel like a technology product.

NFR-07 — Content integrity (explicit) No invented job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, unconfirmed technologies, or business impact percentages may appear; unpopulated fields render as explicit placeholders. Rationale: the brief's no-fabrication rule and its instruction to add accurate content later.

NFR-08 — Branding integrity (explicit) Formative must never be mentioned; the owner must never be presented as a founder; projects are presented simply as systems or projects personally designed or developed; and Royal Enfield, NovaCare, Finviz, and other associated organizations must never be presented in a way that implies direct employment. Rationale: the brief's branding rules.

NFR-09 — Visual direction compliance (explicit) The site must use a dark or near-black theme with strong typography, subtle gradients, soft borders, animated background details, smooth scrolling, premium hover states, subtle parallax, clean cards, architecture diagrams, workflow visualizations, and polished page transitions, and must avoid generic developer portfolio templates, skill percentage bars, excessive neon, gaming aesthetics, unnecessary glassmorphism, random animations, and cliché coding illustrations. Rationale: the brief's design direction and avoid list.

NFR-10 — Owner identity continuity (required_inference) The owner's content-maintenance lifecycle requires first-use access by invitation or provisioning and returning verification, because the centralized project data and portfolio content are durable, owner-specific state that must remain bound to the correct person. Rationale: without this, the accepted maintenance journey cannot be executed; no public enrollment, role management, or permission tiers are implied.

10. Tech Stack

• Frontend: React (component-based SPA with client-side routing for the six primary destinations and the seven /projects/* routes). Rationale: the brief requires reusable components, routing architecture, and polished page transitions; React is the natural fit for the named component set.
• Project data: a centralized projects.js or projects.json module consumed by ProjectGrid, ProjectCard, and ProjectCaseStudy. Rationale: explicitly requested as the single source for project pages.
• Styling: CSS with custom properties for the token set in Section 6 (graphite ground, hairlines, tangerine accent, tabular numerals), plus SVG for all architecture and workflow diagrams. Rationale: the direction's hairline-and-node grammar is best expressed in CSS custom properties and hand-built SVG.
• Backend / API: a lightweight Python/FastAPI service for the owner's identity lifecycle (invitation/provisioning, returning verification, session continuity) and for serving project data. Rationale: the owner maintenance lifecycle requires server-side identity handling; the public site remains readable without it.
• Storage: a persistent store for owner identity records and the project data source. Rationale: durable owner-specific state and durable project records.
• Containerization: Docker / docker-compose for local and deployment parity. Rationale: standard, and keeps the foundation reproducible.
• Kubernetes: not required for this build; the deployment does not require orchestration at this scope.

11. Assumptions and Constraints

Assumptions

• A1 (required_inference): The owner's content-maintenance lifecycle is the only identity boundary; the public site is fully anonymous.
• A2 (required_inference): First-use access is by invitation or provisioning, with no public enrollment, because no enrollment lifecycle is established in the source.
• A3 (required_inference): Project-detail routes resolve from the centralized project data source through the single reusable template.
• A4 (explicit): The eight project placeholders and the Excel Sathi entry are foundation content; their detailed fields, exact title, and dates are populated later.
• A5 (explicit): The associated brands (Royal Enfield, NovaCare, Finviz, and others) are referenced as plain-text context only.

Constraints

• C1 (explicit): Do NOT mention Formative anywhere.
• C2 (explicit): Do NOT present the owner as a founder.
• C3 (explicit): Projects are presented simply as systems or projects personally designed or developed.
• C4 (explicit): Do not invent job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, technologies not confirmed, or business impact percentages; accurate content is added later.
• C5 (explicit): Do not imply direct employment by Royal Enfield, NovaCare, Finviz, or other associated organizations.
• C6 (explicit): Do not fully populate every project or every section in this first build.
• C7 (explicit): Do not fully write all project case studies yet; the structure must allow them to be added later without redesigning the website.
• C8 (explicit): Do not fabricate detailed project content yet.
• C9 (explicit): Do not write a long biography in the About section yet.
• C10 (explicit): The exact Excel Sathi title and dates are added later.
• C11 (explicit): Do not copy any website directly.
• C12 (explicit): Avoid generic developer portfolio templates, skill percentage bars, excessive neon, gaming aesthetics, unnecessary glassmorphism, random animations, and cliché coding illustrations.
• C13 (explicit): Do not duplicate content unnecessarily across components.
• C14 (explicit): Animations must remain lightweight and professional.
• C15 (explicit): Do NOT spend time inventing detailed project content in this first build.
• C16 (explicit): No blue, indigo, or violet anywhere — links, focus rings, chart lines, and diagram strokes stay in warm neutrals, tangerine, or the rare status green.
• C17 (explicit): Inter or Roboto are never the shipped heading or body font; there is never a plain white ground.
• C18 (explicit): No glassmorphism, gradient blobs, glow, neon, particles, or any 3D or photography-led hero.
• C19 (explicit): No skill percentage bars, star ratings, or any invented metric, date, testimonial, or company relationship.
• C20 (explicit): Logos of Royal Enfield, NovaCare, or Finviz are never presented as employer branding; they appear as plain text context only.
• C21 (explicit): No decorative motion that runs without a functional reason, and no animation that ignores prefers-reduced-motion.

12. Glossary

• Business Systems Architect — The owner's professional positioning: someone who studies how a business operates, understands its workflows, identifies problems, designs the data structure, builds the system, automates repetitive work, and creates management reporting.
• MIS — Management Information Systems: the reporting and management-information layer of a business system, including dashboards and operational reporting.
• ERP — Enterprise Resource Planning: an integrated business system spanning functions such as sales, inventory, production, HR, and finance.
• HRMS — Human Resource Management System.
• Architecture diagram — A hand-built SVG node graph using the shared node grammar (8px-radius rectangles, 1px orthogonal connectors, square junction dots) that depicts how business functions connect to a system and what that system produces.
• Workflow diagram — A schematic in the same node grammar depicting a process, including before/after workflow comparisons.
• Node grammar — The single shared visual language for all diagrams: rounded 8px rectangles joined by 1px orthogonal connectors with 2px arrowheads and small square junction dots, repeated at every scale.
• Tabular numerals — Numerals set with font-variant-numeric: tabular-nums so digits align in columns; used as ornament at display sizes for step markers, section markers, and stats.
• Hairline — A 1px border at rgba(237,235,230,0.10) used to separate panels and rule label/value rows instead of card chrome.
• Command palette — The keyboard-first overlay opened with CMD + K or CTRL + K that lists sections and all eight project slugs with their route hints.
• Project data source — The centralized projects.js or projects.json module holding each project's slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, and status.
• Project case-study template — The single reusable ProjectCaseStudy component rendering the twelve sections: Project Hero, Business Problem, Before vs After Workflow, System Architecture, Modules, Key Features, Product Screens, Automation Flow, Technology Stack, Business Impact, What I Learned, Next Project.
• Placeholder — An explicit, ruled "to be added" state shown where content is deferred, used instead of inventing any value.
• prefers-reduced-motion — The user's operating-system motion preference; when set, every animation is disabled and diagrams render static and fully legible.