System Requirements Document for deepak

1. Introduction

deepak is a premium personal portfolio website for a Business Systems Architect / Digital Transformation & MIS professional.

The website shall communicate the core message:

“I design the systems businesses run on.”

It shall position the portfolio owner as a professional who combines:

• Business Analysis
• System Architecture
• MIS
• Automation
• Software Development

The portfolio shall help visitors understand that the owner does not simply build websites. The portfolio shall communicate a systems-oriented approach: studying business operations, understanding workflows, identifying bottlenecks, designing data structures, building systems, automating repetitive work, and creating management reporting.

The first release is a portfolio foundation. It shall prioritize design system quality, routing, reusable components, centralized project data, responsive behavior, visual storytelling, and case-study extensibility. It shall not attempt to fully populate project case studies or introduce unverified professional claims.

2. System Overview

deepak shall be delivered as a public, responsive, first-party portfolio website with custom user interfaces.

The website shall provide public destinations for:

1. Home
2. Projects
3. Project Detail
4. Experience
5. About
6. Resume
7. Contact

The website shall support Portfolio Visitors who want to understand the owner’s positioning, capabilities, systems work, experience foundation, project foundation, and contact paths. It shall also support the Portfolio Owner’s future content-maintenance workflow through reusable data structures and templates rather than duplicated page content.

The website shall present the portfolio owner’s current professional context at Excel Sathi in a senior MIS / digital transformation / systems architecture role. The exact title and employment dates shall remain unpopulated until accurate details are supplied.

The system shall present projects as systems or projects personally designed or developed. It shall not present the owner as a founder. It shall not imply direct employment by Royal Enfield, NovaCare, Finviz, or other organizations associated with projects.

2a. Product Interpretation and Delivery Boundary

The current product is a public portfolio foundation, not a complete professional profile database, hiring platform, CRM, client portal, or project-management system.

All current destinations shall be publicly accessible without account creation, sign-in, role-based permissions, or private visitor state.

The website shall provide:

• A systems-focused public portfolio experience.
• Reusable design and component architecture.
• A centralized project data source.
• A reusable project case-study template.
• Placeholder-based professional and project content structures.
• Public navigation and contact placeholders.
• Responsive layouts for desktop, laptop, tablet, and mobile.
• Lightweight, professional interaction and motion foundations.

The website shall not currently provide:

• Fabricated detailed project case studies.
• Invented project metrics, outcomes, or business impact percentages.
• Invented job dates, education, certifications, testimonials, revenue figures, or company relationships.
• Unconfirmed technologies.
• A claim of direct employment by Royal Enfield, NovaCare, Finviz, or other associated organizations.
• Any mention of the prohibited brand name specified in the source requirements.
• A founder positioning.
• Skill percentage bars.
• A generic developer-portfolio presentation.

Future accurate project, experience, resume, social-profile, and case-study content may be added without redesigning the site architecture.

2b. Page Content and Component Coverage

Home

• Information and state

  • Public entry surface for the portfolio.
  • Core positioning as a Business Systems Architect / Digital Transformation & MIS professional.
  • Exact primary headline: “I design the systems businesses run on.”
  • Supporting message communicating ERP systems, MIS platforms, workflow automation, and internal business software.
  • Concise systems-oriented explanation of how business operations are transformed into structured digital systems.

• Primary actions

  • “Explore My Work” shall route visitors to the Projects destination.
  • “View Projects” shall route visitors to the Projects destination.
  • “View Resume” shall route visitors to the Resume destination.
  • Navigation links shall route to Home, Projects, Experience, About, Resume, and Contact.
  • Command palette activation shall be available through CMD + K or CTRL + K where supported.

• Hero architecture visual

  • The Home hero shall show the following business functions as inputs:
    • Sales
    • Inventory
    • Production
    • HR
    • Finance
    • Operations
  • The inputs shall flow into a central architecture node:
    • Business System Architecture
  • The architecture node shall produce the following outputs:
    • Automation
    • Dashboards
    • Approvals
    • Reports
    • ERP
  • The diagram shall visually communicate that business functions are connected through a structured system architecture.
  • On desktop, the hero shall use a deliberate split-stage layout:
    • Left operational field for headline, supporting content, input ledger, and CTAs.
    • Right architecture canvas for the system diagram.
  • On mobile, the diagram shall become clear stacked input → architecture → output bands.

• Supporting sections

  • A concise “How I Build Systems” process visualization.
  • Grouped capability cards.
  • A selected-project entry point linking to Projects.
  • A contact call-to-action linking to Contact.
  • Footer navigation and social/contact placeholders.

• Component responsibilities

  • Navbar: sticky public navigation and command palette trigger.
  • Hero: split-stage headline, supporting message, CTAs, and architecture composition.
  • ArchitectureDiagram: input, architecture, and output relationship visualization.
  • WorkflowDiagram: reusable workflow visualization foundation.
  • CapabilityCard: grouped skill-placeholder presentation without proficiency percentages.
  • ContactCTA: route to Contact.
  • Footer: navigation and placeholder social/contact links.

• States

  • Default public loading state shall render content without animation dependency.
  • Reduced-motion state shall show the full architecture diagram statically.
  • Navigation and CTA failures shall preserve visible text links and keyboard access.
  • Placeholder social links shall be visibly identified as placeholders until accurate destinations are provided.

