كيف تنقل تطبيقك من Lovable إلى Mythex (الكود والبيانات والنطاق)

لنقل تطبيق من Lovable إلى Mythex، استخرج الكود من Lovable عبر تكامل GitHub الخاص به، ثم أدخله إلى مشروع Mythex بربط المستودع أو استيراد أرشيف، وأعد إضافة أسرارك، واختبر في المعاينة (Preview) قبل النشر. تنتقل الواجهة الأمامية عادةً دون تغييرات. القرارات الحقيقية تتعلق بالخلفية: هل تُبقي مشروع Supabase الحالي، أم تنقل البيانات إلى مكان آخر.

يشرح هذا الدليل النقل كاملاً بالترتيب، ويكون صريحاً بشأن الأجزاء التي تحتاج جهداً.

قبل أن تبدأ: ما الذي ينتقل فعلاً

تطبيق Lovable يتكون من عدة أشياء، ولكل منها طريقة نقل مختلفة.

اكتب هذا الجدول لتطبيقك أولاً. يستغرق ذلك عشر دقائق ويمنع معظم المفاجآت.

الخطوة 1: استخرج كودك من Lovable

توثيق Lovable (حتى سبتمبر 2026) يصف طريقتين للخروج:

• مزامنة GitHub. يستطيع Lovable تصدير مشروعك ومزامنته في الاتجاهين مع GitHub، وتذكر وثائقه دعم github.com في جميع الباقات. اربط GitHub في Lovable، فيصل كودك إلى مستودع تملكه. لاحظ أن Lovable يزامن فرعاً واحداً في كل مرة.
• تنزيل قاعدة الكود. في الباقات المدفوعة لـ Lovable يمكنك تنزيل الكود مباشرة من Project settings → Git.

GitHub هو الخيار الأفضل للنقل: تحصل على السجل الكامل، ويمكنك الاستمرار في المزامنة أثناء اختبار الإعداد الجديد. انظر وثائق تكامل GitHub في Lovable للخطوات الحالية.

قبل أن تغادر Lovable، افتح المستودع وابحث عن:

• ملف .env أو .env.example، وهو يسرد متغيرات البيئة التي يتوقعها التطبيق
• مجلد supabase/، وقد يحتوي على ترحيلات قاعدة البيانات وشيفرة دوال Edge
• سكربتات package.json، وتبين كيف يُبنى التطبيق ويُشغَّل

الخطوة 2: قرر ما تفعله بالخلفية

هذا هو الخيار الأهم. تطبيقات Lovable تستخدم عادةً Supabase لقاعدة البيانات وتسجيل الدخول، إما من خلال مشروع Supabase ربطته بنفسك، أو عبر Lovable Cloud.

الخيار أ: أبقِ مشروع Supabase الخاص بك

إذا كان تطبيقك يتصل أصلاً بمشروع Supabase الخاص بك، فهذا أبسط طريق. يستمر كود التطبيق في استدعاء عنوان Supabase نفسه بالمفاتيح نفسها، فتبقى بياناتك ومستخدموك وملفاتك في مكانها تماماً. أنت تنقل الواجهة الأمامية فقط.

الخيار ب: انتقل بعيداً عن Lovable Cloud

إذا كان تطبيقك يستخدم Lovable Cloud، فإن Lovable يوثّق تصدير قاعدة البيانات ضمن More → Cloud → Overview → Advanced settings. وبحسب وثائق Lovable (حتى سبتمبر 2026):

• يحتوي التصدير على قاعدة البيانات كاملة، البنية والبيانات، بما فيها حسابات المستخدمين وتجزئات كلمات مرورهم.
• لا يتضمن الملفات في التخزين، ولا شيفرة دوال Edge، ولا أسرار مشروعك. كذلك لا تُدرج إعدادات مزودي تسجيل الدخول.
• تغطي التصديرات قواعد بيانات حتى 15 غيغابايت، ويمكن أن يبلغ حجم الملف 5 غيغابايت كحد أقصى، ويمكنك طلب تصدير واحد كل 24 ساعة.
• لا يوجد نقل بنقرة واحدة من Cloud إلى Supabase، والوجهتان المدعومتان لنقل خلفية Cloud هما Supabase المُدار أو Supabase المستضاف ذاتياً.

