apps/ai/src/types/workingHours.ts (1)

1-5: Clarify day representation & use stronger typing

Using naked number[] invites ambiguity (0 = Sunday? locale-dependent?). An enum or union literal improves self-documentation and prevents invalid values.

-export type WorkingHours = {
-  days: number[];
+export enum Weekday {
+  Sunday = 0,
+  Monday,
+  Tuesday,
+  Wednesday,
+  Thursday,
+  Friday,
+  Saturday,
+}
+
+export type WorkingHours = {
+  days: Weekday[];
   startTime: number;
   endTime: number;
 };

apps/ai/next.config.js (1)

1-5: Load bundle-analyzer only when requested

withBundleAnalyzer({ enabled: false }) is still included in every build, adding a (tiny) init cost and extra config noise.

-const withBundleAnalyzer = require("@next/bundle-analyzer");
-
-const plugins = [];
-plugins.push(withBundleAnalyzer({ enabled: process.env.ANALYZE === "true" }));
+const plugins = [];
+if (process.env.ANALYZE === "true") {
+  const withBundleAnalyzer = require("@next/bundle-analyzer");
+  plugins.push(withBundleAnalyzer({ enabled: true }));
+}

Keeps production builds leaner while preserving current behaviour when ANALYZE=true.

apps/ai/tsconfig.json (1)

7-9: Alias points to project root, not src/

Mapping "~/*": ["*"] makes ~/utils/foo resolve to apps/ai/utils/foo, bypassing src/ and hampering editor IntelliSense. Typical Cal.com convention is ~/ → ./src/.

-      "~/*": ["*"]
+      "~/*": ["./src/*"]

Tiny change, big DX win.

apps/ai/src/types/eventType.ts (1)

5-6: Prefer Record<string, unknown> over bare object

object blocks access to all properties without type-casting and is discouraged. Swap for a safer, more expressive type:

-  metadata: object;
+  metadata: Record<string, unknown>;

Improves typing without functional impact.

apps/ai/src/utils/sendEmail.ts (1)

23-24: Set API key once, not per-call

mail.setApiKey is idempotent but costly; move it to module top-level after the null-check.

apps/ai/src/env.mjs (1)

41-46: Consider optional PARSE_KEY for local dev

Requiring PARSE_KEY & DATABASE_URL in all modes blocks next dev for UI-only prototyping.
If that flexibility is desired, wrap them in z.string().optional().default("") for non-prod environments.

apps/ai/src/utils/extractUsers.ts (3)

10-11: Consider improving the username regex pattern.

The current regex (?<![a-zA-Z0-9_.])@[a-zA-Z0-9_]+ may miss valid usernames that contain hyphens or dots, which are commonly allowed in usernames.

-    .match(/(?<![a-zA-Z0-9_.])@[a-zA-Z0-9_]+/g)
+    .match(/(?<![a-zA-Z0-9_.])@[a-zA-Z0-9_.]+/g)

---

12-14: Enhance email regex for better validation.

Consider using a more robust email regex pattern that better handles edge cases and follows RFC standards more closely.

-    .match(/[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+/g)
+    .match(/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g)

---

16-29: Consider combining database queries for better performance.

The current implementation makes two separate database queries. Consider combining them into a single query using OR conditions to reduce database round trips.

-  const dbUsersFromUsernames = usernames
-    ? await prisma.user.findMany({
-        select: {
-          id: true,
-          username: true,
-          email: true,
-        },
-        where: {
-          username: {
-            in: usernames,
-          },
-        },
-      })
-    : [];
-
-  // ... other code ...
-
-  const dbUsersFromEmails = emails
-    ? await prisma.user.findMany({
-        select: {
-          id: true,
-          email: true,
-          username: true,
-        },
-        where: {
-          email: {
-            in: emails,
-          },
-        },
-      })
-    : [];
+  const allUsers = (usernames?.length || emails?.length)
+    ? await prisma.user.findMany({
+        select: {
+          id: true,
+          username: true,
+          email: true,
+        },
+        where: {
+          OR: [
+            ...(usernames ? [{ username: { in: usernames } }] : []),
+            ...(emails ? [{ email: { in: emails } }] : []),
+          ],
+        },
+      })
+    : [];
+
+  const dbUsersFromUsernames = allUsers.filter(u => usernames?.includes(u.username || ''));
+  const dbUsersFromEmails = allUsers.filter(u => emails?.includes(u.email));

Also applies to: 50-63

apps/ai/src/types/user.ts (2)

4-11: Consider making some User fields optional.

All fields in the User type are currently required. Consider whether some fields like username should be optional, as some users might not have usernames set.

 export type User = {
   id: number;
   email: string;
-  username: string;
+  username: string | null;
   timeZone: string;
   eventTypes: EventType[];
   workingHours: WorkingHours[];
 };

---

8-8: Consider using a more specific type for timeZone.

The timeZone field could benefit from being more specific than just string to ensure valid timezone values.

-  timeZone: string;
+  timeZone: string; // Consider using a union type or validation for IANA timezone identifiers

apps/ai/src/tools/getBookings.ts (1)

39-41: Improve error message handling.

The error handling assumes data.message exists but this might not always be the case.

   if (response.status !== 200) {
-    return { error: data.message };
+    return { error: data.message || `API error: ${response.status}` };
   }

apps/ai/src/types/booking.ts (3)

15-16: Consider using more specific types for date/time fields.

The startTime and endTime fields could benefit from being more specific than generic strings.

-  startTime: string;
-  endTime: string;
+  startTime: string; // ISO 8601 datetime string
+  endTime: string;   // ISO 8601 datetime string

---

13-13: Consider using a more specific type for uid.

The uid field appears to be a unique identifier and could benefit from being typed as a UUID or branded string type.

-  uid: string;
+  uid: string; // Consider using branded type for UUID

---

8-23: Consider adding JSDoc documentation.

The Booking type is comprehensive but would benefit from documentation explaining the purpose of each field, especially complex ones like metadata and responses.

+/**
+ * Represents a calendar booking with all associated data
+ */
 export type Booking = {
+  /** Unique booking identifier */
   id: number;
+  /** ID of the user who owns this booking */
   userId: number;
   // ... add documentation for other complex fields

apps/ai/src/tools/deleteBooking.ts (1)

34-36: Remove dead code or surface 401 explicitly

If the backend can return 401, either handle it and forward { error: "Unauthorized" } or drop the commented-out branch entirely to avoid confusion.

apps/ai/src/utils/agent.ts (3)

6-12: Align import names with exported symbols

The modules export createBookingTool, cancelBookingTool, editBookingTool, etc., yet they are imported as createBookingIfAvailable, deleteBooking, updateBooking.
Using the same names avoids mental friction and eases grep-based refactors.

---

32-40: Instantiate tools once, not on every agent call

tools is rebuilt for every invocation, creating new instances that hold no state.
Move the array construction outside agent() or memoise it for minor perf wins and easier unit testing.

---

42-46: Fail fast if OPENAI_API_KEY is missing

ChatOpenAI will throw obscure errors when the key is empty.
Add an early guard:

if (!env.OPENAI_API_KEY) {
  throw new Error("OPENAI_API_KEY not set");
}

apps/ai/src/tools/updateBooking.ts (1)

74-81: Validate status with an enum

-status: z.string().optional(),
+status: z.enum(["ACCEPTED","PENDING","CANCELLED","REJECTED"]).optional(),

Prevents typos reaching the backend.

apps/ai/README.md (1)

7-9: Consider formal wording in examples

Replace “wanna” with “want to” for a more professional tone, matching the rest of the doc.

apps/ai/src/tools/sendBookingEmail.ts (1)

4-6: Use consistent import path style

The imports mix different path styles. Use consistent relative paths throughout.

-import { env } from "~/src/env.mjs";
-import type { User, UserList } from "~/src/types/user";
-import sendEmail from "~/src/utils/sendEmail";
+import { env } from "../env.mjs";
+import type { User, UserList } from "../types/user";
+import sendEmail from "../utils/sendEmail";

apps/ai/src/app/api/receive/route.ts (1)

183-183: Remove or document the arbitrary delay

The 1-second delay seems arbitrary. Either remove it or add a comment explaining why it's needed.

-  await new Promise((r) => setTimeout(r, 1000));
+  // Small delay to ensure the agent request is initiated before responding
+  // This prevents the client from closing the connection too early
+  await new Promise((r) => setTimeout(r, 100));

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

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

Learnt from: vijayraghav-io
PR: calcom/cal.com#21072
File: packages/app-store/office365calendar/api/webhook.ts:120-123
Timestamp: 2025-07-18T17:57:16.370Z
Learning: The office365calendar webhook handler in packages/app-store/office365calendar/api/webhook.ts is specifically designed for Office365 calendar integration, not as a generic webhook handler. Therefore, it's safe to assume that fetchAvailabilityAndSetCache method will be implemented in the Office365CalendarService, making explicit validation checks unnecessary.

apps/ai/src/tools/getAvailability.ts (2)

30-31: Add JSON parsing safety checks

Apply the same JSON parsing improvements as suggested for the event types file to prevent runtime errors from malformed responses.

-    const availabilityData = JSON.parse(content[0]?.text || "{}");
-    return { workingHours: availabilityData.workingHours || [] };
+    try {
+      const availabilityData = JSON.parse(content[0]?.text || "{}");
+      return { workingHours: Array.isArray(availabilityData.workingHours) ? availabilityData.workingHours : [] };
+    } catch (parseError) {
+      return { workingHours: [], error: "Failed to parse availability response" };
+    }

---

33-34: Consider using structured logging

Same logging consistency suggestion as the previous file - consider using the application's structured logging system.

apps/ai/src/tools/getEventTypes.ts (2)

3-10: Improve type safety for event types array

The eventTypes property uses any[] which reduces type safety. Consider defining a proper interface for event type objects.

+interface EventType {
+  id: number | string;
+  slug: string;
+  length: number;
+  title: string;
+}

 export interface EventTypesResponse {
-  eventTypes?: any[];
+  eventTypes?: EventType[];
   error?: string;
 }

---

27-28: Consider using structured logging instead of console.error

Given this is part of a larger Cal.com application, consider using the application's logging system for consistency.

From the relevant code snippets, there appears to be a structured logging system at apps/api/v2/src/lib/logger.bridge.ts. Consider using it for better log management and consistency.

apps/ai/src/tools/getAvailability.ts (1)

3-13: Improve type safety for working hours array

Similar to the previous file, using any[] for workingHours reduces type safety. Consider defining proper types based on the working hours structure.

+interface WorkingHour {
+  days: number[];
+  startTime: number;
+  endTime: number;
+  userId?: number;
+}

 export interface AvailabilityResponse {
-  workingHours: any[];
+  workingHours: WorkingHour[];
   error?: string;
 }

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

Learnt from: vijayraghav-io
PR: calcom/cal.com#21072
File: packages/app-store/office365calendar/api/webhook.ts:120-123
Timestamp: 2025-07-18T17:57:16.370Z
Learning: The office365calendar webhook handler in packages/app-store/office365calendar/api/webhook.ts is specifically designed for Office365 calendar integration, not as a generic webhook handler. Therefore, it's safe to assume that fetchAvailabilityAndSetCache method will be implemented in the Office365CalendarService, making explicit validation checks unnecessary.