apps/dashboard/src/components/resizable-container.tsx-210-215 (1)

210-215: ⚠️ Potential issue | 🟡 Minor

Hardcoded bg-white won't adapt to dark mode.

Line 212 uses bg-white for the container background. Given that the ring already has dark-mode support (dark:ring-white/[0.08]), the background should likely also respect dark mode.

♻️ Suggested fix

-          "bg-white shadow-2xl",
+          "bg-white dark:bg-zinc-900 shadow-2xl",

Adjust the dark color to match your design system's surface token.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/resizable-container.tsx` around lines 210 -
215, The container currently hardcodes "bg-white" inside the className passed to
cn (the JSX in ResizableContainer / resizable-container.tsx); update that class
string to use your design-system surface token and add a dark-mode variant (for
example replace "bg-white" with the surface token and "dark:..." counterpart
such as "bg-surface dark:bg-surface-<dark-token>" or whatever token names your
design system uses) so the background follows dark mode while keeping the
existing ring classes and other utilities untouched.

apps/backend/src/app/api/latest/internal/wysiwyg-edit/route.tsx-151-151 (1)

151-151: ⚠️ Potential issue | 🟡 Minor

Mock-mode // comment may break non-JS source types.

The source_type field accepts "template", "theme", and "draft". If "theme" represents CSS or a non-JS format, prepending a // NOTE: ... comment produces invalid syntax. Consider using a format-appropriate comment or skipping the note for non-JS types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/app/api/latest/internal/wysiwyg-edit/route.tsx` at line 151,
The current construction of updatedSource unconditionally prepends a // comment
which can invalidate non-JS sources; update the logic in route.tsx around the
updatedSource creation (the updatedSource variable and where source_type is
read) to choose a source-type-appropriate comment or omit the note: implement a
small helper (e.g., getCommentPrefixForSourceType(source_type)) that returns
'//' for JS-like types, '/* ... */' or '/*...*/\n' for CSS/theme, '<!-- ... -->'
for HTML templates, or an empty string for unknown binary formats, then prepend
that prefix + note only when non-empty before ${replacedSource}; ensure the
helper covers "template", "theme", and "draft" cases and falls back to omitting
the note.

apps/backend/src/app/api/latest/internal/wysiwyg-edit/route.tsx-27-27 (1)

27-27: ⚠️ Potential issue | 🟡 Minor

Typo in system prompt.

Line 31: "without massively the rest of the source code" → should be "without massively changing the rest of the source code".

Fix

-8. Context: The user is editing the text in a WYSIWYG editor. They expect that the change they made will be reflected as-is, without massively the rest of the source code. However, in most cases, the user don't actually care about the rest of the source code, so in the rare cases where things are complex and you would have to change a bit more than just the text node, you should make the changes that sound reasonable from a UX perspective.
+8. Context: The user is editing the text in a WYSIWYG editor. They expect that the change they made will be reflected as-is, without massively changing the rest of the source code. However, in most cases, the user doesn't actually care about the rest of the source code, so in the rare cases where things are complex and you would have to change a bit more than just the text node, you should make the changes that sound reasonable from a UX perspective.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/app/api/latest/internal/wysiwyg-edit/route.tsx` at line 27,
There's a typo in the system prompt text in route.tsx: replace the phrase
"without massively the rest of the source code" with "without massively changing
the rest of the source code" so the prompt reads correctly; locate the system
prompt string (used in the WYSIWYG edit route handler in
apps/backend/src/app/api/latest/internal/wysiwyg-edit/route.tsx) and update that
literal accordingly.

apps/dashboard/src/components/design-components/button.tsx-58-58 (1)

58-58: ⚠️ Potential issue | 🟡 Minor

Duplicate displayName — both inner and outer button are "DesignButton".

DesignOriginalButton has displayName = "DesignButton" (Line 58) and DesignButton also has displayName = "DesignButton" (Line 91). This makes the two components indistinguishable in React DevTools.

Suggested fix

-DesignOriginalButton.displayName = "DesignButton";
+DesignOriginalButton.displayName = "DesignOriginalButton";

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/design-components/button.tsx` at line 58, Both
components share the same displayName; change DesignOriginalButton.displayName
to a unique name so React DevTools can distinguish them. Locate the displayName
assignments for DesignOriginalButton and DesignButton and set them to distinct
identifiers (e.g., DesignOriginalButton.displayName = "DesignOriginalButton" and
keep DesignButton.displayName = "DesignButton") so each component has a unique
displayName.

apps/dashboard/src/components/design-components/tabs.tsx-96-102 (1)

96-102: ⚠️ Potential issue | 🟡 Minor

!value in getMapValueOrThrow fails for falsy values like 0, "", or false.

Map.get returns undefined for missing keys, so the check should be value === undefined to avoid incorrectly throwing for legitimately stored falsy values. While current callers use object values, the helper is generic.

Suggested fix

 function getMapValueOrThrow<TKey, TValue>(map: Map<TKey, TValue>, key: TKey, mapName: string) {
-  const value = map.get(key);
-  if (!value) {
+  if (!map.has(key)) {
     throw new Error(`Missing ${mapName} entry for key "${String(key)}"`);
   }
-  return value;
+  return map.get(key) as TValue;
 }

Or keep the get + explicit undefined check:

   const value = map.get(key);
-  if (!value) {
+  if (value === undefined) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/design-components/tabs.tsx` around lines 96 -
102, The check in getMapValueOrThrow incorrectly treats falsy stored values (0,
"", false) as missing; update the existence test to only treat undefined as
missing by checking value === undefined (or value === undefined || map.has(key)
=== false pattern), so replace the current if (!value) throw with an explicit
undefined check while keeping the generic signature of getMapValueOrThrow and
using map.get/key/mapName to build the error message.

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

623-635: ⚠️ Potential issue | 🟡 Minor

Fix editableRegions type at the source instead of casting at usage

