Page is a server component, but TransferConfirmMissingCodeView is imported from a "use client" module (and uses DesignAlert, which is also client-only). This makes the “missing code” error path require client JS/hydration even though it’s a static message. Consider rendering a server-safe fallback here (inline markup), or moving the missing-code view into a non-client module so it can be server-rendered.

This module is now hard-coded to the custom integration endpoints, but the component name remains generic (IntegrationProjectTransferConfirmPageClient). Renaming it to something custom-specific (and matching file name) would reduce confusion and prevent accidental reuse for other integrations.

signedInAsLabel is optional but defaults to a placeholder email ("Signed in as preview@example.com"). Even if current callers always pass a real label, this is a footgun in the component API and could easily surface incorrect account info if a future caller omits it. Consider removing the placeholder default and either (a) requiring signedInAsLabel when signedIn is true, or (b) defaulting to a non-misleading generic label.

HTML entity ' in JSX attribute renders literally

JSX string attributes do not process HTML entities — ' will appear as the literal text we'll in the rendered output rather than we'll. Use a JSX expression with a real apostrophe instead.

This is a comment left during a code review.
Path: apps/dashboard/src/components/project-transfer-confirm-view.tsx
Line: 89-95

Comment:
**HTML entity `'` in JSX attribute renders literally**

JSX string attributes do not process HTML entities — `'` will appear as the literal text `we'll` in the rendered output rather than `we'll`. Use a JSX expression with a real apostrophe instead.

```suggestion
              <DesignAlert
                variant="info"
                title="Sign in to continue"
                description={"Transferring a project requires an active Stack Auth account. You can sign in or create one on the next step; we'll bring you back here automatically."}
                glassmorphic
              />
```

How can I resolve this? If you propose a fix, please make it concise.

Async handlers missing runAsynchronouslyWithAlert

All three button onClick handlers (onSwitchAccount, onCancel, onPrimary) are async but just await callback?.() with no error boundary. If any callback rejects — for example onPrimary making a sendRequest call that throws — the error is silently swallowed and the user sees nothing. Per the project convention, async handlers should be wrapped with runAsynchronouslyWithAlert so errors are surfaced automatically.

Rule Used: Use runAsynchronouslyWithAlert from `@stackframe... (source)

Learnt From
stack-auth/stack-auth#943

This is a comment left during a code review.
Path: apps/dashboard/src/components/project-transfer-confirm-view.tsx
Line: 78-86

Comment:
**Async handlers missing `runAsynchronouslyWithAlert`**

All three button `onClick` handlers (`onSwitchAccount`, `onCancel`, `onPrimary`) are async but just `await callback?.()` with no error boundary. If any callback rejects — for example `onPrimary` making a `sendRequest` call that throws — the error is silently swallowed and the user sees nothing. Per the project convention, async handlers should be wrapped with `runAsynchronouslyWithAlert` so errors are surfaced automatically.

```suggestion
                <DesignButton
                  variant="outline"
                  className="w-full sm:w-auto transition-colors duration-150 hover:transition-none"
                  onClick={() => {
                    runAsynchronouslyWithAlert(async () => {
                      await onSwitchAccount?.();
                    });
                  }}
                >
