muntasir-wsx/lifeshield-client

1. Repository shape

- This is a React/Vite single-page frontend for the Life Shield insurance platform.

- The repo is organized around role-specific screens and route guards, not around backend services. The actual API/business logic is expected to live in external endpoints consumed by this client.

2. Bootstrap and runtime

- src/main.jsx and src/App.jsx are the entry points that mount the app.

- Global styling comes from src/index.css and src/App.css, with UI behavior driven by React plus the styling stack described in the README: Tailwind CSS, DaisyUI, and Framer Motion.

3. Top-level routing architecture

- src/Router/Router.jsx is the central route map.

- src/Routes/PrivateRoutes.jsx, AdminRoutes.jsx, and AgentRoutes.jsx act as access-control boundaries around protected sections.

- The route structure splits cleanly into public marketing pages, auth pages, and dashboard pages for different roles.

4. Layout boundaries

- src/Layouts/MainLayouts.jsx is the shell for the public-facing site.

- src/Layouts/DashboardLayout.jsx is the shell for authenticated dashboard flows.

- Shared chrome is factored into src/SharedComponents/Navbar, Footer, LifeShieldLogo, and Loading, which keeps page components focused on content and workflows.

5. Authentication and identity

- src/Context/AuthProvider.jsx and src/Context/AuthContext.jsx hold the app-wide auth state.

- src/Hooks/useAuth.jsx exposes auth state to pages, while src/Firebase/Firebase.init.js contains client-side Firebase setup.

- This suggests Firebase is used for frontend auth/session integration, while the app’s role model is enforced through the app’s route guards and role hooks.

6. Role-based access model

- src/Hooks/useRole.jsx is the key abstraction for determining whether the current user is a Customer, Agent, or Admin.

- The dashboard is partitioned accordingly:

- Customer: policies, claims, payments

- Agent: assigned customers, blog publishing, policy clearance

- Admin: policy moderation, user management, applications, transactions, blogs

- This is the primary architectural boundary in the app.

7. API/data access layer

- src/Hooks/UseAxiosPublic.jsx and src/Hooks/UseAxiosSecure.jsx centralize HTTP access.

- The “secure” client likely carries auth credentials or tokens, while the “public” client is for unauthenticated reads.

- This separation is important because most pages are thin UI shells over backend resources such as policies, users, blogs, payments, claims, and transactions.

8. Public marketing and discovery flow

- The public site includes Home, AboutUs, AllPolicies, Blogs, and QuotePage.

- Home is composed from modular sections like Banner, PopularPolicies, Agents, Testimonials, Articles, Newsletter, indicating a marketing-oriented landing page built from reusable content blocks.

- AllPoliciesDetails.jsx and ArticleDetails.jsx represent drill-down detail views from list pages.

9. Customer workflow

- Customer-facing pages cover the core lifecycle: browse policy → request/quote → pay → view payment status → manage active policies → submit claim request.

- Key screens are under src/Pages/Customer/..., including MyPolicies, PaymentPage, PaymentStatus, and ClaimRequest.

- The payment flow includes CheckoutForm.jsx, and the README confirms Stripe is the external payment gateway.

10. Agent workflow

- Agent pages support back-office content and customer operations: AssignedCustomers, MyBlogs, and PolicyClearance.

- This indicates agents can both manage content and process operational insurance tasks for customers assigned to them.

- The agent dashboard is a distinct workspace rather than just a filtered version of the admin panel.

11. Admin control center

- Admin pages are concentrated under src/Pages/Admin/...: ManageUsers, ManagePolicies, ManageApplications, Transactions, and AllBlogs.

- This is the platform’s governance layer: approve/reject/delete content, promote roles, and monitor financial activity.

- The README’s RBAC description aligns with this structure: admin actions are broad and supervisory, not customer-facing.

12. Cross-cutting UI and content concerns

- Shared UI components are separated from page logic, and the codebase uses many small page components (Card, Details, Form) rather than monoliths.

- react-helmet-async is listed in the README, so pages likely manage document metadata per route.

- Notification and feedback flows are probably handled with SweetAlert2 and React Hot Toast, which are relevant because many dashboard actions are stateful and asynchronous.

13. External/infrastructure boundaries

- firebase.json, .firebaserc, and the .firebase directory show the app is configured for Firebase Hosting deployment.

- The frontend also depends on outside services for authentication, payments, and image hosting (per README: Firebase, Stripe, Cloudinary/ImgBB).

- No backend source is present here, so the architecture diagram should show this repo as the client-side presentation and orchestration layer connecting to those external services and to a separate API backend.