Line 631 casts editableRegions[id] to EditableMetadata to work around the hook returning Record<string, unknown>. Update useEmailPreviewWithEditableMarkers in packages/template/src/lib/stack-app/apps/implementations/admin-app-impl.ts (line 682) to return Record<string, EditableMetadata> instead of Record<string, unknown>, eliminating the need for the cast.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/email-preview.tsx` around lines 623 - 635, The
hook useEmailPreviewWithEditableMarkers currently returns Record<string,
unknown>, forcing callers to cast editableRegions[id] to EditableMetadata;
update the hook implementation (useEmailPreviewWithEditableMarkers) to return
Record<string, EditableMetadata> (or a typed interface) so editableRegions is
correctly typed at the source, adjust any internal logic/returns inside that
function to construct and return EditableMetadata values, and update its
signature/export so callers like the component using editableRegions no longer
need to cast.

apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/playground/page-client.tsx-327-341 (1)

327-341: ⚠️ Potential issue | 🟡 Minor

Replace row.getValue() with row.original to eliminate unnecessary type casts

Lines 331 and 339 use as type assertions on row.getValue(...). Since the column definition is typed as ColumnDef<DemoProduct>[], row.original is already properly typed as DemoProduct and eliminates the need for casts.

Suggested change

- cell: ({ row }) => (
-   <span className="text-sm text-muted-foreground">
-     ${(row.getValue("price") as number).toFixed(2)}
-   </span>
- ),
+ cell: ({ row }) => (
+   <span className="text-sm text-muted-foreground">
+     ${row.original.price.toFixed(2)}
+   </span>
+ ),
...
- const s = row.getValue("status") as DemoProduct["status"];
- return <DesignBadge label={STATUS_BADGE[s].label} color={STATUS_BADGE[s].color} size="sm" />;
+ const status = row.original.status;
+ return <DesignBadge label={STATUS_BADGE[status].label} color={STATUS_BADGE[status].color} size="sm" />;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/(outside-dashboard)/playground/page-client.tsx
around lines 327 - 341, Replace unnecessary type assertions by using the typed
row.original property: in the price column cell (currently using
(row.getValue("price") as number).toFixed(2)) use the typed value from
row.original.price, and in the status column cell (currently using
row.getValue("status") as DemoProduct["status"]) use row.original.status to feed
STATUS_BADGE and DesignBadge; this leverages the ColumnDef<DemoProduct>[] typing
and removes the need for casts on row.getValue.

apps/dashboard/src/components/editable-grid.tsx-438-442 (1)

438-442: ⚠️ Potential issue | 🟡 Minor

Use a stable key for grid items

Line 440 uses key={index}; if items reorder, React can reuse state incorrectly. Since itemKey is available in all item types (via BaseItemProps), use that with a fallback for stability.

Suggested change

- key={index}
+ key={item.itemKey ?? index}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/editable-grid.tsx` around lines 438 - 442, The
map currently uses an unstable index key (key={index}) for GridItemContent which
can cause incorrect state reuse when items reorder; change it to use the item's
stable identifier (item.itemKey) as the key and fall back to a stable derived
value only if item.itemKey is missing so keys remain consistent; update the
items.map call that renders <GridItemContent ...> to use item.itemKey (with a
deterministic fallback) and ensure any code referencing externalModifiedKeys
still uses item.itemKey to check modification status.

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

98-105: ⚠️ Potential issue | 🟡 Minor

Use explicit check instead of !currentCode for string state.

Line 100 uses !currentCode which is a boolean check on a string. An empty template source ("") would be falsy, which means the sync would trigger even if the user had cleared the editor. Consider an explicit check that better represents the intent, e.g. tracking whether the template has been initially loaded.

As per coding guidelines, "prefer explicit null/undefinedness checks over boolean checks, eg. foo == null instead of !foo".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/email-templates/[templateId]/page-client.tsx
around lines 98 - 105, The useEffect currently checks `!currentCode`, which
treats an empty string as unset; change that to an explicit null/undefined check
(e.g., `currentCode == null`) so only truly uninitialized state triggers the
sync; update the conditional in the useEffect that references
`templateFromHook`, `currentCode`, `hasSyncedTemplateFromHook`, and the calls to
`setCurrentCode`/`setSelectedThemeId` to use the explicit null check for
`currentCode` while keeping the existing `hasSyncedTemplateFromHook` guard to
ensure initial-load-only behavior.

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

82-83: ⚠️ Potential issue | 🟡 Minor

Avoid the as type cast — use a fallback or explicit check instead.

Line 83 uses as 'template' | 'theme' | 'both' to bypass the type system. Since yup validates the value via .oneOf(...), the runtime value is guaranteed, but the cast hides this from TypeScript. Consider a safer pattern:

Proposed fix

-    const editableSource = ('editable_source' in body ? body.editable_source : 'template') as 'template' | 'theme' | 'both';
+    const rawEditableSource = 'editable_source' in body ? body.editable_source : undefined;
+    const editableSource: 'template' | 'theme' | 'both' =
+      rawEditableSource === 'template' || rawEditableSource === 'theme' || rawEditableSource === 'both'
+        ? rawEditableSource
+        : 'template';