```

**Rule Used:** Use `runAsynchronouslyWithAlert` from `@stackframe... ([source](https://app.greptile.com/review/custom-context?memory=5e671275-7493-402a-93a8-969537ec4d63))

**Learnt From**
[stack-auth/stack-auth#943](https://github.com/stack-auth/stack-auth/pull/943)

How can I resolve this? If you propose a fix, please make it concise.

Async onClick not wrapped in runAsynchronouslyWithAlert

The "Transfer / Sign in" button's onClick is async and calls sendRequest without any try/catch or runAsynchronouslyWithAlert. If the API call rejects, the error is silently lost and the user gets no feedback. Use runAsynchronouslyWithAlert to automatically surface errors.

Rule Used: Use runAsynchronouslyWithAlert from `@stackframe... (source)

Learnt From
stack-auth/stack-auth#943

This is a comment left during a code review.
Path: apps/dashboard/src/app/(main)/integrations/neon-transfer-confirm-page.tsx
Line: 126-144

Comment:
**Async `onClick` not wrapped in `runAsynchronouslyWithAlert`**

The "Transfer / Sign in" button's `onClick` is async and calls `sendRequest` without any try/catch or `runAsynchronouslyWithAlert`. If the API call rejects, the error is silently lost and the user gets no feedback. Use `runAsynchronouslyWithAlert` to automatically surface errors.

**Rule Used:** Use `runAsynchronouslyWithAlert` from `@stackframe... ([source](https://app.greptile.com/review/custom-context?memory=5e671275-7493-402a-93a8-969537ec4d63))

**Learnt From**
[stack-auth/stack-auth#943](https://github.com/stack-auth/stack-auth/pull/943)

How can I resolve this? If you propose a fix, please make it concise.

⚠️ Potential issue | 🟠 Major

find . -type f -name "neon-transfer-confirm-page.tsx" 2>/dev/null

cat -n apps/dashboard/src/app/\(main\)/integrations/neon-transfer-confirm-page.tsx

Validate error and response objects before accessing properties.

Line 40-41 uses err.message without validating the caught error has this property, causing empty error messages if the contract changes. Lines 137-138 access confirmResJson.project_id without validating it exists, silently navigating to /projects/undefined if the response is missing this field.

The any type casts at lines 30, 40, and 128 also lack explanatory comments required by the coding guidelines. Per guidelines, "Fail early, fail loud" — validate these values and throw explicit errors if assumptions are violated instead of silently using fallback values.

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

In `@apps/dashboard/src/app/`(main)/integrations/neon-transfer-confirm-page.tsx
around lines 29 - 41, The catch block and response handling need explicit
validation: when catching errors from (app as
any)[stackAppInternalsSymbol].sendRequest, check if err is an Error (e.g., err
instanceof Error) and use err.message, otherwise use String(err) or throw a new
Error("Unexpected error from sendRequest"); similarly, after parsing the confirm
response (confirmResJson), validate that confirmResJson and
confirmResJson.project_id exist and are of the expected type before calling
navigate(`/projects/${confirmResJson.project_id}`) — if missing, throw a clear
Error("Missing project_id in confirm response") and setState({type: "error",
message: ...}) so we fail loud; finally, remove or justify the any casts (app as
any and catch err: any) by either adding a brief explanatory comment per
guidelines or converting to proper types so casts are not needed (referencing
stackAppInternalsSymbol, sendRequest, setState, and confirmResJson.project_id).

⚠️ Potential issue | 🔴 Critical

# First, let's look at the file structure and content
wc -l apps/dashboard/src/app/\(main\)/integrations/neon-transfer-confirm-page.tsx

# Read the file with line numbers to see the context
cat -n apps/dashboard/src/app/\(main\)/integrations/neon-transfer-confirm-page.tsx

Move the signup URL construction out of render.

Line 46 reads window.location while rendering. In Next.js, even with the "use client" directive, the component can still participate in the initial server render before hydration, causing a window is not defined error. The signUpUrl is only used in event handlers (lines 103 and 141), so build it lazily inside those handlers or within a useEffect instead.

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

In `@apps/dashboard/src/app/`(main)/integrations/neon-transfer-confirm-page.tsx
around lines 46 - 49, The code builds signUpUrl during render using
window.location (currentUrl, signUpSearchParams, signUpUrl), which can cause
"window is not defined" on server render; move that construction out of the
render path by either 1) creating a small helper function buildSignUpUrl() that
reads window.location and returns the `/handler/signup?...` string and call it
inside the click handlers that currently use signUpUrl (the handlers referenced
around where signUpUrl is used), or 2) compute and store signUpUrl in a
useEffect into state (useState + useEffect) so it runs only on the client; then
remove the top-level construction of currentUrl/signUpSearchParams/signUpUrl
from the component body. Ensure the handlers use the new helper or state value.

⚠️ Potential issue | 🔴 Critical

cat -n apps/dashboard/src/app/\(main\)/integrations/transfer-confirm-page.tsx

Window access at render time causes SSR crash risk.

Line 53 reads window.location.href during render, and the computed signUpUrl is captured in the onPrimary and onSwitchAccount callbacks (lines 86, 94). Despite the "use client" directive, Next.js may include this component in initial server renders, causing "window is not defined" errors. Move the currentUrl and signUpUrl computation into a useEffect that runs only on the client, or use a ref to defer access until after hydration.

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

In `@apps/dashboard/src/app/`(main)/integrations/transfer-confirm-page.tsx around
lines 71 - 95, The code reads window.location.href at render and captures
signUpUrl for the onPrimary and onSwitchAccount callbacks, which risks SSR
crashes; move the currentUrl/signUpUrl computation out of render and into a
client-only effect or ref: create a state/ref (e.g., signUpUrlRef or signUpUrl
state) and set it inside a useEffect that runs on mount, or compute signUpUrl
inside the onPrimary/onSwitchAccount handlers themselves before using it; update
references inside onPrimary and onSwitchAccount (and any usage of currentUrl) to
use the ref/state or freshly computed value so no window access happens during
server render.

⚠️ Potential issue | 🟡 Minor

cd /tmp && find . -type f -name "project-transfer-confirm-view.tsx" 2>/dev/null | head -5

fd "project-transfer-confirm-view.tsx"

cat -n apps/dashboard/src/components/project-transfer-confirm-view.tsx

rg "ProjectTransferConfirmView" --type ts --type tsx

rg "ProjectTransferConfirmView" -A 3

cat -n apps/dashboard/src/app/\(main\)/integrations/transfer-confirm-page.tsx

Make the success-state props fail loud instead of silently defaulting them.

The "Signed in as preview@example.com" fallback and optional handlers allow the success UI to render with dead buttons or fake labels when callers forget to wire handlers. While the current call site at transfer-confirm-page.tsx provides all required props, the component should validate its contract at entry to catch wiring errors early.

When state === "success", require:

• onCancel and onPrimary always
• signedInAsLabel and onSwitchAccount when signedIn === true

Remove the "Signed in as preview@example.com" fallback and add validation checks like:

if (state === "success" && onCancel == null) {
  throw new Error("ProjectTransferConfirmView requires `onCancel` in the success state");
}

This follows the coding guidelines: "NEVER silently use fallback values when type errors occur" and "Fail early, fail loud."

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

In `@apps/dashboard/src/components/project-transfer-confirm-view.tsx` around lines
13 - 21, When rendering ProjectTransferConfirmView, enforce its success-state
contract by removing the fallback "Signed in as preview@example.com" label and
adding runtime validations in the component (e.g., at the start of
ProjectTransferConfirmView render): if state === "success" ensure onCancel and
onPrimary are non-null and throw descriptive Errors if missing; additionally if
state === "success" && signedIn === true ensure signedInAsLabel and
onSwitchAccount are non-null and throw Errors if missing. Make these checks
reference the props by name (state, signedIn, signedInAsLabel, onCancel,
onPrimary, onSwitchAccount) so callers fail loud instead of rendering disabled
buttons or fake labels.