Projects

• Information and state

  • Public projects index.
  • Centralized project data shall provide project cards.
  • Initial project placeholders shall include:
    • Business ERP
    • Inventory & Order Management
    • Employee Timesheet System
    • Business Operations / Mini ERP
    • HRMS
    • Calling / Follow-Up System
    • Import Management System
    • AI Business System Builder
  • Project data shall remain intentionally concise until accurate content is provided.

• Primary actions

  • Visitors shall filter visible projects by category.
  • Visitors shall open a project’s individual case-study route.
  • Visitors shall navigate back to other primary destinations using the shared navigation.

• Filtering categories

  • ERP
  • MIS
  • Inventory
  • HR
  • Automation
  • AI
  • Operations

• Project card information

  • Project title.
  • Short description placeholder.
  • Category.
  • Role.
  • Technologies.
  • Thumbnail or authored system-diagram placeholder.
  • Status.
  • Case-study link.

• Component responsibilities

  • ProjectGrid: renders centrally sourced project records and filter results.
  • ProjectCard: presents context, category, role, status, thumbnail region, technology placeholders, and case-study route.
  • Project cards shall use a paired context/system dossier treatment.
  • Hover and keyboard focus may reveal a compact mono architecture strip and case-study route.
  • Project cards shall not rely on lift-shadow theatrics.

• States

  • Loading state shall preserve the page structure while project records initialize.
  • Empty state shall explain that no projects match the selected category without inventing content.
  • Success state shall present project cards sourced from centralized data.
  • Invalid or unavailable route state shall direct visitors back to Projects.
  • Filters shall remain keyboard accessible and visibly selected.

Project Detail

• Information and state

  • Public reusable project-detail route for project slugs.
  • Individual project routes shall be structured to support, at minimum:
    • /projects/business-erp
    • /projects/inventory-management
    • /projects/timesheet-system
    • /projects/hrms
    • /projects/follow-up-system
    • /projects/import-management
    • /projects/ai-business-system-builder
  • The implementation may also support a route pattern such as /projects/:slug.
  • Project detail content shall read from the centralized project data source wherever possible.
  • The initial release shall use placeholders rather than fabricated case-study content.

• Reusable ProjectCaseStudy 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

• Primary actions

  • Visitors shall navigate between project detail, Projects, and other primary pages.
  • Visitors shall use an anchored section index where supported.
  • Visitors shall use a route breadcrumb to return to Projects.

• Component responsibilities

  • ProjectCaseStudy: renders case-study sections conditionally from project data.
  • ArchitectureDiagram: displays project architecture when accurate architecture content is available.
  • WorkflowDiagram: displays before/after workflow and automation-flow structures when accurate content is available.
  • Project navigation shall provide a Next Project path when valid project data exists.

• States

  • Placeholder state shall clearly indicate that complete case-study content will be added later.
  • Missing project state shall provide a clear route back to Projects.
  • Empty optional fields shall not generate fabricated detail.
  • Reduced-motion state shall display diagrams and section content without animated transitions.

Experience

• Information and state

  • Public professional-experience foundation.
  • A modern timeline/component shall support future role expansion.
  • Initial entry:
    • Organization: Excel Sathi
    • Role: Senior MIS / Digital Transformation / Systems Architecture
  • Exact title and dates shall be marked as content to be added later.

• Primary actions

  • Visitors shall review the current timeline foundation.
  • Visitors shall continue to Resume, Projects, About, or Contact using shared navigation and contextual links.

• Component responsibilities

  • ExperienceTimeline: displays existing and future structured experience entries.
  • Timeline metadata shall use clear “To be added” treatment when dates or exact title data are not confirmed.

• States

  • Initial state shall show the Excel Sathi foundation entry.
  • Future entries shall be addable through the same data structure.
  • Missing dates or exact title data shall remain intentionally unpopulated rather than inferred.

About

• Information and state

  • Public concise positioning destination.
  • The page shall explain that the owner’s work exists between:
    • Business Analysis
    • System Architecture
    • MIS
    • Automation
    • Software Development
  • The page shall explain the transformation from real business processes to structured digital systems.
  • The page shall not contain a long biography.

• Primary actions

  • Visitors shall explore the discipline relationship visual.
  • Visitors shall continue to Projects, Experience, Resume, or Contact.

• Component responsibilities

  • Discipline visualization shall represent the five named areas as connected parts of one systems practice.
  • Layout shall preserve the business-language-to-system-output dialogue.

• States

  • Content shall remain concise and factual.
  • Unverified biography, education, certifications, metrics, or company relationships shall not be rendered.

Resume

• Information and state

  • Public resume destination.
  • The page shall provide a structured foundation for accurate resume content to be added later.
  • It shall be reachable from global navigation and the “View Resume” Home CTA.

• Primary actions

  • Visitors shall review the resume foundation.
  • Visitors shall navigate to Experience, Projects, or Contact.

• Component responsibilities

  • Resume layout shall support future professional summary, experience, systems work, and accurate supporting details.
  • No download file shall be implied or fabricated unless later supplied.

• States

  • The page shall clearly preserve placeholders for information not yet provided.
  • Missing downloadable resume content shall not produce a broken download control.

Contact

• Information and state

  • Public contact destination.
  • Placeholder paths shall be prepared for:
    • LinkedIn
    • GitHub
    • Email

