apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/new-project/page-client.tsx (2)

1161-1166: Inconsistent indentation in else block.

Line 1165 has extra indentation that makes the code structure unclear. Both statements are in the else block, but the indentation suggests otherwise.

🧹 Fix indentation

                 if (includePayments) {
                   await props.setStatus("payments_setup");
                 } else {
                   await props.setStatus("completed");
-                    props.onComplete();
+                  props.onComplete();
                 }

🤖 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)/new-project/page-client.tsx
around lines 1161 - 1166, The else block after the includePayments check has
inconsistent indentation: align both statements inside the else so they clearly
belong together; specifically, in the block that calls await
props.setStatus("completed"); and props.onComplete(); remove the extra leading
spaces before props.onComplete() (and keep the same indentation level as the
await line) so both lines are uniformly indented within the else branch
(referencing includePayments, props.setStatus and props.onComplete to locate the
code).

---

73-83: Duplicate constant definition — import from shared schema instead.

PROJECT_ONBOARDING_STATUSES duplicates projectOnboardingStatusValues defined in packages/stack-shared/src/schema-fields.ts (see context snippet 3). Maintaining two identical lists risks drift and violates DRY.

♻️ Proposed fix: import from shared package

-const PROJECT_ONBOARDING_STATUSES = [
-  "config_choice",
-  "apps_selection",
-  "auth_setup",
-  "domain_setup",
-  "email_theme_setup",
-  "payments_setup",
-  "completed",
-] as const;
-
-type ProjectOnboardingStatus = (typeof PROJECT_ONBOARDING_STATUSES)[number];
+import { projectOnboardingStatusValues, type ProjectOnboardingStatus } from "@stackframe/stack-shared/dist/schema-fields";
+
+const PROJECT_ONBOARDING_STATUSES = projectOnboardingStatusValues;

🤖 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)/new-project/page-client.tsx
around lines 73 - 83, PROJECT_ONBOARDING_STATUSES and ProjectOnboardingStatus
duplicate the canonical list projectOnboardingStatusValues in the shared
package; remove the local constant and type and import
projectOnboardingStatusValues from packages/stack-shared/src/schema-fields.ts,
then recreate the type where needed as (typeof
projectOnboardingStatusValues)[number] (or reference an exported type if
available) and update any local usages to use the imported symbol instead of
PROJECT_ONBOARDING_STATUSES.

apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/new-project/page-client.tsx (4)

188-195: ⚠️ Potential issue | 🟠 Major

deriveInitialSignInMethods currently ignores disabled config flags.

Line 190 pre-seeds methods (credential, magicLink, google, github), so those remain enabled even when config says otherwise.

🐛 Proposed fix

 function deriveInitialSignInMethods(project: AdminOwnedProject): Set<SignInMethod> {
   const config = project.config;
-  const methods = new Set<SignInMethod>([
-    "credential",
-    "magicLink",
-    "google",
-    "github",
-  ]);
+  const methods = new Set<SignInMethod>();

   if (config.credentialEnabled) {
     methods.add("credential");
   }

🤖 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)/new-project/page-client.tsx
around lines 188 - 195, deriveInitialSignInMethods currently pre-populates the
Set with all methods and ignores project.config, so disabled sign-in options
stay enabled; update deriveInitialSignInMethods to read the project's config
(project.config on AdminOwnedProject) and only add each SignInMethod
("credential", "magicLink", "google", "github") to the Set when the
corresponding enable flag in config is true (or present), e.g., check the config
properties that control credentials, magic link, Google, and GitHub before
calling add on the Set.

---

1355-1357: ⚠️ Potential issue | 🟡 Minor

Avoid silently coercing unknown onboarding_status to "completed".

Line 1356 hides unexpected backend values and can incorrectly route users as fully onboarded.

🛡️ Proposed fix

           const onboardingStatus = "onboarding_status" in item ? item.onboarding_status : undefined;
