Database table references exist in schema

A hallucinated table name is one of the clearest markers of AI-generated database code: the model invents a plausible name (userProfile, user_profiles) that differs from the actual schema (users, profiles). Prisma throws Cannot read property 'findMany' of undefined at runtime — a hard crash. Supabase returns a PostgREST 404 or an empty result set, which can silently suppress data that the application treats as authoritative. In both cases the failure mode is a runtime data-layer outage tied directly to reference-integrity drift (CWE-1188, OWASP A08: Software and Data Integrity Failures). The mismatch is undetectable at build time in Supabase projects unless type generation is wired into CI.

Fix each hallucinated table name to exactly match the schema definition. Prisma model names are camelCase client accessors derived from PascalCase model names; Supabase table names are the literal CREATE TABLE identifier (typically snake_case).

// Prisma — model 'User' in schema.prisma → prisma.user (camelCase)
await prisma.userProfile.findMany()  // Bad: 'userProfile' not in schema
await prisma.user.findMany()         // Good

// Supabase — must match CREATE TABLE name in migrations exactly
await supabase.from('user_profiles').select('*')  // Bad: table is 'profiles'
await supabase.from('profiles').select('*')        // Good

For Supabase projects, run supabase gen types typescript --local > src/database.types.ts and use the generated Database type with the client to get compile-time table name checking.