• pnpm-lock.yaml: Language not supported

packages/template/src/dev-tool/iframe-tab.tsx (1)

73-80: onError is unreliable for detecting iframe load failures.

Many iframe loading failures (CSP blocks, X-Frame-Options denials, network issues) don't fire onError. The iframe may display blank content without triggering the error state. Consider adding a timeout fallback or documenting this limitation.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/iframe-tab.tsx` around lines 73 - 80, The
iframe's onError is unreliable; add a timeout fallback that starts whenever src
changes (store an iframe ref like iframeRef) and clears on handleLoad and
handleError; if the timeout elapses (e.g., 5–10s) check the iframeRef.current
(try accessing contentDocument/contentWindow safely) and if it's empty or
cross-origin-inaccessible treat it as a load failure and set the same error
state used by handleError/loading, and also document this limitation in comments
next to the iframe, referencing the iframe element, handleLoad, handleError,
loading, src and title so future readers know why the timer exists.

examples/docs-examples/src/app/team/[teamId]/page.tsx (1)

16-21: Use encodeURIComponent() for URL path segment.

The defensive null check is appropriate given the underlying type-safety gap in TeamSwitcher. However, the URL construction should use proper encoding for consistency with coding guidelines.

♻️ Suggested fix

         urlMap={(t) => {
           if (t == null) {
             throw new Error("SelectedTeamSwitcher urlMap expected a non-null team");
           }
-          return `/team/${t.id}`;
+          return `/team/${encodeURIComponent(t.id)}`;
         }}

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

🤖 Prompt for AI Agents

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