As per coding guidelines, "Do NOT use as/any/type casts or anything else like that to bypass the type system unless you specifically asked the user about it".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/backend/src/app/api/latest/emails/render-email/route.tsx` around lines
82 - 83, The code uses a type cast on editableSource to silence TypeScript;
instead add a runtime check or type guard so TypeScript can infer the union
without "as". Replace the cast on editableSource by validating
body.editable_source with a small predicate or includes check (e.g. an
isEditableSource(value): value is 'template'|'theme'|'both' or
['template','theme','both'].includes(value)) and then set const editableSource =
isEditableSource(body.editable_source) ? body.editable_source : 'template';
ensure you reference the existing editableSource variable and
body.editable_source so the type is narrowed safely without using as.

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

350-355: ⚠️ Potential issue | 🟡 Minor

Yup schema allows empty string for draft name.

yup.string().defined() permits empty strings. While the required HTML attribute on the InputField (line 362) provides browser-level validation, the schema itself would pass "". Consider adding .required() to the yup schema for robust validation.

♻️ Suggested fix

       formSchema={yup.object({
-        name: yup.string().defined().label("Draft name"),
+        name: yup.string().required().label("Draft name"),
       })}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/email-drafts/page-client.tsx
around lines 350 - 355, The yup schema for the form (the formSchema passed to
the component) currently uses yup.string().defined() for the "name" field which
allows empty strings; update the schema for the name field in the formSchema
(the yup.object used alongside handleCreateNewDraft) to enforce non-empty values
by chaining .required() (optionally also .trim().min(1) to reject
whitespace-only names) so the schema itself will reject empty/blank draft names
instead of relying only on the InputField HTML required attribute.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx-395-438 (1)

395-438: ⚠️ Potential issue | 🟡 Minor

Column definitions are re-created on every render; also, status is always hardcoded to "Active".

Two observations:

1. columns is defined inside the else branch without useMemo, so it's re-created on every render. This can cause unnecessary table re-renders.

2. The "Status" column (lines 414-423) always renders a green "Active" badge regardless of the actual endpoint state. If Svix endpoints can be disabled or paused, this misrepresents their status.

♻️ Consider memoizing the columns

Move the column definitions into a useMemo or extract them outside the component (since they depend on props).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx
around lines 395 - 438, The columns array (columns) is being re-created on every
render and the "Status" column always shows a hardcoded "Active" badge; wrap the
column definitions in a useMemo so they are memoized based on dependencies
(e.g., props.updateFn, props.onTestRequested) and update the status column cell
to read the endpoint state from row.original (e.g., row.original.status or
row.original.enabled) and render DesignBadge with the appropriate label and
color instead of the hardcoded "Active"; ensure ActionMenu still receives
endpoint={row.original} and the memo includes any props it uses.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/team-settings/page-client.tsx-37-42 (1)

37-42: ⚠️ Potential issue | 🟡 Minor

useEffect resets selection on every defaultPermissions reference change while dialog is open.

defaultPermissions is an object derived from config, so its reference may change on every render (or whenever config re-fetches). If this happens while the dialog is open, the user's in-progress checkbox changes get silently discarded. Consider memoizing defaultPermissions or comparing by value (e.g., JSON.stringify) to avoid spurious resets.

♻️ Suggested approach

+  const defaultPermissionsKey = JSON.stringify(defaultPermissions);
+
   // Reset selection when dialog opens
   useEffect(() => {
     if (open) {
       setSelectedIds(Object.keys(defaultPermissions).filter(id => defaultPermissions[id]));
     }
-  }, [open, defaultPermissions]);
+  // eslint-disable-next-line react-hooks/exhaustive-deps -- compare by value, not reference
+  }, [open, defaultPermissionsKey]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/team-settings/page-client.tsx
around lines 37 - 42, The useEffect that resets selection when the dialog opens
is using the mutable reference defaultPermissions, causing selection to be reset
whenever defaultPermissions' reference changes while open; update the code so
the effect only depends on stable values—either memoize defaultPermissions where
it's created (so the reference is stable) or change the effect to compare values
(e.g., derive a stringifiedKey = JSON.stringify(defaultPermissions) and depend
on that) and keep the current conditions (open) and update via
setSelectedIds(Object.keys(defaultPermissions).filter(id =>
defaultPermissions[id])) only when the actual permissions value changes rather
than on reference equality; ensure you adjust dependencies to use the memoized
variable or the stringified value in the useEffect signature.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/emails/page-client.tsx-709-719 (1)

709-719: ⚠️ Potential issue | 🟡 Minor

Boolean checks for missing fields: port 0 would be falsely flagged as missing.

!emailServerConfig.port is falsy when the port is 0, which is a valid (though uncommon) port number and is explicitly allowed by the schema (yup.number().min(0, ...)). Use explicit null/undefined checks instead.

Suggested fix

-      if (!emailServerConfig.host) missingFields.push("host");
-      if (!emailServerConfig.port) missingFields.push("port");
-      if (!emailServerConfig.username) missingFields.push("username");
-      if (!emailServerConfig.password) missingFields.push("password");
-      if (!emailServerConfig.senderName) missingFields.push("sender name");
-      if (!emailServerConfig.senderEmail) missingFields.push("sender email");
+      if (emailServerConfig.host == null) missingFields.push("host");
+      if (emailServerConfig.port == null) missingFields.push("port");
+      if (emailServerConfig.username == null) missingFields.push("username");
+      if (emailServerConfig.password == null) missingFields.push("password");
+      if (emailServerConfig.senderName == null) missingFields.push("sender name");
+      if (emailServerConfig.senderEmail == null) missingFields.push("sender email");

As per coding guidelines: "Unless very clearly equivalent from types, prefer explicit null/undefinedness checks over boolean checks, eg. foo == null instead of !foo."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/emails/page-client.tsx
around lines 709 - 719, The null/undefined check logic currently uses boolean
falsiness (e.g., !emailServerConfig.port) which incorrectly treats valid falsy
values like 0 as missing; update the checks to use explicit null/undefined
checks—for example replace the port check with emailServerConfig.port == null
(or === null || === undefined) before pushing "port" to missingFields; apply the
same explicit null/undefined style for any other fields where falsy but valid
values may exist, then keep the setError and return "prevent-close" behavior
unchanged.

apps/dashboard/src/components/design-components/list.tsx-197-206 (1)

197-206: ⚠️ Potential issue | 🟡 Minor

Empty name produces an invisible avatar initial.

If name is an empty string, name.charAt(0) returns "", leaving the avatar circle blank with no visual fallback.

Suggested fix

-      {name.charAt(0)}
+      {name.charAt(0) || "?"}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/design-components/list.tsx` around lines 197 -
206, UserAvatar currently renders name.charAt(0) which produces an empty string
for an empty or whitespace-only name and leaves the avatar blank; update the
rendering in the UserAvatar component to compute a safe initial (for example:
take name?.trim().charAt(0)?.toUpperCase() and fall back to a default like "?"
when that result is falsy) so the avatar always shows a visible character;
reference the UserAvatar function and its name prop to locate where to replace
name.charAt(0) with this guarded fallback.

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

279-287: ⚠️ Potential issue | 🟡 Minor

getErrorMessage is defined but never used.

This function at the bottom of the file is unreferenced — it appears to be dead code left over from refactoring.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/email-drafts/[draftId]/page-client.tsx
around lines 279 - 287, The function getErrorMessage is dead code and should be
removed; delete the getErrorMessage function (and its dependency on
KnownErrors.EmailRenderingError if that import is only used by it) from
page-client.tsx to clean up unused code, or if its logic is still needed,
replace inline error handling in the surrounding components/methods with calls
to getErrorMessage (e.g., where errors are rendered) and ensure
KnownErrors.EmailRenderingError remains imported; locate the symbol
getErrorMessage to remove or replace and adjust imports accordingly.

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

