aaryangole26/lawpal

1. Purpose and Topology

LawPal is a legal-assistance product: a React single-page frontend for authentication, legal-service navigation, and chatbot interaction, backed by Flask services intended to combine Groq language generation with Pinecone legal-document retrieval. Supabase supplies user authentication and potentially data services.

Primary application roots are App/project/ for the browser client and Server/ for the deployable backend. A second Python entrypoint exists at App/app.py, but the README identifies Server/app.py as the local backend runtime.

2. Frontend Bootstrap and Application Shell

Vite loads the React application through App/project/index.html and App/project/src/main.jsx. The root UI composition is App/project/src/App.jsx.

The client is responsible for browser-side navigation and presentation. Shared shell/navigation is represented by App/project/src/Header.jsx; global styling combines App/project/src/index.css, Tailwind configuration, and page-specific CSS.

3. User Access and Identity Boundary

Authentication views are separated into App/project/src/Login.jsx and App/project/src/SignUp.jsx. The Supabase client boundary is centralized in App/project/src/supabase.js.

Frontend authentication should remain distinct from backend AI/retrieval calls: Supabase credentials and session state establish user identity, while Flask endpoints handle legal-query processing. Supabase setup is a material external dependency for email/password and OAuth flows.

4. Legal Experience Pages and Chat Entry

The public/product journey begins at App/project/src/LandingPage.jsx, with service discovery in App/project/src/ServicesPage.jsx and resource content in App/project/src/Resources.jsx.

App/project/src/ServiceChatPage.jsx is the key interactive legal-assistance surface. It is the expected client-side integration point for typed or voice-derived prompts, document-related actions, response display, and browser Web Speech API voice input/output. App/project/src/i18n.js provides the client localization boundary for multilingual interactions.

5. AI and Retrieval Backend

Server/app.py is the documented Flask runtime entrypoint; Server/api.js indicates an additional JavaScript API/deployment surface that should be reconciled before extending backend behavior.

The intended request path is: user query or document input from the React chat page → Flask API → Pinecone vector search for relevant legal material → Groq NLP/generation using retrieved context → response returned to the UI. Pinecone and Groq API keys are server-side environment dependencies; they must not be exposed through the Vite client.

6. Deployment and Runtime Boundaries

The frontend is a Node/Vite build deployed with Vercel metadata at App/project/vercel.json and App/project/src/vercel.json. The backend supports container and process-based deployment through Server/Dockerfile and Server/Procfile, and also has Server/vercel.json.

Python dependency boundaries are split across Server/requirements.txt and root/App requirements files. The authoritative backend dependency set should be treated as Server/requirements.txt because it aligns with the documented Flask runtime.

7. Static Assets and Key Integration Risks

App/project/public/model.gltf is a client-served 3D static asset, likely part of the landing or interactive experience rather than the AI pipeline.

Architecturally important ambiguities are duplicate backend/app entrypoints (App/app.py, Server/app.py, Server/api.js) and duplicate Vercel configuration locations. Establish one canonical API implementation and deployment target before adding features, then preserve a clear boundary: React/Supabase/browser APIs in App/project/src/; secrets, Groq, Pinecone, and retrieval orchestration in Server/.