sanbisensei/live-bakery

1. This is a Next.js App Router application for a cake/bakery storefront. The repository is organized around route segments under src/app, with a mix of public customer-facing pages and a separate admin area.

2. The public storefront is split into product/content sections: home (src/app/page.tsx), cakes catalog (src/app/cakes), cake detail pages (src/app/cakes/[slug]), blog listing and article pages (src/app/blog, src/app/blog/[slug]), reviews (src/app/reviews), custom cake ordering (src/app/custom-cake), checkout (src/app/checkout), and authentication entry points (src/app/login, src/app/signup).

3. The admin subsystem is isolated under src/app/admin and has dedicated pages for managing cakes, blog posts, orders, and promotions. This suggests a separate operational back office, likely sharing the same app shell but serving different workflows and permissions than the customer storefront.

4. Shared presentation is concentrated in src/components. src/components/layout contains the global page chrome: Navbar, Hero, and Footer. src/components/ui/CakeCard.tsx is a reusable product card used to render cake listings consistently across catalog-like screens.

5. The application layout and global styling are centralized in src/app/layout.tsx and src/app/globals.css. This is the main boundary for site-wide structure, typography, and theme, while next.config.ts and postcss.config.mjs indicate standard Next.js build-time configuration and CSS processing.

6. src/lib/supabase.ts is the only explicit infrastructure/data-layer module in the tree. It likely encapsulates the Supabase client and serves as the boundary between UI routes and backend services such as database access, auth, or file storage. No separate API route layer is visible, so data access is probably performed directly from route components or shared helpers.

7. The routing model suggests slug-based dynamic content for baked goods and blog posts. cakes/[slug] and blog/[slug] indicate CMS-like detail views where a list page feeds into per-item pages, which is a common structure for product catalogs and editorial content.

8. Authentication is present as first-class UX, but the implementation appears app-based rather than a separate auth service. login and signup pages likely connect to Supabase auth or another identity flow through shared client logic, with the admin section depending on those credentials for access control.

9. There is no evidence of a standalone backend server, worker process, or message queue in this repo. The architecture is primarily a front-end application with integrated service calls, meaning the important system boundaries are between UI routes, reusable components, and the Supabase-backed data/auth layer.

10. The repository is set up for Vercel-style deployment, which fits the Next.js default hosting model. The README confirms a standard Next.js workflow and uses next/font for optimized font loading, reinforcing that the app is intended to be built and deployed as a single Next.js project rather than a multi-service system.

11. For an architecture diagram, the main boxes should be: customer-facing pages, admin pages, shared layout/components, and the Supabase integration layer. The arrows should show route pages consuming shared UI components and reaching into src/lib/supabase.ts for data, auth, and possibly media-backed content.