apps/dashboard/src/components/vibe-coding/code-editor.tsx (1)

84-92: Defaulting Props to never makes variables impossible to pass

With T = never, the variables prop becomes never, which no value can satisfy. This will surface false-positive type errors in the editor. Use a permissive default.

-          type Props<T = never> = {
+          type Props<T = Record<string, unknown>> = {
             variables: T;
             project: {
               displayName: string;
             };
             user: {
               displayName: string | null;
             };
           };

apps/backend/src/app/api/latest/emails/send-email/route.tsx (1)

54-61: Expose per-user errors in API response (schema).

Augment the response schema to include an optional error string per result.

   body: yupObject({
     results: yupArray(yupObject({
       user_id: yupString().defined(),
       user_email: yupString().optional(),
+      error: yupString().optional(),
     })).defined(),
   }).defined(),

apps/dashboard/src/components/email-theme-selector.tsx (1)

10-15: Keep the null/undefined coercion; it’s intentional and correct for your tri-state mapping

The JSON encode/decode approach correctly:

• maps undefined -> "null" (via stringify) -> undefined on parse (via ?? undefined),
• maps false -> "false" -> false,
• maps string IDs -> quoted JSON string -> the original string.

This contradicts the earlier suggestion to drop the coalescing; that would change semantics and break PROJECT_DEFAULT handling.

apps/backend/prisma/migrations/20250815012830_email_drafts/migration.sql (1)

5-17: Add pragmatic indexes and an integrity CHECK; optionally add a tenancy FK if consistent with your schema policy

For typical list/filter patterns, indexes materially help. A CHECK constraint keeps themeMode/themeId coherent. Re: Tenancy FK—many of your models omit a direct FK to Tenancy for flexibility; if you want cascade guarantees, add it here for consistency across the codebase.

Append these statements after the CREATE TABLE block:

 CREATE TABLE "EmailDraft" (
@@
     CONSTRAINT "EmailDraft_pkey" PRIMARY KEY ("tenancyId","id")
 );
+
+-- Useful indexes for common queries
+CREATE INDEX "EmailDraft_tenancyId_createdAt_idx" ON "EmailDraft" ("tenancyId", "createdAt" DESC);
+CREATE INDEX "EmailDraft_tenancyId_sentAt_idx" ON "EmailDraft" ("tenancyId", "sentAt");
+CREATE INDEX "EmailDraft_tenancyId_displayName_idx" ON "EmailDraft" ("tenancyId", "displayName");
+
+-- Optional: enforce themeMode/themeId consistency
+ALTER TABLE "EmailDraft"
+ADD CONSTRAINT "EmailDraft_theme_consistency"
+CHECK (
+  ("themeMode" = 'CUSTOM' AND "themeId" IS NOT NULL)
+  OR ("themeMode" <> 'CUSTOM' AND "themeId" IS NULL)
+);
+
+-- Optional: add FK if you want referential integrity to Tenancy with cascade
+-- ALTER TABLE "EmailDraft"
+--   ADD CONSTRAINT "EmailDraft_tenancy_fkey"
+--   FOREIGN KEY ("tenancyId") REFERENCES "Tenancy"("id") ON DELETE CASCADE;

If you prefer, I can generate a follow-up migration with these statements.

apps/backend/src/app/api/latest/emails/send-email/route.tsx (1)

96-106: Fix all_users handling: query currently filters by undefined list.

When all_users is true, the current query still adds projectUserId: { in: body.user_ids }, which will result in no matches (or an error) because body.user_ids is undefined.

Apply this diff to conditionally include the projectUserId filter only when user_ids is provided:

-    const users = await prisma.projectUser.findMany({
-      where: {
-        tenancyId: auth.tenancy.id,
-        projectUserId: {
-          in: body.user_ids
-        },
-      },
-      include: {
-        contactChannels: true,
-      },
-    });
+    const users = await prisma.projectUser.findMany({
+      where: {
+        tenancyId: auth.tenancy.id,
+        ...(body.user_ids && {
+          projectUserId: { in: body.user_ids },
+        }),
+      },
+      include: {
+        contactChannels: true,
+      },
+    });

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/page-client.tsx (1)

35-35: Avoid any — define a proper EmailDraft shape.

Using any here loses type safety. Define a minimal interface that matches useEmailDrafts() and use it.

For example (adjust fields as needed):

-      {drafts.map((draft: any) => (
+      type EmailDraftListItem = { id: string, displayName: string };
+      {drafts.map((draft: EmailDraftListItem) => (

packages/template/src/lib/stack-app/apps/interfaces/admin-app.ts (1)

37-37: Unify themeId type: prefer string | null | false for consistency

Current: string | undefined | false. Elsewhere (render preview, server interface), null represents “project theme”. Recommend aligning this store property to string | null | false.

Apply this diff:

-  & AsyncStoreProperty<"emailDrafts", [], { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[], true>
+  & AsyncStoreProperty<"emailDrafts", [], { id: string, displayName: string, themeId: string | null | false, tsxSource: string, sentAt: Date | null }[], true>

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page-client.tsx (1)

24-27: Initialize editor state when the draft loads (async hook timing)

If the draft arrives after mount, currentCode/selectedThemeId remain empty. Seed state once when the draft becomes available to avoid editing a blank buffer.

Apply this diff:

   const [currentCode, setCurrentCode] = useState<string>(draft?.tsxSource ?? "");
   const [stage, setStage] = useState<"edit" | "send">("edit");
   const [selectedThemeId, setSelectedThemeId] = useState<string | undefined | false>(draft?.themeId);
+  const [didInitFromDraft, setDidInitFromDraft] = useState(false);
+
+  useEffect(() => {
+    if (!didInitFromDraft && draft) {
+      setCurrentCode(draft.tsxSource ?? "");
+      setSelectedThemeId(draft.themeId);
+      setDidInitFromDraft(true);
+    }
+  }, [draft, didInitFromDraft]);

packages/stack-shared/src/interface/admin-interface.ts (2)

155-167: Standardize updateEmailDraft theme_id type

Keep theme_id consistent with list/create.

Apply this diff:

-  async updateEmailDraft(id: string, data: { display_name?: string, theme_id?: string | null | false, tsx_source?: string, sent_at_millis?: number | null }): Promise<void> {
+  async updateEmailDraft(id: string, data: { display_name?: string, theme_id?: string | null | false, tsx_source?: string, sent_at_millis?: number | null }): Promise<void> {

---

140-153: Allow null on create to explicitly select “project theme”

Creating a draft currently can’t explicitly set project theme. Align with update/list and other email APIs by allowing null.

Apply this diff:

-  async createEmailDraft(options: { display_name?: string, theme_id?: string | false, tsx_source?: string }): Promise<{ id: string }> {
+  async createEmailDraft(options: { display_name?: string, theme_id?: string | null | false, tsx_source?: string }): Promise<{ id: string }> {

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sidebar-layout.tsx (2)

202-221: Make draft breadcrumbs resilient to nested routes (e.g., /edit, /send).

Current regex only matches the base detail path. If detail pages have subroutes, breadcrumbs won’t render. Broaden both the match and regex to include optional trailing segments.

Apply this diff:

-      const match = pathname.match(/^\/projects\/[^\/]+\/email-drafts\/([^\/]+)$/);
+      const match = pathname.match(/^\/projects\/[^\/]+\/email-drafts\/([^\/]+)(?:\/.*)?$/);
@@
-    regex: /^\/projects\/[^\/]+\/email-drafts\/[^\/]+$/,
+    regex: /^\/projects\/[^\/]+\/email-drafts\/[^\/]+(?:\/.*)?$/,

---

352-361: Provide a stable fallback for draft breadcrumb text while data loads.

When the draft isn’t found yet, the crumb renders empty. Fallback to the draftId to avoid a blank label.

Confirm that useEmailDrafts() always returns an array (not undefined). If it can be undefined, add a default (e.g., const drafts = stackAdminApp.useEmailDrafts() ?? []).

Apply this diff:

 function DraftBreadcrumbItem(props: { draftId: string }) {
   const stackAdminApp = useAdminApp();
   const drafts = stackAdminApp.useEmailDrafts();
   const draft = drafts.find((d) => d.id === props.draftId);
-  if (!draft) {
-    return null;
-  }
-  return draft.displayName;
+  return draft?.displayName ?? props.draftId;
 }

apps/dashboard/src/components/assistant-ui/thread.tsx (2)

81-81: Welcome suggestions hidden — confirm UX intent or remove dead code

You’ve disabled the welcome suggestions. If this is a permanent change, consider removing the unused component to avoid dead code and keep bundle size lean.

---

87-112: ThreadWelcomeSuggestions is now unused — delete to reduce bundle size

This component isn’t referenced anymore. Safe to remove.

-const ThreadWelcomeSuggestions: FC = () => {
-  return (
-    <div className="mt-3 flex w-full items-stretch justify-center gap-4">
-      <ThreadPrimitive.Suggestion
-        className="hover:bg-muted/80 flex max-w-sm grow basis-0 flex-col items-center justify-center rounded-lg border p-3 transition-colors ease-in"
-        prompt="Make a modern email theme with a blue color scheme"
-        method="replace"
-        autoSend
-      >
-        <span className="line-clamp-2 text-ellipsis text-sm font-semibold">
-          Make a blue theme
-        </span>
-      </ThreadPrimitive.Suggestion>
-      <ThreadPrimitive.Suggestion
-        className="hover:bg-muted/80 flex max-w-sm grow basis-0 flex-col items-center justify-center rounded-lg border p-3 transition-colors ease-in"
-        prompt="Make a modern email theme in dark mode"
-        method="replace"
-        autoSend
-      >
-        <span className="line-clamp-2 text-ellipsis text-sm font-semibold">
-          Make a dark theme
-        </span>
-      </ThreadPrimitive.Suggestion>
-    </div>
-  );
-};

apps/backend/src/app/api/latest/internal/ai-chat/[threadId]/route.tsx (1)

31-36: Schema consistency: mark auth.tenancy as defined() in POST like PATCH/GET

POST’s auth.tenancy currently omits .defined(), unlike PATCH/GET. For consistency and clearer validations, define it here too.

-    auth: yupObject({
-      type: yupString().oneOf(["admin"]).defined(),
-      tenancy: adaptSchema,
-    }),
+    auth: yupObject({
+      type: yupString().oneOf(["admin"]).defined(),
+      tenancy: adaptSchema.defined(),
+    }),

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-templates/[templateId]/page-client.tsx (1)

41-45: Simplify undefined→null conversion

Minor nit: coalesce to null more succinctly without changing behavior.

-      await stackAdminApp.updateEmailTemplate(props.templateId, currentCode, selectedThemeId === undefined ? null : selectedThemeId);
+      await stackAdminApp.updateEmailTemplate(props.templateId, currentCode, selectedThemeId ?? null);

apps/backend/prisma/schema.prisma (2)

672-687: Solid model addition; consider adding tenant-scoped indexes for list/sort and query patterns

EmailDraft looks consistent with your multi-tenant composite PK pattern. To keep list pages and queries snappy, add a couple of pragmatic indexes commonly used in dashboards (createdAt desc, sentAt filter) and optionally by displayName.

Apply this diff to add useful indexes:

 model EmailDraft {
   tenancyId String @db.Uuid

   id String @default(uuid()) @db.Uuid

   displayName String
   themeMode   DraftThemeMode @default(PROJECT_DEFAULT)
   themeId     String?
   tsxSource   String
   sentAt      DateTime?

   createdAt DateTime @default(now())
   updatedAt DateTime @updatedAt

+  @@index([tenancyId, createdAt(sort: Desc)], name: "EmailDraft_createdAt_desc")
+  @@index([tenancyId, sentAt], name: "EmailDraft_sentAt")
+  @@index([tenancyId, displayName], name: "EmailDraft_displayName")
   @@id([tenancyId, id])
 }

---

672-687: Optional: Enforce themeMode/themeId consistency at the DB level (CHECK constraint via SQL migration)

App logic maps PROJECT_DEFAULT -> themeId NULL/undefined, NONE -> themeId NULL/false, CUSTOM -> themeId non-null. To prevent bad states, add a CHECK constraint in the migration (Prisma doesn’t support CHECK directly in schema). See the migration file comment for the exact SQL.

I can generate a follow-up migration with the CHECK constraint if you’d like.

apps/dashboard/src/components/email-theme-selector.tsx (1)

21-37: Minor optional: avoid JSON for value encoding to reduce cognitive overhead

Current JSON sentinel encoding is safe (quoted IDs won’t collide with "null"/"false"). If you want a simpler mental model, consider explicit tags:

• "none" => No theme
• "project" => Project theme
• "id:" => Custom theme

Apply this refactor if desired:

-function themeIdToSelectString(themeId: string | undefined | false): string {
-  return JSON.stringify(themeId ?? null);
-}
-function selectStringToThemeId(value: string): string | undefined | false {
-  return JSON.parse(value) ?? undefined;
-}
+function themeIdToSelectString(themeId: string | undefined | false): string {
+  if (themeId === undefined) return "project";
+  if (themeId === false) return "none";
+  return `id:${themeId}`;
+}
+function selectStringToThemeId(value: string): string | undefined | false {
+  if (value === "project") return undefined;
+  if (value === "none") return false;
+  if (value.startsWith("id:")) return value.slice(3);
+  return undefined;
+}
@@
-        <SelectItem value={"false"}>No theme</SelectItem>
-        <SelectItem value={"null"}>Project theme</SelectItem>
+        <SelectItem value="none">No theme</SelectItem>
+        <SelectItem value="project">Project theme</SelectItem>
@@
-          <SelectItem key={theme.id} value={JSON.stringify(theme.id)}>
+          <SelectItem key={theme.id} value={`id:${theme.id}`}>
             {theme.displayName}
           </SelectItem>

apps/backend/src/lib/ai-chat/email-draft-adapter.ts (1)

10-20: Nit: unused context parameter

context is not used. Either prefix with underscore to signal intent or leverage it (e.g., tenancy/thread scoping in a future execute handler).

Apply this minimal tidy:

-export const emailDraftAdapter = (context: ChatAdapterContext) => ({
+export const emailDraftAdapter = (_context: ChatAdapterContext) => ({

apps/backend/src/lib/email-drafts.tsx (1)

25-33: Optional guard for inconsistent CUSTOM-without-themeId cases

If the DB ever contains CUSTOM with themeId null, you currently coerce to undefined. Consider asserting/logging to detect data issues early.

Apply this defensive (non-breaking) tweak:

 export const themeModeToTemplateThemeId = (themeMode: DraftThemeMode, themeId: string | null): string | false | undefined => {
   if (themeMode === DraftThemeMode.PROJECT_DEFAULT) {
     return undefined;
   }
   if (themeMode === DraftThemeMode.NONE) {
     return false;
   }
-  return themeId === null ? undefined : themeId;
+  if (themeId === null) {
+    // CUSTOM without themeId should not happen; surface as default and log in dev
+    if (process.env.NODE_ENV !== "production") {
+      // eslint-disable-next-line no-console
+      console.warn("EmailDraft CUSTOM themeMode without themeId; defaulting to undefined");
+    }
+    return undefined;
+  }
+  return themeId;
 };

packages/stack-shared/src/interface/server-interface.ts (1)

799-809: Enforce recipient XOR at the client boundary (and consider typing it).

Allowing both userIds and allUsers (or neither) to flow to the server shifts an avoidable error to runtime. Add a quick XOR guard (and optionally encode via overloads) to fail fast.

Example minimal runtime guard:

   async sendEmail(options: {
     userIds?: string[],
     allUsers?: true,
     themeId?: string | null | false,
     html?: string,
     subject?: string,
     notificationCategoryName?: string,
     templateId?: string,
     variables?: Record<string, any>,
     draftId?: string,
   }): Promise<Result<void, KnownErrors["RequiresCustomEmailServer"] | KnownErrors["SchemaError"] | KnownErrors["UserIdDoesNotExist"]>> {
+    if (!!options.userIds === !!options.allUsers) {
+      return Result.error(new KnownErrors.SchemaError("Exactly one of userIds or allUsers must be provided"));
+    }

If you want compile-time guarantees, we can switch to overloads/XOR types to represent:

• one of { html } | { templateId (+variables?) } | { draftId }
• and exactly one of { userIds } | { allUsers: true }

apps/dashboard/src/components/vibe-coding/draft-tool-components.tsx (2)

10-25: Avoid re-creating ToolUI on every render (wrap in useMemo).

makeAssistantToolUI returns a component; creating it inside the render path can cause unnecessary re-instantiation and lost internal state. Memoize it based on setCurrentCode.

Apply this diff within the selected lines:

-  const ToolUI = makeAssistantToolUI<
-    { content: string },
-    "success"
-  >({
-    toolName: "createEmailTemplate",
-    render: ({ args }) => {
-      return (
-        <Card className="flex items-center gap-2 p-4 justify-between">
-          <span className="text-sm">Created draft</span>
-          <Button variant="ghost" size="icon" onClick={() => setCurrentCode(args.content)}>
-            <Undo2 className="size-4" />
-          </Button>
-        </Card>
-      );
-    },
-  });
+  const ToolUI = useMemo(() => makeAssistantToolUI<
+    { content: string },
+    "success"
+  >({
+    toolName: "createEmailTemplate",
+    render: ({ args }) => (
+      <Card className="flex items-center gap-2 p-4 justify-between">
+        <span className="text-sm">Created draft</span>
+        <Button variant="ghost" size="icon" aria-label="Apply draft to editor" title="Apply draft to editor" onClick={() => setCurrentCode(args.content)}>
+          <Undo2 className="size-4" />
+        </Button>
+      </Card>
+    ),
+  }), [setCurrentCode]);

Additionally add the import (outside the selected range):

import { useMemo } from "react";

---

19-21: Add accessible label to the icon-only button.

Icon-only buttons should have an aria-label/title for screen readers. Also, “Undo” might be semantically confusing for “apply draft”; label clarifies intent.

Apply this diff:

-          <Button variant="ghost" size="icon" onClick={() => setCurrentCode(args.content)}>
+          <Button
+            variant="ghost"
+            size="icon"
+            aria-label="Apply draft to editor"
+            title="Apply draft to editor"
+            onClick={() => setCurrentCode(args.content)}
+          >
             <Undo2 className="size-4" />
           </Button>

apps/e2e/tests/js/email.test.ts (1)

180-191: Reduce brittleness of schema error assertion (avoid giant inline snapshot).

The union-validator’s error formatting can change; asserting the entire deindented block is brittle. Prefer targeted contains on stable substrings.

Apply this diff to replace the inline snapshot with focused assertions:

-    expect(result.error.message).toMatchInlineSnapshot(`
-      deindent\`
-        Request validation failed on POST /api/v1/emails/send-email:
-          - body is not matched by any of the provided schemas:
-            Schema 0:
-              body.html must be defined
-            Schema 1:
-              body.template_id must be defined
-            Schema 2:
-              body.draft_id must be defined
-      \`
-    `);
+    expect(result.error.message).toContain("Request validation failed on POST /api/v1/emails/send-email:");
+    expect(result.error.message).toContain("body is not matched by any of the provided schemas:");
+    expect(result.error.message).toContain("body.html must be defined");
+    expect(result.error.message).toContain("body.template_id must be defined");
+    expect(result.error.message).toContain("body.draft_id must be defined");

If you’d like, I can add a new test for the draftId happy-path as part of this suite.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page.tsx (1)

7-10: Fix Page props typing; params is not a Promise and async/await is unnecessary.

Next.js App Router provides params synchronously. Cleaning this up avoids confusion and matches framework conventions.

Apply this diff:

-export default async function Page(props: { params: Promise<{ draftId: string }> }) {
-  const params = await props.params;
-  return <PageClient draftId={params.draftId} />;
-}
+export default function Page({ params }: { params: { draftId: string } }) {
+  return <PageClient draftId={params.draftId} />;
+}

apps/e2e/tests/backend/endpoints/api/v1/render-email.test.ts (1)

69-105: Prefer targeted assertions over full inline snapshot for schema errors.

Inline snapshots of long, structured schema errors are fragile. Assert key fields and a couple of substrings to keep tests resilient to formatting/order changes.

Apply this diff within the selected lines:

-      "body": {
-        "code": "SCHEMA_ERROR",
-        "details": {
-          "message": deindent\`
-            Request validation failed on POST /api/v1/emails/render-email:
-              - body is not matched by any of the provided schemas:
-                Schema 0:
-                  body.template_id must be defined
-                  body contains unknown properties: theme_tsx_source, template_tsx_source
-                Schema 1:
-                  body.template_id must be defined
-                  body contains unknown properties: theme_id, template_tsx_source
-                Schema 2:
-                  body contains unknown properties: theme_tsx_source
-                Schema 3:
-                  body contains unknown properties: theme_id
-          \`,
-        },
-        "error": deindent\`
-          Request validation failed on POST /api/v1/emails/render-email:
-            - body is not matched by any of the provided schemas:
-              Schema 0:
-                body.template_id must be defined
-                body contains unknown properties: theme_tsx_source, template_tsx_source
-              Schema 1:
-                body.template_id must be defined
-                body contains unknown properties: theme_id, template_tsx_source
-              Schema 2:
-                body contains unknown properties: theme_tsx_source
-              Schema 3:
-                body contains unknown properties: theme_id
-        \`,
-      },
-      "headers": Headers {
-        "x-stack-known-error": "SCHEMA_ERROR",
-        <some fields may have been hidden>,
-      },
+      "body": expect.objectContaining({
+        code: "SCHEMA_ERROR",
+        details: expect.objectContaining({
+          message: expect.stringContaining("body is not matched by any of the provided schemas:")
+        }),
+      }),
+      "headers": expect.anything(),

If you prefer not to change snapshot style, consider at least snapshotting only response.body and headers key presence separately.

packages/stack-shared/src/utils/types.tsx (1)

69-74: Consider documenting and adding compile-time assertions for XOR.

A brief JSDoc and a couple of typeAssertIs examples will prevent regressions and clarify intended usage (especially around disjoint keys).

Example assertions you could add nearby:

// XOR over two shapes
type A = { html: string };
type B = { templateId: string; variables?: Record<string, any> };
typeAssertIs<XOR<[A, B]>, (A & { [K in keyof B]?: never }) | (B & { [K in keyof A]?: never })>()();

// XOR over three shapes
type C = { draftId: string };
typeAssertIs<XOR<[A, B, C]>, A | B | C>()();

And a short doc comment:

/**
 * Exclusive-or over a tuple of object types.
 * Ensures exactly one shape is present by disallowing the keys of the others (via `?: never`).
 * Note: Works best when shapes have disjoint keys.
 */

apps/dashboard/src/components/email-preview.tsx (1)

47-51: Nit: optional already implies undefined — simplify type.

themeId is an optional prop, so explicitly including undefined in the union is redundant. Recommend simplifying for readability.

Apply this diff:

-  themeId?: string | undefined | false,
+  themeId?: string | false,

apps/e2e/tests/backend/endpoints/api/v1/send-email.test.ts (2)

437-531: Solid coverage for all_users path; consider reducing snapshot brittleness.

The new tests cover mutual exclusivity and broadcast behavior well. However, long deindent() inline snapshots can be fragile if error aggregation text changes. Prefer partial structural assertions for stability.

For example, in the “both user_ids and all_users” test:

-    expect(response).toMatchInlineSnapshot(`
-      NiceResponse {
-        "status": 400,
-        "body": {
-          "code": "SCHEMA_ERROR",
-          "details": { "message": "Exactly one of user_ids or all_users must be provided" },
-          "error": "Exactly one of user_ids or all_users must be provided",
-        },
-        "headers": Headers {
-          "x-stack-known-error": "SCHEMA_ERROR",
-          <some fields may have been hidden>,
-        },
-      }
-    `);
+    expect(response.status).toBe(400);
+    expect(response.body).toMatchObject({
+      code: "SCHEMA_ERROR",
+      details: { message: "Exactly one of user_ids or all_users must be provided" },
+    });

---

533-633: Template/draft mode validation snapshots are precise; consider adding a draft-based happy-path test.

You already validate invalid cases and html/template modes thoroughly. Adding one e2e for draft_id content mode would close the loop on the new “third” input schema.

If helpful, I can draft a test that:

• creates a draft via internal API (admin),
• updates its tsx_source,
• sends via /api/v1/emails/send-email with { all_users: true, draft_id, subject },
• asserts results and mailbox contents.

packages/template/src/lib/stack-app/email/index.ts (2)

26-29: Tighten variables typing to avoid any leaks

Using unknown instead of any improves type safety without reducing flexibility for callers.

Apply this diff:

       {
         templateId: string,
-        variables?: Record<string, any>,
+        variables?: Record<string, unknown>,
       },

---

12-16: Standardize themeId union type across layers

There are multiple definitions of themeId in the codebase—some allow undefined, some null, and some omit either. This inconsistency can lead to subtle bugs when passing values between UI, app implementations, and public/server interfaces. Please align all occurrences to a single union (e.g. string | null | false) and map undefined→null at the UI boundary.

Key locations with divergent themeId types:

• packages/stack-shared/src/interface/server-interface.ts:
  • themeId?: string | null | false
• packages/stack-shared/src/interface/admin-interface.ts:
  • renderEmailPreview(… options: { themeId?: string | null | false, … })
• packages/template/src/lib/stack-app/email/index.ts:
  • type SendEmailOptionsBase { themeId?: string | null | false; … }
• packages/template/src/lib/stack-app/apps/interfaces/admin-app.ts:
  • createEmailDraft(options: { … themeId?: string | undefined | false, … })
  • updateEmailDraft(…, data: { … themeId?: string | undefined | false, … })
  • AsyncStoreProperty<"emailDrafts", … { themeId: string | undefined | false, … }[]>
• packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts:
  • async createEmailDraft(options: { … themeId?: string | false, … })
  • async updateEmailDraft(…, data: { … themeId?: string | undefined | false, … })
• apps/dashboard/src/components/email-preview.tsx:
  • themeId?: string | undefined | false
• packages/template/src/lib/stack-app/apps/interfaces/admin-app.ts:
  • AsyncStoreProperty<"emailPreview", … { themeId?: string | null | false, … }>
• packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts:
  • getEmailPreview(… options: { themeId?: string | null | false, … })
  • useEmailPreview({ themeId?: string | null | false, … })

Suggested approach:

1. Choose string | null | false as the canonical type.
2. Update all UI and admin-app interfaces/implementations to use themeId?: string | null | false.
3. Where callers may pass undefined, convert to null before invoking the shared/public APIs.

packages/template/src/lib/stack-app/apps/interfaces/admin-app.ts (1)

78-79: Align draft API surface to a single themeId representation

Both methods use string | undefined | false. Recommend switching to string | null | false to align with backend/admin interfaces and EmailPreview, and avoid undefined inside unions for optional props.

Apply this diff:

-    createEmailDraft(options: { displayName?: string, themeId?: string | undefined | false, tsxSource?: string }): Promise<{ id: string }>,
-    updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | undefined | false, tsxSource?: string }): Promise<void>,
+    createEmailDraft(options: { displayName?: string, themeId?: string | null | false, tsxSource?: string }): Promise<{ id: string }>,
+    updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | null | false, tsxSource?: string }): Promise<void>,

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page-client.tsx (3)

18-21: Drop local EmailDraft type and cast; rely on inferred hook return type

Avoid shape duplication that can drift from the source. The hook already carries the precise type, so you can remove the alias and cast.

Apply this diff:

-  const { toast } = useToast();
-
-  type EmailDraft = { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null };
-  const drafts = stackAdminApp.useEmailDrafts() as EmailDraft[];
+  // Prefer the hook's inferred type to avoid duplication
+  const drafts = stackAdminApp.useEmailDrafts();

---

18-19: Use a single toast API consistently

Both toast import and useToast() are present; you only need one. Since toast is imported and used elsewhere, drop the hook to reduce duplication.

Apply this diff:

-  const { toast } = useToast();

---

70-71: Guard “Next” button when nothing changed

Prevents a no-op PATCH and stage transition when code/theme are unchanged.

Apply this diff:

-                  <Button onClick={handleNext}>Next</Button>
+                  <Button
+                    disabled={!!draft && currentCode === (draft.tsxSource ?? "") && selectedThemeId === draft.themeId}
+                    onClick={handleNext}
+                  >
+                    Next
+                  </Button>

packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts (2)

304-315: Return type alignment for draft themeId

This exposes themeId: string | undefined | false. Consider returning string | null | false to align with server/public email types and reduce conversions at call sites.

Apply this diff:

-  useEmailDrafts(): { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[] {
+  useEmailDrafts(): { id: string, displayName: string, themeId: string | null | false, tsxSource: string, sentAt: Date | null }[] {

Note: if you adopt this, also adjust draft.theme_id mapping to coerce undefined to null where appropriate.

---

335-344: List API: mirror useEmailDrafts themeId union

Same rationale as above; align to a single representation and let UI map to its local preference.

Apply this diff:

-  async listEmailDrafts(): Promise<{ id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[]> {
+  async listEmailDrafts(): Promise<{ id: string, displayName: string, themeId: string | null | false, tsxSource: string, sentAt: Date | null }[]> {

apps/backend/src/app/api/latest/emails/render-email/route.tsx (4)

47-49: Avoid building Maps for config lookups; use direct object access

Constructing Maps here is unnecessary and adds overhead. The config objects are already key-addressable. This also aligns the membership check with how getEmailThemeForTemplate resolves themes internally.

Apply this diff:

-    const templateList = new Map(Object.entries(tenancy.config.emails.templates));
-    const themeList = new Map(Object.entries(tenancy.config.emails.themes));
+    const templateList = tenancy.config.emails.templates;
+    const themeList = tenancy.config.emails.themes;

-      if (typeof body.theme_id === "string" && !themeList.has(body.theme_id)) {
+      if (typeof body.theme_id === "string" && !Object.prototype.hasOwnProperty.call(themeList, body.theme_id)) {
         throw new StatusError(400, "No theme found with given id");
       }
       themeSource = getEmailThemeForTemplate(tenancy, body.theme_id);
...
-      const template = templateList.get(body.template_id);
+      const template = templateList[body.template_id];

Also applies to: 53-56, 63-63

---

53-56: Use a consistent error type for invalid IDs (SchemaError vs raw 400)

For consistency with the other schema-related failure (Line 69) and downstream error handling, prefer throwing KnownErrors.SchemaError instead of a generic StatusError(400, ...) when the provided IDs don’t resolve.

Apply this diff:

-      if (typeof body.theme_id === "string" && !Object.prototype.hasOwnProperty.call(themeList, body.theme_id)) {
-        throw new StatusError(400, "No theme found with given id");
+      if (typeof body.theme_id === "string" && !Object.prototype.hasOwnProperty.call(themeList, body.theme_id)) {
+        throw new KnownErrors.SchemaError("No theme found with given id");
       }
...
-      if (!template) {
-        throw new StatusError(400, "No template found with given id");
+      if (!template) {
+        throw new KnownErrors.SchemaError("No template found with given id");
       }

Also applies to: 64-66

---

38-45: Optionally include plain-text in the response

renderEmailWithTemplate returns text, but the API omits it. Including it helps clients with plain-text fallbacks and parity with renderer output.

Apply this diff:

   response: yupObject({
     statusCode: yupNumber().oneOf([200]).defined(),
     bodyType: yupString().oneOf(["json"]).defined(),
     body: yupObject({
       html: yupString().defined(),
+      text: yupString(),
       subject: yupString(),
       notification_category: yupString(),
     }).defined(),
   }),
...
     return {
       statusCode: 200,
       bodyType: "json",
       body: {
         html: result.data.html,
+        text: result.data.text,
         subject: result.data.subject,
         notification_category: result.data.notificationCategory,
       },
     };

Also applies to: 86-91

---

9-12: Tighten metadata wording

The route renders an email (template + theme), not just a theme. Minor wording tweak improves clarity in generated docs.

Apply this diff:

-    summary: "Render email theme",
-    description: "Renders HTML content using the specified email theme",
+    summary: "Render email (template + theme)",
+    description: "Renders HTML using a template and theme (or direct TSX sources) for preview",

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: CR
PR: stack-auth/stack-auth#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T22:25:51.260Z
Learning: Applies to apps/backend/prisma/schema.prisma : Database models use Prisma

apps/backend/src/lib/ai-chat/email-draft-adapter.ts (1)

33-49: Critical: Unescaped backticks and ${} in template literal will break at runtime

The example block is inside a JS template string. The raw ``` fences and ${user.displayName} will prematurely terminate/interpolate the outer template, causing syntax errors or ReferenceError at module load. Escape the backticks or remove the fences, and escape ${.

This also addresses the prior bot comment about escaping in the Subject line.

Apply one of the following fixes.

Option A — Remove code fences and escape the ${} in the example:

-Here is an example of a valid email draft:
-```tsx
+Here is an example of a valid email draft:
 import { Container } from "@react-email/components";
 import { Subject, NotificationCategory, Props } from "@stackframe/emails";

 export function EmailTemplate({ user, project }: Props) {
   return (
     <Container>
-      <Subject value={`Hello ${user.displayName}!`} />
+      <Subject value={\`Hello \\\${user.displayName}!\`} />
       <NotificationCategory value="Transactional" />
       <div className="font-bold">Hi {user.displayName}!</div>
       <br />
     </Container>
   );
 }
-```

Option B — Keep fences by escaping backticks and ${}:

-```tsx
+\`\`\`tsx
@@
-      <Subject value={`Hello ${user.displayName}!`} />
+      <Subject value={\`Hello \\\${user.displayName}!\`} />
@@
-```
+\`\`\`

apps/backend/prisma/migrations/20250815012830_email_drafts/migration.sql (1)

5-17: Add missing foreign key constraint to Tenancy (and enforce themeMode/themeId consistency).

There’s no FK from EmailDraft.tenancyId to Tenancy(id). This risks orphaned rows and inconsistent cleanup on tenancy deletion. Prior feedback already flagged this.

Prefer adding explicit constraints after the CREATE TABLE to keep the migration minimally invasive:

 CREATE TABLE "EmailDraft" (
   "tenancyId" UUID NOT NULL,
   "id" UUID NOT NULL,
   "displayName" TEXT NOT NULL,
   "themeMode" "DraftThemeMode" NOT NULL DEFAULT 'PROJECT_DEFAULT',
   "themeId" TEXT,
   "tsxSource" TEXT NOT NULL,
   "sentAt" TIMESTAMP(3),
   "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
   "updatedAt" TIMESTAMP(3) NOT NULL,
 
   CONSTRAINT "EmailDraft_pkey" PRIMARY KEY ("tenancyId","id")
 );
+
+-- Enforce tenancy referential integrity
+ALTER TABLE "EmailDraft"
+  ADD CONSTRAINT "EmailDraft_tenancyId_fkey"
+  FOREIGN KEY ("tenancyId") REFERENCES "Tenancy"("id")
+  ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- Enforce that themeId presence matches themeMode semantics
+ALTER TABLE "EmailDraft"
+  ADD CONSTRAINT "EmailDraft_theme_consistency_ck" CHECK (
+    ("themeMode" = 'CUSTOM' AND "themeId" IS NOT NULL)
+    OR ("themeMode" IN ('PROJECT_DEFAULT', 'NONE') AND "themeId" IS NULL)
+  );

Optional follow-up (if your schema supports it): add an FK to EmailTheme with the appropriate composite key, e.g., (tenancyId, themeId) → EmailTheme(tenancyId, id). If themes are cross-tenant or denormalized, skip this.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/page-client.tsx (1)

35-35: Avoid any for draft items; add a minimal typed shape.

This has been flagged before. Replace the any and type the drafts list.

-      {drafts.map((draft: any) => (
+      {drafts.map((draft) => (

Add near the drafts declaration to preserve type safety:

type EmailDraftListItem = { id: string; displayName: string };
const drafts = stackAdminApp.useEmailDrafts() as EmailDraftListItem[];

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page-client.tsx (1)

24-27: Initialize local state when draft finishes loading to prevent accidental overwrite

If draft loads after mount, currentCode stays "", selectedThemeId stays undefined. Pressing “Next” would overwrite the server draft with empty content. Hydrate state once when the draft becomes available.

Apply this diff to hydrate safely:

   const [currentCode, setCurrentCode] = useState<string>(draft?.tsxSource ?? "");
   const [stage, setStage] = useState<"edit" | "send">("edit");
   const [selectedThemeId, setSelectedThemeId] = useState<string | undefined | false>(draft?.themeId);
 
+  // Hydrate state when draft loads (avoid clobbering user edits)
+  useEffect(() => {
+    if (!draft || stage !== "edit") return;
+    // Only hydrate when the editor is blank and theme unchosen,
+    // which indicates initial load rather than user edits.
+    if (currentCode === "" && selectedThemeId === undefined) {
+      setCurrentCode(draft.tsxSource);
+      setSelectedThemeId(draft.themeId);
+    }
+  }, [draft, stage]); // intentionally exclude currentCode/selectedThemeId

apps/backend/src/app/api/latest/emails/send-email/route.tsx (1)

96-106: Fix: all_users=true breaks Prisma query (in: undefined). Add conditional filter.

When all_users is true, body.user_ids is undefined and Prisma will choke on { in: undefined }. Guard the filter.

Apply this diff:

-    const users = await prisma.projectUser.findMany({
-      where: {
-        tenancyId: auth.tenancy.id,
-        projectUserId: {
-          in: body.user_ids
-        },
-      },
-      include: {
-        contactChannels: true,
-      },
-    });
+    const users = await prisma.projectUser.findMany({
+      where: {
+        tenancyId: auth.tenancy.id,
+        ...(body.user_ids && {
+          projectUserId: {
+            in: body.user_ids,
+          },
+        }),
+      },
+      include: {
+        contactChannels: true,
+      },
+    });

apps/dashboard/src/components/assistant-ui/thread.tsx (1)

81-81: Avoid commented-out JSX; conditionally render to keep symbol referenced and satisfy linters

Commenting out the JSX leaves ThreadWelcomeSuggestions unused and likely triggers no-unused-vars. Prefer a conditional render so the symbol remains referenced and can be toggled easily.

Apply this diff:

-        {/* <ThreadWelcomeSuggestions /> */}
+        {false && <ThreadWelcomeSuggestions />}

apps/dashboard/src/components/email-preview.tsx (3)

47-51: Simplify optional prop type: remove redundant undefined from union

Since themeId is already optional, including undefined in the union is redundant. This simplifies the type without changing runtime behavior.

-  themeId?: string | undefined | false,
+  themeId?: string | false,

---

70-79: Align prop variant with optional semantics to avoid “present but undefined” ambiguity

In the “themeId” variant, you’ve made themeId required but allowed undefined in the union. That allows cases where the key is present with value undefined, which can accidentally exclude the alternative variant that expects themeId to be absent. If that distinction isn’t intentional, prefer making it optional here too.

-  | ({
-    themeId: string | undefined | false,
-    themeTsxSource?: undefined,
-  } | {
+  | ({
+    themeId?: string | false,
+    themeTsxSource?: undefined,
+  } | {
     themeId?: undefined,
     themeTsxSource: string,
   })

If you do need to distinguish presence vs. absence, consider documenting that in a comment to avoid confusion for future contributors.

---

70-89: Consider XOR to enforce exactly-one-of for theme/template sources

You already added a generic XOR utility in shared types. Using it here would clearly enforce the “exactly one” constraint for theme and template sources, reducing edge cases around presence vs. undefined.

For example:

import type { XOR } from "@stackframe/stack-shared/dist/utils/types";

type ThemeSource = XOR<[
  { themeId: string | false },
  { themeTsxSource: string }
]>;

type TemplateSource = XOR<[
  { templateId: string },
  { templateTsxSource: string }
]>;

type EmailPreviewProps = ThemeSource & TemplateSource & {
  disableResizing?: boolean;
};

apps/dashboard/src/components/vibe-coding/draft-tool-components.tsx (2)

19-21: Add accessible label/tooltip to icon-only button

Icon-only buttons should have an accessible name. Add aria-label (and optionally title) to improve a11y.

-          <Button variant="ghost" size="icon" onClick={() => setCurrentCode(args.content)}>
+          <Button
+            variant="ghost"
+            size="icon"
+            aria-label="Insert generated draft into editor"
+            title="Insert generated draft into editor"
+            onClick={() => setCurrentCode(args.content)}
+          >
             <Undo2 className="size-4" />
           </Button>

---

17-22: Icon choice may be confusing for “apply/insert” action

“Undo” glyph suggests reverting a prior change; here it applies the generated draft. Consider a more semantically aligned icon (e.g., Check, Replace, ClipboardCheck) to reduce ambiguity. Not blocking.

packages/stack-shared/src/utils/types.tsx (1)

69-74: XOR utility looks good; consider documenting constraints and adding compile-time examples

The recursive XOR is solid. Two small improvements:

• Document that it’s intended for object-like members (key-based exclusion) to avoid surprising results with primitives.
• Add type-level assertions (like others in this file) to lock behavior.

-export type XOR<T extends readonly any[]> = T extends readonly [infer A, infer B, ...infer Rest]
+/**
+ * Exclusive-or across a tuple of object-like types.
+ * For two elements A and B, yields:
+ *   (A with keys of B forbidden) | (B with keys of A forbidden)
+ * Recursively folds for >2 elements.
+ * Note: Intended for object-like members; behavior with primitives may be unintuitive.
+ */
+export type XOR<T extends readonly any[]> = T extends readonly [infer A, infer B, ...infer Rest]
   ? Rest extends []
   ? (A & { [K in keyof B]?: never }) | (B & { [K in keyof A]?: never })
   : XOR<[(A & { [K in keyof B]?: never }) | (B & { [K in keyof A]?: never }), ...Rest]>
   : T[0];

Additionally (outside this hunk), consider adding examples alongside existing assertions:

// Place near other typeAssert* calls:
typeAssertIs<XOR<[ { a: number }, { b: string } ]>, ({ a: number; b?: never } | { b: string; a?: never })>()();
typeAssertIs<XOR<[ { a: number }, { b: string }, { c: boolean } ]>, (
  | { a: number; b?: never; c?: never }
  | { b: string; a?: never; c?: never }
  | { c: boolean; a?: never; b?: never }
)>()();

apps/backend/prisma/schema.prisma (2)

678-681: Enforce invariants between themeMode and themeId

To prevent invalid states:

• When themeMode = CUSTOM, themeId should be non-null.
• When themeMode ∈ {PROJECT_DEFAULT, NONE}, themeId should be null.

Prisma can’t express conditional constraints directly; consider:

• Adding an app-level validation when creating/updating drafts, and/or
• A DB CHECK constraint in the SQL migration to enforce this invariant.

---

683-687: Add indexes to support common query patterns (list/sort/filter)

Drafts are often listed by recency or filtered by send status. Add tenancy-scoped indexes to keep these queries fast as data grows.

Proposed Prisma additions:

 model EmailDraft {
   tenancyId String @db.Uuid

   id String @default(uuid()) @db.Uuid

   displayName String
   themeMode   DraftThemeMode @default(PROJECT_DEFAULT)
   themeId     String?
   tsxSource   String
   sentAt      DateTime?

   createdAt DateTime @default(now())
   updatedAt DateTime @updatedAt

   @@id([tenancyId, id])
+  @@index([tenancyId, createdAt(sort: Desc)])
+  @@index([tenancyId, updatedAt(sort: Desc)])
+  @@index([tenancyId, sentAt(sort: Desc)])
 }

apps/backend/src/lib/ai-chat/email-draft-adapter.ts (2)

13-19: Tool naming: consider createEmailDraft (alias createEmailTemplate for BC)

For clarity and discoverability in the “email-draft” context, prefer a tool named createEmailDraft (keep createEmailTemplate as an alias to avoid breaking clients).

Proposed change:

   tools: {
-    createEmailTemplate: tool({
+    createEmailDraft: tool({
       description: CREATE_EMAIL_DRAFT_TOOL_DESCRIPTION(),
       parameters: z.object({
         content: z.string().describe("A react component that renders the email template"),
       }),
     }),
+    // Optional alias for backwards-compatibility:
+    createEmailTemplate: tool({
+      description: CREATE_EMAIL_DRAFT_TOOL_DESCRIPTION(),
+      parameters: z.object({
+        content: z.string().describe("A react component that renders the email template"),
+      }),
+    }),
   },

---

16-17: Nit: wording “template” → “draft” in parameter description

This tool is for drafts; align wording to reduce confusion.

-        content: z.string().describe("A react component that renders the email template"),
+        content: z.string().describe("A React component that renders the email draft"),

apps/backend/src/lib/email-rendering.tsx (1)

123-128: Preserve underlying error details from Freestyle for easier debugging

Catching and mapping to a generic message hides useful context. Return the original message when available; also align the cast with optional subject/notificationCategory.

-  try {
-    const output = await freestyle.executeScript(result.data, { nodeModules });
-    return Result.ok(output.result as { html: string, text: string, subject: string, notificationCategory: string });
-  } catch (error) {
-    return Result.error("Unable to render email");
-  }
+  try {
+    const output = await freestyle.executeScript(result.data, { nodeModules });
+    return Result.ok(output.result as { html: string; text: string; subject?: string; notificationCategory?: string });
+  } catch (error) {
+    const message = (error && (error as any).message) || (typeof error === "string" ? error : null);
+    return Result.error(message ?? "Unable to render email");
+  }

apps/e2e/tests/backend/endpoints/api/v1/render-email.test.ts (1)

69-105: Schema-error expectation looks correct; consider asserting minimally to reduce snapshot brittleness

The new SCHEMA_ERROR shape and x-stack-known-error header are good and align with the union validation. Inline snapshots of long, deindented messages tend to be brittle across minor wording/ordering changes. Prefer asserting the status, header, and code, plus a couple of stable substrings.

Proposed change:

-  expect(response).toMatchInlineSnapshot(`
-    NiceResponse {
-      "status": 400,
-      "body": {
-        "code": "SCHEMA_ERROR",
-        "details": {
-          "message": deindent\`
-            Request validation failed on POST /api/v1/emails/render-email:
-              - body is not matched by any of the provided schemas:
-                Schema 0:
-                  body.template_id must be defined
-                  body contains unknown properties: theme_tsx_source, template_tsx_source
-                Schema 1:
-                  body.template_id must be defined
-                  body contains unknown properties: theme_id, template_tsx_source
-                Schema 2:
-                  body contains unknown properties: theme_tsx_source
-                Schema 3:
-                  body contains unknown properties: theme_id
-          \`,
-        },
-        "error": deindent\`
-          Request validation failed on POST /api/v1/emails/render-email:
-            - body is not matched by any of the provided schemas:
-              Schema 0:
-                body.template_id must be defined
-                body contains unknown properties: theme_tsx_source, template_tsx_source
-              Schema 1:
-                body.template_id must be defined
-                body contains unknown properties: theme_id, template_tsx_source
-              Schema 2:
-                body contains unknown properties: theme_tsx_source
-              Schema 3:
-                body contains unknown properties: theme_id
-        \`,
-      },
-      "headers": Headers {
-        "x-stack-known-error": "SCHEMA_ERROR",
-        <some fields may have been hidden>,
-      },
-    }
-  `);
+  expect(response.status).toBe(400);
+  expect(response.headers.get("x-stack-known-error")).toBe("SCHEMA_ERROR");
+  expect(response.body).toMatchObject({ code: "SCHEMA_ERROR" });
+  // Keep just a stable substring to avoid brittleness:
+  expect(
+    typeof response.body?.details?.message === "string" ? response.body.details.message : ""
+  ).toContain("body is not matched by any of the provided schemas");

apps/backend/src/app/api/latest/internal/ai-chat/[threadId]/route.tsx (2)

32-36: Make tenancy required for POST to match PATCH/GET and avoid accidental undefined tenancy

PATCH and GET use adaptSchema.defined() for auth.tenancy, while POST currently allows it to be undefined. For consistency and to prevent accidental missing tenancy in the OpenAI flow, mark it as defined here too.

-    auth: yupObject({
-      type: yupString().oneOf(["admin"]).defined(),
-      tenancy: adaptSchema,
-    }),
+    auth: yupObject({
+      type: yupString().oneOf(["admin"]).defined(),
+      tenancy: adaptSchema.defined(),
+    }),

---

63-81: Optionally include actual tool call results or omit the field to avoid misleading “success”

You currently set result: "success" on every returned tool-call block. If consumers rely on this field, a literal "success" can be misleading. Consider either:

• Propagating the actual tool result (if available in result.steps), or
• Omitting result if there is no useful payload to return.

If tool results are available in your generateText step data, map them through; otherwise, consider:

-        contentBlocks.push({
-          type: "tool-call",
-          toolName: toolCall.toolName,
-          toolCallId: toolCall.toolCallId,
-          args: toolCall.args,
-          argsText: JSON.stringify(toolCall.args),
-          result: "success",
-        });
+        contentBlocks.push({
+          type: "tool-call",
+          toolName: toolCall.toolName,
+          toolCallId: toolCall.toolCallId,
+          args: toolCall.args,
+          argsText: JSON.stringify(toolCall.args),
+          // Optional: only include result if meaningful
+          // result: toolCall.result ?? "success",
+        });

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/page.tsx (1)

1-5: Type metadata for editor support and consistency with Next.js conventions

Annotating metadata with Metadata improves type safety and IDE hints.

+import type { Metadata } from "next";
 
-export const metadata = {
+export const metadata: Metadata = {
   title: "Email Drafts",
 };

apps/e2e/tests/js/email.test.ts (1)

180-191: Assertion is correct; prefer resilient check over full inline snapshot

The unionized validation text can change ordering/wording. A substring check keeps intent while reducing churn.

-    expect(result.error.message).toMatchInlineSnapshot(`
-      deindent\`
-        Request validation failed on POST /api/v1/emails/send-email:
-          - body is not matched by any of the provided schemas:
-            Schema 0:
-              body.html must be defined
-            Schema 1:
-              body.template_id must be defined
-            Schema 2:
-              body.draft_id must be defined
-      \`
-    `);
+    expect(result.error.message).toContain("body is not matched by any of the provided schemas");

apps/dashboard/src/components/vibe-coding/chat-adapters.ts (1)

43-49: Trigger all tool-call callbacks, not just the first

If the model/tooling returns multiple tool calls in one response, only the first currently triggers onToolCall. Iterate and notify for all.

-        if (response.content.some(isToolCall)) {
-          const toolCall = response.content.find(isToolCall);
-          if (toolCall) {
-            onToolCall(toolCall);
-          }
-        }
+        for (const toolCall of response.content.filter(isToolCall)) {
+          onToolCall(toolCall);
+        }

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page.tsx (2)

3-5: Optional: Strongly type metadata to catch future shape regressions.

This helps TS flag invalid metadata fields early.

Apply this diff:

+import type { Metadata } from "next";
 
 export const metadata = {
   title: "Email Draft",
-};
+} satisfies Metadata;

---

7-10: Drop Promise typing and async/await for route params in email-drafts page

The App Router always passes params synchronously. You can simplify the signature and remove the unnecessary Promise and await:

 apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page.tsx
-export default async function Page(props: { params: Promise<{ draftId: string }> }) {
-  const params = await props.params;
-  return <PageClient draftId={params.draftId} />;
-}
+export default function Page({ params }: { params: { draftId: string } }) {
+  return <PageClient draftId={params.draftId} />;
+}

To identify and clean up other occurrences across the repo, you can run:

rg -nP -g '*.ts' -g '*.tsx' '\bparams\s*:\s*Promise<\s*{' -C2

And apply similar diffs to pages, layouts, and route handlers under apps/… and packages/… that type params (or searchParams) as a Promise.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/sidebar-layout.tsx (1)

352-361: Provide a non-null fallback for missing draft names.

Returning null can render a blank crumb. A neutral fallback prevents odd UI in edge cases (e.g., drafts not yet loaded).

Apply this diff:

 function DraftBreadcrumbItem(props: { draftId: string }) {
   const stackAdminApp = useAdminApp();
   const drafts = stackAdminApp.useEmailDrafts();
   const draft = drafts.find((d) => d.id === props.draftId);
-  if (!draft) {
-    return null;
-  }
-  return draft.displayName;
+  if (!draft) {
+    return "Draft";
+  }
+  return draft.displayName;
 }

apps/dashboard/src/components/email-theme-selector.tsx (1)

10-15: Clarify the null/undefined/false mapping with a brief comment.

The JSON encode/decode roundtrip is deliberate to normalize:

• undefined → project default (stored as "null" in the Select value)
• false → no theme
• string → custom theme id

A short comment will prevent regressions and unnecessary future refactors.

Apply this diff:

-function themeIdToSelectString(themeId: string | undefined | false): string {
-  return JSON.stringify(themeId ?? null);
-}
-function selectStringToThemeId(value: string): string | undefined | false {
-  return JSON.parse(value) ?? undefined;
-}
+// Mapping conventions:
+// - undefined: "Project theme" (default) → encoded as "null" for the Select value
+// - false: "No theme" → encoded as "false"
+// - string: Custom theme id → encoded as the JSON string of the id
+function themeIdToSelectString(themeId: string | undefined | false): string {
+  return JSON.stringify(themeId ?? null);
+}
+function selectStringToThemeId(value: string): string | undefined | false {
+  // Decode from Select value; convert null back to undefined to match UI state
+  return JSON.parse(value) ?? undefined;
+}

packages/stack-shared/src/interface/server-interface.ts (1)

799-809: Consider strengthening the sendEmail options type with XOR to prevent invalid combinations at compile time.

Right now both recipients and content fields are optional. Using the shared XOR utility would align the client interface with the template package type and reduce drift.

For example:

import { XOR } from "../utils/types";

type SendEmailRecipient = XOR<[
  { userIds: string[] },
  { allUsers: true }
]>;

type SendEmailContent = XOR<[
  { html: string },
  { templateId: string, variables?: Record<string, any> },
  { draftId: string }
]>;

type SendEmailOptions = SendEmailRecipient & SendEmailContent & {
  themeId?: string | null | false,
  subject?: string,
  notificationCategoryName?: string,
};

async sendEmail(options: SendEmailOptions) { /* ... */ }

apps/backend/src/lib/email-drafts.tsx (2)

25-33: Return-to-template mapping handles null safety; minor edge-case clarification.

For CUSTOM with a null themeId, returning undefined gracefully avoids leaking inconsistent DB state. Optional: assert consistency upstream to prevent CUSTOM + null pairs entering storage.

---

3-13: Nit: add an explicit return type for getEmailDraft for clarity.

Helps with call-site expectations (nullable result) and tooling.

-export async function getEmailDraft(prisma: PrismaClient, tenancyId: string, draftId: string) {
+export async function getEmailDraft(
+  prisma: PrismaClient,
+  tenancyId: string,
+  draftId: string
+): Promise<Awaited<ReturnType<PrismaClient['emailDraft']['findUnique']>>> {

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/page-client.tsx (1)

21-79: Optional: defensive close before navigation in dialog.

Not required, but closing the dialog before push avoids stale state if navigation is intercepted.

apps/backend/src/app/api/latest/internal/email-drafts/[id]/route.tsx (1)

28-28: Minor: prefer findUniqueOrThrow with the composite key for precision.

Current findFirstOrThrow works but is semantically broader than necessary.

-    const d = await prisma.emailDraft.findFirstOrThrow({ where: { tenancyId: tenancy.id, id: params.id } });
+    const d = await prisma.emailDraft.findUniqueOrThrow({
+      where: { tenancyId_id: { tenancyId: tenancy.id, id: params.id } },
+    });

apps/e2e/tests/backend/endpoints/api/v1/send-email.test.ts (2)

586-631: Reduce duplication in schema error messaging (cosmetic)

The validation details list “body contains unknown properties: html” twice for Schema 1 and Schema 2. It’s harmless but noisy. Consider deduplicating per-schema unknown properties to keep error output concise. No change required in tests; this is a route-side improvement.

---

52-87: Rename test to reflect behavior (misleading title)

The test name suggests a “user not found” error, but the scenario creates a valid user and expects a 200 with results. Please rename to avoid confusion (e.g., “should return 200 and include result for valid user”).

apps/backend/src/app/api/latest/internal/email-drafts/route.tsx (1)

31-35: Result capping and sort look good

Limiting to 50 most recently updated drafts per tenancy is reasonable for admin UI listing. Consider making 50 a shared constant if used elsewhere, but not required.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page-client.tsx (1)

39-50: Reset navigation guard after successful save

After updating the draft, clear the confirm flag so moving to the Send stage doesn’t keep prompting.

Apply this diff:

   const handleNext = async () => {
     try {
       await stackAdminApp.updateEmailDraft(draftId, { tsxSource: currentCode, themeId: selectedThemeId });
+      setNeedConfirm(false);
       setStage("send");
     } catch (error) {

packages/stack-shared/src/interface/admin-interface.ts (2)

134-139: Remove redundant | undefined in optional fields

In TypeScript, ? already implies undefined. Simplify the types and keep API shape consistent.

Apply this diff:

-  async listInternalEmailDrafts(): Promise<{ id: string, display_name: string, theme_id?: string | undefined | false, tsx_source: string, sent_at_millis?: number | null }[]> {
+  async listInternalEmailDrafts(): Promise<{ id: string, display_name: string, theme_id?: string | false, tsx_source: string, sent_at_millis?: number | null }[]> {
     const response = await this.sendAdminRequest(`/internal/email-drafts`, {}, null);
-    const result = await response.json() as { drafts: { id: string, display_name: string, theme_id?: string | undefined | false, tsx_source: string, sent_at_millis?: number | null }[] };
+    const result = await response.json() as { drafts: { id: string, display_name: string, theme_id?: string | false, tsx_source: string, sent_at_millis?: number | null }[] };
     return result.drafts;
   }

---

155-167: Unify theme_id nullability across create/update

Update allows null (often meaning “project default”), while create did not. With the change above, create stays string | false, which is fine; for update, keep null to support resetting to project default. Ensure backend normalizes null correctly (see route suggestion).

If you decide to avoid null entirely, change this signature to string | false and have clients omit the field for project-default. Otherwise, keep as-is and ensure the route coerces null to undefined before conversion (suggested in backend comment).

packages/template/src/lib/stack-app/apps/interfaces/admin-app.ts (2)

37-38: Use null instead of undefined for themeId across app types (consistency)

Other parts of the codebase model themeId as string | null | false. Aligning here avoids casting and mismatches in consumers.

Apply this diff:

-  & AsyncStoreProperty<"emailDrafts", [], { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[], true>
+  & AsyncStoreProperty<"emailDrafts", [], { id: string, displayName: string, themeId: string | null | false, tsxSource: string, sentAt: Date | null }[], true>

---

78-80: Align draft APIs’ themeId type with store (string | null | false)

This keeps API, store, and backend expectations consistent and avoids downstream casting.

Apply this diff:

-    createEmailDraft(options: { displayName?: string, themeId?: string | undefined | false, tsxSource?: string }): Promise<{ id: string }>,
-    updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | undefined | false, tsxSource?: string }): Promise<void>,
+    createEmailDraft(options: { displayName?: string, themeId?: string | null | false, tsxSource?: string }): Promise<{ id: string }>,
+    updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | null | false, tsxSource?: string }): Promise<void>,

packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts (4)

304-315: useEmailDrafts: solid mapping; consider extracting a mapper to avoid duplication

The field transforms mirror templates and are consistent with interfaces. To reduce duplication with listEmailDrafts, consider extracting a private mapper method.

Apply this diff to use a mapper, and add the mapper near the other “fromCrud” helpers:

-  useEmailDrafts(): { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[] {
+  useEmailDrafts(): { id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[] {
     const crud = useAsyncCache(this._adminEmailDraftsCache, [], "useEmailDrafts()");
     return useMemo(() => {
-      return crud.map((draft) => ({
-        id: draft.id,
-        displayName: draft.display_name,
-        themeId: draft.theme_id,
-        tsxSource: draft.tsx_source,
-        sentAt: draft.sent_at_millis ? new Date(draft.sent_at_millis) : null,
-      }));
+      return crud.map((draft) => this._adminEmailDraftFromCrud(draft));
     }, [crud]);
   }

Additional code (outside the selected lines) to add once in this class:

private _adminEmailDraftFromCrud(draft: { id: string, display_name: string, theme_id: string | undefined | false, tsx_source: string, sent_at_millis: number | null }) {
  return {
    id: draft.id,
    displayName: draft.display_name,
    themeId: draft.theme_id,
    tsxSource: draft.tsx_source,
    sentAt: draft.sent_at_millis ? new Date(draft.sent_at_millis) : null,
  };
}

---

335-344: listEmailDrafts: mirrors hook mapping; consider reusing the same mapper

Same suggestion as the hook: reuse a single mapper to keep mappings consistent and reduce maintenance overhead.

Apply this diff:

-  async listEmailDrafts(): Promise<{ id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[]> {
+  async listEmailDrafts(): Promise<{ id: string, displayName: string, themeId: string | undefined | false, tsxSource: string, sentAt: Date | null }[]> {
     const crud = Result.orThrow(await this._adminEmailDraftsCache.getOrWait([], "write-only"));
-    return crud.map((draft) => ({
-      id: draft.id,
-      displayName: draft.display_name,
-      themeId: draft.theme_id,
-      tsxSource: draft.tsx_source,
-      sentAt: draft.sent_at_millis ? new Date(draft.sent_at_millis) : null,
-    }));
+    return crud.map((draft) => this._adminEmailDraftFromCrud(draft));
   }

---

477-485: Create draft: align themeId type with backend (allow null)

Server-side templateThemeIdSchema allows null in addition to undefined/false/uuid. Consider permitting null here to avoid unnecessary client-side coercion.

Apply this diff:

-  async createEmailDraft(options: { displayName?: string, themeId?: string | false, tsxSource?: string }): Promise<{ id: string }> {
+  async createEmailDraft(options: { displayName?: string, themeId?: string | false | null, tsxSource?: string }): Promise<{ id: string }> {
     const result = await this._interface.createEmailDraft({
       display_name: options.displayName,
       theme_id: options.themeId,
       tsx_source: options.tsxSource,
     });

---

487-495: Update draft: mirror themeId union and support null

Same rationale as create. Keeps client/server types in sync.

Apply this diff:

-  async updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | undefined | false, tsxSource?: string }): Promise<void> {
+  async updateEmailDraft(id: string, data: { displayName?: string, themeId?: string | false | null | undefined, tsxSource?: string }): Promise<void> {
     await this._interface.updateEmailDraft(id, {
       display_name: data.displayName,
       theme_id: data.themeId,
       tsx_source: data.tsxSource,
     });

apps/backend/src/app/api/latest/emails/send-email/route.tsx (3)

39-50: Validate draft_id as UUID for parity with template_id

If draft IDs are UUIDs, tighten validation for early, consistent failures.

Apply this diff:

-      bodyBase.concat(yupObject({
-        draft_id: yupString().defined(),
-      })),
+      bodyBase.concat(yupObject({
+        draft_id: yupString().uuid().defined(),
+      })),

---

124-145: Avoid double-render when notification_category_name is explicitly provided

You only need the first pass to derive the category from the template if the caller didn’t specify one.

Apply this diff:

-      if (!("html" in body)) {
+      if (!("html" in body) && !body.notification_category_name) {
         // We have to render email twice in this case, first pass is to get the notification category

---

198-201: Consider returning only successful recipients or surfacing per-user errors

Currently, results includes all targeted users regardless of render/send failures; userSendErrors is unused. If callers rely on results to reflect success, consider filtering or adding an errors array. This changes API semantics, so confirm expectation first.

If filtering successes is desired without changing the schema, apply:

-    const results: UserResult[] = Array.from(userMap.values()).map((user) => ({
-      user_id: user.projectUserId,
-      user_email: userPrimaryEmails.get(user.projectUserId) ?? user.contactChannels.find((c) => c.isPrimary === "TRUE")?.value,
-    }));
+    const results: UserResult[] = Array.from(userMap.values())
+      .filter((user) => !userSendErrors.has(user.projectUserId))
+      .map((user) => ({
+        user_id: user.projectUserId,
+        user_email: userPrimaryEmails.get(user.projectUserId) ?? user.contactChannels.find((c) => c.isPrimary === "TRUE")?.value,
+      }));

Alternatively, if you want to keep all recipients and include failure info, we can extend the response type and update clients—say the word and I’ll draft it.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: CR
PR: stack-auth/stack-auth#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-04T22:25:51.260Z
Learning: Applies to apps/backend/prisma/schema.prisma : Database models use Prisma