jsantiago318/improved-tsquared

1. This is a client-side React SPA built with Vite, TypeScript, Tailwind CSS, and shadcn/ui. The repository contains no custom server code; the app depends on external services for persistence/integration.

2. The bootstrapping path is the usual Vite frontend flow: index.html → src/main.tsx → src/App.tsx. Global styling lives in src/styles/globals.css, with Tailwind/PostCSS/Tailwind config handling the design system layer.

3. src/App.tsx is the top-level composition point. Based on the file structure, it likely decides which screen shell to render and wires together the main navigation and shared UI providers such as notifications/toasts.

4. The app is organized around screen-level views in src/screens/: AuthScreen, HomeScreen, MenuScreen, UserHomeScreen, and a dedicated calendar_events/home_calendar.tsx. These are the main user-facing boundaries and are the best candidates for diagram nodes at the “page” level.

5. The domain-specific functionality is concentrated in src/components/: dashboard widgets, tables, menu/instructor selectors, event creation, and notifications. Dashboard.tsx, Header.tsx, NewEvents.tsx, and the various table components (DTable, HTable, ITable, PTable) suggest a data-management UI with reusable table variants.

6. There is a second layer of more feature-specific composition under src/components/Panels/ and src/components/premades/. The Panels directory appears to hold dashboard subviews for different roles or sections (DashboardPanelInstructor, DashboardPanelSeminars, DrawerEntity), while premades contains reusable specialized widgets like instructor dropdowns and seminar table menus.

7. The UI foundation is a large set of local shadcn-style primitives in src/components/ui/ such as dialogs, tables, selects, tabs, dropdowns, forms, and toasts. These are low-level building blocks used by the higher-level feature components rather than being application logic themselves.

8. Data and service boundaries are explicit in src/supabaseClient.ts and src/mailchimpClient.ts. Supabase is the likely backend boundary for authentication and app data; Mailchimp is a separate integration boundary for mailing-list or marketing-related synchronization.

9. The architecture suggests a role- or context-driven UI: authentication, home/dashboard, menu/instructor management, and user home are separate flows rather than one monolithic view. The Dashboard/panel components likely render different content depending on the current user or feature context.

10. Static assets are split between public/ and src/assets/, including src/assets/uiSpritesheets and src/components/assets, which indicates the app uses bundled UI imagery and component-local assets rather than fetching most visuals remotely.

11. The calendar/events area is its own mini-subsystem. The presence of calendar_events/template-center.pptx alongside home_calendar.tsx suggests this part of the app likely supports event scheduling or presentation/export workflows tied to seminars or classes.

12. For an architecture diagram, the most important boundaries are: frontend SPA shell, screen-level routes/views, feature components/panels, shared UI primitives, and external service adapters (Supabase, Mailchimp). Everything appears to flow from the screen layer down into reusable components and then out to those service clients.