You are tasked with building a Minimum Viable Product (MVP) for a web application called 'Identity Guardian'. This application aims to help users detect and resolve fraudulent student loan or enrollment notifications they receive for institutions they never attended. The MVP should be a multi-page Next.js application using the App Router structure (app/ directory). It must include a robust backend with API routes for full CRUD operations and a PostgreSQL database managed by Drizzle ORM.
**Core Functionality:**
1. **User Authentication:** Secure user signup and login.
2. **Institution Management:** Users can add and manage a list of educational institutions they have attended or applied to. They should also be able to mark institutions they have *not* interacted with.
3. **Fraudulent Notification Simulation:** The core MVP feature. Users can input details of a notification they received (e.g., institution name, amount owed, notification date, contact details of the sender). The application should simulate a check against the user's list of attended institutions. If the received notification is from an institution *not* on the user's 'attended' list (or explicitly marked as 'never attended'), it should be flagged as potentially fraudulent.
4. **Fraud Alerting:** When a potentially fraudulent notification is detected, the system should trigger an alert to the user within the application dashboard and via email.
5. **Dispute Letter Generation (Basic):** For flagged notifications, generate a basic dispute letter template. This template should pre-fill with the user's information, the fraudulent institution's details, and the notification specifics. The user can then copy, paste, and modify this letter to send to the institution or collection agency.
6. **Dashboard:** A central place for users to view their registered institutions, received notifications (both legitimate and flagged), and generated dispute letters.
**Technical Requirements:**
* **Framework:** Next.js (App Router - app/ directory)
* **Database:** PostgreSQL
* **ORM:** Drizzle ORM (for PostgreSQL)
* **Styling:** Tailwind CSS (or a similar utility-first CSS framework)
* **State Management:** React Context API or Zustand
* **API Routes:** Implement API routes (`app/api/...`) for all backend operations.
* **CRUD Operations:** Ensure full Create, Read, Update, and Delete functionality for:
* User profiles
* Registered Institutions (user's legitimate institutions)
* Received Notifications (user-inputted suspicious notifications)
* Dispute Letters (generated templates)
* **Database Schema (Drizzle):**
* `users` table: id, name, email, passwordHash, createdAt, updatedAt
* `institutions` table: id, userId, name, address, status (e.g., 'attended', 'applied', 'never_attended')
* `notifications` table: id, userId, institutionName, amountOwed, notificationDate, senderContact, status (e.g., 'flagged', 'verified', 'resolved'), createdAt, updatedAt
* `disputeLetters` table: id, userId, notificationId, templateContent, generatedAt, status (e.g., 'draft', 'sent')
**Development Instructions:**
* Set up a new Next.js project with the App Router enabled.
* Integrate PostgreSQL with Drizzle ORM.
* Create the API routes for each CRUD operation. For example, `/api/institutions` for institution management, `/api/notifications` for handling submitted notifications, etc.
* Develop the UI components for each page: Home, Login, Signup, Dashboard, Add Institution, View Notification, Generate Dispute Letter.
* Implement the logic for flagging notifications based on the user's institution list.
* Implement the dispute letter generation logic, pulling data from the relevant tables.
* Ensure the application is responsive and has a clean, user-friendly interface.
* Do NOT create a single-page application (SPA) that lacks distinct pages. The application should have a clear multi-page structure navigable via links.
* The `flagged` status in the `notifications` table should be determined by comparing the `institutionName` from the notification against the `name` of institutions in the `institutions` table for that user, checking if the `status` of the institution is 'attended' or 'applied'. If no match is found or the institution status is 'never_attended', it's flagged.