devmehrab/outreach-ai

1. Overall shape

- This is a Next.js App Router application with a clear split between server-side route handlers under app/api, page routes under app/, and reusable feature components under components/.

- The repo is organized around three main product areas: lists, templates, and a tool/editor workflow.

2. Primary user-facing routes

- app/page.js is the landing page.

- app/login/page.jsx and app/register/page.jsx handle authentication entry points.

- The main authenticated area lives under app/(main)/..., with pages for:

- list and list/[id]

- templates

- settings

- tool

- app/(main)/layout.js likely provides the shared authenticated shell, such as navigation/sidebar and layout framing.

3. Core domain boundaries

- The app’s data model is centered on:

- models/List.js

- models/Template.js

- models/User.js

- These models indicate three persistent domains: user accounts, reusable templates, and user-owned lists.

- The list domain also has sub-views for table/editing and upload/manual creation flows, suggesting list creation and list item management are major interactions.

4. API layer as the server boundary

- Business operations are exposed through route handlers in app/api/....

- There are dedicated endpoints for:

- authentication: login, logout, register, me

- templates: templates and templates/[id]

- lists: lists and lists/[id]

- generation: generate

- This means the frontend mostly talks to the backend through HTTP API calls rather than direct server actions.

5. Data and persistence

- lib/db.js and the model files strongly suggest a database-backed app, likely using a MongoDB-style persistence layer.

- lib/storage.js indicates additional storage concerns beyond normal DB records, likely for uploaded files or derived artifacts.

- The list upload UI and generation flow suggest data can enter the system both manually and through uploaded content.

6. Authentication and access control

- Auth is handled in app/api/login, app/api/logout, app/api/register, and app/api/me.

- lib/auth.js and middleware.js form the security boundary: middleware likely protects authenticated routes and redirects unauthenticated users.

- components/tool/providers/AuthProvider.jsx suggests the frontend also keeps auth state available to the tool/editor subtree.

7. Template-driven generation flow

- The tool area and app/api/generate/route.js point to a workflow where a user inputs content, selects or edits a template, and receives generated output.

- Supporting pieces include:

- components/editor/TemplateEditor.jsx

- components/editor/GeneratedOutput.jsx

- components/inputs/DynamicInputs.jsx

- lib/placeholder.js, lib/replace.js, and constants/placeholderRegex.js

- This implies a pipeline of template + placeholders + input data → generated text/output.

8. Lists UI and interaction model

- The list feature is decomposed into presentation and editing pieces:

- ListView, ListTable, ListCard, ListViewHeader

- CreateListForm, EditableRow

- ManualTab, UploadTab

- DeleteConfirmationModal

- Hooks like hooks/useLists.js likely encapsulate fetching, mutations, and local UI state for list operations.

- components/shared/PaginationControls.jsx suggests list browsing is paginated.

9. Templates UI

- Templates have their own CRUD-oriented UI surface:

- components/template/TemplateCard.jsx

- components/template/Header.jsx

- components/template/SaveTemplateModal.jsx

- hooks/useTemplates.js likely handles fetching and mutating templates from the API.

- This area appears to be the reusable content library that feeds the generation tool and possibly list workflows.

10. Shared frontend infrastructure

- components/ui/* contains the base design-system primitives, likely generated from or inspired by shadcn/ui.

- components/providers/ToasterProvider.jsx indicates global toast/notification handling.

- components/shared/Sidebar.jsx, plus app/(main)/layout.js, define the authenticated shell used across the main app sections.

- hooks/useClipboard.js and lib/clipboard.js support copy/export-like interactions in the tool/editor flow.

11. Rendering and loading states

- The tool route has dedicated loading.jsx and error.jsx, so the generation/editor workflow has explicit async and failure handling.

- This suggests the tool depends on server calls or data hydration that can fail independently of the rest of the app.

- components/ui/skeleton.jsx and similar primitives are likely used to smooth loading states across feature pages.

12. Static assets and product positioning

- public/images/* contains product imagery for hero, AI, upload, list, and send concepts.

- Combined with the route structure, the app looks like a product for building templates, processing lists, and generating output from structured input, rather than a generic CRUD dashboard.