لذلك فالطريق العملي عادةً هو: استعادة التصدير في مشروع Supabase الخاص بك، وإعادة إنشاء حاويات التخزين ودوال Edge وإعدادات المصادقة هناك، ثم معاملته كالخيار أ. انظر صفحة الإعدادات المتقدمة في Lovable للتفاصيل.

الخيار ج: انقل كل شيء إلى قاعدة بيانات Mythex

يمكن لـ Mythex أن يمنح المشروع قاعدة بيانات Postgres مخصصة. ونقل بياناتك إليها ممكن، لكنه يعني إعادة كتابة كل موضع يستخدم فيه التطبيق مكتبة Supabase للعميل، ولأن Mythex لا يوفر تسجيل دخول مدمجاً للمستخدمين النهائيين، ستحتاج أيضاً إلى ربط مزود مصادقة منفصل. وهذا إعادة بناء حقيقية للخلفية، لا نقلاً. اجعله لاحقاً، إن فعلت أصلاً، بعد أن يعمل التطبيق على Mythex مع Supabase.

الخطوة 3: أدخل الكود إلى Mythex

أنشئ مشروعاً جديداً وفارغاً في Mythex. ثم افعل أحد الأمرين:

• استورد أرشيفاً. افتح project settings → Export → Import into this project وارفع ملف .zip أو .tar.gz أو .tgz. زر Download ZIP في GitHub يعطيك ملفاً يعمل هنا.
• اربط GitHub واسحب الكود. اربط GitHub في إعدادات المشروع، ثم اربط المستودع واسحب. مزامنة GitHub ميزة في باقة Pro.

الاستيراد يستبدل ملفات المشروع، لذا استخدم مشروعاً فارغاً. تُحذف ملفات .env الموجودة في الأرشيف عند الاستيراد، فلا تنتقل أي أسرار بالخطأ. بعد الاستيراد الناجح، يمكن لـ Mythex أن يفتح محادثة جديدة يثبّت فيها الوكيل التبعيات، ويكتشف طريقة تشغيل التطبيق، ويشغّل المعاينة (Preview). يمكنك توجيه تلك المحادثة كأي محادثة أخرى. التفاصيل في بعد الاستيراد.

إذا لم تعمل المعاينة تلقائياً، اطلب:

هذا المشروع مُصدَّر من Lovable. إنه تطبيق React + TypeScript + Tailwind يستخدم Supabase. ثبّت التبعيات، واكتشف أمر التشغيل من package.json، واجعل المعاينة تعمل. لا تغيّر أي كود للتطبيق بعد.

الخطوة 4: أعد إضافة أسرارك

افتح project settings → Secrets وأضف كل قيمة يحتاجها تطبيقك. بالنسبة لتطبيق يعتمد على Supabase، فهذا يعني عادةً عنوان مشروع Supabase ومفتاح الواجهة العام (anon أو publishable). خذ الأسماء من .env.example أو من المكان الذي يقرأ فيه الكود هذه القيم.

قاعدتان:

• المفاتيح العامة فقط تنتمي إلى متغيرات الواجهة الأمامية. في تطبيق Vite، أي متغير يبدأ بـ VITE_ يُدمج في شيفرة JavaScript التي يحملها كل زائر.
• لا تضع أبداً مفتاح service role الخاص بـ Supabase في شيفرة الواجهة الأمامية. إذا احتاجت دالة من جهة الخادم إليه، فيبقى في جهة الخادم.

ثم اطلب من الوكيل التأكد من أن التطبيق يقرأها:

تحقق من متغيرات البيئة التي يقرأها هذا التطبيق. اذكر أي منها غير مضبوط في أسرار المشروع بعد، ولا تطبع قيمها.

يشرح دليلنا عن متغيرات البيئة والأسرار الفرق بين القيم العامة والخاصة.

الخطوة 5: اختبر قبل أن تبدّل أي شيء

تطبيق Lovable ما زال يعمل، فلا داعي للاستعجال. اختبر نسخة Mythex في المعاينة أمام تدفقات حقيقية:

• التسجيل، وتسجيل الدخول، والخروج، وإعادة تعيين كلمة المرور
• إنشاء سجل وتعديله وحذفه
• رفع ملف، إن كان تطبيقك يفعل ذلك
• أي شيء يستدعي دالة Edge أو واجهة برمجية لطرف ثالث

