هل علق Lovable أو Bolt في حلقة إصلاح الأخطاء؟ كيف تُنهي نسختك الأولية (MVP)

تطلب من أداة البناء إصلاح تسجيل الدخول، فيعمل، لكن لوحة التحكم تصبح فارغة. أمر آخر يعيد لوحة التحكم ويُعطّل تسجيل الدخول من جديد. إذا كان Lovable أو Bolt عالقًا في إصلاح الأخطاء نفسها، فالخطوة المفيدة التالية هي تحسين الأدلة حول عطل واحد. المزيد من التغييرات لا يعني تلقائيًا المزيد من التقدّم.

لماذا يعلق تطبيق مبني بالذكاء الاصطناعي في حلقة إصلاح؟

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

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

ضع قاعدة توقف عملية: إذا عاد العَرَض نفسه بعد محاولة إصلاح مركّزة، فتوقف عن تكرار الأمر واجمع نوعًا مختلفًا من الأدلة. هذه عادة عمل، وليست حدًا موثقًا في المنصة. وهي تحمي المشروع الصغير من تراكم تغييرات غير مترابطة بينما لا يستطيع أحد تفسير ما الذي يتعطل.

هل المعطّل هو معاينة أداة البناء أم تطبيقك؟

افحص بيئة أداة البناء بشكل منفصل عن تطبيقك قبل إعادة كتابة الشيفرة. فحادثة في المنصة أو مشكلة في اتصال المعاينة ليست دليلًا على أن بنية منتجك تحتاج إلى استبدال.

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

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

ما الذي يجب حفظه قبل تجربة إصلاح آخر؟

احتفظ بأحدث حالة مفيدة للشيفرة، وحدّد البيانات التي قد يتأثر بها الإصلاح. فسجلّ الشيفرة والنسخ الاحتياطية لقاعدة البيانات يحلّان مشكلات استعادة مختلفة.

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

1. سمِّ آخر حالة عملت فيها الرحلة الرئيسية، مع طابع زمني أو مُعرّف commit.
2. سجّل العطل الحالي، واحفظ أي عمل مفيد غير مُثبَّت عبر سير العمل المدعوم في مشروعك.
3. أنشئ نسخة احتياطية مناسبة لقاعدة البيانات أو نسخة اختبار آمنة قبل أي عمل يغيّر البيانات أو المخطط.
4. دوّن أي مشروع وأي بيئة تحتوي على مستخدمين فعليين، حتى يمكن اختبار الإصلاح بعيدًا عنهم.

كيف يبدو أمر الإصلاح المفيد؟

يحدد أمر الإصلاح المفيد عطلًا واحدًا قابلًا لإعادة الإنتاج، ويقدّم الأدلة ذات الصلة، ويقيّد نطاق التغيير المقترح. اطلب تفسيرًا للسبب قبل أن تأذن بتنفيذ لا تستطيع تقييمه.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

هذا المثال افتراضي؛ استبدل تفاصيله بما لاحظته فعلًا. استجابة 403 هي دليل على فشل في الوصول، وليست إذنًا بإزالة التحقق من الصلاحيات. أبقِ كلمات المرور والرموز (tokens) وسلاسل الاتصال وسجلات العملاء خارج الأوامر ولقطات الشاشة.

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

كيف تعرف أن الإصلاح نجح فعلًا؟

ينجح الإصلاح عندما تُنتج الخطوات الأصلية النتيجة المتوقعة، وتظل المسارات المجاورة المهمة تعمل بشكل صحيح. اختبر الحالة المحفوظة بعد التحديث، لا رسالة النجاح المؤقتة فقط.

1. كرّر العطل الأصلي بحساب جديد وبالمدخلات نفسها.
2. حدّث التطبيق أو أعد فتحه وتأكد من أن النتيجة حُفظت بشكل صحيح.
3. كرّر ذلك بحساب عادي ثانٍ وتحقّق من حدود الملكية المقصودة.
4. جرّب حالة فشل واحدة، مثل مدخلات غير صالحة أو طلب مقطوع، في بيئة اختبار آمنة.
5. افحص المسارات المجاورة التي تشترك في الشيفرة المُعدّلة، ثم شغّل الفحوصات ذات الصلة في المشروع والبناء الإنتاجي.

متى يجب الاستعانة بمطوّر؟

استعن بمطوّر عندما لا تستطيع تفسير تغيير في مسار حرج أو التحقق منه بثقة، أو عندما يعجز تحقيق مركّز عن عزل السبب. وتستدعي صلاحيات الدفع، وانكشاف البيانات بين الحسابات، والتغييرات المتكررة في قاعدة البيانات عنايةً خاصة.

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

يتضمن التسليم الجيد رابط التطبيق، وصلاحية وصول مدعومة إلى المشروع أو المستودع، وخطوات إعادة الإنتاج، وتسجيل شاشة قصيرًا، والخطأ بعد تنقيته، وآخر إصدار يعمل. أضف المرحلة التالية المنتظرة للعملاء والميزات التي يجب ألا تُمسّ. ولا تشارك بيانات الاعتماد إلا عبر آلية مناسبة لمشاركة الأسرار أو منح صلاحيات الوصول إلى الحسابات.

ماذا يجب أن يتضمن إصدارك التالي؟

يجب أن يُغلق إصدارك التالي مجموعة صغيرة وقابلة للقياس من رحلات المستخدم المتعطلة. أبقِ طلبات الميزات منفصلة حتى تُختبر تلك الرحلات على التطبيق المنشور.

استخدم خطة إطلاق MVP من 12 فحصًا لتحديد الثغرات المجاورة بعد الإصلاح. وإذا كان التطبيق يعمل في المعاينة لكنه يتعطل عند نشره على Replit، فاستخدم قائمة التحقق لنشر تطبيقات Replit. وللحصول على مساعدة عملية، اختر نقطة انطلاقك من صفحة Lovable أو Bolt واحجز مكالمة. أحضر معك المسار المتعطل؛ فالمحادثة الأولى يجب أن تساعد في تحديد خطوة تالية مفيدة.