dhakarraghu/gitbuddy

1. Overall shape

- This is a Next.js App Router application with a clear split between public entry points and a protected workspace.

- The public side contains the home page and login flow; the authenticated side is organized around a project workspace and project-management actions.

2. Authentication and access control

- Authentication is handled through NextAuth in src/app/api/auth/[...nextauth]/route.ts.

- src/middleware.ts and the (protected) route group enforce access boundaries so workspace pages only load for signed-in users.

- src/lib/auth.ts is the central auth config/helper, and src/components/Providers.tsx likely wires session/theme/global client providers into the app shell.

3. Persistent application state

- The app uses Prisma with a relational database, as shown by src/lib/db.ts and prisma/schema.prisma.

- Migrations indicate the main stored entities include users, projects, and repository indexing data, plus at least one enum-based state model.

- This database is the system of record for project membership, saved summaries, analytics, and meeting artifacts.

4. Project-centric domain model

- The main workspace is organized around src/app/project/[projectId], which is the primary domain boundary.

- Subpages under a project include:

- dashboard for overview/status

- analytics for repository and activity insights

- meetings for meeting lists and meeting detail

- prAndissue for pull request / issue analysis

- qa for question-answering over project context

- src/app/project/[projectId]/layout.tsx suggests shared project-scoped navigation/state across these tabs.

5. Project lifecycle and collaboration

- Project creation and membership are handled in the protected workspace via create, join/[projectId], and projects.

- Collaboration features are surfaced through components such as invite-button.tsx, team-member.tsx, and archive-button.tsx.

- The billing page implies account or workspace-level plan management, even if it is not the core product flow.

6. Repository ingestion and analysis pipeline

- Repository analysis appears to start from GitHub data and repo loading helpers in src/lib/github.ts, src/lib/githubLoader.ts, src/lib/github-insights.ts, and src/lib/repoEmbedding.ts.

- src/lib/query.ts and src/lib/retrival.ts suggest a retrieval layer that turns indexed repository content into answerable context.

- The architecture implies a pipeline of: user supplies repo URL → repo is fetched/indexed → embeddings are generated → data is stored for search/QA/analytics.

7. Vector retrieval and AI assistant layer

- src/lib/pineconedb.ts indicates a Pinecone-backed vector store for semantic retrieval.

- src/lib/gemini.ts and src/lib/gemini2.ts indicate Gemini is used for generation tasks such as summaries, explanations, and project Q&A.

- This creates a retrieval-augmented workflow: the app fetches relevant project/repo context from Pinecone and passes it to the model for grounded responses.

8. Meeting audio processing

- Meeting support is a separate ingestion path from repository analysis.

- src/components/upload-audio.tsx and src/lib/assembly.ts indicate audio upload plus AssemblyAI transcription.

- src/lib/uploadToVercel.ts suggests uploaded media is stored externally, likely via Vercel storage/asset handling, before transcription and summarization.

- The resulting transcript, summary, and extracted issues feed the meetings pages and likely the project analytics layer.

9. UI composition and state handling

- The UI is built from a shared design system in src/components/ui/*, with app-specific shell pieces like app-sidebar.tsx, homeSidebar.tsx, mode-toggle.tsx, and ConfromDialog.tsx.

- Multiple loading.tsx files under project subroutes show that the workspace is designed around asynchronous data loading and progressive rendering.

- Hooks such as use-refetch.ts and use-mobile.ts suggest client-side refresh and responsive behavior are part of the interaction model.

10. Data flow across the system

- The two main ingestion streams are:

- GitHub repository data flowing into database + embeddings + AI summaries

- Meeting audio flowing into storage + transcription + extracted action items/issues

- Both streams converge in the project workspace, where the UI reads persisted records and generated insights to render dashboards, analytics, Q&A, and meeting views.

11. External service boundaries

- The architecture depends on several external services that materially shape the system:

- GitHub for repository source data

- Gemini for language generation and analysis

- AssemblyAI for audio transcription

- Pinecone for vector search / semantic retrieval

- Vercel for deployment and likely file/storage handling

- These are not just integrations; they define the major processing boundaries of the product.

12. What to draw in an architecture diagram

- A useful diagram should center on the project workspace as the hub, with arrows to:

- auth/middleware and session management

- Prisma/Postgres persistence

- GitHub ingestion/indexing

- Pinecone retrieval

- Gemini generation

- AssemblyAI meeting transcription

- external media upload/storage

- The public login and protected project routes should be shown as separate entry paths into the same core workspace.