• Primary actions

  • Visitors shall select an available contact path once accurate destinations are supplied.
  • Visitors shall return to Home or explore the portfolio through global navigation.

• Component responsibilities

  • Contact links shall have accessible labels.
  • Placeholder status shall be visibly communicated until accurate URLs or email details are added.

• States

  • Available contact destinations shall open or route correctly.
  • Unconfigured placeholders shall not masquerade as active contact endpoints.
  • Keyboard users shall be able to identify and operate each contact action.

3. Functional Requirements

FR-01 — Portfolio Foundation

As a Portfolio Visitor, I should be able to access a premium public portfolio foundation so that I can understand the owner’s systems-focused professional positioning.

• Provenance: explicit
• Access: public; no account required.
• Trigger/Input: Visitor opens any public portfolio route.
• Observable result: The website presents a coherent premium portfolio experience with shared navigation, consistent visual language, and public content.
• Failure/Recovery: If a route is unavailable, the visitor shall receive a clear path back to Home or Projects.
• Continuation: The visitor may navigate to any primary destination.
• Acceptance criteria:
  • The portfolio shall be responsive, visually polished, structured, maintainable, accessible, fast, SEO-friendly, and production-quality.
  • The first build shall prioritize visual design, architecture, reusable components, navigation, centralized project data, reusable project template, responsiveness, and animation foundation.
  • The first build shall not fully populate every project or section.

FR-02 — Systems-Focused Positioning

As a Portfolio Visitor, I should be able to understand that the portfolio owner designs systems businesses run on so that I can distinguish the work from conventional website development.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor views Home or About.
• Observable result: The visitor sees the exact headline “I design the systems businesses run on.” and supporting systems-focused positioning.
• Failure/Recovery: If diagram motion cannot load or is disabled, the static content and complete diagram labels shall remain available.
• Continuation: The visitor may explore projects, experience, resume, or contact paths.
• Acceptance criteria:
  • Supporting messaging shall communicate ERP systems, MIS platforms, workflow automation, and internal business software.
  • The site shall communicate the combination of Business Analysis, System Architecture, MIS, Automation, and Software Development.
  • The site shall communicate a workflow of understanding operations, mapping workflows, identifying problems, designing data structures, building systems, automating repetitive work, and creating management reporting.
  • The presentation shall make visitors understand that the owner does not just build websites.

FR-03 — Public Navigation and Command Palette

As a Portfolio Visitor, I should be able to navigate among primary portfolio destinations so that I can quickly reach relevant information.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor selects navigation links or invokes CMD + K / CTRL + K.
• Observable result: The selected destination opens.
• Failure/Recovery: If command palette keyboard shortcuts are unavailable or unsupported, visible navigation shall remain fully operable.
• Continuation: The visitor may select another destination or return to Home.
• Acceptance criteria:
  • A sticky navigation shall include Home, Projects, Experience, About, Resume, and Contact.
  • The command palette shall support quick navigation to sections and projects where implemented.
  • The command palette shall use a systems-console visual treatment with grouped destinations, mono route labels, visible CMD/CTRL + K keycaps, and a chartreuse active-row rule.
  • Navigation shall be keyboard accessible and provide visible focus states.

FR-04 — Home Hero and Architecture Flow

As a Portfolio Visitor, I should be able to view a business-function-to-system-architecture visual so that I can understand how the owner connects operational functions into system outcomes.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens Home.
• Observable result: Sales, Inventory, Production, HR, Finance, and Operations flow into Business System Architecture, which produces Automation, Dashboards, Approvals, Reports, and ERP.
• Failure/Recovery: When motion is reduced or unavailable, a complete static diagram shall remain visible and readable.
• Continuation: The visitor may select “Explore My Work,” “View Projects,” or “View Resume.”
• Acceptance criteria:
  • The hero shall include the exact primary headline.
  • The hero shall provide the three required CTAs.
  • The architecture visual shall communicate connected business functions.
  • Desktop layout shall maintain left business/process content and right architecture/system output.
  • Mobile layout shall stack readable input, architecture, and output bands.

FR-05 — Projects Grid and Filtering

As a Portfolio Visitor, I should be able to browse and filter project placeholders so that I can identify relevant systems work.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens Projects and selects a category filter.
• Observable result: Project cards update to show matching project placeholders.
• Failure/Recovery: If no project matches a selected category, the page shall show an accessible empty state and retain filter controls.
• Continuation: The visitor may change filters or open a project detail route.
• Acceptance criteria:
  • Project cards shall support title, short description, category, role, technologies, thumbnail, status, and case-study link.
  • The initial project placeholders shall include all eight supplied project names.
  • Filters shall include ERP, MIS, Inventory, HR, Automation, AI, and Operations.
  • Project content shall remain placeholder-driven until accurate details are provided.
  • The project grid shall not fabricate technologies, metrics, impacts, or detailed case-study content.

FR-06 — Centralized Project Data

As a Portfolio Owner, I should be able to maintain project records in a centralized project data source so that project listings and project-detail pages can expand without duplicated content.

