27 enhance email

.cursor/rules/overall.mdc

@@ -0,0 +1,40 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+You are a Senior Front-End Developer and an Expert in ReactJS, NextJS, JavaScript, TypeScript, HTML, CSS and modern UI/UX frameworks (e.g., TailwindCSS, Shadcn, Radix). You are thoughtful, give nuanced answers, and are brilliant at reasoning. You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning.
+
+- Follow the user’s requirements carefully & to the letter.
+- First think step-by-step - describe your plan for what to build in pseudocode, written out in great detail.
+- Confirm, then write code!
+- Always write correct, best practice, DRY principle (Dont Repeat Yourself), bug free, fully functional and working code also it should be aligned to listed rules down below at Code Implementation Guidelines .
+- Focus on easy and readability code, over being performant.
+- Fully implement all requested functionality.
+- Leave NO todo’s, placeholders or missing pieces.
+- Ensure code is complete! Verify thoroughly finalised.
+- Include all required imports, and ensure proper naming of key components.
+- Be concise Minimize any other prose.
+- If you think there might not be a correct answer, you say so.
+- If you do not know the answer, say so, instead of guessing.
+
+### Coding Environment
+The user asks questions about the following coding languages:
+- ReactJS
+- JavaScript
+- TypeScript
+- TailwindCSS
+- HTML
+- CSS
+
+### Requirements
+- Read the project requirements and techhincal design from the docs directory and store it in memory
+
+### Code Implementation Guidelines
+Follow these rules when you write code:
+- Use early returns whenever possible to make the code more readable.
+- Always use Tailwind classes for styling HTML elements; avoid using CSS or tags.
+- Use “class:” instead of the tertiary operator in class tags whenever possible.
+- Use descriptive variable and function/const names. Also, event functions should be named with a “handle” prefix, like “handleClick” for onClick and “handleKeyDown” for onKeyDown.
+- Implement accessibility features on elements. For example, a tag should have a tabindex=“0”, aria-label, on:click, and on:keydown, and similar attributes.
+- Use consts instead of functions, for example, “const toggle = () =>”. Also, define a type if possible.

README.md

@@ -37,12 +37,14 @@ Data Handling:
 - Email integration via Gmail compose URL
 
 Data Security:
+
 - Web Crypto API for encryption
 - AES-GCM encryption algorithm
 - PBKDF2 key derivation
 - Secure salt generation and storage
 
 Data Storage:
+
 - IndexedDB for encrypted data
 - Dexie.js for IndexedDB management
 - Encrypted records for all sensitive data
@@ -109,13 +111,13 @@ Data Storage:
 ## Security Features
 
 ### Encryption
+
 - Uses browser's native Web Crypto API
 - AES-GCM encryption for all sensitive data
 - Secure key derivation using PBKDF2
 - Unique IV (Initialization Vector) per encryption
 - Automatic salt generation and management
 
-
 ## License
 
 ### MIT License

docs/requirements.md

