jsantiago318/scaling-lamp

1. This repository is a client-side single-page application built with React, TypeScript, and Vite. There is no server application in the tree; the frontend is the whole runtime surface, with backend interaction funneled through a Supabase client.

2. The top-level application entry points are src/main.tsx and src/App.tsx. main.tsx is the bootstrapping layer that mounts React into index.html, while App.tsx is the root composition layer that likely selects and wires the app’s main screens.

3. The feature surface is organized around three screen-level views in src/screens: Auth.tsx, Home.tsx, and Calendar.tsx. These are the highest-level domain boundaries in the repo and are the best candidates for diagramming user flows and page transitions.

4. Shared UI is split into two levels: app-specific components in src/components and a larger reusable design system in src/components/ui. The ui folder contains shadcn-style primitives such as button, dialog, tabs, calendar, chart, and navigation components, which indicate the app builds feature screens from composable, low-level UI blocks rather than custom one-off widgets.

5. src/components/CountBtn.tsx is the only clearly custom non-UI component visible in the tree. It likely represents app-specific interaction logic layered on top of the shared component library.

6. supabaseClient.ts is the explicit integration boundary to external services. That file centralizes Supabase access, so any authentication or data-driven calendar behavior is probably mediated through this module rather than direct API calls scattered across screens.

7. The likely data flow is: user action in a screen component → shared UI primitives and custom components handle presentation and interaction → screen logic calls the Supabase client for auth or persisted data → results are rendered back into the screen. In architecture terms, Supabase is the only external system visible from the repository structure.

8. Styling is handled through Tailwind CSS and global stylesheet layering. src/styles/globals.css, tailwind.config.js, and postcss.config.js define the design token and utility-class pipeline, with component styles expected to be mostly utility-driven rather than CSS-module based.

9. src/lib/utils.ts serves as the shared utility boundary for client-side helpers. In shadcn-based projects this typically includes class name composition and related cross-cutting helpers used by many UI components.

10. The project is strongly tool-driven on the frontend build side: Vite for local dev and production bundling, TypeScript for type safety, ESLint for static analysis, and PostCSS/Tailwind for style processing. These are build-time concerns and do not add runtime subsystems, but they shape how the app is assembled and deployed as static assets.

11. public/ and src/assets/ represent the static content boundary. public/ is for assets served as-is by Vite, while src/assets contains importable assets managed through the module graph.

12. The repository also contains broad shadcn/ui coverage in src/components/ui, including calendar, tabs, accordion, dialog, pagination, resizable panels, and charts. That suggests the app is designed to support richer interactive screens and dashboard-like interfaces without introducing a separate UI framework or component server.

13. In diagram terms, the clearest architecture is: Vite-hosted React SPA at the center, three primary screens at the feature layer, shared UI primitives beneath them, a small utility layer for helpers, and a Supabase integration edge for authentication and persistent data.