275-282: ⚠️ Potential issue | 🟡 Minor

Preview senderEmail derivation could produce an odd address for edge-case project names.

If project.displayName is empty or all-special-characters, the email becomes noreply@.com. This is only for a preview so the impact is cosmetic, but a fallback would be cleaner:

- senderEmail={`noreply@${project.displayName.toLowerCase().replace(/[^a-z0-9]/g, '')}.com`}
+ senderEmail={`noreply@${project.displayName.toLowerCase().replace(/[^a-z0-9]/g, '') || 'example'}.com`}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/email-themes/page-client.tsx
around lines 275 - 282, The preview senderEmail can become "noreply@.com" when
project.displayName is empty or fully sanitized away; update the code that
supplies the senderEmail prop for EmailPreview to compute a sanitized local-part
(e.g., lowercased project.displayName with non-alphanumerics removed) and if
that result is empty use a safe fallback (like project.id, "example", or
"default") so senderEmail is always a valid-looking address (e.g.,
`noreply@{sanitizedOrFallback}.com`); adjust where senderEmail is constructed
near the EmailPreview usage that references selectedThemeData and
project.displayName.

🤖 Fix all nitpicks with AI agents

Verify each finding against the current code and only fix it if needed.


In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/(overview)/line-chart.tsx:
- Around line 186-218: Hoist the static mapping const designCardGradients out of
the component and into module scope so it isn't recreated on every render: move
the existing designCardGradients declaration to the top-level of the file (above
the component) and leave all references (designCardGradients[gradientColor])
inside the component unchanged; ensure the identifier name remains the same and
adjust any imports/exports only if you intend to reuse it across files.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/data-vault/stores/[storeId]/page-client.tsx:
- Around line 36-54: The code reads `store = config.dataVault.stores[storeId]`
before checking existence and declares `modifiedKeys` with `useMemo`, which can
leave `store` typed as possibly undefined later; fix by either moving the
existence guard (the `if (!(storeId in config.dataVault.stores))` block) above
the `store` and `useMemo` declarations so hooks remain in the same order across
returns, or keep the current order and add an explicit defensive narrowing
immediately after the guard (e.g., throw via a utility if `store` is undefined)
so usages later (references to `store`, `modifiedKeys`, `useMemo`) see a
non-undefined `store`; ensure you do not introduce conditional hooks when
reordering.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/launch-checklist/page-client.tsx:
- Around line 539-548: The confetti timer uses Date.now() for elapsed-time
calculations; update the logic to use performance.now() instead by setting
animationEnd based on performance.now() + duration (replace the current
animationEnd = Date.now() + duration) and compute timeLeft as animationEnd -
performance.now() inside the setInterval callback (keep the rest of the confetti
logic including defaults, randomInRange, and interval unchanged). Ensure all
references to Date.now() in this block are replaced so elapsed-time measurement
consistently uses performance.now().
- Around line 149-158: The cardClass values for the checklist states (keys done,
action, blocked) use hover-enter classes like "transition-all duration-300
hover:shadow-lg"; update each cardClass in page-client.tsx to follow the
dashboard hover-exit pattern by moving the transition to the base state and
removing hover-enter effects—specifically, keep a base transition (e.g.,
transition-[property] and duration) and replace hover:shadow-lg with
hover:transition-none (and remove or neutralize any shadow-on-hover) so the
visual transition occurs on hover-exit rather than on hover-enter; update the
cardClass strings for done, action, and blocked accordingly.
- Around line 142-161: STATUS_META currently defines identical cardClass strings
for all LaunchTaskStatus keys (done, action, blocked); either deduplicate by
extracting a shared constant and reusing it in STATUS_META or assign distinct
cardClass values per status if visual differentiation is intended. Update the
STATUS_META declaration (and the LaunchTaskStatus usages) to reference a single
constant like DEFAULT_CARD_CLASS for the common string, or replace the three
identical cardClass values with unique style strings for done/action/blocked so
the per-status lookup becomes meaningful.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/vercel/page-client.tsx:
- Around line 492-496: The DesignButton/StyledLink combination currently uses
"transition-all duration-150" which triggers hover-enter transitions; replace
that with a hover-exit pattern such as "transition-colors duration-150
hover:transition-none" (keeping other classes like "font-medium border
border-border shadow-sm active:scale-95 dark:..." intact) for the instance
inside page-client.tsx and the matching button(s) later in the file to follow
the dashboard guideline.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/launch-checklist/page-client.tsx (3)

539-548: Use performance.now() instead of Date.now() for elapsed-time measurement.

The confetti animation interval computes remaining time via Date.now(). Per coding guidelines, performance.now() should be used for measuring elapsed (real) time.

Proposed fix

-      const animationEnd = Date.now() + duration;
+      const animationEnd = performance.now() + duration;
       ...
-        const timeLeft = animationEnd - Date.now();
+        const timeLeft = animationEnd - performance.now();

As per coding guidelines: "Use performance.now() instead of Date.now() for measuring elapsed (real) time."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/launch-checklist/page-client.tsx
around lines 539 - 548, The confetti timer uses Date.now() for elapsed-time
calculations; update the logic to use performance.now() instead by setting
animationEnd based on performance.now() + duration (replace the current
animationEnd = Date.now() + duration) and compute timeLeft as animationEnd -
performance.now() inside the setInterval callback (keep the rest of the confetti
logic including defaults, randomInRange, and interval unchanged). Ensure all
references to Date.now() in this block are replaced so elapsed-time measurement
consistently uses performance.now().

---

149-158: Consider hover-exit transition pattern per dashboard guidelines.

Classes like transition-all duration-300 hover:shadow-lg are hover-enter transitions. The dashboard guideline recommends the inverse: apply transitions on exit, not entry (e.g., transition-all hover:transition-none), so the visual effect feels snappier.

