charan270469/dailyez

Purpose and entry points

DailyEz is a full-stack priority-inbox product intended to consolidate important communications and rank them by user relevance. The browser application starts at src/main.tsx, renders src/App.tsx, and is built with Vite (vite.config.ts). The backend entry point is server/index.js.

Client application shell

The frontend is a TypeScript React dashboard organized around a persistent layout and navigation:

• src/DashboardLayout.tsx

• src/components/Sidebar.tsx

• src/components/TopNavbar.tsx

It presents separate priority, inbox, matched, archive, analytics, settings, help, and watchlist views. The primary message-review surfaces are src/components/PriorityFeed.tsx, src/components/InboxFeed.tsx, and src/components/MessageDetailModal.tsx.

Client/server boundary

Frontend data access is centralized in src/lib/api.ts, which is the key boundary between UI state and backend endpoints. Shared client-side message/domain shapes live in src/types.ts; src/mockData.ts likely supports development/demo rendering when live data is absent. Authentication-facing UI and connected-platform state are represented by src/components/EditProfileModal.tsx and src/components/ConnectedPlatforms.tsx.

Backend API, identity, and persistence

The server owns request handling, authentication, and database access:

• server/index.js

• server/auth.js

• server/authRoutes.js

• server/db.js

This separates identity/session or provider authorization concerns from message processing. The exact database and auth provider are not identifiable from the supplied tree, but Gmail access likely crosses this boundary before ingestion.

Gmail ingestion stage

Gmail is the only explicitly implemented source adapter in the repository:

• server/gmail/fetchMessages.js

• server/index.js

• server/authRoutes.js

Its control flow is expected to authenticate/connect a user, fetch Gmail messages, then pass message content and metadata into the matching pipeline. Although the product description names WhatsApp and Discord, no corresponding source adapters appear in this tree.

Relevance and watchlist matching pipeline

Message prioritization is decomposed into focused server-side stages:

• server/agents/parseSignalEntity.js

• server/agents/matchSourceIntent.js

• server/agents/keywordMatch.js

• server/agents/matchSignal.js

• server/watchlistMatcher.js

The likely flow is: parse entities/signals from an incoming message, assess source intent, compare terms and entities against a watchlist, then produce a match/relevance signal. This modular boundary is the core ranking/explainability layer that feeds the priority and matched-message UI.

User feedback and presentation loop

Matched or prioritized records are surfaced through src/components/MatchedTab.tsx, src/components/InboxMessageCard.tsx, and src/components/WatchlistPanel.tsx. User-managed watchlist criteria form the principal feedback/control input into server matching. Analytics visualization is isolated in src/components/AnalyticsTab.tsx and src/components/DailyVolumeChart.tsx, while archived content is handled by src/components/ArchiveTab.tsx.