prodip-shadow/digital-life-lessons

1. This is a Next.js App Router application with a clear separation between public-facing pages, authenticated dashboard pages, and API route handlers. The app lives under src/app, with layout.jsx files defining global and section-level shells.

2. The route structure is split into two main UI zones:

- (common): landing and browse-oriented pages such as the homepage, “browse wisdom,” profile viewing, and upgrade messaging.

- (dashboard): authenticated product areas like adding lessons, editing lessons, favorites, earnings history, my lessons, and an admin panel.

3. The core domain appears to be “lessons” or “wisdom” content. That domain is surfaced both in the public browsing experience and in the dashboard where creators manage their own content. The presence of browse-wisdom/[id], lesson editing, likes, comments, and favorites suggests a content marketplace/community model.

4. Server-side API routes are the main integration boundary. The src/app/api/lessons tree provides CRUD-style lesson endpoints plus interaction endpoints for likes, favorites, comments, and a “today-count” metric. This is likely the primary data access layer used by the UI pages.

5. Authentication is handled as a dedicated backend concern under src/app/api/auth/[...all]/route.js, with client/server helper modules in src/lib/auth-client.js and src/lib/auth.js. The proxy.js file likely protects certain routes or performs request-time auth gating for the dashboard/admin areas.

6. Payments and premium access are a separate subsystem. There is a checkout route, a checkout verification route, a Stripe webhook handler, a payment success page, and a scripts/update-premium.js maintenance script. Together these imply an external payment provider updates user entitlements, probably premium status or access unlocks.

7. User and analytics data are exposed through dedicated endpoints:

- api/users/[id] for user profile data

- api/dashboard/metrics for creator-facing stats

- api/admin/metrics for administrative reporting

- api/dashboard/favorites and api/dashboard/earnings-history for personalized account views

This indicates separate metric scopes for end users versus admins.

8. The data persistence boundary is centralized in src/lib/db.js, which likely contains the database client/connection used by route handlers. From the file layout, server routes are the main consumers of persistence rather than client components talking directly to storage.

9. The UI is built from a small set of reusable component families under src/components: navbar, footer, sidebar, cards, buttons, forms, loader, and homepage-specific sections like hero, marquee, pillars, and featured lessons. This suggests a design-system-like component layer rather than page-specific duplication.

10. Styling and presentation are handled with the standard Next.js stack plus a global stylesheet (src/app/globals.css) and PostCSS config. There is also a shader background component and a /shader page, which looks like a visual/experimental feature isolated from the main product flow.

11. Public authentication pages are separate from the dashboard: /sign-in and /sign-up live alongside the main app rather than inside the dashboard group. That keeps the auth entry points lightweight and outside the protected workspace.

12. The overall request flow is: browser hits a page route, the page composes shared components, and any interactive or data-heavy action goes through the matching API route. Payments, auth, content management, and analytics are all mediated server-side, which keeps the client layer mostly presentational and interaction-oriented.

13. Operationally, this is a Vercel-friendly Next.js project with standard package/tooling files and a repository-local script for premium updates. The architecture is optimized for serverless route handlers, authenticated dashboard views, and external webhook-driven state changes.