• Provenance: explicit
• Access: implementation-maintenance responsibility; no public editing interface is required.
• Trigger/Input: The Portfolio Owner or implementation maintainer updates a centralized project record.
• Observable result: Project grid and corresponding project-detail template can read shared project data where applicable.
• Failure/Recovery: Missing optional data shall render as an intentional placeholder or omit the unsupported section; it shall not create invented content.
• Continuation: The maintained record can be used by Projects and Project Detail routes.
• Acceptance criteria:
  • A centralized source such as projects.js or projects.json shall be used.
  • Project records shall support: slug, title, description, category, role, technologies, problem, solution, modules, features, architecture, impact, learnings, screenshots, and status.
  • Project pages shall read from this centralized data wherever possible.
  • The system shall avoid unnecessary content duplication.

FR-07 — Reusable Project Detail Template

As a Portfolio Visitor, I should be able to open an individual project route so that I can review a structured case-study foundation when accurate details become available.

• Provenance: explicit, with route ownership required_inference.
• Access: public.
• Trigger/Input: Visitor selects a case-study link from a project card or opens a supported project route.
• Observable result: A reusable Project Detail layout loads the relevant project record and case-study sections.
• Failure/Recovery: Unknown slugs shall show a clear not-found state with a route back to Projects.
• Continuation: The visitor may use section navigation, return to Projects, or open the next available project.
• Acceptance criteria:
  • The reusable template shall support all twelve specified case-study sections.
  • Individual project pages shall be structurally ready without fully writing all project case studies.
  • Routes shall support the supplied example project paths.
  • Project detail pages shall use a route breadcrumb and anchored section index where supported.
  • Unsupported project facts shall remain unpopulated.

FR-08 — Experience Foundation

As a Portfolio Visitor, I should be able to view the professional experience foundation so that I can understand the owner’s current role context.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens Experience.
• Observable result: The visitor sees an extensible modern experience timeline with an Excel Sathi entry.
• Failure/Recovery: Missing exact title or dates shall be shown as intentionally pending rather than inferred.
• Continuation: The visitor may navigate to Resume, Projects, About, or Contact.
• Acceptance criteria:
  • The timeline shall include Excel Sathi.
  • The role shall be represented as Senior MIS / Digital Transformation / Systems Architecture.
  • Exact title and dates shall be added later.
  • The timeline shall support future role entries.

FR-09 — About Foundation

As a Portfolio Visitor, I should be able to view a concise explanation of the owner’s combined disciplines so that I can understand the approach behind the systems work.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens About.
• Observable result: The visitor sees a concise explanation and visual representation of Business Analysis, System Architecture, MIS, Automation, and Software Development.
• Failure/Recovery: If an enhanced visual cannot load, all discipline labels and explanatory text shall remain available.
• Continuation: The visitor may continue to Projects, Experience, Resume, or Contact.
• Acceptance criteria:
  • About shall not become a long biography.
  • The visual shall reinforce the relationship between the five supplied disciplines.
  • Unsupported personal history shall not be introduced.

FR-10 — How I Build Systems Process

As a Portfolio Visitor, I should be able to review the system-building process so that I can understand that the portfolio owner solves business problems through structured system design.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor reaches the process section on Home.
• Observable result: The visitor sees the eight-step process.
• Failure/Recovery: If scroll-linked or reveal motion is unavailable, all process steps shall remain visible in sequence.
• Continuation: The visitor may proceed to projects or contact paths.
• Acceptance criteria:
  • The process shall contain:
    1. Understand the Business
    2. Map the Workflow
    3. Identify Bottlenecks
    4. Design the Data Architecture
    5. Build the System
    6. Automate Repetitive Processes
    7. Create MIS & Reporting
    8. Deploy and Improve
  • The desktop composition shall use an eight-step vertical execution rail.
  • Odd-numbered business-discovery steps shall sit left of the split seam.
  • Even-numbered system-delivery steps shall sit right of the split seam.
  • Active-step connection may use a chartreuse route line.

FR-11 — Capability Groups

As a Portfolio Visitor, I should be able to review grouped capability areas so that I can understand the scope of systems-oriented work without misleading skill rankings.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor views capabilities on Home or an applicable shared section.
• Observable result: The visitor sees grouped cards with supplied placeholder skills.
• Failure/Recovery: Missing future capability content shall remain a placeholder rather than a fabricated claim.
• Continuation: The visitor may explore relevant projects or contact paths.
• Acceptance criteria:
  • Capability groups shall include:
    • Business Systems
    • Development
    • Automation
    • Data & MIS
    • AI
    • Deployment
  • The foundation shall support placeholders for:
    • ERP Architecture
    • Workflow Design
    • Google Apps Script
    • Google Sheets
    • JavaScript
    • HTML
    • CSS
    • API Integration
    • MIS
    • Dashboards
    • Automation
    • Gemini API
    • GitHub
    • CLASP
  • The system shall not use skill percentage bars.
  • The system shall not imply unsupported proficiency levels or unconfirmed technology use.

FR-12 — Resume Foundation

As a Portfolio Visitor, I should be able to open a Resume destination so that I can review accurate resume content when it is later supplied.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor selects “View Resume” or opens Resume from navigation.
• Observable result: The Resume destination opens with a structured, extensible foundation.
• Failure/Recovery: If no downloadable resume is available, the system shall not show a broken or fabricated download action.
• Continuation: The visitor may navigate to Experience, Projects, or Contact.
• Acceptance criteria:
  • Resume shall be a dedicated public destination.
  • The page shall be prepared for accurate future content.
  • The page shall not invent education, certifications, dates, or other resume facts.

