singhgemsaman/sprints-and-outsource-projects

1. This repository is not one app; it is a collection of standalone front-end deliverables organized by sprint and phase. The architecture is evolutionary: early folders are static HTML/CSS/JS prototypes, while later folders introduce build tooling, CSS generation, and a React/Vite application.

2. The simplest boundary is the “static site” tier: Phase_1, phase_2, phase_3, Outsorce_Portfolio, and several Sprint_*/*Phase* folders contain index.html, CSS, and a small main.js. These are self-contained browser apps with direct DOM scripting and no obvious shared runtime.

3. A second tier uses a CSS build pipeline. In Sprint_2/Phase_1-3 and Sprint_3/Phase1-3, the presence of package.json, src/input.css, and generated src/output.css indicates a Tailwind/PostCSS-style workflow where source styles are compiled into distributable CSS. The app logic still lives in main.js, but styling is produced through a build step instead of hand-authored CSS only.

4. The most complete subsystem is Sprint_3/Outsourced(Veridian-gallery), which is a React application built with Vite. src/main.jsx is the entry point, App.jsx is the composition root, and vite.config.js plus eslint.config.js show a modern SPA toolchain.

5. In the gallery app, the UI is split into reusable components and page-level views. Components such as Navbar, Footer, ArtworkCard, and SkeletonLoader handle shared layout, card rendering, and loading states. Page modules such as ArtistDirectory, ArtistPortfolio, ExhibitionHall, Wishlist, Contact, and NotFound represent the major navigable screens.

6. Data and state are separated from presentation in that React app. src/data/exhibitions.js provides local content, src/hooks/useArtists.js and src/hooks/useArtworks.js encapsulate data retrieval and related state, and src/context/PatronWishlistContext.jsx holds client-side wishlist state across pages. useDocumentTitle.js is a small cross-cutting hook for page metadata.

7. The gallery app’s data flow is typical SPA flow: entry point mounts the app, the app renders navigation and page shells, hooks fetch or derive artist/artwork data, context stores wishlist selections, and presentational components render cards and loading skeletons. The boundaries are cleanly split between UI, data fetching, and shared state.

8. Styling in the gallery app is modularized alongside components and pages. Each component/page has its own CSS file, with global styling in src/index.css and app-level styling in src/App.css, which makes the visual system easy to diagram as shared shell styles plus feature-specific styles.

9. Sprint_4 appears to be a separate Vite-based browser app focused on document parsing. The presence of src/pdfParser.js suggests a distinct parsing/processing layer isolated from the main UI in src/main.js, with src/style.css handling presentation. This is a clear example of logic split between parsing and interface layers.

10. The repo also contains deployment and quality artifacts rather than runtime code: the README links to a Netlify-hosted version of a sprint build, and the screenshot folder stores desktop/mobile/audit images for documentation or validation. These are supporting assets, not part of the runtime architecture.

11. From an architecture-diagram perspective, the main repeating patterns are: static pages; CSS-build pages; React SPA with hooks/context/components; and a document-processing app with a dedicated parser module. The important boundaries are between source and generated CSS, between presentation and shared state, and between UI and domain-specific processing logic.