As per coding guidelines: "Use hover-exit transitions instead of hover-enter transitions. For example, transition-colors hover:transition-none."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/launch-checklist/page-client.tsx
around lines 149 - 158, The cardClass values for the checklist states (keys
done, action, blocked) use hover-enter classes like "transition-all duration-300
hover:shadow-lg"; update each cardClass in page-client.tsx to follow the
dashboard hover-exit pattern by moving the transition to the base state and
removing hover-enter effects—specifically, keep a base transition (e.g.,
transition-[property] and duration) and replace hover:shadow-lg with
hover:transition-none (and remove or neutralize any shadow-on-hover) so the
visual transition occurs on hover-exit rather than on hover-enter; update the
cardClass strings for done, action, and blocked accordingly.

---

142-161: All three STATUS_META entries share the same cardClass string.

The done, action, and blocked statuses have identical cardClass values, which makes the per-status lookup pointless. If differentiation is planned, consider adding distinct styles; otherwise, extract a single constant to avoid the repetition.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/launch-checklist/page-client.tsx
around lines 142 - 161, STATUS_META currently defines identical cardClass
strings for all LaunchTaskStatus keys (done, action, blocked); either
deduplicate by extracting a shared constant and reusing it in STATUS_META or
assign distinct cardClass values per status if visual differentiation is
intended. Update the STATUS_META declaration (and the LaunchTaskStatus usages)
to reference a single constant like DEFAULT_CARD_CLASS for the common string, or
replace the three identical cardClass values with unique style strings for
done/action/blocked so the per-status lookup becomes meaningful.

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

492-496: Prefer hover-exit transitions per dashboard guidelines.

The buttons use transition-all duration-150 which applies transitions on hover-enter. The coding guideline states: "Use hover-exit transitions instead of hover-enter transitions. For example, transition-colors hover:transition-none."

Proposed fix

- className="font-medium border border-border shadow-sm transition-all duration-150 hover:bg-accent active:scale-95 ..."
+ className="font-medium border border-border shadow-sm transition-all duration-150 hover:transition-none hover:bg-accent active:scale-95 ..."

Also applies to: 501-508

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/vercel/page-client.tsx
around lines 492 - 496, The DesignButton/StyledLink combination currently uses
"transition-all duration-150" which triggers hover-enter transitions; replace
that with a hover-exit pattern such as "transition-colors duration-150
hover:transition-none" (keeping other classes like "font-medium border
border-border shadow-sm active:scale-95 dark:..." intact) for the instance
inside page-client.tsx and the matching button(s) later in the file to follow
the dashboard guideline.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/data-vault/stores/[storeId]/page-client.tsx (1)

36-54: store is read before the existence guard — consider reordering or adding a defensive throw.

store is assigned on line 36 but may be undefined if storeId isn't present. The early return on line 41 prevents further usage at runtime, but TypeScript may not narrow the type, leaving store typed as potentially undefined when used later (lines 57, 65, 129). A small reorder makes the intent explicit:

♻️ Suggested reorder

  const config = project.useConfig();
- const store = config.dataVault.stores[storeId];
- const modifiedKeys = useMemo(() => new Set([
-   ...(localDisplayName !== undefined ? ["display-name"] : []),
- ]), [localDisplayName]);

  if (!(storeId in config.dataVault.stores)) {
    return (
      ...
    );
  }

+ const store = config.dataVault.stores[storeId] ?? throwErr(`Store ${storeId} not found despite passing existence check`);
+ const modifiedKeys = useMemo(() => new Set([
+   ...(localDisplayName !== undefined ? ["display-name"] : []),
+ ]), [localDisplayName]);

Note: this requires that no React hooks are called between the early return and the rest of the component (hooks must not be called conditionally). Since useMemo is currently before the guard, moving it after the guard would violate the rules of hooks if the guard triggers a different return path. This needs careful handling — you may instead keep the current structure and just add an explicit narrowing assertion after the guard.

As per coding guidelines, 'Code defensively. Prefer ?? throwErr(...) over non-null assertions, with good error messages explicitly stating the assumption that must've been violated'.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/data-vault/stores/[storeId]/page-client.tsx
around lines 36 - 54, The code reads `store = config.dataVault.stores[storeId]`
before checking existence and declares `modifiedKeys` with `useMemo`, which can
leave `store` typed as possibly undefined later; fix by either moving the
existence guard (the `if (!(storeId in config.dataVault.stores))` block) above
the `store` and `useMemo` declarations so hooks remain in the same order across
returns, or keep the current order and add an explicit defensive narrowing
immediately after the guard (e.g., throw via a utility if `store` is undefined)
so usages later (references to `store`, `modifiedKeys`, `useMemo`) see a
non-undefined `store`; ensure you do not introduce conditional hooks when
reordering.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/(overview)/line-chart.tsx (1)

186-218: Consider hoisting designCardGradients to module scope.

This static mapping doesn't depend on props or state, yet it's recreated on every render of ChartCard. Moving it outside the component is a small clarity and allocation win.

♻️ Proposed change

