vivekrai-gif/multi-tenant-erp

1. This is a React single-page application bootstrapped with Create React App. The runtime is entirely client-side, with public/index.html as the host shell and src/index.js mounting the app.

2. The application is organized as a multi-role ERP/portal UI rather than a single-purpose app. The major product surfaces are:

- public landing and login

- global admin

- school admin

- teacher

- parent

- student

3. Navigation and page composition are centralized in src/routes/AppRoutes.jsx, src/App.jsx, and src/layouts/MainLayout.jsx. Each role then has its own layout and shell components, which strongly suggests route-level separation by persona.

4. The shared design system lives under src/components/shared, src/components/ui, and src/components/erp/global. These folders contain reusable UI primitives and app shell pieces such as sidebars, top bars, headers, cards, pagination, charts, and table components.

5. State that crosses multiple screens is handled with React context providers in src/context: ThemeContext, ParentProvider, SchoolAdminProvider, and StudentProvider. This indicates role-specific state hydration and theme handling at the top of the component tree.

6. The service layer is concentrated under src/services. axiosClient.js, apiClient.js, and api.js appear to be the shared HTTP foundation, while parentAPIs.js, schoolAdminApi.js, and studentAPIs.js split API access by role. exportService.js suggests a separate reporting/export flow. The UI pages likely fetch and mutate data through these wrappers rather than calling backend endpoints directly.

7. The global admin area is a platform-management subsystem. Its pages cover schools, domains, subscriptions, payment infrastructure, AI configuration, email configuration, security/access, notifications, settings, and school creation. This is the clearest boundary for tenant/platform administration.

8. The school admin area is the operational management subsystem for a school tenant. It includes students, teachers, parents, class levels, academic years, classes/sections, subjects, role/permission setup, teacher assignment, parent-student mapping, and entity detail/edit pages. This is the main data administration layer for the school domain.

9. The teacher area is the instructional workflow subsystem. It includes class hubs, attendance, assignments, exams, grading, student analytics, performance management, notifications, profile/settings, and a substantial AI content workspace. The AI tool pages cover lesson plans, quizzes, worksheets, rubrics, study notes, question papers, presentations, and history.

10. The student area is the learner-facing subsystem. It includes dashboards, subjects, assignments, attendance, grades, learning materials, quizzes, AI tutor, recommendations, fees/payments, help desk, notifications, profile, and settings. This area is oriented around consuming content and submitting/receiving academic results.

11. The parent area is a monitoring and guidance subsystem. Its pages focus on child overview, attendance, grades/assessment, assignments, recommendations/insights, notifications, and portal settings. This role appears read-heavy compared with teacher and school admin roles.

12. The landing experience under src/components/landing and src/pages/Landing.jsx is a separate marketing/public entry path. It contains hero, roles, flow, intelligence, CTA, navbar, and footer sections, implying a public funnel that leads into login and the role-based app.

13. Styling and presentation are layered through src/index.css, src/styles/aiTheme.css, tailwind.config.js, and postcss.config.js. The presence of Tailwind/PostCSS config plus AI-specific theming suggests the UI is built from utility styling with some custom theme treatment for AI workspace screens.

14. src/hooks/useStaleData.js and src/utils/calculations.js provide cross-cutting client logic for data freshness and derived metrics. These are supporting utilities rather than primary domains, but they likely feed dashboards, charts, and summary cards.

15. fix-darkmode.js and fix_student_section.js look like one-off maintenance scripts rather than runtime application code. They should be treated as repo utilities, not as part of the main request/response architecture.

16. For an architecture diagram, the key boundaries are: public landing/auth, shared client shell, role-specific portals, centralized HTTP/service layer, and context-driven state. The main data flow is user action in a role-specific page → service/API wrapper → backend response → contextual state and dashboard/UI rendering.