@@ -0,0 +1,94 @@
+# MeetWise Requirements Document
+
+**Version:** 1.0
+**Date:** 2024-03-30
+
+## 1. Introduction
+
+MeetWise is a web application designed to help users manage, review, rate, and plan their meetings effectively. It integrates with Google Calendar and provides visualization, prioritization, and reporting features to optimize meeting schedules.
+
+## 2. Goals
+
+- Improve meeting productivity and effectiveness.
+- Provide insights into meeting load and time allocation.
+- Enable users to prioritize upcoming meetings.
+- Facilitate feedback collection on past meetings.
+- Offer a secure and user-friendly interface.
+- Ensure data privacy through client-side encryption.
+
+## 3. Functional Requirements
+
+### 3.1 User Authentication & Authorization
+
+- **FR-AUTH-01:** Users must authenticate via Google OAuth to access Google Calendar data and send emails via Gmail.
+- **FR-AUTH-02:** The application must request necessary Google API scopes (calendar read, gmail send).
+
+### 3.2 Data Import & Management
+
+- **FR-DATA-01:** Users must be able to import calendar events from Google Calendar for specified date ranges.
+- **FR-DATA-02:** Users must be able to import calendar events from a JSON file.
+- **FR-DATA-03:** Imported events must be transformed into the application's `Meeting` data structure.
+- **FR-DATA-04:** Meetings should be filterable based on date ranges (e.g., upcoming week, past week, past 90 days).
+- **FR-DATA-05:** Application data (meetings, settings, ratings, comments, etc.) must be persistently stored locally in the user's browser.
+- **FR-DATA-06:** All sensitive user data stored locally must be encrypted using strong client-side encryption (AES-GCM).
+- **FR-DATA-07:** Users must be able to clear all locally stored application data.
+- **FR-DATA-08:** The application should provide an option to use mock meeting data for demonstration or testing.
+
+### 3.3 Meeting Review (Dashboard)
+
+- **FR-REV-01:** Display meetings from a defined historical period (e.g., past 90 days).
+- **FR-REV-02:** Display visualizations of meeting load over time (e.g., weekly hours chart).
+- **FR-REV-03:** Display visualizations of free vs. meeting hours based on a target.
+- **FR-REV-04:** Display visualizations of meeting type distribution (if applicable - requires type data).
+- **FR-REV-05:** Users must be able to reorder the dashboard components via drag-and-drop.
+
+### 3.4 Meeting Rating
+
+- **FR-RATE-01:** Display meetings from a defined recent period (e.g., past week).
+- **FR-RATE-02:** Allow users to rate meetings on a numerical scale (e.g., 1-5).
+- **FR-RATE-03:** Allow users to add textual comments to their meeting ratings.
+- **FR-RATE-04:** Store meeting ratings and comments persistently and securely.
+- **FR-RATE-05:** Display existing ratings for meetings when shown.
+- **FR-RATE-06:** Display insights derived from meeting ratings (if implemented).
+
+### 3.5 Meeting Planning
+
+- **FR-PLAN-01:** Display meetings for an upcoming period (e.g., next 7 days).
+- **FR-PLAN-02:** Allow users to define weekly priorities (free text).
+- **FR-PLAN-03:** Display meetings grouped by priority level (High, Regular, Low).
+- **FR-PLAN-04:** Allow users to change a meeting's priority level via drag-and-drop between priority groups.
+- **FR-PLAN-05:** Allow users to reorder meetings within a priority group via drag-and-drop.
+- **FR-PLAN-06:** Meeting rank/order must be updated and persisted based on drag-and-drop actions.
+- **FR-PLAN-07:** Allow users to mark meetings with action flags (e.g., Needs Cancel, Needs Shorten, Needs Reschedule, Prep Required).
+- **FR-PLAN-08:** Allow users to add comments specific to planning/actions for a meeting.
+- **FR-PLAN-09:** Display meeting statistics for the planned period (Total hours, Target hours, Available hours, Over hours).
+- **FR-PLAN-10:** Allow users to configure their target meeting hours per week.
+- **FR-PLAN-11:** Display insights derived from upcoming meetings (if implemented).
+
+### 3.6 Reporting & Export
+
+- **FR-REP-01:** Users must be able to generate an email report summarizing meeting plans, priorities, actions needed, and recent ratings.
+- **FR-REP-02:** Users must be able to specify one or more recipients for the email report.
+- **FR-REP-03:** The email report must be sent as a single email to all specified recipients using the authenticated user's Gmail account via the Gmail API.
+- **FR-REP-04:** The email report content should be formatted in HTML.
+- **FR-REP-05:** The email report should include links back to the corresponding Google Calendar events.
+
+## 4. Non-Functional Requirements
+
+- **NFR-PERF-01:** The UI must be responsive and performant, handling potentially large numbers of meetings smoothly.
+- **NFR-PERF-02:** Data loading and initialization should display appropriate loading indicators.
+- **NFR-SEC-01:** All sensitive data stored in the browser (IndexedDB) must be encrypted using the Web Crypto API (AES-GCM with PBKDF2 derived key).
+- **NFR-SEC-02:** Google API credentials (Client ID) should be stored securely (e.g., in environment variables) and not hardcoded in the source.
+- **NFR-UIUX-01:** The UI must be intuitive and follow modern design principles (using shadcn/ui and Tailwind CSS).
+- **NFR-MAINT-01:** The codebase must be well-structured, documented, and follow TypeScript best practices (Clean Code, Async/Await, Error Handling).
+- **NFR-ERR-01:** The application must handle errors gracefully (e.g., API errors, data parsing errors, encryption/decryption errors) and provide informative feedback to the user.
+
+## 5. Future Considerations (Out of Scope for v1.0)
+
+- Integration with other calendar providers (Outlook, etc.).
+- Real-time collaboration features.
+- More advanced meeting analytics and insights.
+- Customizable reporting templates.
+- Backend storage for cross-device synchronization.
+- Automated meeting suggestions/optimizations.
+- Service worker for offline capabilities.

docs/technical-design.md