في مصادقة Supabase إعداد واحد يسهل نسيانه: عناوين إعادة التوجيه (redirect URLs) المسموح بها لرسائل تسجيل الدخول وإعادة تعيين كلمة المرور. أضف عناوين المعاينة والنشر في Mythex إليها، وإلا فستعود تسجيلات الدخول إلى النطاق القديم.

أمر /test في Mythex يجعل الوكيل يتصفح معاينتك كمستخدم ويبلغ عن التدفقات المعطلة. يقدم دليلنا عن اختبار تطبيقك قبل الإطلاق قائمة أوسع.

الخطوة 6: انشر وانقل النطاق

حين يعمل كل شيء، انشر من مساحة العمل للحصول على عنوان <slug>.mythex.app. اختبر مرة أخرى هناك، لأن التطبيق المنشور نسخة منفصلة عن مشروعك.

في باقة Pro يمكنك ربط نطاقك الخاص. حدّث سجلات DNS لدى مزود النطاق، وأضف العنوان الجديد إلى عناوين إعادة التوجيه المسموح بها في Supabase، ثم أوقف نسخة Lovable فقط بعد ذلك. يغطي دليلنا عن ربط نطاق مخصص خطوات DNS بالتفصيل.

أخطاء شائعة

• نقل قاعدة البيانات والواجهة الأمامية في الوقت نفسه. انقل الواجهة الأمامية أولاً، وتحقق أنها تعمل مع الخلفية الحالية، ثم قرر بشأن البيانات.
• نسيان دوال Edge. إذا كان التطبيق يستدعي دوال Supabase Edge، فهي إما أن تبقى في Supabase أو تحتاج إلى إعادة كتابتها كشيفرة خادم. لا تعمل داخل واجهة Vite الأمامية.
• لصق مفتاح service role في الواجهة الأمامية. إنه يمنح وصولاً كاملاً إلى قاعدة بياناتك لأي شخص يفتح أدوات المطور.
• نسيان عناوين إعادة التوجيه في المصادقة. يعمل تسجيل الدخول في المعاينة، ثم يفشل على النطاق الحقيقي.
• تبديل DNS قبل اختبار عنوان النشر. اختبر عنوان mythex.ai أولاً، فتغييرات DNS تستغرق وقتاً للتراجع عنها.
• الاستيراد إلى مشروع فيه عمل سابق. الاستيراد يستبدل الملفات. استخدم مشروعاً جديداً.

متى يكون البقاء على Lovable منطقياً

كن صادقاً مع نفسك بشأن سبب النقل. يقدم Lovable تعديلات مرئية بالنقر على المعاينة، وخلفية متكاملة عبر Lovable Cloud، ولا يقدم Mythex أياً من ذلك. إذا كانت هذه الأشياء ما تعتمد عليه يومياً، فالنقل يكلفك أكثر مما يفيدك. Mythex أنسب إذا أردت محرر كود حقيقياً وطرفية بجانب المحادثة، ورصيد أرصدة واحداً للبناء والاستضافة، أو أردت تشغيل مجموعة تقنية مختلفة. يقارن دليل بدائل Lovable وصفحة Mythex مقابل Lovable الخيارين بتفصيل أكبر.

قائمة مراجعة النقل

• حصرت كل أجزاء التطبيق: الكود، وقاعدة البيانات، والمستخدمين، والملفات، والدوال، والأسرار، والنطاق
• الكود مُزامن مع مستودع GitHub تملكه
• اتُخذ قرار الخلفية (الإبقاء على Supabase، أو تصدير من Lovable Cloud)
• الكود مُستورد إلى مشروع Mythex فارغ، والمعاينة تعمل
• أُعيدت إضافة الأسرار؛ ولا توجد مفاتيح خاصة في متغيرات VITE_
• حُدّثت عناوين إعادة التوجيه في المصادقة للعناوين الجديدة
• اختُبر التسجيل وتسجيل الدخول وتدفقات البيانات الأساسية والرفع في المعاينة
• نُشر التطبيق واختُبر مرة أخرى على عنوان mythex.ai
• نُقل DNS، ولم يُوقف التطبيق القديم إلا بعد تأكيد الجديد

لجانب Mythex، انظر GitHub والتصدير والاستيراد في الوثائق.

الأسئلة