-          statusMap.set(item.id, isProjectOnboardingStatus(onboardingStatus) ? onboardingStatus : "completed");
+          if (onboardingStatus === undefined || onboardingStatus === null) {
+            statusMap.set(item.id, "completed");
+          } else if (isProjectOnboardingStatus(onboardingStatus)) {
+            statusMap.set(item.id, onboardingStatus);
+          } else {
+            throw new Error(`Unexpected onboarding_status "${String(onboardingStatus)}" for project ${item.id}`);
+          }

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/dashboard/src/app/`(main)/(protected)/(outside-dashboard)/new-project/page-client.tsx
around lines 1355 - 1357, The code silently coerces unexpected onboarding_status
values to "completed"; instead, validate onboardingStatus using
isProjectOnboardingStatus and if it returns false, do not default to "completed"
— either set statusMap for item.id to undefined or an explicit "unknown"
sentinel and emit/log an error (or throw) so failures are loud; update the block
around onboardingStatus, isProjectOnboardingStatus, and statusMap.set(item.id,
...) to fail fast and surface the invalid backend value (include item.id and the
raw onboardingStatus in the log/exception).

---

1162-1165: ⚠️ Potential issue | 🟠 Major

"Do This Later" should not call setupPayments().

Line 1163 creates Stripe setup artifacts even when the user explicitly chooses to skip for now.

⚙️ Proposed fix

               <DesignButton
                 className="rounded-xl"
                 variant="outline"
                 loading={saving}
                 onClick={() => runAsynchronouslyWithAlert(() => runWithSaving(async () => {
-                  await props.project.app.setupPayments();
                   await finalizeOnboarding();
                 }))}
               >
                 Do This Later
               </DesignButton>

🤖 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)/new-project/page-client.tsx
around lines 1162 - 1165, The "Do This Later" button is incorrectly invoking
props.project.app.setupPayments() which creates Stripe artifacts; update the
click handler used by runAsynchronouslyWithAlert -> runWithSaving so it does not
call props.project.app.setupPayments() and only calls finalizeOnboarding() for
this path (i.e., remove or conditionally skip the setupPayments() invocation in
the onClick callback where finalizeOnboarding() is called). Ensure you only
change the handler referenced by runAsynchronouslyWithAlert and runWithSaving so
other flows that should perform setupPayments() remain unchanged.

---

446-467: ⚠️ Potential issue | 🔴 Critical

iframe srcDoc is missing sandbox, enabling script execution risk.

Line 463 renders untrusted/templated HTML via srcDoc without sandboxing. That can execute scripts in a sensitive dashboard context.

🔒 Proposed fix

-  const inertPreviewHtml = previewHtml ? `${previewHtml}
-    <script>
-      document.addEventListener('click', function(e) {
-        var target = e.target;
-        while (target && target.tagName !== 'A') {
-          target = target.parentNode;
-        }
-        if (target && target.tagName === 'A') {
-          e.preventDefault();
-          e.stopPropagation();
-        }
-      }, true);
-    </script>
-  ` : previewHtml;
+  const inertPreviewHtml = previewHtml;

   return (
     <iframe
       srcDoc={inertPreviewHtml}
+      sandbox=""
       className="pointer-events-none h-full w-full border-0"
       title="Email theme preview"
     />
   );

🤖 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)/new-project/page-client.tsx
around lines 446 - 467, The iframe is rendering untrusted srcDoc
(inertPreviewHtml) without sandboxing; add a sandbox attribute to the iframe
element (e.g., sandbox="" to block scripts and same-origin) to prevent script
execution and origin access, or if specific features are required, explicitly
whitelist only the minimal flags (e.g., sandbox="allow-popups allow-forms")
rather than allowing scripts or same-origin; update the JSX for the iframe that
uses srcDoc={inertPreviewHtml} to include the appropriate sandbox attribute.

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

102-102: Snapshot updates look correct.

The onboarding_status: "completed" field is properly added to all project response snapshots, reflecting the new default value from the database schema.

However, consider adding an E2E test that explicitly creates or updates a project with a non-default onboarding_status value (e.g., "auth_setup") to verify the API accepts and returns valid status values correctly.

🧪 Suggested test addition

it("updates project onboarding_status", async ({ expect }) => {
  await Project.createAndSwitch();
  const response = await niceBackendFetch("/api/v1/internal/projects/current", {
    method: "PATCH",
    accessType: "admin",
    body: {
      onboarding_status: "auth_setup"
    }
  });
  expect(response.status).toBe(200);
  expect(response.body.onboarding_status).toBe("auth_setup");
});

Based on learnings Applies to **/apps/e2e/**/*.{ts,tsx} : ALWAYS add new E2E tests when you change the API or SDK interface. Generally, err on the side of creating too many tests.

🤖 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/projects.test.ts` at line
102, Add an E2E test that verifies non-default onboarding_status values are
accepted and returned by the API: create or switch to a project using
Project.createAndSwitch(), PATCH /api/v1/internal/projects/current via
niceBackendFetch with body { onboarding_status: "auth_setup" }, assert
response.status is 200 and response.body.onboarding_status equals "auth_setup"
(e.g., add a test case named "updates project onboarding_status" in
apps/e2e/tests/backend/endpoints/api/v1/internal/projects.test.ts).