FR-13 — Contact Placeholders

As a Portfolio Visitor, I should be able to identify prepared LinkedIn, GitHub, and Email contact paths so that I can contact the portfolio owner when accurate destinations are supplied.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens Contact or uses footer contact links.
• Observable result: The visitor sees LinkedIn, GitHub, and Email placeholders.
• Failure/Recovery: Unconfigured links shall be clearly marked and shall not falsely appear active.
• Continuation: The visitor may return to Home or navigate elsewhere.
• Acceptance criteria:
  • Contact paths shall be accessible by keyboard.
  • Contact controls shall have accessible labels.
  • Accurate URLs and email details may be supplied later without redesigning the contact layout.

FR-14 — Motion, Interaction, and Reduced Motion

As a Portfolio Visitor, I should experience lightweight professional interactions so that the portfolio feels technically polished without sacrificing clarity or accessibility.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor scrolls, hovers, focuses, moves a pointer, activates controls, or loads a route.
• Observable result: The website provides restrained visual feedback and architecture-oriented motion.
• Failure/Recovery: With prefers-reduced-motion, all information and navigation shall be immediately available without dependent animation.
• Continuation: The visitor can continue using all controls and content.
• Acceptance criteria:
  • The website may use 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.
  • Motion shall remain lightweight and professional.
  • Motion shall not use random animation, particle fields, bounce effects, decorative floating cards, gaming aesthetics, or excessive neon.
  • Reduced-motion mode shall render the complete connected architecture diagram statically.

FR-15 — Responsive, Accessible, and Search-Friendly Delivery

As a Portfolio Visitor, I should be able to access readable, usable portfolio content on desktop, laptop, tablet, and mobile so that I can explore the portfolio regardless of device or input method.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor opens the site on a supported viewport or uses keyboard navigation.
• Observable result: Content, controls, navigation, diagrams, and page structure remain usable and readable.
• Failure/Recovery: If enhanced layout or motion cannot be used, semantic content and links shall remain accessible.
• Continuation: The visitor can complete any public navigation journey.
• Acceptance criteria:
  • The website shall be intentionally responsive for desktop, laptop, tablet, and mobile.
  • Mobile shall feel intentionally designed.
  • Readable text and controls shall remain entirely inside their containers and viewport at 375px, 768px, and 1280px.
  • Semantic HTML shall be used.
  • The site shall include page titles, meta descriptions, OpenGraph structure, accessibility labels, keyboard navigation, and focus states.
  • Responsive behavior shall not hide required content behind unsupported gestures.

FR-16 — Professional Representation and Content Integrity

As a Portfolio Visitor, I should receive accurate, appropriately scoped professional information so that I can evaluate the portfolio without being misled by invented claims.

• Provenance: explicit
• Access: public.
• Trigger/Input: Visitor reads any portfolio content.
• Observable result: Content presents only supplied professional facts and clearly maintained placeholders.
• Failure/Recovery: When accurate content is missing, the system shall preserve an intentional placeholder or omit the unsupported detail.
• Continuation: Accurate content may be added later through the reusable architecture.
• Acceptance criteria:
  • The website shall not mention the prohibited brand name specified in the source requirements.
  • The website shall not present the owner as a founder.
  • Projects shall be presented as systems or projects personally designed or developed.
  • The website shall not imply direct employment by Royal Enfield, NovaCare, Finviz, or other associated organizations.
  • The website shall not invent job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, unconfirmed technologies, or business impact percentages.

4. User Personas

Portfolio Visitor

• Provenance: required_inference from Planning Scope.
• Product context: A public visitor evaluating whether the portfolio owner understands business operations and can design the systems that support them.
• Primary goal: Understand the owner’s systems-oriented positioning and explore relevant project, experience, capability, resume, and contact foundations.
• Distinct responsibilities and decisions:
  • Review the Home positioning and architecture visual.
  • Browse and filter project placeholders by relevant category.
  • Open available project detail routes.
  • Review the Excel Sathi experience foundation.
  • Review the concise cross-discipline About explanation.
  • Use Resume and Contact destinations when relevant.
  • Use navigation or the command palette to move quickly between destinations.
• Relevant inputs: Navigation selections, project-category filters, project-card selections, command palette actions, pointer interaction, keyboard interaction, and reduced-motion preferences.
• Interaction with other accepted participants: The visitor does not require a direct human handoff. The visitor consumes public content maintained by the Portfolio Owner.
• Observable success: The visitor understands that the owner designs business systems, connects business functions to structured system architecture, and has a foundation of relevant systems work to explore.

Portfolio Owner

• Provenance: explicit.
• Product context: The professional represented by the portfolio and the future supplier of accurate project, experience, resume, social, and case-study content.
• Primary goal: Expand the portfolio with accurate information without redesigning its pages, routing, visual system, or reusable component structure.
• Distinct responsibilities and decisions:
  • Supply accurate project data for centralized project records.
  • Supply accurate project descriptions, categories, roles, technologies, architecture details, modules, features, screens, impact information, and learnings when available.
  • Supply accurate experience title and dates for the Excel Sathi entry.
  • Supply accurate LinkedIn, GitHub, email, and resume details later.
  • Decide when placeholders can be replaced with verified content.
