Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/aluno/dashboard/page.tsx` at line 58, The dashboard flow currently
mixes `user.email` and `user.email!`, which leaves the no-email OAuth path
inconsistent. In `page.tsx`, handle the email once at the start of the component
or handler by reading `user.email` into a local `email` variable, then guard or
redirect early if it is missing before any Prisma queries. After that, reuse the
same `email` variable throughout the rest of the logic instead of accessing
`user.email` again.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/aluno/dashboard/page.tsx` around lines 81 - 103, The `catch` in
`dashboard/page.tsx` is too broad and currently treats every
`prisma.aluno.create` failure as a concurrent insert. Narrow the handler around
the `aluno` creation path to only recover from the unique-constraint race (check
for Prisma `P2002`), then keep the existing `findUnique` refetch; for any other
error, log it and rethrow so real DB/validation failures are not swallowed. Use
the `prisma.aluno.create` and fallback `prisma.aluno.findUnique` block as the
fix point.

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/aluno/dashboard/page.tsx, line 46:

<comment>The auto-provision logic is core business logic, but its success and failure paths are not exercised by the current tests. `page.test.tsx` only mocks `prisma.aluno.findUnique` and does not cover the new `prisma.aluno.create` call or the race-condition refetch in the catch block. Consider adding tests that mock a successful creation and simulate the unique-violation race case so both branches are validated.</comment>

<file context>
@@ -34,7 +34,74 @@ export default async function AlunoDashboardPage() {
+  // already-unique auth uid). Admin can fix the real CPF later. Throws on the
+  // rare race where two concurrent requests both miss findUnique — caught below
+  // surfaces as the original empty-state so the next request finds the row.
+  if (!aluno) {
+    const meta = user.user_metadata ?? {};
+    const nomeCompleto =
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/aluno/dashboard/page.tsx, line 81:

<comment>First-time OAuth users can still land on the “perfil de aluno não foi encontrado” fallback for real create failures because this catches every `prisma.aluno.create` error as if it were only a race. Narrowing this to Prisma `P2002` unique-constraint errors and rethrowing/logging other errors would preserve the intended auto-provisioning behavior and make failures visible.</comment>

<file context>
@@ -34,7 +34,74 @@ export default async function AlunoDashboardPage() {
+          },
+        },
+      });
+    } catch {
+      // Race: another request created the row. Refetch instead of crashing.
+      aluno = await prisma.aluno.findUnique({
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At supabase/config.toml, line 157:

<comment>Local password signup/email confirmation will now send developers to the production app when using the local Supabase stack. The `signUp` flow does not provide `emailRedirectTo`, so this production `site_url` becomes the fallback for confirmation links; consider adding an explicit local/prod callback URL in that signup call or separating local/cloud auth config.</comment>

<file context>
@@ -150,8 +150,11 @@ max_indexes = 5
+# fails allowlist validation, so leaving it as localhost in a linked cloud project sends
+# users to localhost on every OAuth redirect mismatch. Local dev resolves via
+# additional_redirect_urls (localhost entry) instead.
+site_url = "https://smartmanagementsystem.vercel.app"
 # A list of *exact* URLs that auth providers are permitted to redirect to post authentication.
 additional_redirect_urls = [
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/aluno/dashboard/page.tsx, line 48:

<comment>OAuth users with an empty `full_name`/`name` metadata value can be auto-provisioned with a blank display name because `??` does not fall back on empty strings. Treating non-empty trimmed strings as valid before falling back to email keeps the dashboard identity usable.</comment>

<file context>
@@ -34,7 +34,74 @@ export default async function AlunoDashboardPage() {
+  // surfaces as the original empty-state so the next request finds the row.
+  if (!aluno) {
+    const meta = user.user_metadata ?? {};
+    const nomeCompleto =
+      (meta.full_name as string | undefined) ??
+      (meta.name as string | undefined) ??
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/aluno/dashboard/page.tsx, line 63:

<comment>The `select` projection block (15 lines) is duplicated verbatim between the `aluno.create()` call and the catch block's `findUnique()` refetch. If the projection changes — adding a new field, renaming a relation — both copies must be updated in sync. Consider extracting the shared `select` object into a variable or function to keep them consistent.</comment>

<file context>
@@ -34,7 +34,74 @@ export default async function AlunoDashboardPage() {
+          fotoUrl,
+          cpf: cpfPlaceholder,
+        },
+        select: {
+          id: true,
+          nomeCompleto: true,
</file context>