ananya-hegde2001/codevault

1. CodeVault- is split into two deployable surfaces: a React/Vite single-page frontend in frontend-main and an Express/Node backend in backend-main. The frontend is the presentation layer; the backend owns authentication, repository workflow, and data mutations.

2. The frontend is organized by user journey rather than by API domain. src/components/auth handles login/signup, dashboard is the landing workspace, and src/components/user contains repository-centric screens such as create repository, repository details, profile, and a heatmap view. App.jsx, Routes.jsx, authContext.jsx, and themeContext.jsx provide app-wide routing and state.

3. Authentication is a first-class boundary. The backend has userController plus authMiddleware and authorizeMiddleware, which suggests protected endpoints and role/ownership checks. On the frontend, auth state is likely lifted into authContext and used to gate routes and navigation.

4. The backend is organized as an API layer over feature controllers. Routes are separated into main.router, repo.router, user.router, and issue.router, which map to controllers for repo operations, commits, push/pull/revert flows, user actions, and issues. This separation is important for diagramming because it shows the app is domain-driven rather than monolithic.

5. Repository/version-control behavior is the core subsystem. Controllers like init, add, commit, push, pull, and revert indicate CodeVault implements a GitHub-like workflow, not just generic CRUD. These operations likely transform repository state, create commit records, and synchronize local snapshots with stored repository metadata.

6. The storage model appears to mix conventional app models with custom filesystem-backed artifacts. models/ contains userModel, repoModel, and issueModel, while .codeVault/commits contains per-commit folders with commit.json and tracked files. That suggests a hybrid architecture: structured app data through models, plus versioned repository contents stored as on-disk artifacts.

7. The .codeVault directory is an important architectural boundary. It looks like an internal repository workspace/history store containing commit snapshots and configuration, separate from the normal source tree. For architecture purposes, treat it as the persistence layer for repository history and local workflow state.

8. Issue tracking is a secondary subsystem tied to repositories and users. issueController and issueModel imply CRUD-style issue management, likely linked to a repository and created from the repo detail or dashboard views. It is distinct from commit history but shares the same authentication and repository context.

9. There is an external integration seam for AWS. config/aws-config.js indicates the backend can be wired to cloud services, though the exact service is not visible here. Architecturally, this is a configurable integration point rather than the app’s core runtime.

10. The request flow is straightforward: user action in the React UI goes through routed components, hits Express endpoints, passes auth/authorization middleware, then reaches controllers. Controllers either read/write model data or manipulate .codeVault repository artifacts, and the response drives UI updates in the dashboard or repository detail screens.

11. A few files suggest supporting workflows rather than runtime features: WORKFLOW_GUIDE.md and root-level commit.json/update.js likely help with the project’s custom development or repository sync process. They are useful to note on a diagram as operational tooling, but they are not the main product path.

12. The cleanest architecture diagram should therefore show: frontend SPA → backend API → auth/authorization → repo/user/issue controllers → models and .codeVault storage, with AWS as an optional side integration and the issue subsystem attached to repository/user data.