Move over relations to emailAccount

.cursor/rules/data-fetching.mdc

@@ -27,17 +27,18 @@ const { data, isLoading, error } = useSWR<PlanHistoryResponse>(
 ```
 
 ## Error Handling
-Use `isActionError` with `toastError` and `toastSuccess`. Success toast is optional:
+
+Use `result?.serverError` with `toastError` and `toastSuccess`. Success toast is optional:
 
 ```typescript
 import { toastError, toastSuccess } from "@/components/Toast";
 
 const onSubmit: SubmitHandler<TestRulesInputs> = useCallback(async (data) => {
   const result = await testAiCustomContentAction({ content: data.message });
-  if (isActionError(result)) {
+  if (result?.serverError) {
     toastError({
       title: "Error testing email",
-      description: result.error,
+      description: result?.serverError || "",
     });
   } else {
     toastSuccess({ description: "Saved!" });

.cursor/rules/form-handling.mdc

@@ -18,21 +18,21 @@ import { toastSuccess, toastError } from "@/components/Toast";
 import { createExampleAction } from "@/utils/actions/example";
 import { type CreateExampleBody } from "@/utils/actions/example.validation";
 
-export const ExampleForm = () => {
+export const ExampleForm = ({ emailAccountId }: { emailAccountId: string }) => {
   const {
     register,
     handleSubmit,
     formState: { errors, isSubmitting },
   } = useForm<CreateExampleBody>({
-    resolver: zodResolver(processHistorySchema),
+    resolver: zodResolver(schema),
   });
 
   const onSubmit: SubmitHandler<CreateExampleBody> = useCallback(
     async (data) => {
-      const result = await createExampleAction(data.email);
+      const result = await createExampleAction(emailAccountId, data);
 
-      if (isActionError(result)) {
-        toastError({ title: "Error", description: result.error });
+      if (result?.serverError) {
+        toastError({ title: "Error", description: result.serverError });
       } else {
         toastSuccess({ description: "Created example!" });
       }

.cursor/rules/get-api-route.mdc

@@ -11,29 +11,22 @@ Basic Structure. Note how we auto generate the response type for use on the clie
 
 ```typescript
 import { NextResponse } from "next/server";
-import { auth } from "@/app/api/auth/[...nextauth]/auth";
 import prisma from "@/utils/prisma";
-import { withError } from "@/utils/middleware";
+import { withAuth } from "@/utils/middleware";
 
 export type GetExampleResponse = Awaited<ReturnType<typeof getData>>;
 
-export const GET = withError(async () => {
-  const session = await auth();
-  if (!session?.user.id)
-    return NextResponse.json({ error: "Not authenticated" }, { status: 401 });
+export const GET = withAuth(async () => {
+  const emailAccountId = request.auth.emailAccountId;
+
 
-  const result = getData(session.user.id);
+  const result = getData({ email });
   return NextResponse.json(result);
 });
 
-async function getData(userId: string) {
+async function getData({ email }: { email: string }) {
   const items = await prisma.example.findMany({
-    where: {
-      userId: session.user.id,
-    },
-    orderBy: {
-      updatedAt: "desc",
-    },
+    where: { email },
   });
 
   return { items };
@@ -44,8 +37,8 @@ See [data-fetching.mdc](mdc:.cursor/rules/data-fetching.mdc) as to how this woul
 
 Key Requirements:
 
-   - Always wrap the handler with `withError` for consistent error handling. We don't need try/catch
-   - Always check authentication using `auth()`
-   - Infer and export response type
-   - Use Prisma for database queries. See [prisma.mdc](mdc:.cursor/rules/prisma.mdc)
+   - Always wrap the handler with `withAuth` for consistent error handling and authentication.
+   - We don't need try/catch as `withAuth` handles that.
+   - Infer and export response type.
+   - Use Prisma for database queries.
    - Return responses using `NextResponse.json()`

.cursor/rules/hooks.mdc

@@ -0,0 +1,20 @@
+---
+description: React hooks
+globs: 
+alwaysApply: false
+---
+# Custom Hook Guidelines
+
+This rule outlines the guidelines for creating custom React hooks within this project.
+
+## Custom Hooks
+
+-   **Purpose:** Encapsulate reusable stateful logic, especially for data fetching or complex UI interactions.
+-   **Location:** Place custom hooks in the `apps/web/hooks/` directory.
+-   **Naming:** Use the `use` prefix (e.g., `useAccounts.ts`).
+-   **Data Fetching:** For fetching data from API endpoints, prefer using `useSWR`. Follow the guidelines outlined in [data-fetching.mdc](mdc:.cursor/rules/data-fetching.mdc).
+    -   Create dedicated hooks for specific data types (e.g., `useAccounts`, `useLabels`).
+    -   The hook should typically wrap `useSWR`, handle the API endpoint URL, and return the data, loading state, error state, and potentially the `mutate` function from SWR.
+-   **Simplicity:** Keep hooks focused on a single responsibility.
+
+By adhering to these guidelines, we ensure a consistent approach to reusable logic and data fetching throughout the application.

.cursor/rules/index.mdc

@@ -28,17 +28,17 @@ Guidelines for building user interfaces and handling frontend logic.
 | Rule File                          | Description                                                 |
 | :--------------------------------- | :---------------------------------------------------------- |
 | @page-structure.mdc                | Page structure guidelines                                   |
-| @ui-components.mdc                 | UI component and styling guidelines (Shadcn, Radix, Tailwind) |
+| @ui-components.mdc                 | UI component and styling guidelines (Shadcn, Tailwind)      |
 | @form-handling.mdc                 | Form handling using React Hook Form and Zod                 |
 | @data-fetching.mdc                 | Fetching data from the API using SWR                        |
+| @hooks.mdc                         | Guidelines for creating custom React hooks                  |
 
 ## Backend & API
 
 Guidelines for implementing backend logic, APIs, and data persistence.
 
 | Rule File                          | Description                                                 |
 | :--------------------------------- | :---------------------------------------------------------- |
-| @api-routes.mdc                    | Guidelines for implementing Next.js API routes (general)    |
 | @get-api-route.mdc                 | Guidelines for implementing GET API routes in Next.js       |
 | @server-actions.mdc                | Guidelines for implementing Next.js server actions          |
 | @prisma.mdc                        | How to use Prisma                                           |

.cursor/rules/server-actions.mdc

@@ -17,51 +17,86 @@ For `apps/web/utils/actions/NAME.validation.ts`:
 ```typescript
 import { z } from "zod";
 
-export const createApiKeyBody = z.object({ name: z.string().nullish() });
-export type CreateApiKeyBody = z.infer<typeof createApiKeyBody>;
+// Example: Schema for updating AI settings
+export const saveAiSettingsBody = z.object({
+  aiProvider: z.string().optional(), // Adjust types as needed
+  aiModel: z.string().optional(),
+  aiApiKey: z.string().optional(),
+});
+export type SaveAiSettingsBody = z.infer<typeof saveAiSettingsBody>;
+
+// Example: Schema for updating email settings (requires emailAccountId binding)
+export const saveEmailUpdateSettingsBody = z.object({
+  statsEmailFrequency: z.string().optional(), // Use specific enum/types if applicable
+  summaryEmailFrequency: z.string().optional(),
+});
+export type SaveEmailUpdateSettingsBody = z.infer<
+  typeof saveEmailUpdateSettingsBody
+>;
 
-export const deactivateApiKeyBody = z.object({ id: z.string() });
-export type DeactivateApiKeyBody = z.infer<typeof deactivateApiKeyBody>;
 ```
 
 For `apps/web/utils/actions/NAME.ts`:
 
 ```typescript
-'use server';
+"use server";
 
-import { revalidatePath } from "next/cache";
-import { auth } from "@/app/api/auth/[...nextauth]/auth";
-import prisma from "@/utils/prisma";
-import { withActionInstrumentation } from "@/utils/actions/middleware";
+import { actionClient, actionClientUser } from "@/utils/actions/safe-action";
 import {
-  deactivateApiKeyBody,
-  type DeactivateApiKeyBody,
-} from "@/utils/actions/api-key.validation";
-
-export const deactivateApiKeyAction = withActionInstrumentation(
-  "deactivateApiKey",
-  async (unsafeData: DeactivateApiKeyBody) => {
-    const session = await auth();
-    const userId = session?.user.id;
-    if (!userId) return { error: "Not logged in" };
+  saveAiSettingsBody,
+  saveEmailUpdateSettingsBody,
+} from "@/utils/actions/settings.validation"; // Adjust path
+import prisma from "@/utils/prisma";
+import { revalidatePath } from "next/cache"; // Import if needed for cache invalidation
 
-    const { data, success, error } =
-      deactivateApiKeyBody.safeParse(unsafeData);
-    if (!success) return { error: error.message };
+// Example using actionClientUser (requires authenticated user context)
+export const updateAiSettingsAction = actionClientUser
+  .metadata({ name: "updateAiSettings" }) // For logging/instrumentation
+  .schema(saveAiSettingsBody) // Zod schema for input validation
+  .action(
+    async ({
+      ctx: { userId }, // Access context provided by the safe-action client
+      parsedInput: { aiProvider, aiModel, aiApiKey }, // Validated and typed input
+    }) => {
+      await prisma.user.update({
+        where: { id: userId },
+        data: { aiProvider, aiModel, aiApiKey },
+      });
+    },
+  );
 
-    await prisma.apiKey.update({
-      where: { id: data.id, userId },
-      data: { isActive: false },
-    });
+// Example using actionClient (requires authenticated user + bound emailAccountId)
+export const updateEmailSettingsAction = actionClient
+  .metadata({ name: "updateEmailSettings" })
+  .schema(saveEmailUpdateSettingsBody)
+  // Note: emailAccountId is bound when calling this action from the client
+  .action(
+    async ({
+      ctx: { emailAccountId }, // Access context (includes userId, email etc.)
+      parsedInput: { statsEmailFrequency, summaryEmailFrequency },
+    }) => {
+      await prisma.emailAccount.update({
+        where: { id: emailAccountId },
+        data: {
+          statsEmailFrequency,
+          summaryEmailFrequency,
+        },
+      });
+    },
+  );
 
-    revalidatePath("/settings");
-  }
-);
 ```
 
 ## Implementation Guidelines
-- Implement type-safe server actions with proper validation
-- Define input schemas using Zod for robust type checking and validation
-- Handle errors gracefully and return appropriate responses
-- Ensure all server actions return the `Promise<ServerActionResponse>` type
-- The zod schema will also be used on the client for form validation.
+- **Use `next-safe-action`:** Implement all server actions using the `next-safe-action` library for type safety, input validation, context management, and error handling. Refer to `apps/web/utils/actions/safe-action.ts` for client definitions (`actionClient`, `actionClientUser`, `adminActionClient`).
+- **Choose the Right Client:**
+    - `actionClientUser`: Use when only authenticated user context (`userId`) is needed.
+    - `actionClient`: Use when both authenticated user context *and* a specific `emailAccountId` are needed. The `emailAccountId` must be bound when calling the action from the client.
+    - `adminActionClient`: Use for actions restricted to admin users.
+- **Input Validation:** Define input validation schemas using Zod in the corresponding `.validation.ts` file. These schemas are used by `next-safe-action` (`.schema()`) and can also be reused on the client for form validation.
+- **Context (`ctx`):** Access necessary context (like `userId`, `emailAccountId`, etc.) provided by the safe action client via the `ctx` object in the `.action()` handler.
+- **Mutations Only:** Server Actions are **strictly for mutations** (operations that change data, e.g., creating, updating, deleting). **Do NOT use Server Actions for data fetching (GET operations).**
+    - For data fetching, use dedicated [GET API Routes](mdc:.cursor/rules/get-api-route.mdc) combined with [SWR Hooks](mdc:.cursor/rules/data-fetching.mdc).
+- **Error Handling:** `next-safe-action` provides centralized error handling. Use `SafeError` for expected/handled errors within actions if needed (see `apps/web/utils/actions/safe-action.ts`).
+- **Instrumentation:** Sentry instrumentation is automatically applied via `withServerActionInstrumentation` within the safe action clients. Use the `.metadata({ name: "actionName" })` method to provide a meaningful name for monitoring.
+- **Cache Invalidation:** If an action modifies data displayed elsewhere, use `revalidatePath` or `revalidateTag` from `next/cache` within the action handler as needed.