mayank11104/team_code200

1. Overall shape

GearGuard is a two-tier maintenance management system: a Python backend exposes application data and workflow rules, while a React/TypeScript frontend renders operational views such as dashboard, list, kanban, calendar, and detail pages. The database is designed as the system of record and is shared directly via SQL schema/seed files.

2. Backend boundary

The backend is organized as a classic layered API service:

• backend/main.py is the entrypoint.

• backend/api/ contains route modules grouped by domain: auth, equipment, maintenance, reports, and teams.

• backend/services/ holds business logic such as user management and audit tracking.

• backend/models/ contains data models for users, tokens, and login history.

• backend/core/ centralizes configuration, database access, and security utilities.

This separation suggests request handling is kept thin, with workflow rules and persistence behavior pushed into services/core modules.

3. Domain modules and responsibilities

The main domain boundaries are explicit in the backend API:

• Auth: login/session/token handling and identity.

• Equipment: asset registry and equipment lifecycle, including scrap behavior.

• Maintenance: corrective/preventive request creation and status transitions.

• Teams: maintenance team and technician management.

• Reports: aggregated operational views and metrics.

These correspond closely to the UI screens, so the architecture is domain-aligned rather than technical-layer aligned.

4. Business workflow

The central workflow is maintenance request processing:

equipment is selected, a maintenance team is inherited from that equipment, requests start in New, then move through In Progress, and finally to Repaired or Scrap. The readme also calls out technician assignment and preventive maintenance scheduling via scheduled_date. This means the backend is not just CRUD; it enforces a state machine around requests.

5. Security and access control

Role-based access control is a major architectural concern. The readme defines Admin/Manager, Technician, and Employee roles, and the backend includes security.py, token models, and login history tracking. That implies authenticated requests are authorized by role and identity, with token/session handling likely centralized in the core security layer.

6. Audit and traceability

The system emphasizes auditability:

• login_history and token models support authentication traceability.

• The readme mentions request status change history.

• Soft deletes are used across entities via deleted_at.

This means the data model is designed to preserve operational history rather than hard-delete records, which is important for ERP-style reporting and compliance.

7. Database as a first-class component

The repository includes explicit SQL assets under backend/database/:

• schema.sql defines the normalized schema.

• seed.sql provides demo/reference data.

• setup_database.sql suggests repeatable local initialization.

The readme states the schema is in 3NF with junction tables for many-to-many relationships, so the database layer is intentionally authoritative and shared across the team.

8. Frontend structure

The frontend is a Vite-based React application using TypeScript and a component-heavy design system. It is organized into:

• pages/ for route-level screens like Dashboard, Equipment, Teams, Calendar, Reports, Login/SignUp modals, and detail pages.

• components/ for reusable UI and domain widgets.

• components/ui/ for a large shadcn-style primitive library.

• components/layout/ for shell structure such as top bar and app layout.

This indicates the UI is built from reusable primitives plus domain-specific composites, not from one monolithic page layer.

9. Frontend data flow

The frontend reads backend data through src/api/client.ts, src/api/endpoints.ts, and feature-specific hooks such as useEquipment, useMaintenance, useReports, and useTeams. That structure suggests a clean split between transport/client logic and view logic. Pages consume hooks, hooks call endpoints, and components render data states.

10. UI feature mapping

The main screens map directly to backend domains:

• Dashboard and Reports show aggregated operational data.

• Equipment pages manage assets and equipment details.

• Maintenance pages manage requests, including kanban and lists.

• Teams pages manage maintenance groups and technicians.

• Calendar focuses on preventive maintenance scheduling.

This makes the frontend a presentation layer over the backend workflow model, not an independent domain engine.

11. Mock vs live data

There is a src/data/mockData.ts file, which likely supports local development or placeholder rendering, but the README says frontend data is dynamically loaded from the database. Architecturally, mock data appears supplemental rather than primary.

12. Operational setup

The repo is structured for collaborative development:

• PostgreSQL is the external infrastructure dependency.

• Schema and seed files are version-controlled.

• Frontend and backend are kept aligned with the same field names and workflow rules.

• fix_table_names.py hints at migration/compatibility maintenance around schema naming.

This reinforces that the project is designed around stable database contracts and a clear separation between UI, API, and persistence.