In `@examples/docs-examples/src/app/team/`[teamId]/page.tsx around lines 16 - 21,
The urlMap function constructs a raw path using string interpolation; update url
creation in the urlMap arrow function to encode the team id (use
encodeURIComponent(t.id) or the project's urlString helper) while keeping the
existing null-check that throws if t is null—change the return for urlMap to
produce an encoded path like /team/<encoded-id> so ids with unsafe characters
are properly escaped.

docs/src/components/stack-auth/stack-team-switcher.tsx (1)

235-235: Code example doesn't match actual implementation.

The generateCodeExample() at line 125 shows (team: { id: string }) => ... without null handling, but the actual implementation here accepts { id: string } | null. Users copying the code example won't get the defensive null check.

Additionally, consider using encodeURIComponent(team.id) for URL consistency.

♻️ Suggested fixes

1. Update the code example generator (around line 125) to match:

     if (props.urlMap) {
-      propsArray.push('urlMap={(team: { id: string }) => `/teams/${team.id}/dashboard`}');
+      propsArray.push('urlMap={(team: { id: string } | null) => team ? `/teams/${team.id}/dashboard` : `/`}');
     }

2. Encode the URL path:

-                urlMap={props.urlMap ? (team: { id: string } | null) => team ? `/teams/${team.id}/dashboard` : '/' : undefined}
+                urlMap={props.urlMap ? (team: { id: string } | null) => team ? `/teams/${encodeURIComponent(team.id)}/dashboard` : '/' : undefined}

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 `@docs/src/components/stack-auth/stack-team-switcher.tsx` at line 235, The code
example produced by generateCodeExample() must match the actual urlMap prop
signature used in stack-team-switcher.tsx: update generateCodeExample() to show
the parameter as (team: { id: string } | null) => team ?
`/teams/${encodeURIComponent(team.id)}/dashboard` : '/' (or equivalent using
urlString/encodeURIComponent) so the example includes the null defensive check
and encodes team.id; search for generateCodeExample and the urlMap prop to apply
the change and replace plain string interpolation of team.id with
encodeURIComponent(team.id) (or the project urlString helper) for URL safety.

packages/template/src/dev-tool/dev-tool-indicator.tsx (1)

65-70: Use a monotonic clock for duration.

These timings are currently derived from Date.now(), so a system clock adjustment can make the dev-tool latency jump or even go negative. Keep the wall-clock timestamp, but measure elapsed time with performance.now().

As per coding guidelines, don't use Date.now() for measuring elapsed (real) time, instead use performance.now().

Also applies to: 111-117

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-indicator.tsx` around lines 65 - 70,
The code currently uses Date.now() (startTime) to compute request duration in
the fetch wrapper (around the fetch call that uses originalFetch), which is
susceptible to system clock changes; change it to record a monotonic start via
performance.now() (e.g., startMonotonic = performance.now()) and compute
duration as performance.now() - startMonotonic while keeping the wall-clock
timestamp from Date.now() if you still need a timestamp; update the other
analogous occurrence that computes elapsed time elsewhere in this file (the
second startTime/duration pair) the same way to use performance.now() for
elapsed measurements.

packages/template/src/dev-tool/component-catalog.tsx (1)

31-33: Explain the any escape hatch here or narrow it.

CatalogEntry is exported, so React.ComponentType<any> becomes the registry contract for every previewed component. If heterogeneous props make any unavoidable, please add the required inline note about why it's safe and where prop misuse is still caught.

As per coding guidelines, try to avoid the any type; whenever you need it, leave a comment explaining why you're using it and how you can be certain that errors would still be flagged.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/component-catalog.tsx` around lines 31 - 33,
The exported type CatalogEntry currently uses React.ComponentType<any>, which
leaks an any into the public registry contract; either make CatalogEntry generic
(e.g., CatalogEntry<P = unknown> with component: React.ComponentType<P>) or
switch to React.ComponentType<unknown> to avoid any, and update callers to
provide the concrete prop type, or if heterogeneous props truly make any
unavoidable add a concise inline comment on the CatalogEntry.type explaining why
any is required, where runtime/compile-time prop validation still occurs (e.g.,
preview wrappers or story files), and add a TODO to tighten the type when
components share a common prop shape; refer to the exported symbol CatalogEntry
and its component field when making the change.

packages/template/src/dev-tool/tabs/overview-tab.tsx (2)

131-131: Prefer explicit null check over non-null assertion.

Per coding guidelines, prefer ?? throwErr(...) over non-null assertions. Although user is checked in the JSX conditional, the async function scope doesn't carry that narrowing.

Suggested fix

-      await user!.signOut();
+      if (user == null) {
+        throw new Error('Cannot sign out: no user is signed in');
+      }
+      await user.signOut();

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` at line 131, The
non-null assertion on user in the async call await user!.signOut() should be
replaced with an explicit null-check that throws if user is missing; update the
sign-out call in the same scope (the function that calls user.signOut) to use
the null-coalescing pattern (user ?? throwErr("user is undefined when attempting
signOut")) before invoking signOut, or otherwise guard with an if and throw so
the function no longer relies on the non-null assertion operator.

---

89-91: Avoid catch (e: any) pattern.

The coding guidelines prohibit using any. For error handling, consider using a type guard or utility to safely extract the error message.

Suggested approach

-    } catch (e: any) {
-      setStatus({ type: 'error', message: e.message || 'Unknown error' });
+    } catch (e) {
+      setStatus({ type: 'error', message: e instanceof Error ? e.message : 'Unknown error' });
     }

Apply the same pattern to the other catch blocks at lines 121-123 and 133-135.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 89 - 91,
Replace the unsafe "catch (e: any)" usages with "catch (err: unknown)" and use a
small type-guard/helper to extract a safe message before calling setStatus; for
example, add a getErrorMessage(err: unknown): string utility that checks for err
being an Error or having a message property and returns a string, then change
the three catch blocks that call setStatus to use getErrorMessage(err) when
creating the status ({ type: 'error', message: getErrorMessage(err) }); update
all occurrences (the catch currently using setStatus at the top and the two
other similar catch blocks) to use this helper.

packages/template/src/dev-tool/dev-tool-context.tsx (2)

130-132: Document the any cast on globalThis.

The coding guidelines require comments explaining any usage. This global attachment is for cross-module interop with the fetch interceptor.

Suggested fix

 // Expose globally so the fetch interceptor (which may be installed once) can
 // always reach the latest store even after HMR / remounts.
 if (typeof globalThis !== 'undefined') {
+  // Using `any` because globalThis doesn't have a typed slot for our store.
+  // This is safe as we control both the writer (here) and readers (dev-tool-indicator.tsx).
   (globalThis as any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore;
 }

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 130 - 132,
Add a short inline comment explaining the use of "any" on globalThis when
assigning __STACK_DEV_TOOL_LOG_STORE__ to globalLogStore: state that the cast is
intentional to attach a cross-module global used for the fetch
interceptor/cross-module interop, and that TypeScript typing is intentionally
bypassed here because globalThis has no typed property for this runtime-only
debugging store; keep the comment adjacent to the cast that sets (globalThis as
any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore and mention the related
symbol names (__STACK_DEV_TOOL_LOG_STORE__, globalLogStore, fetch interceptor)
so future readers know why the any is necessary.

---

72-74: Add comment explaining why errors are silently ignored.

Per coding guidelines, errors shouldn't be silently swallowed. For localStorage operations, silent failure is often acceptable (quota exceeded, private browsing, etc.), but the reasoning should be documented.

Suggested fix

   } catch {
-    // ignore
+    // localStorage may be unavailable (private browsing, quota exceeded, etc.)
+    // Failing silently is acceptable here as state persistence is non-critical
   }

Apply the same to the catch block at lines 83-85.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 72 - 74,
The empty catch blocks in dev-tool-context (around the localStorage access in
the code surrounding the anonymous catch { // ignore }) silently swallow errors;
update both catch blocks (the one shown and the similar one later) to include a
brief comment explaining why errors are intentionally ignored (e.g.,
localStorage may be unavailable in private mode or exceed quota, so failures are
non-fatal for dev UX) and keep no-op behavior; ensure the comment references the
localStorage/read or write operation performed (so future maintainers know the
rationale) and leave behavior unchanged.

packages/template/src/dev-tool/tabs/console-tab.tsx (1)

161-162: Avoid any in map callback.

The any type in (p: any) => p.id can be replaced with a more specific type or type assertion that documents the expected shape.

Suggested fix

     if (key === 'oauthProviders' && Array.isArray(value)) {
-      lines.push(`${key}: ${value.map((p: any) => p.id).join(', ') || 'None'}`);
+      lines.push(`${key}: ${value.map((p: { id: string }) => p.id).join(', ') || 'None'}`);
     } else {

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/console-tab.tsx` around lines 161 - 162,
The map callback uses an unsafe any: replace (p: any) => p.id with a typed shape
or assertion for the expected provider object (e.g., define or use an
OAuthProvider type/interface with an id property and cast value to
OAuthProvider[] before mapping, or change the callback to (p: OAuthProvider) =>
p.id) so the compiler knows the structure when mapping in the oauthProviders
branch (the check key === 'oauthProviders' and the value.map call should use the
new typed shape).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/template/src/dev-tool/tabs/overview-tab.tsx (3)

125-126: Potential issue with empty string segments in initials computation.

If displayName contains consecutive spaces or leading/trailing spaces, split(' ') may produce empty string elements. Accessing s[0] on an empty string returns undefined, which becomes an empty string when joined—functionally harmless but could be cleaner.

✨ Suggested improvement

   const initials = user
-    ? (user.displayName || user.primaryEmail || '?').split(' ').map((s: string) => s[0]).join('').slice(0, 2).toUpperCase()
+    ? (user.displayName || user.primaryEmail || '?').split(' ').filter(Boolean).map((s) => s[0]).join('').slice(0, 2).toUpperCase()
     : '?';

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 125 - 126,
The initials computation can produce empty segments when displayName has extra
spaces; update the expression that builds initials (the ternary using
user.displayName / user.primaryEmail) to trim the source string and split on
one-or-more whitespace (or filter out empty strings) before mapping to s[0],
e.g., call .trim() and .split(/\s+/) or add .split(' ').filter(Boolean) so the
map over s[0] never sees empty strings and then slice/uppercase as before.

---

116-116: Avoid non-null assertion; add defensive null check.

The coding guidelines prefer ?? throwErr(...) over non-null assertions. Although the button is only rendered when user is truthy, a race condition could occur between render and click if the user signs out elsewhere. Add a defensive check.

🛡️ Proposed fix

   const handleSignOut = async () => {
     setLoading(true);
     setStatus(null);
     try {
+      if (!user) {
+        setStatus({ type: 'error', message: 'No user to sign out' });
+        setLoading(false);
+        return;
+      }
       await user.signOut();
       setStatus({ type: 'success', message: 'Signed out' });
-    } catch (e: any) {
-      setStatus({ type: 'error', message: e.message || 'Sign out failed' });
+    } catch (e: unknown) {
+      setStatus({ type: 'error', message: e instanceof Error ? e.message : 'Sign out failed' });
     }
     setLoading(false);
   };

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` at line 116, Replace
the non-null assertion on the sign-out call to a defensive check: instead of
using await user!.signOut(), ensure user is present before calling signOut by
using a nullish-coalescing guard (e.g., user ?? throwErr('user is null on
signOut')) or an early-return/if-check, so the call to user.signOut() only
happens when user is defined; update the call site referencing user and signOut
(and use the existing throwErr helper if available) to avoid a potential
race-condition NPE.

---

70-72: Use unknown instead of any for caught errors.

Per coding guidelines, avoid using any without an explanatory comment. The caught error should be typed as unknown and checked properly before accessing .message.

♻️ Proposed fix

-    } catch (e: any) {
-      setStatus({ type: 'error', message: e.message || 'Unknown error' });
+    } catch (e: unknown) {
+      setStatus({ type: 'error', message: e instanceof Error ? e.message : 'Unknown error' });
     }

This same pattern applies to lines 106-108 and 118-120.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 70 - 72,
Replace the use of catch (e: any) with catch (error: unknown) in the try/catch
blocks inside overview-tab.tsx (the handlers that call setStatus), and before
reading a message validate the error: if error is an instance of Error use
error.message, otherwise coerce to a safe string (e.g., String(error) or a
fallback like 'Unknown error'); update all three occurrences (the catch near
setStatus for error state and the other two similar catch blocks referenced) so
you never access .message on an unknown-typed value.

packages/template/src/dev-tool/dev-tool-context.tsx (2)

128-132: Add comment explaining the any cast on globalThis.

Per coding guidelines, any usage should include a comment explaining why it's necessary. The global property is intentionally untyped to allow the fetch interceptor to reach the store across HMR boundaries.

📝 Proposed fix

 // Expose globally so the fetch interceptor (which may be installed once) can
 // always reach the latest store even after HMR / remounts.
 if (typeof globalThis !== 'undefined') {
+  // Using `any` because __STACK_DEV_TOOL_LOG_STORE__ is a dev-only global not part of the type system
   (globalThis as any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore;
 }

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 128 - 132,
Add an inline comment explaining the use of the any cast on globalThis where we
assign (globalThis as any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore; —
state that the cast is intentional because we are adding an ad-hoc global
property (__STACK_DEV_TOOL_LOG_STORE__) that cannot be typed safely across
module/HMR boundaries and we need an untyped global so the fetch interceptor can
access the latest globalLogStore across remounts/HMR; place the comment
immediately adjacent to the (globalThis as any) cast to satisfy the coding
guideline.

---

72-74: Consider adding a brief comment explaining why errors are silently ignored.

While silently ignoring localStorage errors is reasonable (private browsing mode, quota exceeded, security restrictions), a brief comment explaining the intent would improve maintainability per the "fail loud" principle—making it clear this is intentional fallback behavior, not accidental error swallowing.

📝 Suggested improvement

   } catch {
-    // ignore
+    // localStorage may be unavailable (private browsing, quota exceeded, etc.)
+    // Fall back to defaults gracefully
   }

Same applies to saveState at lines 83-85.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 72 - 74,
The catch blocks in loadState and saveState silently swallow errors—add a brief
explanatory comment inside each catch explaining this is intentional fallback
behavior (e.g., to handle private browsing, quota limits, or security
restrictions when accessing localStorage) so maintainers know errors are
expected and not accidentally ignored; update the catch in the loadState
function and the catch in saveState to include that comment and, optionally, a
TODO or link to docs if you want to revisit logging/telemetry later.

packages/template/src/dev-tool/tabs/console-tab.tsx (2)

160-166: Add type annotation to avoid any.

Per coding guidelines, avoid any without an explanatory comment. The OAuth provider type should be narrowed for safer iteration.

♻️ Proposed fix

   for (const [key, value] of Object.entries(projectConfig.config)) {
     if (key === 'oauthProviders' && Array.isArray(value)) {
-      lines.push(`${key}: ${value.map((p: any) => p.id).join(', ') || 'None'}`);
+      // OAuth providers are typed with an `id` field in the project config
+      lines.push(`${key}: ${(value as Array<{ id: string }>).map((p) => p.id).join(', ') || 'None'}`);
     } else {
       lines.push(`${key}: ${JSON.stringify(value)}`);
     }
   }

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/console-tab.tsx` around lines 160 - 166,
The loop over projectConfig.config uses (p: any) which violates the no-any rule;
change the oauthProviders branch to narrow the type (e.g., assert value as
Array<OAuthProvider> or define an OAuthProvider interface with id: string and
use (p: OAuthProvider)) and replace (p: any) with the concrete type; ensure the
type (OAuthProvider) is imported or defined near the top and add a brief
explanatory comment if a cast is necessary, keeping the rest of the iteration
logic the same (symbols: projectConfig.config, oauthProviders, and the mapping
callback).

---

169-174: Add comment explaining the any cast on window global.

Per coding guidelines, any usage of any should include a comment explaining why it's necessary and how you can be certain errors would still be flagged.

📝 Suggested improvement

   lines.push(`--- Environment ---`);
+  // __STACK_VERSION__ is injected at build time and not part of Window type
   lines.push(`SDK Version: ${typeof window !== 'undefined' ? (window as any).__STACK_VERSION__ || 'Unknown' : 'Unknown'}`);

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/console-tab.tsx` around lines 169 - 174,
Add an inline comment next to the (window as any).__STACK_VERSION__ cast
explaining why the any is necessary (this is a runtime-injected global not
present in our TypeScript defs), how we ensure type safety (e.g., we surface
errors by keeping the access narrow and checking existence at runtime, and
prefer adding a proper global declaration in a .d.ts to avoid any in future),
and reference the symbol __STACK_VERSION__ and the lines that push environment
info in console-tab.tsx so reviewers know where the justification lives;
optionally note the intended follow-up (add a global Window interface
augmentation) to remove the any in a subsequent change.

packages/template/src/dev-tool/tabs/support-tab.tsx (1)

55-55: Add justification for any cast or use proper typing.

Per coding guidelines, any usage requires a comment explaining why it's necessary and how errors would still be caught. Consider typing the internals symbol access or adding documentation.

-      const opts = (app as any)[stackAppInternalsSymbol]?.getConstructorOptions?.() ?? {};
+      // Using any because stackAppInternalsSymbol is an internal API not exposed in public types.
+      // Type errors are mitigated by optional chaining and nullish coalescing.
+      const opts = (app as any)[stackAppInternalsSymbol]?.getConstructorOptions?.() ?? {};

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/support-tab.tsx` at line 55, The cast to
any when accessing the internals ((app as
any)[stackAppInternalsSymbol]?.getConstructorOptions?.()) lacks justification;
replace it by declaring a proper interface for the internals (with
getConstructorOptions returning the appropriate options type) and assert app as
that interface before indexing, or add a short comment explaining why a
runtime-hidden symbol requires an escape hatch and how type-safety is still
preserved (e.g., validating the return shape). Update references to
stackAppInternalsSymbol and getConstructorOptions to use the new typed interface
so the any cast is removed or clearly documented.

apps/dashboard/src/components/feedback-form.tsx (1)

43-43: Consider typing the render props parameter.

The props: any bypasses type checking. Per coding guidelines, any should include a comment explaining the necessity.

-        stackFormFieldRender: (props: any) => (
+        // Props type comes from SmartForm's internal render system
+        stackFormFieldRender: (props: any) => (

🤖 Prompt for AI Agents

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

In `@apps/dashboard/src/components/feedback-form.tsx` at line 43, The inline
render prop parameter for stackFormFieldRender is currently typed as props: any
which bypasses type checking; update the parameter to a specific type (e.g., the
appropriate form-rendering prop interface used in your codebase like
StackFormFieldProps or React.ComponentProps<typeof SomeFieldComponent>) so
TypeScript can validate usage in stackFormFieldRender, and if a precise type is
not available immediately, replace any with unknown or a narrow union and add a
concise comment explaining why any is necessary and when a proper type will be
introduced; locate the arrow function assigned to stackFormFieldRender to make
this change.

packages/template/src/dev-tool/tabs/overview-tab.tsx (2)

70-72: Avoid any type for caught errors.

Per coding guidelines, avoid the any type. Use unknown and narrow appropriately, or access common error properties safely.

♻️ Suggested fix

-    } catch (e: any) {
-      setStatus({ type: 'error', message: e.message || 'Unknown error' });
+    } catch (e) {
+      setStatus({ type: 'error', message: e instanceof Error ? e.message : 'Unknown error' });
     }

Apply the same pattern at lines 106 and 118.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 70 - 72,
Replace the use of catch (e: any) with catch (e: unknown) and safely narrow the
error before reading message: inside the catch blocks in the component (the
handler that calls setStatus) check if e is an instance of Error and use
e.message, otherwise convert to a safe string (e.g., String(e) or 'Unknown
error'); apply this same change to the other two catch blocks referenced (the
ones at lines around 106 and 118) so all catches use unknown and proper
narrowing before calling setStatus({ type: 'error', message: ... }).

---

115-117: Avoid non-null assertion on user.

Per coding guidelines, prefer ?? throwErr(...) over non-null assertions. Although user is checked in the conditional rendering, explicit validation is safer.

♻️ Suggested fix

   const handleSignOut = async () => {
     setLoading(true);
     setStatus(null);
     try {
-      await user!.signOut();
+      if (!user) {
+        setStatus({ type: 'error', message: 'No user to sign out' });
+        setLoading(false);
+        return;
+      }
+      await user.signOut();
       setStatus({ type: 'success', message: 'Signed out' });

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 115 - 117,
Replace the non-null assertion on user when calling signOut with an explicit
guard using the project's throw helper (e.g., throwErr or a similar
runtime-guard) so the code reads like: resolve user via "user ?? throwErr('user
is required to sign out')" and then call user.signOut(); update the call site
referring to user!.signOut and any related setStatus logic accordingly so the
runtime will throw a clear error if user is null instead of relying on a
non-null assertion.

apps/backend/src/app/api/latest/internal/feedback/route.tsx (1)

49-56: Consider adding a timeout to the production fetch.

The fetch to production lacks a timeout, which could cause requests to hang indefinitely if the production endpoint is slow or unresponsive. For a dev-tool feedback endpoint this is low risk, but adding an AbortController with a reasonable timeout (e.g., 10s) would improve reliability.

♻️ Optional improvement

+    const controller = new AbortController();
+    const timeoutId = setTimeout(() => controller.abort(), 10000);
     const prodResponse = await fetch("https://api.stack-auth.com/api/latest/internal/feedback", {
       method: "POST",
       headers: { "content-type": "application/json", "accept-encoding": "identity" },
       body: JSON.stringify(body),
+      signal: controller.signal,
     });
+    clearTimeout(timeoutId);

🤖 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/feedback/route.tsx` around lines 49
- 56, The production fetch to
"https://api.stack-auth.com/api/latest/internal/feedback" (producing
prodResponse) needs an AbortController timeout to avoid hanging; create an
AbortController, start a timeout (e.g., 10_000 ms) that calls
controller.abort(), pass controller.signal into the fetch options, clear the
timeout after the fetch completes, and catch AbortError to throw an appropriate
StatusError (or map it to a 504) instead of letting the request hang; update the
fetch call in route.tsx to use this controller and ensure you only apply it to
the prod forwarding logic that sets prodResponse.

apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts (1)

90-109: Bug report test lacks email content verification.

The "send bug reports with correct label" test verifies the response but doesn't assert that the email subject contains "[Bug Report]" as expected from the backend changes. Consider adding assertions similar to the other tests.

💡 Suggested enhancement

   it("should send bug reports with correct label", async ({ expect }) => {
     const subject = "[Bug Report] bug@example.com";
+    const recipientMailbox = createMailbox("team@stack-auth.com");

     const response = await niceBackendFetch("/api/v1/internal/feedback", {
       // ...
     });

     expect(response).toMatchInlineSnapshot(`...`);
+
+    const emails = await waitForOutboxEmailWithStatus(subject, "sent");
+    expect(emails[0]?.to).toMatchObject({
+      type: "custom-emails",
+      emails: ["team@stack-auth.com"],
+    });
+
+    const messages = await recipientMailbox.waitForMessagesWithSubject(subject);
+    expect(messages).toHaveLength(1);
+    expect(messages[0]?.subject).toBe(subject);
   });

🤖 Prompt for AI Agents

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

In `@apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts` around
lines 90 - 109, The test "should send bug reports with correct label" currently
only asserts the HTTP response; update it to also verify the outgoing email
subject includes "[Bug Report]". After calling
niceBackendFetch("/api/v1/internal/feedback", ...), inspect the test mailer/mock
used elsewhere (e.g., the captured email or lastSentEmail used by other feedback
tests) and add an assertion that the email subject contains "[Bug Report]" (or
that the subject equals the expected string) so the test ensures the backend
applies the bug label to the email.

packages/template/src/dev-tool/dev-tool-styles.ts (1)

6-34: Factor the theme tokens before they drift.

Lines 6-34, 1999-2025, and 2633-2683 repeat the same light/dark variable sets in multiple places. Since this is already a .ts module, generating those blocks from one token definition would be safer than hand-maintaining parallel copies.

Also applies to: 1999-2025, 2633-2683

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-styles.ts` around lines 6 - 34, The
theme variable blocks repeated for .stack-devtool should be factored into a
single token definition in this module (e.g., export const devToolTokens or a
getDevToolTokens() object) and then used to generate the CSS variable blocks for
the dark and light variants instead of duplicating them; update the existing CSS
generation logic that emits the .stack-devtool blocks (the current repeated
variable list) to read from that single token source and replace the three
duplicated blocks currently present (the block shown here plus the other two
duplicates) so changes to a token propagate everywhere.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/template/src/dev-tool/tabs/support-tab.tsx (1)

31-41: ⚠️ Potential issue | 🟠 Major

Reapply each new support prefill.

FeedbackForm stays mounted after tab switches, so prefillApplied.current never resets. A later “report this issue” flow in the same session will keep the stale message/type instead of the new payload.

Proposed fix

-  const prefillApplied = useRef(false);
-
   // Apply prefill when it changes (e.g. navigating from share dialog)
   useEffect(() => {
-    if (prefill && !prefillApplied.current) {
+    if (prefill != null) {
       setFeedbackType(prefill.feedbackType);
       setMessage(prefill.message);
       setStatus("idle");
-      prefillApplied.current = true;
+      setErrorMessage("");
     }
   }, [prefill]);

Also drop useRef from Line 4 once this gate is removed.

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/support-tab.tsx` around lines 31 - 41,
The current guard using prefillApplied (prefillApplied = useRef(false)) prevents
applying a new prefill after tab switches; remove the ref and simplify the
useEffect so whenever prefill changes and is truthy you call
setFeedbackType(prefill.feedbackType), setMessage(prefill.message), and
setStatus("idle") (i.e., drop the prefillApplied.current check and the ref
declaration), ensuring new prefill payloads always overwrite the form state.

packages/template/src/dev-tool/dev-tool-styles.ts (2)

188-207: ⚠️ Potential issue | 🟠 Major

Restore a visible keyboard focus ring for the main tabs.

This rule removes the default outline, but there is no .sdt-tab:focus-visible replacement, so keyboard navigation across the top-level tabs is invisible.

Proposed fix

   .stack-devtool .sdt-tab {
     position: relative;
     z-index: 1;
     display: flex;
@@
     transition: color 0.15s ease;
     white-space: nowrap;
     outline: none;
   }
+
+  .stack-devtool .sdt-tab:focus-visible {
+    outline: 2px solid var(--sdt-accent);
+    outline-offset: 2px;
+  }

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-styles.ts` around lines 188 - 207,
The .stack-devtool .sdt-tab rule removes the default outline making keyboard
focus invisible; add a .sdt-tab:focus-visible rule that restores a visible focus
indicator (e.g., outline or box-shadow using your design tokens such as
--sdt-focus or --sdt-ring color), ensure it targets .stack-devtool
.sdt-tab:focus-visible and provides sufficient contrast and a clear shape
(rounded corners matching --sdt-radius) while keeping outline: none on the base
selector.

---

132-159: ⚠️ Potential issue | 🟠 Major

Respect prefers-reduced-motion across the dev-tool surface.

Panel enter/exit, tab fades, pulse/shimmer/spinner effects, share-overlay transitions, smooth scrolling, and thinking dots still run even when the user opts out of motion. Add a reduced-motion override that disables animation/transition and resets smooth scrolling.

Proposed fix

+  `@media` (prefers-reduced-motion: reduce) {
+    .stack-devtool,
+    .stack-devtool *,
+    .stack-devtool *::before,
+    .stack-devtool *::after {
+      animation: none !important;
+      transition: none !important;
+      scroll-behavior: auto !important;
+    }
+  }

Also applies to: 273-288, 591-604, 737-749, 1848-1854, 1981-1990, 2124-2130, 2285-2300

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-styles.ts` around lines 132 - 159,
Add a global reduced-motion override using `@media` (prefers-reduced-motion:
reduce) that targets the dev tool surface (.stack-devtool) and disables
animations/transitions and smooth scrolling: set animation: none !important;
transition: none !important; scroll-behavior: auto !important; and override key
animation-using classes such as sdt-panel-enter, sdt-panel-exit,
.sdt-panel-exiting plus UI elements like .sdt-tab, .sdt-pulse, .sdt-shimmer,
.sdt-spinner, .sdt-share-overlay, and .sdt-thinking-dots to ensure no
keyframe/animation runs when the user prefers reduced motion; place this rule
near the existing keyframes (e.g., alongside sdt-panel-enter and sdt-panel-exit)
so it covers the listed sections too.

packages/template/src/dev-tool/tabs/components-tab.tsx (1)

239-245: ⚠️ Potential issue | 🟠 Major

Don't leave version checks stuck in a silent loading state.

If this fetch rejects, latestVersions stays null, so every custom page with a version remains in "loading" forever and the UI never tells the user why version metadata disappeared. Surface an explicit error state here instead of .catch(() => {}).

Based on learnings, "When building frontend code, always carefully deal with loading and error states. Be very explicit with these and make sure errors are NEVER just silently swallowed."

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/tabs/components-tab.tsx` around lines 239 -
245, The fetch in useEffect (inside useEffect -> fetch(...).then(...).catch(()
=> {})) silently swallows errors leaving latestVersions null and pages stuck in
"loading"; update the catch to set a clear error/loading state instead of an
empty catch: call setVersions([]) or a new setVersionsError(true) (or both),
mark the stale guard as appropriate, and log the error (e.g.,
console.error(err)). Modify the promise chain around fetch(...) ->
.then((r)=>r.json()).then((data)=>{ if (!stale) setVersions(data.versions);
}).catch((err)=>{ if (!stale) { setVersions([]); /* or setVersionsError(true) */
} console.error('Failed fetching component versions', err); }) so the UI can
render a non-loading error/empty state rather than hang.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts (4)

132-140: Same fix needed for emails array assertion.

For consistency and fail-fast behavior, add expect(emails).toHaveLength(1) before accessing emails[0].to.

🤖 Prompt for AI Agents

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

In `@apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts` around
lines 132 - 140, Add a length assertion for the outbox emails before indexing
into emails[0]; specifically after calling waitForOutboxEmailWithStatus(subject,
"sent") and assigning to the emails variable, add expect(emails).toHaveLength(1)
so the subsequent access to emails[0]?.to is safe and fails fast—this mirrors
the existing messages length check that uses
recipientMailbox.waitForMessagesWithSubject(subject).

---

94-104: Same optional chaining pattern—add explicit assertion for emails length.

Apply the same fix as the authenticated test: assert emails has length 1 before accessing emails[0].to.

Proposed fix

     const emails = await waitForOutboxEmailWithStatus(subject, "sent");
+    expect(emails).toHaveLength(1);
-    expect(emails[0]?.to).toMatchObject({
+    expect(emails[0].to).toMatchObject({
       type: "custom-emails",
       emails: ["team@stack-auth.com"],
     });

     const messages = await recipientMailbox.waitForMessagesWithSubject(subject);
     expect(messages).toHaveLength(1);
-    expect(messages[0]?.body?.text).toContain("Dev Tool User");
-    expect(messages[0]?.body?.text).toContain("devtool-user@example.com");
-    expect(messages[0]?.body?.text).toContain("Unauthenticated feedback from the dev tool.");
+    expect(messages[0].body?.text).toContain("Dev Tool User");
+    expect(messages[0].body?.text).toContain("devtool-user@example.com");
+    expect(messages[0].body?.text).toContain("Unauthenticated feedback from the dev tool.");

🤖 Prompt for AI Agents

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

In `@apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts` around
lines 94 - 104, The test uses optional chaining on the emails array returned by
waitForOutboxEmailWithStatus without asserting its length; add an explicit
assertion that the emails array has length 1 before accessing emails[0].to
(i.e., after calling waitForOutboxEmailWithStatus(subject, "sent") assert
emails.length === 1), so subsequent lines referencing emails[0].to are safe;
keep the existing checks for recipientMailbox.waitForMessagesWithSubject and
message body unchanged.

---

53-65: Prefer explicit length/existence assertions before accessing array elements.

Using emails[0]?.to and messages[0]?.subject will produce confusing test failures (e.g., "expected undefined to match object") if the arrays are unexpectedly empty. Per coding guidelines, fail fast with clear error messages rather than relying on optional chaining that masks the root cause.

Proposed fix

     const emails = await waitForOutboxEmailWithStatus(subject, "sent");
+    expect(emails).toHaveLength(1);
-    expect(emails[0]?.to).toMatchObject({
+    expect(emails[0].to).toMatchObject({
       type: "custom-emails",
       emails: ["team@stack-auth.com"],
     });

     const messages = await recipientMailbox.waitForMessagesWithSubject(subject);
     expect(messages).toHaveLength(1);
-    expect(messages[0]?.subject).toBe(subject);
-    expect(messages[0]?.body?.text).toContain("Support Tester");
-    expect(messages[0]?.body?.text).toContain(senderEmail);
-    expect(messages[0]?.body?.text).toContain(signInResult.userId);
-    expect(messages[0]?.body?.text).toContain("Authenticated feedback from the dashboard.");
+    expect(messages[0].subject).toBe(subject);
+    expect(messages[0].body?.text).toContain("Support Tester");
+    expect(messages[0].body?.text).toContain(senderEmail);
+    expect(messages[0].body?.text).toContain(signInResult.userId);
+    expect(messages[0].body?.text).toContain("Authenticated feedback from the dashboard.");

As per coding guidelines: "NEVER silently use fallback values when type errors occur... Fail early, fail loud."

🤖 Prompt for AI Agents

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

In `@apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts` around
lines 53 - 65, The test currently indexes emails and messages with optional
chaining (emails[0]?.to, messages[0]?.subject) which can mask empty-array
failures; add explicit existence/length assertions before accessing elements:
assert the result of waitForOutboxEmailWithStatus(subject, "sent") (variable
emails) has the expected length (e.g., toHaveLength(1)) and that
recipientMailbox.waitForMessagesWithSubject(subject) (variable messages) has the
expected length, then replace optional-chained accesses with direct indexing
(emails[0].to, messages[0].subject/body) so failures are fast and clear; keep
the same subject, senderEmail and signInResult.userId checks.

---

5-22: Probe function sends a real email in local mode as a side effect.

When the backend is not in forwarding mode, this probe succeeds and sends an actual email to team@stack-auth.com with the message "mode detection probe". While this email won't interfere with other test assertions (different subject), it does add noise to the outbox.

Consider using a dedicated test mode detection mechanism or accepting this as intentional test infrastructure overhead.

🤖 Prompt for AI Agents

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

In `@apps/e2e/tests/backend/endpoints/api/v1/internal/feedback.test.ts` around
lines 5 - 22, The probe in isForwardingToProduction uses niceBackendFetch to
POST to "/api/v1/internal/feedback" which sends a real email when not
forwarding; change the probe to avoid side effects by calling a test-only path
or adding a probe marker (e.g., a query param or header) that the backend
recognizes and short-circuits email sending. Update isForwardingToProduction to
send the marker (using niceBackendFetch and cachedIsForwarding as-is) and update
the backend feedback handler to detect that marker and return the same
status/body without enqueuing/sending mail.

packages/template/src/dev-tool/dev-tool-indicator.tsx (1)

31-31: Add justification comments for any casts on window.fetch.

The casts to any for checking/setting __stackDevToolPatched violate the coding guideline requiring comments explaining why any is used.

♻️ Suggested fix

-    if ((window.fetch as any).__stackDevToolPatched) return;
+    // any: Adding a non-standard property to the native fetch function to track patching state.
+    // TypeScript doesn't allow extending the fetch type, and this is a controlled dev-tool-only marker.
+    if ((window.fetch as any).__stackDevToolPatched) return;

-    (window.fetch as any).__stackDevToolPatched = true;
+    // any: See comment above for __stackDevToolPatched explanation.
+    (window.fetch as any).__stackDevToolPatched = true;

Also applies to: 140-141

🤖 Prompt for AI Agents

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

In `@packages/template/src/dev-tool/dev-tool-indicator.tsx` at line 31, Add a
concise justification comment wherever window.fetch is cast to any for the
__stackDevToolPatched property (e.g., the check "if ((window.fetch as
any).__stackDevToolPatched) return;" and the assignment sites around lines
140-141 in dev-tool-indicator.tsx), explaining that the cast is necessary
because we're augmenting the global Fetch function at runtime with a nonstandard
property for a deliberate monkey-patch and TypeScript's DOM types do not include
that property; keep the comment short and factual (e.g., "casting to any because
we're adding a runtime-only property __stackDevToolPatched to window.fetch which
isn't in DOM types").