«المشروع يشتغل في المعاينة ويطيح بعد النشر»
المعاينة داخل Lovable فيها كل الإعدادات جاهزة. لما تنشر على دومينك أو تنقل المشروع لاستضافة ثانية مثل Vercel أو Netlify، تنقص غالبًا متغيرات البيئة، أو يبقى رابط الرجوع بعد تسجيل الدخول في Supabase على رابط المعاينة، أو تطلع صفحة 404 لما أحد يفتح رابط داخلي مباشرة، لأن الاستضافة ما تعرف إن كل الروابط تروح لنفس التطبيق.
كيف تتأكد بنفسك: افتح موقعك المنشور في نافذة تصفح خفي، وسجّل دخول، وافتح رابط صفحة داخلية مباشرة واضغط تحديث. في Supabase افتح Authentication ثم URL Configuration، وتأكد إن دومينك الحقيقي موجود في Site URL و Redirect URLs. فيه أسباب ثانية في درس يشتغل عندك ويطيح بعد النشر؟.
«بيانات المستخدمين مكشوفة لأن قواعد Supabase مفتوحة»
تطبيق Lovable يكلّم Supabase مباشرة من متصفح العميل بالمفتاح العام anon، وهذا المفتاح يشوفه أي أحد يفتح موقعك، وهذا طبيعي. الحماية الوحيدة بعدها هي قواعد RLS على كل جدول. إذا الجدول بدون RLS، أو القاعدة تسمح للكل، أي أحد يقدر يقرأ بيانات كل عملائك أو يعدّلها بدون ما يسجّل دخول.
كيف تتأكد بنفسك: في Supabase افتح Table Editor: أي جدول مكتوب جنبه RLS disabled مكشوف. افتح Security Advisor من لوحة Supabase وشوف التحذيرات. بعدها سجّل دخول بحسابين وجرّب: يقدر الحساب الثاني يشوف طلبات الأول؟ فحوصات أكثر في درس 5 ثغرات في تسجيل الدخول.
«كل تعديل جديد يخرّب صفحة ثانية»
كل طلب تكتبه لـ Lovable ممكن يعدّل ملفات كثير غير اللي تقصده، لأن الصفحات تتشارك نفس المكوّنات. ما فيه اختبارات تنبّه إن شي انكسر، فتكتشف الخراب لما يشتكي عميل.
كيف تتأكد بنفسك: اكتب قائمة بأهم 3 إلى 5 مسارات في منتجك، مثل التسجيل والدخول والدفع، وجرّبها كلها بعد كل تعديل. اربط المشروع بـ GitHub عشان تشوف بالضبط وش الملفات اللي تغيّرت مع كل طلب. إذا خرب شي، ارجع لنسخة سابقة من سجل التعديلات بدل ما تطلب من الذكاء الاصطناعي يصلّح فوق الخراب.