miriyalajayanth-19/vidhi_sahayak

1. Overall shape

VidhiSahayak is a Next.js App Router application that mixes static content pages, interactive client components, and a small server-side API layer. The repo is organized around legal-domain experiences: AI chat, lawyer discovery/consultation, document generation, and onboarding/dashboard flows for different user roles.

2. Presentation layer: src/app

The main UI lives in route-based pages under src/app. This includes the public landing pages, legal category browsing, search, chat, documents, support, privacy/terms, and role-specific onboarding and dashboards. Because it uses App Router, each folder is a route boundary, and many pages are likely composed of shared layout pieces plus route-specific content.

3. Public user journeys

The visible product flows are:

• landing and discovery via src/app/page.tsx, categories, search, and lawyers

• AI assistance via src/app/chat

• document creation via src/app/documents

• consultation booking via src/app/consultation

These are the primary end-user paths and likely feed into one another, for example browsing categories or lawyers before initiating chat or booking.

4. Domain-specific dashboard split

There is a clear separation between dashboard/user and dashboard/lawyer. The lawyer side is much richer, with subpages for cases, invoices, payments, profile, and verification. This suggests the architecture is intended to support multiple roles, with different capabilities and workspaces rather than a single generic dashboard.

5. Server API boundary

The server API is concentrated under src/app/api with three routes:

• api/chat for AI/legal question handling

• api/lawyers for lawyer data access

• api/tts for text-to-speech generation

This indicates the app uses Next.js route handlers as the backend boundary, with the client UI calling these endpoints instead of talking directly to external AI or speech services.

6. Shared domain/data layer

Reusable business data and helpers live in src/lib. The important modules are:

• categories.ts for legal category content/navigation

• guidance.ts for legal help content or response scaffolding

• lawyers.ts for lawyer listings/profile data

• types.ts for shared TypeScript models

• lang-utils.ts and utils.ts for text/localization/general helpers

• supabase-browser.ts, supabase-server.ts, and supabase.ts for database client setup

This layer is the main boundary between UI/routes and data/domain logic.

7. AI and voice features

The repo includes dedicated client components for AI and audio experiences:

• ai-chat-widget.tsx

• inline-voice-assistant.tsx

• voice-search.tsx

These likely connect to the chat and TTS API routes, and the README shows AI providers and voice APIs are environment-driven. Architecturally, AI and voice are optional service integrations rather than core storage features.

8. Authentication and onboarding flow

There is an auth section under src/app/auth with signin, signup, and callback handling, plus role-based onboarding under src/app/onboarding/{user,lawyer,consultant}. This suggests auth is designed around post-signup role selection and redirect handling, with the callback route acting as the external auth provider handshake boundary.

9. Styling and shared shell

Global styling is handled by src/app/globals.css, with shared layout in src/app/layout.tsx. The app also has common shell components such as navbar.tsx and footer.tsx. The README and config files indicate Tailwind CSS and shadcn/ui are the main UI system, so most UI composition is utility-class based with reusable component primitives.

10. Operational boundaries and external services

The repo is configured for environment-driven integrations rather than hardcoded infrastructure. The README lists required/optional keys for Gemini, Supabase, OpenAI, Perplexity, and Google TTS, which means the deployment shape depends on those services being available. supabase.schema.sql shows the database schema is part of the repo, but the README frames Supabase as an evolving persistence/auth layer rather than the only current data source.

11. Request handling and cross-cutting control

The presence of proxy.ts implies there is some request-level interception or routing control, likely for auth guards, redirects, or feature gating. In an architecture diagram, this should sit in front of protected dashboard/auth routes as a cross-cutting boundary rather than as a business subsystem.

12. Current maturity

This is a product-oriented scaffold with strong route structure and feature surfaces, but some subsystems are clearly still evolving. The roadmap explicitly calls out fuller auth/roles, persistent Supabase-backed data, payments, and retrieval-enhanced AI chat. So the diagram should treat several areas as present-but-partial, especially around persistence and payment/workflow automation.