@@ -0,0 +1,152 @@
+# MeetWise Technical Design Document
+
+**Version:** 1.0
+**Date:** 2024-03-30
+
+## 1. Introduction
+
+This document outlines the technical design and architecture of the MeetWise application. It details the technologies used, component structure, data flow, state management, and key service implementations.
+
+## 2. Architecture Overview
+
+MeetWise is a client-side single-page application (SPA) built with React (using Vite and TypeScript). It relies heavily on browser capabilities for storage (IndexedDB) and cryptography (Web Crypto API). Data persistence and state management are handled locally within the browser. Integration with Google services (Calendar and Gmail) occurs directly from the client after user authentication via Google OAuth.
+
+## 3. Technology Stack
+
+- **Frontend Framework:** React 18.x with TypeScript
+- **Build Tool:** Vite
+- **Styling:** Tailwind CSS
+- **UI Components:** shadcn/ui (built on Radix UI primitives)
+- **State Management:** Zustand (with `persist` middleware for IndexedDB integration via `db.ts`)
+- **Data Storage (Client-Side):** IndexedDB (managed via Dexie.js in `db.ts`)
+- **Client-Side Encryption:** Web Crypto API (AES-GCM, PBKDF2) implemented in `encryption.ts`
+- **Drag & Drop:** `@hello-pangea/dnd`
+- **Charting/Visualization:** Recharts (implicitly used by components like `WeeklyMeetingLoad`)
+- **Linting/Formatting:** ESLint, Prettier
+- **Google Integration:** Google API Client Library for JavaScript (gapi), Google Identity Services (gis)
+
+## 4. Project Structure
+
+```
+.
+├── README.md
+├── CONTRIBUTING.md
+├── LICENSE
+├── app-script/
+│   └── calendar-export-sample.js
+├── dist/
+│   ├── index.html
+│   └── assets/
+├── docs/
+│   ├── requirements.md
+│   └── technical-design.md
+├── scripts/
+│   └── generateMockData.ts
+├── src/
+│   ├── App.tsx
+│   ├── main.tsx
+│   ├── components/
+│   ├── hooks/
+│   ├── lib/
+│   ├── services/
+│   ├── stores/
+│   ├── styles/
+│   ├── types/
+│   └── utils/
+├── index.html
+├── package.json
+├── package-lock.json
+├── tsconfig.json
+├── vite.config.ts
+└── postcss.config.js
+```
+
+## 5. Core Components & Services
+
+### 5.1 `App.tsx`
+
+- Main application shell.
+- Initializes Google API service and Zustand store (`initializeStore`).
+- Handles top-level state for active tab (Review, Rate, Plan).
+- Renders `Header` and the currently active tab component (`Review`, `Rate`, or `Plan`).
+- Manages loading state during initialization.
+
+### 5.2 `settingsStore.ts` (Zustand Store)
+
+- Central hub for application state.
+- Holds `meetings`, `targetHours`, `meetingRatings`, `meetingComments`, `meetingStatus`, `weeklyPriorities`, etc.
+- Provides actions to modify state (e.g., `setMeetings`, `setMeetingRating`, `setMeetingStatus`, `updateMeetings`).
+- Uses `persist` middleware to automatically save/load state to/from IndexedDB via `db.ts`.
+- Handles initialization (`initializeStore`) by loading all data from `db.ts`.
+- Contains logic for updating meeting ranks based on drag-and-drop.
+
+### 5.3 `db.ts` (Dexie Wrapper)
+
+- Abstraction layer over IndexedDB using Dexie.js.
+- Defines database schema with tables for `meetings`, `settings`, `meetingRatings`, etc.
+- **Crucially, interacts with `EncryptionManager` to encrypt data before writing to IndexedDB and decrypt after reading.**
+- Provides methods for CRUD operations on all stored data types (e.g., `setMeeting`, `getMeeting`, `getAllMeetings`, `setSetting`, `getSetting`, `clearAll`).
+
+### 5.4 `encryption.ts` (Encryption Manager)
+
+- Implements client-side encryption using the Web Crypto API.
+- Uses AES-GCM for authenticated encryption.
+- Derives the encryption key using PBKDF2 from a salt stored in `localStorage`. This ensures the key is persistent for the user's browser session but not stored directly.
+- Handles key derivation, salt generation/storage, IV generation, encryption, and decryption.
+- Provides `encrypt<T>(data)` and `decrypt<T>(encryptedString)` methods used by `db.ts`.
+
+### 5.5 `googleCalendarService.ts`
+
+- Handles all interactions with Google APIs (Calendar & Gmail).
+- Initializes the Google API Client (`gapi`) and Google Identity Services (`gis`) libraries.
+- Manages the Google OAuth 2.0 authentication flow (`authenticate`, `getAuth`).
+- Fetches calendar events (`getCalendarEvents`) using specified date ranges.
+- Filters fetched events (removes all-day events, holidays, single-attendee meetings).
+- Provides user's email (`getUserEmail`).
+- Contains logic to construct and send emails via the Gmail API (`users.messages.send` endpoint, used by `ampEmailService.ts`).
+
+### 5.6 `calendarService.ts`
+
+- Defines date range logic (`getDateRanges`, `DAYS_AGO`, `DAYS_AHEAD`).
+- Provides functions to import data from Google Calendar (`importGoogleCalendar`) by calling `googleCalendarService`.
+- Includes logic to import calendar data from uploaded JSON files (`importCalendarData`, `transformCalendarEvents`).
+- Filters meetings based on specific date ranges (`filterMeetingsByDateRange`).
+
+### 5.7 `ampEmailService.ts`
+
+- Responsible for constructing the HTML content of the email report (`generateAmpEmailContent`).
+- Fetches necessary data from the `db` (via `settingsStore` indirectly perhaps, or directly) like priorities, meeting status, comments, ratings.
+- Formats the data into a structured HTML email.
+- Generates Google Calendar links for meetings.
+- Calls `googleCalendarService.getAuth()` to get the token and then uses `fetch` to call the Gmail API (`users.messages.send`) to send the composed email to recipients specified by the user.
+
+### 5.8 UI Components (`Plan.tsx`, `Review.tsx`, `Rate.tsx`, etc.)
+
+- Responsible for rendering specific views.
+- Fetch data primarily from the `settingsStore`.
+- Implement drag-and-drop functionality (`Plan`, `Review`) using `@hello-pangea/dnd` and update the store accordingly (`updateMeetings` action).
+- Use sub-components (`MeetingCard`, `MeetingRater`, `StatsPanel`, charting components) for modularity.
+- Trigger actions in the `settingsStore` based on user interactions (e.g., rating a meeting, changing status flags, adding comments).
+
+## 6. Data Flow
+
+1.  **Initialization:** `App.tsx` -> `googleCalendarService.initializeGoogleApi` -> `settingsStore.initializeStore` -> `db.ts` (loads all encrypted data) -> `encryption.ts.decrypt` -> State hydrated in Zustand.
+2.  **Import Google Calendar:** `Header.tsx` -> `calendarService.importGoogleCalendar` -> `googleCalendarService.getCalendarEvents` -> `settingsStore.setMeetings` -> `db.ts.setMeeting` -> `encryption.ts.encrypt`.
+3.  **User Interaction (e.g., Drag-and-Drop in `Plan.tsx`):** `Plan.tsx` (DnD event) -> Calculates new ranks/priorities -> Calls `settingsStore.updateMeetings` -> `db.ts.setMeeting` (for each updated meeting) -> `encryption.ts.encrypt`.
+4.  **Rating Meeting:** `MeetingRater.tsx` -> `settingsStore.setMeetingRating` -> `db.ts.setMeetingRating` -> `encryption.ts.encrypt`.
+5.  **Sending Email:** `EmailDialog.tsx` (gets recipients) -> `ampEmailService.sendEmail` -> `ampEmailService.generateAmpEmailContent` (reads data from db/store) -> `googleCalendarService.getAuth` -> `fetch` (Gmail API `users.messages.send`).
+
+## 7. Security Considerations
+
+- **Client-Side Encryption:** The primary security measure for stored data. Relies on the browser's Web Crypto API and key derivation from a locally stored salt. The actual user password/passphrase is not used directly for the symmetric key. Data is only decrypted in the user's browser session.
+- **Google OAuth:** Standard secure method for accessing Google data. Access tokens are handled by the Google libraries and `googleCalendarService`.
+- **API Keys:** The `VITE_GOOGLE_CLIENT_ID` is stored in `.env`. While Vite replaces this at build time, it's still embedded in the client-side bundle. This is standard practice for OAuth Client IDs meant for client-side flows but should not be used for sensitive _secret_ keys.
+- **Data Exposure:** Since decryption happens client-side, decrypted data exists in the application's JavaScript memory during runtime. Standard browser security measures (sandboxing, same-origin policy) provide protection.
+
+## 8. Potential Improvements / Future Work
+
+- **Backend Refactor:** Move Google API interactions (especially email sending if using a backend key becomes necessary) and potentially data storage/encryption to a secure backend service for cross-device syncing and enhanced security.
+- **Error Handling:** Implement more robust and user-friendly error handling across all services and components.
+- **Testing:** Add unit and integration tests for services and state logic.
+- **Performance Optimization:** Analyze performance with large datasets and optimize rendering, data fetching, and encryption/decryption if needed.
+- **Code Splitting:** Implement code splitting for faster initial load times.