Follow-up from #8. The frontend fix in #8 removes the Google-login lockout, but there is still no server-side guarantee that a user_profile row exists.
Blockers found by the planner: user_profile has age, gender, height_cm, weight_kg NOT NULL with no defaults (backend/migrations/002_user_management.sql), so a naive auth.users AFTER INSERT trigger would raise and abort every signup. Doing it properly needs: make those columns nullable or give defaults; check 004 trigger_log_weight against NULL weight; audit MealForm, Recommendations, PhotoMealUpload which assume full profile rows.
Deliverable: backend/migrations/009_user_profile_on_signup.sql + doc note in docs/02-database-setup.md that it is manual-apply. Do NOT run against prod from CI.
Follow-up from #8. The frontend fix in #8 removes the Google-login lockout, but there is still no server-side guarantee that a user_profile row exists.
Blockers found by the planner: user_profile has age, gender, height_cm, weight_kg NOT NULL with no defaults (backend/migrations/002_user_management.sql), so a naive auth.users AFTER INSERT trigger would raise and abort every signup. Doing it properly needs: make those columns nullable or give defaults; check 004 trigger_log_weight against NULL weight; audit MealForm, Recommendations, PhotoMealUpload which assume full profile rows.
Deliverable: backend/migrations/009_user_profile_on_signup.sql + doc note in docs/02-database-setup.md that it is manual-apply. Do NOT run against prod from CI.