bysxx/fullstack-intern-test

1. This repository is a Next.js 15 App Router template, not a feature-complete product. The architecture is centered on src/app for routing and composition, with shared client-side building blocks elsewhere in src/.

2. The top-level application boundary is src/app/layout.tsx, which likely wraps every route with global structure, metadata, styles, and the app provider layer. src/app/template.tsx is present as a route-level wrapper for per-navigation remounting behavior, which is a distinct App Router concept.

3. The only concrete route in the tree is src/app/(main)/page.tsx, meaning the current app has a main route group but no visible feature subdomains yet. The (main) segment is a route grouping boundary rather than a URL segment, used to organize pages without changing paths.

4. src/app/provider.tsx is the app-wide client-provider entry point. Based on the README, this is where React Query and other client-side context providers are expected to be mounted, separating framework-level server layout from browser-only state and caching concerns.

5. Error and fallback handling is explicit: src/app/not-found.tsx defines the 404 boundary, while UI loading states are represented by shared components such as src/components/ui/loading.tsx, loading-spinner.tsx, and table/skeleton.tsx. That suggests the app treats loading and missing routes as first-class UI states.

6. Shared presentational components live under src/components/ui. These are reusable, mostly framework-agnostic UI primitives and composite controls: accordion, action button, footer, icon, sub-header, notification toggle, and table skeletons. This layer is the main reusable view boundary for the app.

7. There is a client-only boundary in src/components/client-only.tsx, which indicates some UI or hooks are intended to run only in the browser. That is important in a Next.js app because it separates server-rendered content from components that rely on DOM APIs, browser storage, or client state.

8. Local interactive state is split between hooks and a store layer. src/hooks/useCustomHook.ts and src/hooks/useNotification.ts encapsulate reusable behavior, while src/stores/useStore.ts provides global client state via Zustand. This creates a clear separation between logic reuse and shared mutable state.

9. src/utils/notification.ts is a small utility boundary that likely supports notification-related UI or state transitions. Combined with notification-toggle.tsx and useNotification.ts, it suggests notification handling is a small internal subsystem, even though no backend or external notification service is present in the tree.

10. Shared typing lives in src/types/auth.ts, but there are no actual auth routes or auth actions in the checked-in file tree. That implies the template was prepared for future feature expansion, and types are already carved out for domain-specific contracts.

11. Styling is centralized in src/styles/global.css, with Tailwind configured through tailwind.config.js and postcss.config.js. The styling architecture is utility-first, with a global stylesheet for resets/base tokens and Tailwind for component-level styling.

12. The repo has no backend service, database client, or API layer in the current tree. So the current architecture is a frontend-only template with client-state, UI primitives, and App Router scaffolding, ready to be extended into a full-stack app later.

13. In diagram terms, the main flow is: browser request enters the Next.js App Router, layout.tsx and provider.tsx establish global shell and client contexts, route pages like (main)/page.tsx render content, and shared UI/hooks/store/utils provide the interactive behavior layer beneath the page surface.

14. The main architectural boundaries to draw are: routing/app shell, client-provider layer, shared UI components, reusable hooks, global store, utilities, and styling. The current repository is intentionally thin in domain logic, which makes these boundaries the primary structure rather than feature subsystems.