• Relevant inputs: Project data fields, verified professional details, verified technology information, approved case-study content, and accurate contact links.
• Interaction with other accepted participants: The owner’s maintained content becomes publicly observable to Portfolio Visitors through the existing site architecture.
• Observable success: Accurate content can be added through centralized data and reusable templates without duplicating content or redesigning the portfolio foundation.

5. Core User Flows

Flow 1 — Understand the Systems-Focused Positioning

1. The Portfolio Visitor opens Home.
2. The visitor sees the exact headline: “I design the systems businesses run on.”
3. The visitor reads supporting content about ERP systems, MIS platforms, workflow automation, and internal business software.
4. The visitor reviews the input ledger containing Sales, Inventory, Production, HR, Finance, and Operations.
5. The visitor sees these functions converge into the Business System Architecture node.
6. The visitor sees system outcomes branch to Automation, Dashboards, Approvals, Reports, and ERP.
7. The visitor decides whether to explore work, projects, or resume content.
8. The visitor selects “Explore My Work,” “View Projects,” or “View Resume.”
9. The selected public destination opens.
10. If reduced motion is enabled, the full system diagram is visible without animation and all CTA actions remain available.

Flow 2 — Browse and Filter Projects

1. The Portfolio Visitor opens Projects from navigation, a Home CTA, or the command palette.
2. The Projects page loads centralized project placeholder records.
3. The visitor reviews the available project cards.
4. The visitor selects a category such as ERP, MIS, Inventory, HR, Automation, AI, or Operations.
5. The ProjectGrid updates to show matching project cards.
6. The visitor reviews each card’s available title, category, role, technologies, thumbnail area, status, and case-study path.
7. The visitor selects a case-study link.
8. The corresponding Project Detail route opens.
9. If no projects match the selected category, the visitor sees an empty state and can choose another category.

Flow 3 — Review a Project Detail Foundation

1. The Portfolio Visitor opens a route such as /projects/business-erp.
2. The Project Detail page reads the project record from the centralized data source.
3. The visitor sees the project hero and available placeholder-based case-study structure.
4. The visitor uses the breadcrumb to understand the route back to Projects.
5. The visitor may use the anchored section index to move among 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.
6. If a section lacks accurate content, it remains intentionally unpopulated or uses an approved placeholder rather than fabricated information.
7. The visitor may return to Projects or select the next valid project route.
8. If the route slug is unavailable, the visitor sees a not-found state and a route back to Projects.

Flow 4 — Review Experience Context

1. The Portfolio Visitor selects Experience from the sticky navigation or command palette.
2. The Experience page displays the reusable timeline foundation.
3. The visitor sees the Excel Sathi entry and the role label: Senior MIS / Digital Transformation / Systems Architecture.
4. The visitor sees that exact title and dates are to be added later.
5. The visitor may continue to Resume, Projects, About, or Contact.
6. The visitor does not see fabricated employment dates, additional organizations, or unsupported career claims.

Flow 5 — Understand the Cross-Discipline Practice

1. The Portfolio Visitor opens About.
2. The visitor reads the concise explanation of the owner’s work between Business Analysis, System Architecture, MIS, Automation, and Software Development.
3. The visitor reviews the discipline visualization.
4. The visitor understands that business processes are translated into structured digital systems.
5. The visitor may continue to Projects, Experience, Resume, or Contact.
6. No long biography, unsupported qualifications, or fabricated personal history is required for completion.

Flow 6 — Review the Systems-Building Process

1. The Portfolio Visitor reaches the “How I Build Systems” section on Home.
2. The visitor reviews step 01: Understand the Business.
3. The visitor reviews step 02: Map the Workflow.
4. The visitor reviews step 03: Identify Bottlenecks.
5. The visitor reviews step 04: Design the Data Architecture.
6. The visitor reviews step 05: Build the System.
7. The visitor reviews step 06: Automate Repetitive Processes.
8. The visitor reviews step 07: Create MIS & Reporting.
9. The visitor reviews step 08: Deploy and Improve.
10. The visitor may proceed to Projects or Contact.
11. If motion is reduced, every process step remains immediately available in a static readable sequence.

Flow 7 — Navigate Through the Command Palette

1. The Portfolio Visitor presses CMD + K or CTRL + K where supported, or activates the visible command trigger.
2. The systems-console command palette opens.
3. The visitor reviews grouped destinations and mono route labels.
4. The visitor selects a primary destination, project, or section.
5. The palette closes and the selected route or destination opens.
6. If keyboard shortcut handling is unavailable, the visitor uses sticky navigation links instead.
7. All navigation destinations remain publicly accessible without sign-in.

Flow 8 — Prepare Accurate Future Content

1. The Portfolio Owner prepares verified project, experience, resume, social, or contact information outside the public portfolio interface.
2. The owner updates the centralized project data source or applicable structured content source.
3. The reusable ProjectGrid and ProjectCaseStudy structures consume updated supported fields where applicable.
4. The owner verifies that no unconfirmed technologies, metrics, dates, business impacts, testimonials, or company relationships have been introduced.
5. The Portfolio Visitor subsequently sees the updated public content through the same established page routes.
6. If a field remains unverified, the owner retains the placeholder or omits the detail.

6. Visuals Colors and Theme

Muse: Adham Dannaway
Headline: Business process meets system architecture.