apps/dashboard/src/app/(main)/(protected)/(outside-dashboard)/new-project/page-client.tsx (1)

1645-1656: Verify fallback to "config_choice" is intentional.

Line 1649 passes selectedProjectStatus ?? "config_choice" to the wizard. While selectedProjectStatus should be non-null at this point (due to the guard at Line 1468-1470), this fallback could silently mask a bug if the status is unexpectedly null.

Consider using a more defensive approach:

🛡️ Suggested change

       <ProjectOnboardingWizard
         project={selectedProject}
-        status={selectedProjectStatus ?? "config_choice"}
+        status={selectedProjectStatus ?? (() => { throw new Error(`Invariant: status should exist for project ${selectedProject.id}`); })()}
         mode={mode}

Or extract to a guarded variable:

const wizardStatus = selectedProjectStatus ?? (() => {
  throw new Error(`Invariant: status should exist for project ${selectedProject.id}`);
})();

As per coding guidelines Prefer ?? throwErr(...) over non-null assertions with good error messages explicitly stating the assumption.

🤖 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)/new-project/page-client.tsx
around lines 1645 - 1656, The code currently silently falls back to
"config_choice" when passing status to ProjectOnboardingWizard; replace that
silent fallback with an explicit invariant check so null/undefined status fails
loudly: compute a guarded wizardStatus from selectedProjectStatus and if it is
null/undefined throw an Error containing the project id (use selectedProject.id)
and a clear message, then pass that wizardStatus into ProjectOnboardingWizard
(referencing ProjectOnboardingWizard and selectedProjectStatus to locate the
change).

apps/backend/src/lib/projects.tsx (2)

131-133: Avoid silently dropping caller-provided onboarding_status when schema is old.

Right now, if a caller sends onboarding_status and the column is missing, the value is ignored without signal. For rollout safety, either throw a clear error or emit a structured warning/metric so this path is visible.

Based on learnings: not used. As per coding guidelines: "Fail early, fail loud. Fail fast with an error instead of silently continuing."

Also applies to: 166-168

🤖 Prompt for AI Agents

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

In `@apps/backend/src/lib/projects.tsx` around lines 131 - 133, The code silently
drops caller-provided onboarding_status when onboardingStatusColumnExists is
false; update the branches that set createData.onboardingStatus (the block using
onboardingStatusColumnExists and options.data.onboarding_status, and the similar
block at the other occurrence) to instead fail loudly: if
options.data.onboarding_status is provided but onboardingStatusColumnExists is
false, throw a clear Error (or call a central validation error helper) naming
the missing column and the caller field (e.g., "onboarding_status provided but
column missing"), so callers see an explicit failure rather than silently losing
their value.

---

105-114: Consider memoizing the column-existence probe to avoid repeating metadata queries.

This check runs on every create/update transaction. Since schema shape changes rarely, a small cache/helper would reduce overhead on hot paths.

🤖 Prompt for AI Agents

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

In `@apps/backend/src/lib/projects.tsx` around lines 105 - 114, The metadata probe
for onboardingStatus currently performs tx.$queryRaw each time (see
onboardingStatusColumnExistsRows and onboardingStatusColumnExists) which is
expensive; introduce a module-level memoized helper (e.g.,
getOnboardingStatusColumnExists) that accepts the Prisma client/transaction
(prisma or tx), returns a cached boolean or runs the query once and caches the
Promise<boolean> for subsequent calls, and replace the direct tx.$queryRaw usage
with calls to that helper; ensure the helper caches per-process and uses the
same query logic as the existing SELECT ... EXISTS, and use the cached boolean
where onboardingStatusColumnExists is currently used.