shivanshu-jha/my-portfolio

1. Overall shape

- This is a single-page, client-rendered React app written in TypeScript.

- The app is organized like a personal portfolio / AI Studio showcase: a landing page with several content sections plus an interactive terminal-like AI feature.

- There is no obvious backend service or database in the repo tree; most content appears to be local/static and rendered in the browser.

2. Application entry and composition

- src/main.tsx is the browser entry point that mounts the app.

- src/App.tsx is the top-level composition layer and likely assembles the page by placing the major sections in order.

- The architecture is therefore a component tree rather than a multi-page or server-centric design.

3. Major UI subsystems

- Header.tsx provides top-level navigation/branding.

- Hero.tsx is the landing/intro section.

- SkillsGrid.tsx, ProjectsShowcase.tsx, and EducationTimeline.tsx render the main portfolio content areas.

- ContactForm.tsx is the user-facing contact boundary.

- InteractiveTerminal.tsx is the most distinct interactive subsystem and likely the only part that behaves differently from the static sections.

4. Shared content and type boundary

- src/data.ts centralizes the portfolio content used by multiple sections.

- src/types.ts defines the shared TypeScript models for that content.

- This creates a clean boundary: data and schema live separately from presentation, so the section components render from imported structured data instead of hardcoding everything.

5. Data flow

- The primary data flow is static content import → typed data objects → presentational section components → rendered page.

- Section components appear to be mostly consumer views over the shared data module.

- This means the app is likely easy to re-theme or re-content without changing layout logic.

6. Interactive/AI boundary

- The README requires GEMINI_API_KEY, which strongly suggests the app has an external Gemini API integration.

- InteractiveTerminal.tsx is the most likely integration point for that API.

- Architecturally, this is the only clear external service boundary in the repo: browser UI ↔ Gemini-powered experience.

7. Styling and presentation layer

- Global styling lives in src/index.css.

- postcss.config.mjs indicates the CSS pipeline is processed, but the repo tree does not show a separate design system or CSS-in-JS layer.

- The visual architecture is therefore likely component-driven styling with a shared global stylesheet.

8. Static assets and document shell

- public/ contains static assets served as-is.

- index.html is the HTML shell that hosts the React app.

- These are standard SPA boundaries: the browser loads one shell, then React takes over rendering.

9. Tooling and build/runtime

- The app is built around Node.js and uses npm.

- vite.config.ts, eslint.config.mjs, and tsconfig.json define the local build, lint, and typecheck environment.

- The repo also contains .next and next.config.ts artifacts, but the visible runtime entrypoints are React/Vite-style (src/main.tsx, vite.config.ts), so those Next-related files look like scaffold or generated support rather than the primary app structure.

10. Operational model

- Local run flow is simple: install deps, provide GEMINI_API_KEY, start dev server.

- There is no sign of separate services, queues, persistence, or auth infrastructure.

- From an architecture-diagram perspective, this is best drawn as a front-end SPA with one external AI API dependency, plus static asset hosting.