The visual system shall communicate composed authority and visible craft. It shall make complex process thinking legible to business and operations audiences while maintaining technical credibility.

Color Tokens

The portfolio shall not use a generic indigo or blue-on-white SaaS visual language.

Typography

• Display and headings: Space Grotesk, weight 600–700.
• Body: IBM Plex Sans.
• Technical labels and metadata: IBM Plex Mono.
• Display tracking: -0.045em.
• Display leading: 1.08.
• Heading leading: 1.18.
• Reading-copy leading: 1.58.

All-caps shall be avoided except for compact technical labels.

Layout and Shape Language

• Use a 12-column desktop grid with 5/7 or 6/6 split compositions.
• Each primary page shall express a left/right dialogue:
  • Left: business language, process inputs, decisions, operational context.
  • Right: system outputs, structured data, modules, and implementation detail.
• On tablet, split layouts shall collapse into paired stacked bands.
• On mobile, diagrams shall become sequential input → architecture → output compositions.
• Architecture canvases shall use square corners.
• Operational cards shall use a 12px radius.
• Surfaces shall be opaque with subtle inner shadow and 1px borders.
• Avoid frosted glass, excessive blur, floating translucent tiles, and generic dashboard treatments.
• Use clipped-corner markers, coordinate ticks, route-like connectors, and code-panel insets.
• Readable text and controls shall remain whole and within their containers at 375px, 768px, and 1280px.

Imagery Direction

The interface itself shall be the visual subject.

Use:

• Authored business-system diagrams.
• Typed workflow maps.
• Sparse schematic data rows.
• Abstracted application-screen fragments built from neutral blocks.
• Purpose-built future project thumbnails based on system views or architectural diagrams.

Do not use:

• Stock people imagery.
• Generic device mockups.
• Laptop mockups.
• Cliché code-editor screenshots.
• Generic coding illustrations.
• Decorative 3D forms unrelated to the portfolio’s systems message.
• Gaming HUD motifs.
• Particle fields.
• Excessive neon.

7. Signature Design Concept

The Persistent Systems Seam

The Home page shall use a persistent vertical seam that separates operational reality from structured system architecture.

On the left side, the visitor sees:

• The headline.
• Supporting systems-focused positioning.
• A business-function input ledger.
• Process language and business context.
• Primary calls to action.

On the right side, the visitor sees:

• The architecture canvas.
• The central Business System Architecture node.
• Routed connector paths.
• System outputs such as Automation, Dashboards, Approvals, Reports, and ERP.
• Structured diagram metadata and system-state styling.

The seam shall continue through Home sections as a visual grammar:

• About uses it to connect disciplines with system outputs.
• The process section uses it as the central execution rail.
• Projects use paired context/system dossiers.
• Capability groups use it to distinguish business-system capability from implementation-oriented skill placeholders.

The concept shall use only accepted portfolio content and navigation. It shall not create a new page, product feature, or user workflow.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The business-function routing diagram connecting Sales, Inventory, Production, HR, Finance, and Operations to Business System Architecture and its outputs.
• Input → transformation → outcome thesis: Named operating functions enter as discrete inputs, converge into Business System Architecture, then route outward into Automation, Dashboards, Approvals, Reports, and ERP. The motion communicates that connected business understanding becomes structured operational systems.
• Motion vocabulary:
  • Measured line-draw reveals.
  • Connector-path sequencing.
  • Restrained 160–240ms state transitions.
  • Subtle pointer-responsive highlight passing across the central split seam.
  • Controlled scroll reveals.
  • Professional button, filter, focus, and card interactions.
• Composed first frame:
  • The left hero panel immediately shows the complete headline, supporting text, input ledger, and CTAs.
  • The right panel immediately shows the central architecture node and all labeled input/output modules.
  • Connector lines may begin in a low-emphasis resting state before measured activation.
• Outcome state:
  • All six business inputs are visibly connected to Business System Architecture.
  • All five outcomes are visibly connected from the architecture node.
  • The diagram remains readable without relying on motion.
• Reduced-motion state:
  • All diagram nodes and connector paths render fully connected and static.
  • No staggered line drawing, pointer-responsive highlight, parallax behavior, or delayed content availability shall occur.
  • Navigation, CTAs, filters, cards, and content remain immediately available.

The system shall not require WebGL, Canvas, React Three Fiber, Drei, or a 3D scene.

9. Non-Functional Requirements

NFR-01 — Responsiveness

• Provenance: explicit
• The website shall be fully responsive for desktop, laptop, tablet, and mobile.
• Mobile shall feel intentionally designed rather than compressed from desktop layouts.
• Text, labels, card content, controls, and navigation shall remain readable and contained at 375px, 768px, and 1280px.
• Desktop diagrams may use split architecture layouts; mobile diagrams shall use readable stacked input → architecture → output structures.

NFR-02 — Accessibility

• Provenance: explicit
• The website shall use semantic HTML.
• The website shall provide accessibility labels for relevant controls.
• The website shall support keyboard navigation.
• The website shall provide visible focus states.
• Navigation, filtering, project links, CTAs, command palette actions, and contact links shall be usable by keyboard.
• Reduced-motion preferences shall be respected.

NFR-03 — Performance

