nabdcm/iada

1. This is a Next.js application using the App Router and TypeScript. The architecture is split between UI routes under src/app, reusable UI in components, and server-side helpers in src/lib.

2. The main runtime boundary is the Next.js app itself: page components render the user-facing screens, while src/app/api/*/route.ts files expose HTTP endpoints for backend actions. That gives the repo a clear frontend + API split inside a single codebase.

3. The backend data layer appears to be Supabase. src/lib/supabase.ts is the central integration point, and src/lib/auth.ts likely contains authentication/session logic used across protected pages and middleware.

4. Authentication and access control are enforced at the edge with middleware.ts. That suggests route gating before requests reach pages, likely protecting dashboard/admin/patient-management areas and redirecting unauthenticated or blocked users.

5. The core product domain looks like a clinic management system. The API routes under src/app/api/ support clinic lifecycle operations: create, update, delete, freeze, cancel, and list clinics. These routes define the main server-side business boundary.

6. The UI is organized around operational workflows rather than generic navigation. Key screens include dashboard, appointments, patients, payments, prescriptions, and patient-tracking, which likely consume shared clinic/patient data from Supabase through the API or direct server access.

7. There is a public booking flow under src/app/book/[clinicId], indicating a clinic-specific appointment booking page. This is a separate entry path from the internal dashboard, and it likely uses the clinic ID as the primary lookup key.

8. There is also a tokenized daily-log/[token] route, which looks like a shareable or access-controlled workflow distinct from normal authenticated users. That implies a second access model alongside the standard login-protected app.

9. src/app/login and src/app/blocked suggest explicit auth-state outcomes: successful sign-in, and a blocked/denied state for accounts or clinics that are suspended/frozen. The freeze/cancel clinic APIs line up with that lifecycle.

10. components/ClinicProfileSetup.tsx is the notable reusable feature component. It likely supports onboarding or clinic configuration and sits between the admin/management pages and the underlying clinic records.

11. The src/app/api/*/page.tsx files are unusual because they are page routes nested under api. In architecture terms, they behave as UI pages rather than HTTP handlers, so they should be treated as part of the app’s screen structure, not the backend API surface.

12. Overall, the repository centers on one bounded domain: managing clinics, their staff/patients/appointments/payments, and access-controlled operational views. The main data flow is: user or public visitor enters a page → middleware/auth decides access → page loads data from Supabase or calls a route handler → UI updates clinic records and related workflows.