zeon-studio/nextplate

1. This is a content-driven Next.js 16 app using the App Router. The repository is structured like a starter for a marketing/blog site rather than an API service or backend-heavy app. Static pages, content collections, and taxonomy pages are the primary architectural units.

2. The main entry boundary is src/app, which contains route segments for homepage, about, contact, blog, authors, categories, tags, and a fallback not-found page. Dynamic routes such as [single] and paginated blog routes indicate that most pages are generated from content files rather than hand-authored React state.

3. Content is stored in src/content as Markdown/MDX-style documents, grouped by domain: homepage, about, blog posts, authors, contact, reusable pages, and section snippets like testimonials and call-to-action blocks. This content layer is the source of truth for site text, post metadata, and taxonomy relationships.

4. src/lib/contentParser.ts and src/lib/taxonomyParser.ts are the key data-ingestion boundaries. They likely transform markdown content into typed objects the route pages can consume, and they feed list/detail views for posts, authors, tags, and categories. Supporting utilities under src/lib/utils handle sorting, filtering, reading time, date formatting, text conversion, and “similar items” recommendations.

5. The blog subsystem is the richest part of the app. It includes listing pages, single-post pages, pagination, similar-post logic, social sharing, comments via Disqus, and post sidebar/layout chrome. Taxonomy pages for tags and categories are built from the same content graph, so the architecture is centered on one content model projected into multiple views.

6. The author subsystem is separate but parallel to blog content. Author profiles live in src/content/authors, with list and detail routes under src/app/authors. Components such as AuthorCard and related taxonomy utilities suggest authors are first-class entities, not just metadata on posts.

7. Reusable page composition lives in src/layouts. This layer provides shared UI shells and content blocks like Header, Footer, PageHeader, Breadcrumbs, SEO meta, testimonials, call-to-action blocks, and shortcodes such as tabs, accordion, notices, buttons, and embedded video/youtube. This is the main presentation boundary between route pages and reusable view primitives.

8. Client-side interactivity is isolated into hooks and interactive components. Hooks such as useLoadMore, useMounted, useOs, useTooltip, and useWindow support hydration-safe UI behavior, search, theme toggling, and responsive interactions. That suggests a deliberate split between server-rendered content pages and small client-only widgets.

9. Styling is handled by Tailwind CSS v4 plus layered CSS files in src/styles, including base, components, navigation, search, utilities, and a generated theme stylesheet. Theme and config JSON files under src/config drive site-wide behavior such as menus, social links, and theme settings, so visual identity is partly data-driven rather than hardcoded.

10. The repo has a CMS/editing and content-management boundary via Sitepins. The .sitepins config and schema files, plus the public/sitepins-manifest.json asset, indicate Git-backed editing for markdown content and site configuration without a custom admin app. That keeps content authoring outside the React runtime while still versioning changes in Git.

11. Deployment and build tooling are optimized for static output. netlify.toml, the Dockerfile, next-sitemap.config.js, and generated sitemap/robots assets show a static/SEO-focused publishing pipeline. The README also describes post-build generation of llms.txt, llms-full.txt, and per-page markdown exports, which is an additional build-time documentation/data product layered on top of the site.

12. Overall, the architecture is: content and config files feed parsers; parsers feed App Router pages; pages render through shared layouts and shortcode components; client-only hooks add interactivity; build tooling emits SEO, sitemap, and LLM-friendly artifacts. The main diagram should show a clear separation between content sources, presentation/layout components, and build-time generators.