• Provenance: explicit
• The website shall be fast and production-quality.
• Motion shall remain lightweight and professional.
• Decorative motion shall not block content rendering, navigation, or comprehension.
• Reusable components and centralized project data shall avoid unnecessary duplication.

NFR-04 — SEO and Metadata

• Provenance: explicit
• Each page shall support a page title.
• Each page shall support a meta description.
• The site shall support OpenGraph structure.
• Metadata shall remain factual and shall not introduce unsupported professional claims.

NFR-05 — Maintainability

• Provenance: explicit
• The website shall use reusable components.
• The site shall centralize project data.
• Project-detail pages shall read from centralized data wherever possible.
• New projects, roles, accurate social links, resume content, and case-study content shall be addable without redesigning the site architecture.

NFR-06 — Content Integrity

• Provenance: explicit
• The system shall not invent job dates, project metrics, testimonials, education, certifications, company relationships, revenue figures, unconfirmed technologies, or business impact percentages.
• The system shall not present associated brands as direct employers unless accurate source material later establishes that relationship.
• Missing factual information shall remain a placeholder or be omitted.

10. Tech Stack

The authoritative requirements do not mandate a specific framework or hosting provider.

Required Implementation Characteristics

• A component-based web implementation suitable for reusable UI components.
• A routing solution capable of supporting:
  • Primary public destinations.
  • Individual project routes using project slugs.
• A centralized project data source such as projects.js or projects.json.
• Semantic HTML output.
• Responsive CSS or equivalent styling architecture.
• Support for metadata, OpenGraph structure, keyboard access, focus states, and reduced-motion behavior.

Technology Defaults

The following are implementation defaults only and are not claims about the portfolio owner’s professional technology experience:

• Frontend: React.
  [Default — not specified by user]
• Styling: CSS variables and responsive CSS architecture for the documented design tokens.
  [Default — not specified by user]
• Routing: React-compatible client or framework routing with /projects/:slug support.
  [Default — not specified by user]
• Project content storage: Local version-controlled JavaScript or JSON project data source.
  [Default — not specified by user]
• Deployment packaging: Docker or docker-compose only if required by the selected deployment environment.
  [Default — not specified by user]

Kubernetes, a backend API, user authentication, database storage, CMS infrastructure, or provider integrations are not required for the current public portfolio foundation.

11. Assumptions and Constraints

Assumptions

1. Public access

   • All current portfolio destinations are public.
   • No visitor account, sign-in, private dashboard, or role-based access is required.

2. Placeholder-driven content

   • Project, resume, social, case-study, exact job-title, and date details may be added later.
   • Placeholder treatment is preferred to unsupported claims.

3. Content maintenance

   • The Portfolio Owner or an implementation maintainer will update the centralized data source with verified content.
   • No public content-management interface is required in the current foundation.

4. Social and contact destinations

   • LinkedIn, GitHub, and Email values are not yet confirmed.
   • The Contact page shall prepare their presentation without fabricating destinations.

Binding Constraints

1. Do not mention the prohibited brand name specified in the source requirements anywhere.
2. Do not present the portfolio owner as a founder.
3. Do not imply direct employment by Royal Enfield, NovaCare, Finviz, or other associated organizations.
4. Present projects as systems or projects personally designed or developed.
5. Do not invent:
   • Job dates.
   • Project metrics.
   • Testimonials.
   • Education.
   • Certifications.
   • Company relationships.
   • Revenue figures.
   • Technologies not confirmed.
   • Business impact percentages.
6. Do not fully populate every project or section in the first foundation build.
7. Do not copy the supplied visual-reference websites directly.
8. Avoid:
   • Generic developer portfolio templates.
   • Skill percentage bars.
   • Excessive neon.
   • Gaming aesthetics.
   • Unnecessary glassmorphism.
   • Random animations.
   • Cliché coding illustrations.
9. Animations must remain lightweight and professional.
10. The system must respect prefers-reduced-motion.
11. The website must be responsive across desktop, laptop, tablet, and mobile.
12. Reusable components and centralized project data shall be used to avoid unnecessary duplication.
13. The system shall use semantic HTML and provide page titles, meta descriptions, OpenGraph structure, accessibility labels, keyboard navigation, and focus states.
14. The generic indigo/blue-on-white SaaS template is forbidden.

12. Glossary

• Architecture Diagram: A visual representation of how business functions, system architecture, modules, data, and outcomes connect.
• Business System Architecture: The structured central system layer that connects operational business functions to outputs such as automation, dashboards, approvals, reports, and ERP.
• Capability Card: A grouped visual unit for presenting skill or practice areas without percentage-based ratings.
• Case Study: A structured project-detail presentation that can explain a system’s problem, workflow, architecture, modules, features, automation, and learnings when accurate content is available.
• Centralized Project Data: A shared data source, such as projects.js or projects.json, used by project grids and project-detail pages.
• Command Palette: A keyboard-accessible navigation interface opened through CMD + K or CTRL + K.
• ERP: Enterprise Resource Planning; a category of integrated business system.
• MIS: Management Information Systems; systems and reporting structures that support management visibility and decision-making.
• Project Slug: The route-safe identifier used for an individual project path, such as business-erp.
• Reduced Motion: An accessibility preference that removes or minimizes non-essential animation while preserving all content and interactions.
• Systems Seam: The persistent visual split between business-process context and structured system architecture used throughout the portfolio.