+const designCardGradients: Record<GradientColor, "blue" | "cyan" | "purple" | "green" | "orange" | "default"> = {
+  blue: "blue",
+  purple: "purple",
+  green: "green",
+  orange: "orange",
+  slate: "default",
+  cyan: "cyan",
+};
+
 export function ChartCard({
   children,
   className,
   gradientColor = "blue"
 }: {
   children: React.ReactNode,
   className?: string,
   gradientColor?: GradientColor,
 }) {
-  const designCardGradients: Record<GradientColor, "blue" | "cyan" | "purple" | "green" | "orange" | "default"> = {
-    blue: "blue",
-    purple: "purple",
-    green: "green",
-    orange: "orange",
-    slate: "default",
-    cyan: "cyan",
-  };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/(overview)/line-chart.tsx
around lines 186 - 218, Hoist the static mapping const designCardGradients out
of the component and into module scope so it isn't recreated on every render:
move the existing designCardGradients declaration to the top-level of the file
(above the component) and leave all references
(designCardGradients[gradientColor]) inside the component unchanged; ensure the
identifier name remains the same and adjust any imports/exports only if you
intend to reuse it across files.

🤖 Fix all nitpicks with AI agents

Verify each finding against the current code and only fix it if needed.


In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx:
- Line 263: The rendering uses a boolean fallback that treats empty strings as
missing; change the fallback for project.description to an explicit nullish
check (e.g., use the null/undefined check on project.description or the nullish
coalescing behavior) so that an empty string remains displayed while only
null/undefined becomes "-"; update the JSX that references project.description
in page-client.tsx (the <p> that shows project.description) to use an explicit
check like project.description == null ? "-" : project.description or the
equivalent nullish-coalescing approach.
- Line 30: Replace the three uses of `any` with proper types or a short
justification comment: for the `TeamMemberItem` prop `member` use the SDK type
(e.g., `TeamMember`) instead of `any`; for the `team` variable use the SDK's
`Team` type; for the form `values` replace `any` with `yup.InferType<typeof
projectInformationSchema>` (or the explicit inferred type) — if a precise type
truly cannot be expressed, add a one-line comment next to each usage explaining
why `any` is required and reference the limitation (e.g., runtime shape,
third‑party SDK looseness) so the rationale is recorded.
- Around line 303-321: The dark-mode LogoUpload handlers are inline async
lambdas while the light-mode handlers use useCallback (handleLogoChange,
handleFullLogoChange); make the dark-mode handlers consistent by creating
memoized callbacks (e.g., handleLogoDarkChange and handleFullLogoDarkChange)
using useCallback that call project.update({ logoDarkModeUrl }) and
project.update({ logoFullDarkModeUrl }) respectively, and pass those memoized
functions to the LogoUpload onValueChange props so all four handlers are
implemented consistently.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx:
- Around line 396-439: The columns array (ColumnDef<Endpoint> assigned to
columns) is recreated on every render and closes over props.updateFn and
props.onTestRequested causing unnecessary re-renders of DesignDataTable; fix by
moving the columns definition above the early return and wrapping it in useMemo,
e.g. useMemo(() => [ ...columns... ], [props.updateFn, props.onTestRequested])
so ActionMenu receives stable updateFn/onTestEndpoint references and the table
won’t re-render unnecessarily.
- Around line 344-350: The conditional rendering uses a truthy check for the
variable errorMessage; change it to an explicit null/undefined check (e.g.,
errorMessage != null) so the condition only triggers when errorMessage is not
null/undefined; update the JSX around the status, errorMessage, and DesignAlert
usage in the page-client component to use the explicit check.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx (3)

263-263: Boolean check on project.description hides empty strings.

project.description || "-" will display "-" for both null/undefined and an empty string "". If an empty description is a valid state distinct from "no description", prefer an explicit nullish check.

-            <p className="text-sm text-foreground/80">{project.description || "-"}</p>
+            <p className="text-sm text-foreground/80">{project.description ?? "-"}</p>

As per coding guidelines: "Prefer explicit null/undefinedness checks over boolean checks, eg. foo == null instead of !foo".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
at line 263, The rendering uses a boolean fallback that treats empty strings as
missing; change the fallback for project.description to an explicit nullish
check (e.g., use the null/undefined check on project.description or the nullish
coalescing behavior) so that an empty string remains displayed while only
null/undefined becomes "-"; update the JSX that references project.description
in page-client.tsx (the <p> that shows project.description) to use an explicit
check like project.description == null ? "-" : project.description or the
equivalent nullish-coalescing approach.

---

30-30: any types used without justification comments.

Three places use any without explaining why the type system can't express the correct type:

• Line 30: member: any
• Line 162: team: any
• Line 167: values: any

Per coding guidelines, when any is necessary, a comment should explain why. Ideally, type these properly (e.g., use the SDK's TeamMember/Team types and yup.InferType<typeof projectInformationSchema> for values).

As per coding guidelines: "Try to avoid the any type. When necessary, leave a comment explaining why you're using it and why the type system fails there".

Also applies to: 162-164, 167-169

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
at line 30, Replace the three uses of `any` with proper types or a short
justification comment: for the `TeamMemberItem` prop `member` use the SDK type
(e.g., `TeamMember`) instead of `any`; for the `team` variable use the SDK's
`Team` type; for the form `values` replace `any` with `yup.InferType<typeof
projectInformationSchema>` (or the explicit inferred type) — if a precise type
truly cannot be expressed, add a one-line comment next to each usage explaining
why `any` is required and reference the limitation (e.g., runtime shape,
third‑party SDK looseness) so the rationale is recorded.

---

303-321: Dark-mode logo callbacks are inline while light-mode equivalents are memoized.

handleLogoChange and handleFullLogoChange are wrapped in useCallback (lines 148–154), but the dark-mode variants at lines 306–308 and 316–318 use inline async lambdas. This is an inconsistency — either memoize all four or none.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
around lines 303 - 321, The dark-mode LogoUpload handlers are inline async
lambdas while the light-mode handlers use useCallback (handleLogoChange,
handleFullLogoChange); make the dark-mode handlers consistent by creating
memoized callbacks (e.g., handleLogoDarkChange and handleFullLogoDarkChange)
using useCallback that call project.update({ logoDarkModeUrl }) and
project.update({ logoFullDarkModeUrl }) respectively, and pass those memoized
functions to the LogoUpload onValueChange props so all four handlers are
implemented consistently.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx (2)

396-439: Column definitions are recreated on every render.

columns is defined inline in the render path and captures props.updateFn / props.onTestRequested via closures. Consider wrapping it in useMemo to avoid unnecessary re-renders of DesignDataTable.

Wrap in useMemo

Move the column definition before the early return and memoize it:

 function Endpoints(props: { updateFn: () => void, onTestRequested: (endpoint: Endpoint) => void }) {
   const endpoints = getSvixResult(useEndpoints({ limit: 100 }));
+
+  const columns: ColumnDef<Endpoint>[] = useMemo(() => [
+    // ...column defs unchanged...
+  ], [props.updateFn, props.onTestRequested]);

   if (!endpoints.loaded) {
     return endpoints.rendered;
-  } else {
-    const columns: ColumnDef<Endpoint>[] = [
-      // ...
-    ];
-    return ( ... );
-  }
+  }
+
+  return ( ... );
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx
around lines 396 - 439, The columns array (ColumnDef<Endpoint> assigned to
columns) is recreated on every render and closes over props.updateFn and
props.onTestRequested causing unnecessary re-renders of DesignDataTable; fix by
moving the columns definition above the early return and wrapping it in useMemo,
e.g. useMemo(() => [ ...columns... ], [props.updateFn, props.onTestRequested])
so ActionMenu receives stable updateFn/onTestEndpoint references and the table
won’t re-render unnecessarily.

---

344-350: Prefer explicit null check for errorMessage.

Line 344 uses a truthy check on errorMessage (a string | null). Per project guidelines, prefer explicit null/undefinedness checks.

-        {status === 'error' && errorMessage && (
+        {status === 'error' && errorMessage != null && (

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx
around lines 344 - 350, The conditional rendering uses a truthy check for the
variable errorMessage; change it to an explicit null/undefined check (e.g.,
errorMessage != null) so the condition only triggers when errorMessage is not
null/undefined; update the JSX around the status, errorMessage, and DesignAlert
usage in the page-client component to use the explicit check.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx (2)

463-468: Inline empty-array literals ([]) create new references each render.

defaultColumnFilters={[]} and defaultSorting={[]} produce fresh arrays every render. If DesignDataTable uses these in dependency arrays or passes them to useReactTable options, this can trigger unnecessary re-computations. Hoist them to module-level constants.

Suggested fix

At the module level (e.g. near the type definition):

const EMPTY_COLUMN_FILTERS: never[] = [];
const EMPTY_SORTING: never[] = [];

Then reference them:

-        defaultColumnFilters={[]}
-        defaultSorting={[]}
+        defaultColumnFilters={EMPTY_COLUMN_FILTERS}
+        defaultSorting={EMPTY_SORTING}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx
around lines 463 - 468, The inline empty-array literals passed to
DesignDataTable as defaultColumnFilters and defaultSorting create new references
each render and can cause unnecessary recomputations; fix by hoisting them to
module-level constants (e.g., EMPTY_COLUMN_FILTERS and EMPTY_SORTING) and then
passing those constants to the DesignDataTable props defaultColumnFilters and
defaultSorting instead of [] so the same reference is reused across renders.

---

398-447: Column definitions and row data are re-created on every render — consider memoizing.

columns and endpointRows are both defined inline in the else branch without useMemo, so they produce new references on each render. This can cause DesignDataTable (and its internal useReactTable) to reset or re-render unnecessarily.

Additionally, Line 445 (description: endpoint.description) is redundant after the ...endpoint spread.

Suggested refactor

Move the column/row definitions above the conditional, wrapping them with useMemo:

 function Endpoints(props: { updateFn: () => void, onTestRequested: (endpoint: Endpoint) => void }) {
   const endpoints = getSvixResult(useEndpoints({ limit: 100 }));
 
+  const columns: ColumnDef<Endpoint>[] = useMemo(() => [
+    {
+      accessorKey: "url",
+      header: "Endpoint URL",
+      cell: ({ row }) => (
+        <span className="text-sm font-medium text-foreground">{row.original.url}</span>
+      ),
+    },
+    {
+      accessorKey: "description",
+      header: "Description",
+      cell: ({ row }) => (
+        row.original.description ? (
+          <span className="text-sm text-foreground/80">{row.original.description}</span>
+        ) : (
+          <span className="text-sm text-muted-foreground">-</span>
+        )
+      ),
+    },
+    {
+      id: "status",
+      header: "Status",
+      cell: ({ row }) => (
+        <DesignBadge
+          label={row.original.disabled ? "Disabled" : "Active"}
+          color={row.original.disabled ? "red" : "green"}
+          size="sm"
+        />
+      ),
+    },
+    {
+      id: "actions",
+      header: "",
+      cell: ({ row }) => (
+        <div className="flex justify-end">
+          <ActionMenu
+            endpoint={row.original}
+            updateFn={props.updateFn}
+            onTestEndpoint={props.onTestRequested}
+          />
+        </div>
+      ),
+    },
+  ], [props.updateFn, props.onTestRequested]);
+
+  const endpointRows: Endpoint[] = useMemo(() =>
+    endpoints.loaded
+      ? endpoints.data.map((endpoint) => ({
+          ...endpoint,
+          disabled: endpoint.disabled ?? false,
+        }))
+      : [],
+    [endpoints.loaded, endpoints.data]
+  );
+
   if (!endpoints.loaded) {
     return endpoints.rendered;
-  } else {
-    const columns: ColumnDef<Endpoint>[] = [ ... ];
-    const endpointRows: Endpoint[] = endpoints.data.map((endpoint) => ({
-      ...endpoint,
-      description: endpoint.description,
-      disabled: endpoint.disabled ?? false,
-    }));
-    return ( ... );
+  }
+
+  return (
+    <DesignCard ...>
+      <DesignDataTable
+        data={endpointRows}
+        columns={columns}
+        defaultColumnFilters={[]}
+        defaultSorting={[]}
+      />
+    </DesignCard>
+  );
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/webhooks/page-client.tsx
around lines 398 - 447, The columns and endpointRows are recreated on every
render which causes unnecessary re-renders of DesignDataTable/useReactTable;
wrap the columns array and the endpointRows mapping in React.useMemo to memoize
them (e.g., const columns = useMemo(() => [...], [props.updateFn,
props.onTestRequested]) and const endpointRows = useMemo(() =>
endpoints.data.map(e => ({ ...e, disabled: e.disabled ?? false })),
[endpoints.data]) ), remove the redundant description: endpoint.description
after the spread, and ensure dependencies include any props or values referenced
by the memoized callbacks (like props.updateFn, props.onTestRequested and
endpoints.data).

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx (4)

171-174: || used instead of explicit nullish check for description.

project.description || undefined treats empty strings as falsy and converts them to undefined. If this is intentional (empty string = no description), a comment would help clarify the intent. Otherwise, project.description ?? undefined is the guideline-preferred pattern.

As per coding guidelines, "Prefer explicit null/undefinedness checks over boolean checks, eg. foo == null instead of !foo."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
around lines 171 - 174, The use of a boolean-falsy fallback incorrectly converts
empty strings to undefined in projectDetailsDefaultValues; update the expression
to use a nullish check so only null/undefined become undefined (replace
project.description || undefined with a nullish pattern such as
project.description ?? undefined), or if empty-string-to-undefined is
intentional, add a clarifying comment next to projectDetailsDefaultValues
explaining that empty strings should be treated as missing descriptions.

---

309-327: Dark-mode logo callbacks are inline while their light-mode counterparts are memoized.

handleLogoChange and handleFullLogoChange (lines 148-154) are extracted as useCallback memos, but the dark-mode variants on lines 312-314 and 322-324 are defined inline. This inconsistency means the dark-mode LogoUpload components receive a new function reference every render. Consider extracting them for consistency.

♻️ Extract memoized callbacks

+  const handleLogoDarkModeChange = useCallback(async (logoDarkModeUrl: string | null) => {
+    await project.update({ logoDarkModeUrl });
+  }, [project]);
+
+  const handleLogoFullDarkModeChange = useCallback(async (logoFullDarkModeUrl: string | null) => {
+    await project.update({ logoFullDarkModeUrl });
+  }, [project]);

Then use onValueChange={handleLogoDarkModeChange} and onValueChange={handleLogoFullDarkModeChange} in the JSX.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
around lines 309 - 327, The dark-mode LogoUpload callbacks are defined inline
causing new function refs each render; extract them as memoized callbacks like
the existing handleLogoChange and handleFullLogoChange by creating useCallback
hooks (e.g., handleLogoDarkModeChange and handleLogoFullDarkModeChange) that
call project.update({ logoDarkModeUrl }) and project.update({
logoFullDarkModeUrl }) respectively, then pass those handlers as onValueChange
to the dark-mode LogoUpload components so the props remain stable across
renders.

---

88-101: URL construction uses raw string interpolation — guideline requires encodeURIComponent or urlString.

project.id is interpolated directly into the URL template. While project IDs are likely safe identifiers, the coding guideline explicitly requires using urlString tagged templates or encodeURIComponent() for URL construction.

♻️ Suggested fix

   const jwksUrl = useMemo(
-    () => `${baseApiUrl}/api/v1/projects/${project.id}/.well-known/jwks.json`,
+    () => `${baseApiUrl}/api/v1/projects/${encodeURIComponent(project.id)}/.well-known/jwks.json`,
     [baseApiUrl, project.id]
   );

Or use urlString if it's available in the project.

As per coding guidelines, "Use urlString`` or encodeURIComponent() instead of normal string interpolation for URLs".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
around lines 88 - 101, The three URL builders jwksUrl, restrictedJwksUrl and
allJwksUrl currently interpolate project.id directly; update them to encode the
project id (or use the project's urlString tagged template if available) so
unsafe characters are escaped: replace `${project.id}` with an encoded value via
encodeURIComponent(project.id) or use urlString`...${project.id}...` and keep
the same dependency arrays ([baseApiUrl, project.id] and [jwksUrl]) so the
useMemo hooks still update correctly.

---

30-30: Multiple any types without explanatory comments.

• member: any (line 30)
• team: any (line 162)
• values: any (line 167)

Per guidelines, the any type should be avoided, and when necessary a comment should explain why. For values, yup.InferType<typeof projectInformationSchema> would be more precise and provide type safety on the project.update(values) call. For member and team, consider using the actual SDK types.

♻️ Example: type-safe submit handler

-  const handleProjectDetailsSubmit = useCallback(async (values: any) => {
+  const handleProjectDetailsSubmit = useCallback(async (values: yup.InferType<typeof projectInformationSchema>) => {
     await project.update(values);
   }, [project]);

As per coding guidelines, "Try to avoid the any type. When necessary, leave a comment explaining why you're using it and why the type system fails there."

Also applies to: 162-163, 167-168

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/project-settings/page-client.tsx
at line 30, The code uses several any types (member in TeamMemberItem, team, and
values) which reduces type safety; replace member and team with the correct SDK
types from your project/team SDK (e.g., TeamMember or User types) by updating
the TeamMemberItem prop signature and the team variable's type, and change
values to a precise type using yup.InferType<typeof projectInformationSchema> so
the call to project.update(values) is type-safe; if an SDK type is missing, add
a short comment explaining why any is used and reference the intended type.

apps/dashboard/src/components/smart-form.tsx (2)

39-52: Dependency array includes props — callback recreated every render.

props as a whole is a new object reference every render, so including it in the useCallback deps makes the memoization effectively useless. Consider destructuring the specific props used (props.onChangeIsSubmitting, props.onSubmit) and listing them individually.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/smart-form.tsx` around lines 39 - 52,
handleSubmit is being recreated each render because the entire props object is
in the useCallback dependency array; instead, destructure the specific callbacks
you use (onChangeIsSubmitting and onSubmit) from props and reference those
individual variables in the dependency list along with form and
resolvedDefaultValues. Update the component to pull const {
onChangeIsSubmitting, onSubmit } = props (or function params) and replace
props.onChangeIsSubmitting/props.onSubmit calls inside handleSubmit, then change
the useCallback deps to [onChangeIsSubmitting, onSubmit, form,
resolvedDefaultValues] to restore proper memoization.

---

54-61: resolvedDefaultValues is a new object reference every render, causing the effect to fire unnecessarily.

resolvedDefaultValues (line 32) is recomputed as a new object each render, so listing it in the dependency array means this effect runs every render. The guard condition (currentOpen && !prevOpen.current) prevents spurious resets, so this is not a correctness bug, but it's wasteful. Memoizing or stabilizing the defaults would make the intent clearer.

♻️ Suggested stabilization

Wrap resolvedDefaultValues in useMemo so the effect (and handleSubmit callback) only re-run when the values actually change:

-  const resolvedDefaultValues = props.defaultValues ?? props.formSchema.getDefault();
+  const resolvedDefaultValues = useMemo(
+    () => props.defaultValues ?? props.formSchema.getDefault(),
+    [props.defaultValues, props.formSchema]
+  );

Note: this still won't deep-stabilize if props.defaultValues is a new object with the same content each render (the caller should memoize). But it avoids the unconditional recompute of getDefault() and signals intent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/src/components/smart-form.tsx` around lines 54 - 61, The
effect depends on resolvedDefaultValues which is recomputed each render;
stabilize it by wrapping the resolvedDefaultValues computation (the variable
assigned at line 32) in useMemo so it only changes when its true inputs change
(e.g., props.defaultValues or getDefault inputs), and then keep that memoized
resolvedDefaultValues in the useEffect dependency array that calls form.reset;
also ensure the handleSubmit callback (which uses resolvedDefaultValues) uses
the memoized value so both the effect and callback only re-run when the actual
defaults change.